From nobody Mon Jan 4 05:48:38 2021 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 88C903A0D3A; Mon, 4 Jan 2021 05:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=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 5hcIHUPnsuJ8; Mon, 4 Jan 2021 05:48:32 -0800 (PST) Received: from p130.piuha.net (p226.piuha.net [193.234.219.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2CF3A0D39; Mon, 4 Jan 2021 05:48:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A9CBB66012A; Mon, 4 Jan 2021 15:48:29 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erltOKfLdTOz; Mon, 4 Jan 2021 15:48:27 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id D11D166019D; Mon, 4 Jan 2021 15:48:27 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <160702546541.14061.15940689920006174458@ietfa.amsl.com> Date: Mon, 4 Jan 2021 15:48:26 +0200 Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <160702546541.14061.15940689920006174458@ietfa.amsl.com> To: Brian Weis X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [Last-Call] Secdir last call review of draft-ietf-core-dev-urn-08 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, 04 Jan 2021 13:48:37 -0000 Brian:=20 Many thanks for your review. I=E2=80=99m going through the various = review comments and taking them into account. I agree with the three = points you made. A new version will be submitted soon, for the moment = you can see the changes in = https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--08.diff.html = and https://arkko.com/ietf/core/draft-ietf-core-dev-urn.txt Jari > On 3 Dec 2020, at 21.57, Brian Weis via Datatracker = wrote: >=20 > Reviewer: Brian Weis > Review result: Serious Issues >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should > treat these comments just like any other last call comments. >=20 > The summary of the review is Ready with nits. >=20 > This document generally defines a new URN namespace for hardware > device identifiers, and then further defines the URN body layout > for several types of devices, where devices are identified by a > global identity (e.g., a MAC address, organizational-specific serial > number, etc.). >=20 > Long-term identifiers have privacy considerations, and these are > well documented here. >=20 > Here are some things that ought to be thought about: >=20 > (1) The Security Considerations section seems to focus on concerns > around devices not allowing the device identifiers to be modified, > and gives rather broad advice about a DEV URN implementation > faithfully representing the device. It would be good for this section > to also warn implementors of the risks of a DEV URN being transmitted > without integrity protection. That is, if the device faithfully > represents itself, a man in the middle changing the DEV URN in a > protocol may cause the system using the device to not manage the > device properly, or in some manner inappropriately adjust the = privileges > allowed by the device within that system. >=20 > (2) Section 1 says about privacy =E2=80=9CNote that long-term stable = unique > identifiers are problematic for privacy reasons and should be used > with care or avoided as described in [RFC7721].=E2=80=9D Given the = later > guidance that =E2=80=9CThe DEV URN type SHOULD only be used for = persistent > identifiers=E2=80=9D, I think the =E2=80=9Cor avoided=E2=80=9D portion = of that sentence is > inappropriate for this document. >=20 > (3) Section 5 begins with =E2=80=9CThe following three examples = provide > examples of MAC-based, 1-Wire, and Cryptographic identifiers=E2=80=9D. = There=20 > are now more than three examples provided (thanks for that!), and=20 > it appears that cryptographic identifiers have ben removed in an > earlier draft. >=20 >=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Mon Jan 4 05:55:43 2021 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 546273A0D3D; Mon, 4 Jan 2021 05:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=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 nGnth4n71ERe; Mon, 4 Jan 2021 05:55:40 -0800 (PST) Received: from p130.piuha.net (p226.piuha.net [193.234.219.226]) by ietfa.amsl.com (Postfix) with ESMTP id E7D553A0CC5; Mon, 4 Jan 2021 05:55:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 518A166019D; Mon, 4 Jan 2021 15:55:38 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45jR3oP_foq2; Mon, 4 Jan 2021 15:55:35 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 93C7C66012A; Mon, 4 Jan 2021 15:55:35 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <160672688076.4884.18269575790406202908@ietfa.amsl.com> Date: Mon, 4 Jan 2021 15:55:34 +0200 Cc: ops-dir@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core Content-Transfer-Encoding: quoted-printable Message-Id: <6242325C-CDC5-4C8E-8E58-50CC74E0EFA2@piuha.net> References: <160672688076.4884.18269575790406202908@ietfa.amsl.com> To: Dan Romascanu X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [Last-Call] Opsdir last call review of draft-ietf-core-dev-urn-08 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, 04 Jan 2021 13:55:41 -0000 Dan: Many thanks for your review. Jari > On 30 Nov 2020, at 11.01, Dan Romascanu via Datatracker = wrote: >=20 > Reviewer: Dan Romascanu > Review result: Ready >=20 > 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. >=20 > 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. >=20 > This document is READY from an OPS-DIR perspective. >=20 >=20 >=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Mon Jan 4 06:10:41 2021 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 ACCFB3A0D6A; Mon, 4 Jan 2021 06:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 4hhBsqqMMv6S; Mon, 4 Jan 2021 06:10:36 -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 04DAA3A0D69; Mon, 4 Jan 2021 06:10:32 -0800 (PST) Received: from [192.168.217.118] (p548dc939.dip0.t-ipconnect.de [84.141.201.57]) (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 4D8cwQ2mHWzyrT; Mon, 4 Jan 2021 15:10:30 +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: Date: Mon, 4 Jan 2021 15:10:30 +0100 Cc: Brian Weis , Last Call , draft-ietf-core-dev-urn.all@ietf.org, "core@ietf.org WG (core@ietf.org)" , secdir@ietf.org X-Mao-Original-Outgoing-Id: 631462229.9462039-8f8dc25ce089c46f5d6667f713835f73 Content-Transfer-Encoding: quoted-printable Message-Id: References: <160702546541.14061.15940689920006174458@ietfa.amsl.com> To: Jari Arkko X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] [Last-Call] Secdir last call review of draft-ietf-core-dev-urn-08 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, 04 Jan 2021 14:10:39 -0000 On 2021-01-04, at 14:48, Jari Arkko wrote: >=20 > = https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--08.diff.html So you can=E2=80=99t have a number zero? Might be worth calling out alongside the fact that there are no leading = zeroes. (=46rom a maintainability POV, calling positive-only numbers = =E2=80=9Cnumber=E2=80=9D in the ABNF is a trap waiting for the next = extension. These are all PENs, no?) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jan 4 07:06:17 2021 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 24AED3A0DCD; Mon, 4 Jan 2021 07:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=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 0qlobdJNMXyu; Mon, 4 Jan 2021 07:06:13 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id BA00B3A0DBB; Mon, 4 Jan 2021 07:06:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5060266019D; Mon, 4 Jan 2021 17:06:12 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ty5YXKIbf6WE; Mon, 4 Jan 2021 17:06:08 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id D0EE966012A; Mon, 4 Jan 2021 17:06:07 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <160608671301.5921.450198697310395020@ietfa.amsl.com> Date: Mon, 4 Jan 2021 17:06:07 +0200 Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <160608671301.5921.450198697310395020@ietfa.amsl.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-dev-urn-08 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, 04 Jan 2021 15:06:16 -0000 Christer, Many thanks for your review! Inline: > Section 6.1. says: >=20 > "The URNs generated according to the rules defined in this document > result in long-term stable unique identifiers for the devices." >=20 > - What are those rules? >=20 > In Section 3.3 I do see the following statement: >=20 > "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." >=20 > Is that what you refer to as rules? Or, have I missed something? >=20 > 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? I think we created confusion with the way that the 6.1 sentence was = formulated. There=E2=80=99s no specific rules; we were just trying to = refer to the use of DEV URNs, and make the point that if you keep = sending your MAC address in some protocol, it may actually create a = privacy problem as others may be able to track you based on that = identity (among others). We were also not trying to make any new applicability statement in the = security considerations, beyond what was already said earlier in the = document. I have reformulated the text, it now reads: DEV URNs often represent long-term stable unique identifiers for devices. Such identifiers may have privacy and security implications because they may enable correlating information about a specific device over a long period of time, location tracking, and device specific vulnerability exploitation [RFC7721].=20 Does this clarify the issue? The full new version with other changes is at = https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--08.diff.html > Section 3.1. says: >=20 > "The DEV URNs identify devices with device-specific identifiers such = as network > card hardware addresses." >=20 > - Can there be multiple DEV URNs associated with a single device? Yes. Section 3.3. says this now in the new version: And of course, a single device may=09 (and often does) have multiple identifiers, e.g,. identifiers=09= associated with different link technologies it supports. > Section 3.1. says: >=20 > "DEV URN is global in scope." >=20 > - What does that actually mean? See RFC 8141 S6.4.1 item 2; we=E2=80=99re requested to specify the scope = of the applicability, and it is not e.g. a single nation of company. But I changed the text to read: DEV URNs are scoped to be globally applicable (see [RFC8141] Section 6.4.1) and enable systems to use these identifiers from multiple sources in an interoperable manner. > 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. That would be good, thanks for the suggestion. I added one example. Jari From nobody Tue Jan 5 01:02:33 2021 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 204C33A10F5; Tue, 5 Jan 2021 01:02:26 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 UPen2S6k6oly; Tue, 5 Jan 2021 01:02:24 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 32AFF3A10B1; Tue, 5 Jan 2021 01:02:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 492306601EB; Tue, 5 Jan 2021 11:02:20 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta2NE9S--4Py; Tue, 5 Jan 2021 11:02:19 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 407DA66012A; Tue, 5 Jan 2021 11:02:19 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Tue, 5 Jan 2021 11:02:18 +0200 Cc: secdir@ietf.org, Last Call , draft-ietf-core-dev-urn.all@ietf.org, "core@ietf.org WG (core@ietf.org)" , Brian Weis Content-Transfer-Encoding: 7bit Message-Id: References: <160702546541.14061.15940689920006174458@ietfa.amsl.com> To: Carsten Bormann X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [Last-Call] Secdir last call review of draft-ietf-core-dev-urn-08 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, 05 Jan 2021 09:02:28 -0000 Thanks Carsten. Will change it. Jari From nobody Tue Jan 5 01:07:06 2021 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 228773A00D8; Tue, 5 Jan 2021 01:07:05 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <160983762509.17933.3641876647275097864@ietfa.amsl.com> Date: Tue, 05 Jan 2021 01:07:05 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-dev-urn-09.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, 05 Jan 2021 09:07:05 -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-09.txt Pages : 20 Date : 2021-01-05 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-core-dev-urn-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dev-urn-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 5 01:45:25 2021 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 9AD043A08B0; Tue, 5 Jan 2021 01:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 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, 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 LBPSIvfS25-S; Tue, 5 Jan 2021 01:45:17 -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 DFB4F3A08AE; Tue, 5 Jan 2021 01:45:16 -0800 (PST) Received: from [192.168.217.118] (p548dc939.dip0.t-ipconnect.de [84.141.201.57]) (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 4D96zt2kLqzydr; Tue, 5 Jan 2021 10:45:14 +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: Date: Tue, 5 Jan 2021 10:45:13 +0100 Cc: Last Call , draft-ietf-core-dev-urn.all@ietf.org, Brian Weis , "core@ietf.org WG (core@ietf.org)" , secdir@ietf.org X-Mao-Original-Outgoing-Id: 631532712.975024-90f5b59b5fd1c4bfa4ad14dccfb4685d Content-Transfer-Encoding: quoted-printable Message-Id: <5B3A8129-2880-42CE-BB83-01F7F10A3DD5@tzi.org> References: <160702546541.14061.15940689920006174458@ietfa.amsl.com> To: Jari Arkko X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] [Last-Call] Secdir last call review of draft-ietf-core-dev-urn-08 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, 05 Jan 2021 09:45:21 -0000 On 2021-01-05, at 10:02, Jari Arkko wrote: >=20 > Thanks Carsten. Will change it. Thanks =E2=80=94 -09 looks good! (Inconsequential typo in Appendix A, though: s/ABN/ABNF/) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 6 06:16:18 2021 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 670FA3A0BFF; Wed, 6 Jan 2021 06:16: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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <160994257634.11721.4203784315583553816@ietfa.amsl.com> Date: Wed, 06 Jan 2021 06:16:16 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-new-block-04.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: Wed, 06 Jan 2021 14:16: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 : Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission Authors : Mohamed Boucadair Jon Shallow Filename : draft-ietf-core-new-block-04.txt Pages : 32 Date : 2021-01-06 Abstract: This document specifies alternative Constrained Application Protocol (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. These options are similar to the CoAP Block1 and Block2 Options, not a replacement for them, but do enable faster transmission rates for large amounts of data with less packet interchanges as well as supporting faster recovery should any of the blocks get lost in transmission. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-new-block-04 https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 6 07:24:29 2021 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 DB34A3A0F74 for ; Wed, 6 Jan 2021 07:24: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 JvVXuRhxUFHS for ; Wed, 6 Jan 2021 07:24:17 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 779003A0F44 for ; Wed, 6 Jan 2021 07:24:17 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kxAfW-0001ZA-N2; Wed, 06 Jan 2021 15:24:14 +0000 From: To: , Cc: , Date: Wed, 6 Jan 2021 15:24:29 -0000 Message-ID: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdbkP95w26IDeT0/RXqAAvtrJTaBNg== Content-Language: en-gb Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 06 Jan 2021 15:24:28 -0000 Hi Christian, Once again, thank you for the comprehensive review. Responses part 2. A new version (-04) of the draft has been published and can be found at https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ Part 1 responses were covered in the main by version -03, so you may want to look at the -02 to -04 differences. The Congestion Control section has been re-written to simplify how things work and has a new set of definitions. There is a separation of Confirmable and Non-Confirmable Congestion Control with the stated assumption that all of a body is sent as Non-Confirmable or Confirmable. Otherwise, see inline. Regards Jon > > * The list of pros and cons (with the cons being almost trivial) does > not explain to the reader why these are not a replacement; I suggest > to add: [Jon] Another disadvantage addition NEW To reduce the transmission times for CON transmission of large bodies, NSTART needs to be increased from 1, but this affects congestion control where other parameters need to be tuned (Section 4.7 of [RFC7252]). Such tuning is out of scope of this document. > > * "If the client transmits a new body of data with a new Request-Tag > to": Processing parallel requests is something Request-Tag opens up. I > don't see why there's a MUST to that; the server certainly MAY drop > the old request, but it may just as well process them in parallel. [Jon] The intent here was that garbage collection would take place sooner than later - especially when running in a lossy environment and the client has updated information to transmit. I agree that Request-Tag enables the possibility of sending multiple block requests with different payloads, and so there is a possibility that the client starts sending body A, then decides to send body B and terminate A, but a packet from B arrives before a packet from body A is received and so things fail as A does not complete. OLD If the client transmits a new body of data with a new Request-Tag to the same resource on a server, the server MUST remove any partially received body held for a previous Request-Tag for that resource. NEW If a server receives payloads with different Request-Tags for the same resource, it should continue to process all the bodies as it has no way of determining which is the latest version, or which body, if any, the client is terminating the transmission for. If the client elects to stop the transmission of a complete body, it SHOULD "forget" all tracked tokens associated with the body's Request-Tag so that a reset message is generated for the invalid token in the 4.08 (Request Entity Incomplete) response. The server on receipt of the reset message SHOULD delete the partial body. END > > * "If the server receives a duplicate block with the same Request-Tag": > Why? Being silent is the default on nonterminal blocks alredy, but in > a situation like figure 5 if the 2.04 is lost, that rule would make > it impossible for the client to ever get a successful response. > > A better rule here may be to say that it processes it all the same > (and if the payload is distinct from the first transmission's payload, > it should err out.) [Jon] Fair point OLD If the server receives a duplicate block with the same Request-Tag, it SHOULD silently ignore the packet. NEW If the server receives a duplicate block with the same Request-Tag, it SHOULD ignore the payload of the packet, but MUST still respond as if the block was received for the first time. > > * "If the server receives multiple requests (implied or otherwise) for > the same block, it MUST only send back one instance of that block.": > This might be read as "ever" rather than "per incoming request", where > probably the latter is meant. [Jon] This text has already been updated following another review "OLD If the server receives multiple requests (implied or otherwise) for the same block, it MUST only send back one instance of that block. NEW If the request includes multiple Q-Block2 Options and these options overlap (e.g., combination of M being set (this and all the later blocks) and being unset (this individual block)) resulting in an individual block being requested multiple times, the server MUST only send back one instance of that block. This behavior is meant to prevent amplification attacks." > > * "The ETag Option MUST NOT be used": This is more a factural than a > normative statement; it *can* not be used there as the server would > respond thusly. It may be used, but then that indicates that the > client is trying to verify a freshness. (However, the client should > not *start* sending an ETag once it learned the current resource's > ETag when still attempting to pull out more blocks, but that's also not > a normative requirement but a consequence of those two requests not > being matchable any more.) [Jon] OK OLD The ETag Option MUST NOT be used in the request as the server could respond with a 2.03 (Valid Response) with no payload. If the server responds with a different ETag Option value (as the resource representation has changed), then the client SHOULD drop all the payloads for the current body that are no longer valid. NEW The ETag Option should not be used in the request for missing blocks as the server could respond with a 2.03 (Valid Response) with no payload. It can be used in the request if the client wants to check the freshness of the currently cached body response. If the server detects part way through a body transfer that the resource data has changed and the server is not maintaining a cached copy of the old data, then the body response SHOULD be restarted with a different ETag Option value. Any subsequent missing block requests MUST respond using the latest ETag Option value. If the server responds during a body update with a different ETag Option value (as the resource representation has changed), then the client should treat the partial body with the old ETag as no longer being fresh. END > > * "then the client SHOULD drop all the payloads for the current body": > "Drop" is overly prescriptive; the client may well keep them, but > just can't consider them fresh any more. (If the client has ample > caching abilities, they might come in handy if the resource goes back > to that ETag state). Same for later "the client MUST remove any > partially received". [Jon] See previous response, otherwise OLD If the server transmits a new body of data (e.g., a triggered Observe) with a new ETag to the same client as an additional response, the client MUST remove any partially received body held for a previous ETag. NEW If the server transmits a new body of data (e.g., a triggered Observe) with a new ETag to the same client as an additional response, the client should remove any partially received body held for a previous ETag for that resource as it is unlikely the missing blocks can be retrieved. > > * "For Confirmable transmission, the client SHOULD continue to": As > above in the other direction, that's not news. [Jon] Again, we are not looking for a response (well, a request in this case as needed by Block2), just an ACK OLD For Confirmable transmission, the client SHOULD continue to acknowledge each packet as well as issuing a separate GET, POST, PUT, FETCH, PATCH, or iPATCH for the missing blocks. NEW For Confirmable transmission, the server continues to acknowledge each packet, but a response is not required (whether separate or piggybacked) until successful receipt of the body or, if some of the payloads are sent as Non-confirmable and have not arrived, a retransmit missing payloads response is needed. > > * "If there is insufficient space to create a response PDU": I don't > understand what that means. (Where are request options reflected > back?). [Jon] This was triggered by a question by Michael Richardson " So, given a Christmas-Tree-Packet (largest packet, every possible option space used, every extension turned on...) how much data can I get back? :-)" and not fully thought through. It could happen though with Location-Path, Location-Query, Q-Block2, ETag, Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in response to a POST. OLD If there is insufficient space to create a response PDU with a block size of 16 bytes (SZX = 0) to reflect back all the request options as appropriate, a 4.13 (Request Entity Too Large) is returned without the Size2 Option. NEW If there is insufficient space to create a response PDU with a block size of 16 bytes (SZX = 0) to send back all the response options as appropriate, a 4.13 (Request Entity Too Large) is returned without the Size1 Option. > > * "If the client requests missing blocks, this is treated as a new > request.": I don't think the client should even make these follow-up > requests Observe, as it already has an ongoing observation. They'd be > sent on a different token too, so setting Observe would be opening > observation up on that token, which AFAIU is not intended. (Figure 7 > example looks good to me in that respect.) > > (It may make sense to ask the client to keep Observe to make the > requests matchable just for the sake of staying in atomic-request > mode. Either way, the server should then not accept that observation > as it's not for a block 0.) [Jon] The intent here was that just a new Token should be used. OLD If the client requests missing blocks, this is treated as a new request. The Observe value may change but MUST still be reported. If the ETag value changes then the previously received partial body should be destroyed and the whole body re-requested. NEW If the client requests missing blocks, this is treated as a new Request and the Observe Option MUST NOT be included. If the ETag value changes, then the previously received partial body should be considered as not fresh and the whole body re-requested. > > * "First is CBOR encoded Request-Tag": Why? Each 4.08 response can be > matched by the token to a unique request that already had a > Request-Tag, and the client needs to have kept that token around > matched to the transfer to make sense of it. > > No need to move that value around between subsystems, and just > dropping it from here would also remove the need for the "If the > client does not recognize the Request-Tag" clause (which would > otherwise need clarification as to what it'd mean if it recognizes it > but it doesn't match what the request was for). [Jon] Good question - it does make sense for the Request-Tag to be tracked alongside the Token in the client. OLD The data payload of the 4.08 (Request Entity Incomplete) Response Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR encoded Request-Tag followed by 1 or more missing CBOR encoded missing block numbers. NEW The data payload of the 4.08 (Request Entity Incomplete) response is encoded as a CBOR Sequence [RFC8742]. There are one or more missing CBOR encoded missing block numbers. OLD ; This defines an array, the elements of which are to be used ; in a CBOR Sequence: payload = [request-tag, + missing-block-number] request-tag = bstr ; A unique block number not received: missing-block-number = uint NEW ; This defines an array, the elements of which are to be used ; in a CBOR Sequence: payload = [+ missing-block-number] request-tag = bstr ; A unique block number not received: missing-block-number = uint OLD A 4.08 (Request Entity Incomplete) Response Code returned with Content-Type "application/missing-blocks+cbor-seq" indicates that some of the payloads are missing and need to be resent. The client then re-transmits the missing payloads using the Request-Tag and Q-Block1 to specify the block number, SZX, and M bit as appropriate. The Request-Tag value to use is determined from the payload of the 4.08 (Request Entity Incomplete) Response Code. If the client does not recognize the Request-Tag, the client can ignore this response. NEW (option presentation has been reformatted) 4.08 (Request Entity Incomplete) This Response Code returned with Content-Type "application/ missing-blocks+cbor-seq" indicates that some of the payloads are missing and need to be resent. The client then retransmits the missing payloads using the same Request-Tag, Size1 and Q-Block1 to specify the block number, SZX, and M bit as appropriate. The Request-Tag value to use is determined from the token in the 4.08 (Request Entity Incomplete) response and then finding the matching client request which contains the Request-Tag that is being used for this Q-Block1 body. END > > * "limit the array count to 23 (Undefined value)": 23 is the maximum > length of a zero-byte length indication, not indefinite-length (31). > Both using 23 and 31 here makes sense (up to 23 to have definite > length that can be updated in-place, or exceeding that switch to > indefinite length if they still fit), but the paragraph seems to be > mixing them up. [Jon] OK OLD Arrays (Section 3.2.2 of [RFC8949]), limit the array count to 23 (Undefined value) so that the array data byte can be updated with the overall length once the payload length is confirmed or limited to MAX_PAYLOADS count. NEW Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit the array count to 23 so that the initial byte with the array major type and data length in the additional information can be updated with the overall count once the payload count is confirmed. Further restricting the count to MAX_PAYLOADS means that congestion control is less likely to be invoked on the server. > > * "Each new request MUST use a unique token": Like above, this is > stating something that's not intended to be changed. [Jon] RFC7252 does not require Tokens to be unique - e.g. empty token values are acceptable. Hence this statement. > > Congestion Control: > > * "Each NON 4.08 (Request Entity Incomplete) Response Codes is subjected > to PROBING_RATE.": That is unexpected here. At most one such > response is sent to each request message, so why is additional > congestion control needed? [Jon] The intention here was that in the previous paragraph that it was not the individual packets that are subject to PROBING_RATE, but a single body comprising of multiple packets is subject to PROBRING_RATE - and hence limiting any individual responses to PROBING_RATE rather than the potentially full set of responses OLD PROBING_RATE parameter in CoAP indicates the average data rate that must not be exceeded by a CoAP endpoint in sending to a peer endpoint that does not respond. The body of blocks will be subjected to PROBING_RATE (Section 4.7 of [RFC7252]). NEW PROBING_RATE parameter in CoAP indicates the average data rate that must not be exceeded by a CoAP endpoint in sending to a peer endpoint that does not respond. The single body of blocks will be subjected to PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets. If the wait time between sending bodies that are not being responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the gap time is limited to NON_PROBING_WAIT. Note: For the particular DOTS application, PROBING_RATE and other transmission parameters are negotiated between peers. Even when not negotiated, the DOTS application uses customized defaults as discussed in Section 4.5.2 of [RFC8782]. END > > On the other hand, *ever* NON request is subject to PROBING_RATE, so > why point out the body of blocks and "GET or similar" particularly? [Jon] It is only GET or FETCH. The intention here is to not request bodies of data at too high a rate. OLD Each NON GET or similar request using Q-Block2 Option is subjected to PROBING_RATE. NEW Each NON GET or FETCH request using Q-Block2 Option is subjected to PROBING_RATE. > > * "a delay is introduced of ACK_TIMEOUT": As I understand MAX_PAYLOADS, > this is (rather implicitly) introduced as the package count up to > which it is OK to exceed PROBING_RATE temporarily (but after that it > kicks in all the harder by requiring to wait until complete-sent-bytes > over PROBING_RATE has expired). If that holds, at that time a much > larger delay than just ACK_TIMEOUT is needed to get a response from > the server: About 3 hours (see later note on parameters). [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re-write of Congestion Control section. > > This is the crucial point in the document, and for it a recommendation > alone is not good enough. The protocol can be run with a vastly > increased PROBING_RATE (however externally determined) and from the > point of MAX_PAYLOADS just observe it. Or it has to get feedback from > the server; a single 4.08 is probably enough to kick off another > vollley of blocks. (How many? MAX_PAYLOADS for every response?). > Both can be permitted, but just waiting ACK_TIMEOUT isn't doing any > good. [Jon] See re-write of Congestion Control section where things should now be simpler and more logical. There is an introduction of new variable definitions. > > * "For NON transmissions": This seems to imply that the full exchange of > a body is either NON or CON; I don't see where that'd come from. I'd > have expected to read something like "Each individual request can be > NON or CON independent of the others. In particular, it can be > convenient to send the ultimate payload...". [Jon]The DOTS environment will only be using NON. To make Congestion Control simple, the expectation is that all transmissions are NON or (not recommended) are all CON. The draft now generally records this expectation. > > * "If a Confirmable packet is used, then the transmitting peer MUST wait > for the ACK": Why? A NSTART > 1 would give it leisure to still > transmit. [Jon] Text has been removed in the clean-up. > > * General on congestion control: It may help implementors if this were > split up into newly introduced rules and concepts (that is, > MAX_PAYLOADS and the answer to whether you may send MAX_PAYLOADS > en > block again after having only even one response from the last round, > and probably the recommended parameters of the "Also on parameters" > comment), and another subsection on how Q-Block behaves well when > observing these. [Jon] Should now be covered in the updated Congestion Control section. > > Caching: > > * "are not part of the cache key": How about "are removed as part of the > block assembly and thus do not reach the cache"? [Jon] OK. OLD As the entire body is being cached in the proxy, the Q-Block1 and Q-Block2 Options are not part of the cache key. NEW As the entire body is being cached in the proxy, the Q-Block1 and Q-Block2 Options are removed as part of the block assembly and thus do not reach the cache. > > * "When the next client completes building the body": If the proxy > chooses not to let them happen in parallel (which it may, see above on > parallel requests, although the server might still not support it and > cancel one of them), why bother letting the first finish just to abort > it? (IOW: If the proxy does not intend to see both through, which it > could if it held back the second until the first is through on the > uplink, it could just as well err out of one of them early, but it may > also rather see both through.) [Jon] It has to be assumed that traffic to/from the origin client and origin server may not both support Q-Blockx and potentially may have a different SZX. Thus passing a request or a response through at the block level introduces a new set of challenges (but not impossible to fix). To keep this simple, my thinking was that the passing through can only take place at the body level. Again, the arrival of packets is not necessarily sequential, so client A's body may start transmitting to the origin server first, but client B's body starts to arrive first - the same being true for the proxy as a client may stop transmitting for whatever reason (restart, network loss etc.). However this is covered by the above update " If a server receives payloads with different Request-Tags for the same resource, it should continue to process all the bodies". OLD and the new body representation transmission starts with a new Request-Tag value. NEW and the new body representation transmission starts with a new Request-Tag value. Note that it cannot be assumed that the proxy will always receive a complete body from a client. > > * Examples: > > * Figure 5: The ... between e3 request and response indicate the > MAX_TRANSMIT_SPAN before sending the 4.08 response. I suppose there > should be the same kind of delay between the failed e5 transmission > and the e4 response. [Jon] Agreed and added in > > * If the second burst had 3 requests out of which 2 made it, is there > any guidance for which of them the 4.08 would come back on? (In the > end, none of them is terminal). [Jon] The client should tracking all Tokens of the burst (hence implementation note about bottom 32bits unique and top 32 bits matching block number for ease of tracking) for a response and so it will make no difference at to which token is used for the 4.08 response. From an implementation perspective, it probably is easier to track the last opaque token that has the same Request-Tag. OLD missing ones in one go (Figure 5). It does so by indicating which blocks have been received in the data portion of the response. NEW missing ones in one go (Figure 5). It does so by indicating which blocks have been received in the data portion of the response. The Token just needs to be one of those that have been received for this Request-Tag , so the client can derive the Request-Tag. > > * If that e4 response gets lost, does the whole mechanism recover from > it in any way? [Jon] In this example, if e4 and e5 get lost, there will be no 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as to whether it sends the request again or gives up. See 9.1 "Under high levels of traffic loss, the client can elect not to retry sending missing blocks of data. This decision is implementation specific." > > Generally, the all-NON and all-CON examples don't look to me like > what I'd be doing with this spec; the mixed "a CON every > MAX_PAYLOADS" appears much more realistic. [Jon] It is unsafe to use CON in the (potentially lossy) DOTS environment (up to 93 secs timeout per payload with the defaults). Hence why we are separating out the NON / CON usage. > > * Figure X: The request ahs M unset and thus indicats a request for > just that block. If more than one is expected, it should say > QB2:0/1/1024. [Jon] With Figure 7, with the M bit set, block 3 would get returned for a second time. Draft-ietf-core-new-block-03 also has a Figure 8 which does exactly what you describe. > > * New Content Format: I think this needs a media type registration to go > with it first; based on that, a content format can be registered. [Jon] Med has responded to this and draft updated. > > * General on MAX_TRANSMIT_SPAN and other timing parameters: I'm not > sure > they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is defined > in terms of reliable transmission, but used for NONs as well. (So is > the alternative ot 2x ACK_TIMEOUT). [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and ACK_TIMEOUT in a NON environment. Hence re-write of Congestion Control section defining new variables that can be used for NON. > > For the purpose of delaying a 4.08 or a follow-up GET, it may make > more sense to define a new parameter based on MAX_LATENCY and the > time > it takes the sender to pump out the options (which I don't think we > have a good factor for, but may even be negligible here). > > Could read like this: > > > The timing parameter MAX_BLOCK_JITTER is introduced, and by default > > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / BANDWIDTH. [Jon] Lets plug in some numbers here. MAX_LATENCY = 100, MAX_PAYLOADS = 10, MTU = 1280bytes and BANDWIDTH = 1Mbps. [Jon] MAX_BLOCK_JITTER = 100 + (10 * 1280 * 8)/(1 000 000) = 100.1. So BANDWITH of 1Mbps has negligible effect on the calculation. 1Kbps makes MAX_BLOCK_JITTER 200 seconds. > > > > With Q-Block2, a client can ask for any missing blocks after not > > having received any further response for the duration of > > MAX_BLOCK_JITTER. [Jon] 100+ seconds delay is way too much time to wait for any missing blocks in my opinion. [Jon] RFC7252 also states (and the intention is that recovery works well) " as MAX_LATENCY is not intended to describe a situation when the protocol works well, but the worst-case situation against which the protocol has to guard." > > > > With Q-Block1, a server holds off any response for MAX_BLOCK_JITTER > > unless all blocks have been received. Only then it evaluates whether > > to respond with a 2.0x code, a 4.08 with payload, or not at all > > (because it responded to a later request). [Jon] I am not convinced that this is necessarily the way to go. The new Congestion Control more cleanly handles this. > > This also brings me back to the earlier matter of 2.31: What is a > server supposed to send when no packages were lost, but it's pasing > the timeout and wants to help the client flush out more packages by > confirming something? It says 4.08 in 3.3, but it's not like there's a > hole in the contiguous range. Does it need to send 4.08 enumerating > all (or at least some) numbers between the first unreceived and what's > indicated by Size1? Or can it just send 2.31 and the client knows all > it needs to know b/c the response came to the largest block that was > sent and 2.31 indicates that everything is good up to that point? [Jon] The previous draft states (under Congestion Control) that the client waits for ACK_TIMEOUT before transmitting the next set of MAX_PAYLOADS blocks. The server should wait for "two times ACK_TIMEOUT " (3.3) before indicating issue. Apart from perhaps having a new name for ACK_TIMOUT I think that these are reasonable values for Non-Confirmable - and are used in the new Congestion Control section. [Jon] I have reworked Congestion Control to use 2.31 (NON only) as a signal to say that all of the current MAX_PAYLOADS payloads of a body have been received, so allowing the client to continue transmitting the next set of MAX_PAYLOADS payloads without the need to wait any longer. > > * Also on parameters: This document is describing flow control stuff > around a situation CoAP was not originally designed for. Wouldn't it > make sense to include a set of parameters (PROBING_RATE, MAX_LATENCY, > ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that > PROBING_RATE will be left to 1 byte/second for any DOTS application > using this (for sending 10KiB in the initial 10-package MAX_PAYLOADS > burst would mark that connection as unusable for about 3 hours if they > all get lost), so better give justifiable numbers here than rely on > implemnetors to come up with unreviewed numbers or disregard > PROBING_RATE altogether. [Jon] Answered by Med, and some new text added. > > I don't know if it needs additional justification, but an increased > N_START may be justifiable there. [Jon] It may be, but tuning the other associated parameters is really out of the cope of this draft. This text has been added NEW Congestion control for CON requests and responses is specified in Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will need to be increased from 1. However, the other CON congestion control parameters will need to be tuned to cover this change. This tuning is out of scope of this document as it is expected that all requests and responses using Q-Block1 and Q-Block2 will be Non- confirmable. > > * Somewhere (never comes up but I think it should): When CONs are used, > a 4.08 (or 2.31?) response to a later request can indicate to the > client that an earlier CON request has been processed successfully. If > the client can match that up (and it should be able to), then it can > (and should) cancel that particular CON request. [Jon] I think that this is covered by my update above with the text " NEW For Confirmable transmission, the server continues to acknowledge each packet, but a response is not required (whether separate or piggybacked) until successful receipt of the body or, if some of the payloads are sent as Non-confirmable and have not arrived, a retransmit missing payloads response is needed." And in my previous part 1 response (updated) NEW For Confirmable transmission, the server continues to acknowledge each packet, but a response is not required (whether separate or piggybacked) until successful receipt of the body or, if some of the payloads are sent as Non-confirmable and have not arrived, a retransmit missing payloads response is needed. > > Best regards > Christian > > -- > There's always a bigger fish. > -- Qui-Gon Jinn From nobody Wed Jan 6 07:40:02 2021 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 27A453A0EF4; Wed, 6 Jan 2021 07:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 Hkqw9PJTQ_-3; Wed, 6 Jan 2021 07:39:58 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB5BB3A0EF1; Wed, 6 Jan 2021 07:39:58 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 4D9tpj35CPz108b; Wed, 6 Jan 2021 16:39:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1609947597; bh=qDHmM5ZBqpbDJZLBovXBj8VW8BoLtNixcZ/ZS09EAaU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=QG+RkbVp9AYDKgg4uF4nv4Zdgf29lfhIRSflEPrVbFQDGZ3HLMpnl6mo5wLP0ngJC nPqbC8PTGjdVMWBClcf0OD9KIEU+ivO0GaGJ/TyAj4hBEW3Pl3QOlLrziSR5YyDNhY YH9kXP81COJgPaQcWWx2eUWFeUEbANsc+xfAmDJDlZt2Ce/93uIvzRlyHvYnqUGmQd pD3xwbu50yjGqUxoVg5+nEZh6vsQaJSkhxpQtCh1dNxmVMM50kR5Iyyxgq2E/Dq9kI +xXHKq216Dmz9P/nuXGu2CXhMBrqnOECd+RkvdYl+NFVfEoYNPtPpItAZGULdc4eUp uIK3R7sjq3iGg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 4D9tpj2Lk2zFpWX; Wed, 6 Jan 2021 16:39:57 +0100 (CET) From: To: "supjps-ietf@jpshallow.com" , "christian@amsuess.com" , "draft-ietf-core-new-block@ietf.org" CC: "dots@ietf.org" , "core@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block Thread-Index: AdbkP95w26IDeT0/RXqAAvtrJTaBNgAAX/ig Date: Wed, 6 Jan 2021 15:39:56 +0000 Message-ID: <16435_1609947597_5FF5D9CD_16435_116_1_787AE7BB302AE849A7480A190F8B9330315A8410@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> In-Reply-To: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 06 Jan 2021 15:40:00 -0000 Hi all,=20 One clarification below.=20 Cheers, Med > -----Message d'origine----- > De=A0: core [mailto:core-bounces@ietf.org] De la part de supjps- > ietf@jpshallow.com > Envoy=E9=A0: mercredi 6 janvier 2021 16:24 > =C0=A0: christian@amsuess.com; draft-ietf-core-new-block@ietf.org > Cc=A0: dots@ietf.org; core@ietf.org > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hi Christian, >=20 > Once again, thank you for the comprehensive review. >=20 > Responses part 2. A new version (-04) of the draft has been > published and can be found at > https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ >=20 >=20 > Part 1 responses were covered in the main by version -03, so you may > want to look at the -02 to -04 differences. [Med] Actually, -03 addresses the WGLC comments from Marco while -04 addres= ses those from Christian. A diff against -03 is thus sufficient to track th= e changes based on Christian's review. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Jan 6 13:41:46 2021 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 1162D3A12B7; Wed, 6 Jan 2021 13:41:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: Cc: core@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160996930502.21827.5533521556349871834@ietfa.amsl.com> Reply-To: Russ Housley Date: Wed, 06 Jan 2021 13:41:45 -0800 Archived-At: Subject: [core] Iotdir telechat review of draft-ietf-core-dev-urn-09 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: Wed, 06 Jan 2021 21:41:45 -0000 Reviewer: Russ Housley Review result: Almost Ready I reviewed this document as part of the IoT Directorate's effort to IoT-related IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Internet Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-core-dev-urn-09 Reviewer: Russ Housley Review Date: 2021-01-06 IETF LC End Date: 2020-12-02 IESG Telechat date: 2021-01-21 A review from the IoT Directorate was requested on 2021-01-05, which is after the IETF Last Call ended. I assume that the Internet ADs want this review to help inform them during IESG Evaluation. Summary: Almost Ready Major Concerns: Section 3.2 says: The optional underscore-separated components following the hexstring are strings depicting individual aspects of a device. Not all of the DEV URN forms contain a hexstring; however, all of them are allowed to end with underscore-separated components. I suggest: The optional underscore-separated components at the end of the DEV URN depict individual aspects of a device. Section 3.2.1 says: ... and a MAC address could be represented either with uppercase or lowercase hexadecimal digits. This is not allowed by the ABNF: hexstring = 1*(hexdigit hexdigit) hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" If both cases are to be supported, the upper case letters need to be added to the ABNF to permit them. Section 4.2 says: ... 64-bit identifier that consists of 8 byte family code, 48 bit identifier unique within a family, and 8 bit CRC code [OW]. The math does not work. I suspect: s/8 byte/8 bit/ Section 6 says: ... An implementation of the DEV URN MUST NOT change these properties from what they were intended. It is not clear to me the meaning of "they" in this sentence. Please clarify. Minor Concerns: Section 3.2 says: DEV URNs do not use r-, q-, or f-components. I would have liked a bit more context here. I suggest: DEV URNs do not use r-, q-, or f-components as defined in [RFC8141]. Section 3.2.1 refers to "BASE64". Please add an informative reference to RFC 4648 to be clear. Section 4.1 uses the term "Ethernet" in two places. I think both of them should be replaced by "MAC-48". Nits: Section 3.2 says: However, due to the SenML RFC 8428 Section 4.5.1 rules, DEV URNs do not support percent-encoding. This does not seem like a "however" statement to me. Perhaps, it is a "Note that" statement. Or, just drop "However". Section 4.1: s/rests within the IEEE/ /rests with the IEEE Registration Authority/ Section 7 includes: "publicly available specification that can be pointed to." It is sufficient to say: ""publicly available specification." From nobody Wed Jan 6 13:50:21 2021 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 CFE0C3A12C6; Wed, 6 Jan 2021 13:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxSa9QwtgO5e; Wed, 6 Jan 2021 13:50:09 -0800 (PST) Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (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 F24193A12BE; Wed, 6 Jan 2021 13:50:08 -0800 (PST) Received: by mail-lf1-f45.google.com with SMTP id h205so9982032lfd.5; Wed, 06 Jan 2021 13:50:08 -0800 (PST) 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=1LkN9/uOmOVc8Sm7yF98SUlSxm449ymNnNTKRRuyDdY=; b=c25CjWvJXZTYiqGuroHDBf6ze8ILzL590OfD8yM9HiU8MnYwQWlYjl3ZjwwDdDwaQJ dUWSFEcyIm+I95j7KJmjz+OegbssAexSbHJY0rTuaY6BEwdSQa9Av0BNh2QRjG+hbejs rIWF8Rlz6ehBsLgoiEsaev6uDlywdrV8+NZQ+jTTCSKrNwlv2d/IEcMBRK1oAxQstHnk E4Ln7sZ6XAN8jHpFIKEI1DKwUpOVnYTi+7O9f428fqeWYP+KHXFORh1KIMtbLfyuPx6D 5SfWG8ihj3coSeXpuNlyQby0FSzjhuw8G7SlXX8RxX6phiswMgDvIYF6nHZ/NyR9c+Tb G+jA== X-Gm-Message-State: AOAM533n+48IWHQtDxkMcmomfzWqqI1Kcg+Kfb6HVWHHIyJibo7/vxU3 BAKzlAjx+WBMu56c0UNiUbvKmuO9f6ssU4EpDZ8= X-Google-Smtp-Source: ABdhPJxSI6MjnxsvTvHAMVB7ZZ6rqX6dReluHPkv576CNg8ek+QC8cMFLzRnl4Jf8EH4OOggcnbEWrOipP3ef/Ow1yI= X-Received: by 2002:a2e:920b:: with SMTP id k11mr2625908ljg.313.1609969806846; Wed, 06 Jan 2021 13:50:06 -0800 (PST) MIME-Version: 1.0 References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> In-Reply-To: <160996930502.21827.5533521556349871834@ietfa.amsl.com> From: Barry Leiba Date: Wed, 6 Jan 2021 16:49:55 -0500 Message-ID: To: Russ Housley Cc: core@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, iot-directorate@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary="0000000000006faff805b8424ef7" Archived-At: Subject: Re: [core] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 06 Jan 2021 21:50:11 -0000 --0000000000006faff805b8424ef7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the quick review, Russ, and good catches here. On one item, though: > If both cases are to be supported, the upper case letters need to be > added to the ABNF to permit them. Actually not: quoted letters in ABNF are case-insensitive, so =E2=80=9Ca=E2= =80=9D matches both lowercase a and uppercase A. Barry On Wed, Jan 6, 2021 at 4:41 PM Russ Housley via Datatracker < noreply@ietf.org> wrote: > Reviewer: Russ Housley > Review result: Almost Ready > > I reviewed this document as part of the IoT Directorate's effort to > IoT-related IETF documents being processed by the IESG. These comments > were written primarily for the benefit of the Internet Area Directors. > Document authors, document editors, and WG chairs should treat these > comments just like any other IETF Last Call comments. > > Document: draft-ietf-core-dev-urn-09 > Reviewer: Russ Housley > Review Date: 2021-01-06 > IETF LC End Date: 2020-12-02 > IESG Telechat date: 2021-01-21 > > > A review from the IoT Directorate was requested on 2021-01-05, which is > after the IETF Last Call ended. I assume that the Internet ADs want > this review to help inform them during IESG Evaluation. > > > Summary: Almost Ready > > > Major Concerns: > > Section 3.2 says: > > The optional underscore-separated components following the hexstring > are strings depicting individual aspects of a device. > > Not all of the DEV URN forms contain a hexstring; however, all of them > are allowed to end with underscore-separated components. I suggest: > > The optional underscore-separated components at the end of the > DEV URN depict individual aspects of a device. > > Section 3.2.1 says: > > ... and a MAC address could be represented either with > uppercase or lowercase hexadecimal digits. > > This is not allowed by the ABNF: > > hexstring =3D 1*(hexdigit hexdigit) > hexdigit =3D DIGIT / "a" / "b" / "c" / "d" / "e" / "f" > > If both cases are to be supported, the upper case letters need to be > added to the ABNF to permit them. > > Section 4.2 says: > > ... > 64-bit identifier that consists of 8 byte family code, 48 bit > identifier unique within a family, and 8 bit CRC code [OW]. > > The math does not work. I suspect: s/8 byte/8 bit/ > > Section 6 says: > > ... An implementation of the DEV URN MUST NOT > change these properties from what they were intended. > > It is not clear to me the meaning of "they" in this sentence. > Please clarify. > > > Minor Concerns: > > Section 3.2 says: > > DEV URNs do not use r-, q-, or f-components. > > I would have liked a bit more context here. I suggest: > > DEV URNs do not use r-, q-, or f-components as defined in [RFC8141]. > > Section 3.2.1 refers to "BASE64". Please add an informative reference > to RFC 4648 to be clear. > > Section 4.1 uses the term "Ethernet" in two places. I think both of > them should be replaced by "MAC-48". > > > Nits: > > Section 3.2 says: > > However, due to the SenML RFC 8428 Section 4.5.1 rules, DEV URNs > do not support percent-encoding. > > This does not seem like a "however" statement to me. Perhaps, it is > a "Note that" statement. Or, just drop "However". > > Section 4.1: s/rests within the IEEE/ > /rests with the IEEE Registration Authority/ > > Section 7 includes: "publicly available specification that can > be pointed to." It is sufficient to say: ""publicly available > specification." > > > > --0000000000006faff805b8424ef7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the quick review, Russ, and good catches here.=

On one item, though:

> If both cases are to be supported, the upper= case letters need to be
> added to the ABNF to permit them.


Actually not: quote= d letters in ABNF are case-insensitive, so =E2=80=9Ca=E2=80=9D matches both= lowercase a and uppercase A.

Barry

On Wed, Jan 6, 2021 at 4:41 PM Russ Housley via Datatracker= <noreply@ietf.org> wrote:
Reviewer: Russ Housley
Review result: Almost Ready

I reviewed this document as part of the IoT Directorate's effort to
IoT-related IETF documents being processed by the IESG.=C2=A0 These comment= s
were written primarily for the benefit of the Internet Area Directors.
Document authors, document editors, and WG chairs should treat these
comments just like any other IETF Last Call comments.

Document: draft-ietf-core-dev-urn-09
Reviewer: Russ Housley
Review Date: 2021-01-06
IETF LC End Date: 2020-12-02
IESG Telechat date: 2021-01-21


A review from the IoT Directorate was requested on 2021-01-05, which is
after the IETF Last Call ended.=C2=A0 I assume that the Internet ADs want this review to help inform them during IESG Evaluation.


Summary: Almost Ready


Major Concerns:

Section 3.2 says:

=C2=A0 =C2=A0The optional underscore-separated components following the hex= string
=C2=A0 =C2=A0are strings depicting individual aspects of a device.

Not all of the DEV URN forms contain a hexstring; however, all of them
are allowed to end with underscore-separated components.=C2=A0 I suggest:
=C2=A0 =C2=A0The optional underscore-separated components at the end of the=
=C2=A0 =C2=A0DEV URN depict individual aspects of a device.

Section 3.2.1 says:

=C2=A0 =C2=A0... and a MAC address could be represented either with
=C2=A0 =C2=A0uppercase or lowercase hexadecimal digits.

This is not allowed by the ABNF:

=C2=A0 =C2=A0hexstring =3D 1*(hexdigit hexdigit)
=C2=A0 =C2=A0hexdigit =3D DIGIT / "a" / "b" / "c&q= uot; / "d" / "e" / "f"

If both cases are to be supported, the upper case letters need to be
added to the ABNF to permit them.

Section 4.2 says:

=C2=A0 =C2=A0...
=C2=A0 =C2=A064-bit identifier that consists of 8 byte family code, 48 bit<= br> =C2=A0 =C2=A0identifier unique within a family, and 8 bit CRC code [OW].
The math does not work.=C2=A0 I suspect: s/8 byte/8 bit/

Section 6 says:

=C2=A0 =C2=A0... An implementation of the DEV URN MUST NOT
=C2=A0 =C2=A0change these properties from what they were intended.

It is not clear to me the meaning of "they" in this sentence.
Please clarify.


Minor Concerns:

Section 3.2 says:

=C2=A0 =C2=A0DEV URNs do not use r-, q-, or f-components.

I would have liked a bit more context here.=C2=A0 I suggest:

=C2=A0 =C2=A0DEV URNs do not use r-, q-, or f-components as defined in [RFC= 8141].

Section 3.2.1 refers to "BASE64".=C2=A0 Please add an informative= reference
to RFC 4648 to be clear.

Section 4.1 uses the term "Ethernet" in two places.=C2=A0 I think= both of
them should be replaced by "MAC-48".


Nits:

Section 3.2 says:

=C2=A0 =C2=A0However, due to the SenML RFC 8428 Section 4.5.1 rules, DEV UR= Ns
=C2=A0 =C2=A0do not support percent-encoding.

This does not seem like a "however" statement to me.=C2=A0 Perhap= s, it is
a "Note that" statement.=C2=A0 Or, just drop "However".=

Section 4.1: s/rests within the IEEE/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /rests with the IEEE Regis= tration Authority/

Section 7 includes: "publicly available specification that can
be pointed to."=C2=A0 It is sufficient to say: ""publicly av= ailable
specification."



--0000000000006faff805b8424ef7-- From nobody Wed Jan 6 17:00:52 2021 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 68D6B3A141A; Wed, 6 Jan 2021 17:00:50 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 HW-K82qiR6iV; Wed, 6 Jan 2021 17:00:48 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACAFB3A1418; Wed, 6 Jan 2021 17:00:48 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kxJfT-000B9i-32; Wed, 06 Jan 2021 20:00:47 -0500 Date: Wed, 06 Jan 2021 20:00:41 -0500 From: John C Klensin To: Russ Housley , iot-directorate@ietf.org cc: last-call@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org Message-ID: In-Reply-To: <160996930502.21827.5533521556349871834@ietfa.amsl.com> References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 07 Jan 2021 01:00:50 -0000 Russ, Barry, Another small catch... --On Wednesday, January 6, 2021 13:41 -0800 Russ Housley via Datatracker wrote: > Nits: > > Section 3.2 says: > > However, due to the SenML RFC 8428 Section 4.5.1 rules, DEV > URNs do not support percent-encoding. > > This does not seem like a "however" statement to me. Perhaps, > it is a "Note that" statement. Or, just drop "However". Sorry I, or someone in the URN registration review process, didn't catch this, but I think it is a little more complicated than a nit. When what became RFC 8141 was being developed, several people made very clear to the WG that there was no possible way for a URN specification to make an exception to the syntax rules for URIs, including the rules about percent-encoding in Sections 2.1 and 2.4 of RFC 3986. I can't speak to what the URNBIS WG would have done had it been allowed to consider the options that might have been opened by developing different requirements for locators and names and, in particular, whether any such changes would have affected percent-encoding. However, it was painfully clear that no URN, much less any particular URN namespace definition, can alter those rules. At this point, the most obvious option would be to change the statement in draft-ietf-core-dev-urn to note that the RFC 3986 rules apply and explain (inline or by reference) how percent-encoding works. Such a statement might explain that, given the characters permitted in RFC 8428 Section 4.5.1, percent-encoding should never be necessary within a DEV URN. However, because the list in 8428 includes characters that are defined as "Reserved Characters" in Section 2.2 of RFC 3986, notably including ":" and "/", the possibility of their being percent-encoded by some process allowed by 3986 cannot be eliminated. Other alternatives involve updating RFC 8141 and 3986, but I wouldn't recommend going there, especially if the CORE WG would like to see the current spec published in 2021. The narrowest of those updates would be to change the rather relaxed-sounding language of RFC 3986 Section 2.1: "used to represent a data octet in a component when that octet's corresponding character is outside the allowed set or is being used as a delimiter of, or within, the component." To say that percent-encoding MUST NOT be used unless actually required, but I'd guess that would not go over well with existing implementations. Or, I suppose, the IESG could decide either that 3986 does not count or that an interpretation that disallowed URN namespaces prohibiting things that it allows is incorrect. But someone would probably take that as a commitment to allow a revision to 8141 that would codify the options that would imply. john p.s. This not being spotted earlier may be a contribution to the discussion that is now occurring on the IETF list of early cross-area review and how important it is to facilitate, rather than discourage, such reviews. Or not. From nobody Thu Jan 7 03:17:18 2021 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 045963A0F74; Thu, 7 Jan 2021 03:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.262, 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=itaoyama.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 yfGI8xHnoxPu; Thu, 7 Jan 2021 03:17:15 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410102.outbound.protection.outlook.com [40.107.141.102]) (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 A753C3A0F5E; Thu, 7 Jan 2021 03:17:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A7Fr+9mN61C1sakLGC5s0/Sqg7pXOcGIzc4QRHxlmSxVZMcdOgC1BBrr2MG+uP5/Re4P9WQo81LMBel6czwYChJ1x4bGr1c/jz32Oq5r2FwSmGPJ4HsJBwgILyKqn5VdFZujqcI0mAmJ85U6LCb8OkazjsBX/VI2yXcELpjYLRK/hY70z9Tp6clhimnVMcSKdXHJ/bZh+6GXY2pvhoWWb6W8NqfUdbfHV6Ks6M0x6IKFahN95SCDwbkd59Qz2ZVI02u5Cr16VqQr6fLXs1OPL7dUWfjYfl3kIRswSjL/V0FBCS2mKkMFyID6uiVSUbSropMDjUnXGqJXRVlYG1+gQw== 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=uN+6bSofjM75SRjiZh65DzLZOhKqjSSnsUUfg11trck=; b=abkSkW0SAnUlzAeBFjKF4B1+E2zu1lZSGtKFCFCkUT3rsQ8M2ZTrSLcJHH7G2g/MbT0M52yz/78btDHy2PzCzrb6JESU7IUzFHPm8he+oXYqYxcWZPuThhlFIhv0UzT/Bh1sRc6xuOjSxhiUrE01XMQW5peMj6svGtb10lspxB1y8fNH3oHleHcrMiQpzSFA1+niAFh58yYmWrLYIPjaRf5DXgGu7OnC9mgEkXZd2pt9gBfSaxZX2M4x/m+hR/PRfrbTb0iHoovp0Ix4P2SHsRhe3y9XLeJAGjWXY8rcSlEU+EZAW8igIk5v9P8MDr9qwCruT01qK6RAahiV2RU9wA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uN+6bSofjM75SRjiZh65DzLZOhKqjSSnsUUfg11trck=; b=gbwPzYXznh3uvA+ihHte759NSKWQtI88N/RsB8pfiHkcPJeZEPjMfoiBzP4pxRG3TIwpzn0+Eal3+ZCp/+vP1sKLppAMtzGjCvjHW8FfSE8CgHdQ0CfUvV5PMMQeoX4iKhxt0cjeBlwv9O6rdI+EO1cYkkKOVDXeYhof7qCUD00= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from OS3PR01MB5686.jpnprd01.prod.outlook.com (2603:1096:604:c3::10) by OSAPR01MB5154.jpnprd01.prod.outlook.com (2603:1096:604:65::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Thu, 7 Jan 2021 11:17:12 +0000 Received: from OS3PR01MB5686.jpnprd01.prod.outlook.com ([fe80::40fe:810c:329b:454]) by OS3PR01MB5686.jpnprd01.prod.outlook.com ([fe80::40fe:810c:329b:454%6]) with mapi id 15.20.3742.006; Thu, 7 Jan 2021 11:17:12 +0000 To: John C Klensin , Russ Housley , iot-directorate@ietf.org Cc: last-call@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <7bb73d56-134d-e8ab-7e65-f013e85d7eae@it.aoyama.ac.jp> Date: Thu, 7 Jan 2021 20:17:08 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [121.118.76.82] X-ClientProxiedBy: TYBP286CA0045.JPNP286.PROD.OUTLOOK.COM (2603:1096:404:10a::33) To OS3PR01MB5686.jpnprd01.prod.outlook.com (2603:1096:604:c3::10) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.2] (121.118.76.82) by TYBP286CA0045.JPNP286.PROD.OUTLOOK.COM (2603:1096:404:10a::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6 via Frontend Transport; Thu, 7 Jan 2021 11:17:11 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 58eb5008-a87d-413e-1482-08d8b2fdc7ba X-MS-TrafficTypeDiagnostic: OSAPR01MB5154: 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: LpMAyU11dBh+rSQfr5odTSpJpXuI5/GCKisGzQl8QqTKgVuCLVwMTc4RBnh8FVG4eGJzn0QJY+pJLNJK7f5ot6zqLB6jmO7oHhO0sl1z/9leC3DOQ8dXxGlUObff04tpbN1Mdbi/zpil2XZMdmIwe9XQwNzANP5on4PBubryU9N9flSqlS1VwKYONh5l5R8g9UkS7ztxz2n944ElP/2SvfOBz3YISoejhsO/gsFyAA+E7OIc+zp2qGFx4r2M8DXfPYBbz60JmkNl+rC2ynh/r0q38+Fb3PeOIcILJ5bo7kvqI6QLjYcu2/o5F0VvlO+MEMlQo5vrjAlze0q/szx5WJ1dkOSglgDlTqOVEn2wNbvmv1THS37YpOt2KuENYMr84sVo3pBmDxVFWEPa+97L0vFE6pYpHxN2Oia/aosurc8UdAlmYDDUGgapUQRMiHpwEY95BqyNrWo7HEfgjJQAMIRLe6kmkWYuPjw1kE6UoF4= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:OS3PR01MB5686.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(136003)(39850400004)(346002)(396003)(366004)(26005)(5660300002)(16526019)(36916002)(2616005)(6486002)(8676002)(478600001)(186003)(8936002)(6666004)(83380400001)(2906002)(52116002)(66574015)(956004)(31686004)(786003)(316002)(110136005)(16576012)(4326008)(31696002)(53546011)(66946007)(66476007)(86362001)(66556008)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?UUN4djVTc3l6QVA2VXd2YVhsTlFDUUhCcWZzN0dYWUhUN1d6OUlXeGV0NG1O?= =?utf-8?B?QnRWVm5QSktTdThoYmpmcWQ0RTQ2anlkQ0FjQ2JZRitJdjV3cUk5SXJ3S2k1?= =?utf-8?B?SnRMZ29SOW41L0tNWFhUNHhWTUhvSzFoRTJQbzhoZ0luOWJGalhjejJNdlhm?= =?utf-8?B?eEozNlQraHJDbm1TalhUakN1ZStuVG9MUUZJTzZ0a040WGxDNFlUWURQbHUw?= =?utf-8?B?ejVFQjA4T2hnMXBoVjlZM1dKemdvZytBeElMdEp5QXdEclhta2dKRy9USWZ4?= =?utf-8?B?ZnQ1UWJsSE42M3RuYkwzMjVlTmNBdk9ZRFFnanpNQ0ZpNEpHRUxXRmVOakph?= =?utf-8?B?Y0FlVFRCSVVFc3Z6MXFyY20yUWE1VjVkSzFaTVYrQ3BpS1NXQ2JBRXFWOEky?= =?utf-8?B?L1lNcElSdkRka3pKWmtJWExnQzRrcXpBVVNpRXQrSFVDN0lFZzdNeUlMdXBG?= =?utf-8?B?M2xDYWdVelJBaS94K3FXT3h0RXRUS3lQODlsWGxJRUJlMEErK1RUVkhjU0lH?= =?utf-8?B?QWFRZDRaQlEzNG1DM25rODZyV2JjMVlOU1IrdmdoOW04NmpIZHNJekd0QVhZ?= =?utf-8?B?d1pjN3NjczRXbHdlS3RFSUk2NEF0aHIxaEJrQUJXOVdFZ0FUVUJ2UktPZUEz?= =?utf-8?B?dTZ5SGlRL2VXeGt4eDU1RStsdzYzV0FGa2Jwa0RCa3UwNnhMZ0w2T25WVkMy?= =?utf-8?B?YUdmMWVpTlBDWTJYUitxMEtLNld2ZzM4amxJdFNtSzU2eFRmWERUYWFCd1lh?= =?utf-8?B?TllqdVNVWGY2R1o5bUozbUtMenZqSnMyYnZWb3ZJUmV2THBHSGxzbVdqMnlt?= =?utf-8?B?OG8vRldzT21iNHpqNHl2MHNkd09hcEd5YkpOUDNkMnJYUzdBQlRtbzZwUnhU?= =?utf-8?B?LzVmTkRBZFdqT3FrTXJCZHU5QndnajloY3Z2bWdkZVpxZWYrUEtRMnF3OFlJ?= =?utf-8?B?cXFuRkdWOGN4aHRxZmZQU0l2czA0ZlJVSEp3SDBNWXZ0TDJPVmRiR0gyYnhV?= =?utf-8?B?QjBpSW9peHYwNmtZSWFQNXNkbzFqaUcvcE5oMmhnN0tyeTRSQTMybjh0a3hU?= =?utf-8?B?V2NlSjZ5Vm9ybklZWFlQczNzaE1CMlE0b2M0bzZidmQrS0JubEhRM3EvcEsv?= =?utf-8?B?MWM4bEVNN0NmZHNiUUsxTmVGTjdVUnlTR0VibGNQbmFZeVlHUDB2MkxXTjZZ?= =?utf-8?B?WnZka1RBd3I4OEc2ajd6UW5Ga0dvWWpOcXJRSDlQZ0ZKNkVsZlRoeGtueHFN?= =?utf-8?B?RzMyM1hVWlRoNWJHMjZPVlZMVTl1Q25GaEpUK3djMEN0K3NLUytHMGRiY2JW?= =?utf-8?Q?Vfs5yPKF6a6fdqTJ25+sDQUMkHyHm40MAr?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-AuthSource: OS3PR01MB5686.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2021 11:17:11.9499 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-Network-Message-Id: 58eb5008-a87d-413e-1482-08d8b2fdc7ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: q8ol6Qi/droDNS8WPLtYCPg2QZMM0ps60bRV5t1Ftt42IDDwf5WG3bRTSsdqUM+Zpo/nQYrrVVxKSsKz8nwAZQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB5154 Archived-At: Subject: Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 07 Jan 2021 11:17:17 -0000 Hello everybody, On 07/01/2021 10:00, John C Klensin wrote: > Russ, Barry, > > Another small catch... > > --On Wednesday, January 6, 2021 13:41 -0800 Russ Housley via > Datatracker wrote: > >> Nits: >> >> Section 3.2 says: >> >> However, due to the SenML RFC 8428 Section 4.5.1 rules, DEV >> URNs do not support percent-encoding. >> >> This does not seem like a "however" statement to me. Perhaps, >> it is a "Note that" statement. Or, just drop "However". > > Sorry I, or someone in the URN registration review process, > didn't catch this, but I think it is a little more complicated > than a nit. When what became RFC 8141 was being developed, > several people made very clear to the WG that there was no > possible way for a URN specification to make an exception to the > syntax rules for URIs, including the rules about > percent-encoding in Sections 2.1 and 2.4 of RFC 3986. I can't > speak to what the URNBIS WG would have done had it been allowed > to consider the options that might have been opened by > developing different requirements for locators and names and, in > particular, whether any such changes would have affected > percent-encoding. However, it was painfully clear that no URN, > much less any particular URN namespace definition, can alter > those rules. John is completely correct here, many thanks for spotting this. Please also note the sentence "The lexical equivalence of the DEV URNs is defined as an exact and case sensitive string match.". Apart from the fact that this would be better written as "an exact case sensitive string match", lexical equivalence has to take into account percent-escaping. That means that e.g. urn:dev:mac:0024beffff804ff1 and urn:dev:mac:0024beffff804ff%31 are equivalent. I'm sorry I don't have the time to read the whole spec; it would be good if some of the authors went over it again with a fine comb after rereading RFC 3986 and understanding how percent-escaping works. If they have questions, the URN mailing list (urn@ietf.org) or the URI mailing list (uri@w3.org) would be the best places to ask for advice. Regards, Martin. > At this point, the most obvious option would be to change the > statement in draft-ietf-core-dev-urn to note that the RFC 3986 > rules apply and explain (inline or by reference) how > percent-encoding works. Such a statement might explain that, > given the characters permitted in RFC 8428 Section 4.5.1, > percent-encoding should never be necessary within a DEV URN. > However, because the list in 8428 includes characters that are > defined as "Reserved Characters" in Section 2.2 of RFC 3986, > notably including ":" and "/", the possibility of their being > percent-encoded by some process allowed by 3986 cannot be > eliminated. > > Other alternatives involve updating RFC 8141 and 3986, but I > wouldn't recommend going there, especially if the CORE WG would > like to see the current spec published in 2021. The narrowest > of those updates would be to change the rather relaxed-sounding > language of RFC 3986 Section 2.1: > > "used to represent a data octet in a component when that > octet's corresponding character is outside the allowed > set or is being used as a delimiter of, or within, the > component." > > To say that percent-encoding MUST NOT be used unless actually > required, but I'd guess that would not go over well with > existing implementations. > > Or, I suppose, the IESG could decide either that 3986 does not > count or that an interpretation that disallowed URN namespaces > prohibiting things that it allows is incorrect. But someone > would probably take that as a commitment to allow a revision to > 8141 that would codify the options that would imply. > > john > > p.s. This not being spotted earlier may be a contribution to the > discussion that is now occurring on the IETF list of early > cross-area review and how important it is to facilitate, rather > than discourage, such reviews. Or not. > From nobody Thu Jan 7 04:17:35 2021 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 124DE3A101A; Thu, 7 Jan 2021 04:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 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.262, 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 GUw824Y6V6EY; Thu, 7 Jan 2021 04:17:28 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2075.outbound.protection.outlook.com [40.107.21.75]) (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 C0EAA3A1016; Thu, 7 Jan 2021 04:17:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Topt65UAr+x/V8ddD3+CEudq5jU6RvORh55RMk2ZJyrm4dFjMop7rb4Nuk0oDu/RSZ+iRIzLrfiWCX84AoGITi4fNbutxMYcHkYp+F4w2IfygkU2qaaQABrhljbncxU3s+482fpzfFLbStxNBTDU0kH8x3IwifSDpICzXvJN2kpAnPh8nHaY6XHSh4+LWglHTptkXePHs/+spt98pjm/QFoYBIrjg5cG58338mNPHUnfpyFDSd6ksPVZ7ziG1B8Ng/3HJ0VZMTQoN1CFLwoCwOtisrjgaYcGiL9RQqclaHjKbCuVGDOAmYY42dEwweUUL1+4ZJUVtM2KW+VMRLfqLA== 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=U9Thpby5E1uOeHIcoKpDqDQ7cv794g3zTjAwe+Kiyz0=; b=km4oJcX8pIUsnsgAWoEb1u/kfXHQ1QAKm6cbfCDL0Edelaz6XxMyv3Qbg5l/AWmLOR4VVhQshv9FajBsK1B6YrOVUw3FRzfwWUnc++gRlZe0DG/LFzQorG5Y8onQZG4aBJVh3Y+1WbSqq/iK6p5lG/XLR2h1p4I7dKWmV0xSpMn4XvTwi6e66KQ9980OIqrHTjlAHJdr9DL14SKlpNSWKSCPl4VD/iL/oamVe5+pKnonlbLmijYOoAmhoOfWTBmh1YscwWRZfVolTmb7aYtMpCvcTaBgD6N05wy34KqW5C8wVLrLR4plevwzyZgpWrgo6QXgzAmd/u5M8x1zjgnHiw== 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=U9Thpby5E1uOeHIcoKpDqDQ7cv794g3zTjAwe+Kiyz0=; b=ckrQjdQ1EVFfaqXnYWAF3SyuW+cz6hQyBkrnocy5X/rt9EyvRD3V+OSNHyoebIAQn2LR56rhd6j7lkyjFsZBC+dgs6xsub05ci48qSIshqKd1o7FIAfvupuLOXlFsp6P0NfQduCRxNT+BEi3q5e/1r6gJajmdzRF/cSq2w/BhNU= 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 DB8P189MB0935.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:165::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Thu, 7 Jan 2021 12:17:23 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3742.006; Thu, 7 Jan 2021 12:17:22 +0000 To: supjps-ietf@jpshallow.com, christian@amsuess.com, draft-ietf-core-new-block@ietf.org Cc: dots@ietf.org, core@ietf.org References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> 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: Thu, 7 Jan 2021 13:17:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dQ8LYdawc3VlQgjcE9JCEHXiJxhWgTmxP" X-Originating-IP: [185.236.42.27] X-ClientProxiedBy: HE1PR09CA0063.eurprd09.prod.outlook.com (2603:10a6:7:3c::31) 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.27) by HE1PR09CA0063.eurprd09.prod.outlook.com (2603:10a6:7:3c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6 via Frontend Transport; Thu, 7 Jan 2021 12:17:22 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: eaf8be0f-eecc-44f9-20a6-08d8b3062ffd X-MS-TrafficTypeDiagnostic: DB8P189MB0935: 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: +MT1Vtc4grRiYz84SQKdmy7p8JVnwQt2PtefMMB9x4iHz/tW/BVVztUV81EOr875P5nFwxLvjcxUydoojkDVEkG3IiGSggz8BnFk90E2wjrh8vrv1xU8kbwo7iA87ubyMMWdpU3jz25tpCR7DXAPzlyuFXb4pCTx2Sg+rJ12R8g7Z4HIqCVuRHNcWoR3Qbie0cdp+27/TfnCAuHArBXy65kjIS16DRXU/youO/Wp1Xig/vCoKVnhB+Tcyu0FfXJLHFsobFQd8FWkoXN5JMMo/QKCsUiiCZOyzmn8V0ti7q6ymflRKY4C/DBDUxwrcFs3b//q4Nzdd9S0SwrByuzj2ThTZ1DbEkHz2K7ntYZSaGE0nov31hjfJWwKe99wnvAFRn5cRGABdx6VdbcrbOVrm47I/yXJHubKMPH5gDnN4Mw6KxE36tLR//cMYxIFlK0pLkvpVfEDKCZGJeeuBoUTYjDswZRvSxUT/R/DiLKdy8b3W96N+5//+5n6/G/AAKFBIAaFsdKG7IyGFMfhKdITg7jFbZuF/lFs+riLZEhGwBqLmZgsZrgZZYfrDaSDiRfu 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)(39850400004)(396003)(346002)(136003)(376002)(366004)(31686004)(66946007)(44832011)(66556008)(66476007)(966005)(53546011)(66574015)(6486002)(45080400002)(33964004)(52116002)(478600001)(8676002)(2616005)(235185007)(956004)(16576012)(2906002)(31696002)(36756003)(6666004)(4326008)(5660300002)(86362001)(16526019)(186003)(26005)(83380400001)(8936002)(30864003)(21480400003)(316002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?VkNlRTdjVlVlKzNPREJGTHFEZ2wwZ1M4VWFnQ2g5UktlY1ZhelN2NlBwZmw2?= =?utf-8?B?SzFKQ3IzdWoyLzRmeXF4U1RHT1piUDREMHZuVUl0QkpyRFFDOHF6T2xoVTFs?= =?utf-8?B?bXRNWFFVR29GNTc0cHNZSGd1M0VUcU1CMy9waWxXQThjbHhISDFkRjlsOUJW?= =?utf-8?B?S0hBZHVmeUpzVHpLa3E3RnlqQWVxUGwzN0trVWpacjBIelZsUkpDMElmNUlB?= =?utf-8?B?aHVhM3FSNFhuV1BDUElNclRZQ2kxSGpKZmNTRVBweCtqM1YwWWI5VzJyc0NY?= =?utf-8?B?aERwdUdHTTY2OGFEeEF0YnZBZXlEaUg1cUhlNVd2QWc0U0lJQmMrV25HZEZU?= =?utf-8?B?ek5UNXJTd0podUpUa2dCeWRiSDBlL0FjcXNOUm5BTnhhdGgxaGhaRktXRzhp?= =?utf-8?B?dGhXOXR3VjFXL2dVa3ZnQ3pSMnR0QTEvSUZWU0srZGt1aUwzUjlEYTRrdmh6?= =?utf-8?B?MG1obkszT0NOMlF6VVhwNnViendvMnNiZXFCZ1E0UWJydlZrYWFKKzFoQkZE?= =?utf-8?B?clUyU216L25GMlkzNHJRaEMzWXNrM0lWaHc2S2pKRExhVmxjVUhXcmlmb2VF?= =?utf-8?B?NnFMKzFnOW5vN1V1Ri9yWmZMbE93WDg1RzBvMmJPRzRJM2FWSjd2bDJsN242?= =?utf-8?B?aS9TMElOL1NhVE4xY3BnSHI1eHhYcS9BZ2lsUXU1Wm0yVWJKSXdETmNhUExt?= =?utf-8?B?ZU8xUXUzSjIwcjJ3eXc2L3pyN2VTMU5uaUJDa293a2o2VmhSS29aVnppTXVi?= =?utf-8?B?MFdYMzVDVE90RS9GejlRWGNLSEZoYTdtdHR4VGN6Rm80amR1TjNzQVBzSE1T?= =?utf-8?B?dHJEUDk0azY1YVBUc3AyZnpIY2tUd1RsQnYxZXk1c28zaFNRVEVDNGZ0VFRo?= =?utf-8?B?RS8zVDEybGN2cUpVSEdiTm0vR3VFTC9GQWVZZC9FeStOd1BneW1YUnpCekVF?= =?utf-8?B?Ym9EUTJvMGFOSlBPTHFlckRLcHoxdE5xRDllc3VDV3hVYjVSR1pYWjlvT0xx?= =?utf-8?B?K1BQOUhXMnhTbzJyUUxRa2VZaXdZVGxocDhqc3JzNENQQUhOYTV6WXUrcldL?= =?utf-8?B?WHFuWWQzb0l0Q0tOVVcvYjlPQ2dnbFhVL2pIenVxRlVVeVpLTmY5ZktWVDBU?= =?utf-8?B?WnRWRTZDb2R0YnlDTWlYTFBHWld2eDY5Ui9DOEdnN2EzTFJQdk13azVpdUJV?= =?utf-8?B?dnZLQmRZcnFYV09CRGxPYzhZZ1R2dnFGRCtSMXd5VWxNdkZnYThUOERLeXV0?= =?utf-8?B?anVaMU05cUY3TkgzY3ZJZEorUGlKdzBwWGZDUVZHUEFHYXBvSFBmaEMrNmpY?= =?utf-8?Q?yYgTyDxrN02VXBR42JM325oiKnOtL1Ym5y?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2021 12:17:22.8173 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: eaf8be0f-eecc-44f9-20a6-08d8b3062ffd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: rczuPEYztmzlmc2AZ+nwBX7cswGaqYg8rAbI8dn43ym6Lu3zoa2BCaLPGmYCK0HfBhJ7toH0Xsz3HMltVNM3Cw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0935 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 07 Jan 2021 12:17:33 -0000 --dQ8LYdawc3VlQgjcE9JCEHXiJxhWgTmxP Content-Type: multipart/mixed; boundary="6NBo78rvo9ddgGch7u9vPyzQZAAono3DS" --6NBo78rvo9ddgGch7u9vPyzQZAAono3DS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi, Thanks for this revision and for addressing my comments already in version=C2=A0 -03. Please, see below some more comments on this version -04. Best, /Marco * s/There are one or more missing CBOR encoded missing block numbers./There are one or more CBOR encoded missing block numbers. *=C2=A0 Section 4 now includes the new paragraph: "The token to use for t= he response SHOULD be the token that was used in the highest block number received payload.=C2=A0 The Q-Block1 Option from the same packet SHOULD b= e included." =C2=A0=C2=A0 Consistently, the example in Figure 5 should also have QB1:3= /0/1024 in the 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08 response with Token T:0xe4. =C2=A0=C2=A0 Since "SHOULD" is used, when is it still fine or expected to= not include Q-Block1 in a 4.08 response? * When commenting the example in Figure 5, Section 9.1 reads: "The Token just needs to be one of those that have been received for this Request-Tag, so the client can derive the Request-Tag." =C2=A0=C2=A0 Should this not be aligned with the SHOULD used in Section 4= about using the Token from the same packet conveying the highest block number? =C2=A0=C2=A0 =C2=A0=C2=A0 You explained in your mail that the client keeps tracking al= l Tokens in the burst anyway, so maybe it's better to rather align the text in Section 4 with what suggested here in Section 9.1, i.e. responding with any of those Token values is just fine. =C2=A0=C2=A0 =C2=A0=C2=A0 In such a case, the Q-Block1 option included in the 4.08 res= ponse has still to be the one from the request conveying the highest block number. Correct? * The new text in Section 6.2 says: "... and the situation re-evaluated for another 24 hour period until there is no report of missing payloads under normal operating conditions." =C2=A0=C2=A0 When that happens, I suppose MAX_PAYLOADS is right away rest= ored to the intended value, i.e. it is not incremented by 1 to start another 24-hour period evaluation. Correct? * Section 6.2 says: "The request that the client sends to acknowledge the receipt of all the current set of MAX_PAYLOADS payloads SHOULD contain a special case Q-Block2 Option with NUM set to the first block of the next set of MAX_PAYLOADS payloads and the M bit set to 1." =C2=A0 Is it possible to reflect this in the example of Figure 6? It woul= d require the body to have more than MAX_PAYLOADS blocks thus resulting in more bursts, which would be inherited by the examples in Figure 7 and Figure 8. * In Section 9, it would be good to have the parameters defined in Section 6.2 and their values reflected in the examples, when applicable. E.g., MAX_PAYLOADS is at least 4 in these examples; the asked retransmissions are presumably due sometimes to MAX_PAYLOADS compared against the value of the latest received Q-Block1/Q-Block2, while sometimes to NON_RECEIVE_TIMEOUT. * In the example in Figure 6, shouldn't the first request from the client have the M bit set to 1 in the Q-Block2 option, i.e. as QB2:0/1/1024 ? As per Section 3.4, that would indicate that the request is in fact for the block 0 and for all of the remaining blocks within the body. On 2021-01-06 16:24, supjps-ietf@jpshallow.com wrote: > Hi Christian, > > Once again, thank you for the comprehensive review. > > Responses part 2. A new version (-04) of the draft has been published = and > can be found at https://eur02.safelinks.protection.outlook.com/?url=3Dh= ttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new-block%2F&am= p;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b257478= 0%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnkno= wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX= VCI6Mn0%3D%7C2000&sdata=3DMlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7jgTY= %3D&reserved=3D0 > > > Part 1 responses were covered in the main by version -03, so you may wa= nt to > look at the -02 to -04 differences. > > The Congestion Control section has been re-written to simplify how thin= gs > work and has a new set of definitions. There is a separation of Confirm= able > and Non-Confirmable Congestion Control with the stated assumption that = all > of a body is sent as Non-Confirmable or Confirmable. > > Otherwise, see inline. > > Regards > > Jon > >> * The list of pros and cons (with the cons being almost trivial) does >> not explain to the reader why these are not a replacement; I suggest= >> to add: > [Jon] Another disadvantage addition > NEW > To reduce the transmission times for CON transmission of large bodies, > NSTART needs to be increased from 1, but this affects congestion contro= l > where other parameters need to be tuned (Section 4.7 of [RFC7252]). S= uch > tuning is out of scope of this document. > >> * "If the client transmits a new body of data with a new Request-Tag >> to": Processing parallel requests is something Request-Tag opens up.= I >> don't see why there's a MUST to that; the server certainly MAY drop >> the old request, but it may just as well process them in parallel. > [Jon] The intent here was that garbage collection would take place soon= er > than later - especially when running in a lossy environment and the cli= ent > has updated information to transmit. I agree that Request-Tag enables t= he > possibility of sending multiple block requests with different payloads,= and > so there is a possibility that the client starts sending body A, then > decides to send body B and terminate A, but a packet from B arrives bef= ore a > packet from body A is received and so things fail as A does not complet= e. > > OLD > If the client transmits a new body of data with a new Request-Tag to= > the same resource on a server, the server MUST remove any partially > received body held for a previous Request-Tag for that resource. > NEW > If a server receives payloads with different Request-Tags for the sam= e > resource, it should continue to process all the bodies as it has no way= of > determining which is the latest version, or which body, if any, the cli= ent > is terminating the transmission for. > > If the client elects to stop the transmission of a complete body, it = > SHOULD "forget" all tracked tokens associated with the body's=09 > Request-Tag so that a reset message is generated for the invalid=09 > token in the 4.08 (Request Entity Incomplete) response. The server=09 > on receipt of the reset message SHOULD delete the partial body. > END > >> * "If the server receives a duplicate block with the same Request-Tag"= : >> Why? Being silent is the default on nonterminal blocks alredy, but i= n >> a situation like figure 5 if the 2.04 is lost, that rule would make >> it impossible for the client to ever get a successful response. >> >> A better rule here may be to say that it processes it all the same >> (and if the payload is distinct from the first transmission's payloa= d, >> it should err out.) > [Jon] Fair point > OLD > If the server receives a duplicate block with the same Request-Tag, > it SHOULD silently ignore the packet. > NEW > If the server receives a duplicate block with the same Request-Tag, > it SHOULD ignore the payload of the packet, but MUST still respond = as if > the block was received for the first time. >> * "If the server receives multiple requests (implied or otherwise) for= >> the same block, it MUST only send back one instance of that block.":= >> This might be read as "ever" rather than "per incoming request", whe= re >> probably the latter is meant. > [Jon] This text has already been updated following another review > "OLD > If the server receives multiple requests > (implied or otherwise) for the same block, it MUST only send back on= e > instance of that block. > NEW > If the request includes multiple Q-Block2 > Options and these options overlap (e.g., combination of M being set > (this and all the later blocks) and being unset (this individual > block)) resulting in an individual block being requested multiple > times, the server MUST only send back one instance of that block. > This behavior is meant to prevent amplification attacks." > >> * "The ETag Option MUST NOT be used": This is more a factural than a >> normative statement; it *can* not be used there as the server would >> respond thusly. It may be used, but then that indicates that the >> client is trying to verify a freshness. (However, the client should >> not *start* sending an ETag once it learned the current resource's >> ETag when still attempting to pull out more blocks, but that's also = not >> a normative requirement but a consequence of those two requests not >> being matchable any more.) > [Jon] OK > OLD > The ETag Option MUST NOT be used in the request as the server could > respond with a 2.03 (Valid Response) with no payload. If the server= > responds with a different ETag Option value (as the resource > representation has changed), then the client SHOULD drop all the > payloads for the current body that are no longer valid.=20 > NEW > The ETag Option should not be used in the request for missing blocks= as > the server could respond with a 2.03 (Valid Response) with no payload. = It > can be used in the request if the client wants to check the freshness o= f the > currently cached body response. > > If the server detects part way through a body transfer that the resourc= e > data has changed and the server is not maintaining a cached copy of the= old > data, then the body response SHOULD be restarted with a different ETag > Option value. Any subsequent missing block requests MUST respond using = the > latest ETag Option value. > > If the server responds during a body update with a different ETag Opti= on > value (as the resource representation has changed), then the client sho= uld > treat the partial body with the old ETag as no longer being fresh.=20 > END >> * "then the client SHOULD drop all the payloads for the current body":= >> "Drop" is overly prescriptive; the client may well keep them, but >> just can't consider them fresh any more. (If the client has ample >> caching abilities, they might come in handy if the resource goes bac= k >> to that ETag state). Same for later "the client MUST remove any >> partially received". > [Jon] See previous response, otherwise > OLD > If the server transmits a new body of data (e.g., a triggered > Observe) with a new ETag to the same client as an additional > response, the client MUST remove any partially received body held fo= r > a previous ETag. > NEW > If the server transmits a new body of data (e.g., a triggered > Observe) with a new ETag to the same client as an additional > response, the client should remove any partially received body held = for > a previous ETag for that resource as it is unlikely the missing bloc= ks > can be retrieved. >> * "For Confirmable transmission, the client SHOULD continue to": As >> above in the other direction, that's not news. > [Jon] Again, we are not looking for a response (well, a request in this= case > as needed by Block2), just an ACK > OLD > For Confirmable transmission, the client SHOULD continue to > acknowledge each packet as well as issuing a separate GET, POST, PUT= , > FETCH, PATCH, or iPATCH for the missing blocks. > NEW > For Confirmable transmission, the server continues to acknowledge=09 > each packet, but a response is not required (whether separate or=09 > piggybacked) until successful receipt of the body or, if some of the = > payloads are sent as Non-confirmable and have not arrived, a=09 > retransmit missing payloads response is needed. >> * "If there is insufficient space to create a response PDU": I don't >> understand what that means. (Where are request options reflected >> back?). > [Jon] This was triggered by a question by Michael Richardson " So, give= n a > Christmas-Tree-Packet (largest packet, every possible option space used= , > every extension turned on...) how much data can I get back? :-)" and no= t > fully thought through. > It could happen though with Location-Path, Location-Query, Q-Block2, ET= ag, > Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in respon= se to > a POST. > OLD > If there is insufficient space to create a response PDU with a block= > size of 16 bytes (SZX =3D 0) to reflect back all the request options= as > appropriate, a 4.13 (Request Entity Too Large) is returned without > the Size2 Option. > NEW > If there is insufficient space to create a response PDU with a block= > size of 16 bytes (SZX =3D 0) to send back all the response options a= s > appropriate, a 4.13 (Request Entity Too Large) is returned without > the Size1 Option. > >> * "If the client requests missing blocks, this is treated as a new >> request.": I don't think the client should even make these follow-u= p >> requests Observe, as it already has an ongoing observation. They'd = be >> sent on a different token too, so setting Observe would be opening >> observation up on that token, which AFAIU is not intended. (Figure = 7 >> example looks good to me in that respect.) >> >> (It may make sense to ask the client to keep Observe to make the >> requests matchable just for the sake of staying in atomic-request >> mode. Either way, the server should then not accept that observatio= n >> as it's not for a block 0.) > [Jon] The intent here was that just a new Token should be used. > OLD > If the client requests missing blocks, this is treated as a new > request. The Observe value may change but MUST still be reported. > If the ETag value changes then the previously received partial body > should be destroyed and the whole body re-requested. > NEW > If the client requests missing blocks, this is treated as a new > Request and the Observe Option MUST NOT be included. If the ETag v= alue > changes, then the previously received partial body > should be considered as not fresh and the whole body re-requested. > >> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response can be >> matched by the token to a unique request that already had a >> Request-Tag, and the client needs to have kept that token around >> matched to the transfer to make sense of it. >> >> No need to move that value around between subsystems, and just >> dropping it from here would also remove the need for the "If the >> client does not recognize the Request-Tag" clause (which would >> otherwise need clarification as to what it'd mean if it recognizes i= t >> but it doesn't match what the request was for). > [Jon] Good question - it does make sense for the Request-Tag to be trac= ked > alongside the Token in the client. > OLD > The data payload of the 4.08 (Request Entity Incomplete) Response > Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR encoded= > Request-Tag followed by 1 or more missing CBOR encoded missing block= > numbers. > NEW > The data payload of the 4.08 (Request Entity Incomplete) response > is encoded as a CBOR Sequence [RFC8742]. There are one or more miss= ing > CBOR encoded missing block numbers. > > OLD > ; This defines an array, the elements of which are to be used > ; in a CBOR Sequence: > payload =3D [request-tag, + missing-block-number] > request-tag =3D bstr > ; A unique block number not received: > missing-block-number =3D uint > NEW > ; This defines an array, the elements of which are to be used > ; in a CBOR Sequence: > payload =3D [+ missing-block-number] > request-tag =3D bstr > ; A unique block number not received: > missing-block-number =3D uint=20 > > OLD > A 4.08 (Request Entity Incomplete) Response Code returned with > Content-Type "application/missing-blocks+cbor-seq" indicates that > some of the payloads are missing and need to be resent. The client > then re-transmits the missing payloads using the Request-Tag and > Q-Block1 to specify the block number, SZX, and M bit as appropriate.= > The Request-Tag value to use is determined from the payload of the > 4.08 (Request Entity Incomplete) Response Code. If the client does > not recognize the Request-Tag, the client can ignore this response. > NEW (option presentation has been reformatted) > 4.08 (Request Entity Incomplete) > > This Response Code returned with Content-Type "application/=09 > missing-blocks+cbor-seq" indicates that some of the payloads are=09 > missing and need to be resent. The client then retransmits the=09 > missing payloads using the same Request-Tag, Size1 and Q-Block1 to=09 > specify the block number, SZX, and M bit as appropriate.=09 > =20 > > The Request-Tag value to use is determined from the token in the=09 > 4.08 (Request Entity Incomplete) response and then finding the=09 > matching client request which contains the Request-Tag that is=09 > being used for this Q-Block1 body. END >> * "limit the array count to 23 (Undefined value)": 23 is the maximum >> length of a zero-byte length indication, not indefinite-length (31).= >> Both using 23 and 31 here makes sense (up to 23 to have definite >> length that can be updated in-place, or exceeding that switch to >> indefinite length if they still fit), but the paragraph seems to be >> mixing them up. > [Jon] OK > OLD > Arrays (Section 3.2.2 of [RFC8949]), limit the array count to 23 > (Undefined value) so that the array data byte can be updated with= > the overall length once the payload length is confirmed or limite= d > to MAX_PAYLOADS count. > NEW > Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit the a= rray > count to > 23 so that the initial byte with the array major type and data le= ngth > in the additional information can be updated with the overall count onc= e the > payload count is confirmed. Further restricting the count to MAX_PAYLO= ADS > means that congestion control is less likely to be invoked on the serve= r. > >> * "Each new request MUST use a unique token": Like above, this is >> stating something that's not intended to be changed. > [Jon] RFC7252 does not require Tokens to be unique - e.g. empty token v= alues > are acceptable. Hence this statement. >> Congestion Control: >> >> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is subject= ed >> to PROBING_RATE.": That is unexpected here. At most one such >> response is sent to each request message, so why is additional >> congestion control needed? > [Jon] The intention here was that in the previous paragraph that it was= not > the individual packets that are subject to PROBING_RATE, but a single b= ody > comprising of multiple packets is subject to PROBRING_RATE - and hence > limiting any individual responses to PROBING_RATE rather than the > potentially full set of responses > OLD > PROBING_RATE parameter in CoAP indicates the average data rate that > must not be exceeded by a CoAP endpoint in sending to a peer endpoin= t > that does not respond. The body of blocks will be subjected to > PROBING_RATE (Section 4.7 of [RFC7252]). > NEW > PROBING_RATE parameter in CoAP indicates the average data rate that > must not be exceeded by a CoAP endpoint in sending to a peer endpoin= t > that does not respond. The single body of blocks will be subjected = to > PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets.= > If the wait time between sending bodies that are not being=09 > responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the = > gap time is limited to NON_PROBING_WAIT. > > Note: For the particular DOTS application, PROBING_RATE and other > transmission parameters are negotiated between peers. Even when=09 > not negotiated, the DOTS application uses customized defaults as=09 > discussed in Section 4.5.2 of [RFC8782]. > END >> On the other hand, *ever* NON request is subject to PROBING_RATE, s= o >> why point out the body of blocks and "GET or similar" particularly?= > [Jon] It is only GET or FETCH. The intention here is to not request bo= dies > of data at too high a rate. > OLD > Each NON GET or similar request using Q-Block2 Option is subjected t= o > PROBING_RATE. > NEW > Each NON GET or FETCH request using Q-Block2 Option is subjected to > PROBING_RATE. >> * "a delay is introduced of ACK_TIMEOUT": As I understand MAX_PAYLOADS= , >> this is (rather implicitly) introduced as the package count up to >> which it is OK to exceed PROBING_RATE temporarily (but after that it= >> kicks in all the harder by requiring to wait until complete-sent-byt= es >> over PROBING_RATE has expired). If that holds, at that time a much >> larger delay than just ACK_TIMEOUT is needed to get a response from >> the server: About 3 hours (see later note on parameters). > [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re-write of > Congestion Control section. >> This is the crucial point in the document, and for it a recommendati= on >> alone is not good enough. The protocol can be run with a vastly >> increased PROBING_RATE (however externally determined) and from the >> point of MAX_PAYLOADS just observe it. Or it has to get feedback fro= m >> the server; a single 4.08 is probably enough to kick off another >> vollley of blocks. (How many? MAX_PAYLOADS for every response?). >> Both can be permitted, but just waiting ACK_TIMEOUT isn't doing any >> good. > [Jon] See re-write of Congestion Control section where things should no= w be > simpler and more logical. There is an introduction of new variable > definitions. >> * "For NON transmissions": This seems to imply that the full exchange = of >> a body is either NON or CON; I don't see where that'd come from. I'd= >> have expected to read something like "Each individual request can be= >> NON or CON independent of the others. In particular, it can be >> convenient to send the ultimate payload...". > [Jon]The DOTS environment will only be using NON. To make Congestion > Control simple, > the expectation is that all transmissions are NON or (not recommended) = are > all CON. The draft now generally records this expectation. >> * "If a Confirmable packet is used, then the transmitting peer MUST wa= it >> for the ACK": Why? A NSTART > 1 would give it leisure to still >> transmit. > [Jon] Text has been removed in the clean-up. >> * General on congestion control: It may help implementors if this were= >> split up into newly introduced rules and concepts (that is, >> MAX_PAYLOADS and the answer to whether you may send MAX_PAYLOADS >> en >> block again after having only even one response from the last round,= >> and probably the recommended parameters of the "Also on parameters" >> comment), and another subsection on how Q-Block behaves well when >> observing these. > [Jon] Should now be covered in the updated Congestion Control section. >> Caching: >> >> * "are not part of the cache key": How about "are removed as part of t= he >> block assembly and thus do not reach the cache"? > [Jon] OK. > OLD > As the entire body is being cached in the proxy, the Q-Block1 and > Q-Block2 Options are not part of the cache key. > NEW > As the entire body is being cached in the proxy, the Q-Block1 and > Q-Block2 Options are removed as part of the > block assembly and thus do not reach the cache. >> * "When the next client completes building the body": If the proxy >> chooses not to let them happen in parallel (which it may, see above = on >> parallel requests, although the server might still not support it an= d >> cancel one of them), why bother letting the first finish just to abo= rt >> it? (IOW: If the proxy does not intend to see both through, which it= >> could if it held back the second until the first is through on the >> uplink, it could just as well err out of one of them early, but it m= ay >> also rather see both through.) > [Jon] It has to be assumed that traffic to/from the origin client and o= rigin > server may not both support Q-Blockx and potentially may have a differe= nt > SZX. Thus passing a request or a response through at the block level > introduces a new set of challenges (but not impossible to fix). To kee= p > this simple, my thinking was that the passing through can only take pla= ce at > the body level. Again, the arrival of packets is not necessarily > sequential, so client A's body may start transmitting to the origin ser= ver > first, but client B's body starts to arrive first - the same being true= for > the proxy as a client may stop transmitting for whatever reason (restar= t, > network loss etc.). However this is covered by the above update " If = a > server receives payloads with different Request-Tags for the same resou= rce, > it should continue to process all the bodies". > > OLD > and the new body representation transmission starts with a new > Request-Tag value. > NEW > and the new body representation transmission starts with a new > Request-Tag value. Note that it cannot be assumed that the proxy wi= ll > always receive a complete body from a client. >> * Examples: >> >> * Figure 5: The ... between e3 request and response indicate the >> MAX_TRANSMIT_SPAN before sending the 4.08 response. I suppose ther= e >> should be the same kind of delay between the failed e5 transmissio= n >> and the e4 response. > [Jon] Agreed and added in >> * If the second burst had 3 requests out of which 2 made it, is ther= e >> any guidance for which of them the 4.08 would come back on? (In th= e >> end, none of them is terminal). > [Jon] The client should tracking all Tokens of the burst (hence > implementation note about bottom 32bits unique and top 32 bits matching= > block number for ease of tracking) for a response and so it will make n= o > difference at to which token is used for the 4.08 response. From an > implementation perspective, it probably is easier to track the last opa= que > token that has the same Request-Tag.=20 > OLD > missing ones in one go (Figure 5). It does so by indicating which > blocks have been received in the data portion of the response. > NEW > missing ones in one go (Figure 5). It does so by indicating which > blocks have been received in the data portion of the response. The T= oken > just needs to be one of those that have been received for this Request-= Tag , > so the client can derive the Request-Tag. >> * If that e4 response gets lost, does the whole mechanism recover fr= om >> it in any way? > [Jon] In this example, if e4 and e5 get lost, there will be no > 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as to whet= her > it sends the request again or gives up. See 9.1 > "Under high levels of traffic loss, the client can elect not to retry= > sending missing blocks of data. This decision is implementation > specific." >> Generally, the all-NON and all-CON examples don't look to me like >> what I'd be doing with this spec; the mixed "a CON every >> MAX_PAYLOADS" appears much more realistic. > [Jon] It is unsafe to use CON in the (potentially lossy) DOTS environm= ent > (up to 93 secs timeout per payload with the defaults). Hence why we ar= e > separating out the NON / CON usage. >> * Figure X: The request ahs M unset and thus indicats a request for >> just that block. If more than one is expected, it should say >> QB2:0/1/1024. > [Jon] With Figure 7, with the M bit set, block 3 would get returned for= a > second time. Draft-ietf-core-new-block-03 also has a Figure 8 which do= es > exactly what you describe. >> * New Content Format: I think this needs a media type registration to = go >> with it first; based on that, a content format can be registered. > [Jon] Med has responded to this and draft updated. >> * General on MAX_TRANSMIT_SPAN and other timing parameters: I'm not >> sure >> they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is defin= ed >> in terms of reliable transmission, but used for NONs as well. (So is= >> the alternative ot 2x ACK_TIMEOUT). > [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and ACK_TIMEOUT in = a NON > environment. Hence re-write of Congestion Control section defining new > variables that can be used for NON. >> For the purpose of delaying a 4.08 or a follow-up GET, it may make >> more sense to define a new parameter based on MAX_LATENCY and the >> time >> it takes the sender to pump out the options (which I don't think we >> have a good factor for, but may even be negligible here). >> >> Could read like this: >> >> > The timing parameter MAX_BLOCK_JITTER is introduced, and by defaul= t >> > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / BANDWIDTH. > [Jon] Lets plug in some numbers here. MAX_LATENCY =3D 100, MAX_PAYLOA= DS =3D > 10, MTU =3D 1280bytes and BANDWIDTH =3D 1Mbps. > > [Jon] MAX_BLOCK_JITTER =3D 100 + (10 * 1280 * 8)/(1 000 000) =3D 100.1.= So > BANDWITH of 1Mbps has negligible effect on the calculation. 1Kbps makes= > MAX_BLOCK_JITTER 200 seconds. >> > >> > With Q-Block2, a client can ask for any missing blocks after not >> > having received any further response for the duration of >> > MAX_BLOCK_JITTER. > [Jon] 100+ seconds delay is way too much time to wait for any missing b= locks > in my opinion. > > [Jon] RFC7252 also states (and the intention is that recovery works wel= l) > " as MAX_LATENCY is not > intended to describe a situation when the protocol works well, bu= t > the worst-case situation against which the protocol has to guard.= " >> > >> > With Q-Block1, a server holds off any response for MAX_BLOCK_JITTE= R >> > unless all blocks have been received. Only then it evaluates wheth= er >> > to respond with a 2.0x code, a 4.08 with payload, or not at all >> > (because it responded to a later request). > [Jon] I am not convinced that this is necessarily the way to go. The n= ew > Congestion Control more cleanly handles this. >> This also brings me back to the earlier matter of 2.31: What is a >> server supposed to send when no packages were lost, but it's pasing >> the timeout and wants to help the client flush out more packages by >> confirming something? It says 4.08 in 3.3, but it's not like there's= a >> hole in the contiguous range. Does it need to send 4.08 enumerating >> all (or at least some) numbers between the first unreceived and what= 's >> indicated by Size1? Or can it just send 2.31 and the client knows al= l >> it needs to know b/c the response came to the largest block that was= =20 >> sent and 2.31 indicates that everything is good up to that point? > [Jon] The previous draft states (under Congestion Control) that the cli= ent > waits for ACK_TIMEOUT before transmitting the next set of MAX_PAYLOADS > blocks. The server should wait for "two times ACK_TIMEOUT " (3.3) befo= re > indicating issue. Apart from perhaps having a new name for ACK_TIMOUT = I > think that these are reasonable values for Non-Confirmable - and are us= ed in > the new Congestion Control section. > > [Jon] I have reworked Congestion Control to use 2.31 (NON only) as a si= gnal > to say that all of the current MAX_PAYLOADS payloads of a body have bee= n > received, so allowing the client to continue transmitting the next set = of > MAX_PAYLOADS payloads without the need to wait any longer. >> * Also on parameters: This document is describing flow control stuff >> around a situation CoAP was not originally designed for. Wouldn't it= >> make sense to include a set of parameters (PROBING_RATE, MAX_LATENCY= , >> ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that >> PROBING_RATE will be left to 1 byte/second for any DOTS application >> using this (for sending 10KiB in the initial 10-package MAX_PAYLOADS= >> burst would mark that connection as unusable for about 3 hours if th= ey >> all get lost), so better give justifiable numbers here than rely on >> implemnetors to come up with unreviewed numbers or disregard >> PROBING_RATE altogether. > [Jon] Answered by Med, and some new text added. >> I don't know if it needs additional justification, but an increased >> N_START may be justifiable there. > [Jon] It may be, but tuning the other associated parameters is really o= ut of > the cope of this draft. This text has been added > NEW > Congestion control for CON requests and responses is specified in=09 > Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will = > need to be increased from 1. However, the other CON congestion=09 > control parameters will need to be tuned to cover this change. This = > tuning is out of scope of this document as it is expected that all=09 > requests and responses using Q-Block1 and Q-Block2 will be Non-=09 > confirmable. >> * Somewhere (never comes up but I think it should): When CONs are used= , >> a 4.08 (or 2.31?) response to a later request can indicate to the >> client that an earlier CON request has been processed successfully. = If >> the client can match that up (and it should be able to), then it can= >> (and should) cancel that particular CON request. > [Jon] I think that this is covered by my update above with the text > " NEW > For Confirmable transmission, the server continues to acknowledge=09 > each packet, but a response is not required (whether separate or=09 > piggybacked) until successful receipt of the body or, if some of the = > payloads are sent as Non-confirmable and have not arrived, a=09 > retransmit missing payloads response is needed." > > And in my previous part 1 response (updated) > NEW > For Confirmable transmission, the server continues to acknowledge=09 > each packet, but a response is not required (whether separate or=09 > piggybacked) until successful receipt of the body or, if some of the=09 > payloads are sent as Non-confirmable and have not arrived, a=09 > retransmit missing payloads response is needed. >> Best regards >> Christian >> >> -- >> There's always a bigger fish. >> -- Qui-Gon Jinn > _______________________________________________ > core mailing list > core@ietf.org > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= =2Eietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloca= %40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09ecc40= cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj= AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3Dt= EJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&reserved=3D0 --=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 --6NBo78rvo9ddgGch7u9vPyzQZAAono3DS-- --dQ8LYdawc3VlQgjcE9JCEHXiJxhWgTmxP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/2+9AACgkQ7iZktA5Y 2kPUoAf/caC/91pj2BAIzRdnSoEonWnndXUwoMCPtT8QB9rHGfKZnhLJBAWQ8bZb z7YcRZvNyAn6X8T4A5oZGnkxCDOfvr9Fpo0RV/E5j+/zfMKdW35PtvlGtqvx77U4 nZZfEC3sI+zYNVqgrOPh97FYP1X0ZFf7NHekkY2bYWzHXTZ+H7DJ2p08XTDCUOJ/ qSn/FuH0fc93e/ajCyCYvn5gATAus2+rGnc9O4uLx9l8dW5vpTfB219p9PsyEU7Z uKqOspeQj0d0k4WwbnurPXMP51Kc18r/n++LLSP6Uywc0/mkV3XFnPsUJxBj6fqy 4KKLc+h84npR0+ebH/ONF4vRhPNjwg== =ZSr9 -----END PGP SIGNATURE----- --dQ8LYdawc3VlQgjcE9JCEHXiJxhWgTmxP-- From nobody Thu Jan 7 05:14:28 2021 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 2A61D3A109D for ; Thu, 7 Jan 2021 05:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRjuldY5KOLY for ; Thu, 7 Jan 2021 05:14:24 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2428C3A109B for ; Thu, 7 Jan 2021 05:14:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A9F3C300BD4 for ; Thu, 7 Jan 2021 08:06:37 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id F8eN2zSW9iZF for ; Thu, 7 Jan 2021 08:06:33 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 529A3300B03; Thu, 7 Jan 2021 08:06:33 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C7682BAD-05AB-4FDA-9999-F6AA15CEC64F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Thu, 7 Jan 2021 08:06:34 -0500 In-Reply-To: Cc: "iot-directorate@ietf.org" , draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org, last-call@ietf.org To: Barry Leiba References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 07 Jan 2021 13:14:26 -0000 --Apple-Mail=_C7682BAD-05AB-4FDA-9999-F6AA15CEC64F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Barry: You are, of course, correct. RFC 5234 says: ABNF strings are case insensitive and the character set for these strings is US-ASCII. However, that raises a different issue: The DEV URN syntax allows both upper and lower case characters. The URN-equivalence of the DEV URNs is defined per [RFC8141] Section 3.1, i.e,. two URNs are URN-equivalent if their assigned-name portions are octet-by-octet equal after applying case normalization to the URI scheme ("urn") and namespace identifier ("dev"). So, the ABNF should be changed so that the "mac:", "ow:", "org:", "os:", = and "ops:" are required to be lowercase. I guess that means replacing = each letter with the appropriate value in the %x61-7A range. That will = not be as easy to read... Russ > On Jan 6, 2021, at 4:49 PM, Barry Leiba = wrote: >=20 > Thanks for the quick review, Russ, and good catches here. >=20 > On one item, though: >=20 > > If both cases are to be supported, the upper case letters need to be > > added to the ABNF to permit them. >=20 >=20 > Actually not: quoted letters in ABNF are case-insensitive, so =E2=80=9Ca= =E2=80=9D matches both lowercase a and uppercase A. >=20 > Barry >=20 > On Wed, Jan 6, 2021 at 4:41 PM Russ Housley via Datatracker = > wrote: > Reviewer: Russ Housley > Review result: Almost Ready >=20 > I reviewed this document as part of the IoT Directorate's effort to > IoT-related IETF documents being processed by the IESG. These = comments > were written primarily for the benefit of the Internet Area Directors. > Document authors, document editors, and WG chairs should treat these > comments just like any other IETF Last Call comments. >=20 > Document: draft-ietf-core-dev-urn-09 > Reviewer: Russ Housley > Review Date: 2021-01-06 > IETF LC End Date: 2020-12-02 > IESG Telechat date: 2021-01-21 >=20 >=20 > A review from the IoT Directorate was requested on 2021-01-05, which = is > after the IETF Last Call ended. I assume that the Internet ADs want > this review to help inform them during IESG Evaluation. >=20 >=20 > Summary: Almost Ready >=20 >=20 > Major Concerns: >=20 > Section 3.2 says: >=20 > The optional underscore-separated components following the = hexstring > are strings depicting individual aspects of a device. >=20 > Not all of the DEV URN forms contain a hexstring; however, all of them > are allowed to end with underscore-separated components. I suggest: >=20 > The optional underscore-separated components at the end of the > DEV URN depict individual aspects of a device. >=20 > Section 3.2.1 says: >=20 > ... and a MAC address could be represented either with > uppercase or lowercase hexadecimal digits. >=20 > This is not allowed by the ABNF: >=20 > hexstring =3D 1*(hexdigit hexdigit) > hexdigit =3D DIGIT / "a" / "b" / "c" / "d" / "e" / "f" >=20 > If both cases are to be supported, the upper case letters need to be > added to the ABNF to permit them. >=20 > Section 4.2 says: >=20 > ...=20 > 64-bit identifier that consists of 8 byte family code, 48 bit > identifier unique within a family, and 8 bit CRC code [OW]. >=20 > The math does not work. I suspect: s/8 byte/8 bit/ >=20 > Section 6 says: >=20 > ... An implementation of the DEV URN MUST NOT > change these properties from what they were intended. >=20 > It is not clear to me the meaning of "they" in this sentence. > Please clarify. >=20 >=20 > Minor Concerns: >=20 > Section 3.2 says: >=20 > DEV URNs do not use r-, q-, or f-components. >=20 > I would have liked a bit more context here. I suggest: >=20 > DEV URNs do not use r-, q-, or f-components as defined in = [RFC8141]. >=20 > Section 3.2.1 refers to "BASE64". Please add an informative reference > to RFC 4648 to be clear. >=20 > Section 4.1 uses the term "Ethernet" in two places. I think both of > them should be replaced by "MAC-48". >=20 >=20 > Nits: >=20 > Section 3.2 says: >=20 > However, due to the SenML RFC 8428 Section 4.5.1 rules, DEV URNs > do not support percent-encoding. >=20 > This does not seem like a "however" statement to me. Perhaps, it is > a "Note that" statement. Or, just drop "However". >=20 > Section 4.1: s/rests within the IEEE/ > /rests with the IEEE Registration Authority/ >=20 > Section 7 includes: "publicly available specification that can > be pointed to." It is sufficient to say: ""publicly available > specification." >=20 >=20 >=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --Apple-Mail=_C7682BAD-05AB-4FDA-9999-F6AA15CEC64F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Barry:

You = are, of course, correct.  RFC 5234 says:

      = ABNF strings are case insensitive and the character set for = these
      strings is = US-ASCII.

However, that raises a different issue:

  =  The DEV URN syntax allows both upper and lower case characters. =  The
   URN-equivalence of the DEV = URNs is defined per [RFC8141] Section 3.1,
  =  i.e,. two URNs are URN-equivalent if their assigned-name portions = are
   octet-by-octet equal after = applying case normalization to the URI
  =  scheme ("urn") and namespace identifier ("dev").

So, the ABNF should be = changed so that the "mac:", "ow:", "org:", "os:", = and "ops:" are required to be lowercase.  I guess that means = replacing each letter with the appropriate value in the %x61-7A = range.  That will not be as easy to read...

Russ


On Jan 6, 2021, at 4:49 PM, Barry Leiba = <barryleiba@computer.org> wrote:

Thanks for the quick review, Russ, and good catches = here.

On one item, though:

> If both = cases are to be supported, the upper case letters need to be
> added to = the ABNF to permit them.


Actually not: quoted = letters in ABNF are case-insensitive, so =E2=80=9Ca=E2=80=9D matches = both lowercase a and uppercase A.

Barry

On Wed, Jan 6, 2021 at 4:41 PM Russ Housley via = Datatracker <noreply@ietf.org> wrote:
Reviewer: Russ Housley
Review result: Almost Ready

I reviewed this document as part of the IoT Directorate's effort to
IoT-related IETF documents being processed by the IESG.  These = comments
were written primarily for the benefit of the Internet Area = Directors.
Document authors, document editors, and WG chairs should treat these
comments just like any other IETF Last Call comments.

Document: draft-ietf-core-dev-urn-09
Reviewer: Russ Housley
Review Date: 2021-01-06
IETF LC End Date: 2020-12-02
IESG Telechat date: 2021-01-21


A review from the IoT Directorate was requested on 2021-01-05, which = is
after the IETF Last Call ended.  I assume that the Internet ADs = want
this review to help inform them during IESG Evaluation.


Summary: Almost Ready


Major Concerns:

Section 3.2 says:

   The optional underscore-separated components following the = hexstring
   are strings depicting individual aspects of a device.

Not all of the DEV URN forms contain a hexstring; however, all of = them
are allowed to end with underscore-separated components.  I = suggest:

   The optional underscore-separated components at the end of = the
   DEV URN depict individual aspects of a device.
=
Section 3.2.1 says:

   ... and a MAC address could be represented either with
   uppercase or lowercase hexadecimal digits.

This is not allowed by the ABNF:

   hexstring =3D 1*(hexdigit hexdigit)
   hexdigit =3D DIGIT / "a" / "b" / "c" / "d" / "e" / "f"

If both cases are to be supported, the upper case letters need to be
added to the ABNF to permit them.

Section 4.2 says:

   ...
   64-bit identifier that consists of 8 byte family code, 48 = bit
   identifier unique within a family, and 8 bit CRC code = [OW].

The math does not work.  I suspect: s/8 byte/8 bit/

Section 6 says:

   ... An implementation of the DEV URN MUST NOT
   change these properties from what they were intended.

It is not clear to me the meaning of "they" in this sentence.
Please clarify.


Minor Concerns:

Section 3.2 says:

   DEV URNs do not use r-, q-, or f-components.

I would have liked a bit more context here.  I suggest:

   DEV URNs do not use r-, q-, or f-components as defined in = [RFC8141].

Section 3.2.1 refers to "BASE64".  Please add an informative = reference
to RFC 4648 to be clear.

Section 4.1 uses the term "Ethernet" in two places.  I think both = of
them should be replaced by "MAC-48".


Nits:

Section 3.2 says:

   However, due to the SenML RFC 8428 Section 4.5.1 rules, DEV = URNs
   do not support percent-encoding.

This does not seem like a "however" statement to me.  Perhaps, it = is
a "Note that" statement.  Or, just drop "However".

Section 4.1: s/rests within the IEEE/
              /rests with the IEEE = Registration Authority/

Section 7 includes: "publicly available specification that can
be pointed to."  It is sufficient to say: ""publicly available
specification."



--
last-call mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call

= --Apple-Mail=_C7682BAD-05AB-4FDA-9999-F6AA15CEC64F-- From nobody Thu Jan 7 05:31:11 2021 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 EA1B93A0A21; Thu, 7 Jan 2021 05:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CLQFKbbIrOv; Thu, 7 Jan 2021 05:31:09 -0800 (PST) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) (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 8B9E83A09D7; Thu, 7 Jan 2021 05:31:09 -0800 (PST) Received: by mail-lf1-f47.google.com with SMTP id o10so3637748lfl.13; Thu, 07 Jan 2021 05:31:09 -0800 (PST) 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=vpUvXqO/WbNJOaK8b8ficGQfDN2NlWa37tcdnz9jN3c=; b=crUkgMSLotbIuPURdF4YwgbbHlJDjzk24pYcy3E1vP3VUiC69tjISnDZA+Vhypmq+W mJanbnFQRfPeU5RtXa2Gw1ufOdha2kJ+iPpp6gKd6V4iLdQuIInUb7R5HnaXpnG7NAkg IlHPYWlga+YeYQvn/B8zKqFqSOJeLpAyVrUPaJiDAg+Qol8AfcAf6VoFIilu7Hea0m3J XOsX6wX66LVt4hy913c25aDma8p/2Cz/rktHpoGWyQnCn9/INl0dMTubE3CV8fnALvDo rJqWUbDGz8KT4Qlfmn5k50V85LUTyaRCKMwW5J6YC00kVP6sOfzLtx8FgW3KOFW4LkOZ 1YpA== X-Gm-Message-State: AOAM531wJooSPjrz+OQfAjddfw3h9k4bv+TqiJ3p47/81jEqx4dWXJjf 6+01z7OevW/hTcWy8rAeB8e+lb9KIPK1Uv/fw4rOCqqi X-Google-Smtp-Source: ABdhPJxGdnbluSQv3LooQG5q7s4zVz3gr3+oKc51LJyfT+tThWPA8joLwwbsZ5+gin21gCW1st8wR65D1me6o7lFbIs= X-Received: by 2002:a05:651c:316:: with SMTP id a22mr3950983ljp.473.1610026267494; Thu, 07 Jan 2021 05:31:07 -0800 (PST) MIME-Version: 1.0 References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Thu, 7 Jan 2021 08:30:56 -0500 Message-ID: To: Russ Housley Cc: "iot-directorate@ietf.org" , draft-ietf-core-dev-urn.all@ietf.org, core WG , last-call@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 07 Jan 2021 13:31:11 -0000 > You are, of course, correct. RFC 5234 says: > > ABNF strings are case insensitive and the character set for these > strings is US-ASCII. > > However, that raises a different issue: > > The DEV URN syntax allows both upper and lower case characters. The > URN-equivalence of the DEV URNs is defined per [RFC8141] Section 3.1, > i.e,. two URNs are URN-equivalent if their assigned-name portions are > octet-by-octet equal after applying case normalization to the URI > scheme ("urn") and namespace identifier ("dev"). > > So, the ABNF should be changed so that the "mac:", "ow:", "org:", "os:", and "ops:" are required to > be lowercase. I guess that means replacing each letter with the appropriate value in the %x61-7A > range. That will not be as easy to read... Not if it's done that way, indeed. But RFC 7405 helps us here. Barry From nobody Thu Jan 7 05:39:30 2021 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 60ADF3A1168 for ; Thu, 7 Jan 2021 05:39:25 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xf9U0EczZfd for ; Thu, 7 Jan 2021 05:39:24 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC9D3A1108 for ; Thu, 7 Jan 2021 05:39:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A6EF5300BD1 for ; Thu, 7 Jan 2021 08:33:14 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YvaPkB7iWYBl for ; Thu, 7 Jan 2021 08:33:12 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 505C8300AE5; Thu, 7 Jan 2021 08:33:12 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: Date: Thu, 7 Jan 2021 08:33:13 -0500 Cc: "iot-directorate@ietf.org" , draft-ietf-core-dev-urn.all@ietf.org, core WG , last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 07 Jan 2021 13:39:29 -0000 Barry: >> You are, of course, correct. RFC 5234 says: >>=20 >> ABNF strings are case insensitive and the character set for = these >> strings is US-ASCII. >>=20 >> However, that raises a different issue: >>=20 >> The DEV URN syntax allows both upper and lower case characters. = The >> URN-equivalence of the DEV URNs is defined per [RFC8141] Section = 3.1, >> i.e,. two URNs are URN-equivalent if their assigned-name portions = are >> octet-by-octet equal after applying case normalization to the URI >> scheme ("urn") and namespace identifier ("dev"). >>=20 >> So, the ABNF should be changed so that the "mac:", "ow:", "org:", = "os:", and "ops:" are required to >> be lowercase. I guess that means replacing each letter with the = appropriate value in the %x61-7A >> range. That will not be as easy to read... >=20 > Not if it's done that way, indeed. But RFC 7405 helps us here. Indeed, I forgot about RFC 7405. Much better solution. Russ From nobody Thu Jan 7 10:50:51 2021 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 4C8C73A0A4D; Thu, 7 Jan 2021 10:50:50 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 xcxb2M4jJ0b1; Thu, 7 Jan 2021 10:50:48 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3363A0A4C; Thu, 7 Jan 2021 10:50:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C8D2D6601E3; Thu, 7 Jan 2021 20:50:46 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nut7jjd9-H5L; Thu, 7 Jan 2021 20:50:43 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id D379A66012A; Thu, 7 Jan 2021 20:50:43 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <160996930502.21827.5533521556349871834@ietfa.amsl.com> Date: Thu, 7 Jan 2021 20:50:43 +0200 Cc: iot-directorate@ietf.org, core@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7BE43FEF-DA33-4B40-9DA7-E646C60CB600@piuha.net> References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> To: Russ Housley X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 07 Jan 2021 18:50:50 -0000 Many thanks for your very useful review, Russ! Some discussion inline, but I have a set of tentative changes at = https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--09.diff.html I plan to submit a new version, as soon as I=E2=80=99ve gone through the = new full thread. The changes so far only relate to your comments, Russ. > Section 3.2 says: >=20 > The optional underscore-separated components following the hexstring > are strings depicting individual aspects of a device. >=20 > Not all of the DEV URN forms contain a hexstring; however, all of them > are allowed to end with underscore-separated components. I suggest: >=20 > The optional underscore-separated components at the end of the > DEV URN depict individual aspects of a device. Yes. I changed this. > Section 3.2.1 says: >=20 > ... and a MAC address could be represented either with > uppercase or lowercase hexadecimal digits. >=20 > This is not allowed by the ABNF: >=20 > hexstring =3D 1*(hexdigit hexdigit) > hexdigit =3D DIGIT / "a" / "b" / "c" / "d" / "e" / "f" >=20 > If both cases are to be supported, the upper case letters need to be > added to the ABNF to permit them. As pointed out by Barry, this is indeed possible. I=E2=80=99m not = entirely sure how necessary it was to restrict the subtypes to lower = case =E2=80=94 RFC 8141 is clear that types can be both cases =E2=80=94 = but I=E2=80=99ve tentatively done that. > Section 4.2 says: >=20 > ...=20 > 64-bit identifier that consists of 8 byte family code, 48 bit > identifier unique within a family, and 8 bit CRC code [OW]. >=20 > The math does not work. I suspect: s/8 byte/8 bit/ Good catch! Corrected. > Section 6 says: >=20 > ... An implementation of the DEV URN MUST NOT > change these properties from what they were intended. >=20 > It is not clear to me the meaning of "they" in this sentence. > Please clarify. I made a small change, but I=E2=80=99m not sure how else to express = this. We are talking about whether identifiers are modifiable for = instance. The whole paragraph reads now: On most devices, the user can display device identifiers. Depending on circumstances, device identifiers may or may not be modified or tampered with by the user. An implementation of the DEV URN MUST NOT = change such limitations or behaviour from what they were intended. In = particular, a device identifier that is intended to be immutable should not become mutable as a part of implementing the DEV URN type. More generally, nothing in this document should be construed to override what the relevant device specifications have already said about the identifiers. > DEV URNs do not use r-, q-, or f-components. >=20 > I would have liked a bit more context here. I suggest: >=20 > DEV URNs do not use r-, q-, or f-components as defined in [RFC8141]. That would be good. Changed. > Section 3.2.1 refers to "BASE64". Please add an informative reference > to RFC 4648 to be clear. Good idea. Done. > Section 4.1 uses the term "Ethernet" in two places. I think both of > them should be replaced by "MAC-48=E2=80=9D. Right. Done. > Nits: >=20 > Section 3.2 says: >=20 > However, due to the SenML RFC 8428 Section 4.5.1 rules, DEV URNs > do not support percent-encoding. >=20 > This does not seem like a "however" statement to me. Perhaps, it is > a "Note that" statement. Or, just drop "However=E2=80=9D. Ok (I have not yet considered John=E2=80=99s comments). > Section 4.1: s/rests within the IEEE/ > /rests with the IEEE Registration Authority/ Thanks. > Section 7 includes: "publicly available specification that can > be pointed to." It is sufficient to say: ""publicly available > specification.=E2=80=9D Ok. Changed. Jari From nobody Thu Jan 7 12:44:15 2021 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 E597C3A0E84 for ; Thu, 7 Jan 2021 12:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 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, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=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=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OVBLA-2AIRz for ; Thu, 7 Jan 2021 12:44:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 02CB83A0E83 for ; Thu, 7 Jan 2021 12:44:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1610052241; bh=f/XH/SlxQixz65S7KropuLvM4rJpr/ndYl2Dlz3XugM=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Zj8APYuHt1g9mYHvH0kHPi4+8LS4vlQ0vPIOGyegKjGX9pezE8VnnCmL8rZynJ/fK v+5KCA5evALZ+vuXyRQRKG1QZWLk8GkI6dcLbK9djE00nDQz9rBG/5K4sOb8VeezBl 3sMrFeH/2u/XP7NaeWiR+UHkcATW4QJIqKRwe9/I= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.100] ([178.2.229.186]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MuUj2-1k6KlG3kbi-00rZY8; Thu, 07 Jan 2021 21:44:01 +0100 To: Carsten Bormann Cc: "core@ietf.org" , Simon Bernard References: <189d3f1e-9c83-b1c7-d8a1-7f195265bd2d@gmx.net> From: Achim Kraus Message-ID: <3560ba6c-9840-653a-bfb6-2685142c0988@gmx.net> Date: Thu, 7 Jan 2021 21:44:00 +0100 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:oZ0kJ3HH9vWp39ZTSguDV2Ifp6TEPi+uL/MFrPfkeuaEjpjBzYA HcwOD+0fduWJ1POqrjgvODTw1VMk7Mu1pA57EIUYo1CG1EeuWuHmqZYEwHV10us/optLaaa CXV0+ZIGLp3uvSN1WyDSckp5+SoKh/AL86a2iR1hYd9r+61YifXMh/Ai34NRXj8a4XPB0gh T1+rcKLxjOP5oA7tDm/kw== X-UI-Out-Filterresults: notjunk:1;V03:K0:w2v1mBKKsKI=:kcB37mVjwGvny/hORaF14w /MOt8q3a3/GN32zxzMUgxwSNWXw/vsoVQZODurVGiI1xnSHdWypen+mb2j2qIweveW7KdtnM2 IUHXTqevMcCiHiRhEXe1fmlPWjZS2keCbg+gVeBxYBFUMLPqgKiIY9uh8BoktY7tKynY6Yagc ioLsQ0fgA++sX+j4wThdzNYlzhb31Wvh9KJdBc79cABIXv9Gz45I2/M6ueOhiNOCUd9niI6Nn Y1QFIR/hXXx4lDVw32fKPwvCsO2VWaETRqoYgoFtiwJtCStyUtmCrUjv8CV9BNOPkx6WvXIez UdTA7E67HVbDTXR0Xj3J9RtSoklwQpyathU7Rx7225bjGnbD9/PzDpqUt/yQVWr/kMIL+7mY1 VnLRpluUxXo16nl0hh+X+Efc49C715j0x3Ir8SxIxcNCuO4LOTCxRJiwuNLG6C6AIIaaoPN/4 s58V4sbH+I+XHXrvjqJ8lBODvouZu7+u6qQkgn5j8a6mbzneMDkRIUvLx4Qp5t9H7teGXZ/k9 M9MF9M79JdmVrPzUjLLG1qfIXL2h3LKen4LmircMSCfX3wIcVrkkAvGIgaEDHyxuA2ohBTWVK sxmZNCX8tCXDeTq556N7nKs0X1nJHrdqsFIwbTU4PYEQg6nLmtqUa5HeLNR6p7i+gskSAXroS I5T97hdsijr8e6Jr9zaGBrqJDOB63SlgKPpdxwlfL6D4GlWBetkNpUuu5pcoon7ZI4mqxFqsS b4HpeExEQcL2uXoliF2nnkYiTtCWwi3U3PY7T+qoQq2unslUAxtn27Q0SdH7IwNakKF8l/sHg EpZEmH0akEKhJcmxywOi64Ahdi/3NTbDGbN4ZT0ihC17mmlbCLsvPUFXLEQQK06PYL63G4ffS HU8mifMkzEkX7N6MEgOA== Archived-At: Subject: Re: [core] block1 size negotiation with 4.13 Request Entity Too Large 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, 07 Jan 2021 20:44:14 -0000 Hi Carsten Hi List, sorry for that late follow up of that question from last summer. Currently I try to cleanup that code in Californium. Doing so, I'm not sure, what the intended behaviour in the following scenario should be: - the client starts with a request "GET block2(num=3D5, size=3D256)". - the server is configured to send blocks only up to 64 bytes. If that exchange would happen at num=3D0, it works fine to send just a smaller response, but with "num=3D5", I'm not sure, what is intended. So, does this result in: - the server respond with "CONTENT block2(num=3D?, size=3D64)" the issue with that is in my opinion, that either the "num" must be changed, or the offset can not longer calculated by option.num * option.size. To change the "num" may cause issues, though that "num" seems to be used to ACK the blocks. - the server respond with an error; but which one should be used? best regards Achim Am 22.07.20 um 15:23 schrieb Carsten Bormann: > On 2020-07-22, at 15:20, Achim Kraus wrote: >> >> Hi Carsten, >> >> thanks a lot! >> >>> So it is not forbidden to request a smaller block size later. >> >> My point is, >> - was this intented or >> - just not considered and therefore not explicitly forbidden? > > This was intended. A Stateless server may simply not know what it did b= efore. It might of course simply give up if the block number is =E2=89=A0= 0, but we gave it a little more freedom, at the cost of maybe causing a b= it more coding for clients that want to cope with these highly stateless s= ervers. > >> All examples and some text points more into the direction, that it is >> intended to be negotiated only in the 1. exchange. I'm still not >> convinced, I think to forbid this is the better approach. > > I don=E2=80=99t know why the server would keep its preferences secret up= to a few blocks into the transfer unless it is of the above kind and face= s a sudden resource shortage. > > Gr=C3=BC=C3=9Fe, Carsten > > >> >> Sure, if no-one else has doubts, go for it. >> >> best regards >> Achim Kraus >> >> Am 22.07.20 um 13:08 schrieb Carsten Bormann: >>> Hi Achim, >>> >>> Good questions. >>> >>>> On 2020-07-22, at 09:56, Achim Kraus wrote: >>>> >>>> Dear list, >>>> >>>> I would really appreciate, if the detail questions about the 4.13 >>>> failover could be answered! >>>> >>>> Without answers, I'm still afraid, that implementations will became >>>> "overcomplicated" and "less interoperable". >>>> >>>> 1. is it intended to change the block size only in the first exchange= ? >>>> Or on other exchanges? (Additionally, if changing later is considered= as >>>> failure, how should that failure be handled/processed?) >>> >>> RFC 7959 says (Section 2): >>> >>> In most cases, all blocks being transferred for a body (except for >>> the last one) will be of the same size. (If the first request use= s a >>> bigger block size than the receiver prefers, subsequent requests w= ill >>> use the preferred block size.) The block size is not fixed by the >>> protocol. [=E2=80=A6] >>> >>> Simon cited some more text, but this is about too many blocks, not abo= ut too big blocks. So it is not forbidden to request a smaller block size= later. I would expect that this is a rather unusual case, so I would not= be surprised if a client gives up if this happens in mid-transfer. On th= e other hand, it is also not hard to enable a client to adapt. >>> >>>> 2. is it intended, that a 4.13 response without block1 option to a >>>> request also without block1 option, should also use/try a failover wi= th >>>> a request with block 1 option? >>> >>> That=E2=80=99s what RFC 7959 says: >>> >>> The error code 4.13 (Request Entity Too Large) can be returned at = any >>> time by a server that does not currently have the resources to sto= re >>> blocks for a block-wise request payload transfer that it would int= end >>> to implement in an atomic fashion. (Note that a 4.13 response to = a >>> request that does not employ Block1 is a hint for the client to tr= y >>> sending Block1, and a 4.13 response with a smaller SZX in its Bloc= k1 >>> Option than requested is a hint to try a smaller SZX.) >>> >>> This is phrased as a note, because the response contains a hint; there= is no requirement that Block1 is supported. >>> >>> Simon also asked: >>> >>>> 2) What exactly should send the server ? 4.13 or 4.13 + block1 wit= h szx option ? is size1 should be used to guess the correct block size ? >>> >>> I would expect that the server should send the desired block size if i= t wants the client to change from the block size it used, so 4.13 + Block1= . Size1 is not about block size, but about the size of the whole body - i= f the server has a limitation there, it might want to error out on a 4.13 = (without a Block1 option). >>> >>> Gr=C3=BC=C3=9Fe, Carsten >>> >> > From nobody Thu Jan 7 13:04:12 2021 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 4A52C3A0EC3 for ; Thu, 7 Jan 2021 13:04: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 qtmrOxINkZrX for ; Thu, 7 Jan 2021 13:04:08 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 41EAC3A0EC0 for ; Thu, 7 Jan 2021 13:04:08 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kxcRx-0002zI-NK; Thu, 07 Jan 2021 21:04:05 +0000 From: To: "Achim Kraus" , "'Carsten Bormann'" Cc: References: <189d3f1e-9c83-b1c7-d8a1-7f195265bd2d@gmx.net> <3560ba6c-9840-653a-bfb6-2685142c0988@gmx.net> In-Reply-To: <3560ba6c-9840-653a-bfb6-2685142c0988@gmx.net> Date: Thu, 7 Jan 2021 21:04:19 -0000 Message-ID: <034801d6e538$aa42eb90$fec8c2b0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMnlbxFyzt/r52kzVIQGv204oQK2gHfla+WAW4JaswBo0oYDwOTXO8KAeLEH4unKA1dwA== Content-Language: en-gb Archived-At: Subject: Re: [core] block1 size negotiation with 4.13 Request Entity Too Large 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, 07 Jan 2021 21:04:10 -0000 Hi Achim, It is my understanding that CONTENT block2(num=3D5, size=3D256) CONTENT block2(num=3D20, size=3D64) Are equivalent as they both define the same offset into the data, and so = returning " CONTENT block2(num=3D20, size=3D64)" is valid for your = example. Regards Jon > -----Original Message----- > From: Achim Kraus [mailto:ietf-supjps-achimkraus@gmx.net] > Sent: 07 January 2021 20:44 > To: Carsten Bormann > Cc: core@ietf.org > Subject: Re: [core] block1 size negotiation with 4.13 Request Entity = Too > Large >=20 > Hi Carsten > Hi List, >=20 > sorry for that late follow up of that question from last summer. > Currently I try to cleanup that code in Californium. > Doing so, I'm not sure, what the intended behaviour in the following > scenario should be: > - the client starts with a request "GET block2(num=3D5, size=3D256)". > - the server is configured to send blocks only up to 64 bytes. >=20 > If that exchange would happen at num=3D0, it works fine to send just a > smaller response, but with "num=3D5", I'm not sure, what is intended. > So, does this result in: >=20 > - the server respond with "CONTENT block2(num=3D?, size=3D64)" > the issue with that is in my opinion, that either the "num" must > be changed, or the offset can not longer calculated by > option.num * option.size. To change the "num" may cause issues, > though that "num" seems to be used to ACK the blocks. >=20 > - the server respond with an error; but which one should be used? >=20 > best regards > Achim >=20 > Am 22.07.20 um 15:23 schrieb Carsten Bormann: > > On 2020-07-22, at 15:20, Achim Kraus wrote: > >> > >> Hi Carsten, > >> > >> thanks a lot! > >> > >>> So it is not forbidden to request a smaller block size later. > >> > >> My point is, > >> - was this intented or > >> - just not considered and therefore not explicitly forbidden? > > > > This was intended. A Stateless server may simply not know what it = did > before. It might of course simply give up if the block number is = =E2=89=A0 0, but we > gave it a little more freedom, at the cost of maybe causing a bit more = coding > for clients that want to cope with these highly stateless servers. > > > >> All examples and some text points more into the direction, that it = is > >> intended to be negotiated only in the 1. exchange. I'm still not > >> convinced, I think to forbid this is the better approach. > > > > I don=E2=80=99t know why the server would keep its preferences = secret up to a few > blocks into the transfer unless it is of the above kind and faces a = sudden > resource shortage. > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > >> > >> Sure, if no-one else has doubts, go for it. > >> > >> best regards > >> Achim Kraus > >> > >> Am 22.07.20 um 13:08 schrieb Carsten Bormann: > >>> Hi Achim, > >>> > >>> Good questions. > >>> > >>>> On 2020-07-22, at 09:56, Achim Kraus wrote: > >>>> > >>>> Dear list, > >>>> > >>>> I would really appreciate, if the detail questions about the 4.13 > >>>> failover could be answered! > >>>> > >>>> Without answers, I'm still afraid, that implementations will = became > >>>> "overcomplicated" and "less interoperable". > >>>> > >>>> 1. is it intended to change the block size only in the first = exchange? > >>>> Or on other exchanges? (Additionally, if changing later is = considered as > >>>> failure, how should that failure be handled/processed?) > >>> > >>> RFC 7959 says (Section 2): > >>> > >>> In most cases, all blocks being transferred for a body (except = for > >>> the last one) will be of the same size. (If the first request = uses a > >>> bigger block size than the receiver prefers, subsequent = requests will > >>> use the preferred block size.) The block size is not fixed by = the > >>> protocol. [=E2=80=A6] > >>> > >>> Simon cited some more text, but this is about too many blocks, not > about too big blocks. So it is not forbidden to request a smaller = block size > later. I would expect that this is a rather unusual case, so I would = not be > surprised if a client gives up if this happens in mid-transfer. On = the other > hand, it is also not hard to enable a client to adapt. > >>> > >>>> 2. is it intended, that a 4.13 response without block1 option to = a > >>>> request also without block1 option, should also use/try a = failover with > >>>> a request with block 1 option? > >>> > >>> That=E2=80=99s what RFC 7959 says: > >>> > >>> The error code 4.13 (Request Entity Too Large) can be returned = at any > >>> time by a server that does not currently have the resources to = store > >>> blocks for a block-wise request payload transfer that it would = intend > >>> to implement in an atomic fashion. (Note that a 4.13 response = to a > >>> request that does not employ Block1 is a hint for the client = to try > >>> sending Block1, and a 4.13 response with a smaller SZX in its = Block1 > >>> Option than requested is a hint to try a smaller SZX.) > >>> > >>> This is phrased as a note, because the response contains a hint; = there is > no requirement that Block1 is supported. > >>> > >>> Simon also asked: > >>> > >>>> 2) What exactly should send the server ? 4.13 or 4.13 + block1 = with szx > option ? is size1 should be used to guess the correct block size ? > >>> > >>> I would expect that the server should send the desired block size = if it > wants the client to change from the block size it used, so 4.13 + = Block1. > Size1 is not about block size, but about the size of the whole body - = if the > server has a limitation there, it might want to error out on a 4.13 = (without a > Block1 option). > >>> > >>> Gr=C3=BC=C3=9Fe, Carsten > >>> > >> > > >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Jan 7 13:16:18 2021 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 DFCD43A0EED for ; Thu, 7 Jan 2021 13:16:17 -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 BmcLhcLxGlOt for ; Thu, 7 Jan 2021 13:16:14 -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 D42333A0D2A for ; Thu, 7 Jan 2021 13:16:13 -0800 (PST) Received: from [192.168.217.118] (p548dc939.dip0.t-ipconnect.de [84.141.201.57]) (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 4DBfDB4gBKzyVj; Thu, 7 Jan 2021 22:16: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: <3560ba6c-9840-653a-bfb6-2685142c0988@gmx.net> Date: Thu, 7 Jan 2021 22:16:10 +0100 Cc: "core@ietf.org" , Simon Bernard X-Mao-Original-Outgoing-Id: 631746969.944153-3c0b443ad5a1f1e09983bc1d0a8e30d2 Content-Transfer-Encoding: quoted-printable Message-Id: References: <189d3f1e-9c83-b1c7-d8a1-7f195265bd2d@gmx.net> <3560ba6c-9840-653a-bfb6-2685142c0988@gmx.net> To: Achim Kraus X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] block1 size negotiation with 4.13 Request Entity Too Large 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, 07 Jan 2021 21:16:18 -0000 Hi Achim, On 2021-01-07, at 21:44, Achim Kraus wrote: >=20 > Hi Carsten > Hi List, >=20 > sorry for that late follow up of that question from last summer. > Currently I try to cleanup that code in Californium. > Doing so, I'm not sure, what the intended behaviour in the following > scenario should be: > - the client starts with a request "GET block2(num=3D5, size=3D256)". The operative word here is =E2=80=9Cstarts with=E2=80=9D. So this is the first time the server has a chance to react to the = proposed block size. Section 2 of RFC 7959 says: In most cases, all blocks being transferred for a body (except for the last one) will be of the same size. (If the first request uses a bigger block size than the receiver prefers, subsequent requests will use the preferred block size.) The block size is not fixed by the = [=E2=80=A6] This talks about the =E2=80=9Cfirst request=E2=80=9D, which could be = read as meaning =E2=80=9Cnum=3D0=E2=80=9D, but in this case clearly = matches the premise. > - the server is configured to send blocks only up to 64 bytes. >=20 > If that exchange would happen at num=3D0, it works fine to send just a > smaller response, but with "num=3D5", I'm not sure, what is intended. > So, does this result in: >=20 > - the server respond with "CONTENT block2(num=3D?, size=3D64)" > the issue with that is in my opinion, that either the "num" must > be changed, or the offset can not longer calculated by > option.num * option.size. To change the "num" may cause issues, > though that "num" seems to be used to ACK the blocks. I don=E2=80=99t know of any issues that the change in =E2=80=9Cnum=E2=80=9D= would cause. =E2=80=9CNum=E2=80=9D is just a terse encoding for the current byte = position (*), based on =E2=80=9Cszx=E2=80=9D, and when szx changes, num = has to change in unison. (Jon is right that, with the size divided by four, the num needs to be = multiplied by four to start filling in the right byte position(**).) > - the server respond with an error; but which one should be used? Since the protocol has been designed to enable stateless servers, we = didn=E2=80=99t see a need to provide an error that a stateless server = would never know what to use for. Gr=C3=BC=C3=9Fe, Carsten (*) Well, that is just given as an =E2=80=9CImplementation note=E2=80=9D = in Section 2.2, but I would expect a sane implementation to follow this = note. (**) A prank implementation might try to fill in num=3D23 for size=3D64, = as this is also part of the block 5 at size 256. I don=E2=80=99t think = that this behavior would be justifiable, as the case for num=3D0 clearly = fills in the leftmost block. From nobody Thu Jan 7 13:42:58 2021 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 749793A00F7 for ; Thu, 7 Jan 2021 13:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 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, NICE_REPLY_A=-0.262, RCVD_IN_DNSWL_BLOCKED=0.001, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEQtsjv7VnAb for ; Thu, 7 Jan 2021 13:42:55 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 A5A0E3A00E0 for ; Thu, 7 Jan 2021 13:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1610055759; bh=+AvUR+0pgTwwMefzEHaDnBFBvYPwDw7RVXHHMfcIqOc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Vx63gJVzGxK5pxqMpNX9dTG1g1couUkx2E8k3YVygpAlrr/z+fqOCeTsik1UMvjDI eoVWQtDGYnJ6zAwB3MVMTiuSEOzWpjJgweqy8tvUKJSjm2fgUgGiy4VMddbqo3tTvh V4hc/beBS0SOUq01dfRiz+WX5uYaXHx2GUa2f7YQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.100] ([178.2.229.186]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M1Hdw-1kzI0b1fII-002ntD; Thu, 07 Jan 2021 22:42:39 +0100 To: Carsten Bormann , jon.shallow@jpshallow.com Cc: "core@ietf.org" , Simon Bernard References: <189d3f1e-9c83-b1c7-d8a1-7f195265bd2d@gmx.net> <3560ba6c-9840-653a-bfb6-2685142c0988@gmx.net> From: Achim Kraus Message-ID: <3558e7a7-4252-4fe5-ed6e-fbfaa7b72bf3@gmx.net> Date: Thu, 7 Jan 2021 22:42:38 +0100 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:3kxU/Mb+K9ckVR/lWGe3oIIerWXGd8azGdga2s4wtfdPif6qXnk 6MohnY57NiW1uDyZd3ux4ktXREHQ0Yp/8XIbe6DFnf2uPmUXQaZ/CZsiOOLdxE8PFXxA0na gPZ6Gy5QH2I3Roc6yzO258acMet2Z4f+2h/srgk9ha7WTr48ZxykMTJeG1phy89TeTxTw11 /0RG559LFBdCTITnj8xww== X-UI-Out-Filterresults: notjunk:1;V03:K0:t434HiMRzQg=:Win1IgE/wbny2jm5utZua8 q2AYMSmTc51z5ULzvC/y5CFn5lgt+nlPKFJqel0pGK3+DoqcSCVQ03HA93b1kxgBKBLjWopCB D8xhfsEjYI8DJWVEEJAWI0imAYK/ABBwU0qYuK8/Y8UhqinCtx68tkp51f1W5OeKfXp4FstpV ibDcovLGeIL5lN5nchL2AuzJfcitKo3dPXXqIHcBE0dY2VEloldufxEkU9JQAUFHPICT1YcFT SaHMpQnLU4L0RtpI6H5Y/+abTqhDK0L6Ff8gRdc6mWJay8mbYZf0f0WiRqdTBFoIXaRd2v9iW r+GDVo+jk/+oa+p4Jou5wNE9Kx/tFWmb/SW2o5Pqdszj+T5x79iEYFb02jYKtwy3xL3T2mbBY ddZHFoIos6JF7PBTl9Jhq0jWcpVgpzXGVOhd56nybY1ZsgqgaykPJ9cUtsWcmwxRqejbwWSkW dZISwj/gC8Pp0bXk3ag/6V14u3q8CfB70UCbwD9GBzAd/F2cG/2MIfsXNKd8TY912UMVzsXYV bUMgvQIIEUWVsUh0HAUvSTnOUENrgBja3eXkkrUsto/Z5GEqFwbxCJP0jNl8B0bDlZ4TMqx6a zf3zkppneF7nNbbD9GZSKV3T9njHaoNEMwqfMPKeKwwv5LbMnq5pELXP6V1Lux+6tJE/8t93e EDgkNOqWAJK53NX0gvCIb+tzRBOCQa5alwGctgwZteiiUJwPx/gYLkBCcjjnEabznHBq9+X4/ 6DaULX2X3kEhl7JItswe2qmntmlqjz4UmnjrXGvmod17EjS2wkukIrRxF1RbeyD3tXVfexCE3 fdHoaJTwZKZ+rp8vODZwX6machK9R2hOiLmbu21Rpmo/0C00nEDAcEKNlV8YoRulAROE/Hm6o KWtviYWKkvoGHJOomTTQ== Archived-At: Subject: Re: [core] block1 size negotiation with 4.13 Request Entity Too Large 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, 07 Jan 2021 21:42:57 -0000 Hi Jon, Hi carsten, thanks for the fast answers! So, changing the block-number to compensate a blocksize change, is the intended behavior. > I don=E2=80=99t know of any issues that the change in =E2=80=9Cnum=E2= =80=9D would cause. That may depend on the interpretation of, RFC 7959, 2.3. Block Options in Requests and Responses Block 2 / Request "The NUM field in the Block2 Option gives the block number of the payload that is being requested to be returned in the response." The interpretation may be, either - the requested "block number" is to be returned in the response, or - the payload of the request block is to be returned. best regards Achim Am 07.01.21 um 22:16 schrieb Carsten Bormann: > Hi Achim, > > On 2021-01-07, at 21:44, Achim Kraus wrote: >> >> Hi Carsten >> Hi List, >> >> sorry for that late follow up of that question from last summer. >> Currently I try to cleanup that code in Californium. >> Doing so, I'm not sure, what the intended behaviour in the following >> scenario should be: >> - the client starts with a request "GET block2(num=3D5, size=3D256)". > > The operative word here is =E2=80=9Cstarts with=E2=80=9D. > So this is the first time the server has a chance to react to the propos= ed block size. > > Section 2 of RFC 7959 says: > > In most cases, all blocks being transferred for a body (except for > the last one) will be of the same size. (If the first request uses = a > bigger block size than the receiver prefers, subsequent requests wil= l > use the preferred block size.) The block size is not fixed by the [= =E2=80=A6] > > This talks about the =E2=80=9Cfirst request=E2=80=9D, which could be rea= d as meaning =E2=80=9Cnum=3D0=E2=80=9D, but in this case clearly matches t= he premise. > >> - the server is configured to send blocks only up to 64 bytes. >> >> If that exchange would happen at num=3D0, it works fine to send just a >> smaller response, but with "num=3D5", I'm not sure, what is intended. >> So, does this result in: >> >> - the server respond with "CONTENT block2(num=3D?, size=3D64)" >> the issue with that is in my opinion, that either the "num" must >> be changed, or the offset can not longer calculated by >> option.num * option.size. To change the "num" may cause issues, >> though that "num" seems to be used to ACK the blocks. > > I don=E2=80=99t know of any issues that the change in =E2=80=9Cnum=E2=80= =9D would cause. > =E2=80=9CNum=E2=80=9D is just a terse encoding for the current byte posi= tion (*), based on =E2=80=9Cszx=E2=80=9D, and when szx changes, num has to= change in unison. > (Jon is right that, with the size divided by four, the num needs to be m= ultiplied by four to start filling in the right byte position(**).) > >> - the server respond with an error; but which one should be used? > > Since the protocol has been designed to enable stateless servers, we did= n=E2=80=99t see a need to provide an error that a stateless server would n= ever know what to use for. > > Gr=C3=BC=C3=9Fe, Carsten > > (*) Well, that is just given as an =E2=80=9CImplementation note=E2=80=9D= in Section 2.2, but I would expect a sane implementation to follow this n= ote. > > (**) A prank implementation might try to fill in num=3D23 for size=3D64,= as this is also part of the block 5 at size 256. I don=E2=80=99t think t= hat this behavior would be justifiable, as the case for num=3D0 clearly fi= lls in the leftmost block. > From nobody Thu Jan 7 15:06:15 2021 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 B33013A0C93 for ; Thu, 7 Jan 2021 15:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 1jzaoie1IqP9 for ; Thu, 7 Jan 2021 15:06:09 -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 C81A23A0C84 for ; Thu, 7 Jan 2021 15:06:09 -0800 (PST) Received: from [192.168.217.118] (p548dc939.dip0.t-ipconnect.de [84.141.201.57]) (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 4DBhg20cQRzyWY; Fri, 8 Jan 2021 00:06:06 +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: <3558e7a7-4252-4fe5-ed6e-fbfaa7b72bf3@gmx.net> Date: Fri, 8 Jan 2021 00:06:05 +0100 Cc: jon.shallow@jpshallow.com, "core@ietf.org" , Simon Bernard X-Mao-Original-Outgoing-Id: 631753565.349872-99fd89cc99fb2f5095f6b3e85bb344f9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <189d3f1e-9c83-b1c7-d8a1-7f195265bd2d@gmx.net> <3560ba6c-9840-653a-bfb6-2685142c0988@gmx.net> <3558e7a7-4252-4fe5-ed6e-fbfaa7b72bf3@gmx.net> To: Achim Kraus X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] block1 size negotiation with 4.13 Request Entity Too Large 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, 07 Jan 2021 23:06:14 -0000 On 2021-01-07, at 22:42, Achim Kraus wrote: >=20 > RFC 7959, 2.3. Block Options in Requests and Responses >=20 > Block 2 / Request > "The NUM field in the Block2 Option gives the block number of > the payload that is being requested to be returned in the > response." >=20 > The interpretation may be, either > - the requested "block number" is to be returned in the response, or > - the payload of the request block is to be returned. It=E2=80=99s already Friday in Germany, so here goes: http://doi.org/10.1353/lan.2003.0189: Temperley, David. (2003). Ambiguity Avoidance in English Relative = Clauses. Language. 79. 464-484. 10.1353/lan.2003.0189 The mouse the cat the dog chased chased ran (The mouse {that the cat {that the dog chased} chased} ran) I=E2=80=99m so glad I=E2=80=99m not a linguist. So maybe a more practical reference can be found at stackexchange. = https://english.stackexchange.com/questions/140932/ambiguity-in-use-of-rel= ative-pronouns says: "You can use a relative pronoun without ambiguity if you make sure it = immediately follows its antecedent.=E2=80=9D Well, that=E2=80=99s just one, unreferenced opinion, but I think this is = indeed what is meant here (i.e., the =E2=80=9Cpayload=E2=80=9D is the = referent [reference target] of the =E2=80=9Cthat=E2=80=9D.) = https://english.stackexchange.com/questions/169939/more-confusion-with-rel= ative-pronoun-ambiguity can be used to muddy the water by distinguishing = integrated relative clauses from supplementary relative clauses. Since the above is an integrated relative clause (i.e., no comma), the = =E2=80=9Cclosest antecedent=E2=80=9D rule still applies. I=E2=80=99m fully convinced that the author had all this in mind (but = then I=E2=80=99m not sure =F0=9F=A4=94; I wrote that text on = 2012-01-13(**) at 00:06:05, which was exactly nine years minus five days = ago, for draft-ietf-core-block-05, published a few minutes later), and = that the RFC editor later pondered the potential ambiguity carefully and = decided that there wasn=E2=80=99t one. Gr=C3=BC=C3=9Fe, Carsten (**) Which was a Friday, 13th. The commit comment clarifies everything, though:=20 it was the single word =E2=80=9CUff.=E2=80=9D (the German word for = =E2=80=9Cphew=E2=80=9D). From nobody Fri Jan 8 05:33:40 2021 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 D3ADE3A0E88 for ; Fri, 8 Jan 2021 05:33:37 -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 Pk9IGbS6MDSp for ; Fri, 8 Jan 2021 05:33:33 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 01AA93A0E83 for ; Fri, 8 Jan 2021 05:33:32 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kxrtR-0003h2-G2; Fri, 08 Jan 2021 13:33:29 +0000 From: To: "Marco Tiloca" , , Cc: , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> In-Reply-To: Date: Fri, 8 Jan 2021 13:33:42 -0000 Message-ID: <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAFUavWxqLCg4/A= Content-Language: en-gb Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 08 Jan 2021 13:33:38 -0000 Hi Marco, Thanks for this - and it is good to have another set of eyes checking = things through. Updates have been pushed to https://github.com/core-wg/new-block and the = differences with the draft can be found at = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-new-block&url2=3Dhttp= s://raw.githubusercontent.com/core-wg/new-block/master/draft-ietf-core-ne= w-block.txt=20 Otherwise, please see inline. Regards Jon > -----Original Message----- > From: Marco Tiloca [mailto: marco.tiloca@ri.se] > Sent: 07 January 2021 12:17 > To: supjps-ietf@jpshallow.com; christian@amsuess.com; = draft-ietf-core-new- > block@ietf.org > Cc: dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hi, >=20 > Thanks for this revision and for addressing my comments already in > version -03. >=20 > Please, see below some more comments on this version -04. >=20 > Best, > /Marco >=20 >=20 > * s/There are one or more missing CBOR encoded missing block > numbers./There are one or more CBOR encoded missing block numbers. [Jon] Fixed. >=20 >=20 > * Section 4 now includes the new paragraph: "The token to use for the > response SHOULD be the token that was used in the highest block number > received payload. The Q-Block1 Option from the same packet SHOULD be > included." [Jon] The Q-Block1 option actually is not needed as it can be derived by = the client from the remembered token (which is used to derive the = Request-Tag. OLD The Q-Block1 Option from the same packet SHOULD be included. NEW The client will use the token to match the request to find what = Request-Tag value is currently being used. Providing the highest received block number will aid any troubleshooting. >=20 > Consistently, the example in Figure 5 should also have QB1:3/0/1024 = in the > 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08 response > with Token T:0xe4. [Jon] No change now needed. >=20 > Since "SHOULD" is used, when is it still fine or expected to not = include Q- > Block1 in a 4.08 response? [Jon] Q-Block1 is no longer needed. >=20 >=20 > * When commenting the example in Figure 5, Section 9.1 reads: "The = Token > just needs to be one of those that have been received for this = Request-Tag, > so the client can derive the Request-Tag." >=20 > Should this not be aligned with the SHOULD used in Section 4 about = using > the Token from the same packet conveying the highest block number? [Jon] Agreed >=20 > You explained in your mail that the client keeps tracking all = Tokens in the > burst anyway, so maybe it's better to rather align the text in Section = 4 with > what suggested here in Section 9.1, i.e. responding with any of those = Token > values is just fine. [Jon] I think that it is useful for the client to have a hint about what = is the latest block number received even if it does not make use it - it = may help in debugging from packet captures etc. which is why I added in = the SHOULD in section 4. So, I would prefer to align this with section = 4 OLD The Token just needs to be one of those that have been received for this Request-Tag, so the client can derive the Request-Tag. NEW The token used in the response should be the token that was used in the = highest block number received payload. The client can then derive the = Request-Tag by matching the token with the sent request.. >=20 > In such a case, the Q-Block1 option included in the 4.08 response = has still > to be the one from the request conveying the highest block number. > Correct? [Jon] We are now dropping the need for Q-Block1 in the response. >=20 >=20 > * The new text in Section 6.2 says: "... and the situation = re-evaluated for > another 24 hour period until there is no report of missing payloads = under > normal operating conditions." >=20 > When that happens, I suppose MAX_PAYLOADS is right away restored to > the intended value, i.e. it is not incremented by 1 to start another = 24-hour > period evaluation. Correct? [Jon] Updated for clarification OLD report of missing payloads under normal operating conditions. = Note that the CoAP peer will not know about the MAX_PAYLOADS change = until NEW report of missing payloads under normal operating conditions. = The newly derived value for MAX_PAYLOADS should be used for both ends of = this particular CoAP peer link. Note that the CoAP peer will not know about the MAX_PAYLOADS change = until >=20 >=20 > * Section 6.2 says: "The request that the client sends to acknowledge = the > receipt of all the current set of MAX_PAYLOADS payloads SHOULD contain = a > special case Q-Block2 Option with NUM set to the first block of the = next set > of MAX_PAYLOADS payloads and the M bit set to 1." >=20 > Is it possible to reflect this in the example of Figure 6? It would = require the > body to have more than MAX_PAYLOADS blocks thus resulting in more > bursts, which would be inherited by the examples in Figure 7 and = Figure 8. [Jon] Examples updated to include this information >=20 >=20 > * In Section 9, it would be good to have the parameters defined in = Section > 6.2 and their values reflected in the examples, when applicable. > E.g., MAX_PAYLOADS is at least 4 in these examples; the asked > retransmissions are presumably due sometimes to MAX_PAYLOADS > compared against the value of the latest received Q-Block1/Q-Block2, = while > sometimes to NON_RECEIVE_TIMEOUT. [Jon] Examples updated to include this information >=20 >=20 > * In the example in Figure 6, shouldn't the first request from the = client have > the M bit set to 1 in the Q-Block2 option, i.e. as > QB2:0/1/1024 ? As per Section 3.4, that would indicate that the = request is in > fact for the block 0 and for all of the remaining blocks within the = body. =20 [Jon] Good catch - corrected. ~Jon >=20 > On 2021-01-06 16:24, supjps-ietf@jpshallow.com wrote: > > Hi Christian, > > > > Once again, thank you for the comprehensive review. > > > > Responses part 2. A new version (-04) of the draft has been = published > > and can be found at > > > = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdata > > tracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new- > block%2F&data=3D04%7C01 > > > %7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a980 > 9cf0 > > > bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown > %7CTWFpb > > > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > 6Mn0 > > > %3D%7C2000&sdata=3DMlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7j > gTY%3D&am > > p;reserved=3D0 > > > > > > Part 1 responses were covered in the main by version -03, so you may > > want to look at the -02 to -04 differences. > > > > The Congestion Control section has been re-written to simplify how > > things work and has a new set of definitions. There is a separation = of > > Confirmable and Non-Confirmable Congestion Control with the stated > > assumption that all of a body is sent as Non-Confirmable or = Confirmable. > > > > Otherwise, see inline. > > > > Regards > > > > Jon > > > >> * The list of pros and cons (with the cons being almost trivial) = does > >> not explain to the reader why these are not a replacement; I = suggest > >> to add: > > [Jon] Another disadvantage addition > > NEW > > To reduce the transmission times for CON transmission of large = bodies, > > NSTART needs to be increased from 1, but this affects congestion > > control where other parameters need to be tuned (Section 4.7 of > > [RFC7252]). Such tuning is out of scope of this document. > > > >> * "If the client transmits a new body of data with a new = Request-Tag > >> to": Processing parallel requests is something Request-Tag opens = up. I > >> don't see why there's a MUST to that; the server certainly MAY = drop > >> the old request, but it may just as well process them in = parallel. > > [Jon] The intent here was that garbage collection would take place > > sooner than later - especially when running in a lossy environment = and > > the client has updated information to transmit. I agree that > > Request-Tag enables the possibility of sending multiple block = requests > > with different payloads, and so there is a possibility that the = client > > starts sending body A, then decides to send body B and terminate A, > > but a packet from B arrives before a packet from body A is received = and so > things fail as A does not complete. > > > > OLD > > If the client transmits a new body of data with a new Request-Tag = to > > the same resource on a server, the server MUST remove any = partially > > received body held for a previous Request-Tag for that resource. > > NEW > > If a server receives payloads with different Request-Tags for the > > same resource, it should continue to process all the bodies as it = has > > no way of determining which is the latest version, or which body, if > > any, the client is terminating the transmission for. > > > > If the client elects to stop the transmission of a complete body, = it > > SHOULD "forget" all tracked tokens associated with the body's > > Request-Tag so that a reset message is generated for the invalid > > token in the 4.08 (Request Entity Incomplete) response. The server > > on receipt of the reset message SHOULD delete the partial body. > > END > > > >> * "If the server receives a duplicate block with the same = Request-Tag": > >> Why? Being silent is the default on nonterminal blocks alredy, = but in > >> a situation like figure 5 if the 2.04 is lost, that rule would = make > >> it impossible for the client to ever get a successful response. > >> > >> A better rule here may be to say that it processes it all the = same > >> (and if the payload is distinct from the first transmission's = payload, > >> it should err out.) > > [Jon] Fair point > > OLD > > If the server receives a duplicate block with the same = Request-Tag, > > it SHOULD silently ignore the packet. > > NEW > > If the server receives a duplicate block with the same = Request-Tag, > > it SHOULD ignore the payload of the packet, but MUST still = respond > > as if the block was received for the first time. > >> * "If the server receives multiple requests (implied or otherwise) = for > >> the same block, it MUST only send back one instance of that = block.": > >> This might be read as "ever" rather than "per incoming request", = where > >> probably the latter is meant. > > [Jon] This text has already been updated following another review = "OLD > > If the server receives multiple requests > > (implied or otherwise) for the same block, it MUST only send back = one > > instance of that block. > > NEW > > If the request includes multiple Q-Block2 > > Options and these options overlap (e.g., combination of M being = set > > (this and all the later blocks) and being unset (this individual > > block)) resulting in an individual block being requested multiple > > times, the server MUST only send back one instance of that block. > > This behavior is meant to prevent amplification attacks." > > > >> * "The ETag Option MUST NOT be used": This is more a factural than = a > >> normative statement; it *can* not be used there as the server = would > >> respond thusly. It may be used, but then that indicates that the > >> client is trying to verify a freshness. (However, the client = should > >> not *start* sending an ETag once it learned the current = resource's > >> ETag when still attempting to pull out more blocks, but that's = also not > >> a normative requirement but a consequence of those two requests = not > >> being matchable any more.) > > [Jon] OK > > OLD > > The ETag Option MUST NOT be used in the request as the server = could > > respond with a 2.03 (Valid Response) with no payload. If the = server > > responds with a different ETag Option value (as the resource > > representation has changed), then the client SHOULD drop all the > > payloads for the current body that are no longer valid. > > NEW > > The ETag Option should not be used in the request for missing > > blocks as the server could respond with a 2.03 (Valid Response) with > > no payload. It can be used in the request if the client wants to = check > > the freshness of the currently cached body response. > > > > If the server detects part way through a body transfer that the > > resource data has changed and the server is not maintaining a cached > > copy of the old data, then the body response SHOULD be restarted = with > > a different ETag Option value. Any subsequent missing block requests > > MUST respond using the latest ETag Option value. > > > > If the server responds during a body update with a different ETag > > Option value (as the resource representation has changed), then the > > client should treat the partial body with the old ETag as no longer = being > fresh. > > END > >> * "then the client SHOULD drop all the payloads for the current = body": > >> "Drop" is overly prescriptive; the client may well keep them, but > >> just can't consider them fresh any more. (If the client has ample > >> caching abilities, they might come in handy if the resource goes = back > >> to that ETag state). Same for later "the client MUST remove any > >> partially received". > > [Jon] See previous response, otherwise OLD > > If the server transmits a new body of data (e.g., a triggered > > Observe) with a new ETag to the same client as an additional > > response, the client MUST remove any partially received body held = for > > a previous ETag. > > NEW > > If the server transmits a new body of data (e.g., a triggered > > Observe) with a new ETag to the same client as an additional > > response, the client should remove any partially received body = held for > > a previous ETag for that resource as it is unlikely the missing > > blocks can be retrieved. > >> * "For Confirmable transmission, the client SHOULD continue to": As > >> above in the other direction, that's not news. > > [Jon] Again, we are not looking for a response (well, a request in > > this case as needed by Block2), just an ACK OLD > > For Confirmable transmission, the client SHOULD continue to > > acknowledge each packet as well as issuing a separate GET, POST, = PUT, > > FETCH, PATCH, or iPATCH for the missing blocks. > > NEW > > For Confirmable transmission, the server continues to acknowledge >=20 > > each packet, but a response is not required (whether separate or > > piggybacked) until successful receipt of the body or, if some of = the > > payloads are sent as Non-confirmable and have not arrived, a > > retransmit missing payloads response is needed. > >> * "If there is insufficient space to create a response PDU": I = don't > >> understand what that means. (Where are request options reflected > >> back?). > > [Jon] This was triggered by a question by Michael Richardson " So, > > given a Christmas-Tree-Packet (largest packet, every possible option > > space used, every extension turned on...) how much data can I get > > back? :-)" and not fully thought through. > > It could happen though with Location-Path, Location-Query, Q-Block2, > > ETag, > > Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in > > response to a POST. > > OLD > > If there is insufficient space to create a response PDU with a = block > > size of 16 bytes (SZX =3D 0) to reflect back all the request = options as > > appropriate, a 4.13 (Request Entity Too Large) is returned = without > > the Size2 Option. > > NEW > > If there is insufficient space to create a response PDU with a = block > > size of 16 bytes (SZX =3D 0) to send back all the response = options as > > appropriate, a 4.13 (Request Entity Too Large) is returned = without > > the Size1 Option. > > > >> * "If the client requests missing blocks, this is treated as a new > >> request.": I don't think the client should even make these = follow-up > >> requests Observe, as it already has an ongoing observation. = They'd be > >> sent on a different token too, so setting Observe would be = opening > >> observation up on that token, which AFAIU is not intended. = (Figure 7 > >> example looks good to me in that respect.) > >> > >> (It may make sense to ask the client to keep Observe to make the > >> requests matchable just for the sake of staying in = atomic-request > >> mode. Either way, the server should then not accept that = observation > >> as it's not for a block 0.) > > [Jon] The intent here was that just a new Token should be used. > > OLD > > If the client requests missing blocks, this is treated as a new > > request. The Observe value may change but MUST still be = reported. > > If the ETag value changes then the previously received partial = body > > should be destroyed and the whole body re-requested. > > NEW > > If the client requests missing blocks, this is treated as a new > > Request and the Observe Option MUST NOT be included. If the = ETag > value > > changes, then the previously received partial body > > should be considered as not fresh and the whole body = re-requested. > > > >> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response can = be > >> matched by the token to a unique request that already had a > >> Request-Tag, and the client needs to have kept that token around > >> matched to the transfer to make sense of it. > >> > >> No need to move that value around between subsystems, and just > >> dropping it from here would also remove the need for the "If the > >> client does not recognize the Request-Tag" clause (which would > >> otherwise need clarification as to what it'd mean if it = recognizes it > >> but it doesn't match what the request was for). > > [Jon] Good question - it does make sense for the Request-Tag to be > > tracked alongside the Token in the client. > > OLD > > The data payload of the 4.08 (Request Entity Incomplete) Response > > Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR = encoded > > Request-Tag followed by 1 or more missing CBOR encoded missing = block > > numbers. > > NEW > > The data payload of the 4.08 (Request Entity Incomplete) response > > is encoded as a CBOR Sequence [RFC8742]. There are one or more > missing > > CBOR encoded missing block numbers. > > > > OLD > > ; This defines an array, the elements of which are to be used > > ; in a CBOR Sequence: > > payload =3D [request-tag, + missing-block-number] > > request-tag =3D bstr > > ; A unique block number not received: > > missing-block-number =3D uint > > NEW > > ; This defines an array, the elements of which are to be used > > ; in a CBOR Sequence: > > payload =3D [+ missing-block-number] > > request-tag =3D bstr > > ; A unique block number not received: > > missing-block-number =3D uint > > > > OLD > > A 4.08 (Request Entity Incomplete) Response Code returned with > > Content-Type "application/missing-blocks+cbor-seq" indicates that > > some of the payloads are missing and need to be resent. The = client > > then re-transmits the missing payloads using the Request-Tag and > > Q-Block1 to specify the block number, SZX, and M bit as = appropriate. > > The Request-Tag value to use is determined from the payload of = the > > 4.08 (Request Entity Incomplete) Response Code. If the client = does > > not recognize the Request-Tag, the client can ignore this = response. > > NEW (option presentation has been reformatted) > > 4.08 (Request Entity Incomplete) > > > > This Response Code returned with Content-Type "application/ > > missing-blocks+cbor-seq" indicates that some of the payloads are > > missing and need to be resent. The client then retransmits the > > missing payloads using the same Request-Tag, Size1 and Q-Block1 to >=20 > > specify the block number, SZX, and M bit as appropriate. > > > > > > The Request-Tag value to use is determined from the token in the > > 4.08 (Request Entity Incomplete) response and then finding the > > matching client request which contains the Request-Tag that is > > being used for this Q-Block1 body. END > >> * "limit the array count to 23 (Undefined value)": 23 is the = maximum > >> length of a zero-byte length indication, not indefinite-length = (31). > >> Both using 23 and 31 here makes sense (up to 23 to have definite > >> length that can be updated in-place, or exceeding that switch to > >> indefinite length if they still fit), but the paragraph seems to = be > >> mixing them up. > > [Jon] OK > > OLD > > Arrays (Section 3.2.2 of [RFC8949]), limit the array count to = 23 > > (Undefined value) so that the array data byte can be updated = with > > the overall length once the payload length is confirmed or = limited > > to MAX_PAYLOADS count. > > NEW > > Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit = the > > array count to > > 23 so that the initial byte with the array major type and data > > length in the additional information can be updated with the overall > > count once the payload count is confirmed. Further restricting the > > count to MAX_PAYLOADS means that congestion control is less likely = to be > invoked on the server. > > > >> * "Each new request MUST use a unique token": Like above, this is > >> stating something that's not intended to be changed. > > [Jon] RFC7252 does not require Tokens to be unique - e.g. empty = token > > values are acceptable. Hence this statement. > >> Congestion Control: > >> > >> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is > subjected > >> to PROBING_RATE.": That is unexpected here. At most one such > >> response is sent to each request message, so why is additional > >> congestion control needed? > > [Jon] The intention here was that in the previous paragraph that it > > was not the individual packets that are subject to PROBING_RATE, but = a > > single body comprising of multiple packets is subject to = PROBRING_RATE > > - and hence limiting any individual responses to PROBING_RATE rather > > than the potentially full set of responses OLD > > PROBING_RATE parameter in CoAP indicates the average data rate = that > > must not be exceeded by a CoAP endpoint in sending to a peer = endpoint > > that does not respond. The body of blocks will be subjected to > > PROBING_RATE (Section 4.7 of [RFC7252]). > > NEW > > PROBING_RATE parameter in CoAP indicates the average data rate = that > > must not be exceeded by a CoAP endpoint in sending to a peer = endpoint > > that does not respond. The single body of blocks will be = subjected to > > PROBING_RATE (Section 4.7 of [RFC7252]), not the individual = packets. > > If the wait time between sending bodies that are not being > > responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, > then the > > gap time is limited to NON_PROBING_WAIT. > > > > Note: For the particular DOTS application, PROBING_RATE and other > > transmission parameters are negotiated between peers. Even when >=20 > > not negotiated, the DOTS application uses customized defaults as > > discussed in Section 4.5.2 of [RFC8782]. > > END > >> On the other hand, *ever* NON request is subject to = PROBING_RATE, so > >> why point out the body of blocks and "GET or similar" = particularly? > > [Jon] It is only GET or FETCH. The intention here is to not request > > bodies of data at too high a rate. > > OLD > > Each NON GET or similar request using Q-Block2 Option is = subjected to > > PROBING_RATE. > > NEW > > Each NON GET or FETCH request using Q-Block2 Option is subjected = to > > PROBING_RATE. > >> * "a delay is introduced of ACK_TIMEOUT": As I understand > MAX_PAYLOADS, > >> this is (rather implicitly) introduced as the package count up to > >> which it is OK to exceed PROBING_RATE temporarily (but after that = it > >> kicks in all the harder by requiring to wait until = complete-sent-bytes > >> over PROBING_RATE has expired). If that holds, at that time a = much > >> larger delay than just ACK_TIMEOUT is needed to get a response = from > >> the server: About 3 hours (see later note on parameters). > > [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re-write = of > > Congestion Control section. > >> This is the crucial point in the document, and for it a = recommendation > >> alone is not good enough. The protocol can be run with a vastly > >> increased PROBING_RATE (however externally determined) and from > the > >> point of MAX_PAYLOADS just observe it. Or it has to get feedback = from > >> the server; a single 4.08 is probably enough to kick off another > >> vollley of blocks. (How many? MAX_PAYLOADS for every response?). > >> Both can be permitted, but just waiting ACK_TIMEOUT isn't doing = any > >> good. > > [Jon] See re-write of Congestion Control section where things should > > now be simpler and more logical. There is an introduction of new > > variable definitions. > >> * "For NON transmissions": This seems to imply that the full = exchange of > >> a body is either NON or CON; I don't see where that'd come from. = I'd > >> have expected to read something like "Each individual request can = be > >> NON or CON independent of the others. In particular, it can be > >> convenient to send the ultimate payload...". > > [Jon]The DOTS environment will only be using NON. To make = Congestion > > Control simple, the expectation is that all transmissions are NON or > > (not recommended) are all CON. The draft now generally records this > > expectation. > >> * "If a Confirmable packet is used, then the transmitting peer MUST = wait > >> for the ACK": Why? A NSTART > 1 would give it leisure to still > >> transmit. > > [Jon] Text has been removed in the clean-up. > >> * General on congestion control: It may help implementors if this = were > >> split up into newly introduced rules and concepts (that is, > >> MAX_PAYLOADS and the answer to whether you may send > MAX_PAYLOADS en > >> block again after having only even one response from the last = round, > >> and probably the recommended parameters of the "Also on > parameters" > >> comment), and another subsection on how Q-Block behaves well when > >> observing these. > > [Jon] Should now be covered in the updated Congestion Control = section. > >> Caching: > >> > >> * "are not part of the cache key": How about "are removed as part = of the > >> block assembly and thus do not reach the cache"? > > [Jon] OK. > > OLD > > As the entire body is being cached in the proxy, the Q-Block1 and > > Q-Block2 Options are not part of the cache key. > > NEW > > As the entire body is being cached in the proxy, the Q-Block1 and > > Q-Block2 Options are removed as part of the block assembly and = thus > > do not reach the cache. > >> * "When the next client completes building the body": If the proxy > >> chooses not to let them happen in parallel (which it may, see = above on > >> parallel requests, although the server might still not support it = and > >> cancel one of them), why bother letting the first finish just to = abort > >> it? (IOW: If the proxy does not intend to see both through, which = it > >> could if it held back the second until the first is through on = the > >> uplink, it could just as well err out of one of them early, but = it may > >> also rather see both through.) > > [Jon] It has to be assumed that traffic to/from the origin client = and > > origin server may not both support Q-Blockx and potentially may have = a > > different SZX. Thus passing a request or a response through at the > > block level introduces a new set of challenges (but not impossible = to > > fix). To keep this simple, my thinking was that the passing through > > can only take place at the body level. Again, the arrival of = packets > > is not necessarily sequential, so client A's body may start > > transmitting to the origin server first, but client B's body starts = to > > arrive first - the same being true for the proxy as a client may = stop > > transmitting for whatever reason (restart, network loss etc.). > > However this is covered by the above update " If a server receives > > payloads with different Request-Tags for the same resource, it = should > continue to process all the bodies". > > > > OLD > > and the new body representation transmission starts with a new > > Request-Tag value. > > NEW > > and the new body representation transmission starts with a new > > Request-Tag value. Note that it cannot be assumed that the proxy > > will always receive a complete body from a client. > >> * Examples: > >> > >> * Figure 5: The ... between e3 request and response indicate the > >> MAX_TRANSMIT_SPAN before sending the 4.08 response. I suppose > there > >> should be the same kind of delay between the failed e5 = transmission > >> and the e4 response. > > [Jon] Agreed and added in > >> * If the second burst had 3 requests out of which 2 made it, is = there > >> any guidance for which of them the 4.08 would come back on? (In = the > >> end, none of them is terminal). > > [Jon] The client should tracking all Tokens of the burst (hence > > implementation note about bottom 32bits unique and top 32 bits > > matching block number for ease of tracking) for a response and so it > > will make no difference at to which token is used for the 4.08 > > response. From an implementation perspective, it probably is easier > > to track the last opaque token that has the same Request-Tag. > > OLD > > missing ones in one go (Figure 5). It does so by indicating = which > > blocks have been received in the data portion of the response. > > NEW > > missing ones in one go (Figure 5). It does so by indicating = which > > blocks have been received in the data portion of the response. = The > > Token just needs to be one of those that have been received for this > > Request-Tag , so the client can derive the Request-Tag. > >> * If that e4 response gets lost, does the whole mechanism recover = from > >> it in any way? > > [Jon] In this example, if e4 and e5 get lost, there will be no > > 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as to > > whether it sends the request again or gives up. See 9.1 > > "Under high levels of traffic loss, the client can elect not to = retry > > sending missing blocks of data. This decision is implementation > > specific." > >> Generally, the all-NON and all-CON examples don't look to me = like > >> what I'd be doing with this spec; the mixed "a CON every > >> MAX_PAYLOADS" appears much more realistic. > > [Jon] It is unsafe to use CON in the (potentially lossy) DOTS > > environment (up to 93 secs timeout per payload with the defaults). > > Hence why we are separating out the NON / CON usage. > >> * Figure X: The request ahs M unset and thus indicats a request = for > >> just that block. If more than one is expected, it should say > >> QB2:0/1/1024. > > [Jon] With Figure 7, with the M bit set, block 3 would get returned > > for a second time. Draft-ietf-core-new-block-03 also has a Figure 8 > > which does exactly what you describe. > >> * New Content Format: I think this needs a media type registration = to go > >> with it first; based on that, a content format can be registered. > > [Jon] Med has responded to this and draft updated. > >> * General on MAX_TRANSMIT_SPAN and other timing parameters: I'm not > >> sure > >> they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is > defined > >> in terms of reliable transmission, but used for NONs as well. (So = is > >> the alternative ot 2x ACK_TIMEOUT). > > [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and ACK_TIMEOUT > in > > a NON environment. Hence re-write of Congestion Control section > > defining new variables that can be used for NON. > >> For the purpose of delaying a 4.08 or a follow-up GET, it may = make > >> more sense to define a new parameter based on MAX_LATENCY and the > >> time > >> it takes the sender to pump out the options (which I don't think = we > >> have a good factor for, but may even be negligible here). > >> > >> Could read like this: > >> > >> > The timing parameter MAX_BLOCK_JITTER is introduced, and by > default > >> > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / > BANDWIDTH. > > [Jon] Lets plug in some numbers here. MAX_LATENCY =3D 100, > > MAX_PAYLOADS =3D 10, MTU =3D 1280bytes and BANDWIDTH =3D 1Mbps. > > > > [Jon] MAX_BLOCK_JITTER =3D 100 + (10 * 1280 * 8)/(1 000 000) =3D = 100.1. > > So BANDWITH of 1Mbps has negligible effect on the calculation. 1Kbps > > makes MAX_BLOCK_JITTER 200 seconds. > >> > > >> > With Q-Block2, a client can ask for any missing blocks after = not > >> > having received any further response for the duration of > >> > MAX_BLOCK_JITTER. > > [Jon] 100+ seconds delay is way too much time to wait for any = missing > > blocks in my opinion. > > > > [Jon] RFC7252 also states (and the intention is that recovery works > > well) " as MAX_LATENCY is not > > intended to describe a situation when the protocol works well, = but > > the worst-case situation against which the protocol has to = guard." > >> > > >> > With Q-Block1, a server holds off any response for = MAX_BLOCK_JITTER > >> > unless all blocks have been received. Only then it evaluates = whether > >> > to respond with a 2.0x code, a 4.08 with payload, or not at all > >> > (because it responded to a later request). > > [Jon] I am not convinced that this is necessarily the way to go. = The > > new Congestion Control more cleanly handles this. > >> This also brings me back to the earlier matter of 2.31: What is a > >> server supposed to send when no packages were lost, but it's = pasing > >> the timeout and wants to help the client flush out more packages = by > >> confirming something? It says 4.08 in 3.3, but it's not like = there's a > >> hole in the contiguous range. Does it need to send 4.08 = enumerating > >> all (or at least some) numbers between the first unreceived and = what's > >> indicated by Size1? Or can it just send 2.31 and the client knows = all > >> it needs to know b/c the response came to the largest block that = was > >> sent and 2.31 indicates that everything is good up to that point? > > [Jon] The previous draft states (under Congestion Control) that the > > client waits for ACK_TIMEOUT before transmitting the next set of > > MAX_PAYLOADS blocks. The server should wait for "two times > > ACK_TIMEOUT " (3.3) before indicating issue. Apart from perhaps > > having a new name for ACK_TIMOUT I think that these are reasonable > > values for Non-Confirmable - and are used in the new Congestion = Control > section. > > > > [Jon] I have reworked Congestion Control to use 2.31 (NON only) as a > > signal to say that all of the current MAX_PAYLOADS payloads of a = body > > have been received, so allowing the client to continue transmitting > > the next set of MAX_PAYLOADS payloads without the need to wait any > longer. > >> * Also on parameters: This document is describing flow control = stuff > >> around a situation CoAP was not originally designed for. Wouldn't = it > >> make sense to include a set of parameters (PROBING_RATE, > MAX_LATENCY, > >> ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that > >> PROBING_RATE will be left to 1 byte/second for any DOTS = application > >> using this (for sending 10KiB in the initial 10-package = MAX_PAYLOADS > >> burst would mark that connection as unusable for about 3 hours if = they > >> all get lost), so better give justifiable numbers here than rely = on > >> implemnetors to come up with unreviewed numbers or disregard > >> PROBING_RATE altogether. > > [Jon] Answered by Med, and some new text added. > >> I don't know if it needs additional justification, but an = increased > >> N_START may be justifiable there. > > [Jon] It may be, but tuning the other associated parameters is = really > > out of the cope of this draft. This text has been added NEW > > Congestion control for CON requests and responses is specified in > > Section 4.7 of [RFC7252]. For faster transmission rates, NSTART = will > > need to be increased from 1. However, the other CON congestion > > control parameters will need to be tuned to cover this change. = This >=20 > > tuning is out of scope of this document as it is expected that all > > requests and responses using Q-Block1 and Q-Block2 will be Non- > > confirmable. > >> * Somewhere (never comes up but I think it should): When CONs are > used, > >> a 4.08 (or 2.31?) response to a later request can indicate to the > >> client that an earlier CON request has been processed = successfully. If > >> the client can match that up (and it should be able to), then it = can > >> (and should) cancel that particular CON request. > > [Jon] I think that this is covered by my update above with the text = " > > NEW > > For Confirmable transmission, the server continues to acknowledge >=20 > > each packet, but a response is not required (whether separate or > > piggybacked) until successful receipt of the body or, if some of = the > > payloads are sent as Non-confirmable and have not arrived, a > > retransmit missing payloads response is needed." > > > > And in my previous part 1 response (updated) NEW > > For Confirmable transmission, the server continues to acknowledge > > each packet, but a response is not required (whether separate or > > piggybacked) until successful receipt of the body or, if some of = the > > payloads are sent as Non-confirmable and have not arrived, a > > retransmit missing payloads response is needed. > >> Best regards > >> Christian > >> > >> -- > >> There's always a bigger fish. > >> -- Qui-Gon Jinn > > _______________________________________________ > > core mailing list > > core@ietf.org > > > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > w. > > > ietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloc > a%4 > > > 0ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09 > ecc4 > > > 0cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8 > eyJWIjoiMC > > > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000& > amp;sd > > > ata=3DtEJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&reserved=3D0 >=20 > -- > Marco Tiloca > Ph.D., Senior Researcher >=20 > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) >=20 > Phone: +46 (0)70 60 46 501 > https://www.ri.se >=20 From nobody Fri Jan 8 07:58:06 2021 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 9D0B23A109F; Fri, 8 Jan 2021 07:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 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.262, 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 IQXIbtvqseSP; Fri, 8 Jan 2021 07:57:58 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130043.outbound.protection.outlook.com [40.107.13.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 AAE1A3A121E; Fri, 8 Jan 2021 07:57:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T+/f8x+7GbvsC1QXShYxA/mCbAa4g/lfME9O+STx/mVRmAlaJ79NJWsFhD7qmHzGPGBra36UaxXtvCzoHwRpwHZVmyI3HwwE/laqJoC0ntUbL05RqOCH9WKS7fS1N52C1jEYd5L0c3gbG0V0dbulx/+6khqvmLiID5LpsZOmYsxysEhghtgh7Rgp6QX7hk+WCIg4WryHjKCMvzfBYeO3D2ERic7fMGqiglZ+E9IB0GqgR3cnb8g74gHHkxipLvDPwtXx+y0payMIQY0zI30eucQFsmUHszwep7LrfLfew7jsjkzAWvCCm48adNwt+amE616Zt2VBbFF1uxOx9fLfrg== 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=NnbJYLnuDk2llz+Z7iRcEdJ3K8lKHpbIPafgy48nZEQ=; b=oFtfhApBzmBMIklRW0xf2oX+7aKXZNeVqmCybYqe20WCSy0bDitcay2K0vevAfON80b6JAhRaTeGRIf/6CbJ96zsl9dwu4gpnA5hVdF7sj1uxrScV1Ho+l4NFTY4aXNBOj6t3EoIzoyZvf9oc0a3LJOB/RgcHCRZEo1ExiojXMt90N0E/CerZGO2rkjfkqIS8tOIEqz1pfFBYkd9OARM/G7AEJBPkx++l9Cjm83jlIF/uGye02iTTyqD5qqLfOmVOp+1ZAvxMeaEFz9jcTba8qRW40uHjkDkXfkBIoQOEAtuc3t/9NDY88OBHvB2Z/uL3JG1T+0MQ4irTECbM5odlA== 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=NnbJYLnuDk2llz+Z7iRcEdJ3K8lKHpbIPafgy48nZEQ=; b=fwmqD9v9S0eAPIKsR8gxiG0+T/d1Ll9lUwfua3cACvNpJ29Ra/5DGGg642N3b8AS7YRj1d4043qBHqvZ8NqgEt37aIU4LNe3EChF0+Kl9ANx9CesXBlr1XyFiXxEtDS+8+BWqd6qg6zyJyPK5+MxFYHbZ0CBrLnP3GNHnqMJGOU= 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 DB8P189MB0763.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:fc::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Fri, 8 Jan 2021 15:57:31 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3742.010; Fri, 8 Jan 2021 15:57:31 +0000 To: supjps-ietf@jpshallow.com, christian@amsuess.com, draft-ietf-core-new-block@ietf.org Cc: dots@ietf.org, core@ietf.org References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> 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: Fri, 8 Jan 2021 16:57:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bI70GoXmPU1JuWEbqCgyPgV7QRUjXYGzJ" X-Originating-IP: [37.120.209.204] X-ClientProxiedBy: HE1PR05CA0152.eurprd05.prod.outlook.com (2603:10a6:7:28::39) 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.7] (37.120.209.204) by HE1PR05CA0152.eurprd05.prod.outlook.com (2603:10a6:7:28::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6 via Frontend Transport; Fri, 8 Jan 2021 15:57:30 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7302a62d-5f80-4e3e-ce25-08d8b3ee1b1b X-MS-TrafficTypeDiagnostic: DB8P189MB0763: 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: JTpMaOkNmhWD1hdTHyTMAY4tYb7W0/wlCZBNZe/NxsKZWW+GXL8Dh7D+gIc/C91flfi1hk5ayjNv3MBKsJe0pceflqELqHqPCLrUcrSynvPWC0cQ0MpBR9Puiom/cn1Nbj4+qWTZM8ht0Cr7OAGaByKOW9jCa98wExbZrd6BtNQiSAHngXcr2HSqmsAMI8/2f80H8hLtiI+dt5JsVgUQ6PH4kf3yaAUAZbVQ8Uq3MN2s76cfgBxHGSOkHPxhRmZ1D7fAe9M+9CCTtDDB/FbafZo2QjYsEIur17nWbVuWfH50LMMiW5kBGkMWrkK2/utw2Giqmwo3xmQBIblV9QvuHJuFSCALiORGBZ87vt0PmPXBx7gR7B0zH3BGMsBiQyfbOnInil2Eua32Ngob8umRagwgfJPHLAqzIPUgAtNVwfH9sZdG1fCVVBIL2ow/bSWh4jUgorbUu1Yp5ePYWnvB+Y9t8fZ0mX+nqumg1btqnFqHAGnOv2hGj3HAw1EFuSpN+xFhxAxGSjI1Cf4w8CrkGHujSXSwkzFTbNaAoheCC6uzg48TibmTvZrIFmOUioQa 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)(136003)(376002)(366004)(396003)(2616005)(8676002)(86362001)(316002)(31686004)(956004)(52116002)(33964004)(2906002)(4326008)(8936002)(31696002)(45080400002)(16576012)(66946007)(966005)(66476007)(66556008)(30864003)(5660300002)(6486002)(53546011)(21480400003)(66574015)(36756003)(235185007)(478600001)(6666004)(44832011)(16526019)(186003)(83380400001)(26005)(45980500001)(43740500002)(579004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?UW9JTXdCWVluUnhZajVQZmxVeXlPeTZETW5pSU1SemZySnloNjFBTVl3SmxI?= =?utf-8?B?ZEZhM0hsRXZ0Mm9WeE5YYzFpZW5mZGhaL1lrNERNbGs4VExMcXk5TUZlOGFH?= =?utf-8?B?YnRqWjgyUmFtNWVkR0F1Vk9pRUNpTnZ0amVxWkdWWTh5VWRSR0ZKUkdJRjlV?= =?utf-8?B?cStCbGpmdzMyaWptajBHRUc3RWdUWVp4bW5HNWlucDNHV01aSzNjVUNxaVlJ?= =?utf-8?B?emVkYnZ1Z3Y4bitLUWorL3lWYTE3NEtvU0JXdnFqWHVOV29zSm1GMXV6RWtp?= =?utf-8?B?bmJKV1VsRVJyTFRCeDJwZ1ZkbDB6MGNrbjIyRjhlZHdVMTJrVmhHM2dDU3Nt?= =?utf-8?B?SWFKSHNEVHdyY0tobFlvMGlIdGRMeXFKRW1za2FiNE9kR3FyaTNZVm4xWlFv?= =?utf-8?B?cU9mVjU5dUJqWGI1RnI3S3hKMHhqaUpra3lWZm8rTnZKL2h4SUpVQ3VSMnRR?= =?utf-8?B?VTBYeXNEUEZsWm8wUGx3WHFIMmRUdWxXWG0zZFQ1c0ZhL0MrOFZyeU1QUWxZ?= =?utf-8?B?cW5YM0h3cW1VVml4U0JjTFNYY3Q0Zy9yNHJRb05Mei9TeEtDQzVDMEFpMStx?= =?utf-8?B?VUozaStibjdTc1VoTHhnOEREODUrQUtpOUpnSzJNL3NOKzM1M1d3cys4STAv?= =?utf-8?B?OUlQc1B4L2xHWkJtUjQ5U1NLZklqWmFEbnMwaVJFSEZrMFRtQzhwN2lhYjV4?= =?utf-8?B?aWw3ZHVCUkRnTjJOeWNHS1Rua21KaDU5amVnZldpRi9pbk8yVVoxa3lRQVcz?= =?utf-8?B?anZXdnVwZFJZUlowaXlYbmZ2d3o4aUFKM3BVUk9EMHFjbElNN2J0eDRvMjM4?= =?utf-8?B?RXZxU0hBMFlrdEVtSUV2Y2RrdTdpcmF3R2kwUjNVOGdqQVF6WTczMGozTEp0?= =?utf-8?B?RmVJbFhHbTd5SE55NVNsOUNHVUJ2WHBHSE1IMUtEd1NtT2hUYnRZQ2s2VENE?= =?utf-8?B?bHlxbElLR1d5RTZIaGlLSHhnVGFVb0Q5SmpIVmtMeDQvTFNqU1ZLcmN6SEdm?= =?utf-8?B?MytSazh6SDNrSzJQMlVFTnFuMldGalg1L1pFRStrQUdMaHI4RFZPdm05UjhC?= =?utf-8?B?N1BRbGRTRjBrdVE5ZW1JMlBuWnFVT2JDZCs5eXFmUGg3ajdFN21kNWJ0eW5z?= =?utf-8?B?c3BnVTM3RTBIRStvMGIwQVdxTXdGTndHbU5BNHFvOFpRdEhQWDA2bVVRM1hP?= =?utf-8?B?NjhqTVVqN0pGTXJMclZHSlJvU3F2RU9oREJodGR6d0s1cDIwQ2E2aHNVMmhC?= =?utf-8?B?a1ZISGRFTGorRnhab2FWQm9MV05QamtJQmdmRnJXUExWWHlEbVN6eFRqQmJo?= =?utf-8?Q?KYDCEornwY1xJrV2s30kwHJv2Z1tyWVN53?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2021 15:57:30.9956 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: 7302a62d-5f80-4e3e-ce25-08d8b3ee1b1b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: WQdoTyAwAErHd78A0Tym5Cb1YcTLKTH+CaKqUJohEevQaYzd8yt0BWByQUAyXItAEp8eG/o4cgKIRTOz86IJnA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0763 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 08 Jan 2021 15:58:05 -0000 --bI70GoXmPU1JuWEbqCgyPgV7QRUjXYGzJ Content-Type: multipart/mixed; boundary="GFQ5741qHBUqJHRDRYN8yYKowe2dLM2NN" --GFQ5741qHBUqJHRDRYN8yYKowe2dLM2NN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jon, Thanks, the changes look good. Just a few minor things. * In Section 3.4, about the second case: =C2=A0 - s/can continue to sent/can continue to send =C2=A0 - It should be as explicit as in Section 6.2, i.e. "... 'NUM modul= o MAX_PAYLOADS' is zero, while NUM is not zero: ..." =C2=A0 - The word "current" can be misleading, if its relation with the v= alue of NUM in the Q-Block2 option is not clarified. Based on the new example in Figure 8, I think you mean the latest set completely transferred to the client, whose last block has block number (NUM - 1). A possible overall rephrasing can be: =C2=A0 =C2=A0 "This is used to confirm that the current set of MAX_PAYLOADS payl= oads (the latest one having block number NUM-1) has been successfully received and that, upon receipt of this request, the server can continue to send the next set of payloads (the first one having block number NUM). This is the 'Continue' Q-Block-2." * In Section 3.4, about the third case: I guess you mean: "This is a request for that block and for all of the remaining blocks in the current MAX_PAYLOADS set." * Section 4 says: "The token to use ... any troubleshooting." =C2=A0=C2=A0 Do you actually mean the highest block number received so fa= r under that Request-Tag, or the highest within the current set of MAX_PAYLOADS payloads for which the server is requesting some missing blocks? =C2=A0=C2=A0 =C2=A0=C2=A0 The new example in Section 5 seems to cover the latter, whic= h I guess is what you intend. =C2=A0=C2=A0 * In Section 9.2: =C2=A0 - Figure 7, the request should have the M bit set, i.e. QB2:0/1/10= 24 =C2=A0=C2=A0 =C2=A0 - Figure 8, the last response should have block number 10, i.e. QB2:10/0/1024 =C2=A0=C2=A0 =C2=A0 - Figure 10, all responses should have ET=3D24 Best, /Marco On 2021-01-08 14:33, supjps-ietf@jpshallow.com wrote: > Hi Marco, > > Thanks for this - and it is good to have another set of eyes checking t= hings through. > > Updates have been pushed to https://eur02.safelinks.protection.outlook.= com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-block&data=3D04%7= C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0= bcb413a838a09ecc40cc9e8%7C0%7C0%7C637457096666452069%7CUnknown%7CTWFpbGZs= b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C= 2000&sdata=3DLN79Z8Ar4AICnpWDOFgkFi3g0Mwf72KPC0ewPW%2FZk3A%3D&res= erved=3D0 and the differences with the draft can be found at https://eur0= 2.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Frf= cdiff%3Furl1%3Ddraft-ietf-core-new-block%26url2%3Dhttps%3A%2F%2Fraw.githu= busercontent.com%2Fcore-wg%2Fnew-block%2Fmaster%2Fdraft-ietf-core-new-blo= ck.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7c81f608= d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63745709666645206= 9%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1= haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DgIc2vkC1XGtyGb17WSmby%2FO9wzA2bMax= DUsl3jmOAL4%3D&reserved=3D0=20 > > Otherwise, please see inline. > > Regards > > Jon > >> -----Original Message----- >> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >> Sent: 07 January 2021 12:17 >> To: supjps-ietf@jpshallow.com; christian@amsuess.com; draft-ietf-core-= new- >> block@ietf.org >> Cc: dots@ietf.org; core@ietf.org >> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >> >> Hi, >> >> Thanks for this revision and for addressing my comments already in >> version -03. >> >> Please, see below some more comments on this version -04. >> >> Best, >> /Marco >> >> >> * s/There are one or more missing CBOR encoded missing block >> numbers./There are one or more CBOR encoded missing block numbers. > [Jon] Fixed. >> >> * Section 4 now includes the new paragraph: "The token to use for the= >> response SHOULD be the token that was used in the highest block number= >> received payload. The Q-Block1 Option from the same packet SHOULD be >> included." > [Jon] The Q-Block1 option actually is not needed as it can be derived b= y the client from the remembered token (which is used to derive the Reque= st-Tag. > OLD > The Q-Block1 Option from the same packet SHOULD be included. > NEW > The client will use the token to match the request to find what Request= -Tag value is > currently being used. Providing the highest received block number > will aid any troubleshooting. > >> Consistently, the example in Figure 5 should also have QB1:3/0/1024= in the >> 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08 response= >> with Token T:0xe4. > [Jon] No change now needed. >> Since "SHOULD" is used, when is it still fine or expected to not in= clude Q- >> Block1 in a 4.08 response? > [Jon] Q-Block1 is no longer needed. >> >> * When commenting the example in Figure 5, Section 9.1 reads: "The Tok= en >> just needs to be one of those that have been received for this Request= -Tag, >> so the client can derive the Request-Tag." >> >> Should this not be aligned with the SHOULD used in Section 4 about = using >> the Token from the same packet conveying the highest block number? > [Jon] Agreed >> You explained in your mail that the client keeps tracking all Token= s in the >> burst anyway, so maybe it's better to rather align the text in Section= 4 with >> what suggested here in Section 9.1, i.e. responding with any of those = Token >> values is just fine. > [Jon] I think that it is useful for the client to have a hint about wha= t is the latest block number received even if it does not make use it - i= t may help in debugging from packet captures etc. which is why I added in= the SHOULD in section 4. So, I would prefer to align this with section = 4 > OLD > The Token just needs to be one of those that have been received for thi= s > Request-Tag, so the client can derive the Request-Tag. > NEW > The token used in the response should be the token that was used in the= highest block number received payload. The client can then derive the Re= quest-Tag by matching the token with the sent request.. > >> In such a case, the Q-Block1 option included in the 4.08 response h= as still >> to be the one from the request conveying the highest block number. >> Correct? > [Jon] We are now dropping the need for Q-Block1 in the response. >> >> * The new text in Section 6.2 says: "... and the situation re-evaluate= d for >> another 24 hour period until there is no report of missing payloads un= der >> normal operating conditions." >> >> When that happens, I suppose MAX_PAYLOADS is right away restored to= >> the intended value, i.e. it is not incremented by 1 to start another 2= 4-hour >> period evaluation. Correct? > [Jon] Updated for clarification > OLD > report of missing payloads under normal operating conditions. N= ote > that the CoAP peer will not know about the MAX_PAYLOADS change = until > NEW > report of missing payloads under normal operating conditions. T= he newly > derived value for MAX_PAYLOADS should be used for both ends of = this > particular CoAP peer link. Note > that the CoAP peer will not know about the MAX_PAYLOADS change = until >> >> * Section 6.2 says: "The request that the client sends to acknowledge = the >> receipt of all the current set of MAX_PAYLOADS payloads SHOULD contain= a >> special case Q-Block2 Option with NUM set to the first block of the ne= xt set >> of MAX_PAYLOADS payloads and the M bit set to 1." >> >> Is it possible to reflect this in the example of Figure 6? It would = require the >> body to have more than MAX_PAYLOADS blocks thus resulting in more >> bursts, which would be inherited by the examples in Figure 7 and Figur= e 8. > [Jon] Examples updated to include this information >> >> * In Section 9, it would be good to have the parameters defined in Sec= tion >> 6.2 and their values reflected in the examples, when applicable. >> E.g., MAX_PAYLOADS is at least 4 in these examples; the asked >> retransmissions are presumably due sometimes to MAX_PAYLOADS >> compared against the value of the latest received Q-Block1/Q-Block2, w= hile >> sometimes to NON_RECEIVE_TIMEOUT. > [Jon] Examples updated to include this information >> >> * In the example in Figure 6, shouldn't the first request from the cli= ent have >> the M bit set to 1 in the Q-Block2 option, i.e. as >> QB2:0/1/1024 ? As per Section 3.4, that would indicate that the reques= t is in >> fact for the block 0 and for all of the remaining blocks within the bo= dy. > =20 > [Jon] Good catch - corrected. > > ~Jon >> On 2021-01-06 16:24, supjps-ietf@jpshallow.com wrote: >>> Hi Christian, >>> >>> Once again, thank you for the comprehensive review. >>> >>> Responses part 2. A new version (-04) of the draft has been publishe= d >>> and can be found at >>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= ta >>> tracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new- >> block%2F&data=3D04%7C01 >> %7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a980 >> 9cf0 >> bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown >> %7CTWFpb >> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI >> 6Mn0 >> %3D%7C2000&sdata=3DMlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7j >> gTY%3D&am >>> p;reserved=3D0 >>> >>> >>> Part 1 responses were covered in the main by version -03, so you may >>> want to look at the -02 to -04 differences. >>> >>> The Congestion Control section has been re-written to simplify how >>> things work and has a new set of definitions. There is a separation o= f >>> Confirmable and Non-Confirmable Congestion Control with the stated >>> assumption that all of a body is sent as Non-Confirmable or Confirmab= le. >>> >>> Otherwise, see inline. >>> >>> Regards >>> >>> Jon >>> >>>> * The list of pros and cons (with the cons being almost trivial) doe= s >>>> not explain to the reader why these are not a replacement; I sugge= st >>>> to add: >>> [Jon] Another disadvantage addition >>> NEW >>> To reduce the transmission times for CON transmission of large bodies= , >>> NSTART needs to be increased from 1, but this affects congestion >>> control where other parameters need to be tuned (Section 4.7 of >>> [RFC7252]). Such tuning is out of scope of this document. >>> >>>> * "If the client transmits a new body of data with a new Request-Tag= >>>> to": Processing parallel requests is something Request-Tag opens u= p. I >>>> don't see why there's a MUST to that; the server certainly MAY dro= p >>>> the old request, but it may just as well process them in parallel.= >>> [Jon] The intent here was that garbage collection would take place >>> sooner than later - especially when running in a lossy environment an= d >>> the client has updated information to transmit. I agree that >>> Request-Tag enables the possibility of sending multiple block request= s >>> with different payloads, and so there is a possibility that the clien= t >>> starts sending body A, then decides to send body B and terminate A, >>> but a packet from B arrives before a packet from body A is received a= nd so >> things fail as A does not complete. >>> OLD >>> If the client transmits a new body of data with a new Request-Tag = to >>> the same resource on a server, the server MUST remove any partiall= y >>> received body held for a previous Request-Tag for that resource. >>> NEW >>> If a server receives payloads with different Request-Tags for the >>> same resource, it should continue to process all the bodies as it has= >>> no way of determining which is the latest version, or which body, if >>> any, the client is terminating the transmission for. >>> >>> If the client elects to stop the transmission of a complete body, i= t >>> SHOULD "forget" all tracked tokens associated with the body's >>> Request-Tag so that a reset message is generated for the invalid >>> token in the 4.08 (Request Entity Incomplete) response. The server >>> on receipt of the reset message SHOULD delete the partial body. >>> END >>> >>>> * "If the server receives a duplicate block with the same Request-Ta= g": >>>> Why? Being silent is the default on nonterminal blocks alredy, but= in >>>> a situation like figure 5 if the 2.04 is lost, that rule would mak= e >>>> it impossible for the client to ever get a successful response. >>>> >>>> A better rule here may be to say that it processes it all the same= >>>> (and if the payload is distinct from the first transmission's payl= oad, >>>> it should err out.) >>> [Jon] Fair point >>> OLD >>> If the server receives a duplicate block with the same Request-Tag= , >>> it SHOULD silently ignore the packet. >>> NEW >>> If the server receives a duplicate block with the same Request-Tag= , >>> it SHOULD ignore the payload of the packet, but MUST still respon= d >>> as if the block was received for the first time. >>>> * "If the server receives multiple requests (implied or otherwise) f= or >>>> the same block, it MUST only send back one instance of that block.= ": >>>> This might be read as "ever" rather than "per incoming request", w= here >>>> probably the latter is meant. >>> [Jon] This text has already been updated following another review "OL= D >>> If the server receives multiple requests >>> (implied or otherwise) for the same block, it MUST only send back = one >>> instance of that block. >>> NEW >>> If the request includes multiple Q-Block2 >>> Options and these options overlap (e.g., combination of M being se= t >>> (this and all the later blocks) and being unset (this individual >>> block)) resulting in an individual block being requested multiple >>> times, the server MUST only send back one instance of that block. >>> This behavior is meant to prevent amplification attacks." >>> >>>> * "The ETag Option MUST NOT be used": This is more a factural than a= >>>> normative statement; it *can* not be used there as the server woul= d >>>> respond thusly. It may be used, but then that indicates that the >>>> client is trying to verify a freshness. (However, the client shoul= d >>>> not *start* sending an ETag once it learned the current resource's= >>>> ETag when still attempting to pull out more blocks, but that's als= o not >>>> a normative requirement but a consequence of those two requests no= t >>>> being matchable any more.) >>> [Jon] OK >>> OLD >>> The ETag Option MUST NOT be used in the request as the server coul= d >>> respond with a 2.03 (Valid Response) with no payload. If the serv= er >>> responds with a different ETag Option value (as the resource >>> representation has changed), then the client SHOULD drop all the >>> payloads for the current body that are no longer valid. >>> NEW >>> The ETag Option should not be used in the request for missing >>> blocks as the server could respond with a 2.03 (Valid Response) with >>> no payload. It can be used in the request if the client wants to chec= k >>> the freshness of the currently cached body response. >>> >>> If the server detects part way through a body transfer that the >>> resource data has changed and the server is not maintaining a cached >>> copy of the old data, then the body response SHOULD be restarted with= >>> a different ETag Option value. Any subsequent missing block requests >>> MUST respond using the latest ETag Option value. >>> >>> If the server responds during a body update with a different ETag >>> Option value (as the resource representation has changed), then the >>> client should treat the partial body with the old ETag as no longer b= eing >> fresh. >>> END >>>> * "then the client SHOULD drop all the payloads for the current body= ": >>>> "Drop" is overly prescriptive; the client may well keep them, but >>>> just can't consider them fresh any more. (If the client has ample >>>> caching abilities, they might come in handy if the resource goes b= ack >>>> to that ETag state). Same for later "the client MUST remove any >>>> partially received". >>> [Jon] See previous response, otherwise OLD >>> If the server transmits a new body of data (e.g., a triggered >>> Observe) with a new ETag to the same client as an additional >>> response, the client MUST remove any partially received body held = for >>> a previous ETag. >>> NEW >>> If the server transmits a new body of data (e.g., a triggered >>> Observe) with a new ETag to the same client as an additional >>> response, the client should remove any partially received body hel= d for >>> a previous ETag for that resource as it is unlikely the missing >>> blocks can be retrieved. >>>> * "For Confirmable transmission, the client SHOULD continue to": As >>>> above in the other direction, that's not news. >>> [Jon] Again, we are not looking for a response (well, a request in >>> this case as needed by Block2), just an ACK OLD >>> For Confirmable transmission, the client SHOULD continue to >>> acknowledge each packet as well as issuing a separate GET, POST, P= UT, >>> FETCH, PATCH, or iPATCH for the missing blocks. >>> NEW >>> For Confirmable transmission, the server continues to acknowledge >>> each packet, but a response is not required (whether separate or >>> piggybacked) until successful receipt of the body or, if some of th= e >>> payloads are sent as Non-confirmable and have not arrived, a >>> retransmit missing payloads response is needed. >>>> * "If there is insufficient space to create a response PDU": I don't= >>>> understand what that means. (Where are request options reflected >>>> back?). >>> [Jon] This was triggered by a question by Michael Richardson " So, >>> given a Christmas-Tree-Packet (largest packet, every possible option >>> space used, every extension turned on...) how much data can I get >>> back? :-)" and not fully thought through. >>> It could happen though with Location-Path, Location-Query, Q-Block2, >>> ETag, >>> Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in >>> response to a POST. >>> OLD >>> If there is insufficient space to create a response PDU with a blo= ck >>> size of 16 bytes (SZX =3D 0) to reflect back all the request optio= ns as >>> appropriate, a 4.13 (Request Entity Too Large) is returned without= >>> the Size2 Option. >>> NEW >>> If there is insufficient space to create a response PDU with a blo= ck >>> size of 16 bytes (SZX =3D 0) to send back all the response options= as >>> appropriate, a 4.13 (Request Entity Too Large) is returned without= >>> the Size1 Option. >>> >>>> * "If the client requests missing blocks, this is treated as a new >>>> request.": I don't think the client should even make these follow= -up >>>> requests Observe, as it already has an ongoing observation. They'= d be >>>> sent on a different token too, so setting Observe would be openin= g >>>> observation up on that token, which AFAIU is not intended. (Figur= e 7 >>>> example looks good to me in that respect.) >>>> >>>> (It may make sense to ask the client to keep Observe to make the >>>> requests matchable just for the sake of staying in atomic-request= >>>> mode. Either way, the server should then not accept that observat= ion >>>> as it's not for a block 0.) >>> [Jon] The intent here was that just a new Token should be used. >>> OLD >>> If the client requests missing blocks, this is treated as a new >>> request. The Observe value may change but MUST still be reported.= >>> If the ETag value changes then the previously received partial bod= y >>> should be destroyed and the whole body re-requested. >>> NEW >>> If the client requests missing blocks, this is treated as a new >>> Request and the Observe Option MUST NOT be included. If the ETag= >> value >>> changes, then the previously received partial body >>> should be considered as not fresh and the whole body re-requested.= >>> >>>> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response can b= e >>>> matched by the token to a unique request that already had a >>>> Request-Tag, and the client needs to have kept that token around >>>> matched to the transfer to make sense of it. >>>> >>>> No need to move that value around between subsystems, and just >>>> dropping it from here would also remove the need for the "If the >>>> client does not recognize the Request-Tag" clause (which would >>>> otherwise need clarification as to what it'd mean if it recognizes= it >>>> but it doesn't match what the request was for). >>> [Jon] Good question - it does make sense for the Request-Tag to be >>> tracked alongside the Token in the client. >>> OLD >>> The data payload of the 4.08 (Request Entity Incomplete) Response >>> Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR encod= ed >>> Request-Tag followed by 1 or more missing CBOR encoded missing blo= ck >>> numbers. >>> NEW >>> The data payload of the 4.08 (Request Entity Incomplete) response >>> is encoded as a CBOR Sequence [RFC8742]. There are one or more >> missing >>> CBOR encoded missing block numbers. >>> >>> OLD >>> ; This defines an array, the elements of which are to be used >>> ; in a CBOR Sequence: >>> payload =3D [request-tag, + missing-block-number] >>> request-tag =3D bstr >>> ; A unique block number not received: >>> missing-block-number =3D uint >>> NEW >>> ; This defines an array, the elements of which are to be used >>> ; in a CBOR Sequence: >>> payload =3D [+ missing-block-number] >>> request-tag =3D bstr >>> ; A unique block number not received: >>> missing-block-number =3D uint >>> >>> OLD >>> A 4.08 (Request Entity Incomplete) Response Code returned with >>> Content-Type "application/missing-blocks+cbor-seq" indicates that >>> some of the payloads are missing and need to be resent. The clien= t >>> then re-transmits the missing payloads using the Request-Tag and >>> Q-Block1 to specify the block number, SZX, and M bit as appropriat= e. >>> The Request-Tag value to use is determined from the payload of the= >>> 4.08 (Request Entity Incomplete) Response Code. If the client doe= s >>> not recognize the Request-Tag, the client can ignore this response= =2E >>> NEW (option presentation has been reformatted) >>> 4.08 (Request Entity Incomplete) >>> >>> This Response Code returned with Content-Type "application/ >>> missing-blocks+cbor-seq" indicates that some of the payloads are >>> missing and need to be resent. The client then retransmits the >>> missing payloads using the same Request-Tag, Size1 and Q-Block1 to >>> specify the block number, SZX, and M bit as appropriate. >>> >>> >>> The Request-Tag value to use is determined from the token in the >>> 4.08 (Request Entity Incomplete) response and then finding the >>> matching client request which contains the Request-Tag that is >>> being used for this Q-Block1 body. END >>>> * "limit the array count to 23 (Undefined value)": 23 is the maximum= >>>> length of a zero-byte length indication, not indefinite-length (31= ). >>>> Both using 23 and 31 here makes sense (up to 23 to have definite >>>> length that can be updated in-place, or exceeding that switch to >>>> indefinite length if they still fit), but the paragraph seems to b= e >>>> mixing them up. >>> [Jon] OK >>> OLD >>> Arrays (Section 3.2.2 of [RFC8949]), limit the array count to 2= 3 >>> (Undefined value) so that the array data byte can be updated wi= th >>> the overall length once the payload length is confirmed or limi= ted >>> to MAX_PAYLOADS count. >>> NEW >>> Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit the= >>> array count to >>> 23 so that the initial byte with the array major type and data >>> length in the additional information can be updated with the overall >>> count once the payload count is confirmed. Further restricting the >>> count to MAX_PAYLOADS means that congestion control is less likely to= be >> invoked on the server. >>>> * "Each new request MUST use a unique token": Like above, this is >>>> stating something that's not intended to be changed. >>> [Jon] RFC7252 does not require Tokens to be unique - e.g. empty token= >>> values are acceptable. Hence this statement. >>>> Congestion Control: >>>> >>>> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is >> subjected >>>> to PROBING_RATE.": That is unexpected here. At most one such >>>> response is sent to each request message, so why is additional >>>> congestion control needed? >>> [Jon] The intention here was that in the previous paragraph that it >>> was not the individual packets that are subject to PROBING_RATE, but = a >>> single body comprising of multiple packets is subject to PROBRING_RAT= E >>> - and hence limiting any individual responses to PROBING_RATE rather >>> than the potentially full set of responses OLD >>> PROBING_RATE parameter in CoAP indicates the average data rate tha= t >>> must not be exceeded by a CoAP endpoint in sending to a peer endpo= int >>> that does not respond. The body of blocks will be subjected to >>> PROBING_RATE (Section 4.7 of [RFC7252]). >>> NEW >>> PROBING_RATE parameter in CoAP indicates the average data rate tha= t >>> must not be exceeded by a CoAP endpoint in sending to a peer endpo= int >>> that does not respond. The single body of blocks will be subjecte= d to >>> PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packet= s. >>> If the wait time between sending bodies that are not being >>> responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, >> then the >>> gap time is limited to NON_PROBING_WAIT. >>> >>> Note: For the particular DOTS application, PROBING_RATE and other >>> transmission parameters are negotiated between peers. Even when >>> not negotiated, the DOTS application uses customized defaults as >>> discussed in Section 4.5.2 of [RFC8782]. >>> END >>>> On the other hand, *ever* NON request is subject to PROBING_RATE,= so >>>> why point out the body of blocks and "GET or similar" particularl= y? >>> [Jon] It is only GET or FETCH. The intention here is to not request >>> bodies of data at too high a rate. >>> OLD >>> Each NON GET or similar request using Q-Block2 Option is subjected= to >>> PROBING_RATE. >>> NEW >>> Each NON GET or FETCH request using Q-Block2 Option is subjected t= o >>> PROBING_RATE. >>>> * "a delay is introduced of ACK_TIMEOUT": As I understand >> MAX_PAYLOADS, >>>> this is (rather implicitly) introduced as the package count up to >>>> which it is OK to exceed PROBING_RATE temporarily (but after that = it >>>> kicks in all the harder by requiring to wait until complete-sent-b= ytes >>>> over PROBING_RATE has expired). If that holds, at that time a much= >>>> larger delay than just ACK_TIMEOUT is needed to get a response fro= m >>>> the server: About 3 hours (see later note on parameters). >>> [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re-write of= >>> Congestion Control section. >>>> This is the crucial point in the document, and for it a recommenda= tion >>>> alone is not good enough. The protocol can be run with a vastly >>>> increased PROBING_RATE (however externally determined) and from >> the >>>> point of MAX_PAYLOADS just observe it. Or it has to get feedback f= rom >>>> the server; a single 4.08 is probably enough to kick off another >>>> vollley of blocks. (How many? MAX_PAYLOADS for every response?). >>>> Both can be permitted, but just waiting ACK_TIMEOUT isn't doing an= y >>>> good. >>> [Jon] See re-write of Congestion Control section where things should >>> now be simpler and more logical. There is an introduction of new >>> variable definitions. >>>> * "For NON transmissions": This seems to imply that the full exchang= e of >>>> a body is either NON or CON; I don't see where that'd come from. I= 'd >>>> have expected to read something like "Each individual request can = be >>>> NON or CON independent of the others. In particular, it can be >>>> convenient to send the ultimate payload...". >>> [Jon]The DOTS environment will only be using NON. To make Congestion= >>> Control simple, the expectation is that all transmissions are NON or >>> (not recommended) are all CON. The draft now generally records this >>> expectation. >>>> * "If a Confirmable packet is used, then the transmitting peer MUST = wait >>>> for the ACK": Why? A NSTART > 1 would give it leisure to still >>>> transmit. >>> [Jon] Text has been removed in the clean-up. >>>> * General on congestion control: It may help implementors if this we= re >>>> split up into newly introduced rules and concepts (that is, >>>> MAX_PAYLOADS and the answer to whether you may send >> MAX_PAYLOADS en >>>> block again after having only even one response from the last roun= d, >>>> and probably the recommended parameters of the "Also on >> parameters" >>>> comment), and another subsection on how Q-Block behaves well when >>>> observing these. >>> [Jon] Should now be covered in the updated Congestion Control section= =2E >>>> Caching: >>>> >>>> * "are not part of the cache key": How about "are removed as part of= the >>>> block assembly and thus do not reach the cache"? >>> [Jon] OK. >>> OLD >>> As the entire body is being cached in the proxy, the Q-Block1 and >>> Q-Block2 Options are not part of the cache key. >>> NEW >>> As the entire body is being cached in the proxy, the Q-Block1 and >>> Q-Block2 Options are removed as part of the block assembly and thu= s >>> do not reach the cache. >>>> * "When the next client completes building the body": If the proxy >>>> chooses not to let them happen in parallel (which it may, see abov= e on >>>> parallel requests, although the server might still not support it = and >>>> cancel one of them), why bother letting the first finish just to a= bort >>>> it? (IOW: If the proxy does not intend to see both through, which = it >>>> could if it held back the second until the first is through on the= >>>> uplink, it could just as well err out of one of them early, but it= may >>>> also rather see both through.) >>> [Jon] It has to be assumed that traffic to/from the origin client and= >>> origin server may not both support Q-Blockx and potentially may have = a >>> different SZX. Thus passing a request or a response through at the >>> block level introduces a new set of challenges (but not impossible to= >>> fix). To keep this simple, my thinking was that the passing through >>> can only take place at the body level. Again, the arrival of packets= >>> is not necessarily sequential, so client A's body may start >>> transmitting to the origin server first, but client B's body starts t= o >>> arrive first - the same being true for the proxy as a client may stop= >>> transmitting for whatever reason (restart, network loss etc.). >>> However this is covered by the above update " If a server receives >>> payloads with different Request-Tags for the same resource, it should= >> continue to process all the bodies". >>> OLD >>> and the new body representation transmission starts with a new >>> Request-Tag value. >>> NEW >>> and the new body representation transmission starts with a new >>> Request-Tag value. Note that it cannot be assumed that the proxy >>> will always receive a complete body from a client. >>>> * Examples: >>>> >>>> * Figure 5: The ... between e3 request and response indicate the >>>> MAX_TRANSMIT_SPAN before sending the 4.08 response. I suppose >> there >>>> should be the same kind of delay between the failed e5 transmiss= ion >>>> and the e4 response. >>> [Jon] Agreed and added in >>>> * If the second burst had 3 requests out of which 2 made it, is th= ere >>>> any guidance for which of them the 4.08 would come back on? (In = the >>>> end, none of them is terminal). >>> [Jon] The client should tracking all Tokens of the burst (hence >>> implementation note about bottom 32bits unique and top 32 bits >>> matching block number for ease of tracking) for a response and so it >>> will make no difference at to which token is used for the 4.08 >>> response. From an implementation perspective, it probably is easier >>> to track the last opaque token that has the same Request-Tag. >>> OLD >>> missing ones in one go (Figure 5). It does so by indicating which= >>> blocks have been received in the data portion of the response. >>> NEW >>> missing ones in one go (Figure 5). It does so by indicating which= >>> blocks have been received in the data portion of the response. The= >>> Token just needs to be one of those that have been received for this >>> Request-Tag , so the client can derive the Request-Tag. >>>> * If that e4 response gets lost, does the whole mechanism recover = from >>>> it in any way? >>> [Jon] In this example, if e4 and e5 get lost, there will be no >>> 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as to >>> whether it sends the request again or gives up. See 9.1 >>> "Under high levels of traffic loss, the client can elect not to ret= ry >>> sending missing blocks of data. This decision is implementation >>> specific." >>>> Generally, the all-NON and all-CON examples don't look to me lik= e >>>> what I'd be doing with this spec; the mixed "a CON every >>>> MAX_PAYLOADS" appears much more realistic. >>> [Jon] It is unsafe to use CON in the (potentially lossy) DOTS >>> environment (up to 93 secs timeout per payload with the defaults). >>> Hence why we are separating out the NON / CON usage. >>>> * Figure X: The request ahs M unset and thus indicats a request fo= r >>>> just that block. If more than one is expected, it should say >>>> QB2:0/1/1024. >>> [Jon] With Figure 7, with the M bit set, block 3 would get returned >>> for a second time. Draft-ietf-core-new-block-03 also has a Figure 8 >>> which does exactly what you describe. >>>> * New Content Format: I think this needs a media type registration t= o go >>>> with it first; based on that, a content format can be registered. >>> [Jon] Med has responded to this and draft updated. >>>> * General on MAX_TRANSMIT_SPAN and other timing parameters: I'm not >>>> sure >>>> they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is >> defined >>>> in terms of reliable transmission, but used for NONs as well. (So = is >>>> the alternative ot 2x ACK_TIMEOUT). >>> [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and ACK_TIMEOUT >> in >>> a NON environment. Hence re-write of Congestion Control section >>> defining new variables that can be used for NON. >>>> For the purpose of delaying a 4.08 or a follow-up GET, it may make= >>>> more sense to define a new parameter based on MAX_LATENCY and the >>>> time >>>> it takes the sender to pump out the options (which I don't think w= e >>>> have a good factor for, but may even be negligible here). >>>> >>>> Could read like this: >>>> >>>> > The timing parameter MAX_BLOCK_JITTER is introduced, and by >> default >>>> > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / >> BANDWIDTH. >>> [Jon] Lets plug in some numbers here. MAX_LATENCY =3D 100, >>> MAX_PAYLOADS =3D 10, MTU =3D 1280bytes and BANDWIDTH =3D 1Mbps. >>> >>> [Jon] MAX_BLOCK_JITTER =3D 100 + (10 * 1280 * 8)/(1 000 000) =3D 100.= 1. >>> So BANDWITH of 1Mbps has negligible effect on the calculation. 1Kbps >>> makes MAX_BLOCK_JITTER 200 seconds. >>>> > >>>> > With Q-Block2, a client can ask for any missing blocks after not= >>>> > having received any further response for the duration of >>>> > MAX_BLOCK_JITTER. >>> [Jon] 100+ seconds delay is way too much time to wait for any missing= >>> blocks in my opinion. >>> >>> [Jon] RFC7252 also states (and the intention is that recovery works >>> well) " as MAX_LATENCY is not >>> intended to describe a situation when the protocol works well, = but >>> the worst-case situation against which the protocol has to guar= d." >>>> > >>>> > With Q-Block1, a server holds off any response for MAX_BLOCK_JIT= TER >>>> > unless all blocks have been received. Only then it evaluates whe= ther >>>> > to respond with a 2.0x code, a 4.08 with payload, or not at all >>>> > (because it responded to a later request). >>> [Jon] I am not convinced that this is necessarily the way to go. The= >>> new Congestion Control more cleanly handles this. >>>> This also brings me back to the earlier matter of 2.31: What is a >>>> server supposed to send when no packages were lost, but it's pasin= g >>>> the timeout and wants to help the client flush out more packages b= y >>>> confirming something? It says 4.08 in 3.3, but it's not like there= 's a >>>> hole in the contiguous range. Does it need to send 4.08 enumeratin= g >>>> all (or at least some) numbers between the first unreceived and wh= at's >>>> indicated by Size1? Or can it just send 2.31 and the client knows = all >>>> it needs to know b/c the response came to the largest block that w= as >>>> sent and 2.31 indicates that everything is good up to that point? >>> [Jon] The previous draft states (under Congestion Control) that the >>> client waits for ACK_TIMEOUT before transmitting the next set of >>> MAX_PAYLOADS blocks. The server should wait for "two times >>> ACK_TIMEOUT " (3.3) before indicating issue. Apart from perhaps >>> having a new name for ACK_TIMOUT I think that these are reasonable >>> values for Non-Confirmable - and are used in the new Congestion Contr= ol >> section. >>> [Jon] I have reworked Congestion Control to use 2.31 (NON only) as a >>> signal to say that all of the current MAX_PAYLOADS payloads of a body= >>> have been received, so allowing the client to continue transmitting >>> the next set of MAX_PAYLOADS payloads without the need to wait any >> longer. >>>> * Also on parameters: This document is describing flow control stuff= >>>> around a situation CoAP was not originally designed for. Wouldn't = it >>>> make sense to include a set of parameters (PROBING_RATE, >> MAX_LATENCY, >>>> ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that >>>> PROBING_RATE will be left to 1 byte/second for any DOTS applicatio= n >>>> using this (for sending 10KiB in the initial 10-package MAX_PAYLOA= DS >>>> burst would mark that connection as unusable for about 3 hours if = they >>>> all get lost), so better give justifiable numbers here than rely o= n >>>> implemnetors to come up with unreviewed numbers or disregard >>>> PROBING_RATE altogether. >>> [Jon] Answered by Med, and some new text added. >>>> I don't know if it needs additional justification, but an increase= d >>>> N_START may be justifiable there. >>> [Jon] It may be, but tuning the other associated parameters is really= >>> out of the cope of this draft. This text has been added NEW >>> Congestion control for CON requests and responses is specified in >>> Section 4.7 of [RFC7252]. For faster transmission rates, NSTART wil= l >>> need to be increased from 1. However, the other CON congestion >>> control parameters will need to be tuned to cover this change. Thi= s >>> tuning is out of scope of this document as it is expected that all >>> requests and responses using Q-Block1 and Q-Block2 will be Non- >>> confirmable. >>>> * Somewhere (never comes up but I think it should): When CONs are >> used, >>>> a 4.08 (or 2.31?) response to a later request can indicate to the >>>> client that an earlier CON request has been processed successfully= =2E If >>>> the client can match that up (and it should be able to), then it c= an >>>> (and should) cancel that particular CON request. >>> [Jon] I think that this is covered by my update above with the text "= >>> NEW >>> For Confirmable transmission, the server continues to acknowledge >>> each packet, but a response is not required (whether separate or >>> piggybacked) until successful receipt of the body or, if some of th= e >>> payloads are sent as Non-confirmable and have not arrived, a >>> retransmit missing payloads response is needed." >>> >>> And in my previous part 1 response (updated) NEW >>> For Confirmable transmission, the server continues to acknowledge >>> each packet, but a response is not required (whether separate or >>> piggybacked) until successful receipt of the body or, if some of the= >>> payloads are sent as Non-confirmable and have not arrived, a >>> retransmit missing payloads response is needed. >>>> Best regards >>>> Christian >>>> >>>> -- >>>> There's always a bigger fish. >>>> -- Qui-Gon Jinn >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >> w. >> ietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloc >> a%4 >> 0ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09 >> ecc4 >> 0cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8 >> eyJWIjoiMC >> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000& >> amp;sd >> ata=3DtEJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&reserved=3D0 >> >> -- >> 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://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7c81= f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374570966664= 57035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI= 6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DiJgJcxZmwbaLrbmzIuzSjezxDRq47w= wWcNvFC7ox8bw%3D&reserved=3D0 >> > --=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 --GFQ5741qHBUqJHRDRYN8yYKowe2dLM2NN-- --bI70GoXmPU1JuWEbqCgyPgV7QRUjXYGzJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/4gOgACgkQ7iZktA5Y 2kOdEwf/TxPU/VfnDDU69aLztTcjrPXrWxQTY7sfyL2MpIozC53KvROuNFJGL1ic yOOOaAZbF5QJ89/pWoNRxh/bZcy3r7THge92JkakPR0S/ZMuHUogBAShTWT5VJk0 mB2fwa/74g/38NZTxzh86HTHXF6nFnpobUVlj2Xb+kHpgdNno/xvrZqQcsq6oyxB GyuoruQEShBrdGpuMLN/F/6rbUdUM1nA5JIwYkMHPB42sVhgpcc6NvLpBC5nllKl qCNukSClguxyCtnlxDRwO2KrAspsUd5Brldu6d9+G0gM/LQtYSmGQe4ZaiFawcUa fxX2iL9o0V24x+t/2pL1mRWXEPmNgA== =hMlF -----END PGP SIGNATURE----- --bI70GoXmPU1JuWEbqCgyPgV7QRUjXYGzJ-- From nobody Fri Jan 8 08:44:27 2021 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 31EC33A1128 for ; Fri, 8 Jan 2021 08:44:22 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ai6SI2677Z0 for ; Fri, 8 Jan 2021 08:44:19 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51AC3A1129 for ; Fri, 8 Jan 2021 08:44:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 22097300BD4 for ; Fri, 8 Jan 2021 11:44:17 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ImA38WruZAnc for ; Fri, 8 Jan 2021 11:44:14 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id EBFE4300A48; Fri, 8 Jan 2021 11:44:13 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A8B02140-027B-460E-8D81-B11045BCDD34" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Fri, 8 Jan 2021 11:44:15 -0500 In-Reply-To: <7BE43FEF-DA33-4B40-9DA7-E646C60CB600@piuha.net> Cc: "iot-directorate@ietf.org" , draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org, last-call@ietf.org To: Jari Arkko References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> <7BE43FEF-DA33-4B40-9DA7-E646C60CB600@piuha.net> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 08 Jan 2021 16:44:22 -0000 --Apple-Mail=_A8B02140-027B-460E-8D81-B11045BCDD34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jari: All but one of my comments are resolved. >> Section 6 says: >>=20 >> ... An implementation of the DEV URN MUST NOT >> change these properties from what they were intended. >>=20 >> It is not clear to me the meaning of "they" in this sentence. >> Please clarify. >=20 > I made a small change, but I=E2=80=99m not sure how else to express = this. We are talking about whether identifiers are modifiable for = instance. The whole paragraph reads now: >=20 > On most devices, the user can display device identifiers. Depending > on circumstances, device identifiers may or may not be modified or > tampered with by the user. An implementation of the DEV URN MUST NOT = change > such limitations or behaviour from what they were intended. In = particular, a device > identifier that is intended to be immutable should not become mutable > as a part of implementing the DEV URN type. More generally, nothing in > this document should be construed to override what the relevant device > specifications have already said about the identifiers. I am still unsure what an implementer would do to comply the MUST NOT = statement. Maybe it will helpful to turn it into a MUST statement. = Does this work for you? On most devices, the user can display device identifiers. Depending on circumstances, device identifiers may or may not be modified or tampered with by the user. An implementation of the DEV URN MUST = preserve such limitations and behaviors associated with the device identifiers. = In particular, a device identifier that is intended to be immutable should not become = mutable as a part of implementing the DEV URN type. More generally, nothing in this document should be construed to override what the relevant device specifications have already said about the identifiers. Russ= --Apple-Mail=_A8B02140-027B-460E-8D81-B11045BCDD34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Jari:

All = but one of my comments are resolved.

Section= 6 says:

 ... An implementation of the = DEV URN MUST NOT
 change these properties from what = they were intended.

It is not clear to me = the meaning of "they" in this sentence.
Please clarify.

I made a small change, but I=E2=80=99m not sure how else to = express this. We are talking about whether identifiers are modifiable = for instance. The whole paragraph reads now:

On most devices, the user can = display device identifiers. Depending
on circumstances, device identifiers may or may not be = modified or
tampered with = by the user. An implementation of the DEV URN MUST NOT change
such limitations or behaviour = from what they were intended. In particular, a device
identifier that is intended to = be immutable should not become mutable
as a part of implementing the DEV URN type. More generally, = nothing in
this document = should be construed to override what the relevant device
specifications have already said = about the identifiers.

I am still unsure what an implementer = would do to comply the MUST NOT statement.  Maybe it will helpful = to turn it into a MUST statement.  Does this work for = you?

On most devices, the user can display device identifiers. = Depending
on circumstances, device identifiers may = or may not be modified or
tampered with by the = user. An implementation of the DEV URN MUST preserve
such limitations and behaviors associated with the device = identifiers. In particular,
a device identifier = that is intended to be immutable should not become mutable
as a part of implementing the DEV URN type. More generally, = nothing in
this document should be construed to = override what the relevant device
specifications = have already said about the identifiers.

Russ
= --Apple-Mail=_A8B02140-027B-460E-8D81-B11045BCDD34-- From nobody Fri Jan 8 09:17:21 2021 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 683973A1172 for ; Fri, 8 Jan 2021 09:17: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 iDLvUpyzeGVJ for ; Fri, 8 Jan 2021 09:17:14 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 039893A1167 for ; Fri, 8 Jan 2021 09:17:13 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kxvNu-0003r5-Mp; Fri, 08 Jan 2021 17:17:10 +0000 From: To: "Marco Tiloca" , , Cc: , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> In-Reply-To: Date: Fri, 8 Jan 2021 17:17:23 -0000 Message-ID: <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAFUavWxAaeeZ2wB9CJyVaiVik3w Content-Language: en-gb Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 08 Jan 2021 17:17:20 -0000 Hi Marco, Thanks for this. The new updates have been pushed to https://github.com/core-wg/new-block = and the differences with the draft can be found at = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-new-block&url2=3Dhttp= s://raw.githubusercontent.com/core-wg/new-block/master/draft-ietf-core-ne= w-block.txt The PR for the responses below can be found at = https://github.com/core-wg/new-block/pull/11=20 Otherwise see inline. Regards Jon > -----Original Message----- > From: Marco Tiloca [mailto: marco.tiloca@ri.se] > Sent: 08 January 2021 15:57 > To: supjps-ietf@jpshallow.com; christian@amsuess.com; = draft-ietf-core-new- > block@ietf.org > Cc: dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hi Jon, >=20 > Thanks, the changes look good. Just a few minor things. >=20 >=20 > * In Section 3.4, about the second case: >=20 > - s/can continue to sent/can continue to send [Jon] Fixed >=20 > - It should be as explicit as in Section 6.2, i.e. "... 'NUM modulo > MAX_PAYLOADS' is zero, while NUM is not zero: ..." [Jon] Updated to be more explicit. >=20 > - The word "current" can be misleading, if its relation with the = value of > NUM in the Q-Block2 option is not clarified. Based on the new example = in > Figure 8, I think you mean the latest set completely transferred to = the > client, whose last block has block number (NUM - 1). A possible = overall > rephrasing can be: >=20 > "This is used to confirm that the current set of MAX_PAYLOADS = payloads > (the latest one having block number NUM-1) has been successfully = received > and that, upon receipt of this request, the server can continue to = send the > next set of payloads (the first one having block number NUM). This is = the > 'Continue' Q-Block-2." [Jon] Thanks - gone with your suggestion >=20 >=20 > * In Section 3.4, about the third case: I guess you mean: "This is a = request for > that block and for all of the remaining blocks in the current = MAX_PAYLOADS > set." [Jon] Yes, updated. >=20 >=20 > * Section 4 says: "The token to use ... any troubleshooting." >=20 > Do you actually mean the highest block number received so far under = that > Request-Tag, or the highest within the current set of MAX_PAYLOADS > payloads for which the server is requesting some missing blocks? >=20 > The new example in Section 5 seems to cover the latter, which I = guess is > what you intend. [Jon] Not sure that it really makes any difference. Have updated the = text to try to clarify OLD The token to use for the response SHOULD be the token that was used in = the highest block number received payload. Note that the use of any = received token would work, but providing the one used in the highest = received block number will aid any troubleshooting. The client will use = the token to match the request to find what Request-Tag value is = currently being used. NEW The token to use for the response SHOULD be the token that was used in = the highest block number received so far with the same Request-Tag = value. Note that the use of any received token with the same Request-Tag = would work, but providing the one used in the highest received block = number will aid any troubleshooting. The client will use the token to = determine what is the previously sent request to obtain the Request-Tag = value to be used. >=20 >=20 > * In Section 9.2: >=20 > - Figure 7, the request should have the M bit set, i.e. QB2:0/1/1024 [Jon] Fixed - you spotted this before and I broke it again with a cut 'n = paste. >=20 > - Figure 8, the last response should have block number 10, i.e. > QB2:10/0/1024 [Jon] Fixed >=20 > - Figure 10, all responses should have ET=3D24 [Jon] Fixed (I only found one) ~Jon >=20 >=20 > Best, > /Marco >=20 >=20 > On 2021-01-08 14:33, supjps-ietf@jpshallow.com wrote: > > Hi Marco, > > > > Thanks for this - and it is good to have another set of eyes = checking things > through. > > > > Updates have been pushed to > > > = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgith > > ub.com%2Fcore-wg%2Fnew- > block&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7 > > > C2385ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e > 8%7 > > > C0%7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMD > > > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D > LN79 > > > Z8Ar4AICnpWDOFgkFi3g0Mwf72KPC0ewPW%2FZk3A%3D&reserved=3D0 > and the > > differences with the draft can be found at > > > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > w. > > ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new- > block%26url2%3Dhttps%3 > > A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew- > block%2Fmaster%2Fdraf > > t-ietf-core-new- > block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C23 > > > 85ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8% > 7C0% > > > 7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > wLjAwMDAiL > > > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DgIc > 2vkC > > 1XGtyGb17WSmby%2FO9wzA2bMaxDUsl3jmOAL4%3D&reserved=3D0 > > > > Otherwise, please see inline. > > > > Regards > > > > Jon > > > >> -----Original Message----- > >> From: Marco Tiloca [mailto: marco.tiloca@ri.se] > >> Sent: 07 January 2021 12:17 > >> To: supjps-ietf@jpshallow.com; christian@amsuess.com; > >> draft-ietf-core-new- block@ietf.org > >> Cc: dots@ietf.org; core@ietf.org > >> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block > >> > >> Hi, > >> > >> Thanks for this revision and for addressing my comments already in > >> version -03. > >> > >> Please, see below some more comments on this version -04. > >> > >> Best, > >> /Marco > >> > >> > >> * s/There are one or more missing CBOR encoded missing block > >> numbers./There are one or more CBOR encoded missing block numbers. > > [Jon] Fixed. > >> > >> * Section 4 now includes the new paragraph: "The token to use for > >> the response SHOULD be the token that was used in the highest block > >> number received payload. The Q-Block1 Option from the same packet > >> SHOULD be included." > > [Jon] The Q-Block1 option actually is not needed as it can be = derived by > the client from the remembered token (which is used to derive the > Request-Tag. > > OLD > > The Q-Block1 Option from the same packet SHOULD be included. > > NEW > > The client will use the token to match the request to find what > > Request-Tag value is currently being used. Providing the highest > > received block number will aid any troubleshooting. > > > >> Consistently, the example in Figure 5 should also have > >> QB1:3/0/1024 in the > >> 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08 > >> response with Token T:0xe4. > > [Jon] No change now needed. > >> Since "SHOULD" is used, when is it still fine or expected to not > >> include Q- > >> Block1 in a 4.08 response? > > [Jon] Q-Block1 is no longer needed. > >> > >> * When commenting the example in Figure 5, Section 9.1 reads: "The > >> Token just needs to be one of those that have been received for = this > >> Request-Tag, so the client can derive the Request-Tag." > >> > >> Should this not be aligned with the SHOULD used in Section 4 = about > >> using the Token from the same packet conveying the highest block > number? > > [Jon] Agreed > >> You explained in your mail that the client keeps tracking all > >> Tokens in the burst anyway, so maybe it's better to rather align = the > >> text in Section 4 with what suggested here in Section 9.1, i.e. > >> responding with any of those Token values is just fine. > > [Jon] I think that it is useful for the client to have a hint about > > what is the latest block number received even if it does not make = use > > it - it may help in debugging from packet captures etc. which is why = I > added in the SHOULD in section 4. So, I would prefer to align this = with > section 4 OLD The Token just needs to be one of those that have been > received for this > > Request-Tag, so the client can derive the Request-Tag. > > NEW > > The token used in the response should be the token that was used in = the > highest block number received payload. The client can then derive the > Request-Tag by matching the token with the sent request.. > > > >> In such a case, the Q-Block1 option included in the 4.08 = response > >> has still to be the one from the request conveying the highest = block > number. > >> Correct? > > [Jon] We are now dropping the need for Q-Block1 in the response. > >> > >> * The new text in Section 6.2 says: "... and the situation > >> re-evaluated for another 24 hour period until there is no report of > >> missing payloads under normal operating conditions." > >> > >> When that happens, I suppose MAX_PAYLOADS is right away restored > >> to the intended value, i.e. it is not incremented by 1 to start > >> another 24-hour period evaluation. Correct? > > [Jon] Updated for clarification > > OLD > > report of missing payloads under normal operating = conditions. Note > > that the CoAP peer will not know about the MAX_PAYLOADS = change > > until NEW > > report of missing payloads under normal operating = conditions. The > newly > > derived value for MAX_PAYLOADS should be used for both ends = of this > > particular CoAP peer link. Note > > that the CoAP peer will not know about the MAX_PAYLOADS = change > > until > >> > >> * Section 6.2 says: "The request that the client sends to = acknowledge > >> the receipt of all the current set of MAX_PAYLOADS payloads SHOULD > >> contain a special case Q-Block2 Option with NUM set to the first > >> block of the next set of MAX_PAYLOADS payloads and the M bit set to = 1." > >> > >> Is it possible to reflect this in the example of Figure 6? It = would > >> require the body to have more than MAX_PAYLOADS blocks thus > resulting > >> in more bursts, which would be inherited by the examples in Figure = 7 and > Figure 8. > > [Jon] Examples updated to include this information > >> > >> * In Section 9, it would be good to have the parameters defined in > >> Section > >> 6.2 and their values reflected in the examples, when applicable. > >> E.g., MAX_PAYLOADS is at least 4 in these examples; the asked > >> retransmissions are presumably due sometimes to MAX_PAYLOADS > compared > >> against the value of the latest received Q-Block1/Q-Block2, while > >> sometimes to NON_RECEIVE_TIMEOUT. > > [Jon] Examples updated to include this information > >> > >> * In the example in Figure 6, shouldn't the first request from the > >> client have the M bit set to 1 in the Q-Block2 option, i.e. as > >> QB2:0/1/1024 ? As per Section 3.4, that would indicate that the > >> request is in fact for the block 0 and for all of the remaining = blocks within > the body. > > > > [Jon] Good catch - corrected. > > > > ~Jon > >> On 2021-01-06 16:24, supjps-ietf@jpshallow.com wrote: > >>> Hi Christian, > >>> > >>> Once again, thank you for the comprehensive review. > >>> > >>> Responses part 2. A new version (-04) of the draft has been > >>> published and can be found at > >>> > >> > = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdat > >> a > >>> tracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new- > >> block%2F&data=3D04%7C01 > >> > %7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a980 > >> 9cf0 > >> > bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown > >> %7CTWFpb > >> > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > >> 6Mn0 > >> > %3D%7C2000&sdata=3DMlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7j > >> gTY%3D&am > >>> p;reserved=3D0 > >>> > >>> > >>> Part 1 responses were covered in the main by version -03, so you = may > >>> want to look at the -02 to -04 differences. > >>> > >>> The Congestion Control section has been re-written to simplify how > >>> things work and has a new set of definitions. There is a = separation > >>> of Confirmable and Non-Confirmable Congestion Control with the > >>> stated assumption that all of a body is sent as Non-Confirmable or > Confirmable. > >>> > >>> Otherwise, see inline. > >>> > >>> Regards > >>> > >>> Jon > >>> > >>>> * The list of pros and cons (with the cons being almost trivial) = does > >>>> not explain to the reader why these are not a replacement; I = suggest > >>>> to add: > >>> [Jon] Another disadvantage addition > >>> NEW > >>> To reduce the transmission times for CON transmission of large > >>> bodies, NSTART needs to be increased from 1, but this affects > >>> congestion control where other parameters need to be tuned = (Section > >>> 4.7 of [RFC7252]). Such tuning is out of scope of this document. > >>> > >>>> * "If the client transmits a new body of data with a new = Request-Tag > >>>> to": Processing parallel requests is something Request-Tag = opens up. I > >>>> don't see why there's a MUST to that; the server certainly MAY = drop > >>>> the old request, but it may just as well process them in = parallel. > >>> [Jon] The intent here was that garbage collection would take place > >>> sooner than later - especially when running in a lossy environment > >>> and the client has updated information to transmit. I agree that > >>> Request-Tag enables the possibility of sending multiple block > >>> requests with different payloads, and so there is a possibility = that > >>> the client starts sending body A, then decides to send body B and > >>> terminate A, but a packet from B arrives before a packet from body = A > >>> is received and so > >> things fail as A does not complete. > >>> OLD > >>> If the client transmits a new body of data with a new = Request-Tag to > >>> the same resource on a server, the server MUST remove any = partially > >>> received body held for a previous Request-Tag for that = resource. > >>> NEW > >>> If a server receives payloads with different Request-Tags for = the > >>> same resource, it should continue to process all the bodies as it > >>> has no way of determining which is the latest version, or which > >>> body, if any, the client is terminating the transmission for. > >>> > >>> If the client elects to stop the transmission of a complete = body, it > >>> SHOULD "forget" all tracked tokens associated with the body's > >>> Request-Tag so that a reset message is generated for the invalid > >>> token in the 4.08 (Request Entity Incomplete) response. The = server > >>> on receipt of the reset message SHOULD delete the partial body. > >>> END > >>> > >>>> * "If the server receives a duplicate block with the same = Request-Tag": > >>>> Why? Being silent is the default on nonterminal blocks alredy, = but in > >>>> a situation like figure 5 if the 2.04 is lost, that rule would = make > >>>> it impossible for the client to ever get a successful response. > >>>> > >>>> A better rule here may be to say that it processes it all the = same > >>>> (and if the payload is distinct from the first transmission's = payload, > >>>> it should err out.) > >>> [Jon] Fair point > >>> OLD > >>> If the server receives a duplicate block with the same = Request-Tag, > >>> it SHOULD silently ignore the packet. > >>> NEW > >>> If the server receives a duplicate block with the same = Request-Tag, > >>> it SHOULD ignore the payload of the packet, but MUST still > >>> respond as if the block was received for the first time. > >>>> * "If the server receives multiple requests (implied or = otherwise) for > >>>> the same block, it MUST only send back one instance of that = block.": > >>>> This might be read as "ever" rather than "per incoming = request", > where > >>>> probably the latter is meant. > >>> [Jon] This text has already been updated following another review > >>> "OLD If the server receives multiple requests > >>> (implied or otherwise) for the same block, it MUST only send = back one > >>> instance of that block. > >>> NEW > >>> If the request includes multiple Q-Block2 > >>> Options and these options overlap (e.g., combination of M being = set > >>> (this and all the later blocks) and being unset (this = individual > >>> block)) resulting in an individual block being requested = multiple > >>> times, the server MUST only send back one instance of that = block. > >>> This behavior is meant to prevent amplification attacks." > >>> > >>>> * "The ETag Option MUST NOT be used": This is more a factural = than a > >>>> normative statement; it *can* not be used there as the server = would > >>>> respond thusly. It may be used, but then that indicates that = the > >>>> client is trying to verify a freshness. (However, the client = should > >>>> not *start* sending an ETag once it learned the current = resource's > >>>> ETag when still attempting to pull out more blocks, but that's = also not > >>>> a normative requirement but a consequence of those two requests > not > >>>> being matchable any more.) > >>> [Jon] OK > >>> OLD > >>> The ETag Option MUST NOT be used in the request as the server = could > >>> respond with a 2.03 (Valid Response) with no payload. If the = server > >>> responds with a different ETag Option value (as the resource > >>> representation has changed), then the client SHOULD drop all = the > >>> payloads for the current body that are no longer valid. > >>> NEW > >>> The ETag Option should not be used in the request for missing > >>> blocks as the server could respond with a 2.03 (Valid Response) = with > >>> no payload. It can be used in the request if the client wants to > >>> check the freshness of the currently cached body response. > >>> > >>> If the server detects part way through a body transfer that the > >>> resource data has changed and the server is not maintaining a = cached > >>> copy of the old data, then the body response SHOULD be restarted > >>> with a different ETag Option value. Any subsequent missing block > >>> requests MUST respond using the latest ETag Option value. > >>> > >>> If the server responds during a body update with a different ETag > >>> Option value (as the resource representation has changed), then = the > >>> client should treat the partial body with the old ETag as no = longer > >>> being > >> fresh. > >>> END > >>>> * "then the client SHOULD drop all the payloads for the current = body": > >>>> "Drop" is overly prescriptive; the client may well keep them, = but > >>>> just can't consider them fresh any more. (If the client has = ample > >>>> caching abilities, they might come in handy if the resource = goes back > >>>> to that ETag state). Same for later "the client MUST remove any > >>>> partially received". > >>> [Jon] See previous response, otherwise OLD > >>> If the server transmits a new body of data (e.g., a triggered > >>> Observe) with a new ETag to the same client as an additional > >>> response, the client MUST remove any partially received body = held for > >>> a previous ETag. > >>> NEW > >>> If the server transmits a new body of data (e.g., a triggered > >>> Observe) with a new ETag to the same client as an additional > >>> response, the client should remove any partially received body = held > for > >>> a previous ETag for that resource as it is unlikely the missing > >>> blocks can be retrieved. > >>>> * "For Confirmable transmission, the client SHOULD continue to": = As > >>>> above in the other direction, that's not news. > >>> [Jon] Again, we are not looking for a response (well, a request in > >>> this case as needed by Block2), just an ACK OLD > >>> For Confirmable transmission, the client SHOULD continue to > >>> acknowledge each packet as well as issuing a separate GET, = POST, PUT, > >>> FETCH, PATCH, or iPATCH for the missing blocks. > >>> NEW > >>> For Confirmable transmission, the server continues to = acknowledge > >>> each packet, but a response is not required (whether separate or > >>> piggybacked) until successful receipt of the body or, if some of = the > >>> payloads are sent as Non-confirmable and have not arrived, a > >>> retransmit missing payloads response is needed. > >>>> * "If there is insufficient space to create a response PDU": I = don't > >>>> understand what that means. (Where are request options = reflected > >>>> back?). > >>> [Jon] This was triggered by a question by Michael Richardson " So, > >>> given a Christmas-Tree-Packet (largest packet, every possible = option > >>> space used, every extension turned on...) how much data can I get > >>> back? :-)" and not fully thought through. > >>> It could happen though with Location-Path, Location-Query, = Q-Block2, > >>> ETag, > >>> Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in > >>> response to a POST. > >>> OLD > >>> If there is insufficient space to create a response PDU with a = block > >>> size of 16 bytes (SZX =3D 0) to reflect back all the request = options as > >>> appropriate, a 4.13 (Request Entity Too Large) is returned = without > >>> the Size2 Option. > >>> NEW > >>> If there is insufficient space to create a response PDU with a = block > >>> size of 16 bytes (SZX =3D 0) to send back all the response = options as > >>> appropriate, a 4.13 (Request Entity Too Large) is returned = without > >>> the Size1 Option. > >>> > >>>> * "If the client requests missing blocks, this is treated as a = new > >>>> request.": I don't think the client should even make these = follow-up > >>>> requests Observe, as it already has an ongoing observation. = They'd be > >>>> sent on a different token too, so setting Observe would be = opening > >>>> observation up on that token, which AFAIU is not intended. = (Figure 7 > >>>> example looks good to me in that respect.) > >>>> > >>>> (It may make sense to ask the client to keep Observe to make = the > >>>> requests matchable just for the sake of staying in = atomic-request > >>>> mode. Either way, the server should then not accept that = observation > >>>> as it's not for a block 0.) > >>> [Jon] The intent here was that just a new Token should be used. > >>> OLD > >>> If the client requests missing blocks, this is treated as a new > >>> request. The Observe value may change but MUST still be = reported. > >>> If the ETag value changes then the previously received partial = body > >>> should be destroyed and the whole body re-requested. > >>> NEW > >>> If the client requests missing blocks, this is treated as a new > >>> Request and the Observe Option MUST NOT be included. If the = ETag > >> value > >>> changes, then the previously received partial body > >>> should be considered as not fresh and the whole body = re-requested. > >>> > >>>> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response = can > be > >>>> matched by the token to a unique request that already had a > >>>> Request-Tag, and the client needs to have kept that token = around > >>>> matched to the transfer to make sense of it. > >>>> > >>>> No need to move that value around between subsystems, and just > >>>> dropping it from here would also remove the need for the "If = the > >>>> client does not recognize the Request-Tag" clause (which would > >>>> otherwise need clarification as to what it'd mean if it = recognizes it > >>>> but it doesn't match what the request was for). > >>> [Jon] Good question - it does make sense for the Request-Tag to be > >>> tracked alongside the Token in the client. > >>> OLD > >>> The data payload of the 4.08 (Request Entity Incomplete) = Response > >>> Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR = encoded > >>> Request-Tag followed by 1 or more missing CBOR encoded missing > block > >>> numbers. > >>> NEW > >>> The data payload of the 4.08 (Request Entity Incomplete) = response > >>> is encoded as a CBOR Sequence [RFC8742]. There are one or more > >> missing > >>> CBOR encoded missing block numbers. > >>> > >>> OLD > >>> ; This defines an array, the elements of which are to be = used > >>> ; in a CBOR Sequence: > >>> payload =3D [request-tag, + missing-block-number] > >>> request-tag =3D bstr > >>> ; A unique block number not received: > >>> missing-block-number =3D uint > >>> NEW > >>> ; This defines an array, the elements of which are to be = used > >>> ; in a CBOR Sequence: > >>> payload =3D [+ missing-block-number] > >>> request-tag =3D bstr > >>> ; A unique block number not received: > >>> missing-block-number =3D uint > >>> > >>> OLD > >>> A 4.08 (Request Entity Incomplete) Response Code returned with > >>> Content-Type "application/missing-blocks+cbor-seq" indicates = that > >>> some of the payloads are missing and need to be resent. The = client > >>> then re-transmits the missing payloads using the Request-Tag = and > >>> Q-Block1 to specify the block number, SZX, and M bit as = appropriate. > >>> The Request-Tag value to use is determined from the payload of = the > >>> 4.08 (Request Entity Incomplete) Response Code. If the client = does > >>> not recognize the Request-Tag, the client can ignore this = response. > >>> NEW (option presentation has been reformatted) > >>> 4.08 (Request Entity Incomplete) > >>> > >>> This Response Code returned with Content-Type "application/ > >>> missing-blocks+cbor-seq" indicates that some of the payloads are > >>> missing and need to be resent. The client then retransmits the > >>> missing payloads using the same Request-Tag, Size1 and Q-Block1 = to > >>> specify the block number, SZX, and M bit as appropriate. > >>> > >>> > >>> The Request-Tag value to use is determined from the token in the > >>> 4.08 (Request Entity Incomplete) response and then finding the > >>> matching client request which contains the Request-Tag that is > >>> being used for this Q-Block1 body. END > >>>> * "limit the array count to 23 (Undefined value)": 23 is the = maximum > >>>> length of a zero-byte length indication, not indefinite-length = (31). > >>>> Both using 23 and 31 here makes sense (up to 23 to have = definite > >>>> length that can be updated in-place, or exceeding that switch = to > >>>> indefinite length if they still fit), but the paragraph seems = to be > >>>> mixing them up. > >>> [Jon] OK > >>> OLD > >>> Arrays (Section 3.2.2 of [RFC8949]), limit the array count = to 23 > >>> (Undefined value) so that the array data byte can be updated = with > >>> the overall length once the payload length is confirmed or = limited > >>> to MAX_PAYLOADS count. > >>> NEW > >>> Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit > >>> the array count to > >>> 23 so that the initial byte with the array major type and = data > >>> length in the additional information can be updated with the = overall > >>> count once the payload count is confirmed. Further restricting = the > >>> count to MAX_PAYLOADS means that congestion control is less likely > >>> to be > >> invoked on the server. > >>>> * "Each new request MUST use a unique token": Like above, this is > >>>> stating something that's not intended to be changed. > >>> [Jon] RFC7252 does not require Tokens to be unique - e.g. empty > >>> token values are acceptable. Hence this statement. > >>>> Congestion Control: > >>>> > >>>> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is > >> subjected > >>>> to PROBING_RATE.": That is unexpected here. At most one such > >>>> response is sent to each request message, so why is additional > >>>> congestion control needed? > >>> [Jon] The intention here was that in the previous paragraph that = it > >>> was not the individual packets that are subject to PROBING_RATE, = but > >>> a single body comprising of multiple packets is subject to > >>> PROBRING_RATE > >>> - and hence limiting any individual responses to PROBING_RATE = rather > >>> than the potentially full set of responses OLD > >>> PROBING_RATE parameter in CoAP indicates the average data rate = that > >>> must not be exceeded by a CoAP endpoint in sending to a peer > endpoint > >>> that does not respond. The body of blocks will be subjected to > >>> PROBING_RATE (Section 4.7 of [RFC7252]). > >>> NEW > >>> PROBING_RATE parameter in CoAP indicates the average data rate = that > >>> must not be exceeded by a CoAP endpoint in sending to a peer > endpoint > >>> that does not respond. The single body of blocks will be = subjected to > >>> PROBING_RATE (Section 4.7 of [RFC7252]), not the individual = packets. > >>> If the wait time between sending bodies that are not being > >>> responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, > >> then the > >>> gap time is limited to NON_PROBING_WAIT. > >>> > >>> Note: For the particular DOTS application, PROBING_RATE and other > >>> transmission parameters are negotiated between peers. Even when > >>> not negotiated, the DOTS application uses customized defaults as > >>> discussed in Section 4.5.2 of [RFC8782]. > >>> END > >>>> On the other hand, *ever* NON request is subject to = PROBING_RATE, > so > >>>> why point out the body of blocks and "GET or similar" = particularly? > >>> [Jon] It is only GET or FETCH. The intention here is to not = request > >>> bodies of data at too high a rate. > >>> OLD > >>> Each NON GET or similar request using Q-Block2 Option is = subjected to > >>> PROBING_RATE. > >>> NEW > >>> Each NON GET or FETCH request using Q-Block2 Option is = subjected > >>> to PROBING_RATE. > >>>> * "a delay is introduced of ACK_TIMEOUT": As I understand > >> MAX_PAYLOADS, > >>>> this is (rather implicitly) introduced as the package count up = to > >>>> which it is OK to exceed PROBING_RATE temporarily (but after = that it > >>>> kicks in all the harder by requiring to wait until = complete-sent-bytes > >>>> over PROBING_RATE has expired). If that holds, at that time a = much > >>>> larger delay than just ACK_TIMEOUT is needed to get a response = from > >>>> the server: About 3 hours (see later note on parameters). > >>> [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re-write > >>> of Congestion Control section. > >>>> This is the crucial point in the document, and for it a = recommendation > >>>> alone is not good enough. The protocol can be run with a vastly > >>>> increased PROBING_RATE (however externally determined) and from > >> the > >>>> point of MAX_PAYLOADS just observe it. Or it has to get = feedback > from > >>>> the server; a single 4.08 is probably enough to kick off = another > >>>> vollley of blocks. (How many? MAX_PAYLOADS for every = response?). > >>>> Both can be permitted, but just waiting ACK_TIMEOUT isn't doing = any > >>>> good. > >>> [Jon] See re-write of Congestion Control section where things = should > >>> now be simpler and more logical. There is an introduction of new > >>> variable definitions. > >>>> * "For NON transmissions": This seems to imply that the full = exchange > of > >>>> a body is either NON or CON; I don't see where that'd come = from. I'd > >>>> have expected to read something like "Each individual request = can be > >>>> NON or CON independent of the others. In particular, it can be > >>>> convenient to send the ultimate payload...". > >>> [Jon]The DOTS environment will only be using NON. To make > >>> Congestion Control simple, the expectation is that all = transmissions > >>> are NON or (not recommended) are all CON. The draft now generally > >>> records this expectation. > >>>> * "If a Confirmable packet is used, then the transmitting peer = MUST > wait > >>>> for the ACK": Why? A NSTART > 1 would give it leisure to still > >>>> transmit. > >>> [Jon] Text has been removed in the clean-up. > >>>> * General on congestion control: It may help implementors if this = were > >>>> split up into newly introduced rules and concepts (that is, > >>>> MAX_PAYLOADS and the answer to whether you may send > >> MAX_PAYLOADS en > >>>> block again after having only even one response from the last = round, > >>>> and probably the recommended parameters of the "Also on > >> parameters" > >>>> comment), and another subsection on how Q-Block behaves well > when > >>>> observing these. > >>> [Jon] Should now be covered in the updated Congestion Control > section. > >>>> Caching: > >>>> > >>>> * "are not part of the cache key": How about "are removed as part = of > the > >>>> block assembly and thus do not reach the cache"? > >>> [Jon] OK. > >>> OLD > >>> As the entire body is being cached in the proxy, the Q-Block1 = and > >>> Q-Block2 Options are not part of the cache key. > >>> NEW > >>> As the entire body is being cached in the proxy, the Q-Block1 = and > >>> Q-Block2 Options are removed as part of the block assembly and > >>> thus do not reach the cache. > >>>> * "When the next client completes building the body": If the = proxy > >>>> chooses not to let them happen in parallel (which it may, see = above > on > >>>> parallel requests, although the server might still not support = it and > >>>> cancel one of them), why bother letting the first finish just = to abort > >>>> it? (IOW: If the proxy does not intend to see both through, = which it > >>>> could if it held back the second until the first is through on = the > >>>> uplink, it could just as well err out of one of them early, but = it may > >>>> also rather see both through.) > >>> [Jon] It has to be assumed that traffic to/from the origin client > >>> and origin server may not both support Q-Blockx and potentially = may > >>> have a different SZX. Thus passing a request or a response = through > >>> at the block level introduces a new set of challenges (but not > >>> impossible to fix). To keep this simple, my thinking was that the > >>> passing through can only take place at the body level. Again, the > >>> arrival of packets is not necessarily sequential, so client A's = body > >>> may start transmitting to the origin server first, but client B's > >>> body starts to arrive first - the same being true for the proxy as = a > >>> client may stop transmitting for whatever reason (restart, network = loss > etc.). > >>> However this is covered by the above update " If a server = receives > >>> payloads with different Request-Tags for the same resource, it > >>> should > >> continue to process all the bodies". > >>> OLD > >>> and the new body representation transmission starts with a new > >>> Request-Tag value. > >>> NEW > >>> and the new body representation transmission starts with a new > >>> Request-Tag value. Note that it cannot be assumed that the = proxy > >>> will always receive a complete body from a client. > >>>> * Examples: > >>>> > >>>> * Figure 5: The ... between e3 request and response indicate = the > >>>> MAX_TRANSMIT_SPAN before sending the 4.08 response. I suppose > >> there > >>>> should be the same kind of delay between the failed e5 = transmission > >>>> and the e4 response. > >>> [Jon] Agreed and added in > >>>> * If the second burst had 3 requests out of which 2 made it, is = there > >>>> any guidance for which of them the 4.08 would come back on? = (In the > >>>> end, none of them is terminal). > >>> [Jon] The client should tracking all Tokens of the burst (hence > >>> implementation note about bottom 32bits unique and top 32 bits > >>> matching block number for ease of tracking) for a response and so = it > >>> will make no difference at to which token is used for the 4.08 > >>> response. From an implementation perspective, it probably is = easier > >>> to track the last opaque token that has the same Request-Tag. > >>> OLD > >>> missing ones in one go (Figure 5). It does so by indicating = which > >>> blocks have been received in the data portion of the response. > >>> NEW > >>> missing ones in one go (Figure 5). It does so by indicating = which > >>> blocks have been received in the data portion of the response. > >>> The Token just needs to be one of those that have been received = for > >>> this Request-Tag , so the client can derive the Request-Tag. > >>>> * If that e4 response gets lost, does the whole mechanism = recover > from > >>>> it in any way? > >>> [Jon] In this example, if e4 and e5 get lost, there will be no > >>> 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as to > >>> whether it sends the request again or gives up. See 9.1 > >>> "Under high levels of traffic loss, the client can elect not to = retry > >>> sending missing blocks of data. This decision is = implementation > >>> specific." > >>>> Generally, the all-NON and all-CON examples don't look to me = like > >>>> what I'd be doing with this spec; the mixed "a CON every > >>>> MAX_PAYLOADS" appears much more realistic. > >>> [Jon] It is unsafe to use CON in the (potentially lossy) DOTS > >>> environment (up to 93 secs timeout per payload with the defaults). > >>> Hence why we are separating out the NON / CON usage. > >>>> * Figure X: The request ahs M unset and thus indicats a request = for > >>>> just that block. If more than one is expected, it should say > >>>> QB2:0/1/1024. > >>> [Jon] With Figure 7, with the M bit set, block 3 would get = returned > >>> for a second time. Draft-ietf-core-new-block-03 also has a Figure = 8 > >>> which does exactly what you describe. > >>>> * New Content Format: I think this needs a media type = registration to > go > >>>> with it first; based on that, a content format can be = registered. > >>> [Jon] Med has responded to this and draft updated. > >>>> * General on MAX_TRANSMIT_SPAN and other timing parameters: I'm > not > >>>> sure > >>>> they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is > >> defined > >>>> in terms of reliable transmission, but used for NONs as well. = (So is > >>>> the alternative ot 2x ACK_TIMEOUT). > >>> [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and > ACK_TIMEOUT > >> in > >>> a NON environment. Hence re-write of Congestion Control section > >>> defining new variables that can be used for NON. > >>>> For the purpose of delaying a 4.08 or a follow-up GET, it may = make > >>>> more sense to define a new parameter based on MAX_LATENCY and > the > >>>> time > >>>> it takes the sender to pump out the options (which I don't = think we > >>>> have a good factor for, but may even be negligible here). > >>>> > >>>> Could read like this: > >>>> > >>>> > The timing parameter MAX_BLOCK_JITTER is introduced, and by > >> default > >>>> > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / > >> BANDWIDTH. > >>> [Jon] Lets plug in some numbers here. MAX_LATENCY =3D 100, > >>> MAX_PAYLOADS =3D 10, MTU =3D 1280bytes and BANDWIDTH =3D 1Mbps. > >>> > >>> [Jon] MAX_BLOCK_JITTER =3D 100 + (10 * 1280 * 8)/(1 000 000) =3D = 100.1. > >>> So BANDWITH of 1Mbps has negligible effect on the calculation. = 1Kbps > >>> makes MAX_BLOCK_JITTER 200 seconds. > >>>> > > >>>> > With Q-Block2, a client can ask for any missing blocks after = not > >>>> > having received any further response for the duration of > >>>> > MAX_BLOCK_JITTER. > >>> [Jon] 100+ seconds delay is way too much time to wait for any > >>> missing blocks in my opinion. > >>> > >>> [Jon] RFC7252 also states (and the intention is that recovery = works > >>> well) " as MAX_LATENCY is not > >>> intended to describe a situation when the protocol works = well, but > >>> the worst-case situation against which the protocol has to = guard." > >>>> > > >>>> > With Q-Block1, a server holds off any response for > MAX_BLOCK_JITTER > >>>> > unless all blocks have been received. Only then it evaluates > whether > >>>> > to respond with a 2.0x code, a 4.08 with payload, or not at = all > >>>> > (because it responded to a later request). > >>> [Jon] I am not convinced that this is necessarily the way to go. > >>> The new Congestion Control more cleanly handles this. > >>>> This also brings me back to the earlier matter of 2.31: What is = a > >>>> server supposed to send when no packages were lost, but it's = pasing > >>>> the timeout and wants to help the client flush out more = packages by > >>>> confirming something? It says 4.08 in 3.3, but it's not like = there's a > >>>> hole in the contiguous range. Does it need to send 4.08 = enumerating > >>>> all (or at least some) numbers between the first unreceived and > what's > >>>> indicated by Size1? Or can it just send 2.31 and the client = knows all > >>>> it needs to know b/c the response came to the largest block = that was > >>>> sent and 2.31 indicates that everything is good up to that = point? > >>> [Jon] The previous draft states (under Congestion Control) that = the > >>> client waits for ACK_TIMEOUT before transmitting the next set of > >>> MAX_PAYLOADS blocks. The server should wait for "two times > >>> ACK_TIMEOUT " (3.3) before indicating issue. Apart from perhaps > >>> having a new name for ACK_TIMOUT I think that these are reasonable > >>> values for Non-Confirmable - and are used in the new Congestion > >>> Control > >> section. > >>> [Jon] I have reworked Congestion Control to use 2.31 (NON only) as = a > >>> signal to say that all of the current MAX_PAYLOADS payloads of a > >>> body have been received, so allowing the client to continue > >>> transmitting the next set of MAX_PAYLOADS payloads without the = need > >>> to wait any > >> longer. > >>>> * Also on parameters: This document is describing flow control = stuff > >>>> around a situation CoAP was not originally designed for. = Wouldn't it > >>>> make sense to include a set of parameters (PROBING_RATE, > >> MAX_LATENCY, > >>>> ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt = that > >>>> PROBING_RATE will be left to 1 byte/second for any DOTS = application > >>>> using this (for sending 10KiB in the initial 10-package = MAX_PAYLOADS > >>>> burst would mark that connection as unusable for about 3 hours = if > they > >>>> all get lost), so better give justifiable numbers here than = rely on > >>>> implemnetors to come up with unreviewed numbers or disregard > >>>> PROBING_RATE altogether. > >>> [Jon] Answered by Med, and some new text added. > >>>> I don't know if it needs additional justification, but an = increased > >>>> N_START may be justifiable there. > >>> [Jon] It may be, but tuning the other associated parameters is > >>> really out of the cope of this draft. This text has been added NEW > >>> Congestion control for CON requests and responses is specified in > >>> Section 4.7 of [RFC7252]. For faster transmission rates, NSTART = will > >>> need to be increased from 1. However, the other CON congestion > >>> control parameters will need to be tuned to cover this change. = This > >>> tuning is out of scope of this document as it is expected that = all > >>> requests and responses using Q-Block1 and Q-Block2 will be Non- > >>> confirmable. > >>>> * Somewhere (never comes up but I think it should): When CONs are > >> used, > >>>> a 4.08 (or 2.31?) response to a later request can indicate to = the > >>>> client that an earlier CON request has been processed = successfully. If > >>>> the client can match that up (and it should be able to), then = it can > >>>> (and should) cancel that particular CON request. > >>> [Jon] I think that this is covered by my update above with the = text " > >>> NEW > >>> For Confirmable transmission, the server continues to = acknowledge > >>> each packet, but a response is not required (whether separate or > >>> piggybacked) until successful receipt of the body or, if some of = the > >>> payloads are sent as Non-confirmable and have not arrived, a > >>> retransmit missing payloads response is needed." > >>> > >>> And in my previous part 1 response (updated) NEW For Confirmable > >>> transmission, the server continues to acknowledge each packet, = but > >>> a response is not required (whether separate or > >>> piggybacked) until successful receipt of the body or, if some of = the > >>> payloads are sent as Non-confirmable and have not arrived, a > >>> retransmit missing payloads response is needed. > >>>> Best regards > >>>> Christian > >>>> > >>>> -- > >>>> There's always a bigger fish. > >>>> -- Qui-Gon Jinn > >>> _______________________________________________ > >>> core mailing list > >>> core@ietf.org > >>> > >> > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > >> w. > >> > ietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloc > >> a%4 > >> > 0ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09 > >> ecc4 > >> > 0cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8 > >> eyJWIjoiMC > >> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000& > >> amp;sd > >> > ata=3DtEJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&reserved=3D0 > >> > >> -- > >> 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://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > w > >> > .ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7 > c8 > >> > 1f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637 > 45709 > >> > 6666457035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > oiV2luMz > >> > IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DiJgJcxZmwbaLrb > mzIuz > >> SjezxDRq47wwWcNvFC7ox8bw%3D&reserved=3D0 > >> > > >=20 > -- > Marco Tiloca > Ph.D., Senior Researcher >=20 > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) >=20 > Phone: +46 (0)70 60 46 501 > https://www.ri.se >=20 From nobody Fri Jan 8 10:18:57 2021 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 81FFE3A0AB9; Fri, 8 Jan 2021 10:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 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.262, 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 09MHehrSX0hM; Fri, 8 Jan 2021 10:18:47 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150080.outbound.protection.outlook.com [40.107.15.80]) (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 0DED33A0A26; Fri, 8 Jan 2021 10:18:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q/JWxxrkGfitb/EIfnsu8F0qV+SyIBzCGroILgvdweRNocuTz3k38LnsOaFZ9QEoVzmLq6EenHcWo4EGZCV1Y7aGL1IcjW2SPVUJ0JPt9HA/mvFmo5jgDi7f4vaVntiPk3eUXVdZs8fW1PHxYqsxdfztTWERAmVENwQKb3R8JqTLBKPeCKdw/Tj4MtMhB0pvVoaoF+zYsSNtBtJuv3XenkniZRassWoEi8AG4axGd6hy0g9aZDo82hMYlAt/lEg6FuJm7Fw+m+CEfW05tQLrORzJkI7z2DJlZAlTmP0j7WZZVw5bQqKFUGveNu0LQxxVlzR6ctDJnaIttrPjoqXCCA== 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=n4iV1gUxMb3ULTpjWyCuvaHWelEXekJ8Gqil7by7e9A=; b=YktrSCQtt2zTKmwXAqNChxQDhoJDXvyyexfFwPu+v7RmU/2FxWBDBkCsVtwo3WKmJxm6m7W+FItxvlmGaEaeESwLJSiF/4K0AFD9j2DV36Ka4g3mf5kZIh5pae7t3OHt8gSFnQtwSGrnSCJHz6kC1h+tlNJe43bROhFdrmgrVgTJ9BfJzGIr9WA+ND5PejO0ko+8STq+IOdnJGmD5NU+4v+1RRjYjMOM5yn8gNbESsSWkGKUqXnxaw5dzUFaDCVwQsY++LLc/iCKT+Mj3st1mYoNoPgmqLeuaP3fHBnzKbu9ukMesiuH8MkQpPrnjhTokTsIIlLuhDQ7SupIRcz1+g== 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=n4iV1gUxMb3ULTpjWyCuvaHWelEXekJ8Gqil7by7e9A=; b=iIFCYVWyazl0NgngtPHfG+HcJVsKl0Xdropi1guwWFQCJQodT1Rte1MResKW1RwGaiOn3txnhvefzUIx7qBBVB0cq/D7mEowrfLN0iJhbr2V2rRzFBm3bSsMWS7vLSSiwOwUCkhjEZpWAbGBWAuWd7av9EdUKS+HHVH3czQfcoI= 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 DB8P189MB0840.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Fri, 8 Jan 2021 18:18:37 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3742.010; Fri, 8 Jan 2021 18:18:37 +0000 To: supjps-ietf@jpshallow.com, christian@amsuess.com, draft-ietf-core-new-block@ietf.org Cc: dots@ietf.org, core@ietf.org References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> 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: Fri, 8 Jan 2021 19:18:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hdMRhfzo3fcM8r6qGFc8qRX57JYLqBwRz" X-Originating-IP: [37.120.209.204] X-ClientProxiedBy: HE1PR0502CA0024.eurprd05.prod.outlook.com (2603:10a6:3:e3::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.3.7] (37.120.209.204) by HE1PR0502CA0024.eurprd05.prod.outlook.com (2603:10a6:3:e3::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6 via Frontend Transport; Fri, 8 Jan 2021 18:18:36 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b98f1ee2-a104-4378-de6f-08d8b401d1aa X-MS-TrafficTypeDiagnostic: DB8P189MB0840: 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: I/vfODuCxu9gIBYb0JvehLft1nS6mo1r0xjsOOZAOjD8Ath5Jwkr3IRVWdRSZvD8Y4TsaVW03/vc6aWYqX41CLKGuGTYN7hw+QRWe4yHNUxSZM33AbPCMrn7ZrRxaXfjdNIjB1EXXZf6l7K3oRWJmKdjCV1FjjITmLSnfY/mVvqB1HcVcoZnsBUhxkiaS0OHw+rjGrG4DeINlxJKevbnWThSIBmqimkkUHpTUXhxPt38kFdHzN45ArZDN4GcC0Aw1Wl35J2uaQFYOpSbfff3g8WcVyqEnX6ruev5/wEXcLF9xUqMYvjR8lxjvd2kxgOT7b8YPS+FvkyOpEl/6Y09FRPxZjvlIgpGTE5FLTFh8dktxh5H1NG8cpqTbsg3UcxxAIDb2cWdofOREPuirLJ0TxdWS6FhvlNkH6HdA0tumHsgr2o2Ii/9S2GKWc5dNykB0GTDmwvE+okoR02xRRWtpdzyLOXpgbtAHseB+nE0rkMln7qmyV4IyTSEggdn6BhlGnHGGFBP8/yBV4vcPiqJpbmlFVr7xCG06u4o+1RrqI4F43E5j8pwGGPJZZ70qUtM 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)(396003)(136003)(346002)(376002)(31686004)(8936002)(52116002)(33964004)(66476007)(83380400001)(16576012)(2616005)(316002)(6666004)(235185007)(66946007)(2906002)(5660300002)(21480400003)(44832011)(66556008)(30864003)(8676002)(16526019)(86362001)(6486002)(186003)(26005)(66574015)(4326008)(45080400002)(36756003)(956004)(478600001)(53546011)(966005)(31696002)(45980500001)(43740500002)(579004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?Rm8yS2krSVVBZjZ0WStRQVJwbldEYVpFQWhGWlVSRFIvWGNVNFd2Nk8vTXBR?= =?utf-8?B?cEdZeDByS3V2TFFhK1ZhV0drdmZzWkV3dCtkck16eFRnMVFUK1BJNlBCcmdm?= =?utf-8?B?SE5LMWF4RUZ5UksyOGpvblUwSUFUUFV4dDlHaHZGNWJteHdFTXlLakc1cUJK?= =?utf-8?B?YkgzY3RBNlVsVFI4OW5XWkRzV3RWL0lkU0J3aGxJTEhMSUhROXZmUjkzc2Uy?= =?utf-8?B?VVdUWFZRQXlWRFRPeUR6WWZZdXJSV3dZRS9kVS9MemtFNmxkbHlBUGxySXdp?= =?utf-8?B?T2k4UXNEU2JTQytIcjJWQlhzb1JlbjVxbmNsQlk1NVJ2bVoyd2drejZIZWdp?= =?utf-8?B?a2xZZmw2THVhZzdLMCtWMDhrQTF3WkpFYXFHelZHQ1pBd202RW1pUFZQeDh3?= =?utf-8?B?L2pXRXRLRjN3YktGQVc4TmZkV0I3VlcvQTQ5dW4zWVRPdXZ3TmlrdDhwNFRU?= =?utf-8?B?UGJCY0NUSHBtb0xKVE1ReDlURXpQeXBZYytUbndTNiswcFhDN1hSS3hMUGpt?= =?utf-8?B?d2tDZkUwVnNYVkVOQWg1ODMxVFdZYVc1N0RlRVlVVkJXd1JqMitUUE82aEdv?= =?utf-8?B?SDVhQitHdTZKMGtHYXE2MTVMY3NQd25wTHpQcXg5VGpobmNjbkRUY05Gakxw?= =?utf-8?B?Y1p1bEVjVjMxdm51T1RCWk9FaUJZMkdrWXlyL1UxTUp5ZzY0cWhXeS9tNEts?= =?utf-8?B?QmlUMW1IeW5uMUIxTEt2QTRTY2Q0NmFTTHcwRlZpdENHaGFSUFdianpuU2tR?= =?utf-8?B?SWY3Z3BVUzFkZ0lwZnJOS3F6S3ZONU9pRXBTSWZKZnQ1NEVtclJMK0hpZHg3?= =?utf-8?B?cUswNG5mNnIycm00bUl2Rm1OVmw0SXNvcThVWllJZWVzd0Y2Y1lhTDFvSEpG?= =?utf-8?B?VUdiRW8xelBnQ21WbHU2SW05Z05OSllFTnZqTzVyc2ZNUWpHeWdOc2JxWFpt?= =?utf-8?B?V2FOWE5keWxFUmdDSWErQmhMVE9TUWtlSHV4Sng3VGpMeG5TRHZpdnVVYkl2?= =?utf-8?B?VkQ4SXc4NThjVVR6VVQvZ2c1RlVuVVJhY2R3OWNER0IrM3I1ZktIUDhtbWFR?= =?utf-8?B?WmsvWXQzK20wRDlZUzg1K2FCV0d5LzJ6dDVDRTlpZkpOMFJoNTk0ZHBVYnFj?= =?utf-8?B?dmxuZ0RjSE0zMjBYSHVOQXdSazlvMkpHVUw0MW4zcVcyZWpRbXlDazkya09W?= =?utf-8?B?dmZEMmIwNnVCdnhqd05HVHErQTN1T0pvQUVIQms5WTJ1K3FSeC80ZVlpRERh?= =?utf-8?B?SmxzdDVLQmczandaMzhld01xcDN2QXFJd2cva1F6Wi9iQ2NUcEd2dWtXTk55?= =?utf-8?Q?Bp7f43kAu6yA8lLqud9TtVG0AA6uKMu2WA?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2021 18:18:37.8224 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: b98f1ee2-a104-4378-de6f-08d8b401d1aa X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Y3mUITpRRS4dfnKJ5a6FGAn32HFNsuRVDfUWhFRaVmC9KxYoSFFS9Y/hKM7LVtvHTiP3HiEkD4CWZxrIGsktow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0840 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 08 Jan 2021 18:18:53 -0000 --hdMRhfzo3fcM8r6qGFc8qRX57JYLqBwRz Content-Type: multipart/mixed; boundary="eTGCNrk7azIPvB4yMHNEpBOBF0S2n2hNo" --eTGCNrk7azIPvB4yMHNEpBOBF0S2n2hNo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jon, On 2021-01-08 18:17, supjps-ietf@jpshallow.com wrote: > Hi Marco, > > Thanks for this. ~snips >> >> * Section 4 says: "The token to use ... any troubleshooting." >> >> Do you actually mean the highest block number received so far under= that >> Request-Tag, or the highest within the current set of MAX_PAYLOADS >> payloads for which the server is requesting some missing blocks? >> >> The new example in Section 5 seems to cover the latter, which I gue= ss is >> what you intend. > [Jon] Not sure that it really makes any difference. Have updated the t= ext to try to clarify > OLD > The token to use for the response SHOULD be the token that was used in = the highest block number received payload. Note that the use of any recei= ved token would work, but providing the one used in the highest received = block number will aid any troubleshooting. The client will use the token = to match the request to find what Request-Tag value is currently being us= ed. > NEW > The token to use for the response SHOULD be the token that was used in = the highest block number received so far with the same Request-Tag value.= Note that the use of any received token with the same Request-Tag would = work, but providing the one used in the highest received block number wil= l aid any troubleshooting. The client will use the token to determine wha= t is the previously sent request to obtain the Request-Tag value to be us= ed. =3D=3D>MT Looks better. To clarify, I meant Figure 5 (not Section 5), where the response with Message ID M:0x91 uses Token T:0xe0. That's matching with the request with Message ID M:0x19, i.e. the received payload with the highest block number *in the current MAX_PAYLOADS payload set* to be still completed. If the SHOULD above was followed, that response would have Token T:0xeb, to match with the one used in "the highest block number received so far", i.e. block number 10 in the request with Message ID M:0x1b. But as per the text above, either Token value is fine to use in the response, so the example is correct anyway. <=3D=3D >> - Figure 10, all responses should have ET=3D24 > [Jon] Fixed (I only found one) =3D=3D>MT The other occurrence is the very last response, with Message ID M:0x9b :-= ) Otherwise, it looks good to me. Thank you! Best, /Marco <=3D=3D > ~Jon >> >> Best, >> /Marco >> >> >> On 2021-01-08 14:33, supjps-ietf@jpshallow.com wrote: >>> Hi Marco, >>> >>> Thanks for this - and it is good to have another set of eyes checking= things >> through. >>> Updates have been pushed to >>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgi= th >>> ub.com%2Fcore-wg%2Fnew- >> block&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7 >> C2385ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e >> 8%7 >> C0%7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi >> MC4wLjAwMD >> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D >> LN79 >> Z8Ar4AICnpWDOFgkFi3g0Mwf72KPC0ewPW%2FZk3A%3D&reserved=3D0 >> and the >>> differences with the draft can be found at >>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >> w. >>> ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new- >> block%26url2%3Dhttps%3 >>> A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew- >> block%2Fmaster%2Fdraf >>> t-ietf-core-new- >> block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C23 >> 85ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8% >> 7C0% >> 7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 >> wLjAwMDAiL >> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DgIc >> 2vkC >>> 1XGtyGb17WSmby%2FO9wzA2bMaxDUsl3jmOAL4%3D&reserved=3D0 >>> >>> Otherwise, please see inline. >>> >>> Regards >>> >>> Jon >>> >>>> -----Original Message----- >>>> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >>>> Sent: 07 January 2021 12:17 >>>> To: supjps-ietf@jpshallow.com; christian@amsuess.com; >>>> draft-ietf-core-new- block@ietf.org >>>> Cc: dots@ietf.org; core@ietf.org >>>> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >>>> >>>> Hi, >>>> >>>> Thanks for this revision and for addressing my comments already in >>>> version -03. >>>> >>>> Please, see below some more comments on this version -04. >>>> >>>> Best, >>>> /Marco >>>> >>>> >>>> * s/There are one or more missing CBOR encoded missing block >>>> numbers./There are one or more CBOR encoded missing block numbers. >>> [Jon] Fixed. >>>> * Section 4 now includes the new paragraph: "The token to use for >>>> the response SHOULD be the token that was used in the highest block >>>> number received payload. The Q-Block1 Option from the same packet >>>> SHOULD be included." >>> [Jon] The Q-Block1 option actually is not needed as it can be derived= by >> the client from the remembered token (which is used to derive the >> Request-Tag. >>> OLD >>> The Q-Block1 Option from the same packet SHOULD be included. >>> NEW >>> The client will use the token to match the request to find what >>> Request-Tag value is currently being used. Providing the highest >>> received block number will aid any troubleshooting. >>> >>>> Consistently, the example in Figure 5 should also have >>>> QB1:3/0/1024 in the >>>> 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08 >>>> response with Token T:0xe4. >>> [Jon] No change now needed. >>>> Since "SHOULD" is used, when is it still fine or expected to not >>>> include Q- >>>> Block1 in a 4.08 response? >>> [Jon] Q-Block1 is no longer needed. >>>> * When commenting the example in Figure 5, Section 9.1 reads: "The >>>> Token just needs to be one of those that have been received for this= >>>> Request-Tag, so the client can derive the Request-Tag." >>>> >>>> Should this not be aligned with the SHOULD used in Section 4 abou= t >>>> using the Token from the same packet conveying the highest block >> number? >>> [Jon] Agreed >>>> You explained in your mail that the client keeps tracking all >>>> Tokens in the burst anyway, so maybe it's better to rather align the= >>>> text in Section 4 with what suggested here in Section 9.1, i.e. >>>> responding with any of those Token values is just fine. >>> [Jon] I think that it is useful for the client to have a hint about >>> what is the latest block number received even if it does not make use= >>> it - it may help in debugging from packet captures etc. which is why = I >> added in the SHOULD in section 4. So, I would prefer to align this wi= th >> section 4 OLD The Token just needs to be one of those that have been >> received for this >>> Request-Tag, so the client can derive the Request-Tag. >>> NEW >>> The token used in the response should be the token that was used in t= he >> highest block number received payload. The client can then derive the >> Request-Tag by matching the token with the sent request.. >>>> In such a case, the Q-Block1 option included in the 4.08 response= >>>> has still to be the one from the request conveying the highest block= >> number. >>>> Correct? >>> [Jon] We are now dropping the need for Q-Block1 in the response. >>>> * The new text in Section 6.2 says: "... and the situation >>>> re-evaluated for another 24 hour period until there is no report of >>>> missing payloads under normal operating conditions." >>>> >>>> When that happens, I suppose MAX_PAYLOADS is right away restored >>>> to the intended value, i.e. it is not incremented by 1 to start >>>> another 24-hour period evaluation. Correct? >>> [Jon] Updated for clarification >>> OLD >>> report of missing payloads under normal operating conditions.= Note >>> that the CoAP peer will not know about the MAX_PAYLOADS chang= e >>> until NEW >>> report of missing payloads under normal operating conditions.= The >> newly >>> derived value for MAX_PAYLOADS should be used for both ends o= f this >>> particular CoAP peer link. Note >>> that the CoAP peer will not know about the MAX_PAYLOADS chang= e >>> until >>>> * Section 6.2 says: "The request that the client sends to acknowledg= e >>>> the receipt of all the current set of MAX_PAYLOADS payloads SHOULD >>>> contain a special case Q-Block2 Option with NUM set to the first >>>> block of the next set of MAX_PAYLOADS payloads and the M bit set to = 1." >>>> >>>> Is it possible to reflect this in the example of Figure 6? It woul= d >>>> require the body to have more than MAX_PAYLOADS blocks thus >> resulting >>>> in more bursts, which would be inherited by the examples in Figure 7= and >> Figure 8. >>> [Jon] Examples updated to include this information >>>> * In Section 9, it would be good to have the parameters defined in >>>> Section >>>> 6.2 and their values reflected in the examples, when applicable. >>>> E.g., MAX_PAYLOADS is at least 4 in these examples; the asked >>>> retransmissions are presumably due sometimes to MAX_PAYLOADS >> compared >>>> against the value of the latest received Q-Block1/Q-Block2, while >>>> sometimes to NON_RECEIVE_TIMEOUT. >>> [Jon] Examples updated to include this information >>>> * In the example in Figure 6, shouldn't the first request from the >>>> client have the M bit set to 1 in the Q-Block2 option, i.e. as >>>> QB2:0/1/1024 ? As per Section 3.4, that would indicate that the >>>> request is in fact for the block 0 and for all of the remaining bloc= ks within >> the body. >>> [Jon] Good catch - corrected. >>> >>> ~Jon >>>> On 2021-01-06 16:24, supjps-ietf@jpshallow.com wrote: >>>>> Hi Christian, >>>>> >>>>> Once again, thank you for the comprehensive review. >>>>> >>>>> Responses part 2. A new version (-04) of the draft has been >>>>> published and can be found at >>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= t >>>> a >>>>> tracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new- >>>> block%2F&data=3D04%7C01 >>>> >> %7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a980 >>>> 9cf0 >>>> >> bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown >>>> %7CTWFpb >>>> >> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI >>>> 6Mn0 >>>> >> %3D%7C2000&sdata=3DMlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7j >>>> gTY%3D&am >>>>> p;reserved=3D0 >>>>> >>>>> >>>>> Part 1 responses were covered in the main by version -03, so you ma= y >>>>> want to look at the -02 to -04 differences. >>>>> >>>>> The Congestion Control section has been re-written to simplify how >>>>> things work and has a new set of definitions. There is a separation= >>>>> of Confirmable and Non-Confirmable Congestion Control with the >>>>> stated assumption that all of a body is sent as Non-Confirmable or >> Confirmable. >>>>> Otherwise, see inline. >>>>> >>>>> Regards >>>>> >>>>> Jon >>>>> >>>>>> * The list of pros and cons (with the cons being almost trivial) d= oes >>>>>> not explain to the reader why these are not a replacement; I sug= gest >>>>>> to add: >>>>> [Jon] Another disadvantage addition >>>>> NEW >>>>> To reduce the transmission times for CON transmission of large >>>>> bodies, NSTART needs to be increased from 1, but this affects >>>>> congestion control where other parameters need to be tuned (Sectio= n >>>>> 4.7 of [RFC7252]). Such tuning is out of scope of this document. >>>>> >>>>>> * "If the client transmits a new body of data with a new Request-T= ag >>>>>> to": Processing parallel requests is something Request-Tag opens= up. I >>>>>> don't see why there's a MUST to that; the server certainly MAY d= rop >>>>>> the old request, but it may just as well process them in paralle= l. >>>>> [Jon] The intent here was that garbage collection would take place >>>>> sooner than later - especially when running in a lossy environment >>>>> and the client has updated information to transmit. I agree that >>>>> Request-Tag enables the possibility of sending multiple block >>>>> requests with different payloads, and so there is a possibility tha= t >>>>> the client starts sending body A, then decides to send body B and >>>>> terminate A, but a packet from B arrives before a packet from body = A >>>>> is received and so >>>> things fail as A does not complete. >>>>> OLD >>>>> If the client transmits a new body of data with a new Request-Ta= g to >>>>> the same resource on a server, the server MUST remove any partia= lly >>>>> received body held for a previous Request-Tag for that resource.= >>>>> NEW >>>>> If a server receives payloads with different Request-Tags for the= >>>>> same resource, it should continue to process all the bodies as it >>>>> has no way of determining which is the latest version, or which >>>>> body, if any, the client is terminating the transmission for. >>>>> >>>>> If the client elects to stop the transmission of a complete body,= it >>>>> SHOULD "forget" all tracked tokens associated with the body's >>>>> Request-Tag so that a reset message is generated for the invalid >>>>> token in the 4.08 (Request Entity Incomplete) response. The server= >>>>> on receipt of the reset message SHOULD delete the partial body. >>>>> END >>>>> >>>>>> * "If the server receives a duplicate block with the same Request-= Tag": >>>>>> Why? Being silent is the default on nonterminal blocks alredy, b= ut in >>>>>> a situation like figure 5 if the 2.04 is lost, that rule would m= ake >>>>>> it impossible for the client to ever get a successful response. >>>>>> >>>>>> A better rule here may be to say that it processes it all the sa= me >>>>>> (and if the payload is distinct from the first transmission's pa= yload, >>>>>> it should err out.) >>>>> [Jon] Fair point >>>>> OLD >>>>> If the server receives a duplicate block with the same Request-T= ag, >>>>> it SHOULD silently ignore the packet. >>>>> NEW >>>>> If the server receives a duplicate block with the same Request-T= ag, >>>>> it SHOULD ignore the payload of the packet, but MUST still >>>>> respond as if the block was received for the first time. >>>>>> * "If the server receives multiple requests (implied or otherwise)= for >>>>>> the same block, it MUST only send back one instance of that bloc= k.": >>>>>> This might be read as "ever" rather than "per incoming request",= >> where >>>>>> probably the latter is meant. >>>>> [Jon] This text has already been updated following another review >>>>> "OLD If the server receives multiple requests >>>>> (implied or otherwise) for the same block, it MUST only send bac= k one >>>>> instance of that block. >>>>> NEW >>>>> If the request includes multiple Q-Block2 >>>>> Options and these options overlap (e.g., combination of M being = set >>>>> (this and all the later blocks) and being unset (this individual= >>>>> block)) resulting in an individual block being requested multipl= e >>>>> times, the server MUST only send back one instance of that block= =2E >>>>> This behavior is meant to prevent amplification attacks." >>>>> >>>>>> * "The ETag Option MUST NOT be used": This is more a factural than= a >>>>>> normative statement; it *can* not be used there as the server wo= uld >>>>>> respond thusly. It may be used, but then that indicates that the= >>>>>> client is trying to verify a freshness. (However, the client sho= uld >>>>>> not *start* sending an ETag once it learned the current resource= 's >>>>>> ETag when still attempting to pull out more blocks, but that's a= lso not >>>>>> a normative requirement but a consequence of those two requests >> not >>>>>> being matchable any more.) >>>>> [Jon] OK >>>>> OLD >>>>> The ETag Option MUST NOT be used in the request as the server co= uld >>>>> respond with a 2.03 (Valid Response) with no payload. If the se= rver >>>>> responds with a different ETag Option value (as the resource >>>>> representation has changed), then the client SHOULD drop all the= >>>>> payloads for the current body that are no longer valid. >>>>> NEW >>>>> The ETag Option should not be used in the request for missing >>>>> blocks as the server could respond with a 2.03 (Valid Response) wit= h >>>>> no payload. It can be used in the request if the client wants to >>>>> check the freshness of the currently cached body response. >>>>> >>>>> If the server detects part way through a body transfer that the >>>>> resource data has changed and the server is not maintaining a cache= d >>>>> copy of the old data, then the body response SHOULD be restarted >>>>> with a different ETag Option value. Any subsequent missing block >>>>> requests MUST respond using the latest ETag Option value. >>>>> >>>>> If the server responds during a body update with a different ETag >>>>> Option value (as the resource representation has changed), then the= >>>>> client should treat the partial body with the old ETag as no longer= >>>>> being >>>> fresh. >>>>> END >>>>>> * "then the client SHOULD drop all the payloads for the current bo= dy": >>>>>> "Drop" is overly prescriptive; the client may well keep them, bu= t >>>>>> just can't consider them fresh any more. (If the client has ampl= e >>>>>> caching abilities, they might come in handy if the resource goes= back >>>>>> to that ETag state). Same for later "the client MUST remove any >>>>>> partially received". >>>>> [Jon] See previous response, otherwise OLD >>>>> If the server transmits a new body of data (e.g., a triggered >>>>> Observe) with a new ETag to the same client as an additional >>>>> response, the client MUST remove any partially received body hel= d for >>>>> a previous ETag. >>>>> NEW >>>>> If the server transmits a new body of data (e.g., a triggered >>>>> Observe) with a new ETag to the same client as an additional >>>>> response, the client should remove any partially received body h= eld >> for >>>>> a previous ETag for that resource as it is unlikely the missing >>>>> blocks can be retrieved. >>>>>> * "For Confirmable transmission, the client SHOULD continue to": A= s >>>>>> above in the other direction, that's not news. >>>>> [Jon] Again, we are not looking for a response (well, a request in >>>>> this case as needed by Block2), just an ACK OLD >>>>> For Confirmable transmission, the client SHOULD continue to >>>>> acknowledge each packet as well as issuing a separate GET, POST,= PUT, >>>>> FETCH, PATCH, or iPATCH for the missing blocks. >>>>> NEW >>>>> For Confirmable transmission, the server continues to acknowledg= e >>>>> each packet, but a response is not required (whether separate or >>>>> piggybacked) until successful receipt of the body or, if some of = the >>>>> payloads are sent as Non-confirmable and have not arrived, a >>>>> retransmit missing payloads response is needed. >>>>>> * "If there is insufficient space to create a response PDU": I don= 't >>>>>> understand what that means. (Where are request options reflected= >>>>>> back?). >>>>> [Jon] This was triggered by a question by Michael Richardson " So, >>>>> given a Christmas-Tree-Packet (largest packet, every possible optio= n >>>>> space used, every extension turned on...) how much data can I get >>>>> back? :-)" and not fully thought through. >>>>> It could happen though with Location-Path, Location-Query, Q-Block2= , >>>>> ETag, >>>>> Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in >>>>> response to a POST. >>>>> OLD >>>>> If there is insufficient space to create a response PDU with a b= lock >>>>> size of 16 bytes (SZX =3D 0) to reflect back all the request opt= ions as >>>>> appropriate, a 4.13 (Request Entity Too Large) is returned witho= ut >>>>> the Size2 Option. >>>>> NEW >>>>> If there is insufficient space to create a response PDU with a b= lock >>>>> size of 16 bytes (SZX =3D 0) to send back all the response optio= ns as >>>>> appropriate, a 4.13 (Request Entity Too Large) is returned witho= ut >>>>> the Size1 Option. >>>>> >>>>>> * "If the client requests missing blocks, this is treated as a new= >>>>>> request.": I don't think the client should even make these foll= ow-up >>>>>> requests Observe, as it already has an ongoing observation. The= y'd be >>>>>> sent on a different token too, so setting Observe would be open= ing >>>>>> observation up on that token, which AFAIU is not intended. (Fig= ure 7 >>>>>> example looks good to me in that respect.) >>>>>> >>>>>> (It may make sense to ask the client to keep Observe to make th= e >>>>>> requests matchable just for the sake of staying in atomic-reque= st >>>>>> mode. Either way, the server should then not accept that observ= ation >>>>>> as it's not for a block 0.) >>>>> [Jon] The intent here was that just a new Token should be used. >>>>> OLD >>>>> If the client requests missing blocks, this is treated as a new >>>>> request. The Observe value may change but MUST still be reporte= d. >>>>> If the ETag value changes then the previously received partial b= ody >>>>> should be destroyed and the whole body re-requested. >>>>> NEW >>>>> If the client requests missing blocks, this is treated as a new >>>>> Request and the Observe Option MUST NOT be included. If the ET= ag >>>> value >>>>> changes, then the previously received partial body >>>>> should be considered as not fresh and the whole body re-requeste= d. >>>>> >>>>>> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response can= >> be >>>>>> matched by the token to a unique request that already had a >>>>>> Request-Tag, and the client needs to have kept that token around= >>>>>> matched to the transfer to make sense of it. >>>>>> >>>>>> No need to move that value around between subsystems, and just >>>>>> dropping it from here would also remove the need for the "If the= >>>>>> client does not recognize the Request-Tag" clause (which would >>>>>> otherwise need clarification as to what it'd mean if it recogniz= es it >>>>>> but it doesn't match what the request was for). >>>>> [Jon] Good question - it does make sense for the Request-Tag to be >>>>> tracked alongside the Token in the client. >>>>> OLD >>>>> The data payload of the 4.08 (Request Entity Incomplete) Respons= e >>>>> Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR enc= oded >>>>> Request-Tag followed by 1 or more missing CBOR encoded missing >> block >>>>> numbers. >>>>> NEW >>>>> The data payload of the 4.08 (Request Entity Incomplete) respons= e >>>>> is encoded as a CBOR Sequence [RFC8742]. There are one or more >>>> missing >>>>> CBOR encoded missing block numbers. >>>>> >>>>> OLD >>>>> ; This defines an array, the elements of which are to be use= d >>>>> ; in a CBOR Sequence: >>>>> payload =3D [request-tag, + missing-block-number] >>>>> request-tag =3D bstr >>>>> ; A unique block number not received: >>>>> missing-block-number =3D uint >>>>> NEW >>>>> ; This defines an array, the elements of which are to be use= d >>>>> ; in a CBOR Sequence: >>>>> payload =3D [+ missing-block-number] >>>>> request-tag =3D bstr >>>>> ; A unique block number not received: >>>>> missing-block-number =3D uint >>>>> >>>>> OLD >>>>> A 4.08 (Request Entity Incomplete) Response Code returned with >>>>> Content-Type "application/missing-blocks+cbor-seq" indicates tha= t >>>>> some of the payloads are missing and need to be resent. The cli= ent >>>>> then re-transmits the missing payloads using the Request-Tag and= >>>>> Q-Block1 to specify the block number, SZX, and M bit as appropri= ate. >>>>> The Request-Tag value to use is determined from the payload of t= he >>>>> 4.08 (Request Entity Incomplete) Response Code. If the client d= oes >>>>> not recognize the Request-Tag, the client can ignore this respon= se. >>>>> NEW (option presentation has been reformatted) >>>>> 4.08 (Request Entity Incomplete) >>>>> >>>>> This Response Code returned with Content-Type "application/ >>>>> missing-blocks+cbor-seq" indicates that some of the payloads are >>>>> missing and need to be resent. The client then retransmits the >>>>> missing payloads using the same Request-Tag, Size1 and Q-Block1 t= o >>>>> specify the block number, SZX, and M bit as appropriate. >>>>> >>>>> >>>>> The Request-Tag value to use is determined from the token in the >>>>> 4.08 (Request Entity Incomplete) response and then finding the >>>>> matching client request which contains the Request-Tag that is >>>>> being used for this Q-Block1 body. END >>>>>> * "limit the array count to 23 (Undefined value)": 23 is the maxim= um >>>>>> length of a zero-byte length indication, not indefinite-length (= 31). >>>>>> Both using 23 and 31 here makes sense (up to 23 to have definite= >>>>>> length that can be updated in-place, or exceeding that switch to= >>>>>> indefinite length if they still fit), but the paragraph seems to= be >>>>>> mixing them up. >>>>> [Jon] OK >>>>> OLD >>>>> Arrays (Section 3.2.2 of [RFC8949]), limit the array count to= 23 >>>>> (Undefined value) so that the array data byte can be updated = with >>>>> the overall length once the payload length is confirmed or li= mited >>>>> to MAX_PAYLOADS count. >>>>> NEW >>>>> Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit >>>>> the array count to >>>>> 23 so that the initial byte with the array major type and dat= a >>>>> length in the additional information can be updated with the overal= l >>>>> count once the payload count is confirmed. Further restricting the= >>>>> count to MAX_PAYLOADS means that congestion control is less likely >>>>> to be >>>> invoked on the server. >>>>>> * "Each new request MUST use a unique token": Like above, this is >>>>>> stating something that's not intended to be changed. >>>>> [Jon] RFC7252 does not require Tokens to be unique - e.g. empty >>>>> token values are acceptable. Hence this statement. >>>>>> Congestion Control: >>>>>> >>>>>> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is >>>> subjected >>>>>> to PROBING_RATE.": That is unexpected here. At most one such >>>>>> response is sent to each request message, so why is additional >>>>>> congestion control needed? >>>>> [Jon] The intention here was that in the previous paragraph that it= >>>>> was not the individual packets that are subject to PROBING_RATE, bu= t >>>>> a single body comprising of multiple packets is subject to >>>>> PROBRING_RATE >>>>> - and hence limiting any individual responses to PROBING_RATE rathe= r >>>>> than the potentially full set of responses OLD >>>>> PROBING_RATE parameter in CoAP indicates the average data rate t= hat >>>>> must not be exceeded by a CoAP endpoint in sending to a peer >> endpoint >>>>> that does not respond. The body of blocks will be subjected to >>>>> PROBING_RATE (Section 4.7 of [RFC7252]). >>>>> NEW >>>>> PROBING_RATE parameter in CoAP indicates the average data rate t= hat >>>>> must not be exceeded by a CoAP endpoint in sending to a peer >> endpoint >>>>> that does not respond. The single body of blocks will be subjec= ted to >>>>> PROBING_RATE (Section 4.7 of [RFC7252]), not the individual pack= ets. >>>>> If the wait time between sending bodies that are not being >>>>> responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, >>>> then the >>>>> gap time is limited to NON_PROBING_WAIT. >>>>> >>>>> Note: For the particular DOTS application, PROBING_RATE and other >>>>> transmission parameters are negotiated between peers. Even when >>>>> not negotiated, the DOTS application uses customized defaults as >>>>> discussed in Section 4.5.2 of [RFC8782]. >>>>> END >>>>>> On the other hand, *ever* NON request is subject to PROBING_RAT= E, >> so >>>>>> why point out the body of blocks and "GET or similar" particula= rly? >>>>> [Jon] It is only GET or FETCH. The intention here is to not reques= t >>>>> bodies of data at too high a rate. >>>>> OLD >>>>> Each NON GET or similar request using Q-Block2 Option is subject= ed to >>>>> PROBING_RATE. >>>>> NEW >>>>> Each NON GET or FETCH request using Q-Block2 Option is subjected= >>>>> to PROBING_RATE. >>>>>> * "a delay is introduced of ACK_TIMEOUT": As I understand >>>> MAX_PAYLOADS, >>>>>> this is (rather implicitly) introduced as the package count up t= o >>>>>> which it is OK to exceed PROBING_RATE temporarily (but after tha= t it >>>>>> kicks in all the harder by requiring to wait until complete-sent= -bytes >>>>>> over PROBING_RATE has expired). If that holds, at that time a mu= ch >>>>>> larger delay than just ACK_TIMEOUT is needed to get a response f= rom >>>>>> the server: About 3 hours (see later note on parameters). >>>>> [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re-write >>>>> of Congestion Control section. >>>>>> This is the crucial point in the document, and for it a recommen= dation >>>>>> alone is not good enough. The protocol can be run with a vastly >>>>>> increased PROBING_RATE (however externally determined) and from >>>> the >>>>>> point of MAX_PAYLOADS just observe it. Or it has to get feedback= >> from >>>>>> the server; a single 4.08 is probably enough to kick off another= >>>>>> vollley of blocks. (How many? MAX_PAYLOADS for every response?).= >>>>>> Both can be permitted, but just waiting ACK_TIMEOUT isn't doing = any >>>>>> good. >>>>> [Jon] See re-write of Congestion Control section where things shoul= d >>>>> now be simpler and more logical. There is an introduction of new >>>>> variable definitions. >>>>>> * "For NON transmissions": This seems to imply that the full excha= nge >> of >>>>>> a body is either NON or CON; I don't see where that'd come from.= I'd >>>>>> have expected to read something like "Each individual request ca= n be >>>>>> NON or CON independent of the others. In particular, it can be >>>>>> convenient to send the ultimate payload...". >>>>> [Jon]The DOTS environment will only be using NON. To make >>>>> Congestion Control simple, the expectation is that all transmission= s >>>>> are NON or (not recommended) are all CON. The draft now generally >>>>> records this expectation. >>>>>> * "If a Confirmable packet is used, then the transmitting peer MUS= T >> wait >>>>>> for the ACK": Why? A NSTART > 1 would give it leisure to still >>>>>> transmit. >>>>> [Jon] Text has been removed in the clean-up. >>>>>> * General on congestion control: It may help implementors if this = were >>>>>> split up into newly introduced rules and concepts (that is, >>>>>> MAX_PAYLOADS and the answer to whether you may send >>>> MAX_PAYLOADS en >>>>>> block again after having only even one response from the last ro= und, >>>>>> and probably the recommended parameters of the "Also on >>>> parameters" >>>>>> comment), and another subsection on how Q-Block behaves well >> when >>>>>> observing these. >>>>> [Jon] Should now be covered in the updated Congestion Control >> section. >>>>>> Caching: >>>>>> >>>>>> * "are not part of the cache key": How about "are removed as part = of >> the >>>>>> block assembly and thus do not reach the cache"? >>>>> [Jon] OK. >>>>> OLD >>>>> As the entire body is being cached in the proxy, the Q-Block1 an= d >>>>> Q-Block2 Options are not part of the cache key. >>>>> NEW >>>>> As the entire body is being cached in the proxy, the Q-Block1 an= d >>>>> Q-Block2 Options are removed as part of the block assembly and >>>>> thus do not reach the cache. >>>>>> * "When the next client completes building the body": If the proxy= >>>>>> chooses not to let them happen in parallel (which it may, see ab= ove >> on >>>>>> parallel requests, although the server might still not support i= t and >>>>>> cancel one of them), why bother letting the first finish just to= abort >>>>>> it? (IOW: If the proxy does not intend to see both through, whic= h it >>>>>> could if it held back the second until the first is through on t= he >>>>>> uplink, it could just as well err out of one of them early, but = it may >>>>>> also rather see both through.) >>>>> [Jon] It has to be assumed that traffic to/from the origin client >>>>> and origin server may not both support Q-Blockx and potentially may= >>>>> have a different SZX. Thus passing a request or a response through= >>>>> at the block level introduces a new set of challenges (but not >>>>> impossible to fix). To keep this simple, my thinking was that the >>>>> passing through can only take place at the body level. Again, the >>>>> arrival of packets is not necessarily sequential, so client A's bod= y >>>>> may start transmitting to the origin server first, but client B's >>>>> body starts to arrive first - the same being true for the proxy as = a >>>>> client may stop transmitting for whatever reason (restart, network = loss >> etc.). >>>>> However this is covered by the above update " If a server receives= >>>>> payloads with different Request-Tags for the same resource, it >>>>> should >>>> continue to process all the bodies". >>>>> OLD >>>>> and the new body representation transmission starts with a new >>>>> Request-Tag value. >>>>> NEW >>>>> and the new body representation transmission starts with a new >>>>> Request-Tag value. Note that it cannot be assumed that the prox= y >>>>> will always receive a complete body from a client. >>>>>> * Examples: >>>>>> >>>>>> * Figure 5: The ... between e3 request and response indicate the= >>>>>> MAX_TRANSMIT_SPAN before sending the 4.08 response. I suppose >>>> there >>>>>> should be the same kind of delay between the failed e5 transmi= ssion >>>>>> and the e4 response. >>>>> [Jon] Agreed and added in >>>>>> * If the second burst had 3 requests out of which 2 made it, is = there >>>>>> any guidance for which of them the 4.08 would come back on? (I= n the >>>>>> end, none of them is terminal). >>>>> [Jon] The client should tracking all Tokens of the burst (hence >>>>> implementation note about bottom 32bits unique and top 32 bits >>>>> matching block number for ease of tracking) for a response and so i= t >>>>> will make no difference at to which token is used for the 4.08 >>>>> response. From an implementation perspective, it probably is easie= r >>>>> to track the last opaque token that has the same Request-Tag. >>>>> OLD >>>>> missing ones in one go (Figure 5). It does so by indicating whi= ch >>>>> blocks have been received in the data portion of the response. >>>>> NEW >>>>> missing ones in one go (Figure 5). It does so by indicating whi= ch >>>>> blocks have been received in the data portion of the response. >>>>> The Token just needs to be one of those that have been received for= >>>>> this Request-Tag , so the client can derive the Request-Tag. >>>>>> * If that e4 response gets lost, does the whole mechanism recove= r >> from >>>>>> it in any way? >>>>> [Jon] In this example, if e4 and e5 get lost, there will be no >>>>> 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as to >>>>> whether it sends the request again or gives up. See 9.1 >>>>> "Under high levels of traffic loss, the client can elect not to r= etry >>>>> sending missing blocks of data. This decision is implementation= >>>>> specific." >>>>>> Generally, the all-NON and all-CON examples don't look to me l= ike >>>>>> what I'd be doing with this spec; the mixed "a CON every >>>>>> MAX_PAYLOADS" appears much more realistic. >>>>> [Jon] It is unsafe to use CON in the (potentially lossy) DOTS >>>>> environment (up to 93 secs timeout per payload with the defaults). >>>>> Hence why we are separating out the NON / CON usage. >>>>>> * Figure X: The request ahs M unset and thus indicats a request = for >>>>>> just that block. If more than one is expected, it should say >>>>>> QB2:0/1/1024. >>>>> [Jon] With Figure 7, with the M bit set, block 3 would get returned= >>>>> for a second time. Draft-ietf-core-new-block-03 also has a Figure = 8 >>>>> which does exactly what you describe. >>>>>> * New Content Format: I think this needs a media type registration= to >> go >>>>>> with it first; based on that, a content format can be registered= =2E >>>>> [Jon] Med has responded to this and draft updated. >>>>>> * General on MAX_TRANSMIT_SPAN and other timing parameters: I'm >> not >>>>>> sure >>>>>> they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is >>>> defined >>>>>> in terms of reliable transmission, but used for NONs as well. (S= o is >>>>>> the alternative ot 2x ACK_TIMEOUT). >>>>> [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and >> ACK_TIMEOUT >>>> in >>>>> a NON environment. Hence re-write of Congestion Control section >>>>> defining new variables that can be used for NON. >>>>>> For the purpose of delaying a 4.08 or a follow-up GET, it may ma= ke >>>>>> more sense to define a new parameter based on MAX_LATENCY and >> the >>>>>> time >>>>>> it takes the sender to pump out the options (which I don't think= we >>>>>> have a good factor for, but may even be negligible here). >>>>>> >>>>>> Could read like this: >>>>>> >>>>>> > The timing parameter MAX_BLOCK_JITTER is introduced, and by >>>> default >>>>>> > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / >>>> BANDWIDTH. >>>>> [Jon] Lets plug in some numbers here. MAX_LATENCY =3D 100, >>>>> MAX_PAYLOADS =3D 10, MTU =3D 1280bytes and BANDWIDTH =3D 1Mbps. >>>>> >>>>> [Jon] MAX_BLOCK_JITTER =3D 100 + (10 * 1280 * 8)/(1 000 000) =3D 10= 0.1. >>>>> So BANDWITH of 1Mbps has negligible effect on the calculation. 1Kbp= s >>>>> makes MAX_BLOCK_JITTER 200 seconds. >>>>>> > >>>>>> > With Q-Block2, a client can ask for any missing blocks after n= ot >>>>>> > having received any further response for the duration of >>>>>> > MAX_BLOCK_JITTER. >>>>> [Jon] 100+ seconds delay is way too much time to wait for any >>>>> missing blocks in my opinion. >>>>> >>>>> [Jon] RFC7252 also states (and the intention is that recovery works= >>>>> well) " as MAX_LATENCY is not >>>>> intended to describe a situation when the protocol works well= , but >>>>> the worst-case situation against which the protocol has to gu= ard." >>>>>> > >>>>>> > With Q-Block1, a server holds off any response for >> MAX_BLOCK_JITTER >>>>>> > unless all blocks have been received. Only then it evaluates >> whether >>>>>> > to respond with a 2.0x code, a 4.08 with payload, or not at al= l >>>>>> > (because it responded to a later request). >>>>> [Jon] I am not convinced that this is necessarily the way to go. >>>>> The new Congestion Control more cleanly handles this. >>>>>> This also brings me back to the earlier matter of 2.31: What is = a >>>>>> server supposed to send when no packages were lost, but it's pas= ing >>>>>> the timeout and wants to help the client flush out more packages= by >>>>>> confirming something? It says 4.08 in 3.3, but it's not like the= re's a >>>>>> hole in the contiguous range. Does it need to send 4.08 enumerat= ing >>>>>> all (or at least some) numbers between the first unreceived and >> what's >>>>>> indicated by Size1? Or can it just send 2.31 and the client know= s all >>>>>> it needs to know b/c the response came to the largest block that= was >>>>>> sent and 2.31 indicates that everything is good up to that point= ? >>>>> [Jon] The previous draft states (under Congestion Control) that the= >>>>> client waits for ACK_TIMEOUT before transmitting the next set of >>>>> MAX_PAYLOADS blocks. The server should wait for "two times >>>>> ACK_TIMEOUT " (3.3) before indicating issue. Apart from perhaps >>>>> having a new name for ACK_TIMOUT I think that these are reasonable >>>>> values for Non-Confirmable - and are used in the new Congestion >>>>> Control >>>> section. >>>>> [Jon] I have reworked Congestion Control to use 2.31 (NON only) as = a >>>>> signal to say that all of the current MAX_PAYLOADS payloads of a >>>>> body have been received, so allowing the client to continue >>>>> transmitting the next set of MAX_PAYLOADS payloads without the need= >>>>> to wait any >>>> longer. >>>>>> * Also on parameters: This document is describing flow control stu= ff >>>>>> around a situation CoAP was not originally designed for. Wouldn'= t it >>>>>> make sense to include a set of parameters (PROBING_RATE, >>>> MAX_LATENCY, >>>>>> ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that= >>>>>> PROBING_RATE will be left to 1 byte/second for any DOTS applicat= ion >>>>>> using this (for sending 10KiB in the initial 10-package MAX_PAYL= OADS >>>>>> burst would mark that connection as unusable for about 3 hours i= f >> they >>>>>> all get lost), so better give justifiable numbers here than rely= on >>>>>> implemnetors to come up with unreviewed numbers or disregard >>>>>> PROBING_RATE altogether. >>>>> [Jon] Answered by Med, and some new text added. >>>>>> I don't know if it needs additional justification, but an increa= sed >>>>>> N_START may be justifiable there. >>>>> [Jon] It may be, but tuning the other associated parameters is >>>>> really out of the cope of this draft. This text has been added NEW >>>>> Congestion control for CON requests and responses is specified in >>>>> Section 4.7 of [RFC7252]. For faster transmission rates, NSTART wi= ll >>>>> need to be increased from 1. However, the other CON congestion >>>>> control parameters will need to be tuned to cover this change. T= his >>>>> tuning is out of scope of this document as it is expected that al= l >>>>> requests and responses using Q-Block1 and Q-Block2 will be Non- >>>>> confirmable. >>>>>> * Somewhere (never comes up but I think it should): When CONs are >>>> used, >>>>>> a 4.08 (or 2.31?) response to a later request can indicate to th= e >>>>>> client that an earlier CON request has been processed successful= ly. If >>>>>> the client can match that up (and it should be able to), then it= can >>>>>> (and should) cancel that particular CON request. >>>>> [Jon] I think that this is covered by my update above with the text= " >>>>> NEW >>>>> For Confirmable transmission, the server continues to acknowledg= e >>>>> each packet, but a response is not required (whether separate or >>>>> piggybacked) until successful receipt of the body or, if some of = the >>>>> payloads are sent as Non-confirmable and have not arrived, a >>>>> retransmit missing payloads response is needed." >>>>> >>>>> And in my previous part 1 response (updated) NEW For Confirmable >>>>> transmission, the server continues to acknowledge each packet, but= >>>>> a response is not required (whether separate or >>>>> piggybacked) until successful receipt of the body or, if some of t= he >>>>> payloads are sent as Non-confirmable and have not arrived, a >>>>> retransmit missing payloads response is needed. >>>>>> Best regards >>>>>> Christian >>>>>> >>>>>> -- >>>>>> There's always a bigger fish. >>>>>> -- Qui-Gon Jinn >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >>>> w. >>>> >> ietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloc >>>> a%4 >>>> >> 0ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09 >>>> ecc4 >>>> >> 0cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8 >>>> eyJWIjoiMC >>>> >> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000& >>>> amp;sd >>>> >> ata=3DtEJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&reserved=3D0 >>>> -- >>>> 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://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >> w >> .ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7 >> c8 >> 1f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637 >> 45709 >> 6666457035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj >> oiV2luMz >> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DiJgJcxZmwbaLrb >> mzIuz >>>> SjezxDRq47wwWcNvFC7ox8bw%3D&reserved=3D0 >>>> >> -- >> 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://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C8651a6788136434842= 2608d8b3f94057%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374572308622= 39405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI= 6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3Dpo%2BnNJAbUW7Jf9cMFxoP8VXDd1%2= FfS%2BsyTl4dePY5A9o%3D&reserved=3D0 >> > --=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 --eTGCNrk7azIPvB4yMHNEpBOBF0S2n2hNo-- --hdMRhfzo3fcM8r6qGFc8qRX57JYLqBwRz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/4ofYACgkQ7iZktA5Y 2kM74QgAoiIMg+FOMHyDlHjlnsv/HX8jjxPKYfllQhH215i3LbuGKpnXH9DSQibk 4lsffuJVpBf4q0ZdRYcBeYF2XOHqlf+GmEk5q12zrN5ZuLZLBszXdIO1QUtBZKqj gSkii3Yg3buKqF7jS/s/jEvFQWzfGKx2ojmBBhFhD8Gp6EHUbet4LUFDNE2v4qCl h5FoOA0mXJuHr5kwfz6bEW2bYaklYIJ8yfr2i1fS+uLf+kCWvvKfc9r8YLQzOpCf 6j/9BgFFmDu8yn0i5gcCBUqqMpVdghdOixkVvJL5u8jQy0zxMXNJlzVwhZCQUOJf i0HVEULA967NhiZS5JMCnuRNrfY+Ag== =OSUY -----END PGP SIGNATURE----- --hdMRhfzo3fcM8r6qGFc8qRX57JYLqBwRz-- From nobody Fri Jan 8 11:01:07 2021 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 CD0373A0AD3; Fri, 8 Jan 2021 11:01:05 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 KMTHjetwypt3; Fri, 8 Jan 2021 11:01:04 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE5A3A09D7; Fri, 8 Jan 2021 11:01:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6DAD56601C1; Fri, 8 Jan 2021 21:01:03 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xw0eto2cRemt; Fri, 8 Jan 2021 21:01:02 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 3DF1E66012A; Fri, 8 Jan 2021 21:01:02 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Fri, 8 Jan 2021 21:01:01 +0200 Cc: "iot-directorate@ietf.org" , draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org, last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> <7BE43FEF-DA33-4B40-9DA7-E646C60CB600@piuha.net> To: Russ Housley X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 08 Jan 2021 19:01:06 -0000 Hi Russ, > I am still unsure what an implementer would do to comply the MUST NOT = statement. Maybe it will helpful to turn it into a MUST statement. = Does this work for you? >=20 > On most devices, the user can display device identifiers. Depending > on circumstances, device identifiers may or may not be modified or > tampered with by the user. An implementation of the DEV URN MUST = preserve > such limitations and behaviors associated with the device identifiers. = In particular, > a device identifier that is intended to be immutable should not become = mutable > as a part of implementing the DEV URN type. More generally, nothing in > this document should be construed to override what the relevant device > specifications have already said about the identifiers. That sounds very good. Thanks! Updated in the draft. Jari From nobody Fri Jan 8 12:21:13 2021 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 E9B723A1288; Fri, 8 Jan 2021 12:21:12 -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_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 gE1lKa-85c7k; Fri, 8 Jan 2021 12:21:11 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95483A1286; Fri, 8 Jan 2021 12:21:11 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 124FCF4071C; Fri, 8 Jan 2021 12:21:06 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, core@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20210108202106.124FCF4071C@rfc-editor.org> Date: Fri, 8 Jan 2021 12:21:06 -0800 (PST) Archived-At: Subject: [core] =?utf-8?q?RFC_8974_on_Extended_Tokens_and_Stateless_Clien?= =?utf-8?q?ts_in_the_Constrained_Application_Protocol_=28CoAP=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: Fri, 08 Jan 2021 20:21:13 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8974 Title: Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) Author: K. Hartke, M. Richardson Status: Standards Track Stream: IETF Date: January 2021 Mailbox: klaus.hartke@ericsson.com, mcr+ietf@sandelman.ca Pages: 20 Updates: RFC 7252, RFC 8323 I-D Tag: draft-ietf-core-stateless-08.txt URL: https://www.rfc-editor.org/info/rfc8974 DOI: 10.17487/RFC8974 This document provides considerations for alleviating Constrained Application Protocol (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. This document is a product of the Constrained RESTful Environments Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Jan 11 00:51:29 2021 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 AE4153A170E; Mon, 11 Jan 2021 00:51:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christer Holmberg via Datatracker To: Cc: core@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161035508766.18664.12189712389925734779@ietfa.amsl.com> Reply-To: Christer Holmberg Date: Mon, 11 Jan 2021 00:51:27 -0800 Archived-At: Subject: [core] Genart telechat review of draft-ietf-core-dev-urn-09 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, 11 Jan 2021 08:51:28 -0000 Reviewer: Christer Holmberg Review result: Ready 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-core-dev-urn-09 Reviewer: Christer Holmberg Review Date: 2021-01-11 IETF LC End Date: 2020-12-02 IESG Telechat date: 2021-01-21 Summary: The issues I raised in my previous Gen-ART review have been resolved, and the document is now ready for publication. Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A From nobody Mon Jan 11 02:33:09 2021 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 CA9893A09BB for ; Mon, 11 Jan 2021 02:33:08 -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 v-ylfTlsF0HN for ; Mon, 11 Jan 2021 02:33:04 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 8900C3A09B7 for ; Mon, 11 Jan 2021 02:33:03 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kyuVP-0006MA-Ra; Mon, 11 Jan 2021 10:33:00 +0000 From: To: "Marco Tiloca" , , Cc: , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> In-Reply-To: Date: Mon, 11 Jan 2021 10:33:10 -0000 Message-ID: <065301d6e805$286163c0$79242b40$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAFUavWxAaeeZ2wB9CJyVQGW5zMSAr51FjWocxRxUA== Content-Language: en-gb Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 11 Jan 2021 10:33:09 -0000 Hi Marco, The new updates have been pushed to https://github.com/core-wg/new-block = and the differences with the draft can be found at = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-new-block&url2=3Dhttp= s://raw.githubusercontent.com/core-wg/new-block/master/draft-ietf-core-ne= w-block.txt The PR for the responses below can be found at = https://github.com/core-wg/new-block/pull/12 (a couple of minor nits = fixed since then which are in master) Otherwise lease see inline. Regards Jon > -----Original Message----- > From: Marco Tiloca [mailto: marco.tiloca@ri.se] > Sent: 08 January 2021 18:19 > To:supjps-ietf@jpshallow.com; christian@amsuess.com; = draft-ietf-core-new- > block@ietf.org > Cc: dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hi Jon, >=20 > On 2021-01-08 18:17, supjps-ietf@jpshallow.com wrote: > > Hi Marco, > > > > Thanks for this. >=20 > ~snips >=20 > >> > >> * Section 4 says: "The token to use ... any troubleshooting." > >> > >> Do you actually mean the highest block number received so far > >> under that Request-Tag, or the highest within the current set of > >> MAX_PAYLOADS payloads for which the server is requesting some > missing blocks? > >> > >> The new example in Section 5 seems to cover the latter, which I > >> guess is what you intend. > > [Jon] Not sure that it really makes any difference. Have updated = the > > text to try to clarify OLD The token to use for the response SHOULD = be > > the token that was used in the highest block number received = payload. > Note that the use of any received token would work, but providing the = one > used in the highest received block number will aid any = troubleshooting. The > client will use the token to match the request to find what = Request-Tag > value is currently being used. > > NEW > > The token to use for the response SHOULD be the token that was used = in > the highest block number received so far with the same Request-Tag = value. > Note that the use of any received token with the same Request-Tag = would > work, but providing the one used in the highest received block number = will > aid any troubleshooting. The client will use the token to determine = what is > the previously sent request to obtain the Request-Tag value to be = used. >=20 > =3D=3D>MT > Looks better. >=20 > To clarify, I meant Figure 5 (not Section 5), where the response with > Message ID M:0x91 uses Token T:0xe0. That's matching with the request > with Message ID M:0x19, i.e. the received payload with the highest = block > number *in the current MAX_PAYLOADS payload set* to be still = completed. >=20 > If the SHOULD above was followed, that response would have Token = T:0xeb, > to match with the one used in "the highest block number received so = far", > i.e. block number 10 in the request with Message ID M:0x1b. >=20 > But as per the text above, either Token value is fine to use in the = response, > so the example is correct anyway. [Jon] Changed highest to last (to simplify things), updated the examples = accordingly. Updated 2.01,2.04 and 2.31 code with which token to use. > <=3D=3D >=20 > >> - Figure 10, all responses should have ET=3D24 > > [Jon] Fixed (I only found one) >=20 > =3D=3D>MT > The other occurrence is the very last response, with Message ID M:0x9b = :-) [Jon] Got it - And M:0x9b updated to M:0xc3 to be consistent. ~Jon >=20 >=20 > Otherwise, it looks good to me. Thank you! >=20 > Best, > /Marco > <=3D=3D >=20 > > ~Jon > >> > >> Best, > >> /Marco > >> > >> > >> On 2021-01-08 14:33, supjps-ietf@jpshallow.com wrote: > >>> Hi Marco, > >>> > >>> Thanks for this - and it is good to have another set of eyes > >>> checking things > >> through. > >>> Updates have been pushed to > >>> > >> > = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgit > >> h > >>> ub.com%2Fcore-wg%2Fnew- > >> block&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7 > >> > C2385ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e > >> 8%7 > >> > C0%7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > >> MC4wLjAwMD > >> > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D > >> LN79 > >> > Z8Ar4AICnpWDOFgkFi3g0Mwf72KPC0ewPW%2FZk3A%3D&reserved=3D0 > >> and the > >>> differences with the draft can be found at > >>> > >> > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > >> w. > >>> ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new- > >> block%26url2%3Dhttps%3 > >>> A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew- > >> block%2Fmaster%2Fdraf > >>> t-ietf-core-new- > >> block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C23 > >> > 85ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8% > >> 7C0% > >> > 7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > >> wLjAwMDAiL > >> > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DgIc > >> 2vkC > >>> 1XGtyGb17WSmby%2FO9wzA2bMaxDUsl3jmOAL4%3D&reserved=3D0 > >>> > >>> Otherwise, please see inline. > >>> > >>> Regards > >>> > >>> Jon > >>> > >>>> -----Original Message----- > >>>> From: Marco Tiloca [mailto: marco.tiloca@ri.se] > >>>> Sent: 07 January 2021 12:17 > >>>> To: supjps-ietf@jpshallow.com; christian@amsuess.com; > >>>> draft-ietf-core-new- block@ietf.org > >>>> Cc: dots@ietf.org; core@ietf.org > >>>> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block > >>>> > >>>> Hi, > >>>> > >>>> Thanks for this revision and for addressing my comments already = in > >>>> version -03. > >>>> > >>>> Please, see below some more comments on this version -04. > >>>> > >>>> Best, > >>>> /Marco > >>>> > >>>> > >>>> * s/There are one or more missing CBOR encoded missing block > >>>> numbers./There are one or more CBOR encoded missing block > numbers. > >>> [Jon] Fixed. > >>>> * Section 4 now includes the new paragraph: "The token to use = for > >>>> the response SHOULD be the token that was used in the highest = block > >>>> number received payload. The Q-Block1 Option from the same = packet > >>>> SHOULD be included." > >>> [Jon] The Q-Block1 option actually is not needed as it can be > >>> derived by > >> the client from the remembered token (which is used to derive the > >> Request-Tag. > >>> OLD > >>> The Q-Block1 Option from the same packet SHOULD be included. > >>> NEW > >>> The client will use the token to match the request to find what > >>> Request-Tag value is currently being used. Providing the highest > >>> received block number will aid any troubleshooting. > >>> > >>>> Consistently, the example in Figure 5 should also have > >>>> QB1:3/0/1024 in the > >>>> 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08 > >>>> response with Token T:0xe4. > >>> [Jon] No change now needed. > >>>> Since "SHOULD" is used, when is it still fine or expected to = not > >>>> include Q- > >>>> Block1 in a 4.08 response? > >>> [Jon] Q-Block1 is no longer needed. > >>>> * When commenting the example in Figure 5, Section 9.1 reads: = "The > >>>> Token just needs to be one of those that have been received for > >>>> this Request-Tag, so the client can derive the Request-Tag." > >>>> > >>>> Should this not be aligned with the SHOULD used in Section 4 > >>>> about using the Token from the same packet conveying the highest > >>>> block > >> number? > >>> [Jon] Agreed > >>>> You explained in your mail that the client keeps tracking all > >>>> Tokens in the burst anyway, so maybe it's better to rather align > >>>> the text in Section 4 with what suggested here in Section 9.1, = i.e. > >>>> responding with any of those Token values is just fine. > >>> [Jon] I think that it is useful for the client to have a hint = about > >>> what is the latest block number received even if it does not make > >>> use it - it may help in debugging from packet captures etc. which = is > >>> why I > >> added in the SHOULD in section 4. So, I would prefer to align this > >> with section 4 OLD The Token just needs to be one of those that = have > >> been received for this > >>> Request-Tag, so the client can derive the Request-Tag. > >>> NEW > >>> The token used in the response should be the token that was used = in > >>> the > >> highest block number received payload. The client can then derive = the > >> Request-Tag by matching the token with the sent request.. > >>>> In such a case, the Q-Block1 option included in the 4.08 > >>>> response has still to be the one from the request conveying the > >>>> highest block > >> number. > >>>> Correct? > >>> [Jon] We are now dropping the need for Q-Block1 in the response. > >>>> * The new text in Section 6.2 says: "... and the situation > >>>> re-evaluated for another 24 hour period until there is no report = of > >>>> missing payloads under normal operating conditions." > >>>> > >>>> When that happens, I suppose MAX_PAYLOADS is right away = restored > >>>> to the intended value, i.e. it is not incremented by 1 to start > >>>> another 24-hour period evaluation. Correct? > >>> [Jon] Updated for clarification > >>> OLD > >>> report of missing payloads under normal operating = conditions. Note > >>> that the CoAP peer will not know about the MAX_PAYLOADS > >>> change until NEW > >>> report of missing payloads under normal operating > >>> conditions. The > >> newly > >>> derived value for MAX_PAYLOADS should be used for both = ends of > this > >>> particular CoAP peer link. Note > >>> that the CoAP peer will not know about the MAX_PAYLOADS > >>> change until > >>>> * Section 6.2 says: "The request that the client sends to > >>>> acknowledge the receipt of all the current set of MAX_PAYLOADS > >>>> payloads SHOULD contain a special case Q-Block2 Option with NUM = set > >>>> to the first block of the next set of MAX_PAYLOADS payloads and = the M > bit set to 1." > >>>> > >>>> Is it possible to reflect this in the example of Figure 6? It > >>>> would require the body to have more than MAX_PAYLOADS blocks thus > >> resulting > >>>> in more bursts, which would be inherited by the examples in = Figure > >>>> 7 and > >> Figure 8. > >>> [Jon] Examples updated to include this information > >>>> * In Section 9, it would be good to have the parameters defined = in > >>>> Section > >>>> 6.2 and their values reflected in the examples, when applicable. > >>>> E.g., MAX_PAYLOADS is at least 4 in these examples; the asked > >>>> retransmissions are presumably due sometimes to MAX_PAYLOADS > >> compared > >>>> against the value of the latest received Q-Block1/Q-Block2, while > >>>> sometimes to NON_RECEIVE_TIMEOUT. > >>> [Jon] Examples updated to include this information > >>>> * In the example in Figure 6, shouldn't the first request from = the > >>>> client have the M bit set to 1 in the Q-Block2 option, i.e. as > >>>> QB2:0/1/1024 ? As per Section 3.4, that would indicate that the > >>>> request is in fact for the block 0 and for all of the remaining > >>>> blocks within > >> the body. > >>> [Jon] Good catch - corrected. > >>> > >>> ~Jon > >>>> On 2021-01-06 16:24, supjps-ietf@jpshallow.com wrote: > >>>>> Hi Christian, > >>>>> > >>>>> Once again, thank you for the comprehensive review. > >>>>> > >>>>> Responses part 2. A new version (-04) of the draft has been > >>>>> published and can be found at > >>>>> > >> > = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdat > >>>> a > >>>>> tracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new- > >>>> block%2F&data=3D04%7C01 > >>>> > >> > %7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a980 > >>>> 9cf0 > >>>> > >> > bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown > >>>> %7CTWFpb > >>>> > >> > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > >>>> 6Mn0 > >>>> > >> > %3D%7C2000&sdata=3DMlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7j > >>>> gTY%3D&am > >>>>> p;reserved=3D0 > >>>>> > >>>>> > >>>>> Part 1 responses were covered in the main by version -03, so you > >>>>> may want to look at the -02 to -04 differences. > >>>>> > >>>>> The Congestion Control section has been re-written to simplify = how > >>>>> things work and has a new set of definitions. There is a > >>>>> separation of Confirmable and Non-Confirmable Congestion Control > >>>>> with the stated assumption that all of a body is sent as > >>>>> Non-Confirmable or > >> Confirmable. > >>>>> Otherwise, see inline. > >>>>> > >>>>> Regards > >>>>> > >>>>> Jon > >>>>> > >>>>>> * The list of pros and cons (with the cons being almost = trivial) does > >>>>>> not explain to the reader why these are not a replacement; I > suggest > >>>>>> to add: > >>>>> [Jon] Another disadvantage addition NEW To reduce the = transmission > >>>>> times for CON transmission of large bodies, NSTART needs to be > >>>>> increased from 1, but this affects congestion control where = other > >>>>> parameters need to be tuned (Section > >>>>> 4.7 of [RFC7252]). Such tuning is out of scope of this = document. > >>>>> > >>>>>> * "If the client transmits a new body of data with a new = Request-Tag > >>>>>> to": Processing parallel requests is something Request-Tag = opens > up. I > >>>>>> don't see why there's a MUST to that; the server certainly = MAY drop > >>>>>> the old request, but it may just as well process them in = parallel. > >>>>> [Jon] The intent here was that garbage collection would take = place > >>>>> sooner than later - especially when running in a lossy = environment > >>>>> and the client has updated information to transmit. I agree that > >>>>> Request-Tag enables the possibility of sending multiple block > >>>>> requests with different payloads, and so there is a possibility > >>>>> that the client starts sending body A, then decides to send body = B > >>>>> and terminate A, but a packet from B arrives before a packet = from > >>>>> body A is received and so > >>>> things fail as A does not complete. > >>>>> OLD > >>>>> If the client transmits a new body of data with a new = Request-Tag to > >>>>> the same resource on a server, the server MUST remove any = partially > >>>>> received body held for a previous Request-Tag for that = resource. > >>>>> NEW > >>>>> If a server receives payloads with different Request-Tags for > >>>>> the same resource, it should continue to process all the bodies = as > >>>>> it has no way of determining which is the latest version, or = which > >>>>> body, if any, the client is terminating the transmission for. > >>>>> > >>>>> If the client elects to stop the transmission of a complete = body, it > >>>>> SHOULD "forget" all tracked tokens associated with the body's > >>>>> Request-Tag so that a reset message is generated for the invalid > >>>>> token in the 4.08 (Request Entity Incomplete) response. The > >>>>> server on receipt of the reset message SHOULD delete the partial > body. > >>>>> END > >>>>> > >>>>>> * "If the server receives a duplicate block with the same = Request- > Tag": > >>>>>> Why? Being silent is the default on nonterminal blocks = alredy, but > in > >>>>>> a situation like figure 5 if the 2.04 is lost, that rule = would make > >>>>>> it impossible for the client to ever get a successful = response. > >>>>>> > >>>>>> A better rule here may be to say that it processes it all the = same > >>>>>> (and if the payload is distinct from the first transmission's = payload, > >>>>>> it should err out.) > >>>>> [Jon] Fair point > >>>>> OLD > >>>>> If the server receives a duplicate block with the same = Request-Tag, > >>>>> it SHOULD silently ignore the packet. > >>>>> NEW > >>>>> If the server receives a duplicate block with the same = Request-Tag, > >>>>> it SHOULD ignore the payload of the packet, but MUST still > >>>>> respond as if the block was received for the first time. > >>>>>> * "If the server receives multiple requests (implied or = otherwise) for > >>>>>> the same block, it MUST only send back one instance of that = block.": > >>>>>> This might be read as "ever" rather than "per incoming > >>>>>> request", > >> where > >>>>>> probably the latter is meant. > >>>>> [Jon] This text has already been updated following another = review > >>>>> "OLD If the server receives multiple requests > >>>>> (implied or otherwise) for the same block, it MUST only send = back > one > >>>>> instance of that block. > >>>>> NEW > >>>>> If the request includes multiple Q-Block2 > >>>>> Options and these options overlap (e.g., combination of M = being set > >>>>> (this and all the later blocks) and being unset (this = individual > >>>>> block)) resulting in an individual block being requested = multiple > >>>>> times, the server MUST only send back one instance of that = block. > >>>>> This behavior is meant to prevent amplification attacks." > >>>>> > >>>>>> * "The ETag Option MUST NOT be used": This is more a factural = than a > >>>>>> normative statement; it *can* not be used there as the server > would > >>>>>> respond thusly. It may be used, but then that indicates that = the > >>>>>> client is trying to verify a freshness. (However, the client = should > >>>>>> not *start* sending an ETag once it learned the current = resource's > >>>>>> ETag when still attempting to pull out more blocks, but = that's also > not > >>>>>> a normative requirement but a consequence of those two = requests > >> not > >>>>>> being matchable any more.) > >>>>> [Jon] OK > >>>>> OLD > >>>>> The ETag Option MUST NOT be used in the request as the server > could > >>>>> respond with a 2.03 (Valid Response) with no payload. If the = server > >>>>> responds with a different ETag Option value (as the resource > >>>>> representation has changed), then the client SHOULD drop all = the > >>>>> payloads for the current body that are no longer valid. > >>>>> NEW > >>>>> The ETag Option should not be used in the request for missing > >>>>> blocks as the server could respond with a 2.03 (Valid Response) > >>>>> with no payload. It can be used in the request if the client = wants > >>>>> to check the freshness of the currently cached body response. > >>>>> > >>>>> If the server detects part way through a body transfer that the > >>>>> resource data has changed and the server is not maintaining a > >>>>> cached copy of the old data, then the body response SHOULD be > >>>>> restarted with a different ETag Option value. Any subsequent > >>>>> missing block requests MUST respond using the latest ETag Option > value. > >>>>> > >>>>> If the server responds during a body update with a different = ETag > >>>>> Option value (as the resource representation has changed), then > >>>>> the client should treat the partial body with the old ETag as no > >>>>> longer being > >>>> fresh. > >>>>> END > >>>>>> * "then the client SHOULD drop all the payloads for the current > body": > >>>>>> "Drop" is overly prescriptive; the client may well keep them, = but > >>>>>> just can't consider them fresh any more. (If the client has = ample > >>>>>> caching abilities, they might come in handy if the resource = goes > back > >>>>>> to that ETag state). Same for later "the client MUST remove = any > >>>>>> partially received". > >>>>> [Jon] See previous response, otherwise OLD > >>>>> If the server transmits a new body of data (e.g., a triggered > >>>>> Observe) with a new ETag to the same client as an additional > >>>>> response, the client MUST remove any partially received body = held > for > >>>>> a previous ETag. > >>>>> NEW > >>>>> If the server transmits a new body of data (e.g., a triggered > >>>>> Observe) with a new ETag to the same client as an additional > >>>>> response, the client should remove any partially received = body > >>>>> held > >> for > >>>>> a previous ETag for that resource as it is unlikely the = missing > >>>>> blocks can be retrieved. > >>>>>> * "For Confirmable transmission, the client SHOULD continue = to": As > >>>>>> above in the other direction, that's not news. > >>>>> [Jon] Again, we are not looking for a response (well, a request = in > >>>>> this case as needed by Block2), just an ACK OLD > >>>>> For Confirmable transmission, the client SHOULD continue to > >>>>> acknowledge each packet as well as issuing a separate GET, = POST, > PUT, > >>>>> FETCH, PATCH, or iPATCH for the missing blocks. > >>>>> NEW > >>>>> For Confirmable transmission, the server continues to = acknowledge > >>>>> each packet, but a response is not required (whether separate = or > >>>>> piggybacked) until successful receipt of the body or, if some = of the > >>>>> payloads are sent as Non-confirmable and have not arrived, a > >>>>> retransmit missing payloads response is needed. > >>>>>> * "If there is insufficient space to create a response PDU": I = don't > >>>>>> understand what that means. (Where are request options = reflected > >>>>>> back?). > >>>>> [Jon] This was triggered by a question by Michael Richardson " = So, > >>>>> given a Christmas-Tree-Packet (largest packet, every possible > >>>>> option space used, every extension turned on...) how much data = can > >>>>> I get back? :-)" and not fully thought through. > >>>>> It could happen though with Location-Path, Location-Query, > >>>>> Q-Block2, ETag, > >>>>> Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in > >>>>> response to a POST. > >>>>> OLD > >>>>> If there is insufficient space to create a response PDU with = a block > >>>>> size of 16 bytes (SZX =3D 0) to reflect back all the request = options as > >>>>> appropriate, a 4.13 (Request Entity Too Large) is returned = without > >>>>> the Size2 Option. > >>>>> NEW > >>>>> If there is insufficient space to create a response PDU with = a block > >>>>> size of 16 bytes (SZX =3D 0) to send back all the response = options as > >>>>> appropriate, a 4.13 (Request Entity Too Large) is returned = without > >>>>> the Size1 Option. > >>>>> > >>>>>> * "If the client requests missing blocks, this is treated as a = new > >>>>>> request.": I don't think the client should even make these = follow- > up > >>>>>> requests Observe, as it already has an ongoing observation. = They'd > be > >>>>>> sent on a different token too, so setting Observe would be = opening > >>>>>> observation up on that token, which AFAIU is not intended. = (Figure > 7 > >>>>>> example looks good to me in that respect.) > >>>>>> > >>>>>> (It may make sense to ask the client to keep Observe to make = the > >>>>>> requests matchable just for the sake of staying in = atomic-request > >>>>>> mode. Either way, the server should then not accept that > observation > >>>>>> as it's not for a block 0.) > >>>>> [Jon] The intent here was that just a new Token should be used. > >>>>> OLD > >>>>> If the client requests missing blocks, this is treated as a = new > >>>>> request. The Observe value may change but MUST still be = reported. > >>>>> If the ETag value changes then the previously received = partial body > >>>>> should be destroyed and the whole body re-requested. > >>>>> NEW > >>>>> If the client requests missing blocks, this is treated as a = new > >>>>> Request and the Observe Option MUST NOT be included. If the = ETag > >>>> value > >>>>> changes, then the previously received partial body > >>>>> should be considered as not fresh and the whole body = re-requested. > >>>>> > >>>>>> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response > >>>>>> can > >> be > >>>>>> matched by the token to a unique request that already had a > >>>>>> Request-Tag, and the client needs to have kept that token = around > >>>>>> matched to the transfer to make sense of it. > >>>>>> > >>>>>> No need to move that value around between subsystems, and = just > >>>>>> dropping it from here would also remove the need for the "If = the > >>>>>> client does not recognize the Request-Tag" clause (which = would > >>>>>> otherwise need clarification as to what it'd mean if it = recognizes it > >>>>>> but it doesn't match what the request was for). > >>>>> [Jon] Good question - it does make sense for the Request-Tag to = be > >>>>> tracked alongside the Token in the client. > >>>>> OLD > >>>>> The data payload of the 4.08 (Request Entity Incomplete) = Response > >>>>> Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR > encoded > >>>>> Request-Tag followed by 1 or more missing CBOR encoded = missing > >> block > >>>>> numbers. > >>>>> NEW > >>>>> The data payload of the 4.08 (Request Entity Incomplete) = response > >>>>> is encoded as a CBOR Sequence [RFC8742]. There are one or = more > >>>> missing > >>>>> CBOR encoded missing block numbers. > >>>>> > >>>>> OLD > >>>>> ; This defines an array, the elements of which are to be = used > >>>>> ; in a CBOR Sequence: > >>>>> payload =3D [request-tag, + missing-block-number] > >>>>> request-tag =3D bstr > >>>>> ; A unique block number not received: > >>>>> missing-block-number =3D uint NEW > >>>>> ; This defines an array, the elements of which are to be = used > >>>>> ; in a CBOR Sequence: > >>>>> payload =3D [+ missing-block-number] > >>>>> request-tag =3D bstr > >>>>> ; A unique block number not received: > >>>>> missing-block-number =3D uint > >>>>> > >>>>> OLD > >>>>> A 4.08 (Request Entity Incomplete) Response Code returned = with > >>>>> Content-Type "application/missing-blocks+cbor-seq" indicates = that > >>>>> some of the payloads are missing and need to be resent. The = client > >>>>> then re-transmits the missing payloads using the Request-Tag = and > >>>>> Q-Block1 to specify the block number, SZX, and M bit as = appropriate. > >>>>> The Request-Tag value to use is determined from the payload = of the > >>>>> 4.08 (Request Entity Incomplete) Response Code. If the = client does > >>>>> not recognize the Request-Tag, the client can ignore this = response. > >>>>> NEW (option presentation has been reformatted) > >>>>> 4.08 (Request Entity Incomplete) > >>>>> > >>>>> This Response Code returned with Content-Type "application/ > >>>>> missing-blocks+cbor-seq" indicates that some of the payloads = are > >>>>> missing and need to be resent. The client then retransmits the > >>>>> missing payloads using the same Request-Tag, Size1 and = Q-Block1 > >>>>> to specify the block number, SZX, and M bit as appropriate. > >>>>> > >>>>> > >>>>> The Request-Tag value to use is determined from the token in = the > >>>>> 4.08 (Request Entity Incomplete) response and then finding the > >>>>> matching client request which contains the Request-Tag that is > >>>>> being used for this Q-Block1 body. END > >>>>>> * "limit the array count to 23 (Undefined value)": 23 is the = maximum > >>>>>> length of a zero-byte length indication, not = indefinite-length (31). > >>>>>> Both using 23 and 31 here makes sense (up to 23 to have = definite > >>>>>> length that can be updated in-place, or exceeding that switch = to > >>>>>> indefinite length if they still fit), but the paragraph seems = to be > >>>>>> mixing them up. > >>>>> [Jon] OK > >>>>> OLD > >>>>> Arrays (Section 3.2.2 of [RFC8949]), limit the array count = to 23 > >>>>> (Undefined value) so that the array data byte can be = updated with > >>>>> the overall length once the payload length is confirmed or = limited > >>>>> to MAX_PAYLOADS count. > >>>>> NEW > >>>>> Arrays (Section 3.2.2 of [RFC8949]), or alternatively = limit > >>>>> the array count to > >>>>> 23 so that the initial byte with the array major type and > >>>>> data length in the additional information can be updated with = the > >>>>> overall count once the payload count is confirmed. Further > >>>>> restricting the count to MAX_PAYLOADS means that congestion > >>>>> control is less likely to be > >>>> invoked on the server. > >>>>>> * "Each new request MUST use a unique token": Like above, this = is > >>>>>> stating something that's not intended to be changed. > >>>>> [Jon] RFC7252 does not require Tokens to be unique - e.g. empty > >>>>> token values are acceptable. Hence this statement. > >>>>>> Congestion Control: > >>>>>> > >>>>>> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is > >>>> subjected > >>>>>> to PROBING_RATE.": That is unexpected here. At most one such > >>>>>> response is sent to each request message, so why is = additional > >>>>>> congestion control needed? > >>>>> [Jon] The intention here was that in the previous paragraph that > >>>>> it was not the individual packets that are subject to > >>>>> PROBING_RATE, but a single body comprising of multiple packets = is > >>>>> subject to PROBRING_RATE > >>>>> - and hence limiting any individual responses to PROBING_RATE > >>>>> rather than the potentially full set of responses OLD > >>>>> PROBING_RATE parameter in CoAP indicates the average data = rate > that > >>>>> must not be exceeded by a CoAP endpoint in sending to a peer > >> endpoint > >>>>> that does not respond. The body of blocks will be subjected = to > >>>>> PROBING_RATE (Section 4.7 of [RFC7252]). > >>>>> NEW > >>>>> PROBING_RATE parameter in CoAP indicates the average data = rate > that > >>>>> must not be exceeded by a CoAP endpoint in sending to a peer > >> endpoint > >>>>> that does not respond. The single body of blocks will be = subjected > to > >>>>> PROBING_RATE (Section 4.7 of [RFC7252]), not the individual > packets. > >>>>> If the wait time between sending bodies that are not being > >>>>> responded to based on PROBING_RATE exceeds > NON_PROBING_WAIT, > >>>> then the > >>>>> gap time is limited to NON_PROBING_WAIT. > >>>>> > >>>>> Note: For the particular DOTS application, PROBING_RATE and = other > >>>>> transmission parameters are negotiated between peers. Even when > >>>>> not negotiated, the DOTS application uses customized defaults as > >>>>> discussed in Section 4.5.2 of [RFC8782]. > >>>>> END > >>>>>> On the other hand, *ever* NON request is subject to > >>>>>> PROBING_RATE, > >> so > >>>>>> why point out the body of blocks and "GET or similar" = particularly? > >>>>> [Jon] It is only GET or FETCH. The intention here is to not > >>>>> request bodies of data at too high a rate. > >>>>> OLD > >>>>> Each NON GET or similar request using Q-Block2 Option is = subjected > to > >>>>> PROBING_RATE. > >>>>> NEW > >>>>> Each NON GET or FETCH request using Q-Block2 Option is > >>>>> subjected to PROBING_RATE. > >>>>>> * "a delay is introduced of ACK_TIMEOUT": As I understand > >>>> MAX_PAYLOADS, > >>>>>> this is (rather implicitly) introduced as the package count = up to > >>>>>> which it is OK to exceed PROBING_RATE temporarily (but after = that > it > >>>>>> kicks in all the harder by requiring to wait until = complete-sent- > bytes > >>>>>> over PROBING_RATE has expired). If that holds, at that time a = much > >>>>>> larger delay than just ACK_TIMEOUT is needed to get a = response > from > >>>>>> the server: About 3 hours (see later note on parameters). > >>>>> [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re- > write > >>>>> of Congestion Control section. > >>>>>> This is the crucial point in the document, and for it a > recommendation > >>>>>> alone is not good enough. The protocol can be run with a = vastly > >>>>>> increased PROBING_RATE (however externally determined) and > from > >>>> the > >>>>>> point of MAX_PAYLOADS just observe it. Or it has to get > >>>>>> feedback > >> from > >>>>>> the server; a single 4.08 is probably enough to kick off = another > >>>>>> vollley of blocks. (How many? MAX_PAYLOADS for every > response?). > >>>>>> Both can be permitted, but just waiting ACK_TIMEOUT isn't = doing > any > >>>>>> good. > >>>>> [Jon] See re-write of Congestion Control section where things > >>>>> should now be simpler and more logical. There is an = introduction > >>>>> of new variable definitions. > >>>>>> * "For NON transmissions": This seems to imply that the full > >>>>>> exchange > >> of > >>>>>> a body is either NON or CON; I don't see where that'd come = from. > I'd > >>>>>> have expected to read something like "Each individual request = can > be > >>>>>> NON or CON independent of the others. In particular, it can = be > >>>>>> convenient to send the ultimate payload...". > >>>>> [Jon]The DOTS environment will only be using NON. To make > >>>>> Congestion Control simple, the expectation is that all > >>>>> transmissions are NON or (not recommended) are all CON. The = draft > >>>>> now generally records this expectation. > >>>>>> * "If a Confirmable packet is used, then the transmitting peer > >>>>>> MUST > >> wait > >>>>>> for the ACK": Why? A NSTART > 1 would give it leisure to = still > >>>>>> transmit. > >>>>> [Jon] Text has been removed in the clean-up. > >>>>>> * General on congestion control: It may help implementors if = this > were > >>>>>> split up into newly introduced rules and concepts (that is, > >>>>>> MAX_PAYLOADS and the answer to whether you may send > >>>> MAX_PAYLOADS en > >>>>>> block again after having only even one response from the last > round, > >>>>>> and probably the recommended parameters of the "Also on > >>>> parameters" > >>>>>> comment), and another subsection on how Q-Block behaves well > >> when > >>>>>> observing these. > >>>>> [Jon] Should now be covered in the updated Congestion Control > >> section. > >>>>>> Caching: > >>>>>> > >>>>>> * "are not part of the cache key": How about "are removed as = part > >>>>>> of > >> the > >>>>>> block assembly and thus do not reach the cache"? > >>>>> [Jon] OK. > >>>>> OLD > >>>>> As the entire body is being cached in the proxy, the Q-Block1 = and > >>>>> Q-Block2 Options are not part of the cache key. > >>>>> NEW > >>>>> As the entire body is being cached in the proxy, the Q-Block1 = and > >>>>> Q-Block2 Options are removed as part of the block assembly = and > >>>>> thus do not reach the cache. > >>>>>> * "When the next client completes building the body": If the = proxy > >>>>>> chooses not to let them happen in parallel (which it may, see > >>>>>> above > >> on > >>>>>> parallel requests, although the server might still not = support it and > >>>>>> cancel one of them), why bother letting the first finish just = to abort > >>>>>> it? (IOW: If the proxy does not intend to see both through, = which it > >>>>>> could if it held back the second until the first is through = on the > >>>>>> uplink, it could just as well err out of one of them early, = but it may > >>>>>> also rather see both through.) > >>>>> [Jon] It has to be assumed that traffic to/from the origin = client > >>>>> and origin server may not both support Q-Blockx and potentially > >>>>> may have a different SZX. Thus passing a request or a response > >>>>> through at the block level introduces a new set of challenges = (but > >>>>> not impossible to fix). To keep this simple, my thinking was = that > >>>>> the passing through can only take place at the body level. = Again, > >>>>> the arrival of packets is not necessarily sequential, so client > >>>>> A's body may start transmitting to the origin server first, but > >>>>> client B's body starts to arrive first - the same being true for > >>>>> the proxy as a client may stop transmitting for whatever reason > >>>>> (restart, network loss > >> etc.). > >>>>> However this is covered by the above update " If a server > >>>>> receives payloads with different Request-Tags for the same > >>>>> resource, it should > >>>> continue to process all the bodies". > >>>>> OLD > >>>>> and the new body representation transmission starts with a = new > >>>>> Request-Tag value. > >>>>> NEW > >>>>> and the new body representation transmission starts with a = new > >>>>> Request-Tag value. Note that it cannot be assumed that the > >>>>> proxy will always receive a complete body from a client. > >>>>>> * Examples: > >>>>>> > >>>>>> * Figure 5: The ... between e3 request and response indicate = the > >>>>>> MAX_TRANSMIT_SPAN before sending the 4.08 response. I > suppose > >>>> there > >>>>>> should be the same kind of delay between the failed e5 > transmission > >>>>>> and the e4 response. > >>>>> [Jon] Agreed and added in > >>>>>> * If the second burst had 3 requests out of which 2 made it, = is there > >>>>>> any guidance for which of them the 4.08 would come back on? = (In > the > >>>>>> end, none of them is terminal). > >>>>> [Jon] The client should tracking all Tokens of the burst (hence > >>>>> implementation note about bottom 32bits unique and top 32 bits > >>>>> matching block number for ease of tracking) for a response and = so > >>>>> it will make no difference at to which token is used for the = 4.08 > >>>>> response. From an implementation perspective, it probably is > >>>>> easier to track the last opaque token that has the same = Request-Tag. > >>>>> OLD > >>>>> missing ones in one go (Figure 5). It does so by indicating = which > >>>>> blocks have been received in the data portion of the = response. > >>>>> NEW > >>>>> missing ones in one go (Figure 5). It does so by indicating = which > >>>>> blocks have been received in the data portion of the = response. > >>>>> The Token just needs to be one of those that have been received > >>>>> for this Request-Tag , so the client can derive the Request-Tag. > >>>>>> * If that e4 response gets lost, does the whole mechanism > >>>>>> recover > >> from > >>>>>> it in any way? > >>>>> [Jon] In this example, if e4 and e5 get lost, there will be no > >>>>> 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as = to > >>>>> whether it sends the request again or gives up. See 9.1 > >>>>> "Under high levels of traffic loss, the client can elect not = to retry > >>>>> sending missing blocks of data. This decision is = implementation > >>>>> specific." > >>>>>> Generally, the all-NON and all-CON examples don't look to = me like > >>>>>> what I'd be doing with this spec; the mixed "a CON every > >>>>>> MAX_PAYLOADS" appears much more realistic. > >>>>> [Jon] It is unsafe to use CON in the (potentially lossy) DOTS > >>>>> environment (up to 93 secs timeout per payload with the = defaults). > >>>>> Hence why we are separating out the NON / CON usage. > >>>>>> * Figure X: The request ahs M unset and thus indicats a = request for > >>>>>> just that block. If more than one is expected, it should = say > >>>>>> QB2:0/1/1024. > >>>>> [Jon] With Figure 7, with the M bit set, block 3 would get > >>>>> returned for a second time. Draft-ietf-core-new-block-03 also = has > >>>>> a Figure 8 which does exactly what you describe. > >>>>>> * New Content Format: I think this needs a media type > >>>>>> registration to > >> go > >>>>>> with it first; based on that, a content format can be = registered. > >>>>> [Jon] Med has responded to this and draft updated. > >>>>>> * General on MAX_TRANSMIT_SPAN and other timing parameters: > I'm > >> not > >>>>>> sure > >>>>>> they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN = is > >>>> defined > >>>>>> in terms of reliable transmission, but used for NONs as well. = (So is > >>>>>> the alternative ot 2x ACK_TIMEOUT). > >>>>> [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and > >> ACK_TIMEOUT > >>>> in > >>>>> a NON environment. Hence re-write of Congestion Control section > >>>>> defining new variables that can be used for NON. > >>>>>> For the purpose of delaying a 4.08 or a follow-up GET, it may = make > >>>>>> more sense to define a new parameter based on MAX_LATENCY and > >> the > >>>>>> time > >>>>>> it takes the sender to pump out the options (which I don't = think we > >>>>>> have a good factor for, but may even be negligible here). > >>>>>> > >>>>>> Could read like this: > >>>>>> > >>>>>> > The timing parameter MAX_BLOCK_JITTER is introduced, and by > >>>> default > >>>>>> > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / > >>>> BANDWIDTH. > >>>>> [Jon] Lets plug in some numbers here. MAX_LATENCY =3D 100, > >>>>> MAX_PAYLOADS =3D 10, MTU =3D 1280bytes and BANDWIDTH =3D 1Mbps. > >>>>> > >>>>> [Jon] MAX_BLOCK_JITTER =3D 100 + (10 * 1280 * 8)/(1 000 000) =3D = 100.1. > >>>>> So BANDWITH of 1Mbps has negligible effect on the calculation. > >>>>> 1Kbps makes MAX_BLOCK_JITTER 200 seconds. > >>>>>> > > >>>>>> > With Q-Block2, a client can ask for any missing blocks = after not > >>>>>> > having received any further response for the duration of > >>>>>> > MAX_BLOCK_JITTER. > >>>>> [Jon] 100+ seconds delay is way too much time to wait for any > >>>>> missing blocks in my opinion. > >>>>> > >>>>> [Jon] RFC7252 also states (and the intention is that recovery > >>>>> works > >>>>> well) " as MAX_LATENCY is not > >>>>> intended to describe a situation when the protocol works = well, but > >>>>> the worst-case situation against which the protocol has to = guard." > >>>>>> > > >>>>>> > With Q-Block1, a server holds off any response for > >> MAX_BLOCK_JITTER > >>>>>> > unless all blocks have been received. Only then it = evaluates > >> whether > >>>>>> > to respond with a 2.0x code, a 4.08 with payload, or not at = all > >>>>>> > (because it responded to a later request). > >>>>> [Jon] I am not convinced that this is necessarily the way to go. > >>>>> The new Congestion Control more cleanly handles this. > >>>>>> This also brings me back to the earlier matter of 2.31: What = is a > >>>>>> server supposed to send when no packages were lost, but it's > pasing > >>>>>> the timeout and wants to help the client flush out more = packages > by > >>>>>> confirming something? It says 4.08 in 3.3, but it's not like = there's a > >>>>>> hole in the contiguous range. Does it need to send 4.08 > enumerating > >>>>>> all (or at least some) numbers between the first unreceived = and > >> what's > >>>>>> indicated by Size1? Or can it just send 2.31 and the client = knows all > >>>>>> it needs to know b/c the response came to the largest block = that > was > >>>>>> sent and 2.31 indicates that everything is good up to that = point? > >>>>> [Jon] The previous draft states (under Congestion Control) that > >>>>> the client waits for ACK_TIMEOUT before transmitting the next = set > >>>>> of MAX_PAYLOADS blocks. The server should wait for "two times > >>>>> ACK_TIMEOUT " (3.3) before indicating issue. Apart from perhaps > >>>>> having a new name for ACK_TIMOUT I think that these are = reasonable > >>>>> values for Non-Confirmable - and are used in the new Congestion > >>>>> Control > >>>> section. > >>>>> [Jon] I have reworked Congestion Control to use 2.31 (NON only) = as > >>>>> a signal to say that all of the current MAX_PAYLOADS payloads of = a > >>>>> body have been received, so allowing the client to continue > >>>>> transmitting the next set of MAX_PAYLOADS payloads without the > >>>>> need to wait any > >>>> longer. > >>>>>> * Also on parameters: This document is describing flow control = stuff > >>>>>> around a situation CoAP was not originally designed for. = Wouldn't it > >>>>>> make sense to include a set of parameters (PROBING_RATE, > >>>> MAX_LATENCY, > >>>>>> ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt = that > >>>>>> PROBING_RATE will be left to 1 byte/second for any DOTS > application > >>>>>> using this (for sending 10KiB in the initial 10-package > MAX_PAYLOADS > >>>>>> burst would mark that connection as unusable for about 3 = hours > >>>>>> if > >> they > >>>>>> all get lost), so better give justifiable numbers here than = rely on > >>>>>> implemnetors to come up with unreviewed numbers or disregard > >>>>>> PROBING_RATE altogether. > >>>>> [Jon] Answered by Med, and some new text added. > >>>>>> I don't know if it needs additional justification, but an = increased > >>>>>> N_START may be justifiable there. > >>>>> [Jon] It may be, but tuning the other associated parameters is > >>>>> really out of the cope of this draft. This text has been added = NEW > >>>>> Congestion control for CON requests and responses is specified = in > >>>>> Section 4.7 of [RFC7252]. For faster transmission rates, NSTART = will > >>>>> need to be increased from 1. However, the other CON = congestion > >>>>> control parameters will need to be tuned to cover this change. = This > >>>>> tuning is out of scope of this document as it is expected that = all > >>>>> requests and responses using Q-Block1 and Q-Block2 will be = Non- > >>>>> confirmable. > >>>>>> * Somewhere (never comes up but I think it should): When CONs = are > >>>> used, > >>>>>> a 4.08 (or 2.31?) response to a later request can indicate to = the > >>>>>> client that an earlier CON request has been processed = successfully. > If > >>>>>> the client can match that up (and it should be able to), then = it can > >>>>>> (and should) cancel that particular CON request. > >>>>> [Jon] I think that this is covered by my update above with the = text " > >>>>> NEW > >>>>> For Confirmable transmission, the server continues to = acknowledge > >>>>> each packet, but a response is not required (whether separate = or > >>>>> piggybacked) until successful receipt of the body or, if some = of the > >>>>> payloads are sent as Non-confirmable and have not arrived, a > >>>>> retransmit missing payloads response is needed." > >>>>> > >>>>> And in my previous part 1 response (updated) NEW For Confirmable > >>>>> transmission, the server continues to acknowledge each packet, > >>>>> but a response is not required (whether separate or > >>>>> piggybacked) until successful receipt of the body or, if some = of the > >>>>> payloads are sent as Non-confirmable and have not arrived, a > >>>>> retransmit missing payloads response is needed. > >>>>>> Best regards > >>>>>> Christian > >>>>>> > >>>>>> -- > >>>>>> There's always a bigger fish. > >>>>>> -- Qui-Gon Jinn > >>>>> _______________________________________________ > >>>>> core mailing list > >>>>> core@ietf.org > >>>>> > >> > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > >>>> w. > >>>> > >> > ietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloc > >>>> a%4 > >>>> > >> > 0ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09 > >>>> ecc4 > >>>> > >> > 0cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8 > >>>> eyJWIjoiMC > >>>> > >> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000& > >>>> amp;sd > >>>> > >> > ata=3DtEJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&reserved=3D0 > >>>> -- > >>>> 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://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > >> w > >> > .ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7 > >> c8 > >> > 1f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637 > >> 45709 > >> > 6666457035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > >> oiV2luMz > >> > IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DiJgJcxZmwbaLrb > >> mzIuz > >>>> SjezxDRq47wwWcNvFC7ox8bw%3D&reserved=3D0 > >>>> > >> -- > >> 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://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > w > >> > .ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C8651a6788136434 > 84 > >> > 22608d8b3f94057%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637 > 45723 > >> > 0862239405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > oiV2luMz > >> > IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3Dpo%2BnNJAbUW > 7Jf9cMF > >> xoP8VXDd1%2FfS%2BsyTl4dePY5A9o%3D&reserved=3D0 > >> > > >=20 > -- > Marco Tiloca > Ph.D., Senior Researcher >=20 > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) >=20 > Phone: +46 (0)70 60 46 501 > https://www.ri.se >=20 From nobody Mon Jan 11 03:39:07 2021 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 336313A0977; Mon, 11 Jan 2021 03:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 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.262, 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 wPGftPSnkYLB; Mon, 11 Jan 2021 03:39:00 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70071.outbound.protection.outlook.com [40.107.7.71]) (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 05A1A3A0AEC; Mon, 11 Jan 2021 03:38:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mj3TQ63lLmGR4IRjfVJRLj6iM43yhGLNW8TdMEQQ5cvRir2FN6eCUgYmLyNoaNXUjVL3yPZ+a9HTCLlXLlOXVGkg3IIBX1OhHJ6TwFasB9cf6n1Fjen59mM6iZPHI3y7Cse1iszgArkzP9sGPLFLvA2pCkqAI8YqAGakNZ+Lz/qU7W+h0pDjvXRWaF83zsHynYSeM3H7Zp9iWotNPx/Mufiiz1VM84gCm6mp7awFCK9lMLSV7GFA5d7+6ZnuscgGp5xo+GxxlHI8c30t/O+1w/rqoIC7qxWoQgLLspSljqFfU36R0cDkcdMUzwk9H5XPG+61+m6eEO+YBIpOsassVQ== 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=IN63M7vsSKJYadjsJ0QnnXhqPcy7JwJ7RMwtSH97r3Q=; b=EJ9NhHpx8GGfujLeFstj6pIaE45Y6wkC4eKYv7dxtvwGuE+7gWV6T+KJALLg3o9wbawCNHiwRJrqDXTqegNfdugZN7qssNboPFeNBvprJ0PdqmMdvwWSFn8VzPQsE4lKeYZksSvLwIEP/xJSo/FW0OjFHWU/+vtTaRiCve5cysYpuOBB+mehRlaINu41iLq1HE/ywC6uwxqMHUnrlI1gLZz+bRz287b55lxHXc8S9JliD3L9oSsaIrrxSM2/PYOfYjNxsaaVSrXvzieFGivKVCGpwZ+elvzvlZ3LymXwPow2gzYrbg+UNw17s/h7S/26UPxXA+zLhpg0JagKlS0rEw== 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=IN63M7vsSKJYadjsJ0QnnXhqPcy7JwJ7RMwtSH97r3Q=; b=Q9xL+aOnHEEuQvgzabyNB6j2qSdHl5+GbUyK14A3qH2qLLZPw6fqj/aTXmwIcvbwmnG8eTkcYzlu3LwVLz5qyHsd2SZhil/tkMM7yrL9HO3Rp7hQEidzz+FuGeLmD533R1HJxIIu6pgA/s3pRTHhdIcLs0nZcNx0DEdvoFTTTwk= 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 DBBP189MB1403.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:1e2::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.8; Mon, 11 Jan 2021 11:38:54 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3742.012; Mon, 11 Jan 2021 11:38:54 +0000 To: supjps-ietf@jpshallow.com, christian@amsuess.com, draft-ietf-core-new-block@ietf.org Cc: dots@ietf.org, core@ietf.org References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <065301d6e805$286163c0$79242b40$@jpshallow.com> 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, 11 Jan 2021 12:38:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <065301d6e805$286163c0$79242b40$@jpshallow.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WtB71mJpZTCXzs72Eamrly3icdUsQg1Y7" X-Originating-IP: [185.236.42.23] X-ClientProxiedBy: HE1PR0401CA0104.eurprd04.prod.outlook.com (2603:10a6:7:54::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.2.3] (185.236.42.23) by HE1PR0401CA0104.eurprd04.prod.outlook.com (2603:10a6:7:54::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6 via Frontend Transport; Mon, 11 Jan 2021 11:38:53 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6737cfa9-071f-4c2c-327d-08d8b62579d3 X-MS-TrafficTypeDiagnostic: DBBP189MB1403: 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: lQ+N3hPEHQSwcZhImjw26y0WJGROyvzc/z4EG85O9I+pC0e00MJS1IQX6BfZWTIpuBVsdn51q+8k1XPujuRMbgwZkk7ZAVvn3NKtn8GIKCWTnTbxYeDV9xthCv5F6aGKpVOG1xrcdlciOyC9LDvy5AvyHFx3TE+PDAcBbBZYNoaeSaKUDJBK5M6UPw3YOExW7MRYfQ4FiWPKP9YDsmy1gAOkqVWiRzVwybFJ1+kEriq8fP9xy8xKeHmJ0XdjpD+q6PulSgSXmr1A3syeZgV7eafOnc8cidP0DFWF765oeD59H1Flb0zIF1kVzM8KKapS/zwTZ6zP0SGF2lcZhUIwBPw6KBUO5mnCethoGVWEB7n7P+9h83g8+CSFgQYbmYubp1zlyHMObbGYLm8v8MUOwogE2c188GWcZTgQfPgs+9/Gb/Zc5o6LlCldW3hzyZe/jGv0fWc4v2Llxb62jT0qj7qxvoXOi5L++5U+kGH7xm5Qlw6VJuM4Ihq2q8QUBPfg52ijGyfYsqjwyCxOeqVMQR6QVcNqEsl1Lh8QwlCKiHYoelSbeafF7XCvDOe3oAFM 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)(39850400004)(346002)(366004)(136003)(376002)(235185007)(5660300002)(30864003)(4326008)(31686004)(52116002)(6666004)(316002)(16576012)(36756003)(8936002)(21480400003)(33964004)(44832011)(6486002)(66556008)(8676002)(26005)(83380400001)(956004)(966005)(66574015)(53546011)(45080400002)(186003)(16526019)(66946007)(31696002)(86362001)(2906002)(478600001)(66476007)(2616005)(45980500001)(43740500002)(579004)(559001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?bEh0bUNWT0JhOUo2QllVQXRWb1M3QkhtZlQ3bXVVZU9XZFdPS2lTa2NVSklU?= =?utf-8?B?aDJLOEdvQWJzOGJ5T2FkMElMc3Evd0hZdWtIc2NCendWRU9yMHFXeTRYTlp5?= =?utf-8?B?MVA5dXo2OHlCWmtEVzExSWwrSGhlMVVEVTYyMlR5MHc4bGM5c2E2YXA1SmZM?= =?utf-8?B?dTFTeE81MGwrcy9MUjRqZXVNdTRvTzA2bElVWVlXdHpvWEdJQ1JsNDdidHha?= =?utf-8?B?b2VnMUhLNmJUR2xpZEs3Vjh4SFdGaXpsZks5aExPNnEyajVISnY1S0tXUm1V?= =?utf-8?B?SmJzdzViSTlXaHFFaGhQb2h3Qk1ELzZ6ajRRTk9MbkI0c3lXV0pBU0Q0cThy?= =?utf-8?B?TUMvR1hsM1dlTWNuZFdLek1DMld4U1BxNFozczdjeGVnRFRLZnZPZU5zam1K?= =?utf-8?B?ZWoxWmM1dzJHcHJvSU10alBzc2ZPanhaS05rMGpwMWJ4RXdTR1M0TFRtalY1?= =?utf-8?B?Tm8xbXUxOUR5Nks4bkpkUmp1dmJwNG1hNlRacm02Zm9pK1NKRHV3eEltTDRI?= =?utf-8?B?bmNIczhScy90Wmw4ejRKR3M5Y1h5ZkE3a3ZQRmJTR1ZIbnhrWTBEdCtDU2ZQ?= =?utf-8?B?ZklZeXVYUkl1UmpHL1dkYXd6anE4djVkSis4WnplY3RBblQ2RHU0UVA1Vkp6?= =?utf-8?B?YnRIMy8wcHMxelNiQ2VXRWpoWE1LWEtkcSs4ZGh4cU51ZVIyVXBzcXhqcU9X?= =?utf-8?B?NVN2OGMyYzYvamd3VmNwaGxVbk8xMzdDTEt4VDg3NWdzUGlCMU56UmpDVDNK?= =?utf-8?B?cGc1dXRRMWdUb0Ezc0dhalFuZlVUTW1oaHRlc1NmZTgwYUFNMStNYlVGUGta?= =?utf-8?B?emgrY1JSR2lUMTdmQm8rTjU4ZVUwZEp4Vmk2cGxpaVg3blZwRmtjYStvOS9v?= =?utf-8?B?OEZQdWZVd3JNUzh3d2lnY1QreFdEYnVDdTNxckZETStCaHI1cnBWMWcvL3Zz?= =?utf-8?B?VityenIzeFlyT043bERCbmRvcnAvYXBWNFM1NEtvZ0UyZWJFTDBHenA4KzBD?= =?utf-8?B?Q20rL2MrOEFCcERZY1lmbmhad1RyVVFvVzNUOFdhaGxPeDZWbEJTdyttSzdi?= =?utf-8?B?SXRMTW9Db0ZsbldJR25wUUVmeE9yY2FxdkR4NE9SRitYZWJ3TUQ3YzE5Rzhi?= =?utf-8?B?K2Z4amlxUVozbXZKZVhDbktsbFM2SWlRN29PNXRKRXNmRFR2Qy9PTlBYK2E5?= =?utf-8?B?dERPVjJBdk1OL0t6NGRsdG4zOFpQV3Bsb0ptS2pPeDlaRElnaEUvSXIxb3Nj?= =?utf-8?B?clgxOWdkdUg2ZW8zR05VNU90NzNUeWdJYThWSW1IbklhM0VzYVVQcUF2c0JI?= =?utf-8?Q?DmeKz6s5PCiGGPqX0zxUSXLYsg85qBCnJt?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2021 11:38:54.6107 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: 6737cfa9-071f-4c2c-327d-08d8b62579d3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: PqQnxgSOM7/A3nlSnpTkp7btiB7dXa4iLgkCcii5ngiYQKGXwRkKHNHxrWh6M8yNzic4bFX9Q5sZU2D7+wf7ew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBP189MB1403 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 11 Jan 2021 11:39:06 -0000 --WtB71mJpZTCXzs72Eamrly3icdUsQg1Y7 Content-Type: multipart/mixed; boundary="AZUxISfTlovYtzMUqTfbBCRvG9nzs4NNW" --AZUxISfTlovYtzMUqTfbBCRvG9nzs4NNW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jon, Thanks, the updates look good. As to the response codes in Section 3.3 "Using the Q-Block1 Option",=C2=A0= wouldn't it make sense to mention also 2.05 (Content) ? Think of a FETCH request with a big body, which is actually mentioned at the beginning of Section 3.3 and in Section 3.1 (though missing the 2.05 response code beside it). Also, more in general, think of an observe registration, for which the server eventually sends back a first notification (possibly split into multiple payloads) with Q-Block2, with a certain Token value. If the observation request used FETCH and was fragmented into several payloads with Q-Block1, each of which with a different Token, it's still true that the notifications can all have any of those Token values and should have the one of the last received request payload. However, later on the client has to retain that Token value as the one associated to the observation, to match future notifications to come. In this case, there is a deviation from the claim used for other response codes, i.e. "The client should then release all of the tokens used for this body." This should concern only 2.01 notifications (hence including the Observe option) in response to observation requests with FETCH, so it can be limited to the context of this section about Q-Block1. Best, /Marco On 2021-01-11 11:33, supjps-ietf@jpshallow.com wrote: > Hi Marco, > > The new updates have been pushed to https://eur02.safelinks.protection.= outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-block&dat= a=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2744bb09ef5945b3d89808d8b61c4788%7C5= a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459580455245128%7CUnknown%7C= TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C2000&sdata=3Dost7IW3KRdzPcvhj6NWjtypuEBpTlLQYYprW2T0tekk%3D&a= mp;reserved=3D0 and the differences with the draft can be found at https:= //eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.or= g%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new-block%26url2%3Dhttps%3A%2F%2Fraw= =2Egithubusercontent.com%2Fcore-wg%2Fnew-block%2Fmaster%2Fdraft-ietf-core= -new-block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2744bb09ef5945= b3d89808d8b61c4788%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459580= 455250109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ= BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3Dh%2FG4febnGfQJJzEJFXCXEuBw= AGNPlDPzub32L%2FLceUI%3D&reserved=3D0 > > The PR for the responses below can be found at https://eur02.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-bl= ock%2Fpull%2F12&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2744bb09ef594= 5b3d89808d8b61c4788%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63745958= 0455250109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC= JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DjUmBoUDRubJVXoq2jcvvgZJ1Z= VPtJUhKMX%2BEeZ0gtT4%3D&reserved=3D0 (a couple of minor nits fixed si= nce then which are in master) > > Otherwise lease see inline. > > Regards > > Jon > >> -----Original Message----- >> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >> Sent: 08 January 2021 18:19 >> To:supjps-ietf@jpshallow.com; christian@amsuess.com; draft-ietf-core-n= ew- >> block@ietf.org >> Cc: dots@ietf.org; core@ietf.org >> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >> >> Hi Jon, >> >> On 2021-01-08 18:17, supjps-ietf@jpshallow.com wrote: >>> Hi Marco, >>> >>> Thanks for this. >> ~snips >> >>>> * Section 4 says: "The token to use ... any troubleshooting." >>>> >>>> Do you actually mean the highest block number received so far >>>> under that Request-Tag, or the highest within the current set of >>>> MAX_PAYLOADS payloads for which the server is requesting some >> missing blocks? >>>> The new example in Section 5 seems to cover the latter, which I >>>> guess is what you intend. >>> [Jon] Not sure that it really makes any difference. Have updated the= >>> text to try to clarify OLD The token to use for the response SHOULD b= e >>> the token that was used in the highest block number received payload.= >> Note that the use of any received token would work, but providing the = one >> used in the highest received block number will aid any troubleshooting= =2E The >> client will use the token to match the request to find what Request-Ta= g >> value is currently being used. >>> NEW >>> The token to use for the response SHOULD be the token that was used i= n >> the highest block number received so far with the same Request-Tag val= ue. >> Note that the use of any received token with the same Request-Tag woul= d >> work, but providing the one used in the highest received block number = will >> aid any troubleshooting. The client will use the token to determine wh= at is >> the previously sent request to obtain the Request-Tag value to be used= =2E >> >> =3D=3D>MT >> Looks better. >> >> To clarify, I meant Figure 5 (not Section 5), where the response with >> Message ID M:0x91 uses Token T:0xe0. That's matching with the request >> with Message ID M:0x19, i.e. the received payload with the highest blo= ck >> number *in the current MAX_PAYLOADS payload set* to be still completed= =2E >> >> If the SHOULD above was followed, that response would have Token T:0xe= b, >> to match with the one used in "the highest block number received so fa= r", >> i.e. block number 10 in the request with Message ID M:0x1b. >> >> But as per the text above, either Token value is fine to use in the re= sponse, >> so the example is correct anyway. > [Jon] Changed highest to last (to simplify things), updated the example= s accordingly. Updated 2.01,2.04 and 2.31 code with which token to use. >> <=3D=3D >> >>>> - Figure 10, all responses should have ET=3D24 >>> [Jon] Fixed (I only found one) >> =3D=3D>MT >> The other occurrence is the very last response, with Message ID M:0x9b= :-) > [Jon] Got it - And M:0x9b updated to M:0xc3 to be consistent. > ~Jon >> >> Otherwise, it looks good to me. Thank you! >> >> Best, >> /Marco >> <=3D=3D >> >>> ~Jon >>>> Best, >>>> /Marco >>>> >>>> >>>> On 2021-01-08 14:33, supjps-ietf@jpshallow.com wrote: >>>>> Hi Marco, >>>>> >>>>> Thanks for this - and it is good to have another set of eyes >>>>> checking things >>>> through. >>>>> Updates have been pushed to >>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgi= t >>>> h >>>>> ub.com%2Fcore-wg%2Fnew- >>>> block&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7 >>>> >> C2385ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e >>>> 8%7 >>>> >> C0%7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi >>>> MC4wLjAwMD >>>> >> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D >>>> LN79 >>>> >> Z8Ar4AICnpWDOFgkFi3g0Mwf72KPC0ewPW%2FZk3A%3D&reserved=3D0 >>>> and the >>>>> differences with the draft can be found at >>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >>>> w. >>>>> ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new- >>>> block%26url2%3Dhttps%3 >>>>> A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew- >>>> block%2Fmaster%2Fdraf >>>>> t-ietf-core-new- >>>> block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C23 >>>> >> 85ef89ef574a7c81f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8% >>>> 7C0% >>>> >> 7C0%7C637457096666452069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 >>>> wLjAwMDAiL >>>> >> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DgIc >>>> 2vkC >>>>> 1XGtyGb17WSmby%2FO9wzA2bMaxDUsl3jmOAL4%3D&reserved=3D0 >>>>> >>>>> Otherwise, please see inline. >>>>> >>>>> Regards >>>>> >>>>> Jon >>>>> >>>>>> -----Original Message----- >>>>>> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >>>>>> Sent: 07 January 2021 12:17 >>>>>> To: supjps-ietf@jpshallow.com; christian@amsuess.com; >>>>>> draft-ietf-core-new- block@ietf.org >>>>>> Cc: dots@ietf.org; core@ietf.org >>>>>> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >>>>>> >>>>>> Hi, >>>>>> >>>>>> Thanks for this revision and for addressing my comments already in= >>>>>> version -03. >>>>>> >>>>>> Please, see below some more comments on this version -04. >>>>>> >>>>>> Best, >>>>>> /Marco >>>>>> >>>>>> >>>>>> * s/There are one or more missing CBOR encoded missing block >>>>>> numbers./There are one or more CBOR encoded missing block >> numbers. >>>>> [Jon] Fixed. >>>>>> * Section 4 now includes the new paragraph: "The token to use for= >>>>>> the response SHOULD be the token that was used in the highest bloc= k >>>>>> number received payload. The Q-Block1 Option from the same packet= >>>>>> SHOULD be included." >>>>> [Jon] The Q-Block1 option actually is not needed as it can be >>>>> derived by >>>> the client from the remembered token (which is used to derive the >>>> Request-Tag. >>>>> OLD >>>>> The Q-Block1 Option from the same packet SHOULD be included. >>>>> NEW >>>>> The client will use the token to match the request to find what >>>>> Request-Tag value is currently being used. Providing the highest >>>>> received block number will aid any troubleshooting. >>>>> >>>>>> Consistently, the example in Figure 5 should also have >>>>>> QB1:3/0/1024 in the >>>>>> 4.08 response with Token T:0xe3, and QB1:1/1/1024 in the 4.08 >>>>>> response with Token T:0xe4. >>>>> [Jon] No change now needed. >>>>>> Since "SHOULD" is used, when is it still fine or expected to no= t >>>>>> include Q- >>>>>> Block1 in a 4.08 response? >>>>> [Jon] Q-Block1 is no longer needed. >>>>>> * When commenting the example in Figure 5, Section 9.1 reads: "The= >>>>>> Token just needs to be one of those that have been received for >>>>>> this Request-Tag, so the client can derive the Request-Tag." >>>>>> >>>>>> Should this not be aligned with the SHOULD used in Section 4 >>>>>> about using the Token from the same packet conveying the highest >>>>>> block >>>> number? >>>>> [Jon] Agreed >>>>>> You explained in your mail that the client keeps tracking all >>>>>> Tokens in the burst anyway, so maybe it's better to rather align >>>>>> the text in Section 4 with what suggested here in Section 9.1, i.e= =2E >>>>>> responding with any of those Token values is just fine. >>>>> [Jon] I think that it is useful for the client to have a hint about= >>>>> what is the latest block number received even if it does not make >>>>> use it - it may help in debugging from packet captures etc. which i= s >>>>> why I >>>> added in the SHOULD in section 4. So, I would prefer to align this >>>> with section 4 OLD The Token just needs to be one of those that have= >>>> been received for this >>>>> Request-Tag, so the client can derive the Request-Tag. >>>>> NEW >>>>> The token used in the response should be the token that was used in= >>>>> the >>>> highest block number received payload. The client can then derive th= e >>>> Request-Tag by matching the token with the sent request.. >>>>>> In such a case, the Q-Block1 option included in the 4.08 >>>>>> response has still to be the one from the request conveying the >>>>>> highest block >>>> number. >>>>>> Correct? >>>>> [Jon] We are now dropping the need for Q-Block1 in the response. >>>>>> * The new text in Section 6.2 says: "... and the situation >>>>>> re-evaluated for another 24 hour period until there is no report o= f >>>>>> missing payloads under normal operating conditions." >>>>>> >>>>>> When that happens, I suppose MAX_PAYLOADS is right away restore= d >>>>>> to the intended value, i.e. it is not incremented by 1 to start >>>>>> another 24-hour period evaluation. Correct? >>>>> [Jon] Updated for clarification >>>>> OLD >>>>> report of missing payloads under normal operating condition= s. Note >>>>> that the CoAP peer will not know about the MAX_PAYLOADS >>>>> change until NEW >>>>> report of missing payloads under normal operating >>>>> conditions. The >>>> newly >>>>> derived value for MAX_PAYLOADS should be used for both ends= of >> this >>>>> particular CoAP peer link. Note >>>>> that the CoAP peer will not know about the MAX_PAYLOADS >>>>> change until >>>>>> * Section 6.2 says: "The request that the client sends to >>>>>> acknowledge the receipt of all the current set of MAX_PAYLOADS >>>>>> payloads SHOULD contain a special case Q-Block2 Option with NUM se= t >>>>>> to the first block of the next set of MAX_PAYLOADS payloads and th= e M >> bit set to 1." >>>>>> Is it possible to reflect this in the example of Figure 6? It >>>>>> would require the body to have more than MAX_PAYLOADS blocks thus >>>> resulting >>>>>> in more bursts, which would be inherited by the examples in Figure= >>>>>> 7 and >>>> Figure 8. >>>>> [Jon] Examples updated to include this information >>>>>> * In Section 9, it would be good to have the parameters defined in= >>>>>> Section >>>>>> 6.2 and their values reflected in the examples, when applicable. >>>>>> E.g., MAX_PAYLOADS is at least 4 in these examples; the asked >>>>>> retransmissions are presumably due sometimes to MAX_PAYLOADS >>>> compared >>>>>> against the value of the latest received Q-Block1/Q-Block2, while >>>>>> sometimes to NON_RECEIVE_TIMEOUT. >>>>> [Jon] Examples updated to include this information >>>>>> * In the example in Figure 6, shouldn't the first request from the= >>>>>> client have the M bit set to 1 in the Q-Block2 option, i.e. as >>>>>> QB2:0/1/1024 ? As per Section 3.4, that would indicate that the >>>>>> request is in fact for the block 0 and for all of the remaining >>>>>> blocks within >>>> the body. >>>>> [Jon] Good catch - corrected. >>>>> >>>>> ~Jon >>>>>> On 2021-01-06 16:24, supjps-ietf@jpshallow.com wrote: >>>>>>> Hi Christian, >>>>>>> >>>>>>> Once again, thank you for the comprehensive review. >>>>>>> >>>>>>> Responses part 2. A new version (-04) of the draft has been >>>>>>> published and can be found at >>>>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= t >>>>>> a >>>>>>> tracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new- >>>>>> block%2F&data=3D04%7C01 >>>>>> >> %7Cmarco.tiloca%40ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a980 >>>>>> 9cf0 >>>>>> >> bcb413a838a09ecc40cc9e8%7C0%7C0%7C637455435959417764%7CUnknown >>>>>> %7CTWFpb >>>>>> >> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI >>>>>> 6Mn0 >>>>>> >> %3D%7C2000&sdata=3DMlMoSqfzcxDvyO41nqA2GfZ7QqYFfeaHvN8fwH7j >>>>>> gTY%3D&am >>>>>>> p;reserved=3D0 >>>>>>> >>>>>>> >>>>>>> Part 1 responses were covered in the main by version -03, so you >>>>>>> may want to look at the -02 to -04 differences. >>>>>>> >>>>>>> The Congestion Control section has been re-written to simplify ho= w >>>>>>> things work and has a new set of definitions. There is a >>>>>>> separation of Confirmable and Non-Confirmable Congestion Control >>>>>>> with the stated assumption that all of a body is sent as >>>>>>> Non-Confirmable or >>>> Confirmable. >>>>>>> Otherwise, see inline. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>>> * The list of pros and cons (with the cons being almost trivial)= does >>>>>>>> not explain to the reader why these are not a replacement; I >> suggest >>>>>>>> to add: >>>>>>> [Jon] Another disadvantage addition NEW To reduce the transmissio= n >>>>>>> times for CON transmission of large bodies, NSTART needs to be >>>>>>> increased from 1, but this affects congestion control where other= >>>>>>> parameters need to be tuned (Section >>>>>>> 4.7 of [RFC7252]). Such tuning is out of scope of this document.= >>>>>>> >>>>>>>> * "If the client transmits a new body of data with a new Request= -Tag >>>>>>>> to": Processing parallel requests is something Request-Tag ope= ns >> up. I >>>>>>>> don't see why there's a MUST to that; the server certainly MAY= drop >>>>>>>> the old request, but it may just as well process them in paral= lel. >>>>>>> [Jon] The intent here was that garbage collection would take plac= e >>>>>>> sooner than later - especially when running in a lossy environmen= t >>>>>>> and the client has updated information to transmit. I agree that >>>>>>> Request-Tag enables the possibility of sending multiple block >>>>>>> requests with different payloads, and so there is a possibility >>>>>>> that the client starts sending body A, then decides to send body = B >>>>>>> and terminate A, but a packet from B arrives before a packet from= >>>>>>> body A is received and so >>>>>> things fail as A does not complete. >>>>>>> OLD >>>>>>> If the client transmits a new body of data with a new Request-= Tag to >>>>>>> the same resource on a server, the server MUST remove any part= ially >>>>>>> received body held for a previous Request-Tag for that resourc= e. >>>>>>> NEW >>>>>>> If a server receives payloads with different Request-Tags for >>>>>>> the same resource, it should continue to process all the bodies a= s >>>>>>> it has no way of determining which is the latest version, or whic= h >>>>>>> body, if any, the client is terminating the transmission for. >>>>>>> >>>>>>> If the client elects to stop the transmission of a complete bod= y, it >>>>>>> SHOULD "forget" all tracked tokens associated with the body's >>>>>>> Request-Tag so that a reset message is generated for the invalid >>>>>>> token in the 4.08 (Request Entity Incomplete) response. The >>>>>>> server on receipt of the reset message SHOULD delete the partial >> body. >>>>>>> END >>>>>>> >>>>>>>> * "If the server receives a duplicate block with the same Reques= t- >> Tag": >>>>>>>> Why? Being silent is the default on nonterminal blocks alredy,= but >> in >>>>>>>> a situation like figure 5 if the 2.04 is lost, that rule would= make >>>>>>>> it impossible for the client to ever get a successful response= =2E >>>>>>>> >>>>>>>> A better rule here may be to say that it processes it all the = same >>>>>>>> (and if the payload is distinct from the first transmission's = payload, >>>>>>>> it should err out.) >>>>>>> [Jon] Fair point >>>>>>> OLD >>>>>>> If the server receives a duplicate block with the same Request= -Tag, >>>>>>> it SHOULD silently ignore the packet. >>>>>>> NEW >>>>>>> If the server receives a duplicate block with the same Request= -Tag, >>>>>>> it SHOULD ignore the payload of the packet, but MUST still >>>>>>> respond as if the block was received for the first time. >>>>>>>> * "If the server receives multiple requests (implied or otherwis= e) for >>>>>>>> the same block, it MUST only send back one instance of that bl= ock.": >>>>>>>> This might be read as "ever" rather than "per incoming >>>>>>>> request", >>>> where >>>>>>>> probably the latter is meant. >>>>>>> [Jon] This text has already been updated following another review= >>>>>>> "OLD If the server receives multiple requests >>>>>>> (implied or otherwise) for the same block, it MUST only send b= ack >> one >>>>>>> instance of that block. >>>>>>> NEW >>>>>>> If the request includes multiple Q-Block2 >>>>>>> Options and these options overlap (e.g., combination of M bein= g set >>>>>>> (this and all the later blocks) and being unset (this individu= al >>>>>>> block)) resulting in an individual block being requested multi= ple >>>>>>> times, the server MUST only send back one instance of that blo= ck. >>>>>>> This behavior is meant to prevent amplification attacks." >>>>>>> >>>>>>>> * "The ETag Option MUST NOT be used": This is more a factural th= an a >>>>>>>> normative statement; it *can* not be used there as the server >> would >>>>>>>> respond thusly. It may be used, but then that indicates that t= he >>>>>>>> client is trying to verify a freshness. (However, the client s= hould >>>>>>>> not *start* sending an ETag once it learned the current resour= ce's >>>>>>>> ETag when still attempting to pull out more blocks, but that's= also >> not >>>>>>>> a normative requirement but a consequence of those two request= s >>>> not >>>>>>>> being matchable any more.) >>>>>>> [Jon] OK >>>>>>> OLD >>>>>>> The ETag Option MUST NOT be used in the request as the server >> could >>>>>>> respond with a 2.03 (Valid Response) with no payload. If the = server >>>>>>> responds with a different ETag Option value (as the resource >>>>>>> representation has changed), then the client SHOULD drop all t= he >>>>>>> payloads for the current body that are no longer valid. >>>>>>> NEW >>>>>>> The ETag Option should not be used in the request for missing >>>>>>> blocks as the server could respond with a 2.03 (Valid Response) >>>>>>> with no payload. It can be used in the request if the client want= s >>>>>>> to check the freshness of the currently cached body response. >>>>>>> >>>>>>> If the server detects part way through a body transfer that the >>>>>>> resource data has changed and the server is not maintaining a >>>>>>> cached copy of the old data, then the body response SHOULD be >>>>>>> restarted with a different ETag Option value. Any subsequent >>>>>>> missing block requests MUST respond using the latest ETag Option >> value. >>>>>>> If the server responds during a body update with a different ETa= g >>>>>>> Option value (as the resource representation has changed), then >>>>>>> the client should treat the partial body with the old ETag as no >>>>>>> longer being >>>>>> fresh. >>>>>>> END >>>>>>>> * "then the client SHOULD drop all the payloads for the current >> body": >>>>>>>> "Drop" is overly prescriptive; the client may well keep them, = but >>>>>>>> just can't consider them fresh any more. (If the client has am= ple >>>>>>>> caching abilities, they might come in handy if the resource go= es >> back >>>>>>>> to that ETag state). Same for later "the client MUST remove an= y >>>>>>>> partially received". >>>>>>> [Jon] See previous response, otherwise OLD >>>>>>> If the server transmits a new body of data (e.g., a triggered >>>>>>> Observe) with a new ETag to the same client as an additional >>>>>>> response, the client MUST remove any partially received body h= eld >> for >>>>>>> a previous ETag. >>>>>>> NEW >>>>>>> If the server transmits a new body of data (e.g., a triggered >>>>>>> Observe) with a new ETag to the same client as an additional >>>>>>> response, the client should remove any partially received body= >>>>>>> held >>>> for >>>>>>> a previous ETag for that resource as it is unlikely the missin= g >>>>>>> blocks can be retrieved. >>>>>>>> * "For Confirmable transmission, the client SHOULD continue to":= As >>>>>>>> above in the other direction, that's not news. >>>>>>> [Jon] Again, we are not looking for a response (well, a request i= n >>>>>>> this case as needed by Block2), just an ACK OLD >>>>>>> For Confirmable transmission, the client SHOULD continue to >>>>>>> acknowledge each packet as well as issuing a separate GET, POS= T, >> PUT, >>>>>>> FETCH, PATCH, or iPATCH for the missing blocks. >>>>>>> NEW >>>>>>> For Confirmable transmission, the server continues to acknowle= dge >>>>>>> each packet, but a response is not required (whether separate o= r >>>>>>> piggybacked) until successful receipt of the body or, if some o= f the >>>>>>> payloads are sent as Non-confirmable and have not arrived, a >>>>>>> retransmit missing payloads response is needed. >>>>>>>> * "If there is insufficient space to create a response PDU": I d= on't >>>>>>>> understand what that means. (Where are request options reflect= ed >>>>>>>> back?). >>>>>>> [Jon] This was triggered by a question by Michael Richardson " So= , >>>>>>> given a Christmas-Tree-Packet (largest packet, every possible >>>>>>> option space used, every extension turned on...) how much data ca= n >>>>>>> I get back? :-)" and not fully thought through. >>>>>>> It could happen though with Location-Path, Location-Query, >>>>>>> Q-Block2, ETag, >>>>>>> Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in >>>>>>> response to a POST. >>>>>>> OLD >>>>>>> If there is insufficient space to create a response PDU with a= block >>>>>>> size of 16 bytes (SZX =3D 0) to reflect back all the request o= ptions as >>>>>>> appropriate, a 4.13 (Request Entity Too Large) is returned wit= hout >>>>>>> the Size2 Option. >>>>>>> NEW >>>>>>> If there is insufficient space to create a response PDU with a= block >>>>>>> size of 16 bytes (SZX =3D 0) to send back all the response opt= ions as >>>>>>> appropriate, a 4.13 (Request Entity Too Large) is returned wit= hout >>>>>>> the Size1 Option. >>>>>>> >>>>>>>> * "If the client requests missing blocks, this is treated as a n= ew >>>>>>>> request.": I don't think the client should even make these fo= llow- >> up >>>>>>>> requests Observe, as it already has an ongoing observation. T= hey'd >> be >>>>>>>> sent on a different token too, so setting Observe would be op= ening >>>>>>>> observation up on that token, which AFAIU is not intended. (F= igure >> 7 >>>>>>>> example looks good to me in that respect.) >>>>>>>> >>>>>>>> (It may make sense to ask the client to keep Observe to make = the >>>>>>>> requests matchable just for the sake of staying in atomic-req= uest >>>>>>>> mode. Either way, the server should then not accept that >> observation >>>>>>>> as it's not for a block 0.) >>>>>>> [Jon] The intent here was that just a new Token should be used. >>>>>>> OLD >>>>>>> If the client requests missing blocks, this is treated as a ne= w >>>>>>> request. The Observe value may change but MUST still be repor= ted. >>>>>>> If the ETag value changes then the previously received partial= body >>>>>>> should be destroyed and the whole body re-requested. >>>>>>> NEW >>>>>>> If the client requests missing blocks, this is treated as a ne= w >>>>>>> Request and the Observe Option MUST NOT be included. If the = ETag >>>>>> value >>>>>>> changes, then the previously received partial body >>>>>>> should be considered as not fresh and the whole body re-reques= ted. >>>>>>> >>>>>>>> * "First is CBOR encoded Request-Tag": Why? Each 4.08 response >>>>>>>> can >>>> be >>>>>>>> matched by the token to a unique request that already had a >>>>>>>> Request-Tag, and the client needs to have kept that token arou= nd >>>>>>>> matched to the transfer to make sense of it. >>>>>>>> >>>>>>>> No need to move that value around between subsystems, and just= >>>>>>>> dropping it from here would also remove the need for the "If t= he >>>>>>>> client does not recognize the Request-Tag" clause (which would= >>>>>>>> otherwise need clarification as to what it'd mean if it recogn= izes it >>>>>>>> but it doesn't match what the request was for). >>>>>>> [Jon] Good question - it does make sense for the Request-Tag to b= e >>>>>>> tracked alongside the Token in the client. >>>>>>> OLD >>>>>>> The data payload of the 4.08 (Request Entity Incomplete) Respo= nse >>>>>>> Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR >> encoded >>>>>>> Request-Tag followed by 1 or more missing CBOR encoded missing= >>>> block >>>>>>> numbers. >>>>>>> NEW >>>>>>> The data payload of the 4.08 (Request Entity Incomplete) respo= nse >>>>>>> is encoded as a CBOR Sequence [RFC8742]. There are one or mor= e >>>>>> missing >>>>>>> CBOR encoded missing block numbers. >>>>>>> >>>>>>> OLD >>>>>>> ; This defines an array, the elements of which are to be u= sed >>>>>>> ; in a CBOR Sequence: >>>>>>> payload =3D [request-tag, + missing-block-number] >>>>>>> request-tag =3D bstr >>>>>>> ; A unique block number not received: >>>>>>> missing-block-number =3D uint NEW >>>>>>> ; This defines an array, the elements of which are to be u= sed >>>>>>> ; in a CBOR Sequence: >>>>>>> payload =3D [+ missing-block-number] >>>>>>> request-tag =3D bstr >>>>>>> ; A unique block number not received: >>>>>>> missing-block-number =3D uint >>>>>>> >>>>>>> OLD >>>>>>> A 4.08 (Request Entity Incomplete) Response Code returned with= >>>>>>> Content-Type "application/missing-blocks+cbor-seq" indicates t= hat >>>>>>> some of the payloads are missing and need to be resent. The c= lient >>>>>>> then re-transmits the missing payloads using the Request-Tag a= nd >>>>>>> Q-Block1 to specify the block number, SZX, and M bit as approp= riate. >>>>>>> The Request-Tag value to use is determined from the payload of= the >>>>>>> 4.08 (Request Entity Incomplete) Response Code. If the client= does >>>>>>> not recognize the Request-Tag, the client can ignore this resp= onse. >>>>>>> NEW (option presentation has been reformatted) >>>>>>> 4.08 (Request Entity Incomplete) >>>>>>> >>>>>>> This Response Code returned with Content-Type "application/ >>>>>>> missing-blocks+cbor-seq" indicates that some of the payloads ar= e >>>>>>> missing and need to be resent. The client then retransmits the >>>>>>> missing payloads using the same Request-Tag, Size1 and Q-Block1= >>>>>>> to specify the block number, SZX, and M bit as appropriate. >>>>>>> >>>>>>> >>>>>>> The Request-Tag value to use is determined from the token in the= >>>>>>> 4.08 (Request Entity Incomplete) response and then finding the >>>>>>> matching client request which contains the Request-Tag that is >>>>>>> being used for this Q-Block1 body. END >>>>>>>> * "limit the array count to 23 (Undefined value)": 23 is the max= imum >>>>>>>> length of a zero-byte length indication, not indefinite-length= (31). >>>>>>>> Both using 23 and 31 here makes sense (up to 23 to have defini= te >>>>>>>> length that can be updated in-place, or exceeding that switch = to >>>>>>>> indefinite length if they still fit), but the paragraph seems = to be >>>>>>>> mixing them up. >>>>>>> [Jon] OK >>>>>>> OLD >>>>>>> Arrays (Section 3.2.2 of [RFC8949]), limit the array count = to 23 >>>>>>> (Undefined value) so that the array data byte can be update= d with >>>>>>> the overall length once the payload length is confirmed or = limited >>>>>>> to MAX_PAYLOADS count. >>>>>>> NEW >>>>>>> Arrays (Section 3.2.2 of [RFC8949]), or alternatively limit= >>>>>>> the array count to >>>>>>> 23 so that the initial byte with the array major type and >>>>>>> data length in the additional information can be updated with the= >>>>>>> overall count once the payload count is confirmed. Further >>>>>>> restricting the count to MAX_PAYLOADS means that congestion >>>>>>> control is less likely to be >>>>>> invoked on the server. >>>>>>>> * "Each new request MUST use a unique token": Like above, this i= s >>>>>>>> stating something that's not intended to be changed. >>>>>>> [Jon] RFC7252 does not require Tokens to be unique - e.g. empty >>>>>>> token values are acceptable. Hence this statement. >>>>>>>> Congestion Control: >>>>>>>> >>>>>>>> * "Each NON 4.08 (Request Entity Incomplete) Response Codes is >>>>>> subjected >>>>>>>> to PROBING_RATE.": That is unexpected here. At most one such >>>>>>>> response is sent to each request message, so why is additiona= l >>>>>>>> congestion control needed? >>>>>>> [Jon] The intention here was that in the previous paragraph that >>>>>>> it was not the individual packets that are subject to >>>>>>> PROBING_RATE, but a single body comprising of multiple packets is= >>>>>>> subject to PROBRING_RATE >>>>>>> - and hence limiting any individual responses to PROBING_RATE >>>>>>> rather than the potentially full set of responses OLD >>>>>>> PROBING_RATE parameter in CoAP indicates the average data rate= >> that >>>>>>> must not be exceeded by a CoAP endpoint in sending to a peer >>>> endpoint >>>>>>> that does not respond. The body of blocks will be subjected t= o >>>>>>> PROBING_RATE (Section 4.7 of [RFC7252]). >>>>>>> NEW >>>>>>> PROBING_RATE parameter in CoAP indicates the average data rate= >> that >>>>>>> must not be exceeded by a CoAP endpoint in sending to a peer >>>> endpoint >>>>>>> that does not respond. The single body of blocks will be subj= ected >> to >>>>>>> PROBING_RATE (Section 4.7 of [RFC7252]), not the individual >> packets. >>>>>>> If the wait time between sending bodies that are not being >>>>>>> responded to based on PROBING_RATE exceeds >> NON_PROBING_WAIT, >>>>>> then the >>>>>>> gap time is limited to NON_PROBING_WAIT. >>>>>>> >>>>>>> Note: For the particular DOTS application, PROBING_RATE and other= >>>>>>> transmission parameters are negotiated between peers. Even when >>>>>>> not negotiated, the DOTS application uses customized defaults as >>>>>>> discussed in Section 4.5.2 of [RFC8782]. >>>>>>> END >>>>>>>> On the other hand, *ever* NON request is subject to >>>>>>>> PROBING_RATE, >>>> so >>>>>>>> why point out the body of blocks and "GET or similar" particu= larly? >>>>>>> [Jon] It is only GET or FETCH. The intention here is to not >>>>>>> request bodies of data at too high a rate. >>>>>>> OLD >>>>>>> Each NON GET or similar request using Q-Block2 Option is subje= cted >> to >>>>>>> PROBING_RATE. >>>>>>> NEW >>>>>>> Each NON GET or FETCH request using Q-Block2 Option is >>>>>>> subjected to PROBING_RATE. >>>>>>>> * "a delay is introduced of ACK_TIMEOUT": As I understand >>>>>> MAX_PAYLOADS, >>>>>>>> this is (rather implicitly) introduced as the package count up= to >>>>>>>> which it is OK to exceed PROBING_RATE temporarily (but after t= hat >> it >>>>>>>> kicks in all the harder by requiring to wait until complete-se= nt- >> bytes >>>>>>>> over PROBING_RATE has expired). If that holds, at that time a = much >>>>>>>> larger delay than just ACK_TIMEOUT is needed to get a response= >> from >>>>>>>> the server: About 3 hours (see later note on parameters). >>>>>>> [Jon] Now limited to 247 seconds (NON_PROBING_WAIT). See re- >> write >>>>>>> of Congestion Control section. >>>>>>>> This is the crucial point in the document, and for it a >> recommendation >>>>>>>> alone is not good enough. The protocol can be run with a vastl= y >>>>>>>> increased PROBING_RATE (however externally determined) and >> from >>>>>> the >>>>>>>> point of MAX_PAYLOADS just observe it. Or it has to get >>>>>>>> feedback >>>> from >>>>>>>> the server; a single 4.08 is probably enough to kick off anoth= er >>>>>>>> vollley of blocks. (How many? MAX_PAYLOADS for every >> response?). >>>>>>>> Both can be permitted, but just waiting ACK_TIMEOUT isn't doin= g >> any >>>>>>>> good. >>>>>>> [Jon] See re-write of Congestion Control section where things >>>>>>> should now be simpler and more logical. There is an introduction= >>>>>>> of new variable definitions. >>>>>>>> * "For NON transmissions": This seems to imply that the full >>>>>>>> exchange >>>> of >>>>>>>> a body is either NON or CON; I don't see where that'd come fro= m. >> I'd >>>>>>>> have expected to read something like "Each individual request = can >> be >>>>>>>> NON or CON independent of the others. In particular, it can be= >>>>>>>> convenient to send the ultimate payload...". >>>>>>> [Jon]The DOTS environment will only be using NON. To make >>>>>>> Congestion Control simple, the expectation is that all >>>>>>> transmissions are NON or (not recommended) are all CON. The draft= >>>>>>> now generally records this expectation. >>>>>>>> * "If a Confirmable packet is used, then the transmitting peer >>>>>>>> MUST >>>> wait >>>>>>>> for the ACK": Why? A NSTART > 1 would give it leisure to still= >>>>>>>> transmit. >>>>>>> [Jon] Text has been removed in the clean-up. >>>>>>>> * General on congestion control: It may help implementors if thi= s >> were >>>>>>>> split up into newly introduced rules and concepts (that is, >>>>>>>> MAX_PAYLOADS and the answer to whether you may send >>>>>> MAX_PAYLOADS en >>>>>>>> block again after having only even one response from the last >> round, >>>>>>>> and probably the recommended parameters of the "Also on >>>>>> parameters" >>>>>>>> comment), and another subsection on how Q-Block behaves well >>>> when >>>>>>>> observing these. >>>>>>> [Jon] Should now be covered in the updated Congestion Control >>>> section. >>>>>>>> Caching: >>>>>>>> >>>>>>>> * "are not part of the cache key": How about "are removed as par= t >>>>>>>> of >>>> the >>>>>>>> block assembly and thus do not reach the cache"? >>>>>>> [Jon] OK. >>>>>>> OLD >>>>>>> As the entire body is being cached in the proxy, the Q-Block1 = and >>>>>>> Q-Block2 Options are not part of the cache key. >>>>>>> NEW >>>>>>> As the entire body is being cached in the proxy, the Q-Block1 = and >>>>>>> Q-Block2 Options are removed as part of the block assembly and= >>>>>>> thus do not reach the cache. >>>>>>>> * "When the next client completes building the body": If the pro= xy >>>>>>>> chooses not to let them happen in parallel (which it may, see >>>>>>>> above >>>> on >>>>>>>> parallel requests, although the server might still not support= it and >>>>>>>> cancel one of them), why bother letting the first finish just = to abort >>>>>>>> it? (IOW: If the proxy does not intend to see both through, wh= ich it >>>>>>>> could if it held back the second until the first is through on= the >>>>>>>> uplink, it could just as well err out of one of them early, bu= t it may >>>>>>>> also rather see both through.) >>>>>>> [Jon] It has to be assumed that traffic to/from the origin client= >>>>>>> and origin server may not both support Q-Blockx and potentially >>>>>>> may have a different SZX. Thus passing a request or a response >>>>>>> through at the block level introduces a new set of challenges (bu= t >>>>>>> not impossible to fix). To keep this simple, my thinking was tha= t >>>>>>> the passing through can only take place at the body level. Again= , >>>>>>> the arrival of packets is not necessarily sequential, so client >>>>>>> A's body may start transmitting to the origin server first, but >>>>>>> client B's body starts to arrive first - the same being true for >>>>>>> the proxy as a client may stop transmitting for whatever reason >>>>>>> (restart, network loss >>>> etc.). >>>>>>> However this is covered by the above update " If a server >>>>>>> receives payloads with different Request-Tags for the same >>>>>>> resource, it should >>>>>> continue to process all the bodies". >>>>>>> OLD >>>>>>> and the new body representation transmission starts with a new= >>>>>>> Request-Tag value. >>>>>>> NEW >>>>>>> and the new body representation transmission starts with a new= >>>>>>> Request-Tag value. Note that it cannot be assumed that the >>>>>>> proxy will always receive a complete body from a client. >>>>>>>> * Examples: >>>>>>>> >>>>>>>> * Figure 5: The ... between e3 request and response indicate t= he >>>>>>>> MAX_TRANSMIT_SPAN before sending the 4.08 response. I >> suppose >>>>>> there >>>>>>>> should be the same kind of delay between the failed e5 >> transmission >>>>>>>> and the e4 response. >>>>>>> [Jon] Agreed and added in >>>>>>>> * If the second burst had 3 requests out of which 2 made it, i= s there >>>>>>>> any guidance for which of them the 4.08 would come back on? = (In >> the >>>>>>>> end, none of them is terminal). >>>>>>> [Jon] The client should tracking all Tokens of the burst (hence >>>>>>> implementation note about bottom 32bits unique and top 32 bits >>>>>>> matching block number for ease of tracking) for a response and so= >>>>>>> it will make no difference at to which token is used for the 4.08= >>>>>>> response. From an implementation perspective, it probably is >>>>>>> easier to track the last opaque token that has the same Request-T= ag. >>>>>>> OLD >>>>>>> missing ones in one go (Figure 5). It does so by indicating w= hich >>>>>>> blocks have been received in the data portion of the response.= >>>>>>> NEW >>>>>>> missing ones in one go (Figure 5). It does so by indicating w= hich >>>>>>> blocks have been received in the data portion of the response.= >>>>>>> The Token just needs to be one of those that have been received >>>>>>> for this Request-Tag , so the client can derive the Request-Tag. >>>>>>>> * If that e4 response gets lost, does the whole mechanism >>>>>>>> recover >>>> from >>>>>>>> it in any way? >>>>>>> [Jon] In this example, if e4 and e5 get lost, there will be no >>>>>>> 4.08/2.01/2.04/5.xx etc. response, so it is up to the client as t= o >>>>>>> whether it sends the request again or gives up. See 9.1 >>>>>>> "Under high levels of traffic loss, the client can elect not to= retry >>>>>>> sending missing blocks of data. This decision is implementati= on >>>>>>> specific." >>>>>>>> Generally, the all-NON and all-CON examples don't look to me= like >>>>>>>> what I'd be doing with this spec; the mixed "a CON every >>>>>>>> MAX_PAYLOADS" appears much more realistic. >>>>>>> [Jon] It is unsafe to use CON in the (potentially lossy) DOTS >>>>>>> environment (up to 93 secs timeout per payload with the defaults)= =2E >>>>>>> Hence why we are separating out the NON / CON usage. >>>>>>>> * Figure X: The request ahs M unset and thus indicats a reques= t for >>>>>>>> just that block. If more than one is expected, it should say= >>>>>>>> QB2:0/1/1024. >>>>>>> [Jon] With Figure 7, with the M bit set, block 3 would get >>>>>>> returned for a second time. Draft-ietf-core-new-block-03 also ha= s >>>>>>> a Figure 8 which does exactly what you describe. >>>>>>>> * New Content Format: I think this needs a media type >>>>>>>> registration to >>>> go >>>>>>>> with it first; based on that, a content format can be register= ed. >>>>>>> [Jon] Med has responded to this and draft updated. >>>>>>>> * General on MAX_TRANSMIT_SPAN and other timing parameters: >> I'm >>>> not >>>>>>>> sure >>>>>>>> they're 1:! applicable here. For example, MAX_TRANSMIT_SPAN is= >>>>>> defined >>>>>>>> in terms of reliable transmission, but used for NONs as well. = (So is >>>>>>>> the alternative ot 2x ACK_TIMEOUT). >>>>>>> [Jon] I hear you about the use of MAX_TRANSMIT_SPAN and >>>> ACK_TIMEOUT >>>>>> in >>>>>>> a NON environment. Hence re-write of Congestion Control section >>>>>>> defining new variables that can be used for NON. >>>>>>>> For the purpose of delaying a 4.08 or a follow-up GET, it may = make >>>>>>>> more sense to define a new parameter based on MAX_LATENCY and >>>> the >>>>>>>> time >>>>>>>> it takes the sender to pump out the options (which I don't thi= nk we >>>>>>>> have a good factor for, but may even be negligible here). >>>>>>>> >>>>>>>> Could read like this: >>>>>>>> >>>>>>>> > The timing parameter MAX_BLOCK_JITTER is introduced, and by >>>>>> default >>>>>>>> > takes a value of MAX_LATENCY + MAX_PAYLOADS * MTU / >>>>>> BANDWIDTH. >>>>>>> [Jon] Lets plug in some numbers here. MAX_LATENCY =3D 100, >>>>>>> MAX_PAYLOADS =3D 10, MTU =3D 1280bytes and BANDWIDTH =3D 1Mbps. >>>>>>> >>>>>>> [Jon] MAX_BLOCK_JITTER =3D 100 + (10 * 1280 * 8)/(1 000 000) =3D = 100.1. >>>>>>> So BANDWITH of 1Mbps has negligible effect on the calculation. >>>>>>> 1Kbps makes MAX_BLOCK_JITTER 200 seconds. >>>>>>>> > >>>>>>>> > With Q-Block2, a client can ask for any missing blocks after= not >>>>>>>> > having received any further response for the duration of >>>>>>>> > MAX_BLOCK_JITTER. >>>>>>> [Jon] 100+ seconds delay is way too much time to wait for any >>>>>>> missing blocks in my opinion. >>>>>>> >>>>>>> [Jon] RFC7252 also states (and the intention is that recovery >>>>>>> works >>>>>>> well) " as MAX_LATENCY is not >>>>>>> intended to describe a situation when the protocol works we= ll, but >>>>>>> the worst-case situation against which the protocol has to = guard." >>>>>>>> > >>>>>>>> > With Q-Block1, a server holds off any response for >>>> MAX_BLOCK_JITTER >>>>>>>> > unless all blocks have been received. Only then it evaluates= >>>> whether >>>>>>>> > to respond with a 2.0x code, a 4.08 with payload, or not at = all >>>>>>>> > (because it responded to a later request). >>>>>>> [Jon] I am not convinced that this is necessarily the way to go. >>>>>>> The new Congestion Control more cleanly handles this. >>>>>>>> This also brings me back to the earlier matter of 2.31: What i= s a >>>>>>>> server supposed to send when no packages were lost, but it's >> pasing >>>>>>>> the timeout and wants to help the client flush out more packag= es >> by >>>>>>>> confirming something? It says 4.08 in 3.3, but it's not like t= here's a >>>>>>>> hole in the contiguous range. Does it need to send 4.08 >> enumerating >>>>>>>> all (or at least some) numbers between the first unreceived an= d >>>> what's >>>>>>>> indicated by Size1? Or can it just send 2.31 and the client kn= ows all >>>>>>>> it needs to know b/c the response came to the largest block th= at >> was >>>>>>>> sent and 2.31 indicates that everything is good up to that poi= nt? >>>>>>> [Jon] The previous draft states (under Congestion Control) that >>>>>>> the client waits for ACK_TIMEOUT before transmitting the next set= >>>>>>> of MAX_PAYLOADS blocks. The server should wait for "two times >>>>>>> ACK_TIMEOUT " (3.3) before indicating issue. Apart from perhaps >>>>>>> having a new name for ACK_TIMOUT I think that these are reasonabl= e >>>>>>> values for Non-Confirmable - and are used in the new Congestion >>>>>>> Control >>>>>> section. >>>>>>> [Jon] I have reworked Congestion Control to use 2.31 (NON only) a= s >>>>>>> a signal to say that all of the current MAX_PAYLOADS payloads of = a >>>>>>> body have been received, so allowing the client to continue >>>>>>> transmitting the next set of MAX_PAYLOADS payloads without the >>>>>>> need to wait any >>>>>> longer. >>>>>>>> * Also on parameters: This document is describing flow control s= tuff >>>>>>>> around a situation CoAP was not originally designed for. Would= n't it >>>>>>>> make sense to include a set of parameters (PROBING_RATE, >>>>>> MAX_LATENCY, >>>>>>>> ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt th= at >>>>>>>> PROBING_RATE will be left to 1 byte/second for any DOTS >> application >>>>>>>> using this (for sending 10KiB in the initial 10-package >> MAX_PAYLOADS >>>>>>>> burst would mark that connection as unusable for about 3 hours= >>>>>>>> if >>>> they >>>>>>>> all get lost), so better give justifiable numbers here than re= ly on >>>>>>>> implemnetors to come up with unreviewed numbers or disregard >>>>>>>> PROBING_RATE altogether. >>>>>>> [Jon] Answered by Med, and some new text added. >>>>>>>> I don't know if it needs additional justification, but an incr= eased >>>>>>>> N_START may be justifiable there. >>>>>>> [Jon] It may be, but tuning the other associated parameters is >>>>>>> really out of the cope of this draft. This text has been added NE= W >>>>>>> Congestion control for CON requests and responses is specified in= >>>>>>> Section 4.7 of [RFC7252]. For faster transmission rates, NSTART = will >>>>>>> need to be increased from 1. However, the other CON congestion= >>>>>>> control parameters will need to be tuned to cover this change. = This >>>>>>> tuning is out of scope of this document as it is expected that = all >>>>>>> requests and responses using Q-Block1 and Q-Block2 will be Non-= >>>>>>> confirmable. >>>>>>>> * Somewhere (never comes up but I think it should): When CONs ar= e >>>>>> used, >>>>>>>> a 4.08 (or 2.31?) response to a later request can indicate to = the >>>>>>>> client that an earlier CON request has been processed successf= ully. >> If >>>>>>>> the client can match that up (and it should be able to), then = it can >>>>>>>> (and should) cancel that particular CON request. >>>>>>> [Jon] I think that this is covered by my update above with the te= xt " >>>>>>> NEW >>>>>>> For Confirmable transmission, the server continues to acknowle= dge >>>>>>> each packet, but a response is not required (whether separate o= r >>>>>>> piggybacked) until successful receipt of the body or, if some o= f the >>>>>>> payloads are sent as Non-confirmable and have not arrived, a >>>>>>> retransmit missing payloads response is needed." >>>>>>> >>>>>>> And in my previous part 1 response (updated) NEW For Confirmable >>>>>>> transmission, the server continues to acknowledge each packet, >>>>>>> but a response is not required (whether separate or >>>>>>> piggybacked) until successful receipt of the body or, if some of= the >>>>>>> payloads are sent as Non-confirmable and have not arrived, a >>>>>>> retransmit missing payloads response is needed. >>>>>>>> Best regards >>>>>>>> Christian >>>>>>>> >>>>>>>> -- >>>>>>>> There's always a bigger fish. >>>>>>>> -- Qui-Gon Jinn >>>>>>> _______________________________________________ >>>>>>> core mailing list >>>>>>> core@ietf.org >>>>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >>>>>> w. >>>>>> >> ietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloc >>>>>> a%4 >>>>>> >> 0ri.se%7C52440c4d23e244168b2108d8b2574780%7C5a9809cf0bcb413a838a09 >>>>>> ecc4 >>>>>> >> 0cc9e8%7C0%7C0%7C637455435959417764%7CUnknown%7CTWFpbGZsb3d8 >>>>>> eyJWIjoiMC >>>>>> >> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000& >>>>>> amp;sd >>>>>> >> ata=3DtEJ8tHhaLeWl4dtblsDzyli5TBSmfnRTxdepcwxhYzY%3D&reserved=3D0 >>>>>> -- >>>>>> 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://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >>>> w >>>> >> .ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2385ef89ef574a7 >>>> c8 >>>> >> 1f608d8b3da00ba%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637 >>>> 45709 >>>> >> 6666457035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj >>>> oiV2luMz >>>> >> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DiJgJcxZmwbaLrb >>>> mzIuz >>>>>> SjezxDRq47wwWcNvFC7ox8bw%3D&reserved=3D0 >>>>>> >>>> -- >>>> 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://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >> w >> .ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C8651a6788136434 >> 84 >> 22608d8b3f94057%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637 >> 45723 >> 0862239405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj >> oiV2luMz >> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3Dpo%2BnNJAbUW >> 7Jf9cMF >>>> xoP8VXDd1%2FfS%2BsyTl4dePY5A9o%3D&reserved=3D0 >>>> >> -- >> 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://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C2744bb09ef5945b3d8= 9808d8b61c4788%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374595804552= 50109%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI= 6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DQKcdNBcFq%2BaG5omNRN1UjaRJ2E5E= V%2FRiw0%2BQ%2FfuSyK0%3D&reserved=3D0 >> > --=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 --AZUxISfTlovYtzMUqTfbBCRvG9nzs4NNW-- --WtB71mJpZTCXzs72Eamrly3icdUsQg1Y7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/8OMcACgkQ7iZktA5Y 2kPrVgf/Yp7AlY52Vs2tWEAdwOocUd/ER+IohY61nSQcCo4MAy6caQDoeVScMwEw 2TlDKt8rZkXtJKvCf6cVA8L21DpCBw7pLKG1gIpxVOR8SnY2rOW4Fuyn0vsYJRzS /YdtHCnehBVYmhKGsaw2pif9Ixw56BXOPyErzUV5sSZ1DEzfUptGoBGhKEue2/hJ oquL2yJr6pbj/u7qY+Sb/mH3Di16U9+m1cQCI00wCultGMN9Cp77zRGTxFDUluIe zhLHTaHJYwYcwEHkYpRRSacu1tlnrvZtVw3IGW7Huq+8aGOFu7imbXct1JvCwX4P AQHLsCOPqOqSL6tar6WZhc0YuTPIww== =GW3k -----END PGP SIGNATURE----- --WtB71mJpZTCXzs72Eamrly3icdUsQg1Y7-- From nobody Mon Jan 11 04:10:19 2021 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 EFD933A0C38 for ; Mon, 11 Jan 2021 04:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.818 X-Spam-Level: X-Spam-Status: No, score=-2.818 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 RjPYjy8LCsGV for ; Mon, 11 Jan 2021 04:06:49 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A023A0C84 for ; Mon, 11 Jan 2021 04:06:32 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 4DDsr71rPdz1yKT for ; Mon, 11 Jan 2021 13:06:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610366791; bh=qsXw4/PQhwUmWr2qZcenvoto2seaCLYzEju00FjbQ84=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=IE7LCXEMDxUh1pnxyyKp/+qvq1THQ9zgtDlgCRvaZzbfMgHZieAIVHtfitfNyAjDX 0FZgoKeK5F7TF21v8XtbT1dvRx/RiXfYD7uUfoj5pn3RFI641L/tVnNMzm45ggGMaH zKwBGgpLx5ZDizjLv81e0lmpDF3BPc7SzQArGuIdJIU2By6SMPPxEW5PiFeKENKOAi pavP3jqkyYlEMcEg3y6Ii0KBfHXtLK0G6V5wsWfvpY6eIOL+ukd6qlnGGkJooS8ID3 sOPxAdwC9RXjmOAbyGhkwNbifVprG+3IQzri3yaiyYtn9pH5OGo1ala9BbpQJGuSlD QrK5iFCD1SlAQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4DDsr71C1HzyQV for ; Mon, 11 Jan 2021 13:06:31 +0100 (CET) From: To: "dots@ietf.org" Thread-Topic: New Version Notification for draft-bosh-dots-quick-blocks-00.txt Thread-Index: AQHW6BE+e4a7glWno0iUb+SxdUBAEKoiUnHw Date: Mon, 11 Jan 2021 12:06:30 +0000 Message-ID: <30501_1610366791_5FFC3F47_30501_159_2_787AE7BB302AE849A7480A190F8B9330315B71FE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <161036637813.11527.15818091495971687767@ietfa.amsl.com> In-Reply-To: <161036637813.11527.15818091495971687767@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 11 Jan 2021 04:10:18 -0800 Subject: [core] TR: New Version Notification for draft-bosh-dots-quick-blocks-00.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, 11 Jan 2021 12:06:51 -0000 SGkgYWxsLCANCg0KKENjaSdpbmcgY29yZSBXRyB3aGVyZSB0aGUgbmV3IGJsb2NrcyBhcmUgZGVm aW5lZCkNCg0KVGhpcyBzcGVjIGRlZmluZXMgbmV3IGF0dHJpYnV0ZXMgdGhhdCBjYW4gYmUgbmVn b3RpYXRlZCBiZXR3ZWVuIERPVFMgYWdlbnRzIHRoYXQgc3VwcG9ydCBRLUJsb2NrMS8yLiBBcyBh IHJlbWluZGVyLCB0aGVzZSBvcHRpb25zIGFyZSBkZXNpZ25lZCB0byBhbGxvdyBmb3IgZmFzdGVy IHRyYW5zbWlzc2lvbiBpbiBET1RTLWxpa2UgZW52aXJvbm1lbnRzLiANCg0KQ29tbWVudHMgYXJl IHdlbGNvbWUuIA0KDQpDaGVlcnMsDQpKb24gJiBNZWQNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQpEZcKgOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddIA0KRW52b3nDqcKgOiBsdW5kaSAxMSBqYW52aWVyIDIwMjEgMTM6MDAN CsOAwqA6IEpvbiBTaGFsbG93IDxzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPjsgQk9VQ0FEQUlS IE1vaGFtZWQgVEdJL09MTiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCk9iamV0wqA6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYm9zaC1kb3RzLXF1aWNrLWJsb2Nr cy0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYm9zaC1kb3RzLXF1aWNr LWJsb2Nrcy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTW9oYW1l ZCBCb3VjYWRhaXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJ ZHJhZnQtYm9zaC1kb3RzLXF1aWNrLWJsb2Nrcw0KUmV2aXNpb246CTAwDQpUaXRsZToJCURpc3Ry aWJ1dGVkIERlbmlhbC1vZi1TZXJ2aWNlIE9wZW4gVGhyZWF0IFNpZ25hbGluZyAoRE9UUykgU2ln bmFsIENoYW5uZWwgQ29uZmlndXJhdGlvbiBBdHRyaWJ1dGVzIGZvciBGYXN0ZXIgQmxvY2sgVHJh bnNtaXNzaW9uDQpEb2N1bWVudCBkYXRlOgkyMDIxLTAxLTExDQpHcm91cDoJCUluZGl2aWR1YWwg U3VibWlzc2lvbg0KUGFnZXM6CQkxNA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL2FyY2hpdmUvaWQvZHJhZnQtYm9zaC1kb3RzLXF1aWNrLWJsb2Nrcy0wMC50eHQNClN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib3NoLWRv dHMtcXVpY2stYmxvY2tzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYm9zaC1kb3RzLXF1aWNrLWJsb2Nrcw0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3NoLWRvdHMtcXVpY2stYmxv Y2tzLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBuZXcgRE9U UyBzaWduYWwgY2hhbm5lbCBjb25maWd1cmF0aW9uDQogICBwYXJhbWV0ZXJzIHRoYXQgYXJlIG5l Z290aWF0ZWQgYmV0d2VlbiBET1RTIHBlZXJzIHRvIGVuYWJsZSB0aGUgdXNlDQogICBvZiBRLUJs b2NrMSBhbmQgUS1CbG9jazIgT3B0aW9ucy4gIFRoZXNlIG9wdGlvbnMgZW5hYmxlIGZhc3Rlcg0K ICAgdHJhbnNtaXNzaW9uIHJhdGVzIGZvciBsYXJnZSBhbW91bnRzIG9mIGRhdGEgd2l0aCBsZXNz IHBhY2tldA0KICAgaW50ZXJjaGFuZ2VzIGFzIHdlbGwgYXMgc3VwcG9ydGluZyBmYXN0ZXIgcmVj b3Zlcnkgc2hvdWxkIGFueSBvZiB0aGUNCiAgIGJsb2NrcyBnZXQgbG9zdCBpbiB0cmFuc21pc3Np b24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsg eW91LgoK From nobody Mon Jan 11 08:39:11 2021 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 0E6FA3A1048 for ; Mon, 11 Jan 2021 08:39:09 -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_DNSWL_BLOCKED=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 emZ3odfk9H6W for ; Mon, 11 Jan 2021 08:39:07 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 0437C3A103A for ; Mon, 11 Jan 2021 08:39:06 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kz0Df-0006d3-Vx; Mon, 11 Jan 2021 16:39:04 +0000 From: To: "Marco Tiloca" , , , Cc: , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <065301d6e805$286163c0$79242b40$@jpshallow.com> In-Reply-To: Date: Mon, 11 Jan 2021 16:39:14 -0000 Message-ID: <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAFUavWxAaeeZ2wB9CJyVQGW5zMSAr51FjUBa6IWcAGdmCj+qF8iPgA= Content-Language: en-gb Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 11 Jan 2021 16:39:09 -0000 Hi Marco, It is good that you are thinking this properly through. FETCH was added = later into this draft and the consequences were not properly thought = through. The new updates have been pushed to https://github.com/core-wg/new-block = and the differences with the draft can be found at = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-new-block&url2=3Dhttp= s://raw.githubusercontent.com/core-wg/new-block/master/draft-ietf-core-ne= w-block.txt The PR for the responses below can be found at = https://github.com/core-wg/new-block/pull/13=20 Otherwise, see inline. Regards Jon > -----Original Message----- > From: Marco Tiloca [mailto: marco.tiloca@ri.se] > Sent: 11 January 2021 11:39 > To:supjps-ietf@jpshallow.com; christian@amsuess.com; = draft-ietf-core-new- > block@ietf.org > Cc: dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hi Jon, >=20 > Thanks, the updates look good. [Jon] Thanks >=20 > As to the response codes in Section 3.3 "Using the Q-Block1 Option", > wouldn't it make sense to mention also 2.05 (Content) ? Think of a = FETCH > request with a big body, which is actually mentioned at the beginning = of > Section 3.3 and in Section 3.1 (though missing the 2.05 response code > beside it). [Jon] Thanks - added. Also added in 2.02 and 2.05 as being expected = response codes in 3.3. [Jon] For the 2.02, I struggle with why anyone would want to use a POST = with a large payload to cause the resource to get deleted (instead of = using DELETE) , but RFC7252 allows this to happen. OLD Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH, PATCH, and iPATCH requests and their responses (2.01 and 2.04). NEW Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH, = PATCH, and iPATCH requests and their responses (2.01, 2.02, 2.04, and = 2.05). [Jon] And added into 3.3 (2.05 is done further into this discussion) NEW 2.02 (Deleted) This Response Code indicates successful receipt of the entire body and = the resource was deleted when using POST (See Section 5.8.2 [RFC7252]). = The token used SHOULD be from the last received payload. The client = should then release all of the tokens used for this body. >=20 > Also, more in general, think of an observe registration, for which the > server eventually sends back a first notification (possibly split into > multiple payloads) with Q-Block2, with a certain Token value. [Jon] OK >=20 > If the observation request used FETCH and was fragmented into several > payloads with Q-Block1, each of which with a different Token, it's = still > true that the notifications can all have any of those Token values and > should have the one of the last received request payload. Jon[OK] >=20 > However, later on the client has to retain that Token value as the one > associated to the observation, to match future notifications to come. = In > this case, there is a deviation from the claim used for other response > codes, i.e. "The client should then release all of the tokens used for > this body." This should concern only 2.01 notifications (hence = including > the Observe option) in response to observation requests with FETCH, so > it can be limited to the context of this section about Q-Block1. [Jon] I was not aware that FETCH could return 2.01 or 2.04. GET does = not return these codes and it is only GET and FETCH that can Observe. = However, it is true what you say for 2.05, so I have added that the = tracked Observe token must be the (if Q-Block1) the one used for = Q-Block1 that has the M bit unset. I have added in some FETCH examples = into the draft. NEW 2.05 (Content) This Response Code indicates successful receipt of the entire FETCH = request body (See Section 2 [RFC8132]) and the appropriate = representation of the resource has been returned. The token used in the = response MUST be the one in the FETCH request that has the Q-Block1 with = the M bit unset. If the FETCH request includes the Observe Option, then = the server MUST use the same token for returning any Observe triggered = responses. The client should then release all of the tokens used for = this body unless a resource is being observed. ~jon >=20 > Best, > /Marco >=20 From nobody Mon Jan 11 11:23:29 2021 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 BB96F3A10E6; Mon, 11 Jan 2021 11:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 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.262, 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 2yn2-haQ7WPo; Mon, 11 Jan 2021 11:23:20 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150049.outbound.protection.outlook.com [40.107.15.49]) (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 3B9353A10DF; Mon, 11 Jan 2021 11:23:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eW+evJa9PqzwqaY7Fq7+olx2f3/irw2j43A9w+68YR2FxvYWkr97Oyc2/26oLGadsoE3O5VUbWhjkFc79FY561K9RqWSyUVuR3lx4JcGpEiIt9B6SdJ+N3u6CPA7B+HRDfNNbitrHu+inLLr9z8m7JhxXbxVtHi5EaF1EkbptwPkr1ynOHuNwBSc5A71hn83AFEkIl3Ct5/UHRGfpo/Fzawny2iZuy/rxUtur13R/l8Wja2erNiu5UxYw6LJOLYsjl/wccKqLQ9ZOaGFDI8tpQcUFCMDQfg0iFSLHxy8S29cylBDQkmCNNCdHwKU9xI0uV+TH/AalDRM6bFUL+ArJw== 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=6LSligQpzMUYWntm2/EfhNzk0t0QNU49hV2nZM0/J58=; b=Us6mf6UWEnIFEMIbpsvfjNiLtzQmk7WMCcB+AUJr7vzWrbSlD7jmbPj589FdltMOEdI1AqA2dzq2Lg+gbNhs5I+W/MYTPzkz4JEpmE+nB/RUfzDTzDwggmhV8gM/zNKAxcRMmBwIVRsizyeWD3XG9+koCYZXq1AlSTw5AWBKjGCV9fre8heBbpfPSRa5umuRLli+dfC0w0NeudmTtU/HV39Xk/Ovc42qAwJppEYKafXvC54nAMgwVY2PCa8olEm+Ylmxe4tHg1DVHZmhQ5giJZK5y5WTKkgm+90L7qHlIV2qY68FkMusNN9Qi8ytwz/EYubV9H/JlH53nlJIhTdluw== 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=6LSligQpzMUYWntm2/EfhNzk0t0QNU49hV2nZM0/J58=; b=GDec57LWJ/kT49HN2wzBuGcSLoUxpHaNWzO0eSMhH3wgmAh6AY2SrJ7pY20OClNRcFHEOYIj/k2Clv0dZhpKKtkjX4JvnJg7SvpNvaWt11EQOTPbrVzYmRLtgGFDwVaXA3n8drQ3RK3f03e1VR4flETFpxJ4blvblH9xi6nrfks= 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 DBBP189MB1308.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:1e5::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Mon, 11 Jan 2021 19:23:15 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3742.012; Mon, 11 Jan 2021 19:23:15 +0000 To: supjps-ietf@jpshallow.com, jon@jpshallow.com, christian@amsuess.com, draft-ietf-core-new-block@ietf.org Cc: dots@ietf.org, core@ietf.org References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <065301d6e805$286163c0$79242b40$@jpshallow.com> <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com> 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: <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se> Date: Mon, 11 Jan 2021 20:23:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hxzk1jEBL79PhTWI869EybVhEy2uxce8U" X-Originating-IP: [185.236.42.23] X-ClientProxiedBy: HE1PR0402CA0016.eurprd04.prod.outlook.com (2603:10a6:3:d0::26) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.2.3] (185.236.42.23) by HE1PR0402CA0016.eurprd04.prod.outlook.com (2603:10a6:3:d0::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6 via Frontend Transport; Mon, 11 Jan 2021 19:23:14 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cce4698b-0904-4e90-f51e-08d8b6665845 X-MS-TrafficTypeDiagnostic: DBBP189MB1308: 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: 7pJrLyWeM87AYO4FOQKjq7UKQ1Ir034nKrQciy5POAOXvBggxz0RPd7K5CII1PL3Y9ZLAB8t51njd6GCCWvn2XFMJeYn+Ee9IVyOzj1oo6zM1QNZ+Rram0cSUp9b5h+GNnoCyI+ImH3i+RKYLh0ma8Br4uK3V7+vJ+UiDQhz7CEqGOEH+lZVGaVeJvYWj0777gSNJiPYk4UZ9fX3jzTAUFP88nInMUS25J5FpD1czGBqPG6hnEORm4jiAAUK+HkupIrhYuPC81mNt9d83Z9nMQOXMRv9mLu1EDC0uIcnYjmvpGIoXvEqfQJWrKpbEM3phTDRLwFBKQRD7H97HOUnxNXLgeE8EAARZciDWc8XboLUI5F7HLVVudEXs61Ek0UxWp8rqWMVK7ZZ1eY4gNSN34hfCGy/WpZD9V1Q0/i+swuP8Um3VJnBNEXRfCbdptzGVmtQN1iXf3LlOWm02IAM05ypGYZWqzeMGaHCC9nouL1CQRbhz1ofjAcxCFhBYDMcwmkFM0OPd6nlGPEVmrS1yQaJYSb9mI0A4muIwE9CyAp8GrB1abHeCmq9zzwaqLtD 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)(376002)(366004)(396003)(39840400004)(136003)(4326008)(66556008)(186003)(66476007)(16526019)(36756003)(8676002)(33964004)(66946007)(5660300002)(44832011)(26005)(956004)(83380400001)(2906002)(235185007)(316002)(2616005)(6666004)(6486002)(31686004)(52116002)(16576012)(31696002)(45080400002)(53546011)(86362001)(8936002)(966005)(21480400003)(66574015)(478600001)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?RC9KQmltWVpqVFY3dnd1VkV3WGRpemFZRlJXTnYydzdCZUdFYWJuc0hDU29B?= =?utf-8?B?RUZSM3BRQWk4a29HQWxXT3VXNmRLSFVFUFJVNnVvaEx2bmxPa05QY2ZtcTNq?= =?utf-8?B?dXI3OHFrZGlTeCttSWJHcWx1KzhHTXJ0aHgvK0l5UUcvWGdQaEU1dFBndEdO?= =?utf-8?B?UHRQd0s5YUFHZkdGclFLTjVVTGpib3RBditFcFpySklXRWdEaGVRSFJmWjZs?= =?utf-8?B?bzBHaGRHYjRMbVBmaExHdGluMkw2TEg3VEl6ZWMrRkZPZTZkQ3pRcEYxOEdK?= =?utf-8?B?YkRSa1BMZUpPeVpvSmZBbEhiS0NaWFZ0Q2dJOXpGYXpVSG95c05YaVZGaUV5?= =?utf-8?B?NVNlbXZseWZ1bWJDdUxVRVdFRDdsZFVWSmdobVZ6RlBITUx0dkFmaldXZDA5?= =?utf-8?B?NzF5TjUzZ0c0YUpFdDdiREVWazBKUCt0d2VrUkc5YzhKTm1aREFyd2NSVk9r?= =?utf-8?B?NjNKUWJSUWUvRWxnbTBVS0VQNFZHNzVtYVhuWHFjMXlLTjZNVlJsUUkxSVQ2?= =?utf-8?B?Tk5MMXZsTnc0QnZJcUhLZ29wY1YzQmErZzJsUXVVM1YzMmtwV2NZbVE1aExi?= =?utf-8?B?MHROTGpWNCtLNzFOSkwxUWdTeEcyemM5cVpGeTB1SzQrMW1aZzVpOGJiSEhs?= =?utf-8?B?ZkJKbzFSdTdvNXF6dHcwQ2VQVXNneW9mUzk0N2E0bDg4cUlzNkxNRW96ZStY?= =?utf-8?B?YkhNWWZYZ0VGWFRTbVdCUTVyRS9UWWQxODMvcUF6WStHaU9jWG5wUWZ0cmdR?= =?utf-8?B?M0lzVjVvQXJxTXQydEFRaVk5SmloWWp4THcxOExobk8yTml5dzdaRzB2QWYr?= =?utf-8?B?Tnh2akdpM3RkTGc2ckRQdTRSTjNJMjhhTTlpaGVHbkhCVkFERkFVd3NZSm9I?= =?utf-8?B?V3VZbGk5d0c5NGR4VmRrWmpVaU1xa2twaUdBTWFNVnRBNHJ1Uk9wOUdzQU13?= =?utf-8?B?VkVlUDlrYTg0V1RyQWZkU3NrTzU0anZla0doQzM5SFlDSklQSnlnTjNwcFB0?= =?utf-8?B?WUU2aDcxK0JoY0NhY295MjNuVEhvL0ZubjZlT2lBQlpFQkd3UEgvK0tpUlUw?= =?utf-8?B?RDlPZUxCN3YrWWdXTHluTDNLbWN0UUtXWGF1SEhLNmxzV205czFZc1lQT0J1?= =?utf-8?B?eHRUY2UwalJxOFR2OENxK2x6RnRIODRJbGh0REhCVWI4R0tybXViaEJ6TTZN?= =?utf-8?B?MmVsY2NaM0syYndVSE4yekhrSVZFaUZGZ2ZpSUhIQjBNYytrWlZ5K0Q2WUc5?= =?utf-8?B?VzJvdkZkekNJU2Jvc01xNk9WRmNPdkVOdVJGa0NYTENUOEs4dURBVDM0dGZF?= =?utf-8?Q?tnoNbnxvYsC34NHQu73+h8Xxw75xsKR7ID?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2021 19:23:15.5530 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: cce4698b-0904-4e90-f51e-08d8b6665845 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Y8P9kyK2cQQ9CuSGg4sDmnpa5DyjPXBmBJozpJIlvNC+eurj1XULDXgH2p4bEw3Wc1+NwoRiSJujQdL1sxP6Mw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBP189MB1308 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 11 Jan 2021 19:23:24 -0000 --hxzk1jEBL79PhTWI869EybVhEy2uxce8U Content-Type: multipart/mixed; boundary="OLwVIjACIILRUNsZ1hXisG5HFD58OKExz" --OLwVIjACIILRUNsZ1hXisG5HFD58OKExz Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jon, Thanks for the fast reaction. Please, see inline. Best, /Marco On 2021-01-11 17:39, supjps-ietf@jpshallow.com wrote: > Hi Marco, > > It is good that you are thinking this properly through. FETCH was adde= d later into this draft and the consequences were not properly thought th= rough. > > The new updates have been pushed to https://eur02.safelinks.protection.= outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-block&dat= a=3D04%7C01%7Cmarco.tiloca%40ri.se%7C4c6021fd365344ae633908d8b64f6af1%7C5= a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459799554192170%7CUnknown%7C= TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C1000&sdata=3DP5eiQyl8meRhZX9t6gtNqwc29ryqLRGnOUwmFQxAydo%3D&a= mp;reserved=3D0 and the differences with the draft can be found at https:= //eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.or= g%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new-block%26url2%3Dhttps%3A%2F%2Fraw= =2Egithubusercontent.com%2Fcore-wg%2Fnew-block%2Fmaster%2Fdraft-ietf-core= -new-block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C4c6021fd365344= ae633908d8b64f6af1%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459799= 554197148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ= BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DIYKVrC1a56Cva5mR4xoM0VM5y6= dhjtQ7M6L5PwlCqzA%3D&reserved=3D0 > > The PR for the responses below can be found at https://eur02.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-bl= ock%2Fpull%2F13&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C4c6021fd36534= 4ae633908d8b64f6af1%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63745979= 9554197148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC= JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3Db9hq1V5X136oGB65e9Ni12V0w= eXoNa%2FY1DT8QtzFRqQ%3D&reserved=3D0=20 > > Otherwise, see inline. > > Regards > > Jon > >> -----Original Message----- >> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >> Sent: 11 January 2021 11:39 >> To:supjps-ietf@jpshallow.com; christian@amsuess.com; draft-ietf-core-n= ew- >> block@ietf.org >> Cc: dots@ietf.org; core@ietf.org >> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >> >> Hi Jon, >> >> Thanks, the updates look good. > [Jon] Thanks >> As to the response codes in Section 3.3 "Using the Q-Block1 Option", >> wouldn't it make sense to mention also 2.05 (Content) ? Think of a FET= CH >> request with a big body, which is actually mentioned at the beginning = of >> Section 3.3 and in Section 3.1 (though missing the 2.05 response code >> beside it). > [Jon] Thanks - added. Also added in 2.02 and 2.05 as being expected re= sponse codes in 3.3. =3D=3D>MT Looks good. <=3D=3D > > [Jon] For the 2.02, I struggle with why anyone would want to use a POS= T with a large payload to cause the resource to get deleted (instead of u= sing DELETE) , but RFC7252 allows this to happen. =3D=3D>MT If it's really about the client just asking to delete a resource, then a DELETE is more efficient. But, the client might just be asking the server to process its POST payload, and it's the server that eventually takes the decision to delete the resource, as a possible side-effect following the request processing. I think that's what the "if" wanted to suggest in RFC 7252, Section 5.8.2: "If the POST succeeds and results in the target resource being deleted, the response SHOULD have a 2.02 (Deleted) Response Code." Alternatively, the client may actually want to delete the resource as somehow indicated in the payload, only following the processing of the rest of the payload. This would not be possible with a DELETE (that has no payload) and if supported by the application it is more efficient than sending first a POST and then a DELETE. <=3D=3D > > OLD > Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH,= > PATCH, and iPATCH requests and their responses (2.01 and 2.04). > NEW > Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH, PA= TCH, and iPATCH requests and their responses (2.01, 2.02, 2.04, and 2.05)= =2E =3D=3D>MT Looks good. <=3D=3D > [Jon] And added into 3.3 (2.05 is done further into this discussion) > > NEW > 2.02 (Deleted) > > This Response Code indicates successful receipt of the entire body and = the resource was deleted when using POST (See Section 5.8.2 [RFC7252]). T= he token used SHOULD be from the last received payload. The client should= then release all of the tokens used for this body. =3D=3D>MT Looks good. <=3D=3D > >> Also, more in general, think of an observe registration, for which the= >> server eventually sends back a first notification (possibly split into= >> multiple payloads) with Q-Block2, with a certain Token value. > [Jon] OK >> If the observation request used FETCH and was fragmented into several >> payloads with Q-Block1, each of which with a different Token, it's sti= ll >> true that the notifications can all have any of those Token values and= >> should have the one of the last received request payload. > Jon[OK] >> However, later on the client has to retain that Token value as the one= >> associated to the observation, to match future notifications to come. = In >> this case, there is a deviation from the claim used for other response= >> codes, i.e. "The client should then release all of the tokens used for= >> this body." This should concern only 2.01 notifications (hence includi= ng >> the Observe option) in response to observation requests with FETCH, so= >> it can be limited to the context of this section about Q-Block1. > [Jon] I was not aware that FETCH could return 2.01 or 2.04. GET does n= ot return these codes and it is only GET and FETCH that can Observe. =20 =3D=3D>MT Oops, I actually meant 2.05 in the paragraph above. Sorry for the confusi= on. <=3D=3D > However, it is true what you say for 2.05, so I have added that the tra= cked Observe token must be the (if Q-Block1) the one used for Q-Block1 th= at has the M bit unset. I have added in some FETCH examples into the dra= ft. > > NEW > 2.05 (Content) > > This Response Code indicates successful receipt of the entire FETCH req= uest body (See Section 2 [RFC8132]) and the appropriate representation of= the resource has been returned. The token used in the response MUST be t= he one in the FETCH request that has the Q-Block1 with the M bit unset. I= f the FETCH request includes the Observe Option, then the server MUST use= the same token for returning any Observe triggered responses. The client= should then release all of the tokens used for this body unless a resour= ce is being observed. =3D=3D>MT Looks good. As to the two new examples in Figures 11 and 12, please add the Observe option with value 0 to the requests from the client, i.e. O:0, just like you do in Figures 7 and 8. Best, /Marco <=3D=3D > ~jon >> Best, >> /Marco >> > > --=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 --OLwVIjACIILRUNsZ1hXisG5HFD58OKExz-- --hxzk1jEBL79PhTWI869EybVhEy2uxce8U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/8pZsACgkQ7iZktA5Y 2kNyoQf9EAd17qSgsyQn5RtP94nJn360gJRO3CQCvLWDxAG7pKtozJIjQWte+M+5 s9VDr+wX1SjvgRih95Yw/t1mtKeE9zHzyPOSzl48NY/UZN+jt3JoVeUiK7PMt2OR QhRmdxwSJ9S90VzzuGxwnUyXgig0JOKtWLHaVbaHEZrEVZe3ng6iAsXOUvh6f1OB p6tidf6MJ0sypRTY6zMQuFha+bJsM1TfRjsurRgYjy8sso/heKWZ1Umcda+FPRZ5 AqvF6SgQcVrqHIxENxEIv90FGNzSftrZtRQOVodQEUMOqeN9NvEqzGTkUWmM+hMx B2Ao9kG9zjulwMItOs2hx3K9wBWORQ== =ap2p -----END PGP SIGNATURE----- --hxzk1jEBL79PhTWI869EybVhEy2uxce8U-- From nobody Mon Jan 11 14:28:33 2021 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 9EEDF3A137B; Mon, 11 Jan 2021 14:28:24 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161040410447.32419.14700059500642797388@ietfa.amsl.com> Date: Mon, 11 Jan 2021 14:28:24 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-yang-library-03.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, 11 Jan 2021 22:28:31 -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 : Constrained YANG Module Library Authors : Michel Veillette Ivaylo Petrov Filename : draft-ietf-core-yang-library-03.txt Pages : 17 Date : 2021-01-11 Abstract: This document describes a constrained version of the YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a constrained network management server (e.g., a CORECONF server). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-library/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-yang-library-03 https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-library-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-yang-library-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 11 23:21:49 2021 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 4829A3A118E; Mon, 11 Jan 2021 23:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 XBd6s8-k3_Sk; Mon, 11 Jan 2021 23:21:46 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C415E3A0EF0; Mon, 11 Jan 2021 23:21:45 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 4DFMT32M6Sz7tHK; Tue, 12 Jan 2021 08:21:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610436103; bh=dCJGAGcA9stvRc1OmBmMzVWkvwpgGHeac9+psHA00Mo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=YpY0pq8InpV+dJFUt6t01395z9c5N4ZeO6b8zGvRos2a3bbgz1IwIzjT5xT1nBOL8 yHJQ/tR2g710afkYdfwAIk7OYqeEdH3FVHtoLOVNsAvjxHopsnGP/UpQB/MKusRQS7 YkbhjskeZdmej+O5AOTl+umguEQ7D6u2DLvX/RybGpaVJ5vjByncBbSMm42+jeI2WF /c1EqAgyH+BYEuo0vx8xxaI5aRQs3O9eUgNPUHNK0VwK53fRpdsH51m3i8Fp8jQq/t xSGlBXEks0QAcyvu5qW+/e9TiMB0Ngy076+PXhBZNYuyIyETMFCUj+FJTOjKYiYCMN zEF4KXC0LaXWQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4DFMT30kLjz2xCZ; Tue, 12 Jan 2021 08:21:43 +0100 (CET) From: To: Marco Tiloca , "supjps-ietf@jpshallow.com" , "jon@jpshallow.com" , "christian@amsuess.com" , "draft-ietf-core-new-block@ietf.org" CC: "dots@ietf.org" , "core@ietf.org" Thread-Topic: [Dots] [core] WG Last Call on draft-ietf-core-new-block Thread-Index: AQHW6E9Bzk5nyR9aqEaF1vgDuALPQKojhhSA Date: Tue, 12 Jan 2021 07:21:42 +0000 Message-ID: <25360_1610436103_5FFD4E07_25360_250_11_787AE7BB302AE849A7480A190F8B9330315B7B02@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <065301d6e805$286163c0$79242b40$@jpshallow.com> <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com> <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se> In-Reply-To: <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] [Dots] WG Last Call on draft-ietf-core-new-block 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, 12 Jan 2021 07:21:47 -0000 SGkgTWFyY28sIGFsbCwgDQoNCldpdGggcmVnYXJkcyB0byAyLjAyLCBSRkM3OTU5IHNheXMgdGhl IGZvbGxvd2luZzogDQoNCiAgIEhlbmNlLCBmb3IgdGhlIG1ldGhvZHMgZGVmaW5lZCBpbiBbUkZD NzI1Ml0sIEJsb2NrMSBpcyB1c2VmdWwgd2l0aA0KICAgdGhlIHBheWxvYWQtYmVhcmluZyBQT1NU IGFuZCBQVVQgcmVxdWVzdHMgYW5kIHRoZWlyIHJlc3BvbnNlcy4NCiAgIEJsb2NrMiBpcyB1c2Vm dWwgd2l0aCBHRVQsIFBPU1QsIGFuZCBQVVQgcmVxdWVzdHMgYW5kIHRoZWlyIHBheWxvYWQtDQog ICBeXl5eXl4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIF5eXl5eXl5eDQogICBiZWFyaW5nIHJlc3BvbnNlcyAoMi4wMSwgMi4wMiwgMi4wNCwgYW5k IDIuMDUgLS0gc2VlIFNlY3Rpb24gNS41IG9mDQogICBeXl5eXl5eXiAgICAgICAgICAgICAgICAg Xl5eXg0KICAgW1JGQzcyNTJdKS4NCg0KV2hpY2ggd2UgdGhpbmsgaXMgYnJva2VuLiANCg0KV2Ug ZG9uJ3QgZWNobyB0aGF0IHBhcnQgaW4gdGhlIG5ldy1ibG9jay4gDQoNClNob3VsZCB3ZSBmaWxs IGFuIGVycmF0YSBhZ2FpbnN0IHRoaXM/DQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYu b3JnXSBEZSBsYSBwYXJ0IGRlIE1hcmNvIFRpbG9jYQ0KPiBFbnZvecOpwqA6IGx1bmRpIDExIGph bnZpZXIgMjAyMSAyMDoyMw0KPiDDgMKgOiBzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tOyBqb25A anBzaGFsbG93LmNvbTsNCj4gY2hyaXN0aWFuQGFtc3Vlc3MuY29tOyBkcmFmdC1pZXRmLWNvcmUt bmV3LWJsb2NrQGlldGYub3JnDQo+IENjwqA6IGRvdHNAaWV0Zi5vcmc7IGNvcmVAaWV0Zi5vcmcN Cj4gT2JqZXTCoDogUmU6IFtEb3RzXSBbY29yZV0gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYt Y29yZS1uZXctYmxvY2sNCj4gDQo+IEhpIEpvbiwNCj4gDQo+IFRoYW5rcyBmb3IgdGhlIGZhc3Qg cmVhY3Rpb24uIFBsZWFzZSwgc2VlIGlubGluZS4NCj4gDQo+IEJlc3QsDQo+IC9NYXJjbw0KPiAN Cj4gT24gMjAyMS0wMS0xMSAxNzozOSwgc3VwanBzLWlldGZAanBzaGFsbG93LmNvbSB3cm90ZToN Cj4gPiBIaSBNYXJjbywNCj4gPg0KPiA+PiByZXNwb25zZSBjb2RlIGJlc2lkZSBpdCkuDQo+ID4g W0pvbl0gVGhhbmtzIC0gYWRkZWQuICBBbHNvIGFkZGVkIGluIDIuMDIgYW5kIDIuMDUgYXMgYmVp bmcNCj4gZXhwZWN0ZWQgcmVzcG9uc2UgY29kZXMgaW4gMy4zLg0KPiANCj4gPT0+TVQNCj4gTG9v a3MgZ29vZC4NCj4gPD09DQo+IA0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQs IHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Tue Jan 12 01:09:57 2021 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 D9E393A0D45; Tue, 12 Jan 2021 01:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 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.262, 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 zzscaFowUzMK; Tue, 12 Jan 2021 01:09:52 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2042.outbound.protection.outlook.com [40.107.21.42]) (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 D44C53A0D3D; Tue, 12 Jan 2021 01:09:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y2Y403bADcJShA5TNUppmXYcr7rYFKWTS73W2oLhbd+/4Wl7e2tHZkgW9cmasR1pgCNjUidcNxJSUrcuYLK23K7ab+XHR3dvkCHIvYwsYStabcO8Cbx/wW5ROxrqbe9QBCw0dLzS1S7NmjaBBiE/h9T+N4BAlyETg07qljgjlFbc6P/yyzQEa2QHY6cbndCvfY18bDDwNaKBCM7pCIHoVH7DcxCaEBiY9J6i5m9M9ByYmCDfmpfwwvIzuQYMneXjo/CZe1YlMmUl+7JVVGLURFdTxsi4dylQS+xSJV01NwNo6d4cGWFZnkQjRGzaKSG0zc1VcQ5GwSN7iIYt/6pMuw== 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=mccrExbGWLTvHPG0rVwJDuGexcvejtlhSsjRpq7b8yc=; b=KCs4t2lrcO0e8h5rlF46FCBXYBm2hG630xIoGWjDFYO8Vyr3aJQZbZPQTy0ZNcjm3jIB8CE7yqhv1i7EpqZ8nTGQSthbYlr/ohN4XZ1mP0VlJW328db2Y+Cdifa0ofSjvlrY1lYIj/P9xKR3gxcu2Pth6Ahdmk4M3bidKbi/MbEnVhosK3hzXw5SRdWj6QV851WZcqpAOAztMNTkU9qRKFYEDDbfSScx3mvJFYpXsMf4oqCPRybQqVekeN1Gv04obilWAGBuJz97p9fJ9QjOxV1vIOBgHgM0n3KFBY87Td9iqc1vflMy/Qe+vrQSX9Qih8rBxyd6+np2VsEzr8j7yA== 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=mccrExbGWLTvHPG0rVwJDuGexcvejtlhSsjRpq7b8yc=; b=DOQtSDpneCxjUS1MTS/3dH5ymjiJgBA3HWnDj18vooue76Dx3zjOqljTRCNdlGsP394O6PXapnOlA6kQJxedoEhyC5jSJSZRXJGkw43lJFN0jbl+svB6tqIpSIBxJIqZHx/0aFSzaV0aP/Gr0Yyx+I/j5NgIqbIG11AoiOGKmVs= 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 DB6P189MB0469.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:3d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Tue, 12 Jan 2021 09:09:48 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3742.012; Tue, 12 Jan 2021 09:09:48 +0000 To: mohamed.boucadair@orange.com, "supjps-ietf@jpshallow.com" , "jon@jpshallow.com" , "christian@amsuess.com" , "draft-ietf-core-new-block@ietf.org" Cc: "dots@ietf.org" , "core@ietf.org" References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <065301d6e805$286163c0$79242b40$@jpshallow.com> <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com> <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se> <25360_1610436103_5FFD4E07_25360_250_11_787AE7BB302AE849A7480A190F8B9330315B7B02@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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: Tue, 12 Jan 2021 10:09:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <25360_1610436103_5FFD4E07_25360_250_11_787AE7BB302AE849A7480A190F8B9330315B7B02@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YvHFkUlJxWEgkH7Gfs1fRldDwxpxvQobk" X-Originating-IP: [45.12.220.164] X-ClientProxiedBy: HE1PR1001CA0024.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::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.5] (45.12.220.164) by HE1PR1001CA0024.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.9 via Frontend Transport; Tue, 12 Jan 2021 09:09:47 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 271690d5-9948-45fd-bff1-08d8b6d9cfa4 X-MS-TrafficTypeDiagnostic: DB6P189MB0469: 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: wtMTKq6N43SAaVb6ayk/XXgdhHsee0SFxtltBNYeCHlrALflbnsC5HviyVAoNyTPulB5VIR9vmjIWeZMh8tFLzEa6KNwIQfgjDVKVz2h9yZeN41f+D712GyM1oCqzKRzVSfHSMKTqF5c0TA8LQxHQOrdAbDgBiD8kBXPMBlHRh/AepHcdign8kuBiVCcBIkSagxZT/6tY2wZxV3Tb7HP4KnvngWpDKbuPpLK21MYrux/otGmvCgN/9ciXaOuonEjnJCwyJlN9tE03QdeG3fEnYQ7cM4K1u5iRNU5UM8PPuPnHga7YO+g74YAmX6bHS6nHLdWEVicvKK/vJ7Vmmp/fWXd9i8Fs0OGCdJjxUDd/66z6AL/8gEl8lxAStoWUgKuUsZ8TaAHwptPLmsJ4Xi80ym3v1igy1OUPYWpDo0QESxLaoRmllAAqJc/TfZKljbrCXD0ylLqo15TOanKCusg4Icxzvviiu3qBv7YN80PIGpWLovUJmQo8iozDl8XAQ1Hhh3C4XEPH4MM3K7qf9GIBAsHxhcBTJ8tJqH7g8dprtUFIe4DsbYTvoBobPKcIiAd 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)(366004)(39850400004)(136003)(396003)(376002)(31686004)(33964004)(2906002)(16576012)(31696002)(53546011)(52116002)(4326008)(44832011)(6666004)(66574015)(316002)(45954011)(110136005)(26005)(16526019)(86362001)(186003)(8936002)(66946007)(66476007)(8676002)(6486002)(83380400001)(21480400003)(36756003)(956004)(66556008)(235185007)(5660300002)(966005)(54906003)(2616005)(478600001)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?OHFzK1FYazFXR2VFZkVtdjZqdDF4ajNkSE03U2c1Zno1U1ZKekpaOEZUQmVW?= =?utf-8?B?Qy81TjJnR05TWXhrdFNWdTN4RWw1aHcrQzFNSk9LUFAxYTJrY0JrSHA1b1FW?= =?utf-8?B?dUpkTTdKVVBhMXRwL2prMG5WOERyMjJXVzUxZ2g2MlFVU2kyaWpBNmdvSTlo?= =?utf-8?B?c3J1L2t6dDVGaVNPNWdHaWdRTlVTSUtZK3FYR2FtSHoxTk9FdUFuR3FNeGtF?= =?utf-8?B?bXBycVNEZ202K2ZOM2FEZHRzSlNhOEorSmlOVVBoSVkwSVBqR1U0WE5DR1Fn?= =?utf-8?B?QVRneXVRYytwT2h6eFZUTG9qNmdDTFVidEc2cjNUSGtPUnQvemk3L3VyNHV4?= =?utf-8?B?OWRobGVxQ3p2U0lkblowRWJXZExFWEcyOVhGdVNlcTJqYWtuVFpWUmJWL2Zn?= =?utf-8?B?RkpOM0lXSGtxSTQ4VlhPUXVHU2ZpV0xZZ0dHM24yUHl3cnRIMVhiNVFkcjRs?= =?utf-8?B?MmpScTNKdm5uUzJHTDU3UXNWdjZFb3hscytidEhobldPalBIK3NadVV3Y0FG?= =?utf-8?B?WW4yc21IS0tEdHVJZGEyRVFvemtCbVFXcGNqbFVGSks0OUtoT1l5aldVZUYz?= =?utf-8?B?Sno1bGcwbWhFS0x2cFd3UzcxYkYwczZVNnFvRkxFTElNZ1EwNHA0OWVRQ2FQ?= =?utf-8?B?a2VNQnJiakpwNUNSU20wVzdPQ1VrZ3pyWCtkTGpCL1hvK1Y3QXBDd0dLV1Jj?= =?utf-8?B?YXptZEw5d1ZSd2dYNmZFSzZyRHFreVNUTkQxZGQ1SFhXWW13TVVSVVB4ek5Z?= =?utf-8?B?UUdWbHhFcjdneEQvdTB6dG1wem9hSzErZmk3bUFTRnFLelVuT3NrT2lRcTJo?= =?utf-8?B?YWkwRDlhUWU1RExtVHdKdGxoRVVtWTFzL0pqNEhmdGJXNXR2WDNobWE3ZFFR?= =?utf-8?B?bTNIb09JUnE5dHdNK3Y5NWRwRmlmQlMvWlBJVHJyd1hPSEkybXA5SnpOamg0?= =?utf-8?B?Nnpqb244Z2pnQXpLS1R0VTIxOERYRVFidWhwY1MzLzRRbGUwUGthWk1WL1pD?= =?utf-8?B?ckF2b3prdUdkZW0xRHBodTBnaUx3VHV6YTZYU0QxVEp2bStpckRPZ3FldklN?= =?utf-8?B?YTI3R0l1RXV5anRuWk9aVXJLd3FRNmlVOW1DSVg4d204eVA2cGhlTWFLUTFV?= =?utf-8?B?L0p5T1JzbFRHeDYxaUlZbnNFVGxPVXg1bEQrVmMzWEI3Yzh4TVlneGpPS1dk?= =?utf-8?B?QThnUm8xNDJabCtPQk9DRExWdkdidnpjK2Q5V2tNTFEwTVQvVkhxdVhkb3lk?= =?utf-8?B?YWFrSmRWTm96Qm1VN2hYdHVLTlN6MzltQk02bFlOYjdteHlqck1YVEhuTEdM?= =?utf-8?Q?uqswHTl5LeT2ApaaPj58BWCuUe19PPROpP?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2021 09:09:48.0057 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: 271690d5-9948-45fd-bff1-08d8b6d9cfa4 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: mPypXRY0vtVG4ypUV5Ur9b2QvUNxBtEBb15etZb4Y5rjlyDmfFmKERlGeir8HQhdsdrSpMe1Jp1tZkTkvPtmlQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0469 Archived-At: Subject: Re: [core] [Dots] WG Last Call on draft-ietf-core-new-block 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, 12 Jan 2021 09:09:56 -0000 --YvHFkUlJxWEgkH7Gfs1fRldDwxpxvQobk Content-Type: multipart/mixed; boundary="LCvih2BaWdcJaGoxpFKHvBJTEuGpEdTSq" --LCvih2BaWdcJaGoxpFKHvBJTEuGpEdTSq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Med, Could you clarify why that part is broken? =46rom RFC 7252, Section 5.9.1.2=C2=A0 "2.02 Deleted" says: =C2=A0=C2=A0 "This Response Code is like HTTP 204 "No Content" but only u= sed in response to requests that cause the resource to cease being available, such as DELETE and, in certain circumstances, POST. The payload returned with the response, if any, is a representation of the action result." So, a 2.02 response can follow a POST request, and it can have a payload, which might be split using Block2. Best, /Marco On 2021-01-12 08:21, mohamed.boucadair@orange.com wrote: > Hi Marco, all,=20 > > With regards to 2.02, RFC7959 says the following:=20 > > Hence, for the methods defined in [RFC7252], Block1 is useful with > the payload-bearing POST and PUT requests and their responses. > Block2 is useful with GET, POST, and PUT requests and their payload-= > ^^^^^^ ^^^^^^^^ > bearing responses (2.01, 2.02, 2.04, and 2.05 -- see Section 5.5 of > ^^^^^^^^ ^^^^ > [RFC7252]). > > Which we think is broken.=20 > > We don't echo that part in the new-block.=20 > > Should we fill an errata against this? > > Cheers, > Med > >> -----Message d'origine----- >> De=C2=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Marco Tilo= ca >> Envoy=C3=A9=C2=A0: lundi 11 janvier 2021 20:23 >> =C3=80=C2=A0: supjps-ietf@jpshallow.com; jon@jpshallow.com; >> christian@amsuess.com; draft-ietf-core-new-block@ietf.org >> Cc=C2=A0: dots@ietf.org; core@ietf.org >> Objet=C2=A0: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-blo= ck >> >> Hi Jon, >> >> Thanks for the fast reaction. Please, see inline. >> >> Best, >> /Marco >> >> On 2021-01-11 17:39, supjps-ietf@jpshallow.com wrote: >>> Hi Marco, >>> >>>> response code beside it). >>> [Jon] Thanks - added. Also added in 2.02 and 2.05 as being >> expected response codes in 3.3. >> >> =3D=3D>MT >> Looks good. >> <=3D=3D >> > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged= information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > Thank you. > --=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 --LCvih2BaWdcJaGoxpFKHvBJTEuGpEdTSq-- --YvHFkUlJxWEgkH7Gfs1fRldDwxpxvQobk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/9Z1MACgkQ7iZktA5Y 2kPGtQf/UKa2lohUgNa3rmkzU4m2ig0Wr/TYszZH4tNj1gFWFmq57xzznLyqpQWy 3t48HtehFYmekaACxkPhbTxfGv/ngcgMAeWk5XmapyQ2l430geNzc22952pcI9hG UOdLC71DvbxBH1VI367Cn+BPIl8JevqgZ9azWGKWAZk6S8xFtI9Feq7GzZAXWpFB hXwdtn9nsGIc13zaoDf6CrclummvJvDhuBLVsYuTAt5z4yzNYYQQXBog2vCBcijd UO9hgzjAKOUrSXQ8LjqpH6gbfqu5LNP1vkuP3xMv5eymUE1pSBFqqgMj4W5RG0WK Hi7Cmk94wnaHTbrmwiqWFtLFJd28dw== =g7LA -----END PGP SIGNATURE----- --YvHFkUlJxWEgkH7Gfs1fRldDwxpxvQobk-- From nobody Tue Jan 12 01:27:13 2021 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 811D83A0E05; Tue, 12 Jan 2021 01:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 SGN_SmDCAxza; Tue, 12 Jan 2021 01:27:09 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525843A0E04; Tue, 12 Jan 2021 01:27:09 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 4DFQFk68DYz2xNs; Tue, 12 Jan 2021 10:27:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610443626; bh=CgOGAj2FBRazfmI011YvZbuA/JVbR0Ape1JyKYxcWss=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=WUTPnjZoIkbHMPMEm29BPqgiZetOp4443OPY8dQH76yV2v8mj0WLt7UBhXHB5ss33 xUCXZAqPKvaxQ9ltOExLwF4ApSLdSHnVEI/e/IOQ6vSrW7KXJYz7sodwcd9Ax/XMSc D2Kk7P3LJeZ48QsM61x6Cu38LGYJ3iLB9lNTev1mdtM5qcYilQQaM9gcie6Z9yj8PP PJ3HGUyUDWnrI94w5jXzGsriPU7DNPvGN6n8T4GbRbjKYS7iXX+h3piF2EYkgWPEaC TU2GCU3defyXOrKU5QdkvgiKEQASPMN0cRhW8R94gOF7qHPiFiJcrYp1uGVCms16Ie uWSmi9TN0N6IQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4DFQFk4SQJz2xCF; Tue, 12 Jan 2021 10:27:06 +0100 (CET) From: To: Marco Tiloca , "supjps-ietf@jpshallow.com" , "jon@jpshallow.com" , "christian@amsuess.com" , "draft-ietf-core-new-block@ietf.org" CC: "dots@ietf.org" , "core@ietf.org" Thread-Topic: [Dots] [core] WG Last Call on draft-ietf-core-new-block Thread-Index: AQHW6MKuBUGUqFPLqk+vRyAaxhyBTKojuDjA Date: Tue, 12 Jan 2021 09:27:05 +0000 Message-ID: <14775_1610443626_5FFD6B6A_14775_483_1_787AE7BB302AE849A7480A190F8B9330315B7C8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <065301d6e805$286163c0$79242b40$@jpshallow.com> <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com> <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se> <25360_1610436103_5FFD4E07_25360_250_11_787AE7BB302AE849A7480A190F8B9330315B7B02@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] [Dots] WG Last Call on draft-ietf-core-new-block 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, 12 Jan 2021 09:27:12 -0000 UmUtLA0KDQpUaGUgY29uY2VybiBpcyB3aGF0IHRvIHB1dCBpbiB0aGF0IHBheWxhb2QgaWYgdGhl IHJlc291cmNlIGRvZXMgbm90IGV4aXN0Og0KDQogICBJZiB0aGUgUE9TVCBzdWNjZWVkcyBhbmQg cmVzdWx0cyBpbiB0aGUgdGFyZ2V0IHJlc291cmNlIGJlaW5nDQogICBkZWxldGVkLCB0aGUgcmVz cG9uc2UgU0hPVUxEIGhhdmUgYSAyLjAyIChEZWxldGVkKSBSZXNwb25zZSBDb2RlLg0KDQpDaGVl cnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogTWFyY28g VGlsb2NhIFttYWlsdG86bWFyY28udGlsb2NhQHJpLnNlXQ0KPiBFbnZvecOpwqA6IG1hcmRpIDEy IGphbnZpZXIgMjAyMSAxMDoxMA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIDxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsNCj4gc3VwanBzLWlldGZAanBzaGFsbG93LmNv bTsgam9uQGpwc2hhbGxvdy5jb207IGNocmlzdGlhbkBhbXN1ZXNzLmNvbTsNCj4gZHJhZnQtaWV0 Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZw0KPiBDY8KgOiBkb3RzQGlldGYub3JnOyBjb3JlQGll dGYub3JnDQo+IE9iamV0wqA6IFJlOiBbRG90c10gW2NvcmVdIFdHIExhc3QgQ2FsbCBvbiBkcmFm dC1pZXRmLWNvcmUtbmV3LWJsb2NrDQo+IA0KPiBIaSBNZWQsDQo+IA0KPiBDb3VsZCB5b3UgY2xh cmlmeSB3aHkgdGhhdCBwYXJ0IGlzIGJyb2tlbj8NCj4gDQo+IEZyb20gUkZDIDcyNTIsIFNlY3Rp b24gNS45LjEuMsKgICIyLjAyIERlbGV0ZWQiIHNheXM6DQo+IA0KPiDCoMKgICJUaGlzIFJlc3Bv bnNlIENvZGUgaXMgbGlrZSBIVFRQIDIwNCAiTm8gQ29udGVudCIgYnV0IG9ubHkgdXNlZA0KPiBp biByZXNwb25zZSB0byByZXF1ZXN0cyB0aGF0IGNhdXNlIHRoZSByZXNvdXJjZSB0byBjZWFzZSBi ZWluZw0KPiBhdmFpbGFibGUsIHN1Y2ggYXMgREVMRVRFIGFuZCwgaW4gY2VydGFpbiBjaXJjdW1z dGFuY2VzLCBQT1NULiBUaGUNCj4gcGF5bG9hZCByZXR1cm5lZCB3aXRoIHRoZSByZXNwb25zZSwg aWYgYW55LCBpcyBhIHJlcHJlc2VudGF0aW9uIG9mDQo+IHRoZSBhY3Rpb24gcmVzdWx0LiINCj4g DQo+IFNvLCBhIDIuMDIgcmVzcG9uc2UgY2FuIGZvbGxvdyBhIFBPU1QgcmVxdWVzdCwgYW5kIGl0 IGNhbiBoYXZlIGENCj4gcGF5bG9hZCwgd2hpY2ggbWlnaHQgYmUgc3BsaXQgdXNpbmcgQmxvY2sy Lg0KPiANCj4gQmVzdCwNCj4gL01hcmNvDQo+IA0KPiBPbiAyMDIxLTAxLTEyIDA4OjIxLCBtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPiA+IEhpIE1hcmNvLCBhbGwsDQo+ID4N Cj4gPiBXaXRoIHJlZ2FyZHMgdG8gMi4wMiwgUkZDNzk1OSBzYXlzIHRoZSBmb2xsb3dpbmc6DQo+ ID4NCj4gPiAgICBIZW5jZSwgZm9yIHRoZSBtZXRob2RzIGRlZmluZWQgaW4gW1JGQzcyNTJdLCBC bG9jazEgaXMgdXNlZnVsDQo+IHdpdGgNCj4gPiAgICB0aGUgcGF5bG9hZC1iZWFyaW5nIFBPU1Qg YW5kIFBVVCByZXF1ZXN0cyBhbmQgdGhlaXIgcmVzcG9uc2VzLg0KPiA+ICAgIEJsb2NrMiBpcyB1 c2VmdWwgd2l0aCBHRVQsIFBPU1QsIGFuZCBQVVQgcmVxdWVzdHMgYW5kIHRoZWlyDQo+IHBheWxv YWQtDQo+ID4gICAgXl5eXl5eDQo+IF5eXl5eXl5eDQo+ID4gICAgYmVhcmluZyByZXNwb25zZXMg KDIuMDEsIDIuMDIsIDIuMDQsIGFuZCAyLjA1IC0tIHNlZSBTZWN0aW9uDQo+IDUuNSBvZg0KPiA+ ICAgIF5eXl5eXl5eICAgICAgICAgICAgICAgICBeXl5eDQo+ID4gICAgW1JGQzcyNTJdKS4NCj4g Pg0KPiA+IFdoaWNoIHdlIHRoaW5rIGlzIGJyb2tlbi4NCj4gPg0KPiA+IFdlIGRvbid0IGVjaG8g dGhhdCBwYXJ0IGluIHRoZSBuZXctYmxvY2suDQo+ID4NCj4gPiBTaG91bGQgd2UgZmlsbCBhbiBl cnJhdGEgYWdhaW5zdCB0aGlzPw0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiBEZcKgOiBEb3RzIFttYWlsdG86ZG90 cy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1hcmNvDQo+IFRpbG9jYQ0KPiA+PiBF bnZvecOpwqA6IGx1bmRpIDExIGphbnZpZXIgMjAyMSAyMDoyMyDDgMKgOiBzdXBqcHMtDQo+IGll dGZAanBzaGFsbG93LmNvbTsNCj4gPj4gam9uQGpwc2hhbGxvdy5jb207IGNocmlzdGlhbkBhbXN1 ZXNzLmNvbTsNCj4gPj4gZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZw0KPiA+PiBD Y8KgOiBkb3RzQGlldGYub3JnOyBjb3JlQGlldGYub3JnDQo+ID4+IE9iamV0wqA6IFJlOiBbRG90 c10gW2NvcmVdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLWNvcmUtbmV3LQ0KPiBibG9jaw0K PiA+Pg0KPiA+PiBIaSBKb24sDQo+ID4+DQo+ID4+IFRoYW5rcyBmb3IgdGhlIGZhc3QgcmVhY3Rp b24uIFBsZWFzZSwgc2VlIGlubGluZS4NCj4gPj4NCj4gPj4gQmVzdCwNCj4gPj4gL01hcmNvDQo+ ID4+DQo+ID4+IE9uIDIwMjEtMDEtMTEgMTc6MzksIHN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20g d3JvdGU6DQo+ID4+PiBIaSBNYXJjbywNCj4gPj4+DQo+ID4+Pj4gcmVzcG9uc2UgY29kZSBiZXNp ZGUgaXQpLg0KPiA+Pj4gW0pvbl0gVGhhbmtzIC0gYWRkZWQuICBBbHNvIGFkZGVkIGluIDIuMDIg YW5kIDIuMDUgYXMgYmVpbmcNCj4gPj4gZXhwZWN0ZWQgcmVzcG9uc2UgY29kZXMgaW4gMy4zLg0K PiA+Pg0KPiA+PiA9PT5NVA0KPiA+PiBMb29rcyBnb29kLg0KPiA+PiA8PT0NCj4gPj4NCj4gPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBfXw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+DQo+ID4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+ID4gY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUNCj4gZGlmZnVz ZXMsDQo+ID4gZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UNCj4gbWVzc2FnZQ0KPiA+IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlDQo+IGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50DQo+IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl DQo+IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4g Pg0KPiA+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvcg0KPiA+IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsgdGhleSBzaG91bGQNCj4gbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+ID4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+IGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID4gQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdA0KPiBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiA+IFRoYW5rIHlvdS4NCj4gPg0K PiANCj4gLS0NCj4gTWFyY28gVGlsb2NhDQo+IFBoLkQuLCBTZW5pb3IgUmVzZWFyY2hlcg0KPiAN Cj4gUklTRSBSZXNlYXJjaCBJbnN0aXR1dGVzIG9mIFN3ZWRlbg0KPiBEaXZpc2lvbiBJQ1QNCj4g SXNhZmpvcmRzZ2F0YW4gMjIgLyBLaXN0YWfDpW5nZW4gMTYNCj4gU0UtMTY0IDQwIEtpc3RhIChT d2VkZW4pDQo+IA0KPiBQaG9uZTogKzQ2ICgwKTcwIDYwIDQ2IDUwMQ0KPiBodHRwczovL3d3dy5y aS5zZQ0KPiANCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Tue Jan 12 06:29:10 2021 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 D5AC83A0AB8; Tue, 12 Jan 2021 06:29:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: barryleiba@computer.org, core-chairs@ietf.org, core@ietf.org, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161046174678.7108.6276766498401505566@ietfa.amsl.com> Date: Tue, 12 Jan 2021 06:29:06 -0800 Archived-At: Subject: [core] core - New Meeting Session Request for IETF 110 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, 12 Jan 2021 14:29:07 -0000 A new meeting session request has just been submitted by Marco Tiloca, a Chair of the core working group. --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Marco Tiloca Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: ace cbor t2trg cose lake artarea Technology Overlap: teep saag secdispatch sacm lwig 6lo roll httpbis lpwan raw Key Participant Conflict: irtfopen rats suit dnssd netconf netmod emu dots anima asdf People who must be present: Barry Leiba Jaime Jimenez Marco Tiloca Resources Requested: Special Requests: Plse also avd any potntlly IoT reltd BOFs&amp;amp;PRGs tht mght cme up. Prefer some time between the two meetings (48 h or more). --------------------------------------------------------- From nobody Tue Jan 12 06:52:43 2021 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 AB6C53A134C; Tue, 12 Jan 2021 06:52:38 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161046315862.25694.11591557362858270437@ietfa.amsl.com> Date: Tue, 12 Jan 2021 06:52:38 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-dynlink-12.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, 12 Jan 2021 14:52:39 -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 : Dynamic Resource Linking for Constrained RESTful Environments Authors : Michael Koster Bilhanan Silverajan Filename : draft-ietf-core-dynlink-12.txt Pages : 25 Date : 2021-01-12 Abstract: This specification defines Link Bindings, which provide dynamic linking of state updates between resources, either on an endpoint or between endpoints, for systems using CoAP (RFC7252). This specification also defines Conditional Notification and Control Attributes that work with Link Bindings or with CoAP Observe (RFC7641). Editor note The git repository for the draft is found at https://github.com/core- wg/dynlink The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-dynlink/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-dynlink-12 https://datatracker.ietf.org/doc/html/draft-ietf-core-dynlink-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dynlink-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 12 07:26:08 2021 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 F19EC3A03EB for ; Tue, 12 Jan 2021 07:26:06 -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 54rh3jkxZhVW for ; Tue, 12 Jan 2021 07:26:03 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 3D60F3A00C9 for ; Tue, 12 Jan 2021 07:26:02 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1kzLYW-0007jN-Nw; Tue, 12 Jan 2021 15:26:00 +0000 From: To: "Marco Tiloca" , , Cc: , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <065301d6e805$286163c0$79242b40$@jpshallow.com> <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com> <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se> In-Reply-To: <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se> Date: Tue, 12 Jan 2021 15:26:10 -0000 Message-ID: <083c01d6e8f7$4137a420$c3a6ec60$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAFUavWxAaeeZ2wB9CJyVQGW5zMSAr51FjUBa6IWcAGdmCj+Al0VD5oCSzuKDKg7hFnQ Content-Language: en-gb Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block 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, 12 Jan 2021 15:26:07 -0000 Hi Marco and all, Need clarity on how to do a (Q-)Block2 request for a specific block when = the request needs (Q-)Block1. Adding in the Observe option into Figures 11 & 12 caused other things to = be updated (text is being updated) - e.g. the Observe option needs to be = set on all of the Q-Block1 payloads making up the body. However, I have run into not being sure what to do when a request needs = Q-Block1 and the response needs Q-Block2 - and then we need to recover a = missing Q-Block2 block. Med and I have been discussing this offline.=20 In the case of Q-Block1/Q-Block2 it is about what is the request needed = to get a missing Q-Block2 block. In the case of Block1/Block2 it is all = about the request needed to get the next Block2 block. For whatever reason, a (Q-)Block2 block needs to be requested. Given = that the request has used (Q-)Block1 to handle the large body, do we = just need to use the request method and matching options (with = appropriate (Q-)Block2 NUM) without the payload, or do we have to use = the payload as well and hence use multiple packets for the complete = request? If the server is caching the response, then a match can just be done on = the cache-key if formed right. If the server does not cache the response, then when using a FETCH, the = FETCH will need to have the body to regenerate the response. The closest I can find to this is in 2.7 rfc7959 which has " In PUT and particularly in POST exchanges, both the request body and the response body may be large enough to require the use of block- wise transfers. First, the Block1 transfer of the request body proceeds as usual. In the exchange of the last slice of this block- wise transfer, the response carries the first slice of the Block2 transfer (NUM is zero). To continue this Block2 transfer, the client continues to send requests similar to the requests in the Block1 phase, but leaves out the Block1 Options and includes a Block2 request option with non-zero NUM." In particular note the occurrence of the second "requests" is plural in = this line. " continues to send requests similar to the requests in the Block1 phase" This implies to me that there are multiple requests needed to make up = the request with a full body to ask for a single block and that is the = way to go - correct? Secondly, For a FETCH to cancel an Observe, again I can find no text giving = clarity (as there are no references to payload), but have to assume that = FETCH needs to be identical (apart from message id and Observe value = which is now 1) including the payload - correct? Regards Jon PS - We have worked out the wording for the 2.02 response. > -----Original Message----- > From: Marco Tiloca [mailto:marco.tiloca@ri.se] > Sent: 11 January 2021 19:23 > To: supjps-ietf@jpshallow.com; christian@amsuess.com; > draft-ietf-core-new-block@ietf.org > Cc: dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hi Jon, >=20 > Thanks for the fast reaction. Please, see inline. >=20 > Best, > /Marco >=20 >=20 > As to the two new examples in Figures 11 and 12, please add the = Observe > option with value 0 to the requests from the client, i.e. O:0, just = like you do > in Figures 7 and 8. >=20 > Best, > /Marco > <=3D=3D >=20 From nobody Tue Jan 12 11:19:21 2021 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 EE4DD3A1068; Tue, 12 Jan 2021 11:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 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, 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 UR2an5Fcq8pa; Tue, 12 Jan 2021 11:19:18 -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 5D39B3A1060; Tue, 12 Jan 2021 11:19:17 -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 10CJJCTl017760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Jan 2021 14:19:16 -0500 Date: Tue, 12 Jan 2021 11:19:11 -0800 From: Benjamin Kaduk To: draft-ietf-core-oscore-groupcomm@ietf.org Cc: core@ietf.org Message-ID: <20210112191911.GT161@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: Subject: [core] Concerns with EC key joint signature and DH usage in draft-ietf-core-oscore-groupcomm 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, 12 Jan 2021 19:19:20 -0000 Hi all, A recent feature request for openssl (https://github.com/openssl/openssl/issues/13630) pointed out that this document rather blithely proposes to reuse signature (e.g., EdDSA and ECDSA) keys for purposes of ECDH key agreement. (This is part of the "pairwise keys" construction in Section 2.3, specifically in 2.3.1.) Use of a given key with multiple algorithms diverges from general cryptographic best practice, and I do see that this draft acknowledges this fact and attempts to justify the choice in the security considerations (Section 10.12) with reference to [Degabriele] (https://eprint.iacr.org/2011/615). However, I do not think that the current discussion (in the -10) is anywhere close to sufficient justification that the proposed behavior is secure. Specifically, the referenced paper primarily focuses on methods used for EMV standards, and in particular limits itself to ECIES (which combines key agreement and message encryption). While OSCORE provides mechanisms conceptually similar to ECIES, the actual mechanics of the cryptography and wire protocol are, to my knowledge, different, and so the referenced paper does not seem to directly apply. This document does not attempt to "bridge the gap" between what it does in practice and the (ECIES-specific) proof, so based on my current understanding, it must still be considered as defying best current practice without formal cryptographic justification. In my opinion, we need to either produce a reference/proof that does apply to OSCORE's usage, or remove this mechanism from the protocol. -Ben From nobody Tue Jan 12 14:21:08 2021 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 C36463A12D1; Tue, 12 Jan 2021 14:21:07 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 Q45HTfKvn5HA; Tue, 12 Jan 2021 14:21:06 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id C55383A12CF; Tue, 12 Jan 2021 14:21:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 27D1666012A; Wed, 13 Jan 2021 00:21:05 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiBfbtkaEAVK; Wed, 13 Jan 2021 00:21:03 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 8BAD36600A2; Wed, 13 Jan 2021 00:21:03 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Wed, 13 Jan 2021 00:21:03 +0200 Cc: Russ Housley , iot-directorate@ietf.org, last-call@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <959CAC2A-A973-4302-842F-5A2955378F99@piuha.net> References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> To: John C Klensin X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 12 Jan 2021 22:21:08 -0000 Hi John, nice to hear from you. Inline: > Sorry I, or someone in the URN registration review process, > didn't catch this, but I think it is a little more complicated > than a nit. When what became RFC 8141 was being developed, > several people made very clear to the WG that there was no > possible way for a URN specification to make an exception to the > syntax rules for URIs, including the rules about > percent-encoding in Sections 2.1 and 2.4 of RFC 3986. =20 Thanks for bringing this point up.=20 I=E2=80=99m not entirely sure that if we dug deeper, what the actual = precedence rules between requirements from different RFCs would be*. Be = that as it may, I=E2=80=99m not sure we need to have that debate. How would people feel about the following text which I think describes = the correct situation with respect to the percent encoding in DEV URNs, = and does not claim to change any rules on 8141: =E2=80=A6 Due to the SenML RFC 8428 Section 4.5.1 rules, it is not desirable to use percent-encoding in DEV URNs, and the subtypes defined in this specification do not really benefit from percent-encoding. However, this specification does not deviate from the general syntax of URNs or their processing and normalization rules as specified in [RFC8141]. This text is in my soon-to-be-submitted version -10, available here: = https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--09.diff.html Jari *) One could for instance also argue that all URN subtype specifications = are narrowing down of the general syntax, although one might equally = well point out that there are some real-life limitations of e.g. = software processing that occurs before handing a URN to a particular = module, which might dictate that some general URN processing rules are = adhered to. Or there=E2=80=99s some other reason that prevents the = particular narrowing down that=E2=80=99s in -09. From nobody Tue Jan 12 14:23:14 2021 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 1C9B43A12E5 for ; Tue, 12 Jan 2021 14:23:13 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 Y-5DFvJ-I-uz for ; Tue, 12 Jan 2021 14:23:11 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50FB3A1323 for ; Tue, 12 Jan 2021 14:22:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 507AF300BD1 for ; Tue, 12 Jan 2021 17:22:35 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VKa-5kkdoh6S for ; Tue, 12 Jan 2021 17:22:32 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 86BD1300512; Tue, 12 Jan 2021 17:22:32 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: <959CAC2A-A973-4302-842F-5A2955378F99@piuha.net> Date: Tue, 12 Jan 2021 17:22:33 -0500 Cc: John C Klensin , "iot-directorate@ietf.org" , last-call@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> <959CAC2A-A973-4302-842F-5A2955378F99@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 12 Jan 2021 22:23:13 -0000 That looks good to me. Russ > On Jan 12, 2021, at 5:21 PM, Jari Arkko wrote: >=20 > Hi John, nice to hear from you. Inline: >=20 >> Sorry I, or someone in the URN registration review process, >> didn't catch this, but I think it is a little more complicated >> than a nit. When what became RFC 8141 was being developed, >> several people made very clear to the WG that there was no >> possible way for a URN specification to make an exception to the >> syntax rules for URIs, including the rules about >> percent-encoding in Sections 2.1 and 2.4 of RFC 3986. =20 >=20 > Thanks for bringing this point up.=20 >=20 > I=E2=80=99m not entirely sure that if we dug deeper, what the actual = precedence rules between requirements from different RFCs would be*. Be = that as it may, I=E2=80=99m not sure we need to have that debate. >=20 > How would people feel about the following text which I think describes = the correct situation with respect to the percent encoding in DEV URNs, = and does not claim to change any rules on 8141: >=20 > =E2=80=A6 Due to the SenML RFC 8428 > Section 4.5.1 rules, it is not desirable to use percent-encoding in > DEV URNs, and the subtypes defined in this specification do not > really benefit from percent-encoding. However, this specification > does not deviate from the general syntax of URNs or their processing > and normalization rules as specified in [RFC8141]. >=20 > This text is in my soon-to-be-submitted version -10, available here: >=20 > = https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--09.diff.html >=20 > Jari >=20 > *) One could for instance also argue that all URN subtype = specifications are narrowing down of the general syntax, although one = might equally well point out that there are some real-life limitations = of e.g. software processing that occurs before handing a URN to a = particular module, which might dictate that some general URN processing = rules are adhered to. Or there=E2=80=99s some other reason that prevents = the particular narrowing down that=E2=80=99s in -09. >=20 >=20 From nobody Tue Jan 12 16:16:27 2021 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 F38EF3A14AA; Tue, 12 Jan 2021 16:16:14 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 9GfaARhh_1CN; Tue, 12 Jan 2021 16:16:13 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC253A14B4; Tue, 12 Jan 2021 16:16:12 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kzTpZ-0009g5-EB; Tue, 12 Jan 2021 19:16:09 -0500 Date: Tue, 12 Jan 2021 19:16:03 -0500 From: John C Klensin To: Jari Arkko cc: Russ Housley , iot-directorate@ietf.org, last-call@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org Message-ID: In-Reply-To: <959CAC2A-A973-4302-842F-5A2955378F99@piuha.net> References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> <959CAC2A-A973-4302-842F-5A2955378F99@piuha.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 13 Jan 2021 00:16:15 -0000 Jari, I think that your proposed text is ok. Some more detailed comments inline below, probably more for information than a suggestion for further changes but others may disagree... --On Wednesday, January 13, 2021 00:21 +0200 Jari Arkko wrote: > Hi John, nice to hear from you. Inline: >=20 >> Sorry I, or someone in the URN registration review process, >> didn't catch this, but I think it is a little more = complicated >> than a nit. When what became RFC 8141 was being developed, >> several people made very clear to the WG that there was no >> possible way for a URN specification to make an exception to >> the syntax rules for URIs, including the rules about >> percent-encoding in Sections 2.1 and 2.4 of RFC 3986. =20 >=20 > Thanks for bringing this point up.=20 >=20 > I'm not entirely sure that if we dug deeper, what the actual > precedence rules between requirements from different RFCs > would be*. Be that as it may, I'm not sure we need to have > that debate. In general, I would agree that precedence rules are often debatable. However, 3986 asserts that URNs are a type of URIs, something the URN WG did not seriously consider trying to change (and, I'm convinced, would not have been allowed to change had it wanted to). And draft-ietf-core-dev-urn asserted that these are, after all, URNs. Now suppose that, instead, the document had been titled "FiddleFrobs for Device Identifiers". Then I think the WG could have had (and probably would have been forced into) an absolutely fascinating discussion as to whether FiddleFrobs where really URIs in disguise and hence should be bound by 3986 and, if so and they were name-type URIs, whether they were URNs or some other name-type creature [1]. Personally, the only thing I've confident about in terms of such a discussion is that I would want to be as far away from it as possible. > How would people feel about the following text which I think > describes the correct situation with respect to the percent > encoding in DEV URNs, and does not claim to change any rules > on 8141: >=20 > =E2=80=A6 Due to the SenML RFC 8428 > Section 4.5.1 rules, it is not desirable to use > percent-encoding in DEV URNs, and the subtypes defined in > this specification do not really benefit from > percent-encoding. However, this specification does not > deviate from the general syntax of URNs or their processing > and normalization rules as specified in [RFC8141]. As I said above, I think it works. However, since the rules that set this discussion off are actually in 3986, I'd be slightly more comfortable, and I think it would serve your readers better in the long run, if you referenced 3986 as well as 8141. I don't think there is any point in going further than that, e.g., by identifying the sections involved. > This text is in my soon-to-be-submitted version -10, available > here: > =20 > https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--09.d > iff.html >=20 > Jari >=20 > *) One could for instance also argue that all URN subtype > specifications are narrowing down of the general syntax, > although one might equally well point out that there are some > real-life limitations of e.g. software processing that occurs > before handing a URN to a particular module, which might > dictate that some general URN processing rules are adhered to. > Or there's some other reason that prevents the particular > narrowing down that's in -09. But that is similar or identical to the arguments the URNBIS WG tried to make vis-a-vis 3986, i.e., that we could take what 3986 allowed and further restrict the syntax and/or provide more specific interpretations of semantics. As I suggested, and Martin D=C3=BCrst affirmed, that didn't get us very far. I = strongly suggest that you take your proposed paragraph above (preferably with the additional reference), run with it, and put this little blip behind you and behind the WG :-) best, john [1] See Section 1.1.3 of RFC 3986. From nobody Tue Jan 12 23:53:37 2021 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 531B23A0D01; Tue, 12 Jan 2021 23:53:36 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 xCcqZNAFFL55; Tue, 12 Jan 2021 23:53:34 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.219.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFCD3A0D00; Tue, 12 Jan 2021 23:53:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3BC076601D1; Wed, 13 Jan 2021 09:53:32 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbaIU5oECWTT; Wed, 13 Jan 2021 09:53:31 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 00CBD6600B8; Wed, 13 Jan 2021 09:53:30 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Wed, 13 Jan 2021 09:53:29 +0200 Cc: Russ Housley , iot-directorate@ietf.org, last-call@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, core@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <68B8D07F-6B14-40F8-8F02-5BF794D4B118@piuha.net> References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> <959CAC2A-A973-4302-842F-5A2955378F99@piuha.net> To: John C Klensin X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 13 Jan 2021 07:53:36 -0000 Thanks, John. I will add the other reference and submit the draft. Jari From nobody Wed Jan 13 01:21:54 2021 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 C7DED3A0BE3; Wed, 13 Jan 2021 01:21:44 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161052970477.29122.9874259954299446280@ietfa.amsl.com> Date: Wed, 13 Jan 2021 01:21:44 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-dev-urn-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: Wed, 13 Jan 2021 09:21:52 -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-10.txt Pages : 21 Date : 2021-01-13 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 passed along in applications that need 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-10 https://datatracker.ietf.org/doc/html/draft-ietf-core-dev-urn-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dev-urn-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 Wed Jan 13 01:39:46 2021 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 BEA563A0ADA; Wed, 13 Jan 2021 01:39:40 -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 xhCTVZJsyiwn; Wed, 13 Jan 2021 01:39:38 -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 5DE453A0AD6; Wed, 13 Jan 2021 01:39:36 -0800 (PST) Received: from [192.168.217.118] (p548dc939.dip0.t-ipconnect.de [84.141.201.57]) (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 4DG2Tf0y5pzyTd; Wed, 13 Jan 2021 10:39:34 +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: <68B8D07F-6B14-40F8-8F02-5BF794D4B118@piuha.net> Date: Wed, 13 Jan 2021 10:39:33 +0100 Cc: John C Klensin , iot-directorate@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, Russ Housley , "core@ietf.org WG (core@ietf.org)" , last-call@ietf.org X-Mao-Original-Outgoing-Id: 632223573.50493-4095438a3c64831573d8976370f15859 Content-Transfer-Encoding: quoted-printable Message-Id: <48D2C104-FA28-41BF-8873-D5DE8AD5BBD2@tzi.org> References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> <959CAC2A-A973-4302-842F-5A2955378F99@piuha.net> <68B8D07F-6B14-40F8-8F02-5BF794D4B118@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 13 Jan 2021 09:39:41 -0000 One nit on -10: I don=E2=80=99t believe RFC 7405 allows whitespace after %s. (The version of bap that I=E2=80=99m using doesn=E2=80=99t support RFC = 7405 yet, so I can=E2=80=99t easily validate this belief.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 13 06:03:09 2021 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 2F3043A1018; Wed, 13 Jan 2021 06:03:08 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 OGSsM-HRjtPx; Wed, 13 Jan 2021 06:03:05 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 6A91F3A1011; Wed, 13 Jan 2021 06:03:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8EAD96601D1; Wed, 13 Jan 2021 16:03:04 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-6zD-hg3LdM; Wed, 13 Jan 2021 16:03:02 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 8C5F56600A2; Wed, 13 Jan 2021 16:03:02 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <48D2C104-FA28-41BF-8873-D5DE8AD5BBD2@tzi.org> Date: Wed, 13 Jan 2021 16:03:01 +0200 Cc: iot-directorate@ietf.org, Russ Housley , last-call@ietf.org, "core@ietf.org WG (core@ietf.org)" , John C Klensin , draft-ietf-core-dev-urn.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <62A1CDC6-23E7-4BD4-BE91-D81EFD073999@piuha.net> References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> <959CAC2A-A973-4302-842F-5A2955378F99@piuha.net> <68B8D07F-6B14-40F8-8F02-5BF794D4B118@piuha.net> <48D2C104-FA28-41BF-8873-D5DE8AD5BBD2@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 13 Jan 2021 14:03:08 -0000 Thanks Carsten, and I think you are right.=20 (I was also suffering from the same issue, so I was only able to verify = the ABNF by removing the RFC 7405 syntax, hence didn=E2=80=99t catch = this. Of course I should have paid more attention when writing it, = though. RFC 7405 is clear that there=E2=80=99s no whitespace.) Jari From nobody Wed Jan 13 07:44:31 2021 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 4C9DE3A1168 for ; Wed, 13 Jan 2021 07:44:29 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGdXhhROneHG for ; Wed, 13 Jan 2021 07:44:27 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E4E3A1165 for ; Wed, 13 Jan 2021 07:44:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CACCB300BD2 for ; Wed, 13 Jan 2021 10:35:09 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ubjdI_HrwlMa for ; Wed, 13 Jan 2021 10:35:07 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 39E40300B66; Wed, 13 Jan 2021 10:35:07 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: <48D2C104-FA28-41BF-8873-D5DE8AD5BBD2@tzi.org> Date: Wed, 13 Jan 2021 10:35:08 -0500 Cc: "iot-directorate@ietf.org" , last-call@ietf.org, "core@ietf.org WG (core@ietf.org)" , draft-ietf-core-dev-urn.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <02E3F1AD-47EA-4CC5-825F-58D75E0DAE13@vigilsec.com> References: <160996930502.21827.5533521556349871834@ietfa.amsl.com> <959CAC2A-A973-4302-842F-5A2955378F99@piuha.net> <68B8D07F-6B14-40F8-8F02-5BF794D4B118@piuha.net> <48D2C104-FA28-41BF-8873-D5DE8AD5BBD2@tzi.org> To: Carsten Bormann , Jari Arkko X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [core] [Last-Call] Iotdir telechat review of draft-ietf-core-dev-urn-09 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, 13 Jan 2021 15:44:29 -0000 https://tools.ietf.org/tools/bap/abnf.cgi It seems to work properly if the space is dropped after the %s. Russ > On Jan 13, 2021, at 4:39 AM, Carsten Bormann wrote: >=20 > One nit on -10: > I don=E2=80=99t believe RFC 7405 allows whitespace after %s. >=20 > (The version of bap that I=E2=80=99m using doesn=E2=80=99t support RFC = 7405 yet, so I can=E2=80=99t easily validate this belief.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Wed Jan 13 10:06:24 2021 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 47A623A1255; Wed, 13 Jan 2021 10:06:19 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161056117925.23400.10291073677288718681@ietfa.amsl.com> Date: Wed, 13 Jan 2021 10:06:19 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-new-block-05.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: Wed, 13 Jan 2021 18:06:19 -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 : Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission Authors : Mohamed Boucadair Jon Shallow Filename : draft-ietf-core-new-block-05.txt Pages : 42 Date : 2021-01-13 Abstract: This document specifies alternative Constrained Application Protocol (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. These options are similar to the CoAP Block1 and Block2 Options, not a replacement for them, but do enable faster transmission rates for large amounts of data with less packet interchanges as well as supporting faster recovery should any of the blocks get lost in transmission. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-new-block-05 https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 13 10:13:48 2021 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 D96C33A125F; Wed, 13 Jan 2021 10:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 5t8ijWi_1JYz; Wed, 13 Jan 2021 10:13:43 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB743A125E; Wed, 13 Jan 2021 10:13:42 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4DGFts0l1Cz101V; Wed, 13 Jan 2021 19:13:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1610561621; bh=SzzxzxwiyeNXRblEFSUltBDxcOdHxRm2yUsMRunlJbw=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=buBQs+8khYXk1hGNBS7EctrvME6i5UEZ1UyRf/Q4bJYSAbZe4NRZDiodQGmp2xzay d90NuHclgm91Sd+ajHg+vVf98pk/AZy+9gFeFzUCGmPi2r+5HMAqsSlHv2voOQMa4p OCPbrLWt6PzpQDDbZBMZ7y41DOsNsERATiYl5IHvVlJ1j0+BRsB0TI0MQuqz/oYCtj qU7upCiaJdxHAh4YTvLgfNFwMMCBJFvj6uc3+PLBMPZEpRh/TXbnEOWsLpby9HjStT In4KghBa7KnkKdtsG5vr/zxjHv2rcou1MNKBoEOGTbML7YDYNvpRlhA72dYDxAfPzt 5ryurb/An+oQw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 4DGFtr72Rdz1xpt; Wed, 13 Jan 2021 19:13:40 +0100 (CET) From: To: "core@ietf.org" CC: "draft-ietf-core-new-block@ietf.org" , "dots@ietf.org" Thread-Topic: I-D Action: draft-ietf-core-new-block-05.txt Thread-Index: AQHW6dbZ1lvpcRxOKUGdJpg2sLRLP6ol2h/g Date: Wed, 13 Jan 2021 18:13:40 +0000 Message-ID: <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> In-Reply-To: <161056117925.23400.10291073677288718681@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.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: Wed, 13 Jan 2021 18:13:46 -0000 Hi all,=20 This version integrates the latest comments from Marco, especially the hand= ling of FETCH. New examples were also added to illustrate the intended beha= vior.=20 If there are still any pending issues, please let us know.=20 Cheers, Jon & Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part > de internet-drafts@ietf.org > Envoy=E9=A0: mercredi 13 janvier 2021 19:06 > =C0=A0: i-d-announce@ietf.org > Cc=A0: core@ietf.org > Objet=A0: I-D Action: draft-ietf-core-new-block-05.txt >=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 : Constrained Application Protocol (CoAP) > Block-Wise Transfer Options for Faster Transmission > Authors : Mohamed Boucadair > Jon Shallow > Filename : draft-ietf-core-new-block-05.txt > Pages : 42 > Date : 2021-01-13 >=20 > Abstract: > This document specifies alternative Constrained Application > Protocol > (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 > Options. >=20 > These options are similar to the CoAP Block1 and Block2 Options, > not > a replacement for them, but do enable faster transmission rates > for > large amounts of data with less packet interchanges as well as > supporting faster recovery should any of the blocks get lost in > transmission. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-core-new-block-05 > https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-new-block-05 >=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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jan 14 11:57:48 2021 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 ABA813A134F; Thu, 14 Jan 2021 11:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.062 X-Spam-Level: X-Spam-Status: No, score=-3.062 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.262, RCVD_IN_DNSWL_LOW=-0.7, 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 7MupuMjtnehZ; Thu, 14 Jan 2021 11:57:43 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60087.outbound.protection.outlook.com [40.107.6.87]) (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 5E5893A14C1; Thu, 14 Jan 2021 11:57:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DKF3Cl/isVlbqa4bVMbwerYfx3hduDINWHuwl0zMf3I68JWXQP4F/nHw/9bfxe5a94gTT9VpcEJ8Dx8ENzrokQg/9/0cVTJMc+yfD14w8U+lndDvLXL+XB029HtZATLPLUel0RETmkJCH9ozzSICZRN6FRwht8AaPE4mfbFGn0qSyQ4tj7PgtEEuun0JfIPVi/v7CdMVBmWZ86ZzyBVaZCJn3rApS8NAdqmC2MoFgbNp9dXlDKFz2Vb8zSEoZlfSjrRXzRIA58hc+zB4TF+b+xr2OBSS69XEi3pYuSBk9LO3wslemahlGOzpdTqef783g68xIDvbdyVdtYLFR9n4mQ== 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=mfEO524lE6lu5AA+CHSm+Y+cbgzmZO7ConU9sKajKE8=; b=R26KUO8wy1seBy307dwnJJMEqX2qlXbQa1smY6lg3yypXRmobzmwVJ6ZJlyYTwYFaUXlsvFnIzPgoiXph3QZxAXjfCcvm4gJkvg393E1lAb9fmBBJaM/9ddCovHFG+uYNalp0OkvjTmIEx0Pq2Bg+B+XHHtG6l/n0fPj2ENyCwQonCbOEyMpQFK6gVokM6jGCQex/BMVleA77MLENvWGmFPsDOtUr/Jy9MTxIUdF2AGHYTQB+6M28for8lMWMyD6cGqRXK5Byxzi/sktyd8+kRSt47VfURe9FlO79dqPHi4JRIDc7yC169bivmGiN3d7mlFt82gvf1iqd1g9nS20Tg== 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=mfEO524lE6lu5AA+CHSm+Y+cbgzmZO7ConU9sKajKE8=; b=MSsT1OROBbNjlfVVsrs+XgAEgHHj8xiwRg6qVNLYcVZULY3J5f+EtKYAc8sX3/28wC3Lk/ZSOUew9x97RaMoluqvzpGcex8F3Y53TT0QeQqic5IZaxgewnaiFvgvr/6phitDTYLiR+43HGxaHCI9rBqU/7JDUO/IKLz+ENTURM8= 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 DB6P189MB0280.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:35::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.9; Thu, 14 Jan 2021 19:57:39 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3763.010; Thu, 14 Jan 2021 19:57:39 +0000 To: mohamed.boucadair@orange.com, "core@ietf.org" Cc: "draft-ietf-core-new-block@ietf.org" , "dots@ietf.org" References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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: <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> Date: Thu, 14 Jan 2021 20:57:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AYugZCTyRlXlJPfGx7lFnEZ6GuGylBScu" X-Originating-IP: [185.236.42.208] X-ClientProxiedBy: HE1PR05CA0274.eurprd05.prod.outlook.com (2603:10a6:3:fc::26) 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.4] (185.236.42.208) by HE1PR05CA0274.eurprd05.prod.outlook.com (2603:10a6:3:fc::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.10 via Frontend Transport; Thu, 14 Jan 2021 19:57:38 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5f793365-31d3-4fce-9d82-08d8b8c6a5a3 X-MS-TrafficTypeDiagnostic: DB6P189MB0280: 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: GACXpp29RGJcjMoipfMTe87CLg2/u2ofBi/Ei9ohjYPnfWG3h/QvPU1Y5l3CX/uZ0p3UhXtCKtzD94RwGJ7IoLTs+DFsZq6+2cpyEn7pdvSHbu+3EOmCdC7jM4NlyCA6M0o4vMxEVkZL48OjfmUeSXMot5mHTyUaIN2za4xkrjl0lpVTALJMEheTpKNqbyn7tqv2uG37sfJqgIBq7JuT4Id9Yzls08vbmSnXJBnLuIbf++ISeUXfULmRiD4V0qXqB1Ii3uGylCl1bqXvug6bKeHvN4uARcD0UAKtywv5NHrwK9k8TQk6fcHK1kj5DfzKISK/AOZ28N45MDPczYqFaQZzyxEAeR9tO9ZJnRcND7EJO4du5B3F+4yWeTwlmiO+AhQv5ylBxt8p7KL/dmLpHf1r5f16Zc2ONWIkVkpguTKPAX0HRYaekAlKw7KcLbwWL//ekhTZnv0DFyUNuOXUch0py4UG4ptofuSQNAUUP0l10Qv5yq3QL2eY4o19d5k7C67SUPDoQHVpN95uvJJ8H0KA94LKg9DUCsXz1bPwNtg= 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)(376002)(366004)(396003)(136003)(39850400004)(2906002)(478600001)(4326008)(54906003)(16576012)(16526019)(5660300002)(66556008)(31696002)(26005)(8676002)(53546011)(8936002)(6486002)(2616005)(36756003)(316002)(86362001)(6916009)(31686004)(186003)(44832011)(52116002)(45080400002)(33964004)(6666004)(21480400003)(66946007)(66574015)(83380400001)(235185007)(66476007)(966005)(956004)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?bXJXZjZTNWtsTDhLS25XUGMzU1kxczUzNGlhUWZCbnh2a1NnbVZWcVplbzRN?= =?utf-8?B?S0xvSlFyVkFIenkrOHYrTmhTOGpqaG94aHZQZW1kZzJaWDZsUmNVWStLSml2?= =?utf-8?B?VGJtZVgzMkE0cERtdDdpNnBMZHR1NCthMzA2NnlqcE83bHFWbWQ2YXhBSXFF?= =?utf-8?B?QWpxekpZeEVpV2VBY050bGk2REtVTXE2czR5MTNQb2pjTXIxcUdybnpjajRZ?= =?utf-8?B?YjdYYkVzTnFYdFYvcjR6WGlSWk9pWHBCQnZMZzF4QkRMZ0VmbFBMMWs2c1Zp?= =?utf-8?B?bmVlS2R1WWloclZ1UjFRdFNTeS8vQml0VzdnVFE5YnVaTWR0NHd1NndHTTlk?= =?utf-8?B?RUdPTm05RFFkdE1xYnl2dHdqc2NWV09EOXBqMjA4a3IzWTczWXBydVo4L2Yy?= =?utf-8?B?Q2Ryd0dKa2hHU0VUUjFJRWVPa2MxcUlrcko3S1hsdWFOYlJFcmF3K1FJYVVa?= =?utf-8?B?Vk1KK1dIalE1cEhJUHp3NW1mNlhGRlNXYXJFKzlGcWJjWFdpU1VTNm9uaFk0?= =?utf-8?B?RXMvVmFjVzB1ajdXcmJiQVBTeFF1UWh3SUFiS3pCY211WTRHb3ViRVBLZDBT?= =?utf-8?B?UnRMUXFVdTlqc3JEQmQva0xHTkNZRVI2L284enpld2kycE9nQ2lUR0twUUN0?= =?utf-8?B?NmRpUDZsK2N6YjY5K1lKb29MRXI3OWk2WWVzaHFKalRyQXRFR2s4VVA2Z25P?= =?utf-8?B?VVlpbE04WHgzZ0JKN2QzalRZRCtIZUo0V1hsTDJ4TTB1dWFDVmJidi9PYlVz?= =?utf-8?B?bG5LMW8wN0s4UmExQ0c5SDY2WHg2dkJXaE9DbkIvOGEzMWxEeFBhTEJsM1E4?= =?utf-8?B?QTdqZGtwbU9nK2lMYjFMV2Q5d2FFanA4S0ZjeVZ3RndHZFA5a1RiVWFxM2Mr?= =?utf-8?B?cjRjSklhK1JTR3FDYUUxVStTRnpQb3VYcjltVGQ3YndOam9KRmFjUFpzMlk3?= =?utf-8?B?ZEF2Nk4vaEE0OWJBTkZJeVp5bkNIK1VNNnZZcnNTRzBvR0x5MWhPTG9EZE5T?= =?utf-8?B?VVVEYm8rcW9xUlE4d3FPNVZNT09Va204Z2IwNW12TzhENDUrb1lWYWY5YkFS?= =?utf-8?B?ZTl1Ky94SVc1TGxvL1Q3U3duemUzSUxtUHkyK2IwWDZ4andGcURkMUxLRlc2?= =?utf-8?B?NnlPNkxNTkNjWWVXZXI4U280NFFCTFM1OGhtVzFsNHdvZkxOTTY5cEsvblVG?= =?utf-8?B?TzREUGpXT0U2Ti9GRVJVa3R1L0pTWFFTdzdmREJVZEZVU1RPQTk5RWR4WkNI?= =?utf-8?B?SlJ4SVhhRmpaWEUrb2tibzdQUlFUQ1RvNTFGQzRPaFdLa3UzUlpDZWc0SkZ3?= =?utf-8?Q?mNqkxZX40sfxkRu1IJCQ5W0IwOW7cfbDAr?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2021 19:57:39.3808 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-Network-Message-Id: 5f793365-31d3-4fce-9d82-08d8b8c6a5a3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ppQAdfHsDXCrtgWErLX2jWIzRQNKI/Bdm2Tm/r6LEFPDjBYpMCvBNExqPCMCFOgw17MllyNcnOPwtqPFOS34kA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0280 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.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: Thu, 14 Jan 2021 19:57:47 -0000 --AYugZCTyRlXlJPfGx7lFnEZ6GuGylBScu Content-Type: multipart/mixed; boundary="ytG8UItc3Uci9JrV0nQLqKNvvqAqH5IdD" --ytG8UItc3Uci9JrV0nQLqKNvvqAqH5IdD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Med, Thanks for the new document version. Please, see below some comments on the latest additions, also related to what Jon raised at [1]. Best, /Marco [1] https://mailarchive.ietf.org/arch/msg/core/Orr8a1WlSu3Dk-gtPQZloDT9_1= E/ * Section 3.5 - This seems to mix aspects specific to Observe, with more general aspects applicable to requests with a payload, i.e. FETCH (with or without Observe), PUT, POST and PATCH/iPATCH. =C2=A0 What is specific of Observe is the first paragraph; and the usage = of the Observe option in the second and third paragraph. Anything else seems generic and applicable to requests with payload, so it might be moved up to some earlier section. * Section 3.5 - In the third paragraph, I'm not sure you necessarily need a payload to be present in the requests asking for missing response payloads. For instance, consider: =C2=A0 =C2=A0 - The examples in Figure 10 and Figure 11 of RFC 7959, with the no= te "(no payload for requests with Block2 with NUM !=3D 0)" , during the phas= e where the client consecutively asks for the next response payload. =C2=A0 - The examples in Figure 2 and Figure 3 of [2], where each request= for the next response payload using Block2 has no payload of its own. This would of course affect the example in Figure 15. =C2=A0 [2] https://tools.ietf.org/html/draft-ietf-ace-coap-est-18 * Section 3.5 - About the last sentence regarding the Observe option, there seems to be an exception to this rule (at least based on the later examples), where the server actually does include the Observe option in the response. =C2=A0=C2=A0 That is, consider the example in Figure 10, where the respon= se with M:0xba is lost. Later on, the client asks for that response payload by sending the request with M:0x87, which correctly does not include the Observe option. =C2=A0=C2=A0 =C2=A0=C2=A0 However, the following response with M:oxc3 and (from the po= int of view of the server) retransmitting that response payload with block number 10 does include the Observe option. =C2=A0=C2=A0 =C2=A0=C2=A0 The exception seems due to the fact that the retransmission = request from the client is specifically what you call 'Continue' Q-Block-2 in Section 3.4. The Observe option is in fact not included for the previously retransmitted response payloads with M:0xbb ... M:0xc2, as still part of the current payload set. * Section 3.6 - Part of the first sentence in the second paragraph seems to repeat what already said in the third paragraph of Section 3.5. On 2021-01-13 19:13, mohamed.boucadair@orange.com wrote: > Hi all,=20 > > This version integrates the latest comments from Marco, especially the = handling of FETCH. New examples were also added to illustrate the intende= d behavior.=20 > > If there are still any pending issues, please let us know.=20 > > Cheers, > Jon & Med > >> -----Message d'origine----- >> De=C2=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la pa= rt >> de internet-drafts@ietf.org >> Envoy=C3=A9=C2=A0: mercredi 13 janvier 2021 19:06 >> =C3=80=C2=A0: i-d-announce@ietf.org >> Cc=C2=A0: core@ietf.org >> Objet=C2=A0: I-D Action: draft-ietf-core-new-block-05.txt >> >> >> 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 : Constrained Application Protocol (CoAP) >> Block-Wise Transfer Options for Faster Transmission >> Authors : Mohamed Boucadair >> Jon Shallow >> Filename : draft-ietf-core-new-block-05.txt >> Pages : 42 >> Date : 2021-01-13 >> >> Abstract: >> This document specifies alternative Constrained Application >> Protocol >> (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 >> Options. >> >> These options are similar to the CoAP Block1 and Block2 Options, >> not >> a replacement for them, but do enable faster transmission rates >> for >> large amounts of data with less packet interchanges as well as >> supporting faster recovery should any of the blocks get lost in >> transmission. >> >> >> The IETF datatracker status page for this draft is: >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= tatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-new-block%2F&data=3D04%7C0= 1%7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bc= b413a838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3= d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C20= 00&sdata=3Dud1P4lktmZSE6bfK3Z1IvqZdjSG6aZJNUNwAfUEliFQ%3D&reserve= d=3D0 >> >> There are also htmlized versions available at: >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fto= ols.ietf.org%2Fhtml%2Fdraft-ietf-core-new-block-05&data=3D04%7C01%7Cm= arco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a= 838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3d8eyJ= WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&am= p;sdata=3DJ4zJlB0x1WpQosEH3R0WBg2hoHuRpKiQVPpfwTk82n4%3D&reserved=3D0= >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= tatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-core-new-block-05&data=3D= 04%7C01%7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a980= 9cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C2000&sdata=3DXzJsVE4fc8Bj8aoKqmVTjSztTnTqsr42QY3u3Fhu4BY%3D&r= eserved=3D0 >> >> A diff from the previous version is available at: >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-core-new-block-05&data=3D04%= 7C01%7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf= 0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZ= sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7= C2000&sdata=3DXfWCRY89NGPI%2BOH6rmg9BuJHjwIpsWAHadSIglqnDDE%3D&re= served=3D0 >> >> >> 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: >> https://eur02.safelinks.protection.outlook.com/?url=3Dftp%3A%2F%2Fftp.= ietf.org%2Finternet-drafts%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7= Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%= 7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ= IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DnDdHKBvQpuw= nSsPvGghajJsaBKTXk295O%2BNDXEri9V4%3D&reserved=3D0 >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ietf.org%2Fmailman%2Flistinfo%2Fi-d-announce&data=3D04%7C01%7Cmarco= =2Etiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a83= 8a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3d8eyJWI= joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&= sdata=3D%2F3GBuD%2Fc2uCE9bAdXWxAy0bYvLIPMczzffzKYKv6Zc4%3D&reserved=3D= 0 >> Internet-Draft directories: https://eur02.safelinks.protection.outlook= =2Ecom/?url=3Dhttp%3A%2F%2Fwww.ietf.org%2Fshadow.html&data=3D04%7C01%= 7Cmarco.tiloca%40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb4= 13a838a09ecc40cc9e8%7C0%7C0%7C637461584588455436%7CUnknown%7CTWFpbGZsb3d8= eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000= &sdata=3D%2BEoWyGAyhlY0NmwyMvoe2vOeuXciF7kdnsZe1dIIHP0%3D&reserve= d=3D0 or >> https://eur02.safelinks.protection.outlook.com/?url=3Dftp%3A%2F%2Fftp.= ietf.org%2Fietf%2F1shadow-sites.txt&data=3D04%7C01%7Cmarco.tiloca%40r= i.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a838a09ecc40cc9e= 8%7C0%7C0%7C637461584588465405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DLDcmi= 9fJAgtoqVsl4AUpt0Xm8K1XEFguDVmCXg6we88%3D&reserved=3D0 > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged= information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > Thank you. > > _______________________________________________ > core mailing list > core@ietf.org > https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= =2Eietf.org%2Fmailman%2Flistinfo%2Fcore&data=3D04%7C01%7Cmarco.tiloca= %40ri.se%7Cd7689f3604014e3b970908d8b7ef02a8%7C5a9809cf0bcb413a838a09ecc40= cc9e8%7C0%7C0%7C637461584588465405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj= AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3Dz= F09t2u3ZkjRw1eRfzIMegbOZRTIVRGGUVKE9TZp0oY%3D&reserved=3D0 --=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 --ytG8UItc3Uci9JrV0nQLqKNvvqAqH5IdD-- --AYugZCTyRlXlJPfGx7lFnEZ6GuGylBScu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmAAoisACgkQ7iZktA5Y 2kO1Dgf+LJj1eu1cO9hC1KCqfJx7+VMvvXocc2PHlku+E35frwlNBY24EFJd/eua i677jBfu9fvmGNZKOEKCXWEENz8M3J3tg4ww/FL4G+0teBI0g3plL88bU/wXpJkm 1tlxh3vFA5SbYPBSrZc0zgylEEKUsbGGzIaaYMvVdZde+tqhDM/tbP2vW0T0yP+a MBO2duNp7/9PnoZM31Y3XDi3iv23h03GNZ+PRgzNKbhvcrfdNYBOc/3FSTvmc3R+ af3mscNWmFoGlEU32kAEf2INvcGn658qPxLCCbcztd15U1lNHb8lBe5p2H6ZVI/Y qMXpUzAcSd16UYtgh3DYEToWxUcSug== =G0w8 -----END PGP SIGNATURE----- --AYugZCTyRlXlJPfGx7lFnEZ6GuGylBScu-- From nobody Fri Jan 15 03:24:32 2021 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 115683A0B1F for ; Fri, 15 Jan 2021 03:24:31 -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 VKoUdvouOnbz for ; Fri, 15 Jan 2021 03:24:29 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 D23003A0B18 for ; Fri, 15 Jan 2021 03:24:28 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1l0NDN-0001xi-3g; Fri, 15 Jan 2021 11:24:25 +0000 From: To: "Marco Tiloca" , , Cc: , References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> In-Reply-To: <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> Date: Fri, 15 Jan 2021 11:24:44 -0000 Message-ID: <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINhJL1nc88GwsEKn+AjV1kVr7Y4AGmsrCNATjbviqppE6oUA== Content-Language: en-gb Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.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, 15 Jan 2021 11:24:31 -0000 Hi Marco, Thanks from this. So moving forward, requests for missing Q-Block2 blocks will follow = Section 2.7 RFC7959 being modelled on (assuming the request was using = Q-Block1) " To continue this Block2 transfer, the client continues to send requests similar to the requests in the Block1 phase, but leaves out the Block1 Options and includes a Block2 request option with non-zero NUM." Otherwise, please see inline which has a couple of questions. Regards Jon > -----Original Message----- > From: Marco Tiloca [mailto: marco.tiloca@ri.se] > Sent: 14 January 2021 19:58 > To: mohamed.boucadair@orange.com; core@ietf.org > Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org > Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt >=20 > Hi Med, >=20 > Thanks for the new document version. >=20 > Please, see below some comments on the latest additions, also related = to what > Jon raised at [1]. >=20 > Best, > /Marco >=20 > [1] = https://mailarchive.ietf.org/arch/msg/core/Orr8a1WlSu3Dk-gtPQZloDT9_1E/ >=20 >=20 > * Section 3.5 - This seems to mix aspects specific to Observe, with = more general > aspects applicable to requests with a payload, i.e. FETCH (with or = without > Observe), PUT, POST and PATCH/iPATCH. [Jon] Now that we understand what needs to be done with requesting = missing Q-Block2 blocks, working with Observe can be simplified. [Jon] Requesting Observe is only valid for GET and FETCH. Hence Observe = request/cancellation setting when using Q-Block1 is only appropriate for = FETCH. [Jon] Unfortunately, RFC8132 does not specify in which of the payloads = of as Block1 based FETCH request should contain the Observe option = assuming observe is required (The first, the last or all of the = payloads). So, here, I believe the safest way to go is with all the = payloads carry the observe option if observe is being requested or = cancelled. Thus any missing payloads should be resent with the observe = configured to be consistent with all the other payloads. Are you happy = with this? >=20 > What is specific of Observe is the first paragraph; and the usage of = the Observe > option in the second and third paragraph. Anything else seems generic = and > applicable to requests with payload, so it might be moved up to some = earlier > section. >=20 [Jon] Sure - will be updated in the simplification tidy up. >=20 > * Section 3.5 - In the third paragraph, I'm not sure you necessarily = need a > payload to be present in the requests asking for missing response = payloads. For > instance, consider: [Jon] Agreed. Now going with Section 2.7 RFC7959 where both Block1 and = payload are not included. >=20 > - The examples in Figure 10 and Figure 11 of RFC 7959, with the note = "(no > payload for requests with Block2 with NUM !=3D 0)" , during the phase = where the > client consecutively asks for the next response payload. >=20 > - The examples in Figure 2 and Figure 3 of [2], where each request = for the next > response payload using Block2 has no payload of its own. >=20 > This would of course affect the example in Figure 15. [Jon] Yes, will be updated. >=20 > [2] https://tools.ietf.org/html/draft-ietf-ace-coap-est-18 >=20 >=20 > * Section 3.5 - About the last sentence regarding the Observe option, = there > seems to be an exception to this rule (at least based on the later = examples), > where the server actually does include the Observe option in the = response. [Jon] If the Observe option is just included with the first payload (NUM = =3D 0) as RFC7959, there is a recovery special case should the first = payload not arrive, but subsequent ones do. In the general case, blocks = that are missing are re-requested by the client and the server responds = with the appropriate block, but without the Observe option. For the = special case when the client requests missing payload with NUM =3D 0 the = server needs to know that it must include the Observe in the response so = that the client following the body re-assembly knows that it is a = Observe triggered additional response. [Jon] I had gone with the Observe should be in all the payloads in the = response apart from specifically re-requested blocks (including NUM =3D = 0). The 'Continue' Q-Block2 was just to indicate a continue so the = server can send the remaining payloads without delay - hence why = remaining payloads had Observe set. =20 [Jon] I am beginning to lean to having it in the first payload and = special case the response to re-request of NUM =3D 0. What do you = think? >=20 > That is, consider the example in Figure 10, where the response with = M:0xba is > lost. Later on, the client asks for that response payload by sending = the request > with M:0x87, which correctly does not include the Observe option. >=20 [Jon] Yes > However, the following response with M:oxc3 and (from the point of = view of > the server) retransmitting that response payload with block number 10 = does > include the Observe option. >=20 > The exception seems due to the fact that the retransmission request = from the > client is specifically what you call 'Continue' Q-Block-2 in Section = 3.4. The > Observe option is in fact not included for the previously = retransmitted response > payloads with M:0xbb ... M:0xc2, as still part of the current payload = set. [Jon] Correct, but obviously not obvious from the text. >=20 >=20 > * Section 3.6 - Part of the first sentence in the second paragraph = seems to > repeat what already said in the third paragraph of Section 3.5. >=20 [Jon] Will clean up in the simplification. ~Jon >=20 From nobody Fri Jan 15 03:44:25 2021 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 CE60D3A0B9E; Fri, 15 Jan 2021 03:44:24 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161071106480.5085.11871190593132075510@ietfa.amsl.com> Date: Fri, 15 Jan 2021 03:44:24 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-data-ct-03.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: Fri, 15 Jan 2021 11:44:25 -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 Data Value Content-Format Indication Authors : Ari Keränen Carsten Bormann Filename : draft-ietf-core-senml-data-ct-03.txt Pages : 7 Date : 2021-01-15 Abstract: The Sensor Measurement Lists (SenML) media type supports multiple types of values, from numbers to text strings and arbitrary binary data values. In order to simplify processing of the data values, this document proposes to specify a new SenML field for indicating the Content-Format of the data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-senml-data-ct-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-data-ct-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 15 05:58:19 2021 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 4BE313A00C9; Fri, 15 Jan 2021 05:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 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.262, 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 TSCnfFYtpMYj; Fri, 15 Jan 2021 05:58:14 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2063.outbound.protection.outlook.com [40.107.21.63]) (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 C05883A005F; Fri, 15 Jan 2021 05:58:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mw8ds/q/Ca8dYhLZiMLx+PoXJncrTbCaCWJdMbW6EIJEWW9moeRUmPCJLrr83okvkQxr2o/bHQCC1DIhnQmNqPv3a/Ss/MoHamiu4DakBrAJjoB8MIWoi9gJAa2In6k7ClAoqRyw8ROgZfUbLe+gcpkg+Sp/kHRsDjVbBmPClKQz12+f0CpxIhu2rOM0L17MgXTJvWKCz5JFLpIFRDfcMqZRLzKSgC4WBw4B4hya10tRu1ZYcBtA1J2j9wIP1ePFZ8rdlvWBGLb8hcK2qjAqmj06mfwxn5I4NDzq50icNi8Mxct7WMuu6fgu0xbzOjMVsfuyspODvKwzJT4YfTrmLg== 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=JsbE/EWoSwbOmlGjEHkfhOFJ1xCMQBh9ePpJsS4nxn4=; b=at038UC/2n93QfGM+OEV39zeAsHbW4BdntzomFcPzdozf10/voXzjjFJxRPpAvW46w75pNSJ5W/vA6VliYZT4w0Vrx1AlLxc/2qJhu7+4sNqon5lFHODG6F1Nabr5seBd7Ny3PEJcc8fMoeX/qiq4Mp35gDJLmpuCTjVYrkK6Uzyv0yGrNHxiVkSCHGJAfjK5Y4ao6sajUKlDEkhVfNkN1AQQLNHo4hLo8IAmIYJNPD59rz6bYtKeAedFAB4pyq8GKu1xKY7NkYdBfb+Qw7bou+fhQGVNmxmU/p1vRam70dIf6ze5YPkLBXOgdWeQGiU1252c0/qvMvHRABmnqrO7g== 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=JsbE/EWoSwbOmlGjEHkfhOFJ1xCMQBh9ePpJsS4nxn4=; b=UbV9Pb2G1m83g1S1Phua2X62TbWn6ZHY0WA5/h4ORCyOnbbnFSMmKCVK9RpXjqPhFkifliTZifLL4yrdTlWXpWci1ZvcooRjO6NJPDLpoYDuBKv7IGgTckdZV+HVFqd8WIPh/Xhh2qmAEKPC6DdjV5hUWvLJLm9jBg8CnXtd11g= 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 DB8P189MB0840.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.10; Fri, 15 Jan 2021 13:58:10 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3763.012; Fri, 15 Jan 2021 13:58:10 +0000 To: supjps-ietf@jpshallow.com, mohamed.boucadair@orange.com, core@ietf.org Cc: draft-ietf-core-new-block@ietf.org, dots@ietf.org References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> 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: <4feb5743-4193-97f1-5231-038b1838b934@ri.se> Date: Fri, 15 Jan 2021 14:57:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Pdv8nlHvanNlz4A8E2T7fPi8DfUREuxQX" X-Originating-IP: [92.34.27.84] X-ClientProxiedBy: BL1PR13CA0411.namprd13.prod.outlook.com (2603:10b6:208:2c2::26) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.68] (92.34.27.84) by BL1PR13CA0411.namprd13.prod.outlook.com (2603:10b6:208:2c2::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.7 via Frontend Transport; Fri, 15 Jan 2021 13:58:09 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 76ae1081-b806-489e-3b92-08d8b95d97ca X-MS-TrafficTypeDiagnostic: DB8P189MB0840: 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: 3lmUuUjqVy7cYTaSI6bOMb4ppl/4KpC+OWdNigvQHRuo+4M1EvpjkginsZQvmh/ypoSNY7N6jjupp5124G4Tazre+SruauAjuCBR0AeDXO4MRARFWFE5T1JJvBQ8aQxPFjuJqavmez+IZue/SUE2rlRfLHrZw3GRul8dWWMc6QVg91EO3W7DqztcgA10UHG0V9qQ6g0npt0jCnz2sxKx+aRvdipHG4bVkj0tKElpUB2lkySO1sC9CcJelSfVeBVVWM5oQIaVvFpDtpioj40sVwALxvSUa0WvxBRLsg33pKS+8LkTuc7xKtwW2EPMC53jCZkEUThszLLWYgyEeyUQoKUBHZ48v/qmWVfrwnQh0UDT7onuDarhD1bcoWdKfFwtjEq/Fu9y3gM1QO8UdqpVGKCMwTto3irmeNG3sp4WXM3dyknMuo/SJaKo9l2dJBmfRqNM8zMldK/rJt8/WpKEgVc8vl/2sU6k4+9iUgBm8Oh5PwMn0DdhUIKNiQH8zUpYKMIRHXeDU2suxd72PlywAVzam9Je8g3XshJ5VqM4e4GODn0thWE8e9UWjKMIvwKq 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)(376002)(39850400004)(346002)(8676002)(53546011)(44832011)(4326008)(45080400002)(6486002)(66476007)(316002)(66946007)(66574015)(2906002)(6666004)(235185007)(66556008)(5660300002)(16526019)(36756003)(16576012)(956004)(86362001)(31686004)(966005)(33964004)(26005)(52116002)(478600001)(31696002)(21480400003)(8936002)(83380400001)(2616005)(186003)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?ZmJSeDh3bGVJdk55YVdBTlNvOFJwWTBJVFZvQnFOUGw4Yno1M1U3NkVLYlJl?= =?utf-8?B?K3JFMml3V0E2OVFJWkxFcjlIQnpicURhRzMxUlRHZ0N1bFVxNzgxc3Q3cXlH?= =?utf-8?B?NU1pRGo3KzJ4bEkzSDBKTm9MMnNTcDc3bmVIWEpjUDJPb1dvckhaaHd1VGtn?= =?utf-8?B?YUJaTmNQR21HalZvL1hQN1pIUlg2ZFhoRDRrSUxUaHpWc1N2dW5RMndqZmsy?= =?utf-8?B?cjlzYVppNVo0ZzBERHl5UExOQjdXSGNOWjFuYjBJckdlR2Yyelpwb3BHVENR?= =?utf-8?B?dlR3Ritjam9Zc2JEbjdxUXVBbzhzenFKTVl6cUhvajVxVUFIbThsMW5wQU5Y?= =?utf-8?B?aTFtMnpsNHZUN3drV3dvK1ZXdXFzOGRuK2U5b3JCYnBhNmRkMFVnY3l5U0c0?= =?utf-8?B?NGhmbzhzNWtLUTNQajZNZ0M0MktJU3IyQk9ycEthQ2pWSTZDWjZ5SFQrSlhR?= =?utf-8?B?ajhxMXl4UmVMcjVvT2VBekZ5UnNQQktEWmY0aVJCUUxWTEQrQVN1ZlU0N25M?= =?utf-8?B?UUxGTk9pV0RzMFZoRGo2SFdPWHlpN3VkNUtqRHdMK1hIU3g0UHdseEVkeGtw?= =?utf-8?B?MldWMmc0M000SHB3Q2hEWTN0czRWeENxaHlOMEwrQW83eGhITTV1WEM3NzM2?= =?utf-8?B?TWZuQVV5MkxKaENuNzFqZjRoQWRaQXh3OTlwaEVxamgxbEdYNlFjRVgzKzRu?= =?utf-8?B?WXlsMjdwdC9BbWZtSExnWGtpT2dZVUxQLzZ2cm5sZ3FUSXpNSFpUVnZIa1NY?= =?utf-8?B?RGY2ZDVHdHNvaGN5dVFvMW9FSFlzQllZNUltdkQybTMrUHNEYndObFNyN1BZ?= =?utf-8?B?NFF2TGlhZTdkOGxoVjFGV1hqMlZ4bWJtbHRrbU1MR3kyWUc0K2RZaVJqRjBq?= =?utf-8?B?S2Rvald1MmhGNnk1Y09SL1MvREsrcXF5dENEZFBpWnJENlF6T29ZR1FjdWpz?= =?utf-8?B?VVZBeFNDdnNuMFFMd3FIbWE4dGh3ei9aMHIzaGprdmVhNDZHTXBFVXJrME5t?= =?utf-8?B?WDRtUTZ3YVhQU3VpOGYvN01XcmE5dGxJaFBXaDdtcUVETDAwelhyQTVwWTVs?= =?utf-8?B?V0drbmE4NW5qc2F2ZmEzQ09EYnZDQVlhcDFUUmw4Z1E5b1lzRzZRQXVySlRB?= =?utf-8?B?Z1RsK3FVeGIwZ2tpM25MMVRTL0NFcVluMFRxQnZKNWlSdldVY3AzbHo0ZVlO?= =?utf-8?B?alY1V0lhODduNVNWL2NxdHo5enA1dEhuMHB3QTg0YlpwNXo3VmUyZ2NWTTl3?= =?utf-8?B?bnpkTE1VUG5taWVXQjhPWlZuQ3d1WWtvMmxRK21XN3FGUExMTU83YjFDcjI5?= =?utf-8?Q?Q+ba4JHIOGQxk=3D?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 76ae1081-b806-489e-3b92-08d8b95d97ca X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2021 13:58:10.5074 (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: HmRhbXH0zVTQfxUrti853mUAwI6j0yQWi/6FHoRoRt6qQty+baeT2P1+bIypSIcJ7D7gxZEFpRY2FBOFKF39jw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0840 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.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, 15 Jan 2021 13:58:18 -0000 --Pdv8nlHvanNlz4A8E2T7fPi8DfUREuxQX Content-Type: multipart/mixed; boundary="wUpSmJEIzsn19Uee57mQ44RnnwmCrPesO" --wUpSmJEIzsn19Uee57mQ44RnnwmCrPesO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jon, On 2021-01-15 12:24, supjps-ietf@jpshallow.com wrote: > Hi Marco, > > Thanks from this. > > So moving forward, requests for missing Q-Block2 blocks will follow Sec= tion 2.7 RFC7959 being modelled on (assuming the request was using Q-Bloc= k1) > " To continue this Block2 transfer, the client > continues to send requests similar to the requests in the Block1 > phase, but leaves out the Block1 Options and includes a Block2 > request option with non-zero NUM." > > Otherwise, please see inline which has a couple of questions. > > Regards > > Jon >> -----Original Message----- >> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >> Sent: 14 January 2021 19:58 >> To: mohamed.boucadair@orange.com; core@ietf.org >> Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org >> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt >> >> Hi Med, >> >> Thanks for the new document version. >> >> Please, see below some comments on the latest additions, also related = to what >> Jon raised at [1]. >> >> Best, >> /Marco >> >> [1] https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcore%2FOrr8a1WlSu3Dk-gtPQZloDT9_1E%= 2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d8b9= 48202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7C= Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw= iLCJXVCI6Mn0%3D%7C1000&sdata=3DE4lIccwYQyVGHxxl9v9iBr70hU6BuxRrzAQoZH= nZt%2B8%3D&reserved=3D0 >> >> >> * Section 3.5 - This seems to mix aspects specific to Observe, with mo= re general >> aspects applicable to requests with a payload, i.e. FETCH (with or wit= hout >> Observe), PUT, POST and PATCH/iPATCH. > [Jon] Now that we understand what needs to be done with requesting miss= ing Q-Block2 blocks, working with Observe can be simplified. > > [Jon] Requesting Observe is only valid for GET and FETCH. Hence Observ= e request/cancellation setting when using Q-Block1 is only appropriate fo= r FETCH. > > [Jon] Unfortunately, RFC8132 does not specify in which of the payloads= of as Block1 based FETCH request should contain the Observe option assu= ming observe is required (The first, the last or all of the payloads). So= , here, I believe the safest way to go is with all the payloads carry the= observe option if observe is being requested or cancelled. Thus any mis= sing payloads should be resent with the observe configured to be consiste= nt with all the other payloads. Are you happy with this? =3D=3D>MT It makes sense to me. <=3D=3D > >> What is specific of Observe is the first paragraph; and the usage of= the Observe >> option in the second and third paragraph. Anything else seems generic = and >> applicable to requests with payload, so it might be moved up to some e= arlier >> section. >> > [Jon] Sure - will be updated in the simplification tidy up. >> * Section 3.5 - In the third paragraph, I'm not sure you necessarily n= eed a >> payload to be present in the requests asking for missing response payl= oads. For >> instance, consider: > [Jon] Agreed. Now going with Section 2.7 RFC7959 where both Block1 and= payload are not included. >> - The examples in Figure 10 and Figure 11 of RFC 7959, with the note= "(no >> payload for requests with Block2 with NUM !=3D 0)" , during the phase = where the >> client consecutively asks for the next response payload. >> >> - The examples in Figure 2 and Figure 3 of [2], where each request f= or the next >> response payload using Block2 has no payload of its own. >> >> This would of course affect the example in Figure 15. > [Jon] Yes, will be updated. >> [2] https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-coap-est-18&data=3D04%7C01%7= Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d8b948202a%7C5a9809cf0bcb41= 3a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7CUnknown%7CTWFpbGZsb3d8e= yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= amp;sdata=3DcSOOuCBEP2jCRzECrJeLli6Z%2Bu%2FUlD%2F1HzVWIM7O7%2BQ%3D&re= served=3D0 >> >> >> * Section 3.5 - About the last sentence regarding the Observe option, = there >> seems to be an exception to this rule (at least based on the later exa= mples), >> where the server actually does include the Observe option in the respo= nse. > [Jon] If the Observe option is just included with the first payload (NU= M =3D 0) as RFC7959, there is a recovery special case should the first pa= yload not arrive, but subsequent ones do. In the general case, blocks th= at are missing are re-requested by the client and the server responds wit= h the appropriate block, but without the Observe option. For the special = case when the client requests missing payload with NUM =3D 0 the server n= eeds to know that it must include the Observe in the response so that the= client following the body re-assembly knows that it is a Observe trigger= ed additional response. > > [Jon] I had gone with the Observe should be in all the payloads in the = response apart from specifically re-requested blocks (including NUM =3D 0= ). The 'Continue' Q-Block2 was just to indicate a continue so the server= can send the remaining payloads without delay - hence why remaining payl= oads had Observe set. =20 > > [Jon] I am beginning to lean to having it in the first payload and spec= ial case the response to re-request of NUM =3D 0. What do you think? =3D=3D>MT Ok, I didn't think also of the case for NUM =3D 0, but that makes sense t= oo. Then it's certainly something better to clarify in the main text and also to show/comment in the example of Figure 10. <=3D=3D > >> That is, consider the example in Figure 10, where the response with= M:0xba is >> lost. Later on, the client asks for that response payload by sending t= he request >> with M:0x87, which correctly does not include the Observe option. >> > [Jon] Yes >> However, the following response with M:oxc3 and (from the point of = view of >> the server) retransmitting that response payload with block number 10 = does >> include the Observe option. >> >> The exception seems due to the fact that the retransmission request= from the >> client is specifically what you call 'Continue' Q-Block-2 in Section 3= =2E4. The >> Observe option is in fact not included for the previously retransmitte= d response >> payloads with M:0xbb ... M:0xc2, as still part of the current payload = set. > [Jon] Correct, but obviously not obvious from the text. =3D=3D>MT Right, I mostly focused on that. I think it's worth clarifying in the main text what the normal case is for the server (client) to include (expect) the Observe option in a response payload; and then highlight the exceptions for the re-request with NUM=3D0 (see above) and for the 'Continue' Q-Block2. Best, /Marco <=3D=3D >> >> * Section 3.6 - Part of the first sentence in the second paragraph see= ms to >> repeat what already said in the third paragraph of Section 3.5. >> > [Jon] Will clean up in the simplification. > ~Jon --=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 --wUpSmJEIzsn19Uee57mQ44RnnwmCrPesO-- --Pdv8nlHvanNlz4A8E2T7fPi8DfUREuxQX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmABn2YACgkQ7iZktA5Y 2kO1Sgf+MXtZ0/eUcU8GCt0bA2wHCNka5/4yV6o4iU9Hh9AW0EldPaW7adsRoSvO yldlSvDFLZmsu8yWtkJkJx6G9l5EMdULFPkTUYzRekQwDPo9ywjm/JPAhT43WjP6 FhSgLttuCNqUi1CyUJ9hDN0Ym72nP0YmyaXAjXfZHlvO1wQQ9N4IItv99IeDAtQT T4S+Dkzy7y6A9/2dRXR7u2IMPY12TRSYEXvStgiR9K2rEERzM3rj8lUtbNpR+prr sP5ONyGJ9WcrVlXci9ZuciQSRUaXhkYDQlfeYIaRT2wBJQ2s4n+RJbW6N2dNoHlH +0exSSZ/nrtGSZAe0CSfEbkw2WNNHA== =8qpT -----END PGP SIGNATURE----- --Pdv8nlHvanNlz4A8E2T7fPi8DfUREuxQX-- From nobody Sun Jan 17 09:07:48 2021 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 A10E23A12A0; Sun, 17 Jan 2021 09:07:46 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161090326651.25629.14237901832957314715@ietfa.amsl.com> Date: Sun, 17 Jan 2021 09:07:46 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-sid-15.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, 17 Jan 2021 17:07:47 -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 : YANG Schema Item iDentifier (YANG SID) Authors : Michel Veillette Alexander Pelov Ivaylo Petrov Filename : draft-ietf-core-sid-15.txt Pages : 37 Date : 2021-01-17 Abstract: YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit unsigned integers used to identify YANG items. This document defines the semantics, the registration, and assignment processes of YANG SIDs. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-sid-15 https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 17 09:11:59 2021 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 30B033A12A2; Sun, 17 Jan 2021 09:11:58 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161090351808.23528.15520527217903185429@ietfa.amsl.com> Date: Sun, 17 Jan 2021 09:11:58 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-yang-cbor-14.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, 17 Jan 2021 17:11:58 -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 : CBOR Encoding of Data Modeled with YANG Authors : Michel Veillette Ivaylo Petrov Alexander Pelov Filename : draft-ietf-core-yang-cbor-14.txt Pages : 46 Date : 2021-01-17 Abstract: This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, action input, action output, notifications and yang-data extension defined within YANG modules using the Concise Binary Object Representation (CBOR, RFC 7049). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-14 https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-yang-cbor-14 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 Jan 17 09:17:43 2021 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 C3A583A12A3; Sun, 17 Jan 2021 09:17:41 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161090386169.22032.6021098098674897344@ietfa.amsl.com> Date: Sun, 17 Jan 2021 09:17:41 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-comi-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: Sun, 17 Jan 2021 17:17:42 -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 Management Interface (CORECONF) Authors : Michel Veillette Peter van der Stok Alexander Pelov Andy Bierman Ivaylo Petrov Filename : draft-ietf-core-comi-11.txt Pages : 52 Date : 2021-01-17 Abstract: This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-comi/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-comi-11 https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-comi-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 Jan 18 06:16:18 2021 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 3B0F53A1311 for ; Mon, 18 Jan 2021 06:16: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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDz4g7WvspbF for ; Mon, 18 Jan 2021 06:16:10 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 008A63A1145 for ; Mon, 18 Jan 2021 06:16:09 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1l1VKA-0005K0-UZ; Mon, 18 Jan 2021 14:16:07 +0000 From: To: "Marco Tiloca" , , Cc: , References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> <4feb5743-4193-97f1-5231-038b1838b934@ri.se> In-Reply-To: <4feb5743-4193-97f1-5231-038b1838b934@ri.se> Date: Mon, 18 Jan 2021 14:16:23 -0000 Message-ID: <033b01d6eda4$8013a980$803afc80$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINhJL1nc88GwsEKn+AjV1kVr7Y4AGmsrCNATjbvioB8R1SgQKCeaN3qYWl4aA= Content-Language: en-gb Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.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, 18 Jan 2021 14:16:13 -0000 Hi Marco, We have updated github [1] to take account of your latest comments for = your review. Regards Jon [1]https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-new-block&url2=3Dh= ttps://raw.githubusercontent.com/core-wg/new-block/master/draft-ietf-core= -new-block.txt > -----Original Message----- > From: Marco Tiloca [mailto: marco.tiloca@ri.se] > Sent: 15 January 2021 13:58 > To: jon@jpshallow.com; mohamed.boucadair@orange.com; core@ietf.org > Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org > Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt >=20 > Hi Jon, >=20 > On 2021-01-15 12:24, supjps-ietf@jpshallow.com wrote: > > Hi Marco, > > > > Thanks from this. > > > > So moving forward, requests for missing Q-Block2 blocks will follow > > Section 2.7 RFC7959 being modelled on (assuming the request was = using Q- > Block1) " To continue this Block2 transfer, the client > > continues to send requests similar to the requests in the Block1 > > phase, but leaves out the Block1 Options and includes a Block2 > > request option with non-zero NUM." > > > > Otherwise, please see inline which has a couple of questions. > > > > Regards > > > > Jon > >> -----Original Message----- > >> From: Marco Tiloca [mailto: marco.tiloca@ri.se] > >> Sent: 14 January 2021 19:58 > >> To: mohamed.boucadair@orange.com; core@ietf.org > >> Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org > >> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt > >> > >> Hi Med, > >> > >> Thanks for the new document version. > >> > >> Please, see below some comments on the latest additions, also = related > >> to what Jon raised at [1]. > >> > >> Best, > >> /Marco > >> > >> [1] > >> = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmai > >> larchive.ietf.org%2Farch%2Fmsg%2Fcore%2FOrr8a1WlSu3Dk- > gtPQZloDT9_1E%2 > >> > F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d > 8b > >> > 948202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63746306674 > 04024 > >> > 21%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > CJBTi > >> > I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DE4lIccwYQyVGHxxl9v9iBr70 > hU6 > >> BuxRrzAQoZHnZt%2B8%3D&reserved=3D0 > >> > >> > >> * Section 3.5 - This seems to mix aspects specific to Observe, with > >> more general aspects applicable to requests with a payload, i.e. > >> FETCH (with or without Observe), PUT, POST and PATCH/iPATCH. > > [Jon] Now that we understand what needs to be done with requesting = missing > Q-Block2 blocks, working with Observe can be simplified. > > > > [Jon] Requesting Observe is only valid for GET and FETCH. Hence = Observe > request/cancellation setting when using Q-Block1 is only appropriate = for FETCH. > > > > [Jon] Unfortunately, RFC8132 does not specify in which of the = payloads of as > Block1 based FETCH request should contain the Observe option assuming > observe is required (The first, the last or all of the payloads). So, = here, I believe > the safest way to go is with all the payloads carry the observe option = if observe > is being requested or cancelled. Thus any missing payloads should be = resent with > the observe configured to be consistent with all the other payloads. = Are you > happy with this? >=20 > =3D=3D>MT > It makes sense to me. > <=3D=3D >=20 > > > >> What is specific of Observe is the first paragraph; and the usage > >> of the Observe option in the second and third paragraph. Anything > >> else seems generic and applicable to requests with payload, so it > >> might be moved up to some earlier section. > >> > > [Jon] Sure - will be updated in the simplification tidy up. > >> * Section 3.5 - In the third paragraph, I'm not sure you = necessarily > >> need a payload to be present in the requests asking for missing > >> response payloads. For instance, consider: > > [Jon] Agreed. Now going with Section 2.7 RFC7959 where both Block1 = and > payload are not included. > >> - The examples in Figure 10 and Figure 11 of RFC 7959, with the > >> note "(no payload for requests with Block2 with NUM !=3D 0)" , = during > >> the phase where the client consecutively asks for the next response = payload. > >> > >> - The examples in Figure 2 and Figure 3 of [2], where each = request > >> for the next response payload using Block2 has no payload of its = own. > >> > >> This would of course affect the example in Figure 15. > > [Jon] Yes, will be updated. > >> [2] > >> = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftoo > >> ls.ietf.org%2Fhtml%2Fdraft-ietf-ace-coap-est- > 18&data=3D04%7C01%7Cma > >> > rco.tiloca%40ri.se%7Cf30167412cf14279616708d8b948202a%7C5a9809cf0bcb > 4 > >> > 13a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7CUnknown%7CT > WFpbGZs > >> > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > %3 > >> > D%7C1000&sdata=3DcSOOuCBEP2jCRzECrJeLli6Z%2Bu%2FUlD%2F1HzVWIM7 > O7%2B > >> Q%3D&reserved=3D0 > >> > >> > >> * Section 3.5 - About the last sentence regarding the Observe = option, > >> there seems to be an exception to this rule (at least based on the > >> later examples), where the server actually does include the Observe = option in > the response. > > [Jon] If the Observe option is just included with the first payload = (NUM =3D 0) as > RFC7959, there is a recovery special case should the first payload not = arrive, but > subsequent ones do. In the general case, blocks that are missing are = re- > requested by the client and the server responds with the appropriate = block, but > without the Observe option. For the special case when the client = requests > missing payload with NUM =3D 0 the server needs to know that it must = include the > Observe in the response so that the client following the body = re-assembly knows > that it is a Observe triggered additional response. > > > > [Jon] I had gone with the Observe should be in all the payloads in = the response > apart from specifically re-requested blocks (including NUM =3D 0). = The 'Continue' > Q-Block2 was just to indicate a continue so the server can send the = remaining > payloads without delay - hence why remaining payloads had Observe set. > > > > [Jon] I am beginning to lean to having it in the first payload and = special case > the response to re-request of NUM =3D 0. What do you think? >=20 > =3D=3D>MT > Ok, I didn't think also of the case for NUM =3D 0, but that makes = sense too. >=20 > Then it's certainly something better to clarify in the main text and = also to > show/comment in the example of Figure 10. > <=3D=3D >=20 > > > >> That is, consider the example in Figure 10, where the response > >> with M:0xba is lost. Later on, the client asks for that response > >> payload by sending the request with M:0x87, which correctly does = not include > the Observe option. > >> > > [Jon] Yes > >> However, the following response with M:oxc3 and (from the point = of > >> view of the server) retransmitting that response payload with block > >> number 10 does include the Observe option. > >> > >> The exception seems due to the fact that the retransmission > >> request from the client is specifically what you call 'Continue' > >> Q-Block-2 in Section 3.4. The Observe option is in fact not = included > >> for the previously retransmitted response payloads with M:0xbb ... = M:0xc2, > as still part of the current payload set. > > [Jon] Correct, but obviously not obvious from the text. >=20 > =3D=3D>MT > Right, I mostly focused on that. >=20 > I think it's worth clarifying in the main text what the normal case is = for the server > (client) to include (expect) the Observe option in a response payload; = and then > highlight the exceptions for the re-request with NUM=3D0 (see above) = and for the > 'Continue' Q-Block2. >=20 > Best, > /Marco > <=3D=3D >=20 > >> > >> * Section 3.6 - Part of the first sentence in the second paragraph > >> seems to repeat what already said in the third paragraph of Section = 3.5. > >> > > [Jon] Will clean up in the simplification. > > ~Jon >=20 > -- > Marco Tiloca > Ph.D., Senior Researcher >=20 > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) >=20 > Phone: +46 (0)70 60 46 501 > https://www.ri.se >=20 From nobody Mon Jan 18 08:26:22 2021 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 D5C753A098C; Mon, 18 Jan 2021 08:26:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-core-dev-urn@ietf.org, core-chairs@ietf.org, core@ietf.org, Marco Tiloca , marco.tiloca@ri.se, housley@vigilsec.com, dthaler@microsoft.com X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <161098718084.16632.293509938198284708@ietfa.amsl.com> Date: Mon, 18 Jan 2021 08:26:20 -0800 Archived-At: Subject: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-dev-urn-10=3A_=28with_COMMENT=29?= 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, 18 Jan 2021 16:26:21 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-core-dev-urn-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. I just wonder why this document is the work of CORE as it is quite generic and could be used outside of CORE (but, this is not a problem at all as it is an IETF stream document and had an IETF last call). There have been two IoT directorate reviews by: - Dave Thaler https://datatracker.ietf.org/doc/review-ietf-core-dev-urn-09-iotdir-telechat-thaler-2021-01-07/ - Russ Housley: https://datatracker.ietf.org/doc/review-ietf-core-dev-urn-09-iotdir-telechat-housley-2021-01-06/ both reviews have a status of 'Almost Ready' that translates into authors SHOULD really address the comments (and I have seen already many email messages on those reviews). Please find below some non-blocking COMMENT points (but replies would be appreciated), and one nit. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 4.1 -- Should "FFFF" be replaced by "0xffff" especially as there is some text before (section 3.2.1) suggesting to use lowercase of MAC addresses ? More important: can MAC address be part of an identifier in the world of random MAC address (or on the spot generated MAC address -- think VM) ? I suggest to add some text around MAC address randomization impact. == NITS == -- Section 4.2 -- s/64 bit identifier/64-bit identifier/ ? From nobody Tue Jan 19 03:50:41 2021 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 834683A147B; Tue, 19 Jan 2021 03:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 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.262, 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=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 W_A_w4YigIZQ; Tue, 19 Jan 2021 03:50:30 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80079.outbound.protection.outlook.com [40.107.8.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 DE4C63A1479; Tue, 19 Jan 2021 03:50:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZUeiHvxfrDraXKzg5H+4KuQgGL7rRTjdEgilvKdHl2mBG1Eae8Q59LflnpxKFJ5YKPREhy3X7iAPUd3OEAEl8DXrLVLK1UFGR01XfbdWFY8/Ykun+5DJ/dh7UapPxDpWFMfkbNM45/lLQdk26i/UWl8Be0Ebt3iOqTnGjSjgKK3K3Zv5hQpv+8Lt48ooMAV2OWhVKjFcaEOcec3xv90Ynfjid4UD6uBBT1D6+qTyboEn+IVoXntQQJqwo3B/vPKjPSaBN6jBXskPEMzS3ic4t0LsekV753/F5hUMOHycBGusPqG9KgbO56izw3ZwTIDwgVWc54tYv8/gXiTVDxgTuQ== 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=Mx9sNUqorWwCfXMhg7RmeUZaqXxbJJ/c+5LUG7sCH4Y=; b=W4s3k3oBbFk58VFRc9ACsuHrTpPjXpe5dBWJfl1Au3gFCvF1D8FrwmogHo4fO88IgRVg+1TyusASCoYGakroOLVpAgm+Io66khrohG7MHI0PfEsHWDLdXdKQNj8U+LKRKnKvZ6oM7Y86/9xKZHKRbuoXgiBOdELK8s/u9nqJ1kyb+ySjaK62zYFOG2GQXaexZhaL/+Y7Zo0XkmDwe5NPLu/K3kp16vItuQRmp+wecrw1Usenl+oKrtRpfvHygd95OPAkeWhxQvStd4UY4M1E9QdN7M//IuD6PYfBMSumzU9a1UUwhJZTBz30jsKgKcZt8xIO4gq/MlKDXJ5VgzFo6w== 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=Mx9sNUqorWwCfXMhg7RmeUZaqXxbJJ/c+5LUG7sCH4Y=; b=ZuRA+79a9emH/FPLDcj4u/dbPt5/DF58a035+/zeMhrLpJYPVvPpj+0Eyu+8w3oLGPnd5MsfpRFoA7v1CQMwDq2ilB7udov0RxKNw9Haf8Bd08+KEZbtyFV02563wL9enn3thXVjxESsQJHt87ntWhtuDCE3rsLHJodNtwOQzG4= 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 DB6P18901MB0135.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:26::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.11; Tue, 19 Jan 2021 11:50:26 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3763.014; Tue, 19 Jan 2021 11:50:26 +0000 To: supjps-ietf@jpshallow.com, mohamed.boucadair@orange.com, core@ietf.org Cc: draft-ietf-core-new-block@ietf.org, dots@ietf.org References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> <4feb5743-4193-97f1-5231-038b1838b934@ri.se> <033b01d6eda4$8013a980$803afc80$@jpshallow.com> 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: <5fc34721-6a91-39b9-5f8d-b58e6ec905f6@ri.se> Date: Tue, 19 Jan 2021 12:50:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <033b01d6eda4$8013a980$803afc80$@jpshallow.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jp3EjbJpE0tGBYJxOyLLxNGLzQ6sXgacO" X-Originating-IP: [37.120.209.212] X-ClientProxiedBy: HE1PR1001CA0003.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::13) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.2.7] (37.120.209.212) by HE1PR1001CA0003.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.10 via Frontend Transport; Tue, 19 Jan 2021 11:50:25 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 977831cd-f3b8-4318-e8b9-08d8bc70694d X-MS-TrafficTypeDiagnostic: DB6P18901MB0135: 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: oIGW6v3Aa6L4SzkIvDO4n6x2YTLRB3cLOxVWWfsgRmq4FUciL4mTX3D3cNb33j9HTpPkwuQpyrY0W3eyMc29IdKemmp4fCDwZVA2AoIp8dQ3IKY1MwkS9SvBL/TJ9NBz4v+Je66Of1n0pXnKZxqUAJMwhVykY3Wn50ZBt+3ZWd9b26ig9S5/JISA5aXcyUX3avpTSSd/9kzojHqMtR/7GnhaAroYSQw01VcgtZ82SXHJBRg+LTMhXexWzRXMoV/wlEpKC4MPl2NMoGyG7A/ltlsL9WZ1tUDzadrX9BtIEjn0S0qgZqcHqD98eYOayBjyzzQ2LtqB6G0eq2CXRtPK4mrMLeD+sAJSgVEVuUMysRNBxdJfDKQfOTIRBSbrHNZt49ogGyCAImUUm8hZHZCW4i2bHHCqzDszJh9vA5tT3+e8XIfurC/shTaJfUnVEM7ORBr+xwjVa+k1J4+uX8z3AR7mS+VuCuU0GPFOQs08I6dqtiJ8mdw3VU3P2xOmGdcW2EpFNl+SUQQFYwfizAqCw195q9E/jtSfMQ5kLVTtd64VnGZm+OmRWIjzUg3jjAi+tW/0XCDbwWxG7WxxbMXY6y7XD23t+7n8BcgbqRCEBsqrj7W4BlqLMu6nxgl0ijuYt1MxfUV7EoWUIeYPX9l9SrM9ntO0gG1ID+rXqq4GD3UJCmAGJ4gAupOVW2VCUOM7 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)(376002)(396003)(366004)(136003)(66574015)(30864003)(5660300002)(235185007)(16526019)(2906002)(6666004)(186003)(83380400001)(36756003)(86362001)(8676002)(53546011)(26005)(8936002)(45080400002)(44832011)(4326008)(31696002)(31686004)(956004)(966005)(52116002)(66556008)(66476007)(33964004)(478600001)(66946007)(21480400003)(6486002)(316002)(16576012)(2616005)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?bjkxcDlSZFk4Q3NBbmtLYzI3Tzg5N1JudzFDNmJSUnFENFIrTFVZRFJpcFht?= =?utf-8?B?eDB1Yis0WVMyRm5ranBlMWhXMUpYRFlwVnBhajF2YiszakVOSnFWUDM5dkhy?= =?utf-8?B?b3BvaGtiTVJYTWhuTkxwa2NTTjkzK3dncmpwVW1UbGdOY2ZMTmxrRnhBUzh6?= =?utf-8?B?WHdPZytDWWhHUVJKSnhiUjdka09tT2R1dTFLcTFOMXV1K0FJZi9EK3lPS3Zn?= =?utf-8?B?NnNEbnFlR1Y1elBlTFBnL1N1ZjRFMXNNZUpwdUtxcmNSNFpWNkRySGoxRHdH?= =?utf-8?B?RGMzOXFCbnVGd2xNdmsxemxDTHRkWVMvNHlucFlCaDNlMzljcG5JWS9GbHl4?= =?utf-8?B?d0piOFg1WEkzaE5HNkY0T3NGWTJwUENkTmJObmZVRE85R3U4ZkxmV0t5a3By?= =?utf-8?B?OFEyQ1lZa0FSVnFLeTIzSWZuQnVqaHNVK3FVSkw0aTBGZGpHaC80MVhoWGN3?= =?utf-8?B?VEh0ZjBTRzIwMXI1eGJUV3RHTW5aazNOWGJ5d0JwM0t5SDZ2UGxKQXdRaWwz?= =?utf-8?B?aDlzaGFSS0IxZFdYL3VsNnkvREJQcE5wYllVUExLc0lLbllqUDFVNFJQYmJq?= =?utf-8?B?QjhCMlNTdjAwVlBpSW90Q0RNeGJMZkVvRng3cFFHRVZYdlVQdTZCajRKUm5z?= =?utf-8?B?cDJOT1VsQXJBaS8wQWM4REZ3SXJVajVvQkV1aElzMmIzTVFkeGFkRGtKdkQx?= =?utf-8?B?UUIwclM2SUJVdDYwRTFzT0E4cnExZEVGWFducnZYZHdzcUhobUdVaWtwY0tC?= =?utf-8?B?ME5LYXlNNFAyTGlUQy9nck5STGVqcEl4NVl0MzlxUlY5OUE1TFJhakM0ZGJo?= =?utf-8?B?L0ZUWUJFeVhJKzBpUmQvVmVFRzNEaWVoM3lPbForQS84Y2VJdjdMTE4yL1RL?= =?utf-8?B?R3MzWTZNU1lneUJyQUpqY3dGajVkWVJXTmJMZmZsN1l0enhWMWRnZ2FZQ2F2?= =?utf-8?B?dnF2cUdCdjdYcWZNSTY5NFRLZnJRUWIrajhxSy9GWkJMSURtMHF2OUpXUFlm?= =?utf-8?B?NEYvenpQaGpRd25YQVV6RnE4dGEvOG8wS0V4SHNFSm5WbWNLWkRIRURYeHFs?= =?utf-8?B?MTJVVEhoY2pSdmFzY1JPMkg1TnlpUlJqUWZ4Uk1FZWQxOTE1UjZDOUloTWZy?= =?utf-8?B?bitoR2l4aW5jWVd0UVVQV0xtY25GdUNNSVRLeEhaTlNnVWtldnZVUWJHMm56?= =?utf-8?B?YldoR0NlUzRML0NqNDl5NFJaMWh4RkZZaHltWnBFd2lIdjRQQW1lMm9LZHFJ?= =?utf-8?B?c1FvcFlicUlQSDdZMmhqeWVKNXdSckZUd00vOFJ6Mm85QWVzSDVKdHZLMzJu?= =?utf-8?B?ZUhGU3VoZVBrOFNIalIvSkhXdFBTS0wvcUJrN1BBRVlzdm9aOFpqdFg0Z0lZ?= =?utf-8?B?eHo0VDljRDVJR1QrUXllUVhtRFRybWwwbHdBUjlUazhJaU9WbG4ycFdTaXpS?= =?utf-8?B?SGY0MkRZeTVmOEdIR1RNa2QySFVlSE53NzI2VE1nPT0=?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 977831cd-f3b8-4318-e8b9-08d8bc70694d X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2021 11:50:26.3650 (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: zEf4i4Ye5ObjJgXoxHHEkHMu7NwI6WPxwRfS+lGzq0rh4uxECyA468hwdppIETibvGdPibZq0+nuFncMUqnJlQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0135 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.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, 19 Jan 2021 11:50:35 -0000 --jp3EjbJpE0tGBYJxOyLLxNGLzQ6sXgacO Content-Type: multipart/mixed; boundary="JdrJAfKLJ5abR0X1dLmV51vh0hqLli0WH" --JdrJAfKLJ5abR0X1dLmV51vh0hqLli0WH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jon, Thanks, please see below some minor points, otherwise it looks good to me= =2E Best, /Marco * Section 3.1 - In the paragraph right above Table 2, s/with CoAP over TCP/with CoAP over reliable transports. * Section 3.1 - I think that the new final paragraph "Note that if Q-Block1 (or Q-Block2) ... MUST NOT be included." fits better before the paragraph discussing the use of OSCORE, i.e. "The Q-Block1 and ... fragmentation of requests." * Section 3.3 - "For Non-confirmable transmission, no response is required until the successful receipt of the body by the server or some of the payloads have not arrived after a timeout and a retransmit missing payloads response is needed." =C2=A0=C2=A0 Shouldn't this also mention the case where the server sends = a 2.31 response to have the client continue sending the next MAX_PAYLOADS payloa= ds? * Section 3.3 - Proposed clarification for the 4.02 response code: =C2=A0=C2=A0=C2=A0 "Either this Response Code (in case of Confirmable req= uest) or a reset message (in case of Non-confirmable request) MUST be returned if the server does not support the Q-Block1 Option." On 2021-01-18 15:16, supjps-ietf@jpshallow.com wrote: > Hi Marco, > > We have updated github [1] to take account of your latest comments for = your review. > > Regards > > Jon > > > [1]https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= www.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new-block%26url2%3Dhttps%= 3A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew-block%2Fmaster%2Fdraft-= ietf-core-new-block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C98040= 4e5b97a4f7d6a2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C= 637465761738775081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2= luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DuGB%2BGu0PztRvMh4= hUFutHMItkR5AJXCJqpt440nphj4%3D&reserved=3D0 > > >> -----Original Message----- >> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >> Sent: 15 January 2021 13:58 >> To: jon@jpshallow.com; mohamed.boucadair@orange.com; core@ietf.org >> Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org >> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt >> >> Hi Jon, >> >> On 2021-01-15 12:24, supjps-ietf@jpshallow.com wrote: >>> Hi Marco, >>> >>> Thanks from this. >>> >>> So moving forward, requests for missing Q-Block2 blocks will follow >>> Section 2.7 RFC7959 being modelled on (assuming the request was using= Q- >> Block1) " To continue this Block2 transfer, the client >>> continues to send requests similar to the requests in the Block1 >>> phase, but leaves out the Block1 Options and includes a Block2 >>> request option with non-zero NUM." >>> >>> Otherwise, please see inline which has a couple of questions. >>> >>> Regards >>> >>> Jon >>>> -----Original Message----- >>>> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >>>> Sent: 14 January 2021 19:58 >>>> To: mohamed.boucadair@orange.com; core@ietf.org >>>> Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org >>>> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt >>>> >>>> Hi Med, >>>> >>>> Thanks for the new document version. >>>> >>>> Please, see below some comments on the latest additions, also relate= d >>>> to what Jon raised at [1]. >>>> >>>> Best, >>>> /Marco >>>> >>>> [1] >>>> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= mai >>>> larchive.ietf.org%2Farch%2Fmsg%2Fcore%2FOrr8a1WlSu3Dk- >> gtPQZloDT9_1E%2 >> F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d >> 8b >> 948202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63746306674 >> 04024 >> 21%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL >> CJBTi >> I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DE4lIccwYQyVGHxxl9v9iBr70 >> hU6 >>>> BuxRrzAQoZHnZt%2B8%3D&reserved=3D0 >>>> >>>> >>>> * Section 3.5 - This seems to mix aspects specific to Observe, with >>>> more general aspects applicable to requests with a payload, i.e. >>>> FETCH (with or without Observe), PUT, POST and PATCH/iPATCH. >>> [Jon] Now that we understand what needs to be done with requesting mi= ssing >> Q-Block2 blocks, working with Observe can be simplified. >>> [Jon] Requesting Observe is only valid for GET and FETCH. Hence Obse= rve >> request/cancellation setting when using Q-Block1 is only appropriate f= or FETCH. >>> [Jon] Unfortunately, RFC8132 does not specify in which of the payloa= ds of as >> Block1 based FETCH request should contain the Observe option assuming= >> observe is required (The first, the last or all of the payloads). So, = here, I believe >> the safest way to go is with all the payloads carry the observe option= if observe >> is being requested or cancelled. Thus any missing payloads should be = resent with >> the observe configured to be consistent with all the other payloads. A= re you >> happy with this? >> >> =3D=3D>MT >> It makes sense to me. >> <=3D=3D >> >>>> What is specific of Observe is the first paragraph; and the usage >>>> of the Observe option in the second and third paragraph. Anything >>>> else seems generic and applicable to requests with payload, so it >>>> might be moved up to some earlier section. >>>> >>> [Jon] Sure - will be updated in the simplification tidy up. >>>> * Section 3.5 - In the third paragraph, I'm not sure you necessarily= >>>> need a payload to be present in the requests asking for missing >>>> response payloads. For instance, consider: >>> [Jon] Agreed. Now going with Section 2.7 RFC7959 where both Block1 a= nd >> payload are not included. >>>> - The examples in Figure 10 and Figure 11 of RFC 7959, with the >>>> note "(no payload for requests with Block2 with NUM !=3D 0)" , durin= g >>>> the phase where the client consecutively asks for the next response = payload. >>>> >>>> - The examples in Figure 2 and Figure 3 of [2], where each request= >>>> for the next response payload using Block2 has no payload of its own= =2E >>>> >>>> This would of course affect the example in Figure 15. >>> [Jon] Yes, will be updated. >>>> [2] >>>> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= too >>>> ls.ietf.org%2Fhtml%2Fdraft-ietf-ace-coap-est- >> 18&data=3D04%7C01%7Cma >> rco.tiloca%40ri.se%7Cf30167412cf14279616708d8b948202a%7C5a9809cf0bcb >> 4 >> 13a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7CUnknown%7CT >> WFpbGZs >> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >> %3 >> D%7C1000&sdata=3DcSOOuCBEP2jCRzECrJeLli6Z%2Bu%2FUlD%2F1HzVWIM7 >> O7%2B >>>> Q%3D&reserved=3D0 >>>> >>>> >>>> * Section 3.5 - About the last sentence regarding the Observe option= , >>>> there seems to be an exception to this rule (at least based on the >>>> later examples), where the server actually does include the Observe = option in >> the response. >>> [Jon] If the Observe option is just included with the first payload (= NUM =3D 0) as >> RFC7959, there is a recovery special case should the first payload not= arrive, but >> subsequent ones do. In the general case, blocks that are missing are = re- >> requested by the client and the server responds with the appropriate b= lock, but >> without the Observe option. For the special case when the client reque= sts >> missing payload with NUM =3D 0 the server needs to know that it must i= nclude the >> Observe in the response so that the client following the body re-assem= bly knows >> that it is a Observe triggered additional response. >>> [Jon] I had gone with the Observe should be in all the payloads in th= e response >> apart from specifically re-requested blocks (including NUM =3D 0). Th= e 'Continue' >> Q-Block2 was just to indicate a continue so the server can send the re= maining >> payloads without delay - hence why remaining payloads had Observe set.= >>> [Jon] I am beginning to lean to having it in the first payload and sp= ecial case >> the response to re-request of NUM =3D 0. What do you think? >> >> =3D=3D>MT >> Ok, I didn't think also of the case for NUM =3D 0, but that makes sens= e too. >> >> Then it's certainly something better to clarify in the main text and a= lso to >> show/comment in the example of Figure 10. >> <=3D=3D >> >>>> That is, consider the example in Figure 10, where the response >>>> with M:0xba is lost. Later on, the client asks for that response >>>> payload by sending the request with M:0x87, which correctly does not= include >> the Observe option. >>> [Jon] Yes >>>> However, the following response with M:oxc3 and (from the point o= f >>>> view of the server) retransmitting that response payload with block >>>> number 10 does include the Observe option. >>>> >>>> The exception seems due to the fact that the retransmission >>>> request from the client is specifically what you call 'Continue' >>>> Q-Block-2 in Section 3.4. The Observe option is in fact not included= >>>> for the previously retransmitted response payloads with M:0xbb ... M= :0xc2, >> as still part of the current payload set. >>> [Jon] Correct, but obviously not obvious from the text. >> =3D=3D>MT >> Right, I mostly focused on that. >> >> I think it's worth clarifying in the main text what the normal case is= for the server >> (client) to include (expect) the Observe option in a response payload;= and then >> highlight the exceptions for the re-request with NUM=3D0 (see above) a= nd for the >> 'Continue' Q-Block2. >> >> Best, >> /Marco >> <=3D=3D >> >>>> * Section 3.6 - Part of the first sentence in the second paragraph >>>> seems to repeat what already said in the third paragraph of Section = 3.5. >>>> >>> [Jon] Will clean up in the simplification. >>> ~Jon >> -- >> 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://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C980404e5b97a4f7d6a= 2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374657617387= 75081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI= 6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DLE%2FKQOOUq5aEBbgVRdtqmLiOz8n%= 2Bt60OuEYgM%2FwCrJg%3D&reserved=3D0 >> > --=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 --JdrJAfKLJ5abR0X1dLmV51vh0hqLli0WH-- --jp3EjbJpE0tGBYJxOyLLxNGLzQ6sXgacO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmAGx3gACgkQ7iZktA5Y 2kNSYQgAswuS3zzIR3mg0uEOtzmWqszybfRwO/BCoXpYVxjShyX69Y1SRl+uo5XL 5aDNxGa21LUiYfrqw1yRYtq+ApkKhJMSqBe6B2cH6U2V3I4/58CtCCBNvjb25+vk y2q7NWI4ttLHXZRow3yl9XnGzjPqiX8IfuHCOvaY2IUGuAKGw2/jR4o5b1GBDOKb 2qHoK/hCWBZrn5XZrPllr7cXvgVaAZpe3EakgvmVjeMefns1gxpkX673fCuuVW1W UrVIHJFFCI05mY03CLynkOTjJgYaOFnztXLGRkUsrfIDbSKvqul/dMXUHAioHyL7 xL1jaVeN/WPoWfcAyN7BP3XtYohmTw== =ChkD -----END PGP SIGNATURE----- --jp3EjbJpE0tGBYJxOyLLxNGLzQ6sXgacO-- From nobody Tue Jan 19 04:24:12 2021 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 216E03A1425; Tue, 19 Jan 2021 04:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 OtBSPhGlk86Z; Tue, 19 Jan 2021 04:24:05 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A463A140E; Tue, 19 Jan 2021 04:24:04 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4DKnrf2CT1z103D; Tue, 19 Jan 2021 13:24:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1611059042; bh=BokdKAvqhyOGTAWvuYhGZqIUBTpW1/tCK8NcPA10z0E=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=p2ksKPB+iJmwhWO9Ppmx5ppWPpHFx7MLeGAlEvgh8E0Sdq4Zbk/xyp7cXOKDNCnTK VyXILmjytTGYemhdA1o89KtbTUndjEdCOV6OxBd/WUCuQsrWpYBGJ9Z/yLxBr69CXD nQogAM4Qt4K/KFZ8xRqpG6k0VyjD890MhntN4dlZihgooP4hr4czNUmBewuz01PeoU 7ROOw0KJgabQT2cZy2ICI10wErwap1ArnWQWAVACH0MdkD3KN9BJn0E4ivvwv/Y1Td Q5OazPC4gi8NNN9y2PcSJif3zmYGrvhdyebJ8RGjRI0h0SITJheb1n8PltIJCw9MuC 0yRourc36wIvw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 4DKnrf1MVDz1xpr; Tue, 19 Jan 2021 13:24:02 +0100 (CET) From: To: Marco Tiloca , "supjps-ietf@jpshallow.com" , "core@ietf.org" CC: "draft-ietf-core-new-block@ietf.org" , "dots@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-new-block-05.txt Thread-Index: AQHW7llKlYyGci3BiUKLfs7WuizUBKou3GxA Date: Tue, 19 Jan 2021 12:24:01 +0000 Message-ID: <3017_1611059042_6006CF62_3017_76_1_787AE7BB302AE849A7480A190F8B9330315BCBD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> <4feb5743-4193-97f1-5231-038b1838b934@ri.se> <033b01d6eda4$8013a980$803afc80$@jpshallow.com> <5fc34721-6a91-39b9-5f8d-b58e6ec905f6@ri.se> In-Reply-To: <5fc34721-6a91-39b9-5f8d-b58e6ec905f6@ri.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.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, 19 Jan 2021 12:24:07 -0000 SGkgTWFyY28sIA0KDQpUaGUgcHJvcG9zZWQgZWRpdHMgbG9vayBnb29kIHRvIG1lLiBXaWxsIGJl IGZpeGVkIGluIHRoZSBnaXRodWIuIA0KDQoyLjMxIGlzIG5vdCBtZW50aW9uZWQgaW4gaW4gdGhl IGV4Y2VycHQgeW91IHF1b3RlZCBmcm9tIFNlY3Rpb24gMy4zIGJlY2F1c2UgMi4zMSBpcyBub3Qg KipyZXF1aXJlZCoqLiBBIHNlcnZlciBtYXkgZGVjaWRlIHRvIG5vdCByZXBseSB3aXRoIDIuMzEg YXMgYSBmdW5jdGlvbiBvZiBpdHMgb3ZlcmFsbCBsb2FkIGFuZCBwcmVmZXIgdG8gb2JzZXJ2ZSBh IHBhdXNlIGJlZm9yZSBoYW5kbGluZyB0aGUgbmV4dCBibG9jay4gVGhhdOKAmXMgaXMgd2h5IHdl IGRvIGhhdmUgU0hPVUxELCBub3QgYSBNVVNULiAgICANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IE1hcmNvIFRpbG9jYSBbbWFpbHRvOm1h cmNvLnRpbG9jYUByaS5zZV0NCj4gRW52b3nDqcKgOiBtYXJkaSAxOSBqYW52aWVyIDIwMjEgMTI6 NTANCj4gw4DCoDogc3VwanBzLWlldGZAanBzaGFsbG93LmNvbTsgQk9VQ0FEQUlSIE1vaGFtZWQg VEdJL09MTg0KPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGNvcmVAaWV0Zi5vcmcN Cj4gQ2PCoDogZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZzsgZG90c0BpZXRmLm9y Zw0KPiBPYmpldMKgOiBSZTogW2NvcmVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY29yZS1uZXct YmxvY2stMDUudHh0DQo+IA0KPiBIaSBKb24sDQo+IA0KPiBUaGFua3MsIHBsZWFzZSBzZWUgYmVs b3cgc29tZSBtaW5vciBwb2ludHMsIG90aGVyd2lzZSBpdCBsb29rcyBnb29kDQo+IHRvIG1lLg0K PiANCj4gQmVzdCwNCj4gL01hcmNvDQo+IA0KPiAqIFNlY3Rpb24gMy4xIC0gSW4gdGhlIHBhcmFn cmFwaCByaWdodCBhYm92ZSBUYWJsZSAyLCBzL3dpdGggQ29BUA0KPiBvdmVyIFRDUC93aXRoIENv QVAgb3ZlciByZWxpYWJsZSB0cmFuc3BvcnRzLg0KPiANCj4gKiBTZWN0aW9uIDMuMSAtIEkgdGhp bmsgdGhhdCB0aGUgbmV3IGZpbmFsIHBhcmFncmFwaCAiTm90ZSB0aGF0IGlmDQo+IFEtQmxvY2sx IChvciBRLUJsb2NrMikgLi4uIE1VU1QgTk9UIGJlIGluY2x1ZGVkLiIgZml0cyBiZXR0ZXIgYmVm b3JlDQo+IHRoZSBwYXJhZ3JhcGggZGlzY3Vzc2luZyB0aGUgdXNlIG9mIE9TQ09SRSwgaS5lLiAi VGhlIFEtQmxvY2sxIGFuZA0KPiAuLi4NCj4gZnJhZ21lbnRhdGlvbiBvZiByZXF1ZXN0cy4iDQo+ IA0KPiAqIFNlY3Rpb24gMy4zIC0gIkZvciBOb24tY29uZmlybWFibGUgdHJhbnNtaXNzaW9uLCBu byByZXNwb25zZSBpcw0KPiByZXF1aXJlZCB1bnRpbCB0aGUgc3VjY2Vzc2Z1bCByZWNlaXB0IG9m IHRoZSBib2R5IGJ5IHRoZSBzZXJ2ZXIgb3INCj4gc29tZSBvZiB0aGUgcGF5bG9hZHMgaGF2ZSBu b3QgYXJyaXZlZCBhZnRlciBhIHRpbWVvdXQgYW5kIGENCj4gcmV0cmFuc21pdCBtaXNzaW5nIHBh eWxvYWRzIHJlc3BvbnNlIGlzIG5lZWRlZC4iDQo+IA0KPiDCoMKgIFNob3VsZG4ndCB0aGlzIGFs c28gbWVudGlvbiB0aGUgY2FzZSB3aGVyZSB0aGUgc2VydmVyIHNlbmRzIGENCj4gMi4zMSByZXNw b25zZSB0byBoYXZlIHRoZSBjbGllbnQgY29udGludWUgc2VuZGluZyB0aGUgbmV4dA0KPiBNQVhf UEFZTE9BRFMgcGF5bG9hZHM/DQo+IA0KPiAqIFNlY3Rpb24gMy4zIC0gUHJvcG9zZWQgY2xhcmlm aWNhdGlvbiBmb3IgdGhlIDQuMDIgcmVzcG9uc2UgY29kZToNCj4gDQo+IMKgwqDCoCAiRWl0aGVy IHRoaXMgUmVzcG9uc2UgQ29kZSAoaW4gY2FzZSBvZiBDb25maXJtYWJsZSByZXF1ZXN0KSBvciBh DQo+IHJlc2V0IG1lc3NhZ2UgKGluIGNhc2Ugb2YgTm9uLWNvbmZpcm1hYmxlIHJlcXVlc3QpIE1V U1QgYmUgcmV0dXJuZWQNCj4gaWYgdGhlIHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IHRoZSBRLUJs b2NrMSBPcHRpb24uIg0KPiANCj4gDQo+IE9uIDIwMjEtMDEtMTggMTU6MTYsIHN1cGpwcy1pZXRm QGpwc2hhbGxvdy5jb20gd3JvdGU6DQo+ID4gSGkgTWFyY28sDQo+ID4NCj4gPiBXZSBoYXZlIHVw ZGF0ZWQgZ2l0aHViIFsxXSB0byB0YWtlIGFjY291bnQgb2YgeW91ciBsYXRlc3QgY29tbWVudHMN Cj4gZm9yIHlvdXIgcmV2aWV3Lg0KPiA+DQo+ID4gUmVnYXJkcw0KPiA+DQo+ID4gSm9uDQo+ID4N Cj4gPg0KPiA+DQo+IFsxXWh0dHBzOi8vZXVyMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyDQo+IEZ3DQo+ID4gd3cuaWV0Zi5vcmclMkZyZmNkaWZm JTNGdXJsMSUzRGRyYWZ0LWlldGYtY29yZS1uZXctDQo+IGJsb2NrJTI2dXJsMiUzRGh0dHANCj4g PiBzJTNBJTJGJTJGcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSUyRmNvcmUtd2clMkZuZXctDQo+ IGJsb2NrJTJGbWFzdGVyJTJGZA0KPiA+IHJhZnQtaWV0Zi1jb3JlLW5ldy0NCj4gYmxvY2sudHh0 JmFtcDtkYXRhPTA0JTdDMDElN0NtYXJjby50aWxvY2ElNDByaS5zZSU3DQo+ID4NCj4gQzk4MDQw NGU1Yjk3YTRmN2Q2YTI3MDhkOGJiYmI5YjA1JTdDNWE5ODA5Y2YwYmNiNDEzYTgzOGEwOWVjYzQw Y2M5ZTgNCj4gJTcNCj4gPg0KPiBDMCU3QzAlN0M2Mzc0NjU3NjE3Mzg3NzUwODElN0NVbmtub3du JTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBdw0KPiBNRA0KPiA+DQo+IEFpTENKUUlqb2lW Mmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPXVH DQo+IEIlDQo+ID4gMkJHdTBQenRSdk1oNGhVRnV0SE1JdGtSNUFKWENKcXB0NDQwbnBoajQlM0Qm YW1wO3Jlc2VydmVkPTANCj4gPg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4+IEZyb206IE1hcmNvIFRpbG9jYSBbbWFpbHRvOiBtYXJjby50aWxvY2FAcmkuc2VdDQo+ ID4+IFNlbnQ6IDE1IEphbnVhcnkgMjAyMSAxMzo1OA0KPiA+PiBUbzogam9uQGpwc2hhbGxvdy5j b207IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207DQo+IGNvcmVAaWV0Zi5vcmcNCj4gPj4g Q2M6IGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2tAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5vcmcNCj4g Pj4gU3ViamVjdDogUmU6IFtjb3JlXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNvcmUtbmV3LWJs b2NrLTA1LnR4dA0KPiA+Pg0KPiA+PiBIaSBKb24sDQo+ID4+DQo+ID4+IE9uIDIwMjEtMDEtMTUg MTI6MjQsIHN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20gd3JvdGU6DQo+ID4+PiBIaSBNYXJjbywN Cj4gPj4+DQo+ID4+PiBUaGFua3MgZnJvbSB0aGlzLg0KPiA+Pj4NCj4gPj4+IFNvIG1vdmluZyBm b3J3YXJkLCByZXF1ZXN0cyBmb3IgbWlzc2luZyBRLUJsb2NrMiBibG9ja3Mgd2lsbA0KPiBmb2xs b3cNCj4gPj4+IFNlY3Rpb24gMi43IFJGQzc5NTkgYmVpbmcgbW9kZWxsZWQgb24gKGFzc3VtaW5n IHRoZSByZXF1ZXN0IHdhcw0KPiA+Pj4gdXNpbmcgUS0NCj4gPj4gQmxvY2sxKSAiIFRvIGNvbnRp bnVlIHRoaXMgQmxvY2syIHRyYW5zZmVyLCB0aGUgY2xpZW50DQo+ID4+PiAgICBjb250aW51ZXMg dG8gc2VuZCByZXF1ZXN0cyBzaW1pbGFyIHRvIHRoZSByZXF1ZXN0cyBpbiB0aGUNCj4gQmxvY2sx DQo+ID4+PiAgICBwaGFzZSwgYnV0IGxlYXZlcyBvdXQgdGhlIEJsb2NrMSBPcHRpb25zIGFuZCBp bmNsdWRlcyBhDQo+IEJsb2NrMg0KPiA+Pj4gICAgcmVxdWVzdCBvcHRpb24gd2l0aCBub24temVy byBOVU0uIg0KPiA+Pj4NCj4gPj4+IE90aGVyd2lzZSwgcGxlYXNlIHNlZSBpbmxpbmUgd2hpY2gg aGFzIGEgY291cGxlIG9mIHF1ZXN0aW9ucy4NCj4gPj4+DQo+ID4+PiBSZWdhcmRzDQo+ID4+Pg0K PiA+Pj4gSm9uDQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9t OiBNYXJjbyBUaWxvY2EgW21haWx0bzogbWFyY28udGlsb2NhQHJpLnNlXQ0KPiA+Pj4+IFNlbnQ6 IDE0IEphbnVhcnkgMjAyMSAxOTo1OA0KPiA+Pj4+IFRvOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tOyBjb3JlQGlldGYub3JnDQo+ID4+Pj4gQ2M6IGRyYWZ0LWlldGYtY29yZS1uZXctYmxv Y2tAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5vcmcNCj4gPj4+PiBTdWJqZWN0OiBSZTogW2NvcmVdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stDQo+IDA1LnR4dA0KPiA+Pj4+DQo+ ID4+Pj4gSGkgTWVkLA0KPiA+Pj4+DQo+ID4+Pj4gVGhhbmtzIGZvciB0aGUgbmV3IGRvY3VtZW50 IHZlcnNpb24uDQo+ID4+Pj4NCj4gPj4+PiBQbGVhc2UsIHNlZSBiZWxvdyBzb21lIGNvbW1lbnRz IG9uIHRoZSBsYXRlc3QgYWRkaXRpb25zLCBhbHNvDQo+ID4+Pj4gcmVsYXRlZCB0byB3aGF0IEpv biByYWlzZWQgYXQgWzFdLg0KPiA+Pj4+DQo+ID4+Pj4gQmVzdCwNCj4gPj4+PiAvTWFyY28NCj4g Pj4+Pg0KPiA+Pj4+IFsxXQ0KPiA+Pj4+DQo+IGh0dHBzOi8vZXVyMDIuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRm0NCj4gPj4+PiBhaQ0KPiA+Pj4+ IGxhcmNoaXZlLmlldGYub3JnJTJGYXJjaCUyRm1zZyUyRmNvcmUlMkZPcnI4YTFXbFN1M0RrLQ0K PiA+PiBndFBRWmxvRFQ5XzFFJTINCj4gPj4NCj4gRiZhbXA7ZGF0YT0wNCU3QzAxJTdDbWFyY28u dGlsb2NhJTQwcmkuc2UlN0NmMzAxNjc0MTJjZjE0Mjc5NjE2NzA4ZA0KPiA+PiA4Yg0KPiA+PiA5 NDgyMDJhJTdDNWE5ODA5Y2YwYmNiNDEzYTgzOGEwOWVjYzQwY2M5ZTglN0MwJTdDMCU3QzYzNzQ2 MzA2Njc0DQo+ID4+IDA0MDI0DQo+ID4+IDIxJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJ am9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUwNCj4gPj4gQ0pCVGkNCj4gPj4NCj4gSTZJ azFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9RTRsSWNjd1lReVZHSHh4bDl2 OWlCcjcwDQo+ID4+IGhVNg0KPiA+Pj4+IEJ1eFJyekFRb1pIblp0JTJCOCUzRCZhbXA7cmVzZXJ2 ZWQ9MA0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiAqIFNlY3Rpb24gMy41IC0gVGhpcyBzZWVtcyB0 byBtaXggYXNwZWN0cyBzcGVjaWZpYyB0byBPYnNlcnZlLA0KPiB3aXRoDQo+ID4+Pj4gbW9yZSBn ZW5lcmFsIGFzcGVjdHMgYXBwbGljYWJsZSB0byByZXF1ZXN0cyB3aXRoIGEgcGF5bG9hZCwNCj4g aS5lLg0KPiA+Pj4+IEZFVENIICh3aXRoIG9yIHdpdGhvdXQgT2JzZXJ2ZSksIFBVVCwgUE9TVCBh bmQgUEFUQ0gvaVBBVENILg0KPiA+Pj4gW0pvbl0gTm93IHRoYXQgd2UgdW5kZXJzdGFuZCB3aGF0 IG5lZWRzIHRvIGJlIGRvbmUgd2l0aA0KPiByZXF1ZXN0aW5nDQo+ID4+PiBtaXNzaW5nDQo+ID4+ IFEtQmxvY2syIGJsb2Nrcywgd29ya2luZyB3aXRoIE9ic2VydmUgY2FuIGJlIHNpbXBsaWZpZWQu DQo+ID4+PiBbSm9uXSBSZXF1ZXN0aW5nIE9ic2VydmUgaXMgb25seSB2YWxpZCBmb3IgR0VUIGFu ZCBGRVRDSC4gIEhlbmNlDQo+ID4+PiBPYnNlcnZlDQo+ID4+IHJlcXVlc3QvY2FuY2VsbGF0aW9u IHNldHRpbmcgd2hlbiB1c2luZyBRLUJsb2NrMSBpcyBvbmx5DQo+IGFwcHJvcHJpYXRlIGZvciBG RVRDSC4NCj4gPj4+IFtKb25dICBVbmZvcnR1bmF0ZWx5LCBSRkM4MTMyIGRvZXMgbm90IHNwZWNp ZnkgaW4gd2hpY2ggb2YgdGhlDQo+ID4+PiBwYXlsb2FkcyBvZiBhcw0KPiA+PiBCbG9jazEgYmFz ZWQgRkVUQ0ggcmVxdWVzdCAgc2hvdWxkIGNvbnRhaW4gdGhlIE9ic2VydmUgb3B0aW9uDQo+ID4+ IGFzc3VtaW5nIG9ic2VydmUgaXMgcmVxdWlyZWQgKFRoZSBmaXJzdCwgdGhlIGxhc3Qgb3IgYWxs IG9mIHRoZQ0KPiA+PiBwYXlsb2FkcykuIFNvLCBoZXJlLCBJIGJlbGlldmUgdGhlIHNhZmVzdCB3 YXkgdG8gZ28gaXMgd2l0aCBhbGwNCj4gdGhlDQo+ID4+IHBheWxvYWRzIGNhcnJ5IHRoZSBvYnNl cnZlIG9wdGlvbiBpZiBvYnNlcnZlIGlzIGJlaW5nIHJlcXVlc3RlZA0KPiBvcg0KPiA+PiBjYW5j ZWxsZWQuICBUaHVzIGFueSBtaXNzaW5nIHBheWxvYWRzIHNob3VsZCBiZSByZXNlbnQgd2l0aCB0 aGUNCj4gPj4gb2JzZXJ2ZSBjb25maWd1cmVkIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCBhbGwgdGhl IG90aGVyIHBheWxvYWRzLg0KPiBBcmUgeW91IGhhcHB5IHdpdGggdGhpcz8NCj4gPj4NCj4gPj4g PT0+TVQNCj4gPj4gSXQgbWFrZXMgc2Vuc2UgdG8gbWUuDQo+ID4+IDw9PQ0KPiA+Pg0KPiA+Pj4+ ICAgV2hhdCBpcyBzcGVjaWZpYyBvZiBPYnNlcnZlIGlzIHRoZSBmaXJzdCBwYXJhZ3JhcGg7IGFu ZCB0aGUNCj4gdXNhZ2UNCj4gPj4+PiBvZiB0aGUgT2JzZXJ2ZSBvcHRpb24gaW4gdGhlIHNlY29u ZCBhbmQgdGhpcmQgcGFyYWdyYXBoLg0KPiBBbnl0aGluZw0KPiA+Pj4+IGVsc2Ugc2VlbXMgZ2Vu ZXJpYyBhbmQgYXBwbGljYWJsZSB0byByZXF1ZXN0cyB3aXRoIHBheWxvYWQsIHNvDQo+IGl0DQo+ ID4+Pj4gbWlnaHQgYmUgbW92ZWQgdXAgdG8gc29tZSBlYXJsaWVyIHNlY3Rpb24uDQo+ID4+Pj4N Cj4gPj4+IFtKb25dIFN1cmUgLSB3aWxsIGJlIHVwZGF0ZWQgaW4gdGhlIHNpbXBsaWZpY2F0aW9u IHRpZHkgdXAuDQo+ID4+Pj4gKiBTZWN0aW9uIDMuNSAtIEluIHRoZSB0aGlyZCBwYXJhZ3JhcGgs IEknbSBub3Qgc3VyZSB5b3UNCj4gPj4+PiBuZWNlc3NhcmlseSBuZWVkIGEgcGF5bG9hZCB0byBi ZSBwcmVzZW50IGluIHRoZSByZXF1ZXN0cyBhc2tpbmcNCj4gZm9yDQo+ID4+Pj4gbWlzc2luZyBy ZXNwb25zZSBwYXlsb2Fkcy4gRm9yIGluc3RhbmNlLCBjb25zaWRlcjoNCj4gPj4+IFtKb25dIEFn cmVlZC4gIE5vdyBnb2luZyB3aXRoIFNlY3Rpb24gMi43IFJGQzc5NTkgd2hlcmUgYm90aA0KPiBC bG9jazENCj4gPj4+IGFuZA0KPiA+PiBwYXlsb2FkIGFyZSBub3QgaW5jbHVkZWQuDQo+ID4+Pj4g ICAtIFRoZSBleGFtcGxlcyBpbiBGaWd1cmUgMTAgYW5kIEZpZ3VyZSAxMSBvZiBSRkMgNzk1OSwg d2l0aA0KPiB0aGUNCj4gPj4+PiBub3RlICIobm8gcGF5bG9hZCBmb3IgcmVxdWVzdHMgd2l0aCBC bG9jazIgd2l0aCBOVU0gIT0gMCkiICwNCj4gZHVyaW5nDQo+ID4+Pj4gdGhlIHBoYXNlIHdoZXJl IHRoZSBjbGllbnQgY29uc2VjdXRpdmVseSBhc2tzIGZvciB0aGUgbmV4dA0KPiByZXNwb25zZSBw YXlsb2FkLg0KPiA+Pj4+DQo+ID4+Pj4gICAtIFRoZSBleGFtcGxlcyBpbiBGaWd1cmUgMiBhbmQg RmlndXJlIDMgb2YgWzJdLCB3aGVyZSBlYWNoDQo+ID4+Pj4gcmVxdWVzdCBmb3IgdGhlIG5leHQg cmVzcG9uc2UgcGF5bG9hZCB1c2luZyBCbG9jazIgaGFzIG5vDQo+IHBheWxvYWQgb2YgaXRzIG93 bi4NCj4gPj4+Pg0KPiA+Pj4+IFRoaXMgd291bGQgb2YgY291cnNlIGFmZmVjdCB0aGUgZXhhbXBs ZSBpbiBGaWd1cmUgMTUuDQo+ID4+PiBbSm9uXSBZZXMsIHdpbGwgYmUgdXBkYXRlZC4NCj4gPj4+ PiBbMl0NCj4gPj4+Pg0KPiBodHRwczovL2V1cjAyLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0DQo+ID4+Pj4gb28NCj4gPj4+PiBscy5pZXRmLm9y ZyUyRmh0bWwlMkZkcmFmdC1pZXRmLWFjZS1jb2FwLWVzdC0NCj4gPj4gMTgmYW1wO2RhdGE9MDQl N0MwMSU3Q21hDQo+ID4+DQo+IHJjby50aWxvY2ElNDByaS5zZSU3Q2YzMDE2NzQxMmNmMTQyNzk2 MTY3MDhkOGI5NDgyMDJhJTdDNWE5ODA5Y2YwYmNiDQo+ID4+IDQNCj4gPj4gMTNhODM4YTA5ZWNj NDBjYzllOCU3QzAlN0MwJTdDNjM3NDYzMDY2NzQwNDAyNDIxJTdDVW5rbm93biU3Q1QNCj4gPj4g V0ZwYkdacw0KPiA+Pg0KPiBiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklp TENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wDQo+ID4+ICUzDQo+ID4+IEQlN0MxMDAwJmFtcDtz ZGF0YT1jU09PdUNCRVAyakNSekVDckplTGxpNlolMkJ1JTJGVWxEJTJGMUh6VldJTTcNCj4gPj4g TzclMkINCj4gPj4+PiBRJTNEJmFtcDtyZXNlcnZlZD0wDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+ ICogU2VjdGlvbiAzLjUgLSBBYm91dCB0aGUgbGFzdCBzZW50ZW5jZSByZWdhcmRpbmcgdGhlIE9i c2VydmUNCj4gPj4+PiBvcHRpb24sIHRoZXJlIHNlZW1zIHRvIGJlIGFuIGV4Y2VwdGlvbiB0byB0 aGlzIHJ1bGUgKGF0IGxlYXN0DQo+IGJhc2VkDQo+ID4+Pj4gb24gdGhlIGxhdGVyIGV4YW1wbGVz KSwgd2hlcmUgdGhlIHNlcnZlciBhY3R1YWxseSBkb2VzIGluY2x1ZGUNCj4gdGhlDQo+ID4+Pj4g T2JzZXJ2ZSBvcHRpb24gaW4NCj4gPj4gdGhlIHJlc3BvbnNlLg0KPiA+Pj4gW0pvbl0gSWYgdGhl IE9ic2VydmUgb3B0aW9uIGlzIGp1c3QgaW5jbHVkZWQgd2l0aCB0aGUgZmlyc3QNCj4gcGF5bG9h ZA0KPiA+Pj4gKE5VTSA9IDApIGFzDQo+ID4+IFJGQzc5NTksIHRoZXJlIGlzIGEgcmVjb3Zlcnkg c3BlY2lhbCBjYXNlIHNob3VsZCB0aGUgZmlyc3QNCj4gcGF5bG9hZA0KPiA+PiBub3QgYXJyaXZl LCBidXQgc3Vic2VxdWVudCBvbmVzIGRvLiAgSW4gdGhlIGdlbmVyYWwgY2FzZSwgYmxvY2tzDQo+ IHRoYXQNCj4gPj4gYXJlIG1pc3NpbmcgYXJlIHJlLSByZXF1ZXN0ZWQgYnkgdGhlIGNsaWVudCBh bmQgdGhlIHNlcnZlcg0KPiByZXNwb25kcw0KPiA+PiB3aXRoIHRoZSBhcHByb3ByaWF0ZSBibG9j aywgYnV0IHdpdGhvdXQgdGhlIE9ic2VydmUgb3B0aW9uLiBGb3INCj4gdGhlDQo+ID4+IHNwZWNp YWwgY2FzZSB3aGVuIHRoZSBjbGllbnQgcmVxdWVzdHMgbWlzc2luZyBwYXlsb2FkIHdpdGggTlVN ID0NCj4gMA0KPiA+PiB0aGUgc2VydmVyIG5lZWRzIHRvIGtub3cgdGhhdCBpdCBtdXN0IGluY2x1 ZGUgdGhlIE9ic2VydmUgaW4gdGhlDQo+ID4+IHJlc3BvbnNlIHNvIHRoYXQgdGhlIGNsaWVudCBm b2xsb3dpbmcgdGhlIGJvZHkgcmUtYXNzZW1ibHkga25vd3MNCj4gdGhhdCBpdCBpcyBhIE9ic2Vy dmUgdHJpZ2dlcmVkIGFkZGl0aW9uYWwgcmVzcG9uc2UuDQo+ID4+PiBbSm9uXSBJIGhhZCBnb25l IHdpdGggdGhlIE9ic2VydmUgc2hvdWxkIGJlIGluIGFsbCB0aGUgcGF5bG9hZHMNCj4gaW4NCj4g Pj4+IHRoZSByZXNwb25zZQ0KPiA+PiBhcGFydCBmcm9tIHNwZWNpZmljYWxseSByZS1yZXF1ZXN0 ZWQgYmxvY2tzIChpbmNsdWRpbmcgTlVNID0gMCkuDQo+IFRoZSAnQ29udGludWUnDQo+ID4+IFEt QmxvY2syIHdhcyBqdXN0IHRvIGluZGljYXRlIGEgY29udGludWUgc28gdGhlIHNlcnZlciBjYW4g c2VuZA0KPiB0aGUNCj4gPj4gcmVtYWluaW5nIHBheWxvYWRzIHdpdGhvdXQgZGVsYXkgLSBoZW5j ZSB3aHkgcmVtYWluaW5nIHBheWxvYWRzDQo+IGhhZCBPYnNlcnZlIHNldC4NCj4gPj4+IFtKb25d IEkgYW0gYmVnaW5uaW5nIHRvIGxlYW4gdG8gaGF2aW5nIGl0IGluIHRoZSBmaXJzdCBwYXlsb2Fk DQo+IGFuZA0KPiA+Pj4gc3BlY2lhbCBjYXNlDQo+ID4+IHRoZSByZXNwb25zZSB0byByZS1yZXF1 ZXN0IG9mIE5VTSA9IDAuICBXaGF0IGRvIHlvdSB0aGluaz8NCj4gPj4NCj4gPj4gPT0+TVQNCj4g Pj4gT2ssIEkgZGlkbid0IHRoaW5rIGFsc28gb2YgdGhlIGNhc2UgZm9yIE5VTSA9IDAsIGJ1dCB0 aGF0IG1ha2VzDQo+IHNlbnNlIHRvby4NCj4gPj4NCj4gPj4gVGhlbiBpdCdzIGNlcnRhaW5seSBz b21ldGhpbmcgYmV0dGVyIHRvIGNsYXJpZnkgaW4gdGhlIG1haW4gdGV4dA0KPiBhbmQNCj4gPj4g YWxzbyB0byBzaG93L2NvbW1lbnQgaW4gdGhlIGV4YW1wbGUgb2YgRmlndXJlIDEwLg0KPiA+PiA8 PT0NCj4gPj4NCj4gPj4+PiAgICBUaGF0IGlzLCBjb25zaWRlciB0aGUgZXhhbXBsZSBpbiBGaWd1 cmUgMTAsIHdoZXJlIHRoZQ0KPiByZXNwb25zZQ0KPiA+Pj4+IHdpdGggTToweGJhIGlzIGxvc3Qu IExhdGVyIG9uLCB0aGUgY2xpZW50IGFza3MgZm9yIHRoYXQNCj4gcmVzcG9uc2UNCj4gPj4+PiBw YXlsb2FkIGJ5IHNlbmRpbmcgdGhlIHJlcXVlc3Qgd2l0aCBNOjB4ODcsIHdoaWNoIGNvcnJlY3Rs eQ0KPiBkb2VzDQo+ID4+Pj4gbm90IGluY2x1ZGUNCj4gPj4gdGhlIE9ic2VydmUgb3B0aW9uLg0K PiA+Pj4gW0pvbl0gWWVzDQo+ID4+Pj4gICAgSG93ZXZlciwgdGhlIGZvbGxvd2luZyByZXNwb25z ZSB3aXRoIE06b3hjMyBhbmQgKGZyb20gdGhlDQo+IHBvaW50DQo+ID4+Pj4gb2YgdmlldyBvZiB0 aGUgc2VydmVyKSByZXRyYW5zbWl0dGluZyB0aGF0IHJlc3BvbnNlIHBheWxvYWQNCj4gd2l0aA0K PiA+Pj4+IGJsb2NrIG51bWJlciAxMCBkb2VzIGluY2x1ZGUgdGhlIE9ic2VydmUgb3B0aW9uLg0K PiA+Pj4+DQo+ID4+Pj4gICAgVGhlIGV4Y2VwdGlvbiBzZWVtcyBkdWUgdG8gdGhlIGZhY3QgdGhh dCB0aGUgcmV0cmFuc21pc3Npb24NCj4gPj4+PiByZXF1ZXN0IGZyb20gdGhlIGNsaWVudCBpcyBz cGVjaWZpY2FsbHkgd2hhdCB5b3UgY2FsbA0KPiAnQ29udGludWUnDQo+ID4+Pj4gUS1CbG9jay0y IGluIFNlY3Rpb24gMy40LiBUaGUgT2JzZXJ2ZSBvcHRpb24gaXMgaW4gZmFjdCBub3QNCj4gPj4+ PiBpbmNsdWRlZCBmb3IgdGhlIHByZXZpb3VzbHkgcmV0cmFuc21pdHRlZCByZXNwb25zZSBwYXls b2Fkcw0KPiB3aXRoDQo+ID4+Pj4gTToweGJiIC4uLiBNOjB4YzIsDQo+ID4+IGFzIHN0aWxsIHBh cnQgb2YgdGhlIGN1cnJlbnQgcGF5bG9hZCBzZXQuDQo+ID4+PiBbSm9uXSBDb3JyZWN0LCBidXQg b2J2aW91c2x5IG5vdCBvYnZpb3VzIGZyb20gdGhlIHRleHQuDQo+ID4+ID09Pk1UDQo+ID4+IFJp Z2h0LCBJIG1vc3RseSBmb2N1c2VkIG9uIHRoYXQuDQo+ID4+DQo+ID4+IEkgdGhpbmsgaXQncyB3 b3J0aCBjbGFyaWZ5aW5nIGluIHRoZSBtYWluIHRleHQgd2hhdCB0aGUgbm9ybWFsDQo+IGNhc2UN Cj4gPj4gaXMgZm9yIHRoZSBzZXJ2ZXINCj4gPj4gKGNsaWVudCkgdG8gaW5jbHVkZSAoZXhwZWN0 KSB0aGUgT2JzZXJ2ZSBvcHRpb24gaW4gYSByZXNwb25zZQ0KPiA+PiBwYXlsb2FkOyBhbmQgdGhl biBoaWdobGlnaHQgdGhlIGV4Y2VwdGlvbnMgZm9yIHRoZSByZS1yZXF1ZXN0DQo+IHdpdGgNCj4g Pj4gTlVNPTAgKHNlZSBhYm92ZSkgYW5kIGZvciB0aGUgJ0NvbnRpbnVlJyBRLUJsb2NrMi4NCj4g Pj4NCj4gPj4gQmVzdCwNCj4gPj4gL01hcmNvDQo+ID4+IDw9PQ0KPiA+Pg0KPiA+Pj4+ICogU2Vj dGlvbiAzLjYgLSBQYXJ0IG9mIHRoZSBmaXJzdCBzZW50ZW5jZSBpbiB0aGUgc2Vjb25kDQo+IHBh cmFncmFwaA0KPiA+Pj4+IHNlZW1zIHRvIHJlcGVhdCB3aGF0IGFscmVhZHkgc2FpZCBpbiB0aGUg dGhpcmQgcGFyYWdyYXBoIG9mDQo+IFNlY3Rpb24gMy41Lg0KPiA+Pj4+DQo+ID4+PiBbSm9uXSBX aWxsIGNsZWFuIHVwIGluIHRoZSBzaW1wbGlmaWNhdGlvbi4NCj4gPj4+IH5Kb24NCj4gPj4gLS0N Cj4gPj4gTWFyY28gVGlsb2NhDQo+ID4+IFBoLkQuLCBTZW5pb3IgUmVzZWFyY2hlcg0KPiA+Pg0K PiA+PiBSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuDQo+ID4+IERpdmlzaW9uIElD VA0KPiA+PiBJc2Fmam9yZHNnYXRhbiAyMiAvIEtpc3RhZ8OlbmdlbiAxNg0KPiA+PiBTRS0xNjQg NDAgS2lzdGEgKFN3ZWRlbikNCj4gPj4NCj4gPj4gUGhvbmU6ICs0NiAoMCk3MCA2MCA0NiA1MDEN Cj4gPj4NCj4gaHR0cHM6Ly9ldXIwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGd3cNCj4gdw0KPiA+Pg0KPiAucmkuc2UlMkYmYW1wO2RhdGE9MDQl N0MwMSU3Q21hcmNvLnRpbG9jYSU0MHJpLnNlJTdDOTgwNDA0ZTViOTdhNGY3ZA0KPiA2DQo+ID4+ DQo+IGEyNzA4ZDhiYmJiOWIwNSU3QzVhOTgwOWNmMGJjYjQxM2E4MzhhMDllY2M0MGNjOWU4JTdD MCU3QzAlN0M2Mzc0NjU3DQo+IDYNCj4gPj4NCj4gMTczODc3NTA4MSU3Q1Vua25vd24lN0NUV0Zw Ykdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU0NCj4geg0KPiA+Pg0KPiBJ aUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPUxFJTJGS1FP T1VxNWFFQmJnVg0KPiBSDQo+ID4+IGR0cW1MaU96OG4lMkJ0NjBPdUVZZ00lMkZ3Q3JKZyUzRCZh bXA7cmVzZXJ2ZWQ9MA0KPiA+Pg0KPiA+DQo+IA0KPiAtLQ0KPiBNYXJjbyBUaWxvY2ENCj4gUGgu RC4sIFNlbmlvciBSZXNlYXJjaGVyDQo+IA0KPiBSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2Yg U3dlZGVuDQo+IERpdmlzaW9uIElDVA0KPiBJc2Fmam9yZHNnYXRhbiAyMiAvIEtpc3RhZ8Olbmdl biAxNg0KPiBTRS0xNjQgNDAgS2lzdGEgKFN3ZWRlbikNCj4gDQo+IFBob25lOiArNDYgKDApNzAg NjAgNDYgNTAxDQo+IGh0dHBzOi8vd3d3LnJpLnNlDQo+IA0KDQoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBl dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2 b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy CmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy YXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5v dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3Uu Cgo= From nobody Tue Jan 19 06:10:12 2021 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 500F63A151B; Tue, 19 Jan 2021 06:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 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.262, 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 FDEbq55iUHIG; Tue, 19 Jan 2021 06:10:02 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140042.outbound.protection.outlook.com [40.107.14.42]) (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 447B23A151A; Tue, 19 Jan 2021 06:10:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q3keTZ29EZSj+e36mtBYS2VzmW5InxtMMiK/OFIHc2CL3vzNG2REY8wifp8HkRB9fR2OLdqBWQazN4B5z2L1hdON+aOtmg4Ds+uc8JDE+SYhzApJmE4YlQG6g+cX6BEQdin+iH42o9G/fFl6AyhkPfm1/Lp0Lq4VPg3D1tlKNF6yr8tbcM7cR2DFSlKBTuH8r0TOqwWmPL9WWfauK2mCmQfbFglxLB5QyQ62+7qKTslRhIPI/dpYWiBA5J4DJy3MGwfY/4P/cugth0DZNAAnA0/3c//JYhcHMqaKs/eWxOezSKZMExEyM/iAQGFRLtIsNe4gRlc0VbxtMW/cXsYEgA== 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=7Dx2St47nNbUmZLZSLX3SSDqNeIi9nN/5XUMRjQvA4o=; b=k4za+Zi1ZFrcTzPRtZ8cacID+JzB4baTQIeTt7C+pTB2Kl9VMX5yFh7JNFRTIMYnVyU+QtyPpWwo8M/aggG/L344M3F6X1y5YVAHqIYRtI2Brjx10m7ZJJqnM9dyMSCQtgrI6mewf0lZBiXtKJS3q8ioGiwRyEO2DWWpwrkgZyNXY92EsH0A0uv0+4xvzh54pONIAwAuIEeQ6eJd6L/DL1jKLqb3ZjqZbDsZjfjuUSCGyn/ycBGOXvGmPk0AUF3FhuDymdGpUtAU+e7H1mxc2ya8QpoAy5mypgnv2SZYKdenhdudJgqQeNaAxttyqxiU3JPUCjxMmDAdBw9zARlVYQ== 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=7Dx2St47nNbUmZLZSLX3SSDqNeIi9nN/5XUMRjQvA4o=; b=AA+r4VmAvTr9Iu8DVfLy7KmGo02dfG1oFGZKT+X5ZKJ5tlk7Mfnt/phrJLAuUzIuYCZVIFs6ir8p1tg1ir52sllPjXRw/ncdSWPMq5DBoMuK7k3ueWYx+MZXRif1vfvC/eLn0GY5lSgSPZJRLLz+7xH7uNHUDb9FsnO24Yq2Z7o= 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 DB8P189MB1080.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.11; Tue, 19 Jan 2021 14:09:54 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3763.014; Tue, 19 Jan 2021 14:09:54 +0000 To: mohamed.boucadair@orange.com, "supjps-ietf@jpshallow.com" , "core@ietf.org" Cc: "draft-ietf-core-new-block@ietf.org" , "dots@ietf.org" References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> <4feb5743-4193-97f1-5231-038b1838b934@ri.se> <033b01d6eda4$8013a980$803afc80$@jpshallow.com> <5fc34721-6a91-39b9-5f8d-b58e6ec905f6@ri.se> <3017_1611059042_6006CF62_3017_76_1_787AE7BB302AE849A7480A190F8B9330315BCBD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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: Tue, 19 Jan 2021 15:09:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <3017_1611059042_6006CF62_3017_76_1_787AE7BB302AE849A7480A190F8B9330315BCBD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JjlH2quIbwmAnOkJzWEChCT8sqHmkOuic" X-Originating-IP: [37.120.209.212] 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.2.7] (37.120.209.212) 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.3784.11 via Frontend Transport; Tue, 19 Jan 2021 14:09:53 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c82628d3-253c-4ab2-022a-08d8bc83e4ee X-MS-TrafficTypeDiagnostic: DB8P189MB1080: 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: pk6XJU1fDKFg+IErAh3KrWGPjyiq5fV8Q0LlxBkHHsvm9Z7opY1aq85bx8/KUaVKUf4Kn+65U5XgLJ3pypMfwsSpjIM9SfecaJ32kFye0uvuyOnY4SfsX7LRMEzQMym+Orpt4IljUo58mg6mpAOxwks+yOw0Papi6SDCh4+c2r9tjWhsag5ilbvtSGjBE7YWEppkuvvKjgEpn5sllTyGmqzpcm6jP3GpTcCJr80HSgndnBaD8U6bP52fz5m3cv+6N9YVPms7q0JsQEAqHDFEyEtZOh+pKlqovzpSlbRB33zFFxTcy6AavzVH5joWobrRY2WtnW5TXzkC4tuTn4bZ7ZEeSBBI9ZPh2YQ+Mcehd1qO58k2DrO+tKN1TzfaOd5+lW+ICOzQCrppGtEfCyxfBRSOTZ+f6+6WG43lLqbA3GyTqVj63gUFbeLEnI2JtMEXjBR7nD2pyen5W96ux8SjRecMIPdpBUqhhN1EjIClKK7OKRlc+lteeXFVWS81bSFQ5GykA/J7wKxcEHIdd9JrAPoTZOK2bfPt2/EnzocS1A4TvaNCdN80QcNe4rU+yDKx 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)(376002)(136003)(39840400004)(366004)(6486002)(31696002)(2906002)(52116002)(21480400003)(30864003)(44832011)(16576012)(110136005)(316002)(54906003)(5660300002)(45080400002)(478600001)(31686004)(8676002)(4326008)(966005)(235185007)(186003)(956004)(66574015)(66556008)(6666004)(16526019)(26005)(66476007)(86362001)(36756003)(33964004)(8936002)(53546011)(2616005)(66946007)(83380400001)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?cEZoWHlxdW9GZXdWV1U0eE1NYVJmSEQyQW1YOVM5bHVIYmZUblBBM290TDlq?= =?utf-8?B?ZktWckdvMzQ1RlZxNHI4aG1USjh4cWlySzMrZm5CQW05WWZJZ1UvNERkRjZP?= =?utf-8?B?c0dseDNIUW9sY1B6bElLRmtxZnBHR1NEbVBtZEx4bWd1eTFWMGZOYmh1OENB?= =?utf-8?B?MHJ4NkNDQUd3QnhhZ1drZkVXaUF5SDdlU2lkZkY0MlpKTXJTL214QW4xL3Yw?= =?utf-8?B?b3JiZDZKTi9UM1pDVm9GYUcxWWlvcEdTSndiMldNb2hhVFZOSGp4M2RUTW1K?= =?utf-8?B?K29Bd0FZT2NyZWVrOUErZVhCSjg4MFpmRFpHZVhtbDdmNnpGbmU4UDhtV21q?= =?utf-8?B?K29Qalp4aGg2T21mK3dSbnZvb2lJNVZqeEZQTCtNRFNOQmVPbDYrNmFpemVp?= =?utf-8?B?czMxRG02ODVWVm9MbGJJb08vd0p5ZWZnd1E0UUZDNjRMWFNQY1FuOHVnajlK?= =?utf-8?B?MTlKUUthYzF3UXlwSmpsL1ljMXh5Qjc3Kzc4M3NYNzVDVDM1cDVQWEs2UzdY?= =?utf-8?B?ZnRoU285Sm5uUzVCcHBTTk5uNTREQ3gyeFNGeWV5dHdJZm5tNytHVU5wZHRu?= =?utf-8?B?OHhNMDVWZEpCeHBFdk5sdGkySStib2V1SXBXdVV1RUlGbElwL3hmMDRPbWQ1?= =?utf-8?B?RWZYQlhsUHB1Z3F2M0V5WGI3dHBPTVF0bEhPR3RUZjJwa28rYnlTaEhNZHl3?= =?utf-8?B?ZGx5TVpHZ3hZdnBOZDRUNUFody9yU21oQXFncUFDNUV4ZXUzR3dUbmJ2WUNW?= =?utf-8?B?Z1h2RVkybE5nSExDWnNIWnJRNUQ0ZVp0NWFYSjdLV3h2eURwWFRNM3JGUHZp?= =?utf-8?B?Y25PbEhydC80OW1Nb2V4TVJpcUxVN3NTOGdSd0dKY2pjYjQ2Z2l6RnJSdUEx?= =?utf-8?B?N3RGQiszdE1MOGtFY2dkTEttR25MS3ZXWnhtdDJXVnMxdGZycUJaaE14V3hh?= =?utf-8?B?OXZ6T3F1U3BiNUNZalhpUGY3alh5T2pyWUJNZE5TTC9YeWVOU3FLSXdKUkRH?= =?utf-8?B?MFFUTVUvbTF4QXdiT1hFaWZhc0FONktnbnkvTlVDWjFwS0Zqak1MZFNSVDNU?= =?utf-8?B?TGRsYnJ6TkFReCs2UTlOc2lwOW5qU3lqcmRvR0lFVjFHYlBkd0JEalR0TkZ5?= =?utf-8?B?cUpGbkFvaEhHRE5YcHhLMFZJRnNIc3djYjM1MlU2MzdUcndEUHR0NjJaM1Vw?= =?utf-8?B?N0dod21tM1pJbis1TFhUNmx0bDMvV0tBZzIrV0xPVUNlbkJwa2FtQkNTZ3A1?= =?utf-8?B?UzBRWHFFU0FyRXFSRnl5blZkd2w5QVFvWm01dWlqZUd1TTdES2NtR0IyTkVV?= =?utf-8?B?VFhuYUk3dk1tZHBPcVRsYnpvdzJ2ZEREcElFNnBOUVZ3Sk4xLzZjN3RZQ0dt?= =?utf-8?B?dHZveW1kR1JndlBET1Nxa1Z1by9LOUZMc2kxNnpOb01COFhiRjA2QlBHVnFN?= =?utf-8?Q?Wlhtu09C?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: c82628d3-253c-4ab2-022a-08d8bc83e4ee X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2021 14:09:54.2756 (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: WbWxjTtSWFD+TdkGavyRvjn7qi6fNBeHlA6N+C/5YZfl4uRktOsONuRpchtxPGed1n8FE5Jn/ZigSQiWayeuFA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB1080 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.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, 19 Jan 2021 14:10:06 -0000 --JjlH2quIbwmAnOkJzWEChCT8sqHmkOuic Content-Type: multipart/mixed; boundary="LGEEhWQZN5PxIGxBMw1EEjciIUGhrkI50" --LGEEhWQZN5PxIGxBMw1EEjciIUGhrkI50 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Got it, thanks. Best, /Marco On 2021-01-19 13:24, mohamed.boucadair@orange.com wrote: > Hi Marco,=20 > > The proposed edits look good to me. Will be fixed in the github.=20 > > 2.31 is not mentioned in in the excerpt you quoted from Section 3.3 bec= ause 2.31 is not **required**. A server may decide to not reply with 2.31= as a function of its overall load and prefer to observe a pause before h= andling the next block. That=E2=80=99s is why we do have SHOULD, not a MU= ST. =20 > > Cheers, > Med > >> -----Message d'origine----- >> De=C2=A0: Marco Tiloca [mailto:marco.tiloca@ri.se] >> Envoy=C3=A9=C2=A0: mardi 19 janvier 2021 12:50 >> =C3=80=C2=A0: supjps-ietf@jpshallow.com; BOUCADAIR Mohamed TGI/OLN >> ; core@ietf.org >> Cc=C2=A0: draft-ietf-core-new-block@ietf.org; dots@ietf.org >> Objet=C2=A0: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt >> >> Hi Jon, >> >> Thanks, please see below some minor points, otherwise it looks good >> to me. >> >> Best, >> /Marco >> >> * Section 3.1 - In the paragraph right above Table 2, s/with CoAP >> over TCP/with CoAP over reliable transports. >> >> * Section 3.1 - I think that the new final paragraph "Note that if >> Q-Block1 (or Q-Block2) ... MUST NOT be included." fits better before >> the paragraph discussing the use of OSCORE, i.e. "The Q-Block1 and >> ... >> fragmentation of requests." >> >> * Section 3.3 - "For Non-confirmable transmission, no response is >> required until the successful receipt of the body by the server or >> some of the payloads have not arrived after a timeout and a >> retransmit missing payloads response is needed." >> >> =C2=A0=C2=A0 Shouldn't this also mention the case where the server sen= ds a >> 2.31 response to have the client continue sending the next >> MAX_PAYLOADS payloads? >> >> * Section 3.3 - Proposed clarification for the 4.02 response code: >> >> =C2=A0=C2=A0=C2=A0 "Either this Response Code (in case of Confirmable = request) or a >> reset message (in case of Non-confirmable request) MUST be returned >> if the server does not support the Q-Block1 Option." >> >> >> On 2021-01-18 15:16, supjps-ietf@jpshallow.com wrote: >>> Hi Marco, >>> >>> We have updated github [1] to take account of your latest comments >> for your review. >>> Regards >>> >>> Jon >>> >>> >>> >> [1]https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= 52 >> Fw >>> ww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new- >> block%26url2%3Dhttp >>> s%3A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew- >> block%2Fmaster%2Fd >>> raft-ietf-core-new- >> block.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7 >> C980404e5b97a4f7d6a2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8 >> %7 >> C0%7C0%7C637465761738775081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw >> MD >> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DuG= >> B% >>> 2BGu0PztRvMh4hUFutHMItkR5AJXCJqpt440nphj4%3D&reserved=3D0 >>> >>> >>>> -----Original Message----- >>>> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >>>> Sent: 15 January 2021 13:58 >>>> To: jon@jpshallow.com; mohamed.boucadair@orange.com; >> core@ietf.org >>>> Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org >>>> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt >>>> >>>> Hi Jon, >>>> >>>> On 2021-01-15 12:24, supjps-ietf@jpshallow.com wrote: >>>>> Hi Marco, >>>>> >>>>> Thanks from this. >>>>> >>>>> So moving forward, requests for missing Q-Block2 blocks will >> follow >>>>> Section 2.7 RFC7959 being modelled on (assuming the request was >>>>> using Q- >>>> Block1) " To continue this Block2 transfer, the client >>>>> continues to send requests similar to the requests in the >> Block1 >>>>> phase, but leaves out the Block1 Options and includes a >> Block2 >>>>> request option with non-zero NUM." >>>>> >>>>> Otherwise, please see inline which has a couple of questions. >>>>> >>>>> Regards >>>>> >>>>> Jon >>>>>> -----Original Message----- >>>>>> From: Marco Tiloca [mailto: marco.tiloca@ri.se] >>>>>> Sent: 14 January 2021 19:58 >>>>>> To: mohamed.boucadair@orange.com; core@ietf.org >>>>>> Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org >>>>>> Subject: Re: [core] I-D Action: draft-ietf-core-new-block- >> 05.txt >>>>>> Hi Med, >>>>>> >>>>>> Thanks for the new document version. >>>>>> >>>>>> Please, see below some comments on the latest additions, also >>>>>> related to what Jon raised at [1]. >>>>>> >>>>>> Best, >>>>>> /Marco >>>>>> >>>>>> [1] >>>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fm >>>>>> ai >>>>>> larchive.ietf.org%2Farch%2Fmsg%2Fcore%2FOrr8a1WlSu3Dk- >>>> gtPQZloDT9_1E%2 >>>> >> F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d >>>> 8b >>>> 948202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63746306674 >>>> 04024 >>>> 21%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL >>>> CJBTi >>>> >> I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DE4lIccwYQyVGHxxl9v9iBr70 >>>> hU6 >>>>>> BuxRrzAQoZHnZt%2B8%3D&reserved=3D0 >>>>>> >>>>>> >>>>>> * Section 3.5 - This seems to mix aspects specific to Observe, >> with >>>>>> more general aspects applicable to requests with a payload, >> i.e. >>>>>> FETCH (with or without Observe), PUT, POST and PATCH/iPATCH. >>>>> [Jon] Now that we understand what needs to be done with >> requesting >>>>> missing >>>> Q-Block2 blocks, working with Observe can be simplified. >>>>> [Jon] Requesting Observe is only valid for GET and FETCH. Hence >>>>> Observe >>>> request/cancellation setting when using Q-Block1 is only >> appropriate for FETCH. >>>>> [Jon] Unfortunately, RFC8132 does not specify in which of the >>>>> payloads of as >>>> Block1 based FETCH request should contain the Observe option >>>> assuming observe is required (The first, the last or all of the >>>> payloads). So, here, I believe the safest way to go is with all >> the >>>> payloads carry the observe option if observe is being requested >> or >>>> cancelled. Thus any missing payloads should be resent with the >>>> observe configured to be consistent with all the other payloads. >> Are you happy with this? >>>> =3D=3D>MT >>>> It makes sense to me. >>>> <=3D=3D >>>> >>>>>> What is specific of Observe is the first paragraph; and the >> usage >>>>>> of the Observe option in the second and third paragraph. >> Anything >>>>>> else seems generic and applicable to requests with payload, so >> it >>>>>> might be moved up to some earlier section. >>>>>> >>>>> [Jon] Sure - will be updated in the simplification tidy up. >>>>>> * Section 3.5 - In the third paragraph, I'm not sure you >>>>>> necessarily need a payload to be present in the requests asking >> for >>>>>> missing response payloads. For instance, consider: >>>>> [Jon] Agreed. Now going with Section 2.7 RFC7959 where both >> Block1 >>>>> and >>>> payload are not included. >>>>>> - The examples in Figure 10 and Figure 11 of RFC 7959, with >> the >>>>>> note "(no payload for requests with Block2 with NUM !=3D 0)" , >> during >>>>>> the phase where the client consecutively asks for the next >> response payload. >>>>>> - The examples in Figure 2 and Figure 3 of [2], where each >>>>>> request for the next response payload using Block2 has no >> payload of its own. >>>>>> This would of course affect the example in Figure 15. >>>>> [Jon] Yes, will be updated. >>>>>> [2] >>>>>> >> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ft >>>>>> oo >>>>>> ls.ietf.org%2Fhtml%2Fdraft-ietf-ace-coap-est- >>>> 18&data=3D04%7C01%7Cma >>>> >> rco.tiloca%40ri.se%7Cf30167412cf14279616708d8b948202a%7C5a9809cf0bcb >>>> 4 >>>> 13a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7CUnknown%7CT >>>> WFpbGZs >>>> >> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >>>> %3 >>>> D%7C1000&sdata=3DcSOOuCBEP2jCRzECrJeLli6Z%2Bu%2FUlD%2F1HzVWIM7 >>>> O7%2B >>>>>> Q%3D&reserved=3D0 >>>>>> >>>>>> >>>>>> * Section 3.5 - About the last sentence regarding the Observe >>>>>> option, there seems to be an exception to this rule (at least >> based >>>>>> on the later examples), where the server actually does include >> the >>>>>> Observe option in >>>> the response. >>>>> [Jon] If the Observe option is just included with the first >> payload >>>>> (NUM =3D 0) as >>>> RFC7959, there is a recovery special case should the first >> payload >>>> not arrive, but subsequent ones do. In the general case, blocks >> that >>>> are missing are re- requested by the client and the server >> responds >>>> with the appropriate block, but without the Observe option. For >> the >>>> special case when the client requests missing payload with NUM =3D >> 0 >>>> the server needs to know that it must include the Observe in the >>>> response so that the client following the body re-assembly knows >> that it is a Observe triggered additional response. >>>>> [Jon] I had gone with the Observe should be in all the payloads >> in >>>>> the response >>>> apart from specifically re-requested blocks (including NUM =3D 0). >> The 'Continue' >>>> Q-Block2 was just to indicate a continue so the server can send >> the >>>> remaining payloads without delay - hence why remaining payloads >> had Observe set. >>>>> [Jon] I am beginning to lean to having it in the first payload >> and >>>>> special case >>>> the response to re-request of NUM =3D 0. What do you think? >>>> >>>> =3D=3D>MT >>>> Ok, I didn't think also of the case for NUM =3D 0, but that makes >> sense too. >>>> Then it's certainly something better to clarify in the main text >> and >>>> also to show/comment in the example of Figure 10. >>>> <=3D=3D >>>> >>>>>> That is, consider the example in Figure 10, where the >> response >>>>>> with M:0xba is lost. Later on, the client asks for that >> response >>>>>> payload by sending the request with M:0x87, which correctly >> does >>>>>> not include >>>> the Observe option. >>>>> [Jon] Yes >>>>>> However, the following response with M:oxc3 and (from the >> point >>>>>> of view of the server) retransmitting that response payload >> with >>>>>> block number 10 does include the Observe option. >>>>>> >>>>>> The exception seems due to the fact that the retransmission >>>>>> request from the client is specifically what you call >> 'Continue' >>>>>> Q-Block-2 in Section 3.4. The Observe option is in fact not >>>>>> included for the previously retransmitted response payloads >> with >>>>>> M:0xbb ... M:0xc2, >>>> as still part of the current payload set. >>>>> [Jon] Correct, but obviously not obvious from the text. >>>> =3D=3D>MT >>>> Right, I mostly focused on that. >>>> >>>> I think it's worth clarifying in the main text what the normal >> case >>>> is for the server >>>> (client) to include (expect) the Observe option in a response >>>> payload; and then highlight the exceptions for the re-request >> with >>>> NUM=3D0 (see above) and for the 'Continue' Q-Block2. >>>> >>>> Best, >>>> /Marco >>>> <=3D=3D >>>> >>>>>> * Section 3.6 - Part of the first sentence in the second >> paragraph >>>>>> seems to repeat what already said in the third paragraph of >> Section 3.5. >>>>> [Jon] Will clean up in the simplification. >>>>> ~Jon >>>> -- >>>> 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://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= >> w >> .ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C980404e5b97a4f7d= >> 6 >> a2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374657 >> 6 >> 1738775081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM >> z >> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DLE%2FKQOOUq5aEBbgV= >> R >>>> dtqmLiOz8n%2Bt60OuEYgM%2FwCrJg%3D&reserved=3D0 >>>> >> -- >> 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://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ri.se%2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C21a30f35d4534262c3= 8c08d8bc751b7c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374665585176= 29762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI= 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D5npricMtOuyVskAU%2FpP%2BnvzjAc= %2Bazs%2BQ1G54jPNW6Wo%3D&reserved=3D0 >> > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged= information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > Thank you. > --=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 --LGEEhWQZN5PxIGxBMw1EEjciIUGhrkI50-- --JjlH2quIbwmAnOkJzWEChCT8sqHmkOuic Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmAG6CsACgkQ7iZktA5Y 2kNwhAf+KjYPcq/SWgt9faaPezWe1pN+pjCEvqBxq5FVKqFiG0PoszY+Qpck/pNP l8Yf08SUl6tl3tdvl+jfonZLWDUnfbGRRUwmcil+1TWGNq8+7n4RDW73WLnQWOAI z9ZxINLUFkyAi7mMDE7yJfF4l5W1yeUOeOqun3Ww5m5ztyyfQFaX1+SM4RyOAsLe 79ELbFhwa/ycqyYpMaW2c17CP74nKkirg5cJqHW06ZXfNYbCpGIYJKk3Sa2C/rsA YHlLwjC8PScdL6XMswbukqLzjHOKzBVkfPxqhkq4f+vJk/fAlQ0TxpqufNzDJPIE LX+jCdfOJRXS/5QLrvOZvHMnCNOqAw== =Pesm -----END PGP SIGNATURE----- --JjlH2quIbwmAnOkJzWEChCT8sqHmkOuic-- From nobody Tue Jan 19 07:19:07 2021 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 535883A159E; Tue, 19 Jan 2021 07:19:06 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161106954627.30354.11510619547642306741@ietfa.amsl.com> Date: Tue, 19 Jan 2021 07:19:06 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-new-block-06.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, 19 Jan 2021 15:19:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Faster Transmission Authors : Mohamed Boucadair Jon Shallow Filename : draft-ietf-core-new-block-06.txt Pages : 44 Date : 2021-01-19 Abstract: This document specifies alternative Constrained Application Protocol (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. These options are similar to the CoAP Block1 and Block2 Options, not a replacement for them, but do enable faster transmission rates for large amounts of data with less packet interchanges as well as supporting faster recovery should any of the blocks get lost in transmission. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-new-block-06 https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 19 07:21:09 2021 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 261243A159C; Tue, 19 Jan 2021 07:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 mdI9BRFTLhim; Tue, 19 Jan 2021 07:21:05 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E153A159E; Tue, 19 Jan 2021 07:21:05 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4DKsmw0rwCzCrKv; Tue, 19 Jan 2021 16:21:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1611069664; bh=J+XLJtYvfQpZGTGjjEwmDePktNGMWhuwcFIqlgGYi5A=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ervHUfef+/pF3mB4XbmnalB+bvYUzG+xBCG26WKzA+76QacjnLq9Kue+axlajXEsN 4G00C08eNuuB7EyVTshiCXa4c/XW8Egls6B0tTtSTSPPzA3siK6YBuLWo0mwU8f9/g lDxbLwxbVSmbQgkD/Atg87nG74EZdHaNco5VNbSkbi1VHWybjbfySmQ/LEZrUk+sZD rIcaQyj326D/urcoyQ/EHz3kbnW3dLC42QvuSEeVeA8MXs8QjqrerdZufaFBgFHVA+ oCUISwVaTThIb2Ixqh5hLtV1kwXruBw8eh/v1AXsnD3sqbF5pouiTgpwcTjq+GMwZd hj4WuYewzM0Hg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4DKsmw04jjz8sZq; Tue, 19 Jan 2021 16:21:04 +0100 (CET) From: To: Marco Tiloca , "supjps-ietf@jpshallow.com" , "core@ietf.org" CC: "draft-ietf-core-new-block@ietf.org" , "dots@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-new-block-05.txt Thread-Index: AQHW7mzEKkNbbrzxCk+23dClOwj886ovEB+A Date: Tue, 19 Jan 2021 15:21:03 +0000 Message-ID: <11344_1611069664_6006F8E0_11344_455_1_787AE7BB302AE849A7480A190F8B9330315BD0BE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> <4feb5743-4193-97f1-5231-038b1838b934@ri.se> <033b01d6eda4$8013a980$803afc80$@jpshallow.com> <5fc34721-6a91-39b9-5f8d-b58e6ec905f6@ri.se> <3017_1611059042_6006CF62_3017_76_1_787AE7BB302AE849A7480A190F8B9330315BCBD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.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, 19 Jan 2021 15:21:07 -0000 UmUtLA0KDQpHcmVhdC4gVGhhbmtzLiANCg0KQSB2ZXJzaW9uIHdpdGggdGhlIGFncmVlZCBjaGFu Z2VzIGlzIG5vdyBwdWJsaWM6IA0KDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvYXJjaGl2ZS9pZC9kcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrLTA2LnR4dCANClN0YXR1czog ICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvcmUt bmV3LWJsb2NrLyANCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LWlldGYtY29yZS1uZXctYmxvY2sgDQpIdG1saXplZDogICAgICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMDYgDQpE aWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtY29yZS1uZXctYmxvY2stMDYNCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+IERlwqA6IE1hcmNvIFRpbG9jYSBbbWFpbHRvOm1hcmNvLnRpbG9jYUBy aS5zZV0NCj4gRW52b3nDqcKgOiBtYXJkaSAxOSBqYW52aWVyIDIwMjEgMTU6MTANCj4gw4DCoDog Qk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47 DQo+IHN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb207IGNvcmVAaWV0Zi5vcmcNCj4gQ2PCoDogZHJh ZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZzsgZG90c0BpZXRmLm9yZw0KPiBPYmpldMKg OiBSZTogW2NvcmVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMDUudHh0 DQo+IA0KPiBHb3QgaXQsIHRoYW5rcy4NCj4gDQo+IEJlc3QsDQo+IC9NYXJjbw0KPiANCj4gT24g MjAyMS0wMS0xOSAxMzoyNCwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4g PiBIaSBNYXJjbywNCj4gPg0KPiA+IFRoZSBwcm9wb3NlZCBlZGl0cyBsb29rIGdvb2QgdG8gbWUu IFdpbGwgYmUgZml4ZWQgaW4gdGhlIGdpdGh1Yi4NCj4gPg0KPiA+IDIuMzEgaXMgbm90IG1lbnRp b25lZCBpbiBpbiB0aGUgZXhjZXJwdCB5b3UgcXVvdGVkIGZyb20gU2VjdGlvbg0KPiAzLjMgYmVj YXVzZSAyLjMxIGlzIG5vdCAqKnJlcXVpcmVkKiouIEEgc2VydmVyIG1heSBkZWNpZGUgdG8gbm90 DQo+IHJlcGx5IHdpdGggMi4zMSBhcyBhIGZ1bmN0aW9uIG9mIGl0cyBvdmVyYWxsIGxvYWQgYW5k IHByZWZlciB0bw0KPiBvYnNlcnZlIGEgcGF1c2UgYmVmb3JlIGhhbmRsaW5nIHRoZSBuZXh0IGJs b2NrLiBUaGF04oCZcyBpcyB3aHkgd2UgZG8NCj4gaGF2ZSBTSE9VTEQsIG5vdCBhIE1VU1QuDQo+ ID4NCj4gPiBDaGVlcnMsDQo+ID4gTWVkDQo+ID4NCj4gPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+ID4+IERlwqA6IE1hcmNvIFRpbG9jYSBbbWFpbHRvOm1hcmNvLnRpbG9jYUByaS5z ZV0gRW52b3nDqcKgOiBtYXJkaSAxOQ0KPiA+PiBqYW52aWVyIDIwMjEgMTI6NTAgw4DCoDogc3Vw anBzLWlldGZAanBzaGFsbG93LmNvbTsgQk9VQ0FEQUlSDQo+IE1vaGFtZWQNCj4gPj4gVEdJL09M TiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IGNvcmVAaWV0Zi5vcmcgQ2PCoDoNCj4g Pj4gZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZzsgZG90c0BpZXRmLm9yZyBPYmpl dMKgOiBSZToNCj4gW2NvcmVdDQo+ID4+IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY29yZS1uZXct YmxvY2stMDUudHh0DQo+ID4+DQo+ID4+IEhpIEpvbiwNCj4gPj4NCj4gPj4gVGhhbmtzLCBwbGVh c2Ugc2VlIGJlbG93IHNvbWUgbWlub3IgcG9pbnRzLCBvdGhlcndpc2UgaXQgbG9va3MNCj4gZ29v ZA0KPiA+PiB0byBtZS4NCj4gPj4NCj4gPj4gQmVzdCwNCj4gPj4gL01hcmNvDQo+ID4+DQo+ID4+ ICogU2VjdGlvbiAzLjEgLSBJbiB0aGUgcGFyYWdyYXBoIHJpZ2h0IGFib3ZlIFRhYmxlIDIsIHMv d2l0aCBDb0FQDQo+ID4+IG92ZXIgVENQL3dpdGggQ29BUCBvdmVyIHJlbGlhYmxlIHRyYW5zcG9y dHMuDQo+ID4+DQo+ID4+ICogU2VjdGlvbiAzLjEgLSBJIHRoaW5rIHRoYXQgdGhlIG5ldyBmaW5h bCBwYXJhZ3JhcGggIk5vdGUgdGhhdA0KPiBpZg0KPiA+PiBRLUJsb2NrMSAob3IgUS1CbG9jazIp IC4uLiBNVVNUIE5PVCBiZSBpbmNsdWRlZC4iIGZpdHMgYmV0dGVyDQo+IGJlZm9yZQ0KPiA+PiB0 aGUgcGFyYWdyYXBoIGRpc2N1c3NpbmcgdGhlIHVzZSBvZiBPU0NPUkUsIGkuZS4gIlRoZSBRLUJs b2NrMQ0KPiBhbmQNCj4gPj4gLi4uDQo+ID4+IGZyYWdtZW50YXRpb24gb2YgcmVxdWVzdHMuIg0K PiA+Pg0KPiA+PiAqIFNlY3Rpb24gMy4zIC0gIkZvciBOb24tY29uZmlybWFibGUgdHJhbnNtaXNz aW9uLCBubyByZXNwb25zZSBpcw0KPiA+PiByZXF1aXJlZCB1bnRpbCB0aGUgc3VjY2Vzc2Z1bCBy ZWNlaXB0IG9mIHRoZSBib2R5IGJ5IHRoZSBzZXJ2ZXINCj4gb3INCj4gPj4gc29tZSBvZiB0aGUg cGF5bG9hZHMgaGF2ZSBub3QgYXJyaXZlZCBhZnRlciBhIHRpbWVvdXQgYW5kIGENCj4gPj4gcmV0 cmFuc21pdCBtaXNzaW5nIHBheWxvYWRzIHJlc3BvbnNlIGlzIG5lZWRlZC4iDQo+ID4+DQo+ID4+ IMKgwqAgU2hvdWxkbid0IHRoaXMgYWxzbyBtZW50aW9uIHRoZSBjYXNlIHdoZXJlIHRoZSBzZXJ2 ZXIgc2VuZHMgYQ0KPiA+PiAyLjMxIHJlc3BvbnNlIHRvIGhhdmUgdGhlIGNsaWVudCBjb250aW51 ZSBzZW5kaW5nIHRoZSBuZXh0DQo+ID4+IE1BWF9QQVlMT0FEUyBwYXlsb2Fkcz8NCj4gPj4NCj4g Pj4gKiBTZWN0aW9uIDMuMyAtIFByb3Bvc2VkIGNsYXJpZmljYXRpb24gZm9yIHRoZSA0LjAyIHJl c3BvbnNlDQo+IGNvZGU6DQo+ID4+DQo+ID4+IMKgwqDCoCAiRWl0aGVyIHRoaXMgUmVzcG9uc2Ug Q29kZSAoaW4gY2FzZSBvZiBDb25maXJtYWJsZSByZXF1ZXN0KQ0KPiBvciBhDQo+ID4+IHJlc2V0 IG1lc3NhZ2UgKGluIGNhc2Ugb2YgTm9uLWNvbmZpcm1hYmxlIHJlcXVlc3QpIE1VU1QgYmUNCj4g cmV0dXJuZWQNCj4gPj4gaWYgdGhlIHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IHRoZSBRLUJsb2Nr MSBPcHRpb24uIg0KPiA+Pg0KPiA+Pg0KPiA+PiBPbiAyMDIxLTAxLTE4IDE1OjE2LCBzdXBqcHMt aWV0ZkBqcHNoYWxsb3cuY29tIHdyb3RlOg0KPiA+Pj4gSGkgTWFyY28sDQo+ID4+Pg0KPiA+Pj4g V2UgaGF2ZSB1cGRhdGVkIGdpdGh1YiBbMV0gdG8gdGFrZSBhY2NvdW50IG9mIHlvdXIgbGF0ZXN0 DQo+IGNvbW1lbnRzDQo+ID4+IGZvciB5b3VyIHJldmlldy4NCj4gPj4+IFJlZ2FyZHMNCj4gPj4+ DQo+ID4+PiBKb24NCj4gPj4+IA0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From Lauri.Piikivi@pelion.com Wed Jan 20 01:35:06 2021 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 0DBB43A0DC9 for ; Wed, 20 Jan 2021 01:35:06 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=RkW1X0QC; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=RkW1X0QC 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 7Yv1QpwOaiTN for ; Wed, 20 Jan 2021 01:35:03 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60083.outbound.protection.outlook.com [40.107.6.83]) (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 6064B3A0DBD for ; Wed, 20 Jan 2021 01:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nrmy4KQN/O11Y+OrjDpC2nUlRITM/zwSZMA6MNmDO9I=; b=RkW1X0QCJDahJ2rpL89Z45XqeKOyHCvzlCsQApEC7N+6v3/AbGZ5REKsneppWEpPtJi3KPv0Xq8bmoqkOqg74was2GMiZbhidFK7u0nm2QyTjBaD4KhSLpZW+TV8bTgMki7fHZznTtApeC+9lED0uDCPhdUW32c1YJXTxj6EqC0= Received: from AS8PR04CA0067.eurprd04.prod.outlook.com (2603:10a6:20b:313::12) by VI1PR08MB3904.eurprd08.prod.outlook.com (2603:10a6:803:c0::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.9; Wed, 20 Jan 2021 09:34:58 +0000 Received: from AM5EUR03FT052.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:313:cafe::d8) by AS8PR04CA0067.outlook.office365.com (2603:10a6:20b:313::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.12 via Frontend Transport; Wed, 20 Jan 2021 09:34:58 +0000 X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 63.35.35.123) smtp.mailfrom=pelion.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=none action=none header.from=pelion.com; Received-SPF: Fail (protection.outlook.com: domain of pelion.com does not designate 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT052.mail.protection.outlook.com (10.152.17.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.11 via Frontend Transport; Wed, 20 Jan 2021 09:34:57 +0000 Received: ("Tessian outbound 28c96a6c9d2e:v71"); Wed, 20 Jan 2021 09:34:57 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: a2d8914ad15752ee X-CR-MTA-TID: 64aa7808 Received: from d2a2c867d2bd.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D6777FD5-396C-46AA-801E-6EECF0B9477A.1; Wed, 20 Jan 2021 09:34:52 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id d2a2c867d2bd.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 20 Jan 2021 09:34:52 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RUpv1CYfwyA9dPlzJOcfa6OA9M6aozg61yudMUuL8EzpRoj1h2Uc2SPBUxfohkgUl16IKJAVwNjmSl99QNF2Ls9jJW/AO5IZhkB9Torh63PCKktZhzlsWEGlVtUhvokQGC3Tgfry9c3pcdxYBNHl5hKj/zZh6AU50MWDG2EHFKXNeFCVZue67vGK8iy+70v/9pCUSBYYS4+4bCTf7LJDIW6VMtrefGdxIi8opK/C1xQe3NmsP58Zr1RBGkqHW9OIrdVwXojb2GO0EZX2uvUaUVLo2KqszMoiIpXsXDYLogX3fTjFaKZ0/HEBPUis9ZKIoEGXoYU9SNLqZ/nESoJQEA== 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=Nrmy4KQN/O11Y+OrjDpC2nUlRITM/zwSZMA6MNmDO9I=; b=SFS4Zsd4mrFJiD+AgxTdTHFR0JQIwKb6t+tseuEKHZhD39rD8C19oMmOFVEuEi0Z4RqDvMWtXw+eeH1LOYk6hLdvJaM6SZ5GUvmBuOUxrDgKueCxAUvKaGuRv81bVwMKVOvTp5g0fWzd7wDiAsfdeK2vWHXQB+TfqwkdU7y7hS9944ygSKhTBKvAkOiKIEwmFp79/vflSlLm0bddqHlaZfXThA6HvNPtly4VkapBm1hI3hdv5lh7HfWCNsxwYjhwBnhCQKlStM/EIzWHBFZ+NoCC7wyEkF4F8J4hpY1poJJqkgtJ0LvywDRpugYlYwSi5ta3xRsV0sX8rRAAJnK2Kw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=pelion.com; dmarc=pass action=none header.from=pelion.com; dkim=pass header.d=pelion.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nrmy4KQN/O11Y+OrjDpC2nUlRITM/zwSZMA6MNmDO9I=; b=RkW1X0QCJDahJ2rpL89Z45XqeKOyHCvzlCsQApEC7N+6v3/AbGZ5REKsneppWEpPtJi3KPv0Xq8bmoqkOqg74was2GMiZbhidFK7u0nm2QyTjBaD4KhSLpZW+TV8bTgMki7fHZznTtApeC+9lED0uDCPhdUW32c1YJXTxj6EqC0= Received: from HE1PR08MB2825.eurprd08.prod.outlook.com (2603:10a6:7:35::21) by HE1PR0802MB2249.eurprd08.prod.outlook.com (2603:10a6:3:c2::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.9; Wed, 20 Jan 2021 09:34:50 +0000 Received: from HE1PR08MB2825.eurprd08.prod.outlook.com ([fe80::e552:4f51:ab4c:eb44]) by HE1PR08MB2825.eurprd08.prod.outlook.com ([fe80::e552:4f51:ab4c:eb44%5]) with mapi id 15.20.3763.014; Wed, 20 Jan 2021 09:34:50 +0000 From: Lauri Piikivi To: "core@ietf.org" Thread-Topic: Request-Token (in draft-ietf-core-new-block-06 and draft-ietf-core-echo-request-tag-11) Thread-Index: AQHW7w+AXy8B2TA/Tky41ga77K+Dlw== Date: Wed, 20 Jan 2021 09:34:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.4) Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=pelion.com; x-originating-ip: [2001:14ba:14fc:f700:6d68:ed2c:42b8:74c7] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: ea375a7a-f7f3-4d46-a341-08d8bd26a6b0 x-ms-traffictypediagnostic: HE1PR0802MB2249:|VI1PR08MB3904: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 1wSl88XANvAMsJDvkZ/XOTgKaDuDXrAKTdljTneQrBUB/eIup1xT4BFDObYTn2oUmp69QMHAdiQK/QSwAAh0nXJk3B8xtS+eOQiVkTA/HiIlRCkvKsZ+4wAMTSb408QduLjKjlIiLGvIFj8KpePh56USIqJUS73qAgkK5HRgU/7213YFbRrLNLTk5eVjpmSVDzBxSCyp2omXLz+fIDEipEKakXL2apjT9HwaNr4GLB6U7xddaPOEmLcuvhUte4gcd0pY7mtUCS2G0Y/Xo2Z/rPbuuTFUrSC2xFMwFmrKhuRBJuhk+fVklCJhNAMkbNn0gYZ0nFjte/bLJWhYKuAMJv/9IE/UrIiMkYjs64lsBQGu9Tbo0cR8vHX9Cpe4D8/ELEjO5qfzPQNBmYpjlaX7qgsHKPsMWVMtSYnx7n1v0TvwjC35fe5XBSlzPtEJkvv6GTjHGN7yWyVShuuNTWAuJQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR08MB2825.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(346002)(39850400004)(366004)(136003)(66446008)(71200400001)(8936002)(6916009)(83380400001)(76116006)(8676002)(66476007)(66946007)(64756008)(5660300002)(33656002)(66556008)(2906002)(478600001)(36756003)(316002)(86362001)(9686003)(6486002)(186003)(6506007)(166002)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?bGdObHdzdHJyS3pNVlI4b0xkQWtQaW9XeC91MGEwcVZKMENyVGtPOUR2RHNV?= =?utf-8?B?dnp3TlBxbjg4NEFLRnlrNnJldmVhSFE1UjRjNlpSUS9vcGFJL3dqYUp0aExT?= =?utf-8?B?LzErbGJaWWU4VlFjN0cyWmpkb2lYblBLOFV4L0lhY1J6MGtqUW00T2d0cmRE?= =?utf-8?B?WDM4RzNjNE9KWU9pQjN3SWkyWE80T283L21BTXBCTjAwYVRzVHl4N3RieWRE?= =?utf-8?B?bUIybWlsYjRZVVZqTDUvaHNHcEFHT0twRzZGU1I5aXcwMTBwVEx3KzNlUC9s?= =?utf-8?B?bVpQVG9kWGtVWG1xSlorSWJ3Q01ORVFIOHRIWGtGM0FqTjVZRG5iNnFaODdJ?= =?utf-8?B?eGgxekRiUnNhZU9vTTB4YU5QNVdUZERvT1dhUmppSzBLT1FZQmRwREs3dVNl?= =?utf-8?B?c2xKTVQ0Y2dBa3lPNWxIYXRVZlRMMHRFSGlUWnRnSG5lVzl6UU84U1MrZVBu?= =?utf-8?B?V1NnYUg1SjY2ZEVWcmV4VHVTMk9NMzE4R1JhU01Wbktabm5GVStsZTVITVdk?= =?utf-8?B?TFQ3ZUdpNURyR1hweUJxcUxhNnBFWWhENnRpRW1EOGZ6QWZlM2lvZ2ljTXJ2?= =?utf-8?B?czVIRlpIdzZDRTd6RnAyWHp4TVB4QzdnbXJUQUdHM3JmejI1ZVNxcnRDVWtL?= =?utf-8?B?WmQ3T09lT0FpbDJzUnB3VThMcExOdU14dnduZ0N2U0ZyMmlGRlhQSkx3YnFF?= =?utf-8?B?eDArZjJXODN1TGxwM3lYeUZKWGlCeWE4MFpaUjR0RW9UTU9BWnpzTVRQZVY3?= =?utf-8?B?QTdxSHRUKzRzLzNlTjhJaUhXSEd1LzRoRVhOOHM3WFYrdS9HcUxuTDhPdHZR?= =?utf-8?B?ZVFkSDhYTTloOGJjTHlibTJ4TTFZTjlKWHVIMUpEanpXTmpLNSt6SlVVdlNT?= =?utf-8?B?am5wekk2TDd6Vi9pejNEZXkzUkdlOWwxMGplWHoxVkVYWHFmUW5OcU4wZHRT?= =?utf-8?B?OW5tWFZFcmFqeUdMLzFxZUxtMk9jaWloMjQySWpWRDc1R0hhQzV3am8reTY2?= =?utf-8?B?QVhBZ3F6U1Yra0JSNWlYRllZRm1TVFA5NnN1TmZTQi95QVQ2NExxU0N0SnNs?= =?utf-8?B?VFRXaGhzaTEvZFYwSzBGWEVjbEo1L3pRYlB5TlY0QkliMVFFTE9NbzJ1aEUr?= =?utf-8?B?Mm1vR3lPMDJGdGtOZ3hvWUFQK0xKVkVFTVRueFZJditRb0NwRFRjTGJkTDJR?= =?utf-8?B?TkJUbUJDUGNsM1Q1S0QyaXRjRC9Kc2x5Wkk2OWtPUFZuWGlrRGNYOHJIY1FJ?= =?utf-8?B?eHdjaEI3aXpnOS9ndC9UMnJaell3L3l1aVpIMkVyYUY3SHc4RnJ2NmhWc05R?= =?utf-8?B?TGc4ZEp5UksvN1RNSnBId0hnMXd0WW9ESGZiUS9LdmtCM0tyUys1dEM5WVNI?= =?utf-8?B?QWJLRU1qK2ZidHBqdDhFWVF1OEYzTlN5anlmVXdXQlBueXVaYTUwODgxMG04?= =?utf-8?Q?OOhus+9e?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_B57FD1F880A24B5396A5DBD1489F0692armcom_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2249 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=pelion.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT052.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: f5aed1d3-1f3d-4de2-7fc2-08d8bd26a298 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: gSnJTPunIMl/YHDM/P96Y6QOfOGfCDcp0gtBqoxoLep35JaQpyZJnVMwepVV+eZ0bb+Mv1utdVQI/YXyYhMA1UikhMXxex7SyJQqPIn1arLq4TVAnjvvdPlmPGEWgON1xKAC5Jg9kd2YRLm7ppm3Jg4+40+kWOP1h8NDyjyT+rAZsMoPgBP6TWkpkp+tI5kJH04uZYRLkcMLI2M3gMZhG1CbD3Gy+BcHER8JSavkWBgPm7PcWQIaZ0TVemtMwmXPfsV6F/f0gUI47nChlL2RuYjVWq86RoL+KdyYsWcqQD5CafhaBS8KbiWGZHZNE0r8XgNUZ7t5xBw0ZJQZMqo22dX3tItg9GQLcRk2Qa5HbJrbDyYrRTgC9s4b6EHoMBsZ7rKM/ab6s6zLeS0pETwvYxwKTuq+BwAlzmqOaF7Vl/76CRgs6k2DGa+S0f+jfq1MSH8Lp+AU3lIlzLdniEM8pbnxZksxmoxgXO5p0HHM0N5Klx7V1um+31zzQtzfxhRjPM0q7osL9cUguMy183ZktqNv/mqG8jg3v6zoKM5d9xE= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(346002)(396003)(376002)(39850400004)(136003)(46966006)(6486002)(166002)(82310400003)(82740400003)(70586007)(316002)(33964004)(2906002)(83380400001)(8676002)(81166007)(33656002)(6512007)(336012)(478600001)(8936002)(356005)(6916009)(6506007)(5660300002)(186003)(36756003)(86362001)(47076005)(26005)(45080400002)(70206006)(9686003); DIR:OUT; SFP:1101; X-OriginatorOrg: pelion.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2021 09:34:57.5166 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ea375a7a-f7f3-4d46-a341-08d8bd26a6b0 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT052.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3904 Archived-At: X-Mailman-Approved-At: Wed, 20 Jan 2021 01:43:26 -0800 Subject: [core] Request-Token (in draft-ietf-core-new-block-06 and 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: Wed, 20 Jan 2021 09:36:40 -0000 --_000_B57FD1F880A24B5396A5DBD1489F0692armcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxscywNCg0KSSByZWFkIHRoZSBuZXcgYmxvY2sgd2l0aCBpbnRlcmVzdCBhbmQgc3RhcnRl ZCB3b25kZXJpbmcgYWJvdXQgdGhlIHJlcXVlc3QgdGFnLiBXaHkgZG8gd2UgbmVlZCBuZXcgdGFn LCB3aGVuIHdlIGhhdmUgdGhlIGJhc2ljIENPQVAgdG9rZW4uIFRva2VuIGlzIHVzZWQgdG8gbWF0 Y2ggcmVxdWVzdCBhbmQgcmVzcG9uc2UsIGFuZCBpbiBkb2luZyB0aGF0IGl0IGRvZXMgaWRlbnRp ZnkgdGhlIHJlcXVlc3QgYmxvY2tzIGFuZCByZXNwb25zZSBibG9ja3MgdG8gYmUgcGFydCBvZiB0 aGUgc2FtZSByZXF1ZXN0IGFuZCByZXNwb25zZS4NCg0KSW4gYmxvY3dpc2UgdHJhbnNmZXIgNzk1 OSAsIHRoZSBtZXNzYWdlIElEcyBjaGFuZ2UgYnV0IHRva2VuIGNvbWJpbmVzIHRoZW0gdG9nZXRo ZXIuIFNhbWUgc2VlbXMgdXNhYmxlIGluIHRoZSBuZXctYmxvY2sgYXBwcm9hY2guIEl0IGlzIHRo ZSBzYW1lIHJlcXVlc3QsIHNvIHRoZXkgc2hvdWxkIGhhdmUgdGhlIHNhbWUgdG9rZW4uIFJGQyA3 OTU5IGRvZXMgbm90IHNheSBhIHdob2xlIGxvdCBhYm91dCB0b2tlbnMgIkFzIGEgZ2VuZXJhbCBj b21tZW50IG9uIHRva2VucywgdGhlcmUgaXMgbm8gb3RoZXIgbWVudGlvbiBvZiB0b2tlbnMgaW4g dGhpcyBkb2N1bWVudCwgYXMgYmxvY2std2lzZSB0cmFuc2ZlcnMgaGFuZGxlIHRva2VucyBsaWtl IGFueSBvdGhlciBDb0FQIGV4Y2hhbmdlLiBBcyB1c3VhbCwgdGhlIGNsaWVudCBpcyBmcmVlIHRv IGNob29zZSB0b2tlbnMgZm9yIGVhY2ggZXhjaGFuZ2UgYXMgaXQgbGlrZXMu4oCdIFRoaXMgY291 bGQgYmUgY2xhcmlmaWVkLiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIHRva2VuIGlzIHRo ZSBzYW1lIGZvciBhbGwgYmxvY2tzIG9mIGEgcmVxdWVzdCBhbmQgcmVzcG9uc2UuICBUaGlzIGlz IHNob3duIGZvciBleGFtcGxlIGluIHRoZSBGaWd1cmUgMTMgb2YgNzk1OS4NCg0KTXkgd29uZGVy aW5nIHN0YXJ0ZWQgZnJvbSByZWFkaW5nIHRoZSAgZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay0w Ni4gSXQgc3RhdGVzIHRoZW4gbmVlZCBmb3IgcmVxdWVzdCB0YWcsIGFuZCBpbiBleGFtcGxlIDku MS4xICBzaG93cyB0aGUgYmFzaWMgdG9rZW5zIGFzIGRpZmZlcmVudCBmb3IgdGhlIGZyYWdtZW50 ZWQgcmVxdWVzdC4gSXMgdGhhdCBhbiBlcnJvcj8gU2hvdWxkIHRoZSBiYXNpYyB0b2tlbnMgYmUg dGhlIHNhbWU/IEFuZCBpZiB0aGUgdG9rZW5zIGFyZSB0aGUgc2FtZSwgdGhlIHJlcXVlc3QtdGFn IHNlZW1zIHVubmVjZXNzYXJ5Lg0KDQpJIGRpZCByZWFkIHRoZSBkcmFmdC1pZXRmLWNvcmUtZWNo by1yZXF1ZXN0LXRhZy0xMSB0byB1bmRlcnN0YW5kIHRoZSByZXF1ZXN0LXRva2VuIGJldHRlciwg YnV0IEkgZm91bmQgdGhlIGRlc2NyaXB0aW9uIGEgYml0IGhhcmQgdG8gZm9sbG93LiBJdCBzYXlz IGluIGluIGNocCAzLjIgdGhhdCAgIlRoZSBSZXF1ZXN0LVRhZyBpcyBpbnRlbmRlZCBmb3IgdXNl IGFzIGEgc2hvcnQtbGl2ZWQgaWRlbnRpZmllciBmb3Iga2VlcGluZyBhcGFydCBkaXN0aW5jdCBi bG9jay13aXNlIHJlcXVlc3Qgb3BlcmF0aW9ucyBvbiBvbmUgcmVzb3VyY2UgZnJvbSBvbmUgY2xp ZW504oCdDQoNCkJ1dCBvbiB0aGUgd2lyZSB0aGVyZSBpcyBhbHJlYWR5IHRoZSB0b2tlbiBzcGVj aWZpZWQgaW4gNzI1MiBjaHAgNS4zLjEgIkEgdG9rZW4gaXMgaW50ZW5kZWQgZm9yIHVzZSBhcyBh IGNsaWVudC1sb2NhbCBpZGVudGlmaWVyIGZvciAgZGlmZmVyZW50aWF0aW5nIGJldHdlZW4gY29u Y3VycmVudCByZXF1ZXN0cyAoc2VlIFNlY3Rpb24gNS4zPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM3MjUyI3NlY3Rpb24tNS4zPinigJ0uDQoNCg0KSSBkbyBub3QgdW5kZXJzdGFuZCBl eGFjdGx5IHdoYXQgaXMgbWVhbnQgYnkgICJUaGUgYmxvY2std2lzZSBmdW5jdGlvbmFsaXR5IGRv ZXMgbm90IHN1cHBvcnQgdGhlIGRldGVjdGlvbiBvZiBpbnRlcmNoYW5nZWQgYmxvY2tzIGJldHdl ZW4gZGlmZmVyZW50IG1lc3NhZ2UgYm9kaWVzIHRvIHRoZSBzYW1lIHJlc291cmNlIGhhdmluZyB0 aGUgc2FtZSBibG9jayBudW1iZXLigJ0gaW4gIHRhZy0xMSBjaHAgMy4xLiBJcyB0aGUgbWVzc2Fn ZSBib2R5IHRoZSBwYXlsb2FkPyAgSWYgdGhlIHJlcXVlc3RzIGNvbWUgZnJvbSBzYW1lIGNsaWVu dCwgdGhleSBtdXN0IGhhdmUgZGlmZmVyZW50IHRva2VucywgcGVyIHJmYyA3MjUyLg0KDQoNCklz IHRoZXJlIHNvbWUgcHJvYmxlbSBpbiB0b2tlbiB0aGF0IEkgZmFpbCB0byB1bmRlcnN0YW5kIG5v dyDigJQgbmVjZXNzaXRhdGluZyB0aGUgcmVxdWVzdC10b2tlbj8NCg0KDQpJbiBzaW1pbGFyIHZl aW4sIGFuZCBhcyBhIHVzZSBjYXNlIHdoZXJlIHJlcXVlc3QgdG9rZW4gc2VlbXMgZ29vZCwgaXMg dGhlIHVuZGVyc3RhbmRpbmcgY29ycmVjdCB0aGF0IGZvciBibG9jazEgcmVxdWVzdHMgYWxsIHRo ZSByZXF1ZXN0IG9wdGlvbnMgYXJlIGR1cGxpY2F0ZWQgaW4gYWxsIHRoZSBibG9ja3M/IEkgY291 bGQgbm90IGZpbmQgYSBjbGVhciBzdGF0ZW1lbnQsIGJ1dCBvbmNlIGFnYWluIHRoZSBmaWd1cmVz IGluIDc5NTkgc2hvdyB0aGUgVVJJIGZvciBlYWNoIGJsb2NrLiBUaGUgVVJJIHBhdGggYW5kIHF1 ZXJ5IG9wdGlvbnMgY2FuIGJlIGxvbmcsIGFuZCB0YWtlIGNvbnNpZGVyYWJsZSBzcGFjZSBpbiBl YWNoIGJsb2NrLg0KDQpDb3VsZCByZXF1ZXN0IHRva2VuIGJlIHRoZSBpZGVudGlmaWVyIGZvciBy ZXF1ZXN0IG9wdGlvbnMsIHNvIHRoYXQgb25seSAxc3QgYmxvY2sgd291bGQgaGF2ZSBmdWxsIG9w dGlvbnMgYW5kIGxhdGVyIG9uZXMgb25seSB0aGUgdGhlIHJlcXVlc3QgdGFnPw0KDQpTaW5jZXJl bHksDQotIExhdXJpDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVt YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUg cHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0 b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_B57FD1F880A24B5396A5DBD1489F0692armcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNHB4 OyIgY2xhc3M9IiI+SGkgYWxscyw8L3NwYW4+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDE0cHg7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE0cHg7IiBjbGFzcz0iIj5JIHJl YWQgdGhlIG5ldyBibG9jayB3aXRoIGludGVyZXN0IGFuZCBzdGFydGVkIHdvbmRlcmluZyBhYm91 dCB0aGUgcmVxdWVzdCB0YWcuIFdoeSBkbyB3ZSBuZWVkIG5ldyB0YWcsIHdoZW4gd2UgaGF2ZSB0 aGUgYmFzaWMgQ09BUCB0b2tlbi4gVG9rZW4gaXMgdXNlZCB0byBtYXRjaCByZXF1ZXN0IGFuZCBy ZXNwb25zZSwgYW5kIGluIGRvaW5nIHRoYXQgaXQNCiBkb2VzIGlkZW50aWZ5IHRoZSByZXF1ZXN0 IGJsb2NrcyBhbmQgcmVzcG9uc2UgYmxvY2tzIHRvIGJlIHBhcnQgb2YgdGhlIHNhbWUgcmVxdWVz dCBhbmQgcmVzcG9uc2UuPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxNHB4OyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyIgY2xhc3M9IiI+SW4g YmxvY3dpc2UgdHJhbnNmZXIgNzk1OSAsIHRoZSBtZXNzYWdlIElEcyBjaGFuZ2UgYnV0IHRva2Vu IGNvbWJpbmVzIHRoZW0gdG9nZXRoZXIuIFNhbWUgc2VlbXMgdXNhYmxlIGluIHRoZSBuZXctYmxv Y2sgYXBwcm9hY2guIEl0IGlzIHRoZSBzYW1lIHJlcXVlc3QsIHNvIHRoZXkgc2hvdWxkIGhhdmUg dGhlIHNhbWUgdG9rZW4uIFJGQyA3OTU5IGRvZXMNCiBub3Qgc2F5IGEgd2hvbGUgbG90IGFib3V0 IHRva2VucyAmcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzMzMzMDE1 NDQxODk1cHg7IiBjbGFzcz0iIj5BcyBhIGdlbmVyYWwgY29tbWVudCBvbiB0b2tlbnMsIHRoZXJl IGlzIG5vIG90aGVyJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEzLjMzMzMz MzAxNTQ0MTg5NXB4OyIgY2xhc3M9IiI+bWVudGlvbiBvZiB0b2tlbnMgaW4gdGhpcyBkb2N1bWVu dCwgYXMgYmxvY2std2lzZQ0KIHRyYW5zZmVycyBoYW5kbGUmbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTMuMzMzMzMzMDE1NDQxODk1cHg7IiBjbGFzcz0iIj50b2tlbnMgbGlr ZSBhbnkgb3RoZXIgQ29BUCBleGNoYW5nZS4gQXMgdXN1YWwsIHRoZSBjbGllbnQgaXMgZnJlZSB0 byZuYnNwOzwvc3Bhbj48Zm9udCBzaXplPSIyIiBjbGFzcz0iIj5jaG9vc2UgdG9rZW5zIGZvciBl YWNoIGV4Y2hhbmdlIGFzIGl0IGxpa2VzLuKAnSBUaGlzIGNvdWxkIGJlIGNsYXJpZmllZC4gTTwv Zm9udD55DQogdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSB0b2tlbiBpcyB0aGUgc2FtZSBmb3Ig YWxsIGJsb2NrcyBvZiBhIHJlcXVlc3QgYW5kIHJlc3BvbnNlLiAmbmJzcDtUaGlzIGlzIHNob3du IGZvciBleGFtcGxlIGluIHRoZSBGaWd1cmUgMTMgb2YgNzk1OS48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N Cjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTRw eDsiIGNsYXNzPSIiPk15IHdvbmRlcmluZyBzdGFydGVkIGZyb20gcmVhZGluZyB0aGUgJm5ic3A7 ZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay0wNi4gSXQgc3RhdGVzIHRoZW4mbmJzcDtuZWVkIGZv ciByZXF1ZXN0IHRhZywgYW5kIGluJm5ic3A7ZXhhbXBsZSA5LjEuMTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxNHB4OyIgY2xhc3M9IiI+Jm5ic3A7IHNob3dzIHRoZSBiYXNpYyB0b2tl bnMgYXMgZGlmZmVyZW50DQogZm9yIHRoZSBmcmFnbWVudGVkIHJlcXVlc3QuIElzIHRoYXQgYW4g ZXJyb3I/IFNob3VsZCB0aGUgYmFzaWMgdG9rZW5zIGJlIHRoZSBzYW1lPyBBbmQgaWYgdGhlIHRv a2VucyBhcmUgdGhlIHNhbWUsIHRoZSByZXF1ZXN0LXRhZyBzZWVtcyB1bm5lY2Vzc2FyeS48L3Nw YW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyIgY2xhc3M9IiI+SSBkaWQgcmVhZCB0 aGUmbmJzcDtkcmFmdC1pZXRmLWNvcmUtZWNoby1yZXF1ZXN0LXRhZy0xMSB0byB1bmRlcnN0YW5k IHRoZSByZXF1ZXN0LXRva2VuIGJldHRlciwgYnV0IEkgZm91bmQgdGhlIGRlc2NyaXB0aW9uIGEg Yml0IGhhcmQgdG8gZm9sbG93LiBJdCBzYXlzIGluIGluIGNocCAzLjIgdGhhdCAmbmJzcDsmcXVv dDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgYmFja2dyb3VuZC1jb2xvcjog cmdiKDI1NSwgMjUzLCAyNDUpOyIgY2xhc3M9IiI+VGhlDQogUmVxdWVzdC1UYWcgaXMgaW50ZW5k ZWQgZm9yIHVzZSBhcyBhIHNob3J0LWxpdmVkIGlkZW50aWZpZXIgZm9yJm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1 MywgMjQ1KTsiIGNsYXNzPSIiPmtlZXBpbmcgYXBhcnQgZGlzdGluY3QgYmxvY2std2lzZSByZXF1 ZXN0IG9wZXJhdGlvbnMgb24gb25lIHJlc291cmNlJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDE0cHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsiIGNs YXNzPSIiPmZyb20NCiBvbmUgY2xpZW50PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE0 cHg7IiBjbGFzcz0iIj7igJ08L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTMsIDI0NSk7IGZvbnQtc2l6ZTogMTRweDsi IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJiYWNrZ3Jv dW5kLWNvbG9yOiByZ2IoMjU1LCAyNTMsIDI0NSk7IiBjbGFzcz0iIj5CdXQgb24gdGhlIHdpcmUg dGhlcmUgaXMgYWxyZWFkeSZuYnNwO3RoZSB0b2tlbiZuYnNwO3NwZWNpZmllZCBpbiA3MjUyIGNo cCA1LjMuMSAmcXVvdDs8L3NwYW4+QSB0b2tlbiBpcyBpbnRlbmRlZCBmb3IgdXNlIGFzIGEgY2xp ZW50LWxvY2FsIGlkZW50aWZpZXIgZm9yJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDE0cHg7IiBjbGFzcz0iIj4mbmJzcDtkaWZmZXJlbnRpYXRpbmcNCiBiZXR3ZWVuIGNvbmN1 cnJlbnQgcmVxdWVzdHMgKHNlZSA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzcyNTIjc2VjdGlvbi01LjMiIHN0eWxlPSJmb250LXNpemU6IDE0cHg7IiBjbGFz cz0iIj5TZWN0aW9uIDUuMzwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyIgY2xhc3M9 IiI+KeKAnS4gJm5ic3A7PC9zcGFuPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9Im1hcmdp bi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7Ij48Zm9u dCBmYWNlPSJIZWx2ZXRpY2EiIHN0eWxlPSJmb250LXNpemU6IDE0cHg7IiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+PC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9Im1hcmdp bi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7Ij48Zm9u dCBmYWNlPSJIZWx2ZXRpY2EiIHN0eWxlPSJmb250LXNpemU6IDE0cHg7IiBjbGFzcz0iIj5JIGRv IG5vdCB1bmRlcnN0YW5kIGV4YWN0bHkgd2hhdCBpcyBtZWFudCBieSAgJnF1b3Q7PHNwYW4gc3R5 bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsiIGNsYXNzPSIiPlRoZSBi bG9jay13aXNlIGZ1bmN0aW9uYWxpdHkgPC9zcGFuPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNv bG9yOiByZ2IoMjU1LCAyNTMsIDI0NSk7IiBjbGFzcz0iIj5kb2VzIG5vdCBzdXBwb3J0IHRoZSBk ZXRlY3Rpb24gb2YgaW50ZXJjaGFuZ2VkIGJsb2NrcyBiZXR3ZWVuIDwvc3Bhbj48c3BhbiBzdHls ZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyIgY2xhc3M9IiI+ZGlmZmVy ZW50IG1lc3NhZ2UgYm9kaWVzIHRvIHRoZSBzYW1lIHJlc291cmNlIGhhdmluZyB0aGUgc2FtZSBi bG9jayA8L3NwYW4+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1Mywg MjQ1KTsiIGNsYXNzPSIiPm51bWJlcuKAnSBpbiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsiIGNsYXNzPSIiPiB0 YWctMTEgY2hwIDMuMS4gSXMgdGhlIG1lc3NhZ2UgYm9keSB0aGUgcGF5bG9hZD8gIDwvc3Bhbj48 Zm9udCBmYWNlPSJIZWx2ZXRpY2EiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNv bG9yOiByZ2IoMjU1LCAyNTMsIDI0NSk7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxNHB4OyIgY2xhc3M9IiI+SWYgdGhlIHJlcXVlc3RzIGNvbWUgZnJvbSBzYW1lIGNsaWVudCwg dGhleSBtdXN0IGhhdmUgZGlmZmVyZW50IHRva2VucywgcGVyIHJmYyA3MjUyLiA8L3NwYW4+PC9z cGFuPjwvZm9udD48L3ByZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9t OiAwcHg7IGJyZWFrLWJlZm9yZTogcGFnZTsiPjxmb250IGZhY2U9IkhlbHZldGljYSIgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsiIGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE0cHg7IiBjbGFzcz0iIj5JcyB0aGVyZSBz b21lIHByb2JsZW0gaW4gdG9rZW4gdGhhdCBJIGZhaWwgdG8gdW5kZXJzdGFuZCBub3cg4oCUIG5l Y2Vzc2l0YXRpbmcgdGhlIHJlcXVlc3QtdG9rZW4/Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+ PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJn aW4tYm90dG9tOiAwcHg7IGJyZWFrLWJlZm9yZTogcGFnZTsiPjxmb250IGZhY2U9IkhlbHZldGlj YSIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1Mywg MjQ1KTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE0cHg7IiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdw YWdlIiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IGJyZWFrLWJl Zm9yZTogcGFnZTsiPjxmb250IGZhY2U9IkhlbHZldGljYSIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDE0cHg7IiBjbGFzcz0iIj5JbiBzaW1pbGFyIHZlaW4sIGFuZCBhcyBh IHVzZSBjYXNlIHdoZXJlIHJlcXVlc3QgdG9rZW4gc2VlbXMgZ29vZCwgaXMgdGhlIHVuZGVyc3Rh bmRpbmcgY29ycmVjdCB0aGF0IGZvciBibG9jazEgcmVxdWVzdHMgYWxsIHRoZSByZXF1ZXN0IG9w dGlvbnMgYXJlIGR1cGxpY2F0ZWQgaW4gYWxsIHRoZSBibG9ja3M/IEkgY291bGQgbm90IGZpbmQg YSBjbGVhciBzdGF0ZW1lbnQsIGJ1dCBvbmNlIGFnYWluIHRoZSBmaWd1cmVzIGluIDc5NTkgc2hv dyB0aGUgVVJJIGZvciBlYWNoIGJsb2NrLiBUaGUgVVJJIHBhdGggYW5kIHF1ZXJ5IG9wdGlvbnMg Y2FuIGJlIGxvbmcsIGFuZCB0YWtlIGNvbnNpZGVyYWJsZSBzcGFjZSBpbiBlYWNoIGJsb2NrLiZu YnNwOzwvc3Bhbj48L3NwYW4+PC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5 bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBicmVhay1iZWZvcmU6IHBh Z2U7Ij48Zm9udCBmYWNlPSJIZWx2ZXRpY2EiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJiYWNrZ3Jv dW5kLWNvbG9yOiByZ2IoMjU1LCAyNTMsIDI0NSk7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxNHB4OyIgY2xhc3M9IiI+Q291bGQgcmVxdWVzdCB0b2tlbiBiZSB0aGUgaWRlbnRp ZmllciBmb3IgcmVxdWVzdCBvcHRpb25zLCBzbyB0aGF0IG9ubHkgMXN0IGJsb2NrIHdvdWxkIGhh dmUgZnVsbCBvcHRpb25zIGFuZCBsYXRlciBvbmVzIG9ubHkgdGhlIHRoZSByZXF1ZXN0IHRhZz8g PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgYmFja2dy b3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyIg Y2xhc3M9IiI+ICA8L3NwYW4+PC9wcmU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNpbmNlcmVseSw8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+LSBMYXVyaTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv ZGl2Pg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2Vk LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8g YW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBj b3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_B57FD1F880A24B5396A5DBD1489F0692armcom_-- From nobody Wed Jan 20 02:08:22 2021 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 A43943A0FAD for ; Wed, 20 Jan 2021 02:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 YOVjzEUZlG1C for ; Wed, 20 Jan 2021 02:08:19 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7705A3A0F7F for ; Wed, 20 Jan 2021 02:08:19 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4DLLnY5rPgz8spl; Wed, 20 Jan 2021 11:08:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1611137297; bh=F3KaR3SXa9E03TeZZqWTLyvJFvBtJF6KoWYJw/sdtHw=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=gSxLcxegkOfjIRr3GgQFa755h+55jY77/KRHzPua9MV5gebu2J7d8kyZZENc1RZFr MHaOchCKbroWA7H+wgg++tHVdsia0O5tidrLP4kk1teGc79Gi/F5dEHx4AhfQXKZ1N S7XUy/xw2+8Vw/S0HQITHyk6/1dpHa2VeaeDHhOFbx5MNZPIxZeVNCwTFLmf+1y5CC sI47SCjVESnfaxEYKk1AmEq+QL8TgyrHjpDiSNdESfGd10c1z6t99ol7AkEx11ANuZ Bmx3VNOOCuSFB2ews+cXEmwtDlrDhhk1MfS+84hQDypoKIpiVkkbntSXa3ucRSimEq a13Y5CXhmWzGg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.51]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4DLLnY4kzFz2xDc; Wed, 20 Jan 2021 11:08:17 +0100 (CET) From: To: Lauri Piikivi , "core@ietf.org" Thread-Topic: Request-Token (in draft-ietf-core-new-block-06 and draft-ietf-core-echo-request-tag-11) Thread-Index: AQHW7w+AXy8B2TA/Tky41ga77K+Dl6owR14Q Date: Wed, 20 Jan 2021 10:08:16 +0000 Message-ID: <32212_1611137297_60080111_32212_473_1_787AE7BB302AE849A7480A190F8B9330315BD735@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330315BD735OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Request-Token (in draft-ietf-core-new-block-06 and 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: Wed, 20 Jan 2021 10:08:22 -0000 --_000_787AE7BB302AE849A7480A190F8B9330315BD735OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGF1cmksDQoNClRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnQuDQoNCmRyYWZ0LWlldGYtY29y ZS1lY2hvLXJlcXVlc3QtdGFnLTExI3NlY3Rpb24tNCBkZXNjcmliZXMgdGhlIHJlYXNvbnMgd2h5 IHRva2VuIGhhbmRsaW5nIG9mIDcyNTIgc2hvdWxkIGJlIHVwZGF0ZWQuIFBsZWFzZSBsb29rIGF0 IHRob3NlLiBXaXRoIHRoYXQgdXBkYXRlIGluIG1pbmQsIHRva2VuIHdpbGwgbmVlZCB0byBiZSB1 cGRhdGVkIGZvciBlYWNoIHJlcXVlc3Qgd2l0aCBhIG5ldyBibG9jay4NCg0KUmVxdWVzdHMtVGFn IGlzIHVzZWQgaW4gdGhlIG5ldy1ibG9jayB0byBiaW5kIGJsb2NrcyBvZiB0aGUgc2FtZSBmcmFn bWVudGVkIHJlcXVlc3QuIFNlY3Rpb24gNSBvZiB0aGUgbmV3LWJsb2NrIEktRCBjYWxscyBvdXQg dGhhdCB0aGUgYXV0aG9yaXRhdGl2ZSBiZWhhdmlvciBpcyB0aGUgdXBkYXRlZCBvbmUgaW4gZHJh ZnQtaWV0Zi1jb3JlLWVjaG8tcmVxdWVzdC10YWcuDQoNClBsZWFzZSBsZXQgdXMga25vdyBpZiBh bnkgY2xhcmlmaWNhdGlvbiBpcyBuZWVkZWQgdG8gdGhlIG5ldy1ibG9jayBJLUQuDQoNCkNoZWVy cywNCk1lZA0KDQpEZSA6IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxh IHBhcnQgZGUgTGF1cmkgUGlpa2l2aQ0KRW52b3nDqSA6IG1lcmNyZWRpIDIwIGphbnZpZXIgMjAy MSAxMDozNQ0Kw4AgOiBjb3JlQGlldGYub3JnDQpPYmpldCA6IFtjb3JlXSBSZXF1ZXN0LVRva2Vu IChpbiBkcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrLTA2IGFuZCBkcmFmdC1pZXRmLWNvcmUtZWNo by1yZXF1ZXN0LXRhZy0xMSkNCg0KSGkgYWxscywNCg0KSSByZWFkIHRoZSBuZXcgYmxvY2sgd2l0 aCBpbnRlcmVzdCBhbmQgc3RhcnRlZCB3b25kZXJpbmcgYWJvdXQgdGhlIHJlcXVlc3QgdGFnLiBX aHkgZG8gd2UgbmVlZCBuZXcgdGFnLCB3aGVuIHdlIGhhdmUgdGhlIGJhc2ljIENPQVAgdG9rZW4u IFRva2VuIGlzIHVzZWQgdG8gbWF0Y2ggcmVxdWVzdCBhbmQgcmVzcG9uc2UsIGFuZCBpbiBkb2lu ZyB0aGF0IGl0IGRvZXMgaWRlbnRpZnkgdGhlIHJlcXVlc3QgYmxvY2tzIGFuZCByZXNwb25zZSBi bG9ja3MgdG8gYmUgcGFydCBvZiB0aGUgc2FtZSByZXF1ZXN0IGFuZCByZXNwb25zZS4NCg0KSW4g YmxvY3dpc2UgdHJhbnNmZXIgNzk1OSAsIHRoZSBtZXNzYWdlIElEcyBjaGFuZ2UgYnV0IHRva2Vu IGNvbWJpbmVzIHRoZW0gdG9nZXRoZXIuIFNhbWUgc2VlbXMgdXNhYmxlIGluIHRoZSBuZXctYmxv Y2sgYXBwcm9hY2guIEl0IGlzIHRoZSBzYW1lIHJlcXVlc3QsIHNvIHRoZXkgc2hvdWxkIGhhdmUg dGhlIHNhbWUgdG9rZW4uIFJGQyA3OTU5IGRvZXMgbm90IHNheSBhIHdob2xlIGxvdCBhYm91dCB0 b2tlbnMgIkFzIGEgZ2VuZXJhbCBjb21tZW50IG9uIHRva2VucywgdGhlcmUgaXMgbm8gb3RoZXIg bWVudGlvbiBvZiB0b2tlbnMgaW4gdGhpcyBkb2N1bWVudCwgYXMgYmxvY2std2lzZSB0cmFuc2Zl cnMgaGFuZGxlIHRva2VucyBsaWtlIGFueSBvdGhlciBDb0FQIGV4Y2hhbmdlLiBBcyB1c3VhbCwg dGhlIGNsaWVudCBpcyBmcmVlIHRvIGNob29zZSB0b2tlbnMgZm9yIGVhY2ggZXhjaGFuZ2UgYXMg aXQgbGlrZXMu4oCdIFRoaXMgY291bGQgYmUgY2xhcmlmaWVkLiBNeSB1bmRlcnN0YW5kaW5nIGlz IHRoYXQgdGhlIHRva2VuIGlzIHRoZSBzYW1lIGZvciBhbGwgYmxvY2tzIG9mIGEgcmVxdWVzdCBh bmQgcmVzcG9uc2UuICBUaGlzIGlzIHNob3duIGZvciBleGFtcGxlIGluIHRoZSBGaWd1cmUgMTMg b2YgNzk1OS4NCg0KTXkgd29uZGVyaW5nIHN0YXJ0ZWQgZnJvbSByZWFkaW5nIHRoZSAgZHJhZnQt aWV0Zi1jb3JlLW5ldy1ibG9jay0wNi4gSXQgc3RhdGVzIHRoZW4gbmVlZCBmb3IgcmVxdWVzdCB0 YWcsIGFuZCBpbiBleGFtcGxlIDkuMS4xICBzaG93cyB0aGUgYmFzaWMgdG9rZW5zIGFzIGRpZmZl cmVudCBmb3IgdGhlIGZyYWdtZW50ZWQgcmVxdWVzdC4gSXMgdGhhdCBhbiBlcnJvcj8gU2hvdWxk IHRoZSBiYXNpYyB0b2tlbnMgYmUgdGhlIHNhbWU/IEFuZCBpZiB0aGUgdG9rZW5zIGFyZSB0aGUg c2FtZSwgdGhlIHJlcXVlc3QtdGFnIHNlZW1zIHVubmVjZXNzYXJ5Lg0KDQpJIGRpZCByZWFkIHRo ZSBkcmFmdC1pZXRmLWNvcmUtZWNoby1yZXF1ZXN0LXRhZy0xMSB0byB1bmRlcnN0YW5kIHRoZSBy ZXF1ZXN0LXRva2VuIGJldHRlciwgYnV0IEkgZm91bmQgdGhlIGRlc2NyaXB0aW9uIGEgYml0IGhh cmQgdG8gZm9sbG93LiBJdCBzYXlzIGluIGluIGNocCAzLjIgdGhhdCAgIlRoZSBSZXF1ZXN0LVRh ZyBpcyBpbnRlbmRlZCBmb3IgdXNlIGFzIGEgc2hvcnQtbGl2ZWQgaWRlbnRpZmllciBmb3Iga2Vl cGluZyBhcGFydCBkaXN0aW5jdCBibG9jay13aXNlIHJlcXVlc3Qgb3BlcmF0aW9ucyBvbiBvbmUg cmVzb3VyY2UgZnJvbSBvbmUgY2xpZW504oCdDQoNCkJ1dCBvbiB0aGUgd2lyZSB0aGVyZSBpcyBh bHJlYWR5IHRoZSB0b2tlbiBzcGVjaWZpZWQgaW4gNzI1MiBjaHAgNS4zLjEgIkEgdG9rZW4gaXMg aW50ZW5kZWQgZm9yIHVzZSBhcyBhIGNsaWVudC1sb2NhbCBpZGVudGlmaWVyIGZvciAgZGlmZmVy ZW50aWF0aW5nIGJldHdlZW4gY29uY3VycmVudCByZXF1ZXN0cyAoc2VlIFNlY3Rpb24gNS4zPGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjUyI3NlY3Rpb24tNS4zPinigJ0uDQoNCg0K DQpJIGRvIG5vdCB1bmRlcnN0YW5kIGV4YWN0bHkgd2hhdCBpcyBtZWFudCBieSAgIlRoZSBibG9j ay13aXNlIGZ1bmN0aW9uYWxpdHkgZG9lcyBub3Qgc3VwcG9ydCB0aGUgZGV0ZWN0aW9uIG9mIGlu dGVyY2hhbmdlZCBibG9ja3MgYmV0d2VlbiBkaWZmZXJlbnQgbWVzc2FnZSBib2RpZXMgdG8gdGhl IHNhbWUgcmVzb3VyY2UgaGF2aW5nIHRoZSBzYW1lIGJsb2NrIG51bWJlcuKAnSBpbiAgdGFnLTEx IGNocCAzLjEuIElzIHRoZSBtZXNzYWdlIGJvZHkgdGhlIHBheWxvYWQ/ICBJZiB0aGUgcmVxdWVz dHMgY29tZSBmcm9tIHNhbWUgY2xpZW50LCB0aGV5IG11c3QgaGF2ZSBkaWZmZXJlbnQgdG9rZW5z LCBwZXIgcmZjIDcyNTIuDQoNCg0KSXMgdGhlcmUgc29tZSBwcm9ibGVtIGluIHRva2VuIHRoYXQg SSBmYWlsIHRvIHVuZGVyc3RhbmQgbm93IOKAlCBuZWNlc3NpdGF0aW5nIHRoZSByZXF1ZXN0LXRv a2VuPw0KDQoNCg0KSW4gc2ltaWxhciB2ZWluLCBhbmQgYXMgYSB1c2UgY2FzZSB3aGVyZSByZXF1 ZXN0IHRva2VuIHNlZW1zIGdvb2QsIGlzIHRoZSB1bmRlcnN0YW5kaW5nIGNvcnJlY3QgdGhhdCBm b3IgYmxvY2sxIHJlcXVlc3RzIGFsbCB0aGUgcmVxdWVzdCBvcHRpb25zIGFyZSBkdXBsaWNhdGVk IGluIGFsbCB0aGUgYmxvY2tzPyBJIGNvdWxkIG5vdCBmaW5kIGEgY2xlYXIgc3RhdGVtZW50LCBi dXQgb25jZSBhZ2FpbiB0aGUgZmlndXJlcyBpbiA3OTU5IHNob3cgdGhlIFVSSSBmb3IgZWFjaCBi bG9jay4gVGhlIFVSSSBwYXRoIGFuZCBxdWVyeSBvcHRpb25zIGNhbiBiZSBsb25nLCBhbmQgdGFr ZSBjb25zaWRlcmFibGUgc3BhY2UgaW4gZWFjaCBibG9jay4NCg0KQ291bGQgcmVxdWVzdCB0b2tl biBiZSB0aGUgaWRlbnRpZmllciBmb3IgcmVxdWVzdCBvcHRpb25zLCBzbyB0aGF0IG9ubHkgMXN0 IGJsb2NrIHdvdWxkIGhhdmUgZnVsbCBvcHRpb25zIGFuZCBsYXRlciBvbmVzIG9ubHkgdGhlIHRo ZSByZXF1ZXN0IHRhZz8NCg0KU2luY2VyZWx5LA0KLSBMYXVyaQ0KDQpJTVBPUlRBTlQgTk9USUNF OiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2Ug aXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBh bnkgbWVkaXVtLiBUaGFuayB5b3UuDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_787AE7BB302AE849A7480A190F8B9330315BD735OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRN TCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZv cm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6 bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAu ODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIExhdXJp LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmsgeW91IGZvciB0aGUg Y29tbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ ZHJhZnQtaWV0Zi1jb3JlLWVjaG8tcmVxdWVzdC10YWctMTEjc2VjdGlvbi00IGRlc2NyaWJlcyB0 aGUgcmVhc29ucyB3aHkgdG9rZW4gaGFuZGxpbmcgb2YgNzI1MiBzaG91bGQgYmUgdXBkYXRlZC4g UGxlYXNlIGxvb2sgYXQNCiB0aG9zZS4gV2l0aCB0aGF0IHVwZGF0ZSBpbiBtaW5kLCB0b2tlbiB3 aWxsIG5lZWQgdG8gYmUgdXBkYXRlZCBmb3IgZWFjaCByZXF1ZXN0IHdpdGggYSBuZXcgYmxvY2su PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlcXVlc3Rz LVRhZyBpcyB1c2VkIGluIHRoZSBuZXctYmxvY2sgdG8gYmluZCBibG9ja3Mgb2YgdGhlIHNhbWUg ZnJhZ21lbnRlZCByZXF1ZXN0LiBTZWN0aW9uIDUgb2YgdGhlIG5ldy1ibG9jayBJLUQgY2FsbHMg b3V0IHRoYXQNCiB0aGUgYXV0aG9yaXRhdGl2ZSBiZWhhdmlvciBpcyB0aGUgdXBkYXRlZCBvbmUg aW4gZHJhZnQtaWV0Zi1jb3JlLWVjaG8tcmVxdWVzdC10YWcuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlBsZWFzZSBsZXQgdXMga25vdyBpZiBhbnkgY2xh cmlmaWNhdGlvbiBpcyBuZWVkZWQgdG8gdGhlIG5ldy1ibG9jayBJLUQuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWVkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGUmbmJzcDs6 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGll dGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gTGF1cmkgUGlpa2l2aTxicj4NCjxiPkVudm95 w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAyMCBqYW52aWVyIDIwMjEgMTA6MzU8YnI+DQo8Yj7DgCZu YnNwOzo8L2I+IGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFtjb3JlXSBS ZXF1ZXN0LVRva2VuIChpbiBkcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrLTA2IGFuZCBkcmFmdC1p ZXRmLWNvcmUtZWNoby1yZXF1ZXN0LXRhZy0xMSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQi PkhpIGFsbHMsPC9zcGFuPiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5JIHJlYWQgdGhlIG5ldyBibG9j ayB3aXRoIGludGVyZXN0IGFuZCBzdGFydGVkIHdvbmRlcmluZyBhYm91dCB0aGUgcmVxdWVzdCB0 YWcuIFdoeSBkbyB3ZSBuZWVkIG5ldyB0YWcsIHdoZW4gd2UgaGF2ZSB0aGUgYmFzaWMgQ09BUCB0 b2tlbi4gVG9rZW4gaXMgdXNlZCB0byBtYXRjaCByZXF1ZXN0IGFuZCByZXNwb25zZSwgYW5kIGlu IGRvaW5nIHRoYXQgaXQNCiBkb2VzIGlkZW50aWZ5IHRoZSByZXF1ZXN0IGJsb2NrcyBhbmQgcmVz cG9uc2UgYmxvY2tzIHRvIGJlIHBhcnQgb2YgdGhlIHNhbWUgcmVxdWVzdCBhbmQgcmVzcG9uc2Uu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+SW4gYmxvY3dpc2UgdHJhbnNmZXIg Nzk1OSAsIHRoZSBtZXNzYWdlIElEcyBjaGFuZ2UgYnV0IHRva2VuIGNvbWJpbmVzIHRoZW0gdG9n ZXRoZXIuIFNhbWUgc2VlbXMgdXNhYmxlIGluIHRoZSBuZXctYmxvY2sgYXBwcm9hY2guIEl0IGlz IHRoZSBzYW1lIHJlcXVlc3QsIHNvIHRoZXkgc2hvdWxkIGhhdmUgdGhlIHNhbWUgdG9rZW4uIFJG QyA3OTU5IGRvZXMgbm90DQogc2F5IGEgd2hvbGUgbG90IGFib3V0IHRva2VucyAmcXVvdDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkFzIGEgZ2VuZXJhbCBjb21tZW50IG9u IHRva2VucywgdGhlcmUgaXMgbm8gb3RoZXImbmJzcDttZW50aW9uIG9mIHRva2VucyBpbiB0aGlz IGRvY3VtZW50LCBhcyBibG9jay13aXNlIHRyYW5zZmVycyBoYW5kbGUmbmJzcDt0b2tlbnMgbGlr ZSBhbnkgb3RoZXIgQ29BUCBleGNoYW5nZS4gQXMgdXN1YWwsIHRoZSBjbGllbnQgaXMgZnJlZSB0 byZuYnNwO2Nob29zZQ0KIHRva2VucyBmb3IgZWFjaCBleGNoYW5nZSBhcyBpdCBsaWtlcy7igJ0g VGhpcyBjb3VsZCBiZSBjbGFyaWZpZWQuIE08L3NwYW4+eSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQg dGhlIHRva2VuIGlzIHRoZSBzYW1lIGZvciBhbGwgYmxvY2tzIG9mIGEgcmVxdWVzdCBhbmQgcmVz cG9uc2UuICZuYnNwO1RoaXMgaXMgc2hvd24gZm9yIGV4YW1wbGUgaW4gdGhlIEZpZ3VyZSAxMyBv ZiA3OTU5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+TXkgd29uZGVyaW5nIHN0YXJ0ZWQg ZnJvbSByZWFkaW5nIHRoZSAmbmJzcDtkcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrLTA2LiBJdCBz dGF0ZXMgdGhlbiZuYnNwO25lZWQgZm9yIHJlcXVlc3QgdGFnLCBhbmQgaW4mbmJzcDtleGFtcGxl IDkuMS4xJm5ic3A7IHNob3dzIHRoZSBiYXNpYyB0b2tlbnMgYXMgZGlmZmVyZW50IGZvciB0aGUg ZnJhZ21lbnRlZCByZXF1ZXN0LiBJcyB0aGF0IGFuIGVycm9yPw0KIFNob3VsZCB0aGUgYmFzaWMg dG9rZW5zIGJlIHRoZSBzYW1lPyBBbmQgaWYgdGhlIHRva2VucyBhcmUgdGhlIHNhbWUsIHRoZSBy ZXF1ZXN0LXRhZyBzZWVtcyB1bm5lY2Vzc2FyeS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0Ij5JIGRpZCByZWFkIHRoZSZuYnNwO2RyYWZ0LWlldGYtY29yZS1lY2hvLXJlcXVlc3Qt dGFnLTExIHRvIHVuZGVyc3RhbmQgdGhlIHJlcXVlc3QtdG9rZW4gYmV0dGVyLCBidXQgSSBmb3Vu ZCB0aGUgZGVzY3JpcHRpb24gYSBiaXQgaGFyZCB0byBmb2xsb3cuIEl0IHNheXMgaW4gaW4gY2hw IDMuMiB0aGF0ICZuYnNwOyZxdW90OzxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOiNGRkZERjUiPlRo ZQ0KIFJlcXVlc3QtVGFnIGlzIGludGVuZGVkIGZvciB1c2UgYXMgYSBzaG9ydC1saXZlZCBpZGVu dGlmaWVyIGZvciZuYnNwO2tlZXBpbmcgYXBhcnQgZGlzdGluY3QgYmxvY2std2lzZSByZXF1ZXN0 IG9wZXJhdGlvbnMgb24gb25lIHJlc291cmNlJm5ic3A7ZnJvbSBvbmUgY2xpZW50PC9zcGFuPuKA nTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7YmFja2dyb3VuZDojRkZGREY1Ij5C dXQgb24gdGhlIHdpcmUgdGhlcmUgaXMgYWxyZWFkeSZuYnNwO3RoZSB0b2tlbiZuYnNwO3NwZWNp ZmllZCBpbiA3MjUyIGNocCA1LjMuMSAmcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQiPkEgdG9rZW4gaXMgaW50ZW5kZWQgZm9yIHVzZSBhcyBhIGNsaWVudC1sb2NhbCBp ZGVudGlmaWVyIGZvciZuYnNwOyZuYnNwO2RpZmZlcmVudGlhdGluZw0KIGJldHdlZW4gY29uY3Vy cmVudCByZXF1ZXN0cyAoc2VlIDwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNzI1MiNzZWN0aW9uLTUuMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQi PlNlY3Rpb24gNS4zPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+KeKA nS4gJm5ic3A7PC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6IHBhZ2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5JIGRvIG5vdCB1bmRlcnN0YW5kIGV4YWN0bHkgd2hhdCBpcyBtZWFudCBieSZuYnNwOyAmcXVv dDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRkZGREY1Ij5UaGUgYmxvY2std2lzZSBmdW5jdGlv bmFsaXR5IGRvZXMgbm90IHN1cHBvcnQgdGhlIGRldGVjdGlvbiBvZiBpbnRlcmNoYW5nZWQgYmxv Y2tzIGJldHdlZW4gZGlmZmVyZW50IG1lc3NhZ2UgYm9kaWVzIHRvIHRoZSBzYW1lIHJlc291cmNl IGhhdmluZyB0aGUgc2FtZSBibG9jayBudW1iZXLigJ0gaW4mbmJzcDs8L3NwYW4+IHRhZy0xMSBj aHAgMy4xLiBJcyB0aGUgbWVzc2FnZSBib2R5IHRoZSBwYXlsb2FkPyZuYnNwOyA8c3BhbiBzdHls ZT0iYmFja2dyb3VuZDojRkZGREY1Ij5JZiB0aGUgcmVxdWVzdHMgY29tZSBmcm9tIHNhbWUgY2xp ZW50LCB0aGV5IG11c3QgaGF2ZSBkaWZmZXJlbnQgdG9rZW5zLCBwZXIgcmZjIDcyNTIuIDwvc3Bh bj48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOiBw YWdlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtiYWNrZ3JvdW5kOiNGRkZERjUiPklzIHRoZXJlIHNvbWUg cHJvYmxlbSBpbiB0b2tlbiB0aGF0IEkgZmFpbCB0byB1bmRlcnN0YW5kIG5vdyDigJQgbmVjZXNz aXRhdGluZyB0aGUgcmVxdWVzdC10b2tlbj8mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTogcGFnZSI+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTogcGFnZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7YmFja2dy b3VuZDojRkZGREY1Ij5JbiBzaW1pbGFyIHZlaW4sIGFuZCBhcyBhIHVzZSBjYXNlIHdoZXJlIHJl cXVlc3QgdG9rZW4gc2VlbXMgZ29vZCwgaXMgdGhlIHVuZGVyc3RhbmRpbmcgY29ycmVjdCB0aGF0 IGZvciBibG9jazEgcmVxdWVzdHMgYWxsIHRoZSByZXF1ZXN0IG9wdGlvbnMgYXJlIGR1cGxpY2F0 ZWQgaW4gYWxsIHRoZSBibG9ja3M/IEkgY291bGQgbm90IGZpbmQgYSBjbGVhciBzdGF0ZW1lbnQs IGJ1dCBvbmNlIGFnYWluIHRoZSBmaWd1cmVzIGluIDc5NTkgc2hvdyB0aGUgVVJJIGZvciBlYWNo IGJsb2NrLiBUaGUgVVJJIHBhdGggYW5kIHF1ZXJ5IG9wdGlvbnMgY2FuIGJlIGxvbmcsIGFuZCB0 YWtlIGNvbnNpZGVyYWJsZSBzcGFjZSBpbiBlYWNoIGJsb2NrLiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOiBwYWdlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZjtiYWNrZ3JvdW5kOiNGRkZERjUiPkNvdWxkIHJlcXVlc3QgdG9rZW4gYmUgdGhlIGlkZW50 aWZpZXIgZm9yIHJlcXVlc3Qgb3B0aW9ucywgc28gdGhhdCBvbmx5IDFzdCBibG9jayB3b3VsZCBo YXZlIGZ1bGwgb3B0aW9ucyBhbmQgbGF0ZXIgb25lcyBvbmx5IHRoZSB0aGUgcmVxdWVzdCB0YWc/ Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW5jZXJlbHksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIExhdXJpPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTVBPUlRBTlQgTk9USUNFOiBUaGUgY29u dGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwg YW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90 IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLA0KIHVzZSBpdCBmb3Ig YW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRp dW0uIFRoYW5rIHlvdS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2Nl cHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4K ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh dXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B9330315BD735OPEXCAUBMA2corp_-- From nobody Wed Jan 20 04:43:37 2021 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 027913A11D3 for ; Wed, 20 Jan 2021 04:43:36 -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, MSGID_FROM_MTA_HEADER=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=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 2d47dmCPGxY3 for ; Wed, 20 Jan 2021 04:43:33 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2056.outbound.protection.outlook.com [40.107.22.56]) (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 D01C33A11D0 for ; Wed, 20 Jan 2021 04:43:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eQaZBgA8TeHLm372V6AmtyxNP4i9jxigcetXHXNPWupq+8ptqWeYoG826NcQ7gGGIsVdAoqmSOAP+Ehy5QcVVjlPnFlcSuCa5/53MmO8osHNiKuv4IJcIo9dDLBu4wtUmejeeVAYTlyTh/yVACvCuYRDwpsMIBFmuNG2Tw2PcMmVBIupLtV6H4kHXr+SwpnecJsdg8ajU9VYZvOvM/9Q2KRO25p2ZzpUi3pT8FDL3ZqTkjZyqBibPPW4evPZYNqivSdfA8xKE6l6r+gcNp1P6knARm60jLsAaxkleH/bT5EQCTj5O93jC0uojiv1Ukyx12HOpVmqdBIzYex+zqNfLA== 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=4B4ivqORJKOFpEUXElWk3H+1B3LmNB4J3V8f7xk0pDE=; b=gPxvboD4g+PS4GBY5hgvW3rn5ArZMWvgc9Uw/H+pwA9v3TBoyQ1Qz8eU0V++xeRHq3QauW5o8p9s63X51UfVdqThGe/EHqlRWdZXoweVFflrwq4IEuxvam53VCFKj5e8K2mr9NWtkNezOdp1EB1TJ4fUCuZpTzNm8BlUr8W0BVBYZ1TYe8aRqRbPmhfNS5daWBPgbVhc+epPFhK6tJBpmUIePyGcnzj5ckX+NMiKHL6LTzfUcAUE9ivII4JZdfIrrB48/QySrALG7M1VWMhmr/3MbuMR0dTEXKoeBZOfRP295KaILtbC2+9apgj3tB2sqPowBb/MTajRxGB1LfmtIQ== 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=4B4ivqORJKOFpEUXElWk3H+1B3LmNB4J3V8f7xk0pDE=; b=IiijHw5akfh6ZoV7/6FGYgxhU/kSgfBpDGu4vQLTtlvrIbmNoQmGAoZwGXlAjq6Vcmpqy7MUwv7LUVcFBgK4FICeEvUBWafQjFguDPnDc3UAJllWj0vvEini81gH43OHOQTR6NIa+zjGW+ATXDcekHPkL5c83fQh8un/HGg8pGo= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from PR3P189MB1034.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:40::19) by PA4P189MB1230.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:cb::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.10; Wed, 20 Jan 2021 12:43:30 +0000 Received: from PR3P189MB1034.EURP189.PROD.OUTLOOK.COM ([fe80::5581:9ee4:ee75:e018]) by PR3P189MB1034.EURP189.PROD.OUTLOOK.COM ([fe80::5581:9ee4:ee75:e018%9]) with mapi id 15.20.3763.014; Wed, 20 Jan 2021 12:43:29 +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, 20 Jan 2021 13:43: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="gGnGPicmr0z4xkFIA1O6pwBuobGSwFivx" X-Originating-IP: [86.106.103.103] X-ClientProxiedBy: HE1PR07CA0041.eurprd07.prod.outlook.com (2603:10a6:7:66::27) To PR3P189MB1034.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:40::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.2.10] (86.106.103.103) by HE1PR07CA0041.eurprd07.prod.outlook.com (2603:10a6:7:66::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.6 via Frontend Transport; Wed, 20 Jan 2021 12:43:29 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1b91f92b-ccec-43a0-6581-08d8bd40fd28 X-MS-TrafficTypeDiagnostic: PA4P189MB1230: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: HyocyT6W74HuTum6NGhQZSVBHu6mguXwx4TIX7Eh6dwsJtVg+Ar5pYFXz4IPeLFDvO8O7hzuE2FMJ25f6ZsTywUE+NjE3UwAfYjbevmFT2ODJrvRu0KpHvxPsLG7FdSeiez+orY8gmXWqY932FVb8+CzkcrC4dur2K2dhD4vUwuVaqY0SpUEyqUy1XfXigyOqDD8TFufqHv9HqanwJAJEbWgOKjdx6rj8V41RvgvN8PW2CL36rKZgRnTcLnXNIeillPrHVODs4SCBBjnmoXYWIlgS1a3uda3cDbztF4wV+7bl+U9J5c4Hn7jUGx+hjXagBbDzbn0J7XaFS7ZMgKEQgF53TIVDDvdENNm+Nd3R8Pxyb8pCBkipPDfufxjn11ES+NCUfwr6AGE66yqER2PAD7nH9tS8aB/J30j3RwT04Pfm5HzigPXFoCibIrYexCUlnw+WnVV64E1S56I155Q1nlhF80QySBwGRJQz4LFyyXm6sD4FJC+jKwhaFl+GqA2L92QTqSJGIJ5N8PZq5BvMDlONOKGFgmHRE2Z7kuzfGWZtFk5wJSL8NkHHYfu9HLBafmzl0sHjBo0E/OpeeQl472Lki7zN62n0YXP2bZQyXxIBXyt2n8MqnFReFAj5BTRIORHwTOtirN6ZIpjKhfpRC4+CaJioHaSTIWAt34hFXg8oox+2Gruu62241RaVawI X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3P189MB1034.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(136003)(396003)(376002)(366004)(16799955002)(478600001)(316002)(21480400003)(2906002)(5660300002)(6916009)(86362001)(8936002)(31686004)(956004)(31696002)(16526019)(2616005)(66556008)(8676002)(16576012)(6486002)(44832011)(6666004)(33964004)(66574015)(186003)(26005)(966005)(235185007)(83380400001)(52116002)(36756003)(66946007)(66476007)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?TE1kMGwzSTVwTmNOMzZ4YTBnMFB2UkxtTG95bEh4VHJLRUROY0NsZGZLM0w5?= =?utf-8?B?R2x1RDB1dEducVRLR0Z6dDdZVW5CSUZ2RExPNG9PbjhEWGFmZEVrZEZRRThL?= =?utf-8?B?WEg4bDU4b3B5aE9uWmlyMUlLWWVwcURpTmVCK0NaOHZyWGJDUEEwZjdpRHNP?= =?utf-8?B?eUxCQWpMZWRwblFNYVJOTHErZ3dUYk53WGNNYVVSSTN4VFZFSFBPY29PUWJ0?= =?utf-8?B?UFhvS2ZRWTJVeTRXdVc2U0pMVmdlSVdFUUZ0Mjh0U2xTZE50d205bzY0cFV6?= =?utf-8?B?dG9LNGVkZWI1Z0I5SmRqWXV5ZkxlendXSi84cldYWFQ2dGlWTENGUWNYRkQ0?= =?utf-8?B?OVYvMEZabzlQdUF1amdUUkNJWHBnT2VvdlNZSlNkQ3dQdGZqWUVjOERoOUdY?= =?utf-8?B?cTAzaEhFNzFlMEY5L0szWnZhSzUzNjNpME54ZTZsL1pWQ3dkdkZOZWUwcTNH?= =?utf-8?B?YklhUFdONnZPdzRnSXlUYUhmYVRvSkdVRnhUZUJzZVJYVFBsMjZBbW5IdEZC?= =?utf-8?B?VE9vNldGRmcvYXMyZFZ3eW02czFTdEp4WjQ0djdhN1lDeHlPM0lybnZXbjlj?= =?utf-8?B?NWcyazdoaURrV0JNS00vZ1RFMDNOOEhKV1VRMGIyOEVKeGJ3MEFiQ3o0Zkkz?= =?utf-8?B?bDYvZHdtL0R2V1lUczZlRE9PKzJnTkx6NTZVb05RUm9kZWxxRDdraTRPTEM1?= =?utf-8?B?OXRJNk9VL0cyNEMxdmk5WUdpekl4N2lVRldxVThvU2RrdnBPbmdCQnJJM0Fz?= =?utf-8?B?T1BhZStNTTQ5MmlUa2diZWxXZTFpT2l4c3dPTzdkNHMyS0luOGJLcHo2TVN2?= =?utf-8?B?blhxYlBqeVg2VWM4dFpiSHkyN2J6c283WHo1c0lNWU10dXhEWG1XeU8xR1RM?= =?utf-8?B?RmR1UGV1cDZLd0tnUG9RRWNyRDZlTnV5S2RwdFM5ZW1CM0x0VkJFVjRnT3Fp?= =?utf-8?B?TFN3WEtZSkFkTk51Wi84L0RzMTNzd21objlIQjNkUWdoejNXUEkxa1JCRkw4?= =?utf-8?B?Q0NQWTZtVWpVT2JLTjhZNHVXcWkwaFozMnVtWVNlamN0blZqV3dZOVRnSGp4?= =?utf-8?B?c3RSV1ptWFlhUDRWd0l0anFqTEROTEs5a01TZzZzNFNaa0JBVm1RcG5HTTZT?= =?utf-8?B?RnlPdFlNL054WWRhSzhPZ1JjV3hjT0tvY09jeG55VWlGcERaZGdJaDJraTIx?= =?utf-8?B?K25kWUtGSVdvVlNNMEM2Z0kvZGxmVFIySHdlaFdSd3hETWg1OU1LdVNNT0ZE?= =?utf-8?B?N2JRbW5CdjJoanp4b25LOVBPQURha3VzSzVuT2VwcnJCZnFFVEN0dWhDS1Ru?= =?utf-8?B?S250cFpQQWhNb1ZLS1FPWjlLeTIraW9saGx1UTFvUFVWZXRPT0ZldWY2VGtp?= =?utf-8?B?NDZ3RTFWalJPaERpL2JuZmo2a1JmM0JvZnZ0d2ROQXRVWlhWNDB1aXpwNnlU?= =?utf-8?Q?YHYAl40b?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 1b91f92b-ccec-43a0-6581-08d8bd40fd28 X-MS-Exchange-CrossTenant-AuthSource: PR3P189MB1034.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2021 12:43:29.8841 (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: QPzHpLCit63vxscyI+K7zN5Iy4XplVKG0r3W/yfJ7he1IhniH/Vds7T1UvVjKjbGKfDqG57q0Do0lIgsXJsIhQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4P189MB1230 Archived-At: Subject: [core] CoRE WG Virtual Interim 2021-01-21 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, 20 Jan 2021 12:43:36 -0000 --gGnGPicmr0z4xkFIA1O6pwBuobGSwFivx Content-Type: multipart/mixed; boundary="DkmuY84toq4Ty7dCBkmlF2iohSHulriue" --DkmuY84toq4Ty7dCBkmlF2iohSHulriue 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. The agenda is to discuss latest design developments and open points for the Cachable OSCORE document [1][2]. Please, find below the information to join the meeting. Best, Marco and Jaime [1] https://tools.ietf.org/html/draft-amsuess-core-cachable-oscore-00 [2] https://gitlab.com/chrysn/core-cachable-oscore/ =3D=3D=3D Meeting Information =3D=3D=3D Jabber: core@jabber.ietf.org Etherpad: https://codimd.ietf.org/notes-ietf-interim-2021-core-01-core?bo= th Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dm790e95229319dac1566d4677f2067d5= 6 Meeting number: 178 150 1389 Password: constrained More ways to join Join by video system Dial 1781501389@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: 178 150 1389 --=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 --DkmuY84toq4Ty7dCBkmlF2iohSHulriue-- --gGnGPicmr0z4xkFIA1O6pwBuobGSwFivx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmAIJWsACgkQ7iZktA5Y 2kOqxgf/RDa6X6wWV5qNFZ4dcbDzKs+q0psalWjA6XGds5SmM/JmWc7gzvU0aky7 2zaHnQRGQ5Wfl22VFUDZ4cMbqYRnsfX71hho4V1eQgvd0orHXx3FUqZ7Jl/Gv+t5 VGpMoqMihXVVrnigXA/qiIcw4TWlpsJ82Xyn1i8OPhuAvQCFO0Kfh4ywnykO8JoJ 8IZy+3INHqOmMx9WEGc2dYuqI6WXAtVes1RO4lxrJmfmbMeP8fRNnHRB678pYaR4 fl3pav0KPLfh7CtWslU9nfdiS9hS1scsPRCOqhh42/3eNJy8/9TIyOUF/Nr7GeKE U93zzrX8mfoJAZ/b/IzCfdkmvQirAw== =pBPY -----END PGP SIGNATURE----- --gGnGPicmr0z4xkFIA1O6pwBuobGSwFivx-- From nobody Wed Jan 20 06:05:55 2021 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 0719E3A1384; Wed, 20 Jan 2021 06:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, 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=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 AN6SHgPI-i9i; Wed, 20 Jan 2021 06:05:51 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2056.outbound.protection.outlook.com [40.107.20.56]) (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 CCD423A1386; Wed, 20 Jan 2021 06:05:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V7qf6TH6QqIgaPjEVuRHYNJZZUPQjlZsrGzW2SoJMp4K+1Pm/jUzt+1RE0P3mnCu/173oZZKBQS4RBZNG4L94aeoOqGt6WKag5YWSo0i3HSUn+tB3za0Aut/HFQAG2sPTRHprGM1r/48lC73iyPAMxzNvuYpUBM2RXgEmjJ/Uf345wfX5xvYT8pQybZ2Wm+Nf3VrM+0YvfC/ZSXN1ThPOq9nsRyfwJRGnbFMvNK3ddpEjuyG4V5Ajfn+y/j5L6sNM/VcnQYqLt01N1R+yk1gz2BCyjVpikUYs1O4Phx+4VnV5a+YS6ib1+k2VrlqYs+HgejY/vAAQ+aJ1CSJd0NxuQ== 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=I3BN/SccQhDjr28Q6sbKv1QL48jeQBHzctlqWC3wC3o=; b=l9z/raN2Wx7QUO47A+tc4G5os9JbfIfjGIRTy5ciATg/DHRGyvmQ8Z6YTHCUt6acgnkUJLCMnxSNp+88lUqAa0T6ekxx4Pig2uNu+1xsSuk8yDIwQlHQMP0lICS2gI+aFr1J7c5KAAh/rOtF66S9+8mXM64GaZe0CIUbQs/qq+IcuBBfMAeuaU54wzDyWppY6PeGSJXhoibETrwVHmBTjKoXCrscHWWj0sdY4h/Sxb2X7EghvU2c9g3/V4UW9shO5DCyReh3XuqTqHX2qqcTvkzgmQumfirGOi7TMK2wqHNIQnQXL6WnMByjGOXIoGn3Mf1ZybQV15CYf1UCiB3QjA== 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=I3BN/SccQhDjr28Q6sbKv1QL48jeQBHzctlqWC3wC3o=; b=BCf9PnqHgdqEp7GZcRahgUnQEswa2UDyKXnL3GOjRifb+HT4FHr4S9ffv8/Yr6oJPmx6w93j2C9rUMLzc8LYdRBSixChobKKrHipmrS2aHodMzTLQHvNyN3lp43lpXzKV187Pmy8gylDLGsYL7wD4q07TVmsqnot4jcLYkmNgac= Received: from (2603:10a6:7:82::14) by HE1PR0702MB3673.eurprd07.prod.outlook.com (2603:10a6:7:81::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.9; Wed, 20 Jan 2021 14:05:45 +0000 Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::fd09:b8f4:2698:e86]) by HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::fd09:b8f4:2698:e86%6]) with mapi id 15.20.3784.011; Wed, 20 Jan 2021 14:05:45 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Benjamin Kaduk , "draft-ietf-core-oscore-groupcomm@ietf.org" CC: "core@ietf.org" Thread-Topic: Concerns with EC key joint signature and DH usage in draft-ietf-core-oscore-groupcomm Thread-Index: AQHW6RfY9iCglnm+UUiICUuvD3s5raowqUSA Date: Wed, 20 Jan 2021 14:05:45 +0000 Message-ID: <9D7AAAF7-D8BF-46F2-B6D5-60BEEA836636@ericsson.com> References: <20210112191911.GT161@kduck.mit.edu> In-Reply-To: <20210112191911.GT161@kduck.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21011300 authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [83.249.67.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f5e8f2d1-4815-426e-0b2d-08d8bd4c7b34 x-ms-traffictypediagnostic: HE1PR0702MB3673: 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: /SnXpDDNmQTX/Se1ZWfAL4MgKgof7Of/EKTnLT/3Xr+gFXQ3Zo+V16R80cOAUpeeloVELKh4mWka15bWNX8+mPOXKSEvZBltUfOGzXt4P2gHODGLnu3hjxIMwwdqZHpfQq9tlXigXoCovEEbFCREPnVvSlq/BkKlYM/MU+5oBQgS+GmBHbkJsCjktESpEO9UFI/nqNLs1TZf7Eau+ySxlry0kh+rpeMFAGXB2xgsMPJG4iLmWqW1MXQmrOgVi3aD/c6JoCQNRrx44n+G2xIzeDBdfOcI2WylPOH6Q1ZKe+ZIZFahuJ4bnf7hAGMkI5WK+8LjHaLou0E6dB/PdVytj6jluOVM5ChsaN8D5VHwsca3GeGeJasU6Rs7jMPF1seM+BOKUnuCdqJeriRwAsKEM/CvphLGkhM2eIUr3NgZqE/RGHzs7HELXDikiznEKl0xchcMGNBJy8kYI/Hntvf6TGRdpxA9hBbDXnCRfGKhe6b2WTVsWP9jO5y9Ug0vLOuBBVoMP5bt9HYKk5tlr1Wxjg== 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)(136003)(346002)(396003)(376002)(39860400002)(366004)(83380400001)(2906002)(6512007)(316002)(478600001)(2616005)(6506007)(966005)(26005)(66446008)(66574015)(71200400001)(186003)(76116006)(33656002)(64756008)(66556008)(85202003)(36756003)(66946007)(5660300002)(85182001)(66476007)(6486002)(8676002)(110136005)(8936002)(86362001)(4326008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?UVJHS3ZvaGRzMnBycUdKZFQ0cGlnK0o1QmRkQnk1WlRxbUF0cy9pK0FGdzg1?= =?utf-8?B?Q0RVMjZ0dDhwdk0rUXdRbDZnZHE5T2trbk9PYVkwNVc2SGQxNjNpRVVlUUp3?= =?utf-8?B?LzVpOFNnNWN0cXJ4NnJoM1kvVVo0cFJaSHRGTFJORDkrUS9oUEVLUWZsdVdM?= =?utf-8?B?aXM5M2dObGN2TTgyYVE3aHlhUEZ6TEh3eVJQdXhpU0VRdVBTQ0xRbVM2M3BG?= =?utf-8?B?MEpIcWpBN1NHQWNtSFV5VTVBbzZKUWVYc3kyUDF3V054V0F2M2dueUF5NG5L?= =?utf-8?B?MWJYWkpNd05ueGgvVGZndWd2MWV6RGIvMUxuT0JqY1E3dlp0MUVEb0VPZGZL?= =?utf-8?B?REsvRG5md3c3dHhXa2RXYTdNUm9LT3g2NG83bnVHU3YyWVFkNkwrWVUwQ2tE?= =?utf-8?B?eG1tMnZjK0F3Z29GQjN6MWduYTc0bWx6V3BSeEhzdnd6QVBwYWdDREluY0da?= =?utf-8?B?cmREdmRva0lrWW1FYys0WHV1WFU0RUdhMUNid0xOMS9YWHZzcWd3ZWYyMmZM?= =?utf-8?B?N0h0alVNbHVIT1RyYStZWkVrSzIwM2ZNdCtkZkE0YkNEZVZDSVl3OEMrL1l2?= =?utf-8?B?SHVhdlB4VmdjS3FucW9vTkVET2ttV24xdjBEWGh0c0UydlB6c1h6a2tVOW9r?= =?utf-8?B?L2NyZSt2a0ptbjNSWGdoNXFEVXoreS9VdVRZQUUvempmRmdqOFp4TThOMkYr?= =?utf-8?B?bUFsT2hBSGUzMTJBdU1kalp5QUJNTG1QUkQ3TnhuSWFkcTFxYXhzUU01aWt3?= =?utf-8?B?a3hxam5vQU9ya3NHZklLeCtIemdqSk9LaHhOcUE2K1RBdk5ZVU91ellxb05m?= =?utf-8?B?eENTcDl6SmZmMENLNEZKc0tLejcya3NxdXE3MUkzR096M3dibUowN2VmRGpD?= =?utf-8?B?YmxISnhBZ1Bkb1cxaE9Od1daSmxOWkdObmRFU0NMaVlBSzh3TEZvMk9SU0Z1?= =?utf-8?B?ZUc3cDl5ZGdaY2pWbjAycnJ0Wk1LZ3pVd0x0NWZaaXQ1d2RoOHk2dUs2RVVT?= =?utf-8?B?RzA0T3d4Z0dKVVc3SzFsSlJVMVExMWlhbHhLbWdza3RRSk43RjlvMGd6MkJG?= =?utf-8?B?aVF3ZVJTT24rWEdQRVEwRXVTRGoxa1B4cjQ4ZGs2cFdBSDBXdFNsc1NMUW5j?= =?utf-8?B?RGMzYkcrWGtjTGx6Ulg0QXg2Y2hDd1ZUbGw0N3dIRFFKZ1NmYVJ5bWRtU0t6?= =?utf-8?B?VWtLUGJqZll3WEVHRUNCaUdYQzQ2aVZLVFpUUHFXMGRjMEtzV3JxVVRQTlF4?= =?utf-8?B?U2x0RGRIMDE2MzZteERVbUs5VUgvSlBSc01uYjdnQlFsZjRzbW1jcU8zSTJ5?= =?utf-8?Q?+0mkNDcB9mwDnAhYhe5Jf/QrYgSOyI6glI?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <39C1836AB276A445A0EAF1740D19AB55@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 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: f5e8f2d1-4815-426e-0b2d-08d8bd4c7b34 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2021 14:05:45.4338 (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: pjeSVt3d+L5qNKOUdJsr6Av3AuEjkfSU8miUv8dXU5KVh0ZIehLgM7qmAI4Rh6ygmITfWT0d++xcc0iOHGrsR5oN4t/o1p89jT8LAuD0C7U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3673 Archived-At: Subject: Re: [core] Concerns with EC key joint signature and DH usage in draft-ietf-core-oscore-groupcomm 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, 20 Jan 2021 14:05:54 -0000 DQpIaSBCZW4sDQoNClRoYW5rcyBmb3IgYnJpbmdpbmcgdXAgdGhpcyBhbHJlYWR5IGluIHRoZSBX Ry4gDQoNCkJlbG93IHdlIHJlY2FwIHRoZSByZWFzb25pbmcgd2hpY2ggbGVkIHRvIHVzZSB0aGUg c2FtZSBwdWJsaWMga2V5IGluIHBhaXJ3aXNlIG1vZGUgYXMgaW4gZ3JvdXAgbW9kZS4gVHJpZ2dl cmVkIGJ5IHlvdXIgbWFpbCB3ZSByZXZpc2l0ZWQgdGhlIHByb2JsZW0gYXJlYSBhbmQgd2UgYWdy ZWUgdGhhdCBzaW1wbHkgcmVmZXJyaW5nIHRvIFsxXSBhcyBpcyBjdXJyZW50bHkgZG9uZSBpcyBu b3Qgc3VmZmljaWVudCBtb3RpdmF0aW9uLiBNb3JlIGRldGFpbHMgZnVydGhlciBiZWxvdy4NCg0K DQoxLiBbMV0gZG9lcyBwcm92ZSB0aGUgam9pbnQgc2VjdXJpdHkgb2YgYSBESC1iYXNlZCBLRU0g YW5kIHNpZ25pbmcgdXNpbmcgRUNEU0Egb3IgZWxsaXB0aWMgY3VydmUgU2Nobm9yciBzaWduYXR1 cmVzLiBUaGUgS0VNIGlzIHRoZW4gdXNlZCBpbiBFQ0lFUywgYnV0IHRoYXQgZG9lcyBub3QgbGlt aXQgdGhlIHByb29mIHRvIHRoaXMgc2V0dGluZywgYW5kIHRoZSB1c2Ugb2Ygc3RhdGljIERIIGlu IHRoZSBwcm90b2NvbCBjYW4gYmUgbWFwcGVkIHRvIGEgS0VNIHNldHRpbmcuIA0KDQoyLiBXZSBt YWRlIGFuIGFzc2Vzc21lbnQgc2ltaWxhciBhcyBmb3IgU2lnbmFsJ3MgWDNESCBbMl0gd2hpY2gg dXNlcyB0aGUgc2FtZSBYRWREU0EgWzNdIGtleSBwYWlyIGZvciBESCBhbmQgc2lnbmluZyAodGhl IGNvbnZlcnNpb24gYmV0d2VlbiBFZHdhcmRzIGFuZCBNb250Z29tZXJ5IGNvb3JkaW5hdGVzIGlu IHRoYXQgY2FzZSBpcyBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24pLg0KDQozLiBUaGUgcGFpcndp c2UgbW9kZSBhcyBzcGVjaWZpZWQgaW4gdGhlIGRyYWZ0IHdvcmtzIHdpdGggc2VwYXJhdGUgc2ln bmF0dXJlIGFuZCBrZXkgYWdyZWVtZW50IGtleXMsIGJ1dCB0aGF0IHdvdWxkIGluY3VyIGRvdWJs ZSBvdmVyaGVhZCBib3RoIGluIHRlcm1zIG9mIGtleSBkaXN0cmlidXRpb24gYW5kIHN0b3JhZ2Uu IFRoZSBjb25zdHJ1Y3Rpb24gaW4gWzFdIGlzIGEgZGVzaXJhYmxlIG9wdGltaXphdGlvbiB0aGF0 IGhhcyBhbiBpbXBhY3Qgb24gcGVyZm9ybWFuY2UgaW4gY29uc3RyYWluZWQgc2V0dGluZ3MuDQoN CjQuIE9uZSBtYWpvciByZWFzb24gd2h5IHRvIG5vdCB1c2Ugb25lIGtleSB3aXRoIG11bHRpcGxl IGFsZ29yaXRobXMgaXMgYmVjYXVzZSB0aGVyZSBtYXkgYmUgdmFzdGx5IGRpZmZlcmVudCBwb2xp Y2llcyBhc3NvY2lhdGVkIHdpdGggdGhlIGRpZmZlcmVudCB1c2VzLiBUaGF0IGlzIG5vdCB0aGUg Y2FzZSBoZXJlLCB3aGVyZSB0aGUgcHVycG9zZSBvZiBib3RoIHVzZXMgaXMgdG8gcHJvdGVjdCB0 aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGVuZHBvaW50cyBkdXJpbmcgdGhlIHZhbGlkaXR5IG9m IHRoZSBncm91cCBjb250ZXh0Lg0KDQpXaXRoIHRoaXMgd2UgZm91bmQgaXQgbW90aXZhdGVkIHRv IHJlLXVzZSB0aGUgc2lnbmF0dXJlIGtleSBvZiBncm91cCBtb2RlIGFzIGtleSBhZ3JlZW1lbnQg a2V5IG9mIHRoZSBwYWlyd2lzZSBtb2RlLiBCdXQgdGhlIHNldHRpbmcgaXMgbm90IGlkZW50aWNh bCB0byB0aGUgbGl0ZXJhdHVyZSBzbyBhIGZ1cnRoZXIgbW90aXZhdGlvbiBpcyBuZWVkZWQuIFdl IGhhdmUgb3BlbmVkIGFuIGlzc3VlIG9uIHRoZSBDb1JFIFdHIGdpdGh1Yi4gQWxsb3cgdXMgdG8g Z2V0IGJhY2sgd2l0aCBtb3JlIGRldGFpbHMuIA0KDQpHw7ZyYW4NCg0KDQpbMV0gaHR0cHM6Ly9l cHJpbnQuaWFjci5vcmcvMjAxMS82MTUucGRmDQpbMl0gaHR0cHM6Ly9zaWduYWwub3JnL2RvY3Mv c3BlY2lmaWNhdGlvbnMveDNkaC8NClszXSBodHRwczovL3NpZ25hbC5vcmcvZG9jcy9zcGVjaWZp Y2F0aW9ucy94ZWRkc2EvDQoNCg0K77u/T24gMjAyMS0wMS0xMiwgMjA6MTksICJCZW5qYW1pbiBL YWR1ayIgPGthZHVrQG1pdC5lZHU+IHdyb3RlOg0KDQogICAgSGkgYWxsLA0KDQogICAgQSByZWNl bnQgZmVhdHVyZSByZXF1ZXN0IGZvciBvcGVuc3NsDQogICAgKGh0dHBzOi8vcHJvdGVjdDIuZmly ZWV5ZS5jb20vdjEvdXJsP2s9ZTRhM2E5MjAtYmIzODkwMjUtZTRhM2U5YmItODY5NTllNDcyMjQz LTI3YmIzNzhmZmJmNTg2YjkmcT0xJmU9MmZhZjUwNTAtNGEwZS00MTc2LTg3NjEtOGNjMjc1MmZk ZmUxJnU9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGb3BlbnNzbCUyRm9wZW5zc2wlMkZpc3N1 ZXMlMkYxMzYzMCkgcG9pbnRlZCBvdXQgdGhhdCB0aGlzDQogICAgZG9jdW1lbnQgcmF0aGVyIGJs aXRoZWx5IHByb3Bvc2VzIHRvIHJldXNlIHNpZ25hdHVyZSAoZS5nLiwgRWREU0EgYW5kDQogICAg RUNEU0EpIGtleXMgZm9yIHB1cnBvc2VzIG9mIEVDREgga2V5IGFncmVlbWVudC4gIChUaGlzIGlz IHBhcnQgb2YgdGhlDQogICAgInBhaXJ3aXNlIGtleXMiIGNvbnN0cnVjdGlvbiBpbiBTZWN0aW9u IDIuMywgc3BlY2lmaWNhbGx5IGluIDIuMy4xLikNCg0KICAgIFVzZSBvZiBhIGdpdmVuIGtleSB3 aXRoIG11bHRpcGxlIGFsZ29yaXRobXMgZGl2ZXJnZXMgZnJvbSBnZW5lcmFsDQogICAgY3J5cHRv Z3JhcGhpYyBiZXN0IHByYWN0aWNlLCBhbmQgSSBkbyBzZWUgdGhhdCB0aGlzIGRyYWZ0IGFja25v d2xlZGdlcw0KICAgIHRoaXMgZmFjdCBhbmQgYXR0ZW1wdHMgdG8ganVzdGlmeSB0aGUgY2hvaWNl IGluIHRoZSBzZWN1cml0eQ0KICAgIGNvbnNpZGVyYXRpb25zIChTZWN0aW9uIDEwLjEyKSB3aXRo IHJlZmVyZW5jZSB0byBbRGVnYWJyaWVsZV0NCiAgICAoaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXll LmNvbS92MS91cmw/az1mNzJkNGVhMy1hOGI2NzdhNi1mNzJkMGUzOC04Njk1OWU0NzIyNDMtZWE4 NzBjN2JhYmJjYjM4YyZxPTEmZT0yZmFmNTA1MC00YTBlLTQxNzYtODc2MS04Y2MyNzUyZmRmZTEm dT1odHRwcyUzQSUyRiUyRmVwcmludC5pYWNyLm9yZyUyRjIwMTElMkY2MTUpLiAgSG93ZXZlciwg SSBkbyBub3QgdGhpbmsgdGhhdCB0aGUNCiAgICBjdXJyZW50IGRpc2N1c3Npb24gKGluIHRoZSAt MTApIGlzIGFueXdoZXJlIGNsb3NlIHRvIHN1ZmZpY2llbnQNCiAgICBqdXN0aWZpY2F0aW9uIHRo YXQgdGhlIHByb3Bvc2VkIGJlaGF2aW9yIGlzIHNlY3VyZS4gIFNwZWNpZmljYWxseSwgdGhlDQog ICAgcmVmZXJlbmNlZCBwYXBlciBwcmltYXJpbHkgZm9jdXNlcyBvbiBtZXRob2RzIHVzZWQgZm9y IEVNViBzdGFuZGFyZHMsDQogICAgYW5kIGluIHBhcnRpY3VsYXIgbGltaXRzIGl0c2VsZiB0byBF Q0lFUyAod2hpY2ggY29tYmluZXMga2V5IGFncmVlbWVudA0KICAgIGFuZCBtZXNzYWdlIGVuY3J5 cHRpb24pLiAgV2hpbGUgT1NDT1JFIHByb3ZpZGVzIG1lY2hhbmlzbXMgY29uY2VwdHVhbGx5DQog ICAgc2ltaWxhciB0byBFQ0lFUywgdGhlIGFjdHVhbCBtZWNoYW5pY3Mgb2YgdGhlIGNyeXB0b2dy YXBoeSBhbmQgd2lyZQ0KICAgIHByb3RvY29sIGFyZSwgdG8gbXkga25vd2xlZGdlLCBkaWZmZXJl bnQsIGFuZCBzbyB0aGUgcmVmZXJlbmNlZCBwYXBlcg0KICAgIGRvZXMgbm90IHNlZW0gdG8gZGly ZWN0bHkgYXBwbHkuICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGF0dGVtcHQgdG8NCiAgICAiYnJp ZGdlIHRoZSBnYXAiIGJldHdlZW4gd2hhdCBpdCBkb2VzIGluIHByYWN0aWNlIGFuZCB0aGUNCiAg ICAoRUNJRVMtc3BlY2lmaWMpIHByb29mLCBzbyBiYXNlZCBvbiBteSBjdXJyZW50IHVuZGVyc3Rh bmRpbmcsIGl0IG11c3QNCiAgICBzdGlsbCBiZSBjb25zaWRlcmVkIGFzIGRlZnlpbmcgYmVzdCBj dXJyZW50IHByYWN0aWNlIHdpdGhvdXQgZm9ybWFsDQogICAgY3J5cHRvZ3JhcGhpYyBqdXN0aWZp Y2F0aW9uLg0KDQogICAgSW4gbXkgb3Bpbmlvbiwgd2UgbmVlZCB0byBlaXRoZXIgcHJvZHVjZSBh IHJlZmVyZW5jZS9wcm9vZiB0aGF0IGRvZXMNCiAgICBhcHBseSB0byBPU0NPUkUncyB1c2FnZSwg b3IgcmVtb3ZlIHRoaXMgbWVjaGFuaXNtIGZyb20gdGhlIHByb3RvY29sLg0KDQogICAgLUJlbg0K DQoNCg== From nobody Wed Jan 20 06:33:56 2021 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 9F8763A1409 for ; Wed, 20 Jan 2021 06:31:48 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=Nk0gQCvj; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=Nk0gQCvj 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 GPDSR5BSqUW6 for ; Wed, 20 Jan 2021 06:31:45 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30081.outbound.protection.outlook.com [40.107.3.81]) (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 E858D3A13E9 for ; Wed, 20 Jan 2021 06:31:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wLtJ3myJago08leeGx3wh6y9RcmdOeyITIvf18IgITM=; b=Nk0gQCvjEJTT9R6CbJRfBndXryeCXtH+rnkAL2bUdClX90PjB3XH7oP/19N9tRxj1/TIZWIJ8F6nwzcQQDDmf4bD9qamXD1TkFog11cgJpq2+UxwLJSiEZpmmqcHOtHS20hSoC3mwZfucpz6aQBeeZs4ywln2MzRCax08uczMsA= Received: from MR2P264CA0065.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:31::29) by DB8PR08MB5323.eurprd08.prod.outlook.com (2603:10a6:10:fa::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.11; Wed, 20 Jan 2021 14:31:42 +0000 Received: from VE1EUR03FT045.eop-EUR03.prod.protection.outlook.com (2603:10a6:500:31:cafe::7a) by MR2P264CA0065.outlook.office365.com (2603:10a6:500:31::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.13 via Frontend Transport; Wed, 20 Jan 2021 14:31:41 +0000 X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 63.35.35.123) smtp.mailfrom=pelion.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=none action=none header.from=pelion.com; Received-SPF: Fail (protection.outlook.com: domain of pelion.com does not designate 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT045.mail.protection.outlook.com (10.152.19.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.11 via Frontend Transport; Wed, 20 Jan 2021 14:31:41 +0000 Received: ("Tessian outbound 8418c949a3fa:v71"); Wed, 20 Jan 2021 14:31:41 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: ec67ad84cdaf4390 X-CR-MTA-TID: 64aa7808 Received: from 31da618f5f07.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 48EEB7D4-1470-4287-8383-5C0F825416DB.1; Wed, 20 Jan 2021 14:31:33 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 31da618f5f07.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 20 Jan 2021 14:31:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hp9ZecY1Ru0Y/DUi/ZQSnTkQdhuHbg2ePegIKu+WXMRmKEdEckw//RHOEkHQYXO4htiGqsNwcpifW0ShXSUyyA5Uk1ldZSHnsqa/noss+ycpujCqv7tabuTDrgwhzNJRbabix2sEOw3NeKp/4vaIkXITI6zXtpcbf/F8yy46mB4P/vMmc2QkE+nc8lcWMjHQC5qF0o/IpUNqewIfYYJGepPVqrCHCDvll6/14vQOKKjZi00D2kVl9xpgZguJifqgWP2/61Q8HHQrpRrz1kVHX6Q/ZbTEyYsBM7LnQ1GNN3oQWTJIIAuEqXgCaRWJEwvZwlAeDYh8WH3XxlsOEWLsyA== 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=wLtJ3myJago08leeGx3wh6y9RcmdOeyITIvf18IgITM=; b=fGb6jlTcM24p/0NeOL0QkcGwGJr0yRXqOoCK9YB4gDwUMhVWXs7rkjThloCmoJFj5R17nqF0XK9sEagFBRSRWYkbEnCV15ArCnmQZaqZrZLeIqPP1oygSnGvJ9biZLKLBU9aS04rsbZO1srbbdDrrT7u5a3S93EbulUdLaRXIpdyIYORnlvXDM4JprPMvzCS3VjiuUESneV8G3Zb3KTBtb3tayvkG2vh3FR6/rMdnFa0sV+mWMHXAw12GPOXBumlg881f9QySv0IDnT3RCuijVz6SLF1+AxYbC/Iu95WG92HeuNL7qxgcKKEL0tCgXujEKMSVcuJYn1xkEMWVkltag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=pelion.com; dmarc=pass action=none header.from=pelion.com; dkim=pass header.d=pelion.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wLtJ3myJago08leeGx3wh6y9RcmdOeyITIvf18IgITM=; b=Nk0gQCvjEJTT9R6CbJRfBndXryeCXtH+rnkAL2bUdClX90PjB3XH7oP/19N9tRxj1/TIZWIJ8F6nwzcQQDDmf4bD9qamXD1TkFog11cgJpq2+UxwLJSiEZpmmqcHOtHS20hSoC3mwZfucpz6aQBeeZs4ywln2MzRCax08uczMsA= Received: from HE1PR08MB2825.eurprd08.prod.outlook.com (2603:10a6:7:35::21) by HE1PR0802MB2348.eurprd08.prod.outlook.com (2603:10a6:3:c5::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.9; Wed, 20 Jan 2021 14:31:31 +0000 Received: from HE1PR08MB2825.eurprd08.prod.outlook.com ([fe80::e552:4f51:ab4c:eb44]) by HE1PR08MB2825.eurprd08.prod.outlook.com ([fe80::e552:4f51:ab4c:eb44%5]) with mapi id 15.20.3763.014; Wed, 20 Jan 2021 14:31:31 +0000 From: Lauri Piikivi To: "mohamed.boucadair@orange.com" CC: Lauri Piikivi , "core@ietf.org" Thread-Topic: Request-Token (in draft-ietf-core-new-block-06 and draft-ietf-core-echo-request-tag-11) Thread-Index: AQHW7w+ArQqIIS90mUSS1I1Bv08YGKowSjcAgABJjAA= Date: Wed, 20 Jan 2021 14:31:31 +0000 Message-ID: <6C682C0B-BE8F-45A8-8020-CB8365985CAD@arm.com> References: <32212_1611137297_60080111_32212_473_1_787AE7BB302AE849A7480A190F8B9330315BD735@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <32212_1611137297_60080111_32212_473_1_787AE7BB302AE849A7480A190F8B9330315BD735@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.4) Authentication-Results-Original: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=pelion.com; x-originating-ip: [2001:14ba:14fc:f700:6d68:ed2c:42b8:74c7] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: d3161d20-ee0c-4114-e750-08d8bd501ac7 x-ms-traffictypediagnostic: HE1PR0802MB2348:|DB8PR08MB5323: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: D/Te8P/whn2aLcXIlyFzfZ/YM1kudsalM0pcYtBAfeNn2SGAtxIAboc87/wFPNYl03xR+qRYX0e9ZwzFiZOV9oAeGBq0pALUYSyvZ8LgLTpalljSuEeP3PAQsCBJEOfuKjrcVaO600ptpIKr5MGiYkMiZGXYkeY9JKI5/clE81L9v2oieQ6q5kNz1e2MBl/jGUnjhp74UFsJ+Xyn1PA4vQpWRko+yJcLOVMlNfI6erEM+Xo8TyqUSreIE0amJC5kijLAcR4Jb3r2VZ0rANHFyG5i6rDmp6dKj0PCx4+bIZTWbnNmix44YI7IWh4yGKW5NwwZ/G++uzeh3prSX155m+7bdoRs/StW3UR7txrs5jmeTptdt3Kgc8c1igWQ/qjygR346cVpFocjQ8PALAMk3RcB7DkfDJguALVhDIpwumUHiWv0uNnFnAWhT/lYgUiemD3U9eOVsMYcn/RDhuJYKA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR08MB2825.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(136003)(376002)(346002)(396003)(316002)(8936002)(76116006)(6916009)(83380400001)(478600001)(64756008)(66476007)(91956017)(5660300002)(8676002)(66556008)(2906002)(6512007)(6506007)(33656002)(66446008)(66946007)(54906003)(36756003)(166002)(6486002)(4326008)(71200400001)(86362001)(9686003)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?QU81LzA2RE95NTc2Nk9IVlZDTGtJVG0zQTJpeC9UTEtRbFRFcHY3V3NQd2dJ?= =?utf-8?B?QVRaR1krdEwwR01IcGkvaThzSGQ4NDZhZjJycXVoaldBeFV6b0JNVGVSVHdZ?= =?utf-8?B?QWo3Yll2ZjF4dUhqU3FhZlY1aWV5S29CMWRNbThHQmNHem1FKzgzOUtpZWU1?= =?utf-8?B?SmdiR1p2Y0VDWXFkVkd4MUtja2RJemlXMXRCc2xNTnB1WmRKVGZDdHFqRHAv?= =?utf-8?B?bzJPMmtzSmpub1VGL2lSU01rdzYvZnBhOFk2WjU3bHNXRngzRngvcmNwR05j?= =?utf-8?B?V3pMdTl1V21ycnJLWXJRVGc2d0tFdXQrMGtVdUduSVh3Yk5PME83bjRNSWo4?= =?utf-8?B?azlzaVp0amRMUkEwZlBzbTk1Ujg3bHJtcHNXOFhkNUtKUXk4alJQMlErWXYy?= =?utf-8?B?eGxWdDYvbVVvTmtDNnRacEIyTjZyZ01FZTljYi9XVGVYMk50R2FUZzVtSzND?= =?utf-8?B?emlGZTRlNFJQSU1lOElnUHBKNUhGcWRpamtQTzZUTVJ6bXM4V3pzSEZFUU1G?= =?utf-8?B?SHV0Z1hsTzBycS9KVlUyay95dW1HTXhROXJPM2l3UTloRUdKVjAxczdLYzhn?= =?utf-8?B?S2FuSStMWFQ4RkovR1h1alB4Vk9mYzRvSHZQcnNGUTVxa2I2SE9Ha1JDUWc1?= =?utf-8?B?QVQ3eisvaEpxWHBpSllqWEJXVGRwa0ZqTXVhSWViM3ZuUjhpeDZ6WXpBZEpS?= =?utf-8?B?ZXZNeHplSHBsNUJQNDlhMjczRGNLbDJJcEI1eStYcFJYU1owYmw2Sm90ekln?= =?utf-8?B?Q2pUWW5HQk1LLzA4M1J5bmxWUWNUMWI3TnB4SUx5SUg4SGp3WFB2eTY5OEpL?= =?utf-8?B?a3pQaEhrZTNXSFpDZ1FEalV4TzMybURBd2ZxcTFDTnJ5d1NGMDJOaDF4ZkY4?= =?utf-8?B?MDVvV25kVzBDeEVxejRBdEcrL01EYUtHWFZieWNIcGRHNE9vbkt2ZW1Wb1ZT?= =?utf-8?B?QkRDdmUxRmZGdEgwbnlCcDJkSStaQ3BMa1k4UUdPbUpIb0dYaUFpeC9FZFJQ?= =?utf-8?B?dm0vSTFZWk00ckhhQUVYSStHL1B6TUZ0NkFOaHhWT1lSRmRVREtkSE5PM1ZD?= =?utf-8?B?VGJOZk95UnplTEJhQ0NCcklxRnkyKzh4Y3l1all3WFphem1oV082R1dZbUNy?= =?utf-8?B?SFl1OUFVc0ZVeXBucXVsekZWVUF1b3B6N1ZDOGVaU09FVVgzZm85RFpxTmZz?= =?utf-8?B?d2lqT0dmbENMQmNQSWJUa2tJazJPNWdKTlF2aThHTnc5MkxabGlNSU9EUDZU?= =?utf-8?B?ZUdHSWpxRjZJeko2SU5GMS9vN2FzdHl2SkNCMi9kMUV6TWNqTkhwY2JiVkdi?= =?utf-8?B?S2hZT1RzaEhlN2h2RHljOWN3c3pDTGlONktpRWc0WDJHQnA5azlMVXZCaGJ0?= =?utf-8?B?bHV3UUYrSFhaSkxoeDJJdHJDYm93Y05sWC9GaTFDY21lbUYrbWFocFl6andD?= =?utf-8?Q?3de7Jumu?= Content-Type: multipart/alternative; boundary="_000_6C682C0BBE8F45A88020CB8365985CADarmcom_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2348 Original-Authentication-Results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=pelion.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT045.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 28a81bd7-cc6b-4a36-95c1-08d8bd501499 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3zUCWUwvlhJ4qIYu2kEdWHqzhnIHqnxThFvAhg9xpRV0d+ILJNnI6uGrdObGpWy0jhD2NqlRhrc7huMSOMN4wC2xNj7Ti5MGE8l+4VoYjBt+umaDWRvwhcxjEe7Nd81QciP9/lcuFJ5KnW2JwrjlVpzFLUzGED5VSO3YIyGAG8yYpzdV5xPEr68Tyk1hagyFWvrUk14YjbUAgFsGFBcgHkqOIdIkTtFKvLR9mUTz+C35dkRi/uVvERgEoYknWyoXgbkjclbnuD72pdZTX3pkWXsFxXSFdyMjU2IZAdz6GIYiZDuBPujyDu3XpN2jzGDgsXQ2VOfCi9OsijqzSmPMX/XwZTJfoQn5TGuLiC/Mob76gJU69xcBU0DXXKyjQ9n3CNlyuAqTbHGiarb8MeEaVHsFMIvNA9Jj1P/1Gra3BZoyuxsQ0Lm8JmjFBeLNLuP9C0nd1I4baedr/Wks6fse7V3IwzaxyWe/H7jgQsWsIwWyZCecSudY6LwwWs1zldXtj6gWil8tT/bvPi/d/UX3cCrl5s+XY1TsBY6fdo7EvF8= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(396003)(39860400002)(376002)(136003)(346002)(46966006)(166002)(9686003)(6512007)(6506007)(81166007)(2906002)(8676002)(82740400003)(356005)(86362001)(336012)(6486002)(6862004)(82310400003)(33964004)(33656002)(47076005)(478600001)(45080400002)(54906003)(83380400001)(36756003)(5660300002)(70586007)(26005)(70206006)(186003)(8936002)(30864003)(316002)(4326008); DIR:OUT; SFP:1101; X-OriginatorOrg: pelion.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2021 14:31:41.5527 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d3161d20-ee0c-4114-e750-08d8bd501ac7 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT045.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5323 Archived-At: X-Mailman-Approved-At: Wed, 20 Jan 2021 06:33:55 -0800 Subject: Re: [core] Request-Token (in draft-ietf-core-new-block-06 and 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: Wed, 20 Jan 2021 14:31:49 -0000 --_000_6C682C0BBE8F45A88020CB8365985CADarmcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSBNZWQsDQoNClRoYW5rIHlvdSBmb3IgYSB2ZXJ5IGZhc3QgYW5zd2VyLg0KDQpNeSBjb25j ZXJuIGhlcmUgaXMgdGhhdCB3ZSBkbyBub3QgbWFrZSBDb0FQIHN0YW5kIGZvciBDb21wbGV4IEFw cGxpY2F0aW9uIFByb3RvY29sLiBBbmQgSSB0aGluayB0aGVzZSBhcmUgbm90IGlzc3VlcyBpbiB0 aGUgbmV3IGJsb2NrLCBidXQgaW4gdGhlIHRhZyBpdHNlbGYuDQoNCkZpcnN0IG9mIGFsbCB0aGUg cmVxdWVzdC10YWcgaXQgaXMgZGVmaW5lZCB0byBvdmVyY29tZSB0aGUgd2Vha25lc3NlcyBvZiB0 b2tlbiDigJQgYnV0IHRoZSBzYW1lIHNwZWNpZmljYXRpb24gZml4ZXMgdGhlIHRva2VuLCBtYWtp bmcgaXQgc2VlbSBsaWtlIHRoZSDigJxzdXNwZW5kZXJzIGFuZCBiZWx04oCdIGFwcHJvYWNoLiBJ IHdvdWxkIGxpa2UgdG8gYXZvaWQgdGhlIGNvbXBsZXhpdHkgaWYgYXQgYWxsIHBvc3NpYmxlLCBU aGVyZSBhcmUgZ29vZCBkZWZpbml0aW9ucyB0aGVyZSwgbWFrZSB0aGVtIGZvciB0aGUgdG9rZW4s IGFuZCB1c2UgdGhhdCBleGlzdGluZyBtZWNoYW5pc21zLiBTb21lIG9mIHRoZSBwcm9ibGVtcyBp biB0aGUgZHJhZnQtbWF0dHNzb24tY29yZS1jb2FwLWFjdHVhdG9ycy0wNiBhcmUgbWlzc2luZyB0 b2tlbiBvciBhc3N1bWluZyBuYWl2ZSByZXVzZSBvZiB0aGUgc2FtZSB0b2tlbiAoZXNwZWNpYWxs eSB0aGUgMi41LjIg4oCUIHdoZXJlIGNsaWVudCBoYXMgYSBjb25jdXJyZW50IHRyYW5zYWN0aW9u LCBhcHBsZXMgYW5kIG11cmRlcmVycykuIFdlIGFyZSBub3QgcmVhbGx5IGRvaW5nIGFueXRoaW5n IGZ1bmRhbWVudGFsIGNoYW5nZSwgd2UgYXJlIHN0YXRpbmcgdGhhdCBhIHRva2VuIGlzIHdlYWss IGFuZCBhZGRpbmcgYSBiZXR0ZXIgZGVmaW5lZCB0b2tlbi4gRG9lcyB0aGF0IHNvbHZlIHRoZSBp c3N1ZXM/IEFzc3VtaW5nIHRoZSBraW5kIG9mIHJlcGxheXMgYXMgaW4gdGhlIGFjdHVhdG9ycy0w OCBkb2N1bWVudCwgdGhlIGVjaG8gc2VlbXMgdGhlIGFuc3dlciwgbm90IGEgdG9rZW4tY2FsbGVk LXRhZyB0byBmaXggYW4gZXhpc3RpbmcgdG9rZW4gdGhhdCBpcyB0aGVuIHN0aWxsIHVwZGF0ZWQg aW4gY2hhcHRlciA0Lg0KDQpBcyBmb3IgdGhlIG5ldyBibG9jaywgSWYgdGhlIHRva2VucyBhcmUg dXNlZCB0byBjb21iaW5lIHRoZSBzZXBhcmF0ZSBtZXNzYWdlIElEcyBhcyBpbiBzdGFuZGFyZCBD T0FQIGFuZCBibG9ja2x3aXNlIOKAlCBpdCBpcyBhIGh1Z2UgY2hhbmdlIHRvIG1ha2UgdGhlIHRv a2VuIGNoYW5nZSBmb3IgZWFjaCBibG9jayBmb3IgdGhlIHNlcnZlci4gSXMgdGhpcyB0aGUgcmVh c29uIHRoYXQgdGhlIGRvY3VtZW50IGlzIGRlc2NyaWJlZCBhcyBleHBlcmltZW50YWwgaW4gY2hw IDEuMyDigJQgb3IgZG9lcyB0aGF0IHJlZmVyIG9ubHkgdG8gdGhlIHJhdGUgY29udHJvbCAiVGhp cyBtZWNoYW5pc20gaXMgbm90IGludGVuZGVkIGZvciBnZW5lcmFsIENvQVAgdXNhZ2UsIGFuZCBh bnkgdXNlIG91dHNpZGUgdGhlIGludGVuZGVkIHVzZSBjYXNlIHNob3VsZCBiZSBjYXJlZnVsbHkg d2VpZ2hlZCBhZ2FpbnN0IHRoZSBsb3NzIG9mIGludGVyb3BlcmFiaWxpdHkgd2l0aCBnZW5lcmlj IENvQVAgYXBwbGljYXRpb25z4oCdLiBTdGlsbCB0aGUgZG9jdW1lbnQgaXMgbWFya2VkIGZvciBz dGFuZGFyZHMgdHJhY2s/IE9yIGlzIGl0IGFpbWVkIHB1cmVseSBmb3IgdGhlIEREb1MgT3BlbiBU aHJlYXQgU2lnbmFsaW5nDQogVXNlIGFuZCBzaW1pbGFyIGNhc2VzPw0KDQpDT01NRU5UIE9OIFRB Ry0xMSBFY2hvDQpUaGUgZXJyb3IgY29kZSA0LjAzIHNlZW1zIGNsb3NlciB0byB0aGUgZWNobyBv cGVyYXRpb24uIEF1dGhlbnRpY2F0aW9uIGlzIHN0YXRlZCBvdXRzaWRlIG9mIFJGQyA3MjUyLCBh bmQgNDAzIGluIGh0dHAgc3RhdGVzICJUaGUgNDAzIChGb3JiaWRkZW4pIHN0YXR1cyBjb2RlIGlu ZGljYXRlcyB0aGF0IHRoZSBzZXJ2ZXIgdW5kZXJzdG9vZA0KDQp0aGUgcmVxdWVzdCBidXQgcmVm dXNlcyB0byBhdXRob3JpemUgaXQu4oCdIEEgbmV3IGF0dGVtcHQgd2l0aCBjaGFuZ2VkIGNyZWRl bnRpYWxzIGNhbiBiZSBtYWRlLg0KDQpFUlJPUlMgSU4gVEFHLTExDQpUaGVyZSBpcyBzb21lIGVy cm9yIGluIHRoZSB0YWctMTEgZG9jdW1lbnQsIGl0IGhhcyBjb25mbGljdGluZyBzdGF0ZW1lbnRz IG9uIHVzaW5nIHRoZSBvcHRpb24gaW4gcmVzcG9uc2VzLg0KSW4gMy4yIFRoZSBSZXF1ZXN0LVRh ZyBvcHRpb24gaXMgb25seSB1c2VkIGluIHJlcXVlc3RzIHRoYXQgY2FycnkgdGhlIEJsb2NrMSBv cHRpb24sIGFuZCBpbiBCbG9jazIgcmVxdWVzdHMgZm9sbG93aW5nIHRoZXNlLg0KSW4gMy4yLjEg IFRoZSBSZXF1ZXN0LVRhZyBvcHRpb24gaXMgb25seSB1c2VkIGluIHRoZSByZXF1ZXN0IG1lc3Nh Z2VzIG9mIGJsb2NrLXdpc2Ugb3BlcmF0aW9ucy4NCg0KVGhlbiBvbiBwYWdlIDE0DQoNCiBXaGVu IEJsb2NrMSBhbmQgQmxvY2syIGFyZSBjb21iaW5lZCBpbiBhbiBvcGVyYXRpb24sIHRoZSBSZXF1 ZXN0LVRhZw0KICAgb2YgdGhlIEJsb2NrMSBwaGFzZSBpcyBzZXQgaW4gdGhlIEJsb2NrMiBwaGFz ZSBhcyB3ZWxsIGZvciBvdGhlcndpc2UNCiAgIHRoZSByZXF1ZXN0IHdvdWxkIGhhdmUgYSBkaWZm ZXJlbnQgc2V0IG9mIG9wdGlvbnMgYW5kIHdvdWxkIG5vdCBiZQ0KICAgcmVjb2duaXplZCBhbnkg bW9yZS4NCg0KICAgQ2xpZW50cyBhcmUgZW5jb3VyYWdlZCB0byBnZW5lcmF0ZSBjb21wYWN0IG1l c3NhZ2VzLiAgVGhpcyBtZWFucw0KICAgc2VuZGluZyBtZXNzYWdlcyB3aXRob3V0IFJlcXVlc3Qt VGFnIG9wdGlvbnMgd2hlbmV2ZXIgcG9zc2libGUsIGFuZA0KICAgdXNpbmcgc2hvcnQgdmFsdWVz IHdoZW4gdGhlIGFic2VudCBvcHRpb24gY2FuIG5vdCBiZSByZWN5Y2xlZC4NCg0KICAgTm90ZSB0 aGF0IFJlcXVlc3QtVGFnIG9wdGlvbnMgY2FuIGJlIHByZXNlbnQgaW4gcmVxdWVzdCBtZXNzYWdl cyB0aGF0DQogICBjYXJyeSBubyBCbG9jayBvcHRpb24gKGZvciBleGFtcGxlLCBiZWNhdXNlIGEg UmVxdWVzdC1UYWcgdW5hd2FyZQ0KICAgcHJveHkgcmVhc3NlbWJsZWQgdGhlbSksIGFuZCBNVVNU IGJlIGlnbm9yZWQgaW4gdGhvc2UuDQoNCiAgIFRoZSBSZXF1ZXN0LVRhZyBvcHRpb24gTVVTVCBO T1QgYmUgcHJlc2VudCBpbiByZXNwb25zZSBtZXNzYWdlcy4NCg0KQlINCi0gTGF1cmkNCg0KT24g MjAuIEphbiAyMDIxLCBhdCAxMi4wOCwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWls dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQoNCkhpIExhdXJpLA0KDQpU aGFuayB5b3UgZm9yIHRoZSBjb21tZW50Lg0KDQpkcmFmdC1pZXRmLWNvcmUtZWNoby1yZXF1ZXN0 LXRhZy0xMSNzZWN0aW9uLTQgZGVzY3JpYmVzIHRoZSByZWFzb25zIHdoeSB0b2tlbiBoYW5kbGlu ZyBvZiA3MjUyIHNob3VsZCBiZSB1cGRhdGVkLiBQbGVhc2UgbG9vayBhdCB0aG9zZS4gV2l0aCB0 aGF0IHVwZGF0ZSBpbiBtaW5kLCB0b2tlbiB3aWxsIG5lZWQgdG8gYmUgdXBkYXRlZCBmb3IgZWFj aCByZXF1ZXN0IHdpdGggYSBuZXcgYmxvY2suDQoNClJlcXVlc3RzLVRhZyBpcyB1c2VkIGluIHRo ZSBuZXctYmxvY2sgdG8gYmluZCBibG9ja3Mgb2YgdGhlIHNhbWUgZnJhZ21lbnRlZCByZXF1ZXN0 LiBTZWN0aW9uIDUgb2YgdGhlIG5ldy1ibG9jayBJLUQgY2FsbHMgb3V0IHRoYXQgdGhlIGF1dGhv cml0YXRpdmUgYmVoYXZpb3IgaXMgdGhlIHVwZGF0ZWQgb25lIGluIGRyYWZ0LWlldGYtY29yZS1l Y2hvLXJlcXVlc3QtdGFnLg0KDQpQbGVhc2UgbGV0IHVzIGtub3cgaWYgYW55IGNsYXJpZmljYXRp b24gaXMgbmVlZGVkIHRvIHRoZSBuZXctYmxvY2sgSS1ELg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUg OiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIExhdXJp IFBpaWtpdmkNCkVudm95w6kgOiBtZXJjcmVkaSAyMCBqYW52aWVyIDIwMjEgMTA6MzUNCsOAIDog Y29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4NCk9iamV0IDogW2NvcmVdIFJlcXVl c3QtVG9rZW4gKGluIGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMDYgYW5kIGRyYWZ0LWlldGYt Y29yZS1lY2hvLXJlcXVlc3QtdGFnLTExKQ0KDQpIaSBhbGxzLA0KDQpJIHJlYWQgdGhlIG5ldyBi bG9jayB3aXRoIGludGVyZXN0IGFuZCBzdGFydGVkIHdvbmRlcmluZyBhYm91dCB0aGUgcmVxdWVz dCB0YWcuIFdoeSBkbyB3ZSBuZWVkIG5ldyB0YWcsIHdoZW4gd2UgaGF2ZSB0aGUgYmFzaWMgQ09B UCB0b2tlbi4gVG9rZW4gaXMgdXNlZCB0byBtYXRjaCByZXF1ZXN0IGFuZCByZXNwb25zZSwgYW5k IGluIGRvaW5nIHRoYXQgaXQgZG9lcyBpZGVudGlmeSB0aGUgcmVxdWVzdCBibG9ja3MgYW5kIHJl c3BvbnNlIGJsb2NrcyB0byBiZSBwYXJ0IG9mIHRoZSBzYW1lIHJlcXVlc3QgYW5kIHJlc3BvbnNl Lg0KDQpJbiBibG9jd2lzZSB0cmFuc2ZlciA3OTU5ICwgdGhlIG1lc3NhZ2UgSURzIGNoYW5nZSBi dXQgdG9rZW4gY29tYmluZXMgdGhlbSB0b2dldGhlci4gU2FtZSBzZWVtcyB1c2FibGUgaW4gdGhl IG5ldy1ibG9jayBhcHByb2FjaC4gSXQgaXMgdGhlIHNhbWUgcmVxdWVzdCwgc28gdGhleSBzaG91 bGQgaGF2ZSB0aGUgc2FtZSB0b2tlbi4gUkZDIDc5NTkgZG9lcyBub3Qgc2F5IGEgd2hvbGUgbG90 IGFib3V0IHRva2VucyAiQXMgYSBnZW5lcmFsIGNvbW1lbnQgb24gdG9rZW5zLCB0aGVyZSBpcyBu byBvdGhlciBtZW50aW9uIG9mIHRva2VucyBpbiB0aGlzIGRvY3VtZW50LCBhcyBibG9jay13aXNl IHRyYW5zZmVycyBoYW5kbGUgdG9rZW5zIGxpa2UgYW55IG90aGVyIENvQVAgZXhjaGFuZ2UuIEFz IHVzdWFsLCB0aGUgY2xpZW50IGlzIGZyZWUgdG8gY2hvb3NlIHRva2VucyBmb3IgZWFjaCBleGNo YW5nZSBhcyBpdCBsaWtlcy7igJ0gVGhpcyBjb3VsZCBiZSBjbGFyaWZpZWQuIE15IHVuZGVyc3Rh bmRpbmcgaXMgdGhhdCB0aGUgdG9rZW4gaXMgdGhlIHNhbWUgZm9yIGFsbCBibG9ja3Mgb2YgYSBy ZXF1ZXN0IGFuZCByZXNwb25zZS4gIFRoaXMgaXMgc2hvd24gZm9yIGV4YW1wbGUgaW4gdGhlIEZp Z3VyZSAxMyBvZiA3OTU5Lg0KDQpNeSB3b25kZXJpbmcgc3RhcnRlZCBmcm9tIHJlYWRpbmcgdGhl ICBkcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrLTA2LiBJdCBzdGF0ZXMgdGhlbiBuZWVkIGZvciBy ZXF1ZXN0IHRhZywgYW5kIGluIGV4YW1wbGUgOS4xLjEgIHNob3dzIHRoZSBiYXNpYyB0b2tlbnMg YXMgZGlmZmVyZW50IGZvciB0aGUgZnJhZ21lbnRlZCByZXF1ZXN0LiBJcyB0aGF0IGFuIGVycm9y PyBTaG91bGQgdGhlIGJhc2ljIHRva2VucyBiZSB0aGUgc2FtZT8gQW5kIGlmIHRoZSB0b2tlbnMg YXJlIHRoZSBzYW1lLCB0aGUgcmVxdWVzdC10YWcgc2VlbXMgdW5uZWNlc3NhcnkuDQoNCkkgZGlk IHJlYWQgdGhlIGRyYWZ0LWlldGYtY29yZS1lY2hvLXJlcXVlc3QtdGFnLTExIHRvIHVuZGVyc3Rh bmQgdGhlIHJlcXVlc3QtdG9rZW4gYmV0dGVyLCBidXQgSSBmb3VuZCB0aGUgZGVzY3JpcHRpb24g YSBiaXQgaGFyZCB0byBmb2xsb3cuIEl0IHNheXMgaW4gaW4gY2hwIDMuMiB0aGF0ICAiVGhlIFJl cXVlc3QtVGFnIGlzIGludGVuZGVkIGZvciB1c2UgYXMgYSBzaG9ydC1saXZlZCBpZGVudGlmaWVy IGZvciBrZWVwaW5nIGFwYXJ0IGRpc3RpbmN0IGJsb2NrLXdpc2UgcmVxdWVzdCBvcGVyYXRpb25z IG9uIG9uZSByZXNvdXJjZSBmcm9tIG9uZSBjbGllbnTigJ0NCg0KQnV0IG9uIHRoZSB3aXJlIHRo ZXJlIGlzIGFscmVhZHkgdGhlIHRva2VuIHNwZWNpZmllZCBpbiA3MjUyIGNocCA1LjMuMSAiQSB0 b2tlbiBpcyBpbnRlbmRlZCBmb3IgdXNlIGFzIGEgY2xpZW50LWxvY2FsIGlkZW50aWZpZXIgZm9y ICBkaWZmZXJlbnRpYXRpbmcgYmV0d2VlbiBjb25jdXJyZW50IHJlcXVlc3RzIChzZWUgU2VjdGlv biA1LjM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyNTIjc2VjdGlvbi01LjM+KeKA nS4NCg0KDQoNCkkgZG8gbm90IHVuZGVyc3RhbmQgZXhhY3RseSB3aGF0IGlzIG1lYW50IGJ5ICAi VGhlIGJsb2NrLXdpc2UgZnVuY3Rpb25hbGl0eSBkb2VzIG5vdCBzdXBwb3J0IHRoZSBkZXRlY3Rp b24gb2YgaW50ZXJjaGFuZ2VkIGJsb2NrcyBiZXR3ZWVuIGRpZmZlcmVudCBtZXNzYWdlIGJvZGll cyB0byB0aGUgc2FtZSByZXNvdXJjZSBoYXZpbmcgdGhlIHNhbWUgYmxvY2sgbnVtYmVy4oCdIGlu ICB0YWctMTEgY2hwIDMuMS4gSXMgdGhlIG1lc3NhZ2UgYm9keSB0aGUgcGF5bG9hZD8gIElmIHRo ZSByZXF1ZXN0cyBjb21lIGZyb20gc2FtZSBjbGllbnQsIHRoZXkgbXVzdCBoYXZlIGRpZmZlcmVu dCB0b2tlbnMsIHBlciByZmMgNzI1Mi4NCg0KDQoNCklzIHRoZXJlIHNvbWUgcHJvYmxlbSBpbiB0 b2tlbiB0aGF0IEkgZmFpbCB0byB1bmRlcnN0YW5kIG5vdyDigJQgbmVjZXNzaXRhdGluZyB0aGUg cmVxdWVzdC10b2tlbj8NCg0KDQoNCkluIHNpbWlsYXIgdmVpbiwgYW5kIGFzIGEgdXNlIGNhc2Ug d2hlcmUgcmVxdWVzdCB0b2tlbiBzZWVtcyBnb29kLCBpcyB0aGUgdW5kZXJzdGFuZGluZyBjb3Jy ZWN0IHRoYXQgZm9yIGJsb2NrMSByZXF1ZXN0cyBhbGwgdGhlIHJlcXVlc3Qgb3B0aW9ucyBhcmUg ZHVwbGljYXRlZCBpbiBhbGwgdGhlIGJsb2Nrcz8gSSBjb3VsZCBub3QgZmluZCBhIGNsZWFyIHN0 YXRlbWVudCwgYnV0IG9uY2UgYWdhaW4gdGhlIGZpZ3VyZXMgaW4gNzk1OSBzaG93IHRoZSBVUkkg Zm9yIGVhY2ggYmxvY2suIFRoZSBVUkkgcGF0aCBhbmQgcXVlcnkgb3B0aW9ucyBjYW4gYmUgbG9u ZywgYW5kIHRha2UgY29uc2lkZXJhYmxlIHNwYWNlIGluIGVhY2ggYmxvY2suDQoNCkNvdWxkIHJl cXVlc3QgdG9rZW4gYmUgdGhlIGlkZW50aWZpZXIgZm9yIHJlcXVlc3Qgb3B0aW9ucywgc28gdGhh dCBvbmx5IDFzdCBibG9jayB3b3VsZCBoYXZlIGZ1bGwgb3B0aW9ucyBhbmQgbGF0ZXIgb25lcyBv bmx5IHRoZSB0aGUgcmVxdWVzdCB0YWc/DQoNCg0KU2luY2VyZWx5LA0KLSBMYXVyaQ0KDQpJTVBP UlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIg cGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZv cm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpU aGFuayB5b3UuDQoNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBw cml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29u dGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3Rv cmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_6C682C0BBE8F45A88020CB8365985CADarmcom_ Content-Type: text/html; charset="utf-8" Content-ID: <422514BD795DA64DA240EC76098857F7@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQpIaSBNZWQsDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5UaGFuayB5b3UgZm9yIGEgdmVyeSBmYXN0IGFuc3dlci4mbmJzcDs8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk15IGNv bmNlcm4gaGVyZSBpcyB0aGF0IHdlIGRvIG5vdCBtYWtlIENvQVAgc3RhbmQgZm9yIENvbXBsZXgg QXBwbGljYXRpb24gUHJvdG9jb2wuIEFuZCBJIHRoaW5rIHRoZXNlIGFyZSBub3QgaXNzdWVzIGlu IHRoZSBuZXcgYmxvY2ssIGJ1dCBpbiB0aGUgdGFnIGl0c2VsZi4gJm5ic3A7PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5GaXJzdCBvZiBh bGwgdGhlIHJlcXVlc3QtdGFnIGl0IGlzIGRlZmluZWQgdG8gb3ZlcmNvbWUgdGhlIHdlYWtuZXNz ZXMgb2YgdG9rZW4g4oCUIGJ1dCB0aGUgc2FtZSBzcGVjaWZpY2F0aW9uIGZpeGVzIHRoZSB0b2tl biwgbWFraW5nIGl0IHNlZW0gbGlrZSB0aGUg4oCcc3VzcGVuZGVycyBhbmQgYmVsdOKAnSBhcHBy b2FjaC4gSSB3b3VsZCBsaWtlIHRvIGF2b2lkIHRoZSBjb21wbGV4aXR5IGlmIGF0IGFsbCBwb3Nz aWJsZSwgVGhlcmUNCiBhcmUgZ29vZCBkZWZpbml0aW9ucyB0aGVyZSwgbWFrZSB0aGVtIGZvciB0 aGUgdG9rZW4sIGFuZCB1c2UgdGhhdCBleGlzdGluZyBtZWNoYW5pc21zLiBTb21lIG9mIHRoZSBw cm9ibGVtcyBpbiB0aGUmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxZW07IGZvbnQtd2Vp Z2h0OiBib2xkOyIgY2xhc3M9IiI+ZHJhZnQtbWF0dHNzb24tY29yZS1jb2FwLWFjdHVhdG9ycy0w Ng0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDFlbTsiIGNsYXNzPSIiPmFyZSBtaXNz aW5nIHRva2VuIG9yIGFzc3VtaW5nIG5haXZlIHJldXNlIG9mIHRoZSBzYW1lIHRva2VuIChlc3Bl Y2lhbGx5IHRoZSAyLjUuMiZuYnNwOzwvc3Bhbj7igJQ8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx ZW07IiBjbGFzcz0iIj4mbmJzcDt3aGVyZSBjbGllbnQgaGFzIGEgY29uY3VycmVudCB0cmFuc2Fj dGlvbiwgYXBwbGVzIGFuZCBtdXJkZXJlcnMpLiBXZSBhcmUgbm90IHJlYWxseQ0KIGRvaW5nIGFu eXRoaW5nIGZ1bmRhbWVudGFsIGNoYW5nZSwgd2UgYXJlIHN0YXRpbmcgdGhhdCBhIHRva2VuIGlz IHdlYWssIGFuZCBhZGRpbmcgYSBiZXR0ZXIgZGVmaW5lZCB0b2tlbi4gRG9lcyB0aGF0IHNvbHZl IHRoZSBpc3N1ZXM/IEFzc3VtaW5nIHRoZSBraW5kIG9mIHJlcGxheXMgYXMgaW4gdGhlIGFjdHVh dG9ycy0wOCBkb2N1bWVudCwgdGhlIGVjaG8gc2VlbXMgdGhlIGFuc3dlciwgbm90IGEgdG9rZW4t Y2FsbGVkLXRhZyB0byBmaXggYW4NCiBleGlzdGluZyB0b2tlbiB0aGF0IGlzIHRoZW4gc3RpbGwg dXBkYXRlZCBpbiBjaGFwdGVyIDQuJm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMgZm9yIHRoZSBuZXcgYmxvY2ss IElmIHRoZSB0b2tlbnMgYXJlIHVzZWQgdG8gY29tYmluZSB0aGUgc2VwYXJhdGUgbWVzc2FnZSBJ RHMgYXMgaW4gc3RhbmRhcmQgQ09BUCBhbmQgYmxvY2tsd2lzZSDigJQgaXQgaXMgYSBodWdlIGNo YW5nZSB0byBtYWtlIHRoZSB0b2tlbiBjaGFuZ2UgZm9yIGVhY2ggYmxvY2sgZm9yIHRoZSBzZXJ2 ZXIuIElzIHRoaXMgdGhlIHJlYXNvbiB0aGF0IHRoZSBkb2N1bWVudCBpcyBkZXNjcmliZWQNCiBh cyBleHBlcmltZW50YWwgaW4gY2hwIDEuMyDigJQgb3IgZG9lcyB0aGF0IHJlZmVyIG9ubHkgdG8g dGhlIHJhdGUgY29udHJvbCAmcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O1BU IE1vbm8mcXVvdDssIE1vbmFjbywgbW9ub3NwYWNlOyBmb250LXNpemU6IDE0cHg7IGJhY2tncm91 bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsiIGNsYXNzPSIiPlRoaXMgbWVjaGFuaXNtIGlz IG5vdCBpbnRlbmRlZCBmb3IgZ2VuZXJhbCBDb0FQIHVzYWdlLCBhbmQgYW55DQogdXNlJm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7UFQgTW9ubyZxdW90OywgTW9u YWNvLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTRweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjUzLCAyNDUpOyIgY2xhc3M9IiI+b3V0c2lkZSB0aGUgaW50ZW5kZWQgdXNlIGNhc2Ugc2hv dWxkIGJlIGNhcmVmdWxseSB3ZWlnaGVkIGFnYWluc3QgdGhlJm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTMsIDI0NSk7IiBjbGFzcz0iIj48Zm9u dCBmYWNlPSJQVCBNb25vLCBNb25hY28sIG1vbm9zcGFjZSIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTRweDsiIGNsYXNzPSIiPmxvc3MNCiBvZiBpbnRlcm9wZXJhYmlsaXR5IHdp dGggZ2VuZXJpYyBDb0FQIGFwcGxpY2F0aW9uc+KAnS4gU3RpbGwgdGhlIGRvY3VtZW50IGlzIG1h cmtlZCBmb3Igc3RhbmRhcmRzIHRyYWNrPyZuYnNwO09yIGlzIGl0IGFpbWVkIHB1cmVseSBmb3Ig dGhlJm5ic3A7PC9zcGFuPjwvZm9udD48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAm cXVvdDtQVCBNb25vJnF1b3Q7LCBNb25hY28sIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxNHB4OyBi YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTMsIDI0NSk7IiBjbGFzcz0iIj5ERG9TDQogT3Bl biBUaHJlYXQgU2lnbmFsaW5nPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDtVc2Ug YW5kIHNpbWlsYXIgY2FzZXM/Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DT01NRU5UIE9OIFRBRy0xMSBFY2hvPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPlRoZSBlcnJvciBjb2RlIDQuMDMgc2VlbXMgY2xvc2VyIHRvIHRoZSBlY2hv IG9wZXJhdGlvbi4gQXV0aGVudGljYXRpb24gaXMgc3RhdGVkIG91dHNpZGUgb2YgUkZDIDcyNTIs IGFuZCA0MDMgaW4gaHR0cCBzdGF0ZXMgJnF1b3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTMu MzMzMzMzMDE1NDQxODk1cHg7IiBjbGFzcz0iIj5UaGUgNDAzIChGb3JiaWRkZW4pIHN0YXR1cyBj b2RlIGluZGljYXRlcyB0aGF0IHRoZSBzZXJ2ZXIgdW5kZXJzdG9vZDwvc3Bhbj48L2Rpdj4NCjxw cmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6IDEzLjMzMzMzMzAxNTQ0MTg5NXB4 OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgYnJlYWstYmVmb3JlOiBwYWdl OyI+dGhlIHJlcXVlc3QgYnV0IHJlZnVzZXMgdG8gYXV0aG9yaXplIGl0LuKAnSBBIG5ldyBhdHRl bXB0IHdpdGggY2hhbmdlZCBjcmVkZW50aWFscyBjYW4gYmUgbWFkZS4gPC9wcmU+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FUlJPUlMgSU4gVEFH LTExPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZXJlIGlzIHNvbWUgZXJyb3IgaW4gdGhlIHRhZy0x MSBkb2N1bWVudCwgaXQgaGFzIGNvbmZsaWN0aW5nIHN0YXRlbWVudHMgb24gdXNpbmcgdGhlIG9w dGlvbiBpbiByZXNwb25zZXMuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiIGNsYXNzPSIi PkluIDMuMiZuYnNwOzwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O1BUIE1vbm8m cXVvdDssIE1vbmFjbywgbW9ub3NwYWNlOyBmb250LXNpemU6IDE0cHg7IGJhY2tncm91bmQtY29s b3I6IHJnYigyNTUsIDI1MywgMjQ1KTsiIGNsYXNzPSIiPlRoZSBSZXF1ZXN0LVRhZyBvcHRpb24g aXMgb25seSB1c2VkIGluIHJlcXVlc3RzIHRoYXQmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiAmcXVvdDtQVCBNb25vJnF1b3Q7LCBNb25hY28sIG1vbm9zcGFjZTsgZm9udC1z aXplOiAxNHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTMsIDI0NSk7IiBjbGFzcz0i Ij5jYXJyeQ0KIHRoZSBCbG9jazEgb3B0aW9uLCBhbmQgaW4gQmxvY2syIHJlcXVlc3RzIGZvbGxv d2luZyB0aGVzZS48L3NwYW4+DQo8ZGl2IGNsYXNzPSIiPkluIDMuMi4xJm5ic3A7PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtQVCBNb25vJnF1b3Q7LCBNb25hY28sIG1vbm9zcGFjZTsg Zm9udC1zaXplOiAxNHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTMsIDI0NSk7IiBj bGFzcz0iIj4gVGhlIFJlcXVlc3QtVGFnIG9wdGlvbiBpcyBvbmx5IHVzZWQgaW4gdGhlIHJlcXVl c3QgbWVzc2FnZXMgb2YgYmxvY2stPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1 b3Q7UFQgTW9ubyZxdW90OywgTW9uYWNvLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTRweDsgYmFj a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyIgY2xhc3M9IiI+d2lzZQ0KIG9wZXJh dGlvbnMuPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+VGhlbiBvbiBwYWdlIDE0PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHBy ZSBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgb3ZlcmZsb3c6IGF1dG87IGZvbnQtZmFt aWx5OiAmcXVvdDtQVCBNb25vJnF1b3Q7LCBNb25hY28sIG1vbm9zcGFjZTsgZm9udC1zaXplOiAx NHB4OyBwYWRkaW5nOiAxMHB4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDEwLjVw eDsgbGluZS1oZWlnaHQ6IDEuMjE0OyB3b3JkLWJyZWFrOiBicmVhay1hbGw7IHdvcmQtd3JhcDog YnJlYWstd29yZDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyBib3JkZXI6 IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IGJvcmRlci10b3AtbGVmdC1yYWRpdXM6IDRw eDsgYm9yZGVyLXRvcC1yaWdodC1yYWRpdXM6IDRweDsgYm9yZGVyLWJvdHRvbS1yaWdodC1yYWRp dXM6IDRweDsgYm9yZGVyLWJvdHRvbS1sZWZ0LXJhZGl1czogNHB4OyIgY2xhc3M9IiI+IFdoZW4g QmxvY2sxIGFuZCBCbG9jazIgYXJlIGNvbWJpbmVkIGluIGFuIG9wZXJhdGlvbiwgdGhlIFJlcXVl c3QtVGFnDQogICBvZiB0aGUgQmxvY2sxIHBoYXNlIGlzIHNldCBpbiB0aGUgQmxvY2syIHBoYXNl IGFzIHdlbGwgZm9yIG90aGVyd2lzZQ0KICAgdGhlIHJlcXVlc3Qgd291bGQgaGF2ZSBhIGRpZmZl cmVudCBzZXQgb2Ygb3B0aW9ucyBhbmQgd291bGQgbm90IGJlDQogICByZWNvZ25pemVkIGFueSBt b3JlLg0KDQogICBDbGllbnRzIGFyZSBlbmNvdXJhZ2VkIHRvIGdlbmVyYXRlIGNvbXBhY3QgbWVz c2FnZXMuICBUaGlzIG1lYW5zDQogICBzZW5kaW5nIG1lc3NhZ2VzIHdpdGhvdXQgUmVxdWVzdC1U YWcgb3B0aW9ucyB3aGVuZXZlciBwb3NzaWJsZSwgYW5kDQogICB1c2luZyBzaG9ydCB2YWx1ZXMg d2hlbiB0aGUgYWJzZW50IG9wdGlvbiBjYW4gbm90IGJlIHJlY3ljbGVkLg0KDQogICBOb3RlIHRo YXQgUmVxdWVzdC1UYWcgb3B0aW9ucyBjYW4gYmUgcHJlc2VudCBpbiByZXF1ZXN0IG1lc3NhZ2Vz IHRoYXQNCiAgIGNhcnJ5IG5vIEJsb2NrIG9wdGlvbiAoZm9yIGV4YW1wbGUsIGJlY2F1c2UgYSBS ZXF1ZXN0LVRhZyB1bmF3YXJlDQogICBwcm94eSByZWFzc2VtYmxlZCB0aGVtKSwgYW5kIE1VU1Qg YmUgaWdub3JlZCBpbiB0aG9zZS4NCg0KICAgPGIgY2xhc3M9IiI+VGhlIFJlcXVlc3QtVGFnIG9w dGlvbiBNVVNUIE5PVCBiZSBwcmVzZW50IGluIHJlc3BvbnNlIG1lc3NhZ2VzPC9iPi48L3ByZT4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+QlI8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBMYXVyaTwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24g MjAuIEphbiAyMDIxLCBhdCAxMi4wOCwgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20iIGNsYXNzPSIiPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4g d3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRT ZWN0aW9uMTsgY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsiIGNs YXNzPSIiPkhpIExhdXJpLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcm cXVvdDs7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsiIGNsYXNzPSIiPlRoYW5rIHlvdSBmb3IgdGhlIGNv bW1lbnQuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNz PSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsiIGNsYXNzPSIiPmRyYWZ0LWlldGYtY29yZS1l Y2hvLXJlcXVlc3QtdGFnLTExI3NlY3Rpb24tNCBkZXNjcmliZXMgdGhlIHJlYXNvbnMgd2h5IHRv a2VuIGhhbmRsaW5nIG9mIDcyNTIgc2hvdWxkIGJlIHVwZGF0ZWQuIFBsZWFzZSBsb29rIGF0IHRo b3NlLiBXaXRoIHRoYXQgdXBkYXRlIGluIG1pbmQsIHRva2VuIHdpbGwgbmVlZA0KIHRvIGJlIHVw ZGF0ZWQgZm9yIGVhY2ggcmVxdWVzdCB3aXRoIGEgbmV3IGJsb2NrLjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss IHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyIgY2xhc3M9IiI+PG86 cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcm cXVvdDs7IiBjbGFzcz0iIj5SZXF1ZXN0cy1UYWcgaXMgdXNlZCBpbiB0aGUgbmV3LWJsb2NrIHRv IGJpbmQgYmxvY2tzIG9mIHRoZSBzYW1lIGZyYWdtZW50ZWQgcmVxdWVzdC4gU2VjdGlvbiA1IG9m IHRoZSBuZXctYmxvY2sgSS1EIGNhbGxzIG91dCB0aGF0IHRoZSBhdXRob3JpdGF0aXZlIGJlaGF2 aW9yIGlzIHRoZSB1cGRhdGVkIG9uZQ0KIGluIGRyYWZ0LWlldGYtY29yZS1lY2hvLXJlcXVlc3Qt dGFnLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7OyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0iIj5QbGVhc2UgbGV0IHVzIGtub3cg aWYgYW55IGNsYXJpZmljYXRpb24gaXMgbmVlZGVkIHRvIHRoZSBuZXctYmxvY2sgSS1ELjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyIg Y2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogJnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0iIj5DaGVlcnMsPG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0iIj5NZWQ8bzpw IGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozsi IGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtd2lk dGg6IDEuNXB0OyBib3JkZXItbGVmdC1jb2xvcjogYmx1ZTsgcGFkZGluZzogMGNtIDBjbSAwY20g NHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxl OiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3Atd2lkdGg6IDFwdDsgYm9yZGVyLXRvcC1jb2xv cjogcmdiKDIyNSwgMjI1LCAyMjUpOyBwYWRkaW5nOiAzcHQgMGNtIDBjbTsiIGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+ DQo8YiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+Y29yZSBbPGEgaHJlZj0ibWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZyIgc3R5bGU9ImNv bG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+bWFpbHRv OmNvcmUtYm91bmNlc0BpZXRmLm9yZzwvYT5dPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxiIGNsYXNzPSIiPkRlDQogbGEgcGFydCBkZTwvYj48c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TGF1cmkgUGlpa2l2aTxi ciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkVudm95w6kmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5tZXJjcmVkaSAyMCBqYW52aWVyIDIw MjEgMTA6MzU8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj7DgCZuYnNwOzo8L2I+PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpj b3JlQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl cmxpbmU7IiBjbGFzcz0iIj5jb3JlQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNz PSIiPk9iamV0Jm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+W2NvcmVdIFJlcXVlc3QtVG9rZW4gKGluIGRyYWZ0LWlldGYtY29yZS1uZXct YmxvY2stMDYgYW5kIGRyYWZ0LWlldGYtY29yZS1lY2hvLXJlcXVlc3QtdGFnLTExKTxvOnAgY2xh c3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0i Ij4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsiIGNsYXNzPSIiPkhpIGFsbHMsPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MC41cHQ7IiBjbGFzcz0iIj5JIHJlYWQgdGhlIG5ldyBibG9jayB3aXRoIGludGVyZXN0IGFuZCBz dGFydGVkIHdvbmRlcmluZyBhYm91dCB0aGUgcmVxdWVzdCB0YWcuIFdoeSBkbyB3ZSBuZWVkIG5l dyB0YWcsIHdoZW4gd2UgaGF2ZSB0aGUgYmFzaWMgQ09BUCB0b2tlbi4gVG9rZW4gaXMgdXNlZCB0 byBtYXRjaCByZXF1ZXN0IGFuZCByZXNwb25zZSwgYW5kIGluIGRvaW5nIHRoYXQgaXQgZG9lcyBp ZGVudGlmeQ0KIHRoZSByZXF1ZXN0IGJsb2NrcyBhbmQgcmVzcG9uc2UgYmxvY2tzIHRvIGJlIHBh cnQgb2YgdGhlIHNhbWUgcmVxdWVzdCBhbmQgcmVzcG9uc2UuPC9zcGFuPjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5i c3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsiIGNsYXNzPSIiPkluIGJsb2N3aXNlIHRyYW5zZmVyIDc5NTkgLCB0 aGUgbWVzc2FnZSBJRHMgY2hhbmdlIGJ1dCB0b2tlbiBjb21iaW5lcyB0aGVtIHRvZ2V0aGVyLiBT YW1lIHNlZW1zIHVzYWJsZSBpbiB0aGUgbmV3LWJsb2NrIGFwcHJvYWNoLiBJdCBpcyB0aGUgc2Ft ZSByZXF1ZXN0LCBzbyB0aGV5IHNob3VsZCBoYXZlIHRoZSBzYW1lIHRva2VuLiBSRkMgNzk1OSBk b2VzIG5vdCBzYXkgYSB3aG9sZQ0KIGxvdCBhYm91dCB0b2tlbnMgJnF1b3Q7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IiBjbGFzcz0iIj5BcyBhIGdlbmVyYWwgY29tbWVudCBv biB0b2tlbnMsIHRoZXJlIGlzIG5vIG90aGVyJm5ic3A7bWVudGlvbiBvZiB0b2tlbnMgaW4gdGhp cyBkb2N1bWVudCwgYXMgYmxvY2std2lzZSB0cmFuc2ZlcnMgaGFuZGxlJm5ic3A7dG9rZW5zIGxp a2UgYW55IG90aGVyIENvQVAgZXhjaGFuZ2UuIEFzIHVzdWFsLCB0aGUgY2xpZW50IGlzIGZyZWUg dG8mbmJzcDtjaG9vc2UNCiB0b2tlbnMgZm9yIGVhY2ggZXhjaGFuZ2UgYXMgaXQgbGlrZXMu4oCd IFRoaXMgY291bGQgYmUgY2xhcmlmaWVkLiBNPC9zcGFuPnkgdW5kZXJzdGFuZGluZyBpcyB0aGF0 IHRoZSB0b2tlbiBpcyB0aGUgc2FtZSBmb3IgYWxsIGJsb2NrcyBvZiBhIHJlcXVlc3QgYW5kIHJl c3BvbnNlLiAmbmJzcDtUaGlzIGlzIHNob3duIGZvciBleGFtcGxlIGluIHRoZSBGaWd1cmUgMTMg b2YgNzk1OS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9 IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IiBjbGFzcz0iIj5NeSB3b25k ZXJpbmcgc3RhcnRlZCBmcm9tIHJlYWRpbmcgdGhlICZuYnNwO2RyYWZ0LWlldGYtY29yZS1uZXct YmxvY2stMDYuIEl0IHN0YXRlcyB0aGVuJm5ic3A7bmVlZCBmb3IgcmVxdWVzdCB0YWcsIGFuZCBp biZuYnNwO2V4YW1wbGUgOS4xLjEmbmJzcDsgc2hvd3MgdGhlIGJhc2ljIHRva2VucyBhcyBkaWZm ZXJlbnQgZm9yIHRoZSBmcmFnbWVudGVkIHJlcXVlc3QuIElzIHRoYXQgYW4gZXJyb3I/IFNob3Vs ZA0KIHRoZSBiYXNpYyB0b2tlbnMgYmUgdGhlIHNhbWU/IEFuZCBpZiB0aGUgdG9rZW5zIGFyZSB0 aGUgc2FtZSwgdGhlIHJlcXVlc3QtdGFnIHNlZW1zIHVubmVjZXNzYXJ5Ljwvc3Bhbj48bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNz PSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IiBjbGFzcz0iIj5JIGRpZCByZWFkIHRoZSZuYnNwO2Ry YWZ0LWlldGYtY29yZS1lY2hvLXJlcXVlc3QtdGFnLTExIHRvIHVuZGVyc3RhbmQgdGhlIHJlcXVl c3QtdG9rZW4gYmV0dGVyLCBidXQgSSBmb3VuZCB0aGUgZGVzY3JpcHRpb24gYSBiaXQgaGFyZCB0 byBmb2xsb3cuIEl0IHNheXMgaW4gaW4gY2hwIDMuMiB0aGF0ICZuYnNwOyZxdW90OzxzcGFuIHN0 eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTMsIDI0NSk7IGJhY2tncm91bmQtcG9z aXRpb246IGluaXRpYWwgaW5pdGlhbDsgYmFja2dyb3VuZC1yZXBlYXQ6IGluaXRpYWwgaW5pdGlh bDsiIGNsYXNzPSIiPlRoZQ0KIFJlcXVlc3QtVGFnIGlzIGludGVuZGVkIGZvciB1c2UgYXMgYSBz aG9ydC1saXZlZCBpZGVudGlmaWVyIGZvciZuYnNwO2tlZXBpbmcgYXBhcnQgZGlzdGluY3QgYmxv Y2std2lzZSByZXF1ZXN0IG9wZXJhdGlvbnMgb24gb25lIHJlc291cmNlJm5ic3A7ZnJvbSBvbmUg Y2xpZW50PC9zcGFuPuKAnTwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss IHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGJh Y2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1MywgMjQ1KTsgYmFja2dyb3VuZC1wb3NpdGlvbjog aW5pdGlhbCBpbml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0aWFsOyIgY2xh c3M9IiI+QnV0IG9uIHRoZSB3aXJlIHRoZXJlIGlzIGFscmVhZHkmbmJzcDt0aGUgdG9rZW4mbmJz cDtzcGVjaWZpZWQgaW4gNzI1MiBjaHAgNS4zLjEgJnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsiIGNsYXNzPSIiPkENCiB0b2tlbiBpcyBpbnRlbmRlZCBmb3IgdXNl IGFzIGEgY2xpZW50LWxvY2FsIGlkZW50aWZpZXIgZm9yJm5ic3A7Jm5ic3A7ZGlmZmVyZW50aWF0 aW5nIGJldHdlZW4gY29uY3VycmVudCByZXF1ZXN0cyAoc2VlPHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNzI1MiNzZWN0aW9uLTUuMyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7 IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTAuNXB0OyIgY2xhc3M9IiI+U2VjdGlvbg0KIDUuMzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyIgY2xhc3M9IiI+KeKAnS4gJm5ic3A7PC9zcGFuPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 OyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGJyZWFrLWJlZm9yZTogcGFnZTsiIGNsYXNzPSIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPkkgZG8gbm90IHVuZGVyc3RhbmQgZXhhY3RseSB3aGF0IGlzIG1l YW50IGJ5Jm5ic3A7ICZxdW90OzxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTMsIDI0NSk7IGJhY2tncm91bmQtcG9zaXRpb246IGluaXRpYWwgaW5pdGlhbDsgYmFja2dy b3VuZC1yZXBlYXQ6IGluaXRpYWwgaW5pdGlhbDsiIGNsYXNzPSIiPlRoZSBibG9jay13aXNlIGZ1 bmN0aW9uYWxpdHkgZG9lcyBub3Qgc3VwcG9ydCB0aGUgZGV0ZWN0aW9uIG9mIGludGVyY2hhbmdl ZCBibG9ja3MgYmV0d2VlbiBkaWZmZXJlbnQgbWVzc2FnZSBib2RpZXMgdG8gdGhlIHNhbWUgcmVz b3VyY2UgaGF2aW5nIHRoZSBzYW1lIGJsb2NrIG51bWJlcuKAnSBpbiZuYnNwOzwvc3Bhbj4gdGFn LTExIGNocCAzLjEuIElzIHRoZSBtZXNzYWdlIGJvZHkgdGhlIHBheWxvYWQ/Jm5ic3A7IDxzcGFu IHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTMsIDI0NSk7IGJhY2tncm91bmQt cG9zaXRpb246IGluaXRpYWwgaW5pdGlhbDsgYmFja2dyb3VuZC1yZXBlYXQ6IGluaXRpYWwgaW5p dGlhbDsiIGNsYXNzPSIiPklmIHRoZSByZXF1ZXN0cyBjb21lIGZyb20gc2FtZSBjbGllbnQsIHRo ZXkgbXVzdCBoYXZlIGRpZmZlcmVudCB0b2tlbnMsIHBlciByZmMgNzI1Mi4gPC9zcGFuPjwvc3Bh bj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvcHJlPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFz cz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVy IE5ldyZxdW90OzsgYnJlYWstYmVmb3JlOiBwYWdlOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBiYWNr Z3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTMsIDI0NSk7IGJhY2tncm91bmQtcG9zaXRpb246IGlu aXRpYWwgaW5pdGlhbDsgYmFja2dyb3VuZC1yZXBlYXQ6IGluaXRpYWwgaW5pdGlhbDsiIGNsYXNz PSIiPklzIHRoZXJlIHNvbWUgcHJvYmxlbSBpbiB0b2tlbiB0aGF0IEkgZmFpbCB0byB1bmRlcnN0 YW5kIG5vdyDigJQgbmVjZXNzaXRhdGluZyB0aGUgcmVxdWVzdC10b2tlbj8mbmJzcDs8L3NwYW4+ PG86cCBjbGFzcz0iIj48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcm cXVvdDs7IGJyZWFrLWJlZm9yZTogcGFnZTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBicmVhay1i ZWZvcmU6IHBhZ2U7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZv bnQtZmFtaWx5OiBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGJhY2tncm91bmQtY29sb3I6IHJnYigy NTUsIDI1MywgMjQ1KTsgYmFja2dyb3VuZC1wb3NpdGlvbjogaW5pdGlhbCBpbml0aWFsOyBiYWNr Z3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0aWFsOyIgY2xhc3M9IiI+SW4gc2ltaWxhciB2ZWlu LCBhbmQgYXMgYSB1c2UgY2FzZSB3aGVyZSByZXF1ZXN0IHRva2VuIHNlZW1zIGdvb2QsIGlzIHRo ZSB1bmRlcnN0YW5kaW5nIGNvcnJlY3QgdGhhdCBmb3IgYmxvY2sxIHJlcXVlc3RzIGFsbCB0aGUg cmVxdWVzdCBvcHRpb25zIGFyZSBkdXBsaWNhdGVkIGluIGFsbCB0aGUgYmxvY2tzPyBJIGNvdWxk IG5vdCBmaW5kIGEgY2xlYXIgc3RhdGVtZW50LCBidXQgb25jZSBhZ2FpbiB0aGUgZmlndXJlcyBp biA3OTU5IHNob3cgdGhlIFVSSSBmb3IgZWFjaCBibG9jay4gVGhlIFVSSSBwYXRoIGFuZCBxdWVy eSBvcHRpb25zIGNhbiBiZSBsb25nLCBhbmQgdGFrZSBjb25zaWRlcmFibGUgc3BhY2UgaW4gZWFj aCBibG9jay4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGJyZWFrLWJlZm9yZTogcGFnZTsiIGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYSwg c2Fucy1zZXJpZjsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyBiYWNrZ3Jv dW5kLXBvc2l0aW9uOiBpbml0aWFsIGluaXRpYWw7IGJhY2tncm91bmQtcmVwZWF0OiBpbml0aWFs IGluaXRpYWw7IiBjbGFzcz0iIj5Db3VsZCByZXF1ZXN0IHRva2VuIGJlIHRoZSBpZGVudGlmaWVy IGZvciByZXF1ZXN0IG9wdGlvbnMsIHNvIHRoYXQgb25seSAxc3QgYmxvY2sgd291bGQgaGF2ZSBm dWxsIG9wdGlvbnMgYW5kIGxhdGVyIG9uZXMgb25seSB0aGUgdGhlIHJlcXVlc3QgdGFnPyZuYnNw OyZuYnNwOyA8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L3ByZT4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJp ZjsiIGNsYXNzPSIiPg0KU2luY2VyZWx5LDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 Oywgc2VyaWY7IiBjbGFzcz0iIj4NCi0gTGF1cmk8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCBzZXJpZjsiIGNsYXNzPSIiPg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0 aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwN CiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5 b3UuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cHJlIHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9 IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3Ow0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCjwvcHJlPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KSU1QT1JUQU5UIE5PVElDRTog VGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlk ZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0 IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBh bnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6C682C0BBE8F45A88020CB8365985CADarmcom_-- From nobody Wed Jan 20 06:34:31 2021 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 42C333A140D; Wed, 20 Jan 2021 06:34:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-core-dev-urn@ietf.org, core-chairs@ietf.org, core@ietf.org, Marco Tiloca , marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <161115326975.3512.8243027047984463257@ietfa.amsl.com> Date: Wed, 20 Jan 2021 06:34:30 -0800 Archived-At: Subject: [core] Roman Danyliw's No Objection on draft-ietf-core-dev-urn-10: (with COMMENT) 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: Wed, 20 Jan 2021 14:34:30 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-core-dev-urn-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Brian Weis for the SECDIR review. ** Section 1. Per “UUID-based identifiers are recommended for all general purpose uses when MAC addresses are available as identifiers”, this recommendation (non-normative) to use UUIDs without any context seems too strong. To me, it read like, “if you have a MAC then this is perfectly acceptable UUID”. ** Section 3.3. Per “The DEV URN type SHOULD only be used for persistent identifiers, such as hardware-based identifiers”, I have a few comments around the notion of “persistent”. -- Shouldn’t the text be s/persistent identifiers/hardware device identifiers/ as this is the definition from the first sentences of Sections 1 and 3.1? -- It seems like the document should acknowledge that “hardware-based identifiers” come in different flavors of permanence -- What would be the case for the DEV URNs to be used as ephemeral identifiers (as permitted by this text not using a MUST?) ** Section 6. Repeating the caution from Section 6 of RFC4122 seems applicable here – (paraphrasing as this urn is more generic than RFC4122) without deferring to the policies governing particular sub-types and their delegated assignees (through PENs, etc.), no assumptions should be made that these URNs are “hard to guess”. ** Section 6.1. Per “Also, usually here is no easy way to change the identifiers”, this reads a bit too strong of a statement. Given the virtualization and OS privacy features, MACs are trivial to change and urn:dev:org is defined with sufficient ambiguity (which makes sense) that it isn’t clear what rules govern it. ** Section 6.2. It would be useful to unpack “illegitimate entities on the path” – are this malicious entities which put themselves on the path, entities expected to be on the path that are acting contrary to the intent of the end points, compromised on-path infrastructure, etc … From nobody Wed Jan 20 07:29:56 2021 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 9FB4F3A149E for ; Wed, 20 Jan 2021 07:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 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, 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 Tb1sqU7RFriO for ; Wed, 20 Jan 2021 07:29:43 -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 130963A14B2 for ; Wed, 20 Jan 2021 07:29:43 -0800 (PST) Received: from [192.168.217.118] (p548dc939.dip0.t-ipconnect.de [84.141.201.57]) (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 4DLTwP2Vwtzyv7; Wed, 20 Jan 2021 16:29:41 +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: <6C682C0B-BE8F-45A8-8020-CB8365985CAD@arm.com> Date: Wed, 20 Jan 2021 16:29:40 +0100 Cc: "mohamed.boucadair@orange.com" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 632849380.8343951-65f6062d3748cc01d9a5a88e0facf298 Content-Transfer-Encoding: quoted-printable Message-Id: <2F78CEF4-5747-4B31-8A82-5328CB111A50@tzi.org> References: <32212_1611137297_60080111_32212_473_1_787AE7BB302AE849A7480A190F8B9330315BD735@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6C682C0B-BE8F-45A8-8020-CB8365985CAD@arm.com> To: Lauri Piikivi X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] Request-Token (in draft-ietf-core-new-block-06 and 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: Wed, 20 Jan 2021 15:29:53 -0000 On 2021-01-20, at 15:31, Lauri Piikivi wrote: >=20 > First of all the request-tag it is defined to overcome the weaknesses = of token=20 Well, the CoAP Token isn=E2=80=99t weak, it is solving a different = problem. A request tag is not needed if there is some other way to differentiate = different block-wise interactions, but if there isn=E2=80=99t, it can = serve as the no-op cache-key. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 20 11:33:07 2021 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 632743A1342; Wed, 20 Jan 2021 11:33:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-core-dev-urn@ietf.org, core-chairs@ietf.org, core@ietf.org, Marco Tiloca , marco.tiloca@ri.se, dromasca@gmail.com, opsdir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <161117118138.10314.2914806647572820268@ietfa.amsl.com> Date: Wed, 20 Jan 2021 11:33:01 -0800 Archived-At: Subject: [core] Warren Kumari's Yes on draft-ietf-core-dev-urn-10: (with COMMENT) 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: Wed, 20 Jan 2021 19:33:02 -0000 Warren Kumari has entered the following ballot position for draft-ietf-core-dev-urn-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this document -- it is both interesting and useful. I'd also like to thank Dan for the helpful OpsDir review. From nobody Wed Jan 20 21:14:53 2021 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 9227C3A0DAE; Wed, 20 Jan 2021 21:14:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-core-dev-urn@ietf.org, core-chairs@ietf.org, core@ietf.org, Marco Tiloca , marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <161120609258.28271.3910532837900948427@ietfa.amsl.com> Date: Wed, 20 Jan 2021 21:14:52 -0800 Archived-At: Subject: [core] Benjamin Kaduk's No Objection on draft-ietf-core-dev-urn-10: (with COMMENT) 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, 21 Jan 2021 05:14:53 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-core-dev-urn-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- What's the relationship of urn:dev:os: and urn:dev:ops to the stuff already done by OMA LwM2M? Section 4.4 has a note that it was originally defined there, but the template in Section 3 says this is the initial registration. This seems particularly important if we are also changing the syntax at the same time. The referenced [LwM2M] document seems to be https://www.openmobilealliance.org/release/LightweightM2M/V1_2-20190124-C/OMA-RD-LightweightM2M-V1_2-20190124-C.pdf (based solely on the google results for the title and comparing the revision number+date), which mentions neither "private enterprise number" nor "dev:", "serial", etc. I see a brief mention of this action in the change log in Appendix A, but no clear indication of specific change-control transfer or similar. Do we really want to reference some "tutorials" from www.maximintegrated.com as the normative reference for 1-Wire? Thanks to Brian Weis for the secdir review, and thanks for updating the document in response to it! Section 1 This document describes a new Uniform Resource Name (URN) [RFC8141] 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 [RFC8428], or equipment inventories [RFC7252], [I-D.ietf-core-resource-directory]. I'm not sure why RFC 7252 and [I-D.ietf-core-resource-directory] appear to be getting used as references for "equipment inventories" when neither mentions either term. [RFC3261], [RFC7252]. Finally, URNs can also be easily carried and stored in formats such as XML [W3C.REC-xml-19980210] or JSON [RFC8259] [RFC8428]. Using URNs in these formats is often preferable Similarly, RFC 8428 appears to be unrelated to either the XML or JSON formats directly. Future device identifier types can extend the device URN type defined here, or define their own URNs. Do we want a forward-reference to Section 7 here (we have one later on where a similar statement appears)? Section 6 We might mention again the case-sensitivity issue, and that in many cases it is easy for an attacker to create collisions. But neither of those seems particularly earth-shattering. Section 7 Do we anticipate the future allocation of a "null" subtype? ;) On a more serious note, though, "Specification Required" comes with Expert Review -- is there more guidance we should give to the experts about when to reject or accept a proposed new subtype other than "there is a new namespace with stable reference"? Perhaps a bias towards accepting all proposals that even weakly meet that criterion and are not abusive, even if not in broad use? From nobody Fri Jan 22 11:30:52 2021 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 90D453A1474; Fri, 22 Jan 2021 11:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XA_BulYBsbfp; Fri, 22 Jan 2021 11:30:49 -0800 (PST) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (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 A33A53A146E; Fri, 22 Jan 2021 11:30:45 -0800 (PST) Received: by mail-lj1-f178.google.com with SMTP id i17so7851053ljn.1; Fri, 22 Jan 2021 11:30:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=pVcQdITiXwxwIeLvHbeGAVFryXsh9N/nbP5y/x8uXps=; b=puGUJGdnfcx2sTSSwtq2ozepRA4xvi41mEGypHeTXz9dPbkUYw9tMydy22ENF96Yjh xPVTWHsuGTH2Vmpl5Z4NgoMjpOtLplmb23zL2UL7avFXXFp0O146hMBdoqD0Z5JvgZNE PHD1yXm5rXlIr225C/soRlvIfMNsmxuNLVCktgtMS70Jax9CxXuJidI34Mh0zwa2ub93 Y12Suov0D9e+5ZmKOx/5q7DQbhfyco531S+f9AMQUVmc5gosBZSONgLJ2LGHmZ/6XCik g0/svdYTkp867hPwRshhXa2h3e2B9UbdWvoJIDQLBX+UVIZA7BIFCveX6NIYSZgaAYe1 Yk8w== X-Gm-Message-State: AOAM5311JC+VXutqnApbmHm0EXu8fhegbxCQpNLSx6mzEac7H3l7+7G4 HjcjXdF0CBaXuiCuPG+FdCzlnknIv8osC8SmoxUNuc3hpgI= X-Google-Smtp-Source: ABdhPJzB5xBfHdOpZyxDtupask7CQ1xtufA1YijbwN/mXaSqyxep+7PuYeDiLBc09+YBacPkwZfTMwp5Ee9nD34e1lY= X-Received: by 2002:a2e:b5cd:: with SMTP id g13mr439097ljn.248.1611343843513; Fri, 22 Jan 2021 11:30:43 -0800 (PST) MIME-Version: 1.0 From: Barry Leiba Date: Fri, 22 Jan 2021 14:30:32 -0500 Message-ID: To: draft-ietf-core-echo-request-tag.all@ietf.org Cc: core WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [core] Status 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: Fri, 22 Jan 2021 19:30:51 -0000 This document finished last call about a month and a half ago, and I'm waiting on resolution of the GenART, TSVART, and OpsDir reviews (or for someone to tell me that no changes are needed). What's the status? Barry From nobody Mon Jan 25 10:50:42 2021 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 AC0033A174B; Mon, 25 Jan 2021 10:50:41 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <161160064165.23622.4354008976387932983@ietfa.amsl.com> Date: Mon, 25 Jan 2021 10:50:41 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-yang-cbor-15.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, 25 Jan 2021 18:50:42 -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 : CBOR Encoding of Data Modeled with YANG Authors : Michel Veillette Ivaylo Petrov Alexander Pelov Filename : draft-ietf-core-yang-cbor-15.txt Pages : 48 Date : 2021-01-24 Abstract: This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, action input, action output, notifications and yang-data extension defined within YANG modules using the Concise Binary Object Representation (CBOR, RFC 8949). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-yang-cbor-15 https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-yang-cbor-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 26 06:31:30 2021 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 26F2D3A0AE5 for ; Tue, 26 Jan 2021 06:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.653 X-Spam-Level: X-Spam-Status: No, score=0.653 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NEUTRAL=0.652, 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 B74tTOnUn__a for ; Tue, 26 Jan 2021 06:31:26 -0800 (PST) Received: from forward3-smtp.messagingengine.com (forward3-smtp.messagingengine.com [66.111.4.237]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ADC13A0AEC for ; Tue, 26 Jan 2021 06:31:25 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id 55B731948185; Tue, 26 Jan 2021 09:31:24 -0500 (EST) Received: from imap3 ([10.202.2.53]) by compute2.internal (MEProxy); Tue, 26 Jan 2021 09:31:24 -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=VN/yeDAH++PKEKv4YPJzPGaobDeTbVjhNlPJTCwnR Dk=; b=VUsTh8Fb81eZnn0lCx5hTj8+6/m+ewQ3U4qtQKpbhXFDCcbnET0C5zflc evyZQv3yWCjXnK4Q0SF2nqUVxWglrsGEFenv3I763d6SDtYZC/TrNS5KGyMHS/e0 45QWWLTgIbskaRVrHxlqJBgVXBtHHMGCzQLcqCNBxRfkCbzDjmlcn/5cD5KSI1p7 aqrPSFWhT6G1P473c3M771d05h3PjVg6lqyXTTH9RJuumYmASpTQ5m7r9UIg9TG5 fQAL2keUH+gZTByt165DUy7ocwn0fkhzQIg7dE7s3JUtK8LuLQH2XpP2jGQ5GVdZ bz6g84HyGWsduqcf2Qj4ZMCfZBm4Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeigddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomheplfgrihhm vggplfhimhornhgviicuoehjrghimhgvsehikhhirdhfiheqnecuggftrfgrthhtvghrnh epleduieffieduteetudeutdduhfekffefudefueeggedvtedvffevudduheelkeeknecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjhgrihhmvg esihhkihdrfhhi X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CD55B420062; Tue, 26 Jan 2021 09:31:22 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-78-g36b56e88ef-fm-20210120.001-g36b56e88 Mime-Version: 1.0 Message-Id: In-Reply-To: <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> <922BCE09-874C-4445-9ACC-24740CB94FD4@tzi.org> Date: Tue, 26 Jan 2021 16:31:01 +0200 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: "Carsten Bormann" Cc: "Michael Koster" , "CoRE WG" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Tue, 26 Jan 2021 14:31:28 -0000 Dear all, pinging on this. Is it there anything else that needs to be done to add = this to the secondary registry? It's something we need for IPSO as we have new objects coming. Ciao! --=20 Jaime Jim=C3=A9nez On Tue, Nov 17, 2020, at 12:16 AM, Carsten Bormann wrote: > On 2020-11-16, at 22:59, Jaime Jim=C3=A9nez wrote: > >=20 > > intriduce new errors: >=20 > Something weird happened with the table lines. >=20 > The units need to be singular, i.e., milligram, not milligrams. >=20 > (For ppb, ppt we probably want to stay with =E2=80=9Cparts per=E2=80=A6= =E2=80=9D as this is=20 > vernacular anyway.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 > From nobody Tue Jan 26 07:33:35 2021 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 CF4903A0C18 for ; Tue, 26 Jan 2021 07:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.654 X-Spam-Level: X-Spam-Status: No, score=0.654 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.652, 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 tWm_uQmNXT2r for ; Tue, 26 Jan 2021 07:33:31 -0800 (PST) Received: from forward5-smtp.messagingengine.com (forward5-smtp.messagingengine.com [66.111.4.239]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71603A0BF7 for ; Tue, 26 Jan 2021 07:33:31 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id 4A3E01943255; Tue, 26 Jan 2021 10:33:01 -0500 (EST) Received: from imap3 ([10.202.2.53]) by compute2.internal (MEProxy); Tue, 26 Jan 2021 10:33:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=jiaGY6 syhqj8X1ymjlAm5kf6O6+N/C+SocUBpWNQlI8=; b=glABvMtyWZTMpJgTVgXqtv 1LTvNm8hX/bHgPgw/qzAQmHf3ZvVIi6XBbI/YfgKcy6HUPxym2wrudZt2NxvtzoJ OqhgPlR/AKCgu2nqL/HuQtLc6RwnQCtobJUYM0weXfPeUBmL8kAtFfJD+zySzhuA FdaPDFAaptkzD5c2MiBRbRrR8ooCYTfVqxEYFWIcDFUTHTeBhPda7xcFyFyU9xbC 0QW4NcOibPdBdev34AR21TJvhXHLnl8wPHTNgEnBhftEKAsqMolGEd2kAjHjT+Lp jFfZ0aX1fgmgo7b9FNlxfhwIFkJCFwnAlxVCjYVRRodps3lTaveKhcb3ZsQBnZHg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeigdduiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpeflrghimhgv pgflihhmrohnvgiiuceojhgrihhmvgesihhkihdrfhhiqeenucggtffrrghtthgvrhhnpe efheejveetveeileekudeuvdelfeevgeeuleffvdefueehgefgvdefheeftdehffenucff ohhmrghinhepihhsohdrohhrghdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepjhgrihhmvgesihhkihdrfhhi X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BF10C420062; Tue, 26 Jan 2021 10:32:59 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-78-g36b56e88ef-fm-20210120.001-g36b56e88 Mime-Version: 1.0 Message-Id: <77fa71c2-df5e-4954-bd42-d60805fe4284@www.fastmail.com> In-Reply-To: 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> <922BCE09-874C-4445-9ACC-24740CB94FD4@tzi.org> Date: Tue, 26 Jan 2021 17:32:39 +0200 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: "Carsten Bormann" , "Michael Koster" , core@ietf.org Content-Type: multipart/alternative; boundary=ec42f82fe041462c9f287915e2feaea3 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: Tue, 26 Jan 2021 15:33:34 -0000 --ec42f82fe041462c9f287915e2feaea3 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi again,=20 this is the last version I have of the table. On the SenML Units registry: +=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+ =20 | 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 | = =20 +-----------+--------------------------------+-------+ On the Secondary Units registry: +=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 | +---------+----------------------+------+----------+------+ | VAh | volt-ampere hour | VAs | 3600 | 0 | +---------+----------------------+------+----------+------+ | mg/l | milligram per liter | kg/m3| 1/1000 | 0 | +---------+----------------------+------+----------+------+ | ug/l | microgram per liter | kg/m3| 1e-6 | 0 |=20 +---------+----------------------+------+----------+------+ | g/l | gram per liter | kg/m3| 1 | 0 | +---------+----------------------+------+----------+------+ A reference for NTU can be found here for example: https://www.iso.org/s= tandard/62801.html If someone has more experience and knows better references, please let m= e know. Ciao! --=20 Jaime Jim=C3=A9nez On Tue, Jan 26, 2021, at 4:31 PM, Jaime Jim=C3=A9nez wrote: > Dear all, >=20 > pinging on this. Is it there anything else that needs to be done to ad= d=20 > this to the secondary registry? > It's something we need for IPSO as we have new objects coming. >=20 > Ciao! > --=20 > Jaime Jim=C3=A9nez >=20 > On Tue, Nov 17, 2020, at 12:16 AM, Carsten Bormann wrote: > > On 2020-11-16, at 22:59, Jaime Jim=C3=A9nez wrote: > > >=20 > > > intriduce new errors: > >=20 > > Something weird happened with the table lines. > >=20 > > The units need to be singular, i.e., milligram, not milligrams. > >=20 > > (For ppb, ppt we probably want to stay with =E2=80=9Cparts per=E2=80= =A6=E2=80=9D as this is=20 > > vernacular anyway.) > >=20 > > Gr=C3=BC=C3=9Fe, Carsten > >=20 > >=20 > >=20 > > >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --ec42f82fe041462c9f287915e2feaea3 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi again,
<= br>this is the last version I have of the table.

On the SenML Units registry:

<= /span>
+=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+     &nbs= p;           &nbs= p;    
| Symbol = ;   | Description       &nb= sp;            | = 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 |      =             =    
+-----------+--------= ------------------------+-------+

On the Secondary Units registry:

+=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  &nb= sp;       |SenML |   Scale = |Offset|
| Unit    |&nbs= p;           &nbs= p;         | Unit |  &= nbsp;       |     = ; |
+=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+
<= div>| ppb     | parts per billion &n= bsp;  | /    |   1e-9   | &= nbsp;  0 |
+---------+-------------= ---------+------+----------+------+
| pp= t     | parts per trillion   | / &nbs= p;  |   1e-12  |    0 |
+---------+----------------------+------+----------+-= -----+
| VAh     | v= olt-ampere hour     | VAs  |   3600&n= bsp;  |    0 |
+----= -----+----------------------+------+----------+------+
<= div>| mg/l    | milligram per liter  | kg= /m3|   1/1000 |    0 |
+---------+----------------------+------+----------+------+
<= /span>
| ug/l    | microgram per lit= er  | kg/m3|   1e-6   |    0 |&n= bsp;
+---------+----------------------+-= -----+----------+------+
| g/l &nbs= p;   | gram per liter       | kg= /m3|     1    |    0 |=
+---------+----------------------+-----= -+----------+------+

A reference for= NTU can be found here for example: https://www.iso.org/standard/62801.html
If s= omeone has more experience and knows better references, please let me kn= ow.

Ciao!
-- 
Jaim= e Jim=C3=A9nez

On Tue, Jan 26, 2021, at 4:3= 1 PM, Jaime Jim=C3=A9nez wrote:
> Dear all,
> 
> pinging on this. Is it there anything e= lse that needs to be done to add 
> this to the se= condary registry?
> It's something we need for IPSO as = we have new objects coming.
> 
> = Ciao!
> -- 
> Jaime Jim=C3=A9nez<= br>
> 
> On Tue, Nov 17, 2020, at 12:= 16 AM, Carsten Bormann wrote:
> > On 2020-11-16, at = 22:59, Jaime Jim=C3=A9nez <jaime@iki.= fi> wrote:
> > > 
> = > > intriduce new errors:
> > 
<= div>> > 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=9Cpa= rts per=E2=80=A6=E2=80=9D as this is 
> > verna= cular anyway.)
> > 
> > Gr=C3= =BC=C3=9Fe, Carsten
> > 
> >= ; 
> > 
> >
<= div>> 
> ______________________________________= _________
> core mailing list
> <= a href=3D"mailto:core@ietf.org">core@ietf.org
>
--ec42f82fe041462c9f287915e2feaea3-- From nobody Tue Jan 26 07:54:34 2021 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 364253A0CC0 for ; Tue, 26 Jan 2021 07:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 QldOZF3ccNJb for ; Tue, 26 Jan 2021 07:54:29 -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 720263A085E for ; Tue, 26 Jan 2021 07:54:28 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (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 4DQBBB6bTtzyTZ; Tue, 26 Jan 2021 16:54: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: <77fa71c2-df5e-4954-bd42-d60805fe4284@www.fastmail.com> Date: Tue, 26 Jan 2021 16:54:26 +0100 Cc: Michael Koster , core@ietf.org X-Mao-Original-Outgoing-Id: 633369266.3603539-b3f62d7721d449445f4aa4fa86295e9e Content-Transfer-Encoding: quoted-printable Message-Id: 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> <922BCE09-874C-4445-9ACC-24740CB94FD4@tzi.org> <77fa71c2-df5e-4954-bd42-d60805fe4284@www.fastmail.com> 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: Tue, 26 Jan 2021 15:54:32 -0000 This looks good to me. The reference should probably say that it points to ISO 7027-1:2016. I don=E2=80=99t know why we used both =E2=80=9Cvolt-ampere second=E2=80=9D= (one hyphen) and "kilovolt-ampere-hour=E2=80=9D (two hyphens) in RFC = 8798, so =E2=80=9Cvolt-ampere hour=E2=80=9D isn=E2=80=99t more = inconsistent than RFC 8798 already is to itself, but I would still write = =E2=80=9Cvolt-ampere-hour=E2=80=9D. The next step would be for you to ask IANA to register these, based on = https://mailarchive.ietf.org/arch/msg/core/I7u1kV6VXIrU7wjfRhghlTplfxA/ (The expert for the secondary registry opened in RFC 8798 is unassigned; = I=E2=80=99m sure IANA will get that fixed in the process.) Gr=C3=BC=C3=9Fe, Carsten > On 2021-01-26, at 16:32, Jaime Jim=C3=A9nez wrote: >=20 > Hi again,=20 >=20 > this is the last version I have of the table. >=20 > On the SenML Units registry: >=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+ =20 > | 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 | = =20 > +-----------+--------------------------------+-------+ >=20 > On the Secondary Units registry: >=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 | > +---------+----------------------+------+----------+------+ > | VAh | volt-ampere hour | VAs | 3600 | 0 | > +---------+----------------------+------+----------+------+ > | mg/l | milligram per liter | kg/m3| 1/1000 | 0 | > +---------+----------------------+------+----------+------+ > | ug/l | microgram per liter | kg/m3| 1e-6 | 0 |=20 > +---------+----------------------+------+----------+------+ > | g/l | gram per liter | kg/m3| 1 | 0 | > +---------+----------------------+------+----------+------+ >=20 > A reference for NTU can be found here for example: = https://www.iso.org/standard/62801.html > If someone has more experience and knows better references, please let = me know. >=20 > Ciao! > --=20 > Jaime Jim=C3=A9nez >=20 > On Tue, Jan 26, 2021, at 4:31 PM, Jaime Jim=C3=A9nez wrote: > > Dear all, > >=20 > > pinging on this. Is it there anything else that needs to be done to = add=20 > > this to the secondary registry? > > It's something we need for IPSO as we have new objects coming. > >=20 > > Ciao! > > --=20 > > Jaime Jim=C3=A9nez > >=20 > > On Tue, Nov 17, 2020, at 12:16 AM, Carsten Bormann wrote: > > > On 2020-11-16, at 22:59, Jaime Jim=C3=A9nez wrote: > > > >=20 > > > > intriduce new errors: > > >=20 > > > Something weird happened with the table lines. > > >=20 > > > The units need to be singular, i.e., milligram, not milligrams. > > >=20 > > > (For ppb, ppt we probably want to stay with =E2=80=9Cparts = per=E2=80=A6=E2=80=9D as this is=20 > > > vernacular anyway.) > > >=20 > > > Gr=C3=BC=C3=9Fe, Carsten > > >=20 > > >=20 > > >=20 > > > > >=20 > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > From nobody Tue Jan 26 08:47:34 2021 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 2C8413A0A4C for ; Tue, 26 Jan 2021 08:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.653 X-Spam-Level: X-Spam-Status: No, score=0.653 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NEUTRAL=0.652, 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 AtJ9nmJVp9WH for ; Tue, 26 Jan 2021 08:47:31 -0800 (PST) Received: from forward5-smtp.messagingengine.com (forward5-smtp.messagingengine.com [66.111.4.239]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577223A0C7B for ; Tue, 26 Jan 2021 08:47:26 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id 658E51941265; Tue, 26 Jan 2021 11:47:25 -0500 (EST) Received: from imap3 ([10.202.2.53]) by compute2.internal (MEProxy); Tue, 26 Jan 2021 11:47:25 -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=GVydZk26lERkwbN+z8SasxnrvViYTYKkVKknH5zFN MU=; b=drm6jSsCA9w+ftEf3mvD5XSKBPL5G6KT6INAP6NM3+8JQGYp7EO4u8nzk b1hH6Jb2sbY302G3Aif0+4N8XTZvLPqrpu7jIoemsJWMijr7LMC4uf7o7G7GMJ6C a6S4unT9UNhFWY7mtcpN8Q6LlYKPsFuq/VSpnWkkqbv+Y1TsqEaw86Hv5CT+AJmE Bf0knYpCTI9ghc1BWXgYrYuoxdtVbiLRkFfDusaCKK5hC3IPNXIJRXKhotcxAatj Axjo6BSk9n5RDqmkH2N97sdVR0utTAuVcII4bw2S19f2Xi+XL/L8XqWUC2Dyw6mv OrOPHe4gFng7Lyh5y59FVgIkICP2g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeigdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomheplfgrihhm vggplfhimhornhgviicuoehjrghimhgvsehikhhirdhfiheqnecuggftrfgrthhtvghrnh epveduteeikedvteehhfdvffetlefhheelhfeuvdevudeiteehjeejudfgtdeikeeknecu ffhomhgrihhnpehivghtfhdrohhrghdpihhsohdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjrghimhgvsehikhhirdhfih X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9647E420062; Tue, 26 Jan 2021 11:47:23 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-78-g36b56e88ef-fm-20210120.001-g36b56e88 Mime-Version: 1.0 Message-Id: <52df74ce-b104-4195-bbae-f8d6d4444924@www.fastmail.com> In-Reply-To: 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> <922BCE09-874C-4445-9ACC-24740CB94FD4@tzi.org> <77fa71c2-df5e-4954-bd42-d60805fe4284@www.fastmail.com> Date: Tue, 26 Jan 2021 18:47:02 +0200 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: "Carsten Bormann" Cc: "Michael Koster" , core@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Tue, 26 Jan 2021 16:47:33 -0000 Great!! I=E2=80=99ll send it now then, thanks! --=20 Jaime Jim=C3=A9nez On Tue, Jan 26, 2021, at 5:54 PM, Carsten Bormann wrote: > This looks good to me. > The reference should probably say that it points to ISO 7027-1:2016. >=20 > I don=E2=80=99t know why we used both =E2=80=9Cvolt-ampere second=E2=80= =9D (one hyphen) and=20 > "kilovolt-ampere-hour=E2=80=9D (two hyphens) in RFC 8798, so =E2=80=9C= volt-ampere hour=E2=80=9D=20 > isn=E2=80=99t more inconsistent than RFC 8798 already is to itself, bu= t I would=20 > still write =E2=80=9Cvolt-ampere-hour=E2=80=9D. >=20 > The next step would be for you to ask IANA to register these, based on= =20 > https://mailarchive.ietf.org/arch/msg/core/I7u1kV6VXIrU7wjfRhghlTplfxA= / >=20 > (The expert for the secondary registry opened in RFC 8798 is=20 > unassigned; I=E2=80=99m sure IANA will get that fixed in the process.)= >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > On 2021-01-26, at 16:32, Jaime Jim=C3=A9nez wrote: > >=20 > > Hi again,=20 > >=20 > > this is the last version I have of the table. > >=20 > > On the SenML Units registry: > >=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+ =20 > > | 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 | = =20 > > +-----------+--------------------------------+-------+ > >=20 > > On the Secondary Units registry: > >=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 | > > +---------+----------------------+------+----------+------+ > > | VAh | volt-ampere hour | VAs | 3600 | 0 | > > +---------+----------------------+------+----------+------+ > > | mg/l | milligram per liter | kg/m3| 1/1000 | 0 | > > +---------+----------------------+------+----------+------+ > > | ug/l | microgram per liter | kg/m3| 1e-6 | 0 |=20 > > +---------+----------------------+------+----------+------+ > > | g/l | gram per liter | kg/m3| 1 | 0 | > > +---------+----------------------+------+----------+------+ > >=20 > > A reference for NTU can be found here for example: https://www.iso.o= rg/standard/62801.html > > If someone has more experience and knows better references, please l= et me know. > >=20 > > Ciao! > > --=20 > > Jaime Jim=C3=A9nez > >=20 > > On Tue, Jan 26, 2021, at 4:31 PM, Jaime Jim=C3=A9nez wrote: > > > Dear all, > > >=20 > > > pinging on this. Is it there anything else that needs to be done t= o add=20 > > > this to the secondary registry? > > > It's something we need for IPSO as we have new objects coming. > > >=20 > > > Ciao! > > > --=20 > > > Jaime Jim=C3=A9nez > > >=20 > > > On Tue, Nov 17, 2020, at 12:16 AM, Carsten Bormann wrote: > > > > On 2020-11-16, at 22:59, Jaime Jim=C3=A9nez wrote= : > > > > >=20 > > > > > intriduce new errors: > > > >=20 > > > > Something weird happened with the table lines. > > > >=20 > > > > The units need to be singular, i.e., milligram, not milligrams. > > > >=20 > > > > (For ppb, ppt we probably want to stay with =E2=80=9Cparts per=E2= =80=A6=E2=80=9D as this is=20 > > > > vernacular anyway.) > > > >=20 > > > > Gr=C3=BC=C3=9Fe, Carsten > > > >=20 > > > >=20 > > > >=20 > > > > > > >=20 > > > _______________________________________________ > > > core mailing list > > > core@ietf.org > > > https://www.ietf.org/mailman/listinfo/core > > > >=20 > From nobody Fri Jan 29 06:43:41 2021 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 40BAF3A0D7D; Fri, 29 Jan 2021 06:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yd5R_NtvYkPz; Fri, 29 Jan 2021 06:43:39 -0800 (PST) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (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 E9F1F3A0D7B; Fri, 29 Jan 2021 06:43:38 -0800 (PST) Received: by mail-lj1-f178.google.com with SMTP id c18so10723190ljd.9; Fri, 29 Jan 2021 06:43:38 -0800 (PST) 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=/qqAQ0uZQfbICPdlxIDHk9RsfUbmado2MkkNeiELRqg=; b=FzukvQQiLxWmnWzuCgyUhs18AWaFWbi6CabmhaqVy5QeY7vYhA2taVzDd0MjnwOcwf /dR1H/XYkWUM8cX/v/TmFKqtwR3i5U0cLcwEbPgYph/ZMM3Bpzo4Y6LGVVOJMiJNloYz FfT9+Hvik81pdOJudwrO9Q/YhU0Dqug9V9GtpOzf9f3mv0umcF+t+GT3KoKrE2rvcUO0 FasAHXkCJcKgkTFisoOI9nxXTWH7fjrpLCcJLsV77iUb72e5vPlAEuuVAYR76xbq+IYR iy69H1M5Jhpcw4SyyzahS3pA2DeDFe8EB1rZD1YDe9JoTsWQPxv0dELtznQN0OkcCfGp DODQ== X-Gm-Message-State: AOAM5337W59osm3NEWMFbDPNEW2PD3F14tzVc8HnBQ/d0bPTn4iRvNgg n50euz+w5bPNc9Hq2BB5nKoGEGCHCld5+GJhSPT5+a48 X-Google-Smtp-Source: ABdhPJx9zxvQeet8HQzeTYagp/u1fv8DVVOl6yaRSOLarpL7LrkydWz72a+TDPzEhMLbkWV7IcXZsaxO9dWRruEDqEE= X-Received: by 2002:a2e:8ec3:: with SMTP id e3mr2478349ljl.467.1611931416563; Fri, 29 Jan 2021 06:43:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Fri, 29 Jan 2021 09:43:25 -0500 Message-ID: To: draft-ietf-core-echo-request-tag.all@ietf.org Cc: core WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] Status 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: Fri, 29 Jan 2021 14:43:40 -0000 Ping... I'm waiting for authors or shepherd to give me a signal about the status of this. Thanks, Barry On Fri, Jan 22, 2021 at 2:30 PM Barry Leiba wrote: > > This document finished last call about a month and a half ago, and I'm > waiting on resolution of the GenART, TSVART, and OpsDir reviews (or > for someone to tell me that no changes are needed). What's the > status? > > Barry From nobody Fri Jan 29 06:50:56 2021 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 B7D283A0E18; Fri, 29 Jan 2021 06:50:54 -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 qySDiD9Botvj; Fri, 29 Jan 2021 06:50: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 D30293A0EF3; Fri, 29 Jan 2021 06:50: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 02FB6405E2; Fri, 29 Jan 2021 15:50:50 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 1253D106; Fri, 29 Jan 2021 15:50:49 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:4f12:4282:3180:75d3]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9C41444; Fri, 29 Jan 2021 15:50:48 +0100 (CET) Received: (nullmailer pid 3646458 invoked by uid 1000); Fri, 29 Jan 2021 14:50:47 -0000 Date: Fri, 29 Jan 2021 15:50:47 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Barry Leiba Cc: draft-ietf-core-echo-request-tag.all@ietf.org, core WG Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3d7fvzh4npyWrLls" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] Status 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: Fri, 29 Jan 2021 14:50:55 -0000 --3d7fvzh4npyWrLls Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 22, 2021 at 02:30:32PM -0500, Barry Leiba wrote: > This document finished last call about a month and a half ago, and I'm > waiting on resolution of the GenART, TSVART, and OpsDir reviews (or > for someone to tell me that no changes are needed). What's the > status? The status is that I lost track of things and just resumed going through the open points in collaboration with the other authors; sorry for the delays. BR c --=20 Yesterday is history, tomorrow is a mystery, and today is a gift. That is why it is called the present. -- ancient saying --3d7fvzh4npyWrLls Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAUIMEACgkQOY0REtOk veGb1xAA0JGIgKjdUXfdfeC488dTjYTysHCUuZUIFzBpkeFDd4Hwdixi/RVllQsn Li+LBeobD+XskE5jEWbdrkr7lsXTAlNA1axK80LwXELW1cLrDQHQPV95isME/tHp 9zzOd4GkuoydBFrPmvyvgnl0GlbCZ+wot7rFZ/wDPEm0A8br2cK3wps0Lb4COl6/ RKb9aQ1ypwZ08hUiyoQPseTIHjB9ZVTRsCdYXrPa2ZtzmLyyGARIlidS2TTdwtaE psZW009Mkw+CJo1DHRIqXKPctCdR5hyYeh8A5Bjipz31CM0aYU39DQIdIP1eyHFj w570t7m8k4ce9x8S15gtVNBTQ2HB4i+dY65ugeQKH8grusXPGhRlpSAroVGrL95D yBQvTxSayn5lbppKQDTLjpfg/dEvU4qLVoRKMVvJHOsMGOA81CF476Y0/kvgCD3K x8ZLIp7rlNfywrsqeMP0UMwftBvAYIIKNqUg0XqSCdkT62LmdJtdMMp8E1aORTCW tr/y1aFQrndqYO1PNdo/RnsQTlwIuzTRdTUINP/HUlMtDeXaSh2VrYsaZ3yvDhYT 9rRHAzdhJwxEW45Ct/ntbLMhsOnmsF9kS0rayWss8Ldc+G75YpzsbAkowDOZv+ao jT55AmXtsSl41GTH6/bw1ty/v63Mja1JMrVtOZKaL2jrGQ5zajw= =zaN5 -----END PGP SIGNATURE----- --3d7fvzh4npyWrLls-- From nobody Fri Jan 29 06:52:27 2021 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 297763A0E18; Fri, 29 Jan 2021 06:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJkcA0f1qjfr; Fri, 29 Jan 2021 06:52:25 -0800 (PST) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) (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 C29113A103D; Fri, 29 Jan 2021 06:52:24 -0800 (PST) Received: by mail-lj1-f175.google.com with SMTP id f2so10743710ljp.11; Fri, 29 Jan 2021 06:52:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=BJOnlKjRp20/yu8zwRHIteuZ5FAvuRrD8Hj9slJmEBE=; b=QbX8kksY7bTYDX2H3rm3ZnBR4cBIKgSgWUaEqDERntZLa9WEHXb+GaCBGJp+rpf7M6 7LEpdEXhn7i5tNMtklNubU8vh6xwutKAbFI4nl4p3mBI6ZkHFdW03NFYg1ZL+WVOeGwY 4yHJYUAyhJq41yQA/c0JvtriFEpm6fFCAfrvDMZprEyEFH9SCqs5XxyohPZIHVDlyjZK V25+XG1j+LTXDON8x4gsav0eJSkgWrKIYPNfW/qsM6xW6+N097tVT6NskS+e97HskgcB 3KzdTQJoTfhtYOjXiOz5At6+Sy5Ej/C8n7qv6xrSjYn6GzT90hnAGqwFLuJlRzvPbVdL gbGw== X-Gm-Message-State: AOAM532kuMq9Wmcy3xBuobw17ZxkM1xR9vAd9/QFc5sqikCloueUldbQ 8zCZHiPGAKM69rWkUzLt9wc2m4tvs59pN/Ukw++Lh+H0KZY= X-Google-Smtp-Source: ABdhPJzbszQdAwUYt4ehlzxQN98EEC4PcNik9JI5DPiOWbVIQg1DF0G/9d5tLgnlHTXtozbI95RYOIjT1GXjK/uvlac= X-Received: by 2002:a2e:8ec3:: with SMTP id e3mr2496110ljl.467.1611931942384; Fri, 29 Jan 2021 06:52:22 -0800 (PST) MIME-Version: 1.0 From: Barry Leiba Date: Fri, 29 Jan 2021 09:52:11 -0500 Message-ID: To: draft-ietf-core-dev-urn.all@ietf.org Cc: core WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [core] draft-ietf-core-dev-urn-10 status 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, 29 Jan 2021 14:52:26 -0000 Authors and document shepherd, draft-ietf-core-dev-urn-10 has no DISCUSS points, but there are still non-blocking comments from Ben, =C3=89ric, and Roman. Do you want to address any of those before we proceed with approval? Barry From nobody Fri Jan 29 07:06:03 2021 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 A47B33A1052; Fri, 29 Jan 2021 07:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1M2IGe9SF6a; Fri, 29 Jan 2021 07:05:54 -0800 (PST) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) (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 D100C3A1078; Fri, 29 Jan 2021 07:05:42 -0800 (PST) Received: by mail-lj1-f175.google.com with SMTP id l12so10814405ljc.3; Fri, 29 Jan 2021 07:05:42 -0800 (PST) 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=mrlzNbaPZzgZyJSwnN/vv7zmwMpCDhTbbRhDNLb+/lE=; b=pqMGeD2mBiez0guvTZG7DHVH1pqDztNIfbFXyvyuH6qKJfuCnQ8cMh2vj3aA19PJSr CJJcVm67o/nnBcY0XmSD5IcbwO9YTZwfrjjtjXx8pUWsQjd+7asUDV6Nyo/ca8vlqVYe JVniCvg2fMbs8Qd6pAI9+X9ZKkp+RbzFPpY8O2/Ci2+GOTM/iQoUcBjYUAD5fqDhz/e0 ONVsWN2UMZatNPsiUAGVS3u5mZ5ysC7upawYNTd4srD/2wFAHlAy8BftLp20hlmyi1v0 CGAW+kuDFG5QtUeekLrqb/T5rcVIIjzrdnE7kXmyzX8sEZIDOqxbAz1S9eBMw4os633B rwhQ== X-Gm-Message-State: AOAM533Es3uXTQ0KhZ4LCNcRMlr16PYgd0JXbKoQn0Tm564ahaFpYmvx b8Ak/nFy7Hj7URBEuj5gruNSluOSXawhoDD42YM= X-Google-Smtp-Source: ABdhPJxDxtvlzlBmgV22HDKbZBSEFyIyH6zMfQaXwQJdbYBJW/D62CKbXPj8qsAtPjYXjT6bc1K+B+dneUI79FHYq3I= X-Received: by 2002:a2e:824b:: with SMTP id j11mr2641203ljh.473.1611932740178; Fri, 29 Jan 2021 07:05:40 -0800 (PST) MIME-Version: 1.0 References: <159730632066.12379.5174560093789503034@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> <20201103172739.GE45088@hephaistos.amsuess.com> In-Reply-To: <20201103172739.GE45088@hephaistos.amsuess.com> From: Barry Leiba Date: Fri, 29 Jan 2021 10:05:28 -0500 Message-ID: To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: Benjamin Kaduk , draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, The IESG , core WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Fri, 29 Jan 2021 15:05:59 -0000 Ben, can you check version -26 and see how much of your ballot is addressed there? Christian, do you think you've addressed all of Ben's issues in -26? Barry On Tue, Nov 3, 2020 at 12:28 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 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 crea= ted. > The First-Come-First-Remembered policy implements one of the candidates t= hat > were considered for this role, and was picked because unlike its "endpoin= t 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: > > > > (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 b= e > > known (though for static networks it could be), yet I don't see any > > discussion that indicates this as a prerequisite; and > > > > (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 kn= ow the > clients' expectations, the clients may only expect things they know to be= true > 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 end= points > mimick the examples of RFC6690; it is a point here to have things look ju= st > like in direct discovery. > > The if=3Dcore.a and if=3Dcore.p use values from the expired and partially= abandoned > 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 regi= stered, > but not to for et but for rt) and rt=3D"light"; rt=3Dsensor was dropped a= s 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 discover= y > > 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 ho= st > discovery steps are generally unprotected; instead, it emphasizes the > importance of checking the RD's authorization for any security properties= the > client would expect. In the context of the server authorization topic (se= e > OPEN-SERVER), it was added that if the authorization is conditional on th= e > resources being advertised with a particular resource type, that authoriz= ation > 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 lai= d > > out; this document had the misfortune of being the last one I got to > > this week. > > > > Section 1 > > > > [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 practica= l > > due to sleeping nodes, disperse networks, or networks where multicas= t > > traffic is inefficient. These problems can be solved by employing a= n > > entity called a Resource Directory (RD), which contains information > > about resources held on other servers, allowing lookups to be > > performed for those resources. > > > > 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= by a > security policy backed by the RD's credentials. > > > Section 2 > > > > 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. > > > > 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 structu= re 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 thi= ng. > > > 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. > > > > 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 autono= mously > while the CT is absent and can thus not refresh registrations, but those = exceed > the scope of the document. (Discussed at > https://github.com/core-wg/resource-directory/issues/290). > > > Section 3.1 > > > > Information SHOULD only be stored in the RD if it can be obtained by > > querying the described device's /.well-known/core resource directly. > > > > When might that not be the case? > > response: > > The prime example here is with devices that don't even have a copy of wha= t they > might want to (but can't for resource constraints) express there; those u= se 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 pu= blish > data to an authorized RD of which they don't even know who precisely migh= t be > authorized to read them. > > > Section 3.2 > > > > 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 > > > > (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. > > > > 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. > > > > 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 u= ses > simple client has no way of managing the contents. If it were capable eno= ugh to > do that, it'd go the regular registration route. > > > Section 4 > > > > 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 recover= y > > is not possible. In particular, they should retry the request upon > > > > "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 > > > > 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*". > > > > 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 > > > > "core.rd" in the query string. Likewise, a Resource Type parameter > > value of "core.rd-lookup*" is used to discover the URIs for RD Looku= p > > operations, core.rd* is used to discover all URI paths for RD > > operations. [...] > > > > 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= /277. > > > 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. > > > > 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 t= hus > 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]): > > > > Req: GET /.well-known/core?rel=3Dimpl-info > > > > 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 (i= n > https://github.com/core-wg/resource-directory/pull/278). > > > Section 5 > > > > 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 secur= ity > 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 > > > > 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 end= point > lookup interface. > > Note that around ACE, bearer tokens (which capability URLs are) are gener= ally > discouraged in favor of proof-of-possession tokens. > > > The registration request interface is specified as follows: > > > > Interaction: EP -> RD > > > > 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= the > 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. > > > > 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", > > > > (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 h= ave > ct=3D entries for reasons of chronology), and keeping them aligned is a g= ood > thing. > > > An RD may optionally support HTTP. Here is an example of almost the > > same registration operation above, when done using HTTP. > > > > Req: > > POST /rd?ep=3Dnode1&base=3Dhttp://[2001:db8:1::1] HTTP/1.1 > > Host: example.com > > > > 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 he= re, > but performing "almost the same registration" over two protocols already > necessarily does that). > > > Section 5.1 > > > > 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 kn= own, > 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. > > > > 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 > > > > 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. > > > > (This MAY is actually a MUST for the simple registration case, per =C2= =A75.1, > > right?) > > response: > > No, it's a choice there as well. One server may keep them around forever,= and > 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 > > > > An update MAY update the lifetime or the base URI registration > > parameters "lt", "base" as in Section 5. Parameters that are not > > > > 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 > > > > 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. > > > > 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 b= e > > 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 > > > > 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 t= he > 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 = even > look at the registrations themselves". > > > Section 6.1 > > > > 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. > > > > Are the "submitted ones" the submissions at registration time, or durin= g > > 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= . > > > > 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 > > > > The page and count parameters are used to obtain lookup results in > > specified increments using pagination, where count specifies how man= y > > > > (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 define= d > > as "link-type" match if the search value matches any of their values > > > > 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. > > > > 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. (Jus= t 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-Por= t > 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 situati= ons, > but when they do happen. We don't automatically declare the offending par= ty > broken by putting a MUST here, but encourage the peer to assist it. The c= lient > can help by providing the relative reference (for then, disagreement pass= ses > unnoticed), and the server by recognizing the full URI (for the client ma= y have > obtained it and not know that it'd match what the server thinks is its Ur= i-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= out > //hostname/path style references). > > > Section 6.3 > > > > The following example shows a client performing a lookup of all > > resources of all endpoints of a given endpoint type. It assumes tha= t > > 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]= . > > > > 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 > > > > The endpoint lookup returns registration resources which can only be > > manipulated by the registering endpoint. > > > > 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 NO= T > > attempt to dereference or manipulate them. > > > > 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 additional= ly be > used in implementation defined operations on the resource that could be a= llowed > for administrators. Last but not least, link-format (unlike the upcoming = CoRAL) > 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 n= ot be > exposed to just any lookup client). > > The WG discussion of this did, however, lead to a point added to the secu= rity > 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. [...] > > > > The "same address" as what? > > response: > > Sharpened in https://github.com/core-wg/resource-directory/pull/294. > > > Section 7.1 > > > > Whenever an RD needs to provide trustworthy results to clients doing > > endpoint lookup, or resource lookup with filtering on the endpoint > > > > 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 th= e > > 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 > > > > I suppose there might be plausible authorization models where a > > return-routability check to a given address constitutes authorization t= o > > 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 u= ses a > different (and usually dormant) network interface for registration, the l= ine > between EP and the CT gets blurry; we tolerate that blurriness because th= e > 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 th= ere 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 firs= t > place; it is more reflective of what I understand to be an industry pract= ice > 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. I= n > > an ACE context, those are typically transported in a scope claim. > > > > 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 > > > > 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 > > > > 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 wit= h not > implementing retry, UUID URNs are pointed to, which themselves cover the = topic. > > > Section 7.2 > > > > 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. > > > > 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, a= n > 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= trust > that metadatum (which they'll want to verify from some claim) know they c= an > trust the RD to have checked ep names. > > See also GENERIC-WHOPICKSMODEL > > > An RD may also require that only links are registered on whose ancho= r > > (or even target) the RD recognizes as authoritative of. One way to > > > > 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 > > > > In contexts where we discuss DTLS and TLS as being generally comparable= , > > we typically will state that DTLS replay protection is required in orde= r > > 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 th= e > issue described at OPEN-REPLAY-FRESHNESS, but once that is addressed for = good, > 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 discussio= n > > 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 name= s > > 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 repeatin= g > > 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 > > > > 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). > > > > 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 > > > > 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 serve= r > > were found to be 19 times larger than the request. An RD which > > > > (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 > > > > Should we also include "rt" in the initial entries? I see it is used a= s > > 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, a= nd > while there's been talk over ond over that it would be nice, I don't thin= k > there will be any until linkformat-CoRAL conversion is defined (and even = then > it may not be comprehensive). Selectively picking some distinguished comm= on > link attributes into this registry won't make things less messy. > > The prime line of defense against this getting messy is the expert guidan= ce > that for some types of parameters their short names should be checked aga= inst > "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... > > > > 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 th= e > > > > ... and this text suggests that query parameters for *resource* lookups > > need not be registered.) > > > > 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 wit= h > > an "if" query parameter could ambiguously filter by the registered > > endpoint property or the [RFC6690] target attribute). > > > > 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 no= t be > registered. These unregistered wild-west attribute names can be used both= with > 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, th= at > would not per se create ambiguous queries (the rules would still say "mat= ches > either"), but the results would be prone to causing confusion. > > > Section 10.1.2 > > > > 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. > > > > Just to check: the luminaries are learning their own group membership b= y > > querying the resource directory? > > response: > > Not directly. They (in this very particular example that seems to be base= d on > industry process but which I'd not necessarily recommend for imitation) u= se a > heuristic to find any multicast URI they might possibly provide, and join= that > group. > > > Section 10.2.2 > > > > Please expand MSISDN. > > response: > > Taking a step back from this and other comments led to a drastical shorte= ning > of the example. > > See also GENERIC-ODDEXAMPLES > > > Section 13.2 > > > > I think RFC 7252 should probably be normative. > > > > 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 happ= ens 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). From nobody Fri Jan 29 07:07:07 2021 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 06B583A1053; Fri, 29 Jan 2021 07:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMYl27P6b9xh; Fri, 29 Jan 2021 07:07:00 -0800 (PST) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (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 1E2F13A1059; Fri, 29 Jan 2021 07:06:55 -0800 (PST) Received: by mail-lj1-f179.google.com with SMTP id v15so7824688ljk.13; Fri, 29 Jan 2021 07:06:55 -0800 (PST) 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=0ieoF91Hv/bhN2LZaFUHIq7lvrQiX/oVJ7R3uKwo57I=; b=lweFEd8baHEgA160qOKGZj8UxpbQ3IC6PhmSsFRxKAKqD8LXUjBA65IF+XuTNl6AU3 UZ7WPf459EJ6Xu9oECef6szicQioYoo86mAh2e7iYs/EFHaSvsPJnCMEoP/C/nB3aD4w qiqLeypDrMADo/H2jGqIs1qm0uE4riP+AIZCgfyWelZ+3tB/zshYnYAjGWAXuiDUOSr1 HAIk0dBjeCgwySNxedGGsafSjNAGvSvt3hkVn1rNxFm/4SK+Y7hbVgBktKmtvpYcvpWN sUNpGkmGUTR2tXYowKT3dZZELfTd2WiYV+DSAk3UVDsH5ZQsEe2MeDyuoNTyEDG+YLDI VwhA== X-Gm-Message-State: AOAM532vDQ4W2a1z373mFoMrLHONp7gys5+4dUDoJoE/av8rNHsHzO3R 4BnQxp23N4J4NWtX4jtBrX3Ch+E2xJlL1SU5Y2gY+Pu0 X-Google-Smtp-Source: ABdhPJwjJoBUCTg/CGAudikRA55IJ3lB8b5DJN07MaaHC6KkUsvViY3BQVlGylBKJzAdECQ0nciqYD0XrhMVcPZwczE= X-Received: by 2002:a2e:7d04:: with SMTP id y4mr2634503ljc.65.1611932813233; Fri, 29 Jan 2021 07:06:53 -0800 (PST) MIME-Version: 1.0 References: <159661278180.30518.10421410106159995546@ietfa.amsl.com> In-Reply-To: <159661278180.30518.10421410106159995546@ietfa.amsl.com> From: Barry Leiba Date: Fri, 29 Jan 2021 10:06:42 -0500 Message-ID: To: =?UTF-8?B?w4lyaWMgVnluY2tl?= Cc: The IESG , jaime.jimenez@ericsson.com, core-chairs@ietf.org, Bob Hinden , draft-ietf-core-resource-directory@ietf.org, Ole Troan , =?UTF-8?Q?Jaime_Jim=C3=A9nez?= , core WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-core?= =?utf-8?q?-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: Fri, 29 Jan 2021 15:07:02 -0000 =C3=89ric, will you please check version -26 and see if your DISCUSS is handled there? Thanks, Barry On Wed, Aug 5, 2020 at 3:33 AM =C3=89ric Vyncke via Datatracker wrote: > > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-core-resource-directory-25: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ > > > > ---------------------------------------------------------------------- > 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)... whil= e > 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 c= urrent > responsible ADs on this aspect. > > 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. > > BTW, I appreciated the use of ASCII art to represent an entity-relationsh= ip > diagram ! > > Please find below a couple of non-blocking COMMENTs (and I would apprecia= te a > reply to each of my COMMENTs) and 2 blocking DISCUSS points (but only tri= vial > actions/fixes are required). > > I hope that this helps to improve the document, > > Regards, > > -=C3=A9ric > > =3D=3D DISCUSS =3D=3D > > -- 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 configur= ed via > SLAAC, DHCPv6 other-information can be used to configure the Recursive DN= S > Server (or possibly the RD). > > -- Section 4.1.1 -- > Another trivial DISCUSS to fix: in which message is this RDAO sent ? I gu= ess > unicast Router Advertisement but this MUST be specified. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > =3D=3D COMMENTS =3D=3D > > In general, I wonder how much interactions and exchanges of ideas have ha= ppened > in the long history of this document with the DNSSD (DNS Service Discover= y) > Working Group that has very similar constraints (sleeping nodes) and same > objectives. > > -- 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 m= ind too > much the use of "destination address (URI)" as it is really 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" ? > > -- Section 3.3 -- > Should the lifetime be specified in seconds at first use in the text? > > -- Section 3.6 -- > Is the use of "M2M" still current? I would suggest to use the word "IoT" = esp > when 6LBR (assuming it is 6LO Border Router) is cited later. > > Please expand and add reference for 6LBR. > > Using 'modern' technologies (cfr LP-WAN WG) could also add justification = to > section 3.5. > > -- Section 4.1 -- > About "coap://[MCD1]/.well-known/core?rt=3Dcore.rd*", what is the value o= f MCD1 ? > The IANA section discuss about it but it may help the reader to give a hi= nt > before (or simply use TBDx that is common in I-D). > > Any reason to use "address" rather than "group" in "When answering a mult= icast > request directed at a link-local address" ? > > Later "to use one of their own routable addresses for registration." but = there > can be multiple configured prefixes... Which one should the RD select ? S= hould > this be specified ? > > 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 ? > > -- 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). > > -- Section 5 -- > May be I missed it, but, can an end-point register multiple base URI ? E.= g., > multiple IPv6 addresses. > > -- Section 9.2 -- > For information, value 38 is already assigned to RFC 8781. > > =3D=3D NITS =3D=3D > > -- Section 2 -- > The extra new lines when defining "Sector" are slighly confusing. Same ap= plies > to "Target" and "Context". This is cosmetic only. > > > From nobody Fri Jan 29 07:08:04 2021 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 6EA773A1066; Fri, 29 Jan 2021 07:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj0PEEaM5lUa; Fri, 29 Jan 2021 07:07:57 -0800 (PST) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (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 D7BE73A111E; Fri, 29 Jan 2021 07:07:53 -0800 (PST) Received: by mail-lf1-f54.google.com with SMTP id b2so12965967lfq.0; Fri, 29 Jan 2021 07:07:53 -0800 (PST) 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=qfodEZ5ALYLg8NaHxohErFnRiL5Oqxe4hwNnG/x3bGo=; b=ee3ph0QwiPSWZYSKBtxWSrWnwlIc+Wnt/54KVEvwEbqr7qg/7/a/KFBFfbgeoFLPY9 ra5GfKzDtmJ3fAmpLntjm6NTCN0Src5JZRBbB2m2MbRUJuTKR+IsszQIV5Hgs09DdEvO uPWlH7Yztt9721oKGfMIHpmGhC+OmxFIGfuryJcTiKg0gnoHdrARZ9R9R9VFEmd6jyZl zm1MNQXLPB1H6tsNOZ2xAcYuTMFdFGswPr+lK0Tvb6aY76r+teX1A9BSuO47lNmr2hhw XYgUTnIun6St/EOsYFY5/A1cFaxNLTSRk1vMz26N9oLSLIopscVteQWPXWllfpZq3qcu SviA== X-Gm-Message-State: AOAM531BGe+K/WBzATYku66Q8QzIURaLgou+jHmrE5T/vPE1bDML0qse Nl/CGUAuwXvmqejcunYa9ouBUebFi7cCo4cfvrI= X-Google-Smtp-Source: ABdhPJxTjVcxZF7WLFOGZjOn22haVFcpTBISE9BdseNNkghYCz8DbOznChjMZmMyDxM4jduM8wIOySDlARM3OtacQZw= X-Received: by 2002:ac2:592a:: with SMTP id v10mr2358974lfi.123.1611932871886; Fri, 29 Jan 2021 07:07:51 -0800 (PST) MIME-Version: 1.0 References: <159721596413.8457.13314798043091474779@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> <20201103172847.GF45088@hephaistos.amsuess.com> In-Reply-To: <20201103172847.GF45088@hephaistos.amsuess.com> From: Barry Leiba Date: Fri, 29 Jan 2021 10:07:40 -0500 Message-ID: To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: Erik Kline , draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, The IESG , core WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Fri, 29 Jan 2021 15:08:00 -0000 Erik, will you please check Christian's response and version -26, and see if your DISCUSS is handled? Thanks, Barry On Tue, Nov 3, 2020 at 12:29 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 DISCUSS: > > > [ section 4.1.1 ] > > > > * Did this get presented to 6man at any point, either via mail to the l= ist or > > chair or in a presentation slot at an IETF meeting or a 6man interim? > > > > I feel confident that there would be no objection to the option as de= scribed > > here, but the working group should have its chance to make an evaluat= ion > > irrespective of my opinion. > > see: GENERIC-6MAN > > > If this is to be used when link-local methods don't work, another opt= ion > > would have been to add an RD PVD API key and recommend including a PV= D > > option. > > response: > > The RDAO should compose well with PvD based options without further measu= res, > but does not receive explicit treatment here as no use of PvDs is known w= ith > constrained devices yet. Please see the more comprehensive discussion of = PvD in > the comment =C3=89ric Vyncke raised. > > > [ section 4.1.1 & 9.2 ] > > > > * Please clarify which ND messages can carry an RDAO. I suspect they s= hould > > only appear in RAs, but it would be good to state the expectation exp= licitly. > > respond: > > You are right, and the text now says so. > > The concrete change is in https://github.com/core-wg/resource-directory/p= ull/262. > > > [ Appendix A. ] > > > > * Can you explain the ff35:30:2001:db8:1 construction? RFC 3306 sectio= n 4 > > defines some fine-grained structure, and I'm wondering how a group ID= of 1 > > is selected/computed/well known. If there is already a COAP document > > describing this vis. RFC 3307 section 4.*, perhaps it's worth droppin= g a > > reference in here. > > response: > > See GENERIC-FFxxDB > > As COMMENT: > > > [ section 1 ] > > > > * 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 introduct= ion in > https://github.com/core-wg/resource-directory/pull/269. > > > [ section 10.1.1 ] > > > > * What is meant by "therefore SLAAC addresses are assigned..." followed= by this > > table of not-very-random-looking IPv6 addresses? > > > > Is the assumption that there might not be some off-network DNS server= but > > there is some RA with a /64 A=3D1 PIO? > > response: > > There are two scenarios that satisfy the tacit assumptions -- a router ca= n be > in place without an uplink or any DNS server and still supply ULA A=3D1 P= IOs, or > there is a routable prefix around, but not yet coordinated with the light= ing > 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 add= resses > 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). From nobody Fri Jan 29 07:10:53 2021 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 5DDE83A105D; Fri, 29 Jan 2021 07:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDGku1KntKpc; Fri, 29 Jan 2021 07:10:51 -0800 (PST) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) (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 0722B3A105B; Fri, 29 Jan 2021 07:10:51 -0800 (PST) Received: by mail-lj1-f170.google.com with SMTP id e18so10821523lja.12; Fri, 29 Jan 2021 07:10:50 -0800 (PST) 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=MpmkkjbmoITjmLUw1/zkBHC5zINkhjNDvPpWpbawPE4=; b=CJnOOwuRBsmLfJSLJK2qS1wnbOUsnWQkzUdGlYO81HzZP+OC8YkEPX4QQadDZtPjar RITXSwPl7NqQ2pxCTYDi52lmJkElSrRsVCS542qrXrJEtLOQ60SKSVA/kWH7+j+QH+5R rJ2rScWJcuQMU2d1VryM1iOX3/3NFqEaWMUSZbjzj34P3JaWYDSuGUT8sHFcI809fb7W 16Jj6U473qdqd4PfMnpbglw4RWYJlfeliEtgnwdXr7vAL7uMsSYox/SPF+Agw7fcC2Is C8JREZ5eFyPqKG1/owrs3oIyw0iVdk/rRpv1eMvPu4CQMSf5iyQf9qq6QlIP83kMoXDB MuPA== X-Gm-Message-State: AOAM5338JreOiqGyJxQIkZimBvbovThMW7K99C9eOJvcWNq6U8b4zgOX y3AL1ePEf5XVBIaSzvwSgCHJjWdNDLcGYH+gCEJvhDc+ X-Google-Smtp-Source: ABdhPJw07SPL6WL6WdqJ4TmBd2ZhhQuAcbOoBfnRx5U3uhGa49UJZR+hBmrUMLcdVVj1B7poSpUxq6pjBwc6MqndbTg= X-Received: by 2002:a2e:824b:: with SMTP id j11mr2653999ljh.473.1611933049203; Fri, 29 Jan 2021 07:10:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Fri, 29 Jan 2021 10:10:37 -0500 Message-ID: To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= Cc: draft-ietf-core-echo-request-tag.all@ietf.org, core WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] Status 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: Fri, 29 Jan 2021 15:10:53 -0000 Thanks! b On Fri, Jan 29, 2021 at 9:50 AM Christian M. Ams=C3=BCss wrote: > > On Fri, Jan 22, 2021 at 02:30:32PM -0500, Barry Leiba wrote: > > This document finished last call about a month and a half ago, and I'm > > waiting on resolution of the GenART, TSVART, and OpsDir reviews (or > > for someone to tell me that no changes are needed). What's the > > status? > > The status is that I lost track of things and just resumed going through > the open points in collaboration with the other authors; sorry for the > delays. > > BR > c > > -- > Yesterday is history, tomorrow is a mystery, and today is a gift. That > is why it is called the present. > -- ancient saying From nobody Fri Jan 29 08:55:16 2021 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 220E13A1165; Fri, 29 Jan 2021 08:55: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, SPF_HELO_NONE=0.001, SPF_NONE=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 aOZ1zXVzxhws; Fri, 29 Jan 2021 08:55:13 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.219.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5513A1164; Fri, 29 Jan 2021 08:55:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1CD2A66020F; Fri, 29 Jan 2021 18:55:12 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74a9c58nvIUJ; Fri, 29 Jan 2021 18:55:10 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 28825660119; Fri, 29 Jan 2021 18:55:10 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Fri, 29 Jan 2021 18:55:04 +0200 Cc: draft-ietf-core-dev-urn.all@ietf.org, core WG Content-Transfer-Encoding: quoted-printable Message-Id: <42B9CBC6-6A7D-436F-86CD-6CD6F1DD9CF0@piuha.net> References: To: Barry Leiba X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-dev-urn-10 status 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, 29 Jan 2021 16:55:15 -0000 Hi Barry, I would like to go through the points and address the ones that need = addressing =E2=80=94 but have not had time to do that yet. Please hold = for a few days. Jari > On 29 Jan 2021, at 16.52, Barry Leiba wrote: >=20 > Authors and document shepherd, >=20 > draft-ietf-core-dev-urn-10 has no DISCUSS points, but there are still > non-blocking comments from Ben, =C3=89ric, and Roman. Do you want to > address any of those before we proceed with approval? >=20 > Barry From nobody Fri Jan 29 09:25:33 2021 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 23F243A11A9; Fri, 29 Jan 2021 09:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lwlcx7M3cC_U; Fri, 29 Jan 2021 09:25:29 -0800 (PST) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (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 3B7E23A11A5; Fri, 29 Jan 2021 09:25:29 -0800 (PST) Received: by mail-lj1-f173.google.com with SMTP id b20so3503602ljo.1; Fri, 29 Jan 2021 09:25:28 -0800 (PST) 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=Natecz/oihJXue70bJUI7N9NfQ0Qhxx689UhrTNybtw=; b=q1SqfnDnZ5IIwNyOxAGAU00iriIV3llUJ0ClgT/3QZiFdrO7BZtWIBhv+q/WMvmDU3 AkCA4yoc4j4ea0yCPDqWjaG9smhHczw5ygA8y1q5CI6B9TghNeiaHlezAfjMto7cw4xM +8jezpzSV8xvMUmeFx8q7gCUVvptFCKQ+cemm+sj5WQS67cYeatlt8SyFSW4kY//udBv C3FhNtIxAs6cWhbvyrurkPF182jl3Qj60U3blovKleGU6cn9WAvkABSodPYwYOn8+SBr PlrQ/sH6OBvmPUJKpJb0eylAJ5X+tGOhu/JY8upxXhlBM4AfRCZ48K9L/bY8lBPimuEK f4TA== X-Gm-Message-State: AOAM530LRo1vpdmQZZBEER+ktT22dZxjvO54v0ajdyh8+1rkE7oH4bvy U52lD0SMGQVGldlsWdAh07/lEGchtSY51fLIJD8= X-Google-Smtp-Source: ABdhPJzx4Ya5Rb6EGJ1MPHQC6z4iN9HEfEuTHc6l43joG+EV4YR0AMYHypPM0DwLxZ8ziUcFkuRunWJOSI45hRLDjwo= X-Received: by 2002:a2e:7d04:: with SMTP id y4mr2946601ljc.65.1611941127224; Fri, 29 Jan 2021 09:25:27 -0800 (PST) MIME-Version: 1.0 References: <42B9CBC6-6A7D-436F-86CD-6CD6F1DD9CF0@piuha.net> In-Reply-To: <42B9CBC6-6A7D-436F-86CD-6CD6F1DD9CF0@piuha.net> From: Barry Leiba Date: Fri, 29 Jan 2021 12:25:14 -0500 Message-ID: To: Jari Arkko Cc: draft-ietf-core-dev-urn.all@ietf.org, core WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] draft-ietf-core-dev-urn-10 status 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, 29 Jan 2021 17:25:31 -0000 Holding. Thanks for the update, and enjoy your weekend. Barry On Fri, Jan 29, 2021 at 11:55 AM Jari Arkko wrote: > > Hi Barry, > > I would like to go through the points and address the ones that need addr= essing =E2=80=94 but have not had time to do that yet. Please hold for a fe= w days. > > Jari > > > On 29 Jan 2021, at 16.52, Barry Leiba wrote: > > > > Authors and document shepherd, > > > > draft-ietf-core-dev-urn-10 has no DISCUSS points, but there are still > > non-blocking comments from Ben, =C3=89ric, and Roman. Do you want to > > address any of those before we proceed with approval? > > > > Barry > From nobody Fri Jan 29 14:27:42 2021 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 1249B3A133D; Fri, 29 Jan 2021 14:27:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-core-resource-directory@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime.jimenez@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <161195926061.2651.9906207311487711748@ietfa.amsl.com> Date: Fri, 29 Jan 2021 14:27:41 -0800 Archived-At: Subject: [core] Erik Kline's No Objection on draft-ietf-core-resource-directory-26: (with COMMENT) 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: Fri, 29 Jan 2021 22:27:41 -0000 Erik Kline has entered the following ballot position for draft-ietf-core-resource-directory-26: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ comments ]] Clearing my discuss from -25. Thanks for the thoughtful feedback. [ section 4.1.1 ] * I just thought of one thing that might help save some RA space: In the case (perhaps not the common case) there the RDAO IPv6 address is the same as the source address of the RA itself, the length field could be just 1 and the IPv6 address field omitted. I don't think this complicates parsing too much -- the length is either 3 => address included or 1 => address is the RA source address (a link-local address). I'll leave it up to the group to consider whether this is a useful optimisation or not. Perhaps this idea has already been considered and rejected, though. From nobody Fri Jan 29 14:30:20 2021 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 C85C93A133D; Fri, 29 Jan 2021 14:30:15 -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 nS5p301Q5LWx; Fri, 29 Jan 2021 14:30:00 -0800 (PST) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 4DFB63A1333; Fri, 29 Jan 2021 14:30:00 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id h6so11632955oie.5; Fri, 29 Jan 2021 14:30:00 -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=66vQvDZNhcnDg6zBV1A4Keqso4Sish/J8Tq5zWtMqDM=; b=I5lOkCocMvR/gb+kTilgJIRIVAQqJEXVGG0bQg67Acj1xKvNdIymkW4Npgi8SuSZhw paeaLodBr/HWy3ZsfOlWBROfjVABiy2fZImANRIKxhG2UE2W6eRGKwfG5+QJLC9YZxKr mWVbWw8J+4pjOG9TvPOc0edIahv9cd2oeJ/SQXqWe4+T1BbA8hOXt5Z7LiAp8M+wxTND vQt/GagkVvE5C9Dd1ScvpYQT1Wt92ldgAoVbhrU6IZcqRvCiGdo4JAoBbF12EPRFF8g3 Uq8q7bHSuEFHLHZXfUTb7jJGfB/yMv4BiXJFJj9vcdeuShuFDAvmZD5ihjESlPLy6CuL 0/DA== 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=66vQvDZNhcnDg6zBV1A4Keqso4Sish/J8Tq5zWtMqDM=; b=dNIZbNcayjBynfcF1U+eWQ+fFpSAsT+c/y1+A2qfT3mVtKlk02582zR3Ozq1cK5b0/ RDK5cFV25aXgOByt11wZJQO08pyxxW4fnggNA9xGBxIX7m9hD1DWCGblzTrqxLwGLF56 aAWT9rYW8YiyhgCqWjMOGZQhzRYRLDus8fEUnizlK3LeqI2l0XOPGY+9s9d3giIPP84L I5P8AKzYyCNNyQ0FfWKLmwLOnx00ixIF99WgSHj6ouiJ0HWj8aIJ/fMso1LdhdF2kaS4 snQtg9o90LIDSLhjq91CegkFi6h6hbwA25PyDimgkVHFmhJLN1CaxXcl6/gm6SPuQ7Ai ldGw== X-Gm-Message-State: AOAM533QlUVZxfVP4ArsHaiigizyC7FLsgNTMDgcS+LpeWhqKdBe0M0e HH6RmCDZ3WoVnIIAubzkMUY68Zm6ohLK9Iu9MHbfefE1 X-Google-Smtp-Source: ABdhPJx6EIC7z0wGa+6Sg1ueFBGMkMCPFXVbzjwGLpl1vzO7137jGBfJGIyoWq89ldjls/YWSulAJc4tA72pfYQsBpc= X-Received: by 2002:aca:6503:: with SMTP id m3mr4021150oim.97.1611959399668; Fri, 29 Jan 2021 14:29:59 -0800 (PST) MIME-Version: 1.0 References: <159721596413.8457.13314798043091474779@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> <20201103172847.GF45088@hephaistos.amsuess.com> In-Reply-To: From: Erik Kline Date: Fri, 29 Jan 2021 14:29:48 -0800 Message-ID: To: Barry Leiba Cc: =?UTF-8?Q?Christian_Ams=C3=BCss?= , draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, The IESG , core WG Content-Type: multipart/alternative; boundary="00000000000068eee905ba118b91" 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: Fri, 29 Jan 2021 22:30:16 -0000 --00000000000068eee905ba118b91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the nudge! Cleared, with one more random comment. On Fri, Jan 29, 2021 at 7:07 AM Barry Leiba wrote= : > Erik, will you please check Christian's response and version -26, and > see if your DISCUSS is handled? > > Thanks, > Barry > > On Tue, Nov 3, 2020 at 12:29 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 DISCUSS: > > > > > [ section 4.1.1 ] > > > > > > * Did this get presented to 6man at any point, either via mail to the > list or > > > chair or in a presentation slot at an IETF meeting or a 6man interi= m? > > > > > > I feel confident that there would be no objection to the option as > described > > > 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 > measures, > > but does not receive explicit treatment here as no use of PvDs is known > with > > constrained devices yet. Please see the more comprehensive discussion o= f > PvD in > > the comment =C3=89ric Vyncke raised. > > > > > [ section 4.1.1 & 9.2 ] > > > > > > * Please clarify which ND messages can carry an RDAO. I suspect they > should > > > only appear in RAs, but it would be good to state the expectation > explicitly. > > > > respond: > > > > You are right, and the text now says so. > > > > The concrete change is in > https://github.com/core-wg/resource-directory/pull/262. > > > > > [ Appendix A. ] > > > > > > * 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 of 1 > > > is selected/computed/well known. If there is already a COAP docume= nt > > > describing this vis. RFC 3307 section 4.*, perhaps it's worth > dropping a > > > reference in here. > > > > response: > > > > See GENERIC-FFxxDB > > > > As COMMENT: > > > > > [ section 1 ] > > > > > > * 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 > introduction in > > https://github.com/core-wg/resource-directory/pull/269. > > > > > [ section 10.1.1 ] > > > > > > * What is meant by "therefore SLAAC addresses are assigned..." > followed by this > > > table of not-very-random-looking IPv6 addresses? > > > > > > Is the assumption that there might not be some off-network DNS > server but > > > 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 > PIOs, 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 > addresses > > 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). > --00000000000068eee905ba118b91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the nudge!=C2=A0 Cleared, with one more rand= om comment.

On Fri, Jan 29, 2021 at 7:07 AM Barry Leiba <barryleiba@computer.org> wrote:
=
Erik, will you please che= ck Christian's response and version -26, and
see if your DISCUSS is handled?

Thanks,
Barry

On Tue, Nov 3, 2020 at 12:29 PM Christian Ams=C3=BCss <christian@amsuess.com> wro= te:
>
> (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 v= arious
> positions on draft-ietf-core-resource-directory-25" at
> <https://mailarchive.= ietf.org/arch/msg/core/xWLomwwhovkU-CPGNxnvs40BhaM/>).
>
> As DISCUSS:
>
> > [ section 4.1.1 ]
> >
> > * Did this get presented to 6man at any point, either via mail to= the list or
> >=C2=A0 =C2=A0chair or in a presentation slot at an IETF meeting or= a 6man interim?
> >
> >=C2=A0 =C2=A0I feel confident that there would be no objection to = the option as described
> >=C2=A0 =C2=A0here, but the working group should have its chance to= make an evaluation
> >=C2=A0 =C2=A0irrespective of my opinion.
>
> see: GENERIC-6MAN
>
> >=C2=A0 =C2=A0If this is to be used when link-local methods don'= ;t work, another option
> >=C2=A0 =C2=A0would have been to add an RD PVD API key and recommen= d including a PVD
> >=C2=A0 =C2=A0option.
>
> response:
>
> The RDAO should compose well with PvD based options without further me= asures,
> but does not receive explicit treatment here as no use of PvDs is know= n with
> constrained devices yet. Please see the more comprehensive discussion = of PvD in
> the comment =C3=89ric Vyncke raised.
>
> > [ section 4.1.1 & 9.2 ]
> >
> > * Please clarify which ND messages can carry an RDAO.=C2=A0 I sus= pect they should
> >=C2=A0 =C2=A0only appear in RAs, but it would be good to state the= expectation explicitly.
>
> respond:
>
> You are right, and the text now says so.
>
> The concrete change is in https://github.= com/core-wg/resource-directory/pull/262.
>
> > [ Appendix A. ]
> >
> > * Can you explain the ff35:30:2001:db8:1 construction?=C2=A0 RFC = 3306 section 4
> >=C2=A0 =C2=A0defines some fine-grained structure, and I'm wond= ering how a group ID of 1
> >=C2=A0 =C2=A0is selected/computed/well known.=C2=A0 If there is al= ready a COAP document
> >=C2=A0 =C2=A0describing this vis. RFC 3307 section 4.*, perhaps it= 's worth dropping a
> >=C2=A0 =C2=A0reference in here.
>
> response:
>
> See GENERIC-FFxxDB
>
> As COMMENT:
>
> > [ section 1 ]
> >
> > * I'm unclear on what "disperse networks" might mea= n.
>
> 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 introd= uction in
> https://github.com/core-wg/resource-direc= tory/pull/269.
>
> > [ section 10.1.1 ]
> >
> > * What is meant by "therefore SLAAC addresses are assigned..= ." followed by this
> >=C2=A0 =C2=A0table of not-very-random-looking IPv6 addresses?
> >
> >=C2=A0 =C2=A0Is the assumption that there might not be some off-ne= twork DNS server but
> >=C2=A0 =C2=A0there 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=3D= 1 PIOs, or
> there is a routable prefix around, but not yet coordinated with the li= ghting
> installation.
>
> The 2001:db8:: addresses are indeed not what one would get out of SLAA= C, but
> full random addresses would make the examples hard to read. Where the = addresses
> are introduced, they are now called stand-in addresses for the example= s (see
> https://github.com/core-wg/resource-direc= tory/pull/268 for full
> change).
--00000000000068eee905ba118b91--