From nobody Sat May 1 11:56:45 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 E3F1E3A24DE; Sat, 1 May 2021 11:56:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: Cc: core@ietf.org, draft-ietf-core-senml-versions.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161989540388.8528.14442751027312770969@ietfa.amsl.com> Reply-To: Joseph Salowey Date: Sat, 01 May 2021 11:56:43 -0700 Archived-At: Subject: [core] Secdir last call review of draft-ietf-core-senml-versions-02 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: Sat, 01 May 2021 18:56:44 -0000 Reviewer: Joseph Salowey Review result: Ready 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. The summary of the review is the document is ready. This is a short document that describes how to encode features in the SenML version. The document is clear, I don't see any security. The encoding features in a version string will cause some confusion, but this is pointed out. From nobody Mon May 3 05:16:51 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 A486A3A0CCD; Mon, 3 May 2021 05:16:50 -0700 (PDT) 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-new-block@ietf.org, core-chairs@ietf.org, core@ietf.org, marco.tiloca@ri.se, marco.tiloca@ri.se, csp@csperkins.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <162004421064.19511.6477108778521848512@ietfa.amsl.com> Date: Mon, 03 May 2021 05:16:50 -0700 Archived-At: Subject: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-new-block-11=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, 03 May 2021 12:16:51 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-core-new-block-11: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated especially on the intended status/lack of public implementations). I hope that this helps to improve the document, Regards, -éric == COMMENTS == !!! I was about to ballot a DISCUSS on this point... In the absence of a section about existing implementations for such a new transport, I really wonder whether standard track should be used rather then experimental. Did the authors/WG run some simulations ? Happy to have read Colin Perkins' review for the Transport ART, which has provided me with some confidence in this brand new transport protocol. I am also trusting the TSV Area Directors on this point. -- Section 1 -- I had in mind that constrained network are well protected either at layer-2 or by having an air-gap or firewall at their edges, so, a DoS seems quite improbable in those deployments. Should this 'use case' really be part of the introduction? Or is it simply linked to the DOTS use case ? In either case, the DoS should be more detailed. -- Section 3 -- Any reason why 'CON' is not expanded/explained on first use ? From nobody Mon May 3 05:36: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 38EFD3A0E13; Mon, 3 May 2021 05:36:12 -0700 (PDT) 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, 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, 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 rIgmJhM_QDnx; Mon, 3 May 2021 05:36:07 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (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 A51853A0E0F; Mon, 3 May 2021 05:36:06 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 4FYjBX5V60zBshl; Mon, 3 May 2021 14:36:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620045364; bh=8287P9c2HGTAnPWCFhfEjKtScV0oc4FjJxGJwOxV/4M=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=IUL7zGT7A9gSohZE1vZWFfLzGvl4eM0fJjDyr15GGi8E5vXkywD5VI5azHiCYIRJ7 lqedarG0nFdk8cuOYLSoVgB5iXBr/c9wcABXF0lUh6/1ZNPHHNuHkHAxNrZEOnoLUu IIvZsV8mdINWadz2o3fly42MidMmEkOn8bGNl5BzoH2mzYjWlYDu+FceUTdI+VZi/u ro49/7UnwCCRUoDM3L0d0mZW0vhLFDRUN2++si6qFq7OMwS59SHIfU/bkRGse3ZJ6L 5yxkPBL9RrKSlfmhfg00sDoH+JanYDpMfeaZEx1Osxi+bgL5hjQcpTBGh6MuwsCL8E LMIvQo80yBENQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4FYjBX3q5rz3wbB; Mon, 3 May 2021 14:36:04 +0200 (CEST) From: To: =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG CC: "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" , "csp@csperkins.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtY29y?= =?utf-8?Q?e-new-block-11:_(with_COMMENT)?= Thread-Index: AQHXQBY05oJi2PX0SEmSBa0SEhG1K6rRrPZg Date: Mon, 3 May 2021 12:36:03 +0000 Message-ID: <32469_1620045364_608FEE34_32469_195_1_787AE7BB302AE849A7480A190F8B933035375C5B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162004421064.19511.6477108778521848512@ietfa.amsl.com> In-Reply-To: <162004421064.19511.6477108778521848512@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: Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-new-block-11=3A_=28with_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: Mon, 03 May 2021 12:36:12 -0000 SGkgRXJpYywgDQoNClRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnRzLiANCg0KUGxlYXNlIHNlZSBp bmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiBEZcKgOiDDiXJpYyBWeW5ja2UgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRm Lm9yZ10NCj4gRW52b3nDqcKgOiBsdW5kaSAzIG1haSAyMDIxIDE0OjE3DQo+IMOAwqA6IFRoZSBJ RVNHIDxpZXNnQGlldGYub3JnPg0KPiBDY8KgOiBkcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrQGll dGYub3JnOyBjb3JlLWNoYWlyc0BpZXRmLm9yZzsNCj4gY29yZUBpZXRmLm9yZzsgbWFyY28udGls b2NhQHJpLnNlOyBtYXJjby50aWxvY2FAcmkuc2U7DQo+IGNzcEBjc3BlcmtpbnMub3JnDQo+IE9i amV0wqA6IMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWNvcmUtbmV3 LWJsb2NrLTExOg0KPiAod2l0aCBDT01NRU5UKQ0KPiANCj4gw4lyaWMgVnluY2tlIGhhcyBlbnRl cmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWNvcmUt bmV3LWJsb2NrLTExOiBObyBPYmplY3Rpb24NCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNl IGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiBlbWFpbCBh ZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBj dXQNCj4gdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQ bGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vz cy0NCj4gY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBESVNDVVNT IGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdp dGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS1uZXctYmxvY2svDQo+IA0K PiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiAtDQo+IA0KPiBUaGFuayB5b3UgZm9yIHRoZSB3b3JrIHB1dCBpbnRvIHRoaXMgZG9jdW1lbnQu DQo+IA0KPiBQbGVhc2UgZmluZCBiZWxvdyBzb21lIG5vbi1ibG9ja2luZyBDT01NRU5UIHBvaW50 cyAoYnV0IHJlcGxpZXMgd291bGQNCj4gYmUgYXBwcmVjaWF0ZWQgZXNwZWNpYWxseSBvbiB0aGUg aW50ZW5kZWQgc3RhdHVzL2xhY2sgb2YgcHVibGljDQo+IGltcGxlbWVudGF0aW9ucykuDQo+IA0K PiBJIGhvcGUgdGhhdCB0aGlzIGhlbHBzIHRvIGltcHJvdmUgdGhlIGRvY3VtZW50LA0KPiANCj4g UmVnYXJkcywNCj4gDQo+IC3DqXJpYw0KPiANCj4gPT0gQ09NTUVOVFMgPT0NCj4gDQo+ICEhISBJ IHdhcyBhYm91dCB0byBiYWxsb3QgYSBESVNDVVNTIG9uIHRoaXMgcG9pbnQuLi4gSW4gdGhlIGFi c2VuY2UNCj4gb2YgYSBzZWN0aW9uIGFib3V0IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBmb3Ig c3VjaCBhIG5ldyB0cmFuc3BvcnQsDQo+IEkgcmVhbGx5IHdvbmRlciB3aGV0aGVyIHN0YW5kYXJk IHRyYWNrIHNob3VsZCBiZSB1c2VkIHJhdGhlciB0aGVuDQo+IGV4cGVyaW1lbnRhbC4gRGlkIHRo ZSBhdXRob3JzL1dHIHJ1biBzb21lIHNpbXVsYXRpb25zID8NCg0KW01lZF0gVGhlcmUgaXMgYW4g aW1wbGVtZW50YXRpb24gYW5kIGEgUFIgd2FzIHB1c2hlZCBzbyB0aGF0IHRoaXMgZnVuY3Rpb25h bGl0eSBpcyBzdXBwb3J0ZWQgaW4gdGhlIGxpYmNvYXAuIFBsZWFzZSByZWZlciB0byB0aGUgZm9s bG93aW5nIGZyb20gdGhlIHdyaXRlLXVwOg0KDQo9PT09PT0NCkEgUHVsbC1SZXF1ZXN0IG9mIGFu IGF1dGhvcidzIGltcGxlbWVudGF0aW9uIHRvICJsaWJjb2FwIiBpcyBhdmFpbGFibGUgYXQgaHR0 cHM6Ly9naXRodWIuY29tL29iZ20vbGliY29hcC9wdWxsLzYxMSANCg0KRmVlZGJhY2sgZnJvbSB0 aGUgaW1wbGVtZW50YXRpb24gYWN0aXZpdHkgaGFzIGNvbnRyaWJ1dGVkIHRvIHRoZSBkZXNpZ24g YW5kIHJlZmluZW1lbnQgb2Ygc3BlY2lmaWMgYXNwZWN0cywgbm90YWJseToNCg0KLSBMaW1pdGlu ZyBuZXcgbWVjaGFuaWNzIGZvciBjb25nZXN0aW9uIGNvbnRyb2wgb25seSB0byBDb0FQIE5vbi1D b25maXJtYWJsZSBtZXNzYWdlcy4NCi0gTm90IG1peGluZyBDb0FQIENvbmZpcm1hYmxlIGFuZCBO b24tQ29uZmlybWFibGUgbWVzc2FnZXMgZm9yIGEgc2FtZSByZXF1ZXN0L3Jlc3BvbnNlIGJvZHku DQotIFRoZSAnQ29udGludWUnIGluZGljYXRpb24gb2Ygc3VjY2Vzc2Z1bGx5IHJlY2VpdmVkIGJs b2Nrcy4NCi0gVGhlIGRpc2NvdmVyeSBvZiBzZXJ2ZXIgc3VwcG9ydCBmb3IgdGhlIFEtQmxvY2sx IGFuZCBRLUJsb2NrMiBPcHRpb25zLg0KLSBGdXJ0aGVyIGxlc3NvbnMgbGVhcm5lZCBoaWdobGln aHRlZCBhcyAiSW1wbGVtZW50YXRpb24gbm90ZSIgaW4gdGhlIGRvY3VtZW50Lg0KPT09PQ0KDQo+ IA0KPiBIYXBweSB0byBoYXZlIHJlYWQgQ29saW4gUGVya2lucycgcmV2aWV3IGZvciB0aGUgVHJh bnNwb3J0IEFSVCwgd2hpY2gNCj4gaGFzIHByb3ZpZGVkIG1lIHdpdGggc29tZSBjb25maWRlbmNl IGluIHRoaXMgYnJhbmQgbmV3IHRyYW5zcG9ydA0KPiBwcm90b2NvbC4gSSBhbSBhbHNvIHRydXN0 aW5nIHRoZSBUU1YgQXJlYSBEaXJlY3RvcnMgb24gdGhpcyBwb2ludC4NCj4gDQo+IC0tIFNlY3Rp b24gMSAtLQ0KPiBJIGhhZCBpbiBtaW5kIHRoYXQgY29uc3RyYWluZWQgbmV0d29yayBhcmUgd2Vs bCBwcm90ZWN0ZWQgZWl0aGVyIGF0DQo+IGxheWVyLTIgb3IgYnkgaGF2aW5nIGFuIGFpci1nYXAg b3IgZmlyZXdhbGwgYXQgdGhlaXIgZWRnZXMsIHNvLCBhIERvUw0KPiBzZWVtcyBxdWl0ZSBpbXBy b2JhYmxlIGluIHRob3NlIGRlcGxveW1lbnRzLg0KDQpbTWVkXSBPbmUgc2lkZSBub3RlOiB0aGVy ZSB3ZXJlIHJlcG9ydHMgb2YgIndlYWsiIGltcGxlbWVudGF0aW9ucyBhbmQgZGVwbG95bWVudHMu IFlvdSBtYXkgcmVmZXIgZm9yIGV4YW1wbGUgdG8gaHR0cHM6Ly9mdXR1cmVpb3QudGVjaC90b3At aW90LXByb3RvY29scy1tcXR0LWNvYXAtaGF2ZS1tYWpvci1mbGF3cy13YXJucy10cmVuZC1taWNy by8gb3IgaHR0cHM6Ly93d3cuemRuZXQuY29tL2FydGljbGUvdGhlLWNvYXAtcHJvdG9jb2wtaXMt dGhlLW5leHQtYmlnLXRoaW5nLWZvci1kZG9zLWF0dGFja3MvLiBPZiBjb3Vyc2UsIHRoZXJlIGFy ZSBndWFyZHMgb3V0IHRoZXJlIGJ1dCBkZXBsb3ltZW50cyBtYXkgbm90IHN1cHBvcnQgdGhlbS4g DQoNCiBTaG91bGQgdGhpcyAndXNlIGNhc2UnDQo+IHJlYWxseSBiZSBwYXJ0IG9mIHRoZSBpbnRy b2R1Y3Rpb24/IE9yIGlzIGl0IHNpbXBseSBsaW5rZWQgdG8gdGhlDQo+IERPVFMgdXNlIGNhc2Ug PyBJbiBlaXRoZXIgY2FzZSwgdGhlIERvUyBzaG91bGQgYmUgbW9yZSBkZXRhaWxlZC4NCg0KW01l ZF0gVGhpcyBpcyBtYWlubHkgZHJpdmVuIGJ5IHRoZSBET1RTIHVzZSBjYXNlLiBOb3Qgc3VyZSB3 aGljaCBtb3JlIGRldGFpbHMgeW91IHdvdWxkIGxpa2Ugc2VlIGFkZGVkLiAgIA0KDQo+IA0KPiAt LSBTZWN0aW9uIDMgLS0NCj4gQW55IHJlYXNvbiB3aHkgJ0NPTicgaXMgbm90IGV4cGFuZGVkL2V4 cGxhaW5lZCBvbiBmaXJzdCB1c2UgPw0KDQpbTWVkXSBBY3R1YWxseSwgaXQgaXMuIFBsZWFzZSBy ZWZlciB0byBTZWN0aW9uIDE6DQoNCiAgIEFzIGEgcmVtaW5kZXIsIFtSRkM3OTU5XQ0KICAgcmVj b21tZW5kcyB0aGUgdXNlIG9mIENvbmZpcm1hYmxlIChDT04pIHJlc3BvbnNlcyB0byBoYW5kbGUg cG90ZW50aWFsDQogICBwYWNrZXQgbG9zcy4gDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Mon May 3 08:12:00 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 9FEE73A17DA; Mon, 3 May 2021 08:11:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Emmanuel Baccelli via Datatracker To: Cc: core@ietf.org, draft-ietf-core-new-block.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162005471461.25481.16323677090483356173@ietfa.amsl.com> Reply-To: Emmanuel Baccelli Date: Mon, 03 May 2021 08:11:54 -0700 Archived-At: Subject: [core] Iotdir telechat review of draft-ietf-core-new-block-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 15:11:55 -0000 Reviewer: Emmanuel Baccelli Review result: Ready with Nits iotdir telechat review of draft-ietf-core-new-block-11 Emmanuel Baccelli, 3 May 2021 ==== Summary ==== Many thanks for this document. In general, the spec is well written as far as I could see. I have a few nits and suggestions (see below). My main question is about the use of Confirmable messages. Maybe I missed something, but it seems to me the use of CON messages is not recommended in the spec, but is nevertheless evoked in the spec. Is there room for simplification, or is it considered too "radical" to only specify the use of Q-Block with non-confirmable messages? Details below. Best regards, Emmanuel ==== Comments ==== # Section 1 ## Second to last sentence: "such a recommendation does not work with a flooded pipe DDoS situation." => an explicit ref would feel natural at this point of the text (RFC8782 again? Or another ref?). ## Last sentence: Ends a little dry. How about completing it with something similar to: OLD: "This document introduces the CoAP Q-Block1 and Q-Block2 Options (Section 3)" NEW: "This document introduces the CoAP Q-Block1 and Q-Block2 Options which allow block-wise transfer to work with series of Non-confirmable messages, instead of lock-stepping using CON messages". # Section 3 It would read more naturally to my eyes if you'd swap around the section's content in the beginning (part before 3.1 begins) like this: - move up the overview of the Q-Block options, i.e essentially the part "Q-Block1 and Q-Block2 Options are designed to work in particular with NON requests and responses..." and onwards; - gather afterwards the bullet points summing up the advantages / limitations /drawbacks of Q-Block options compared to the Block options. # Section 4.1 the first time you mention POST, PUT? FETCH, iPATCH etc., I suggest you explicitly cite RFC8132 again. # Section 4.3, for Response code 4.13 "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." => since this is a *should* and not a MUST, would it make sense to add reassuring an implementer note on how to comply while minimzing buffer memory requirements? Are there use cases where the server is *very* constrained in RAM for instance (say: Class 1 devices in RFC 7228)? # Section 7.1 Do I understand correctly that this configuration (all confirmable messages for a given body) is *not* recommended? The statement "it is expected that all requests and responses using Q-Block1 and Q-Block2 will be Non-confirmable" is confusing at first sight, it begs the question: why specify the configuration using CON, then? But maybe I missed something. # Section 11 If the Request-tag happens to be an outer option (or if there is a proxy) does the above comment on section 4.3 (response code 4.13) translate in a potential resource exhaustion vulnerability for the server? From nobody Mon May 3 08:47: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 89C613A1A30; Mon, 3 May 2021 08:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.617 X-Spam-Level: X-Spam-Status: No, score=-9.617 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DqmzAAT0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=SMuFN8DL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hknfzNI2HZ5K; Mon, 3 May 2021 08:47:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660B03A1A08; Mon, 3 May 2021 08:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9004; q=dns/txt; s=iport; t=1620056832; x=1621266432; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mKSjWq6E4VcdcRloIE8FPi+HGTLofqnuc1WR1us/ieM=; b=DqmzAAT0WYbCjTRhhZTbP1kV3ysMhLenJbUT7xOPitPi1rrarY8Uw3wB Lvqcg2A7jnaUpm3yjayLNo7Np95XNoCHJ9hKYONo46An/tgnHRdVVm7nT 6mAbyCFzV58K+VLoxS3LSndctzFk636sW37syu4VYbHcbdoL4pYs1jFBi s=; IronPort-PHdr: =?us-ascii?q?A9a23=3A2gu0UB8mHQHKof9uWNfoyV9lXQAupqn0MwgJ6?= =?us-ascii?q?5Eul7NJdOG58o//OFDEjd1qllbPUoid4PVB2KLasKHlDGoH55vJ8HUPa4dFW?= =?us-ascii?q?BJNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2Yk9PEcDxahvZpXjhpTIXE?= =?us-ascii?q?w/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxnec4M?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AEwNjOaApuxbC9aflHei9tceALOonbusQ8z?= =?us-ascii?q?AX/mhLY1h8btGYm8eynP4SyB/zj3IrVGs9nM2bUZPgfVr1zrQwxYUKJ7+tUE?= =?us-ascii?q?3duGWuJJx/9oeK+VPdMgXE3Kpm2a9kGpIQNPTZB1J3lNu/xQG+HcopztXvyt?= =?us-ascii?q?HWuc715R5WPGZXQotn6Bp0DRveMmAefngHObMSEp2A6s1b4x+pfnoKZsq2b0?= =?us-ascii?q?N1IdTrjdvNiZ7gfFo6HBYh8gaDlneF77T9Hhie0H4lInBy6J0l9nXIlBG827?= =?us-ascii?q?W7v5iAu17h/kLwz7ATotvuzdNfGNeB4/J0FhzAghulDb4RIIGqkysypIiUmT?= =?us-ascii?q?MXufnK5ywtJsFir07WF1vF3SfF/ynF/HIQ52T5yVme6EGT4/DRYD4hEcJOic?= =?us-ascii?q?Z4X3LimjAdlepx2q5KwG6V3qA/ZXir8UiNhKmrazhQmkW5unYkm+II5kYvLL?= =?us-ascii?q?c2UqNbroAU4SpuYfE9NR/684wuHa1PC8zR9Z9tACunRk3ZpWVmzZiQWG0yFH?= =?us-ascii?q?69MzE/k/GSugIm+ExR/g89/ogyj30A/JUyR91v/OLfKJllk7lIU4s/cb99LP?= =?us-ascii?q?1pe7rzNkX9BTb3dE6CK1XuE68Kf1jXrYTs3bkz7Oa2PLQV0ZoJnojbWl8wjx?= =?us-ascii?q?93R2veTem1mLFb+BHER2uwGR73zNtF2pR/srrgAJ3mLDOEU1Jrt8e7uf0QDo?= =?us-ascii?q?n6Vp+ISdVrKs6mCVGrNZdC3gX4VZUXA2IZStcpttEyXE/LrdnMLoHsq+zHYP?= =?us-ascii?q?feLLfgCl8fKzrCK0pGeAK2CNRL70itVHO9qgPWQWnRdkv2+o81EKWyxZlK9K?= =?us-ascii?q?E9cql39iQFg1Ww4c+GbRdYtLYtQUd4KLT71qeypWy8+3fU/3xkUyAtVXp90f?= =?us-ascii?q?HFaTdntAUKO0T7ffIooNOEY11f23OBO1t4VMPZEAlWolxt4qKpJ5mMxSQvYu?= =?us-ascii?q?jXdF6yvj82njanXp0ckqqM6YPOYZUjFKsrX6R3CEHWDRBvgB1rr21CcQcAQU?= =?us-ascii?q?faGlrV+P+Ypa1RINuaW8h3gQ+tL8IRlGnWsl+Eo9ozAlEBWSS1bMKRiQEyZj?= =?us-ascii?q?Zdi1Fr6ZUDiL6YlTvHExpjvM0IdHl3LEWeGvZvERmMboQ8oMGbRChACUOxwQ?= =?us-ascii?q?G8pz52UGzw7EkWjnHmNkSvCIH2K2sYnGtZ3Kbs+E5zbUOHcStLGyxHmLw4M3?= =?us-ascii?q?jasXBu1uLOQay/3wKqGwU/69BYFi3Zaj0PJQ4r/fSL7Vq+nTaPEmhO/ORwAs?= =?us-ascii?q?XUEKkjf7bP2nmkNY2PkuUcE+VJ+Yt+XeqewNMjTfiSYEucIj/+FooSqn+oj2?= =?us-ascii?q?dgNy9upHY+l/T0nBXj8WijxXY6ReHfOVJ8WtggUp2hxnmhQ/aDy5Nii90p+e?= =?us-ascii?q?O2L2Xqc9aDoJunJQJrO1fWoWSsSfsvpo0RtaUutKFrF52eVTfTznlI0FE/K8?= =?us-ascii?q?jz/XluDZhT8fTEOoV1edYVdD8c9l01lM6XJE9uqxfoGIYFDBgQpm6eO8nM76?= =?us-ascii?q?vDqLIpDEHErAzsOUOH+ykY+/veRSOM2bMTFqpYGxUYVGEsrHB5uO+SfYzZDw?= =?us-ascii?q?unM/tO+1e3KXexer5QQqrtI8Rakj9qp9WT2+OHfSvx3w7d+SZhKqVV6mC9XI?= =?us-ascii?q?e8BhmPFeMgya31BX2cxq+xpMi9gzf8RWHlNwAWhYhZeVcRacoGgD84l4Ez2j?= =?us-ascii?q?WzTKuyok9NqSoo3Rh30lr2no6h6yPHGEsDNwvTiJBfRyNSPXiFlt6ty5nR6F?= =?us-ascii?q?3tpDxenYDeH0JRdMxUE9ceToLrPz5jQPJgyIKA7u4qmGBfex8gAG43lSDl0+?= =?us-ascii?q?5n1bm/3u/OW+eKMwafBXsRvThfBoB1mSQ3qWZPN8imhKjNFzkqKg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CKAACLGpBg/4ENJK1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAgVeBU1EHd1o2MYREg0gDhTmIcAO?= =?us-ascii?q?PNIodgUKBEQNUCwEBAQ0BASoIAgQBAYRQAheBZAIlOBMCBAEBDAEBBQEBAQI?= =?us-ascii?q?BBgRxE4VQDYZEAQEBAwEjEQwBATcBCwQCAQgRAwECAwIjAwICAjAUAQUDCAI?= =?us-ascii?q?EAQ0FgnEBglUDDiEBDp1YAooPEHqBMoEBggQBAQYEBIE0AQMCAQ0DAQ4JJoM?= =?us-ascii?q?sGIITAwaBECoBgniCcVNKgkSDDoEHJxyBSUKBFSccgl8+gmABAQIBgSgBEgE?= =?us-ascii?q?JGIMXNoIrgVNYGQciCzYEFA4ZEAYCDSIoKAQVPC0RMy8DkEEICw8EgndClQO?= =?us-ascii?q?QV4EUCoMQiXmHd4YAhT4FIoNUiwyGHZAlhRuQFIt/knIIGIRPAgICAgQFAg4?= =?us-ascii?q?BAQY1gTYjaVgRB3AVZQGCPlAXAg6OHwwWg06FFIIjgyZzOAIGAQkBAQMJAXu?= =?us-ascii?q?MEwEB?= X-IronPort-AV: E=Sophos;i="5.82,270,1613433600"; d="scan'208";a="866001703" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 May 2021 15:47:11 +0000 Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 143FlBQ1007933 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 3 May 2021 15:47:11 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Mon, 3 May 2021 10:47:10 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 3 May 2021 11:47:09 -0400 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 3 May 2021 11:47:09 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UsPNxMMlHUKPR9rE8lFz41gEozeJrlLsb5sHx3Ic6YZVN2Si1CLRbScHL1aYphztOD5QsuZP7ZxPIP+dY8TPI8trmQFHC5dK5ZZt83lLAszlNUCucC5BErgET8ox+lvrGn0xEel3l/ZxQ9WbeZDY1YNzle2EgZTwV6fPEhgEcD6Q8WSU0An6cVkluyZX7zmwESr3N2XNJSohqqD/A1xMdmJ4BaU81GumMDS/eoAlaxmp5lHwBGMUl3esKUQG3g14wpz5h3slrE4hVZam9VRTG43vZfA/3qgIWcljA3YrHcqMCpR5AB7fcRrVkiLfqVwsoPq3sp6LygABevEi8TUtYA== 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=mKSjWq6E4VcdcRloIE8FPi+HGTLofqnuc1WR1us/ieM=; b=dWQ6NrEP8SrjGaFFZT7U8xiI2BUWY7Ze7HUNAMfe6jUzqdYERoviKHDDgTX4hw9AY6vXAXbdzrgxz7VyeKthqxbzl8tIYE7PVXD6+0JdADfFvYVDqmtJZ7Cu7efFr57f/7eeAeUGoM13X9M9vdIoyd906C8HHpxKnYBa8djecXhmhxyG52Ga7qIyleHOyqvA8nHun4GC5/WANra+sv9++LKpTKeaZvVihWYjtzO5qooxQLPHYsgNulWxCyEvQsWoz7Mqdz8jnTxyCbNTMbsp8P3r7fWRRsdo8cUC384KnpJjlP68ekoywOyHr07Us7Npo396UvSFm+sOhjwLv7MZ3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mKSjWq6E4VcdcRloIE8FPi+HGTLofqnuc1WR1us/ieM=; b=SMuFN8DLyYcdsqux8vARpG7mfXzZx/odDp7W9a3PbYxOHvmt5yJKZh+3JCbgXqk0N4dtzK0qXaiaq6eVv3gzNQBEpdx7IGnW1fTLFe4Ld0bHE742VfT7voPC6/x1S+23nnFkbMDmJeSur3nuBoBP0EJrQGqAQQkzcYmw8izZ+ZI= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4919.namprd11.prod.outlook.com (2603:10b6:510:34::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.35; Mon, 3 May 2021 15:47:08 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::ccc:1b78:44b5:b74b]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::ccc:1b78:44b5:b74b%3]) with mapi id 15.20.4087.044; Mon, 3 May 2021 15:47:08 +0000 From: "Eric Vyncke (evyncke)" To: "mohamed.boucadair@orange.com" , The IESG CC: "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" , "csp@csperkins.org" , "Emmanuel.Baccelli@inria.fr" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtY29y?= =?utf-8?Q?e-new-block-11:_(with_COMMENT)?= Thread-Index: AQHXQBZDbuo9fWQ7OkebTxbj0UeYfqrRsZWAgABW6wA= Date: Mon, 3 May 2021 15:47:08 +0000 Message-ID: <165556CA-81F5-46F6-A40C-B4F3B69E03CC@cisco.com> References: <162004421064.19511.6477108778521848512@ietfa.amsl.com> <32469_1620045364_608FEE34_32469_195_1_787AE7BB302AE849A7480A190F8B933035375C5B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <32469_1620045364_608FEE34_32469_195_1_787AE7BB302AE849A7480A190F8B933035375C5B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:a566:ff3d:1176:7f5d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ad5addc3-d71d-41c6-8a17-08d90e4ab5a0 x-ms-traffictypediagnostic: PH0PR11MB4919: 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: 7oK7QFh9NmA3+m9w8wQArVLHeXSFTkWdpqDolqQNQRfvyHdAr4vQVxqHcNxa5ZoGEZFv2lTeeIlYXZBg7TITWpdeN2z0ZuoZAJOmVayXGtP9k5SRgJGTG3lMBZNyDvWoTLY3F7755zQ96gUVfaFHKqBPb8pKQRM5mui1kdk/q12dVaDnzkH/ZKtU9j9rWe70eou92u6wyEoEV1RlJEnUeMXfRD1hDEAELj3WeT8p/4MNgh+A7SP59FmUBGnssj+gskPqnjEkzJgwHoMvw2M7lk+tguMpROms6BZjnl/cn9D67tl9QT0nFe1usTb7UN3jD0wU0vLpgrdsNzYuj5T6ZvWArUdPwdR2T27bZPH6OIrfAOCxhWBHGJRAc+Iqx4apHrUo7wnyzwGhBN9MA3ZaV4xgeHxCIremW0GWnoAe6wE4JIU8y56GH3lbJQUihWn8n9UFrZKWO7vE8DaGpx9GQE3cLSjJMYK+w2g51gebN5uUUTvTKPcLfaGzhf02RH+eRLvCqoxNbYvmCPM8kTPAe+8TX3IaxL5Jsy7I4/TuWPQdkJQgHbOlRvayRHdDYhqZKKvkfWeiJVrkbw0a7pZkLPUc+OvuXjndYumvrHXyQVZ+GOCqw08kg0Y2B9ojoSMvgZg5IG7202mIlS6N8vL+dOz+mZVtdvdxmgc1Ih7ciyLQtGKRTvM1wK00tTr8rpIrMEy/8cXW4rq9Z7CW+HTy2/L3ogQPu8c8GhxQziQEM6E= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(396003)(136003)(376002)(346002)(366004)(2906002)(53546011)(5660300002)(4326008)(76116006)(91956017)(54906003)(6512007)(66556008)(66946007)(71200400001)(66476007)(66446008)(186003)(2616005)(966005)(478600001)(64756008)(6506007)(38100700002)(122000001)(316002)(6486002)(86362001)(83380400001)(33656002)(8936002)(36756003)(110136005)(224303003)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?MTVtT0lXanVjK251cnAwc2tvaVF5N3EwRmRTcXc4Z05lQ1dEVUpUVTQ3cGZR?= =?utf-8?B?QUVTY0FlMk4vZnhIOTZsSXMrNkJYMEEvTDRaSzBxOE1GNndjRUtRRW1aRnh5?= =?utf-8?B?WXlyZEVXVWhybFRNUEpzenVrRjduQ2ZnWlhBUVN0dHg4dmF2N2Y5NURRTGpi?= =?utf-8?B?RXEwaFNOZkF5dDhkRXQwUGVXQlMrZkZWeG5Kd24xYzM0L0NFKzkvSWFBTmZu?= =?utf-8?B?bmx0TWcyeElUdHZ6NHZSU0lIZzVzRWR2dktNbUZxZElRc240cURXbEUzTC9C?= =?utf-8?B?eFpxOUlob3Vrc2VrZG4vMFFPZUd2S0d2UFE4Rys3YzRIMms2UXpHRE5oR3FF?= =?utf-8?B?TmlCTmNVM1k5Z21QdkFmQ1FoWTRGVWpwNWJSaEhRdFg3bWI5aXVZWUhDR1dy?= =?utf-8?B?QTROcllHZ3o4a0pTS1hPMlpDTnFsdnIyeUkrZUQ5blZhQUZSS293Z2poTzEw?= =?utf-8?B?ZmYwbzF0cFpoTCtsY3hzY2RPZUhWYWZnVlcwY2E4RmNObTdGb29vdlVUTEEx?= =?utf-8?B?RllXRExEWDdpb2dSTDBCWEpyalByVVMvTVA5c0pqOEpvZXZHS0VlWFNTaFNr?= =?utf-8?B?RE5sRUkrdkdiS1V2WC8weStsejdYQ2ZOR1Zqamh0SXlDUVcrMnp3Y0RtRWxL?= =?utf-8?B?ZmtMUUVlcGZlQU9VeVB4czJwSTdGZHhUNko3NHJROFkxOU5XZmdRYlBrMk92?= =?utf-8?B?REhYMENEZ2w5cU4ybzl1MEVSSGtUQUlGaUhIYXIwdmNFYzZJT2psUWxNbllS?= =?utf-8?B?RndQRWQ4bTFiZ3FucTFZeTl6bEtmTGZMODllaDZxdTRNZ1pYekRjZmhpNmxk?= =?utf-8?B?SGRFdzJGTU41ZEFBYkRzTVd6T3pLSU9qWVZyMVg4WFVuU05WYmlDd1ZqNk1n?= =?utf-8?B?VkNxb1IvR281emJvQ05GNGt0UElYUXpkTjJ2QUN5cGpuN1VOQlRXMUtpQi9N?= =?utf-8?B?VnA3MkJHWXhWcFRocms3SW9QNy8xYjA0QjNpcVRjUEc4ZXVWRFVKeHI5alpF?= =?utf-8?B?eERNN3Zzc2RGYUJlclQ4ZGhuWFd1bHpFWHVBM2tFSnN1azhwLzNCTUhjRmx3?= =?utf-8?B?RFRKWG45cU5mY0VqUE1hTFNVc1BWd09EMWxRSkhlcGIxdG44cEhNcVVkd3h6?= =?utf-8?B?dnZGVkQ0RzlWcUF0WTZiVFFYK1VnQk5kOUZ1Sml3Ujk0UnhHU2NrbFBQVU90?= =?utf-8?B?aElQZi9ZRThMSk03L0tpVlRMYkFSeFFpRjhmRHB1SDM2bTZUOHFQeE1FbnhP?= =?utf-8?B?ZWRRQWpwcTVkWEtiYVRKYkkxamZxcjBuTm56bVVRejZURWtwTU1FNVRDMmF4?= =?utf-8?B?OWVMMW5GWWRiWktLbTdnektGMDBuQ1JzRUl6TWdHU2svMmhwTC83a2Vkb2x6?= =?utf-8?B?MS9kNUdoZ1VRNy9kOXg3a3RtM0ZJdjlPcXAwS2w3bmg1YzNIN201SEJCKzc2?= =?utf-8?B?ODcvTXdkVWw3b1N3M09KOG1lbTc3dVYwQ0VrNjdlZ1dhRXBtMXZGbXhuVTJQ?= =?utf-8?B?cDJtbVppNlFYZ3JuaEdZYU02aWh1VVEwTlFlb1h2V1haamlIYWpGcDdWS1RQ?= =?utf-8?B?V09TMllEZ1kyWkNxRG1vOENvbjh2cDBrWTdVeGg3TVJ4RHlZT0lGSkhFcnhq?= =?utf-8?B?bi9KRWd3dXhvQXRuS2piQjU1MTRuY1NIVVVycmhYRW1NR2VTSzVuWWxtZEY2?= =?utf-8?B?bkNOTTFiZ1FDTmZSaTJKWlZ3b3JBcU5xVjVyVjlEQWVJZlRCMzZ0dngxNXc5?= =?utf-8?B?M01xdnRTYWIyWmY1OUtYQngvNysxaVUrbjZJblprR09lMGhoblNhZ2dTNVlN?= =?utf-8?B?YkxiK0pkY1FtRk9GZXhXdjU1bWFOUWhNSmNPUGJvd00wek40Z1R3T1p0UWlJ?= =?utf-8?Q?5emtTrI3RSuk5?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <11F3F1D493A180409766BD37BCC2E521@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ad5addc3-d71d-41c6-8a17-08d90e4ab5a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2021 15:47:08.5788 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Gr3RLodLi+xV6hvHApJb4qjoPvzhRECv5FwxRZYFtrztoEbpoAsRtUD021AlO3lcrcug7w3rkdtEnboHbJC6wg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4919 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-new-block-11=3A_=28with_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: Mon, 03 May 2021 15:47:23 -0000 SGVsbG8gTWVkLA0KDQpTZWUgaW4tbGluZSBmb3IgRVYNCg0KQXMgeW91IGtub3csIGFsbCBteSBj b21tZW50cyBhcmUgbm9uLWJsb2NraW5nLCBzbywgSSBoYXZlIGFwcHJlY2lhdGVkIHlvdXIgcmVw bHkuDQoNCkJUVywgaGF2ZSB5b3Ugc2VlbiB0aGUgcmVjZW50IElvVCBkaXJlY3RvcmF0ZSByZXZp ZXcgYnkgRW1tYW51ZWwgQmFjY2VsbGkNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L3Jldmlldy1pZXRmLWNvcmUtbmV3LWJsb2NrLTExLWlvdGRpci10ZWxlY2hhdC1iYWNjZWxsaS0y MDIxLTA1LTAzLw0KDQpLaW5kIHJlZ2FyZHMNCg0KLcOpcmljDQoNCu+7vy0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiAibW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgPG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpEYXRlOiBNb25kYXksIDMgTWF5IDIwMjEgYXQgMTQ6 MzYNClRvOiBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5jb20+LCBUaGUgSUVTRyA8aWVzZ0Bp ZXRmLm9yZz4NCkNjOiAiZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZyIgPGRyYWZ0 LWlldGYtY29yZS1uZXctYmxvY2tAaWV0Zi5vcmc+LCAiY29yZS1jaGFpcnNAaWV0Zi5vcmciIDxj b3JlLWNoYWlyc0BpZXRmLm9yZz4sICJjb3JlQGlldGYub3JnIiA8Y29yZUBpZXRmLm9yZz4sICJt YXJjby50aWxvY2FAcmkuc2UiIDxtYXJjby50aWxvY2FAcmkuc2U+LCAiY3NwQGNzcGVya2lucy5v cmciIDxjc3BAY3NwZXJraW5zLm9yZz4NClN1YmplY3Q6IFJFOiDDiXJpYyBWeW5ja2UncyBObyBP YmplY3Rpb24gb24gZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay0xMTogKHdpdGggQ09NTUVOVCkN Cg0KICAgIEhpIEVyaWMsIA0KDQogICAgVGhhbmsgeW91IGZvciB0aGUgY29tbWVudHMuIA0KDQog ICAgUGxlYXNlIHNlZSBpbmxpbmUuDQoNCiAgICBDaGVlcnMsDQogICAgTWVkDQoNCiAgICA+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KICAgID4gRGUgOiDDiXJpYyBWeW5ja2UgdmlhIERh dGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10NCiAgICA+IEVudm95w6kgOiBsdW5k aSAzIG1haSAyMDIxIDE0OjE3DQogICAgPiDDgCA6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0K ICAgID4gQ2MgOiBkcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrQGlldGYub3JnOyBjb3JlLWNoYWly c0BpZXRmLm9yZzsNCiAgICA+IGNvcmVAaWV0Zi5vcmc7IG1hcmNvLnRpbG9jYUByaS5zZTsgbWFy Y28udGlsb2NhQHJpLnNlOw0KICAgID4gY3NwQGNzcGVya2lucy5vcmcNCiAgICA+IE9iamV0IDog w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2st MTE6DQogICAgPiAod2l0aCBDT01NRU5UKQ0KICAgID4gDQogICAgPiDDiXJpYyBWeW5ja2UgaGFz IGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQogICAgPiBkcmFmdC1p ZXRmLWNvcmUtbmV3LWJsb2NrLTExOiBObyBPYmplY3Rpb24NCiAgICA+IA0KICAgID4gV2hlbiBy ZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkg dG8gYWxsDQogICAgPiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBs aW5lcy4gKEZlZWwgZnJlZSB0byBjdXQNCiAgICA+IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFw aCwgaG93ZXZlci4pDQogICAgPiANCiAgICA+IA0KICAgID4gUGxlYXNlIHJlZmVyIHRvIGh0dHBz Oi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtDQogICAgPiBjcml0ZXJpYS5o dG1sDQogICAgPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBESVNDVVNTIGFuZCBDT01NRU5U IHBvc2l0aW9ucy4NCiAgICA+IA0KICAgID4gDQogICAgPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdp dGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQogICAgPiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrLw0K ICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiAtDQogICAg PiBDT01NRU5UOg0KICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiAtDQogICAgPiANCiAgICA+IFRo YW5rIHlvdSBmb3IgdGhlIHdvcmsgcHV0IGludG8gdGhpcyBkb2N1bWVudC4NCiAgICA+IA0KICAg ID4gUGxlYXNlIGZpbmQgYmVsb3cgc29tZSBub24tYmxvY2tpbmcgQ09NTUVOVCBwb2ludHMgKGJ1 dCByZXBsaWVzIHdvdWxkDQogICAgPiBiZSBhcHByZWNpYXRlZCBlc3BlY2lhbGx5IG9uIHRoZSBp bnRlbmRlZCBzdGF0dXMvbGFjayBvZiBwdWJsaWMNCiAgICA+IGltcGxlbWVudGF0aW9ucykuDQog ICAgPiANCiAgICA+IEkgaG9wZSB0aGF0IHRoaXMgaGVscHMgdG8gaW1wcm92ZSB0aGUgZG9jdW1l bnQsDQogICAgPiANCiAgICA+IFJlZ2FyZHMsDQogICAgPiANCiAgICA+IC3DqXJpYw0KICAgID4g DQogICAgPiA9PSBDT01NRU5UUyA9PQ0KICAgID4gDQogICAgPiAhISEgSSB3YXMgYWJvdXQgdG8g YmFsbG90IGEgRElTQ1VTUyBvbiB0aGlzIHBvaW50Li4uIEluIHRoZSBhYnNlbmNlDQogICAgPiBv ZiBhIHNlY3Rpb24gYWJvdXQgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGZvciBzdWNoIGEgbmV3 IHRyYW5zcG9ydCwNCiAgICA+IEkgcmVhbGx5IHdvbmRlciB3aGV0aGVyIHN0YW5kYXJkIHRyYWNr IHNob3VsZCBiZSB1c2VkIHJhdGhlciB0aGVuDQogICAgPiBleHBlcmltZW50YWwuIERpZCB0aGUg YXV0aG9ycy9XRyBydW4gc29tZSBzaW11bGF0aW9ucyA/DQoNCiAgICBbTWVkXSBUaGVyZSBpcyBh biBpbXBsZW1lbnRhdGlvbiBhbmQgYSBQUiB3YXMgcHVzaGVkIHNvIHRoYXQgdGhpcyBmdW5jdGlv bmFsaXR5IGlzIHN1cHBvcnRlZCBpbiB0aGUgbGliY29hcC4gUGxlYXNlIHJlZmVyIHRvIHRoZSBm b2xsb3dpbmcgZnJvbSB0aGUgd3JpdGUtdXA6DQoNCiAgICA9PT09PT0NCiAgICBBIFB1bGwtUmVx dWVzdCBvZiBhbiBhdXRob3IncyBpbXBsZW1lbnRhdGlvbiB0byAibGliY29hcCIgaXMgYXZhaWxh YmxlIGF0IGh0dHBzOi8vZ2l0aHViLmNvbS9vYmdtL2xpYmNvYXAvcHVsbC82MTEgDQoNCiAgICBG ZWVkYmFjayBmcm9tIHRoZSBpbXBsZW1lbnRhdGlvbiBhY3Rpdml0eSBoYXMgY29udHJpYnV0ZWQg dG8gdGhlIGRlc2lnbiBhbmQgcmVmaW5lbWVudCBvZiBzcGVjaWZpYyBhc3BlY3RzLCBub3RhYmx5 Og0KDQogICAgLSBMaW1pdGluZyBuZXcgbWVjaGFuaWNzIGZvciBjb25nZXN0aW9uIGNvbnRyb2wg b25seSB0byBDb0FQIE5vbi1Db25maXJtYWJsZSBtZXNzYWdlcy4NCiAgICAtIE5vdCBtaXhpbmcg Q29BUCBDb25maXJtYWJsZSBhbmQgTm9uLUNvbmZpcm1hYmxlIG1lc3NhZ2VzIGZvciBhIHNhbWUg cmVxdWVzdC9yZXNwb25zZSBib2R5Lg0KICAgIC0gVGhlICdDb250aW51ZScgaW5kaWNhdGlvbiBv ZiBzdWNjZXNzZnVsbHkgcmVjZWl2ZWQgYmxvY2tzLg0KICAgIC0gVGhlIGRpc2NvdmVyeSBvZiBz ZXJ2ZXIgc3VwcG9ydCBmb3IgdGhlIFEtQmxvY2sxIGFuZCBRLUJsb2NrMiBPcHRpb25zLg0KICAg IC0gRnVydGhlciBsZXNzb25zIGxlYXJuZWQgaGlnaGxpZ2h0ZWQgYXMgIkltcGxlbWVudGF0aW9u IG5vdGUiIGluIHRoZSBkb2N1bWVudC4NCiAgICA9PT09DQoNCkVWPiBpbmRlZWQsIHRoYW5rIHlv dS4gTm93LCB3aGV0aGVyIHRoaXMgY29kZSBoYXMgYmVlbiB0ZXN0ZWQgaW4gc2V2ZXJhbCBzZXR1 cHMgLyB0ZXN0IGNhc2VzIChiYW5kd2lkdGgsIHBhY2tldCBsb3NzLCByZWJvb3RzKSB3b3VsZCBi ZSBpbnRlcmVzdGluZy4NCg0KICAgID4gDQogICAgPiBIYXBweSB0byBoYXZlIHJlYWQgQ29saW4g UGVya2lucycgcmV2aWV3IGZvciB0aGUgVHJhbnNwb3J0IEFSVCwgd2hpY2gNCiAgICA+IGhhcyBw cm92aWRlZCBtZSB3aXRoIHNvbWUgY29uZmlkZW5jZSBpbiB0aGlzIGJyYW5kIG5ldyB0cmFuc3Bv cnQNCiAgICA+IHByb3RvY29sLiBJIGFtIGFsc28gdHJ1c3RpbmcgdGhlIFRTViBBcmVhIERpcmVj dG9ycyBvbiB0aGlzIHBvaW50Lg0KICAgID4gDQogICAgPiAtLSBTZWN0aW9uIDEgLS0NCiAgICA+ IEkgaGFkIGluIG1pbmQgdGhhdCBjb25zdHJhaW5lZCBuZXR3b3JrIGFyZSB3ZWxsIHByb3RlY3Rl ZCBlaXRoZXIgYXQNCiAgICA+IGxheWVyLTIgb3IgYnkgaGF2aW5nIGFuIGFpci1nYXAgb3IgZmly ZXdhbGwgYXQgdGhlaXIgZWRnZXMsIHNvLCBhIERvUw0KICAgID4gc2VlbXMgcXVpdGUgaW1wcm9i YWJsZSBpbiB0aG9zZSBkZXBsb3ltZW50cy4NCg0KICAgIFtNZWRdIE9uZSBzaWRlIG5vdGU6IHRo ZXJlIHdlcmUgcmVwb3J0cyBvZiAid2VhayIgaW1wbGVtZW50YXRpb25zIGFuZCBkZXBsb3ltZW50 cy4gWW91IG1heSByZWZlciBmb3IgZXhhbXBsZSB0byBodHRwczovL2Z1dHVyZWlvdC50ZWNoL3Rv cC1pb3QtcHJvdG9jb2xzLW1xdHQtY29hcC1oYXZlLW1ham9yLWZsYXdzLXdhcm5zLXRyZW5kLW1p Y3JvLyBvciBodHRwczovL3d3dy56ZG5ldC5jb20vYXJ0aWNsZS90aGUtY29hcC1wcm90b2NvbC1p cy10aGUtbmV4dC1iaWctdGhpbmctZm9yLWRkb3MtYXR0YWNrcy8uIE9mIGNvdXJzZSwgdGhlcmUg YXJlIGd1YXJkcyBvdXQgdGhlcmUgYnV0IGRlcGxveW1lbnRzIG1heSBub3Qgc3VwcG9ydCB0aGVt LiANCg0KRVY+IGZvciBzdXJlIF9fDQoNCiAgICAgU2hvdWxkIHRoaXMgJ3VzZSBjYXNlJw0KICAg ID4gcmVhbGx5IGJlIHBhcnQgb2YgdGhlIGludHJvZHVjdGlvbj8gT3IgaXMgaXQgc2ltcGx5IGxp bmtlZCB0byB0aGUNCiAgICA+IERPVFMgdXNlIGNhc2UgPyBJbiBlaXRoZXIgY2FzZSwgdGhlIERv UyBzaG91bGQgYmUgbW9yZSBkZXRhaWxlZC4NCg0KICAgIFtNZWRdIFRoaXMgaXMgbWFpbmx5IGRy aXZlbiBieSB0aGUgRE9UUyB1c2UgY2FzZS4gTm90IHN1cmUgd2hpY2ggbW9yZSBkZXRhaWxzIHlv dSB3b3VsZCBsaWtlIHNlZSBhZGRlZC4gICANCg0KRVY+IHNpbXBseSBhZGRpbmcgYSByZWZlcmVu Y2UgdG8gdGhlIERPVFMgUkZDL3VzZXIgY2FzZSB0byBhdm9pZCBjb25mdXNpbmcgcmVhZGVycyAo bGlrZSBteXNlbGYpDQoNCiAgICA+IA0KICAgID4gLS0gU2VjdGlvbiAzIC0tDQogICAgPiBBbnkg cmVhc29uIHdoeSAnQ09OJyBpcyBub3QgZXhwYW5kZWQvZXhwbGFpbmVkIG9uIGZpcnN0IHVzZSA/ DQoNCiAgICBbTWVkXSBBY3R1YWxseSwgaXQgaXMuIFBsZWFzZSByZWZlciB0byBTZWN0aW9uIDE6 DQoNCiAgICAgICBBcyBhIHJlbWluZGVyLCBbUkZDNzk1OV0NCiAgICAgICByZWNvbW1lbmRzIHRo ZSB1c2Ugb2YgQ29uZmlybWFibGUgKENPTikgcmVzcG9uc2VzIHRvIGhhbmRsZSBwb3RlbnRpYWwN CiAgICAgICBwYWNrZXQgbG9zcy4gDQoNCkVWPiBpbmRlZWQsIHRoaXMgd2FzIG5vdCBteSBkYXku Li4NCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCiAgICBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCiAgICBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KICAgIGEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQogICAgT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQogICAgVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCiAgICB0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4N CiAgICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4NCiAgICBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu DQogICAgVGhhbmsgeW91Lg0KDQoNCg== From nobody Mon May 3 11:56:50 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 D40963A0475; Mon, 3 May 2021 11:56:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Elwyn Davies via Datatracker To: Cc: core@ietf.org, draft-ietf-core-senml-versions.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162006820882.8146.574742678195359661@ietfa.amsl.com> Reply-To: Elwyn Davies Date: Mon, 03 May 2021 11:56:48 -0700 Archived-At: Subject: [core] Genart last call review of draft-ietf-core-senml-versions-02 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, 03 May 2021 18:56:49 -0000 Reviewer: Elwyn Davies Review result: Almost 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 treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-core-senml-versions-02 Reviewer: Elwyn Davies Review Date: 2021-05-03 IETF LC End Date: 2021-05-03 IESG Telechat date: Not scheduled for a telechat Summary: Almost ready. There is one issue that needs to be sorted out. This document removes the ordering relationship between the values of version.. Section 4.4 of RFC 8428 relies on that ordering relationahip. Accordingly there needs to be explicit new text for Section 4.4 in this document. Also the concept of 'must understand' items is used in this document but is not explicitly defined in RFC 8428. This needs to be fixed - which could happen in the new version of Setion 4.4. Major issues: None Minor issues: The redefinition of version means that this document should contain an explicit update of (at least)  paragraph 3 of Section 4.4 of RFC 8428,  That section assumes that there is an ordering relationship between version field values which is invalidated by this document. Also the concept of 'must understand' fields is supposed to be explained in that section as well as discussed in s2.1 of this document.  That term is not explicitly used in RFC 8428 but I take it that it is supposed to refer to field names ending wth an underscore character ('_').  This should be fixed with a rewrite of s4.4 of RFC 8428. Nits/editorial comments: General:  The RFC Editor preferes the US convention for quoting items using exclusively singe quote rather than double quote marks. s1, para 2:  I found this paragraph difficult to parse, especially the second sentence.  Here is an alternative suggestion. OLD: The traditional idea of using a version number for evolving an interchange format presupposes a linear progression of that format. A more likely form of evolution of SenML is the addition of independently selectable _features_ that can be added to the base version (version 10) in a fashion that these are mostly independent of each other. A recipient of a SenML pack can check the features it implements against those required by the pack, processing the pack only if all required features are provided in the implementation. NEW: The traditional idea of using a version number to indicate the evolution of an interchage format generally assmes an incremental progression of the version number as the format develops over time. However in the case of SenML it is expected that the likely evolution mechanism will be for independently selectable capabiity _features_ to be added to the basic system indicated by 'version' 10. To support this model, this document repurposes the single version number accompanying a pack of SenML records so that it is interpreted as a bitmap indicating the set of features a recipient would need to have implemented to be able to process the pack. ENDS s2:  Personally I would have used the left shift operator rather then 2^fc but that is a personal view. s2,1, para 2: s/lower-most bit positions Section 3./least significant bit positions for the base version as described in Section 3./ s2.1, para 2:  s/Section 4/by the feature defined in Section 4/ s2.1, para 2: 'boutique' is slang:  s/boutique/less generally applicable/ s3: s/already/effectively already/ s6:  I am not we really care but are feature names case sensitve? From nobody Mon May 3 11:57: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 8EFE53A0835; Mon, 3 May 2021 11:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=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 T0YEwsGWBkae; Mon, 3 May 2021 11:57:19 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 BFE083A0645; Mon, 3 May 2021 11:57:16 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id l21so4995453iob.1; Mon, 03 May 2021 11:57:16 -0700 (PDT) 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=d8pLEkdNEiB3BJY5n8AK1S38inj4Zl682Wex7Byd6o4=; b=nbysyClbYmTD7m82isy3EZwoTT7tn8GszIUF0bh30jTPPc2tQqnv/z3bc9/3HSapn0 p1j1o3Ya18E0m0scasbsHlAyl8D9USj4cQnPozWxUGOT1h5u0Pa7aA+nSqHRcT/7px1W 2FbM2nAIQFys7fDlCpv7xNJarLOBW0StKi22TkQrmeObppDCBAAZciwh5tLWEaiDMoKa xCY1GDDFmyijwG/AJHOHOW8HN/Anf5aTgD2Ol8KVWmOe0eBU69gZjjkAcBHy7ANlvXDX UiSxhOY/9D69HYAZARik7GH2tM1vgmVeyehg8V3lv2qVDeS8ZIb115QEYckjGaIxfwIb ax1w== 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=d8pLEkdNEiB3BJY5n8AK1S38inj4Zl682Wex7Byd6o4=; b=CCgoMWk5xFLXV1ixOhnr8Ltx8ncw7eipuvOjOnBUPi5HXckQA8iAMyjAJ/fxWMx1ot x7q6K0o10Dw8ZapiUf+vDyBkbR2pRg88zrnDkmspLYpg7Vr/EHKPC5bkFobzRIZX+pCn juxQf2uHuDQ/v9gulNJ+2B/MbPJVEglG68N+7LJwGJa0arwgR8LvQW3TAOJAUfgcb4dM scAR6H1ZRjqqCxb4l4ssy1V+A0eVm58DKictce6TV6xu1rtrwYFaVtXUMfsx5ggSVzDq FJ1ejLMDkIWA5AKEOxmcsDk1HYagpAnqW2ntXGAOwJyc00U3pFj6wVnbJmMv06j9VQvM pJBQ== X-Gm-Message-State: AOAM530kHP541qKRIe3MqOjUBmeFehVl9CCR0d8/cXRpzXvZ+pnjlhOl BjpKQXpJa5oXc9tJ5ioL/mh4cffmZ/SjGI6X4lQ= X-Google-Smtp-Source: ABdhPJwyKk1gaFYP/ur2UleshRLV13Yi/L5u5CfGxWNCPKSRfz9jdMsIv10YkzyjhmDzwv4kwCYIOvxBt44XwosVego= X-Received: by 2002:a02:b698:: with SMTP id i24mr11304197jam.121.1620068235083; Mon, 03 May 2021 11:57:15 -0700 (PDT) MIME-Version: 1.0 References: <161973861706.19975.3092798532288165336@ietfa.amsl.com> <9640_1619783334_608BEEA5_9640_342_16_787AE7BB302AE849A7480A190F8B9330353751A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <9640_1619783334_608BEEA5_9640_342_16_787AE7BB302AE849A7480A190F8B9330353751A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Martin Duke Date: Mon, 3 May 2021 11:57:12 -0700 Message-ID: To: mohamed.boucadair@orange.com Cc: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Content-Type: multipart/alternative; boundary="000000000000aa036e05c171870f" Archived-At: Subject: Re: [core] Martin Duke's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 18:57:31 -0000 --000000000000aa036e05c171870f Content-Type: text/plain; charset="UTF-8" On Fri, Apr 30, 2021 at 4:48 AM wrote: > > > > I can't reconcile (4.1) with the last sentence in (7.2). > > [Med] Why? 4.1 can be done with default CoAP setting. The purpose of this > CON request is to determine support of the functionality. We made this > change: > > OLD: > Congestion control for CON requests and responses is specified in > Section 4.7 of [RFC7252]. In order to benefit from 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 not specified in this > document given that the applicability scope of the current > specification assumes that all requests and responses using Q-Block1 > and Q-Block2 will be Non-confirmable (Section 3.2). > > NEW: > Congestion control for CON requests and responses is specified in > Section 4.7 of [RFC7252]. In order to benefit from 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 not specified in this > document given that the applicability scope of the current > specification assumes that all requests and responses using Q-Block1 > and Q-Block2 will be Non-confirmable (Section 3.2) apart from the > ^^^^^^^^^^^^^^ > initial Q-Block functionality negotiation. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Does the functionality negotiation in (4.1) involve something other than sending Q-Block options? If so, then (4.1) ought to clarify that it's what you mean. If it's just a GET or whatever, then the text here is fine, but there needs to be more on congestion control for confirmable messages. > > Moreover, if > > my reading of (4.1) is correct, it's not sufficient to declare > > congestion control guidance out of scope when it's a mandated part of > > the protocol. > > > > > > > - (7.2) If NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT both "have the > > same value as computed for EXCHANGE_LIFETIME", why are they different > > variables? > > [Med] Because they refer to distinct aspects that may be tweaked > separately: the timeout induced by PROBING_RATE and the one to observe for > expired partial bodies. > > Or is that they SHOULD have the same value but might not? > > A normative word would be helpful here. > > [Med] Not sure a change is needed here given the definition of the two > parameters. > But they can't be tweaked separately! The spec states that they are both computed as EXCHANGE_LIFETIME. It does not allow for them to be set separately. --000000000000aa036e05c171870f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 30, 2021 at 4:48 AM <<= a href=3D"mailto:mohamed.boucadair@orange.com">mohamed.boucadair@orange.com= > wrote:
>
> I can't reconcile (4.1) with the last sentence in (7.2).

[Med] Why? 4.1 can be done with default CoAP setting. The purpose of this C= ON request is to determine support of the functionality. We made this chang= e:

OLD:
=C2=A0 =C2=A0Congestion control for CON requests and responses is specified= in
=C2=A0 =C2=A0Section 4.7 of [RFC7252].=C2=A0 In order to benefit from faste= r
=C2=A0 =C2=A0transmission rates, NSTART will need to be increased from 1. =C2=A0 =C2=A0However, the other CON congestion control parameters will need= to be
=C2=A0 =C2=A0tuned to cover this change.=C2=A0 This tuning is not specified= in this
=C2=A0 =C2=A0document given that the applicability scope of the current
=C2=A0 =C2=A0specification assumes that all requests and responses using Q-= Block1
=C2=A0 =C2=A0and Q-Block2 will be Non-confirmable (Section 3.2).

NEW:=C2=A0
=C2=A0 =C2=A0Congestion control for CON requests and responses is specified= in
=C2=A0 =C2=A0Section 4.7 of [RFC7252].=C2=A0 In order to benefit from faste= r
=C2=A0 =C2=A0transmission rates, NSTART will need to be increased from 1. =C2=A0 =C2=A0However, the other CON congestion control parameters will need= to be
=C2=A0 =C2=A0tuned to cover this change.=C2=A0 This tuning is not specified= in this
=C2=A0 =C2=A0document given that the applicability scope of the current
=C2=A0 =C2=A0specification assumes that all requests and responses using Q-= Block1
=C2=A0 =C2=A0and Q-Block2 will be Non-confirmable (Section 3.2) apart from = the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^^^^=C2=A0
=C2=A0 =C2=A0initial Q-Block functionality negotiation.
=C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
=
Does the functionality negotiation in (4.1) involve somethin= g other than sending Q-Block options? If so, then (4.1) ought to clarify th= at it's what you mean. If it's just a GET or whatever, then the tex= t here is fine, but there needs to be more on congestion control for confir= mable messages.
=C2=A0

=C2=A0Moreover, if
> my reading of (4.1) is correct, it's not sufficient to declare
> congestion control guidance out of scope when it's a mandated part= of
> the protocol.
>

>
> - (7.2) If NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT both "have th= e
> same value as computed for EXCHANGE_LIFETIME", why are they diffe= rent
> variables?

[Med] Because they refer to distinct aspects that may be tweaked separately= : the timeout induced by PROBING_RATE and the one to observe for expired pa= rtial bodies.

=C2=A0Or is that they SHOULD have the same value but might not?
> A normative word would be helpful here.

[Med] Not sure a change is needed here given the definition of the two para= meters.

But they can't be tweaked separately! = The spec states that they are both computed as EXCHANGE_LIFETIME. It does n= ot allow for them to be set separately.
=C2=A0
--000000000000aa036e05c171870f-- From nobody Mon May 3 23:46:54 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 E7D2E3A2810; Mon, 3 May 2021 23:46:52 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-0.001, 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 O8hQi99rBwmK; Mon, 3 May 2021 23:46:48 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 C3E173A280F; Mon, 3 May 2021 23:46:47 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 4FZ9P03J6kz4wkg; Tue, 4 May 2021 08:46:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620110804; bh=T2MnuO8a7adqP8hzhba/7QI5RiRW+1kbgT03jjAyMAE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=PzUzDjCbTf9wJmGpy+FNwbLQIq74zm6PUQCJ2QrzumEcjkf1JXYoRq5CNZWaXdvEx 3qUuskAWhRqsihVLlhXMRFDGC3ub+ZzzauWLbk034wV6putZK56LPUDDDyBgChb25k A+h/+ze252Il1mM/mbTZ0Ql6758MxTJKudopEzGBrEaeYtOmnOzvfqtCVaivm9Qg1J VqcfYuhCs8O9Yr/jln+V/xOlWx1JSUn1tZKzpkKNqHaBEHjvN6Dvz5CCi3fKdjYX73 CHmV3kEImgR1noCK+oAAQXt2ivXAO/FtlDigCOUeX0+dwP+0fTW8mfy2GWxouwVPz8 Fab6hyTI6nYyQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4FZ9P01xg1z8sYX; Tue, 4 May 2021 08:46:44 +0200 (CEST) From: To: Emmanuel Baccelli , "iot-directorate@ietf.org" CC: "core@ietf.org" , "draft-ietf-core-new-block.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Iotdir telechat review of draft-ietf-core-new-block-11 Thread-Index: AQHXQC6pZ+6l5oMxxEK4DOYhqxchnKrSzSzw Date: Tue, 4 May 2021 06:46:43 +0000 Message-ID: <3417_1620110804_6090EDD4_3417_461_1_787AE7BB302AE849A7480A190F8B93303537633E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162005471461.25481.16323677090483356173@ietfa.amsl.com> In-Reply-To: <162005471461.25481.16323677090483356173@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] Iotdir telechat review of draft-ietf-core-new-block-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 06:46:53 -0000 SGkgRW1tYW51ZWwsIA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIA0KDQpZb3UgbWF5IHRy YWNrIHRoZSBjaGFuZ2VzIGF0OiBodHRwczovL3Rpbnl1cmwuY29tL25ldy1ibG9jay1sYXRlc3Qu DQoNClBsZWFzZSBzZWUgaW5saW5lLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEVtbWFudWVsIEJhY2NlbGxpIHZpYSBEYXRhdHJhY2tl ciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+IEVudm95w6nCoDogbHVuZGkgMyBtYWkgMjAy MSAxNzoxMg0KPiDDgMKgOiBpb3QtZGlyZWN0b3JhdGVAaWV0Zi5vcmcNCj4gQ2PCoDogY29yZUBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay5hbGxAaWV0Zi5vcmc7IGxhc3QtDQo+ IGNhbGxAaWV0Zi5vcmcNCj4gT2JqZXTCoDogSW90ZGlyIHRlbGVjaGF0IHJldmlldyBvZiBkcmFm dC1pZXRmLWNvcmUtbmV3LWJsb2NrLTExDQo+IA0KPiBSZXZpZXdlcjogRW1tYW51ZWwgQmFjY2Vs bGkNCj4gUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBOaXRzDQo+IA0KPiBpb3RkaXIgdGVsZWNo YXQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMTEgRW1tYW51ZWwNCj4gQmFj Y2VsbGksIDMgTWF5IDIwMjENCj4gDQo+ID09PT0NCj4gU3VtbWFyeQ0KPiA9PT09DQo+IA0KPiBN YW55IHRoYW5rcyBmb3IgdGhpcyBkb2N1bWVudC4gSW4gZ2VuZXJhbCwgdGhlIHNwZWMgaXMgd2Vs bCB3cml0dGVuDQo+IGFzIGZhciBhcyBJIGNvdWxkIHNlZS4gSSBoYXZlIGEgZmV3IG5pdHMgYW5k IHN1Z2dlc3Rpb25zIChzZWUgYmVsb3cpLg0KPiANCj4gTXkgbWFpbiBxdWVzdGlvbiBpcyBhYm91 dCB0aGUgdXNlIG9mIENvbmZpcm1hYmxlIG1lc3NhZ2VzLiBNYXliZSBJDQo+IG1pc3NlZCBzb21l dGhpbmcsIGJ1dCBpdCBzZWVtcyB0byBtZSB0aGUgdXNlIG9mIENPTiBtZXNzYWdlcyBpcyBub3QN Cj4gcmVjb21tZW5kZWQgaW4gdGhlIHNwZWMsIGJ1dCBpcyBuZXZlcnRoZWxlc3MgZXZva2VkIGlu IHRoZSBzcGVjLiBJcw0KPiB0aGVyZSByb29tIGZvciBzaW1wbGlmaWNhdGlvbiwgb3IgaXMgaXQg Y29uc2lkZXJlZCB0b28gInJhZGljYWwiIHRvDQo+IG9ubHkgc3BlY2lmeSB0aGUgdXNlIG9mIFEt QmxvY2sgd2l0aCBub24tY29uZmlybWFibGUgbWVzc2FnZXM/DQoNCltNZWRdIFdlIG5lZWQgdG8g Y292ZXIgYm90aCBDT04vTk9OIGZvciB0aGUgZ2VuZXJhbCBpbnRlcm9wZXJhYmlsaXR5IGFuZCBh bHNvIGJlY2F1c2Ugd2UgdXNlIGF0IGxlYXN0IG9uZSBDT04gdG8gZGV0ZWN0IHRoZSBmdW5jdGlv bmFsaXR5IHN1cHBvcnQuIEhvd2V2ZXIsIHRoZSBwZXJmb3JtYW5jZSBiZW5lZml0IGlzIG9ubHkg c3VwcG9ydGVkIGZvciBOT04gYXMgdGhpcyBpcyB0aGUgbWFpbiBhcHBsaWNhYmlsaXR5IHNjb3Bl LiBBcyBub3RlZCBpbiB0aGUgc3BlYywgdGhlIHBlcmZvcm1hbmNlIGJlbmVmaXQgbWF5IGFsc28g YmUgYWNoaWV2ZWQgZm9yIENPTiBidXQgdGhpcyByZXF1aXJlcyBOU1RBUlQgYW5kIG90aGVyIHBh cmFtZXRlcnMuIEFkanVzdGluZyB0aGVzZSBwYXJhbWV0ZXJzIGlzIG91dCBvZiBzY29wZS4NCg0K PiANCj4gRGV0YWlscyBiZWxvdy4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gDQo+IEVtbWFudWVs DQo+IA0KPiA9PT09DQo+IENvbW1lbnRzDQo+ID09PT0NCj4gDQo+ICMgU2VjdGlvbiAxDQo+IA0K PiAjIyBTZWNvbmQgdG8gbGFzdCBzZW50ZW5jZToNCj4gInN1Y2ggYSByZWNvbW1lbmRhdGlvbiBk b2VzIG5vdCB3b3JrIHdpdGggYSBmbG9vZGVkIHBpcGUgRERvUw0KPiBzaXR1YXRpb24uIg0KPiA9 PiBhbiBleHBsaWNpdCByZWYgd291bGQgZmVlbCBuYXR1cmFsIGF0IHRoaXMgcG9pbnQgb2YgdGhl IHRleHQNCj4gKFJGQzg3ODIgYWdhaW4/DQo+IE9yIGFub3RoZXIgcmVmPykuDQoNCltNZWRdIFdl IGNhbiBjaXRlIGl0IGFnYWluIGlmIHRoaXMgaGVscHMuDQoNCj4gDQo+ICMjIExhc3Qgc2VudGVu Y2U6DQo+IEVuZHMgYSBsaXR0bGUgZHJ5LiBIb3cgYWJvdXQgY29tcGxldGluZyBpdCB3aXRoIHNv bWV0aGluZyBzaW1pbGFyIHRvOg0KPiBPTEQ6ICJUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgdGhl IENvQVAgUS1CbG9jazEgYW5kIFEtQmxvY2syIE9wdGlvbnMNCj4gKFNlY3Rpb24gMykiIE5FVzog IlRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUgQ29BUCBRLUJsb2NrMSBhbmQgUS0NCj4gQmxv Y2syIE9wdGlvbnMgd2hpY2ggYWxsb3cgYmxvY2std2lzZSB0cmFuc2ZlciB0byB3b3JrIHdpdGgg c2VyaWVzIG9mDQo+IE5vbi1jb25maXJtYWJsZSBtZXNzYWdlcywgaW5zdGVhZCBvZiBsb2NrLXN0 ZXBwaW5nIHVzaW5nIENPTg0KPiBtZXNzYWdlcyIuDQo+IA0KDQpbTWVkXSBXb3JrcyBmb3IgdXMu IFRoYW5rcy4gDQoNCj4gIyBTZWN0aW9uIDMNCj4gSXQgd291bGQgcmVhZCBtb3JlIG5hdHVyYWxs eSB0byBteSBleWVzIGlmIHlvdSdkIHN3YXAgYXJvdW5kIHRoZQ0KPiBzZWN0aW9uJ3MgY29udGVu dCBpbiB0aGUgYmVnaW5uaW5nIChwYXJ0IGJlZm9yZSAzLjEgYmVnaW5zKSBsaWtlDQo+IHRoaXM6 DQo+ICAtIG1vdmUgdXAgdGhlIG92ZXJ2aWV3IG9mIHRoZSBRLUJsb2NrIG9wdGlvbnMsIGkuZSBl c3NlbnRpYWxseSB0aGUNCj4gcGFydA0KPiAgIlEtQmxvY2sxIGFuZCBRLUJsb2NrMiBPcHRpb25z IGFyZSBkZXNpZ25lZCB0byB3b3JrIGluIHBhcnRpY3VsYXINCj4gd2l0aCBOT04gIHJlcXVlc3Rz IGFuZCByZXNwb25zZXMuLi4iIGFuZCBvbndhcmRzOyAtIGdhdGhlciBhZnRlcndhcmRzDQo+IHRo ZSBidWxsZXQgcG9pbnRzICBzdW1taW5nIHVwIHRoZSBhZHZhbnRhZ2VzIC8gbGltaXRhdGlvbnMg L2RyYXdiYWNrcw0KPiBvZiBRLUJsb2NrIG9wdGlvbnMgY29tcGFyZWQgIHRvIHRoZSBCbG9jayBv cHRpb25zLg0KPiANCg0KW01lZF0gV2UgcmVhcnJhbmdlZCB0aGUgdGV4dCBhcyBzaG93biBpbiB0 aGUgZGlmZi4gICANCg0KPiAjIFNlY3Rpb24gNC4xDQo+IHRoZSBmaXJzdCB0aW1lIHlvdSBtZW50 aW9uIFBPU1QsIFBVVD8gRkVUQ0gsIGlQQVRDSCBldGMuLCBJIHN1Z2dlc3QNCj4geW91IGV4cGxp Y2l0bHkgY2l0ZSBSRkM4MTMyIGFnYWluLg0KDQpbTWVkXSBOb3Qgc3VyZSB3aHkgaXQgaXMgbmVl ZGVkIGFnYWluLiANCg0KPiANCj4gIyBTZWN0aW9uIDQuMywgZm9yIFJlc3BvbnNlIGNvZGUgNC4x Mw0KPiAiSWYgYSBzZXJ2ZXIgcmVjZWl2ZXMgcGF5bG9hZHMgd2l0aCBkaWZmZXJlbnQgUmVxdWVz dC1UYWdzIGZvciB0aGUNCj4gc2FtZSByZXNvdXJjZSwgaXQgc2hvdWxkIGNvbnRpbnVlIHRvIHBy b2Nlc3MgYWxsIHRoZSBib2RpZXMgYXMgaXQgaGFzDQo+IG5vIHdheSBvZiBkZXRlcm1pbmluZyB3 aGljaCBpcyB0aGUgbGF0ZXN0IHZlcnNpb24sIG9yIHdoaWNoIGJvZHksIGlmDQo+IGFueSwgdGhl IGNsaWVudCBpcyB0ZXJtaW5hdGluZyB0aGUgdHJhbnNtaXNzaW9uIGZvci4iID0+IHNpbmNlIHRo aXMNCj4gaXMgYSAqc2hvdWxkKiBhbmQgbm90IGEgTVVTVCwgd291bGQgaXQgbWFrZSBzZW5zZSB0 byBhZGQgcmVhc3N1cmluZw0KPiBhbiBpbXBsZW1lbnRlciBub3RlIG9uIGhvdyB0byBjb21wbHkg d2hpbGUgbWluaW16aW5nIGJ1ZmZlciBtZW1vcnkNCj4gcmVxdWlyZW1lbnRzPyBBcmUgdGhlcmUg dXNlIGNhc2VzIHdoZXJlIHRoZSBzZXJ2ZXIgaXMgKnZlcnkqDQo+IGNvbnN0cmFpbmVkIGluIFJB TSBmb3IgaW5zdGFuY2UgKHNheTogQ2xhc3MgMSBkZXZpY2VzIGluIFJGQyA3MjI4KT8NCg0KW01l ZF0gSXQgaXMgdW5saWtlbHkgZm9yIHRoZSB0YXJnZXQgRE9UUyBjYXNlLCBidXQgdGhpcyBpcyBw b3NzaWJsZSBpZiB0aGUgbWVjaGFuaXNtIGlzIHVzZWQgaW4gb3RoZXIgY29udGV4dHMuIA0KDQpO b3RoaW5nIG11Y2ggY2FuIGJlIGRvbmUgaWYgYSBzZXJ2ZXIgY2Fubm90IHRha2UgYSBsYXJnZSBi bG9jayBvZiBkYXRhLiBUaGUgYXBwbGljYXRpb24gZGVzaWduIHdpbGwgbmVlZCB0byBsb29rIGF0 IHJlc3RyaWN0aW5nIHRoZSBhbW91bnQgb2YgZGF0YSB0aGF0IG5lZWRzIHRvIGJlIHRyYW5zZmVy cmVkLg0KDQo+IA0KPiAjIFNlY3Rpb24gNy4xDQo+IERvIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHkg dGhhdCB0aGlzIGNvbmZpZ3VyYXRpb24gKGFsbCBjb25maXJtYWJsZQ0KPiBtZXNzYWdlcyBmb3Ig YSBnaXZlbiBib2R5KSBpcyAqbm90KiByZWNvbW1lbmRlZD8gVGhlIHN0YXRlbWVudCAiaXQgaXMN Cj4gZXhwZWN0ZWQgdGhhdCBhbGwgcmVxdWVzdHMgYW5kIHJlc3BvbnNlcyB1c2luZyBRLUJsb2Nr MSBhbmQgUS1CbG9jazINCj4gd2lsbCBiZSBOb24tY29uZmlybWFibGUiIGlzIGNvbmZ1c2luZyBh dCBmaXJzdCBzaWdodCwNCg0KW01lZF0gV2UgaGF2ZSBhbHJlYWR5IHVwZGF0ZWQgdGhpcyB0ZXh0 IGZvciBiZXR0ZXIgY2xhcml0eS4gUGxlYXNlIHNlZSB0aGUgZGlmZi4gIA0KDQogaXQgYmVncyB0 aGUNCj4gcXVlc3Rpb246IHdoeSBzcGVjaWZ5IHRoZSBjb25maWd1cmF0aW9uIHVzaW5nIENPTiwg dGhlbj8gQnV0IG1heWJlIEkNCj4gbWlzc2VkIHNvbWV0aGluZy4NCg0KW01lZF0gV2UgbmVlZCB0 byBjb3ZlciBpdCBpbiBjYXNlIGFuIGVuZHBvaW50IGVsZWN0cyB0byB1c2UgQ09OLiAgIA0KDQo+ IA0KPiAjIFNlY3Rpb24gMTENCj4gSWYgdGhlIFJlcXVlc3QtdGFnIGhhcHBlbnMgdG8gYmUgYW4g b3V0ZXIgb3B0aW9uIChvciBpZiB0aGVyZSBpcyBhDQo+IHByb3h5KSBkb2VzIHRoZSBhYm92ZSBj b21tZW50IG9uIHNlY3Rpb24gNC4zIChyZXNwb25zZSBjb2RlIDQuMTMpDQo+IHRyYW5zbGF0ZSBp biBhIHBvdGVudGlhbCByZXNvdXJjZSBleGhhdXN0aW9uIHZ1bG5lcmFiaWxpdHkgZm9yIHRoZQ0K PiBzZXJ2ZXI/DQo+IA0KDQpbTWVkXSBUaGUgdGV4dCBzYXlzIHRoYXQgaXQgaXMgbm90IHJlY29t bWVuZGVkIE5vU2VjIGFzIE9TQ09SRSBkb2VzIG5vdCBwcm92aWRlIHRoZSBvdXRlciB3cmFwcGVy IHRhbXBlcmluZyBzZWN1cml0eS4NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4 cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNl IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFs dGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBt b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Mon May 3 23:54: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 3C1D63A2846; Mon, 3 May 2021 23:54:41 -0700 (PDT) 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 6AK3Dm8SGleX; Mon, 3 May 2021 23:54:36 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 999FF3A2845; Mon, 3 May 2021 23:54:35 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 4FZ9Z16lW3z10wR; Tue, 4 May 2021 08:54:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620111273; bh=MLHqmrpmKPGL7qqST5BNjSe8uksoaxG4C/7AshwfyJo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=OC7QRr68A/jaeNhyFGflPL9O8/VgBKXqGTiTFanfXzIJdHxceBE/b2CEjPk11oFto 1hrBruLxqb8ITZzUTTDJzj7kT3BAYNlXDtFC0NbkIRlJVd12recsisCmkNWPFO5NJn /3eta2ef3asxevmyxyEv8CeRE2QxUDCfP8OoWgqWYoODEROe9EQo5QZXnFulWUuhAq RZykeutovGjDzDXSQBg3SHQTbkqbaxQbb6uIzmxhJ8F2u0t6Sq6QJwd5+rBZSgfIA4 mix+C/KWyARUI1msoTjhLO7BCN+22+i3GaItPLN+Gb+D90wMBInq8NjZqaQ1AFUDdK ZcNk9UNpOZp0g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4FZ9Z15vxCz8sZ5; Tue, 4 May 2021 08:54:33 +0200 (CEST) From: To: "Eric Vyncke (evyncke)" , The IESG CC: "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" , "csp@csperkins.org" , "Emmanuel.Baccelli@inria.fr" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtY29y?= =?utf-8?Q?e-new-block-11:_(with_COMMENT)?= Thread-Index: AQHXQBY05oJi2PX0SEmSBa0SEhG1K6rRrPZggAAYewCAARzwsA== Date: Tue, 4 May 2021 06:54:32 +0000 Message-ID: <4090_1620111273_6090EFA9_4090_294_1_787AE7BB302AE849A7480A190F8B933035376354@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162004421064.19511.6477108778521848512@ietfa.amsl.com> <32469_1620045364_608FEE34_32469_195_1_787AE7BB302AE849A7480A190F8B933035375C5B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <165556CA-81F5-46F6-A40C-B4F3B69E03CC@cisco.com> In-Reply-To: <165556CA-81F5-46F6-A40C-B4F3B69E03CC@cisco.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-new-block-11=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 06:54:41 -0000 SGkgRXJpYywgDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogRXJpYyBWeW5ja2UgKGV2eW5ja2UpIFtt YWlsdG86ZXZ5bmNrZUBjaXNjby5jb21dDQo+IEVudm95w6nCoDogbHVuZGkgMyBtYWkgMjAyMSAx Nzo0Nw0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIDxtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPjsgVGhlDQo+IElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjwqA6IGRyYWZ0 LWlldGYtY29yZS1uZXctYmxvY2tAaWV0Zi5vcmc7IGNvcmUtY2hhaXJzQGlldGYub3JnOw0KPiBj b3JlQGlldGYub3JnOyBtYXJjby50aWxvY2FAcmkuc2U7IGNzcEBjc3BlcmtpbnMub3JnOw0KPiBF bW1hbnVlbC5CYWNjZWxsaUBpbnJpYS5mcg0KPiBPYmpldMKgOiBSZTogw4lyaWMgVnluY2tlJ3Mg Tm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stDQo+IDExOiAod2l0aCBD T01NRU5UKQ0KPiANCj4gSGVsbG8gTWVkLA0KPiANCj4gU2VlIGluLWxpbmUgZm9yIEVWDQo+IA0K PiBBcyB5b3Uga25vdywgYWxsIG15IGNvbW1lbnRzIGFyZSBub24tYmxvY2tpbmcsIHNvLCBJIGhh dmUgYXBwcmVjaWF0ZWQNCj4geW91ciByZXBseS4NCj4gDQo+IEJUVywgaGF2ZSB5b3Ugc2VlbiB0 aGUgcmVjZW50IElvVCBkaXJlY3RvcmF0ZSByZXZpZXcgYnkgRW1tYW51ZWwNCj4gQmFjY2VsbGkg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvcmV2aWV3LWlldGYtY29yZS1uZXctYmxv Y2stDQo+IDExLWlvdGRpci10ZWxlY2hhdC1iYWNjZWxsaS0yMDIxLTA1LTAzLw0KPiANCg0KW01l ZF0gQUNLLiBUaGFua3MuDQoNCj4gS2luZCByZWdhcmRzDQo+IA0KPiAtw6lyaWMNCj4gDQo+IO+7 vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206ICJtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gRGF0ZTogTW9uZGF5 LCAzIE1heSAyMDIxIGF0IDE0OjM2DQo+IFRvOiBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5j b20+LCBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6ICJkcmFmdC1pZXRmLWNvcmUtbmV3 LWJsb2NrQGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1jb3JlLW5ldy0NCj4gYmxvY2tAaWV0Zi5vcmc+ LCAiY29yZS1jaGFpcnNAaWV0Zi5vcmciIDxjb3JlLWNoYWlyc0BpZXRmLm9yZz4sDQo+ICJjb3Jl QGlldGYub3JnIiA8Y29yZUBpZXRmLm9yZz4sICJtYXJjby50aWxvY2FAcmkuc2UiDQo+IDxtYXJj by50aWxvY2FAcmkuc2U+LCAiY3NwQGNzcGVya2lucy5vcmciIDxjc3BAY3NwZXJraW5zLm9yZz4N Cj4gU3ViamVjdDogUkU6IMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm LWNvcmUtbmV3LWJsb2NrLQ0KPiAxMTogKHdpdGggQ09NTUVOVCkNCj4gDQo+ICAgICBIaSBFcmlj LA0KPiANCj4gICAgIFRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnRzLg0KPiANCj4gICAgIFBsZWFz ZSBzZWUgaW5saW5lLg0KPiANCj4gICAgIENoZWVycywNCj4gICAgIE1lZA0KPiANCj4gICAgID4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ICAgICA+IERlIDogw4lyaWMgVnluY2tlIHZp YSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+ICAgICA+IEVudm95w6kg OiBsdW5kaSAzIG1haSAyMDIxIDE0OjE3DQo+ICAgICA+IMOAIDogVGhlIElFU0cgPGllc2dAaWV0 Zi5vcmc+DQo+ICAgICA+IENjIDogZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZzsg Y29yZS1jaGFpcnNAaWV0Zi5vcmc7DQo+ICAgICA+IGNvcmVAaWV0Zi5vcmc7IG1hcmNvLnRpbG9j YUByaS5zZTsgbWFyY28udGlsb2NhQHJpLnNlOw0KPiAgICAgPiBjc3BAY3NwZXJraW5zLm9yZw0K PiAgICAgPiBPYmpldCA6IMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm LWNvcmUtbmV3LQ0KPiBibG9jay0xMToNCj4gICAgID4gKHdpdGggQ09NTUVOVCkNCj4gICAgID4N Cj4gICAgID4gw4lyaWMgVnluY2tlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv c2l0aW9uIGZvcg0KPiAgICAgPiBkcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrLTExOiBObyBPYmpl Y3Rpb24NCj4gICAgID4NClsuLl0NCj4gICAgID4gPT0gQ09NTUVOVFMgPT0NCj4gICAgID4NCj4g ICAgID4gISEhIEkgd2FzIGFib3V0IHRvIGJhbGxvdCBhIERJU0NVU1Mgb24gdGhpcyBwb2ludC4u LiBJbiB0aGUNCj4gYWJzZW5jZQ0KPiAgICAgPiBvZiBhIHNlY3Rpb24gYWJvdXQgZXhpc3Rpbmcg aW1wbGVtZW50YXRpb25zIGZvciBzdWNoIGEgbmV3DQo+IHRyYW5zcG9ydCwNCj4gICAgID4gSSBy ZWFsbHkgd29uZGVyIHdoZXRoZXIgc3RhbmRhcmQgdHJhY2sgc2hvdWxkIGJlIHVzZWQgcmF0aGVy DQo+IHRoZW4NCj4gICAgID4gZXhwZXJpbWVudGFsLiBEaWQgdGhlIGF1dGhvcnMvV0cgcnVuIHNv bWUgc2ltdWxhdGlvbnMgPw0KPiANCj4gICAgIFtNZWRdIFRoZXJlIGlzIGFuIGltcGxlbWVudGF0 aW9uIGFuZCBhIFBSIHdhcyBwdXNoZWQgc28gdGhhdCB0aGlzDQo+IGZ1bmN0aW9uYWxpdHkgaXMg c3VwcG9ydGVkIGluIHRoZSBsaWJjb2FwLiBQbGVhc2UgcmVmZXIgdG8gdGhlDQo+IGZvbGxvd2lu ZyBmcm9tIHRoZSB3cml0ZS11cDoNCj4gDQo+ICAgICA9PT09PT0NCj4gICAgIEEgUHVsbC1SZXF1 ZXN0IG9mIGFuIGF1dGhvcidzIGltcGxlbWVudGF0aW9uIHRvICJsaWJjb2FwIiBpcw0KPiBhdmFp bGFibGUgYXQgaHR0cHM6Ly9naXRodWIuY29tL29iZ20vbGliY29hcC9wdWxsLzYxMQ0KPiANCj4g ICAgIEZlZWRiYWNrIGZyb20gdGhlIGltcGxlbWVudGF0aW9uIGFjdGl2aXR5IGhhcyBjb250cmli dXRlZCB0byB0aGUNCj4gZGVzaWduIGFuZCByZWZpbmVtZW50IG9mIHNwZWNpZmljIGFzcGVjdHMs IG5vdGFibHk6DQo+IA0KPiAgICAgLSBMaW1pdGluZyBuZXcgbWVjaGFuaWNzIGZvciBjb25nZXN0 aW9uIGNvbnRyb2wgb25seSB0byBDb0FQIE5vbi0NCj4gQ29uZmlybWFibGUgbWVzc2FnZXMuDQo+ ICAgICAtIE5vdCBtaXhpbmcgQ29BUCBDb25maXJtYWJsZSBhbmQgTm9uLUNvbmZpcm1hYmxlIG1l c3NhZ2VzIGZvciBhDQo+IHNhbWUgcmVxdWVzdC9yZXNwb25zZSBib2R5Lg0KPiAgICAgLSBUaGUg J0NvbnRpbnVlJyBpbmRpY2F0aW9uIG9mIHN1Y2Nlc3NmdWxseSByZWNlaXZlZCBibG9ja3MuDQo+ ICAgICAtIFRoZSBkaXNjb3Zlcnkgb2Ygc2VydmVyIHN1cHBvcnQgZm9yIHRoZSBRLUJsb2NrMSBh bmQgUS1CbG9jazINCj4gT3B0aW9ucy4NCj4gICAgIC0gRnVydGhlciBsZXNzb25zIGxlYXJuZWQg aGlnaGxpZ2h0ZWQgYXMgIkltcGxlbWVudGF0aW9uIG5vdGUiIGluDQo+IHRoZSBkb2N1bWVudC4N Cj4gICAgID09PT0NCj4gDQo+IEVWPiBpbmRlZWQsIHRoYW5rIHlvdS4gTm93LCB3aGV0aGVyIHRo aXMgY29kZSBoYXMgYmVlbiB0ZXN0ZWQgaW4NCj4gc2V2ZXJhbCBzZXR1cHMgLyB0ZXN0IGNhc2Vz IChiYW5kd2lkdGgsIHBhY2tldCBsb3NzLCByZWJvb3RzKSB3b3VsZA0KPiBiZSBpbnRlcmVzdGlu Zy4NCj4gDQoNCltNZWRdIEl0IHdhcyB0ZXN0ZWQgaW4gdGhlIGNvbnRleHQgb2YgRE9UUyB0ZWxl bWV0cnkuIFRoZSBsaXN0IGFib3ZlIHNob3dzIGhvdyB0aGUgdGVzdGluZyB3YXMgaGVscGZ1bCB0 byByZWZpbmUvYXNzZXNzIHRoZSBkZXNpZ24uDQoNClsuLl0NCj4gDQo+ICAgICAgU2hvdWxkIHRo aXMgJ3VzZSBjYXNlJw0KPiAgICAgPiByZWFsbHkgYmUgcGFydCBvZiB0aGUgaW50cm9kdWN0aW9u PyBPciBpcyBpdCBzaW1wbHkgbGlua2VkIHRvDQo+IHRoZQ0KPiAgICAgPiBET1RTIHVzZSBjYXNl ID8gSW4gZWl0aGVyIGNhc2UsIHRoZSBEb1Mgc2hvdWxkIGJlIG1vcmUNCj4gZGV0YWlsZWQuDQo+ IA0KPiAgICAgW01lZF0gVGhpcyBpcyBtYWlubHkgZHJpdmVuIGJ5IHRoZSBET1RTIHVzZSBjYXNl LiBOb3Qgc3VyZSB3aGljaA0KPiBtb3JlIGRldGFpbHMgeW91IHdvdWxkIGxpa2Ugc2VlIGFkZGVk Lg0KPiANCj4gRVY+IHNpbXBseSBhZGRpbmcgYSByZWZlcmVuY2UgdG8gdGhlIERPVFMgUkZDL3Vz ZXIgY2FzZSB0byBhdm9pZA0KPiBFVj4gY29uZnVzaW5nIHJlYWRlcnMgKGxpa2UgbXlzZWxmKQ0K DQpbTWVkXSBXaWxsIHNlZSB3aGF0IHdlIGNhbiBkbyBhcyB3ZSBkbyBhbHJlYWR5IGNpdGUgaXQg bWFueSB0aW1lcywgYW5kIGV2ZW4gb25lIG1vcmUgYXMgcGVyIHRoZSBpb3RkaXIgcmV2aWV3LiBU aGFuayB5b3UuDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFu Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNo YW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Tue May 4 01:05:26 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 D198B3A2A66 for ; Tue, 4 May 2021 01:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS-cJ8wedTdL for ; Tue, 4 May 2021 01:05:21 -0700 (PDT) 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 8F37A3A2A6A for ; Tue, 4 May 2021 01:05:21 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1ldq3S-0006FK-8i; Tue, 04 May 2021 09:05:18 +0100 From: To: "'Eric Vyncke \(evyncke\)'" , "'The IESG'" , Cc: , , , , , References: <162004421064.19511.6477108778521848512@ietfa.amsl.com> <32469_1620045364_608FEE34_32469_195_1_787AE7BB302AE849A7480A190F8B933035375C5B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <165556CA-81F5-46F6-A40C-B4F3B69E03CC@cisco.com> <4090_1620111273_6090EFA9_4090_294_1_787AE7BB302AE849A7480A190F8B933035376354@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <4090_1620111273_6090EFA9_4090_294_1_787AE7BB302AE849A7480A190F8B933035376354@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Tue, 4 May 2021 09:05:13 +0100 Message-ID: <038501d740bc$3639b5a0$a2ad20e0$@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: AQKGE6Nw3OFgz/ZV5pUWU0xmNvlPXAI8Dl6IAlhE7hUBPvCS36lGsmIQ Content-Language: en-gb Archived-At: Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-new-block-11=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 08:05:24 -0000 Hi Eric, > > > > EV> indeed, thank you. Now, whether this code has been tested in > > several setups / test cases (bandwidth, packet loss, reboots) would > > be interesting. > > >=20 > [Med] It was tested in the context of DOTS telemetry. The list above = shows > how the testing was helpful to refine/assess the design. >=20 Libcoap provides the testing capability of one or more specific packets = dropped, or randomly dropped. Testing was done with one or more packets = missing from the start, around the MAX_PAYLOADS pause point, at the end = as well as in the middle of a MAX_PAYLOAD sequence for both CON and NON. = Lessons learnt about the recoveries etc. updated the draft. Logic tested with complete packet loss in one direction (for NON, CON = fails here) confirming data still gets through. Multiple concurrent sessions were run in parallel - including with = enforced packet loss. Applications running on the peers were restarted frequently (other peer = remaining up) to checkout out recovery etc. The block size (SZX) was deliberately set to a small size, thus = considerably increasing the number of blocks needed to transfer large = payloads to exercise that logic. This brought about the addition of the = 'Continue' logic. Regards Jon From nobody Tue May 4 01:07: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 E6C243A2A81; Tue, 4 May 2021 01:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.918 X-Spam-Level: X-Spam-Status: No, score=-11.918 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=MKRYqmmM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=yVQIoWDL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzlyi2kL_B8z; Tue, 4 May 2021 01:07:50 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7386F3A2A73; Tue, 4 May 2021 01:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2874; q=dns/txt; s=iport; t=1620115670; x=1621325270; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9K3T9wvmUgiQBg212jOtNyxQFb57Q5qR0RC9Rw1BzB0=; b=MKRYqmmMl1HStMT5OFKyTW+IfoI+8jYIaSalKl2ZfOxK4FGy0FyH7TeJ pWjrRdnZPDDddA3x/gQxV7Oq5AgFt7iRKeNkrPWQuv7wKrWO7ghnaPqys LRm1QD9ZF+yz5jCLQAr8otXndhR+SqivPY5YJY22Q3T/8VnbDKqTFTf2B E=; X-IPAS-Result: =?us-ascii?q?A0A6AADG/5BgmIYNJK1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFXgVNRgVg2MYREg0gDhTmIcQOZUoJTA1QLAQEBDQEBMgIEA?= =?us-ascii?q?QGEUAIXgWQCJTgTAgQBAQEDAgMBAQEBAQUBAQECAQYEFAEBAQEBAQEBaIVQD?= =?us-ascii?q?YZEAQEBBCMRDAEBNwELBAIBCBEDAQIDAiYCAgIwFQUDCAIEAQkEBYJxglYDL?= =?us-ascii?q?wGeDwKKH3qBMoEBggQBAQYEBIUtGIITCYEQKgGCeIQOgkSEFSccgUlCgRUnH?= =?us-ascii?q?IJfPoRCBzOCXTaCK4IrNgsMOiKBCCQKE5U+QqZvCoMQnS4FIqUjhRyQFJ8Fh?= =?us-ascii?q?FwCAgICBAUCDgEBBjWBNiGBW3AVOyoBgj5QFwIOjh8Zg1eKXAFzOAIGAQkBA?= =?us-ascii?q?QMJAXuMEwEB?= IronPort-PHdr: A9a23:rGSAeRbVorILYkU4+PB8PdH/LTDVhN3EVjU944c7i79IbqWo9ojjO 0qa//h2kVvVRu3z6epfi+PSt6f/H2cH5MXJvHMDdclKUBkIwYUTkhc7CcGIQUv8MLbxbiM8E cgDMT0t/3yyPUVPXsqrYVrUry6w9SUSExH7MhUzLePwScbeis2t3LW0/JveKwxDmDu6Z+Z0K xO75QXcv8Ubm81sMKE0nxDIuXBPPe9RwDAAGA== IronPort-HdrOrdr: A9a23:dPKBmq7yhZpCcTRFrwPXwdmFI+orLtY04lQ7vn1ZYSd+NuSFis Gjm+ka3xfoiDAXHEotg8yEJbPoexLh3LZPy800Ma25VAfr/FGpIoZr8Jf4z1TbdRHW3tV2kZ 1te60WMrLNJHBxh8ri/U2cG9Ev3NGI/MmT9Jjj5l1GJDsaDJ1IxQF/FwqdDwlXaWB9dNoEPb Cb4ddKoCflXHwRYNiyCHVtZZm8m/TgkpX6bRkaQyM94A6Vgj+yrJL8GR6U3hAROgk/gosK22 7DjgD/++Gfo+i2oyWsllP7wrZ3vJ/aytVFDNGRkcR9EFXRoyuheYgJYcz4gBkbu+eqgWxa9e XkgxBlBMhr7mOUQ2fdm2qQ5yDF8BIDr0Dv0kWZh3yLm726eBsfB9BajYxUNjv1gnBQxu1U66 5A02KHu5c/N3qp906Ri6mqJnNXv3G5rnY4nekYg2Y3a/piVJZqsYcd8ElJea1weh7S1YE9HO FiSOHa6fpGGGnqF0zxg2h1zNSgGkk0BxeNK3Jyw/C97j4+pgEc82IogOgk2lsQ/pM0TJdJo8 7eNL5zqb1IRsgKKYpgGeYoW6KMeynwaCOJFFjXDUXsFakBNX6IgYXw+q8J6Oajf4FN5Icuma 7GTEhTuQcJCgbTIPzL+KcO3gHGQW27Uzio4NpZ/YJFtrr1Q6euFiGfVlY0kY+Fr+8ECsPWH9 a/UagmRMPLHC/LI8Jkzgf+U55dJT01S8sOoOs2XFqIv4bFMYvvuuvHcOvCJbbkHDo+M1mPW0 crbXzWHoFt/0qrUnj3jFz6QHX2YHHy+pp2Dezb8oEoudAwH7wJljJQpUWy58mNJzEHmLcxZl FCLLTulb7+oWG3+G3P/nh4IxY1NDcP3JzQF1dx4SMaOUL9drgO//+Ff3pJ4XeBLhhjC8XMEA BeoFxz8bmtL4OZwD0jD97PCBPds1Ij4FaxC7sMkKyK4snoPrkiCIw9ZaB3HQLXUwBulR1ys2 dFYg8cTkrZHjfj4J/V1qA8NaX6TZ1RkQ2rKclbpTbjrk2av9goXWZedSWpS9SrjQEnQCd0il V9/7QEuqeJnS+iJAIE8bkFGWwJTF7SIbpdSCyZeY1fm9nQCXBNZFbPoQbftjYeVS7B8V4Iim noMCuOEMu7cmZ1izR/yabl8FR9a2OHWVl/A0oK7bFVJCDhpmt51/ONa+6V1WacA2FynN01AX XifSYYJB9oypSM8COt3ByGFXkg2/wVT7PgJbw+brDe3W6sIoWUlacAW+RZ5ophKcqGiJ54bc uCYQOPaDv3B+Q1sjbl1UoNKW16rmIpnujv3wCg5G+k3GQnCf6XO1h+QaoHSuvso1TMVrKN0J 9ji8gysvb1OmLtasSewaW/VU8IFjrD5Wq3Rfovs5ZaoOY7s6ZyBYDSVX/N2Gtc1BszaMfym0 V2etU33JnRfotuddcVYSRX4x4gk8mONlIitkjuGfAlFGtdxkPzLpeM+f7FuLAvCkqOqE/5Pk Se6TRU+7PAUzGY3bAXBqosKQ1tGQcBwWUn+PnHe5zbCQ2see0G5la8P3OneLJWSaSOG9wr31 1HysDNm/XSezvz2QjWszc+P7lH9Hy/R9iuRA2LAuxF/rWBSBqxq7rv5NT2ijj5STG2MRtFwY JEcFEddcRFhH0pipYt3i27V6zwpQYknjJlkEZav0+o3pLj5mHRWVxCO0nehJ5dWDFIKHiGjc jf64GjpTzAySkA3YOGDVtae9FFBsMZQYf2JTp/MMR4hs/dw4M/xiBYJAo0B2EyiDrhz/pr0L ew1vLVQfDjAx7TSCQ80C8AAJV1kCwtoXxBdMb77YvVWHRjKtI1 X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,271,1613433600"; d="scan'208";a="680373566" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 May 2021 08:07:49 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 14487ng6006708 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 4 May 2021 08:07:49 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Tue, 4 May 2021 03:07:49 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 4 May 2021 04:07:48 -0400 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 4 May 2021 04:07:47 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bvUnZh0aIFWtE6y3kPt65bwjkkTO/qKXw0LALpu0NyrTjILOeNn8RX7uIncNqN5S9kv1jHloSLgC18bb9shy++gKvBO4QtAIQmUahqgWc5zgfkQi2VXBb+IAl/ugpSS5QeWHngkvjdt1u3bjHnoSaNaP5nMA9M+1IIgjQW27bPMJjWIA69Wi6ITWeAHPfTs8KggVLxl6b+/7gIkUY+DNTIDk/SKreVRSdtQBJ5yBkqBjT5cgIbujA37KGabdqF4ZK9ahcS/Yt2WosZHTvycjrzXP5eP0M4lh+GysuixyTOyX+Swd7ehc0e0onZvXmfr9yIEI+4zbVZSP2thC6O1Psg== 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=9K3T9wvmUgiQBg212jOtNyxQFb57Q5qR0RC9Rw1BzB0=; b=OoXI6kzMez7vxSpCbB5HnEfEDy5ZefNwI7JQcf+nPqsQgmgRTuWuYNsSbAELPo07zr3Bs5IEMfzuww9jM8DxIVExhqCpbWpIiiIOmNF44cfC73DuWMYdo0BX4LX2hVNL3rNqP6UA4eAy+t+ZCZZNtNjWgRwmba12pZcDoWRQ5+/PrbP0yb2YLqNV3lmVZnGa7XM+UyAG63Ek4geczQ14crkxmOPEY1MJ1/CrkObpXxj9lTYsFju4vZN743tCqkPhWJCo221quzkit+YvYdg7TCRoYakqdJEYBzbRXVm6rH+GqKTToVYnsrOKz0H68o1pJXc13+cEiiBBG1niZ6FKvQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9K3T9wvmUgiQBg212jOtNyxQFb57Q5qR0RC9Rw1BzB0=; b=yVQIoWDLnfNHK2H5ykxdUIw/fJu2EThWZw7RGWiM23xty/gETja2MpQww6pex2dwffvxE3H2CAQrnPl68DywqLSCI08etPzs307MQUJd0RaUcE8ealxPOLcc57qUzgu6SSVB6z6vOfodwnODzK1LpewvImRJbax9YK7um9BwMzQ= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5063.namprd11.prod.outlook.com (2603:10b6:510:3d::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.44; Tue, 4 May 2021 08:07:46 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::ccc:1b78:44b5:b74b]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::ccc:1b78:44b5:b74b%3]) with mapi id 15.20.4087.044; Tue, 4 May 2021 08:07:46 +0000 From: "Eric Vyncke (evyncke)" To: "supjps-ietf@jpshallow.com" , "'The IESG'" , "mohamed.boucadair@orange.com" CC: "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" , "csp@csperkins.org" , "Emmanuel.Baccelli@inria.fr" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtY29y?= =?utf-8?Q?e-new-block-11:_(with_COMMENT)?= Thread-Index: AQHXQBZDbuo9fWQ7OkebTxbj0UeYfgI8Dl6IAlhE7hUBPvCS36lGsmIQgV3N+wA= Date: Tue, 4 May 2021 08:07:46 +0000 Message-ID: References: <162004421064.19511.6477108778521848512@ietfa.amsl.com> <32469_1620045364_608FEE34_32469_195_1_787AE7BB302AE849A7480A190F8B933035375C5B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <165556CA-81F5-46F6-A40C-B4F3B69E03CC@cisco.com> <4090_1620111273_6090EFA9_4090_294_1_787AE7BB302AE849A7480A190F8B933035376354@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <038501d740bc$3639b5a0$a2ad20e0$@jpshallow.com> In-Reply-To: <038501d740bc$3639b5a0$a2ad20e0$@jpshallow.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 authentication-results: jpshallow.com; dkim=none (message not signed) header.d=none;jpshallow.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:b09e:200e:1def:5c31] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 14999948-b7e9-4a11-e6b4-08d90ed3b3cf x-ms-traffictypediagnostic: PH0PR11MB5063: 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: xw9m6Ckmfn2jq+bMUPBnp5bQtotDE99ep2R57WRm5GjZ0RbFMjbY2BnKgb/L/9llKPwc6jdc5fsIsrGqkF7XY/Z8Zr8Id8ES0rhjtSXjmz50FCpSbqAIj/oOeQiabtRbNaTk3KWGGIshyOUFfU+i3Hc5Lgu/1sQeAxHpk7VOi6CQ0mI7uRMnqbJUYNo1NqKRKt6MFTph2kUwR4Mu8ns81bgAuUcfSM6LFb2z128N0wKu2DdTCXiqLp9IKj7zzl8bUbH0f/SQMqSBlAUrZsXstY0/3wtYLVUOgNCNLSjduirLY6OoG8MXRAABO1LkKEyBbOXrDKfqaY3dIS3abhRxWugQNACqCmPNOiQq1eVSRFBvmeTm3epM3szMc6KkB4o7H3MklfDoTYZ2dUoq4SNO94jf1FyEr50QkMANag4Bjr7OiGH65Q3a25QUKaKGBnVdri1lYARLFG8pyLgi14chKvM5B9Q+CHUkY2HAtwhGNK7jKWSmB6xJANNDuOdvJOyqfM3gtrWm0DceKPnvQrVMHXw+nJy5R12OYrZL6bzUR+snqfd0y5KucEpt5bLzm7E4mJ3d4bUouAoqCaDd164pRF9L/zn9oB7fc5Le0NFH37xTVAU8/7oVN3kTl1HpOasR6/ghUEY4bJwwowhIqZTGJ0dg/sJZpYR5NV3HaJ1EYkU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(39860400002)(366004)(136003)(346002)(83380400001)(54906003)(33656002)(6486002)(110136005)(6512007)(224303003)(478600001)(86362001)(38100700002)(36756003)(4326008)(122000001)(66946007)(6506007)(8936002)(53546011)(186003)(71200400001)(5660300002)(66476007)(64756008)(66556008)(66446008)(316002)(2906002)(91956017)(2616005)(76116006)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?c1VnakZNRFg4WEEvaVpPbENJK3pCMmQzV2RXamF5S2tySEdmOUlxRktHTlNY?= =?utf-8?B?ZzBXbU1uY3lFUS9WSVNqdDJSNXFMcVd0SC9WYUdZR2tRa2xOS0dMM01TbllT?= =?utf-8?B?NHhDb0NhNjNNQ3JWOEtpSlZxbGsvZXhCRzdMMmFUdS9Tc01vejAwbmVPUFha?= =?utf-8?B?ZTRHa2g0eDlremZkcEMzY0o2ai9qTE02Sm9Bb0pEWUJoWnNFTXdYMHF2SUN4?= =?utf-8?B?aG94bFRGaHFNZnFBME5SVEZodnUyNDhmV1cxV2g4MVJPdzF2WnpuZGVFTlcx?= =?utf-8?B?cSt4RDkvT0pLNFkvMVdzcGYvejl3MVFJenQybU54b3lpQVJNcGtPcTRzUlhj?= =?utf-8?B?UmFrMzNHakJJSXN0Rm4rYnVuQnliWlc3cmpWbXgxUlZOdDZYR1BWbldhOWEv?= =?utf-8?B?aDJvc1pYa3lDdFE5ZjNmNTRGVFM4UGlhL0RPRXdSbGhZMTJsN2pQVS9seXVT?= =?utf-8?B?bU4xTFVnYXY3Rk5XZG5ic2pQR2NVbk5iOWxtMmpEVE5QZkEwQ3lLTFFBd1Zj?= =?utf-8?B?TjFhZFdHK2g1aE93YWlZUnQ2cDBSVjdKa0IyVnVzRFE0S2Y2a0d3dUhLVVBP?= =?utf-8?B?eXJKamUvOFBmWi82MjM2RXhRSGtYOVhlVk1zOWpmSFVuQ09VNHptK252QWNV?= =?utf-8?B?ay9nbEFsTWd6QzJ4ei9ybDd1OUhvTXM3UXVhUWErYzMrZVNFazZUbGtlWjJp?= =?utf-8?B?Vko4MmpUQkhBWDRxaXN4Ylg3cUpFU0lDeFVHVWFFUVBLRHlMd1ZuOTloZEFG?= =?utf-8?B?Y3ptaEZ6N3FSR25JWGdyUkIxdXNTRmpncjI2Zlh5aTBVN3I3dG9oYVNKV3cx?= =?utf-8?B?NU1kWGtxNC9zOU80Nkg1eWlrRjM4ZVdCYXpQSG9tdVRWd2NwNGdMSU1CRCsy?= =?utf-8?B?V3gvRFJGM2tsd1JPeHY0YW5DWDgxdGhVTEdvSmVXRExzMDgzc2o3QjludEQ5?= =?utf-8?B?WDVtaWExOGZFN3V6VDNKaEhhcjNWNlFOOUZLaUVPbEJaVms0YUZnUlMybUw2?= =?utf-8?B?U1FLU2xtTndLSkJ6OGdLaGszUmtHdDViOVlIRlJrcUFTVWt4UGFNcFUxM3FZ?= =?utf-8?B?UjhmM2EydE43MXNaV1k2SlRoMlRHTWcwWE52M1k4UG9qaEVuZWpPME5ZNjRx?= =?utf-8?B?K3c4K2VoYTVFamV0NUNicFdPRG0zZlRNc3hDWDZZeURiSjZCcngyTTBib3h2?= =?utf-8?B?aEZ3YTZYOUtXUDBPdGdSaDh4bHMwTW5aVDB5TlRuVUZUSW5hYXNRSU1SVEZE?= =?utf-8?B?Mi81ZnhMVi9vcFN4dlk3THBzek85TEZNeVE3bjVjTUtXMG90WHpmTldNKzBJ?= =?utf-8?B?WkZ3NlVmcDlMSExxU1FKa1hneXFHTnRPMWU5ajh0dXJUSnIwTDR6NlFEQW5z?= =?utf-8?B?eTlKclJkR1NiL3gvTkRBc0dpRGhJRTExK2N4WjJnZWM4K1BVbVVwT3dKY0R1?= =?utf-8?B?TFZIR0R5ZW03QlBEZHZ2bmdtd3l1aEc4dDg4Rzg0SExxWGc5WVJ1M1BNTlQ2?= =?utf-8?B?ZUFXdUswckpBVEtEcUdLTzhjQlltN2ZTYmRVSktoN2VHWXU0bGg5TTErby81?= =?utf-8?B?RHUwbm1VMFdPNjk4QW1OeS9TcnZGLzVZNEhqYjZkbjFyK3lGSEEzV3pKblZI?= =?utf-8?B?L203c1o5SHF4aHJMYkFSZHNvREx3Q00zU01yMHduWjlqY0RqM0lGcFRVVzNx?= =?utf-8?B?R0t4NGVSaFluaGxqOGdGRVhwZkFiZTRwQmE3bUIvU29WaWNtcjd1dS9YeUw5?= =?utf-8?B?VWxiQ2l6TVpCL21pOHZFVGRaaWoveWh4cnovdWNzS3dJS1lWR3F3SXZqQUM3?= =?utf-8?B?dzFDRmkvVDUxNFNJTDhGZ2FXRGhZMU1xOTJyd00wcWk0OUlrNkI2cENMZWt4?= =?utf-8?Q?SG6XyqNdxFz69?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14999948-b7e9-4a11-e6b4-08d90ed3b3cf X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2021 08:07:46.5757 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: H/hH3c5wcXS1ALAu29TTHxTfL+Uz5gMMMU9+A5/0cIGwdZLZqrhtYoOqWLI3kz/fG5QBugVnfETsCj31Kx3jtQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5063 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-new-block-11=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 08:07:56 -0000 Sm9uIGFuZCBNZWQsDQoNClRoYW5rIHlvdSwgSSBmZWVsIHdheSBtb3JlIGNvbWZvcnRhYmxlIHdp dGggdGhhdCBhbW91bnQgb2YgdGVzdGluZyA7LSkNCg0KUmVnYXJkcw0KDQotw6lyaWMNCg0K77u/ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206ICJzdXBqcHMtaWV0ZkBqcHNoYWxsb3cu Y29tIiA8c3VwanBzLWlldGZAanBzaGFsbG93LmNvbT4NCkRhdGU6IFR1ZXNkYXksIDQgTWF5IDIw MjEgYXQgMTA6MDUNClRvOiBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5jb20+LCAnVGhlIElF U0cnIDxpZXNnQGlldGYub3JnPiwgIm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIDxtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KQ2M6ICJkcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2Nr QGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZz4sICJjb3JlLWNo YWlyc0BpZXRmLm9yZyIgPGNvcmUtY2hhaXJzQGlldGYub3JnPiwgImNvcmVAaWV0Zi5vcmciIDxj b3JlQGlldGYub3JnPiwgIm1hcmNvLnRpbG9jYUByaS5zZSIgPG1hcmNvLnRpbG9jYUByaS5zZT4s ICJjc3BAY3NwZXJraW5zLm9yZyIgPGNzcEBjc3BlcmtpbnMub3JnPiwgIkVtbWFudWVsLkJhY2Nl bGxpQGlucmlhLmZyIiA8RW1tYW51ZWwuQmFjY2VsbGlAaW5yaWEuZnI+DQpTdWJqZWN0OiBSRTog w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2st MTE6ICh3aXRoIENPTU1FTlQpDQoNCiAgICBIaSBFcmljLA0KDQogICAgPiA+DQogICAgPiA+IEVW PiBpbmRlZWQsIHRoYW5rIHlvdS4gTm93LCB3aGV0aGVyIHRoaXMgY29kZSBoYXMgYmVlbiB0ZXN0 ZWQgaW4NCiAgICA+ID4gc2V2ZXJhbCBzZXR1cHMgLyB0ZXN0IGNhc2VzIChiYW5kd2lkdGgsIHBh Y2tldCBsb3NzLCByZWJvb3RzKSB3b3VsZA0KICAgID4gPiBiZSBpbnRlcmVzdGluZy4NCiAgICA+ ID4NCiAgICA+IA0KICAgID4gW01lZF0gSXQgd2FzIHRlc3RlZCBpbiB0aGUgY29udGV4dCBvZiBE T1RTIHRlbGVtZXRyeS4gVGhlIGxpc3QgYWJvdmUgc2hvd3MNCiAgICA+IGhvdyB0aGUgdGVzdGlu ZyB3YXMgaGVscGZ1bCB0byByZWZpbmUvYXNzZXNzIHRoZSBkZXNpZ24uDQogICAgPiANCg0KICAg IExpYmNvYXAgcHJvdmlkZXMgdGhlIHRlc3RpbmcgY2FwYWJpbGl0eSBvZiBvbmUgb3IgbW9yZSBz cGVjaWZpYyBwYWNrZXRzIGRyb3BwZWQsIG9yIHJhbmRvbWx5IGRyb3BwZWQuIFRlc3Rpbmcgd2Fz IGRvbmUgd2l0aCBvbmUgb3IgbW9yZSBwYWNrZXRzIG1pc3NpbmcgZnJvbSB0aGUgc3RhcnQsIGFy b3VuZCB0aGUgTUFYX1BBWUxPQURTIHBhdXNlIHBvaW50LCBhdCB0aGUgZW5kIGFzIHdlbGwgYXMg aW4gdGhlIG1pZGRsZSBvZiBhIE1BWF9QQVlMT0FEIHNlcXVlbmNlIGZvciBib3RoIENPTiBhbmQg Tk9OLiAgTGVzc29ucyBsZWFybnQgYWJvdXQgdGhlIHJlY292ZXJpZXMgZXRjLiB1cGRhdGVkIHRo ZSBkcmFmdC4NCg0KICAgIExvZ2ljIHRlc3RlZCB3aXRoIGNvbXBsZXRlIHBhY2tldCBsb3NzIGlu IG9uZSBkaXJlY3Rpb24gKGZvciBOT04sIENPTiBmYWlscyBoZXJlKSBjb25maXJtaW5nIGRhdGEg c3RpbGwgZ2V0cyB0aHJvdWdoLg0KDQogICAgTXVsdGlwbGUgY29uY3VycmVudCBzZXNzaW9ucyB3 ZXJlIHJ1biBpbiBwYXJhbGxlbCAtIGluY2x1ZGluZyB3aXRoIGVuZm9yY2VkIHBhY2tldCBsb3Nz Lg0KDQogICAgQXBwbGljYXRpb25zIHJ1bm5pbmcgb24gdGhlIHBlZXJzIHdlcmUgcmVzdGFydGVk IGZyZXF1ZW50bHkgKG90aGVyIHBlZXIgcmVtYWluaW5nIHVwKSB0byBjaGVja291dCBvdXQgcmVj b3ZlcnkgZXRjLg0KDQogICAgVGhlIGJsb2NrIHNpemUgKFNaWCkgd2FzIGRlbGliZXJhdGVseSBz ZXQgdG8gYSBzbWFsbCBzaXplLCB0aHVzIGNvbnNpZGVyYWJseSBpbmNyZWFzaW5nIHRoZSBudW1i ZXIgb2YgYmxvY2tzIG5lZWRlZCB0byB0cmFuc2ZlciBsYXJnZSBwYXlsb2FkcyB0byBleGVyY2lz ZSB0aGF0IGxvZ2ljLiAgVGhpcyBicm91Z2h0IGFib3V0IHRoZSBhZGRpdGlvbiBvZiB0aGUgJ0Nv bnRpbnVlJyBsb2dpYy4NCg0KICAgIFJlZ2FyZHMNCg0KICAgIEpvbg0KDQoNCg== From nobody Tue May 4 02:01: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 771D43A2C16; Tue, 4 May 2021 02:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 Yxz4NEoLPY9z; Tue, 4 May 2021 02:01:13 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 5CEC33A2C0B; Tue, 4 May 2021 02:01:08 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 4FZDN16Qz9z5wpK; Tue, 4 May 2021 11:01:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620118865; bh=GM3ET2wu+avKOIjD5zRoQ2iV5P1uYAneKCktPE9mkB0=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=tlVqoK16c8p+OMZ6ybaSPjOXj/xP4Ic/DhoGfJsDoLtGS8y0cgCZVwX1cSTKLlr71 yYsQ78miFxtEg2HxEydSp2+k1UXGV7eWiXGiYgxw+qrWInUSwyThJoEi+3KRrZ/4WE toJ7A0C5EwD2iu4OShLAZwkPVT3kkOcF/aJjizXvkYzpCAnXisw6TivP5+xJfcx1Fj EI+C2+LChp8Oqyr0K+iMgAtB2IHwSu1XEgaCnG9ny7gx980bOsHws7nfxivD/6ueq+ XcGNP9v/hWFx4RTQIpvEMM4HYKg7rsu5cz/siAKyzvskMjvlU6JSdDlbRzGs4U8U64 IWZLhoZc3qylg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 4FZDN14mMWzDq7T; Tue, 4 May 2021 11:01:05 +0200 (CEST) From: To: Martin Duke CC: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: Martin Duke's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXPU6wbjJP1GdcPEqPLDpTNWikEarMh5CAgAV4iwCAAOpaQA== Date: Tue, 4 May 2021 09:01:04 +0000 Message-ID: <21895_1620118865_60910D51_21895_367_1_787AE7BB302AE849A7480A190F8B9330353764A2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <161973861706.19975.3092798532288165336@ietfa.amsl.com> <9640_1619783334_608BEEA5_9640_342_16_787AE7BB302AE849A7480A190F8B9330353751A9@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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330353764A2OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Martin Duke's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 09:01:19 -0000 --_000_787AE7BB302AE849A7480A190F8B9330353764A2OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFydGluLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDog TWFydGluIER1a2UgW21haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbV0NCkVudm95w6kgOiBs dW5kaSAzIG1haSAyMDIxIDIwOjU3DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gPG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpDYyA6IFRoZSBJRVNHIDxpZXNnQGlldGYub3Jn PjsgZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZzsgY29yZS1jaGFpcnNAaWV0Zi5v cmc7IGNvcmVAaWV0Zi5vcmc7IG1hcmNvLnRpbG9jYUByaS5zZQ0KT2JqZXQgOiBSZTogTWFydGlu IER1a2UncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMTE6ICh3aXRoIERJ U0NVU1MgYW5kIENPTU1FTlQpDQoNCg0KDQpPbiBGcmksIEFwciAzMCwgMjAyMSBhdCA0OjQ4IEFN IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPj4gd3JvdGU6DQo+DQo+IEkgY2FuJ3QgcmVjb25jaWxlICg0LjEpIHdpdGggdGhl IGxhc3Qgc2VudGVuY2UgaW4gKDcuMikuDQoNCltNZWRdIFdoeT8gNC4xIGNhbiBiZSBkb25lIHdp dGggZGVmYXVsdCBDb0FQIHNldHRpbmcuIFRoZSBwdXJwb3NlIG9mIHRoaXMgQ09OIHJlcXVlc3Qg aXMgdG8gZGV0ZXJtaW5lIHN1cHBvcnQgb2YgdGhlIGZ1bmN0aW9uYWxpdHkuIFdlIG1hZGUgdGhp cyBjaGFuZ2U6DQoNCk9MRDoNCiAgIENvbmdlc3Rpb24gY29udHJvbCBmb3IgQ09OIHJlcXVlc3Rz IGFuZCByZXNwb25zZXMgaXMgc3BlY2lmaWVkIGluDQogICBTZWN0aW9uIDQuNyBvZiBbUkZDNzI1 Ml0uICBJbiBvcmRlciB0byBiZW5lZml0IGZyb20gZmFzdGVyDQogICB0cmFuc21pc3Npb24gcmF0 ZXMsIE5TVEFSVCB3aWxsIG5lZWQgdG8gYmUgaW5jcmVhc2VkIGZyb20gMS4NCiAgIEhvd2V2ZXIs IHRoZSBvdGhlciBDT04gY29uZ2VzdGlvbiBjb250cm9sIHBhcmFtZXRlcnMgd2lsbCBuZWVkIHRv IGJlDQogICB0dW5lZCB0byBjb3ZlciB0aGlzIGNoYW5nZS4gIFRoaXMgdHVuaW5nIGlzIG5vdCBz cGVjaWZpZWQgaW4gdGhpcw0KICAgZG9jdW1lbnQgZ2l2ZW4gdGhhdCB0aGUgYXBwbGljYWJpbGl0 eSBzY29wZSBvZiB0aGUgY3VycmVudA0KICAgc3BlY2lmaWNhdGlvbiBhc3N1bWVzIHRoYXQgYWxs IHJlcXVlc3RzIGFuZCByZXNwb25zZXMgdXNpbmcgUS1CbG9jazENCiAgIGFuZCBRLUJsb2NrMiB3 aWxsIGJlIE5vbi1jb25maXJtYWJsZSAoU2VjdGlvbiAzLjIpLg0KDQpORVc6DQogICBDb25nZXN0 aW9uIGNvbnRyb2wgZm9yIENPTiByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIGlzIHNwZWNpZmllZCBp bg0KICAgU2VjdGlvbiA0Ljcgb2YgW1JGQzcyNTJdLiAgSW4gb3JkZXIgdG8gYmVuZWZpdCBmcm9t IGZhc3Rlcg0KICAgdHJhbnNtaXNzaW9uIHJhdGVzLCBOU1RBUlQgd2lsbCBuZWVkIHRvIGJlIGlu Y3JlYXNlZCBmcm9tIDEuDQogICBIb3dldmVyLCB0aGUgb3RoZXIgQ09OIGNvbmdlc3Rpb24gY29u dHJvbCBwYXJhbWV0ZXJzIHdpbGwgbmVlZCB0byBiZQ0KICAgdHVuZWQgdG8gY292ZXIgdGhpcyBj aGFuZ2UuICBUaGlzIHR1bmluZyBpcyBub3Qgc3BlY2lmaWVkIGluIHRoaXMNCiAgIGRvY3VtZW50 IGdpdmVuIHRoYXQgdGhlIGFwcGxpY2FiaWxpdHkgc2NvcGUgb2YgdGhlIGN1cnJlbnQNCiAgIHNw ZWNpZmljYXRpb24gYXNzdW1lcyB0aGF0IGFsbCByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIHVzaW5n IFEtQmxvY2sxDQogICBhbmQgUS1CbG9jazIgd2lsbCBiZSBOb24tY29uZmlybWFibGUgKFNlY3Rp b24gMy4yKSBhcGFydCBmcm9tIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl4NCiAgIGluaXRpYWwgUS1CbG9jayBm dW5jdGlvbmFsaXR5IG5lZ290aWF0aW9uLg0KICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXg0KDQpEb2VzIHRoZSBmdW5jdGlvbmFsaXR5IG5lZ290aWF0aW9uIGluICg0 LjEpIGludm9sdmUgc29tZXRoaW5nIG90aGVyIHRoYW4gc2VuZGluZyBRLUJsb2NrIG9wdGlvbnM/ DQpbTWVkXSBOby4gQWxsIHdoYXQgaXMgbmVlZGVkIGlzIHRvIHNlbmQgdGhlIG9wdGlvbnMgaW4g YSBDT04gbWVzc2FnZSBhcyBwZXI6DQoNCiAgIFRvIGluZGljYXRlIHN1cHBvcnQgZm9yIFEtQmxv Y2syIHJlc3BvbnNlcywgdGhlIENvQVAgY2xpZW50IE1VU1QNCiAgIGluY2x1ZGUgdGhlIFEtQmxv Y2syIE9wdGlvbiBpbiBhIEdFVCBvciBzaW1pbGFyIHJlcXVlc3QgKEZFVENILCBmb3INCiAgIGV4 YW1wbGUpLCB0aGUgUS1CbG9jazIgT3B0aW9uIGluIGEgUFVUIG9yIHNpbWlsYXIgcmVxdWVzdCAo UE9TVCwgZm9yDQogICBleGFtcGxlKSwgb3IgdGhlIFEtQmxvY2sxIE9wdGlvbiBpbiBhIFBVVCBv ciBzaW1pbGFyIHJlcXVlc3Qgc28gdGhhdA0KICAgdGhlIHNlcnZlciBrbm93cyB0aGF0IHRoZSBj bGllbnQgc3VwcG9ydHMgdGhpcyBRLUJsb2NrIGZ1bmN0aW9uYWxpdHkNCiAgIHNob3VsZCBpdCBu ZWVkIHRvIHNlbmQgYmFjayBhIGJvZHkgdGhhdCBzcGFucyBtdWx0aXBsZSBwYXlsb2Fkcy4NCiAg IE90aGVyd2lzZSwgdGhlIHNlcnZlciB3b3VsZCB1c2UgdGhlIEJsb2NrMiBPcHRpb24gKGlmIHN1 cHBvcnRlZCkgdG8NCiAgIHNlbmQgYmFjayBhIG1lc3NhZ2UgYm9keSB0aGF0IGlzIHRvbyBsYXJn ZSB0byBmaXQgaW50byBhIHNpbmdsZSBJUA0KICAgcGFja2V0IFtSRkM3OTU5XS4NCg0KSWYgc28s IHRoZW4gKDQuMSkgb3VnaHQgdG8gY2xhcmlmeSB0aGF0IGl0J3Mgd2hhdCB5b3UgbWVhbi4gSWYg aXQncyBqdXN0IGEgR0VUIG9yIHdoYXRldmVyLCB0aGVuIHRoZSB0ZXh0IGhlcmUgaXMgZmluZSwg YnV0IHRoZXJlIG5lZWRzIHRvIGJlIG1vcmUgb24gY29uZ2VzdGlvbiBjb250cm9sIGZvciBjb25m aXJtYWJsZSBtZXNzYWdlcy4NCg0KDQogTW9yZW92ZXIsIGlmDQo+IG15IHJlYWRpbmcgb2YgKDQu MSkgaXMgY29ycmVjdCwgaXQncyBub3Qgc3VmZmljaWVudCB0byBkZWNsYXJlDQo+IGNvbmdlc3Rp b24gY29udHJvbCBndWlkYW5jZSBvdXQgb2Ygc2NvcGUgd2hlbiBpdCdzIGEgbWFuZGF0ZWQgcGFy dCBvZg0KPiB0aGUgcHJvdG9jb2wuDQo+DQoNCj4NCj4gLSAoNy4yKSBJZiBOT05fUFJPQklOR19X QUlUIGFuZCBOT05fUEFSVElBTF9USU1FT1VUIGJvdGggImhhdmUgdGhlDQo+IHNhbWUgdmFsdWUg YXMgY29tcHV0ZWQgZm9yIEVYQ0hBTkdFX0xJRkVUSU1FIiwgd2h5IGFyZSB0aGV5IGRpZmZlcmVu dA0KPiB2YXJpYWJsZXM/DQoNCltNZWRdIEJlY2F1c2UgdGhleSByZWZlciB0byBkaXN0aW5jdCBh c3BlY3RzIHRoYXQgbWF5IGJlIHR3ZWFrZWQgc2VwYXJhdGVseTogdGhlIHRpbWVvdXQgaW5kdWNl ZCBieSBQUk9CSU5HX1JBVEUgYW5kIHRoZSBvbmUgdG8gb2JzZXJ2ZSBmb3IgZXhwaXJlZCBwYXJ0 aWFsIGJvZGllcy4NCg0KIE9yIGlzIHRoYXQgdGhleSBTSE9VTEQgaGF2ZSB0aGUgc2FtZSB2YWx1 ZSBidXQgbWlnaHQgbm90Pw0KPiBBIG5vcm1hdGl2ZSB3b3JkIHdvdWxkIGJlIGhlbHBmdWwgaGVy ZS4NCg0KW01lZF0gTm90IHN1cmUgYSBjaGFuZ2UgaXMgbmVlZGVkIGhlcmUgZ2l2ZW4gdGhlIGRl ZmluaXRpb24gb2YgdGhlIHR3byBwYXJhbWV0ZXJzLg0KDQpCdXQgdGhleSBjYW4ndCBiZSB0d2Vh a2VkIHNlcGFyYXRlbHkhIFRoZSBzcGVjIHN0YXRlcyB0aGF0IHRoZXkgYXJlIGJvdGggY29tcHV0 ZWQgYXMgRVhDSEFOR0VfTElGRVRJTUUuIEl0IGRvZXMgbm90IGFsbG93IGZvciB0aGVtIHRvIGJl IHNldCBzZXBhcmF0ZWx5Lg0KW01lZF0gQWgsIEkgc2VlIHdoYXQgY29uZnVzZXMgeW91LiBXZSBt YWRlIHRoaXMgY2hhbmdlOg0KDQpPTEQ6DQogICBOT05fUFJPQklOR19XQUlUIGlzIHVzZWQgdG8g bGltaXQgdGhlIHBvdGVudGlhbCB3YWl0IG5lZWRlZA0KICAgY2FsY3VsYXRlZCB3aGVuIHVzaW5n IFBST0JJTkdfUkFURS4gIE5PTl9QUk9CSU5HX1dBSVQgaGFzIHRoZSBzYW1lDQogICB2YWx1ZSBh cyBjb21wdXRlZCBmb3IgRVhDSEFOR0VfTElGRVRJTUUgKFNlY3Rpb24gNC44LjIgb2YgW1JGQzcy NTJdKS4NCg0KICAgTk9OX1BBUlRJQUxfVElNRU9VVCBpcyB1c2VkIGZvciBleHBpcmluZyBwYXJ0 aWFsbHkgcmVjZWl2ZWQgYm9kaWVzLg0KICAgTk9OX1BBUlRJQUxfVElNRU9VVCBoYXMgdGhlIHNh bWUgdmFsdWUgYXMgY29tcHV0ZWQgZm9yDQogICBFWENIQU5HRV9MSUZFVElNRSAoU2VjdGlvbiA0 LjguMiBvZiBbUkZDNzI1Ml0pLg0KDQpORVc6DQoNCiAgIE5PTl9QUk9CSU5HX1dBSVQgaXMgdXNl ZCB0byBsaW1pdCB0aGUgcG90ZW50aWFsIHdhaXQgbmVlZGVkDQoNCiAgIGNhbGN1bGF0ZWQgd2hl biB1c2luZyBQUk9CSU5HX1JBVEUuICBCeSBkZWZhdWx0LCBOT05fUFJPQklOR19XQUlUIGhhcw0K DQogICB0aGUgc2FtZSB2YWx1ZSBhcyBFWENIQU5HRV9MSUZFVElNRSAoU2VjdGlvbiA0LjguMiBv ZiBbUkZDNzI1Ml0pLg0KDQoNCg0KICAgTk9OX1BBUlRJQUxfVElNRU9VVCBpcyB1c2VkIGZvciBl eHBpcmluZyBwYXJ0aWFsbHkgcmVjZWl2ZWQgYm9kaWVzLg0KDQogICBCeSBkZWZhdWx0LCBOT05f UEFSVElBTF9USU1FT1VUIGhhcyB0aGUgc2FtZSB2YWx1ZSBhcw0KDQogICBFWENIQU5HRV9MSUZF VElNRSAoU2VjdGlvbiA0LjguMiBvZiBbUkZDNzI1Ml0pLg0KDQoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBl dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2 b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy CmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy YXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5v dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3Uu Cgo= --_000_787AE7BB302AE849A7480A190F8B9330353764A2OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBy w6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SGkgTWFydGluLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIHNl ZSBpbmxpbmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNYXJ0aW4gRHVrZSBbbWFpbHRvOm1h cnRpbi5oLmR1a2VAZ21haWwuY29tXQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IGx1bmRp IDMgbWFpIDIwMjEgMjA6NTc8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVk IFRHSS9PTE4gJmx0O21vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20mZ3Q7PGJyPg0KPGI+Q2Mm bmJzcDs6PC9iPiBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs7IGRyYWZ0LWlldGYtY29y ZS1uZXctYmxvY2tAaWV0Zi5vcmc7IGNvcmUtY2hhaXJzQGlldGYub3JnOyBjb3JlQGlldGYub3Jn OyBtYXJjby50aWxvY2FAcmkuc2U8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBNYXJ0aW4g RHVrZSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay0xMTogKHdpdGggRElT Q1VTUyBhbmQgQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBcHIgMzAsIDIwMjEgYXQgNDo0OCBBTSAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgPGJyPg0KJmd0OyBJIGNhbid0IHJl Y29uY2lsZSAoNC4xKSB3aXRoIHRoZSBsYXN0IHNlbnRlbmNlIGluICg3LjIpLjxicj4NCjxicj4N CltNZWRdIFdoeT8gNC4xIGNhbiBiZSBkb25lIHdpdGggZGVmYXVsdCBDb0FQIHNldHRpbmcuIFRo ZSBwdXJwb3NlIG9mIHRoaXMgQ09OIHJlcXVlc3QgaXMgdG8gZGV0ZXJtaW5lIHN1cHBvcnQgb2Yg dGhlIGZ1bmN0aW9uYWxpdHkuIFdlIG1hZGUgdGhpcyBjaGFuZ2U6PGJyPg0KPGJyPg0KT0xEOjxi cj4NCiZuYnNwOyAmbmJzcDtDb25nZXN0aW9uIGNvbnRyb2wgZm9yIENPTiByZXF1ZXN0cyBhbmQg cmVzcG9uc2VzIGlzIHNwZWNpZmllZCBpbjxicj4NCiZuYnNwOyAmbmJzcDtTZWN0aW9uIDQuNyBv ZiBbUkZDNzI1Ml0uJm5ic3A7IEluIG9yZGVyIHRvIGJlbmVmaXQgZnJvbSBmYXN0ZXI8YnI+DQom bmJzcDsgJm5ic3A7dHJhbnNtaXNzaW9uIHJhdGVzLCBOU1RBUlQgd2lsbCBuZWVkIHRvIGJlIGlu Y3JlYXNlZCBmcm9tIDEuPGJyPg0KJm5ic3A7ICZuYnNwO0hvd2V2ZXIsIHRoZSBvdGhlciBDT04g Y29uZ2VzdGlvbiBjb250cm9sIHBhcmFtZXRlcnMgd2lsbCBuZWVkIHRvIGJlPGJyPg0KJm5ic3A7 ICZuYnNwO3R1bmVkIHRvIGNvdmVyIHRoaXMgY2hhbmdlLiZuYnNwOyBUaGlzIHR1bmluZyBpcyBu b3Qgc3BlY2lmaWVkIGluIHRoaXM8YnI+DQombmJzcDsgJm5ic3A7ZG9jdW1lbnQgZ2l2ZW4gdGhh dCB0aGUgYXBwbGljYWJpbGl0eSBzY29wZSBvZiB0aGUgY3VycmVudDxicj4NCiZuYnNwOyAmbmJz cDtzcGVjaWZpY2F0aW9uIGFzc3VtZXMgdGhhdCBhbGwgcmVxdWVzdHMgYW5kIHJlc3BvbnNlcyB1 c2luZyBRLUJsb2NrMTxicj4NCiZuYnNwOyAmbmJzcDthbmQgUS1CbG9jazIgd2lsbCBiZSBOb24t Y29uZmlybWFibGUgKFNlY3Rpb24gMy4yKS48YnI+DQo8YnI+DQpORVc6Jm5ic3A7IDxicj4NCiZu YnNwOyAmbmJzcDtDb25nZXN0aW9uIGNvbnRyb2wgZm9yIENPTiByZXF1ZXN0cyBhbmQgcmVzcG9u c2VzIGlzIHNwZWNpZmllZCBpbjxicj4NCiZuYnNwOyAmbmJzcDtTZWN0aW9uIDQuNyBvZiBbUkZD NzI1Ml0uJm5ic3A7IEluIG9yZGVyIHRvIGJlbmVmaXQgZnJvbSBmYXN0ZXI8YnI+DQombmJzcDsg Jm5ic3A7dHJhbnNtaXNzaW9uIHJhdGVzLCBOU1RBUlQgd2lsbCBuZWVkIHRvIGJlIGluY3JlYXNl ZCBmcm9tIDEuPGJyPg0KJm5ic3A7ICZuYnNwO0hvd2V2ZXIsIHRoZSBvdGhlciBDT04gY29uZ2Vz dGlvbiBjb250cm9sIHBhcmFtZXRlcnMgd2lsbCBuZWVkIHRvIGJlPGJyPg0KJm5ic3A7ICZuYnNw O3R1bmVkIHRvIGNvdmVyIHRoaXMgY2hhbmdlLiZuYnNwOyBUaGlzIHR1bmluZyBpcyBub3Qgc3Bl Y2lmaWVkIGluIHRoaXM8YnI+DQombmJzcDsgJm5ic3A7ZG9jdW1lbnQgZ2l2ZW4gdGhhdCB0aGUg YXBwbGljYWJpbGl0eSBzY29wZSBvZiB0aGUgY3VycmVudDxicj4NCiZuYnNwOyAmbmJzcDtzcGVj aWZpY2F0aW9uIGFzc3VtZXMgdGhhdCBhbGwgcmVxdWVzdHMgYW5kIHJlc3BvbnNlcyB1c2luZyBR LUJsb2NrMTxicj4NCiZuYnNwOyAmbmJzcDthbmQgUS1CbG9jazIgd2lsbCBiZSBOb24tY29uZmly bWFibGUgKFNlY3Rpb24gMy4yKSBhcGFydCBmcm9tIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IF5eXl5eXl5eXl5eXl5eJm5ic3A7IDxicj4NCiZuYnNwOyAmbmJzcDtpbml0aWFsIFEtQmxvY2sg ZnVuY3Rpb25hbGl0eSBuZWdvdGlhdGlvbi48YnI+DQombmJzcDsgJm5ic3A7Xl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9lcyB0aGUgZnVuY3Rpb25hbGl0eSBu ZWdvdGlhdGlvbiBpbiAoNC4xKSBpbnZvbHZlIHNvbWV0aGluZyBvdGhlciB0aGFuIHNlbmRpbmcg US1CbG9jayBvcHRpb25zPzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj5bTWVkXSBOby4gQWxsIHdoYXQgaXMgbmVlZGVkIGlzIHRvIHNlbmQgdGhlIG9wdGlvbnMg aW4gYSBDT04gbWVzc2FnZSBhcyBwZXI6ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRvIGluZGljYXRlIHN1cHBvcnQgZm9yIFEtQmxvY2sy IHJlc3BvbnNlcywgdGhlIENvQVAgY2xpZW50IE1VU1Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGluY2x1ZGUgdGhlIFEt QmxvY2syIE9wdGlvbiBpbiBhIEdFVCBvciBzaW1pbGFyIHJlcXVlc3QgKEZFVENILCBmb3I8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IGV4YW1wbGUpLCB0aGUgUS1CbG9jazIgT3B0aW9uIGluIGEgUFVUIG9yIHNpbWlsYXIg cmVxdWVzdCAoUE9TVCwgZm9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBleGFtcGxlKSwgb3IgdGhlIFEtQmxvY2sxIE9w dGlvbiBpbiBhIFBVVCBvciBzaW1pbGFyIHJlcXVlc3Qgc28gdGhhdDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhlIHNl cnZlciBrbm93cyB0aGF0IHRoZSBjbGllbnQgc3VwcG9ydHMgdGhpcyBRLUJsb2NrIGZ1bmN0aW9u YWxpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IHNob3VsZCBpdCBuZWVkIHRvIHNlbmQgYmFjayBhIGJvZHkgdGhhdCBz cGFucyBtdWx0aXBsZSBwYXlsb2Fkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IE90aGVyd2lzZSwgdGhlIHNlcnZlciB3 b3VsZCB1c2UgdGhlIEJsb2NrMiBPcHRpb24gKGlmIHN1cHBvcnRlZCkgdG88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHNl bmQgYmFjayBhIG1lc3NhZ2UgYm9keSB0aGF0IGlzIHRvbyBsYXJnZSB0byBmaXQgaW50byBhIHNp bmdsZSBJUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgcGFja2V0IFtSRkM3OTU5XS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklm IHNvLCB0aGVuICg0LjEpIG91Z2h0IHRvIGNsYXJpZnkgdGhhdCBpdCdzIHdoYXQgeW91IG1lYW4u IElmIGl0J3MganVzdCBhIEdFVCBvciB3aGF0ZXZlciwgdGhlbiB0aGUgdGV4dCBoZXJlIGlzIGZp bmUsIGJ1dCB0aGVyZSBuZWVkcyB0byBiZSBtb3JlIG9uIGNvbmdlc3Rpb24gY29udHJvbCBmb3Ig Y29uZmlybWFibGUgbWVzc2FnZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZuYnNwO01vcmVvdmVyLCBpZjxicj4NCiZn dDsgbXkgcmVhZGluZyBvZiAoNC4xKSBpcyBjb3JyZWN0LCBpdCdzIG5vdCBzdWZmaWNpZW50IHRv IGRlY2xhcmU8YnI+DQomZ3Q7IGNvbmdlc3Rpb24gY29udHJvbCBndWlkYW5jZSBvdXQgb2Ygc2Nv cGUgd2hlbiBpdCdzIGEgbWFuZGF0ZWQgcGFydCBvZjxicj4NCiZndDsgdGhlIHByb3RvY29sLjxi cj4NCiZndDsgPGJyPg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0gKDcuMikgSWYgTk9OX1BST0JJ TkdfV0FJVCBhbmQgTk9OX1BBUlRJQUxfVElNRU9VVCBib3RoICZxdW90O2hhdmUgdGhlPGJyPg0K Jmd0OyBzYW1lIHZhbHVlIGFzIGNvbXB1dGVkIGZvciBFWENIQU5HRV9MSUZFVElNRSZxdW90Oywg d2h5IGFyZSB0aGV5IGRpZmZlcmVudDxicj4NCiZndDsgdmFyaWFibGVzPzxicj4NCjxicj4NCltN ZWRdIEJlY2F1c2UgdGhleSByZWZlciB0byBkaXN0aW5jdCBhc3BlY3RzIHRoYXQgbWF5IGJlIHR3 ZWFrZWQgc2VwYXJhdGVseTogdGhlIHRpbWVvdXQgaW5kdWNlZCBieSBQUk9CSU5HX1JBVEUgYW5k IHRoZSBvbmUgdG8gb2JzZXJ2ZSBmb3IgZXhwaXJlZCBwYXJ0aWFsIGJvZGllcy4NCjxicj4NCjxi cj4NCiZuYnNwO09yIGlzIHRoYXQgdGhleSBTSE9VTEQgaGF2ZSB0aGUgc2FtZSB2YWx1ZSBidXQg bWlnaHQgbm90Pzxicj4NCiZndDsgQSBub3JtYXRpdmUgd29yZCB3b3VsZCBiZSBoZWxwZnVsIGhl cmUuPGJyPg0KPGJyPg0KW01lZF0gTm90IHN1cmUgYSBjaGFuZ2UgaXMgbmVlZGVkIGhlcmUgZ2l2 ZW4gdGhlIGRlZmluaXRpb24gb2YgdGhlIHR3byBwYXJhbWV0ZXJzLjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IHRoZXkgY2Fu J3QgYmUgdHdlYWtlZCBzZXBhcmF0ZWx5ISBUaGUgc3BlYyBzdGF0ZXMgdGhhdCB0aGV5IGFyZSBi b3RoIGNvbXB1dGVkIGFzIEVYQ0hBTkdFX0xJRkVUSU1FLiBJdCBkb2VzIG5vdCBhbGxvdyBmb3Ig dGhlbSB0byBiZSBzZXQgc2VwYXJhdGVseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNZWRdIEFoLCBJIHNlZSB3aGF0 IGNvbmZ1c2VzIHlvdS4gV2UgbWFkZSB0aGlzIGNoYW5nZTo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T0xEOjxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyBOT05fUFJPQklOR19XQUlUIGlzIHVzZWQgdG8gbGltaXQgdGhlIHBvdGVudGlhbCB3YWl0IG5l ZWRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgY2FsY3VsYXRlZCB3aGVuIHVzaW5nIFBST0JJTkdfUkFURS4mbmJzcDsg Tk9OX1BST0JJTkdfV0FJVCBoYXMgdGhlIHNhbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHZhbHVlIGFzIGNvbXB1dGVk IGZvciBFWENIQU5HRV9MSUZFVElNRSAoU2VjdGlvbiA0LjguMiBvZiBbUkZDNzI1Ml0pLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IE5PTl9QQVJUSUFMX1RJTUVPVVQgaXMgdXNlZCBmb3IgZXhwaXJpbmcgcGFydGlh bGx5IHJlY2VpdmVkIGJvZGllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IE5PTl9QQVJUSUFMX1RJTUVPVVQgaGFzIHRo ZSBzYW1lIHZhbHVlIGFzIGNvbXB1dGVkIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgRVhDSEFOR0VfTElGRVRJTUUg KFNlY3Rpb24gNC44LjIgb2YgW1JGQzcyNTJdKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5FVzo8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPiZuYnNw OyZuYnNwOyBOT05fUFJPQklOR19XQUlUIGlzIHVzZWQgdG8gbGltaXQgdGhlIHBvdGVudGlhbCB3 YWl0IG5lZWRlZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjYWxjdWxhdGVk IHdoZW4gdXNpbmcgUFJPQklOR19SQVRFLiZuYnNwOyA8c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5C eSBkZWZhdWx0LCA8L3NwYW4+Tk9OX1BST0JJTkdfV0FJVCBoYXM8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgdGhlIHNhbWUgdmFsdWUgYXMgRVhDSEFOR0VfTElGRVRJTUUgKFNl Y3Rpb24gNC44LjIgb2YgW1JGQzcyNTJdKS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgTk9OX1BBUlRJQUxfVElNRU9VVCBp cyB1c2VkIGZvciBleHBpcmluZyBwYXJ0aWFsbHkgcmVjZWl2ZWQgYm9kaWVzLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyA8c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5CeSBkZWZh dWx0LCA8L3NwYW4+Tk9OX1BBUlRJQUxfVElNRU9VVCBoYXMgdGhlIHNhbWUgdmFsdWUgYXM8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgRVhDSEFOR0VfTElGRVRJTUUgKFNlY3Rp b24gNC44LjIgb2YgW1JGQzcyNTJdKS48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRl cyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHBy aXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRl cyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3Nh Z2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUg ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0 cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUg dG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUg b3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkg YmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2Vk IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmll ZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1s Pg0K --_000_787AE7BB302AE849A7480A190F8B9330353764A2OPEXCAUBMA2corp_-- From nobody Tue May 4 08:28: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 8B9E23A0B56; Tue, 4 May 2021 08:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=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 ed4l0-VrvZ3r; Tue, 4 May 2021 08:28:35 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8CF23A0B9E; Tue, 4 May 2021 08:28:34 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id c3so6687318ils.5; Tue, 04 May 2021 08:28:34 -0700 (PDT) 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=l4MTkMHmLcoTNvVaNI4Jzb8ZGKws9idIJ4AL2IlGYHw=; b=V7izwVoqorqOYU1FwG2sss0vvqMW5vuq0Y10Tc79KJcq4Us4lBLWisoXT3MUuo5nxV LmmdjT6hR0knu0GoCUq+IoSOUhx5j78QbRcHirvp56LimLcVIaWb9gt5c5vs8gXW9IYu UP23hHPh7n7ecHqdJWe0o16nZSYz/6OJS4txh/rBvwPWfWC3+5xM9PzleWqU7BrHQqFD cec2L1VzhdVaE5njEgjJvjlrtdJ6ajM+5BvkMVicehDlyKecb1+rxDdqhpRFxntGBxWX Kzxk5Nc6mYE8dTzMwHjLLp1Uw2Q0BBHII9iaDg1WLJ3s/+JuDiRPkwHJns6GxZU9xaes +obQ== 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=l4MTkMHmLcoTNvVaNI4Jzb8ZGKws9idIJ4AL2IlGYHw=; b=tkmZtxju+sZOFK3Ydk+RYBTVxrNxabpyfnVpLyL54R9Sl+ChwBHLNnskm0CCUeeHo8 U8lmbQQwaS72JDs0GcY2FLlG9+kyd6Ovgca69oAvxDhYeMYwUDTMGDsrn6Cx/RD+Shsq bLPQeTRXl2xZPOE19dtBc7TO9i/ie3Dv1mfEHuLcl8YtRNzrtQCpZvmoGrMcSpz5gBNy VHgRBDAGeY2LqN5xq6cgyNlziOi2ULwg0c5AJAMlQKxsgEsnZgSzvjMs86daEvWLsQYN t2Ra63xcorjOFpECvkIQnF3eGnM+dx89Z6Qxxz1y06PhoWvZA0U1JOOor+xLw5xqL0mP WE/A== X-Gm-Message-State: AOAM531JT4h5WcRazB4/bkpwMxbz9DRiUl+jMPkmHJA3++yf8bRYpiNd ATm5iJKIRTFort5TpdABX+pjOp5lXhpBKnSGvUs= X-Google-Smtp-Source: ABdhPJzdHMezXnZSWa7+Ex+pRKS0hFt0F37KF2gUDzMuKXs8z7eo1uaeCc+C6w87uu9or19WyIVVTvUWac36jWscS8g= X-Received: by 2002:a05:6e02:2162:: with SMTP id s2mr21158617ilv.237.1620142112561; Tue, 04 May 2021 08:28:32 -0700 (PDT) MIME-Version: 1.0 References: <161973861706.19975.3092798532288165336@ietfa.amsl.com> <9640_1619783334_608BEEA5_9640_342_16_787AE7BB302AE849A7480A190F8B9330353751A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <21895_1620118865_60910D51_21895_367_1_787AE7BB302AE849A7480A190F8B9330353764A2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <21895_1620118865_60910D51_21895_367_1_787AE7BB302AE849A7480A190F8B9330353764A2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Martin Duke Date: Tue, 4 May 2021 08:28:23 -0700 Message-ID: To: mohamed.boucadair@orange.com Cc: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Content-Type: multipart/alternative; boundary="0000000000001adef205c182bb09" Archived-At: Subject: Re: [core] Martin Duke's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 15:28:41 -0000 --0000000000001adef205c182bb09 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK, we've reached understanding on the NON_PROBING_WAIT/NON_PARTIAL_TIMEOUT issue. Thank you for the edit. I also now understand that essentially every connection will have a Q-block exchange using CON. As this is an integral part of the protocol, I don't believe it's sufficient for Sec 7.1 to declare congestion control parameters out of scope, unless there's a normative reference to some other draft that explains how to do it. Thanks Martin On Tue, May 4, 2021 at 2:01 AM wrote: > Hi Martin, > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :* Martin Duke [mailto:martin.h.duke@gmail.com] > *Envoy=C3=A9 :* lundi 3 mai 2021 20:57 > *=C3=80 :* BOUCADAIR Mohamed TGI/OLN > *Cc :* The IESG ; draft-ietf-core-new-block@ietf.org; > core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se > *Objet :* Re: Martin Duke's Discuss on draft-ietf-core-new-block-11: > (with DISCUSS and COMMENT) > > > > > > > > On Fri, Apr 30, 2021 at 4:48 AM wrote: > > > > > I can't reconcile (4.1) with the last sentence in (7.2). > > [Med] Why? 4.1 can be done with default CoAP setting. The purpose of this > CON request is to determine support of the functionality. We made this > change: > > OLD: > Congestion control for CON requests and responses is specified in > Section 4.7 of [RFC7252]. In order to benefit from 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 not specified in this > document given that the applicability scope of the current > specification assumes that all requests and responses using Q-Block1 > and Q-Block2 will be Non-confirmable (Section 3.2). > > NEW: > Congestion control for CON requests and responses is specified in > Section 4.7 of [RFC7252]. In order to benefit from 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 not specified in this > document given that the applicability scope of the current > specification assumes that all requests and responses using Q-Block1 > and Q-Block2 will be Non-confirmable (Section 3.2) apart from the > ^^^^^^^^^^^^^^ > initial Q-Block functionality negotiation. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Does the functionality negotiation in (4.1) involve something other than > sending Q-Block options? > > *[Med] No. All what is needed is to send the options in a CON message as > per: * > > > > To indicate support for Q-Block2 responses, the CoAP client MUST > > include the Q-Block2 Option in a GET or similar request (FETCH, for > > example), the Q-Block2 Option in a PUT or similar request (POST, for > > example), or the Q-Block1 Option in a PUT or similar request so that > > the server knows that the client supports this Q-Block functionality > > should it need to send back a body that spans multiple payloads. > > Otherwise, the server would use the Block2 Option (if supported) to > > send back a message body that is too large to fit into a single IP > > packet [RFC7959]. > > > > If so, then (4.1) ought to clarify that it's what you mean. If it's just = a > GET or whatever, then the text here is fine, but there needs to be more o= n > congestion control for confirmable messages. > > > > > Moreover, if > > my reading of (4.1) is correct, it's not sufficient to declare > > congestion control guidance out of scope when it's a mandated part of > > the protocol. > > > > > > > - (7.2) If NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT both "have the > > same value as computed for EXCHANGE_LIFETIME", why are they different > > variables? > > [Med] Because they refer to distinct aspects that may be tweaked > separately: the timeout induced by PROBING_RATE and the one to observe fo= r > expired partial bodies. > > Or is that they SHOULD have the same value but might not? > > A normative word would be helpful here. > > [Med] Not sure a change is needed here given the definition of the two > parameters. > > > > But they can't be tweaked separately! The spec states that they are both > computed as EXCHANGE_LIFETIME. It does not allow for them to be set > separately. > > *[Med] Ah, I see what confuses you. We made this change:* > > > > *OLD:* > > NON_PROBING_WAIT is used to limit the potential wait needed > > calculated when using PROBING_RATE. NON_PROBING_WAIT has the same > > value as computed for EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). > > > > NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. > > NON_PARTIAL_TIMEOUT has the same value as computed for > > EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). > > > > *NEW:* > > NON_PROBING_WAIT is used to limit the potential wait needed > > calculated when using PROBING_RATE. By default, NON_PROBING_WAIT has > > the same value as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). > > > > NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. > > By default, NON_PARTIAL_TIMEOUT has the same value as > > EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --0000000000001adef205c182bb09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, we've reached understanding on the NON_PROBIN= G_WAIT/NON_PARTIAL_TIMEOUT issue. Thank you for the edit.

I also now understand that essentially every connection will have a= Q-block exchange using CON. As this is an integral part of the protocol, I= don't believe it's sufficient for Sec 7.1 to declare congestion co= ntrol parameters out of scope, unless there's a normative reference to = some other draft that explains how to do it.

Thank= s
Martin

On Tue, May 4, 2021 at 2:01 AM <mohamed.boucadair@orange.com> = wrote:

Hi Martin,

=C2=A0

Please see inline.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Martin= Duke [mailto:= martin.h.duke@gmail.com]
Envoy=C3=A9=C2=A0: lundi 3 mai 2021 20:57
=C3=80=C2=A0: BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com&= gt;
Cc=C2=A0: The IESG <iesg@ietf.org>; draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org= ; core@ietf.org; marco.tiloca@ri.se=
Objet=C2=A0: Re: Martin Duke's Discuss on draft-ietf-core-new-bl= ock-11: (with DISCUSS and COMMENT)

=C2=A0

=C2=A0

=C2=A0

On Fri, Apr 30, 2021 at 4:48 AM <mohamed.boucadair@orange.= com> wrote:

>
> I can't reconcile (4.1) with the last sentence in (7.2).

[Med] Why? 4.1 can be done with default CoAP setting. The purpose of this C= ON request is to determine support of the functionality. We made this chang= e:

OLD:
=C2=A0 =C2=A0Congestion control for CON requests and responses is specified= in
=C2=A0 =C2=A0Section 4.7 of [RFC7252].=C2=A0 In order to benefit from faste= r
=C2=A0 =C2=A0transmission rates, NSTART will need to be increased from 1. =C2=A0 =C2=A0However, the other CON congestion control parameters will need= to be
=C2=A0 =C2=A0tuned to cover this change.=C2=A0 This tuning is not specified= in this
=C2=A0 =C2=A0document given that the applicability scope of the current
=C2=A0 =C2=A0specification assumes that all requests and responses using Q-= Block1
=C2=A0 =C2=A0and Q-Block2 will be Non-confirmable (Section 3.2).

NEW:=C2=A0
=C2=A0 =C2=A0Congestion control for CON requests and responses is specified= in
=C2=A0 =C2=A0Section 4.7 of [RFC7252].=C2=A0 In order to benefit from faste= r
=C2=A0 =C2=A0transmission rates, NSTART will need to be increased from 1. =C2=A0 =C2=A0However, the other CON congestion control parameters will need= to be
=C2=A0 =C2=A0tuned to cover this change.=C2=A0 This tuning is not specified= in this
=C2=A0 =C2=A0document given that the applicability scope of the current
=C2=A0 =C2=A0specification assumes that all requests and responses using Q-= Block1
=C2=A0 =C2=A0and Q-Block2 will be Non-confirmable (Section 3.2) apart from = the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^^^^=C2=A0
=C2=A0 =C2=A0initial Q-Block functionality negotiation.
=C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

=C2=A0

Does the functionality negotiation in (4.1) involve = something other than sending Q-Block options?

[Med] No. All what is needed is t= o send the options in a CON message as per: =C2=A0=

=C2=A0

=C2=A0=C2=A0 To indicate support for Q-Block2 responses, the= CoAP client MUST

=C2=A0=C2=A0 include the Q-Block2 Option in a GET or similar= request (FETCH, for

=C2=A0=C2=A0 example), the Q-Block2 Option in a PUT or simil= ar request (POST, for

=C2=A0=C2=A0 example), or the Q-Block1 Option in a PUT or si= milar request so that

=C2=A0=C2=A0 the server knows that the client supports this = Q-Block functionality

=C2=A0=C2=A0 should it need to send back a body that spans m= ultiple payloads.

=C2=A0=C2=A0 Otherwise, the server would use the Block2 Opti= on (if supported) to

=C2=A0=C2=A0 send back a message body that is too large to f= it into a single IP

=C2=A0=C2=A0 packet [RFC7959].

=C2=A0

If so, then (4.1) ought to clarify that it's wha= t you mean. If it's just a GET or whatever, then the text here is fine,= but there needs to be more on congestion control for confirmable messages.=

=C2=A0


=C2=A0Moreover, if
> my reading of (4.1) is correct, it's not sufficient to declare
> congestion control guidance out of scope when it's a mandated part= of
> the protocol.
>

>
> - (7.2) If NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT both "have th= e
> same value as computed for EXCHANGE_LIFETIME", why are they diffe= rent
> variables?

[Med] Because they refer to distinct aspects that may be tweaked separately= : the timeout induced by PROBING_RATE and the one to observe for expired pa= rtial bodies.

=C2=A0Or is that they SHOULD have the same value but might not?
> A normative word would be helpful here.

[Med] Not sure a change is needed here given the definition of the two para= meters.

=C2=A0

But they can't be tweaked separately! The spec s= tates that they are both computed as EXCHANGE_LIFETIME. It does not allow f= or them to be set separately.

[Med] Ah, I see what confuses you= . We made this change:

=C2=A0

OLD:=

=C2=A0=C2=A0 NON_PROBING_WAIT is used to limit the potential= wait needed

=C2=A0=C2=A0 calculated when using PROBING_RATE.=C2=A0 NON_P= ROBING_WAIT has the same

=C2=A0=C2=A0 value as computed for EXCHANGE_LIFETIME (Sectio= n 4.8.2 of [RFC7252]).

=C2=A0

=C2=A0=C2=A0 NON_PARTIAL_TIMEOUT is used for expiring partia= lly received bodies.

=C2=A0=C2=A0 NON_PARTIAL_TIMEOUT has the same value as compu= ted for

=C2=A0=C2=A0 EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).=

=C2=A0

NEW:<= u>

=C2=A0=C2=A0 NON_PROBING_WAIT is used to limit the potential wait need=
ed
=C2=A0=C2=A0 calculated when using PROBING_RATE.=C2=A0 By default, NON_PROBING_WAIT has
=C2=A0=C2=A0 the same value as EXCHANGE_LIFETIME (Section 4.8.2 of [RF=
C7252]).
=C2=A0
=C2=A0=C2=A0 NON_PARTIAL_TIMEOUT is used for expiring partially receiv=
ed bodies.
=C2=A0=C2=A0 By default, NON_PARTIAL_=
TIMEOUT has the same value as
=C2=A0=C2=A0 EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).=

=C2=A0

______________________________________________________________________=
___________________________________________________

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 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 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.
--0000000000001adef205c182bb09-- From nobody Tue May 4 09:33:44 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 737293A113F; Tue, 4 May 2021 09:33:41 -0700 (PDT) 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_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 Dn4VizJaW_dY; Tue, 4 May 2021 09:33:36 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 581893A1271; Tue, 4 May 2021 09:33:12 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 4FZQPd3sQ5z1yw9; Tue, 4 May 2021 18:33:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620145989; bh=PMNdAPe2KRyKbCfkjO3Q+3Ry8lsT/xlK3J+xkciKhE8=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=I0eEBZG5+FolaM0e8Zm4Vqs6EEJdbf0UunfsDuUFNWgmO3Zg50HJ/9JfoLkOflo9O 5jN5Bv4KXaKfR+OR+Kfk5QAROGSkEPUHOqyWo9l4jWZsMAZbac04oXOF+X93uLXp86 +21ZhI0oH3sdAXBCw0r+3Hkwfv66Z6AnCaWjFZayvGNLZL0EH0KcZDkLJKIJYjEkdj L0d5/qrARgE2sLhIuJv1SXEb3OnV/LLL9WX6napemM/dU/A9zi5J3kbk5hzHv76Kng aG3V/VdbKpQ50VNogZJGoWx2EZWJw86VuouACyznvvxVsJPoTFkepyvwQSJR4guYIo F7mqwsMyQO9KA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4FZQPd2z5GzDq7l; Tue, 4 May 2021 18:33:09 +0200 (CEST) From: To: Martin Duke CC: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: Martin Duke's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXPU6wbjJP1GdcPEqPLDpTNWikEarMh5CAgAV4iwCAAOpaQIAAbaOAgAAv2jA= Date: Tue, 4 May 2021 16:33:08 +0000 Message-ID: <18827_1620145989_60917745_18827_231_1_787AE7BB302AE849A7480A190F8B93303537688C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <161973861706.19975.3092798532288165336@ietfa.amsl.com> <9640_1619783334_608BEEA5_9640_342_16_787AE7BB302AE849A7480A190F8B9330353751A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <21895_1620118865_60910D51_21895_367_1_787AE7BB302AE849A7480A190F8B9330353764A2@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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303537688COPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Martin Duke's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 16:33:42 -0000 --_000_787AE7BB302AE849A7480A190F8B93303537688COPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpXZSBhcmUgbm90IHNlZWtpbmcgZm9yIHBlcmZvcm1hbmNlIGVuaGFuY2VtZW50IHdo ZW4gZGV0ZXJtaW5pbmcgUS1CbG9jayBzdXBwb3J0LiBUaGlzIHdoeSBJIGluZGljYXRlZCBpbiBt eSBmaXJzdCByZXBseSB0aGF0IG5vIGNoYW5nZSB0byB0aGUgYmFzZSBDQyBpcyBuZWVkZWQgZm9y IHRoYXQuIFdlIHVwZGF0ZWQgdGhlIHRleHQgYXMgZm9sbG93czoNCg0KT0xEOg0KICAgV2l0aCBD b0FQIG92ZXIgVURQLCB0aGUgd2F5IGEgcmVxdWVzdCBtZXNzYWdlIGlzIHJlamVjdGVkIGZvcg0K ICAgY3JpdGljYWwgb3B0aW9ucyBkZXBlbmRzIG9uIHRoZSBtZXNzYWdlIHR5cGUuICBBIENvbmZp cm1hYmxlIG1lc3NhZ2UNCiAgIHdpdGggYW4gdW5yZWNvZ25pemVkIGNyaXRpY2FsIG9wdGlvbiBp cyByZWplY3RlZCB3aXRoIGEgNC4wMiAoQmFkDQogICBPcHRpb24pIHJlc3BvbnNlIChTZWN0aW9u IDUuNC4xIG9mIFtSRkM3MjUyXSkuICBBIE5vbi1jb25maXJtYWJsZQ0KICAgbWVzc2FnZSB3aXRo IGFuIHVucmVjb2duaXplZCBjcml0aWNhbCBvcHRpb24gaXMgZWl0aGVyIHJlamVjdGVkIHdpdGgN CiAgIGEgUmVzZXQgbWVzc2FnZSBvciBqdXN0IHNpbGVudGx5IGlnbm9yZWQgKFNlY3Rpb25zIDUu NC4xIGFuZCA0LjMgb2YNCiAgIFtSRkM3MjUyXSkuICBUbyByZWxpYWJseSBnZXQgYSByZWplY3Rp b24gbWVzc2FnZSwgaXQgaXMgdGhlcmVmb3JlDQogICBSRVFVSVJFRCB0aGF0IGNsaWVudHMgdXNl IGEgQ29uZmlybWFibGUgbWVzc2FnZSBmb3IgZGV0ZXJtaW5pbmcNCiAgIHN1cHBvcnQgZm9yIFEt QmxvY2sxIGFuZCBRLUJsb2NrMiBPcHRpb25zLg0KDQpORVc6DQogICBXaXRoIENvQVAgb3ZlciBV RFAsIHRoZSB3YXkgYSByZXF1ZXN0IG1lc3NhZ2UgaXMgcmVqZWN0ZWQgZm9yDQogICBjcml0aWNh bCBvcHRpb25zIGRlcGVuZHMgb24gdGhlIG1lc3NhZ2UgdHlwZS4gIEEgQ29uZmlybWFibGUgbWVz c2FnZQ0KICAgd2l0aCBhbiB1bnJlY29nbml6ZWQgY3JpdGljYWwgb3B0aW9uIGlzIHJlamVjdGVk IHdpdGggYSA0LjAyIChCYWQNCiAgIE9wdGlvbikgcmVzcG9uc2UgKFNlY3Rpb24gNS40LjEgb2Yg W1JGQzcyNTJdKS4gIEEgTm9uLWNvbmZpcm1hYmxlDQogICBtZXNzYWdlIHdpdGggYW4gdW5yZWNv Z25pemVkIGNyaXRpY2FsIG9wdGlvbiBpcyBlaXRoZXIgcmVqZWN0ZWQgd2l0aA0KICAgYSBSZXNl dCBtZXNzYWdlIG9yIGp1c3Qgc2lsZW50bHkgaWdub3JlZCAoU2VjdGlvbnMgNS40LjEgYW5kIDQu MyBvZg0KICAgW1JGQzcyNTJdKS4gIFRvIHJlbGlhYmx5IGdldCBhIHJlamVjdGlvbiBtZXNzYWdl LCBpdCBpcyB0aGVyZWZvcmUNCiAgIFJFUVVJUkVEIHRoYXQgY2xpZW50cyB1c2UgYSBDb25maXJt YWJsZSBtZXNzYWdlIGZvciBkZXRlcm1pbmluZw0KICAgc3VwcG9ydCBmb3IgUS1CbG9jazEgYW5k IFEtQmxvY2syIE9wdGlvbnMuICBUaGlzIENPTiBtZXNzYWdlIGNhbiBiZQ0KICAgc2VudCB1bmRl ciBiYXNlIENvQVAgY29uZ2VzdGlvbiBjb250cm9sIHNldHVwIHNwZWNpZmllZCBpbg0KICAgU2Vj dGlvbiA0Ljcgb2YgW1JGQzcyNTJdICh0aGF0IGlzLCBOU1RBUlQgZG9lcyBub3QgbmVlZCB0byBi ZQ0KICAgaW5jcmVhc2VkKS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTWFydGluIER1a2UgW21h aWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbV0NCkVudm95w6kgOiBtYXJkaSA0IG1haSAyMDIx IDE3OjI4DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gPG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20+DQpDYyA6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1j b3JlLW5ldy1ibG9ja0BpZXRmLm9yZzsgY29yZS1jaGFpcnNAaWV0Zi5vcmc7IGNvcmVAaWV0Zi5v cmc7IG1hcmNvLnRpbG9jYUByaS5zZQ0KT2JqZXQgOiBSZTogTWFydGluIER1a2UncyBEaXNjdXNz IG9uIGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMTE6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1F TlQpDQoNCk9LLCB3ZSd2ZSByZWFjaGVkIHVuZGVyc3RhbmRpbmcgb24gdGhlIE5PTl9QUk9CSU5H X1dBSVQvTk9OX1BBUlRJQUxfVElNRU9VVCBpc3N1ZS4gVGhhbmsgeW91IGZvciB0aGUgZWRpdC4N Cg0KSSBhbHNvIG5vdyB1bmRlcnN0YW5kIHRoYXQgZXNzZW50aWFsbHkgZXZlcnkgY29ubmVjdGlv biB3aWxsIGhhdmUgYSBRLWJsb2NrIGV4Y2hhbmdlIHVzaW5nIENPTi4gQXMgdGhpcyBpcyBhbiBp bnRlZ3JhbCBwYXJ0IG9mIHRoZSBwcm90b2NvbCwgSSBkb24ndCBiZWxpZXZlIGl0J3Mgc3VmZmlj aWVudCBmb3IgU2VjIDcuMSB0byBkZWNsYXJlIGNvbmdlc3Rpb24gY29udHJvbCBwYXJhbWV0ZXJz IG91dCBvZiBzY29wZSwgdW5sZXNzIHRoZXJlJ3MgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIHNv bWUgb3RoZXIgZHJhZnQgdGhhdCBleHBsYWlucyBob3cgdG8gZG8gaXQuDQoNClRoYW5rcw0KTWFy dGluDQoNCk9uIFR1ZSwgTWF5IDQsIDIwMjEgYXQgMjowMSBBTSA8bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0K SGkgTWFydGluLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDog TWFydGluIER1a2UgW21haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTxtYWlsdG86bWFydGlu LmguZHVrZUBnbWFpbC5jb20+XQ0KRW52b3nDqSA6IGx1bmRpIDMgbWFpIDIwMjEgMjA6NTcNCsOA IDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+DQpDYyA6IFRoZSBJRVNHIDxp ZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPj47IGRyYWZ0LWlldGYtY29yZS1uZXct YmxvY2tAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2tAaWV0Zi5vcmc+ OyBjb3JlLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86Y29yZS1jaGFpcnNAaWV0Zi5vcmc+OyBjb3Jl QGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPjsgbWFyY28udGlsb2NhQHJpLnNlPG1haWx0 bzptYXJjby50aWxvY2FAcmkuc2U+DQpPYmpldCA6IFJlOiBNYXJ0aW4gRHVrZSdzIERpc2N1c3Mg b24gZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay0xMTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVO VCkNCg0KDQoNCk9uIEZyaSwgQXByIDMwLCAyMDIxIGF0IDQ6NDggQU0gPG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PiB3cm90 ZToNCj4NCj4gSSBjYW4ndCByZWNvbmNpbGUgKDQuMSkgd2l0aCB0aGUgbGFzdCBzZW50ZW5jZSBp biAoNy4yKS4NCg0KW01lZF0gV2h5PyA0LjEgY2FuIGJlIGRvbmUgd2l0aCBkZWZhdWx0IENvQVAg c2V0dGluZy4gVGhlIHB1cnBvc2Ugb2YgdGhpcyBDT04gcmVxdWVzdCBpcyB0byBkZXRlcm1pbmUg c3VwcG9ydCBvZiB0aGUgZnVuY3Rpb25hbGl0eS4gV2UgbWFkZSB0aGlzIGNoYW5nZToNCg0KT0xE Og0KICAgQ29uZ2VzdGlvbiBjb250cm9sIGZvciBDT04gcmVxdWVzdHMgYW5kIHJlc3BvbnNlcyBp cyBzcGVjaWZpZWQgaW4NCiAgIFNlY3Rpb24gNC43IG9mIFtSRkM3MjUyXS4gIEluIG9yZGVyIHRv IGJlbmVmaXQgZnJvbSBmYXN0ZXINCiAgIHRyYW5zbWlzc2lvbiByYXRlcywgTlNUQVJUIHdpbGwg bmVlZCB0byBiZSBpbmNyZWFzZWQgZnJvbSAxLg0KICAgSG93ZXZlciwgdGhlIG90aGVyIENPTiBj b25nZXN0aW9uIGNvbnRyb2wgcGFyYW1ldGVycyB3aWxsIG5lZWQgdG8gYmUNCiAgIHR1bmVkIHRv IGNvdmVyIHRoaXMgY2hhbmdlLiAgVGhpcyB0dW5pbmcgaXMgbm90IHNwZWNpZmllZCBpbiB0aGlz DQogICBkb2N1bWVudCBnaXZlbiB0aGF0IHRoZSBhcHBsaWNhYmlsaXR5IHNjb3BlIG9mIHRoZSBj dXJyZW50DQogICBzcGVjaWZpY2F0aW9uIGFzc3VtZXMgdGhhdCBhbGwgcmVxdWVzdHMgYW5kIHJl c3BvbnNlcyB1c2luZyBRLUJsb2NrMQ0KICAgYW5kIFEtQmxvY2syIHdpbGwgYmUgTm9uLWNvbmZp cm1hYmxlIChTZWN0aW9uIDMuMikuDQoNCk5FVzoNCiAgIENvbmdlc3Rpb24gY29udHJvbCBmb3Ig Q09OIHJlcXVlc3RzIGFuZCByZXNwb25zZXMgaXMgc3BlY2lmaWVkIGluDQogICBTZWN0aW9uIDQu NyBvZiBbUkZDNzI1Ml0uICBJbiBvcmRlciB0byBiZW5lZml0IGZyb20gZmFzdGVyDQogICB0cmFu c21pc3Npb24gcmF0ZXMsIE5TVEFSVCB3aWxsIG5lZWQgdG8gYmUgaW5jcmVhc2VkIGZyb20gMS4N CiAgIEhvd2V2ZXIsIHRoZSBvdGhlciBDT04gY29uZ2VzdGlvbiBjb250cm9sIHBhcmFtZXRlcnMg d2lsbCBuZWVkIHRvIGJlDQogICB0dW5lZCB0byBjb3ZlciB0aGlzIGNoYW5nZS4gIFRoaXMgdHVu aW5nIGlzIG5vdCBzcGVjaWZpZWQgaW4gdGhpcw0KICAgZG9jdW1lbnQgZ2l2ZW4gdGhhdCB0aGUg YXBwbGljYWJpbGl0eSBzY29wZSBvZiB0aGUgY3VycmVudA0KICAgc3BlY2lmaWNhdGlvbiBhc3N1 bWVzIHRoYXQgYWxsIHJlcXVlc3RzIGFuZCByZXNwb25zZXMgdXNpbmcgUS1CbG9jazENCiAgIGFu ZCBRLUJsb2NrMiB3aWxsIGJlIE5vbi1jb25maXJtYWJsZSAoU2VjdGlvbiAzLjIpIGFwYXJ0IGZy b20gdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBeXl5eXl5eXl5eXl5eXg0KICAgaW5pdGlhbCBRLUJsb2NrIGZ1bmN0aW9uYWxpdHkgbmVn b3RpYXRpb24uDQogICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQoN CkRvZXMgdGhlIGZ1bmN0aW9uYWxpdHkgbmVnb3RpYXRpb24gaW4gKDQuMSkgaW52b2x2ZSBzb21l dGhpbmcgb3RoZXIgdGhhbiBzZW5kaW5nIFEtQmxvY2sgb3B0aW9ucz8NCltNZWRdIE5vLiBBbGwg d2hhdCBpcyBuZWVkZWQgaXMgdG8gc2VuZCB0aGUgb3B0aW9ucyBpbiBhIENPTiBtZXNzYWdlIGFz IHBlcjoNCg0KICAgVG8gaW5kaWNhdGUgc3VwcG9ydCBmb3IgUS1CbG9jazIgcmVzcG9uc2VzLCB0 aGUgQ29BUCBjbGllbnQgTVVTVA0KICAgaW5jbHVkZSB0aGUgUS1CbG9jazIgT3B0aW9uIGluIGEg R0VUIG9yIHNpbWlsYXIgcmVxdWVzdCAoRkVUQ0gsIGZvcg0KICAgZXhhbXBsZSksIHRoZSBRLUJs b2NrMiBPcHRpb24gaW4gYSBQVVQgb3Igc2ltaWxhciByZXF1ZXN0IChQT1NULCBmb3INCiAgIGV4 YW1wbGUpLCBvciB0aGUgUS1CbG9jazEgT3B0aW9uIGluIGEgUFVUIG9yIHNpbWlsYXIgcmVxdWVz dCBzbyB0aGF0DQogICB0aGUgc2VydmVyIGtub3dzIHRoYXQgdGhlIGNsaWVudCBzdXBwb3J0cyB0 aGlzIFEtQmxvY2sgZnVuY3Rpb25hbGl0eQ0KICAgc2hvdWxkIGl0IG5lZWQgdG8gc2VuZCBiYWNr IGEgYm9keSB0aGF0IHNwYW5zIG11bHRpcGxlIHBheWxvYWRzLg0KICAgT3RoZXJ3aXNlLCB0aGUg c2VydmVyIHdvdWxkIHVzZSB0aGUgQmxvY2syIE9wdGlvbiAoaWYgc3VwcG9ydGVkKSB0bw0KICAg c2VuZCBiYWNrIGEgbWVzc2FnZSBib2R5IHRoYXQgaXMgdG9vIGxhcmdlIHRvIGZpdCBpbnRvIGEg c2luZ2xlIElQDQogICBwYWNrZXQgW1JGQzc5NTldLg0KDQpJZiBzbywgdGhlbiAoNC4xKSBvdWdo dCB0byBjbGFyaWZ5IHRoYXQgaXQncyB3aGF0IHlvdSBtZWFuLiBJZiBpdCdzIGp1c3QgYSBHRVQg b3Igd2hhdGV2ZXIsIHRoZW4gdGhlIHRleHQgaGVyZSBpcyBmaW5lLCBidXQgdGhlcmUgbmVlZHMg dG8gYmUgbW9yZSBvbiBjb25nZXN0aW9uIGNvbnRyb2wgZm9yIGNvbmZpcm1hYmxlIG1lc3NhZ2Vz Lg0KDQoNCiBNb3Jlb3ZlciwgaWYNCj4gbXkgcmVhZGluZyBvZiAoNC4xKSBpcyBjb3JyZWN0LCBp dCdzIG5vdCBzdWZmaWNpZW50IHRvIGRlY2xhcmUNCj4gY29uZ2VzdGlvbiBjb250cm9sIGd1aWRh bmNlIG91dCBvZiBzY29wZSB3aGVuIGl0J3MgYSBtYW5kYXRlZCBwYXJ0IG9mDQo+IHRoZSBwcm90 b2NvbC4NCj4NCg0KPg0KPiAtICg3LjIpIElmIE5PTl9QUk9CSU5HX1dBSVQgYW5kIE5PTl9QQVJU SUFMX1RJTUVPVVQgYm90aCAiaGF2ZSB0aGUNCj4gc2FtZSB2YWx1ZSBhcyBjb21wdXRlZCBmb3Ig RVhDSEFOR0VfTElGRVRJTUUiLCB3aHkgYXJlIHRoZXkgZGlmZmVyZW50DQo+IHZhcmlhYmxlcz8N Cg0KW01lZF0gQmVjYXVzZSB0aGV5IHJlZmVyIHRvIGRpc3RpbmN0IGFzcGVjdHMgdGhhdCBtYXkg YmUgdHdlYWtlZCBzZXBhcmF0ZWx5OiB0aGUgdGltZW91dCBpbmR1Y2VkIGJ5IFBST0JJTkdfUkFU RSBhbmQgdGhlIG9uZSB0byBvYnNlcnZlIGZvciBleHBpcmVkIHBhcnRpYWwgYm9kaWVzLg0KDQog T3IgaXMgdGhhdCB0aGV5IFNIT1VMRCBoYXZlIHRoZSBzYW1lIHZhbHVlIGJ1dCBtaWdodCBub3Q/ DQo+IEEgbm9ybWF0aXZlIHdvcmQgd291bGQgYmUgaGVscGZ1bCBoZXJlLg0KDQpbTWVkXSBOb3Qg c3VyZSBhIGNoYW5nZSBpcyBuZWVkZWQgaGVyZSBnaXZlbiB0aGUgZGVmaW5pdGlvbiBvZiB0aGUg dHdvIHBhcmFtZXRlcnMuDQoNCkJ1dCB0aGV5IGNhbid0IGJlIHR3ZWFrZWQgc2VwYXJhdGVseSEg VGhlIHNwZWMgc3RhdGVzIHRoYXQgdGhleSBhcmUgYm90aCBjb21wdXRlZCBhcyBFWENIQU5HRV9M SUZFVElNRS4gSXQgZG9lcyBub3QgYWxsb3cgZm9yIHRoZW0gdG8gYmUgc2V0IHNlcGFyYXRlbHku DQpbTWVkXSBBaCwgSSBzZWUgd2hhdCBjb25mdXNlcyB5b3UuIFdlIG1hZGUgdGhpcyBjaGFuZ2U6 DQoNCk9MRDoNCiAgIE5PTl9QUk9CSU5HX1dBSVQgaXMgdXNlZCB0byBsaW1pdCB0aGUgcG90ZW50 aWFsIHdhaXQgbmVlZGVkDQogICBjYWxjdWxhdGVkIHdoZW4gdXNpbmcgUFJPQklOR19SQVRFLiAg Tk9OX1BST0JJTkdfV0FJVCBoYXMgdGhlIHNhbWUNCiAgIHZhbHVlIGFzIGNvbXB1dGVkIGZvciBF WENIQU5HRV9MSUZFVElNRSAoU2VjdGlvbiA0LjguMiBvZiBbUkZDNzI1Ml0pLg0KDQogICBOT05f UEFSVElBTF9USU1FT1VUIGlzIHVzZWQgZm9yIGV4cGlyaW5nIHBhcnRpYWxseSByZWNlaXZlZCBi b2RpZXMuDQogICBOT05fUEFSVElBTF9USU1FT1VUIGhhcyB0aGUgc2FtZSB2YWx1ZSBhcyBjb21w dXRlZCBmb3INCiAgIEVYQ0hBTkdFX0xJRkVUSU1FIChTZWN0aW9uIDQuOC4yIG9mIFtSRkM3MjUy XSkuDQoNCk5FVzoNCg0KICAgTk9OX1BST0JJTkdfV0FJVCBpcyB1c2VkIHRvIGxpbWl0IHRoZSBw b3RlbnRpYWwgd2FpdCBuZWVkZWQNCg0KICAgY2FsY3VsYXRlZCB3aGVuIHVzaW5nIFBST0JJTkdf UkFURS4gIEJ5IGRlZmF1bHQsIE5PTl9QUk9CSU5HX1dBSVQgaGFzDQoNCiAgIHRoZSBzYW1lIHZh bHVlIGFzIEVYQ0hBTkdFX0xJRkVUSU1FIChTZWN0aW9uIDQuOC4yIG9mIFtSRkM3MjUyXSkuDQoN Cg0KDQogICBOT05fUEFSVElBTF9USU1FT1VUIGlzIHVzZWQgZm9yIGV4cGlyaW5nIHBhcnRpYWxs eSByZWNlaXZlZCBib2RpZXMuDQoNCiAgIEJ5IGRlZmF1bHQsIE5PTl9QQVJUSUFMX1RJTUVPVVQg aGFzIHRoZSBzYW1lIHZhbHVlIGFzDQoNCiAgIEVYQ0hBTkdFX0xJRkVUSU1FIChTZWN0aW9uIDQu OC4yIG9mIFtSRkM3MjUyXSkuDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVz IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4 cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNl IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFs dGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBt b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_787AE7BB302AE849A7480A190F8B93303537688COPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBI VE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uUHJmb3JtYXRI VE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0K CWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0 IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+UmUtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGFyZSBu b3Qgc2Vla2luZyBmb3IgcGVyZm9ybWFuY2UgZW5oYW5jZW1lbnQgd2hlbiBkZXRlcm1pbmluZyBR LUJsb2NrIHN1cHBvcnQuIFRoaXMgd2h5IEkgaW5kaWNhdGVkIGluIG15IGZpcnN0IHJlcGx5IHRo YXQgbm8gY2hhbmdlIHRvIHRoZSBiYXNlIENDIGlzIG5lZWRlZCBmb3IgdGhhdC4NCiBXZSB1cGRh dGVkIHRoZSB0ZXh0IGFzIGZvbGxvd3M6IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9M RDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IFdpdGggQ29BUCBvdmVyIFVEUCwgdGhlIHdheSBhIHJlcXVlc3QgbWVzc2Fn ZSBpcyByZWplY3RlZCBmb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGNyaXRpY2FsIG9wdGlvbnMgZGVwZW5kcyBvbiB0 aGUgbWVzc2FnZSB0eXBlLiZuYnNwOyBBIENvbmZpcm1hYmxlIG1lc3NhZ2U8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHdp dGggYW4gdW5yZWNvZ25pemVkIGNyaXRpY2FsIG9wdGlvbiBpcyByZWplY3RlZCB3aXRoIGEgNC4w MiAoQmFkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBPcHRpb24pIHJlc3BvbnNlIChTZWN0aW9uIDUuNC4xIG9mIFtSRkM3 MjUyXSkuJm5ic3A7IEEgTm9uLWNvbmZpcm1hYmxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBtZXNzYWdlIHdpdGggYW4g dW5yZWNvZ25pemVkIGNyaXRpY2FsIG9wdGlvbiBpcyBlaXRoZXIgcmVqZWN0ZWQgd2l0aDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgYSBSZXNldCBtZXNzYWdlIG9yIGp1c3Qgc2lsZW50bHkgaWdub3JlZCAoU2VjdGlvbnMg NS40LjEgYW5kIDQuMyBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgW1JGQzcyNTJdKS4mbmJzcDsgVG8gcmVsaWFibHkg Z2V0IGEgcmVqZWN0aW9uIG1lc3NhZ2UsIGl0IGlzIHRoZXJlZm9yZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgUkVRVUlS RUQgdGhhdCBjbGllbnRzIHVzZSBhIENvbmZpcm1hYmxlIG1lc3NhZ2UgZm9yIGRldGVybWluaW5n PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBzdXBwb3J0IGZvciBRLUJsb2NrMSBhbmQgUS1CbG9jazIgT3B0aW9ucy4mbmJz cDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5FVzo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFdpdGggQ29B UCBvdmVyIFVEUCwgdGhlIHdheSBhIHJlcXVlc3QgbWVzc2FnZSBpcyByZWplY3RlZCBmb3I8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IGNyaXRpY2FsIG9wdGlvbnMgZGVwZW5kcyBvbiB0aGUgbWVzc2FnZSB0eXBlLiZuYnNw OyBBIENvbmZpcm1hYmxlIG1lc3NhZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHdpdGggYW4gdW5yZWNvZ25pemVkIGNy aXRpY2FsIG9wdGlvbiBpcyByZWplY3RlZCB3aXRoIGEgNC4wMiAoQmFkPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBPcHRp b24pIHJlc3BvbnNlIChTZWN0aW9uIDUuNC4xIG9mIFtSRkM3MjUyXSkuJm5ic3A7IEEgTm9uLWNv bmZpcm1hYmxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyBtZXNzYWdlIHdpdGggYW4gdW5yZWNvZ25pemVkIGNyaXRpY2Fs IG9wdGlvbiBpcyBlaXRoZXIgcmVqZWN0ZWQgd2l0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYSBSZXNldCBtZXNzYWdl IG9yIGp1c3Qgc2lsZW50bHkgaWdub3JlZCAoU2VjdGlvbnMgNS40LjEgYW5kIDQuMyBvZjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgW1JGQzcyNTJdKS4mbmJzcDsgVG8gcmVsaWFibHkgZ2V0IGEgcmVqZWN0aW9uIG1lc3Nh Z2UsIGl0IGlzIHRoZXJlZm9yZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgUkVRVUlSRUQgdGhhdCBjbGllbnRzIHVzZSBh IENvbmZpcm1hYmxlIG1lc3NhZ2UgZm9yIGRldGVybWluaW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBzdXBwb3J0IGZv ciBRLUJsb2NrMSBhbmQgUS1CbG9jazIgT3B0aW9ucy4mbmJzcDsNCjxzcGFuIHN0eWxlPSJjb2xv cjpyZWQiPlRoaXMgQ09OIG1lc3NhZ2UgY2FuIGJlPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7 IHNlbnQgdW5kZXIgYmFzZSBDb0FQIGNvbmdlc3Rpb24gY29udHJvbCBzZXR1cCBzcGVjaWZpZWQg aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpyZWQiPiZuYnNwOyZuYnNwOyBTZWN0aW9uIDQuNyBvZiBbUkZDNzI1Ml0gKHRoYXQgaXMs IE5TVEFSVCBkb2VzIG5vdCBuZWVkIHRvIGJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsmbmJzcDsgaW5jcmVhc2Vk KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBN YXJ0aW4gRHVrZSBbbWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21haWwuY29tXQ0KPGJyPg0KPGI+RW52 b3nDqSZuYnNwOzo8L2I+IG1hcmRpIDQgbWFpIDIwMjEgMTc6Mjg8YnI+DQo8Yj7DgCZuYnNwOzo8 L2I+IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gJmx0O21vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20mZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9y ZyZndDs7IGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2tAaWV0Zi5vcmc7IGNvcmUtY2hhaXJzQGll dGYub3JnOyBjb3JlQGlldGYub3JnOyBtYXJjby50aWxvY2FAcmkuc2U8YnI+DQo8Yj5PYmpldCZu YnNwOzo8L2I+IFJlOiBNYXJ0aW4gRHVrZSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1jb3JlLW5l dy1ibG9jay0xMTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9LLCB3ZSd2ZSByZWFj aGVkIHVuZGVyc3RhbmRpbmcgb24gdGhlIE5PTl9QUk9CSU5HX1dBSVQvTk9OX1BBUlRJQUxfVElN RU9VVCBpc3N1ZS4gVGhhbmsgeW91IGZvciB0aGUgZWRpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbHNvIG5vdyB1bmRlcnN0YW5kIHRo YXQgZXNzZW50aWFsbHkgZXZlcnkgY29ubmVjdGlvbiB3aWxsIGhhdmUgYSBRLWJsb2NrIGV4Y2hh bmdlIHVzaW5nIENPTi4gQXMgdGhpcyBpcyBhbiBpbnRlZ3JhbCBwYXJ0IG9mIHRoZSBwcm90b2Nv bCwgSSBkb24ndCBiZWxpZXZlIGl0J3Mgc3VmZmljaWVudCBmb3IgU2VjIDcuMSB0byBkZWNsYXJl IGNvbmdlc3Rpb24gY29udHJvbCBwYXJhbWV0ZXJzIG91dCBvZiBzY29wZSwNCiB1bmxlc3MgdGhl cmUncyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gc29tZSBvdGhlciBkcmFmdCB0aGF0IGV4cGxh aW5zIGhvdyB0byBkbyBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5NYXJ0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBNYXkgNCwgMjAyMSBhdCAyOjAxIEFNICZsdDs8 YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpIE1hcnRpbiwNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj5QbGVhc2Ugc2VlIGlubGluZS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij5DaGVlcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj5NZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdp bmRvd3RleHQgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdDtib3JkZXItY29sb3I6Y3Vy cmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgYmx1ZSI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY207Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29s b3IiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNYXJ0aW4g RHVrZQ0KIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bWFydGluLmguZHVrZUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+RW52 b3nDqSZuYnNwOzo8L2I+IGx1bmRpIDMgbWFpIDIwMjEgMjA6NTc8YnI+DQo8Yj7DgCZuYnNwOzo8 L2I+IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBUaGUgSUVTRyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZXNnQGlldGYub3Jn PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2tAaWV0Zi5vcmc8 L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmNvcmUtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+Y29yZS1jaGFpcnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPg0KY29yZUBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpt YXJjby50aWxvY2FAcmkuc2UiIHRhcmdldD0iX2JsYW5rIj5tYXJjby50aWxvY2FAcmkuc2U8L2E+ PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogTWFydGluIER1a2UncyBEaXNjdXNzIG9uIGRy YWZ0LWlldGYtY29yZS1uZXctYmxvY2stMTE6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gRnJpLCBBcHIgMzAsIDIwMjEgYXQgNDo0OCBBTSAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0 ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVy LWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsMjA0 LDIwNCkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7DQo8YnI+DQomZ3Q7IEkgY2FuJ3Qg cmVjb25jaWxlICg0LjEpIHdpdGggdGhlIGxhc3Qgc2VudGVuY2UgaW4gKDcuMikuPGJyPg0KPGJy Pg0KW01lZF0gV2h5PyA0LjEgY2FuIGJlIGRvbmUgd2l0aCBkZWZhdWx0IENvQVAgc2V0dGluZy4g VGhlIHB1cnBvc2Ugb2YgdGhpcyBDT04gcmVxdWVzdCBpcyB0byBkZXRlcm1pbmUgc3VwcG9ydCBv ZiB0aGUgZnVuY3Rpb25hbGl0eS4gV2UgbWFkZSB0aGlzIGNoYW5nZTo8YnI+DQo8YnI+DQpPTEQ6 PGJyPg0KJm5ic3A7ICZuYnNwO0Nvbmdlc3Rpb24gY29udHJvbCBmb3IgQ09OIHJlcXVlc3RzIGFu ZCByZXNwb25zZXMgaXMgc3BlY2lmaWVkIGluPGJyPg0KJm5ic3A7ICZuYnNwO1NlY3Rpb24gNC43 IG9mIFtSRkM3MjUyXS4mbmJzcDsgSW4gb3JkZXIgdG8gYmVuZWZpdCBmcm9tIGZhc3Rlcjxicj4N CiZuYnNwOyAmbmJzcDt0cmFuc21pc3Npb24gcmF0ZXMsIE5TVEFSVCB3aWxsIG5lZWQgdG8gYmUg aW5jcmVhc2VkIGZyb20gMS48YnI+DQombmJzcDsgJm5ic3A7SG93ZXZlciwgdGhlIG90aGVyIENP TiBjb25nZXN0aW9uIGNvbnRyb2wgcGFyYW1ldGVycyB3aWxsIG5lZWQgdG8gYmU8YnI+DQombmJz cDsgJm5ic3A7dHVuZWQgdG8gY292ZXIgdGhpcyBjaGFuZ2UuJm5ic3A7IFRoaXMgdHVuaW5nIGlz IG5vdCBzcGVjaWZpZWQgaW4gdGhpczxicj4NCiZuYnNwOyAmbmJzcDtkb2N1bWVudCBnaXZlbiB0 aGF0IHRoZSBhcHBsaWNhYmlsaXR5IHNjb3BlIG9mIHRoZSBjdXJyZW50PGJyPg0KJm5ic3A7ICZu YnNwO3NwZWNpZmljYXRpb24gYXNzdW1lcyB0aGF0IGFsbCByZXF1ZXN0cyBhbmQgcmVzcG9uc2Vz IHVzaW5nIFEtQmxvY2sxPGJyPg0KJm5ic3A7ICZuYnNwO2FuZCBRLUJsb2NrMiB3aWxsIGJlIE5v bi1jb25maXJtYWJsZSAoU2VjdGlvbiAzLjIpLjxicj4NCjxicj4NCk5FVzombmJzcDsgPGJyPg0K Jm5ic3A7ICZuYnNwO0Nvbmdlc3Rpb24gY29udHJvbCBmb3IgQ09OIHJlcXVlc3RzIGFuZCByZXNw b25zZXMgaXMgc3BlY2lmaWVkIGluPGJyPg0KJm5ic3A7ICZuYnNwO1NlY3Rpb24gNC43IG9mIFtS RkM3MjUyXS4mbmJzcDsgSW4gb3JkZXIgdG8gYmVuZWZpdCBmcm9tIGZhc3Rlcjxicj4NCiZuYnNw OyAmbmJzcDt0cmFuc21pc3Npb24gcmF0ZXMsIE5TVEFSVCB3aWxsIG5lZWQgdG8gYmUgaW5jcmVh c2VkIGZyb20gMS48YnI+DQombmJzcDsgJm5ic3A7SG93ZXZlciwgdGhlIG90aGVyIENPTiBjb25n ZXN0aW9uIGNvbnRyb2wgcGFyYW1ldGVycyB3aWxsIG5lZWQgdG8gYmU8YnI+DQombmJzcDsgJm5i c3A7dHVuZWQgdG8gY292ZXIgdGhpcyBjaGFuZ2UuJm5ic3A7IFRoaXMgdHVuaW5nIGlzIG5vdCBz cGVjaWZpZWQgaW4gdGhpczxicj4NCiZuYnNwOyAmbmJzcDtkb2N1bWVudCBnaXZlbiB0aGF0IHRo ZSBhcHBsaWNhYmlsaXR5IHNjb3BlIG9mIHRoZSBjdXJyZW50PGJyPg0KJm5ic3A7ICZuYnNwO3Nw ZWNpZmljYXRpb24gYXNzdW1lcyB0aGF0IGFsbCByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIHVzaW5n IFEtQmxvY2sxPGJyPg0KJm5ic3A7ICZuYnNwO2FuZCBRLUJsb2NrMiB3aWxsIGJlIE5vbi1jb25m aXJtYWJsZSAoU2VjdGlvbiAzLjIpIGFwYXJ0IGZyb20gdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgXl5eXl5eXl5eXl5eXl4mbmJzcDsgPGJyPg0KJm5ic3A7ICZuYnNwO2luaXRpYWwgUS1CbG9j ayBmdW5jdGlvbmFsaXR5IG5lZ290aWF0aW9uLjxicj4NCiZuYnNwOyAmbmJzcDteXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5ePG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RG9lcyB0aGUgZnVuY3Rpb25h bGl0eSBuZWdvdGlhdGlvbiBpbiAoNC4xKSBpbnZvbHZlIHNvbWV0aGluZyBvdGhlciB0aGFuIHNl bmRpbmcgUS1CbG9jayBvcHRpb25zPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5bTWVkXSBOby4gQWxsIHdoYXQgaXMg bmVlZGVkIGlzIHRvIHNlbmQgdGhlIG9wdGlvbnMgaW4gYSBDT04gbWVzc2FnZSBhcyBwZXI6ICZu YnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyBUbyBpbmRpY2F0ZSBzdXBwb3J0IGZvciBRLUJsb2NrMiByZXNwb25zZXMsIHRoZSBDb0FQIGNs aWVudCBNVVNUPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGluY2x1ZGUgdGhlIFEtQmxvY2syIE9wdGlvbiBpbiBhIEdF VCBvciBzaW1pbGFyIHJlcXVlc3QgKEZFVENILCBmb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZXhhbXBsZSksIHRo ZSBRLUJsb2NrMiBPcHRpb24gaW4gYSBQVVQgb3Igc2ltaWxhciByZXF1ZXN0IChQT1NULCBmb3I8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgZXhhbXBsZSksIG9yIHRoZSBRLUJsb2NrMSBPcHRpb24gaW4gYSBQVVQgb3Ig c2ltaWxhciByZXF1ZXN0IHNvIHRoYXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhlIHNlcnZlciBrbm93cyB0aGF0 IHRoZSBjbGllbnQgc3VwcG9ydHMgdGhpcyBRLUJsb2NrIGZ1bmN0aW9uYWxpdHk8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgc2hvdWxkIGl0IG5lZWQgdG8gc2VuZCBiYWNrIGEgYm9keSB0aGF0IHNwYW5zIG11bHRpcGxl IHBheWxvYWRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBPdGhlcndpc2UsIHRoZSBzZXJ2ZXIgd291bGQgdXNlIHRo ZSBCbG9jazIgT3B0aW9uIChpZiBzdXBwb3J0ZWQpIHRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHNlbmQgYmFjayBh IG1lc3NhZ2UgYm9keSB0aGF0IGlzIHRvbyBsYXJnZSB0byBmaXQgaW50byBhIHNpbmdsZSBJUDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBwYWNrZXQgW1JGQzc5NTldLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHNv LCB0aGVuICg0LjEpIG91Z2h0IHRvIGNsYXJpZnkgdGhhdCBpdCdzIHdoYXQgeW91IG1lYW4uIElm IGl0J3MganVzdCBhIEdFVCBvciB3aGF0ZXZlciwgdGhlbiB0aGUgdGV4dCBoZXJlIGlzIGZpbmUs IGJ1dCB0aGVyZSBuZWVkcyB0byBiZSBtb3JlIG9uIGNvbmdlc3Rpb24gY29udHJvbCBmb3IgY29u ZmlybWFibGUNCiBtZXNzYWdlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1 cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsMjA0LDIwNCkiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQombmJzcDtNb3Jlb3ZlciwgaWY8YnI+DQomZ3Q7 IG15IHJlYWRpbmcgb2YgKDQuMSkgaXMgY29ycmVjdCwgaXQncyBub3Qgc3VmZmljaWVudCB0byBk ZWNsYXJlPGJyPg0KJmd0OyBjb25nZXN0aW9uIGNvbnRyb2wgZ3VpZGFuY2Ugb3V0IG9mIHNjb3Bl IHdoZW4gaXQncyBhIG1hbmRhdGVkIHBhcnQgb2Y8YnI+DQomZ3Q7IHRoZSBwcm90b2NvbC48YnI+ DQomZ3Q7IDxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyAtICg3LjIpIElmIE5PTl9QUk9CSU5H X1dBSVQgYW5kIE5PTl9QQVJUSUFMX1RJTUVPVVQgYm90aCAmcXVvdDtoYXZlIHRoZTxicj4NCiZn dDsgc2FtZSB2YWx1ZSBhcyBjb21wdXRlZCBmb3IgRVhDSEFOR0VfTElGRVRJTUUmcXVvdDssIHdo eSBhcmUgdGhleSBkaWZmZXJlbnQ8YnI+DQomZ3Q7IHZhcmlhYmxlcz88YnI+DQo8YnI+DQpbTWVk XSBCZWNhdXNlIHRoZXkgcmVmZXIgdG8gZGlzdGluY3QgYXNwZWN0cyB0aGF0IG1heSBiZSB0d2Vh a2VkIHNlcGFyYXRlbHk6IHRoZSB0aW1lb3V0IGluZHVjZWQgYnkgUFJPQklOR19SQVRFIGFuZCB0 aGUgb25lIHRvIG9ic2VydmUgZm9yIGV4cGlyZWQgcGFydGlhbCBib2RpZXMuDQo8YnI+DQo8YnI+ DQombmJzcDtPciBpcyB0aGF0IHRoZXkgU0hPVUxEIGhhdmUgdGhlIHNhbWUgdmFsdWUgYnV0IG1p Z2h0IG5vdD88YnI+DQomZ3Q7IEEgbm9ybWF0aXZlIHdvcmQgd291bGQgYmUgaGVscGZ1bCBoZXJl Ljxicj4NCjxicj4NCltNZWRdIE5vdCBzdXJlIGEgY2hhbmdlIGlzIG5lZWRlZCBoZXJlIGdpdmVu IHRoZSBkZWZpbml0aW9uIG9mIHRoZSB0d28gcGFyYW1ldGVycy48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CdXQgdGhleSBj YW4ndCBiZSB0d2Vha2VkIHNlcGFyYXRlbHkhIFRoZSBzcGVjIHN0YXRlcyB0aGF0IHRoZXkgYXJl IGJvdGggY29tcHV0ZWQgYXMgRVhDSEFOR0VfTElGRVRJTUUuIEl0IGRvZXMgbm90IGFsbG93IGZv ciB0aGVtIHRvIGJlIHNldCBzZXBhcmF0ZWx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5bTWVkXSBBaCwgSSBzZWUg d2hhdCBjb25mdXNlcyB5b3UuIFdlIG1hZGUgdGhpcyBjaGFuZ2U6PC9zcGFuPjwvaT48L2I+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5PTEQ6PC9zcGFuPjwv aT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgTk9OX1BST0JJTkdfV0FJVCBpcyB1c2VkIHRvIGxpbWl0IHRoZSBwb3RlbnRp YWwgd2FpdCBuZWVkZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgY2FsY3VsYXRlZCB3aGVuIHVzaW5nIFBST0JJTkdf UkFURS4mbmJzcDsgTk9OX1BST0JJTkdfV0FJVCBoYXMgdGhlIHNhbWU8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdmFs dWUgYXMgY29tcHV0ZWQgZm9yIEVYQ0hBTkdFX0xJRkVUSU1FIChTZWN0aW9uIDQuOC4yIG9mIFtS RkM3MjUyXSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IE5PTl9QQVJUSUFMX1RJTUVPVVQgaXMgdXNlZCBm b3IgZXhwaXJpbmcgcGFydGlhbGx5IHJlY2VpdmVkIGJvZGllcy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgTk9OX1BB UlRJQUxfVElNRU9VVCBoYXMgdGhlIHNhbWUgdmFsdWUgYXMgY29tcHV0ZWQgZm9yPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IEVYQ0hBTkdFX0xJRkVUSU1FIChTZWN0aW9uIDQuOC4yIG9mIFtSRkM3MjUyXSkuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TkVXOjwvc3Bh bj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4mbmJzcDsmbmJz cDsgTk9OX1BST0JJTkdfV0FJVCBpcyB1c2VkIHRvIGxpbWl0IHRoZSBwb3RlbnRpYWwgd2FpdCBu ZWVkZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY2FsY3VsYXRlZCB3aGVu IHVzaW5nIFBST0JJTkdfUkFURS4mbmJzcDsgPHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+QnkgZGVm YXVsdCwgPC9zcGFuPk5PTl9QUk9CSU5HX1dBSVQgaGFzPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IHRoZSBzYW1lIHZhbHVlIGFzIEVYQ0hBTkdFX0xJRkVUSU1FIChTZWN0aW9u IDQuOC4yIG9mIFtSRkM3MjUyXSkuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IE5PTl9QQVJUSUFMX1RJTUVPVVQgaXMgdXNl ZCBmb3IgZXhwaXJpbmcgcGFydGlhbGx5IHJlY2VpdmVkIGJvZGllcy48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgPHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+QnkgZGVmYXVsdCwg PC9zcGFuPk5PTl9QQVJUSUFMX1RJTUVPVVQgaGFzIHRoZSBzYW1lIHZhbHVlIGFzPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEVYQ0hBTkdFX0xJRkVUSU1FIChTZWN0aW9uIDQu OC4yIG9mIFtSRkM3MjUyXSkuPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDoyMi4wNXB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5 Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93303537688COPEXCAUBMA2corp_-- From nobody Tue May 4 09:58: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 977813A126B; Tue, 4 May 2021 09:58:30 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 qOY-hC6j34OM; Tue, 4 May 2021 09:58:25 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 123F33A126A; Tue, 4 May 2021 09:58:24 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id t3so2532670iol.5; Tue, 04 May 2021 09:58:24 -0700 (PDT) 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=CFBn143OkCBEAuARM/+DI3F37/2X9wez91waM0csUeE=; b=WIBE1ox2zCSDU62o81b21lomPUSioiCW1VdazXVQAdQjBoE2EACwqAaSiPSL3/TEJd NZbiArwH2umz9bfiCkZaf4hdmzuOZvu4SDASSdCH0m6UXIF976WsCXQFR9B8tdvUH1ee eYOhsZoKz8x9UXvL+/Ei2xKl1WiQRmTv/D8TAVENuVQsocUUkdLEcOy5I2iP4VDKPwhe mV9vhvN+MqhKcULBZmK2QotDojuJ08lFQwqiYbljquShddx/DlY1Jjcd/i1z4GhSImHX ydRqUlsta0eKdNTkhCMygvcwovuRcmwtI8Js1ak3qMce/yM9fM8NzTzz4QSs5OgnDsoh kfvw== 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=CFBn143OkCBEAuARM/+DI3F37/2X9wez91waM0csUeE=; b=A/rzt6NTfaorZJ9i2YNUbtJPk/Jz7N3PGQCU/tNEivxy2ostio3h/YmlvpvpQVXZlV iMxPXAerdkekJcagskuyqvmQTDGnGzqFLf16IDJAyAExjAS1URl7uU7Y9CK/3p8K5FNK 1xkigu0yt73ygk8sST1zilurcbzkKuK/DCP5kBHPKSSm6UElbxz4UP4niaChEkxA9eUP PVdTbkYPgeT7JXSz31Oth7s34RrtusvWgc/M3o8k80DMD3SwhsrJx9mwxJaGKLXNb12N 8A+mfUKJN8SPFMs62T0TTJHTsHPAR0q+1mvr0g/UfJvxyjv76K8LcIsUErnuMnJODiTi NnVg== X-Gm-Message-State: AOAM530GmlrQ6FHwr79CH3agYWy3ksE3kIN6qZCgFu0177utrz/hJ+Fq 1EnekK0QZRfr08rpxF2FFi1nQ9tLcmMuW0ME878= X-Google-Smtp-Source: ABdhPJw1UPGGHEZxD30pTbDJ97pq1IbE9UZ77JZQdg0QhOvypFP8evSAc80VAcJKQ/6yFOrSrOkq5/TGae3zryrs8P0= X-Received: by 2002:a5d:8ad2:: with SMTP id e18mr19614914iot.51.1620147503725; Tue, 04 May 2021 09:58:23 -0700 (PDT) MIME-Version: 1.0 References: <161973861706.19975.3092798532288165336@ietfa.amsl.com> <9640_1619783334_608BEEA5_9640_342_16_787AE7BB302AE849A7480A190F8B9330353751A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <21895_1620118865_60910D51_21895_367_1_787AE7BB302AE849A7480A190F8B9330353764A2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <18827_1620145989_60917745_18827_231_1_787AE7BB302AE849A7480A190F8B93303537688C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <18827_1620145989_60917745_18827_231_1_787AE7BB302AE849A7480A190F8B93303537688C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Martin Duke Date: Tue, 4 May 2021 09:58:14 -0700 Message-ID: To: mohamed.boucadair@orange.com Cc: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Content-Type: multipart/alternative; boundary="0000000000007181c605c183fccc" Archived-At: Subject: Re: [core] Martin Duke's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 16:58:31 -0000 --0000000000007181c605c183fccc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Wonderful, that is satisfactory. I will lift my discuss when the changes land. On Tue, May 4, 2021 at 9:33 AM wrote: > Re-, > > > > We are not seeking for performance enhancement when determining Q-Block > support. This why I indicated in my first reply that no change to the bas= e > CC is needed for that. We updated the text as follows: > > > > OLD: > > With CoAP over UDP, the way a request message is rejected for > > critical options depends on the message type. A Confirmable message > > with an unrecognized critical option is rejected with a 4.02 (Bad > > Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable > > message with an unrecognized critical option is either rejected with > > a Reset message or just silently ignored (Sections 5.4.1 and 4.3 of > > [RFC7252]). To reliably get a rejection message, it is therefore > > REQUIRED that clients use a Confirmable message for determining > > support for Q-Block1 and Q-Block2 Options. > > > > NEW: > > With CoAP over UDP, the way a request message is rejected for > > critical options depends on the message type. A Confirmable message > > with an unrecognized critical option is rejected with a 4.02 (Bad > > Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable > > message with an unrecognized critical option is either rejected with > > a Reset message or just silently ignored (Sections 5.4.1 and 4.3 of > > [RFC7252]). To reliably get a rejection message, it is therefore > > REQUIRED that clients use a Confirmable message for determining > > support for Q-Block1 and Q-Block2 Options. This CON message can be > > sent under base CoAP congestion control setup specified in > > Section 4.7 of [RFC7252] (that is, NSTART does not need to be > > increased). > > > > Cheers, > > Med > > > > *De :* Martin Duke [mailto:martin.h.duke@gmail.com] > *Envoy=C3=A9 :* mardi 4 mai 2021 17:28 > *=C3=80 :* BOUCADAIR Mohamed TGI/OLN > *Cc :* The IESG ; draft-ietf-core-new-block@ietf.org; > core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se > *Objet :* Re: Martin Duke's Discuss on draft-ietf-core-new-block-11: > (with DISCUSS and COMMENT) > > > > OK, we've reached understanding on the > NON_PROBING_WAIT/NON_PARTIAL_TIMEOUT issue. Thank you for the edit. > > > > I also now understand that essentially every connection will have a > Q-block exchange using CON. As this is an integral part of the protocol, = I > don't believe it's sufficient for Sec 7.1 to declare congestion control > parameters out of scope, unless there's a normative reference to some oth= er > draft that explains how to do it. > > > > Thanks > > Martin > > > > On Tue, May 4, 2021 at 2:01 AM wrote: > > Hi Martin, > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :* Martin Duke [mailto:martin.h.duke@gmail.com] > *Envoy=C3=A9 :* lundi 3 mai 2021 20:57 > *=C3=80 :* BOUCADAIR Mohamed TGI/OLN > *Cc :* The IESG ; draft-ietf-core-new-block@ietf.org; > core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se > *Objet :* Re: Martin Duke's Discuss on draft-ietf-core-new-block-11: > (with DISCUSS and COMMENT) > > > > > > > > On Fri, Apr 30, 2021 at 4:48 AM wrote: > > > > > I can't reconcile (4.1) with the last sentence in (7.2). > > [Med] Why? 4.1 can be done with default CoAP setting. The purpose of this > CON request is to determine support of the functionality. We made this > change: > > OLD: > Congestion control for CON requests and responses is specified in > Section 4.7 of [RFC7252]. In order to benefit from 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 not specified in this > document given that the applicability scope of the current > specification assumes that all requests and responses using Q-Block1 > and Q-Block2 will be Non-confirmable (Section 3.2). > > NEW: > Congestion control for CON requests and responses is specified in > Section 4.7 of [RFC7252]. In order to benefit from 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 not specified in this > document given that the applicability scope of the current > specification assumes that all requests and responses using Q-Block1 > and Q-Block2 will be Non-confirmable (Section 3.2) apart from the > ^^^^^^^^^^^^^^ > initial Q-Block functionality negotiation. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Does the functionality negotiation in (4.1) involve something other than > sending Q-Block options? > > *[Med] No. All what is needed is to send the options in a CON message as > per: * > > > > To indicate support for Q-Block2 responses, the CoAP client MUST > > include the Q-Block2 Option in a GET or similar request (FETCH, for > > example), the Q-Block2 Option in a PUT or similar request (POST, for > > example), or the Q-Block1 Option in a PUT or similar request so that > > the server knows that the client supports this Q-Block functionality > > should it need to send back a body that spans multiple payloads. > > Otherwise, the server would use the Block2 Option (if supported) to > > send back a message body that is too large to fit into a single IP > > packet [RFC7959]. > > > > If so, then (4.1) ought to clarify that it's what you mean. If it's just = a > GET or whatever, then the text here is fine, but there needs to be more o= n > congestion control for confirmable messages. > > > > > Moreover, if > > my reading of (4.1) is correct, it's not sufficient to declare > > congestion control guidance out of scope when it's a mandated part of > > the protocol. > > > > > > > - (7.2) If NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT both "have the > > same value as computed for EXCHANGE_LIFETIME", why are they different > > variables? > > [Med] Because they refer to distinct aspects that may be tweaked > separately: the timeout induced by PROBING_RATE and the one to observe fo= r > expired partial bodies. > > Or is that they SHOULD have the same value but might not? > > A normative word would be helpful here. > > [Med] Not sure a change is needed here given the definition of the two > parameters. > > > > But they can't be tweaked separately! The spec states that they are both > computed as EXCHANGE_LIFETIME. It does not allow for them to be set > separately. > > *[Med] Ah, I see what confuses you. We made this change:* > > > > *OLD:* > > NON_PROBING_WAIT is used to limit the potential wait needed > > calculated when using PROBING_RATE. NON_PROBING_WAIT has the same > > value as computed for EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). > > > > NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. > > NON_PARTIAL_TIMEOUT has the same value as computed for > > EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). > > > > *NEW:* > > NON_PROBING_WAIT is used to limit the potential wait needed > > calculated when using PROBING_RATE. By default, NON_PROBING_WAIT has > > the same value as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). > > > > NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. > > By default, NON_PARTIAL_TIMEOUT has the same value as > > EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --0000000000007181c605c183fccc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wonderful, that is satisfactory. I will lift my discuss wh= en the changes land.

On Tue, May 4, 2021 at 9:33 AM <mohamed.boucadair@orange.com> wrote:=

Re-,

=C2=A0

We are not seeking for performance enha= ncement when determining Q-Block support. This why I indicated in my first = reply that no change to the base CC is needed for that. We updated the text as follows:

=C2=A0

OLD:

=C2=A0=C2=A0 With CoAP over UDP, the way a request message i= s rejected for

=C2=A0=C2=A0 critical options depends on the message type.= =C2=A0 A Confirmable message

=C2=A0=C2=A0 with an unrecognized critical option is rejecte= d with a 4.02 (Bad

=C2=A0=C2=A0 Option) response (Section 5.4.1 of [RFC7252]).= =C2=A0 A Non-confirmable

=C2=A0=C2=A0 message with an unrecognized critical option is= either rejected with

=C2=A0=C2=A0 a Reset message or just silently ignored (Secti= ons 5.4.1 and 4.3 of

=C2=A0=C2=A0 [RFC7252]).=C2=A0 To reliably get a rejection m= essage, it is therefore

=C2=A0=C2=A0 REQUIRED that clients use a Confirmable message= for determining

=C2=A0=C2=A0 support for Q-Block1 and Q-Block2 Options.=C2= =A0

=C2=A0

NEW:

=C2=A0=C2=A0 With CoAP over UDP, the way a request message i= s rejected for

=C2=A0=C2=A0 critical options depends on the message type.= =C2=A0 A Confirmable message

=C2=A0=C2=A0 with an unrecognized critical option is rejecte= d with a 4.02 (Bad

=C2=A0=C2=A0 Option) response (Section 5.4.1 of [RFC7252]).= =C2=A0 A Non-confirmable

=C2=A0=C2=A0 message with an unrecognized critical option is= either rejected with

=C2=A0=C2=A0 a Reset message or just silently ignored (Secti= ons 5.4.1 and 4.3 of

=C2=A0=C2=A0 [RFC7252]).=C2=A0 To reliably get a rejection m= essage, it is therefore

=C2=A0=C2=A0 REQUIRED that clients use a Confirmable message= for determining

=C2=A0=C2=A0 support for Q-Block1 and Q-Block2 Options.=C2= =A0 This CON message can be

=C2=A0=C2=A0 sent under base CoAP congestion contr= ol setup specified in

=C2=A0=C2=A0 Section 4.7 of [RFC7252] (that is, NS= TART does not need to be

=C2=A0=C2=A0 increased).

=C2=A0

Cheers,

Med

=C2=A0=

De=C2=A0: Martin= Duke [mailto:= martin.h.duke@gmail.com]
Envoy=C3=A9=C2=A0: mardi 4 mai 2021 17:28
=C3=80=C2=A0: BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com&= gt;
Cc=C2=A0: The IESG <iesg@ietf.org>; draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org= ; core@ietf.org; marco.tiloca@ri.se=
Objet=C2=A0: Re: Martin Duke's Discuss on draft-ietf-core-new-bl= ock-11: (with DISCUSS and COMMENT)

=C2=A0

OK, we've reached understanding on the NON_PROBI= NG_WAIT/NON_PARTIAL_TIMEOUT issue. Thank you for the edit.

=C2=A0

I also now understand that essentially every connect= ion will have a Q-block exchange using CON. As this is an integral part of = the protocol, I don't believe it's sufficient for Sec 7.1 to declar= e congestion control parameters out of scope, unless there's a normative reference to some other draft that explains= how to do it.

=C2=A0

Thanks

Martin

=C2=A0

On Tue, May 4, 2021 at 2:01 AM <mohamed.boucadair@orange.c= om> wrote:

Hi Martin,

=C2=A0

Please see inline.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Martin= Duke [mailto:marti= n.h.duke@gmail.com]
Envoy=C3=A9=C2=A0: lundi 3 mai 2021 20:57
=C3=80=C2=A0: BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com&= gt;
Cc=C2=A0: The IESG <iesg@ietf.org>; dra= ft-ietf-core-new-block@ietf.org; core-chairs@ietf.= org; core@ietf.org; = marco.tiloca@ri.se
Objet=C2=A0: Re: Martin Duke's Discuss on draft-ietf-core-new-bl= ock-11: (with DISCUSS and COMMENT)

=C2=A0

=C2=A0

=C2=A0

On Fri, Apr 30, 2021 at 4:48 AM <mohamed.boucadair@orange.= com> wrote:

>
> I can't reconcile (4.1) with the last sentence in (7.2).

[Med] Why? 4.1 can be done with default CoAP setting. The purpose of this C= ON request is to determine support of the functionality. We made this chang= e:

OLD:
=C2=A0 =C2=A0Congestion control for CON requests and responses is specified= in
=C2=A0 =C2=A0Section 4.7 of [RFC7252].=C2=A0 In order to benefit from faste= r
=C2=A0 =C2=A0transmission rates, NSTART will need to be increased from 1. =C2=A0 =C2=A0However, the other CON congestion control parameters will need= to be
=C2=A0 =C2=A0tuned to cover this change.=C2=A0 This tuning is not specified= in this
=C2=A0 =C2=A0document given that the applicability scope of the current
=C2=A0 =C2=A0specification assumes that all requests and responses using Q-= Block1
=C2=A0 =C2=A0and Q-Block2 will be Non-confirmable (Section 3.2).

NEW:=C2=A0
=C2=A0 =C2=A0Congestion control for CON requests and responses is specified= in
=C2=A0 =C2=A0Section 4.7 of [RFC7252].=C2=A0 In order to benefit from faste= r
=C2=A0 =C2=A0transmission rates, NSTART will need to be increased from 1. =C2=A0 =C2=A0However, the other CON congestion control parameters will need= to be
=C2=A0 =C2=A0tuned to cover this change.=C2=A0 This tuning is not specified= in this
=C2=A0 =C2=A0document given that the applicability scope of the current
=C2=A0 =C2=A0specification assumes that all requests and responses using Q-= Block1
=C2=A0 =C2=A0and Q-Block2 will be Non-confirmable (Section 3.2) apart from = the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^^^^=C2=A0
=C2=A0 =C2=A0initial Q-Block functionality negotiation.
=C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

=C2=A0

Does the functionality negotiation in (4.1) involve = something other than sending Q-Block options?

[Med] No. All what is needed is t= o send the options in a CON message as per: =C2=A0=

=C2=A0

=C2=A0=C2=A0 To indicate support for Q-Block2 responses, the= CoAP client MUST

=C2=A0=C2=A0 include the Q-Block2 Option in a GET or similar= request (FETCH, for

=C2=A0=C2=A0 example), the Q-Block2 Option in a PUT or simil= ar request (POST, for

=C2=A0=C2=A0 example), or the Q-Block1 Option in a PUT or si= milar request so that

=C2=A0=C2=A0 the server knows that the client supports this = Q-Block functionality

=C2=A0=C2=A0 should it need to send back a body that spans m= ultiple payloads.

=C2=A0=C2=A0 Otherwise, the server would use the Block2 Opti= on (if supported) to

=C2=A0=C2=A0 send back a message body that is too large to f= it into a single IP

=C2=A0=C2=A0 packet [RFC7959].

=C2=A0

If so, then (4.1) ought to clarify that it's wha= t you mean. If it's just a GET or whatever, then the text here is fine,= but there needs to be more on congestion control for confirmable messages.

=C2=A0


=C2=A0Moreover, if
> my reading of (4.1) is correct, it's not sufficient to declare
> congestion control guidance out of scope when it's a mandated part= of
> the protocol.
>

>
> - (7.2) If NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT both "have th= e
> same value as computed for EXCHANGE_LIFETIME", why are they diffe= rent
> variables?

[Med] Because they refer to distinct aspects that may be tweaked separately= : the timeout induced by PROBING_RATE and the one to observe for expired pa= rtial bodies.

=C2=A0Or is that they SHOULD have the same value but might not?
> A normative word would be helpful here.

[Med] Not sure a change is needed here given the definition of the two para= meters.

=C2=A0

But they can't be tweaked separately! The spec s= tates that they are both computed as EXCHANGE_LIFETIME. It does not allow f= or them to be set separately.

[Med] Ah, I see what confuses you= . We made this change:

=C2=A0

OLD:=

=C2=A0=C2=A0 NON_PROBING_WAIT is used to limit the potential= wait needed

=C2=A0=C2=A0 calculated when using PROBING_RATE.=C2=A0 NON_P= ROBING_WAIT has the same

=C2=A0=C2=A0 value as computed for EXCHANGE_LIFETIME (Sectio= n 4.8.2 of [RFC7252]).

=C2=A0

=C2=A0=C2=A0 NON_PARTIAL_TIMEOUT is used for expiring partia= lly received bodies.

=C2=A0=C2=A0 NON_PARTIAL_TIMEOUT has the same value as compu= ted for

=C2=A0=C2=A0 EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).=

=C2=A0

NEW:= 

=C2=A0=C2=A0 NON_PROBING_WAIT is used to limit the potential wait need=
ed
=C2=A0=C2=A0 calculated when using PROBING_RATE.=C2=A0 By default, NON_PROBING_WAIT has
=C2=A0=C2=A0 the same value as EXCHANGE_LIFETIME (Section 4.8.2 of [RF=
C7252]).
=C2=A0
=C2=A0=C2=A0 NON_PARTIAL_TIMEOUT is used for expiring partially receiv=
ed bodies.
=C2=A0=C2=A0 By default, NON_PARTIAL_=
TIMEOUT has the same value as
=C2=A0=C2=A0 EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).=

=C2=A0

______________________________________________________________________=
___________________________________________________

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 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 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.
--0000000000007181c605c183fccc-- From nobody Wed May 5 00: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 B321F3A1590 for ; Wed, 5 May 2021 00:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 rqul_GVIpXIF for ; Wed, 5 May 2021 00:30:45 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140074.outbound.protection.outlook.com [40.107.14.74]) (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 DCB7C3A158E for ; Wed, 5 May 2021 00:30:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Goeg1F2KXnY8vEMFJ8cGj4r5CWCGUKPrrNeG9ki9LtkT3kiOBF4apKn3354UcxYSnY6Y5FE7Ulhqw/pWFzdZpK12CQn/Zk2kJcZ95YiO2ijzSBbO5XPkyYxe5r5Pb9DQEpj8bFLqS1oj2s1eFxPpIvWRy6b9Vey6WZMeHQCWz8IjHv0XhYuTIzX/sKfbeCPv7cjNXbtoV7pHqp2zMt/GTASMdzdzxs7y/CNbNycVgZMCVQqZ9wu52k7OeDFuB+etDOg6YDTEsvEI+DcwxH4aAzanZEn0PtWc4JD8bUXLYYrYqWOHzROkj6gXG+ubg0CmTJ9TMJWUv8wkluw5mivo+A== 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=TfWx318Oo3W6ceLma77BKhFbSLJP12mwaLg6zvXkCkY=; b=XRjcmBwkKqfig3LSaHM4f9tLhv/EbvWlr+4bGaIus3Aq9izT7fDO1HSa/dXDduwHx4JGQWqmH8gvLjoCnys+EraFC+zeOPZ7kPhXQ+KqVaSjPhgrya8LFYcWwzsmEvNZW/1jZRqOlx+0Cg0sQVz9n7CkvfpTP/PvsVUE80zu7ifq+Mz69zIEbVT29jl79HLjgbP0c5Qwq/c3i6HtuEUaWH1XdZBtkEqf/maXuAaz1yiD5KUA7dLsyv3G1s4gqjousG1+AFay98oo3Jj/9fcNlcQaxe1hr7miIqDcrjxRE/oq8WY7AIZ0Z36oTxGKCziOYYHvg3bueV5z1JipBfo5MQ== 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=TfWx318Oo3W6ceLma77BKhFbSLJP12mwaLg6zvXkCkY=; b=YRYt1bJ9ZlQMopj3t1awAYAyT9AfIDj6EH/4rpdw0qxNSomwUzH65tvSrBgPjkySVoSbd/G0CXRMrRFmkgswNWPqi5Yilrn7Wq2Bd4L2ivlVitxcIq6D7HcGtOtkDP3mSzEJ7FV2IXyokbgZJUySzEkxqigLXRGK0lSmtHvZfys= Received: from AM9P189MB1571.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:30d::9) by AM9P189MB1620.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:304::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.24; Wed, 5 May 2021 07:30:41 +0000 Received: from AM9P189MB1571.EURP189.PROD.OUTLOOK.COM ([fe80::6028:cab:3af5:69bc]) by AM9P189MB1571.EURP189.PROD.OUTLOOK.COM ([fe80::6028:cab:3af5:69bc%7]) with mapi id 15.20.4087.044; Wed, 5 May 2021 07:30:41 +0000 From: =?utf-8?B?UmlrYXJkIEjDtmdsdW5k?= To: John Mattsson , Marco Tiloca , "core@ietf.org WG (core@ietf.org)" Thread-Topic: [core] CoRE WG Virtual Interim 2021-04-28 Thread-Index: AQHXNsit23B0og1IvUeABOeSJxd+9arJ35qAgAFvCICACUB6TA== Date: Wed, 5 May 2021 07:30:41 +0000 Message-ID: References: <9c14ea30-3f76-f840-7e7b-901dcb1c8678@ri.se> <69df215a-b7de-c837-75ee-d118af8b9304@ri.se>, <008617DF-D15B-4597-A7B4-F13E3B06C95F@ericsson.com> In-Reply-To: <008617DF-D15B-4597-A7B4-F13E3B06C95F@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ri.se; x-originating-ip: [85.228.127.50] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4552abe4-c643-4c90-a174-08d90f97b024 x-ms-traffictypediagnostic: AM9P189MB1620: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8I61BgU1Io9KfGqXKDwwWR2dYWaVfh03LnBIb/M+bQ1TJ3/Ac3tlLCs2pLIV6w3GeAieSybsM/GVszXT5j0NuqzD2rrRLylNIUmBrE4gKP4kuk5aC9VGClN6aTpK8c92XKtW+dQ78ZZNqupWsRKSr0y6kafkk1VEy7TYVh8K8lJ2GUU92iNI0VmXXHfEKlNvrYB9UEHT12nM6TtWnaCo9UCkZoaU06j17L7Pl5ldjwMLBELk5iKOVkZHH/nckesS5ju7v6Qj3v5SBF9r3xeUyWzc52af7Xb8fdFeaINyHqlLXKYnVEVsIe9OGPs2F6cJZYZe2OP/YvR69cDl0O2Qo4W6z4PG6lxdVmGB+gdAR7muBZ2R51mhGBcNc5Jp6wd9gtnhWPtoHct2nJP9B4xDXBSs7duUnQORogy6DaWOm3+PyxdkdJMR7UWv7YL8dPf9JZLy0L1bFzc/Uy+0ZGTpqXkNG5gHnffGHNxuHfxQTzzO1qVRQqd/kk+W6qiz5VB3+i1lJSkpkXMEdTdNaZhIjzuli6GDe746wtB2KTHH3q4XWmsXWJyNtazhoiOXRezyxekbcubCel+ZR/t12ArdqLFEVfwciuBl7p/ghU1ymp8ekfM2ME7ImqZGx2a4OLk03Pn0IKRttC5emWB7yDCBp7JEmI1WtWRQ5YinbLw0/21YZD6CxbK9SA9vbJpeqbXM x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9P189MB1571.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(39850400004)(396003)(376002)(136003)(8676002)(9686003)(66574015)(5660300002)(83380400001)(186003)(166002)(55016002)(2906002)(53546011)(6506007)(8936002)(86362001)(122000001)(26005)(52536014)(478600001)(110136005)(16799955002)(316002)(33656002)(66446008)(966005)(7696005)(64756008)(66556008)(19627405001)(66946007)(71200400001)(45080400002)(38100700002)(85182001)(85202003)(76116006)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?MzgwNmFRcGZBZHhISmpEYXBWdGtuTkVPWE5QSnB2TUYrVkFadWdJdDdpMGZR?= =?utf-8?B?UkZpdXovS2NSNU9MUUJNZjFRQXFrWXBaWlBzRlZqMjY2NEgrMDUzcEJjbVdl?= =?utf-8?B?c2xDVDd5aHpjbldrbmVDN0ZPeWttY0RKbS9BV3l1OEJ1Tnh3OFJ3dWNkZi9O?= =?utf-8?B?a0s1aVFpcUErQ3k5YWJPTkdHNDlBWVdmMk51RVorSExnSXVzc2pWQTRLNUZU?= =?utf-8?B?M2ZaejM2UHhjckFQUHJqYW9oMzBiVG9IazNUbitBNEFHVW9RTldZSlRicDVw?= =?utf-8?B?YkQ4ajArSXJaaWZLL3JTRWZBVU1ibUU4bUdKeFNyc3FzV1kwMG5pemkyNFVt?= =?utf-8?B?TEQ4NFpvd1NnSlppZkJGSUQ2Nzc0a2RaSFUvK29tdzYvRzZmTDhaekhjOGEw?= =?utf-8?B?TFlhNzR0ZGorMnNVTjYwTWNVTHRxM2YyZ2dtTFJXekNZOEswREIxZmUycCtz?= =?utf-8?B?SnA3OG1DaWhmQjJvZTdnenNpN2gyN3FESTIxOUF6NytmQVAySFE0bzdyVUpD?= =?utf-8?B?c3d0akE4K29pWStZdFc2SkZabDhhQkpOdmZmUW1IbFZaQmR0QytaekR2K0M1?= =?utf-8?B?aFVsdTJXK3ZQYUZzMnJHRTNONS80ZWc5MUQ5ZWpFeVNreW9JcEhJMHRXTCtp?= =?utf-8?B?a05VYXlPZzQxeFppZThNdmtLemlETGU0V3ZhQkFHcWl4THArYXNNVjBCcW9h?= =?utf-8?B?eDZtTmE5MUxxNjNEcWk1YldYZEV3RktjV0x1eHFEc3p5bDNLRStrbEZEMCtN?= =?utf-8?B?R1BOTmNpK2Yvek5SSHhHemlqZWNCSyt4VUVyb1B2TkdjaFV1V2ViWVFRU2xB?= =?utf-8?B?anJHNi9QWFU3T00vUC9ZNUtPRDFwZGJWdWxyTVEyaGRPQkd6THBaVjNzVnRk?= =?utf-8?B?RURJVTFKU25lQ1MyTDlNTXZFQnQ4TmlJbDlzbzBiMHlGTnpQYmgxTVNjTENU?= =?utf-8?B?MjF0UHFDeGlCSk9zeUpwNUowODN2dEZlS3RxYlhkbElHUmQ2bDRzN0tRV3Zi?= =?utf-8?B?NEJxK3F4RkRLdFVwakNjQS9yNURFOE9GUDVLTUcwUmIvT21MRGtTNUUrNFI3?= =?utf-8?B?Q2FQckptVEFNMXhxSWdZbi9XYnU3d0loWHZ5aVArUFBML1dyN2ppeTdqeFFR?= =?utf-8?B?WHdoanRYRDJKTnVCWVhiY04rN29sSGNJUGU5L0FYSXp3ZVFBdks2VzlCWkFZ?= =?utf-8?B?bGI0SXR6MW44UXpQOWhYOWRZLzBYRk9ZWUp0S2RjdWlEck5BbUhDREJkU2hE?= =?utf-8?B?Qm45bXJibGhQUmhlRUZ6cjRSQi9yL041R3dYMUthT0t1OVEwM1RrSkMvWitW?= =?utf-8?B?M3BEdDNGcFRnamlrbW5MaWZycnpRSlcxeWk3S3hLd1UwL29ENFlPQ096WkpQ?= =?utf-8?B?bUFqK1BMNkdmb3JrNWtMZkt0b3ZqS2gvNjkwM0hDSDdhMCtsWUo5OTZ4SjZp?= =?utf-8?B?S2hYL1Qxcy9mbUtOcVhZWGV2cWFXT3dYZzZJM1dWRVlnOCt3Nlkyei9TdUVU?= =?utf-8?B?WG1GZll6ZGlDYXI2UzZRdlZZQlZ1L24xTlQ5eHRVYU5YQTE0R1l2NStqVzRZ?= =?utf-8?B?eDNWdjFXcmo5N25RRzRLN3hYYmJveTIrNDYyZDFZVS9ta3dkS3Z0Z2xEWEt4?= =?utf-8?B?c0hWaU9QWG1yVXdhMkRVdE8ydW5tU2kzOFBPUFkwckl3eS94clJXOFBsY0Y3?= =?utf-8?B?UjV1QnRDL3NCTHRZeWVwNWt3aXprU1hpbWtVWktsTkZWU3pwaTd1ek9vc0Zl?= =?utf-8?Q?v/vPlXoi+3BgZxvkiY=3D?= Content-Type: multipart/alternative; boundary="_000_AM9P189MB1571B8F076D8C99862FD3C3283599AM9P189MB1571EURP_" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM9P189MB1571.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 4552abe4-c643-4c90-a174-08d90f97b024 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2021 07:30:41.7622 (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: /B6AZ1p8q7RMX3+e2I66elh3UAthgQkpB6uOQKJxvqOcHWutMEO7dVgxB6wrQQcGAupZeITheKhbln5E7NU54Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P189MB1620 Archived-At: Subject: Re: [core] CoRE WG Virtual Interim 2021-04-28 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, 05 May 2021 07:30:51 -0000 --_000_AM9P189MB1571B8F076D8C99862FD3C3283599AM9P189MB1571EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8uDQoNClRoYW5rIHlvdSBKb2huIGZvciBpbml0aWF0aW5nIHRoaXMgZGlzY3Vzc2lvbi4N Cg0KQXMgbWVudGlvbmVkIGR1cmluZyB0aGUgbGFzdCBpbnRlcmltIG1lZXRpbmcsIHdlIGNhbiBz dGFydCBleHBhbmRpbmcgdGhlIGN1cnJlbnQgZHJhZnQgYXQgWzFdIHRvIGFsc28gaW5jbHVkZSBp bmZvcm1hdGlvbiBhYm91dCBhbiB1cGRhdGVkIHByb2Nlc3MgZm9yIHJla2V5aW5nIE9TQ09SRS4N Cg0KQ3VycmVudGx5IHdlIGFyZSB1c2luZyBsID0gMl4xMCA9IDEwMjQgaW4gdGhlIGRyYWZ0IHRl eHQsIHdoaWNoIGlzIGJhc2VkIG9uIHRoZSB2YWx1ZXMgZnJvbSB0aGUgRFRMUyAxLjMgZHJhZnQg YXQgWzJdLCBhcyBpcyB0aGUgcF9xIGFuZCBwX3YgcHJvYmFiaWxpdHkgdmFsdWVzLiBJbiB0aGF0 IGRyYWZ0IHRoZXkgbW90aXZhdGUgYSBjaG9zZW4gbCB2YWx1ZSBvZiAxMDI0IGFzIGJlbG93LiBU aGUgcGFwZXIgcmVmZXJyZWQgdG8gYXMgQUVCb3VuZHMgY2FuIGJlIGZvdW5kIGF0IFszXS4NCg0K Rm9yIHNpbXBsaWNpdHksIGFuZCB0byBtYXRjaCB0aGUgYW5hbHlzaXMgb2Ygb3RoZXIgQUVBRCBm dW5jdGlvbnMgaW4gW0FFQm91bmRzXSwNCg0KdGhpcyBhbmFseXNpcyBhc3N1bWVzIGEgcGFja2V0 IGxlbmd0aCBvZiAyXjEwIGJsb2NrcyBhbmQgYSBwYWNrZXQgc2l6ZSBsaW1pdCBvZiAyXjE0IGJ5 dGVzLg0KDQpBcyB5b3Ugc2F5IGl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIG9wZW4gYSBkaXNj dXNzaW9uIG9uIGhvdyB0aGUgY2hvaWNlIG9mIGxpbWl0cyBmb3IgdiAmIHEsIGFuZCB0aGUgY2hv aWNlIG9mIGwgd291bGQgYWZmZWN0IGFwcGxpY2F0aW9ucy4NCg0KQmVzdCB3aXNoZXMNClJpa2Fy ZCBIw7ZnbHVuZA0KDQpbMV0gaHR0cHM6Ly9naXRsYWIuY29tL3Jpa2FyZC1zaWNzL2RyYWZ0LWhv ZWdsdW5kLW9zY29yZS1yZWtleWluZy1saW1pdHMvLS90cmVlL3YtMDENClsyXSBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdGxzLWR0bHMxMy00Mw0KWzNd IGh0dHBzOi8vd3d3LmlzZy5yaHVsLmFjLnVrL35rcC9UTFMtQUVib3VuZHMucGRmDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogY29yZSA8Y29yZS1ib3VuY2VzQGlldGYu b3JnPiBvbiBiZWhhbGYgb2YgSm9obiBNYXR0c3NvbiA8am9obi5tYXR0c3Nvbj00MGVyaWNzc29u LmNvbUBkbWFyYy5pZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyOSwgMjAyMSAxMTo1 Nw0KVG86IE1hcmNvIFRpbG9jYSA8bWFyY28udGlsb2NhQHJpLnNlPjsgY29yZUBpZXRmLm9yZyBX RyAoY29yZUBpZXRmLm9yZykgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIENv UkUgV0cgVmlydHVhbCBJbnRlcmltIDIwMjEtMDQtMjgNCg0KSGksDQoNCkJlbG93IGFyZSBteSB0 aG91Z2h0cyBhZnRlciB0aGUgaW50ZXJpbSB5ZXN0ZXJkYXk6DQoNCi0gVHdvIGVxdWFsbHkgaW1w b3J0YW50IHJlYXNvbnMgdG8gcmVrZXksIEFFQUQgbGltaXRzIGFuZCBmb3J3YXJkIHNlY3JlY3ku IEEgZG9jdW1lbnQNCiAgdXBkYXRpbmcgT1NDT1JFIHNob3VsZCB0cmVhdCBib3RoIHdpdGggZXF1 YWwgd2VpZ2h0Lg0KLSBGcmVxdWVudCByZWtleWluZyByZXF1aXJlIGVmZmljaWVudCByZWtleWlu Zywgc2hvdWxkIGJlIHB1Ymxpc2hlZCB0b2dldGhlci4NCi0gT3RoZXIgcXVlc3Rpb25zIGxpa2Ug ZXJyb3IgbWVzc2FnZXMgZXRjLiwgbmVlZHMgdG8gYmUgc3BlY2lmaWVkIGF0IHRoZSBzYW1lIHRp bWUuDQotIFRoZSBsaW1pdCBzZXR0aW5nIHByb2Nlc3MgdXNlZCBpbiBUTFMgaXMgZmxhd2VkIGFu ZCBzaG91bGQgcHJvYmFibHkgbm90IGJlIHVzZWQgYXQgYWxsLg0KLSBUaGUgbGltaXRzIGluIFRM UyBhcmUgc2VjdXJlLCBhbnkgbGltaXRzIGVxdWFsIG9yIGxvd2VyIGRvZXMgbm90IG5lZWQgbW90 aXZhdGlvbi4NCi0gUG9seTEzMDUgdiwgR0NNIHYsIENoYUNoYTIwIHEgZG9lcyBub3QgbmVlZCBh bnkgQUVBRCBsaW1pdHMgYXQgYWxsLg0KLSBDQ00gdiwgQ0NNIHEsIEdDTSBxIHNob3VsZCBiZSBy ZWtleWVkIGFyb3VuZCAyXjIzIC0gMl4yNC41IGxpa2UgaW4gVExTDQotIENDTV84IHYgY291bGQg YmUgdXNlZCBtdWNoIGxvbmdlciwgbWF5YmUgMl4zNQ0KLSBTaG91bGQgY29uc2lkZXIgbG93ZXJp bmcgbCBhbmQgQ0NNIHEgY29tcGFyZWQgdG8gVExTIHRvIG1ha2UgQ0NNXzggYmVoYXZlIGV2ZW4g bW9yZSBsaWtlIHBlcmZlY3QgTUFDIChyaWdodCBub3cgdGhlIGF0dGFja2VyIGNhbiBsb29rIGF0 IDJeMjMgbWVzc2FnZXMgYW5kIHRoZW4gc2VuZCBhIHNpbmdsZSBmb3JnZXJ5IGF0dGVtcHQpLiBU aGlzIHNpbmdsZSBmb3JnZXJ5IGF0dGVtcHQgc3VjY2VkcyB3aXRoIHByb2JhYmlsaXR5IDJeNjAu DQotIE1pZ2h0IGJlIGVhc2llciB0byBzZXQgc2ltcGxlIGxpbWl0IG9mIHEsIHYgPSAyXjIwIG9y IDJeMjMgZm9yIGFsbCBhbGdvcml0aG1zLg0KLSBUaGUgbGltaXQgbCA9IDJeMTAgaXMgbWVhc3Vy ZWQgaW4gYmxvY2tzICh3b3JzdCBjYXNlKSwgSW4gYnl0ZXMgdGhlIGxpbWl0IGlzDQogIDJeMTAg KiAyXjQgPSAyXjE0IGJ5dGVzID0gMTYga0IuDQotIENhbiBiZSBkaXNjdXNzZWQgd2hpY2ggbGlt aXRzIHNob3VsZCBiZSBNVVNUIG9yIFNIT1VMRC4NCi0gRm9jdXMgb24gZGlzY3Vzc2lvbiBuZWVk cyB0byBiZSBvbiBob3cgcSx2LGwgbGltaXRzIGFuZCByZWtleWluZyBhZmZlY3QgYXBwbGljYXRp b25zLg0KDQpDaGVlcnMsDQpKb2huDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBjb3JlIDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBNYXJjbyBUaWxv Y2EgPG1hcmNvLnRpbG9jYUByaS5zZT4NCkRhdGU6IFdlZG5lc2RheSwgMjggQXByaWwgMjAyMSBh dCAxNDowNA0KVG86ICJjb3JlQGlldGYub3JnIFdHIChjb3JlQGlldGYub3JnKSIgPGNvcmVAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIENvUkUgV0cgVmlydHVhbCBJbnRlcmltIDIwMjEt MDQtMjgNCg0KRGVhciBhbGwsDQoNCkp1c3QgYSByZW1pbmRlciB0aGF0IHdlIGFyZSBoYXZpbmcg b3VyIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIGluDQpzbGlnaHRseSBsZXNzIHRoYW4gMiBob3Vy cyBbMV0uDQoNClBsZWFzZSBmaW5kIGJlbG93IHRoZSBpbmZvcm1hdGlvbiB0byBqb2luLg0KDQpC ZXN0LA0KTWFyY28gYW5kIEphaW1lDQoNClsxXSBodHRwczovL2V1cjAyLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9y ZyUyRm1lZXRpbmclMkZpbnRlcmltLTIwMjEtY29yZS0wNCUyRnNlc3Npb24lMkZjb3JlJmFtcDtk YXRhPTA0JTdDMDElN0NyaWthcmQuaG9nbHVuZCU0MHJpLnNlJTdDZTgzYmM4NTBkZTUxNDMyYmYz MmYwOGQ5MGFmNTRjYWMlN0M1YTk4MDljZjBiY2I0MTNhODM4YTA5ZWNjNDBjYzllOCU3QzAlN0Mw JTdDNjM3NTUyODcwOTM1NjY0NjI4JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0 d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3 QzEwMDAmYW1wO3NkYXRhPVhiS29BV01IWGNCT1dlUGVxbXAxYWV2OCUyQjFUZU5ibHYlMkZ4eTg4 V2MxNFMwJTNEJmFtcDtyZXNlcnZlZD0wDQoNCg0KPT09IE1lZXRpbmcgSW5mb3JtYXRpb24gPT09 DQoNCkphYmJlcjogY29yZUBqYWJiZXIuaWV0Zi5vcmcNCg0KRXRoZXJwYWQ6IGh0dHBzOi8vZXVy MDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmNv ZGltZC5pZXRmLm9yZyUyRm5vdGVzLWlldGYtaW50ZXJpbS0yMDIxLWNvcmUtMDQtY29yZSZhbXA7 ZGF0YT0wNCU3QzAxJTdDcmlrYXJkLmhvZ2x1bmQlNDByaS5zZSU3Q2U4M2JjODUwZGU1MTQzMmJm MzJmMDhkOTBhZjU0Y2FjJTdDNWE5ODA5Y2YwYmNiNDEzYTgzOGEwOWVjYzQwY2M5ZTglN0MwJTdD MCU3QzYzNzU1Mjg3MDkzNTY2NDYyOCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1D NHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0Ql N0MxMDAwJmFtcDtzZGF0YT1qeGdzVUptJTJGVUtSSkxyYTV0emlBS1oweWtqMyUyQkRCWnVBTk5m cEZxJTJCOGpjJTNEJmFtcDtyZXNlcnZlZD0wDQoNCk1lZXRpbmcgbGluazoNCmh0dHBzOi8vZXVy MDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmll dGYud2ViZXguY29tJTJGaWV0ZiUyRmoucGhwJTNGTVRJRCUzRG04ODhhOTkwNzYwNDI1MjcxYTEz MjdmNTNjNjcxNGIwNyZhbXA7ZGF0YT0wNCU3QzAxJTdDcmlrYXJkLmhvZ2x1bmQlNDByaS5zZSU3 Q2U4M2JjODUwZGU1MTQzMmJmMzJmMDhkOTBhZjU0Y2FjJTdDNWE5ODA5Y2YwYmNiNDEzYTgzOGEw OWVjYzQwY2M5ZTglN0MwJTdDMCU3QzYzNzU1Mjg3MDkzNTY2NDYyOCU3Q1Vua25vd24lN0NUV0Zw Ykdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhh V3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT1UR2RhYnRkd0g5bWFjc2Y0R2pMSG5i bTFMV0I4JTJGd2hYZCUyQmpnQUVhQTNoayUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQpNZWV0aW5nIG51 bWJlcjogMTg1IDI0OCA5MjMxDQpQYXNzd29yZDogY29uc3RyYWluZWQNCg0KDQpNb3JlIHdheXMg dG8gam9pbg0KDQpKb2luIGJ5IHZpZGVvIHN5c3RlbQ0KRGlhbCAxODUyNDg5MjMxQGlldGYud2Vi ZXguY29tDQpZb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVl dGluZyBudW1iZXIuDQoNCkpvaW4gYnkgcGhvbmUNCjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gbnVt YmVyIChVUy9DYW5hZGEpDQpBY2Nlc3MgY29kZTogMTg1IDI0OCA5MjMxDQoNCg0KT24gMjAyMS0w NC0yMSAxODowNywgTWFyY28gVGlsb2NhIHdyb3RlOg0KPiBEZWFyIGFsbCwNCj4NCj4gSnVzdCBh IHJlbWluZGVyIHRoYXQgd2UnbGwgaGF2ZSBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIG9uDQo+ IFdlZG5lc2RheSwgQXByaWwgMjh0aCBhdCAxNDowMCBVVEMuIFRoZSBhZ2VuZGEgaXMgYXZhaWxh YmxlIGF0IFsxXS4NCj4NCj4gQmVzdCwNCj4gTWFyY28gYW5kIEphaW1lDQo+DQo+IFsxXQ0KPiBo dHRwczovL2V1cjAyLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRm1lZXRpbmclMkZpbnRlcmltLTIwMjEtY29y ZS0wNCUyRnNlc3Npb24lMkZjb3JlJmFtcDtkYXRhPTA0JTdDMDElN0NyaWthcmQuaG9nbHVuZCU0 MHJpLnNlJTdDZTgzYmM4NTBkZTUxNDMyYmYzMmYwOGQ5MGFmNTRjYWMlN0M1YTk4MDljZjBiY2I0 MTNhODM4YTA5ZWNjNDBjYzllOCU3QzAlN0MwJTdDNjM3NTUyODcwOTM1Njc0NTg1JTdDVW5rbm93 biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJU aUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPXhkV1pUeHZ5UVVIeCUy QnRFMU9mSFFiU3pkSjRzJTJCbEVQa29aamYwdUdTQ1NzJTNEJmFtcDtyZXNlcnZlZD0wDQo+DQoN Ci0tDQpNYXJjbyBUaWxvY2ENClBoLkQuLCBTZW5pb3IgUmVzZWFyY2hlcg0KDQpEaXZpc2lvbjog RGlnaXRhbCBTeXN0ZW0NCkRlcGFydG1lbnQ6IENvbXB1dGVyIFNjaWVuY2UNClVuaXQ6IEN5YmVy c2VjdXJpdHkNCg0KUklTRSBSZXNlYXJjaCBJbnN0aXR1dGVzIG9mIFN3ZWRlbg0KaHR0cHM6Ly9l dXIwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG cHJvdGVjdDIuZmlyZWV5ZS5jb20lMkZ2MSUyRnVybCUzRmslM0Q0YzRhNTk4Ny0xM2QxNjE2NS00 YzRhMTkxYy04NjA3M2IzNmVhMjgtMmFkZWMyMWYwMzcyMzc3MSUyNnElM0QxJTI2ZSUzRGRjNjA5 MzMxLTZiMmYtNDkwYy1iNTQ1LWY5MzdjNzAzZjA2NSUyNnUlM0RodHRwcyUyNTNBJTI1MkYlMjUy Rnd3dy5yaS5zZSUyNTJGJmFtcDtkYXRhPTA0JTdDMDElN0NyaWthcmQuaG9nbHVuZCU0MHJpLnNl JTdDZTgzYmM4NTBkZTUxNDMyYmYzMmYwOGQ5MGFmNTRjYWMlN0M1YTk4MDljZjBiY2I0MTNhODM4 YTA5ZWNjNDBjYzllOCU3QzAlN0MwJTdDNjM3NTUyODcwOTM1Njc0NTg1JTdDVW5rbm93biU3Q1RX RnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsx aGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPTRqMDBjRXR0QlRqeVhHWmxxY1NR YzdBMWpQTnFoMSUyRnNUR0lTNEMya0JwVSUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQpQaG9uZTogKzQ2 ICgwKTcwIDYwIDQ2IDUwMQ0KSXNhZmpvcmRzZ2F0YW4gMjIgLyBLaXN0YWfDpW5nZW4gMTYNClNF LTE2NCA0MCBLaXN0YSAoU3dlZGVuKQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpo dHRwczovL2V1cjAyLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZjb3JlJmFtcDtkYXRh PTA0JTdDMDElN0NyaWthcmQuaG9nbHVuZCU0MHJpLnNlJTdDZTgzYmM4NTBkZTUxNDMyYmYzMmYw OGQ5MGFmNTRjYWMlN0M1YTk4MDljZjBiY2I0MTNhODM4YTA5ZWNjNDBjYzllOCU3QzAlN0MwJTdD NjM3NTUyODcwOTM1Njc0NTg1JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xq QXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEw MDAmYW1wO3NkYXRhPWxaYklvQVEzWDRwT1Y1aWslMkI1RzJhZCUyRmMwRXFGciUyQm1iOThtdDJF aWFselElM0QmYW1wO3Jlc2VydmVkPTANCg== --_000_AM9P189MB1571B8F076D8C99862FD3C3283599AM9P189MB1571EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNv bG9yOiByZ2IoMCwgMCwgMCk7Ij4NCkhlbGxvLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJw dDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQpUaGFuayB5b3UgSm9obiBmb3IgaW5pdGlh dGluZyB0aGlzIGRpc2N1c3Npb24uPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xv cjogcmdiKDAsIDAsIDApOyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCkFzIG1lbnRpb25lZCBkdXJpbmcgdGhlIGxhc3QgaW50 ZXJpbSBtZWV0aW5nLCB3ZSBjYW4gc3RhcnQgZXhwYW5kaW5nIHRoZSBjdXJyZW50IGRyYWZ0IGF0 IFsxXSB0byBhbHNvIGluY2x1ZGUgaW5mb3JtYXRpb24gYWJvdXQgYW4gdXBkYXRlZCBwcm9jZXNz IGZvciByZWtleWluZyBPU0NPUkUuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xv cjogcmdiKDAsIDAsIDApOyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCkN1cnJlbnRseSB3ZSBhcmUgdXNpbmcgbCA9IDJeMTAg PSAxMDI0IGluIHRoZSBkcmFmdCB0ZXh0LCB3aGljaCBpcyBiYXNlZCBvbiB0aGUgdmFsdWVzIGZy b20gdGhlIERUTFMgMS4zIGRyYWZ0IGF0IFsyXSwgYXMgaXMgdGhlIHBfcSBhbmQgcF92IHByb2Jh YmlsaXR5IHZhbHVlcy4gSW4gdGhhdCBkcmFmdCB0aGV5IG1vdGl2YXRlIGEgY2hvc2VuIGwgdmFs dWUgb2YgMTAyNCBhcyBiZWxvdy4mbmJzcDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjpy Z2IoMjU1LCAyNTUsIDI1NSk7ZGlzcGxheTppbmxpbmUgIWltcG9ydGFudCI+VGhlDQogcGFwZXIg cmVmZXJyZWQgdG8gYXMgQUVCb3VuZHMgY2FuIGJlIGZvdW5kIGF0IFszXS48L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8cHJlIGNs YXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDtt YXJnaW4tYm90dG9tOjBweDticmVhay1iZWZvcmU6cGFnZSI+Rm9yIHNpbXBsaWNpdHksIGFuZCB0 byBtYXRjaCB0aGUgYW5hbHlzaXMgb2Ygb3RoZXIgQUVBRCBmdW5jdGlvbnMgaW4gW0FFQm91bmRz XSwgPC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNw eDttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDticmVhay1iZWZvcmU6cGFnZSI+dGhp cyBhbmFseXNpcyBhc3N1bWVzIGEgcGFja2V0IGxlbmd0aCBvZiAyXjEwIGJsb2NrcyBhbmQgYSBw YWNrZXQgc2l6ZSBsaW1pdCBvZiAyXjE0IGJ5dGVzLjwvcHJlPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KQXMgeW91IHNheSBpdCB3 b3VsZCBiZSBpbnRlcmVzdGluZyB0byBvcGVuIGEgZGlzY3Vzc2lvbiBvbiBob3cgdGhlIGNob2lj ZSBvZiBsaW1pdHMgZm9yIHYgJmFtcDsgcSwgYW5kIHRoZSBjaG9pY2Ugb2YgbCB3b3VsZCBhZmZl Y3QgYXBwbGljYXRpb25zLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmks IEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJn YigwLCAwLCAwKTsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xv cjogcmdiKDAsIDAsIDApOyI+DQpCZXN0IHdpc2hlczwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KUmlrYXJkIEjDtmdsdW5kPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NClsxXSZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vZ2l0bGFiLmNvbS9yaWthcmQtc2ljcy9kcmFmdC1ob2VnbHVuZC1v c2NvcmUtcmVrZXlpbmctbGltaXRzLy0vdHJlZS92LTAxIj5odHRwczovL2dpdGxhYi5jb20vcmlr YXJkLXNpY3MvZHJhZnQtaG9lZ2x1bmQtb3Njb3JlLXJla2V5aW5nLWxpbWl0cy8tL3RyZWUvdi0w MTwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7 Ij4NClsyXSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaWV0Zi10bHMtZHRsczEzLTQzIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LWlldGYtdGxzLWR0bHMxMy00MzwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NClszXSZuYnNwOzxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlzZy5yaHVsLmFjLnVrL35rcC9UTFMtQUVib3VuZHMucGRmIj5odHRwczovL3d3 dy5pc2cucmh1bC5hYy51ay9+a3AvVExTLUFFYm91bmRzLnBkZjwvYT48L2Rpdj4NCjxkaXYgaWQ9 ImFwcGVuZG9uc2VuZCI+PC9kaXY+DQo8aHIgc3R5bGU9ImRpc3BsYXk6aW5saW5lLWJsb2NrO3dp ZHRoOjk4JSIgdGFiaW5kZXg9Ii0xIj4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciIGRpcj0ibHRy Ij48Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBzdHlsZT0iZm9udC1zaXplOjExcHQi IGNvbG9yPSIjMDAwMDAwIj48Yj5Gcm9tOjwvYj4gY29yZSAmbHQ7Y29yZS1ib3VuY2VzQGlldGYu b3JnJmd0OyBvbiBiZWhhbGYgb2YgSm9obiBNYXR0c3NvbiAmbHQ7am9obi5tYXR0c3Nvbj00MGVy aWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXks IEFwcmlsIDI5LCAyMDIxIDExOjU3PGJyPg0KPGI+VG86PC9iPiBNYXJjbyBUaWxvY2EgJmx0O21h cmNvLnRpbG9jYUByaS5zZSZndDs7IGNvcmVAaWV0Zi5vcmcgV0cgKGNvcmVAaWV0Zi5vcmcpICZs dDtjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2NvcmVdIENvUkUg V0cgVmlydHVhbCBJbnRlcmltIDIwMjEtMDQtMjg8L2ZvbnQ+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSJCb2R5RnJhZ21lbnQiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTFwdDsiPg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij5IaSw8YnI+DQo8 YnI+DQpCZWxvdyBhcmUgbXkgdGhvdWdodHMgYWZ0ZXIgdGhlIGludGVyaW0geWVzdGVyZGF5Ojxi cj4NCjxicj4NCi0gVHdvIGVxdWFsbHkgaW1wb3J0YW50IHJlYXNvbnMgdG8gcmVrZXksIEFFQUQg bGltaXRzIGFuZCBmb3J3YXJkIHNlY3JlY3kuIEEgZG9jdW1lbnQ8YnI+DQombmJzcDsgdXBkYXRp bmcgT1NDT1JFIHNob3VsZCB0cmVhdCBib3RoIHdpdGggZXF1YWwgd2VpZ2h0Ljxicj4NCi0gRnJl cXVlbnQgcmVrZXlpbmcgcmVxdWlyZSBlZmZpY2llbnQgcmVrZXlpbmcsIHNob3VsZCBiZSBwdWJs aXNoZWQgdG9nZXRoZXIuPGJyPg0KLSBPdGhlciBxdWVzdGlvbnMgbGlrZSBlcnJvciBtZXNzYWdl cyBldGMuLCBuZWVkcyB0byBiZSBzcGVjaWZpZWQgYXQgdGhlIHNhbWUgdGltZS48YnI+DQotIFRo ZSBsaW1pdCBzZXR0aW5nIHByb2Nlc3MgdXNlZCBpbiBUTFMgaXMgZmxhd2VkIGFuZCBzaG91bGQg cHJvYmFibHkgbm90IGJlIHVzZWQgYXQgYWxsLjxicj4NCi0gVGhlIGxpbWl0cyBpbiBUTFMgYXJl IHNlY3VyZSwgYW55IGxpbWl0cyBlcXVhbCBvciBsb3dlciBkb2VzIG5vdCBuZWVkIG1vdGl2YXRp b24uPGJyPg0KLSBQb2x5MTMwNSB2LCBHQ00gdiwgQ2hhQ2hhMjAgcSBkb2VzIG5vdCBuZWVkIGFu eSBBRUFEIGxpbWl0cyBhdCBhbGwuPGJyPg0KLSBDQ00gdiwgQ0NNIHEsIEdDTSBxIHNob3VsZCBi ZSByZWtleWVkIGFyb3VuZCAyXjIzIC0gMl4yNC41IGxpa2UgaW4gVExTPGJyPg0KLSBDQ01fOCB2 IGNvdWxkIGJlIHVzZWQgbXVjaCBsb25nZXIsIG1heWJlIDJeMzUgPGJyPg0KLSBTaG91bGQgY29u c2lkZXIgbG93ZXJpbmcgbCBhbmQgQ0NNIHEgY29tcGFyZWQgdG8gVExTIHRvIG1ha2UgQ0NNXzgg YmVoYXZlIGV2ZW4gbW9yZSBsaWtlIHBlcmZlY3QgTUFDIChyaWdodCBub3cgdGhlIGF0dGFja2Vy IGNhbiBsb29rIGF0IDJeMjMgbWVzc2FnZXMgYW5kIHRoZW4gc2VuZCBhIHNpbmdsZSBmb3JnZXJ5 IGF0dGVtcHQpLiBUaGlzIHNpbmdsZSBmb3JnZXJ5IGF0dGVtcHQgc3VjY2VkcyB3aXRoIHByb2Jh YmlsaXR5IDJeNjAuPGJyPg0KLSBNaWdodCBiZSBlYXNpZXIgdG8gc2V0IHNpbXBsZSBsaW1pdCBv ZiBxLCB2ID0gMl4yMCBvciAyXjIzIGZvciBhbGwgYWxnb3JpdGhtcy48YnI+DQotIFRoZSBsaW1p dCBsID0gMl4xMCBpcyBtZWFzdXJlZCBpbiBibG9ja3MgKHdvcnN0IGNhc2UpLCBJbiBieXRlcyB0 aGUgbGltaXQgaXM8YnI+DQombmJzcDsgMl4xMCAqIDJeNCA9IDJeMTQgYnl0ZXMgPSAxNiBrQi48 YnI+DQotIENhbiBiZSBkaXNjdXNzZWQgd2hpY2ggbGltaXRzIHNob3VsZCBiZSBNVVNUIG9yIFNI T1VMRC48YnI+DQotIEZvY3VzIG9uIGRpc2N1c3Npb24gbmVlZHMgdG8gYmUgb24gaG93IHEsdixs IGxpbWl0cyBhbmQgcmVrZXlpbmcgYWZmZWN0IGFwcGxpY2F0aW9ucy48YnI+DQo8YnI+DQpDaGVl cnMsPGJyPg0KSm9objxicj4NCjxicj4NCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KRnJvbTogY29yZSAmbHQ7Y29yZS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2Yg TWFyY28gVGlsb2NhICZsdDttYXJjby50aWxvY2FAcmkuc2UmZ3Q7PGJyPg0KRGF0ZTogV2VkbmVz ZGF5LCAyOCBBcHJpbCAyMDIxIGF0IDE0OjA0PGJyPg0KVG86ICZxdW90O2NvcmVAaWV0Zi5vcmcg V0cgKGNvcmVAaWV0Zi5vcmcpJnF1b3Q7ICZsdDtjb3JlQGlldGYub3JnJmd0Ozxicj4NClN1Ympl Y3Q6IFJlOiBbY29yZV0gQ29SRSBXRyBWaXJ0dWFsIEludGVyaW0gMjAyMS0wNC0yODxicj4NCjxi cj4NCkRlYXIgYWxsLDxicj4NCjxicj4NCkp1c3QgYSByZW1pbmRlciB0aGF0IHdlIGFyZSBoYXZp bmcgb3VyIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIGluIDxicj4NCnNsaWdodGx5IGxlc3MgdGhh biAyIGhvdXJzIFsxXS48YnI+DQo8YnI+DQpQbGVhc2UgZmluZCBiZWxvdyB0aGUgaW5mb3JtYXRp b24gdG8gam9pbi48YnI+DQo8YnI+DQpCZXN0LDxicj4NCk1hcmNvIGFuZCBKYWltZTxicj4NCjxi cj4NClsxXSA8YSBocmVmPSJodHRwczovL2V1cjAyLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRm1lZXRpbmcl MkZpbnRlcmltLTIwMjEtY29yZS0wNCUyRnNlc3Npb24lMkZjb3JlJmFtcDthbXA7ZGF0YT0wNCU3 QzAxJTdDcmlrYXJkLmhvZ2x1bmQlNDByaS5zZSU3Q2U4M2JjODUwZGU1MTQzMmJmMzJmMDhkOTBh ZjU0Y2FjJTdDNWE5ODA5Y2YwYmNiNDEzYTgzOGEwOWVjYzQwY2M5ZTglN0MwJTdDMCU3QzYzNzU1 Mjg3MDkzNTY2NDYyOCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURB aUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFt cDthbXA7c2RhdGE9WGJLb0FXTUhYY0JPV2VQZXFtcDFhZXY4JTJCMVRlTmJsdiUyRnh5ODhXYzE0 UzAlM0QmYW1wO2FtcDtyZXNlcnZlZD0wIj4NCmh0dHBzOi8vZXVyMDIuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3Jn JTJGbWVldGluZyUyRmludGVyaW0tMjAyMS1jb3JlLTA0JTJGc2Vzc2lvbiUyRmNvcmUmYW1wO2Ft cDtkYXRhPTA0JTdDMDElN0NyaWthcmQuaG9nbHVuZCU0MHJpLnNlJTdDZTgzYmM4NTBkZTUxNDMy YmYzMmYwOGQ5MGFmNTRjYWMlN0M1YTk4MDljZjBiY2I0MTNhODM4YTA5ZWNjNDBjYzllOCU3QzAl N0MwJTdDNjM3NTUyODcwOTM1NjY0NjI4JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9p TUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUz RCU3QzEwMDAmYW1wO2FtcDtzZGF0YT1YYktvQVdNSFhjQk9XZVBlcW1wMWFldjglMkIxVGVOYmx2 JTJGeHk4OFdjMTRTMCUzRCZhbXA7YW1wO3Jlc2VydmVkPTA8L2E+PGJyPg0KPGJyPg0KPGJyPg0K PT09IE1lZXRpbmcgSW5mb3JtYXRpb24gPT09PGJyPg0KPGJyPg0KSmFiYmVyOiBjb3JlQGphYmJl ci5pZXRmLm9yZzxicj4NCjxicj4NCkV0aGVycGFkOiA8YSBocmVmPSJodHRwczovL2V1cjAyLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZjb2RpbWQu aWV0Zi5vcmclMkZub3Rlcy1pZXRmLWludGVyaW0tMjAyMS1jb3JlLTA0LWNvcmUmYW1wO2FtcDtk YXRhPTA0JTdDMDElN0NyaWthcmQuaG9nbHVuZCU0MHJpLnNlJTdDZTgzYmM4NTBkZTUxNDMyYmYz MmYwOGQ5MGFmNTRjYWMlN0M1YTk4MDljZjBiY2I0MTNhODM4YTA5ZWNjNDBjYzllOCU3QzAlN0Mw JTdDNjM3NTUyODcwOTM1NjY0NjI4JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0 d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3 QzEwMDAmYW1wO2FtcDtzZGF0YT1qeGdzVUptJTJGVUtSSkxyYTV0emlBS1oweWtqMyUyQkRCWnVB Tk5mcEZxJTJCOGpjJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MCI+DQpodHRwczovL2V1cjAyLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZjb2RpbWQuaWV0 Zi5vcmclMkZub3Rlcy1pZXRmLWludGVyaW0tMjAyMS1jb3JlLTA0LWNvcmUmYW1wO2FtcDtkYXRh PTA0JTdDMDElN0NyaWthcmQuaG9nbHVuZCU0MHJpLnNlJTdDZTgzYmM4NTBkZTUxNDMyYmYzMmYw OGQ5MGFmNTRjYWMlN0M1YTk4MDljZjBiY2I0MTNhODM4YTA5ZWNjNDBjYzllOCU3QzAlN0MwJTdD NjM3NTUyODcwOTM1NjY0NjI4JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xq QXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEw MDAmYW1wO2FtcDtzZGF0YT1qeGdzVUptJTJGVUtSSkxyYTV0emlBS1oweWtqMyUyQkRCWnVBTk5m cEZxJTJCOGpjJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MDwvYT48YnI+DQo8YnI+DQpNZWV0aW5nIGxp bms6IDxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZXVyMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmlldGYud2ViZXguY29tJTJGaWV0ZiUyRmoucGhw JTNGTVRJRCUzRG04ODhhOTkwNzYwNDI1MjcxYTEzMjdmNTNjNjcxNGIwNyZhbXA7YW1wO2RhdGE9 MDQlN0MwMSU3Q3Jpa2FyZC5ob2dsdW5kJTQwcmkuc2UlN0NlODNiYzg1MGRlNTE0MzJiZjMyZjA4 ZDkwYWY1NGNhYyU3QzVhOTgwOWNmMGJjYjQxM2E4MzhhMDllY2M0MGNjOWU4JTdDMCU3QzAlN0M2 Mzc1NTI4NzA5MzU2NjQ2MjglN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpB d01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAw MCZhbXA7YW1wO3NkYXRhPVRHZGFidGR3SDltYWNzZjRHakxIbmJtMUxXQjglMkZ3aFhkJTJCamdB RWFBM2hrJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly9ldXIwMi5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGaWV0Zi53ZWJleC5jb20lMkZp ZXRmJTJGai5waHAlM0ZNVElEJTNEbTg4OGE5OTA3NjA0MjUyNzFhMTMyN2Y1M2M2NzE0YjA3JmFt cDthbXA7ZGF0YT0wNCU3QzAxJTdDcmlrYXJkLmhvZ2x1bmQlNDByaS5zZSU3Q2U4M2JjODUwZGU1 MTQzMmJmMzJmMDhkOTBhZjU0Y2FjJTdDNWE5ODA5Y2YwYmNiNDEzYTgzOGEwOWVjYzQwY2M5ZTgl N0MwJTdDMCU3QzYzNzU1Mjg3MDkzNTY2NDYyOCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpX SWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZN bjAlM0QlN0MxMDAwJmFtcDthbXA7c2RhdGE9VEdkYWJ0ZHdIOW1hY3NmNEdqTEhuYm0xTFdCOCUy RndoWGQlMkJqZ0FFYUEzaGslM0QmYW1wO2FtcDtyZXNlcnZlZD0wPC9hPjxicj4NCjxicj4NCk1l ZXRpbmcgbnVtYmVyOiAxODUgMjQ4IDkyMzE8YnI+DQpQYXNzd29yZDogY29uc3RyYWluZWQ8YnI+ DQo8YnI+DQo8YnI+DQpNb3JlIHdheXMgdG8gam9pbjxicj4NCjxicj4NCkpvaW4gYnkgdmlkZW8g c3lzdGVtPGJyPg0KRGlhbCAxODUyNDg5MjMxQGlldGYud2ViZXguY29tPGJyPg0KWW91IGNhbiBh bHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLjxicj4N Cjxicj4NCkpvaW4gYnkgcGhvbmU8YnI+DQoxLTY1MC00NzktMzIwOCBDYWxsLWluIG51bWJlciAo VVMvQ2FuYWRhKTxicj4NCkFjY2VzcyBjb2RlOiAxODUgMjQ4IDkyMzE8YnI+DQo8YnI+DQo8YnI+ DQpPbiAyMDIxLTA0LTIxIDE4OjA3LCBNYXJjbyBUaWxvY2Egd3JvdGU6PGJyPg0KJmd0OyBEZWFy IGFsbCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBKdXN0IGEgcmVtaW5kZXIgdGhhdCB3ZSdsbCBoYXZl IGEgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcgb24gPGJyPg0KJmd0OyBXZWRuZXNkYXksIEFwcmls IDI4dGggYXQgMTQ6MDAgVVRDLiBUaGUgYWdlbmRhIGlzIGF2YWlsYWJsZSBhdCBbMV0uPGJyPg0K Jmd0Ozxicj4NCiZndDsgQmVzdCw8YnI+DQomZ3Q7IE1hcmNvIGFuZCBKYWltZTxicj4NCiZndDs8 YnI+DQomZ3Q7IFsxXSA8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZXVyMDIuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmll dGYub3JnJTJGbWVldGluZyUyRmludGVyaW0tMjAyMS1jb3JlLTA0JTJGc2Vzc2lvbiUyRmNvcmUm YW1wO2FtcDtkYXRhPTA0JTdDMDElN0NyaWthcmQuaG9nbHVuZCU0MHJpLnNlJTdDZTgzYmM4NTBk ZTUxNDMyYmYzMmYwOGQ5MGFmNTRjYWMlN0M1YTk4MDljZjBiY2I0MTNhODM4YTA5ZWNjNDBjYzll OCU3QzAlN0MwJTdDNjM3NTUyODcwOTM1Njc0NTg1JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5 SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJ Nk1uMCUzRCU3QzEwMDAmYW1wO2FtcDtzZGF0YT14ZFdaVHh2eVFVSHglMkJ0RTFPZkhRYlN6ZEo0 cyUyQmxFUGtvWmpmMHVHU0NTcyUzRCZhbXA7YW1wO3Jlc2VydmVkPTAiPg0KaHR0cHM6Ly9ldXIw Mi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0 YXRyYWNrZXIuaWV0Zi5vcmclMkZtZWV0aW5nJTJGaW50ZXJpbS0yMDIxLWNvcmUtMDQlMkZzZXNz aW9uJTJGY29yZSZhbXA7YW1wO2RhdGE9MDQlN0MwMSU3Q3Jpa2FyZC5ob2dsdW5kJTQwcmkuc2Ul N0NlODNiYzg1MGRlNTE0MzJiZjMyZjA4ZDkwYWY1NGNhYyU3QzVhOTgwOWNmMGJjYjQxM2E4Mzhh MDllY2M0MGNjOWU4JTdDMCU3QzAlN0M2Mzc1NTI4NzA5MzU2NzQ1ODUlN0NVbmtub3duJTdDVFdG cGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFo YVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7YW1wO3NkYXRhPXhkV1pUeHZ5UVVIeCUyQnRF MU9mSFFiU3pkSjRzJTJCbEVQa29aamYwdUdTQ1NzJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MDwvYT48 YnI+DQomZ3Q7PGJyPg0KPGJyPg0KLS0gPGJyPg0KTWFyY28gVGlsb2NhPGJyPg0KUGguRC4sIFNl bmlvciBSZXNlYXJjaGVyPGJyPg0KPGJyPg0KRGl2aXNpb246IERpZ2l0YWwgU3lzdGVtPGJyPg0K RGVwYXJ0bWVudDogQ29tcHV0ZXIgU2NpZW5jZTxicj4NClVuaXQ6IEN5YmVyc2VjdXJpdHk8YnI+ DQo8YnI+DQpSSVNFIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuPGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly9ldXIwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGcHJvdGVjdDIuZmlyZWV5ZS5jb20lMkZ2MSUyRnVybCUzRmslM0Q0YzRhNTk4Ny0x M2QxNjE2NS00YzRhMTkxYy04NjA3M2IzNmVhMjgtMmFkZWMyMWYwMzcyMzc3MSUyNnElM0QxJTI2 ZSUzRGRjNjA5MzMxLTZiMmYtNDkwYy1iNTQ1LWY5MzdjNzAzZjA2NSUyNnUlM0RodHRwcyUyNTNB JTI1MkYlMjUyRnd3dy5yaS5zZSUyNTJGJmFtcDthbXA7ZGF0YT0wNCU3QzAxJTdDcmlrYXJkLmhv Z2x1bmQlNDByaS5zZSU3Q2U4M2JjODUwZGU1MTQzMmJmMzJmMDhkOTBhZjU0Y2FjJTdDNWE5ODA5 Y2YwYmNiNDEzYTgzOGEwOWVjYzQwY2M5ZTglN0MwJTdDMCU3QzYzNzU1Mjg3MDkzNTY3NDU4NSU3 Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16 SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDthbXA7c2RhdGE9NGow MGNFdHRCVGp5WEdabHFjU1FjN0ExalBOcWgxJTJGc1RHSVM0QzJrQnBVJTNEJmFtcDthbXA7cmVz ZXJ2ZWQ9MCI+aHR0cHM6Ly9ldXIwMi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGcHJvdGVjdDIuZmlyZWV5ZS5jb20lMkZ2MSUyRnVybCUzRmslM0Q0 YzRhNTk4Ny0xM2QxNjE2NS00YzRhMTkxYy04NjA3M2IzNmVhMjgtMmFkZWMyMWYwMzcyMzc3MSUy NnElM0QxJTI2ZSUzRGRjNjA5MzMxLTZiMmYtNDkwYy1iNTQ1LWY5MzdjNzAzZjA2NSUyNnUlM0Ro dHRwcyUyNTNBJTI1MkYlMjUyRnd3dy5yaS5zZSUyNTJGJmFtcDthbXA7ZGF0YT0wNCU3QzAxJTdD cmlrYXJkLmhvZ2x1bmQlNDByaS5zZSU3Q2U4M2JjODUwZGU1MTQzMmJmMzJmMDhkOTBhZjU0Y2Fj JTdDNWE5ODA5Y2YwYmNiNDEzYTgzOGEwOWVjYzQwY2M5ZTglN0MwJTdDMCU3QzYzNzU1Mjg3MDkz NTY3NDU4NSU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJ am9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDthbXA7 c2RhdGE9NGowMGNFdHRCVGp5WEdabHFjU1FjN0ExalBOcWgxJTJGc1RHSVM0QzJrQnBVJTNEJmFt cDthbXA7cmVzZXJ2ZWQ9MDwvYT48YnI+DQo8YnI+DQpQaG9uZTogKzQ2ICgwKTcwIDYwIDQ2IDUw MTxicj4NCklzYWZqb3Jkc2dhdGFuIDIyIC8gS2lzdGFnw6VuZ2VuIDE2PGJyPg0KU0UtMTY0IDQw IEtpc3RhIChTd2VkZW4pPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpjb3JlIG1haWxpbmcgbGlzdDxicj4N CmNvcmVAaWV0Zi5vcmc8YnI+DQo8YSBocmVmPSJodHRwczovL2V1cjAyLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWls bWFuJTJGbGlzdGluZm8lMkZjb3JlJmFtcDthbXA7ZGF0YT0wNCU3QzAxJTdDcmlrYXJkLmhvZ2x1 bmQlNDByaS5zZSU3Q2U4M2JjODUwZGU1MTQzMmJmMzJmMDhkOTBhZjU0Y2FjJTdDNWE5ODA5Y2Yw YmNiNDEzYTgzOGEwOWVjYzQwY2M5ZTglN0MwJTdDMCU3QzYzNzU1Mjg3MDkzNTY3NDU4NSU3Q1Vu a25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlM Q0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDthbXA7c2RhdGE9bFpiSW9B UTNYNHBPVjVpayUyQjVHMmFkJTJGYzBFcUZyJTJCbWI5OG10MkVpYWx6USUzRCZhbXA7YW1wO3Jl c2VydmVkPTAiPmh0dHBzOi8vZXVyMDIuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmNv cmUmYW1wO2FtcDtkYXRhPTA0JTdDMDElN0NyaWthcmQuaG9nbHVuZCU0MHJpLnNlJTdDZTgzYmM4 NTBkZTUxNDMyYmYzMmYwOGQ5MGFmNTRjYWMlN0M1YTk4MDljZjBiY2I0MTNhODM4YTA5ZWNjNDBj YzllOCU3QzAlN0MwJTdDNjM3NTUyODcwOTM1Njc0NTg1JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNk OGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pY VkNJNk1uMCUzRCU3QzEwMDAmYW1wO2FtcDtzZGF0YT1sWmJJb0FRM1g0cE9WNWlrJTJCNUcyYWQl MkZjMEVxRnIlMkJtYjk4bXQyRWlhbHpRJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MDwvYT48YnI+DQo8 L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM9P189MB1571B8F076D8C99862FD3C3283599AM9P189MB1571EURP_-- From nobody Wed May 5 01:00:28 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 5526A3A16C2; Wed, 5 May 2021 01:00:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-core-new-block@ietf.org, core-chairs@ietf.org, core@ietf.org, marco.tiloca@ri.se, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <162020162632.31228.3329646750403522840@ietfa.amsl.com> Date: Wed, 05 May 2021 01:00:26 -0700 Archived-At: Subject: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and 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, 05 May 2021 08:00:26 -0000 Lars Eggert has entered the following ballot position for draft-ietf-core-new-block-11: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The current CORE charter does not seem to cover the topic of this document. I also see no related milestone. Section 1, paragraph 4, discuss: > There is a requirement for these blocks of data to be transmitted at > higher rates under network conditions where there may be asymmetrical > transient packet loss (i.e., responses may get dropped). An example > is when a network is subject to a Distributed Denial of Service > (DDoS) attack and there is a need for DDoS mitigation agents relying > upon CoAP to communicate with each other (e.g., > [RFC8782][I-D.ietf-dots-telemetry]). As a reminder, [RFC7959] I understand that COAP was initially chosen to transport DOTS signaling messages due to their small size, support for structured messages and request/response semantics, as well as the ability to function over lossy paths such as found in IoT deployment, which COAP is architected for. DOTS now seems to desire to transport larger messages, and this document extends CORE to enable this functionality. However, this CORE extension seems to solely focus on Internet deployment scenarios, essentially attempting to re-architect COAP into a general Internet transport protocol for transmission over paths with high loss rates. I do not believe that the CORE WG is chartered to do this. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools, so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 1, paragraph 3, nit: > ell in environments where there are no or minimal packet losses. These optio > ^^ Did you mean "now" (=at this moment) instead of 'no' (negation)? Section 3, paragraph 16, nit: > ed by the peer whether the body comprises of a single or multiple payloads a > ^^^^^^^^^^^^ Did you mean "comprises" or "consists of"? Section 4.1, paragraph 18, nit: > T be included as Inner options. Similarly there MUST NOT be a mix of Q-Block > ^^^^^^^^^ Did you forget a comma after a conjunctive/linking adverb? Section 4.3, paragraph 3, nit: > -Tag value MUST be the same for all of the requests for the body of data tha > ^^^^^^^^^^ Consider using "all the". Section 4.3, paragraph 3, nit: > ue, the server still treats it as opaque but the client MUST ensure that it i > ^^^^^^ Use a comma before 'but' if it connects two independent clauses (unless they are closely connected and short). Section 4.3, paragraph 6, nit: > not arrived after a timeout and a retransmit missing payloads response is n > ^^^^^^^^^^^^ After 'a', do not use a verb. Make sure that the spelling of 'retransmit' is correct. If 'retransmit' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 4.3, paragraph 6, nit: > a timeout and a retransmit missing payloads response is needed. For reliabl > ^^^^^^^^ An apostrophe may be missing. Section 4.3, paragraph 11, nit: > g. The client should then release all of the tokens used for this body. Note > ^^^^^^^^^^ Consider using "all the". Section 4.3, paragraph 13, nit: > t. The client should then release all of the tokens used for this body. 2 > ^^^^^^^^^^ Consider using "all the". Section 4.3, paragraph 15, nit: > quest. The client should then release all of the tokens used for this body. > ^^^^^^^^^^ Consider using "all the". Section 4.3, paragraph 18, nit: > The client should then release all of the tokens used for this body unless > ^^^^^^^^^^ Consider using "all the". Section 4.3, paragraph 20, nit: > e Code can be used to indicate that all of the blocks up to and including th > ^^^^^^^^^^ Consider using "all the". Section 4.3, paragraph 30, nit: > ing-blocks+cbor-seq" indicates that some of the payloads are missing and need > ^^^^^^^^^^^ If the text is a generality, 'of the' is not necessary. Section 4.4, paragraph 4, nit: > a request for that block and for all of the remaining blocks in the current > ^^^^^^^^^^^^^^^^ Consider using "all the". Section 4.4, paragraph 7, nit: > paque, the client still treats it as opaque but the server MUST ensure that i > ^^^^^^ Use a comma before 'but' if it connects two independent clauses (unless they are closely connected and short). Section 4.4, paragraph 16, nit: > , the client should then release all of the tokens used for this body unless > ^^^^^^^^^^ Consider using "all the". Section 4.5, paragraph 1, nit: > r a request that uses Q-Block1, the Observe value [RFC7641] MUST be the same > ^^^^^^^^^^^ After 'the', do not use a verb. Make sure that the spelling of 'Observe' is correct. If 'Observe' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 4.5, paragraph 2, nit: > a response that uses Q-Block2, the Observe value MUST be the same for all t > ^^^^^^^^^^^ After 'the', do not use a verb. Make sure that the spelling of 'Observe' is correct. If 'Observe' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 4.5, paragraph 3, nit: > ferent from Block2 usage where the Observe value is only present in the firs > ^^^^^^^^^^^ After 'the', do not use a verb. Make sure that the spelling of 'Observe' is correct. If 'Observe' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 5, paragraph 2, nit: > that the server has not received all of the blocks of the request body that > ^^^^^^^^^^ Consider using "all the". Section 5, paragraph 4, nit: > as a CBOR Sequence [RFC8742]. It comprises of one or more missing block numb > ^^^^^^^^^^^^ Did you mean "comprises" or "consists of"? Section 5, paragraph 6, nit: > sing blocks is as follows: ; A notional array, the elements of which > ^ Loose punctuation mark. Section 7.1, paragraph 2, nit: > It is implementation specific as to whether there should be any further req > ^^^^^^^^^^^^^ Consider shortening this phrase to just "whether", or rephrase the sentence to avoid "as to". Section 7.2, paragraph 9, nit: > D consider the body stale, remove any body, and release Tokens and Request-T > ^^^^^^^^ Did you mean "anybody"? Section 7.2, paragraph 10, nit: > limit the potential wait needed calculated when using PROBING_WAIT. NON_PROB > ^^^^^^^^^^ "needed calculated" is only accepted in certain dialects. For something more widely acceptable, consider "to be calculated". Section 7.2, paragraph 14, nit: > G_WAIT. Note: For the particular DOTS application, PROBING_RATE and other > ^^^^ An apostrophe may be missing. Section 7.2, paragraph 15, nit: > s. Even when not negotiated, the DOTS application uses customized defaults as > ^^^^ An apostrophe may be missing. Section 7.2, paragraph 19, nit: > rived for each body for at least a 24 hour period and it is known that there > ^^^^^^^ When a number forms part of an adjectival compound, use a hyphen: "24-hour" Section 7.2, paragraph 19, nit: > each body for at least a 24 hour period and it is known that there are no ot > ^^^^^^^^^^ Use a comma before 'and' if it connects two independent clauses (unless they are closely connected and short). Section 7.2, paragraph 19, nit: > situation re-evaluated for another 24 hour period until there is no report > ^^^^^^^ It appears that a hyphen is missing. Section 7.2, paragraph 19, nit: > PAYLOADS values, a peer may continue indicate that there are some missing pa > ^^^^^^^^^^^^^^^^^ Probably a preposition is missing after 'continue'. Section 7.2, paragraph 22, nit: > tinue) Response Code on receipt of all of the MAX_PAYLOADS payloads to preven > ^^^^^^^^^^ Consider using "all the". Section 7.2, paragraph 22, nit: > t unnecessarily delaying. If not all of the MAX_PAYLOADS payloads were receiv > ^^^^^^^^^^^^^ Consider using "all the". Section 7.2, paragraph 24, nit: > xt set of payloads on receipt of all of the MAX_PAYLOADS payloads to prevent > ^^^^^^^^^^ Consider using "all the". Section 7.2, paragraph 24, nit: > e server unnecessarily delaying. Otherwise the client SHOULD delay for NON_R > ^^^^^^^^^ Did you forget a comma after a conjunctive/linking adverb? Section 10.1.3, paragraph 5, nit: > - Tag by matching the token with the sent request. CoAP CoAP > ^^^^ Did you mean "scent"? Section 10.2, paragraph 2, nit: > n is not required for Q-Block2; the observe detail can thus be ignored. 10.2 > ^^^^^^^^^^^ After 'the', do not use a verb. Make sure that the spelling of 'observe' is correct. If 'observe' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 10.2.1, paragraph 2, nit: > The same process is repeated when an Observe is triggered, but no loss is ex > ^^^^^^^^^^ After 'an', do not use a verb. Make sure that the spelling of 'Observe' is correct. If 'Observe' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 10.2.3, paragraph 1, nit: > y Figure 10 shows the example of an Observe that is triggered but for which s > ^^^^^^^^^^ After 'an', do not use a verb. Make sure that the spelling of 'Observe' is correct. If 'Observe' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 10.2.4, paragraph 1, nit: > t Figure 11 shows the example of an Observe that is triggered but only the fi > ^^^^^^^^^^ After 'an', do not use a verb. Make sure that the spelling of 'Observe' is correct. If 'Observe' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 10.3.3, paragraph 5, nit: > t-Tag by matching the token with the sent request. CoAP CoAP C > ^^^^ Did you mean "scent"? Section 12.3, paragraph 3, nit: > blocks+cbor-seq o Encoding: - o Id: TBA3 o Reference: [RFCXXXX] Th > ^^ Possible spelling mistake found Section 13.2, paragraph 4, nit: > try] Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c., > ^ Add a space between sentences Section 13.2, paragraph 9, nit: > org/info/rfc8610>. [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P > ^ Add a space between sentences "A.1.", paragraph 7, nit: > It is up to the implementation as to whether the application process stops t > ^^^^^^^^^^^^^ Consider shortening this phrase to just "whether", or rephrase the sentence to avoid "as to". "A.2.", paragraph 4, nit: > It is up to the implementation as to whether the application process stops t > ^^^^^^^^^^^^^ Consider shortening this phrase to just "whether", or rephrase the sentence to avoid "as to". "B.1.", paragraph 1, nit: > use of Q-Block1 Option with a reliable transport as shown in Figure 20. Ther > ^^^^^^^^^^^^^^^^^^^^^^^ Uncountable nouns are usually not used with an indefinite article. Use simply "reliable transport". "B.1.", paragraph 2, nit: > shown in Figure 20. There is no acknowledgment of packets at the CoAP layer, > ^^^^^^^^^^^^^^ Do not mix variants of the same word ('acknowledgment' and 'acknowledgement') within a single text. "B.2.", paragraph 1, nit: > of the use of Q-Block2 Option with a reliable transport is shown in Figure > ^^^^^^^^^^^^^^^^^^^^ Uncountable nouns are usually not used with an indefinite article. Use simply "reliable transport". Document references draft-ietf-core-echo-request-tag-11, but draft-ietf-core-echo-request-tag-12 is the latest available revision. From nobody Wed May 5 01:01: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 61E2F3A16C9; Wed, 5 May 2021 01:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLltb1saYfMy; Wed, 5 May 2021 01:01:16 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 B38CA3A16C6; Wed, 5 May 2021 01:01:15 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:54ca:2d0:fd87:7c95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 952D6600353; Wed, 5 May 2021 11:01:06 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1620201666; bh=vmMADrZLs70Xap2SfOpv8Yq7ai9AKHozU7tfr0+gigM=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Z4edYMadZ/iyA5RO6uScyq5V6kEf6oTw8ze0HK+jChpvqVzYo3cngVYi/ODh6j90y xKVDmiVoOkUG+AZami4ii0zg5UHaZtPR+2PKX1ztpG/56qbP63NaF8j49dBA3f/+PA PGL4+bhMdTyPcdUsiKfu0iixmTFAlogNTYR6JrXU= From: Lars Eggert Message-Id: <7C241E58-84B1-4D11-88A3-B602CD547C3A@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_FBDE6074-B569-40D3-8285-FAD08225BE51"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Wed, 5 May 2021 11:01:03 +0300 In-Reply-To: <161930002269.19583.4502578348808948027@ietfa.amsl.com> Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-core-new-block.all@ietf.org, core@ietf.org To: Pete Resnick References: <161930002269.19583.4502578348808948027@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-MailScanner-ID: 952D6600353.A0E68 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [core] [Gen-art] Genart last call review of draft-ietf-core-new-block-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 08:01:21 -0000 --Apple-Mail=_FBDE6074-B569-40D3-8285-FAD08225BE51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Pete, thank you for your review and thank you all for the following = discussion. I have entered a Discuss ballot for this document based on = my own review. Lars On 2021-4-25, at 0:33, Pete Resnick via Datatracker = wrote: >=20 > Reviewer: Pete Resnick > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-core-new-block-10 > Reviewer: Pete Resnick > Review Date: 2021-04-24 > IETF LC End Date: 2021-04-28 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: >=20 > The document looks pretty solid to me. There is one item I marked as a = minor > "issue", but it may simply be an editorial item that confused me; I = figured I'd > call it an issue just in case so it doesn't get left to the last = minute to look > at. >=20 > Do note that I have not reviewed the examples for correctness; I = simply don't > have the expertise to be convinced I'd do it right. >=20 > Major issues: >=20 > None. >=20 > Minor issues: >=20 > In section 4.4: >=20 > I find this paragraph confusing: >=20 > The requested missing block numbers MUST have an increasing block > number in each additional Q-Block2 Option with no duplicates. The > server SHOULD respond with a 4.00 (Bad Request) to requests not > adhering to this behavior. >=20 > So, given the SHOULD in the second sentence, it appears that the MUST = in the > first sentence doesn't apply to the server (i.e., to enforce this), = but rather > to the client doing the request. You should probably say it that way. = Also, the > SHOULD in the second sentence is not entirely clear to me: Are you = saying that > the server can choose to use some other response code, or are you = saying that > the server can accept the request and do something interesting with = it? Below > is an attempt to fix it, but might not be correct depending on what = you mean: >=20 > The client MUST use an increasing block number in each additional > Q-Block2 Option when requesting missing block numbers, and MUST > request no duplicates. The server MUST reject requests not = adhering > to this behavior and SHOULD respond with a 4.00 (Bad Request) to = such > requests. >=20 > There are other places in the document that use MUST with regard to = what needs > to be in a piece of data (see for example sections 4.5 and 4.6), but = don't make > it clear who is responsible for enforcing that MUST (the client or the = server). > You should read through the entire document for MUSTs (or SHOULDs) = like that > and make sure it's clear from the context. >=20 > Nits/editorial comments: >=20 > In section 4.3: >=20 > In several response code definitions: >=20 > The token used MUST be any token that was received in a request = using > the same Request-Tag. >=20 > That doesn't really parse well. I think you either mean "The token = used MUST be > a token" or you mean "The token used can be any token". >=20 > Specific response codes: >=20 > 4.00 (Bad Request) >=20 > This Response Code MUST be returned if the request does not > include neither a Request-Tag Option nor a Size1 Option but does > include a Q-Block1 option. >=20 > Either change "neither...nor" to "either or", or change "does not = include" to > "includes". >=20 > 4.02 (Bad Option) >=20 > 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-Block Options. >=20 > That sort of buries a MUST requirement for the Non-confirmable case = inside this > requirement for a Response Code. I suggest instead: >=20 > This Response Code MUST be returned for a Confirmable request if > the server does not support the Q-Block Options. (A reset message > is sent in case of Non-confirmable request.) >=20 > In section 4.4: >=20 > The passive here is not great form, particularly because it doesn't = name the > actor: >=20 > It is permissible to set the M bit to request this... >=20 > How about instead: >=20 > The client MAY set the M bit to request this... >=20 > Maybe that's obvious, since the client does the requesting, but I = think the > non-passive form is easier to read. >=20 > In the second to last paragraph: >=20 > If the server transmits a new body of data (e.g., a triggered = Observe > notification) 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. >=20 > I'm ambivalent about whether that "should" ought to be uppercased, but = I just > wanted to make sure you intended the lowercase. >=20 > In section 7.2: >=20 > For the server receiving NON Q-Block1 requests, it SHOULD send back = a > 2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS > payloads to prevent the client unnecessarily delaying. Otherwise... >=20 > When you say "Otherwise", Do you mean, "For other payloads"? Either = way, you > should probably change that to make it clear. >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_FBDE6074-B569-40D3-8285-FAD08225BE51 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmCSUL8ACgkQVLXDCb9w wVfltxAArHqnngqLxWXt4uhNxZdIkEllcZv6LvJVnroQvxjdnwuTuncWfEqgnhBJ M0YzHjWM41+RviaIHA88PhZjaKGBGb8Y2iigOqckAwildjj+paIdcpZZOWvjUYVD VgV1Q7v3onzXMiu39irrSsnL/t6WQ+18EPQTc0LK6+m0oo6+0N+7Ijh754UFeoi2 05r6YjJfSmDhVr1Ys6ioQnkh1HIveM/YTK11e3Sp3aZxGniXAl/hWDVWgx9/nBhN Z0viBcylT6X1hQULraLJ+fS8ZIEr+UfQNspiFRvucyWCH8r/pBg85UI2RobM4ftR dxZZDG5L4Ps63DqDBKiFtAWgMF4etdFgWGJ3aIQs8LEbNWpwmUunW/UZ88ZlMTBK csWD5kNtE8nlZK9wnP2X+ibVkbNK9520RaIqW6j59EytyG6rIzp8M2mopdx90pUy KtP6dXDi7IhKhBrKsqnoc9UklwwIgICcHgnbErM/y9NvQ35t7zT/SoGqmUv2NwGl 3A5gpPNY5nUg86yBFMLbk2qFBzC1J673YP/CXWpVbi/tJspbK/egJdJFdnYJXcY+ iwPqW6P6gruPQ/XcMTfL4zN6RHN3tx5HnYHVb6Eg+U/NLsC0rFxP8ummAbkJcPpw 8SvOxYF1RiIQGLLqdxG4Y0rp94RHN+UhwdmC1lAnaPN0pPegN9c= =nQZT -----END PGP SIGNATURE----- --Apple-Mail=_FBDE6074-B569-40D3-8285-FAD08225BE51-- From nobody Wed May 5 02:02: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 49D023A18F5; Wed, 5 May 2021 02:02:24 -0700 (PDT) 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 7Vqe2YErHplP; Wed, 5 May 2021 02:02:19 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (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 D8AD93A18F3; Wed, 5 May 2021 02:02:18 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 4FZrLw5FTczBrjy; Wed, 5 May 2021 11:02:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620205336; bh=G2rMWovlfsJQZNFqoIReubU+QAiXOod0Tp0d2cbUWkc=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=fKvjvvmGOwnJkrA7ypTHIhlqTfhXr8/sO7lbigru+/HVqPaWk0UpF8AG4aYBeg8jA TtK/8LHT6CHTrRaZUcORrabb0uCPz3Oq/RkMqZkWIrKORW006VTiTZB8lU1Q99evHb OExtPTVM68+NhPluK1VyW0Nme2/4YsoT+IdQXY7Zlbi6YP8P8U/tLfNrD4nyQ0k7aY FKWS2GDPoCHK1Vt/F8bNyC/kxDVPBRX9Tq5+Syof1hYp2ZTjRZUQKbRUrFv/obRIrK NR1akojQmqOcZTZaUjXFEEQXS0DnA3EimoK3gs3TWcQ1OODxLduX39z556earzu80B /xR2J0CNvLc0g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4FZrLw3cTQz2xCG; Wed, 5 May 2021 11:02:16 +0200 (CEST) From: To: Lars Eggert , The IESG CC: "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXQYS466xRZE0VFEm3pHYwmGElFKrUjd9w Date: Wed, 5 May 2021 09:02:15 +0000 Message-ID: <18631_1620205336_60925F18_18631_96_1_787AE7BB302AE849A7480A190F8B933035376CCC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162020162632.31228.3329646750403522840@ietfa.amsl.com> In-Reply-To: <162020162632.31228.3329646750403522840@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (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: Wed, 05 May 2021 09:02:24 -0000 SGkgTGFycywgYWxsLCANCg0KUGxlYXNlIHNlZSBpbmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0K PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogTGFycyBFZ2dlcnQgdmlhIERh dGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10NCj4gRW52b3nDqcKgOiBtZXJjcmVk aSA1IG1haSAyMDIxIDEwOjAwDQo+IMOAwqA6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBD Y8KgOiBkcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrQGlldGYub3JnOyBjb3JlLWNoYWlyc0BpZXRm Lm9yZzsNCj4gY29yZUBpZXRmLm9yZzsgbWFyY28udGlsb2NhQHJpLnNlOyBtYXJjby50aWxvY2FA cmkuc2UNCj4gT2JqZXTCoDogTGFycyBFZ2dlcnQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtY29y ZS1uZXctYmxvY2stMTE6ICh3aXRoDQo+IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBMYXJz IEVnZ2VydCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4g ZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay0xMTogRGlzY3Vzcw0KPiANCj4gV2hlbiByZXNwb25k aW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxs DQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVl bCBmcmVlIHRvIGN1dA0KPiB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0K PiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRl bWVudC9kaXNjdXNzLQ0KPiBjcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVu dCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToN Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLW5ldy1i bG9jay8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0NCj4gRElTQ1VTUzoNCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IC0NCj4gDQo+IFRoZSBjdXJyZW50IENPUkUgY2hhcnRlciBkb2VzIG5vdCBz ZWVtIHRvIGNvdmVyIHRoZSB0b3BpYyBvZiB0aGlzDQo+IGRvY3VtZW50LiBJIGFsc28gc2VlIG5v IHJlbGF0ZWQgbWlsZXN0b25lLg0KPiANCj4gU2VjdGlvbiAxLCBwYXJhZ3JhcGggNCwgZGlzY3Vz czoNCj4gPiAgICBUaGVyZSBpcyBhIHJlcXVpcmVtZW50IGZvciB0aGVzZSBibG9ja3Mgb2YgZGF0 YSB0byBiZQ0KPiB0cmFuc21pdHRlZCBhdA0KPiA+ICAgIGhpZ2hlciByYXRlcyB1bmRlciBuZXR3 b3JrIGNvbmRpdGlvbnMgd2hlcmUgdGhlcmUgbWF5IGJlDQo+IGFzeW1tZXRyaWNhbA0KPiA+ICAg IHRyYW5zaWVudCBwYWNrZXQgbG9zcyAoaS5lLiwgcmVzcG9uc2VzIG1heSBnZXQgZHJvcHBlZCku ICBBbg0KPiBleGFtcGxlDQo+ID4gICAgaXMgd2hlbiBhIG5ldHdvcmsgaXMgc3ViamVjdCB0byBh IERpc3RyaWJ1dGVkIERlbmlhbCBvZiBTZXJ2aWNlDQo+ID4gICAgKEREb1MpIGF0dGFjayBhbmQg dGhlcmUgaXMgYSBuZWVkIGZvciBERG9TIG1pdGlnYXRpb24gYWdlbnRzDQo+IHJlbHlpbmcNCj4g PiAgICB1cG9uIENvQVAgdG8gY29tbXVuaWNhdGUgd2l0aCBlYWNoIG90aGVyIChlLmcuLA0KPiA+ ICAgIFtSRkM4NzgyXVtJLUQuaWV0Zi1kb3RzLXRlbGVtZXRyeV0pLiAgQXMgYSByZW1pbmRlciwg W1JGQzc5NTldDQo+IA0KPiBJIHVuZGVyc3RhbmQgdGhhdCBDT0FQIHdhcyBpbml0aWFsbHkgY2hv c2VuIHRvIHRyYW5zcG9ydCBET1RTDQo+IHNpZ25hbGluZyBtZXNzYWdlcyBkdWUgdG8gdGhlaXIg c21hbGwgc2l6ZSwgc3VwcG9ydCBmb3Igc3RydWN0dXJlZA0KPiBtZXNzYWdlcyBhbmQgcmVxdWVz dC9yZXNwb25zZSBzZW1hbnRpY3MsIGFzIHdlbGwgYXMgdGhlIGFiaWxpdHkgdG8NCj4gZnVuY3Rp b24gb3ZlciBsb3NzeSBwYXRocyBzdWNoIGFzIGZvdW5kIGluIElvVCBkZXBsb3ltZW50LCB3aGlj aCBDT0FQDQo+IGlzIGFyY2hpdGVjdGVkIGZvci4NCj4gDQo+IERPVFMgbm93IHNlZW1zIHRvIGRl c2lyZSB0byB0cmFuc3BvcnQgbGFyZ2VyIG1lc3NhZ2VzLA0KDQpbTWVkXSBJdCBpcyB0cnVlIHRo YXQgRE9UUyB3YXMgZGVzaWduZWQgd2l0aCBjb21wYWN0IG1lc3NhZ2VzIGluIG1pbmQsIGJ1dCBo YW5kbGluZyBsYXJnZSBkYXRhIHdhcyAqKmFscmVhZHkqKiBjb3ZlcmVkIGluIHRoZSBET1RTIHNw ZWMgKHNlZSBTZWN0aW9uIDQuNC4yIG9mIFJGQzg3ODIpLiBXZSB0aGVuIGZvdW5kIHRoYXQgdGhl IG5vcm1hbCBibG9jay13aXNlIG1lY2hhbmlzbSBpcyBzdWJvcHRpbWFsIGZvciB0aGUgRE9UUyBh cHBsaWNhdGlvbi4NCg0KIGFuZCB0aGlzDQo+IGRvY3VtZW50IGV4dGVuZHMgQ09SRSB0byBlbmFi bGUgdGhpcyBmdW5jdGlvbmFsaXR5LiBIb3dldmVyLCB0aGlzDQo+IENPUkUgZXh0ZW5zaW9uIHNl ZW1zIHRvIHNvbGVseSBmb2N1cyBvbiBJbnRlcm5ldCBkZXBsb3ltZW50DQo+IHNjZW5hcmlvcywg ZXNzZW50aWFsbHkgYXR0ZW1wdGluZyB0byByZS1hcmNoaXRlY3QgQ09BUCBpbnRvIGEgZ2VuZXJh bA0KPiBJbnRlcm5ldCB0cmFuc3BvcnQgcHJvdG9jb2wgZm9yIHRyYW5zbWlzc2lvbiBvdmVyIHBh dGhzIHdpdGggaGlnaA0KPiBsb3NzIHJhdGVzLiBJIGRvIG5vdCBiZWxpZXZlIHRoYXQgdGhlIENP UkUgV0cgaXMgY2hhcnRlcmVkIHRvIGRvDQo+IHRoaXMuDQo+IA0KDQpbTWVkXSBUaGlzIHdvcmsg aXMgcGFydCBvZiB0aGUgbWFpbnRlbmFuY2Ugb2YgUkZDNzk1OSB0aGF0IGlzIGNvdmVyZWQgYnkg dGhlIGNvcmUgV0cgY2hhcnRlcjoNCg0KPT0NClRoZSB3b3JraW5nIGdyb3VwIHdpbGwgcGVyZm9y bSBtYWludGVuYW5jZSBvbiBpdHMgZmlyc3QgZm91cg0Kc3RhbmRhcmRzLXRyYWNrIHNwZWNpZmlj YXRpb25zOg0KPT0NCg0KQXMgeW91IGNhbiByZWFkIGluIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL21pbnV0ZXMtaW50ZXJpbS0yMDIwLWNvcmUtMDYtMjAyMDA2MTAxNjAwLywgdGhl IFdHIGRlY2lkZWQgdG86DQoic2NvcGUgaXQgYXMgYW4gZXh0ZW5zaW9uIChhcyBvcHBvc2VkIHRv IGJsb2Nrd2lzZS1iaXMpIi4NCg0KVGhlIHBsYW4gaXMgdG8gdXNlIHRoaXMgZXh0ZW5zaW9uIGFz IHRoZSBiYXNlIGZvciBhIGJpcyB3aGVuIHRoZSBXRyB3aWxsIGJlIHJlYWR5IHRvIGNvdmVyIG90 aGVyIGFzcGVjdHMgdGhhdCBhcmUgbGVmdCBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZXh0ZW5zaW9u LiBTZWUsIGUuZy4sIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL21pbnV0ZXMtMTEw LWNvcmUtMjAyMTAzMTIxMzAwLzogIml0IGNhbiBiZSBzZW1pbmFsIG1hdGVyaWFsIGZvciBhIGJs b2Nrd2lzZSBiaXMgZG9jdW1lbnQiLg0KDQpJIGxldCB0aGUgQUQgYW5kIHRoZSBjaGFpcnMgZnVy dGhlciBlbGFib3JhdGUgb24gdGhlIGNoYXJ0ZXIgcG9pbnQuDQoNCg0KCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsg eW91LgoK From nobody Wed May 5 03:05:42 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 03D543A0BD7; Wed, 5 May 2021 03:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bW2ApJ2TYMLg; Wed, 5 May 2021 03:05:35 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 E12643A0BD2; Wed, 5 May 2021 03:05:34 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:54ca:2d0:fd87:7c95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id C7948600353; Wed, 5 May 2021 13:05:25 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1620209125; bh=1fIzkmsFymrzmZrK0+MqGBaK7hYEMA2907p71dOFm2k=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=aDsvgZjz+WWYYb/rKcUwPTS323GN4VncOSk+bhuxyj9kpVtbnoB3H2WfkjfIO/9je X96DikGwllKTNM9m+xBmRjusVyivOmvGt3947FGwYc5bsXhiq65+mD9awCaVcFWhnn JW9pTYuJ4oTy0xWZkrDRQ3DP4RwWE7wMzAlfWdos= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_DE96EDC5-5CAB-40B4-9971-BDFB34FCF511"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Wed, 5 May 2021 13:05:23 +0300 In-Reply-To: <18631_1620205336_60925F18_18631_96_1_787AE7BB302AE849A7480A190F8B933035376CCC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Cc: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" To: mohamed.boucadair@orange.com References: <162020162632.31228.3329646750403522840@ietfa.amsl.com> <18631_1620205336_60925F18_18631_96_1_787AE7BB302AE849A7480A190F8B933035376CCC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-MailScanner-ID: C7948600353.AF3E8 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (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: Wed, 05 May 2021 10:05:41 -0000 --Apple-Mail=_DE96EDC5-5CAB-40B4-9971-BDFB34FCF511 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Med, On 2021-5-5, at 12:02, mohamed.boucadair@orange.com wrote: >=20 > [Med] It is true that DOTS was designed with compact messages in mind, = but handling large data was **already** covered in the DOTS spec (see = Section 4.4.2 of RFC8782). We then found that the normal block-wise = mechanism is suboptimal for the DOTS application. >=20 > and this >> document extends CORE to enable this functionality. However, this >> CORE extension seems to solely focus on Internet deployment >> scenarios, essentially attempting to re-architect COAP into a general >> Internet transport protocol for transmission over paths with high >> loss rates. I do not believe that the CORE WG is chartered to do >> this. >>=20 >=20 > [Med] This work is part of the maintenance of RFC7959 that is covered = by the core WG charter: >=20 > =3D=3D > The working group will perform maintenance on its first four > standards-track specifications: > =3D=3D those four specifications are RFC 6690, RFC 7252, RFC 7641 and = draft-ietf-core-block (=3D RFC7959). In my understanding, draft-ietf-core-new-block is a separate COAP = extension, not a maintenance effort related to RFC7959. The abstract = even says that the new mechanisms are similar to, but not a replacement = for, RFC 7959. If it were maintenance, draft-ietf-core-new-block would = replace or at the very least update some parts of RFC7959. > As you can read in = https://datatracker.ietf.org/doc/minutes-interim-2020-core-06-202006101600= /, the WG decided to: > "scope it as an extension (as opposed to blockwise-bis)". I think this decision is exactly were the WG went beyond its charter. > The plan is to use this extension as the base for a bis when the WG = will be ready to cover other aspects that are left out of scope for this = extension. See, e.g., = https://datatracker.ietf.org/doc/minutes-110-core-202103121300/: "it can = be seminal material for a blockwise bis document". Until that plan has consensus and is chartered, = draft-ietf-core-new-block IMOR remains a COAP extensions that is = out-of-charter. > I let the AD and the chairs further elaborate on the charter point. I'm sure we'll discuss this on the call tomorrow. Thanks, Lars --Apple-Mail=_DE96EDC5-5CAB-40B4-9971-BDFB34FCF511 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmCSbeMACgkQVLXDCb9w wVf+gw/+OI5Mp0nqg9o9q6JandhnDAnDkoabh3ftTSNEFwwJN5jr372YVRx4E9Xf KQzlbtRSJ+uLyLch0mTi9lxraOLbRIcm5qOxFevRblFjs2Nq20R6/xEZwn4sQonx Z9w7Brx6wQhPjXMDggGIZdn9OC2HXlbz7UGPNpCrYvbcDmo451vfYCKKa35YaIw6 2hadWfZKNgmyNn/ADdJ/Iw22Dl+gD+42zokbv7dXRW1xHCmguon/66zQgRJQrgSt gPCqQ3mWiTKIIMfjZqH+uopPpxNfYorXljxuUBUVZjpusvfy14CIuADkHIuZcoMv tGvC+syOw3EP+vTl77dv+5vycU+8FuLKFg+v9eqy+25jzPbf0LZ25v8ofbm5SP5b v4aD0+d/w+LmOHbEyyzJspRbsAck5mL4EHtc4hVVoIhXJA8bHdiZy/ofXLZj90yd t+jzNNTqMmNqtDMTKDhsa2Ih42PLNUeon7jQs/5iu2ce5Psj1v9VzxMPqCrthA95 apIJ4bYGQPwk75cqRLkoLhk0zQ0woSEAa41itsFjpmiwVtBnkWyP4c4+DFczsY/x 316Yh9R5h7ifGdLvu6exz5Uw2KlUr4ai1p4VRMeGr20jI7WGxc6+2ArK4Y0l+Vfq toDdDlhbmQrRSUTouBboJ1/agvZ/o5lllWYKbVqej3M+Kka2Qjw= =iG5t -----END PGP SIGNATURE----- --Apple-Mail=_DE96EDC5-5CAB-40B4-9971-BDFB34FCF511-- From nobody Wed May 5 09:26:03 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 B063A3A17B3; Wed, 5 May 2021 09:25:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-core-new-block@ietf.org, core-chairs@ietf.org, core@ietf.org, marco.tiloca@ri.se, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <162023195660.31473.11383940038766618259@ietfa.amsl.com> Date: Wed, 05 May 2021 09:25:56 -0700 Archived-At: Subject: [core] Martin Duke's No Objection on draft-ietf-core-new-block-11: (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, 05 May 2021 16:25:57 -0000 Martin Duke has entered the following ballot position for draft-ietf-core-new-block-11: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. Thank you for the examples. They were useful in providing an overview of the protocol. Thanks also to Colin Perkins for an especially thoughtful TSVART review. Please address his comments, although his concerns about (7.1) are IMO mostly subsumed by my DISCUSS. - It would be useful to introduce the "token", "request tag", and "Etag" concepts before using them. Reading front-to-back, I spent most of Section 4 confused. - (4.4) It would be useful to state that clients MUST (SHOULD?) NOT request retransmission of blocks from ETags that are not "fresh" -- IIUC, they probably don't exist anymore, and anyway the server has no way of knowing which non-fresh ETag to serve beacuse it says "The ETag Option should not be used in the request for missing blocks" BTW, s/should/SHOULD - (7.2) If NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT both "have the same value as computed for EXCHANGE_LIFETIME", why are they different variables? Or is that they SHOULD have the same value but might not? A normative word would be helpful here. From nobody Wed May 5 12:18: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 F36993A1D77; Wed, 5 May 2021 12:17:52 -0700 (PDT) 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-new-block@ietf.org, core-chairs@ietf.org, core@ietf.org, marco.tiloca@ri.se, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <162024227267.18682.9364450117778772479@ietfa.amsl.com> Date: Wed, 05 May 2021 12:17:52 -0700 Archived-At: Subject: [core] Roman Danyliw's No Objection on draft-ietf-core-new-block-11: (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, 05 May 2021 19:17:53 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-core-new-block-11: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** Section 3.2 and Section 11 (a) Section 3.2. It is not recommended that these options are used in a NoSec security mode (b) Section 11. It is NOT RECOMMENDED that the NoSec security mode is used if the Q-Block1 and Q-Block2 Options are to be used. I believe that the intend of (a) and (b) is to caution against using NoSec mode with either Q-Block1 or 2. One read of (b) would be that this guidance is only about when both options are used together (e.g., the language of Section 4.7). I recommend restating (b) to be more along the lines of: Therefore, it is NOT RECOMMENDED to use the NoSec security mode if either the Q-Block1 or Q-Block2 Options is used. ** Section 4.1. Colloquialism. s/local configuration knob/local configuration option/ ** Section 4.4. (a) 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 transmission is terminated. Any subsequent missing block requests MUST be responded to using the latest ETag and Size2 Option values with the updated data. ... (b) If the server transmits a new body of data (e.g., a triggered Observe notification) 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. (1) Is (a) suggesting that the missing block requests would be serviced from a copy of the “resource data that has changed”? This would mean that the client would get an inconsistent version of the resource which is neither the old or new version. (2) (b) seems like it is noting that the partially received body should in fact be discarded to avoid the situation in (1). However, how does the client get the initial, now discarded blocks? I’m not sure where that transmission shouldn’t fail with an error as I don’t follow how recover is possible. From nobody Wed May 5 17:41: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 BBDB53A1B0C; Wed, 5 May 2021 17:41:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: John Scudder via Datatracker To: "The IESG" Cc: draft-ietf-core-new-block@ietf.org, core-chairs@ietf.org, core@ietf.org, marco.tiloca@ri.se, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: John Scudder Message-ID: <162026169267.30008.8195219304146866165@ietfa.amsl.com> Date: Wed, 05 May 2021 17:41:32 -0700 Archived-At: Subject: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and 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, 06 May 2021 00:41:33 -0000 John Scudder has entered the following ballot position for draft-ietf-core-new-block-11: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- For the most part I found this document relatively easy to follow, considering my complete lack of background in CoAP. However, despite a concerted effort I have not been able to nail down with confidence what the intended semantics of several of your timeouts are, notably NON_RECEIVE_TIMEOUT. Some of the text (for example, §4.4) implies that the timeout is an upper bound on how long an implementation should wait before declaring a block to have been lost (“The client SHOULD wait for up to NON_RECEIVE_TIMEOUT”). At the very least, this is imprecise because the timeout increases exponentially with repeated timeouts — but this is a relatively minor matter, discussed further in my comments. Later, in §7.2, you say that expiry of the timeout is not the only trigger for a 4.08 response: It is likely that the client will start transmitting the next set of MAX_PAYLOADS payloads before the server times out on waiting for the last of the previous MAX_PAYLOADS payloads. On receipt of the first payload from the new set of MAX_PAYLOADS payloads, the server SHOULD send a 4.08 (Request Entity Incomplete) Response Code indicating any missing payloads from any previous MAX_PAYLOADS payloads. It makes sense to me that you use this additional trigger. At this point in my reading of the spec, my understanding of the retransmission algorithm was that a 4.08 should be sent when either a payload is received from a new set of MAX_PAYLOADS, or NON_RECEIVE_TIMEOUT expires. But then I got to the example in 10.2.3, which shows the client waiting for the expiration of NON_RECEIVE_TIMEOUT even though it has received the first of a new set of MAX_PAYLOADS, and I concluded that either I’ve missed something basic, or the document is internally inconsistent. As an aside, I’m also unclear as to why the only trigger you specify for sending a 4.08 is the arrival of the first of a new MAX_PAYLOADS flight. Other possible triggers I noticed include a gap in the sequence, and reception of a payload with More=0. Some of these issues are repeated in my comments, below — I’ve noted those in the comment. Possibly in addressing this DISCUSS we’ll clear up some of those comments too. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Comments: (draft-ietf-core-new-block-11) 1. Section 3.2 This mechanism is not intended for general CoAP usage, and any use outside the intended use case should be carefully weighed against the loss of interoperability with generic CoAP applications. I’m curious: is the only reason the mechanism isn’t intended for general usage, the fact some implementations won’t support it? Or does it have other deficiencies that also make it unsuitable? 2. Section 4.1 Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and iPATCH requests and their payload-bearing responses (2.01, 2.02, 2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]). I found the list of codes incomprehensible on first encountering it, since the concept of response codes hadn’t been introduced yet. I do understand that the document assumes familiarity with CoAP; nonetheless for basic clarity I think this should say “(response codes 2.01, 2.02…”. Additionally, the reference to RFC 7252 §5.5 doesn’t seem to be especially germane? By the way, is 2.03 indeed a payload-bearing response? The only other place the spec touches on it is in §4.4, which says “the server could respond with a 2.03 (Valid) response with no payload”. 3. Section 4.1 To indicate support for Q-Block2 responses, the CoAP client MUST include the Q-Block2 Option in a GET or similar request (FETCH, for example), the Q-Block2 Option in a PUT or similar request, or the Q-Block1 Option in a PUT or similar request so that the server knows that the client supports this Q-Block functionality should it need to send back a body that spans multiple payloads. Otherwise, the server would use the Block2 Option (if supported) to send back a message body that is too large to fit into a single IP packet [RFC7959]. Is this paragraph really supposed to mention both Q-Block2 and Q-Block1? In particular, I’m confused by the mention of both of these in relation to PUT. 4. Section 4.1 The Q-Block1 and Q-Block2 Options are unsafe to forward. That is, a CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option MUST reject the request or response that uses either option. Presumably (hopefully) this is simply describing the behavior of existing spec-compliant proxies when processing the new messages. As such, is the MUST appropriate? I would think not. 5. Section 4.3 body. Note that the last received payload may not be the one with the highest block number. “Might not” would be less ambiguous than “may not”. 6. Section 4.4 (also two places in §4.3) (This comment rehashes, in more detail, the difficulty explained in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.) The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2) I read this as meaning the client should wait for as little as zero, or as long as NON_RECEIVE_TIMEOUT — that’s my understanding of “up to”. Is that the intended meaning? If it is, I think it’s worth writing out as I’ve done, for clarity. If it’s not, it definitely needs to be fixed. There’s a similar issue with “up to NON_PARTIAL_TIMEOUT” later in the section. Referring ahead to Section 7.2 muddies the waters further. Even though the text quoted above says NON_RECEIVE_TIMEOUT is an upper limit on how long to wait, §7.2 says it’s a lower limit instead... maybe? From §7.2: NON_RECEIVE_TIMEOUT is the initial maximum time to wait for a missing “Maximum”, ok great, that means “upper bound” and so lines up with §4.4 although the “initial” is surprising since §4.4 doesn’t say anything about the upper limit increasing. It continues: payload before requesting retransmission for the first time. Every time the missing payload is re-requested, the time to wait value doubles. The time to wait is calculated as: Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1)) But this part says it’s (a) an exact time-to-wait, not a “maximum”, and (b) it says it increases exponentially, so NON_RECEIVE_TIMEOUT isn’t a maximum at all, but a minimum. This later text in §7.2 implies that perhaps the problem in the above passages is the word “maximum”, and it should simply be deleted: For the server receiving NON Q-Block1 requests, it SHOULD send back a 2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS payloads to prevent the client unnecessarily delaying. If not all of the MAX_PAYLOADS payloads were received, the server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request count for a payload) before sending the 4.08 (Request Entity Incomplete) Response Code for the missing payload(s). Similarly “up to” in the quote that began this comment should be “at least”. Whether you adopt those suggestions or not, it seems as though all this needs to be rewritten with careful attention to conveying what the desired behavior is. But the plot thickens. Later in §7.2 we have It is likely that the client will start transmitting the next set of MAX_PAYLOADS payloads before the server times out on waiting for the last of the previous MAX_PAYLOADS payloads. On receipt of the first payload from the new set of MAX_PAYLOADS payloads, the server SHOULD send a 4.08 (Request Entity Incomplete) Response Code indicating any missing payloads from any previous MAX_PAYLOADS payloads. The point being that the retransmission request can be triggered by an event other than timer expiration. So in that sense, “maximum” is right — it provides an upper bound on how long to wait before requesting a retransmission — but in another sense it’s wrong because the exponential increase is applied to it. I think the word “maximum” is trying to do too much work, and more words are probably required in order to make this clear. I also think the problem is exacerbated by the fact both §4.4 and §7.2 are talking normatively about how to use NON_RECEIVE_TIMEOUT. It seems as though the main description is found in §7.2, and some confusion would be avoided by making §4.4 less specific, and simply referring forward to §7.2. And, as noted in my DISCUSS, example 10.2.3 muddies the waters still further since it illustrates yet another behavior. 7. Section 4.4 The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2) after the last received payload for NON payloads before issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or more Q-Block2 Options that define the missing blocks with the M bit unset. The client MAY set the M bit to request this and later blocks from this MAX_PAYLOADS set. Further considerations related to the transmission timing for missing requests are discussed in Section 7.2. I find this whole paragraph pretty confusing with the dueling SHOULD and MAY, where it appears the SHOULD might be doing two jobs at once. I *think* your intent is something like the following? “The client SHOULD wait as specified in Section 7.2 for NON payloads before requesting retransmission of any missing blocks. Retransmission is requested by issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or more Q-Block2 Options that define the missing block(s). Generally the M bit on the Q-Block option(s) SHOULD be unset, although the M bit MAY be set to request this and later blocks from this MAX_PAYLOADS set, see Section 10.2.4 for an example of this in operation.” 8. Section 5 If the size of the 4.08 (Request Entity Incomplete) response packet is larger than that defined by Section 4.6 [RFC7252], then the number of missing blocks MUST be limited so that the response can fit into a single packet. If this is the case, then the server can send Suggestion: “then the number of missing blocks reported MUST...” (The thing being limited is not the actual number of missing blocks. You’re limiting the number you report on.) 9. Section 7.1 It is implementation specific as to whether there should be any further requests for missing data as there will have been significant transmission failure as individual payloads will have failed after MAX_TRANSMIT_SPAN. This paragraph seems as though it’s a non-sequitur. It just doesn’t make sense to me. :-( 10. Section 7.2 (This comment relates to the difficulty explained in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.) NON_TIMEOUT is the maximum period of delay between sending sets of MAX_PAYLOADS payloads for the same body. By default, NON_TIMEOUT has the same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]). Presumably the use of “maximum” means it’s fine to delay zero seconds (or any value lower than NON_TIMEOUT). 11. General By the way, none of the timers specify jitter (and indeed, if read literally, jitter would be forbidden). Is this intentional? 12. Section 7.2 If the CoAP peer reports at least one payload has not arrived for each body for at least a 24 hour period and it is known that there are no other network issues over that period, then the value of MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and the situation re-evaluated for another 24 hour period until there is no 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 it is reconfigured. As a consequence of the two peers having different MAX_PAYLOADS values, a peer may continue indicate that there are some missing payloads as all of its MAX_PAYLOADS set may not have arrived. How the two peer values for MAX_PAYLOADS are synchronized is out of the scope. I take it this is just thrown in here as an operational suggestion? It’s not specifying protocol, right? It seems a little misplaced, if so. 13. Section 10.1.3 (This comment relates to the aside in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.) Why doesn’t the server request 1,9,10 in one go? Since its rxmt request is triggered by rx of 11, one would think it could infer 10 had been lost. 14. Section 10.1.4 (also 10.3.3) (This comment relates to the aside in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.) Why doesn’t reception of a message with More=0 trigger the server to request retransmission of the missing block? Why does it have to wait for timeout? 15. Section 10.2.3 (This comment relates to my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.) Why doesn’t reception of QB2:10/0/1024 trigger the client to request retransmission? Why does it have to wait for timeout? Similarly reception of QB2:9/1/1024 later in the example. 16. Section 10.2.4 Since MAX_PAYLOADS is 10, why does the example say “MAX_PAYLOADS has been reached” after payloads 2-9 have been retransmitted? That’s only 8 payloads. From nobody Wed May 5 18:58: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 413183A2AE4; Wed, 5 May 2021 18:58:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-core-new-block@ietf.org, core-chairs@ietf.org, core@ietf.org, marco.tiloca@ri.se, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <162026630680.17506.6477675472375470197@ietfa.amsl.com> Date: Wed, 05 May 2021 18:58:27 -0700 Archived-At: Subject: [core] Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and 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, 06 May 2021 01:58:27 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-core-new-block-11: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a concern about the MAX_PAYLOADS congestion-control parameter. In Section 7.2 it is stated that both endpoints only SHOULD have the same value. I don't see how this can be anything less than MUST, given that we attribute semantics to whether NUM modulo MAX_PAYLOADS is zero or non-zero in the processing of the Q-Block2 option. If the endpoints disagree on the value of MAX_PAYLOADS they will disagree on the semantics of Q-Block2 -- how can that be interoperable? (Being able to negotiate the value does not seem inherently problematic, but since it is relevant for protocol semantics it seems like the value must be identical on both endpoints.) This seems especially important to have clarity on given that the current specification allows for MAX_PAYLOADS to be decreased at runtime in response to congestion feedback over a 24-hour period, with no synchronization between peers provided ("Note that the CoAP peer will not know about the MAX_PAYLOADS change until it is reconfigured".) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I made some editorial suggestions in a github pull request at https://github.com/core-wg/new-block/pull/21 . It seems that there are now some merge conflicts; I cannot promise to have availability to try to resolve them particularly quickly, but I can do so "eventually" if needed. Section 1 There is a requirement for these blocks of data to be transmitted at higher rates under network conditions where there may be asymmetrical transient packet loss (i.e., responses may get dropped). An example is when a network is subject to a Distributed Denial of Service (DDoS) attack and there is a need for DDoS mitigation agents relying upon CoAP to communicate with each other (e.g., [RFC8782][I-D.ietf-dots-telemetry]). As a reminder, [RFC7959] I suppose the RFC Editor will do the right thing about referencing 8782 vs 8782bis ... and I am overdue in following up on the IETF LC results for the latter :( Section 2 We currently introduce the concept of MAX_PAYLOADs by implicit use in a few places before it is actually given a proper definition. I wonder if mentioning here that it is used to group a batch of blocks would help the reader. Section 3 o They support sending an entire body using Non-confirmable (NON) messages without requiring a response from the peer. I put this change in my github PR, but repeating here for visibility since I am making an assumption: I propose adding "intermediate" for "without requiring an intermediate response from the peer". My understanding is that a final message indicaing successful receiption is still used (or a selective ack in case of loss), so the contrast to RFC 7959 is in the (lack of) need for intermediate responses for each block. o Mixing of NON and CON during requests/responses using Q-Block is not supported. There is perhaps subtle differences across "not supported", "forbidden", and "not defined in this specification". Do we perhaps actually mean "forbidden"? Section 3.2 (DOTS) that cannot use CON responses to handle potential packet loss and that support application-specific mechanisms to assess whether the remote peer is able to handle the messages sent by a CoAP endpoint (e.g., DOTS heartbeats in Section 4.7 of [RFC8782]). Can we get greater clarity on what "able to handle" is intended to mean? I can't tell if it's anywhere between "the transport is able to deliver message bodies" and "the software stack implements and enables a particular feature". Section 4.1 When the Content-Format Option is present together with the Q-Block1 or Q-Block2 Option, the option applies to the body not to the payload (i.e., it must be the same for all payloads of the same body). Do we have a normative requirement somewhere that the recipient track and compare the content-format values across blocks? If not, should we? Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and iPATCH requests and their payload-bearing responses (2.01, 2.02, 2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]). Do we need an "e.g." in front of the list, to account for the potential future registration of new payload-bearing response codes? If Q-Block1 Option is present in a request or Q-Block2 Option in a response (i.e., in that message to the payload of which it pertains), Can we reword this parenthetical in a less convoluted way? I'm not even sure I'm parsing it properly. [RFC7252]). To reliably get a rejection message, it is therefore REQUIRED that clients use a Confirmable message for determining support for Q-Block1 and Q-Block2 Options. (I know that some other discussion happened on this mechanism, but I forget if there are already plans to add a clarification that this is only needed once per peer within a given set of exchanges.) The Q-Block2 Option is repeatable when requesting retransmission of missing blocks, but not otherwise. Except that case, any request carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled following the procedure specified in Section 5.4.5 of [RFC7252]. Since these are critical options, the referenced procedures involve rejecting the message, right? Is that important enough to note directly? Note that if Q-Block1 or Q-Block2 Options are included in a packet as Inner options, Block1 or Block2 Options MUST NOT be included as Inner options. Similarly there MUST NOT be a mix of Q-Block and Block for the Outer options. [...] (Hopefully a silly question, but do we make the analogous prohibition against combining Q-Block and regular Block for non-OSCORE cases anywhere? I thought we did, but now I can't find it...) Section 4.3 being transferred. The Request-Tag is opaque, the server still treats it as opaque but the client MUST ensure that it is unique for every different body of transmitted data. (nit) the structure of this sentence seems off, to me. I may just want a comma after "server still treats it as opaque", but looking more closely I might rewrite to more like "The Request-Tag is opaque to the server, but the client MUST ensure that it is unique for every different request body being transmitted". Implementation Note: It is suggested that the client treats the Request-Tag as an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The initial Request-Tag value should be randomly generated and then subsequently incremented by the client whenever a new body of data is being transmitted between peers. In the vein of draft-gont-numeric-ids-sec-considerations, is the increment necessarily 1 or can there be gaps? Similarly, the risk of information disclosure (via side channel) is reduced if the initial random value is generated anew for each connection. This is maybe implied by the current text but could be stated more clearly. The client MUST send the payloads with the block numbers increasing, starting from zero, until the body is complete (subject to any congestion control (Section 7)). Any missing payloads requested by the server must in addition be separately transmitted with increasing block numbers. When I first read this, I thought that the block numbers of retransmissions needed to continue to increase in the same sequence as the original transmission, i.e., retransmitted blocks are assigned new block numbers. The examples do not bear this out (and it seems like it would be complicated to specify clearly), so I suggest rephrasing to "in order of increasing block number". If the FETCH request includes the Observe Option, then the server MUST use the same token as used for the initial response for returning any Observe triggered responses so that the client can match them up. The client should then release all of the tokens used for this body unless a resource is being observed. If a resource is being observed, should the client release all the other tokens (than the one used for the initial response)? Also, is the "initial response" the first response for the blockwise transfer (which might be a 2.31 or 4.08 for NON requests), or the first one with response code 2.05? 2.31 (Continue) This Response Code can be used to indicate that all of the blocks up to and including the Q-Block1 Option block NUM (all having the M bit set) have been successfully received. The token used MUST be one of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received request. Can the client release any tokens upon receipt of such a response? 4.02 (Bad Option) This Response Code MUST be returned for a Confirmable request if the server does not support the Q-Block Options. Note that a reset message must be sent in case of Non-confirmable request. Reset only needs to be sent if the server is not ignoring the request entirely, though, right? %%% The following few comments are interrelated: 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 NUM, SZX, and M bit as appropriate. The new 'M' bit is "as appropriate" for the new flight of messages, or as was sent initially? (The examples in §10.x suggest "as was sent initially".) The Request-Tag value to use is determined by taking the token in the 4.08 (Request Entity Incomplete) response, locating the matching client request, and then using its Request-Tag. The "value to use" here seems to be indicating the value to use in the retransmitted request... The token used MUST be one of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received request. See Section 5 for further information. ... but here the "token used" seems to be indicating the token to be used in constructing the response that has response code 4.08. If my understanding is correct, we really should have more clarity on which value is "used" for which message. Additionally, in the last quoted paragraph we refer to Section 5 for further information, which includes a SHOULD-level requirement to "provide the [token] used in the last received request". It is very surprising to have the normative requirements for behavior split across sections in this manner. (Or was the intent that Section 5 also use the "desirable" wording?) %%% Section 4.4 The ETag is opaque, the client still treats it as opaque but the server MUST ensure that it is unique for every different body of transmitted data. [analogous comment as for Request-Tag] Implementation Note: It is suggested that the server treats the ETag as an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The initial ETag value should be randomly generated and then subsequently incremented by the server whenever a new body of data is being transmitted between peers. [analogous comment as for Request-Tag] The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2) after the last received payload for NON payloads before issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or more Q-Block2 Options that define the missing blocks with the M bit unset. The client MAY set the M bit to request this and later blocks from this MAX_PAYLOADS set. Further considerations related to the transmission timing for missing requests are discussed in Section 7.2. Does the MAY grant permission to send with M bit set prior to NON_RECEIVE_TIMEOUT, or just permission to send with M bit set in addition to with M bit unset (but still after the timeout)? For Confirmable responses, the client continues to acknowledge each packet. Typically, the server acknowledges the initial request using an ACK with the payload, and then sends the subsequent payloads as CON responses. The server will detect failure to send a packet, but the client can issue, after a MAX_TRANSMIT_SPAN delay, a separate GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as needed. Starting out with "for confirmable responses" implies that we're going to separately cover non-confirmable responses later, or at some point transition to statements of general applicability (to both confirmable and non-confirmable responses). Where does that happen? A client SHOULD maintain a partial body (missing payloads) for up to NON_PARTIAL_TIMEOUT (Section 7.2) or as defined by the Max-Age Option (or its default of 60 seconds (Section 5.6.1 of [RFC7252])), whichever is the less. On release of the partial body, the client should then release all of the tokens used for this body unless a resource is being observed. [as above, can the client release any subset of tokens in the case of observe?] It is RECOMMENDED that the server maintains a cached copy of the body when using the Q-Block2 Option to facilitate retransmission of any missing payloads. It's surprising to write that the client SHOULD but it is RECOMMENDED that the server cache, when those two requirements keywords have an equivalent strength per BCP 14. Can't we used consistent terminology for the same requirement level? 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 transmission is terminated. Any subsequent missing block requests MUST be responded to using the latest ETag and Size2 Option values with the updated data. This sounds like the server starts responding "in the middle" of the new representation, so the client would need to go back and re-request the initial parts, possibly across multiple groups of MAX_PAYLOADS blocks. It seems like this requirement for client behavior should be more clearly documented somewhere. We do go on to talk about the client removing the stale partial body, but not about completing the new body. Section 4.5 For a response that uses Q-Block2, the Observe value MUST be the same for all the payloads of the same body. This is different from Block2 usage where the Observe value is only present in the first block (Section 3.4 of [RFC7959]). This includes payloads transmitted following receipt of the 'Continue' Q-Block2 Option (Section 4.4) by the server. If a missing payload is requested by a client, then both the request and response MUST NOT include the Observe Option. (side note?) It seems very surprising to omit Observe from only retransmitted payloads but keep it in all initial payload transmissions. Section 4.6 The Size1 or Size2 option values MUST exactly represent the size of the data on the body so that any missing data can easily be determined. Is this MUST duplicating the behavior already specified by RFC 7959? Section 5 The data payload of the 4.08 (Request Entity Incomplete) response is encoded as a CBOR Sequence [RFC8742]. It comprises of one or more I think we want some qualifying text that reaffirms that the behavior being described is applicable only to the application/missing-blocks+cbor-seq content-type case, possibly by having the previous discussion state that "this section defines the behavior and semantics for 4.08 responses using the new content-type." The Concise Data Definition Language [RFC8610] (and see Section 4.1 [RFC8742]) for the data describing these missing blocks is as follows: (Should we mention that this is only informational and that the prose description is normative, in line with RFC 8610 being only an informative reference?) ; A notional array, the elements of which are to be used ; in a CBOR Sequence: (nit) Is there a reason to use a different wording than the referenced example from RFC 8742? Section 6 Implementation Note: By using 8-byte tokens, it is possible to easily minimize the number of tokens that have to be tracked by clients, by keeping the bottom 32 bits the same for the same body and the upper 32 bits containing the current body's request number (incrementing every request, including every re-transmit). This allows the client to be alleviated from keeping all the per- request-state, e.g., in Section 3 of [RFC8974]. If we're going to introduce structure into a nominally opaque identifier, we need to discuss the consequences of that in the security considerations. draft-gont-numeric-ids-sec-considerations has some guidance in this regard. Section 7.1 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. [...] I thought there had been some discussion in a different AD's ballot thread on this text, but I can't find it now. I'm happy to defer to the previous discussion if I'm not just imagining it. Anyways, I might suggest phrasing this as "if faster transmission rates are needed, NSTART will need to be increased from 1". It is implementation specific as to whether there should be any further requests for missing data as there will have been significant transmission failure as individual payloads will have failed after MAX_TRANSMIT_SPAN. (editorial) I don't think I can successfully parse this sentence. There may be a few missing words, and splitting into multiple sentences would likely help as well. Section 7.2 NON_RECEIVE_TIMEOUT is the initial maximum time to wait for a missing payload before requesting retransmission for the first time. Every time the missing payload is re-requested, the time to wait value doubles. The time to wait is calculated as: Thank you for being very clear about the exponential backoff procedure :) payloads to prevent the client unnecessarily delaying. If not all of the MAX_PAYLOADS payloads were received, the server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request count for a payload) before sending the 4.08 (Request Entity Incomplete) Response Code for the missing payload(s). If this is a repeat for the 2.31 (Continue) response, the server SHOULD send a 4.08 (Request Entity Incomplete) response detailing the missing payloads after the block number that would have been indicated in the 2.31 (Continue). [...] I don't understand what "if this is a repeat for the 2.31 (Continue) response" is intended to mean. The client does not need to acknowledge the receipt of the entire body. Does that mean that the last group of response blocks will always be retransmitted NON_MAX_RETRANSMIT times? Section 10 QB1: Q-Block1 Option values NUM/More/SZX QB2: Q-Block2 Option values NUM/More/SZX What's depicted in the figure seems to be the actual block size, and not the three-bit SZX value. Section 10.1.3 Should we indicate somehow in Figure 6 that the 4.08 responses use the new content-format? Also, is there any value in indicating that there might be a race between the client continuing to send the next set of payloads and the initial 4.08 response? Section 10.2.3 I don't understand why the NON_RECEIVE_TIMEOUT (client) triggers -- shouldn't the delivery of the 11th block indicate that the server thinks it sent a full MAX_PAYLOADS group and thus a selective ACK, after perhaps just a modest reordering delay? Section 10.3.2 [[MAX_PAYLOADS has been reached]] | [[MAX_PAYLOADS blocks acknowledged by client using | 'Continue' Q-Block2]] +--------->| NON FETCH /path M:0x3b T:0xab QB2:10/1/1024 |<---------+ NON 2.05 M:0x8b T:0xaa O:1334 ET=21 QB2:10/0/1024 Shouldn't the server switch to using T:0xab now? +--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024 |<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024 and 0xac here? Section 10.3.3 |<---------+ NON 2.05 M:0xa6 T:0xc6 ET=23 QB2:3/0/1024 | ... | [[NON_RECEIVE_TIMEOUT (client) delay expires]] Why does the client time out here (at least with the full NON_RECEIVE_TIMEOUT); the final-message indication seems like it would allow for an ~immediate response (delayed only for some reordering threshold)? From nobody Wed May 5 23:12:59 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 6E7BB3A1083; Wed, 5 May 2021 23:12:54 -0700 (PDT) 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 Ge8FLY7m-CkF; Wed, 5 May 2021 23:12:49 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (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 4C2443A1071; Wed, 5 May 2021 23:12:48 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 4FbNXs3vJHzFqKF; Thu, 6 May 2021 08:12:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620281565; bh=KAF8FD5b555CB0/NHAkNFDWzUy9OtSWYMGE0G81OWs4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ucpCyxTyjPGLMpNTj0aJr+22GOxzfQ68NwPEU1UVkixi04OG6DIYF4OKdlQyRI7Ic pmP1ANq/3N+Shr6+Dq3W6IGBKkmbjWg5rxZvg8pk7l9kPcsFEskoNUevL1Y5iwBoMf fhvU+yMLSZj8NTKKjgzByn4FnhN6TSUMuYfL9KvRN2yJ/okI3rfUgNkm9Su1Z3yejY lXWbbhpzcpk4XR7CQSwBmyDOmgVAaSp5dm3zYPDdVuYzBrIA4bbeWRPeSEW6Uv7AkI OKGkGe4milVo4gA/qzQ14VxwvK9v4Y1ZQSDLA+3WYo5ovn5APaBpkSBfAkAygu4maz ZGRlpoRD5/f6A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4FbNXs2P4zzBrLj; Thu, 6 May 2021 08:12:45 +0200 (CEST) From: To: Roman Danyliw , The IESG CC: "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: Roman Danyliw's No Objection on draft-ietf-core-new-block-11: (with COMMENT) Thread-Index: AQHXQeNbFwKD5z5uIk+Qp/pk7eHOL6rV7ZMQ Date: Thu, 6 May 2021 06:12:44 +0000 Message-ID: <2142_1620281565_609388DD_2142_32_1_787AE7BB302AE849A7480A190F8B9330353776FE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162024227267.18682.9364450117778772479@ietfa.amsl.com> In-Reply-To: <162024227267.18682.9364450117778772479@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] Roman Danyliw's No Objection on draft-ietf-core-new-block-11: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 06:12:58 -0000 SGkgUm9tYW4sIA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIA0KDQpQbGVhc2Ugc2VlIGlu bGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiBEZcKgOiBSb21hbiBEYW55bGl3IHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0 Zi5vcmddDQo+IEVudm95w6nCoDogbWVyY3JlZGkgNSBtYWkgMjAyMSAyMToxOA0KPiDDgMKgOiBU aGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2PCoDogZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9j a0BpZXRmLm9yZzsgY29yZS1jaGFpcnNAaWV0Zi5vcmc7DQo+IGNvcmVAaWV0Zi5vcmc7IG1hcmNv LnRpbG9jYUByaS5zZTsgbWFyY28udGlsb2NhQHJpLnNlDQo+IE9iamV0wqA6IFJvbWFuIERhbnls aXcncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay0xMToNCj4gKHdp dGggQ09NTUVOVCkNCj4gDQo+IFJvbWFuIERhbnlsaXcgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2lu ZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMTE6IE5v IE9iamVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVj dCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRl ZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dA0KPiB0aGlzIGludHJv ZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBo dHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLQ0KPiBjcml0ZXJpYS5o dG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IERJU0NVU1MgYW5kIENPTU1FTlQgcG9z aXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3Qg cG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay8NCj4gDQo+IA0KPiANCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IC0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0NCj4gDQo+ICoqIFNl Y3Rpb24gMy4yIGFuZCBTZWN0aW9uIDExDQo+IChhKSBTZWN0aW9uIDMuMi4gSXQgaXMgbm90IHJl Y29tbWVuZGVkIHRoYXQgdGhlc2Ugb3B0aW9ucyBhcmUgdXNlZCBpbg0KPiBhIE5vU2VjIHNlY3Vy aXR5IG1vZGUNCj4gDQo+IChiKSBTZWN0aW9uIDExLiBJdCBpcyBOT1QgUkVDT01NRU5ERUQgdGhh dCB0aGUgTm9TZWMgc2VjdXJpdHkgbW9kZSBpcw0KPiAgICB1c2VkIGlmIHRoZSBRLUJsb2NrMSBh bmQgUS1CbG9jazIgT3B0aW9ucyBhcmUgdG8gYmUgdXNlZC4NCj4gDQo+IEkgYmVsaWV2ZSB0aGF0 IHRoZSBpbnRlbmQgb2YgKGEpIGFuZCAoYikgaXMgdG8gY2F1dGlvbiBhZ2FpbnN0IHVzaW5nDQo+ IE5vU2VjIG1vZGUgd2l0aCBlaXRoZXIgUS1CbG9jazEgb3IgMi4gIE9uZSByZWFkIG9mIChiKSB3 b3VsZCBiZSB0aGF0DQo+IHRoaXMgZ3VpZGFuY2UgaXMgb25seSBhYm91dCB3aGVuIGJvdGggb3B0 aW9ucyBhcmUgdXNlZCB0b2dldGhlcg0KPiAoZS5nLiwgdGhlIGxhbmd1YWdlIG9mIFNlY3Rpb24g NC43KS4NCj4gSSByZWNvbW1lbmQgcmVzdGF0aW5nIChiKSB0byBiZSBtb3JlIGFsb25nIHRoZSBs aW5lcyBvZjoNCj4gDQo+IFRoZXJlZm9yZSwgaXQgaXMgTk9UIFJFQ09NTUVOREVEIHRvIHVzZSB0 aGUgTm9TZWMgc2VjdXJpdHkgbW9kZSBpZg0KPiBlaXRoZXIgdGhlDQo+IFEtQmxvY2sxIG9yIFEt QmxvY2syIE9wdGlvbnMgaXMgdXNlZC4NCg0KW01lZF0gQUNLLg0KDQo+IA0KPiAqKiBTZWN0aW9u IDQuMS4gIENvbGxvcXVpYWxpc20uIHMvbG9jYWwgY29uZmlndXJhdGlvbiBrbm9iL2xvY2FsDQo+ IGNvbmZpZ3VyYXRpb24gb3B0aW9uLw0KPiANCg0KW01lZF0gQ2hhbmdlZCBpdCB0byAibG9jYWwg Y29uZmlndXJhdGlvbiBwYXJhbWV0ZXIiLg0KDQo+ICoqIFNlY3Rpb24gNC40Lg0KPiANCj4gKGEp ICAgSWYgdGhlIHNlcnZlciBkZXRlY3RzIHBhcnQgd2F5IHRocm91Z2ggYSBib2R5IHRyYW5zZmVy IHRoYXQgdGhlDQo+ICAgIHJlc291cmNlIGRhdGEgaGFzIGNoYW5nZWQgYW5kIHRoZSBzZXJ2ZXIg aXMgbm90IG1haW50YWluaW5nIGENCj4gY2FjaGVkDQo+ICAgIGNvcHkgb2YgdGhlIG9sZCBkYXRh LCB0aGVuIHRoZSB0cmFuc21pc3Npb24gaXMgdGVybWluYXRlZC4gIEFueQ0KPiAgICBzdWJzZXF1 ZW50IG1pc3NpbmcgYmxvY2sgcmVxdWVzdHMgTVVTVCBiZSByZXNwb25kZWQgdG8gdXNpbmcgdGhl DQo+ICAgIGxhdGVzdCBFVGFnIGFuZCBTaXplMiBPcHRpb24gdmFsdWVzIHdpdGggdGhlIHVwZGF0 ZWQgZGF0YS4NCj4gDQo+IC4uLg0KPiANCj4gKGIpIElmIHRoZSBzZXJ2ZXIgdHJhbnNtaXRzIGEg bmV3IGJvZHkgb2YgZGF0YSAoZS5nLiwgYSB0cmlnZ2VyZWQNCj4gT2JzZXJ2ZQ0KPiAgICBub3Rp ZmljYXRpb24pIHdpdGggYSBuZXcgRVRhZyB0byB0aGUgc2FtZSBjbGllbnQgYXMgYW4gYWRkaXRp b25hbA0KPiAgICByZXNwb25zZSwgdGhlIGNsaWVudCBzaG91bGQgcmVtb3ZlIGFueSBwYXJ0aWFs bHkgcmVjZWl2ZWQgYm9keQ0KPiBoZWxkDQo+ICAgIGZvciBhIHByZXZpb3VzIEVUYWcgZm9yIHRo YXQgcmVzb3VyY2UgYXMgaXQgaXMgdW5saWtlbHkgdGhlDQo+IG1pc3NpbmcNCj4gICAgYmxvY2tz IGNhbiBiZSByZXRyaWV2ZWQuDQo+IA0KPiAoMSkgSXMgKGEpIHN1Z2dlc3RpbmcgdGhhdCB0aGUg bWlzc2luZyBibG9jayByZXF1ZXN0cyB3b3VsZCBiZQ0KPiBzZXJ2aWNlZCBmcm9tIGEgY29weSBv ZiB0aGUg4oCccmVzb3VyY2UgZGF0YSB0aGF0IGhhcyBjaGFuZ2Vk4oCdPyAgVGhpcw0KPiB3b3Vs ZCBtZWFuIHRoYXQgdGhlIGNsaWVudCB3b3VsZCBnZXQgYW4gaW5jb25zaXN0ZW50IHZlcnNpb24g b2YgdGhlDQo+IHJlc291cmNlIHdoaWNoIGlzIG5laXRoZXIgdGhlIG9sZCBvciBuZXcgdmVyc2lv bi4NCg0KW01lZF0gVGhlIGNsaWVudCB3aWxsIGRldGVjdCB0aGF0IGFzIHBlciB0aGUgdGV4dCBy aWdodCBhZnRlciB0aGUgb25lIHlvdSBxdW90ZWQ6IA0KDQogICBJZiB0aGUgc2VydmVyIHJlc3Bv bmRzIGR1cmluZyBhIGJvZHkgdXBkYXRlIHdpdGggYSBkaWZmZXJlbnQgRVRhZw0KICAgICAgICAg ICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl4NCiAgIE9wdGlvbiB2YWx1ZSAoYXMgdGhlIHJlc291cmNlIHJlcHJlc2VudGF0aW9uIGhhcyBj aGFuZ2VkKSwgdGhlbiB0aGUNCiAgIGNsaWVudCBzaG91bGQgdHJlYXQgdGhlIHBhcnRpYWwgYm9k eSB3aXRoIHRoZSBvbGQgRVRhZyBhcyBubyBsb25nZXINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eICAgICAgICAg ICAgDQogICBiZWluZyBmcmVzaC4NCiAgIF5eXl5eXl5eXl5eXiAgDQoNClRoZSBjbGllbnQgY2Fu IHRoZW4gZ2V0IHRoZSBuZXcgdmVyc2lvbi4gSXQgY2FuJ3QgZ2V0IHRoZSBvbGQgb25lIGFzIHRo ZSBzZXJ2ZXIgZG9lcyBub3QgY2FjaGUgaXQuIA0KDQo+IA0KPiAoMikgKGIpIHNlZW1zIGxpa2Ug aXQgaXMgbm90aW5nIHRoYXQgdGhlIHBhcnRpYWxseSByZWNlaXZlZCBib2R5DQo+IHNob3VsZCBp biBmYWN0IGJlIGRpc2NhcmRlZCB0byBhdm9pZCB0aGUgc2l0dWF0aW9uIGluICgxKS4gIEhvd2V2 ZXIsDQo+IGhvdyBkb2VzIHRoZSBjbGllbnQgZ2V0IHRoZSBpbml0aWFsLCBub3cgZGlzY2FyZGVk IGJsb2Nrcz8gIEnigJltIG5vdA0KPiBzdXJlIHdoZXJlIHRoYXQgdHJhbnNtaXNzaW9uIHNob3Vs ZG7igJl0IGZhaWwgd2l0aCBhbiBlcnJvciBhcyBJIGRvbuKAmXQNCj4gZm9sbG93IGhvdyByZWNv dmVyIGlzIHBvc3NpYmxlLg0KPiANCg0KW01lZF0gVGhpcyBpcyBub3QgYW4gZXJyb3IgZ2l2ZW4g dGhhdCB0aGUgY2xpZW50IGlzIGdldHRpbmcgdGhlIG5ldyByZXNvdXJjZSByZXByZXNlbnRhdGlv biBhcyBtYWludGFpbmVkIGJ5IHRoZSBzZXJ2ZXIuIFRoZSBvbGQgb25lIGlzIG9ic29sZXRlIGlm IHlvdSB3aWxsLiANCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVz IHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJp dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVz IG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2Fn ZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBk ZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ry b25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0 b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBv dSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi ZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg T3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVk LCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Thu May 6 00:45:27 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 A36D13A164F; Thu, 6 May 2021 00:45:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-core-new-block@ietf.org, core-chairs@ietf.org, core@ietf.org, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <162028712564.13140.13224982050073005354@ietfa.amsl.com> Date: Thu, 06 May 2021 00:45:25 -0700 Archived-At: Subject: [core] Murray Kucherawy's No Objection on draft-ietf-core-new-block-11: (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, 06 May 2021 07:45:26 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-core-new-block-11: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Ben's DISCUSS. Nearly every SHOULD [NOT] in this document left me wondering "Why isn't this a MUST [NOT]?" or "Since this is a SHOULD, I have a choice, but it's not clear to me how I should make that choice." I see Ben also tripped on at least one of these. Nice work on the IANA Considerations section. From nobody Thu May 6 02:13:16 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 ACA4D3A198F; Thu, 6 May 2021 02:13:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-core-new-block@ietf.org, core-chairs@ietf.org, core@ietf.org, marco.tiloca@ri.se, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <162029239466.19801.6616209452902790093@ietfa.amsl.com> Date: Thu, 06 May 2021 02:13:14 -0700 Archived-At: Subject: [core] Robert Wilton's No Objection on draft-ietf-core-new-block-11: (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, 06 May 2021 09:13:15 -0000 Robert Wilton has entered the following ballot position for draft-ietf-core-new-block-11: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Lars's discuss. I am conflicted with how to ballot on this document, and I am also considering whether to abstain instead. I appreciate the utility and problem that this is trying to address, but I'm concerned that this is pushing CoAP outside the IOT domain, and it seems to be very focused on solving a specific DOTs problem, and seems to make CoAP creep towards TCP. I also note that the following paragraph seems to suggest that what is being done here is somewhat experimental in nature and could even be replaced in future. Hence I wonder whether publishing as an experimental RFC might be an alternative, although that does not really answer the question as to whether it is right to extend CoAP's block handling in this way. This mechanism is not intended for general CoAP usage, and any use outside the intended use case should be carefully weighed against the loss of interoperability with generic CoAP applications. It is hoped that the experience gained with this mechanism can feed future extensions of the block-wise mechanism that will both be generally applicable and serve this particular use case. Regards, Rob From nobody Thu May 6 06:47: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 C9AFC3A22DD; Thu, 6 May 2021 06:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4khBde9miGnh; Thu, 6 May 2021 06:47:31 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 8A9513A22DA; Thu, 6 May 2021 06:47:31 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 146DlTYv020653; Thu, 6 May 2021 09:47:29 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 146DlTYv020653 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1620308849; bh=DR3wT5mcIksmnOE8lDUnfPOpqTwXwNMIkVI4rwlG/pM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=XglnhTBZlgJwqMZq7HRUQDVAI3kr0jQf6l0iRr7u1J/ukzrhe41OLNXdRNS8Ibp8B Kf9XCkGVpaArKWMHJDplxKj47J1qOH851EEpzaKsCzc8g4aBpfnT7q8UHF6r49q2Ic HoazG/e/4+qiizZHHIpeF8mAwMm6mUTCocUnS+dc= Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 146DlS0t028197; Thu, 6 May 2021 09:47:28 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Thu, 6 May 2021 09:47:28 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%21]) with mapi id 15.01.2242.008; Thu, 6 May 2021 09:47:28 -0400 From: Roman Danyliw To: "mohamed.boucadair@orange.com" , The IESG CC: "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: Roman Danyliw's No Objection on draft-ietf-core-new-block-11: (with COMMENT) Thread-Index: AQHXQeNgQirCS7pC+k22RIReFtLSb6rWPO8AgAA7e+A= Date: Thu, 6 May 2021 13:47:27 +0000 Message-ID: <1ca5bb75f8764f6cbbca99d9ed0c1213@cert.org> References: <162024227267.18682.9364450117778772479@ietfa.amsl.com> <2142_1620281565_609388DD_2142_32_1_787AE7BB302AE849A7480A190F8B9330353776FE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <2142_1620281565_609388DD_2142_32_1_787AE7BB302AE849A7480A190F8B9330353776FE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.201.86] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] Roman Danyliw's No Objection on draft-ietf-core-new-block-11: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 13:47:37 -0000 SGkgTWVkIQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGllc2cgPGll c2ctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mDQo+IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20NCj4gU2VudDogVGh1cnNkYXksIE1heSA2LCAyMDIxIDI6MTMgQU0NCj4gVG86IFJv bWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBD YzogZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZzsgY29yZS1jaGFpcnNAaWV0Zi5v cmc7IGNvcmVAaWV0Zi5vcmc7DQo+IG1hcmNvLnRpbG9jYUByaS5zZQ0KPiBTdWJqZWN0OiBSRTog Um9tYW4gRGFueWxpdydzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2Nr LTExOg0KPiAod2l0aCBDT01NRU5UKQ0KPiANCj4gSGkgUm9tYW4sDQo+IA0KPiBUaGFuayB5b3Ug Zm9yIHRoZSByZXZpZXcuDQo+IA0KPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gDQo+IENoZWVycywN Cj4gTWVkDQo+IA0KPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+IERlwqA6IFJv bWFuIERhbnlsaXcgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10gRW52 b3nDqcKgOg0KPiA+IG1lcmNyZWRpIDUgbWFpIDIwMjEgMjE6MTggw4DCoDogVGhlIElFU0cgPGll c2dAaWV0Zi5vcmc+IENjwqA6DQo+ID4gZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9y ZzsgY29yZS1jaGFpcnNAaWV0Zi5vcmc7DQo+ID4gY29yZUBpZXRmLm9yZzsgbWFyY28udGlsb2Nh QHJpLnNlOyBtYXJjby50aWxvY2FAcmkuc2UgT2JqZXTCoDogUm9tYW4NCj4gPiBEYW55bGl3J3Mg Tm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMTE6DQo+ID4gKHdpdGgg Q09NTUVOVCkNCj4gPg0KPiA+IFJvbWFuIERhbnlsaXcgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2lu ZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ID4gZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay0xMTog Tm8gT2JqZWN0aW9uDQo+ID4NCj4gPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBz dWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gPiBlbWFpbCBhZGRyZXNzZXMg aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQNCj4gPiB0 aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiA+DQo+ID4NCj4gPiBQbGVh c2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy0N Cj4gPiBjcml0ZXJpYS5odG1sDQo+ID4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgRElTQ1VT UyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ID4NCj4gPg0KPiA+IFRoZSBkb2N1bWVudCwgYWxv bmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gPiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2Nr Lw0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IC0NCj4gPiBDT01NRU5UOg0K PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+IC0NCj4gPg0KPiA+ICoqIFNlY3Rpb24gMy4yIGFuZCBTZWN0 aW9uIDExDQo+ID4gKGEpIFNlY3Rpb24gMy4yLiBJdCBpcyBub3QgcmVjb21tZW5kZWQgdGhhdCB0 aGVzZSBvcHRpb25zIGFyZSB1c2VkIGluDQo+ID4gYSBOb1NlYyBzZWN1cml0eSBtb2RlDQo+ID4N Cj4gPiAoYikgU2VjdGlvbiAxMS4gSXQgaXMgTk9UIFJFQ09NTUVOREVEIHRoYXQgdGhlIE5vU2Vj IHNlY3VyaXR5IG1vZGUgaXMNCj4gPiAgICB1c2VkIGlmIHRoZSBRLUJsb2NrMSBhbmQgUS1CbG9j azIgT3B0aW9ucyBhcmUgdG8gYmUgdXNlZC4NCj4gPg0KPiA+IEkgYmVsaWV2ZSB0aGF0IHRoZSBp bnRlbmQgb2YgKGEpIGFuZCAoYikgaXMgdG8gY2F1dGlvbiBhZ2FpbnN0IHVzaW5nDQo+ID4gTm9T ZWMgbW9kZSB3aXRoIGVpdGhlciBRLUJsb2NrMSBvciAyLiAgT25lIHJlYWQgb2YgKGIpIHdvdWxk IGJlIHRoYXQNCj4gPiB0aGlzIGd1aWRhbmNlIGlzIG9ubHkgYWJvdXQgd2hlbiBib3RoIG9wdGlv bnMgYXJlIHVzZWQgdG9nZXRoZXIgKGUuZy4sDQo+ID4gdGhlIGxhbmd1YWdlIG9mIFNlY3Rpb24g NC43KS4NCj4gPiBJIHJlY29tbWVuZCByZXN0YXRpbmcgKGIpIHRvIGJlIG1vcmUgYWxvbmcgdGhl IGxpbmVzIG9mOg0KPiA+DQo+ID4gVGhlcmVmb3JlLCBpdCBpcyBOT1QgUkVDT01NRU5ERUQgdG8g dXNlIHRoZSBOb1NlYyBzZWN1cml0eSBtb2RlIGlmDQo+ID4gZWl0aGVyIHRoZQ0KPiA+IFEtQmxv Y2sxIG9yIFEtQmxvY2syIE9wdGlvbnMgaXMgdXNlZC4NCj4gDQo+IFtNZWRdIEFDSy4NCj4gDQo+ ID4NCj4gPiAqKiBTZWN0aW9uIDQuMS4gIENvbGxvcXVpYWxpc20uIHMvbG9jYWwgY29uZmlndXJh dGlvbiBrbm9iL2xvY2FsDQo+ID4gY29uZmlndXJhdGlvbiBvcHRpb24vDQo+ID4NCj4gDQo+IFtN ZWRdIENoYW5nZWQgaXQgdG8gImxvY2FsIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVyIi4NCg0KVGhh bmtzIGZvciB0aGVzZSBjaGFuZ2VzLg0KDQo+ID4gKiogU2VjdGlvbiA0LjQuDQo+ID4NCj4gPiAo YSkgICBJZiB0aGUgc2VydmVyIGRldGVjdHMgcGFydCB3YXkgdGhyb3VnaCBhIGJvZHkgdHJhbnNm ZXIgdGhhdCB0aGUNCj4gPiAgICByZXNvdXJjZSBkYXRhIGhhcyBjaGFuZ2VkIGFuZCB0aGUgc2Vy dmVyIGlzIG5vdCBtYWludGFpbmluZyBhDQo+ID4gY2FjaGVkDQo+ID4gICAgY29weSBvZiB0aGUg b2xkIGRhdGEsIHRoZW4gdGhlIHRyYW5zbWlzc2lvbiBpcyB0ZXJtaW5hdGVkLiAgQW55DQo+ID4g ICAgc3Vic2VxdWVudCBtaXNzaW5nIGJsb2NrIHJlcXVlc3RzIE1VU1QgYmUgcmVzcG9uZGVkIHRv IHVzaW5nIHRoZQ0KPiA+ICAgIGxhdGVzdCBFVGFnIGFuZCBTaXplMiBPcHRpb24gdmFsdWVzIHdp dGggdGhlIHVwZGF0ZWQgZGF0YS4NCj4gPg0KPiA+IC4uLg0KPiA+DQo+ID4gKGIpIElmIHRoZSBz ZXJ2ZXIgdHJhbnNtaXRzIGEgbmV3IGJvZHkgb2YgZGF0YSAoZS5nLiwgYSB0cmlnZ2VyZWQNCj4g PiBPYnNlcnZlDQo+ID4gICAgbm90aWZpY2F0aW9uKSB3aXRoIGEgbmV3IEVUYWcgdG8gdGhlIHNh bWUgY2xpZW50IGFzIGFuIGFkZGl0aW9uYWwNCj4gPiAgICByZXNwb25zZSwgdGhlIGNsaWVudCBz aG91bGQgcmVtb3ZlIGFueSBwYXJ0aWFsbHkgcmVjZWl2ZWQgYm9keSBoZWxkDQo+ID4gICAgZm9y IGEgcHJldmlvdXMgRVRhZyBmb3IgdGhhdCByZXNvdXJjZSBhcyBpdCBpcyB1bmxpa2VseSB0aGUg bWlzc2luZw0KPiA+ICAgIGJsb2NrcyBjYW4gYmUgcmV0cmlldmVkLg0KPiA+DQo+ID4gKDEpIElz IChhKSBzdWdnZXN0aW5nIHRoYXQgdGhlIG1pc3NpbmcgYmxvY2sgcmVxdWVzdHMgd291bGQgYmUN Cj4gPiBzZXJ2aWNlZCBmcm9tIGEgY29weSBvZiB0aGUg4oCccmVzb3VyY2UgZGF0YSB0aGF0IGhh cyBjaGFuZ2Vk4oCdPyAgVGhpcw0KPiA+IHdvdWxkIG1lYW4gdGhhdCB0aGUgY2xpZW50IHdvdWxk IGdldCBhbiBpbmNvbnNpc3RlbnQgdmVyc2lvbiBvZiB0aGUNCj4gPiByZXNvdXJjZSB3aGljaCBp cyBuZWl0aGVyIHRoZSBvbGQgb3IgbmV3IHZlcnNpb24uDQo+IA0KPiBbTWVkXSBUaGUgY2xpZW50 IHdpbGwgZGV0ZWN0IHRoYXQgYXMgcGVyIHRoZSB0ZXh0IHJpZ2h0IGFmdGVyIHRoZSBvbmUgeW91 IHF1b3RlZDoNCj4gDQo+ICAgIElmIHRoZSBzZXJ2ZXIgcmVzcG9uZHMgZHVyaW5nIGEgYm9keSB1 cGRhdGUgd2l0aCBhIGRpZmZlcmVudCBFVGFnDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+ICAgIE9wdGlvbiB2 YWx1ZSAoYXMgdGhlIHJlc291cmNlIHJlcHJlc2VudGF0aW9uIGhhcyBjaGFuZ2VkKSwgdGhlbiB0 aGUNCj4gICAgY2xpZW50IHNob3VsZCB0cmVhdCB0aGUgcGFydGlhbCBib2R5IHdpdGggdGhlIG9s ZCBFVGFnIGFzIG5vIGxvbmdlcg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KPiAgICBiZWluZyBmcmVzaC4N Cj4gICAgXl5eXl5eXl5eXl5eDQo+IA0KPiBUaGUgY2xpZW50IGNhbiB0aGVuIGdldCB0aGUgbmV3 IHZlcnNpb24uIEl0IGNhbid0IGdldCB0aGUgb2xkIG9uZSBhcyB0aGUgc2VydmVyDQo+IGRvZXMg bm90IGNhY2hlIGl0Lg0KPiANCj4gPg0KPiA+ICgyKSAoYikgc2VlbXMgbGlrZSBpdCBpcyBub3Rp bmcgdGhhdCB0aGUgcGFydGlhbGx5IHJlY2VpdmVkIGJvZHkNCj4gPiBzaG91bGQgaW4gZmFjdCBi ZSBkaXNjYXJkZWQgdG8gYXZvaWQgdGhlIHNpdHVhdGlvbiBpbiAoMSkuICBIb3dldmVyLA0KPiA+ IGhvdyBkb2VzIHRoZSBjbGllbnQgZ2V0IHRoZSBpbml0aWFsLCBub3cgZGlzY2FyZGVkIGJsb2Nr cz8gIEnigJltIG5vdA0KPiA+IHN1cmUgd2hlcmUgdGhhdCB0cmFuc21pc3Npb24gc2hvdWxkbuKA mXQgZmFpbCB3aXRoIGFuIGVycm9yIGFzIEkgZG9u4oCZdA0KPiA+IGZvbGxvdyBob3cgcmVjb3Zl ciBpcyBwb3NzaWJsZS4NCj4gPg0KPiANCj4gW01lZF0gVGhpcyBpcyBub3QgYW4gZXJyb3IgZ2l2 ZW4gdGhhdCB0aGUgY2xpZW50IGlzIGdldHRpbmcgdGhlIG5ldyByZXNvdXJjZQ0KPiByZXByZXNl bnRhdGlvbiBhcyBtYWludGFpbmVkIGJ5IHRoZSBzZXJ2ZXIuIFRoZSBvbGQgb25lIGlzIG9ic29s ZXRlIGlmIHlvdSB3aWxsLg0KDQpHb3QgaXQuICBUaGFua3MgZm9yIGV4cGxhaW5pbmcgaXQuDQoN ClJvbWFuDQoNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gY29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdQ0KPiBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUNCj4gc2lnbmFsZXIgYSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzDQo+IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUNCj4gcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPiANCj4gVGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQNCj4gaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhl eSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkDQo+IG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uDQo+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMNCj4gbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzLg0KPiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbg0KPiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuDQo+IFRoYW5rIHlvdS4NCg0K From nobody Thu May 6 10:35: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 B19853A2A43; Thu, 6 May 2021 10:35:31 -0700 (PDT) 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 ME14_1yTAFa3; Thu, 6 May 2021 10:35:25 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 C10B03A2A3F; Thu, 6 May 2021 10:35:23 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 4FbghS61jkz2y8k; Thu, 6 May 2021 19:35:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620322520; bh=4YBqAlX9VRbelHaBW3jDEpO6loxWj+gnPJYoiLFlD9s=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=wDtwIBXRK7HO9TMd1X1dXuEvAXmNSQa8Mltpsr8rsh6dBLBW4pLvqF268s2AEeQCq 0KsBss6MCv10z3yUt1hizms8rSsCvEZgEfSQZ+t6EB4Q2vEOU3TkFz3huY5J/UUAcK kg0xqgxL2u/HNhGnCZdvdlpdROcXyqH3N6BuyDQEWhSWbzrKkRZSvsWainEluaCdrN I5/sSUW+VIzR2lbp4NLAfEFpPp0i3vpopEywqUyEwGmXI6y/Ddomy0412Kf9hlgwfZ FMS6wX5NDwHqfXn8G/gkRXb0SZmLanGV/QOiVIRtjV8Avqmq2cbKpfb3oBGN9s9H1G SvBFjFAPUxIOw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4FbghS4Yxtz3wbX; Thu, 6 May 2021 19:35:20 +0200 (CEST) From: To: Benjamin Kaduk , The IESG CC: "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXQhtQJ0eiusrJ/U2y11QoEHt7QqrWMTfg Date: Thu, 6 May 2021 17:35:19 +0000 Message-ID: <12589_1620322520_609428D8_12589_262_1_787AE7BB302AE849A7480A190F8B933035377DD2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162026630680.17506.6477675472375470197@ietfa.amsl.com> In-Reply-To: <162026630680.17506.6477675472375470197@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 17:35:32 -0000 SGkgQmVuLCANCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiBBbGwgdGhlIGNoYW5nZXMgY2Fu IGJlIHRyYWNrZWQgYXQ6IGh0dHBzOi8vdGlueXVybC5jb20vbmV3LWJsb2NrLWxhdGVzdC4gDQoN ClBsZWFzZSBzZWUgaW5saW5lLiANCg0KQ2hlZXJzLA0KSm9uICYgTWVkDQoNCj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEJlbmphbWluIEthZHVrIHZpYSBEYXRhdHJhY2tl ciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+IEVudm95w6nCoDogamV1ZGkgNiBtYWkgMjAy MSAwMzo1OA0KPiDDgMKgOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2PCoDogZHJhZnQt aWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZzsgY29yZS1jaGFpcnNAaWV0Zi5vcmc7DQo+IGNv cmVAaWV0Zi5vcmc7IG1hcmNvLnRpbG9jYUByaS5zZTsgbWFyY28udGlsb2NhQHJpLnNlDQo+IE9i amV0wqA6IEJlbmphbWluIEthZHVrJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWNvcmUtbmV3LWJs b2NrLTExOg0KPiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gQmVuamFtaW4gS2Fk dWsgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0 LWlldGYtY29yZS1uZXctYmxvY2stMTE6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywg cGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiBl bWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZSB0byBjdXQNCj4gdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+ IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQv ZGlzY3Vzcy0NCj4gY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBE SVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFs b25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS1uZXctYmxvY2sv DQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiAtDQo+IA0KPiBJIGhhdmUgYSBjb25jZXJuIGFib3V0IHRoZSBNQVhfUEFZTE9BRFMg Y29uZ2VzdGlvbi1jb250cm9sIHBhcmFtZXRlci4NCj4gSW4gU2VjdGlvbiA3LjIgaXQgaXMgc3Rh dGVkIHRoYXQgYm90aCBlbmRwb2ludHMgb25seSBTSE9VTEQgaGF2ZSB0aGUNCj4gc2FtZSB2YWx1 ZS4gIEkgZG9uJ3Qgc2VlIGhvdyB0aGlzIGNhbiBiZSBhbnl0aGluZyBsZXNzIHRoYW4gTVVTVCwN Cj4gZ2l2ZW4gdGhhdCB3ZSBhdHRyaWJ1dGUgc2VtYW50aWNzIHRvIHdoZXRoZXIgTlVNIG1vZHVs byBNQVhfUEFZTE9BRFMNCj4gaXMgemVybyBvciBub24temVybyBpbiB0aGUgcHJvY2Vzc2luZyBv ZiB0aGUgUS1CbG9jazIgb3B0aW9uLiAgSWYgdGhlDQo+IGVuZHBvaW50cyBkaXNhZ3JlZSBvbiB0 aGUgdmFsdWUgb2YgTUFYX1BBWUxPQURTIHRoZXkgd2lsbCBkaXNhZ3JlZSBvbg0KPiB0aGUgc2Vt YW50aWNzIG9mIFEtQmxvY2syIC0tIGhvdyBjYW4gdGhhdCBiZSBpbnRlcm9wZXJhYmxlPw0KPiAo QmVpbmcgYWJsZSB0byBuZWdvdGlhdGUgdGhlIHZhbHVlIGRvZXMgbm90IHNlZW0gaW5oZXJlbnRs eQ0KPiBwcm9ibGVtYXRpYywgYnV0IHNpbmNlIGl0IGlzIHJlbGV2YW50IGZvciBwcm90b2NvbCBz ZW1hbnRpY3MgaXQgc2VlbXMNCj4gbGlrZSB0aGUgdmFsdWUgbXVzdCBiZSBpZGVudGljYWwgb24g Ym90aCBlbmRwb2ludHMuKSBUaGlzIHNlZW1zDQo+IGVzcGVjaWFsbHkgaW1wb3J0YW50IHRvIGhh dmUgY2xhcml0eSBvbiBnaXZlbiB0aGF0IHRoZSBjdXJyZW50DQo+IHNwZWNpZmljYXRpb24gYWxs b3dzIGZvciBNQVhfUEFZTE9BRFMgdG8gYmUgZGVjcmVhc2VkIGF0IHJ1bnRpbWUgaW4NCj4gcmVz cG9uc2UgdG8gY29uZ2VzdGlvbiBmZWVkYmFjayBvdmVyIGEgMjQtaG91ciBwZXJpb2QsIHdpdGgg bm8NCj4gc3luY2hyb25pemF0aW9uIGJldHdlZW4gcGVlcnMgcHJvdmlkZWQgKCJOb3RlIHRoYXQg dGhlIENvQVAgcGVlciB3aWxsDQo+IG5vdCBrbm93IGFib3V0IHRoZSBNQVhfUEFZTE9BRFMgY2hh bmdlIHVudGlsIGl0IGlzIHJlY29uZmlndXJlZCIuKQ0KPiANCj4gDQoNCkltcGxlbWVudGF0aW9u IHRlc3Rpbmcgd2l0aCBNQVhfUEFZTE9BRCBiZWluZyBkaWZmZXJlbnQgaW4gdGhlIHBlZXJzIHNo b3dlZCB0aGluZ3Mgd29ya2VkIGJhZGx5ICh1bm5lY2Vzc2FyeSB0aW1lb3V0cy9yZWNvdmVyeSkg YnV0IGNvbnRpbnVlZCB0byB3b3JrLiANCg0KSWYgdGhlIHBlZXJzIHdlcmUgbmVnb3RpYXRpbmcg YW5kIGluc3RhbGxpbmcgYSBuZXcgY29tbW9uIHZhbHVlIChhcHBsaWNhdGlvbiBsYXllciksIHRo ZXJlIHdhcyBhIGJyaWVmIHBlcmlvZCBvZiBpbnN0YWJpbGl0eS4NCg0KUGxlYXNlIG5vdGUgdGhh dCB0aGlzIGlzIGEgdmFsdWUgdGhhdCBpcyB1bmxpa2VseSB0byBjaGFuZ2U6IDE1MDAgYnl0ZSBw YWNrZXRzIGFuZCBNQVhfUEFZTE9BRFMoMTApIGdpdmVzIGEgc2V0IG9mIDE1LDAwMCBieXRlcy4g V2l0aCBhbiB1cCB0byBOT05fVElNRU9VVCAoMiBzZWNzKSBkZWxheSwgYXZlcmFnZSBkYXRhIHJh dGVzIGFyZSBvZiB0aGUgb3JkZXIgb2YgNjBrYnBzICgxNTAwICogOCAqIDEwIC8gMiksIHNvIHBy b3ZpZGluZyB0aGUgY29uZ2VzdGVkIG5ldHdvcmsgY2FuIGhhbmRsZSA2MEticHMsIGFsbCB3aWxs IGJlIE9LLiBJZiBoaWdoZXIgdmFsdWVzLCB0aGVuIHRoZSAnQ29udGludWUnIHdpbGwgY29tZSBi YWNrIHF1aWNrZXIgdGhhbiB0aGUgTk9OX1RJTUVPVVQuDQoNCg0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g LQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLQ0KPiANCj4gSSBtYWRlIHNvbWUgZWRp dG9yaWFsIHN1Z2dlc3Rpb25zIGluIGEgZ2l0aHViIHB1bGwgcmVxdWVzdCBhdA0KPiBodHRwczov L2dpdGh1Yi5jb20vY29yZS13Zy9uZXctYmxvY2svcHVsbC8yMSAuICBJdCBzZWVtcyB0aGF0IHRo ZXJlDQo+IGFyZSBub3cgc29tZSBtZXJnZSBjb25mbGljdHM7IEkgY2Fubm90IHByb21pc2UgdG8g aGF2ZSBhdmFpbGFiaWxpdHkNCj4gdG8gdHJ5IHRvIHJlc29sdmUgdGhlbSBwYXJ0aWN1bGFybHkg cXVpY2tseSwgYnV0IEkgY2FuIGRvIHNvDQo+ICJldmVudHVhbGx5IiBpZiBuZWVkZWQuDQo+IA0K DQpGaXhlZCB0aGUgY29uZmxpY3QuIFdlbnQgd2l0aCBtYW55IG9mIHlvdXIgc3VnZ2VzdGlvbnMu IFRoYW5rcy4NCg0KPiBTZWN0aW9uIDENCj4gDQo+ICAgIFRoZXJlIGlzIGEgcmVxdWlyZW1lbnQg Zm9yIHRoZXNlIGJsb2NrcyBvZiBkYXRhIHRvIGJlIHRyYW5zbWl0dGVkDQo+IGF0DQo+ICAgIGhp Z2hlciByYXRlcyB1bmRlciBuZXR3b3JrIGNvbmRpdGlvbnMgd2hlcmUgdGhlcmUgbWF5IGJlDQo+ IGFzeW1tZXRyaWNhbA0KPiAgICB0cmFuc2llbnQgcGFja2V0IGxvc3MgKGkuZS4sIHJlc3BvbnNl cyBtYXkgZ2V0IGRyb3BwZWQpLiAgQW4NCj4gZXhhbXBsZQ0KPiAgICBpcyB3aGVuIGEgbmV0d29y ayBpcyBzdWJqZWN0IHRvIGEgRGlzdHJpYnV0ZWQgRGVuaWFsIG9mIFNlcnZpY2UNCj4gICAgKERE b1MpIGF0dGFjayBhbmQgdGhlcmUgaXMgYSBuZWVkIGZvciBERG9TIG1pdGlnYXRpb24gYWdlbnRz DQo+IHJlbHlpbmcNCj4gICAgdXBvbiBDb0FQIHRvIGNvbW11bmljYXRlIHdpdGggZWFjaCBvdGhl ciAoZS5nLiwNCj4gICAgW1JGQzg3ODJdW0ktRC5pZXRmLWRvdHMtdGVsZW1ldHJ5XSkuICBBcyBh IHJlbWluZGVyLCBbUkZDNzk1OV0NCj4gDQo+IEkgc3VwcG9zZSB0aGUgUkZDIEVkaXRvciB3aWxs IGRvIHRoZSByaWdodCB0aGluZyBhYm91dCByZWZlcmVuY2luZw0KPiA4NzgyIHZzIDg3ODJiaXMg Li4uIGFuZCBJIGFtIG92ZXJkdWUgaW4gZm9sbG93aW5nIHVwIG9uIHRoZSBJRVRGIExDDQo+IHJl c3VsdHMgZm9yIHRoZSBsYXR0ZXIgOigNCj4gDQo+IFNlY3Rpb24gMg0KPiANCj4gV2UgY3VycmVu dGx5IGludHJvZHVjZSB0aGUgY29uY2VwdCBvZiBNQVhfUEFZTE9BRHMgYnkgaW1wbGljaXQgdXNl IGluDQo+IGEgZmV3IHBsYWNlcyBiZWZvcmUgaXQgaXMgYWN0dWFsbHkgZ2l2ZW4gYSBwcm9wZXIg ZGVmaW5pdGlvbi4gIEkNCj4gd29uZGVyIGlmIG1lbnRpb25pbmcgaGVyZSB0aGF0IGl0IGlzIHVz ZWQgdG8gZ3JvdXAgYSBiYXRjaCBvZiBibG9ja3MNCj4gd291bGQgaGVscCB0aGUgcmVhZGVyLg0K PiANCg0KQWRkZWQgdGhlIGZvbGxvd2luZyBpbiBTZWN0aW9uIDI6DQoNCk5FVzoNCiAgIE1BWF9Q QVlMT0FEUyByZWZlcnMgdG8gdGhlIG1heGltdW0gbnVtYmVyIG9mIGJsb2NrcyB0aGF0IGNhbiBi ZSBzZW50DQogICBieSBhbiBlbmRwb2ludA0KDQo+IFNlY3Rpb24gMw0KPiANCj4gICAgbyAgVGhl eSBzdXBwb3J0IHNlbmRpbmcgYW4gZW50aXJlIGJvZHkgdXNpbmcgTm9uLWNvbmZpcm1hYmxlIChO T04pDQo+ICAgICAgIG1lc3NhZ2VzIHdpdGhvdXQgcmVxdWlyaW5nIGEgcmVzcG9uc2UgZnJvbSB0 aGUgcGVlci4NCj4gDQo+IEkgcHV0IHRoaXMgY2hhbmdlIGluIG15IGdpdGh1YiBQUiwgYnV0IHJl cGVhdGluZyBoZXJlIGZvciB2aXNpYmlsaXR5DQo+IHNpbmNlIEkgYW0gbWFraW5nIGFuIGFzc3Vt cHRpb246IEkgcHJvcG9zZSBhZGRpbmcgImludGVybWVkaWF0ZSIgZm9yDQo+ICJ3aXRob3V0IHJl cXVpcmluZyBhbiBpbnRlcm1lZGlhdGUgcmVzcG9uc2UgZnJvbSB0aGUgcGVlciIuICBNeQ0KPiB1 bmRlcnN0YW5kaW5nIGlzIHRoYXQgYSBmaW5hbCBtZXNzYWdlIGluZGljYWluZyBzdWNjZXNzZnVs IHJlY2VpcHRpb24NCj4gaXMgc3RpbGwgdXNlZCAob3IgYSBzZWxlY3RpdmUgYWNrIGluIGNhc2Ug b2YgbG9zcyksIHNvIHRoZSBjb250cmFzdA0KPiB0byBSRkMNCj4gNzk1OSBpcyBpbiB0aGUgKGxh Y2sgb2YpIG5lZWQgZm9yIGludGVybWVkaWF0ZSByZXNwb25zZXMgZm9yIGVhY2gNCj4gYmxvY2su DQo+IA0KDQpPSy4NCg0KPiAgICBvICBNaXhpbmcgb2YgTk9OIGFuZCBDT04gZHVyaW5nIHJlcXVl c3RzL3Jlc3BvbnNlcyB1c2luZyBRLUJsb2NrDQo+IGlzDQo+ICAgICAgIG5vdCBzdXBwb3J0ZWQu DQo+IA0KPiBUaGVyZSBpcyBwZXJoYXBzIHN1YnRsZSBkaWZmZXJlbmNlcyBhY3Jvc3MgIm5vdCBz dXBwb3J0ZWQiLA0KPiAiZm9yYmlkZGVuIiwgYW5kICJub3QgZGVmaW5lZCBpbiB0aGlzIHNwZWNp ZmljYXRpb24iLiAgRG8gd2UgcGVyaGFwcw0KPiBhY3R1YWxseSBtZWFuICJmb3JiaWRkZW4iPw0K DQpJdCBpcyBub3QgYWxsb3dlZCBhcyBwZXI6ICANCg0KICAgVGhlIHRyYW5zbWlzc2lvbiBvZiBh bGwgdGhlIGJsb2NrcyBvZiBhIHNpbmdsZSBib2R5IG92ZXIgYW4NCiAgIHVucmVsaWFibGUgdHJh bnNwb3J0IE1VU1QgZWl0aGVyIGFsbCBiZSBDb25maXJtYWJsZSBvciBhbGwgYmUgTm9uLQ0KICAg Y29uZmlybWFibGUuICBUaGlzIGlzIG1lYW50IHRvIHNpbXBsaWZ5IHRoZSBjb25nZXN0aW9uIGNv bnRyb2wNCiAgIHByb2NlZHVyZS4NCg0KU2F5aW5nICJub3Qgc3VwcG9ydGVkIiBpcyBPSyBpbiBT ZWN0aW9uIDMsIHRob3VnaC4gDQoNCj4gDQo+IFNlY3Rpb24gMy4yDQo+IA0KPiAgICAoRE9UUykg dGhhdCBjYW5ub3QgdXNlIENPTiByZXNwb25zZXMgdG8gaGFuZGxlIHBvdGVudGlhbCBwYWNrZXQN Cj4gbG9zcw0KPiAgICBhbmQgdGhhdCBzdXBwb3J0IGFwcGxpY2F0aW9uLXNwZWNpZmljIG1lY2hh bmlzbXMgdG8gYXNzZXNzIHdoZXRoZXINCj4gICAgdGhlIHJlbW90ZSBwZWVyIGlzIGFibGUgdG8g aGFuZGxlIHRoZSBtZXNzYWdlcyBzZW50IGJ5IGEgQ29BUA0KPiAgICBlbmRwb2ludCAoZS5nLiwg RE9UUyBoZWFydGJlYXRzIGluIFNlY3Rpb24gNC43IG9mIFtSRkM4NzgyXSkuDQo+IA0KPiBDYW4g d2UgZ2V0IGdyZWF0ZXIgY2xhcml0eSBvbiB3aGF0ICJhYmxlIHRvIGhhbmRsZSIgaXMgaW50ZW5k ZWQgdG8NCj4gbWVhbj8NCj4gSSBjYW4ndCB0ZWxsIGlmIGl0J3MgYW55d2hlcmUgYmV0d2VlbiAi dGhlIHRyYW5zcG9ydCBpcyBhYmxlIHRvDQo+IGRlbGl2ZXIgbWVzc2FnZSBib2RpZXMiIGFuZCAi dGhlIHNvZnR3YXJlIHN0YWNrIGltcGxlbWVudHMgYW5kDQo+IGVuYWJsZXMgYSBwYXJ0aWN1bGFy IGZlYXR1cmUiLg0KDQpUaGUgaXNzdWVzIGlzIHRvIGNoZWNrIHRoYXQgd2UgYXJlIG5vdCBvdmVy bG9hZGluZyB0aGUgcmVtb3RlIHBlZXIuIEkgbWFkZSB0aGlzIGNoYW5nZTogDQoNCnMvYWJsZSB0 byBoYW5kbGUvaXMgbm90IG92ZXJsb2FkZWQgYW5kIGlzIHRodXMgYWJsZSB0byBwcm9jZXNzDQoN Cj4gDQo+IFNlY3Rpb24gNC4xDQo+IA0KPiAgICBXaGVuIHRoZSBDb250ZW50LUZvcm1hdCBPcHRp b24gaXMgcHJlc2VudCB0b2dldGhlciB3aXRoIHRoZSBRLQ0KPiBCbG9jazENCj4gICAgb3IgUS1C bG9jazIgT3B0aW9uLCB0aGUgb3B0aW9uIGFwcGxpZXMgdG8gdGhlIGJvZHkgbm90IHRvIHRoZQ0K PiBwYXlsb2FkDQo+ICAgIChpLmUuLCBpdCBtdXN0IGJlIHRoZSBzYW1lIGZvciBhbGwgcGF5bG9h ZHMgb2YgdGhlIHNhbWUgYm9keSkuDQo+IA0KPiBEbyB3ZSBoYXZlIGEgbm9ybWF0aXZlIHJlcXVp cmVtZW50IHNvbWV3aGVyZSB0aGF0IHRoZSByZWNpcGllbnQgdHJhY2sNCj4gYW5kIGNvbXBhcmUg dGhlIGNvbnRlbnQtZm9ybWF0IHZhbHVlcyBhY3Jvc3MgYmxvY2tzPyAgSWYgbm90LCBzaG91bGQN Cj4gd2U/DQoNCk5vIHRleHQgaXMgaW5jbHVkZWQgYmVjYXVzZSByZmM3OTU5I3NlY3Rpb24tMi45 LjIgKHdoaWNoIGRlZmluZXMgNC4wOCBhbmQgY2l0ZWQgaW4gdGhlIHNwZWMpIGFscmVhZHkgY292 ZXJzIHRoYXQgY2hlY2suIA0KDQpMaWtld2lzZSwgdGhlIGNsaWVudCBzaWRlIGlzIGFsc28gY292 ZXJzIGluIFJGQzc5NTk6IA0KDQogICBJZiBibG9ja3Mgb2YgYQ0KICAgcmVzcG9uc2UgYm9keSBh cnJpdmUgd2l0aCBkaWZmZXJlbnQgQ29udGVudC1Gb3JtYXQgT3B0aW9ucywgaXQgaXMgdXANCiAg IHRvIHRoZSBjbGllbnQgaG93IHRvIGhhbmRsZSB0aGlzIGVycm9yIChpdCB3aWxsIHR5cGljYWxs eSBhYm9ydCBhbnkNCiAgIG9uZ29pbmcgYmxvY2std2lzZSB0cmFuc2ZlcikuIA0KDQpBcyBhIHJl bWluZGVyLCB3ZSBkbyBzYXk6IA0KDQogICBUaGUgZGV2aWF0aW9ucyBmcm9tIEJsb2NrMSBhbmQg QmxvY2syIE9wdGlvbnMgYXJlIHNwZWNpZmllZCBpbg0KICAgU2VjdGlvbiA0Lg0KDQo+IA0KPiAg ICBRLUJsb2NrMiBPcHRpb24gaXMgdXNlZnVsIHdpdGggR0VULCBQT1NULCBQVVQsIEZFVENILCBQ QVRDSCwgYW5kDQo+ICAgIGlQQVRDSCByZXF1ZXN0cyBhbmQgdGhlaXIgcGF5bG9hZC1iZWFyaW5n IHJlc3BvbnNlcyAoMi4wMSwgMi4wMiwNCj4gICAgMi4wMywgMi4wNCwgYW5kIDIuMDUpIChTZWN0 aW9uIDUuNSBvZiBbUkZDNzI1Ml0pLg0KPiANCj4gRG8gd2UgbmVlZCBhbiAiZS5nLiIgaW4gZnJv bnQgb2YgdGhlIGxpc3QsIHRvIGFjY291bnQgZm9yIHRoZQ0KPiBwb3RlbnRpYWwgZnV0dXJlIHJl Z2lzdHJhdGlvbiBvZiBuZXcgcGF5bG9hZC1iZWFyaW5nIHJlc3BvbnNlIGNvZGVzPw0KDQpBZ3Jl ZS4gUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIHRoZSByZWFzb24gd2h5IHdlIGFyZSB1c2luZyAi b3Igc2ltaWxhciIgaW4gb3RoZXIgc2VjdGlvbnMuIA0KDQo+IA0KPiAgICBJZiBRLUJsb2NrMSBP cHRpb24gaXMgcHJlc2VudCBpbiBhIHJlcXVlc3Qgb3IgUS1CbG9jazIgT3B0aW9uIGluIGENCj4g ICAgcmVzcG9uc2UgKGkuZS4sIGluIHRoYXQgbWVzc2FnZSB0byB0aGUgcGF5bG9hZCBvZiB3aGlj aCBpdA0KPiBwZXJ0YWlucyksDQo+IA0KPiBDYW4gd2UgcmV3b3JkIHRoaXMgcGFyZW50aGV0aWNh bCBpbiBhIGxlc3MgY29udm9sdXRlZCB3YXk/ICBJJ20gbm90DQo+IGV2ZW4gc3VyZSBJJ20gcGFy c2luZyBpdCBwcm9wZXJseS4NCg0KQ2hhbmdlZCB0bzogDQoNCiJJZiB0aGUgUS1CbG9jazEgT3B0 aW9uIGlzIHByZXNlbnQgaW4gYSByZXF1ZXN0IG9yIHRoZSBRLUJsb2NrMiBPcHRpb24gaXMgcmV0 dXJuZWQgaW4gYSByZXNwb25zZSwuLi4iDQoNCj4gDQo+ICAgIFtSRkM3MjUyXSkuICBUbyByZWxp YWJseSBnZXQgYSByZWplY3Rpb24gbWVzc2FnZSwgaXQgaXMgdGhlcmVmb3JlDQo+ICAgIFJFUVVJ UkVEIHRoYXQgY2xpZW50cyB1c2UgYSBDb25maXJtYWJsZSBtZXNzYWdlIGZvciBkZXRlcm1pbmlu Zw0KPiAgICBzdXBwb3J0IGZvciBRLUJsb2NrMSBhbmQgUS1CbG9jazIgT3B0aW9ucy4NCj4gDQo+ IChJIGtub3cgdGhhdCBzb21lIG90aGVyIGRpc2N1c3Npb24gaGFwcGVuZWQgb24gdGhpcyBtZWNo YW5pc20sIGJ1dCBJDQo+IGZvcmdldCBpZiB0aGVyZSBhcmUgYWxyZWFkeSBwbGFucyB0byBhZGQg YSBjbGFyaWZpY2F0aW9uIHRoYXQgdGhpcyBpcw0KPiBvbmx5IG5lZWRlZCBvbmNlIHBlciBwZWVy IHdpdGhpbiBhIGdpdmVuIHNldCBvZiBleGNoYW5nZXMuKQ0KDQpXZSBoYXZlIGFkZGVkIHRoZSBm b2xsb3dpbmcgdG8gYWRkcmVzcyBzb21lIG90aGVyIGNvbW1lbnRzIDoNCg0KIiAuLi5hcGFydCBm cm9tIHRoZQ0KICAgaW5pdGlhbCBRLUJsb2NrIGZ1bmN0aW9uYWxpdHkgbmVnb3RpYXRpb24uICIN CiAgIF5eXl5eXl5eDQogDQo+IA0KPiAgICBUaGUgUS1CbG9jazIgT3B0aW9uIGlzIHJlcGVhdGFi bGUgd2hlbiByZXF1ZXN0aW5nIHJldHJhbnNtaXNzaW9uDQo+IG9mDQo+ICAgIG1pc3NpbmcgYmxv Y2tzLCBidXQgbm90IG90aGVyd2lzZS4gIEV4Y2VwdCB0aGF0IGNhc2UsIGFueSByZXF1ZXN0DQo+ ICAgIGNhcnJ5aW5nIG11bHRpcGxlIFEtQmxvY2sxIChvciBRLUJsb2NrMikgT3B0aW9ucyBNVVNU IGJlIGhhbmRsZWQNCj4gICAgZm9sbG93aW5nIHRoZSBwcm9jZWR1cmUgc3BlY2lmaWVkIGluIFNl Y3Rpb24gNS40LjUgb2YgW1JGQzcyNTJdLg0KPiANCj4gU2luY2UgdGhlc2UgYXJlIGNyaXRpY2Fs IG9wdGlvbnMsIHRoZSByZWZlcmVuY2VkIHByb2NlZHVyZXMgaW52b2x2ZQ0KPiByZWplY3Rpbmcg dGhlIG1lc3NhZ2UsIHJpZ2h0PyAgSXMgdGhhdCBpbXBvcnRhbnQgZW5vdWdoIHRvIG5vdGUNCj4g ZGlyZWN0bHk/DQoNClNlY3Rpb24gNS40LjUgb2YgNzI1MiBpbmNsdWRlcyBhIHBvaW50ZXIgdG8g NS40LjEuIEkgZG9uJ3QgdGhpbmsgYSBjaGFuZ2UgaXMgbmVlZGVkLiAgDQoNCj4gDQo+ICAgIE5v dGUgdGhhdCBpZiBRLUJsb2NrMSBvciBRLUJsb2NrMiBPcHRpb25zIGFyZSBpbmNsdWRlZCBpbiBh IHBhY2tldA0KPiBhcw0KPiAgICBJbm5lciBvcHRpb25zLCBCbG9jazEgb3IgQmxvY2syIE9wdGlv bnMgTVVTVCBOT1QgYmUgaW5jbHVkZWQgYXMNCj4gSW5uZXINCj4gICAgb3B0aW9ucy4gIFNpbWls YXJseSB0aGVyZSBNVVNUIE5PVCBiZSBhIG1peCBvZiBRLUJsb2NrIGFuZCBCbG9jaw0KPiBmb3IN Cj4gICAgdGhlIE91dGVyIG9wdGlvbnMuICBbLi4uXQ0KPiANCj4gKEhvcGVmdWxseSBhIHNpbGx5 IHF1ZXN0aW9uLCBidXQgZG8gd2UgbWFrZSB0aGUgYW5hbG9nb3VzIHByb2hpYml0aW9uDQo+IGFn YWluc3QgY29tYmluaW5nIFEtQmxvY2sgYW5kIHJlZ3VsYXIgQmxvY2sgZm9yIG5vbi1PU0NPUkUg Y2FzZXMNCj4gYW55d2hlcmU/ICBJIHRob3VnaHQgd2UgZGlkLCBidXQgbm93IEkgY2FuJ3QgZmlu ZCBpdC4uLikNCg0KVGhlIG91dGVyIHdyYXBwZXIgY292ZXJzIHRoaXMgaW4gb3VyIG9waW5pb246 IGlmIHRoZXJlIGlzIG5vIE9TQ09SRSBvcHRpb24gaW4gdGhlIG91dGVyIHdyYXBwZXIsIHRoZW4g dGhlcmUgaXMgbm8gaW5uZXIgZGF0YS4gDQoNCkFsc28sIHdlIGRvIGFscmVhZHkgaGF2ZTogDQoN CiAgIElmIHRoZSBuZXcgb3B0aW9ucyBhcmUgbm90IHN1cHBvcnRlZCBieSBhIHBlZXIsIHRoZW4N CiAgIHRyYW5zbWlzc2lvbnMgY2FuIGZhbGwgYmFjayB0byB1c2luZyBCbG9jazEgYW5kIEJsb2Nr MiBPcHRpb25zDQoNClRoYXQncyBzYWlkIHdlIGNhbiBiZSBtb3JlIGV4cGxpY2l0Lg0KDQo+IA0K PiBTZWN0aW9uIDQuMw0KPiANCj4gICAgYmVpbmcgdHJhbnNmZXJyZWQuICBUaGUgUmVxdWVzdC1U YWcgaXMgb3BhcXVlLCB0aGUgc2VydmVyIHN0aWxsDQo+ICAgIHRyZWF0cyBpdCBhcyBvcGFxdWUg YnV0IHRoZSBjbGllbnQgTVVTVCBlbnN1cmUgdGhhdCBpdCBpcyB1bmlxdWUNCj4gZm9yDQo+ICAg IGV2ZXJ5IGRpZmZlcmVudCBib2R5IG9mIHRyYW5zbWl0dGVkIGRhdGEuDQo+IA0KPiAobml0KSB0 aGUgc3RydWN0dXJlIG9mIHRoaXMgc2VudGVuY2Ugc2VlbXMgb2ZmLCB0byBtZS4gIEkgbWF5IGp1 c3QNCj4gd2FudCBhIGNvbW1hIGFmdGVyICJzZXJ2ZXIgc3RpbGwgdHJlYXRzIGl0IGFzIG9wYXF1 ZSIsIGJ1dCBsb29raW5nDQo+IG1vcmUgY2xvc2VseSBJIG1pZ2h0IHJld3JpdGUgdG8gbW9yZSBs aWtlICJUaGUgUmVxdWVzdC1UYWcgaXMgb3BhcXVlDQo+IHRvIHRoZSBzZXJ2ZXIsIGJ1dCB0aGUg Y2xpZW50IE1VU1QgZW5zdXJlIHRoYXQgaXQgaXMgdW5pcXVlIGZvciBldmVyeQ0KPiBkaWZmZXJl bnQgcmVxdWVzdCBib2R5IGJlaW5nIHRyYW5zbWl0dGVkIi4NCj4gDQoNCk9LDQoNCj4gICAgICAg SW1wbGVtZW50YXRpb24gTm90ZTogSXQgaXMgc3VnZ2VzdGVkIHRoYXQgdGhlIGNsaWVudCB0cmVh dHMgdGhlDQo+ICAgICAgIFJlcXVlc3QtVGFnIGFzIGFuIHVuc2lnbmVkIGludGVnZXIgb2YgOCBi eXRlcyBpbiBsZW5ndGguICBBbg0KPiAgICAgICBpbXBsZW1lbnRhdGlvbiBtYXkgd2FudCB0byBj b25zaWRlciBsaW1pdGluZyB0aGlzIHRvIDQgYnl0ZXMgdG8NCj4gICAgICAgcmVkdWNlIHBhY2tl dCBvdmVyaGVhZCBzaXplLiAgVGhlIGluaXRpYWwgUmVxdWVzdC1UYWcgdmFsdWUNCj4gc2hvdWxk DQo+ICAgICAgIGJlIHJhbmRvbWx5IGdlbmVyYXRlZCBhbmQgdGhlbiBzdWJzZXF1ZW50bHkgaW5j cmVtZW50ZWQgYnkgdGhlDQo+ICAgICAgIGNsaWVudCB3aGVuZXZlciBhIG5ldyBib2R5IG9mIGRh dGEgaXMgYmVpbmcgdHJhbnNtaXR0ZWQgYmV0d2Vlbg0KPiAgICAgICBwZWVycy4NCj4gDQo+IElu IHRoZSB2ZWluIG9mIGRyYWZ0LWdvbnQtbnVtZXJpYy1pZHMtc2VjLWNvbnNpZGVyYXRpb25zLCBp cyB0aGUNCj4gaW5jcmVtZW50IG5lY2Vzc2FyaWx5IDEgb3IgY2FuIHRoZXJlIGJlIGdhcHM/ICBT aW1pbGFybHksIHRoZSByaXNrIG9mDQo+IGluZm9ybWF0aW9uIGRpc2Nsb3N1cmUgKHZpYSBzaWRl IGNoYW5uZWwpIGlzIHJlZHVjZWQgaWYgdGhlIGluaXRpYWwNCj4gcmFuZG9tIHZhbHVlIGlzIGdl bmVyYXRlZCBhbmV3IGZvciBlYWNoIGNvbm5lY3Rpb24uICBUaGlzIGlzIG1heWJlDQo+IGltcGxp ZWQgYnkgdGhlIGN1cnJlbnQgdGV4dCBidXQgY291bGQgYmUgc3RhdGVkIG1vcmUgY2xlYXJseS4N Cg0KV2UgZG9uJ3Qgc2F5ICJtb25vdG9uaWNhbGx5IGluY3JlbWVudGVkIiBvciBzcGVjaWZ5IGFu IGluY3JlbWVudCB1bml0LiBTbywgeWVzIHRoZXJlIGNhbiBiZSByYW5kb20gZ2FwcyBhc3N1bWlu ZyB0aGUgcmVzdWx0YW50IHZhbHVlcyBtdXN0IG5vdCBjbGFzaCB0aG91Z2guDQoNCk5vdGUgdGhh dCB0aGUgaW5pdGlhbCB2YWx1ZSBpcyByYW5kb21seSBnZW5lcmF0ZWQ6DQogDQogICAgICByZWR1 Y2UgcGFja2V0IG92ZXJoZWFkIHNpemUuICBUaGUgaW5pdGlhbCBSZXF1ZXN0LVRhZyB2YWx1ZSBz aG91bGQNCiAgICAgIGJlIHJhbmRvbWx5IGdlbmVyYXRlZCBhbmQgdGhlbiBzdWJzZXF1ZW50bHkg aW5jcmVtZW50ZWQgYnkgdGhlDQogICAgICAgICBeXl5eXl5eXiANCiAgICAgIGNsaWVudCB3aGVu ZXZlciBhIG5ldyBib2R5IG9mIGRhdGEgaXMgYmVpbmcgdHJhbnNtaXR0ZWQgYmV0d2Vlbg0KICAg ICAgcGVlcnMuDQoNCj4gDQo+ICAgIFRoZSBjbGllbnQgTVVTVCBzZW5kIHRoZSBwYXlsb2FkcyB3 aXRoIHRoZSBibG9jayBudW1iZXJzDQo+IGluY3JlYXNpbmcsDQo+ICAgIHN0YXJ0aW5nIGZyb20g emVybywgdW50aWwgdGhlIGJvZHkgaXMgY29tcGxldGUgKHN1YmplY3QgdG8gYW55DQo+ICAgIGNv bmdlc3Rpb24gY29udHJvbCAoU2VjdGlvbiA3KSkuICBBbnkgbWlzc2luZyBwYXlsb2FkcyByZXF1 ZXN0ZWQNCj4gYnkNCj4gICAgdGhlIHNlcnZlciBtdXN0IGluIGFkZGl0aW9uIGJlIHNlcGFyYXRl bHkgdHJhbnNtaXR0ZWQgd2l0aA0KPiBpbmNyZWFzaW5nDQo+ICAgIGJsb2NrIG51bWJlcnMuDQo+ IA0KPiBXaGVuIEkgZmlyc3QgcmVhZCB0aGlzLCBJIHRob3VnaHQgdGhhdCB0aGUgYmxvY2sgbnVt YmVycyBvZg0KPiByZXRyYW5zbWlzc2lvbnMgbmVlZGVkIHRvIGNvbnRpbnVlIHRvIGluY3JlYXNl IGluIHRoZSBzYW1lIHNlcXVlbmNlDQo+IGFzIHRoZSBvcmlnaW5hbCB0cmFuc21pc3Npb24sIGku ZS4sIHJldHJhbnNtaXR0ZWQgYmxvY2tzIGFyZSBhc3NpZ25lZA0KPiBuZXcgYmxvY2sgbnVtYmVy cy4gIFRoZSBleGFtcGxlcyBkbyBub3QgYmVhciB0aGlzIG91dCAoYW5kIGl0IHNlZW1zDQo+IGxp a2UgaXQgd291bGQgYmUgY29tcGxpY2F0ZWQgdG8gc3BlY2lmeSBjbGVhcmx5KSwgc28gSSBzdWdn ZXN0DQo+IHJlcGhyYXNpbmcgdG8gImluIG9yZGVyIG9mIGluY3JlYXNpbmcgYmxvY2sgbnVtYmVy Ii4NCg0KQUNLLg0KDQo+IA0KPiAgICAgICBJZiB0aGUgRkVUQ0ggcmVxdWVzdCBpbmNsdWRlcyB0 aGUgT2JzZXJ2ZSBPcHRpb24sIHRoZW4gdGhlDQo+IHNlcnZlcg0KPiAgICAgICBNVVNUIHVzZSB0 aGUgc2FtZSB0b2tlbiBhcyB1c2VkIGZvciB0aGUgaW5pdGlhbCByZXNwb25zZSBmb3INCj4gICAg ICAgcmV0dXJuaW5nIGFueSBPYnNlcnZlIHRyaWdnZXJlZCByZXNwb25zZXMgc28gdGhhdCB0aGUg Y2xpZW50DQo+IGNhbg0KPiAgICAgICBtYXRjaCB0aGVtIHVwLg0KPiANCj4gICAgICAgVGhlIGNs aWVudCBzaG91bGQgdGhlbiByZWxlYXNlIGFsbCBvZiB0aGUgdG9rZW5zIHVzZWQgZm9yIHRoaXMN Cj4gICAgICAgYm9keSB1bmxlc3MgYSByZXNvdXJjZSBpcyBiZWluZyBvYnNlcnZlZC4NCj4gDQo+ IElmIGEgcmVzb3VyY2UgaXMgYmVpbmcgb2JzZXJ2ZWQsIHNob3VsZCB0aGUgY2xpZW50IHJlbGVh c2UgYWxsIHRoZQ0KPiBvdGhlciB0b2tlbnMgKHRoYW4gdGhlIG9uZSB1c2VkIGZvciB0aGUgaW5p dGlhbCByZXNwb25zZSk/DQoNClRoZXJlIGlzIG5vIHJlYXNvbiB3aHkgdGhlIGNsaWVudCBjYW5u b3QgcmVsZWFzZSBhbGwgdGhlIG90aGVyIHRva2Vucy4NCg0KPiANCj4gQWxzbywgaXMgdGhlICJp bml0aWFsIHJlc3BvbnNlIiB0aGUgZmlyc3QgcmVzcG9uc2UgZm9yIHRoZSBibG9ja3dpc2UNCj4g dHJhbnNmZXIgKHdoaWNoIG1pZ2h0IGJlIGEgMi4zMSBvciA0LjA4IGZvciBOT04gcmVxdWVzdHMp LCBvciB0aGUNCj4gZmlyc3Qgb25lIHdpdGggcmVzcG9uc2UgY29kZSAyLjA1Pw0KDQpUaGUgImlu aXRpYWwgYWxsIGRhdGEgcmVjZWl2ZWQgcmVzcG9uc2UiIC0gaS5lLiAyLjAxIG9yIDIuMDUuDQoN Cj4gDQo+ICAgIDIuMzEgKENvbnRpbnVlKQ0KPiANCj4gICAgICAgVGhpcyBSZXNwb25zZSBDb2Rl IGNhbiBiZSB1c2VkIHRvIGluZGljYXRlIHRoYXQgYWxsIG9mIHRoZQ0KPiBibG9ja3MNCj4gICAg ICAgdXAgdG8gYW5kIGluY2x1ZGluZyB0aGUgUS1CbG9jazEgT3B0aW9uIGJsb2NrIE5VTSAoYWxs IGhhdmluZw0KPiB0aGUNCj4gICAgICAgTSBiaXQgc2V0KSBoYXZlIGJlZW4gc3VjY2Vzc2Z1bGx5 IHJlY2VpdmVkLiAgVGhlIHRva2VuIHVzZWQNCj4gTVVTVA0KPiAgICAgICBiZSBvbmUgb2YgdGhl IHRva2VucyB0aGF0IHdlcmUgcmVjZWl2ZWQgaW4gYSByZXF1ZXN0IGZvciB0aGlzDQo+ICAgICAg IGJsb2NrLXdpc2UgZXhjaGFuZ2UuICBIb3dldmVyLCBpdCBpcyBkZXNpcmFibGUgdG8gcHJvdmlk ZSB0aGUNCj4gb25lDQo+ICAgICAgIHVzZWQgaW4gdGhlIGxhc3QgcmVjZWl2ZWQgcmVxdWVzdC4N Cj4gDQo+IENhbiB0aGUgY2xpZW50IHJlbGVhc2UgYW55IHRva2VucyB1cG9uIHJlY2VpcHQgb2Yg c3VjaCBhIHJlc3BvbnNlPw0KDQpZZXMuICBJZiBnb2luZyB3aXRoIHRoZSBJbXBsZW1lbnRhdGlv biBOb3RlICM2LiwgdGhlIGxvd2VyIDMyIGJpdHMgdHJhY2tlciBtdXN0IG5vdCBiZSByZWxlYXNl ZC4NCg0KPiANCj4gICAgNC4wMiAoQmFkIE9wdGlvbikNCj4gDQo+ICAgICAgIFRoaXMgUmVzcG9u c2UgQ29kZSBNVVNUIGJlIHJldHVybmVkIGZvciBhIENvbmZpcm1hYmxlIHJlcXVlc3QNCj4gaWYN Cj4gICAgICAgdGhlIHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IHRoZSBRLUJsb2NrIE9wdGlvbnMu ICBOb3RlIHRoYXQgYQ0KPiAgICAgICByZXNldCBtZXNzYWdlIG11c3QgYmUgc2VudCBpbiBjYXNl IG9mIE5vbi1jb25maXJtYWJsZSByZXF1ZXN0Lg0KPiANCj4gUmVzZXQgb25seSBuZWVkcyB0byBi ZSBzZW50IGlmIHRoZSBzZXJ2ZXIgaXMgbm90IGlnbm9yaW5nIHRoZSByZXF1ZXN0DQo+IGVudGly ZWx5LCB0aG91Z2gsIHJpZ2h0Pw0KDQpUaGUgcmVxdWVzdCB3aWxsIGJlIHJlamVjdGVkLiBQbGVh c2Ugc2VlOiANCg0KICAgQSBOb24tY29uZmlybWFibGUNCiAgIG1lc3NhZ2Ugd2l0aCBhbiB1bnJl Y29nbml6ZWQgY3JpdGljYWwgb3B0aW9uIGlzIGVpdGhlciByZWplY3RlZCB3aXRoDQogICBhIFJl c2V0IG1lc3NhZ2Ugb3IganVzdCBzaWxlbnRseSBpZ25vcmVkIChTZWN0aW9ucyA1LjQuMSBhbmQg NC4zIG9mDQogICBbUkZDNzI1Ml0pLg0KDQpIZW5jZSB0aGUgUS1CbG9jayBhdmFpbGFiaWxpdHkg Y2hlY2sgbXVzdCBiZSBhIENPTi4NCg0KPiANCj4gDQo+ICUlJQ0KPiBUaGUgZm9sbG93aW5nIGZl dyBjb21tZW50cyBhcmUgaW50ZXJyZWxhdGVkOg0KPiANCj4gICAgICAgVGhpcyBSZXNwb25zZSBD b2RlIHJldHVybmVkIHdpdGggQ29udGVudC1UeXBlICJhcHBsaWNhdGlvbi8NCj4gICAgICAgbWlz c2luZy1ibG9ja3MrY2Jvci1zZXEiIGluZGljYXRlcyB0aGF0IHNvbWUgb2YgdGhlIHBheWxvYWRz DQo+IGFyZQ0KPiAgICAgICBtaXNzaW5nIGFuZCBuZWVkIHRvIGJlIHJlc2VudC4gIFRoZSBjbGll bnQgdGhlbiByZXRyYW5zbWl0cyB0aGUNCj4gICAgICAgbWlzc2luZyBwYXlsb2FkcyB1c2luZyB0 aGUgc2FtZSBSZXF1ZXN0LVRhZywgU2l6ZTEgYW5kIFEtQmxvY2sxDQo+IHRvDQo+ICAgICAgIHNw ZWNpZnkgdGhlIGJsb2NrIE5VTSwgU1pYLCBhbmQgTSBiaXQgYXMgYXBwcm9wcmlhdGUuDQo+IA0K PiBUaGUgbmV3ICdNJyBiaXQgaXMgImFzIGFwcHJvcHJpYXRlIiBmb3IgdGhlIG5ldyBmbGlnaHQg b2YgbWVzc2FnZXMsDQo+IG9yIGFzIHdhcyBzZW50IGluaXRpYWxseT8gIChUaGUgZXhhbXBsZXMg aW4gwqcxMC54IHN1Z2dlc3QgImFzIHdhcw0KPiBzZW50DQo+IGluaXRpYWxseSIuKQ0KPiANCj4g ICAgICAgVGhlIFJlcXVlc3QtVGFnIHZhbHVlIHRvIHVzZSBpcyBkZXRlcm1pbmVkIGJ5IHRha2lu ZyB0aGUgdG9rZW4NCj4gaW4NCj4gICAgICAgdGhlIDQuMDggKFJlcXVlc3QgRW50aXR5IEluY29t cGxldGUpIHJlc3BvbnNlLCBsb2NhdGluZyB0aGUNCj4gICAgICAgbWF0Y2hpbmcgY2xpZW50IHJl cXVlc3QsIGFuZCB0aGVuIHVzaW5nIGl0cyBSZXF1ZXN0LVRhZy4NCj4gDQo+IFRoZSAidmFsdWUg dG8gdXNlIiBoZXJlIHNlZW1zIHRvIGJlIGluZGljYXRpbmcgdGhlIHZhbHVlIHRvIHVzZSBpbg0K PiB0aGUgcmV0cmFuc21pdHRlZCByZXF1ZXN0Li4uDQoNClllcy4gDQoNCj4gDQo+ICAgICAgIFRo ZSB0b2tlbiB1c2VkIE1VU1QgYmUgb25lIG9mIHRoZSB0b2tlbnMgdGhhdCB3ZXJlIHJlY2VpdmVk IGluDQo+IGENCj4gICAgICAgcmVxdWVzdCBmb3IgdGhpcyBibG9jay13aXNlIGV4Y2hhbmdlLiAg SG93ZXZlciwgaXQgaXMgZGVzaXJhYmxlDQo+IHRvDQo+ICAgICAgIHByb3ZpZGUgdGhlIG9uZSB1 c2VkIGluIHRoZSBsYXN0IHJlY2VpdmVkIHJlcXVlc3QuICBTZWUgU2VjdGlvbg0KPiA1DQo+ICAg ICAgIGZvciBmdXJ0aGVyIGluZm9ybWF0aW9uLg0KPiANCj4gLi4uIGJ1dCBoZXJlIHRoZSAidG9r ZW4gdXNlZCIgc2VlbXMgdG8gYmUgaW5kaWNhdGluZyB0aGUgdG9rZW4gdG8gYmUNCj4gdXNlZCBp biBjb25zdHJ1Y3RpbmcgdGhlIHJlc3BvbnNlIHRoYXQgaGFzIHJlc3BvbnNlIGNvZGUgNC4wOC4N Cg0KVGhpcyBpcyB0byB0b2tlbiB0byBiZSB1c2VkIHRvIHNlbmQgdGhlIHJlc3BvbnNlIGNvZGU6 IHMvdG9rZW4gdXNlci90b2tlbiB0byB1c2UNCg0KPiANCj4gSWYgbXkgdW5kZXJzdGFuZGluZyBp cyBjb3JyZWN0LCB3ZSByZWFsbHkgc2hvdWxkIGhhdmUgbW9yZSBjbGFyaXR5IG9uDQo+IHdoaWNo IHZhbHVlIGlzICJ1c2VkIiBmb3Igd2hpY2ggbWVzc2FnZS4NCj4gDQo+IEFkZGl0aW9uYWxseSwg aW4gdGhlIGxhc3QgcXVvdGVkIHBhcmFncmFwaCB3ZSByZWZlciB0byBTZWN0aW9uIDUgZm9yDQo+ IGZ1cnRoZXIgaW5mb3JtYXRpb24sIHdoaWNoIGluY2x1ZGVzIGEgU0hPVUxELWxldmVsIHJlcXVp cmVtZW50IHRvDQo+ICJwcm92aWRlIHRoZSBbdG9rZW5dIHVzZWQgaW4gdGhlIGxhc3QgcmVjZWl2 ZWQgcmVxdWVzdCIuICBJdCBpcyB2ZXJ5DQo+IHN1cnByaXNpbmcgdG8gaGF2ZSB0aGUgbm9ybWF0 aXZlIHJlcXVpcmVtZW50cyBmb3IgYmVoYXZpb3Igc3BsaXQNCj4gYWNyb3NzIHNlY3Rpb25zIGlu IHRoaXMgbWFubmVyLiAgKE9yIHdhcyB0aGUgaW50ZW50IHRoYXQgU2VjdGlvbiA1DQo+IGFsc28g dXNlIHRoZSAiZGVzaXJhYmxlIiB3b3JkaW5nPykgJSUlDQoNCiJkZXNpcmFibGUiIGlzIG1vcmUg YXBwcm9wcmlhdGUuIEZpeGVkLiANCg0KPiANCj4gU2VjdGlvbiA0LjQNCj4gDQo+ICAgIFRoZSBF VGFnIGlzIG9wYXF1ZSwgdGhlIGNsaWVudCBzdGlsbCB0cmVhdHMgaXQgYXMgb3BhcXVlIGJ1dCB0 aGUNCj4gICAgc2VydmVyIE1VU1QgZW5zdXJlIHRoYXQgaXQgaXMgdW5pcXVlIGZvciBldmVyeSBk aWZmZXJlbnQgYm9keSBvZg0KPiAgICB0cmFuc21pdHRlZCBkYXRhLg0KPiANCj4gW2FuYWxvZ291 cyBjb21tZW50IGFzIGZvciBSZXF1ZXN0LVRhZ10NCg0KT0sNCg0KPiANCj4gICAgICAgSW1wbGVt ZW50YXRpb24gTm90ZTogSXQgaXMgc3VnZ2VzdGVkIHRoYXQgdGhlIHNlcnZlciB0cmVhdHMgdGhl DQo+ICAgICAgIEVUYWcgYXMgYW4gdW5zaWduZWQgaW50ZWdlciBvZiA4IGJ5dGVzIGluIGxlbmd0 aC4gIEFuDQo+ICAgICAgIGltcGxlbWVudGF0aW9uIG1heSB3YW50IHRvIGNvbnNpZGVyIGxpbWl0 aW5nIHRoaXMgdG8gNCBieXRlcyB0bw0KPiAgICAgICByZWR1Y2UgcGFja2V0IG92ZXJoZWFkIHNp emUuICBUaGUgaW5pdGlhbCBFVGFnIHZhbHVlIHNob3VsZCBiZQ0KPiAgICAgICByYW5kb21seSBn ZW5lcmF0ZWQgYW5kIHRoZW4gc3Vic2VxdWVudGx5IGluY3JlbWVudGVkIGJ5IHRoZQ0KPiBzZXJ2 ZXINCj4gICAgICAgd2hlbmV2ZXIgYSBuZXcgYm9keSBvZiBkYXRhIGlzIGJlaW5nIHRyYW5zbWl0 dGVkIGJldHdlZW4gcGVlcnMuDQo+IA0KPiBbYW5hbG9nb3VzIGNvbW1lbnQgYXMgZm9yIFJlcXVl c3QtVGFnXQ0KDQpOb3RlZC4gDQoNCj4gDQo+ICAgIFRoZSBjbGllbnQgU0hPVUxEIHdhaXQgZm9y IHVwIHRvIE5PTl9SRUNFSVZFX1RJTUVPVVQgKFNlY3Rpb24gNy4yKQ0KPiAgICBhZnRlciB0aGUg bGFzdCByZWNlaXZlZCBwYXlsb2FkIGZvciBOT04gcGF5bG9hZHMgYmVmb3JlIGlzc3VpbmcgYQ0K PiAgICBHRVQsIFBPU1QsIFBVVCwgRkVUQ0gsIFBBVENILCBvciBpUEFUQ0ggcmVxdWVzdCB0aGF0 IGNvbnRhaW5zIG9uZQ0KPiBvcg0KPiAgICBtb3JlIFEtQmxvY2syIE9wdGlvbnMgdGhhdCBkZWZp bmUgdGhlIG1pc3NpbmcgYmxvY2tzIHdpdGggdGhlIE0NCj4gYml0DQo+ICAgIHVuc2V0LiAgVGhl IGNsaWVudCBNQVkgc2V0IHRoZSBNIGJpdCB0byByZXF1ZXN0IHRoaXMgYW5kIGxhdGVyDQo+IGJs b2Nrcw0KPiAgICBmcm9tIHRoaXMgTUFYX1BBWUxPQURTIHNldC4gIEZ1cnRoZXIgY29uc2lkZXJh dGlvbnMgcmVsYXRlZCB0byB0aGUNCj4gICAgdHJhbnNtaXNzaW9uIHRpbWluZyBmb3IgbWlzc2lu ZyByZXF1ZXN0cyBhcmUgZGlzY3Vzc2VkIGluDQo+ICAgIFNlY3Rpb24gNy4yLg0KPiANCj4gRG9l cyB0aGUgTUFZIGdyYW50IHBlcm1pc3Npb24gdG8gc2VuZCB3aXRoIE0gYml0IHNldCBwcmlvciB0 bw0KPiBOT05fUkVDRUlWRV9USU1FT1VULCBvciBqdXN0IHBlcm1pc3Npb24gdG8gc2VuZCB3aXRo IE0gYml0IHNldCBpbg0KPiBhZGRpdGlvbiB0byB3aXRoIE0gYml0IHVuc2V0IChidXQgc3RpbGwg YWZ0ZXIgdGhlIHRpbWVvdXQpPw0KDQpJZiB0aGUgbWlzc2luZyBibG9ja3MgYXJlIGEgY29tcGxl dGUgc2V0IGZyb20gbGFzdCByZWNlaXZlZCBibG9jaywgdGhlbiB0aGUgTUFZIGFsbG93cyB0aGUg TSBiaXQgdG8gYmUgc2V0IGluZGljYXRpbmcgJ3RoZSByZXN0JyBhcyBvcHBvc2VkIGZvciBkZWZp bmluZyBlYWNoIG9uZSB0aGF0IGlzIG1pc3NpbmcgaW4gdGhlIHJlcXVlc3QuICBJdCB3YXMgbm90 IGludGVuZGVkIGFzIGJlaW5nIGFuIGFsdGVybmF0aXZlIHRvICJUaGUgY2xpZW50IFNIT1VMRCB3 YWl0Ii4NCg0KPiANCj4gICAgRm9yIENvbmZpcm1hYmxlIHJlc3BvbnNlcywgdGhlIGNsaWVudCBj b250aW51ZXMgdG8gYWNrbm93bGVkZ2UNCj4gZWFjaA0KPiAgICBwYWNrZXQuICBUeXBpY2FsbHks IHRoZSBzZXJ2ZXIgYWNrbm93bGVkZ2VzIHRoZSBpbml0aWFsIHJlcXVlc3QNCj4gdXNpbmcNCj4g ICAgYW4gQUNLIHdpdGggdGhlIHBheWxvYWQsIGFuZCB0aGVuIHNlbmRzIHRoZSBzdWJzZXF1ZW50 IHBheWxvYWRzIGFzDQo+ICAgIENPTiByZXNwb25zZXMuICBUaGUgc2VydmVyIHdpbGwgZGV0ZWN0 IGZhaWx1cmUgdG8gc2VuZCBhIHBhY2tldCwNCj4gYnV0DQo+ICAgIHRoZSBjbGllbnQgY2FuIGlz c3VlLCBhZnRlciBhIE1BWF9UUkFOU01JVF9TUEFOIGRlbGF5LCBhIHNlcGFyYXRlDQo+ICAgIEdF VCwgUE9TVCwgUFVULCBGRVRDSCwgUEFUQ0gsIG9yIGlQQVRDSCBmb3IgYW55IG1pc3NpbmcgYmxv Y2tzIGFzDQo+ICAgIG5lZWRlZC4NCj4gDQo+IFN0YXJ0aW5nIG91dCB3aXRoICJmb3IgY29uZmly bWFibGUgcmVzcG9uc2VzIiBpbXBsaWVzIHRoYXQgd2UncmUNCj4gZ29pbmcgdG8gc2VwYXJhdGVs eSBjb3ZlciBub24tY29uZmlybWFibGUgcmVzcG9uc2VzIGxhdGVyLCBvciBhdCBzb21lDQo+IHBv aW50IHRyYW5zaXRpb24gdG8gc3RhdGVtZW50cyBvZiBnZW5lcmFsIGFwcGxpY2FiaWxpdHkgKHRv IGJvdGgNCj4gY29uZmlybWFibGUgYW5kIG5vbi1jb25maXJtYWJsZSByZXNwb25zZXMpLiAgV2hl cmUgZG9lcyB0aGF0IGhhcHBlbj8NCg0KSXQgaXMgaW4gdGhpcyBzZWN0aW9uLiBUaGUgdGV4dCB5 b3UgcXVvdGVkIGlzIHdoYXQgaXMgc3BlY2lmaWMgdG8gQ09OIHJlc3BvbnNlcy4gDQoNCj4gDQo+ ICAgIEEgY2xpZW50IFNIT1VMRCBtYWludGFpbiBhIHBhcnRpYWwgYm9keSAobWlzc2luZyBwYXls b2FkcykgZm9yIHVwDQo+IHRvDQo+ICAgIE5PTl9QQVJUSUFMX1RJTUVPVVQgKFNlY3Rpb24gNy4y KSBvciBhcyBkZWZpbmVkIGJ5IHRoZSBNYXgtQWdlDQo+IE9wdGlvbg0KPiAgICAob3IgaXRzIGRl ZmF1bHQgb2YgNjAgc2Vjb25kcyAoU2VjdGlvbiA1LjYuMSBvZiBbUkZDNzI1Ml0pKSwNCj4gICAg d2hpY2hldmVyIGlzIHRoZSBsZXNzLiAgT24gcmVsZWFzZSBvZiB0aGUgcGFydGlhbCBib2R5LCB0 aGUgY2xpZW50DQo+ICAgIHNob3VsZCB0aGVuIHJlbGVhc2UgYWxsIG9mIHRoZSB0b2tlbnMgdXNl ZCBmb3IgdGhpcyBib2R5IHVubGVzcyBhDQo+ICAgIHJlc291cmNlIGlzIGJlaW5nIG9ic2VydmVk Lg0KPiANCj4gW2FzIGFib3ZlLCBjYW4gdGhlIGNsaWVudCByZWxlYXNlIGFueSBzdWJzZXQgb2Yg dG9rZW5zIGluIHRoZSBjYXNlIG9mDQo+IG9ic2VydmU/XQ0KDQpZZXMuIA0KDQo+IA0KPiAgICBJ dCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZSBzZXJ2ZXIgbWFpbnRhaW5zIGEgY2FjaGVkIGNvcHkg b2YgdGhlDQo+IGJvZHkNCj4gICAgd2hlbiB1c2luZyB0aGUgUS1CbG9jazIgT3B0aW9uIHRvIGZh Y2lsaXRhdGUgcmV0cmFuc21pc3Npb24gb2YgYW55DQo+ICAgIG1pc3NpbmcgcGF5bG9hZHMuDQo+ IA0KPiBJdCdzIHN1cnByaXNpbmcgdG8gd3JpdGUgdGhhdCB0aGUgY2xpZW50IFNIT1VMRCBidXQg aXQgaXMgUkVDT01NRU5ERUQNCj4gdGhhdCB0aGUgc2VydmVyIGNhY2hlLCB3aGVuIHRob3NlIHR3 byByZXF1aXJlbWVudHMga2V5d29yZHMgaGF2ZSBhbg0KPiBlcXVpdmFsZW50IHN0cmVuZ3RoIHBl ciBCQ1AgMTQuICBDYW4ndCB3ZSB1c2VkIGNvbnNpc3RlbnQgdGVybWlub2xvZ3kNCj4gZm9yIHRo ZSBzYW1lIHJlcXVpcmVtZW50IGxldmVsPw0KDQpTdXJlLiAgDQoNCj4gDQo+ICAgIElmIHRoZSBz ZXJ2ZXIgZGV0ZWN0cyBwYXJ0IHdheSB0aHJvdWdoIGEgYm9keSB0cmFuc2ZlciB0aGF0IHRoZQ0K PiAgICByZXNvdXJjZSBkYXRhIGhhcyBjaGFuZ2VkIGFuZCB0aGUgc2VydmVyIGlzIG5vdCBtYWlu dGFpbmluZyBhDQo+IGNhY2hlZA0KPiAgICBjb3B5IG9mIHRoZSBvbGQgZGF0YSwgdGhlbiB0aGUg dHJhbnNtaXNzaW9uIGlzIHRlcm1pbmF0ZWQuICBBbnkNCj4gICAgc3Vic2VxdWVudCBtaXNzaW5n IGJsb2NrIHJlcXVlc3RzIE1VU1QgYmUgcmVzcG9uZGVkIHRvIHVzaW5nIHRoZQ0KPiAgICBsYXRl c3QgRVRhZyBhbmQgU2l6ZTIgT3B0aW9uIHZhbHVlcyB3aXRoIHRoZSB1cGRhdGVkIGRhdGEuDQo+ IA0KPiBUaGlzIHNvdW5kcyBsaWtlIHRoZSBzZXJ2ZXIgc3RhcnRzIHJlc3BvbmRpbmcgImluIHRo ZSBtaWRkbGUiIG9mIHRoZQ0KPiBuZXcgcmVwcmVzZW50YXRpb24sIHNvIHRoZSBjbGllbnQgd291 bGQgbmVlZCB0byBnbyBiYWNrIGFuZCByZS0NCj4gcmVxdWVzdCB0aGUgaW5pdGlhbCBwYXJ0cywg cG9zc2libHkgYWNyb3NzIG11bHRpcGxlIGdyb3VwcyBvZg0KPiBNQVhfUEFZTE9BRFMgYmxvY2tz Lg0KDQpUaGlzIGlzIG9ubHkgbmVlZGVkIGlmIHRoZSBzZXJ2ZXIgZG9lcyBub3QgY2FjaGUgYSBy ZXNwb25zZSBhbmQgdGhlIHJlc291cmNlIGNoYW5nZXMgbWlkLWZsaWdodC4gVGhlIEV0YWcgKyBw b3NzaWJsZSBTSVpFMiBjaGFuZ2UgaW5kaWNhdGUgdGhlIHJlc291cmNlIGhhcyBoYW5nZWQgYW5k IG5lZWRzIHRvIGJlIHJlLXJlcXVlc3RlZCBmcm9tIHRoZSBzdGFydCAoYmxvY2sgMCkuDQoNCj4g SXQgc2VlbXMgbGlrZSB0aGlzIHJlcXVpcmVtZW50IGZvciBjbGllbnQgYmVoYXZpb3Igc2hvdWxk IGJlIG1vcmUNCj4gY2xlYXJseSBkb2N1bWVudGVkIHNvbWV3aGVyZS4gIFdlIGRvIGdvIG9uIHRv IHRhbGsgYWJvdXQgdGhlIGNsaWVudA0KPiByZW1vdmluZyB0aGUgc3RhbGUgcGFydGlhbCBib2R5 LCBidXQgbm90IGFib3V0IGNvbXBsZXRpbmcgdGhlIG5ldw0KPiBib2R5Lg0KPiANCj4gU2VjdGlv biA0LjUNCj4gDQo+ICAgIEZvciBhIHJlc3BvbnNlIHRoYXQgdXNlcyBRLUJsb2NrMiwgdGhlIE9i c2VydmUgdmFsdWUgTVVTVCBiZSB0aGUNCj4gc2FtZQ0KPiAgICBmb3IgYWxsIHRoZSBwYXlsb2Fk cyBvZiB0aGUgc2FtZSBib2R5LiAgVGhpcyBpcyBkaWZmZXJlbnQgZnJvbQ0KPiBCbG9jazINCj4g ICAgdXNhZ2Ugd2hlcmUgdGhlIE9ic2VydmUgdmFsdWUgaXMgb25seSBwcmVzZW50IGluIHRoZSBm aXJzdCBibG9jaw0KPiAgICAoU2VjdGlvbiAzLjQgb2YgW1JGQzc5NTldKS4gIFRoaXMgaW5jbHVk ZXMgcGF5bG9hZHMgdHJhbnNtaXR0ZWQNCj4gICAgZm9sbG93aW5nIHJlY2VpcHQgb2YgdGhlICdD b250aW51ZScgUS1CbG9jazIgT3B0aW9uIChTZWN0aW9uIDQuNCkNCj4gYnkNCj4gICAgdGhlIHNl cnZlci4gIElmIGEgbWlzc2luZyBwYXlsb2FkIGlzIHJlcXVlc3RlZCBieSBhIGNsaWVudCwgdGhl bg0KPiBib3RoDQo+ICAgIHRoZSByZXF1ZXN0IGFuZCByZXNwb25zZSBNVVNUIE5PVCBpbmNsdWRl IHRoZSBPYnNlcnZlIE9wdGlvbi4NCj4gDQo+IChzaWRlIG5vdGU/KSBJdCBzZWVtcyB2ZXJ5IHN1 cnByaXNpbmcgdG8gb21pdCBPYnNlcnZlIGZyb20gb25seQ0KPiByZXRyYW5zbWl0dGVkIHBheWxv YWRzIGJ1dCBrZWVwIGl0IGluIGFsbCBpbml0aWFsIHBheWxvYWQNCj4gdHJhbnNtaXNzaW9ucy4N Cg0KVGhpcyBpcyBkaWZmZXJlbnQgZnJvbSBCbG9jazIgaW4gdGhlIChmaXJzdCBhbmQgb2JzZXJ2 ZSB0cmlnZ2VyZWQgYWRkaXRpb25hbCkgcmVzcG9uc2UgaXMgdGhhdCBibG9jayMwIChhbmQgb3Ro ZXIgYmxvY2tzKSBtYXkgbm90IGFycml2ZSwgc28gdGhlIE9ic2VydmUgT3B0aW9uIHZhbHVlIG5l ZWRzIHRvIGJlIGluIGFsbCB0aGUgcGFja2V0cyAoaW5jbHVkaW5nIGEgc3Vic2VxdWVudCBNQVhf UEFZTE9BRFMgY2h1bmsgYXMgdGhlIGZpcnN0IE1BWF9QQVlMT0FEUyBzZXQgbWF5IG5vdCBoYXZl IGFycml2ZWQpLiAgT25jZSB0aGUgY2xpZW50IGhhcyBhdCBsZWFzdCBvbmUgcGFja2V0IHdpdGgg T2JzZXJ2ZSwgdGhlbiB0aGUgcmVxdWVzdGluZyBvZiBtaXNzaW5nIHBhY2tldHMgZG9lcyBub3Qg bmVlZCB0aGUgT2JzZXJ2ZSkgYXMgQmxvY2syIGRvZXMgbm90IG5lZWQgaXQgd2hlbiBhc2tpbmcg Zm9yIHRoZSBuZXh0IHBhY2tldC4NCg0KPiANCj4gU2VjdGlvbiA0LjYNCj4gDQo+ICAgIFRoZSBT aXplMSBvciBTaXplMiBvcHRpb24gdmFsdWVzIE1VU1QgZXhhY3RseSByZXByZXNlbnQgdGhlIHNp emUNCj4gb2YNCj4gICAgdGhlIGRhdGEgb24gdGhlIGJvZHkgc28gdGhhdCBhbnkgbWlzc2luZyBk YXRhIGNhbiBlYXNpbHkgYmUNCj4gICAgZGV0ZXJtaW5lZC4NCj4gDQo+IElzIHRoaXMgTVVTVCBk dXBsaWNhdGluZyB0aGUgYmVoYXZpb3IgYWxyZWFkeSBzcGVjaWZpZWQgYnkgUkZDIDc5NTk/DQoN Ck5vLCA3OTU5IGRpc2N1c3NlcyAic2l6ZSBlc3RpbWF0ZXMiIG9yICJzaXplIGluZGljYXRpb24i LiANCg0KPiANCj4gU2VjdGlvbiA1DQo+IA0KPiAgICBUaGUgZGF0YSBwYXlsb2FkIG9mIHRoZSA0 LjA4IChSZXF1ZXN0IEVudGl0eSBJbmNvbXBsZXRlKSByZXNwb25zZQ0KPiBpcw0KPiAgICBlbmNv ZGVkIGFzIGEgQ0JPUiBTZXF1ZW5jZSBbUkZDODc0Ml0uICBJdCBjb21wcmlzZXMgb2Ygb25lIG9y IG1vcmUNCj4gDQo+IEkgdGhpbmsgd2Ugd2FudCBzb21lIHF1YWxpZnlpbmcgdGV4dCB0aGF0IHJl YWZmaXJtcyB0aGF0IHRoZSBiZWhhdmlvcg0KPiBiZWluZyBkZXNjcmliZWQgaXMgYXBwbGljYWJs ZSBvbmx5IHRvIHRoZSBhcHBsaWNhdGlvbi9taXNzaW5nLQ0KPiBibG9ja3MrY2Jvci1zZXEgY29u dGVudC10eXBlIGNhc2UsIHBvc3NpYmx5IGJ5IGhhdmluZyB0aGUgcHJldmlvdXMNCj4gZGlzY3Vz c2lvbiBzdGF0ZSB0aGF0ICJ0aGlzIHNlY3Rpb24gZGVmaW5lcyB0aGUgYmVoYXZpb3IgYW5kDQo+ IHNlbWFudGljcyBmb3IgNC4wOCByZXNwb25zZXMgdXNpbmcgdGhlIG5ldyBjb250ZW50LXR5cGUu Ig0KDQpXaHkgaXMgdGhpcyBuZWVkZWQ/DQoNCj4gDQo+ICAgIFRoZSBDb25jaXNlIERhdGEgRGVm aW5pdGlvbiBMYW5ndWFnZSBbUkZDODYxMF0gKGFuZCBzZWUgU2VjdGlvbg0KPiA0LjENCj4gICAg W1JGQzg3NDJdKSBmb3IgdGhlIGRhdGEgZGVzY3JpYmluZyB0aGVzZSBtaXNzaW5nIGJsb2NrcyBp cyBhcw0KPiAgICBmb2xsb3dzOg0KPiANCj4gKFNob3VsZCB3ZSBtZW50aW9uIHRoYXQgdGhpcyBp cyBvbmx5IGluZm9ybWF0aW9uYWwgYW5kIHRoYXQgdGhlIHByb3NlDQo+IGRlc2NyaXB0aW9uIGlz IG5vcm1hdGl2ZSwgaW4gbGluZSB3aXRoIFJGQyA4NjEwIGJlaW5nIG9ubHkgYW4NCj4gaW5mb3Jt YXRpdmUgcmVmZXJlbmNlPykNCg0KSSdtIG5vdCBzdXJlIHRoaXMgaXMgbmVlZGVkLiBXaGF0IGlz IGF1dGhvcml0YXRpdmUgaXMgdGhlIENCT1Igc2VxdWVuY2UuIA0KDQo+IA0KPiAgICAgICAgICA7 IEEgbm90aW9uYWwgYXJyYXksIHRoZSBlbGVtZW50cyBvZiB3aGljaCBhcmUgdG8gYmUgdXNlZA0K PiAgICAgICAgICA7IGluIGEgQ0JPUiBTZXF1ZW5jZToNCj4gDQo+IChuaXQpIElzIHRoZXJlIGEg cmVhc29uIHRvIHVzZSBhIGRpZmZlcmVudCB3b3JkaW5nIHRoYW4gdGhlDQo+IHJlZmVyZW5jZWQg ZXhhbXBsZSBmcm9tIFJGQyA4NzQyPw0KDQpOby4gDQoNCj4gDQo+IFNlY3Rpb24gNg0KPiANCj4g ICAgSW1wbGVtZW50YXRpb24gTm90ZTogIEJ5IHVzaW5nIDgtYnl0ZSB0b2tlbnMsIGl0IGlzIHBv c3NpYmxlIHRvDQo+ICAgICAgIGVhc2lseSBtaW5pbWl6ZSB0aGUgbnVtYmVyIG9mIHRva2VucyB0 aGF0IGhhdmUgdG8gYmUgdHJhY2tlZCBieQ0KPiAgICAgICBjbGllbnRzLCBieSBrZWVwaW5nIHRo ZSBib3R0b20gMzIgYml0cyB0aGUgc2FtZSBmb3IgdGhlIHNhbWUNCj4gYm9keQ0KPiAgICAgICBh bmQgdGhlIHVwcGVyIDMyIGJpdHMgY29udGFpbmluZyB0aGUgY3VycmVudCBib2R5J3MgcmVxdWVz dA0KPiBudW1iZXINCj4gICAgICAgKGluY3JlbWVudGluZyBldmVyeSByZXF1ZXN0LCBpbmNsdWRp bmcgZXZlcnkgcmUtdHJhbnNtaXQpLg0KPiBUaGlzDQo+ICAgICAgIGFsbG93cyB0aGUgY2xpZW50 IHRvIGJlIGFsbGV2aWF0ZWQgZnJvbSBrZWVwaW5nIGFsbCB0aGUgcGVyLQ0KPiAgICAgICByZXF1 ZXN0LXN0YXRlLCBlLmcuLCBpbiBTZWN0aW9uIDMgb2YgW1JGQzg5NzRdLg0KPiANCj4gSWYgd2Un cmUgZ29pbmcgdG8gaW50cm9kdWNlIHN0cnVjdHVyZSBpbnRvIGEgbm9taW5hbGx5IG9wYXF1ZQ0K PiBpZGVudGlmaWVyLCB3ZSBuZWVkIHRvIGRpc2N1c3MgdGhlIGNvbnNlcXVlbmNlcyBvZiB0aGF0 IGluIHRoZQ0KPiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4gIGRyYWZ0LWdvbnQtbnVtZXJpYy1p ZHMtc2VjLWNvbnNpZGVyYXRpb25zDQo+IGhhcyBzb21lIGd1aWRhbmNlIGluIHRoaXMgcmVnYXJk Lg0KDQpJdCBpcyBhbGwgb3BhcXVlIHRvIHRoZSBzZXJ2ZXIsIHRoZSBjbGllbnQgaXMganVzdCB1 c2luZyBpdCB0byBtYWtlIHN1cmUgaGlzIHJlcXVlc3RzIGFyZSB1bmlxdWUuIElmIG9uZSBjYW4g YWNjZXNzIHRoZSB0b2tlbiwgaXQgY2FuIGFjY2VzcyBtb3JlIGNyaXRpY2FsIGluZm9ybWF0aW9u LiBJJ20gbm90IHN1cmUgdGhlcmUgaXMgbXVjaCB0byBzYXkgYXMgdGhlIG1lc3NhZ2VzIGFyZSBu b3Qgc3VwcG9zZWQgdG8gYmUgc2VudCBvbiBjbGVhci4gVGFtcGVyaW5nIG9mIHRoZSB0b2tlbiBp cyB0aHVzIHZlcnkgZGlmZmljdWx0IGdpdmVuIHdlIGFyZSBub3QgdXNpbmcgTm9TZWMuIA0KDQo+ IA0KPiBTZWN0aW9uIDcuMQ0KPiANCj4gICAgQ29uZ2VzdGlvbiBjb250cm9sIGZvciBDT04gcmVx dWVzdHMgYW5kIHJlc3BvbnNlcyBpcyBzcGVjaWZpZWQgaW4NCj4gICAgU2VjdGlvbiA0Ljcgb2Yg W1JGQzcyNTJdLiAgRm9yIGZhc3RlciB0cmFuc21pc3Npb24gcmF0ZXMsIE5TVEFSVA0KPiB3aWxs DQo+ICAgIG5lZWQgdG8gYmUgaW5jcmVhc2VkIGZyb20gMS4gIEhvd2V2ZXIsIHRoZSBvdGhlciBD T04gY29uZ2VzdGlvbg0KPiAgICBjb250cm9sIHBhcmFtZXRlcnMgd2lsbCBuZWVkIHRvIGJlIHR1 bmVkIHRvIGNvdmVyIHRoaXMgY2hhbmdlLg0KPiBbLi4uXQ0KPiANCj4gSSB0aG91Z2h0IHRoZXJl IGhhZCBiZWVuIHNvbWUgZGlzY3Vzc2lvbiBpbiBhIGRpZmZlcmVudCBBRCdzIGJhbGxvdA0KPiB0 aHJlYWQgb24gdGhpcyB0ZXh0LCBidXQgSSBjYW4ndCBmaW5kIGl0IG5vdy4gIEknbSBoYXBweSB0 byBkZWZlciB0bw0KPiB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbiBpZiBJJ20gbm90IGp1c3QgaW1h Z2luaW5nIGl0Lg0KPiBBbnl3YXlzLCBJIG1pZ2h0IHN1Z2dlc3QgcGhyYXNpbmcgdGhpcyBhcyAi aWYgZmFzdGVyIHRyYW5zbWlzc2lvbg0KPiByYXRlcyBhcmUgbmVlZGVkLCBOU1RBUlQgd2lsbCBu ZWVkIHRvIGJlIGluY3JlYXNlZCBmcm9tIDEiLg0KDQpDaGFuZ2VkIHRvICJJbiBvcmRlciB0byBi ZW5lZml0IGZyb20gZmFzdGVyICINCg0KPiANCj4gICAgSXQgaXMgaW1wbGVtZW50YXRpb24gc3Bl Y2lmaWMgYXMgdG8gd2hldGhlciB0aGVyZSBzaG91bGQgYmUgYW55DQo+ICAgIGZ1cnRoZXIgcmVx dWVzdHMgZm9yIG1pc3NpbmcgZGF0YSBhcyB0aGVyZSB3aWxsIGhhdmUgYmVlbg0KPiBzaWduaWZp Y2FudA0KPiAgICB0cmFuc21pc3Npb24gZmFpbHVyZSBhcyBpbmRpdmlkdWFsIHBheWxvYWRzIHdp bGwgaGF2ZSBmYWlsZWQgYWZ0ZXINCj4gICAgTUFYX1RSQU5TTUlUX1NQQU4uDQo+IA0KPiAoZWRp dG9yaWFsKSBJIGRvbid0IHRoaW5rIEkgY2FuIHN1Y2Nlc3NmdWxseSBwYXJzZSB0aGlzIHNlbnRl bmNlLg0KPiBUaGVyZSBtYXkgYmUgYSBmZXcgbWlzc2luZyB3b3JkcywgYW5kIHNwbGl0dGluZyBp bnRvIG11bHRpcGxlDQo+IHNlbnRlbmNlcyB3b3VsZCBsaWtlbHkgaGVscCBhcyB3ZWxsLg0KDQpX aWxsIHVwZGF0ZSBpdC4gDQoNCj4gDQo+IFNlY3Rpb24gNy4yDQo+IA0KPiAgICBOT05fUkVDRUlW RV9USU1FT1VUIGlzIHRoZSBpbml0aWFsIG1heGltdW0gdGltZSB0byB3YWl0IGZvciBhDQo+IG1p c3NpbmcNCj4gICAgcGF5bG9hZCBiZWZvcmUgcmVxdWVzdGluZyByZXRyYW5zbWlzc2lvbiBmb3Ig dGhlIGZpcnN0IHRpbWUuDQo+IEV2ZXJ5DQo+ICAgIHRpbWUgdGhlIG1pc3NpbmcgcGF5bG9hZCBp cyByZS1yZXF1ZXN0ZWQsIHRoZSB0aW1lIHRvIHdhaXQgdmFsdWUNCj4gICAgZG91Ymxlcy4gIFRo ZSB0aW1lIHRvIHdhaXQgaXMgY2FsY3VsYXRlZCBhczoNCj4gDQo+IFRoYW5rIHlvdSBmb3IgYmVp bmcgdmVyeSBjbGVhciBhYm91dCB0aGUgZXhwb25lbnRpYWwgYmFja29mZg0KPiBwcm9jZWR1cmUN Cj4gOikNCj4gDQo+ICAgIHBheWxvYWRzIHRvIHByZXZlbnQgdGhlIGNsaWVudCB1bm5lY2Vzc2Fy aWx5IGRlbGF5aW5nLiAgSWYgbm90IGFsbA0KPiBvZg0KPiAgICB0aGUgTUFYX1BBWUxPQURTIHBh eWxvYWRzIHdlcmUgcmVjZWl2ZWQsIHRoZSBzZXJ2ZXIgU0hPVUxEIGRlbGF5DQo+IGZvcg0KPiAg ICBOT05fUkVDRUlWRV9USU1FT1VUIChleHBvbmVudGlhbGx5IHNjYWxlZCBiYXNlZCBvbiB0aGUg cmVwZWF0DQo+IHJlcXVlc3QNCj4gICAgY291bnQgZm9yIGEgcGF5bG9hZCkgYmVmb3JlIHNlbmRp bmcgdGhlIDQuMDggKFJlcXVlc3QgRW50aXR5DQo+ICAgIEluY29tcGxldGUpIFJlc3BvbnNlIENv ZGUgZm9yIHRoZSBtaXNzaW5nIHBheWxvYWQocykuICBJZiB0aGlzIGlzDQo+IGENCj4gICAgcmVw ZWF0IGZvciB0aGUgMi4zMSAoQ29udGludWUpIHJlc3BvbnNlLCB0aGUgc2VydmVyIFNIT1VMRCBz ZW5kIGENCj4gICAgNC4wOCAoUmVxdWVzdCBFbnRpdHkgSW5jb21wbGV0ZSkgcmVzcG9uc2UgZGV0 YWlsaW5nIHRoZSBtaXNzaW5nDQo+ICAgIHBheWxvYWRzIGFmdGVyIHRoZSBibG9jayBudW1iZXIg dGhhdCB3b3VsZCBoYXZlIGJlZW4gaW5kaWNhdGVkIGluDQo+IHRoZQ0KPiAgICAyLjMxIChDb250 aW51ZSkuICBbLi4uXQ0KPiANCj4gSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgImlmIHRoaXMgaXMg YSByZXBlYXQgZm9yIHRoZSAyLjMxIChDb250aW51ZSkNCj4gcmVzcG9uc2UiIGlzIGludGVuZGVk IHRvIG1lYW4uDQoNCkRvZXMgdGhpcyBoZWxwPw0KDQpPTEQNCiAgIElmIHRoaXMgaXMgYQ0KICAg cmVwZWF0IGZvciB0aGUgMi4zMSAoQ29udGludWUpIHJlc3BvbnNlLCB0aGUgc2VydmVyIFNIT1VM RCBzZW5kIGENCiAgIDQuMDggKFJlcXVlc3QgRW50aXR5IEluY29tcGxldGUpIHJlc3BvbnNlIGRl dGFpbGluZyB0aGUgbWlzc2luZw0KICAgcGF5bG9hZHMgYWZ0ZXIgdGhlIGJsb2NrIG51bWJlciB0 aGF0IHdvdWxkIGhhdmUgYmVlbiBpbmRpY2F0ZWQgaW4gdGhlDQogICAyLjMxIChDb250aW51ZSku DQoNCk5FVw0KICAgDQogICBJZiBhbGwgb2YgdGhlDQogICBNQVhfUEFZTE9BRFMgd2VyZSByZWNl aXZlZCBhbmQgYSAyLjMxIChjb250aW51ZSkgaGFkIGJlZW4gc2VudCwgYnV0DQogICBubyBtb3Jl IHBheWxvYWRzIHdlcmUgcmVjZWl2ZWQgZm9yIE5PTl9SRUNFSVZFX1RJTUVPVVQgKGV4cG9uZW50 aWFsbHkNCiAgIHNjYWxlZCksIHRoZSBzZXJ2ZXIgU0hPVUxEIHNlbmQgYSA0LjA4IChSZXF1ZXN0 IEVudGl0eSBJbmNvbXBsZXRlKQ0KICAgcmVzcG9uc2UgZGV0YWlsaW5nIHRoZSBtaXNzaW5nIHBh eWxvYWRzIGFmdGVyIHRoZSBibG9jayBudW1iZXIgdGhhdA0KICAgd2FzIGluZGljYXRlZCBpbiB0 aGUgc2VudCAyLjMxIChDb250aW51ZSkuDQoNCj4gDQo+ICAgIFRoZSBjbGllbnQgZG9lcyBub3Qg bmVlZCB0byBhY2tub3dsZWRnZSB0aGUgcmVjZWlwdCBvZiB0aGUgZW50aXJlDQo+ICAgIGJvZHku DQo+IA0KPiBEb2VzIHRoYXQgbWVhbiB0aGF0IHRoZSBsYXN0IGdyb3VwIG9mIHJlc3BvbnNlIGJs b2NrcyB3aWxsIGFsd2F5cyBiZQ0KPiByZXRyYW5zbWl0dGVkIE5PTl9NQVhfUkVUUkFOU01JVCB0 aW1lcz8NCg0KTm8uIFRoZSBzZXJ2ZXIgd29uJ3QgcmV0cmFuc21pdCBpZiBub3QgcmVxdWVzdCBp cyByZWNlaXZlZCBmcm9tIHRoZSBjbGllbnQuICAgDQoNCj4gDQo+IFNlY3Rpb24gMTANCj4gDQo+ ICAgICAgICAgICAgIFFCMTogUS1CbG9jazEgT3B0aW9uIHZhbHVlcyBOVU0vTW9yZS9TWlgNCj4g ICAgICAgICAgICAgUUIyOiBRLUJsb2NrMiBPcHRpb24gdmFsdWVzIE5VTS9Nb3JlL1NaWA0KPiAN Cj4gV2hhdCdzIGRlcGljdGVkIGluIHRoZSBmaWd1cmUgc2VlbXMgdG8gYmUgdGhlIGFjdHVhbCBi bG9jayBzaXplLCBhbmQNCj4gbm90IHRoZSB0aHJlZS1iaXQgU1pYIHZhbHVlLg0KDQpJdCBpcyBh Y3R1YWwgc2l6ZS4gQ2xhcmlmaWVkIGluIHRoZSB0ZXh0LiANCg0KPiANCj4gU2VjdGlvbiAxMC4x LjMNCj4gDQo+IFNob3VsZCB3ZSBpbmRpY2F0ZSBzb21laG93IGluIEZpZ3VyZSA2IHRoYXQgdGhl IDQuMDggcmVzcG9uc2VzIHVzZQ0KPiB0aGUgbmV3IGNvbnRlbnQtZm9ybWF0Pw0KPiANCj4gQWxz bywgaXMgdGhlcmUgYW55IHZhbHVlIGluIGluZGljYXRpbmcgdGhhdCB0aGVyZSBtaWdodCBiZSBh IHJhY2UNCj4gYmV0d2VlbiB0aGUgY2xpZW50IGNvbnRpbnVpbmcgdG8gc2VuZCB0aGUgbmV4dCBz ZXQgb2YgcGF5bG9hZHMgYW5kDQo+IHRoZSBpbml0aWFsIDQuMDggcmVzcG9uc2U/DQoNCkFkZGVk IGEgcG9pbnRlciB0byB0aGUgc2VjdGlvbiB3aGVyZSA0LjA4IGlzIGRlZmluZWQuIA0KDQo+IA0K PiBTZWN0aW9uIDEwLjIuMw0KPiANCj4gSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB0aGUgTk9OX1JF Q0VJVkVfVElNRU9VVCAoY2xpZW50KSB0cmlnZ2VycyAtLQ0KPiBzaG91bGRuJ3QgdGhlIGRlbGl2 ZXJ5IG9mIHRoZSAxMXRoIGJsb2NrIGluZGljYXRlIHRoYXQgdGhlIHNlcnZlcg0KPiB0aGlua3Mg aXQgc2VudCBhIGZ1bGwgTUFYX1BBWUxPQURTIGdyb3VwIGFuZCB0aHVzIGEgc2VsZWN0aXZlIEFD SywNCj4gYWZ0ZXIgcGVyaGFwcyBqdXN0IGEgbW9kZXN0IHJlb3JkZXJpbmcgZGVsYXk/DQoNCkZh aXIgcXVlc3Rpb24gZm9yIHRoZSBmaXJzdCB0aGUgTk9OX1JFQ0VJVkVfVElNRU9VVC4gIFdlIGhh bmRsZSB0aGlzIGZvciBRLUJsb2NrMSAoRmlndXJlIDYpLiAgV2UgZG8gaGF2ZToNCg0KICAgSXQg aXMgbGlrZWx5IHRoYXQgdGhlIHNlcnZlciB3aWxsIHN0YXJ0IHRyYW5zbWl0dGluZyB0aGUgbmV4 dCBzZXQgb2YNCiAgIE1BWF9QQVlMT0FEUyBwYXlsb2FkcyBiZWZvcmUgdGhlIGNsaWVudCB0aW1l cyBvdXQgb24gd2FpdGluZyBmb3IgdGhlDQogICBsYXN0IG9mIHRoZSBwcmV2aW91cyBNQVhfUEFZ TE9BRFMgcGF5bG9hZHMuICBVcG9uIHJlY2VpcHQgb2YgdGhlDQogICBmaXJzdCBwYXlsb2FkIGZy b20gdGhlIG5ldyBzZXQgb2YgTUFYX1BBWUxPQURTIHBheWxvYWRzLCB0aGUgY2xpZW50DQogICBT SE9VTEQgc2VuZCBhIHJlcXVlc3QgaW5kaWNhdGluZyBhbnkgbWlzc2luZyBwYXlsb2FkcyBmcm9t IGFueQ0KICAgcHJldmlvdXMgc2V0IG9mIE1BWF9QQVlMT0FEUyBwYXlsb2Fkcy4gIFVwb24gcmVj ZWlwdCBvZiBzdWNoIHJlcXVlc3QsDQogICB0aGUgc2VydmVyIFNIT1VMRCBzZW5kIHRoZSBtaXNz aW5nIHBheWxvYWRzIGJlZm9yZSBjb250aW51aW5nIHRvIHNlbmQNCiAgIHRoZSByZW1haW5kZXIg b2YgdGhlIE1BWF9QQVlMT0FEUyBwYXlsb2FkcyBhbmQgdGhlbiBnbyBpbnRvIGFub3RoZXINCiAg IE5PTl9USU1FT1VUIGRlbGF5IHByaW9yIHRvIHNlbmRpbmcgdGhlIG5leHQgc2V0IG9mIHBheWxv YWRzLg0KDQpPTEQ6DQogICAgICAgW1tOT05fVElNRU9VVCAoc2VydmVyKSBkZWxheSBleHBpcmVz XV0NCiAgICAgICAgICB8ICAgICBbW1NlcnZlciBzZW5kcyBuZXh0IHNldCBvZiBwYXlsb2Fkc11d DQogICAgICAgICAgfDwtLS0tLS0tLS0rIE5PTiAyLjA1IE06MHhhYiBUOjB4ZjAgTzoxMjM2IEVU PTIzIFFCMjoxMC8wLzEwMjQNCiAgICAgICAgICB8ICAgLi4uICAgIHwNCiAgICAgICBbW05PTl9S RUNFSVZFX1RJTUVPVVQgKGNsaWVudCkgZGVsYXkgZXhwaXJlc11dDQogICAgICAgICAgfCAgICAg W1tDbGllbnQgcmVhbGl6ZXMgYmxvY2tzIGFyZSBtaXNzaW5nIGFuZCBhc2tzIGZvciB0aGUNCiAg ICAgICAgICB8ICAgICAgIG1pc3Npbmcgb25lcyBpbiBvbmUgZ29dXQ0KICAgICAgICAgICstLS0t LS0tLS0+fCBOT04gR0VUIC9wYXRoIE06MHgwNCBUOjB4ZjMgUUIyOjEvMC8xMDI0XA0KICAgICAg ICAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUUIyOjkvMC8xMDI0 DQogICAgICAgICAgfCAgICAgWDwtLS0rIE5PTiAyLjA1IE06MHhhYyBUOjB4ZjMgRVQ9MjMgUUIy OjEvMS8xMDI0IA0KDQpORVc6DQogICAgICAgW1tOT05fVElNRU9VVCAoc2VydmVyKSBkZWxheSBl eHBpcmVzXV0NCiAgICAgICAgICB8ICAgICBbW1NlcnZlciBzZW5kcyBuZXh0IHNldCBvZiBwYXls b2Fkc11dDQogICAgICAgICAgfDwtLS0tLS0tLS0rIE5PTiAyLjA1IE06MHhhYiBUOjB4ZjAgTzox MjM2IEVUPTIzIFFCMjoxMC8wLzEwMjQNCiAgICAgICAgICB8ICAgICBbW09uIHNlZWluZyBhIHBh eWxvYWQgZnJvbSB0aGUgbmV4dCBzZXQgb2YgcGF5bG9hZHMsIA0KICAgICAgICAgIHwgICAgICBD bGllbnQgcmVhbGl6ZXMgYmxvY2tzIGFyZSBtaXNzaW5nIGFuZCBhc2tzIGZvciB0aGUNCiAgICAg ICAgICB8ICAgICAgIG1pc3Npbmcgb25lcyBpbiBvbmUgZ29dXQ0KICAgICAgICAgICstLS0tLS0t LS0+fCBOT04gR0VUIC9wYXRoIE06MHgwNCBUOjB4ZjMgUUIyOjEvMC8xMDI0XA0KICAgICAgICAg IHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUUIyOjkvMC8xMDI0DQog ICAgICAgICAgfCAgICAgWDwtLS0rIE5PTiAyLjA1IE06MHhhYyBUOjB4ZjMgRVQ9MjMgUUIyOjEv MS8xMDI0DQoNCg0KPiANCj4gU2VjdGlvbiAxMC4zLjINCj4gDQo+ICAgIFtbTUFYX1BBWUxPQURT IGhhcyBiZWVuIHJlYWNoZWRdXQ0KPiAgICAgICB8ICAgICBbW01BWF9QQVlMT0FEUyBibG9ja3Mg YWNrbm93bGVkZ2VkIGJ5IGNsaWVudCB1c2luZw0KPiAgICAgICB8ICAgICAgICdDb250aW51ZScg US1CbG9jazJdXQ0KPiAgICAgICArLS0tLS0tLS0tPnwgTk9OIEZFVENIIC9wYXRoIE06MHgzYiBU OjB4YWIgUUIyOjEwLzEvMTAyNA0KPiAgICAgICB8PC0tLS0tLS0tLSsgTk9OIDIuMDUgTToweDhi IFQ6MHhhYSBPOjEzMzQgRVQ9MjEgUUIyOjEwLzAvMTAyNA0KPiANCj4gU2hvdWxkbid0IHRoZSBz ZXJ2ZXIgc3dpdGNoIHRvIHVzaW5nIFQ6MHhhYiBub3c/DQoNClRoaXMgaXMgYSAnQ29udGludWUn IGFzIHBlcjoNCg0KICAgVGhlIHNlcnZlciBTSE9VTEQgcmVjb2duaXplIHRoZSAnQ29udGludWUn IFEtQmxvY2syIHJlcXVlc3QgYXMgYQ0KICAgY29udGludWUgcmVxdWVzdCBhbmQganVzdCBjb250 aW51ZSB0aGUgdHJhbnNtaXNzaW9uIG9mIHRoZSBib2R5DQogICAoaW5jbHVkaW5nIE9ic2VydmUg T3B0aW9uLCBpZiBhcHByb3ByaWF0ZSBmb3IgYW4gdW5zb2xpY2l0ZWQNCiAgIHJlc3BvbnNlKSBy YXRoZXIgdGhhbiBhcyBhIHJlcXVlc3QgZm9yIHRoZSByZW1haW5pbmcgbWlzc2luZyBibG9ja3Mu DQoNClNvIHRva2VuIGRvZXMgbm90IGNoYW5nZS4gV2UgY2FuIGFkZCBpdCB0aGUgdGV4dC4gDQoN Cj4gDQo+ICAgICAgICstLS0tLS0tLS0+fCBOT04gRkVUQ0ggL3BhdGggTToweDNjIFQ6MHhhYyBR QjI6MTAvMS8xMDI0DQo+ICAgICAgIHw8LS0tLS0tLS0tKyBOT04gMi4wNSBNOjB4OTYgVDoweGFh IE86MTMzNSBFVD0yMiBRQjI6MTAvMC8xMDI0DQo+IA0KPiBhbmQgMHhhYyBoZXJlPw0KDQpJZGVt IGFzIHByZXZpb3VzIG9uZS4gDQoNCj4gDQo+IFNlY3Rpb24gMTAuMy4zDQo+IA0KPiAgICAgICAg ICAgfDwtLS0tLS0tLS0rIE5PTiAyLjA1IE06MHhhNiBUOjB4YzYgRVQ9MjMgUUIyOjMvMC8xMDI0 DQo+ICAgICAgICAgICB8ICAgLi4uICAgIHwNCj4gICAgICAgIFtbTk9OX1JFQ0VJVkVfVElNRU9V VCAoY2xpZW50KSBkZWxheSBleHBpcmVzXV0NCj4gDQo+IFdoeSBkb2VzIHRoZSBjbGllbnQgdGlt ZSBvdXQgaGVyZSAoYXQgbGVhc3Qgd2l0aCB0aGUgZnVsbA0KPiBOT05fUkVDRUlWRV9USU1FT1VU KTsgdGhlIGZpbmFsLW1lc3NhZ2UgaW5kaWNhdGlvbiBzZWVtcyBsaWtlIGl0DQo+IHdvdWxkIGFs bG93IGZvciBhbiB+aW1tZWRpYXRlIHJlc3BvbnNlIChkZWxheWVkIG9ubHkgZm9yIHNvbWUNCj4g cmVvcmRlcmluZyB0aHJlc2hvbGQpPw0KPiANCg0KV2UgbmVlZCB0byBvYnNlcnZlIGEgZGVsYXkg aGVyZSBpbiBjYXNlIHRoZXJlIGlzIGFueSBwYWNrZXQgYXJyaXZhbCByZS1vcmRlcmluZy4gV2Ug ZGVjaWRlZCBhdCB0aGUgdGltZSB0byBub3QgaGF2ZSBhbm90aGVyIHlldCBleHRyYSB0aW1lciB0 byBjb3ZlciB0aGlzLiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgYW4gb3B0aW1pemF0aW9uIGFu ZCBldmVuIHdpdGggdGhlIGN1cnJlbnQgZGVzaWduLCB0aGUgcGVyZm9ybWFuY2UgaXMgbXVjaCBi ZXR0ZXIgdGhhbiB0aGUgbGVnYWN5IGJsb2NrLXdpc2UuICANCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIK YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4K Cg== From nobody Thu May 6 22:03: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 50B5E3A184A; Thu, 6 May 2021 22:03:35 -0700 (PDT) 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_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 vyt10pb962eN; Thu, 6 May 2021 22:03:29 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (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 C1EE13A1863; Thu, 6 May 2021 22:02:32 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 4FbyxK3MLsz5wH4; Fri, 7 May 2021 07:02:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620363749; bh=h0//XjVwRBoDOUQkPnFhRjWFT8K4aqfLzZkktZhxPyk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=FtGAJsO5Kv95ad7/piAf+huaH3S1LT33SXfEujtlvWeVbODDxlRjJKu17SlVnFfmA 8io9fng5MSExbhUtK96hPqriDzib74cc9VFJpkNNfnvHDsfd37kkSnyoaJmE6jb6gx HyHs4usPFomVdRQIuySAyPOA8OaeY3fgybUbYjOgCPLZw4ccswEwL+1SnJh3zZWnKB s4I+1SFVSTR+jfWGsW9gWZpJZoR8MkFk8gob+e9qGzGb3hSEjhWOD0XrDzoftLRP8W J7zx0UzeRmA/ljYOZPVpAdwkPiDTBxTjqyWLdmiqDRcitSHAVl9W6DN/UbIu95CCgg 3JWlctbV7dprQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 4FbyxK1tM0zDq8C; Fri, 7 May 2021 07:02:29 +0200 (CEST) From: To: John Scudder , The IESG CC: "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXQhDFbxj+uJeZ3ki6j7o7EbYtyKrV+drw Date: Fri, 7 May 2021 05:02:28 +0000 Message-ID: <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> In-Reply-To: <162026169267.30008.8195219304146866165@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (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, 07 May 2021 05:03:36 -0000 SGkgSm9obiwNCg0KVGhhbmsgeW91IGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3LiBNdWNoIGFwcHJl Y2lhdGVkLiANCg0KQ2hhbmdlcyBjYW4gYmUgdHJhY2tlZCBhdDogaHR0cHM6Ly90aW55dXJsLmNv bS9uZXctYmxvY2stbGF0ZXN0IA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCkpv biAmIE1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb2huIFNj dWRkZXIgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10NCj4gRW52b3nD qcKgOiBqZXVkaSA2IG1haSAyMDIxIDAyOjQyDQo+IMOAwqA6IFRoZSBJRVNHIDxpZXNnQGlldGYu b3JnPg0KPiBDY8KgOiBkcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrQGlldGYub3JnOyBjb3JlLWNo YWlyc0BpZXRmLm9yZzsNCj4gY29yZUBpZXRmLm9yZzsgbWFyY28udGlsb2NhQHJpLnNlOyBtYXJj by50aWxvY2FAcmkuc2UNCj4gT2JqZXTCoDogSm9obiBTY3VkZGVyJ3MgRGlzY3VzcyBvbiBkcmFm dC1pZXRmLWNvcmUtbmV3LWJsb2NrLTExOiAod2l0aA0KPiBESVNDVVNTIGFuZCBDT01NRU5UKQ0K PiANCj4gSm9obiBTY3VkZGVyIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0 aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrLTExOiBEaXNjdXNzDQo+IA0KPiBX aGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCBy ZXBseSB0byBhbGwNCj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0Mg bGluZXMuIChGZWVsIGZyZWUgdG8gY3V0DQo+IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwg aG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3Jn L2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtDQo+IGNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5m b3JtYXRpb24gYWJvdXQgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4g VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBm b3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWNvcmUtbmV3LWJsb2NrLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLQ0KPiBESVND VVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLQ0KPiANCj4gRm9yIHRoZSBtb3N0IHBhcnQgSSBmb3Vu ZCB0aGlzIGRvY3VtZW50IHJlbGF0aXZlbHkgZWFzeSB0byBmb2xsb3csDQo+IGNvbnNpZGVyaW5n IG15IGNvbXBsZXRlIGxhY2sgb2YgYmFja2dyb3VuZCBpbiBDb0FQLiBIb3dldmVyLCBkZXNwaXRl DQo+IGEgY29uY2VydGVkIGVmZm9ydCBJIGhhdmUgbm90IGJlZW4gYWJsZSB0byBuYWlsIGRvd24g d2l0aCBjb25maWRlbmNlDQo+IHdoYXQgdGhlIGludGVuZGVkIHNlbWFudGljcyBvZiBzZXZlcmFs IG9mIHlvdXIgdGltZW91dHMgYXJlLCBub3RhYmx5DQo+IE5PTl9SRUNFSVZFX1RJTUVPVVQuIFNv bWUgb2YgdGhlIHRleHQgKGZvciBleGFtcGxlLCDCpzQuNCkgaW1wbGllcw0KPiB0aGF0IHRoZSB0 aW1lb3V0IGlzIGFuIHVwcGVyIGJvdW5kIG9uIGhvdyBsb25nIGFuIGltcGxlbWVudGF0aW9uDQo+ IHNob3VsZCB3YWl0IGJlZm9yZSBkZWNsYXJpbmcgYSBibG9jayB0byBoYXZlIGJlZW4gbG9zdCAo 4oCcVGhlIGNsaWVudA0KPiBTSE9VTEQgd2FpdCBmb3IgdXAgdG8gTk9OX1JFQ0VJVkVfVElNRU9V VOKAnSkuDQoNClRoZSB0ZXh0IGFyb3VuZCB0aGUgdGltZW91dCB2YWx1ZXMgaGF2ZSBiZWVuIG1h ZGUgYWJzb2x1dGUgKGFzIHBlciB5b3VyIENPTU1FTlRTKSwgcmVtb3ZpbmcgInVwIHRvIiwgZXRj LiwgYW5kIG9uY2UgdGhlIHRpbWVvdXQgaGFzIGV4cGlyZWQsIHRoZW4gdGhlIG5leHQgYWN0aXZp dHkgdGFrZXMgcGxhY2UuIERvZXMgdGhpcyBoZWxwIGNsYXJpZnkgdGhpbmdzPw0KDQogQXQgdGhl IHZlcnkgbGVhc3QsIHRoaXMNCj4gaXMgaW1wcmVjaXNlIGJlY2F1c2UgdGhlIHRpbWVvdXQgaW5j cmVhc2VzIGV4cG9uZW50aWFsbHkgd2l0aA0KPiByZXBlYXRlZCB0aW1lb3V0cyDigJQgYnV0IHRo aXMgaXMgYSByZWxhdGl2ZWx5IG1pbm9yIG1hdHRlciwgZGlzY3Vzc2VkDQo+IGZ1cnRoZXIgaW4g bXkgY29tbWVudHMuDQo+IA0KPiBMYXRlciwgaW4gwqc3LjIsIHlvdSBzYXkgdGhhdCBleHBpcnkg b2YgdGhlIHRpbWVvdXQgaXMgbm90IHRoZSBvbmx5DQo+IHRyaWdnZXIgZm9yIGEgNC4wOCByZXNw b25zZToNCj4gDQo+ICAgIEl0IGlzIGxpa2VseSB0aGF0IHRoZSBjbGllbnQgd2lsbCBzdGFydCB0 cmFuc21pdHRpbmcgdGhlIG5leHQgc2V0DQo+IG9mDQo+ICAgIE1BWF9QQVlMT0FEUyBwYXlsb2Fk cyBiZWZvcmUgdGhlIHNlcnZlciB0aW1lcyBvdXQgb24gd2FpdGluZyBmb3INCj4gdGhlDQo+ICAg IGxhc3Qgb2YgdGhlIHByZXZpb3VzIE1BWF9QQVlMT0FEUyBwYXlsb2Fkcy4gIE9uIHJlY2VpcHQg b2YgdGhlDQo+IGZpcnN0DQo+ICAgIHBheWxvYWQgZnJvbSB0aGUgbmV3IHNldCBvZiBNQVhfUEFZ TE9BRFMgcGF5bG9hZHMsIHRoZSBzZXJ2ZXINCj4gU0hPVUxEDQo+ICAgIHNlbmQgYSA0LjA4IChS ZXF1ZXN0IEVudGl0eSBJbmNvbXBsZXRlKSBSZXNwb25zZSBDb2RlIGluZGljYXRpbmcNCj4gYW55 DQo+ICAgIG1pc3NpbmcgcGF5bG9hZHMgZnJvbSBhbnkgcHJldmlvdXMgTUFYX1BBWUxPQURTIHBh eWxvYWRzLg0KPiANCj4gSXQgbWFrZXMgc2Vuc2UgdG8gbWUgdGhhdCB5b3UgdXNlIHRoaXMgYWRk aXRpb25hbCB0cmlnZ2VyLiBBdCB0aGlzDQo+IHBvaW50IGluIG15IHJlYWRpbmcgb2YgdGhlIHNw ZWMsIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlDQo+IHJldHJhbnNtaXNzaW9uIGFsZ29yaXRobSB3 YXMgdGhhdCBhIDQuMDggc2hvdWxkIGJlIHNlbnQgd2hlbiBlaXRoZXIgYQ0KPiBwYXlsb2FkIGlz IHJlY2VpdmVkIGZyb20gYSBuZXcgc2V0IG9mIE1BWF9QQVlMT0FEUywgb3INCj4gTk9OX1JFQ0VJ VkVfVElNRU9VVCBleHBpcmVzLiBCdXQgdGhlbiBJIGdvdCB0byB0aGUgZXhhbXBsZSBpbiAxMC4y LjMsDQoNClRoZSB0ZXh0IHlvdSBxdW90ZWQgaXMgZm9yIFEtQmxvY2sxLCAxMC4yLjMgaXMgYWJv dXQgUS1CbG9jazIuIA0KDQo+IHdoaWNoIHNob3dzIHRoZSBjbGllbnQgd2FpdGluZyBmb3IgdGhl IGV4cGlyYXRpb24gb2YNCj4gTk9OX1JFQ0VJVkVfVElNRU9VVCBldmVuIHRob3VnaCBpdCBoYXMg cmVjZWl2ZWQgdGhlIGZpcnN0IG9mIGEgbmV3DQo+IHNldCBvZiBNQVhfUEFZTE9BRFMsIGFuZCBJ IGNvbmNsdWRlZCB0aGF0IGVpdGhlciBJ4oCZdmUgbWlzc2VkDQo+IHNvbWV0aGluZyBiYXNpYywg b3IgdGhlIGRvY3VtZW50IGlzIGludGVybmFsbHkgaW5jb25zaXN0ZW50Lg0KDQpUaGUgY2xpZW50 IGZvbGxvd3MgdGhpcyBiZWhhdmlvcjoNCg0KICAgVGhlIGNsaWVudCBTSE9VTEQgd2FpdCBmb3Ig dXAgdG8gTk9OX1JFQ0VJVkVfVElNRU9VVCAoU2VjdGlvbiA3LjIpDQogICBhZnRlciB0aGUgbGFz dCByZWNlaXZlZCBwYXlsb2FkIGZvciBOT04gcGF5bG9hZHMgYmVmb3JlIGlzc3VpbmcgYQ0KICAg R0VULCBQT1NULCBQVVQsIEZFVENILCBQQVRDSCwgb3IgaVBBVENIIHJlcXVlc3QgdGhhdCBjb250 YWlucyBvbmUgb3INCiAgIG1vcmUgUS1CbG9jazIgT3B0aW9ucyB0aGF0IGRlZmluZSB0aGUgbWlz c2luZyBibG9ja3Mgd2l0aCB0aGUgTSBiaXQNCiAgIHVuc2V0LiAgVGhlIGNsaWVudCBNQVkgc2V0 IHRoZSBNIGJpdCB0byByZXF1ZXN0IHRoaXMgYW5kIGxhdGVyIGJsb2Nrcw0KICAgZnJvbSB0aGlz IE1BWF9QQVlMT0FEUyBzZXQuICANCg0KPiANCj4gQXMgYW4gYXNpZGUsIEnigJltIGFsc28gdW5j bGVhciBhcyB0byB3aHkgdGhlIG9ubHkgdHJpZ2dlciB5b3Ugc3BlY2lmeQ0KPiBmb3Igc2VuZGlu ZyBhIDQuMDggaXMgdGhlIGFycml2YWwgb2YgdGhlIGZpcnN0IG9mIGEgbmV3IE1BWF9QQVlMT0FE Uw0KDQoiRmlyc3QiIGlzIG5vdCB1c2VkIGluIHJlZmVyZW5jZSB0aGUgYmxvY2sgb3JkZXIgaW4g dGhlIG5leHQgYmxvY2ssIGJ1dCB0aGUgZmlyc3Qgb25lIHJlY2VpdmVkLiBJIHNlZSB0aGlzIGlz IGNvbmZ1c2luZy4gTWFkZSB0aGlzIGNoYW5nZTogcy90aGUgZmlyc3QvYQ0KDQo+IGZsaWdodC4g T3RoZXIgcG9zc2libGUgdHJpZ2dlcnMgSSBub3RpY2VkIGluY2x1ZGUgYSBnYXAgaW4gdGhlDQo+ IHNlcXVlbmNlLCBhbmQgcmVjZXB0aW9uIG9mIGEgcGF5bG9hZCB3aXRoIE1vcmU9MC4NCj4gDQo+ IFNvbWUgb2YgdGhlc2UgaXNzdWVzIGFyZSByZXBlYXRlZCBpbiBteSBjb21tZW50cywgYmVsb3cg 4oCUIEnigJl2ZSBub3RlZA0KPiB0aG9zZSBpbiB0aGUgY29tbWVudC4gUG9zc2libHkgaW4gYWRk cmVzc2luZyB0aGlzIERJU0NVU1Mgd2XigJlsbCBjbGVhcg0KPiB1cCBzb21lIG9mIHRob3NlIGNv bW1lbnRzIHRvby4NCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLQ0KPiBDT01NRU5UOg0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gLQ0KPiANCj4gQ29tbWVudHM6DQo+IA0KPiAoZHJhZnQtaWV0Zi1jb3Jl LW5ldy1ibG9jay0xMSkNCj4gDQo+IDEuIFNlY3Rpb24gMy4yDQo+IA0KPiAgICBUaGlzIG1lY2hh bmlzbSBpcyBub3QgaW50ZW5kZWQgZm9yIGdlbmVyYWwgQ29BUCB1c2FnZSwgYW5kIGFueSB1c2UN Cj4gICAgb3V0c2lkZSB0aGUgaW50ZW5kZWQgdXNlIGNhc2Ugc2hvdWxkIGJlIGNhcmVmdWxseSB3 ZWlnaGVkIGFnYWluc3QNCj4gdGhlDQo+ICAgIGxvc3Mgb2YgaW50ZXJvcGVyYWJpbGl0eSB3aXRo IGdlbmVyaWMgQ29BUCBhcHBsaWNhdGlvbnMuDQo+IA0KPiBJ4oCZbSBjdXJpb3VzOiBpcyB0aGUg b25seSByZWFzb24gdGhlIG1lY2hhbmlzbSBpc27igJl0IGludGVuZGVkIGZvcg0KPiBnZW5lcmFs IHVzYWdlLCB0aGUgZmFjdCBzb21lIGltcGxlbWVudGF0aW9ucyB3b27igJl0IHN1cHBvcnQgaXQ/ IE9yDQo+IGRvZXMgaXQgaGF2ZSBvdGhlciBkZWZpY2llbmNpZXMgdGhhdCBhbHNvIG1ha2UgaXQg dW5zdWl0YWJsZT8NCg0KVGhpcyBpcyBiZWNhdXNlIHRoZSBnZW5lcmFsIGFwcGxpY2F0aW9uIGNh c2UgbWF5IHJlcXVpcmUgdG91Y2hpbmcgb3RoZXIgcGFydHMgb2YgdGhlIGJsb2NrLXdpc2UgKGlu dGVyZmVyZW5jZSB3aXRoIGNhY2hpbmcsIG1peGluZyBDT04vTk9OLCBldGMuKS4gQWxzbywgdGhl IGNvbmdlc3Rpb24gY29udHJvbCBndWFyZHMgYXJlIGdvb2QgZW5vdWdoIGZvciB0aGUgdGFyZ2V0 IGNhc2UgYXMgd2UgZG8gaGF2ZSBhbiBpbmRpY2F0aW9uIGF0IHRoZSBET1RTIGxldmVsIGlmIHRo ZSBwZWVycyBhcmUgbm90IG92ZXJsb2FkZWQgKGhlYXJ0YmVhdHMpIGFuZCBhYmxlIHRvIG5lZ290 aWF0ZSB0aGUgcHJvYmluZy1yYXRlLiBTdWNoIGZlYXR1cmVzIG1heSBub3QgYmUgYXZhaWxhYmxl IGluIHRoZSBnZW5lcmljIENvQVAgY2FzZS4gDQoNCj4gDQo+IDIuIFNlY3Rpb24gNC4xDQo+IA0K PiAgICBRLUJsb2NrMiBPcHRpb24gaXMgdXNlZnVsIHdpdGggR0VULCBQT1NULCBQVVQsIEZFVENI LCBQQVRDSCwgYW5kDQo+ICAgIGlQQVRDSCByZXF1ZXN0cyBhbmQgdGhlaXIgcGF5bG9hZC1iZWFy aW5nIHJlc3BvbnNlcyAoMi4wMSwgMi4wMiwNCj4gICAgMi4wMywgMi4wNCwgYW5kIDIuMDUpIChT ZWN0aW9uwqA1LjUgb2YgW1JGQzcyNTJdKS4NCj4gDQo+IEkgZm91bmQgdGhlIGxpc3Qgb2YgY29k ZXMgaW5jb21wcmVoZW5zaWJsZSBvbiBmaXJzdCBlbmNvdW50ZXJpbmcgaXQsDQo+IHNpbmNlIHRo ZSBjb25jZXB0IG9mIHJlc3BvbnNlIGNvZGVzIGhhZG7igJl0IGJlZW4gaW50cm9kdWNlZCB5ZXQu IEkgZG8NCj4gdW5kZXJzdGFuZCB0aGF0IHRoZSBkb2N1bWVudCBhc3N1bWVzIGZhbWlsaWFyaXR5 IHdpdGggQ29BUDsNCj4gbm9uZXRoZWxlc3MgZm9yIGJhc2ljIGNsYXJpdHkgSSB0aGluayB0aGlz IHNob3VsZCBzYXkg4oCcKHJlc3BvbnNlDQo+IGNvZGVzIDIuMDEsIDIuMDLigKbigJ0uIEFkZGl0 aW9uYWxseSwgdGhlIHJlZmVyZW5jZSB0byBSRkMgNzI1MiDCpzUuNQ0KPiBkb2VzbuKAmXQgc2Vl bSB0byBiZSBlc3BlY2lhbGx5IGdlcm1hbmU/DQoNClRoZSBrZXkgZWxlbWVudCBpbiB0aGUgdGV4 dCB5b3UgcXVvdGVkIGlzICJwYXlsb2FkLWJlYXJpbmcgcmVzcG9uc2VzIi4gSGVuY2UgdGhlIHBv aW50ZXIgdG8gNS41IG9mIFJGQzcyNTIuDQoNCj4gDQo+IEJ5IHRoZSB3YXksIGlzIDIuMDMgaW5k ZWVkIGEgcGF5bG9hZC1iZWFyaW5nIHJlc3BvbnNlPyBUaGUgb25seSBvdGhlcg0KPiBwbGFjZSB0 aGUgc3BlYyB0b3VjaGVzIG9uIGl0IGlzIGluIMKnNC40LCB3aGljaCBzYXlzIOKAnHRoZSBzZXJ2 ZXIgY291bGQNCj4gcmVzcG9uZCB3aXRoIGEgMi4wMw0KPiAoVmFsaWQpIHJlc3BvbnNlIHdpdGgg bm8gcGF5bG9hZOKAnS4NCj4gDQoNCk5vdGVkLiANCg0KPiAzLiBTZWN0aW9uIDQuMQ0KPiANCj4g ICAgVG8gaW5kaWNhdGUgc3VwcG9ydCBmb3IgUS1CbG9jazIgcmVzcG9uc2VzLCB0aGUgQ29BUCBj bGllbnQgTVVTVA0KPiAgICBpbmNsdWRlIHRoZSBRLUJsb2NrMiBPcHRpb24gaW4gYSBHRVQgb3Ig c2ltaWxhciByZXF1ZXN0IChGRVRDSCwNCj4gZm9yDQo+ICAgIGV4YW1wbGUpLCB0aGUgUS1CbG9j azIgT3B0aW9uIGluIGEgUFVUIG9yIHNpbWlsYXIgcmVxdWVzdCwgb3IgdGhlDQo+ICAgIFEtQmxv Y2sxIE9wdGlvbiBpbiBhIFBVVCBvciBzaW1pbGFyIHJlcXVlc3Qgc28gdGhhdCB0aGUgc2VydmVy DQo+IGtub3dzDQo+ICAgIHRoYXQgdGhlIGNsaWVudCBzdXBwb3J0cyB0aGlzIFEtQmxvY2sgZnVu Y3Rpb25hbGl0eSBzaG91bGQgaXQgbmVlZA0KPiB0bw0KPiAgICBzZW5kIGJhY2sgYSBib2R5IHRo YXQgc3BhbnMgbXVsdGlwbGUgcGF5bG9hZHMuICBPdGhlcndpc2UsIHRoZQ0KPiBzZXJ2ZXINCj4g ICAgd291bGQgdXNlIHRoZSBCbG9jazIgT3B0aW9uIChpZiBzdXBwb3J0ZWQpIHRvIHNlbmQgYmFj ayBhIG1lc3NhZ2UNCj4gICAgYm9keSB0aGF0IGlzIHRvbyBsYXJnZSB0byBmaXQgaW50byBhIHNp bmdsZSBJUCBwYWNrZXQgW1JGQzc5NTldLg0KPiANCj4gSXMgdGhpcyBwYXJhZ3JhcGggcmVhbGx5 IHN1cHBvc2VkIHRvIG1lbnRpb24gYm90aCBRLUJsb2NrMiBhbmQgUS0NCj4gQmxvY2sxPw0KDQpZ ZXMsIGJlY2F1c2U6IA0KDQogICBBIENvQVAgZW5kcG9pbnQgKG9yIHByb3h5KSBNVVNUIHN1cHBv cnQgZWl0aGVyIGJvdGggb3IgbmVpdGhlciBvZiB0aGUNCiAgIFEtQmxvY2sxIGFuZCBRLUJsb2Nr MiBPcHRpb25zLg0KDQogSW4gcGFydGljdWxhciwgSeKAmW0gY29uZnVzZWQgYnkgdGhlIG1lbnRp b24gb2YgYm90aCBvZiB0aGVzZQ0KPiBpbiByZWxhdGlvbiB0byBQVVQuDQoNClRoZSBzZXJ2ZXIg d2lsbCBpZ25vcmUgdGhlIG9wdGlvbiBpZiBpdCBzdXBwb3J0cyBpdCwgb3RoZXJ3aXNlIGl0IHdp bGwgc2VuZCBhbiBlcnJvciBhcyB0aGlzIGlzIGNyaXRpY2FsIG9wdGlvbi4gVGhlIHB1cnBvc2Ug aXMgdG8gbm90aWZ5L2NoZWNrIFEtQmxvY2sgaXMgc3VwcG9ydGVkLiANCg0KPiANCj4gNC4gU2Vj dGlvbiA0LjENCj4gDQo+ICAgIFRoZSBRLUJsb2NrMSBhbmQgUS1CbG9jazIgT3B0aW9ucyBhcmUg dW5zYWZlIHRvIGZvcndhcmQuICBUaGF0IGlzLA0KPiBhDQo+ICAgIENvQVAgcHJveHkgdGhhdCBk b2VzIG5vdCB1bmRlcnN0YW5kIHRoZSBRLUJsb2NrMSAob3IgUS1CbG9jazIpDQo+IE9wdGlvbg0K PiAgICBNVVNUIHJlamVjdCB0aGUgcmVxdWVzdCBvciByZXNwb25zZSB0aGF0IHVzZXMgZWl0aGVy IG9wdGlvbi4NCj4gDQo+IFByZXN1bWFibHkgKGhvcGVmdWxseSkgdGhpcyBpcyBzaW1wbHkgZGVz Y3JpYmluZyB0aGUgYmVoYXZpb3Igb2YNCj4gZXhpc3Rpbmcgc3BlYy1jb21wbGlhbnQgcHJveGll cyB3aGVuIHByb2Nlc3NpbmcgdGhlIG5ldyBtZXNzYWdlcy4gQXMNCj4gc3VjaCwgaXMgdGhlIE1V U1QgYXBwcm9wcmlhdGU/IEkgd291bGQgdGhpbmsgbm90Lg0KDQpUaGlzIGlzIG9ubHkgZm9yIHRo b3NlIHRoYXQgYXJlIHRhZ2dlZCBhcyB1bnNhZmUgdG8gZm9yd2FyZC4gVGhlIG5vcm1hdGl2ZSBs YW5ndWFnZSBpcyBPSy4gDQoNCj4gDQo+IDUuIFNlY3Rpb24gNC4zDQo+IA0KPiAgICAgICBib2R5 LiAgTm90ZSB0aGF0IHRoZSBsYXN0IHJlY2VpdmVkIHBheWxvYWQgbWF5IG5vdCBiZSB0aGUgb25l DQo+IHdpdGgNCj4gICAgICAgdGhlIGhpZ2hlc3QgYmxvY2sgbnVtYmVyLg0KPiANCj4g4oCcTWln aHQgbm904oCdIHdvdWxkIGJlIGxlc3MgYW1iaWd1b3VzIHRoYW4g4oCcbWF5IG5vdOKAnS4NCj4g DQoNCkZpeGVkLiBUaGFua3MuDQoNCg0KPiA2LiBTZWN0aW9uIDQuNCAoYWxzbyB0d28gcGxhY2Vz IGluIMKnNC4zKQ0KPiANCj4gKFRoaXMgY29tbWVudCByZWhhc2hlcywgaW4gbW9yZSBkZXRhaWws IHRoZSBkaWZmaWN1bHR5IGV4cGxhaW5lZCBpbg0KPiBteSBESVNDVVNTLg0KPiBZb3UgbWF5IHdh bnQgdG8gc2tpcCBvdmVyIGl0IHVudGlsIHdl4oCZdmUgcmVzb2x2ZWQgdGhlIERJU0NVU1MsIGFm dGVyDQo+IHdoaWNoIHRoaXMgbWF5LCBvciBtYXkgbm90LCBiZSByZWxldmFudC4pDQo+IA0KPiAg ICBUaGUgY2xpZW50IFNIT1VMRCB3YWl0IGZvciB1cCB0byBOT05fUkVDRUlWRV9USU1FT1VUIChT ZWN0aW9uIDcuMikNCj4gDQo+IEkgcmVhZCB0aGlzIGFzIG1lYW5pbmcgdGhlIGNsaWVudCBzaG91 bGQgd2FpdCBmb3IgYXMgbGl0dGxlIGFzIHplcm8sDQo+IG9yIGFzIGxvbmcgYXMgTk9OX1JFQ0VJ VkVfVElNRU9VVCDigJQgdGhhdOKAmXMgbXkgdW5kZXJzdGFuZGluZyBvZiDigJx1cA0KPiB0b+KA nS4gSXMgdGhhdCB0aGUgaW50ZW5kZWQgbWVhbmluZz8gSWYgaXQgaXMsIEkgdGhpbmsgaXTigJlz IHdvcnRoDQo+IHdyaXRpbmcgb3V0IGFzIEnigJl2ZSBkb25lLCBmb3IgY2xhcml0eS4gSWYgaXTi gJlzIG5vdCwgaXQgZGVmaW5pdGVseQ0KPiBuZWVkcyB0byBiZSBmaXhlZC4NCj4gDQo+IFRoZXJl 4oCZcyBhIHNpbWlsYXIgaXNzdWUgd2l0aCDigJx1cCB0byBOT05fUEFSVElBTF9USU1FT1VU4oCd IGxhdGVyIGluIHRoZQ0KPiBzZWN0aW9uLg0KPiANCj4gUmVmZXJyaW5nIGFoZWFkIHRvIFNlY3Rp b24gNy4yIG11ZGRpZXMgdGhlIHdhdGVycyBmdXJ0aGVyLiBFdmVuDQo+IHRob3VnaCB0aGUgdGV4 dCBxdW90ZWQgYWJvdmUgc2F5cyBOT05fUkVDRUlWRV9USU1FT1VUIGlzIGFuIHVwcGVyDQo+IGxp bWl0IG9uIGhvdyBsb25nIHRvIHdhaXQsDQo+IMKnNy4yIHNheXMgaXTigJlzIGEgbG93ZXIgbGlt aXQgaW5zdGVhZC4uLiBtYXliZT8gRnJvbSDCpzcuMjoNCj4gDQo+ICAgIE5PTl9SRUNFSVZFX1RJ TUVPVVQgaXMgdGhlIGluaXRpYWwgbWF4aW11bSB0aW1lIHRvIHdhaXQgZm9yIGENCj4gbWlzc2lu Zw0KPiANCj4g4oCcTWF4aW11beKAnSwgb2sgZ3JlYXQsIHRoYXQgbWVhbnMg4oCcdXBwZXIgYm91 bmTigJ0gYW5kIHNvIGxpbmVzIHVwIHdpdGgNCj4gwqc0LjQgYWx0aG91Z2ggdGhlIOKAnGluaXRp YWzigJ0gaXMgc3VycHJpc2luZyBzaW5jZSDCpzQuNCBkb2VzbuKAmXQgc2F5DQo+IGFueXRoaW5n IGFib3V0IHRoZSB1cHBlciBsaW1pdCBpbmNyZWFzaW5nLiBJdCBjb250aW51ZXM6DQo+IA0KPiAg ICBwYXlsb2FkIGJlZm9yZSByZXF1ZXN0aW5nIHJldHJhbnNtaXNzaW9uIGZvciB0aGUgZmlyc3Qg dGltZS4NCj4gRXZlcnkNCj4gICAgdGltZSB0aGUgbWlzc2luZyBwYXlsb2FkIGlzIHJlLXJlcXVl c3RlZCwgdGhlIHRpbWUgdG8gd2FpdCB2YWx1ZQ0KPiAgICBkb3VibGVzLiAgVGhlIHRpbWUgdG8g d2FpdCBpcyBjYWxjdWxhdGVkIGFzOg0KPiANCj4gICAgICAgVGltZS10by1XYWl0ID0gTk9OX1JF Q0VJVkVfVElNRU9VVCAqICgyICoqIChSZS1SZXF1ZXN0LUNvdW50IC0NCj4gMSkpDQo+IA0KPiBC dXQgdGhpcyBwYXJ0IHNheXMgaXTigJlzIChhKSBhbiBleGFjdCB0aW1lLXRvLXdhaXQsIG5vdCBh IOKAnG1heGltdW3igJ0sDQo+IGFuZCAoYikgaXQgc2F5cyBpdCBpbmNyZWFzZXMgZXhwb25lbnRp YWxseSwgc28gTk9OX1JFQ0VJVkVfVElNRU9VVA0KPiBpc27igJl0IGEgbWF4aW11bSBhdCBhbGws IGJ1dCBhIG1pbmltdW0uDQoNCkl0IGlzIGFuIGV4YWN0IHRpbWUgdG8gd2FpdCB3aGVuIHRoZXJl IGlzIG5vIHBhY2tldHMuIFdlIG1hZGUgdGhlc2UgY2hhbmdlczogDQoNCigxKQ0KT0xEOg0KICBU aGUgY2xpZW50IFNIT1VMRCB3YWl0IGZvciB1cCB0byBOT05fUkVDRUlWRV9USU1FT1VUIChTZWN0 aW9uIDcuMikNCg0KTkVXOiANCiAgVGhlIGNsaWVudCBTSE9VTEQgd2FpdCBmb3IgTk9OX1JFQ0VJ VkVfVElNRU9VVCAoU2VjdGlvbiA3LjIpDQoNCigyKQ0KDQpPTEQ6IA0KICAgcGF5bG9hZHMpIGZv ciB1cCB0byBOT05fUEFSVElBTF9USU1FT1VUIChTZWN0aW9uIDcuMikuDQoNCk5FVzogDQogICBw YXlsb2FkcykgZm9yIE5PTl9QQVJUSUFMX1RJTUVPVVQgKFNlY3Rpb24gNy4yKS4NCg0KDQo+IA0K PiBUaGlzIGxhdGVyIHRleHQgaW4gwqc3LjIgaW1wbGllcyB0aGF0IHBlcmhhcHMgdGhlIHByb2Js ZW0gaW4gdGhlIGFib3ZlDQo+IHBhc3NhZ2VzIGlzIHRoZSB3b3JkIOKAnG1heGltdW3igJ0sIGFu ZCBpdCBzaG91bGQgc2ltcGx5IGJlIGRlbGV0ZWQ6DQoNCkZhaXIgY29tbWVudC4gV2UgbWFkZSB0 aGVzZSBjaGFuZ2VzOiANCg0KKDEpDQpPTEQ6DQogIE5PTl9USU1FT1VUIGlzIHRoZSBtYXhpbXVt IHBlcmlvZCBvZiBkZWxheQ0KDQpORVc6DQogIE5PTl9USU1FT1VUIGlzIHRoZSBwZXJpb2Qgb2Yg ZGVsYXkNCg0KKDIpDQpPTEQ6DQogIE5PTl9SRUNFSVZFX1RJTUVPVVQgaXMgdGhlIGluaXRpYWwg bWF4aW11bSB0aW1lIHRvIHdhaXQNCg0KTkVXOg0KICBOT05fUkVDRUlWRV9USU1FT1VUIGlzIHRo ZSBpbml0aWFsIHRpbWUgdG8gd2FpdA0KDQo+IA0KPiAgICBGb3IgdGhlIHNlcnZlciByZWNlaXZp bmcgTk9OIFEtQmxvY2sxIHJlcXVlc3RzLCBpdCBTSE9VTEQgc2VuZA0KPiBiYWNrIGENCj4gICAg Mi4zMSAoQ29udGludWUpIFJlc3BvbnNlIENvZGUgb24gcmVjZWlwdCBvZiBhbGwgb2YgdGhlDQo+ IE1BWF9QQVlMT0FEUw0KPiAgICBwYXlsb2FkcyB0byBwcmV2ZW50IHRoZSBjbGllbnQgdW5uZWNl c3NhcmlseSBkZWxheWluZy4gIElmIG5vdCBhbGwNCj4gb2YNCj4gICAgdGhlIE1BWF9QQVlMT0FE UyBwYXlsb2FkcyB3ZXJlIHJlY2VpdmVkLCB0aGUgc2VydmVyIFNIT1VMRCBkZWxheQ0KPiBmb3IN Cj4gICAgTk9OX1JFQ0VJVkVfVElNRU9VVCAoZXhwb25lbnRpYWxseSBzY2FsZWQgYmFzZWQgb24g dGhlIHJlcGVhdA0KPiByZXF1ZXN0DQo+ICAgIGNvdW50IGZvciBhIHBheWxvYWQpIGJlZm9yZSBz ZW5kaW5nIHRoZSA0LjA4IChSZXF1ZXN0IEVudGl0eQ0KPiAgICBJbmNvbXBsZXRlKSBSZXNwb25z ZSBDb2RlIGZvciB0aGUgbWlzc2luZyBwYXlsb2FkKHMpLg0KPiANCj4gU2ltaWxhcmx5IOKAnHVw IHRv4oCdIGluIHRoZSBxdW90ZSB0aGF0IGJlZ2FuIHRoaXMgY29tbWVudCBzaG91bGQgYmUg4oCc YXQNCj4gbGVhc3TigJ0uDQoNCkZpeGVkIGFib3ZlIGJ5IGNvbXBsZXRlIHJlbW92YWwgb2YgInVw IHRvIi4NCg0KPiANCj4gV2hldGhlciB5b3UgYWRvcHQgdGhvc2Ugc3VnZ2VzdGlvbnMgb3Igbm90 LCAgaXQgc2VlbXMgYXMgdGhvdWdoIGFsbA0KPiB0aGlzIG5lZWRzIHRvIGJlIHJld3JpdHRlbiB3 aXRoIGNhcmVmdWwgYXR0ZW50aW9uIHRvIGNvbnZleWluZyB3aGF0DQo+IHRoZSBkZXNpcmVkIGJl aGF2aW9yIGlzLg0KPiANCj4gQnV0IHRoZSBwbG90IHRoaWNrZW5zLiBMYXRlciBpbiDCpzcuMiB3 ZSBoYXZlDQo+IA0KPiAgICBJdCBpcyBsaWtlbHkgdGhhdCB0aGUgY2xpZW50IHdpbGwgc3RhcnQg dHJhbnNtaXR0aW5nIHRoZSBuZXh0IHNldA0KPiBvZg0KPiAgICBNQVhfUEFZTE9BRFMgcGF5bG9h ZHMgYmVmb3JlIHRoZSBzZXJ2ZXIgdGltZXMgb3V0IG9uIHdhaXRpbmcgZm9yDQo+IHRoZQ0KPiAg ICBsYXN0IG9mIHRoZSBwcmV2aW91cyBNQVhfUEFZTE9BRFMgcGF5bG9hZHMuICBPbiByZWNlaXB0 IG9mIHRoZQ0KPiBmaXJzdA0KPiAgICBwYXlsb2FkIGZyb20gdGhlIG5ldyBzZXQgb2YgTUFYX1BB WUxPQURTIHBheWxvYWRzLCB0aGUgc2VydmVyDQo+IFNIT1VMRA0KPiAgICBzZW5kIGEgNC4wOCAo UmVxdWVzdCBFbnRpdHkgSW5jb21wbGV0ZSkgUmVzcG9uc2UgQ29kZSBpbmRpY2F0aW5nDQo+IGFu eQ0KPiAgICBtaXNzaW5nIHBheWxvYWRzIGZyb20gYW55IHByZXZpb3VzIE1BWF9QQVlMT0FEUyBw YXlsb2Fkcy4NCj4gDQo+IFRoZSBwb2ludCBiZWluZyB0aGF0IHRoZSByZXRyYW5zbWlzc2lvbiBy ZXF1ZXN0IGNhbiBiZSB0cmlnZ2VyZWQgYnkNCj4gYW4gZXZlbnQgb3RoZXIgdGhhbiB0aW1lciBl eHBpcmF0aW9uLiBTbyBpbiB0aGF0IHNlbnNlLCDigJxtYXhpbXVt4oCdIGlzDQo+IHJpZ2h0IOKA lCBpdCBwcm92aWRlcyBhbiB1cHBlciBib3VuZCBvbiBob3cgbG9uZyB0byB3YWl0IGJlZm9yZQ0K PiByZXF1ZXN0aW5nIGEgcmV0cmFuc21pc3Npb24g4oCUIGJ1dCBpbiBhbm90aGVyIHNlbnNlIGl0 4oCZcyB3cm9uZyBiZWNhdXNlDQo+IHRoZSBleHBvbmVudGlhbCBpbmNyZWFzZSBpcyBhcHBsaWVk IHRvIGl0LiBJIHRoaW5rIHRoZSB3b3JkIOKAnG1heGltdW3igJ0NCj4gaXMgdHJ5aW5nIHRvIGRv IHRvbyBtdWNoIHdvcmssIGFuZCBtb3JlIHdvcmRzIGFyZSBwcm9iYWJseSByZXF1aXJlZA0KPiBp biBvcmRlciB0byBtYWtlIHRoaXMgY2xlYXIuIEkgYWxzbyB0aGluayB0aGUgcHJvYmxlbSBpcyBl eGFjZXJiYXRlZA0KPiBieSB0aGUgZmFjdCBib3RoIMKnNC40IGFuZCDCpzcuMiBhcmUgdGFsa2lu ZyBub3JtYXRpdmVseSBhYm91dCBob3cgdG8NCj4gdXNlIE5PTl9SRUNFSVZFX1RJTUVPVVQuIEl0 IHNlZW1zIGFzIHRob3VnaCB0aGUgbWFpbiBkZXNjcmlwdGlvbiBpcw0KPiBmb3VuZCBpbiDCpzcu MiwgYW5kIHNvbWUgY29uZnVzaW9uIHdvdWxkIGJlIGF2b2lkZWQgYnkgbWFraW5nIMKnNC40DQo+ IGxlc3Mgc3BlY2lmaWMsIGFuZCBzaW1wbHkgcmVmZXJyaW5nIGZvcndhcmQgdG8gwqc3LjIuDQo+ IA0KDQpXZSBob3BlIHRoZSBjaGFuZ2VzIGFib3ZlIGNsYXJpZnkgdGhpcy4NCg0KPiBBbmQsIGFz IG5vdGVkIGluIG15IERJU0NVU1MsIGV4YW1wbGUgMTAuMi4zIG11ZGRpZXMgdGhlIHdhdGVycyBz dGlsbA0KPiBmdXJ0aGVyIHNpbmNlIGl0IGlsbHVzdHJhdGVzIHlldCBhbm90aGVyIGJlaGF2aW9y Lg0KPiANCj4gNy4gU2VjdGlvbiA0LjQNCj4gDQo+ICAgIFRoZSBjbGllbnQgU0hPVUxEIHdhaXQg Zm9yIHVwIHRvIE5PTl9SRUNFSVZFX1RJTUVPVVQgKFNlY3Rpb24gNy4yKQ0KPiAgICBhZnRlciB0 aGUgbGFzdCByZWNlaXZlZCBwYXlsb2FkIGZvciBOT04gcGF5bG9hZHMgYmVmb3JlIGlzc3Vpbmcg YQ0KPiAgICBHRVQsIFBPU1QsIFBVVCwgRkVUQ0gsIFBBVENILCBvciBpUEFUQ0ggcmVxdWVzdCB0 aGF0IGNvbnRhaW5zIG9uZQ0KPiBvcg0KPiAgICBtb3JlIFEtQmxvY2syIE9wdGlvbnMgdGhhdCBk ZWZpbmUgdGhlIG1pc3NpbmcgYmxvY2tzIHdpdGggdGhlIE0NCj4gYml0DQo+ICAgIHVuc2V0LiAg VGhlIGNsaWVudCBNQVkgc2V0IHRoZSBNIGJpdCB0byByZXF1ZXN0IHRoaXMgYW5kIGxhdGVyDQo+ IGJsb2Nrcw0KPiAgICBmcm9tIHRoaXMgTUFYX1BBWUxPQURTIHNldC4gIEZ1cnRoZXIgY29uc2lk ZXJhdGlvbnMgcmVsYXRlZCB0byB0aGUNCj4gICAgdHJhbnNtaXNzaW9uIHRpbWluZyBmb3IgbWlz c2luZyByZXF1ZXN0cyBhcmUgZGlzY3Vzc2VkIGluDQo+ICAgIFNlY3Rpb24gNy4yLg0KPiANCj4g SSBmaW5kIHRoaXMgd2hvbGUgcGFyYWdyYXBoIHByZXR0eSBjb25mdXNpbmcgd2l0aCB0aGUgZHVl bGluZyBTSE9VTEQNCj4gYW5kIE1BWSwgd2hlcmUgaXQgYXBwZWFycyB0aGUgU0hPVUxEIG1pZ2h0 IGJlIGRvaW5nIHR3byBqb2JzIGF0IG9uY2UuDQo+IEkgKnRoaW5rKiB5b3VyIGludGVudCBpcyBz b21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nPw0KPiANCj4g4oCcVGhlIGNsaWVudCBTSE9VTEQg d2FpdCBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiA3LjIgZm9yIE5PTiBwYXlsb2Fkcw0KPiBiZWZv cmUgcmVxdWVzdGluZyByZXRyYW5zbWlzc2lvbiBvZiBhbnkgbWlzc2luZyBibG9ja3MuDQo+IFJl dHJhbnNtaXNzaW9uIGlzIHJlcXVlc3RlZCBieSBpc3N1aW5nIGEgR0VULCBQT1NULCBQVVQsIEZF VENILA0KPiBQQVRDSCwgb3IgaVBBVENIIHJlcXVlc3QgdGhhdCBjb250YWlucyBvbmUgb3IgbW9y ZSBRLUJsb2NrMiBPcHRpb25zDQo+IHRoYXQgZGVmaW5lIHRoZSBtaXNzaW5nIGJsb2NrKHMpLiBH ZW5lcmFsbHkgdGhlIE0gYml0IG9uIHRoZSBRLUJsb2NrDQo+IG9wdGlvbihzKSBTSE9VTEQgYmUg dW5zZXQsIGFsdGhvdWdoIHRoZSBNIGJpdCBNQVkgYmUgc2V0IHRvIHJlcXVlc3QNCj4gdGhpcyBh bmQgbGF0ZXIgYmxvY2tzIGZyb20gdGhpcyBNQVhfUEFZTE9BRFMgc2V0LCBzZWUgU2VjdGlvbiAx MC4yLjQNCj4gZm9yIGFuIGV4YW1wbGUgb2YgdGhpcyBpbiBvcGVyYXRpb24u4oCdDQo+IA0KDQpU aGFua3MuIFdlIHdlbnQgd2l0aCB0aGlzIGNoYW5nZTogDQoNCiAgIEZvciBOT04gcGF5bG9hZHMs IHRoZSBjbGllbnQgU0hPVUxEIHdhaXQgTk9OX1JFQ0VJVkVfVElNRU9VVA0KICAgKFNlY3Rpb24g Ny4yKSBhZnRlciB0aGUgbGFzdCByZWNlaXZlZCBwYXlsb2FkIGJlZm9yZSByZXF1ZXN0aW5nDQog ICByZXRyYW5zbWlzc2lvbiBvZiBhbnkgbWlzc2luZyBibG9ja3MuICBSZXRyYW5zbWlzc2lvbiBp cyByZXF1ZXN0ZWQgYnkNCiAgIGlzc3VpbmcgYSBHRVQsIFBPU1QsIFBVVCwgRkVUQ0gsIFBBVENI LCBvciBpUEFUQ0ggcmVxdWVzdCB0aGF0DQogICBjb250YWlucyBvbmUgb3IgbW9yZSBRLUJsb2Nr MiBPcHRpb25zIHRoYXQgZGVmaW5lIHRoZSBtaXNzaW5nDQogICBibG9jayhzKS4gIEdlbmVyYWxs eSB0aGUgTSBiaXQgb24gdGhlIFEtQmxvY2syIE9wdGlvbihzKSBTSE9VTEQgYmUNCiAgIHVuc2V0 LCBhbHRob3VnaCB0aGUgTSBiaXQgTUFZIGJlIHNldCB0byByZXF1ZXN0IHRoaXMgYW5kIGxhdGVy IGJsb2Nrcw0KICAgZnJvbSB0aGlzIE1BWF9QQVlMT0FEUyBzZXQsIHNlZSBTZWN0aW9uIDEwLjIu NCBmb3IgYW4gZXhhbXBsZSBvZiB0aGlzDQogICBpbiBvcGVyYXRpb24uDQoNCg0KPiA4LiBTZWN0 aW9uIDUNCj4gDQo+ICAgIElmIHRoZSBzaXplIG9mIHRoZSA0LjA4IChSZXF1ZXN0IEVudGl0eSBJ bmNvbXBsZXRlKSByZXNwb25zZQ0KPiBwYWNrZXQNCj4gICAgaXMgbGFyZ2VyIHRoYW4gdGhhdCBk ZWZpbmVkIGJ5IFNlY3Rpb27CoDQuNiBbUkZDNzI1Ml0sIHRoZW4gdGhlDQo+IG51bWJlcg0KPiAg ICBvZiBtaXNzaW5nIGJsb2NrcyBNVVNUIGJlIGxpbWl0ZWQgc28gdGhhdCB0aGUgcmVzcG9uc2Ug Y2FuIGZpdA0KPiBpbnRvIGENCj4gICAgc2luZ2xlIHBhY2tldC4gIElmIHRoaXMgaXMgdGhlIGNh c2UsIHRoZW4gdGhlIHNlcnZlciBjYW4gc2VuZA0KPiANCj4gU3VnZ2VzdGlvbjog4oCcdGhlbiB0 aGUgbnVtYmVyIG9mIG1pc3NpbmcgYmxvY2tzIHJlcG9ydGVkIE1VU1QuLi7igJ0gKFRoZQ0KPiB0 aGluZyBiZWluZyBsaW1pdGVkIGlzIG5vdCB0aGUgYWN0dWFsIG51bWJlciBvZiBtaXNzaW5nIGJs b2Nrcy4NCj4gWW914oCZcmUgbGltaXRpbmcgdGhlIG51bWJlciB5b3UgcmVwb3J0IG9uLikNCg0K QWdyZWUuIEZpeGVkLiANCg0KPiANCj4gOS4gU2VjdGlvbiA3LjENCj4gDQo+ICAgIEl0IGlzIGlt cGxlbWVudGF0aW9uIHNwZWNpZmljIGFzIHRvIHdoZXRoZXIgdGhlcmUgc2hvdWxkIGJlIGFueQ0K PiAgICBmdXJ0aGVyIHJlcXVlc3RzIGZvciBtaXNzaW5nIGRhdGEgYXMgdGhlcmUgd2lsbCBoYXZl IGJlZW4NCj4gc2lnbmlmaWNhbnQNCj4gICAgdHJhbnNtaXNzaW9uIGZhaWx1cmUgYXMgaW5kaXZp ZHVhbCBwYXlsb2FkcyB3aWxsIGhhdmUgZmFpbGVkIGFmdGVyDQo+ICAgIE1BWF9UUkFOU01JVF9T UEFOLg0KPiANCj4gVGhpcyBwYXJhZ3JhcGggc2VlbXMgYXMgdGhvdWdoIGl04oCZcyBhIG5vbi1z ZXF1aXR1ci4gSXQganVzdCBkb2VzbuKAmXQNCj4gbWFrZSBzZW5zZSB0byBtZS4gOi0oDQo+IA0K DQpDaGFuZ2VkIHRvOg0KDQogICBGb2xsb3dpbmcgdGhlIGZhaWx1cmUgdG8gdHJhbnNtaXQgYSBw YWNrZXQgZHVlIHRvIHBhY2tldCBsb3NzIGFmdGVyDQogICBNQVhfVFJBTlNNSVRfU1BBTiB0aW1l IChTZWN0aW9uIDQuOC4yIG9mIFtSRkM3MjUyXSksIHdoZXRoZXIgdGhlcmUNCiAgIHNob3VsZCBi ZSBhbnkgZnVydGhlciByZXF1ZXN0cyBmb3IgbWlzc2luZyBkYXRhIGlzIGltcGxlbWVudGF0aW9u DQogICBzcGVjaWZpYy4NCg0KDQo+IDEwLiBTZWN0aW9uIDcuMg0KPiANCj4gKFRoaXMgY29tbWVu dCByZWxhdGVzIHRvIHRoZSBkaWZmaWN1bHR5IGV4cGxhaW5lZCBpbiBteSBESVNDVVNTLiBZb3UN Cj4gbWF5IHdhbnQgdG8gc2tpcCBvdmVyIGl0IHVudGlsIHdl4oCZdmUgcmVzb2x2ZWQgdGhlIERJ U0NVU1MsIGFmdGVyDQo+IHdoaWNoIHRoaXMgbWF5LCBvciBtYXkgbm90LCBiZSByZWxldmFudC4p DQo+IA0KPiAgICBOT05fVElNRU9VVCBpcyB0aGUgbWF4aW11bSBwZXJpb2Qgb2YgZGVsYXkgYmV0 d2VlbiBzZW5kaW5nIHNldHMgb2YNCj4gICAgTUFYX1BBWUxPQURTIHBheWxvYWRzIGZvciB0aGUg c2FtZSBib2R5LiAgQnkgZGVmYXVsdCwgTk9OX1RJTUVPVVQNCj4gaGFzDQo+ICAgIHRoZSBzYW1l IHZhbHVlIGFzIEFDS19USU1FT1VUIChTZWN0aW9uwqA0Ljggb2YgW1JGQzcyNTJdKS4NCj4gDQo+ IFByZXN1bWFibHkgdGhlIHVzZSBvZiDigJxtYXhpbXVt4oCdIG1lYW5zIGl04oCZcyBmaW5lIHRv IGRlbGF5IHplcm8gc2Vjb25kcw0KPiAob3IgYW55IHZhbHVlIGxvd2VyIHRoYW4gTk9OX1RJTUVP VVQpLg0KDQoibWF4aW11bSIgaGFzIGJlZW4gZGVsZXRlZCBhcyBwZXIgcHJldmlvdXMgY29tbWVu dHMsIHRodXMgaW1wbHlpbmcgYW4gZXhhY3QgbWF0Y2guDQoNCj4gDQo+IDExLiBHZW5lcmFsDQo+ IA0KPiBCeSB0aGUgd2F5LCBub25lIG9mIHRoZSB0aW1lcnMgc3BlY2lmeSBqaXR0ZXIgKGFuZCBp bmRlZWQsIGlmIHJlYWQNCj4gbGl0ZXJhbGx5LCBqaXR0ZXIgd291bGQgYmUgZm9yYmlkZGVuKS4g SXMgdGhpcyBpbnRlbnRpb25hbD8NCg0KTm8gKy8tIHRvbGVyYW5jZXMgaGF2ZSBiZWVuIGRlZmlu ZWQuIFdoZW4gYSB0aW1lciBleHBpcmVzLCB0aGVuIHRoZSBuZXh0IGFjdGlvbiB0YWtlcyBwbGFj ZS4NCg0KPiANCj4gMTIuIFNlY3Rpb24gNy4yDQo+IA0KPiAgICBJZiB0aGUgQ29BUCBwZWVyIHJl cG9ydHMgYXQgbGVhc3Qgb25lIHBheWxvYWQgaGFzIG5vdCBhcnJpdmVkIGZvcg0KPiAgICBlYWNo IGJvZHkgZm9yIGF0IGxlYXN0IGEgMjQgaG91ciBwZXJpb2QgYW5kIGl0IGlzIGtub3duIHRoYXQg dGhlcmUNCj4gICAgYXJlIG5vIG90aGVyIG5ldHdvcmsgaXNzdWVzIG92ZXIgdGhhdCBwZXJpb2Qs IHRoZW4gdGhlIHZhbHVlIG9mDQo+ICAgIE1BWF9QQVlMT0FEUyBjYW4gYmUgcmVkdWNlZCBieSAx IGF0IGEgdGltZSAodG8gYSBtaW5pbXVtIG9mIDEpIGFuZA0KPiAgICB0aGUgc2l0dWF0aW9uIHJl LWV2YWx1YXRlZCBmb3IgYW5vdGhlciAyNCBob3VyIHBlcmlvZCB1bnRpbCB0aGVyZQ0KPiBpcw0K PiAgICBubyByZXBvcnQgb2YgbWlzc2luZyBwYXlsb2FkcyB1bmRlciBub3JtYWwgb3BlcmF0aW5n IGNvbmRpdGlvbnMuDQo+IFRoZQ0KPiAgICBuZXdseSBkZXJpdmVkIHZhbHVlIGZvciBNQVhfUEFZ TE9BRFMgc2hvdWxkIGJlIHVzZWQgZm9yIGJvdGggZW5kcw0KPiBvZg0KPiAgICB0aGlzIHBhcnRp Y3VsYXIgQ29BUCBwZWVyIGxpbmsuICBOb3RlIHRoYXQgdGhlIENvQVAgcGVlciB3aWxsIG5vdA0K PiAgICBrbm93IGFib3V0IHRoZSBNQVhfUEFZTE9BRFMgY2hhbmdlIHVudGlsIGl0IGlzIHJlY29u ZmlndXJlZC4gIEFzIGENCj4gICAgY29uc2VxdWVuY2Ugb2YgdGhlIHR3byBwZWVycyBoYXZpbmcg ZGlmZmVyZW50IE1BWF9QQVlMT0FEUyB2YWx1ZXMsDQo+IGENCj4gICAgcGVlciBtYXkgY29udGlu dWUgaW5kaWNhdGUgdGhhdCB0aGVyZSBhcmUgc29tZSBtaXNzaW5nIHBheWxvYWRzIGFzDQo+ICAg IGFsbCBvZiBpdHMgTUFYX1BBWUxPQURTIHNldCBtYXkgbm90IGhhdmUgYXJyaXZlZC4gIEhvdyB0 aGUgdHdvDQo+IHBlZXINCj4gICAgdmFsdWVzIGZvciBNQVhfUEFZTE9BRFMgYXJlIHN5bmNocm9u aXplZCBpcyBvdXQgb2YgdGhlIHNjb3BlLg0KPiANCj4gSSB0YWtlIGl0IHRoaXMgaXMganVzdCB0 aHJvd24gaW4gaGVyZSBhcyBhbiBvcGVyYXRpb25hbCBzdWdnZXN0aW9uPw0KPiBJdOKAmXMgbm90 IHNwZWNpZnlpbmcgcHJvdG9jb2wsIHJpZ2h0PyBJdCBzZWVtcyBhIGxpdHRsZSBtaXNwbGFjZWQs IGlmDQo+IHNvLg0KDQpUaGlzIGlzIGEgZ3VpZGFuY2UgdG8gYWRqdXN0IHRoZSBtYXhfcGF5bG9h ZHMgdG8gYXZvaWQgbG9zc2VzIHVuZGVyIG5vcm1hbCBjb25kaXRpb25zLiAgDQoNCj4gDQo+IDEz LiBTZWN0aW9uIDEwLjEuMw0KPiANCj4gKFRoaXMgY29tbWVudCByZWxhdGVzIHRvIHRoZSBhc2lk ZSBpbiBteSBESVNDVVNTLiBZb3UgbWF5IHdhbnQgdG8NCj4gc2tpcCBvdmVyIGl0IHVudGlsIHdl 4oCZdmUgcmVzb2x2ZWQgdGhlIERJU0NVU1MsIGFmdGVyIHdoaWNoIHRoaXMgbWF5LA0KPiBvciBt YXkgbm90LCBiZQ0KPiByZWxldmFudC4pDQo+IA0KPiBXaHkgZG9lc27igJl0IHRoZSBzZXJ2ZXIg cmVxdWVzdCAxLDksMTAgaW4gb25lIGdvPyBTaW5jZSBpdHMgcnhtdA0KPiByZXF1ZXN0IGlzIHRy aWdnZXJlZCBieSByeCBvZiAxMSwgb25lIHdvdWxkIHRoaW5rIGl0IGNvdWxkIGluZmVyIDEwDQo+ IGhhZCBiZWVuIGxvc3QuDQoNCkJlY2F1c2Ugb25seSB0aGUgbWlzc2luZyBibG9ja3Mgb2YgdGhl IHByZXZpb3VzIHNldCBhcmUgaW5jbHVkZWQgYW5kIHRoZXJlIG1heSBoYXZlIGJlZW4gc29tZSBw YWNrZXQgYXJyaXZhbCByZS1vcmRlcmluZyBmb3IgMTAgYW5kIDExLg0KDQogICBPbiByZWNlaXB0 IG9mIGEgcGF5bG9hZA0KICAgZnJvbSB0aGUgbmV3IHNldCBvZiBNQVhfUEFZTE9BRFMgcGF5bG9h ZHMsIHRoZSBzZXJ2ZXIgU0hPVUxEIHNlbmQgYQ0KICAgNC4wOCAoUmVxdWVzdCBFbnRpdHkgSW5j b21wbGV0ZSkgUmVzcG9uc2UgQ29kZSBpbmRpY2F0aW5nIGFueSBtaXNzaW5nDQogICBwYXlsb2Fk cyBmcm9tIGFueSBwcmV2aW91cyBNQVhfUEFZTE9BRFMgcGF5bG9hZHMuICBVcG9uIHJlY2VpcHQg b2YNCiAgIHRoZSA0LjA4IChSZXF1ZXN0IEVudGl0eSBJbmNvbXBsZXRlKSBSZXNwb25zZSBDb2Rl LCB0aGUgY2xpZW50IFNIT1VMRA0KICAgc2VuZCB0aGUgbWlzc2luZyBwYXlsb2FkcyBiZWZvcmUg Y29udGludWluZyB0byBzZW5kIHRoZSByZW1haW5kZXIgb2YNCiAgIHRoZSBNQVhfUEFZTE9BRFMg cGF5bG9hZHMgYW5kIHRoZW4gZ28gaW50byBhbm90aGVyIE5PTl9USU1FT1VUIGRlbGF5DQogICBw cmlvciB0byBzZW5kaW5nIHRoZSBuZXh0IHNldCBvZiBwYXlsb2Fkcy4NCg0KPiANCj4gMTQuIFNl Y3Rpb24gMTAuMS40IChhbHNvIDEwLjMuMykNCj4gDQo+IChUaGlzIGNvbW1lbnQgcmVsYXRlcyB0 byB0aGUgYXNpZGUgaW4gbXkgRElTQ1VTUy4gWW91IG1heSB3YW50IHRvDQo+IHNraXAgb3ZlciBp dCB1bnRpbCB3ZeKAmXZlIHJlc29sdmVkIHRoZSBESVNDVVNTLCBhZnRlciB3aGljaCB0aGlzIG1h eSwNCj4gb3IgbWF5IG5vdCwgYmUNCj4gcmVsZXZhbnQuKQ0KPiANCj4gV2h5IGRvZXNu4oCZdCBy ZWNlcHRpb24gb2YgYSBtZXNzYWdlIHdpdGggTW9yZT0wIHRyaWdnZXIgdGhlIHNlcnZlciB0bw0K PiByZXF1ZXN0IHJldHJhbnNtaXNzaW9uIG9mIHRoZSBtaXNzaW5nIGJsb2NrPyBXaHkgZG9lcyBp dCBoYXZlIHRvIHdhaXQNCj4gZm9yIHRpbWVvdXQ/DQoNClRoaXMgaXMgdG8gY292ZXIgb24tcGF0 aCByZW9yZGVyaW5nIGlzc3Vlcy4gSXQgd2FzIGRlY2lkZWQgbm90IHRvIGludHJvZHVjZSBhbm90 aGVyIHRpbWVvdXQgdG8gYmUgc3VyZSBhbGwgdGhlIHJlLW9yZGVyZWQgcGFja2V0cyBoYWQgYXJy aXZlZC4gDQoNCj4gDQo+IDE1LiBTZWN0aW9uIDEwLjIuMw0KPiANCj4gKFRoaXMgY29tbWVudCBy ZWxhdGVzIHRvIG15IERJU0NVU1MuIFlvdSBtYXkgd2FudCB0byBza2lwIG92ZXIgaXQNCj4gdW50 aWwgd2XigJl2ZSByZXNvbHZlZCB0aGUgRElTQ1VTUywgYWZ0ZXIgd2hpY2ggdGhpcyBtYXksIG9y IG1heSBub3QsDQo+IGJlIHJlbGV2YW50LikNCj4gDQo+IFdoeSBkb2VzbuKAmXQgcmVjZXB0aW9u IG9mIFFCMjoxMC8wLzEwMjQgdHJpZ2dlciB0aGUgY2xpZW50IHRvIHJlcXVlc3QNCj4gcmV0cmFu c21pc3Npb24/IFdoeSBkb2VzIGl0IGhhdmUgdG8gd2FpdCBmb3IgdGltZW91dD8NCg0KVGhpcyBp cyBmaXhlZCBhcyBwZXIgYSBzaW1pbGFyIGNvbW1lbnQgZnJvbSBCZW46DQoNCk9MRDoNCiAgICAg ICBbW05PTl9USU1FT1VUIChzZXJ2ZXIpIGRlbGF5IGV4cGlyZXNdXQ0KICAgICAgICAgIHwgICAg IFtbU2VydmVyIHNlbmRzIG5leHQgc2V0IG9mIHBheWxvYWRzXV0NCiAgICAgICAgICB8PC0tLS0t LS0tLSsgTk9OIDIuMDUgTToweGFiIFQ6MHhmMCBPOjEyMzYgRVQ9MjMgUUIyOjEwLzAvMTAyNA0K ICAgICAgICAgIHwgICAuLi4gICAgfA0KICAgICAgIFtbTk9OX1JFQ0VJVkVfVElNRU9VVCAoY2xp ZW50KSBkZWxheSBleHBpcmVzXV0NCiAgICAgICAgICB8ICAgICBbW0NsaWVudCByZWFsaXplcyBi bG9ja3MgYXJlIG1pc3NpbmcgYW5kIGFza3MgZm9yIHRoZQ0KICAgICAgICAgIHwgICAgICAgbWlz c2luZyBvbmVzIGluIG9uZSBnb11dDQogICAgICAgICAgKy0tLS0tLS0tLT58IE5PTiBHRVQgL3Bh dGggTToweDA0IFQ6MHhmMyBRQjI6MS8wLzEwMjRcDQogICAgICAgICAgfCAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBRQjI6OS8wLzEwMjQNCiAgICAgICAgICB8ICAgICBY PC0tLSsgTk9OIDIuMDUgTToweGFjIFQ6MHhmMyBFVD0yMyBRQjI6MS8xLzEwMjQgDQoNCk5FVzoN CiAgICAgICBbW05PTl9USU1FT1VUIChzZXJ2ZXIpIGRlbGF5IGV4cGlyZXNdXQ0KICAgICAgICAg IHwgICAgIFtbU2VydmVyIHNlbmRzIG5leHQgc2V0IG9mIHBheWxvYWRzXV0NCiAgICAgICAgICB8 PC0tLS0tLS0tLSsgTk9OIDIuMDUgTToweGFiIFQ6MHhmMCBPOjEyMzYgRVQ9MjMgUUIyOjEwLzAv MTAyNA0KICAgICAgICAgIHwgICAgIFtbT24gc2VlaW5nIGEgcGF5bG9hZCBmcm9tIHRoZSBuZXh0 IHNldCBvZiBwYXlsb2FkcywgDQogICAgICAgICAgfCAgICAgIENsaWVudCByZWFsaXplcyBibG9j a3MgYXJlIG1pc3NpbmcgYW5kIGFza3MgZm9yIHRoZQ0KICAgICAgICAgIHwgICAgICAgbWlzc2lu ZyBvbmVzIGluIG9uZSBnb11dDQogICAgICAgICAgKy0tLS0tLS0tLT58IE5PTiBHRVQgL3BhdGgg TToweDA0IFQ6MHhmMyBRQjI6MS8wLzEwMjRcDQogICAgICAgICAgfCAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBRQjI6OS8wLzEwMjQNCiAgICAgICAgICB8ICAgICBYPC0t LSsgTk9OIDIuMDUgTToweGFjIFQ6MHhmMyBFVD0yMyBRQjI6MS8xLzEwMjQNCg0KDQogU2ltaWxh cmx5DQo+IHJlY2VwdGlvbiBvZg0KPiBRQjI6OS8xLzEwMjQgbGF0ZXIgaW4gdGhlIGV4YW1wbGUu DQo+IA0KDQpUaGVyZSBoYXMgdG8gYmUgYSBkZWxheSBoZXJlIGJlY2F1c2Ugb2YgdGhlIHBvdGVu dGlhbCBvZiBwYWNrZXQgcmUtb3JkZXJpbmcgYXJyaXZhbC4NCg0KPiAxNi4gU2VjdGlvbiAxMC4y LjQNCj4gDQo+IFNpbmNlIE1BWF9QQVlMT0FEUyBpcyAxMCwgd2h5IGRvZXMgdGhlIGV4YW1wbGUg c2F5IOKAnE1BWF9QQVlMT0FEUyBoYXMNCj4gYmVlbiByZWFjaGVk4oCdIGFmdGVyIHBheWxvYWRz IDItOSBoYXZlIGJlZW4gcmV0cmFuc21pdHRlZD8gVGhhdOKAmXMgb25seQ0KPiA4IHBheWxvYWRz Lg0KPiANCg0KTUFYX1BBWUxPQURTIGlzIG5vdCBhIHNsaWRpbmcgd2luZG93LiBJdCBpcyBhIHNw ZWNpZmljIHNldCBvZiBibG9ja3MsIGJsb2NrcyAjMCAtICM5IChwYXlsb2FkcyAxIHRvIDEwKSBp biB0aGlzIGNhc2UsIHRoZW4gYmxvY2tzICMxMCAtICMxOSBhbmQgc28gb24uIA0KCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3Ig cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4K VGhhbmsgeW91LgoK From nobody Fri May 7 05:50: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 3B2653A1FF1; Fri, 7 May 2021 05:50:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-core-new-block@ietf.org, core-chairs@ietf.org, core@ietf.org, marco.tiloca@ri.se, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <162039183121.15574.16597240090409070575@ietfa.amsl.com> Date: Fri, 07 May 2021 05:50:31 -0700 Archived-At: Subject: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and 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, 07 May 2021 12:50:31 -0000 Lars Eggert has entered the following ballot position for draft-ietf-core-new-block-11: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [Updating this DISCUSS based on the discussion during the May 6 telechat.] Section 1, paragraph 4, discuss: > There is a requirement for these blocks of data to be transmitted at > higher rates under network conditions where there may be asymmetrical > transient packet loss (i.e., responses may get dropped). An example > is when a network is subject to a Distributed Denial of Service > (DDoS) attack and there is a need for DDoS mitigation agents relying > upon CoAP to communicate with each other (e.g., > [RFC8782][I-D.ietf-dots-telemetry]). As a reminder, [RFC7959] I understand that COAP was initially chosen to transport DOTS signaling messages due to their small size, support for structured messages and request/response semantics, as well as the ability to function over lossy paths such as found in IoT deployment, which COAP is architected for. DOTS now seems to desire to transport larger messages, and this document extends CORE to enable this functionality. However, this CORE extension seems to solely focus on Internet deployment scenarios, essentially attempting to re-architect COAP into a general Internet transport protocol for transmission over paths with high loss rates. It's questionable whether "maintenance of RFC7959" part of the current CORE charter covers this document. The motivation for this new extension is apparently that RFC7959 doesn't result in sufficient performance for the DOTS use case, i.e., timely delivery of larger amounts of data during periods of high random loss (i.e., under DDoS). This is a fundamentally hard problem, because in order to deliver data in a timely manner in such scenarios, the sender needs to be very aggressive, to send enough packets into the network so that enough arrive at the receiver to make steady progress; and at the same time the feedback channel is also severely degraded due to loss. The IETF TSV area currently has hence no known good solution for such use cases. This specification possibly describes such a solution, but I was not able to find any evaluation results that would show that this proposed mechanism actually delivers the desired performance improvements over RFC7959 in the scenarios of interest. I was also not able to find any evaluation results of whether the proposed mechanism is safe to use in situations that might be easily confused with DDoS, such as high-load scenarios that are not of malicious origin, or if it even is safe when executing over normal Internet paths. If such evaluation results exists, would you mind pointing me at them? Without evaluation results that demonstrate that the proposed mechanism is effective and safe, I do not believe it should be published on the Standards Track. It could go forward as an Experimental RFC, supporting an experiment to perform such an evaluation. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools, so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 1, paragraph 3, nit: > ell in environments where there are no or minimal packet losses. These optio > ^^ Did you mean "now" (=at this moment) instead of 'no' (negation)? Section 3, paragraph 16, nit: > ed by the peer whether the body comprises of a single or multiple payloads a > ^^^^^^^^^^^^ Did you mean "comprises" or "consists of"? Section 4.1, paragraph 18, nit: > T be included as Inner options. Similarly there MUST NOT be a mix of Q-Block > ^^^^^^^^^ Did you forget a comma after a conjunctive/linking adverb? Section 4.3, paragraph 3, nit: > -Tag value MUST be the same for all of the requests for the body of data tha > ^^^^^^^^^^ Consider using "all the". Section 4.3, paragraph 3, nit: > ue, the server still treats it as opaque but the client MUST ensure that it i > ^^^^^^ Use a comma before 'but' if it connects two independent clauses (unless they are closely connected and short). Section 4.3, paragraph 6, nit: > not arrived after a timeout and a retransmit missing payloads response is n > ^^^^^^^^^^^^ After 'a', do not use a verb. Make sure that the spelling of 'retransmit' is correct. If 'retransmit' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 4.3, paragraph 6, nit: > a timeout and a retransmit missing payloads response is needed. For reliabl > ^^^^^^^^ An apostrophe may be missing. Section 4.3, paragraph 11, nit: > g. The client should then release all of the tokens used for this body. Note > ^^^^^^^^^^ Consider using "all the". Section 4.3, paragraph 13, nit: > t. The client should then release all of the tokens used for this body. 2 > ^^^^^^^^^^ Consider using "all the". Section 4.3, paragraph 15, nit: > quest. The client should then release all of the tokens used for this body. > ^^^^^^^^^^ Consider using "all the". Section 4.3, paragraph 18, nit: > The client should then release all of the tokens used for this body unless > ^^^^^^^^^^ Consider using "all the". Section 4.3, paragraph 20, nit: > e Code can be used to indicate that all of the blocks up to and including th > ^^^^^^^^^^ Consider using "all the". Section 4.3, paragraph 30, nit: > ing-blocks+cbor-seq" indicates that some of the payloads are missing and need > ^^^^^^^^^^^ If the text is a generality, 'of the' is not necessary. Section 4.4, paragraph 4, nit: > a request for that block and for all of the remaining blocks in the current > ^^^^^^^^^^^^^^^^ Consider using "all the". Section 4.4, paragraph 7, nit: > paque, the client still treats it as opaque but the server MUST ensure that i > ^^^^^^ Use a comma before 'but' if it connects two independent clauses (unless they are closely connected and short). Section 4.4, paragraph 16, nit: > , the client should then release all of the tokens used for this body unless > ^^^^^^^^^^ Consider using "all the". Section 4.5, paragraph 1, nit: > r a request that uses Q-Block1, the Observe value [RFC7641] MUST be the same > ^^^^^^^^^^^ After 'the', do not use a verb. Make sure that the spelling of 'Observe' is correct. If 'Observe' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 4.5, paragraph 2, nit: > a response that uses Q-Block2, the Observe value MUST be the same for all t > ^^^^^^^^^^^ After 'the', do not use a verb. Make sure that the spelling of 'Observe' is correct. If 'Observe' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 4.5, paragraph 3, nit: > ferent from Block2 usage where the Observe value is only present in the firs > ^^^^^^^^^^^ After 'the', do not use a verb. Make sure that the spelling of 'Observe' is correct. If 'Observe' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 5, paragraph 2, nit: > that the server has not received all of the blocks of the request body that > ^^^^^^^^^^ Consider using "all the". Section 5, paragraph 4, nit: > as a CBOR Sequence [RFC8742]. It comprises of one or more missing block numb > ^^^^^^^^^^^^ Did you mean "comprises" or "consists of"? Section 5, paragraph 6, nit: > sing blocks is as follows: ; A notional array, the elements of which > ^ Loose punctuation mark. Section 7.1, paragraph 2, nit: > It is implementation specific as to whether there should be any further req > ^^^^^^^^^^^^^ Consider shortening this phrase to just "whether", or rephrase the sentence to avoid "as to". Section 7.2, paragraph 9, nit: > D consider the body stale, remove any body, and release Tokens and Request-T > ^^^^^^^^ Did you mean "anybody"? Section 7.2, paragraph 10, nit: > limit the potential wait needed calculated when using PROBING_WAIT. NON_PROB > ^^^^^^^^^^ "needed calculated" is only accepted in certain dialects. For something more widely acceptable, consider "to be calculated". Section 7.2, paragraph 14, nit: > G_WAIT. Note: For the particular DOTS application, PROBING_RATE and other > ^^^^ An apostrophe may be missing. Section 7.2, paragraph 15, nit: > s. Even when not negotiated, the DOTS application uses customized defaults as > ^^^^ An apostrophe may be missing. Section 7.2, paragraph 19, nit: > rived for each body for at least a 24 hour period and it is known that there > ^^^^^^^ When a number forms part of an adjectival compound, use a hyphen: "24-hour" Section 7.2, paragraph 19, nit: > each body for at least a 24 hour period and it is known that there are no ot > ^^^^^^^^^^ Use a comma before 'and' if it connects two independent clauses (unless they are closely connected and short). Section 7.2, paragraph 19, nit: > situation re-evaluated for another 24 hour period until there is no report > ^^^^^^^ It appears that a hyphen is missing. Section 7.2, paragraph 19, nit: > PAYLOADS values, a peer may continue indicate that there are some missing pa > ^^^^^^^^^^^^^^^^^ Probably a preposition is missing after 'continue'. Section 7.2, paragraph 22, nit: > tinue) Response Code on receipt of all of the MAX_PAYLOADS payloads to preven > ^^^^^^^^^^ Consider using "all the". Section 7.2, paragraph 22, nit: > t unnecessarily delaying. If not all of the MAX_PAYLOADS payloads were receiv > ^^^^^^^^^^^^^ Consider using "all the". Section 7.2, paragraph 24, nit: > xt set of payloads on receipt of all of the MAX_PAYLOADS payloads to prevent > ^^^^^^^^^^ Consider using "all the". Section 7.2, paragraph 24, nit: > e server unnecessarily delaying. Otherwise the client SHOULD delay for NON_R > ^^^^^^^^^ Did you forget a comma after a conjunctive/linking adverb? Section 10.1.3, paragraph 5, nit: > - Tag by matching the token with the sent request. CoAP CoAP > ^^^^ Did you mean "scent"? Section 10.2, paragraph 2, nit: > n is not required for Q-Block2; the observe detail can thus be ignored. 10.2 > ^^^^^^^^^^^ After 'the', do not use a verb. Make sure that the spelling of 'observe' is correct. If 'observe' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 10.2.1, paragraph 2, nit: > The same process is repeated when an Observe is triggered, but no loss is ex > ^^^^^^^^^^ After 'an', do not use a verb. Make sure that the spelling of 'Observe' is correct. If 'Observe' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 10.2.3, paragraph 1, nit: > y Figure 10 shows the example of an Observe that is triggered but for which s > ^^^^^^^^^^ After 'an', do not use a verb. Make sure that the spelling of 'Observe' is correct. If 'Observe' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 10.2.4, paragraph 1, nit: > t Figure 11 shows the example of an Observe that is triggered but only the fi > ^^^^^^^^^^ After 'an', do not use a verb. Make sure that the spelling of 'Observe' is correct. If 'Observe' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English. Section 10.3.3, paragraph 5, nit: > t-Tag by matching the token with the sent request. CoAP CoAP C > ^^^^ Did you mean "scent"? Section 12.3, paragraph 3, nit: > blocks+cbor-seq o Encoding: - o Id: TBA3 o Reference: [RFCXXXX] Th > ^^ Possible spelling mistake found Section 13.2, paragraph 4, nit: > try] Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c., > ^ Add a space between sentences Section 13.2, paragraph 9, nit: > org/info/rfc8610>. [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P > ^ Add a space between sentences "A.1.", paragraph 7, nit: > It is up to the implementation as to whether the application process stops t > ^^^^^^^^^^^^^ Consider shortening this phrase to just "whether", or rephrase the sentence to avoid "as to". "A.2.", paragraph 4, nit: > It is up to the implementation as to whether the application process stops t > ^^^^^^^^^^^^^ Consider shortening this phrase to just "whether", or rephrase the sentence to avoid "as to". "B.1.", paragraph 1, nit: > use of Q-Block1 Option with a reliable transport as shown in Figure 20. Ther > ^^^^^^^^^^^^^^^^^^^^^^^ Uncountable nouns are usually not used with an indefinite article. Use simply "reliable transport". "B.1.", paragraph 2, nit: > shown in Figure 20. There is no acknowledgment of packets at the CoAP layer, > ^^^^^^^^^^^^^^ Do not mix variants of the same word ('acknowledgment' and 'acknowledgement') within a single text. "B.2.", paragraph 1, nit: > of the use of Q-Block2 Option with a reliable transport is shown in Figure > ^^^^^^^^^^^^^^^^^^^^ Uncountable nouns are usually not used with an indefinite article. Use simply "reliable transport". Document references draft-ietf-core-echo-request-tag-11, but draft-ietf-core-echo-request-tag-12 is the latest available revision. From nobody Fri May 7 06:56: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 757C43A2280; Fri, 7 May 2021 06:56:10 -0700 (PDT) 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=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 nce0wg6mGRca; Fri, 7 May 2021 06:56:05 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (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 16CE53A227C; Fri, 7 May 2021 06:56:04 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar27.francetelecom.fr (ESMTP service) with ESMTPS id 4FcBmy1g6Wz2y81; Fri, 7 May 2021 15:56:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620395762; bh=cjzPUKYtbQng5cJaCINn2eTV/p4p2Rx0EsonoT+L7zs=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=cIHIh+09YGChO6fvT/m72+Pca9yoSA2lENVhC8FDTob+Q30YMNzBx3OaKpEYA/dcw VuIVeXZ1RgoBZsYvxh59YtPNo3HhAtczaNltfE2gWJvfZmcfYEj4Muk04NSlM/jnLy nlH8fEzFREogqM8lKqKR/3HjtCh6di8GzTKnsxRRGu5upK6AXGj0ZNzkF0AAaoHaYs MmH452auBc4T0J/hEGpd/5yuwU0W9Ku8g6PMsJmx8qv7gM42vyDyYuF8PwVoAafBoT nxs4KKvWliCWHgIrHMmjiGEJ9laqzhBujta5GnCdk6i/qRBD6sw1sORnRBr2VaHfVC NfWtD6Nc5sIIw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4FcBmx759WzCqkf; Fri, 7 May 2021 15:56:01 +0200 (CEST) From: To: Lars Eggert , The IESG CC: "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXQz+Tx85/LIwI7Ee6i4xXZSbinKrYAPxQ Date: Fri, 7 May 2021 13:56:00 +0000 Message-ID: <29803_1620395762_609546F2_29803_68_1_787AE7BB302AE849A7480A190F8B9330353787B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162039183121.15574.16597240090409070575@ietfa.amsl.com> In-Reply-To: <162039183121.15574.16597240090409070575@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (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, 07 May 2021 13:56:11 -0000 SGkgTGFycywgDQoNClBsZWFzZSBzZWUgaW5saW5lLiANCg0KQ2hlZXJzLA0KSm9uICYgTWVkDQoN Cj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IExhcnMgRWdnZXJ0IHZpYSBE YXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+IEVudm95w6nCoDogdmVuZHJl ZGkgNyBtYWkgMjAyMSAxNDo1MQ0KPiDDgMKgOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4g Q2PCoDogZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZzsgY29yZS1jaGFpcnNAaWV0 Zi5vcmc7DQo+IGNvcmVAaWV0Zi5vcmc7IG1hcmNvLnRpbG9jYUByaS5zZTsgbWFyY28udGlsb2Nh QHJpLnNlDQo+IE9iamV0wqA6IExhcnMgRWdnZXJ0J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWNv cmUtbmV3LWJsb2NrLTExOiAod2l0aA0KPiBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gTGFy cyBFZ2dlcnQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ IGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMTE6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9u ZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFs bA0KPiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZl ZWwgZnJlZSB0byBjdXQNCj4gdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikN Cj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0 ZW1lbnQvZGlzY3Vzcy0NCj4gY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1l bnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6 DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS1uZXct YmxvY2svDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtDQo+IERJU0NVU1M6DQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiAtDQo+IA0KPiBbVXBkYXRpbmcgdGhpcyBESVNDVVNTIGJhc2VkIG9uIHRo ZSBkaXNjdXNzaW9uIGR1cmluZyB0aGUgTWF5IDYNCj4gdGVsZWNoYXQuXQ0KPiANCj4gU2VjdGlv biAxLCBwYXJhZ3JhcGggNCwgZGlzY3VzczoNCj4gPiAgICBUaGVyZSBpcyBhIHJlcXVpcmVtZW50 IGZvciB0aGVzZSBibG9ja3Mgb2YgZGF0YSB0byBiZQ0KPiB0cmFuc21pdHRlZCBhdA0KPiA+ICAg IGhpZ2hlciByYXRlcyB1bmRlciBuZXR3b3JrIGNvbmRpdGlvbnMgd2hlcmUgdGhlcmUgbWF5IGJl DQo+IGFzeW1tZXRyaWNhbA0KPiA+ICAgIHRyYW5zaWVudCBwYWNrZXQgbG9zcyAoaS5lLiwgcmVz cG9uc2VzIG1heSBnZXQgZHJvcHBlZCkuICBBbg0KPiBleGFtcGxlDQo+ID4gICAgaXMgd2hlbiBh IG5ldHdvcmsgaXMgc3ViamVjdCB0byBhIERpc3RyaWJ1dGVkIERlbmlhbCBvZiBTZXJ2aWNlDQo+ ID4gICAgKEREb1MpIGF0dGFjayBhbmQgdGhlcmUgaXMgYSBuZWVkIGZvciBERG9TIG1pdGlnYXRp b24gYWdlbnRzDQo+IHJlbHlpbmcNCj4gPiAgICB1cG9uIENvQVAgdG8gY29tbXVuaWNhdGUgd2l0 aCBlYWNoIG90aGVyIChlLmcuLA0KPiA+ICAgIFtSRkM4NzgyXVtJLUQuaWV0Zi1kb3RzLXRlbGVt ZXRyeV0pLiAgQXMgYSByZW1pbmRlciwgW1JGQzc5NTldDQo+IA0KPiBJIHVuZGVyc3RhbmQgdGhh dCBDT0FQIHdhcyBpbml0aWFsbHkgY2hvc2VuIHRvIHRyYW5zcG9ydCBET1RTDQo+IHNpZ25hbGlu ZyBtZXNzYWdlcyBkdWUgdG8gdGhlaXIgc21hbGwgc2l6ZSwgc3VwcG9ydCBmb3Igc3RydWN0dXJl ZA0KPiBtZXNzYWdlcyBhbmQgcmVxdWVzdC9yZXNwb25zZSBzZW1hbnRpY3MsIGFzIHdlbGwgYXMg dGhlIGFiaWxpdHkgdG8NCj4gZnVuY3Rpb24gb3ZlciBsb3NzeSBwYXRocyBzdWNoIGFzIGZvdW5k IGluIElvVCBkZXBsb3ltZW50LCB3aGljaCBDT0FQDQo+IGlzIGFyY2hpdGVjdGVkIGZvci4NCj4g DQo+IERPVFMgbm93IHNlZW1zIHRvIGRlc2lyZSB0byB0cmFuc3BvcnQgbGFyZ2VyIG1lc3NhZ2Vz LCBhbmQgdGhpcw0KPiBkb2N1bWVudCBleHRlbmRzIENPUkUgdG8gZW5hYmxlIHRoaXMgZnVuY3Rp b25hbGl0eS4gSG93ZXZlciwgdGhpcw0KPiBDT1JFIGV4dGVuc2lvbiBzZWVtcyB0byBzb2xlbHkg Zm9jdXMgb24gSW50ZXJuZXQgZGVwbG95bWVudA0KPiBzY2VuYXJpb3MsIGVzc2VudGlhbGx5IGF0 dGVtcHRpbmcgdG8gcmUtYXJjaGl0ZWN0IENPQVAgaW50byBhIGdlbmVyYWwNCj4gSW50ZXJuZXQg dHJhbnNwb3J0IHByb3RvY29sIGZvciB0cmFuc21pc3Npb24gb3ZlciBwYXRocyB3aXRoIGhpZ2gN Cj4gbG9zcyByYXRlcy4gSXQncyBxdWVzdGlvbmFibGUgd2hldGhlciAibWFpbnRlbmFuY2Ugb2Yg UkZDNzk1OSIgcGFydA0KPiBvZiB0aGUgY3VycmVudCBDT1JFIGNoYXJ0ZXIgY292ZXJzIHRoaXMg ZG9jdW1lbnQuDQo+IA0KPiBUaGUgbW90aXZhdGlvbiBmb3IgdGhpcyBuZXcgZXh0ZW5zaW9uIGlz IGFwcGFyZW50bHkgdGhhdCBSRkM3OTU5DQo+IGRvZXNuJ3QgcmVzdWx0IGluIHN1ZmZpY2llbnQg cGVyZm9ybWFuY2UgZm9yIHRoZSBET1RTIHVzZSBjYXNlLA0KDQpBY3R1YWxseSwgdGhlIG1vdGl2 YXRpb24gaXMgdGhlIGxhY2sgb2Ygc3VwcG9ydCBvZiBibG9jay13aXNlIGZvciBOT04gbWVzc2Fn ZXMuIFRoaXMgaXMgZXhwbGljaXRseSBpbmRpY2F0ZWQgaW4gdGhlIGludHJvZHVjdGlvbjoNCg0K ICAgQXMgYSByZW1pbmRlciwgW1JGQzc5NTldDQogICByZWNvbW1lbmRzIHRoZSB1c2Ugb2YgQ29u ZmlybWFibGUgKENPTikgcmVzcG9uc2VzIHRvIGhhbmRsZSBwb3RlbnRpYWwNCiAgIHBhY2tldCBs b3NzLiAgSG93ZXZlciwgc3VjaCBhIHJlY29tbWVuZGF0aW9uIGRvZXMgbm90IHdvcmsgd2l0aCBh DQogICBmbG9vZGVkIHBpcGUgRERvUyBzaXR1YXRpb24uDQoNCkZXSVcsIGhlcmUgaXMgdGhlIGZ1 bGwgYmFja2dyb3VuZDoNCg0KKDEpDQoNClJGQzcyNTIgc3VwcG9ydHMgdHdvIGNvbW11bmljYXRp b24gdHlwZXMgb2YgcmVxdWVzdCBpbiB0aGUgcmVxdWVzdC9yZXNwb25zZSBtb2RlbCBhcyBpbiBy ZmM3MjUyI3NlY3Rpb24tMS4yOiBDb25maXJtYWJsZSBNZXNzYWdlIGFuZCBOb24tY29uZmlybWFi bGUgTWVzc2FnZS4NCg0KKDIpDQoNCkNvQVAgaW1wb3NlcyBhIGxpbWl0YXRpb24gb24gdGhlIGRh dGEgdHJhbnNtaXNzaW9uIHNpemUgYXMgaW4gcmZjNzI1MiNzZWN0aW9uLTQuNg0KDQogICBBIENv QVAgbWVzc2FnZSwgYXBwcm9wcmlhdGVseSBlbmNhcHN1bGF0ZWQsIFNIT1VMRCBmaXQgd2l0aGlu IGENCiAgIHNpbmdsZSBJUCBwYWNrZXQgKGkuZS4sIGF2b2lkIElQIGZyYWdtZW50YXRpb24pIGFu ZCAoYnkgZml0dGluZyBpbnRvDQogICBvbmUgVURQIHBheWxvYWQpIG9idmlvdXNseSBuZWVkcyB0 byBmaXQgd2l0aGluIGEgc2luZ2xlIElQIGRhdGFncmFtLg0KDQooMykNCg0KU28gdGhlbiBSRkM3 OTU5IGNhbWUgYWJvdXQgdG8gaGFuZGxlIHNpbmdsZSBwYWNrZXQgbGltaXRhdGlvbnMgYnkgYWRk aW5nIGluICdibG9jaycgc3VwcG9ydC4gSG93ZXZlciwgaXQgaXMgZGVzaWduZWQgdG8gd29yayB3 aXRoIENvbmZpcm1hYmxlLCByZWNvZ25pemluZyB0aGUgbGltaXRhdGlvbnMgb2YgTm9uLWNvbmZp cm1hYmxlIGFzIGluIHJmYzc5NTkjc2VjdGlvbi0xDQoNCiAgICBUaGUgcHJlc2VudA0KICAgc3Bl Y2lmaWNhdGlvbiBtaW5pbWl6ZXMgdGhlIGNvbnN0cmFpbnRzIGl0IGFkZHMgdG8gdGhvc2UgYmFz ZQ0KICAgZXhjaGFuZ2VzOyBob3dldmVyLCBub3QgYWxsIHZhcmlhbnRzIG9mIHVzaW5nIENvQVAg YXJlIHZlcnkgdXNlZnVsDQogICBpbnNpZGUgYSBibG9jay13aXNlIHRyYW5zZmVyIChlLmcuLCB1 c2luZyBOb24tY29uZmlybWFibGUgcmVxdWVzdHMNCiAgIHdpdGhpbiBibG9jay13aXNlIHRyYW5z ZmVycyBvdXRzaWRlIHRoZSB1c2UgY2FzZSBvZiBTZWN0aW9uIDIuOCB3b3VsZA0KICAgZXNjYWxh dGUgdGhlIG92ZXJhbGwgbm9uLWRlbGl2ZXJ5IHByb2JhYmlsaXR5KS4NCg0KKDQpDQoNCmRyYWZ0 LWlldGYtY29yZS1uZXctYmxvY2sgcHJvdmlkZXMgYSBtaXNzaW5nIHBpZWNlIG9mIFJGQzc5NTks IG5hbWVseSB0aGUgc3VwcG9ydCBvZiBibG9jay13aXNlIHRyYW5zZmVyIHVzaW5nIE5vbi1jb25m aXJtYWJsZSB3aGVyZSBhbiBlbnRpcmUgYm9keSBvZiBkYXRhIGNhbiBiZSB0cmFuc21pdHRlZCB3 aXRob3V0IHRoZSByZXF1aXJlbWVudCBmb3IgYW4gYWNrbm93bGVkZ2VtZW50Lg0KDQooNSkNCg0K TGlrZSA3OTU5LCBkcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrIGRvZXMgbm90IHJlbW92ZSBhbnkg b2YgdGhlIGNvbnN0cmFpbnRzIHBvc2VkIGJ5IHRoZSBiYXNlIENvQVAgc3BlY2lmaWNhdGlvbi4N Cg0KSXQganVzdCAnaGFwcGVucycgdGhhdCB0aGVyZSBhcmUgYWRkaXRpb25hbCB0cmFuc21pc3Np b24gcmF0ZSBiZW5lZml0cyAoc3ViamVjdCB0byBjb25nZXN0aW9uIGNvbnRyb2wpIHdoZW4gdXNp bmcgZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay4NCg0KV2UgdXBkYXRlZCB0aGUgaW50cm9kdWN0 aW9uIHRvIGNsYXJpZnkgdGhpcyBiYWNrZ3JvdW5kLiBQbGVhc2UgY2hlY2s6IGh0dHBzOi8vdGlu eXVybC5jb20vbmV3LWJsb2NrLWxhdGVzdCANCg0KRG9lcyB0aGlzIGNsYXJpZnkgeW91ciBjb25j ZXJuPw0KDQogaS5lLiwNCj4gdGltZWx5IGRlbGl2ZXJ5IG9mIGxhcmdlciBhbW91bnRzIG9mIGRh dGEgZHVyaW5nIHBlcmlvZHMgb2YgaGlnaA0KPiByYW5kb20gbG9zcyAoaS5lLiwgdW5kZXIgRERv UykuIFRoaXMgaXMgYSBmdW5kYW1lbnRhbGx5IGhhcmQgcHJvYmxlbSwNCj4gYmVjYXVzZSBpbiBv cmRlciB0byBkZWxpdmVyIGRhdGEgaW4gYSB0aW1lbHkgbWFubmVyIGluIHN1Y2gNCj4gc2NlbmFy aW9zLCB0aGUgc2VuZGVyIG5lZWRzIHRvIGJlIHZlcnkgYWdncmVzc2l2ZSwgdG8gc2VuZCBlbm91 Z2gNCj4gcGFja2V0cyBpbnRvIHRoZSBuZXR3b3JrIHNvIHRoYXQgZW5vdWdoIGFycml2ZSBhdCB0 aGUgcmVjZWl2ZXIgdG8NCj4gbWFrZSBzdGVhZHkgcHJvZ3Jlc3M7IGFuZCBhdCB0aGUgc2FtZSB0 aW1lIHRoZSBmZWVkYmFjayBjaGFubmVsIGlzDQo+IGFsc28gc2V2ZXJlbHkgZGVncmFkZWQgZHVl IHRvIGxvc3MuDQo+IA0KPiBUaGUgSUVURiBUU1YgYXJlYSBjdXJyZW50bHkgaGFzIGhlbmNlIG5v IGtub3duIGdvb2Qgc29sdXRpb24gZm9yIHN1Y2gNCj4gdXNlIGNhc2VzLg0KPiBUaGlzIHNwZWNp ZmljYXRpb24gcG9zc2libHkgZGVzY3JpYmVzIHN1Y2ggYSBzb2x1dGlvbiwgYnV0IEkgd2FzIG5v dA0KPiBhYmxlIHRvIGZpbmQgYW55IGV2YWx1YXRpb24gcmVzdWx0cyB0aGF0IHdvdWxkIHNob3cg dGhhdCB0aGlzDQo+IHByb3Bvc2VkIG1lY2hhbmlzbSBhY3R1YWxseSBkZWxpdmVycyB0aGUgZGVz aXJlZCBwZXJmb3JtYW5jZQ0KPiBpbXByb3ZlbWVudHMgb3ZlciBSRkM3OTU5IGluIHRoZSBzY2Vu YXJpb3Mgb2YgaW50ZXJlc3QuIEkgd2FzIGFsc28NCj4gbm90IGFibGUgdG8gZmluZCBhbnkgZXZh bHVhdGlvbiByZXN1bHRzIG9mIHdoZXRoZXIgdGhlIHByb3Bvc2VkDQo+IG1lY2hhbmlzbSBpcyBz YWZlIHRvIHVzZSBpbiBzaXR1YXRpb25zIHRoYXQgbWlnaHQgYmUgZWFzaWx5IGNvbmZ1c2VkDQo+ IHdpdGggRERvUywgc3VjaCBhcyBoaWdoLWxvYWQgc2NlbmFyaW9zIHRoYXQgYXJlIG5vdCBvZiBt YWxpY2lvdXMNCj4gb3JpZ2luLCBvciBpZiBpdCBldmVuIGlzIHNhZmUgd2hlbiBleGVjdXRpbmcg b3ZlciBub3JtYWwgSW50ZXJuZXQNCj4gcGF0aHMuDQo+IA0KPiBJZiBzdWNoIGV2YWx1YXRpb24g cmVzdWx0cyBleGlzdHMsIHdvdWxkIHlvdSBtaW5kIHBvaW50aW5nIG1lIGF0DQo+IHRoZW0/DQoN ClRoZXJlIGlzIG5vdCBldmFsdWF0aW9uIHBhcGVyLCBidXQgYXMgc3RhdGVkIGluIHRoZSB0aHJl YWQgd2l0aCBFcmljIFYuLCBleHRlbnNpdmUgdGVzdHMgd2VyZSBtYWRlIHRoYXQgY29uZmlybWVk IHRoZSBiZW5lZml0cy4gVGhlIGNvZGUgZ2l2aW5nIFEtQmxvY2sgc3VwcG9ydCBpcyBvdXQgdGhl cmUgaW4gdGhlIHB1YmxpYyBkb21haW4uIEEgcG9pbnRlciBpcyBpbmNsdWRlZCBpbiB0aGUgd3Jp dGUtdXAuIA0KDQo+IA0KPiBXaXRob3V0IGV2YWx1YXRpb24gcmVzdWx0cyB0aGF0IGRlbW9uc3Ry YXRlIHRoYXQgdGhlIHByb3Bvc2VkDQo+IG1lY2hhbmlzbSBpcyBlZmZlY3RpdmUgYW5kIHNhZmUs IEkgZG8gbm90IGJlbGlldmUgaXQgc2hvdWxkIGJlDQo+IHB1Ymxpc2hlZCBvbiB0aGUgU3RhbmRh cmRzIFRyYWNrLiBJdCBjb3VsZCBnbyBmb3J3YXJkIGFzIGFuDQo+IEV4cGVyaW1lbnRhbCBSRkMs IHN1cHBvcnRpbmcgYW4gZXhwZXJpbWVudCB0byBwZXJmb3JtIHN1Y2ggYW4NCj4gZXZhbHVhdGlv bi4NCj4gDQo+IA0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRl dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJv bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Fri May 7 07:03: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 05D783A22F8; Fri, 7 May 2021 07:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_BLOCKED=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 (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yW61wHzFQyr; Fri, 7 May 2021 07:03:32 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 2F29B3A22CD; Fri, 7 May 2021 07:03:26 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:b856:e449:5fc8:1058]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 90EBD600355; Fri, 7 May 2021 17:03:16 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1620396196; bh=g6fmkQ84YVI44jLAlzwet5HxWdzcyn4z/GNEB0CuADI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=mTHV3zttWZAI5XI79p39ivJtN2h3LdQ+ad5hL2arYSKy9pWoNs2Jto+rlqru1V0FY ZgRjM5sgtn4I69vkarZlISiG4FqsABhl84wdazV4y8YcW4ctcrC4Iz7dTNfE9k7GfV BvfKsGWO0PGry70Q2UqciUcKU3cTvjE0I7WooUtc= From: Lars Eggert Message-Id: <666D5FF1-9E96-4522-A0FB-0A3042225BE7@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_297D5ED4-CA3D-4B62-BABC-37135C0FEA5C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Fri, 7 May 2021 17:03:16 +0300 In-Reply-To: <29803_1620395762_609546F2_29803_68_1_787AE7BB302AE849A7480A190F8B9330353787B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Cc: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" To: mohamed.boucadair@orange.com References: <162039183121.15574.16597240090409070575@ietfa.amsl.com> <29803_1620395762_609546F2_29803_68_1_787AE7BB302AE849A7480A190F8B9330353787B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-MailScanner-ID: 90EBD600355.A2DE9 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (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, 07 May 2021 14:03:43 -0000 --Apple-Mail=_297D5ED4-CA3D-4B62-BABC-37135C0FEA5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-5-7, at 16:56, mohamed.boucadair@orange.com wrote: > There is not evaluation paper, but as stated in the thread with Eric = V., extensive tests were made that confirmed the benefits. The code = giving Q-Block support is out there in the public domain. A pointer is = included in the write-up. is there any public information about the methodology and results for = these extensive tests? I understand there is no paper, but is there a = presentation or anything else? Thanks, Lars --Apple-Mail=_297D5ED4-CA3D-4B62-BABC-37135C0FEA5C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmCVSKQACgkQVLXDCb9w wVeFCg/8CPto9M722oDjU4qCG6aoYfL6Pdx/LJk2LpLiwjj4rjfLK033RNeeqLjp gx+O5vv38iKH1kJGMPD8XgRVFiEII5bCIqJyADXr2/I0RblrIwkTtXoV3vX+jfgx +Up86Ot1HTPU9Re9cFB4F6HpDx9MGjHjigWN1qyvHKfi6Dlz8/vGIbnZzq67sZuR x+oUjIjrGw6Ux9biVoQOHRaUP9ulOPphwZLqF5iqW3vlXk+tkvnaURL+vYE8s3GA 1tarScfjmdSPG8+LOk8uEmAT3t3lT/jqcuOU8ILVlRAqRw009j00I9by8dChPRbb VxmJ04CWH3W0BnQDlkYVX8sCG9GpJPcf1mjQmg/Xoa4BOGSTdXP7B7AJlBaHeS06 cJotzukMZrcdX/6IGObforeHkwd0hGBYlPN6vNBDaiGGVxSh5zxOScjIcB0iebbL tg1d4YJdoZISDjYUP1IPjyui5lI1ysl/Qf4d4YJi0RNgyQh83byg9wgRTs0uGhmT at/+es4qGBBd7eK5w46Uk8w9zjqbXLHGAnAVCqswOkwodxbFrqJBN+aGyyTyYe5J ioS/X8N4koAhL/K5aVnUD2vyHTTl8wcMPq6mngx0y/PfzVQqx44R6JJ3cDRmczl9 UZVlFTrejzpf/814iARJ2n5kdNMr8xj4WaPzYjANmvKMQjAzOGI= =2zgl -----END PGP SIGNATURE----- --Apple-Mail=_297D5ED4-CA3D-4B62-BABC-37135C0FEA5C-- From nobody Fri May 7 10:59:37 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 854433A2C23; Fri, 7 May 2021 10:59:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162041037547.22240.17644800648647728159@ietfa.amsl.com> Date: Fri, 07 May 2021 10:59:35 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-href-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: Fri, 07 May 2021 17:59:36 -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 Resource Identifiers Authors : Klaus Hartke Carsten Bormann Filename : draft-ietf-core-href-04.txt Pages : 15 Date : 2021-05-07 Abstract: The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that serializes the URI components in Concise Binary Object Representation (CBOR) instead of a sequence of characters. This simplifies parsing, comparison and reference resolution in environments with severe limitations on processing power, code size, and memory size. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-href/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-href-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-href-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 Sun May 9 12:47:05 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 548D43A1D15; Sun, 9 May 2021 12:47:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162058962328.30942.5334997688634398011@ietfa.amsl.com> Date: Sun, 09 May 2021 12:47:03 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-versions-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: Sun, 09 May 2021 19:47:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : SenML Features and Versions Author : Carsten Bormann Filename : draft-ietf-core-senml-versions-03.txt Pages : 7 Date : 2021-05-09 Abstract: This short document updates RFC 8428, Sensor Measurement Lists (SenML), by specifying the use of independently selectable "SenML Features" and mapping them to SenML version numbers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-senml-versions-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-versions-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 Sun May 9 12:52: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 D81BE3A1D62; Sun, 9 May 2021 12:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0ugxhYsn9wE; Sun, 9 May 2021 12:52:01 -0700 (PDT) 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 386203A1D5E; Sun, 9 May 2021 12:52:01 -0700 (PDT) Received: from [192.168.217.118] (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (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 4FdZZk0BpmzymM; Sun, 9 May 2021 21:51:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) From: Carsten Bormann In-Reply-To: <162006820882.8146.574742678195359661@ietfa.amsl.com> Date: Sun, 9 May 2021 21:51:57 +0200 Cc: gen-art@ietf.org, core@ietf.org, draft-ietf-core-senml-versions.all@ietf.org, last-call@ietf.org X-Mao-Original-Outgoing-Id: 642282717.514873-4ca94560db0b827ddb32b763c4b2be40 Content-Transfer-Encoding: quoted-printable Message-Id: References: <162006820882.8146.574742678195359661@ietfa.amsl.com> To: Elwyn Davies X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-senml-versions-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2021 19:52:06 -0000 Hi Elwyn, I finally got around to process your review. I have submitted a new version -03 based on this review. I could make direct use of your text suggestions, but did edit them a = little. So you may want to have another look at the second paragraph of 1 = (introduction) and the new section 2.2, which address your main points. https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ https://www.ietf.org/archive/id/draft-ietf-core-senml-versions-03.html https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-versions-03.txt That was a great, thoughtful review. Thanks again! CoRE WG: Please also check the above documents and diffs! Gr=C3=BC=C3=9Fe, Carsten > On 2021-05-03, at 20:56, Elwyn Davies via Datatracker = wrote: >=20 > Reviewer: Elwyn Davies > Review result: Almost Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-core-senml-versions-02 > Reviewer: Elwyn Davies > Review Date: 2021-05-03 > IETF LC End Date: 2021-05-03 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Almost ready. There is one issue that needs to be sorted = out. This > document removes the ordering relationship between the values of = version.. > Section 4.4 of RFC 8428 relies on that ordering relationahip. = Accordingly > there needs to be explicit new text for Section 4.4 in this document. = Also the > concept of 'must understand' items is used in this document but is not > explicitly defined in RFC 8428. This needs to be fixed - which could = happen in > the new version of Setion 4.4. >=20 > Major issues: > None >=20 > Minor issues: >=20 > The redefinition of version means that this document should contain an = explicit > update of (at least) paragraph 3 of Section 4.4 of RFC 8428, That = section > assumes that there is an ordering relationship between version field = values > which is invalidated by this document. >=20 > Also the concept of 'must understand' fields is supposed to be = explained in > that section as well as discussed in s2.1 of this document. That term = is not > explicitly used in RFC 8428 but I take it that it is supposed to refer = to field > names ending wth an underscore character ('_'). This should be fixed = with a > rewrite of s4.4 of RFC 8428. >=20 > Nits/editorial comments: >=20 > General: The RFC Editor preferes the US convention for quoting items = using > exclusively singe quote rather than double quote marks. >=20 > s1, para 2: I found this paragraph difficult to parse, especially the = second > sentence. Here is an alternative suggestion. OLD: The traditional = idea of > using a version number for evolving an interchange format presupposes = a linear > progression of that format. A more likely form of evolution of SenML = is the > addition of independently selectable _features_ that can be added to = the base > version (version 10) in a fashion that these are mostly independent of = each > other. A recipient of a SenML pack can check the features it = implements against > those required by the pack, processing the pack only if all required = features > are provided in the implementation. NEW: The traditional idea of using = a > version number to indicate the evolution of an interchage format = generally > assmes an incremental progression of the version number as the format = develops > over time. However in the case of SenML it is expected that the likely > evolution mechanism will be for independently selectable capabiity = _features_ > to be added to the basic system indicated by 'version' 10. To support = this > model, this document repurposes the single version number accompanying = a pack > of SenML records so that it is interpreted as a bitmap indicating the = set of > features a recipient would need to have implemented to be able to = process the > pack. ENDS >=20 > s2: Personally I would have used the left shift operator rather then = 2^fc but > that is a personal view. >=20 > s2,1, para 2: s/lower-most bit positions Section 3./least significant = bit > positions for the base version as described in Section 3./ >=20 > s2.1, para 2: s/Section 4/by the feature defined in Section 4/ >=20 > s2.1, para 2: 'boutique' is slang: s/boutique/less generally = applicable/ >=20 > s3: s/already/effectively already/ >=20 > s6: I am not we really care but are feature names case sensitve? >=20 >=20 >=20 From nobody Mon May 10 00:06: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 191D43A0931 for ; Mon, 10 May 2021 00:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6tsQlTrV417 for ; Mon, 10 May 2021 00:06:23 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80082.outbound.protection.outlook.com [40.107.8.82]) (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 4DEFD3A0927 for ; Mon, 10 May 2021 00:06:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=If+YKB/P/+pVasobapTz4JYTixSvZnP2K0In4R22f+wpGea8VqN0ae6ncGDYDtGg8qcesxOWzlfmEHxVsUa+wWVPH4Sv7FECRKsdW4CUsSo5Jq5j4frM4khtm3+rUJ8HEhSeAblRpeopmOsA3A/6BXyNr3mbH20BIMT9cqW8oKExcGF+1nYDC2gnUDId4qDtCWjgqj4ckylPdGRQ021fAy/PQRlM/imgI9QcxthRbRapveP3rY8BmYlHEzrjB2W4lUUeNRRivLEB8PfuzRccVPkoLVKsguibQFDSZ21y9BHCX5gFWAhNzy9igRy/BDF/PErqT0Qu4+1Ub3sDpygQUw== 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=5T3622uyFHqgcE+Ax1fDjc+N/AvkeqT7dCrkn7lDg6w=; b=I2Ih/jRNLRahpT9w+jK67JiodTqrnoAlbZiYKvITZN0Aa+jQmykNMldTt/cUpSFZLO5pU81ft+QEvLNGJfja2i+51OFRvwzWpgtkZToSxzQEHlHqMjly/F22qKwBVQuXItgYMeyWiOa8DGWA4JO062gmx3TCSQHLp5+qwRLTNCBqdio3Gx+LJ1Q7aZf3L8vIZ1Lapdj3nhFkX5Emi7/njy5769/owWTOuRgWl4hJ0xzLHJOWIdNINY99x4hzCYt2+fxArqN7PF/gI8lJu1uvUJhmIo0ibBUx38AUE67nTVoIWqsppovYH6bUz9J4HOMjBig0Spz4MfOGV3Y+LijGRw== 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=5T3622uyFHqgcE+Ax1fDjc+N/AvkeqT7dCrkn7lDg6w=; b=EDvmZd2KQAmSaI9wywKvTgIXSKhq6yLmO9PzboYWFmImri1xx/jB0WOXHK3WqX4GXR4c3HPELQ46p/fQTzFGHglZne48Cf1IkhjVbzf7E43HXMQIQGpDWKuJxGfcwS7UvKGtfisLdzh0WDVu8OVeSS9Pd6MLLvwTSwxKgbfbRMI= 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 DB8P189MB1093.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:163::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.26; Mon, 10 May 2021 07:06:20 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::6918:90f9:e9c4:d3b3]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::6918:90f9:e9c4:d3b3%3]) with mapi id 15.20.4108.031; Mon, 10 May 2021 07:06:20 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: <83073aeb-c1c4-7c17-4a77-aae5d989c81d@ri.se> Date: Mon, 10 May 2021 09:06:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TsfyPojf0Vi2ABo8a2nbtiAE4PqWYai5b" X-Originating-IP: [84.17.36.156] X-ClientProxiedBy: HE1PR05CA0322.eurprd05.prod.outlook.com (2603:10a6:7:92::17) 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.5] (84.17.36.156) by HE1PR05CA0322.eurprd05.prod.outlook.com (2603:10a6:7:92::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.24 via Frontend Transport; Mon, 10 May 2021 07:06:19 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d13038f2-16ad-4d08-110b-08d913821ca2 X-MS-TrafficTypeDiagnostic: DB8P189MB1093: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2150; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZNmgkpHV5MkA070lyDChcDbcl6vyUY3SxauWSdJ+XQvwGSiHRYsVlJEAbHP3zvgZ22mjgMHEdq8UDIccn9AhXQTyJekMKsYZq2QDuRUzRzHE/fvcONJVvoidxulx/4znqMhnUY/kffDnd+kKQjvgHFppyozyfcy2LHpxufrqZv56Rfp9VbT0H+hE/Tc8HOVFRxIX5Ia+u2XLOHEQVuc1FdYg8h/j5Vy8b4MYPpGLfBVvJe6IyOtMM48YKzqPG8LYFVRzbxI3n8kQ3UvKi7XDpWG7e1/TPVeZlci5zN2CmMc49c6JdQzt00qnGL80e7d5Fp2j+Wy3U+rQuKaDnGBMqxIDWTuppuv8wEfBsus7uq7Lhr6qoF1T9RhfGUIBton69s2fQdpFUSmYKQo7+R256KAAtDLlx8dZjeqFE1JhhuqmrrbTuwBDjO5mSo1Ek3H3r0n8RqXhc9OgArJO86LxyTXLE5FkHFngaP1xVJHuQQDYYQG0FZEbXt29m6ch0I5qzTVWDF5dRhbElKHBM0WBx0ZwUHCIqDMsO2bLbYYOhMTx8WXBGp5iuAKfMiAeHEoUZUWjJEuPP9ehPVEFL8d4/AnTYOYJGp8y0iRcOuSQnSBqcegQW2U2qXLK5NohrYexyChQrFFD0JT+/jBulx1DpX3LpapHm4PO9f0f1f4ZhMiO5wqzYXardsMfBuE6LlzA0YwsYdHIBQYNQ6Ou2AQbTnRNZrgmCVULIO/m7NxGgkFB9ATcXyVSg7M8r2a8An0acdoHlr0Wnd//qKtzmn/kflsqKV2lEYZCSDJXb1Tn4JQ= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(39850400004)(346002)(366004)(396003)(136003)(8936002)(83380400001)(16576012)(6916009)(6486002)(8676002)(316002)(31696002)(26005)(186003)(16526019)(966005)(478600001)(33964004)(52116002)(66574015)(86362001)(2906002)(66946007)(235185007)(31686004)(5660300002)(36756003)(21480400003)(38100700002)(956004)(44832011)(66476007)(2616005)(38350700002)(66556008)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?V01TWnpydkZCT1h0VUJyN1JrSXAvL1RObkcvbC9ra2tGZ2JTbnhtY05naFhr?= =?utf-8?B?bVZPWDB5M1VvWlk1MHpPSDJVbGQvbHVObUdxU2REOGcyWnllTUp6TkhxRkhq?= =?utf-8?B?aFRYVlVmRG0zaG5lSEVYajRlSlFDZzMwUkZzT2JKeE9TR2dRZXF3c1NnWGJh?= =?utf-8?B?ZEFkZkdyWnFEOS80akZidFZxTWducHNQVTVXcXJFSU9YQlorYm1oOXdJdzJj?= =?utf-8?B?eXk0ckZOTzlPYzJ6Q3NwR2dvVVRkV1FqUlczSkc5ZFZpa1RzNTFjQ0xyZUl5?= =?utf-8?B?Z0dMWlkyT1h6djAvK2VYdUIwcUd0N1dmQk1KaS9Za0NFbmNVVFZDNER4UjJk?= =?utf-8?B?OVJwMDhNSFpOcXFtNzFueXhJMUxrR1dnYlR6azd6R1NrRFhtWE1DOFRVanBL?= =?utf-8?B?RVNidkIzKzg0ckVlaml2WGdjdlI0dzJqZ1kyY2VDY3BST1Bra2d6RTZ1N051?= =?utf-8?B?Q0RROTU2ckFCZnR6elhuQytERFBTcFZHRjZCTk9HOWNaTmJTRExWZWNyL3hE?= =?utf-8?B?Q1RUbWpaYlNNdkNxMGVvTy9YREtzRUh1S2hxQlQ3QzRDY1QveWgveDRlWlhP?= =?utf-8?B?TEQwTkZNbXBwRklDRFMwNHdVS2lhQUFiQ0NmR09BNVAxY1JOV09EVUxGSXJy?= =?utf-8?B?T0Y4Y1FGU3lDM29PdTZlNXlVZ0prZEFHUG1tWThUVUdiNE5tWVByUE1UMlZG?= =?utf-8?B?RExvOS9IQ0hoMEhIWk56Qm0yMEZKNjd3andqY2lCYk4xaGU3a0U4aWJBbmxp?= =?utf-8?B?M1VLR1RMVzVIV2NMT3lMbVZZTUtlZ3RqV01mdjc1S2ZiTWRseCs2Q1lxQXRM?= =?utf-8?B?VS90Z0hab0dCbHpmK3FiaU0zWTVyOVZWL0Y1Z1lycjlCS0ZLQURaWDVUbnk3?= =?utf-8?B?THQ2MFYzY2I4V0ZobktWSkJrRWQ4bHNaNGxkV09adTM2ZzFsYmpOczdRRERD?= =?utf-8?B?eHE2T1QzaVFhT2s5eUFyc1B1cVc0KzVoTVdoaXl2NXRqYnkzd1VRNWFJRGhn?= =?utf-8?B?UWRRNEFuYzlBTy9FNmxUQ09ULzI1c1ZUTnZINlduNWQrSXZtSEtES0VaSElX?= =?utf-8?B?cjkxSkhYMy9WVnJaanozbDk1aitzVUpDcXY1MS9mcFl6VE1FMG44Y1JTMmZi?= =?utf-8?B?bloveW1sVnV5aFBkQXF3cXRuZUlxNzVDL0xqdUJQM0h6alA3eDRHV2tSZVlR?= =?utf-8?B?eXl6ajdsVnh4YU8zUXI4eVovTElMV1FzRWx0N3hpd01XY28xZ0RVcEpHeXJM?= =?utf-8?B?VFZMbGs4a3FwSWQzYmJncDVyWDFCeDJrZXNCNHg1elh2ZVZ2Zmw0ZVFjQjNj?= =?utf-8?B?aGlmWDgzMk1vRGxnQm5aK2FZYmx4bi9TMDJZOXhHVS9VYk8vQXU4SE92NTcw?= =?utf-8?B?MjRiN0ZrU3ZSTUNZS2ptOFlyR1o1ajRKNFN0bmZUb2tUWkRtT3ROd3BMZmsy?= =?utf-8?B?azU5dHhsREx0SDlUNEthRHZtTVphZGhWbGFySWlNSExvTWZXZ2orV2trd0g5?= =?utf-8?B?dEZLQzNRUGVFL3NzTGFObXdRU1RxRXdrdTNmT0xBNHd2M1J2UWNFcHU5UU1D?= =?utf-8?B?L3F4dzYrQ2FRbjRrd29DWDk1OVBKditkOWo2SGdpbVp1ZXpWM2REQXBoV0RY?= =?utf-8?B?NUFzd3dxQ216ZVJQWnU1dlBGaEptL1NGMmVCOUVZSzhsU29ZaGdSSnkvNWcy?= =?utf-8?B?bHVEWlpZNUxES0ZoWTBmdlJNWnUrWC9CakdTWlBNOGJEN3g5Y21tRmtqQWVD?= =?utf-8?Q?kp90C0y9QMoqdgccA55mBs1TnU8aJpU8oyykUUm?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: d13038f2-16ad-4d08-110b-08d913821ca2 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2021 07:06:20.0359 (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: p2+azk5dgLqx3n1E6dlCi2angdGpP+chmHEVvRW5e0224lFYv6PXkdLNxfjZgN49sZJqyQW20n9uz+VOx4wAWw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB1093 Archived-At: Subject: [core] CoRE WG Virtual Interim 2021-05-12 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, 10 May 2021 07:06:28 -0000 --TsfyPojf0Vi2ABo8a2nbtiAE4PqWYai5b Content-Type: multipart/mixed; boundary="SUBBJ3S3aUIxEq3Xxv8fONmOwsFM4B9NU"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <83073aeb-c1c4-7c17-4a77-aae5d989c81d@ri.se> Subject: [core] CoRE WG Virtual Interim 2021-05-12 --SUBBJ3S3aUIxEq3Xxv8fONmOwsFM4B9NU Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that we'll have a virtual interim meeting on Wednesday,=20 May 12th at 14:00 UTC. The agenda is available at [1]. Best, Marco and Jaime [1] https://datatracker.ietf.org/doc/agenda-interim-2021-core-05-sessa/ --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --SUBBJ3S3aUIxEq3Xxv8fONmOwsFM4B9NU-- --TsfyPojf0Vi2ABo8a2nbtiAE4PqWYai5b Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmCY22kFAwAAAAAACgkQ7iZktA5Y2kMC TggAoosz+4x0cTs2vYy2he5jvBSxv0l8wSx/3qNedvqoZpLJ8Eszo4Y8QXk5LvLA1WOObFGRYBng gA/E2ZmkBIRL4nGg1Mpt9gIaxNv2zxvT1Qo8r8J4wui1XDC4J01EHiI9Zi2TM4Kt1X5qLN4StC5O lpL3+lMoLh00icmkhkGhhyL2KjaFsXfnLG6bHQCPt+vXGLn73Bno4flvKWtGpXG5lhbtppU/vwUu Z/f4FcsghyI3cSxHguLtjfLJ6QfdW7bAHxEwvFqyXLHBD5P4dkySGxk0zrHmaRyHrmrlmIfXSEzP bCkbkmo90oYMQ0tEn3zIHiFELwTQjenUTCZlIhWc8A== =RBoo -----END PGP SIGNATURE----- --TsfyPojf0Vi2ABo8a2nbtiAE4PqWYai5b-- From nobody Mon May 10 21:54: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 A49D73A0A92; Mon, 10 May 2021 21:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 shahm5B34alg; Mon, 10 May 2021 21:53:50 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (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 1035D3A0A8F; Mon, 10 May 2021 21:53:49 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 4FfQYQ5bjWz20sL; Tue, 11 May 2021 06:53:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620708826; bh=J5jPOZFyIooIUduGeT+9KPBS/xczKqqbmn1URyafhZc=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Pvy+ZgXjaLbt7Kq7IELgMqBnziUsUEMt0eU3Qa4j9+6Pktqr3hze+pLSOG0iqDl1n gz6H7OKC+fAZEk8EtuWtEmmcoz3JN+hohpc2hbc2qwnpQf73Jj+oyokLdJvf0d8+yr M2VpR3o8UQCep2ziMcpA0TXlnhKa+9Kf41BfhCRE/JNbDu0PEs1p9jHryETkQqKPlY +DbKRGwknaYkrJrzNYZ3r/ORVl1jeDT5xOIv1z00o3xdvIfeesyj17Lrv2f3DgiTk+ 4BA/uRVMKlwjeCp7cQdiH8DarHISsd/ZZNS3RkCzIdUQEGN0u85Wa9ACc+pLleTUBY dAL4slfHiI5gw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4FfQYQ4LlYzDq7S; Tue, 11 May 2021 06:53:46 +0200 (CEST) From: To: Benjamin Kaduk , The IESG CC: "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXQhtQJ0eiusrJ/U2y11QoEHt7QqrWMTfggAeMMqA= Date: Tue, 11 May 2021 04:53:45 +0000 Message-ID: <31572_1620708826_609A0DDA_31572_193_1_787AE7BB302AE849A7480A190F8B933035382F17@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162026630680.17506.6477675472375470197@ietfa.amsl.com> <12589_1620322520_609428D8_12589_262_1_787AE7BB302AE849A7480A190F8B933035377DD2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <12589_1620322520_609428D8_12589_262_1_787AE7BB302AE849A7480A190F8B933035377DD2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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] Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 04:53:56 -0000 SGkgQmVuLCANCg0KSXQgc2VlbXMgdGhhdCB3ZSBtaXNzZWQgdG8gcmVwbHkgdG8gb25lIG9mIHlv dXIgY29tbWVudHMuIFBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpKb24gJiBNZWQNCg0K PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogY29yZSBbbWFpbHRvOmNvcmUt Ym91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZQ0KPiBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tDQo+IEVudm95w6nCoDogamV1ZGkgNiBtYWkgMjAyMSAxOTozNQ0KPiDDgMKgOiBCZW5q YW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVkdT47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBD Y8KgOiBkcmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrQGlldGYub3JnOyBjb3JlLWNoYWlyc0BpZXRm Lm9yZzsNCj4gY29yZUBpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW2NvcmVdIEJlbmphbWluIEth ZHVrJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWNvcmUtbmV3LQ0KPiBibG9jay0xMTogKHdpdGgg RElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IEhpIEJlbiwNCj4gDQo+IFRoYW5rIHlvdSBmb3Ig dGhlIHJldmlldy4gQWxsIHRoZSBjaGFuZ2VzIGNhbiBiZSB0cmFja2VkIGF0Og0KPiBodHRwczov L3Rpbnl1cmwuY29tL25ldy1ibG9jay1sYXRlc3QuDQo+IA0KPiBQbGVhc2Ugc2VlIGlubGluZS4N Cj4gDQo+IENoZWVycywNCj4gSm9uICYgTWVkDQo+IA0KPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KPiA+IERlwqA6IEJlbmphbWluIEthZHVrIHZpYSBEYXRhdHJhY2tlciBbbWFpbHRv Om5vcmVwbHlAaWV0Zi5vcmddDQo+IEVudm95w6nCoDoNCj4gPiBqZXVkaSA2IG1haSAyMDIxIDAz OjU4IMOAwqA6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPiBDY8KgOg0KPiA+IGRyYWZ0LWlldGYt Y29yZS1uZXctYmxvY2tAaWV0Zi5vcmc7IGNvcmUtY2hhaXJzQGlldGYub3JnOw0KPiA+IGNvcmVA aWV0Zi5vcmc7IG1hcmNvLnRpbG9jYUByaS5zZTsgbWFyY28udGlsb2NhQHJpLnNlIE9iamV0wqA6 DQo+IEJlbmphbWluDQo+ID4gS2FkdWsncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtY29yZS1uZXct YmxvY2stMTE6DQo+ID4gKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gPg0KWy4uXQ0KPiA+ DQo+ID4gJSUlDQo+ID4gVGhlIGZvbGxvd2luZyBmZXcgY29tbWVudHMgYXJlIGludGVycmVsYXRl ZDoNCj4gPg0KPiA+ICAgICAgIFRoaXMgUmVzcG9uc2UgQ29kZSByZXR1cm5lZCB3aXRoIENvbnRl bnQtVHlwZSAiYXBwbGljYXRpb24vDQo+ID4gICAgICAgbWlzc2luZy1ibG9ja3MrY2Jvci1zZXEi IGluZGljYXRlcyB0aGF0IHNvbWUgb2YgdGhlIHBheWxvYWRzDQo+IGFyZQ0KPiA+ICAgICAgIG1p c3NpbmcgYW5kIG5lZWQgdG8gYmUgcmVzZW50LiAgVGhlIGNsaWVudCB0aGVuIHJldHJhbnNtaXRz DQo+IHRoZQ0KPiA+ICAgICAgIG1pc3NpbmcgcGF5bG9hZHMgdXNpbmcgdGhlIHNhbWUgUmVxdWVz dC1UYWcsIFNpemUxIGFuZCBRLQ0KPiBCbG9jazENCj4gPiB0bw0KPiA+ICAgICAgIHNwZWNpZnkg dGhlIGJsb2NrIE5VTSwgU1pYLCBhbmQgTSBiaXQgYXMgYXBwcm9wcmlhdGUuDQo+ID4NCj4gPiBU aGUgbmV3ICdNJyBiaXQgaXMgImFzIGFwcHJvcHJpYXRlIiBmb3IgdGhlIG5ldyBmbGlnaHQgb2Yg bWVzc2FnZXMsDQo+IG9yDQo+ID4gYXMgd2FzIHNlbnQgaW5pdGlhbGx5PyAgKFRoZSBleGFtcGxl cyBpbiDCpzEwLnggc3VnZ2VzdCAiYXMgd2FzIHNlbnQNCj4gPiBpbml0aWFsbHkiLikNCg0KWWVz LiBXZSB1cGRhdGUgdGhlIHRleHQgYXMgZm9sbG93czogDQoNCiAgICAgIFRoaXMgUmVzcG9uc2Ug Q29kZSByZXR1cm5lZCB3aXRoIENvbnRlbnQtVHlwZSAiYXBwbGljYXRpb24vDQogICAgICBtaXNz aW5nLWJsb2NrcytjYm9yLXNlcSIgaW5kaWNhdGVzIHRoYXQgc29tZSBvZiB0aGUgcGF5bG9hZHMg YXJlDQogICAgICBtaXNzaW5nIGFuZCBuZWVkIHRvIGJlIHJlc2VudC4gIFRoZSBjbGllbnQgdGhl biByZXRyYW5zbWl0cyB0aGUNCiAgICAgIGluZGl2aWR1YWwgbWlzc2luZyBwYXlsb2FkcyB1c2lu ZyB0aGUgc2FtZSBSZXF1ZXN0LVRhZywgU2l6ZTEsDQogICAgICBhbmQsIFEtQmxvY2sxIE9wdGlv biB0byBzcGVjaWZ5IHRoZSBzYW1lIE5VTSwgU1pYLCBhbmQgTSBiaXQgYXMNCiAgICAgIHNlbnQg aW5pdGlhbGx5IGluIHRoZSBvcmlnaW5hbCwgYnV0IG5vdCByZWNlaXZlZCwgcGFja2V0Lg0KDQoN CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu ZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1l cmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Tue May 11 05:06:05 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 3CC6D3A14E1; Tue, 11 May 2021 05:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 OE9LHp0GoyEu; Tue, 11 May 2021 05:05:58 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (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 52EA03A14F0; Tue, 11 May 2021 05:05:58 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4Ffc832q9Xz5w7F; Tue, 11 May 2021 14:05:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620734755; bh=Ike2JgerAtx48n7fZDihkswneVQyX0chAf+kinngQHY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=HZOGYfyS+5bG+BiaiV/NSwEIir4ErUQZiBEzgY3jUXqYkvDX39xlVDC9SxUcRXbnU UUmEcUbbcyK6FciiWl6tUrZ0qDgOJ0scZkyDUu+KaWxf3iaG9bK1BXC9R/6ZdOTPB7 Ljly/aooHDACNtXp+01jwrwJc+GtpX7OOWMufoklUY9uZeBvIOohTQS53hSeI5ee4z fxC0MoxkX7UdZbbixIEiQV6h2hpDQU6p7AOFMoPwUvZE/SiXtl8lz2Xs1h7KiuX0Y1 UTYUcgOqogyi3e3QVQ0AMt4uS6Abs4U9XuaFe8fsbOVADl+AntxABe/jIqAV6srGIS +37BYp5EQqaDA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4Ffc831Jn4zBrLb; Tue, 11 May 2021 14:05:55 +0200 (CEST) From: To: Lars Eggert CC: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXQz+Tx85/LIwI7Ee6i4xXZSbinKrYAPxQ///qcQCABkhLMA== Date: Tue, 11 May 2021 12:05:54 +0000 Message-ID: <17373_1620734755_609A7323_17373_63_1_787AE7BB302AE849A7480A190F8B933035384380@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162039183121.15574.16597240090409070575@ietfa.amsl.com> <29803_1620395762_609546F2_29803_68_1_787AE7BB302AE849A7480A190F8B9330353787B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <666D5FF1-9E96-4522-A0FB-0A3042225BE7@eggert.org> In-Reply-To: <666D5FF1-9E96-4522-A0FB-0A3042225BE7@eggert.org> 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] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 12:06:03 -0000 Hi Lars,=20 We prepared some material for your to describe the methodology and to list = various interops and other useful pointers: https://github.com/core-wg/new-block/blob/master/testing%20methodology.md= =20 Please let us know if any further information is needed.=20 Cheers, Jon & Med > -----Message d'origine----- > De=A0: Lars Eggert [mailto:lars@eggert.org] > Envoy=E9=A0: vendredi 7 mai 2021 16:03 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: The IESG ; draft-ietf-core-new-block@ietf.org; > core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se > Objet=A0: Re: Lars Eggert's Discuss on draft-ietf-core-new-block-11: > (with DISCUSS and COMMENT) >=20 > Hi, >=20 > On 2021-5-7, at 16:56, mohamed.boucadair@orange.com wrote: > > There is not evaluation paper, but as stated in the thread with > Eric V., extensive tests were made that confirmed the benefits. The > code giving Q-Block support is out there in the public domain. A > pointer is included in the write-up. >=20 > is there any public information about the methodology and results for > these extensive tests? I understand there is no paper, but is there a > presentation or anything else? >=20 > Thanks, > Lars ___________________________________________________________________________= ______________________________________________ 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 Tue May 11 05:13:38 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 E15E93A1550; Tue, 11 May 2021 05:13:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162073521686.28209.2319938431113240491@ietfa.amsl.com> Date: Tue, 11 May 2021 05:13:36 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-new-block-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, 11 May 2021 12:13:37 -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-12.txt Pages : 48 Date : 2021-05-11 Abstract: This document specifies alternative Constrained Application Protocol (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. These options are similar to, but distinct from, the CoAP Block1 and Block2 Options defined in RFC 7959. Q-Block1 and Q-Block2 Options are not intended to replace Block1 and Block2 Options, but rather have the goal of enabling faster transmission rates for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 Options support 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-12 https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-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 May 11 05:21: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 ADE1B3A158C for ; Tue, 11 May 2021 05:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 r0o14V9DPSP0 for ; Tue, 11 May 2021 05:21:05 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (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 C05DB3A1576 for ; Tue, 11 May 2021 05:21:04 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4FfcTW1dYHz5wMZ; Tue, 11 May 2021 14:21:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620735663; bh=TQp/EKYF/Q9JmySIZzlycpUSXyT4WJm3SGpOpDtXRRQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=EY7PqZadMtLRPsIDj6uU7GnqGEsjp6V67ySJS0rA3am4GkI3MuI5Oikh4dycMr+3R gbjvL10XmdgkLJFwfc2zr2zsLeRpbDaGO0MXvqrNco0Uy2GvzEhY607FiQscPgfW3B oAvyDy3DfbXTQYUetMVc2oE9vA8Of+ks9plc1o4FVuFDMyLJ1g8fiDWVe2zwsQq3k5 OQKYAwJXKYdNMSTzLTOmLJNB8NgMGTABAH3zttz4ecWtWxSesBuR7hcPSmYKQ0DGlS 3MSLin3VzJlpQDC0XqG9e4JIKT8v2wwrhvQiskZtU7EXhrIeqnrc9vsUc/Tzw8gRgy leudmke6VVKRQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 4FfcTW0SNgz1xpL; Tue, 11 May 2021 14:21:03 +0200 (CEST) From: To: "core@ietf.org" , Francesca Palombini Thread-Topic: New Version Notification for draft-ietf-core-new-block-12.txt Thread-Index: AQHXRl8Tnr4Q/OaT4EGWm2F8AMz40KreMYOg Date: Tue, 11 May 2021 12:21:02 +0000 Message-ID: <29056_1620735663_609A76AF_29056_67_1_787AE7BB302AE849A7480A190F8B9330353843C2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162073521717.28209.17124738870629476119@ietfa.amsl.com> In-Reply-To: <162073521717.28209.17124738870629476119@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] New Version Notification for draft-ietf-core-new-block-12.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, 11 May 2021 12:21:10 -0000 SGkgYWxsLCANCg0KVGhpcyB2ZXJzaW9uIGludGVncmF0ZXMgdHN2YXJ0LCBpb3RkaXIsIGFuZCBp ZXNnIHJldmlld3MuIERldGFpbHMgYWJvdXQgdGhlIGNoYW5nZXMgd2VyZSBhbHJlYWR5IHNoYXJl ZCBpbiBlYWNoIG9mIHRoZSB0aHJlYWRzIGRpc2N1c3NpbmcgZWFjaCByZXZpZXcuIA0KDQpJZiB3 ZSBtaXNzZWQgYW55IGNvbW1lbnQgb3IgeW91IGRpc2FncmVlIHdpdGggYW55IG9mIHRoZSBjaGFu Z2VzLCBwbGVhc2UgbGV0IHVzIGtub3cuICANCg0KQ2hlZXJzLA0KSm9uICYgTWVkIA0KDQo+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IEVudm95w6nCoDogbWFyZGkg MTEgbWFpIDIwMjEgMTQ6MTQNCj4gw4DCoDogSm9uIFNoYWxsb3cgPHN1cGpwcy1pZXRmQGpwc2hh bGxvdy5jb20+OyBCT1VDQURBSVIgTW9oYW1lZA0KPiBUR0kvT0xOIDxtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPg0KPiBPYmpldMKgOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWlldGYtY29yZS1uZXctYmxvY2stMTIudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMTIudHh0IGhhcyBiZWVuDQo+IHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgTW9oYW1lZCBCb3VjYWRhaXIgYW5kIHBvc3RlZCB0byB0aGUg SUVURg0KPiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LWlldGYtY29yZS1uZXctYmxv Y2sNCj4gUmV2aXNpb246CTEyDQo+IFRpdGxlOgkJQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJv dG9jb2wgKENvQVApIEJsb2NrLVdpc2UNCj4gVHJhbnNmZXIgT3B0aW9ucyBmb3IgRmFzdGVyIFRy YW5zbWlzc2lvbg0KPiBEb2N1bWVudCBkYXRlOgkyMDIxLTA1LTExDQo+IEdyb3VwOgkJY29yZQ0K PiBQYWdlczoJCTQ4DQo+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNo aXZlL2lkL2RyYWZ0LWlldGYtY29yZS1uZXctDQo+IGJsb2NrLTEyLnR4dA0KPiBTdGF0dXM6ICAg ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLW5l dy0NCj4gYmxvY2svDQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtDQo+IGNvcmUtbmV3LWJsb2NrDQo+IEh0bWxpemVkOiAg ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLW5ldy0NCj4g YmxvY2stMTINCj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLWNvcmUtDQo+IG5ldy1ibG9jay0xMg0KPiANCj4gQWJzdHJhY3Q6DQo+ ICAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGFsdGVybmF0aXZlIENvbnN0cmFpbmVkIEFwcGxp Y2F0aW9uDQo+IFByb3RvY29sDQo+ICAgIChDb0FQKSBCbG9jay1XaXNlIHRyYW5zZmVyIG9wdGlv bnM6IFEtQmxvY2sxIGFuZCBRLUJsb2NrMiBPcHRpb25zLg0KPiANCj4gICAgVGhlc2Ugb3B0aW9u cyBhcmUgc2ltaWxhciB0bywgYnV0IGRpc3RpbmN0IGZyb20sIHRoZSBDb0FQIEJsb2NrMQ0KPiBh bmQNCj4gICAgQmxvY2syIE9wdGlvbnMgZGVmaW5lZCBpbiBSRkMgNzk1OS4gIFEtQmxvY2sxIGFu ZCBRLUJsb2NrMiBPcHRpb25zDQo+ICAgIGFyZSBub3QgaW50ZW5kZWQgdG8gcmVwbGFjZSBCbG9j azEgYW5kIEJsb2NrMiBPcHRpb25zLCBidXQgcmF0aGVyDQo+ICAgIGhhdmUgdGhlIGdvYWwgb2Yg ZW5hYmxpbmcgZmFzdGVyIHRyYW5zbWlzc2lvbiByYXRlcyBmb3IgbGFyZ2UNCj4gYW1vdW50cw0K PiAgICBvZiBkYXRhIHdpdGggZmV3ZXIgcGFja2V0IGludGVyY2hhbmdlcy4gIEFsc28sIHRoZSBR LUJsb2NrMSBhbmQNCj4gICAgUS1CbG9jazIgT3B0aW9ucyBzdXBwb3J0IGZhc3RlciByZWNvdmVy eSBzaG91bGQgYW55IG9mIHRoZSBibG9ja3MNCj4gZ2V0DQo+ICAgIGxvc3QgaW4gdHJhbnNtaXNz aW9uLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+IHRvb2xzLmlldGYu b3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gDQoNCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlv dS4KCg== From nobody Tue May 11 06:11: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 680523A1736; Tue, 11 May 2021 06:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_BLOCKED=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 (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQd4GCa1ShuA; Tue, 11 May 2021 06:11:38 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 14FE43A1738; Tue, 11 May 2021 06:11:38 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:1574:cd7a:7f:13e3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id DB0B260035E; Tue, 11 May 2021 16:11:22 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1620738683; bh=nLDdFA9SpyoFL4QemX73FBEOhm+wDoL/YBi6fSJcH/o=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=QfrSWDUGq1toSpKiAiD6z6xYpN3XnLwQBOdw2EiK5wuFPDYlyDIQMBxTYmIFCP4ay vIyzjWeTiYumiw0mJh3TN7iqCDwXuJNFjNLAZbhFxPgIpxpZlJUh5rVz4fZBeG/GHE PeaCEz9CtImgmLIXC7hzFKG3T1tFSX38juxrUZ40= From: Lars Eggert Message-Id: <47273993-E4D3-4042-85B5-17163C984B18@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_187EA2A5-6200-42DE-88FB-24032B45B790"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Tue, 11 May 2021 16:11:22 +0300 In-Reply-To: <17373_1620734755_609A7323_17373_63_1_787AE7BB302AE849A7480A190F8B933035384380@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Cc: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" To: mohamed.boucadair@orange.com References: <162039183121.15574.16597240090409070575@ietfa.amsl.com> <29803_1620395762_609546F2_29803_68_1_787AE7BB302AE849A7480A190F8B9330353787B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <666D5FF1-9E96-4522-A0FB-0A3042225BE7@eggert.org> <17373_1620734755_609A7323_17373_63_1_787AE7BB302AE849A7480A190F8B933035384380@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-MailScanner-ID: DB0B260035E.A2484 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 13:11:44 -0000 --Apple-Mail=_187EA2A5-6200-42DE-88FB-24032B45B790 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-5-11, at 15:05, mohamed.boucadair@orange.com wrote: > We prepared some material for your to describe the methodology and to = list various interops and other useful pointers: > = https://github.com/core-wg/new-block/blob/master/testing%20methodology.md thanks for the pointer, Med. This is a clear description of the tests = that were done, most (all?) of which seem to be focused on regression = and interop testing. What I was hoping to see, however, were some results that quantified the = performance and safety aspects of this proposal. I tried to explain what = I was looking for in my DISCUSS. draft-ietf-core-new-block basically = proposes a send rate control mechanism, to be used in DDoS scenarios, = i.e., a component of a transport protocol. The IETF has a pretty = well-developed approach for analyzing such mechanisms. As part of that = analysis, one would investigate a number of things: 1. The motivation for draft-ietf-core-new-block seems to be a lack of = performance with RFC7959. For a Proposed Standard, I would expect there = to be an evaluation that draft-ietf-core-new-block achieves that desired = level of performance over RFC7959, in a number of scenarios of interest. = This is to establish that the proposed mechanism is fit for purpose. 2. For a Proposed Standard, I would also expect to see an evaluation = whether draft-ietf-core-new-block achieves that desired level of = performance in non-DDoS scenarios *without* unduly affecting competing = traffic. (Or else there needs to be an applicability statement that = draft-ietf-core-new-block MUST only be used under DDoS, and a reference = needs to be given for how a DDoS scenario can be reliably determined.) = This is so the proposed mechanism can be recommended as the IETF = solution for a given use case, without too many restrictions. To be clear, that is not material that would be in the specification. = Such material would probably be presented to the WG early during the = standardization process (often at adoption time), and referred to in the = specification. In other words, I'm not asking you or the WG to now go = and perform this analysis - I'm asking whether it has been performed = already, because that is to me the deciding factor in whether I can = ballot "no objection" to publishing this as a Proposed Standard. I hope this clarifies things further? Thanks, Lars --Apple-Mail=_187EA2A5-6200-42DE-88FB-24032B45B790 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmCagnoACgkQVLXDCb9w wVePUBAA0KW4bD+rwBQnRmhIsVVbHH/AsUoiq2RUIhm1VzkwfnexHT/rY6abyvbd I/kkoojNFgR2fbvN7geU251i2iutNHIbLaWobDfWvC1P3GTE1lq3DeDsY6olkuhL pqSmaI6lAN/wLH6vjwUygwfkxadp9liIoXeZZK8JT8ZeV2kw1f8XCjKjzLUjHw4C E1YQmJBUTxyrhS75BF0CM44epV3LYQ06zCDqCkXoCJ/3mmjhW8GN82a5c0aK8NFp fQbSRAMvPMAqwfXob+31zHdFb4GAzZW0tfBlT51bMDxKpJgpBwquEbKD7SgAjlHE 9zVyu/3/AQVjBhwzvCXtK2ZWI+GTNo7L91JCi7ft9Sq5QG8yvDQrenekH8UMsMTV jp919FxB8bxVUwNTfYmSWP0RTRmrQJwo0fuocO/EMT/rJeyMCPpIRIkpA8F7Ajhj IxqaDpyXS9FivwNBYDc7kQCgND5UiHLhdWE7aVvFrcZ36AuLQiGWFppGRd3uR48J hGcJm2JYtTrcJaaCiUOn0fP3m4lhJyRdlh+1b5Mz2Xd8IvKKxOBCjTudULPKpktq wltC1/u91RGGoLaZzY6OzMMM+r25ZJZI+sMdYQ9tibezRuOmGEPs3+XcXe7CQ9vX qeI6ppBQsH9JeR8TpwIoarWFOYwb9iOsJaHXBGJXb+3N8UUWxP4= =/IbO -----END PGP SIGNATURE----- --Apple-Mail=_187EA2A5-6200-42DE-88FB-24032B45B790-- From nobody Tue May 11 06:28: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 19F143A17E3; Tue, 11 May 2021 06:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 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, PDS_BAD_THREAD_QP_64=0.998, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 2XQiWFWHDIzf; Tue, 11 May 2021 06:28:49 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (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 54AD23A17E0; Tue, 11 May 2021 06:28:49 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4Ffdzg5Ft9z16k8; Tue, 11 May 2021 15:28:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620739727; bh=Nb4p7AFUBgjDmDtvO+Vd2Aj02CQnXj4yYHNT1uL0Hw0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=hoHGhqArn7MXKXohf0K9TVVjpzZZ0nEgnQ1e176zRsP3aKo10wY4RlRSqcLBhOQoH p4XYICh7izOXP8TetmhaIvE711ZLVcoBQyvBGdqZDMAY0E8zshvj8c10QiX2wCeoLF IJPfMuYgIcZxW+3cDSSFxb5IpfOpH6DrMW+bxRR4j0KbYiSFYKWVDQ6znxCWC1O6D2 oB8AMilskvdRXT3YZFGWk8P88T4EMKMj1GKEv3K6qF+OfhsS4KXP7CQWAnXPfV+oF4 VRuy6qI2ylOZRZFIjHA8Z1p0AqgyUlQvWWavTDbsGeoZDmGgQKd12avscw9qAeNWNq sqrjiwifXV1Pw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4Ffdzg3hS8zDq8B; Tue, 11 May 2021 15:28:47 +0200 (CEST) From: To: Lars Eggert CC: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXRmcjbs3/HDljMxiZ+ChpLivgHqreQwXQ Date: Tue, 11 May 2021 13:28:46 +0000 Message-ID: <17932_1620739727_609A868F_17932_314_1_787AE7BB302AE849A7480A190F8B9330353854D5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162039183121.15574.16597240090409070575@ietfa.amsl.com> <29803_1620395762_609546F2_29803_68_1_787AE7BB302AE849A7480A190F8B9330353787B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <666D5FF1-9E96-4522-A0FB-0A3042225BE7@eggert.org> <17373_1620734755_609A7323_17373_63_1_787AE7BB302AE849A7480A190F8B933035384380@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <47273993-E4D3-4042-85B5-17163C984B18@eggert.org> In-Reply-To: <47273993-E4D3-4042-85B5-17163C984B18@eggert.org> 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] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 13:28:54 -0000 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Lars Eggert [mailto:lars@eggert.org] > Envoy=E9=A0: mardi 11 mai 2021 15:11 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: The IESG ; draft-ietf-core-new-block@ietf.org; > core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se > Objet=A0: Re: Lars Eggert's Discuss on draft-ietf-core-new-block-11: > (with DISCUSS and COMMENT) >=20 > Hi, >=20 > On 2021-5-11, at 15:05, mohamed.boucadair@orange.com wrote: > > We prepared some material for your to describe the methodology and > to list various interops and other useful pointers: > > https://github.com/core-wg/new- > block/blob/master/testing%20methodology.md >=20 > thanks for the pointer, Med. This is a clear description of the tests > that were done, most (all?) of which seem to be focused on regression > and interop testing. >=20 > What I was hoping to see, however, were some results that quantified > the performance and safety aspects of this proposal. I tried to > explain what I was looking for in my DISCUSS. draft-ietf-core-new- > block basically proposes a send rate control mechanism, to be used in > DDoS scenarios, i.e., a component of a transport protocol. The IETF > has a pretty well-developed approach for analyzing such mechanisms. > As part of that analysis, one would investigate a number of things: >=20 > 1. The motivation for draft-ietf-core-new-block seems to be a lack of > performance with RFC7959. For a Proposed Standard, I would expect > there to be an evaluation that draft-ietf-core-new-block achieves > that desired level of performance over RFC7959, in a number of > scenarios of interest. This is to establish that the proposed > mechanism is fit for purpose. [Med] We thought that this is covered by this part of the text:=20 =3D=3D Libcoap was tested with complete packet loss in one direction (for NON) con= firming data still gets through, albeit more slowly with the NON_TIMEOUT ti= meout for every MAX_PAYLOADS packets adding to the overall transmission tim= e. Note that CON fails under these conditions, and as such RFC7959 fails to= retrieve the body. =3D=3D The performance comparison is straightforward as RFC7959 (with CON messages= ) fails while the body is successfully retrieved using the new-block. >=20 > 2. For a Proposed Standard, I would also expect to see an evaluation > whether draft-ietf-core-new-block achieves that desired level of > performance in non-DDoS scenarios *without* unduly affecting > competing traffic. (Or else there needs to be an applicability > statement that draft-ietf-core-new-block MUST only be used under > DDoS, and a reference needs to be given for how a DDoS scenario can > be reliably determined.) [Med] We do have the following applicability scope (an excerpt below):=20= =20 The block-wise transfer specified in [RFC7959] covers the general case, but falls short in situations where packet loss is highly asymmetrical. The mechanism specified in this document provides roughly similar features to the Block1/Block2 Options. It provides additional properties that are tailored towards the intended use case of Non-Confirmable transmission. Concretely, this mechanism primarily targets applications such as DDoS Open Threat Signaling (DOTS) that cannot use CON responses to handle potential packet loss and that support application-specific mechanisms to assess whether the remote peer is not overloaded and thus is able to process the messages sent by a CoAP endpoint (e.g., DOTS heartbeats in Section 4.7 of [RFC8782]). ... This mechanism is not intended for general CoAP usage, and any use outside the intended use case should be carefully weighed=20 I think that we do already have the guards clearly explained. If you don't = think so, can you please share which change you would like see in the appli= cability scope? This is so the proposed mechanism can be > recommended as the IETF solution for a given use case, without too > many restrictions. >=20 > To be clear, that is not material that would be in the specification. > Such material would probably be presented to the WG early during the > standardization process (often at adoption time), and referred to in > the specification. In other words, I'm not asking you or the WG to > now go and perform this analysis - I'm asking whether it has been > performed already, because that is to me the deciding factor in > whether I can ballot "no objection" to publishing this as a Proposed > Standard. >=20 > I hope this clarifies things further? >=20 > Thanks, > Lars ___________________________________________________________________________= ______________________________________________ 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 Tue May 11 10:26: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 A8AEA3A1F7C; Tue, 11 May 2021 10:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_BLOCKED=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 (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbYkFPIUyX2N; Tue, 11 May 2021 10:26:48 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 729AB3A1F7A; Tue, 11 May 2021 10:26:47 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:1574:cd7a:7f:13e3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 8F2BD60035E; Tue, 11 May 2021 20:26:39 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1620753999; bh=juDurZBI75KS2qUgtA6B9OV2vYTHHs+rKfNwLepNWDo=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=ebd6DOBSkEvu+vXU16XVqjkz05+A0cIdQDWA96NMne9q3pTjBydxYcH1svlV25lFj /k4OCkvKY9JhzuM3n67aanExYAgfjDx5mV5/rwk6Syn6GxtHn0Nbwbg3yBBdLmUfVS A1jsQ2JgJfoA4mFnv9PAVg6FR5H8PvnNoD1vygvo= From: Lars Eggert Message-Id: <39AC6D5F-0FA3-4FE3-BD59-302B65CFDE49@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_35F07822-74CB-4C6E-8A31-C1EA5FD0A872"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Tue, 11 May 2021 20:26:38 +0300 In-Reply-To: <17932_1620739727_609A868F_17932_314_1_787AE7BB302AE849A7480A190F8B9330353854D5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Cc: "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "marco.tiloca@ri.se" To: mohamed.boucadair@orange.com References: <162039183121.15574.16597240090409070575@ietfa.amsl.com> <29803_1620395762_609546F2_29803_68_1_787AE7BB302AE849A7480A190F8B9330353787B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <666D5FF1-9E96-4522-A0FB-0A3042225BE7@eggert.org> <17373_1620734755_609A7323_17373_63_1_787AE7BB302AE849A7480A190F8B933035384380@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <47273993-E4D3-4042-85B5-17163C984B18@eggert.org> <17932_1620739727_609A868F_17932_314_1_787AE7BB302AE849A7480A190F8B9330353854D5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-MailScanner-ID: 8F2BD60035E.A5C1B X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 17:26:53 -0000 --Apple-Mail=_35F07822-74CB-4C6E-8A31-C1EA5FD0A872 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-5-11, at 16:28, mohamed.boucadair@orange.com wrote: >> 1. The motivation for draft-ietf-core-new-block seems to be a lack of >> performance with RFC7959. For a Proposed Standard, I would expect >> there to be an evaluation that draft-ietf-core-new-block achieves >> that desired level of performance over RFC7959, in a number of >> scenarios of interest. This is to establish that the proposed >> mechanism is fit for purpose. >=20 > [Med] We thought that this is covered by this part of the text: >=20 > =3D=3D > Libcoap was tested with complete packet loss in one direction (for = NON) confirming data still gets through, albeit more slowly with the = NON_TIMEOUT timeout for every MAX_PAYLOADS packets adding to the overall = transmission time. Note that CON fails under these conditions, and as = such RFC7959 fails to retrieve the body. > =3D=3D >=20 > The performance comparison is straightforward as RFC7959 (with CON = messages) fails while the body is successfully retrieved using the = new-block. this says that draft-ietf-core-new-block works where RFC7959 fails. = While it's technically true that this makes draft-ietf-core-new-block = infinitely faster then RFC7959, I didn't understand that that was what = the title, abstract and some other places in the document meant - it = sounded to me that a performance difference compared to RFC7959 was the = motivation for draft-ietf-core-new-block? Because if it's purely about not failing, you could make = draft-ietf-core-new-block (much) less aggressive and all my issues would = go away. Is that a way forward here? If not, and a performance difference is part of the motivation, I think = a Proposed Standard should refer to some analysis that demonstrates that = in a number of scenarios of interest. >> 2. For a Proposed Standard, I would also expect to see an evaluation >> whether draft-ietf-core-new-block achieves that desired level of >> performance in non-DDoS scenarios *without* unduly affecting >> competing traffic. (Or else there needs to be an applicability >> statement that draft-ietf-core-new-block MUST only be used under >> DDoS, and a reference needs to be given for how a DDoS scenario can >> be reliably determined.) >=20 > [Med] We do have the following applicability scope (an excerpt below): >=20 > The block-wise transfer specified in [RFC7959] covers the general > case, but falls short in situations where packet loss is highly > asymmetrical. The mechanism specified in this document provides > roughly similar features to the Block1/Block2 Options. It provides > additional properties that are tailored towards the intended use = case > of Non-Confirmable transmission. Concretely, this mechanism > primarily targets applications such as DDoS Open Threat Signaling > (DOTS) that cannot use CON responses to handle potential packet loss > and that support application-specific mechanisms to assess whether > the remote peer is not overloaded and thus is able to process the > messages sent by a CoAP endpoint (e.g., DOTS heartbeats in > Section 4.7 of [RFC8782]). > ... > This mechanism is not intended for general CoAP usage, and any use > outside the intended use case should be carefully weighed >=20 > I think that we do already have the guards clearly explained. If you = don't think so, can you please share which change you would like see in = the applicability scope? This says "only use this for DOTS". But it doesn't discuss whether = draft-ietf-core-new-block is only deemed safe for DOTS scenarios in = which a DDoS is present, or also in cases where a DDoS is absent, and it = doesn't cite any analysis into *why* this recommendation can safely be = made. If DOTS uses draft-ietf-core-new-block, what is the impact on = crosstraffic? (Also, in the IESG discussion the point was brought up that = draft-ietf-core-new-block may form the basis for a revision of RFC7959, = so it's a bit odd to see this strict limitation on one application = and/or a very specific scenario.) > This is so the proposed mechanism can be >> recommended as the IETF solution for a given use case, without too >> many restrictions. >>=20 >> To be clear, that is not material that would be in the specification. >> Such material would probably be presented to the WG early during the >> standardization process (often at adoption time), and referred to in >> the specification. In other words, I'm not asking you or the WG to >> now go and perform this analysis - I'm asking whether it has been >> performed already, because that is to me the deciding factor in >> whether I can ballot "no objection" to publishing this as a Proposed >> Standard. >>=20 >> I hope this clarifies things further? >>=20 >> Thanks, >> Lars --Apple-Mail=_35F07822-74CB-4C6E-8A31-C1EA5FD0A872 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmCavk4ACgkQVLXDCb9w wVf45g//WlfCbYNubBXSkXLfRVOi+3dfas6vHEGbB82/0lVG8/RJg644dE1lueuY bNEg5672lUEYi1dqMnHORxjjBDWHWthsif0aRTTYeTJqsZreNschcLSpL45kX7N7 4d4N2Jqeu8y2rn8mphh5U4dz6Ipd9lPUu5wMvTTvoo20vYGnbMWV/Y/O13jmMwb3 q7tIaG1b0HIRamqmp5/E8bU8Iy6vbO7Q6lyXD+B4Y126o7rSiEmiJW2oqu+cTs6J h9oCEQPPPoBS1qbChJzvr4eoc6xETAPGhyIGet2oadbcKHiuN1BZ5c4KoOkioAs9 wxnqfeIrJh5am/8wEQWGYGhWhcdPHLFMK6A6tmKGePzjPn9DENSOJGhl+f6utRpe Pe8MOwsYh3Fl4mSZbNMM9EXYhQnbZExm4bJx+BKp3oHMy8rvL6DyzTXgbwEFdWWA E20sjW22/0gZMwiw1nQ1A0tNuFi4zDVOfYp3EyYXlhXqR8tmyP6tME4xu9WGi11A o9iZbvd9XqGOC91pdxBsLDQM2F4KpcIpuYr9gp71I1cCLt7vP4RS2naqrApySbrv IMAZ1rXZZps4oVD5ICqRywlfDpUspwfESLIWBN8GcTFzpxlcU+1MHCLdrVT4gJFg 0dXpp2uV4pWDX+qOUKBU0JmY5aCRvSd13gfhdmTqunbrmcDeYZA= =/I0H -----END PGP SIGNATURE----- --Apple-Mail=_35F07822-74CB-4C6E-8A31-C1EA5FD0A872-- From nobody Wed May 12 02:23: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 A928D3A0AEE for ; Wed, 12 May 2021 02:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=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 mEYceFVxSO52 for ; Wed, 12 May 2021 02:23:46 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0628.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::628]) (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 BAD433A0AF7 for ; Wed, 12 May 2021 02:23:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a+3A2pyZhpwT9jkgzm41yjAI29/TcQc06g5U9xC/ikY0ffZIQ5gPbzuhjaimV/fPmg6q2xk2ucIIv6rc1Hu5FOGobQjWQwm5oMqqO/j4Nw3OyQJ06HrmaayGzsd3aCIvQV457msg9KOaiPZLOh4BSDLRmArOmKXoAzxtjftSUyHewA//eBxCkTTi2Mlq6Ng0ftO1BVEgXP2l1o3OUhIE598sIEajJtOrTYNvmW0vnOxl7KQNlJL2PS2KLvGQnE9UliJPCMTVz9B7+GCkEdG79YafTDxkKBkc5AjjVry1lCORTb/KSNCHMjjUotjeXoaui07ff5vhX6f4sW1E02jzYg== 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=HlohaM38joqCHR5ymITmBYGeCdxekKG84adL07W2efE=; b=JjJSFSqQK5MCIcBPn+g/yCgsQs0fa2ihINE2vGuNz5fZyaR44Qu1LtsgJdo2/z/VZ4uRIFGcqCBVgVVZUN5TfvcjXkr2n2sAwNDUBb2kcSo2llkGiZ4Ty1rCv8tvMZiSZMQp+z6QnSmUnxLz8IJalBhSCl1XdjEfgOw/vyaufAgGHBiYPvYXy43N9RkCZRFPlFj6NaOkdgjwZ3G3jmzy5z9HVP2TB+xAxvKqFZ01z4Yieggrbi+oSgdYDh9NQYKtFXNh1Usk+SGuldAl1kqNKZT10ajXLmzyHk262kj5fwvS6NBb8Y7OlNkzReW+53vqb3c0+tEiSzU5WVAPsiA9pA== 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=HlohaM38joqCHR5ymITmBYGeCdxekKG84adL07W2efE=; b=FTqwN0FBi4ghXOwhJGATekAjmKd++rJKT0+BK/soGRHfhBP8kkLmSOSUiPmY+L1Wac/Z2CUC29xKRKu8SNmVoP1JaMzGlUdd48jW0A0rd7JNMWqJqENLMSfl+KdgKRvJexse9OgsyuZJWEKb1ASgxWKuQnaVO1pYmc4g7iuYlhA= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR0701MB2937.eurprd07.prod.outlook.com (2603:10a6:3:56::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.12; Wed, 12 May 2021 09:23:42 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3%11]) with mapi id 15.20.4129.026; Wed, 12 May 2021 09:23:41 +0000 From: John Mattsson To: "core@ietf.org" CC: Benjamin Kaduk , Roman Danyliw Thread-Topic: Publish draft-mattsson-core-coap-actuators as a companion document to draft-ietf-core-echo-request-tag Thread-Index: AQHXRxB/w18uKlZ79kGgJ3Jg60mKSQ== Date: Wed, 12 May 2021 09:23:41 +0000 Message-ID: <8DECAD2F-F175-4405-BED7-0B6C95665231@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: af7602ad-2bd6-41c2-44ad-08d91527a244 x-ms-traffictypediagnostic: HE1PR0701MB2937: 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: HYQKxYaRBMbLZjOBL5YPrdOqFrDcoPnUadAmXBzjWw9qElzIeoReBZyvL/YpGTDAvDkME2LkAqxwR0wgIGHxaTMn4BkeBkQ/19LAOTFGDCKUa1y/ZR/UCcfX1XBONvH3ZhzKoe0R2yIRF8ZnJBcXQREewjJ2ofCzUIJkA4Y0uCmH37ByqbKOwHmWzNQbV7ZCbi7ctltSDzpwBIneiO9EARH/kR7aP1iHOo8DEVrX5J5UQhiIzWa7WsdCd3wtlDkC1ABqm4N2bKc3oqzUhljbsFkz/Ro3ZpVVG5KeVFLpHqJLJAXZXaFq7K43QXSAzI6MgfoRrvNTW/9tMn1ANJv1+5Fwvs/dH257obz9bl2oDnDTcg9ReA/M3yMGf7L2ztyvm6TrkX2gSiFhhPPXGxVB5zzMg4BLCOUd9JVOzOck7KWr7XYVe4+wD4M5SiZWn+Ted/kOSf/2+yY8Lex6yRwv+WP2IVgY/7NllBaQ/gFXr/wSryNm3HNt8MiOaz1KX0n01FztvsOxuk+3I/wJdcCjwcc200wqEnQpU+MikBMX2dVN2HkiyMtbAcVtyjsSHyUEcjJwiLo3IxTlX8bPbEDpR7sMPTrKINukrH23C939wmoRpYENuFhg4UGjYCtAcGC5jhT33Ty4aidNUM7fRPjB/dkq3ZRn1lqJNn0VwYa6lBm+Gv/O6LLOfq0tfC/GyiqDuoVE8ArMWRs/hkr1idBrePINPndTH/WpG+TeuFFWhfRScjIaLxUqrPDuknL2FZyU/Olw8fh6qupgjEIWNpQx1g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(396003)(366004)(39860400002)(346002)(316002)(2616005)(38100700002)(186003)(83380400001)(6916009)(6506007)(6512007)(966005)(122000001)(8936002)(86362001)(5660300002)(44832011)(26005)(54906003)(36756003)(64756008)(66446008)(4326008)(2906002)(6486002)(71200400001)(33656002)(66946007)(478600001)(66476007)(66556008)(76116006)(8676002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?c2tnRHQwVUh1R3FMZ01sS01yMEVUdzd0VG1GMXd5VHBFQ0pqT3pSOGZSYVF5?= =?utf-8?B?SU1QQVFaN1M0QS9wMHEwMXQ0eERNdHBWYk9oS2oraGlhZWk4NWg2SzNBRm1i?= =?utf-8?B?T09mYy9adVRPVXJzU0FTWEFIN296OW4vTHNSWmlLZmFOUS9rU3BYNnRlc3Rk?= =?utf-8?B?TjJBTkpIT1BNckdFY1lNYTlzWWR1bllPQXFXRFUxTGlPYk9EclcwT3QrbDln?= =?utf-8?B?UWZTeVRmWDRXaVdCOEpmUE9LSDMxY3h0QkZQWW1DcWVKajJ5d1I0K3RleHIr?= =?utf-8?B?SW1wekRXUkhSRTZ2WXZiakJzK2dxRk9JSUVYdUZ0R1F2cHkzTmQya2lCeDdF?= =?utf-8?B?U25kQk15SU10WTVZRm5XOEtXaXJWY3hZdmVSRzJ3NEYzUlkwTU9XSUV0MHIx?= =?utf-8?B?VDVzV1EyZXhoNjBwYzJVY09rYiszMkNSdGlQQjdiZ0YzSFZ0QmdvWjZHaHg1?= =?utf-8?B?MVZGQWV5VlQ3bVZFQW55K04yVDdGV0k3TGl3ZG10WTQzWndpVzkzSGlKMFVX?= =?utf-8?B?N1k0OEtBSnh1cGZpam9oRHpwSi9JVFYySUw1TWF5TWN3WHNiUmZId1NjTjI1?= =?utf-8?B?VkpoS3YxQkZRUWZXNjBiOVZxVy9SZ0lFNlJvTGt4eGtIVEo2R01TeXJYeHNs?= =?utf-8?B?WmJiSk9NdGxqTDMzUHo2blc2Yk9UZU5mSHBucTY1YVhWd2hMbFUwUkdvMEJj?= =?utf-8?B?VzFXZU4ySUxTSFcvZ3RpQkR2U0JPUWtiWGdIMUtVaW5ZN2RzelV4dGx4U0tC?= =?utf-8?B?Tk5LeVg2b1oyWGpVM2VwblBCbC9FTHVwbWpHMzBFOFlGU29nb0NOWEJNdXlH?= =?utf-8?B?L3RpT1ZQQXY4VENiUVJVdmExQ0IzbG1FdUJSVzdtK2R1bTN5UnVaTnVLVWlS?= =?utf-8?B?MXRSdnIzK0ZDTFd3QUJFTGhzVnd1aVp2OU83SFdZTDVZaUZBVzNJVnVsb1hT?= =?utf-8?B?ZnZIMW5iVWQ0bzNUaU01b2NtV3o1aVNZNVNQcG1YaFY2K3BqK1FxS1czVllk?= =?utf-8?B?QURyWXJQRnRFUDRIOFZCd0xvWFhXcEk2UytYdHFrdGtqMW14RGRJQkVQU0ZE?= =?utf-8?B?M3N2MUVuV3dUVjdCTURmUnQwT3dLcW01YjR1RVA2K1Z4WWtNUGNGeG5jaFRH?= =?utf-8?B?VmtDRmxrUmsyWFJsUjJYUFNpMVRmd3djbnFlSm91WHdzWk54KzdZVHBKQjU1?= =?utf-8?B?SXRBMDVNd243V3E0SmtlL0YvL2FIRHN3U2NCUG10TlRTdzhPSURwUDNJaXdT?= =?utf-8?B?dlVyMkk1V291M0JGU1VieGp6TktnWkl1TmN6TlJ1MkZsc3YyemN5WFd6c0FR?= =?utf-8?B?dGk4eDhHQ050SXVONTdsTG1LR2pNVnNhRWs5VEVmenlndUttTDBpelZ0TTdI?= =?utf-8?B?d1lxSFVQbUlYNVVZY1MyMEdmMks3YlBvZkVFOUlwWFFSL1VnV0I5MzZlVXBm?= =?utf-8?B?RDIxaDJNell0VDdLakI2MEV4bDhYa2VMOGN0VVNOaEQ2ODl5dUVIcnNkM1hC?= =?utf-8?B?U29vQUpkZDdqRGpEOGM4TldGSnp4clltU2hQUThsNTFVb25qVlFqT3VDaVNh?= =?utf-8?B?WmNrdCtMakRKT2cvNHJUV0ZTUlJmOVBjN3pkS04zdUx3QmNOSGxWVTRKSHRU?= =?utf-8?B?TFVjd0hDZ3Uwa0JMdUFSeVhBMzNBNGhaKzg2N3VvTTVtSmhoSnk0NWV0VDJt?= =?utf-8?B?WFEvQm1Oa0RUcDM5SkZ0VFBnQkN4RmI1UWhPNDVMb3ZwNC92Qlc1UnRGOTNw?= =?utf-8?Q?Qhtwn8FBVnEwK3Z8ssydSgaGf5cc6kesrkYY7nL?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <77E05890D453314B8314B5A1AA229BA6@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: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: af7602ad-2bd6-41c2-44ad-08d91527a244 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2021 09:23:41.8207 (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: i2ljUjnavHjSNaaZd2eo8DevP04Hgy/dUPX4wVlUbFNkO5+tiYJpsD2WOhtAwbzsEEc/Qp/Mp1mVvccKHQTHagGvxY7XqZ4vDtsG1cqig5g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2937 Archived-At: Subject: [core] Publish draft-mattsson-core-coap-actuators as a companion document to draft-ietf-core-echo-request-tag 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, 12 May 2021 09:23:52 -0000 SGksDQoNCkluIHRoZWlyIElFU0cgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29yZS1lY2hvLXJlcXVl c3QtdGFnLCBib3RoIHNlY3VyaXR5IEFEcyBtZW50aW9ucyBhbmQgcmVmZXJlbmNlcyBkcmFmdC1t YXR0c3Nvbi1jb3JlLWNvYXAtYWN0dWF0b3JzLg0KDQpCZW4gc2VlbXMgdG8gc3VnZ3N0IHRoYXQg aXQgd291bGQgYmUgZ29vZCB0byBwdWJsaXNoIGRyYWZ0LWlldGYtY29yZS1lY2hvLXJlcXVlc3Qt dGFnIGFzIGFuIGluZm9ybWF0aXZlIFJGQzoNCg0KIkkgbm90ZSB0aGF0IGRyYWZ0LW1hdHRzc29u LWNvcmUtY29hcC1hY3R1YXRvcnMgaXMgcmVmZXJlbmNlZCBmcm9tDQpzZXZlcmFsIGxvY2F0aW9u cyAoZm9yIHVzZWZ1bCBhZGRpdGlvbmFsIGRpc2N1c3Npb24sIHRvIGJlIGNsZWFyKSwgYnV0DQpp dCBpcyBvbmx5IGFuIGluZGl2aWR1YWwgZHJhZnQgdGhhdCBleHBpcmVkIGFsbW9zdCB0d28geWVh cnMgYWdvLiAgSXMNCnRoZXJlIGFueSBsaWtlbGlob29kIHRoYXQgaXQgd2lsbCBldmVyIHByb2dy ZXNzIHRvIGFuIFJGQz8iDQoNCkkgdGVuZCB0byBJIGFncmVlLCBub3cgd2hlbiB3ZSBoYXZlIG1p dGlnYXRpb25zIGZvciB0aGUgc2VjdXJpdHkgcHJvYmxlbXMgZGVzY3JpYmVkIGluIGRyYWZ0LW1h dHRzc29uLWNvcmUtY29hcC1hY3R1YXRvcnMsIEkgdGhpbmsgaXQgd291bGQgbWFrZSBzZW5zZSB0 byBkb2N1bWVudCBpdCBhcyBhIGluZm9ybWF0aXZlIFJGQyB0byBjb21wbGVtZW50IGRyYWZ0LWll dGYtY29yZS1lY2hvLXJlcXVlc3QtdGFnLiBJIHRoaW5rIGRyYWZ0LW1hdHRzc29uLWNvcmUtY29h cC1hY3R1YXRvcnMgaXMgaW4gYSBwcmV0dHkgZ29vZCBzaGFwZSBhbHJlYWR5LiBJdCBzaG91bGQg cHJvYmFibHkgYmUgZXhwYW5kZWQgd2l0aCBhIGRlc2NyaXB0aW9uIG9mIERvUyBhdHRhY2tzIHdo aWNoIGlzIHNvbWV0aGluZyB0aGUgRWNobyBvcHRpb24gaW4gZHJhZnQtaWV0Zi1jb3JlLWVjaG8t cmVxdWVzdC10YWcgaXMgYSBzb2x1dGlvbiBmb3IgYnV0IHdoaWNoIGlzIG5vdCBkb2N1bWVudGVk IGluIGRyYWZ0LW1hdHRzc29uLWNvcmUtY29hcC1hY3R1YXRvcnMuIENvYXAgYW5kIEREb1MgYXR0 YWNrcyBoYXZlIHJlY2VudGx5IGdvdHRlbiBxdWl0ZSBhIGxvdCBvZiBtZWRpYSBhdHRlbnRpb24u DQoNCmh0dHBzOi8vbWVkaXVtLmNvbS9uc2M0Mi93aGF0LWlzLWNvYXAtYW5kLWlzLWl0LXRoZS1u ZXh0LWRkb3MtZm9yLWlvdC1kZThlZTk3ZTU3ZTYNCg0KaHR0cHM6Ly93d3cuemRuZXQuY29tL2Fy dGljbGUvdGhlLWNvYXAtcHJvdG9jb2wtaXMtdGhlLW5leHQtYmlnLXRoaW5nLWZvci1kZG9zLWF0 dGFja3MvDQoNCkNoZWVycywNCkpvaG4NCg0K From nobody Wed May 12 02:36:50 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 3B7643A3B67 for ; Wed, 12 May 2021 02:36:49 -0700 (PDT) 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 MJVCzkOk4-gP for ; Wed, 12 May 2021 02:36:43 -0700 (PDT) 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 B9E5C3A3B68 for ; Wed, 12 May 2021 02:36:43 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lglIG-0004KH-Gh; Wed, 12 May 2021 10:36:40 +0100 From: To: "'Lars Eggert'" , Cc: , , "'The IESG'" , , References: <162039183121.15574.16597240090409070575@ietfa.amsl.com> <29803_1620395762_609546F2_29803_68_1_787AE7BB302AE849A7480A190F8B9330353787B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <666D5FF1-9E96-4522-A0FB-0A3042225BE7@eggert.org> <17373_1620734755_609A7323_17373_63_1_787AE7BB302AE849A7480A190F8B933035384380@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <47273993-E4D3-4042-85B5-17163C984B18@eggert.org> <17932_1620739727_609A868F_17932_314_1_787AE7BB302AE849A7480A190F8B9330353854D5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <39AC6D5F-0FA3-4FE3-BD59-302B65CFDE49@eggert.org> In-Reply-To: <39AC6D5F-0FA3-4FE3-BD59-302B65CFDE49@eggert.org> Date: Wed, 12 May 2021 10:36:43 +0100 Message-ID: <03a501d74712$516f6fc0$f44e4f40$@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: AQEp71xGbs3/HDljMxiZ+ChpLivgHgKIHcrlApPqG38CEWvyxQJ3w676AJILkT0BGVdVmavfrZtg Content-Language: en-gb Archived-At: Subject: Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (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: Wed, 12 May 2021 09:36:49 -0000 Hi Lars, I will come up with draft changes if the below is acceptable to you. Please see inline. Regards Jon > -----Original Message----- > From: Lars Eggert [mailto: lars@eggert.org] > Sent: 11 May 2021 18:27 > To: mohamed.boucadair@orange.com > Cc: draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; The IESG; > core@ietf.org; marco.tiloca@ri.se > Subject: Re: Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with > DISCUSS and COMMENT) > > Hi, > > On 2021-5-11, at 16:28, mohamed.boucadair@orange.com wrote: > >> 1. The motivation for draft-ietf-core-new-block seems to be a lack of > >> performance with RFC7959. For a Proposed Standard, I would expect > >> there to be an evaluation that draft-ietf-core-new-block achieves > >> that desired level of performance over RFC7959, in a number of > >> scenarios of interest. This is to establish that the proposed > >> mechanism is fit for purpose. > > > > [Med] We thought that this is covered by this part of the text: > > > > == > > Libcoap was tested with complete packet loss in one direction (for NON) > confirming data still gets through, albeit more slowly with the > NON_TIMEOUT timeout for every MAX_PAYLOADS packets adding to the > overall transmission time. Note that CON fails under these conditions, and > as such RFC7959 fails to retrieve the body. > > == > > > > The performance comparison is straightforward as RFC7959 (with CON > messages) fails while the body is successfully retrieved using the new- > block. > > this says that draft-ietf-core-new-block works where RFC7959 fails. While > it's technically true that this makes draft-ietf-core-new-block infinitely > faster then RFC7959, I didn't understand that that was what the title, > abstract and some other places in the document meant - it sounded to me > that a performance difference compared to RFC7959 was the motivation for > draft-ietf-core-new-block? [Jon] No- performance was not the original motivation. We appear to have been focused on highlighting the performance benefits rather that this draft is supporting a missing piece out RFC7252/RFC7959, namely robustly supporting of Non-Confirmable using a block-wise transfer. It just happened that there was a performance benefit (as seen with TCP sliding window where each packet does not have to be acknowledged before sending the next one) which we got excited about. [Jon] I will look at updating the emphasis in the draft, including the title and abstract which were there from the initial drafts and never properly revisited. [Jon] The presentation given at Interim Core 13 May 2020 https://datatracker.ietf.org/meeting/interim-2020-core-04/materials/slides-i nterim-2020-core-04-sessa-new-coap-block-wise-transfer-options-draft-bosh-co re-new-block-01.pdf Slide 4 highlights the RFC7959 issue when using Non-Confirmable and lossy traffic, Slides 5 - 9 working through the issues we had found up to that point. [Jon] As can be seen the IETF 109 presentation https://datatracker.ietf.org/meeting/109/materials/slides-109-core-sessa-dra ft-ietf-core-new-block-01.pdf Slide 5 there was a lot of debate over the naming of this Block option and ended up with Q-Block - again implying performance. [Jon] As a side note, if returning acknowledgement traffic from the remote peer is getting dropped, the large request (or large response) will still get through, albeit with a timeout of NON_TIMEOUT every MAX_PAYLOADS. It is more important (certainly in the DOTS case) to get the information through than how fast could it get there. (Overall transmission rate is kept low, covered by PROBING_WAIT, with an upper limit wait timeout of NON_PROBING_WAIT). > > Because if it's purely about not failing, you could make draft-ietf-core-new- > block (much) less aggressive and all my issues would go away. Is that a way > forward here? [Jon] Yes, agreed. > > If not, and a performance difference is part of the motivation, I think a > Proposed Standard should refer to some analysis that demonstrates that in > a number of scenarios of interest. [Jon] I don't think that this is needed now. > > >> 2. For a Proposed Standard, I would also expect to see an evaluation > >> whether draft-ietf-core-new-block achieves that desired level of > >> performance in non-DDoS scenarios *without* unduly affecting > >> competing traffic. (Or else there needs to be an applicability > >> statement that draft-ietf-core-new-block MUST only be used under > >> DDoS, and a reference needs to be given for how a DDoS scenario can > >> be reliably determined.) > > > > [Med] We do have the following applicability scope (an excerpt below): > > > > The block-wise transfer specified in [RFC7959] covers the general > > case, but falls short in situations where packet loss is highly > > asymmetrical. The mechanism specified in this document provides > > roughly similar features to the Block1/Block2 Options. It provides > > additional properties that are tailored towards the intended use case > > of Non-Confirmable transmission. Concretely, this mechanism > > primarily targets applications such as DDoS Open Threat Signaling > > (DOTS) that cannot use CON responses to handle potential packet loss > > and that support application-specific mechanisms to assess whether > > the remote peer is not overloaded and thus is able to process the > > messages sent by a CoAP endpoint (e.g., DOTS heartbeats in > > Section 4.7 of [RFC8782]). > > ... > > This mechanism is not intended for general CoAP usage, and any use > > outside the intended use case should be carefully weighed > > > > I think that we do already have the guards clearly explained. If you don't > think so, can you please share which change you would like see in the > applicability scope? > > This says "only use this for DOTS". But it doesn't discuss whether draft-ietf- > core-new-block is only deemed safe for DOTS scenarios in which a DDoS is > present, or also in cases where a DDoS is absent, and it doesn't cite any > analysis into *why* this recommendation can safely be made. If DOTS uses > draft-ietf-core-new-block, what is the impact on crosstraffic? [Jon] Good point. I cannot think of any reason as to why it would not be safe for any environment that supports Q-Block (subject to the noted limitations list - hence comment about "intended use case should be carefully weighed") . As Q-Block1 and Q-Block2 are 'Critical', then if an agent does not support Q-Block, there can be a fall-back to RFC7959 Block. Also see next comment. > > (Also, in the IESG discussion the point was brought up that draft-ietf-core- > new-block may form the basis for a revision of RFC7959, so it's a bit odd to > see this strict limitation on one application and/or a very specific scenario.) > [Jon] Initially, the WG were concerned that people would see this draft as an alternative to RFC7959 (e.g. draft name of new-block) and wanted us to highlight the limitations and indicate that it had come about from the DOTS requirements. At that point, it was looking as if we may have to alter some RFC7959 block characteristics to get things working. After much discussion / brainstorming ways to handle Congestion Control / Recovery there is no longer any need to violate any of the RFC7252/RFC7959 principles. Hence the later WG thinking about the possibility of using this draft as material for a RFC7959-bis. > > This is so the proposed mechanism can be > >> recommended as the IETF solution for a given use case, without too > >> many restrictions. > >> > >> To be clear, that is not material that would be in the specification. > >> Such material would probably be presented to the WG early during the > >> standardization process (often at adoption time), and referred to in > >> the specification. In other words, I'm not asking you or the WG to > >> now go and perform this analysis - I'm asking whether it has been > >> performed already, because that is to me the deciding factor in > >> whether I can ballot "no objection" to publishing this as a Proposed > >> Standard. > >> > >> I hope this clarifies things further? > >> > >> Thanks, > >> Lars From nobody Wed May 12 05:04:54 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 C8C543A0BFD for ; Wed, 12 May 2021 05:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlKyim6r6adv for ; Wed, 12 May 2021 05:04:47 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2058.outbound.protection.outlook.com [40.107.20.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C403A0BFA for ; Wed, 12 May 2021 05:04:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E5w70ziWKrWSyuFAUpFxyMISrC74Pf7dk2szvo8fWx1KMv3RNqOGOhz6AcwPgQDmRI8fwcZ/nq8KaBD0f83UKCV/cRLAeI1b1YPcDwlnlufQZNiicvGJAxHO/JGTDdG/fDlPJ3fch8hLeBp40VtNQ5/MGsk1XXfwqNougjK/VtoZuKNdsr7LrViY51eY6h8XUop88pe57lnae+jdsFdKAHrVIKxM+XBx6t+H2KoEWXirPpX+rW3KAwtO8LgozvBKfV97CdqmrCgxmTH7Cv9Jtcb94EMPwiNBsJhhYHV/R0GoUxPsKRj5xuwFACZus8kC4hQ/QzFWkC5CC5H07tfvdA== 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=rkfJodspq77Hi2g2XyrAcj2w4e/tlxD5Yyns3SWj3IU=; b=HuQydGYYcz2sdI9k5LOXKUXrWQvl+HtW7KU28S/LDxKjrBoOcgCyVsL+A0UPZ+bH9QywN0INGP896jtkbu7cffvy+n8dCdgQQS8S3ZV2jrdm54CgmSlerqH5RdNiAqMuNICPCayR6/5T9f/jIshypAo6LZTwUDoSi//awFK8Loxrg4RjtM7iR3mDqgWrCeb+WtZX8lHyEy096DuM56L/3T41aS47edc2JoHcA+SRWBO91iF7cmkIDE68j68BnPguak+KEXjAP2tZ5MVDHttC8lE8f8YH7JYlwof2Q1oU6EWq3EtPmVQm6WL0kOpT+ngdH0fL6onQmQUOYH6EOC3YEA== 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=rkfJodspq77Hi2g2XyrAcj2w4e/tlxD5Yyns3SWj3IU=; b=B6x5E76B1Y4FSUutLieQalihiVscxy2Pwvw07/ayA93eQa+8tNZw008H5/MYPQcQgpwQLZFagNOwYUTDWwM8gE+2s1GDi+51Q4Xl8kiVblb/1hQghuGH3wSbtYO0AsYCz6FMzAM9O0vIkJxrF+RYadux+rcX3nklfy1Ix+rHIL4= 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 DB8P189MB0999.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:160::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.25; Wed, 12 May 2021 12:04:43 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::6918:90f9:e9c4:d3b3]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::6918:90f9:e9c4:d3b3%3]) with mapi id 15.20.4129.026; Wed, 12 May 2021 12:04:42 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: <83073aeb-c1c4-7c17-4a77-aae5d989c81d@ri.se> Message-ID: Date: Wed, 12 May 2021 14:04:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 In-Reply-To: <83073aeb-c1c4-7c17-4a77-aae5d989c81d@ri.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XyiJEWjOMf4FG0lRiX93uLpl8dJIbVqFQ" X-Originating-IP: [185.236.42.111] X-ClientProxiedBy: HE1PR07CA0005.eurprd07.prod.outlook.com (2603:10a6:7:67::15) 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.5] (185.236.42.111) by HE1PR07CA0005.eurprd07.prod.outlook.com (2603:10a6:7:67::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.11 via Frontend Transport; Wed, 12 May 2021 12:04:42 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4092a75a-4bb7-4b57-2e72-08d9153e205e X-MS-TrafficTypeDiagnostic: DB8P189MB0999: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:1013; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jiqcGrALY0vEHJ+dtlUu6wp41qahnMnmEMoEAnYT2+J7ogQXRT1d5OGKf4r56d5YJJQC+wuwGcR8sNmazWGwFh0F2hQtyUHilqCBTPw275b2EzsC4SnT+w4zj02oDfNZZ5RKSfnQg4ostbfOGCMj8SKxFiQsbC9NycYycPfDoG3feEn+YlmAQBECGPItVxI0LoWNdARioEea6P1oFQI/bdxjUtxKMTBQmu3b2858uoNY/z5eNksuNk9KYRhwCINzuhnFdBoRKkHNzzNonKZgpkGy6lXYnJOJNXJQ9cTxQyFADTIsNRgycHEhEc2BUlVp9vzQLjaTtlM/IfkZ8pUmC/YIKCWnrvDRBjNwpIfz0MW4NVrw+7pA5DhjJ3sB2gg2u4coWywWoZeCCeyYlEj5dlHDr8yeOcecbm48sYBpphqrjOu3fukh4ZPspbIApk9d4DqW04+5PtxKW33QA9Fit8Hx4kPO7KV2zLo4kv/Pn7GiutAc8UnALZpv5bQ2GOeVZEwrJfGrnCHoqQV7N7HvqRGsM/L6fgDgKE5Y+h9mFHTJ0m4p/32XSyLrtEcXyLIpwmFywLZXjiNb+1P2RAf6b0OntYHZZFDwUNxihsv8V9oDT7h1YqHugyoZBvQdYDY2pFTcFtlUOELxXJedgaJ7261Ye7oO8sjsZaeYDPE+PvOaXmudPJDiwxGB/zIZ84yBLcTGgOXOMcFTLDi5Pxv8sjb4CxlrkzkyvjI/2tqXD1mO4C2zBzljEXuaWKTNo/ofB6UOVuQkXe20XChJzJqbaA6rzTMchTtkVW5B9IreLxQ= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(136003)(346002)(39850400004)(396003)(235185007)(16526019)(186003)(2616005)(2906002)(5660300002)(26005)(956004)(38350700002)(478600001)(966005)(66946007)(66616009)(66476007)(8676002)(6486002)(38100700002)(66556008)(8936002)(33964004)(16576012)(44832011)(31696002)(16799955002)(53546011)(83380400001)(316002)(21480400003)(31686004)(86362001)(6916009)(52116002)(36756003)(66574015)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?ek9mLzF6VXA2dXNudXNwWGN0WGFzYlNFM09wak1VMXZQajh5MEtHVHJxUlYz?= =?utf-8?B?U245NlV2Ym5ZbkJuMzhUN21IZk41MVJ1U1N3ZEpuYUNoancxajFCczQ2L24r?= =?utf-8?B?NG02N0RMZWYrdmxCQUN6OXhKRDJBZHNNRVJiWmxJWldOZ3NyKzMweDZvbE1p?= =?utf-8?B?S1hsRUt5WDg2OEQyY295NlpYclZGZ0VycDdWQ0NwNCtIZGJObms2SnA3TTRF?= =?utf-8?B?NzVqTk52UUUrNHFqUHFkM3poa0JyREZmSGkyZlp0YXpPd1Y3dkFZNHBQY1JE?= =?utf-8?B?dW5pUmdoRXBGcTc5RFRncGJ5Z2dubTBmRzlEUTlhQVhOUlU5NTA2aUZLbUpV?= =?utf-8?B?RFVxNEV6WHhudnZIZ3F6SkZuT2d3Z0JuRTl0ekg5SmNqbVBHN0V3aDU4eVUx?= =?utf-8?B?bzkxN3A3OTdtNDRQSGlmMW5sMlo3QUpMTUNYUHBSMnBQQkxqV2NaVTVIeElo?= =?utf-8?B?MUNzVXlBeXI3eHVIRjVHSitoYW5TWUpvVFVpZ1F6RXZIQW12aXJXV2kzT1Bs?= =?utf-8?B?ZDVqWUF5UzBKV01CNU1id0d2L203NlY1WlRGSEJwZkxNU01sa01la0Z3a0sr?= =?utf-8?B?WWdKT0xjT1dxbkxvYldVRSsyT1dNbmFlRVEvRWV4c0tVeWpCRUVzUW0rM2lN?= =?utf-8?B?UmErNGhsWm9ZbEEwZ0l1RE53WVl5ZzlTUVNrWm45alFVT3dCempucUcwZkI5?= =?utf-8?B?MFk1SG5WTzd2d1dkcndkMmc0d0t0Z3JxZXVCQU5lMVJ1YTB5aDlqMFZyRTFw?= =?utf-8?B?SVVSYzVnTTNmc05wbUE2NTRsTytUYlVNV1FzMGN5SE9lN2ljdkV0cFJrbXBS?= =?utf-8?B?d0N4WlQwa3AzSngwME9VTklTMk51cVdRTUhYaDhDSjZNMkY0U0lseTlwNlBS?= =?utf-8?B?bERjQ3ZJUHEvR1IwTldZb2RjOWQrbGNaSGtlWHFYZWNnNDZPK2xNejI4YXYv?= =?utf-8?B?bGphYnplcGNZWVA5RlBRQnNZQ3FYVmJLc2JpMTR2aW5LV1B5L1p1UFVhOFVC?= =?utf-8?B?TkN0ZHdDZThiN2l4RTV3UzhRRjQ2TU1ERnZOY0RkbVFmdVFVZDBQQm1BMGhM?= =?utf-8?B?dFliMkpQNWx4cHlkRGJzcDE4UnNnNHRENTQwU2FFVDI1WFdLQ3lMK1VWZU1r?= =?utf-8?B?TWdqb0hIRTVJSWJxcFZsSXRaL0V2YUxEUnUwdUNRaUJGWmdvVXZaL0tWOEw4?= =?utf-8?B?MXFoVDl0OS9zRkxObWdVU2lXcDV4UW41VW5PcnZwSDFscmFUbllnVWxjUkh3?= =?utf-8?B?YTI2WlhWNnR6c2thVzNaRlo0RVdLRE0xUVRaSkgwY3k2a2VwSG5TQkVpeW1J?= =?utf-8?B?TjQ0NW5nL0tzMXdEaWhEd3I3SWprZVJ2dExQWHhrUm5lN0o1am5PTkNtclFY?= =?utf-8?B?Y3ZwdjI0b3FQUWdKYVdCbWlJdU1yOUQ2cU9QenBnWUh4MlZBZm9jVEdHeVA2?= =?utf-8?B?R2JuUGZKUklzYldkVkptOEZyenhPdjZNeUhVenJoSi9McmF2aW0zVnppcjI2?= =?utf-8?B?Vmdid0s5OEdPVi9GYVc3enp6SGNyTWk4dkd1TkIyOFlDN01rYlBKOGZkTGtK?= =?utf-8?B?dk9uV3ZHTklMVDkwQU1idVRlMTZNWlE1Z01ndTBnVEx1TGxZczVhek02VU1X?= =?utf-8?B?Q1cvT1dqM1g3Z2ZUOUJnYVdsYmxjYWhlMkZUNGNRQ3hXajNyVTcxSXIwRnBw?= =?utf-8?B?OE9uSmhhdXcvN2lOTkNVRUxPYzl1REJkOXBFNmllY21ueGw2dXZ2YTdkZm1o?= =?utf-8?Q?34fHxCSLZVxtLCtg0S+obQrbyQYqqrp3lJChPFR?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 4092a75a-4bb7-4b57-2e72-08d9153e205e X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2021 12:04:42.7313 (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: PwyJzOcjC9mD0HUT+tL7kGBMnpY2dJnt7uQz/f0rkSQoYJnv/NtPoEmOVMq/bAfjxrL5kB5OUizSAaWY+TF0UA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0999 Archived-At: Subject: Re: [core] CoRE WG Virtual Interim 2021-05-12 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, 12 May 2021 12:04:53 -0000 --XyiJEWjOMf4FG0lRiX93uLpl8dJIbVqFQ Content-Type: multipart/mixed; boundary="hMtllkN3Cm1GkxI7SylrqEAb8kfIp3zcb"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: Re: [core] CoRE WG Virtual Interim 2021-05-12 References: <83073aeb-c1c4-7c17-4a77-aae5d989c81d@ri.se> In-Reply-To: <83073aeb-c1c4-7c17-4a77-aae5d989c81d@ri.se> --hMtllkN3Cm1GkxI7SylrqEAb8kfIp3zcb Content-Type: multipart/mixed; boundary="------------3DD17DB0941FD21B2FEAFC5A" Content-Language: en-US This is a multi-part message in MIME format. --------------3DD17DB0941FD21B2FEAFC5A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Dear all, Just a reminder that we are having our virtual interim meeting in=20 slightly less than 2 hours [1]. Please find below the information to join. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/interim-2021-core-05/session/cor= e =3D=3D=3D Meeting Information =3D=3D=3D Jabber: core@jabber.ietf.org Etherpad: https://codimd.ietf.org/notes-ietf-interim-2021-core-05-core Meeting link:=20 https://ietf.webex.com/ietf/j.php?MTID=3Dmb2d62b1da561183acc59e83e93a5dae= 6 Meeting number: 185 242 5774 Password: constrained More ways to join Join by video system Dial 1852425774@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: 185 242 5774 On 2021-05-10 09:06, Marco Tiloca wrote: > Dear all, > > Just a reminder that we'll have a virtual interim meeting on=20 > Wednesday, May 12th at 14:00 UTC. The agenda is available at [1]. > > Best, > Marco and Jaime > > [1] https://datatracker.ietf.org/doc/agenda-interim-2021-core-05-sessa/= > --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --------------3DD17DB0941FD21B2FEAFC5A Content-Type: application/pgp-keys; name="OpenPGP_0xEE2664B40E58DA43.asc" Content-Transfer-Encoding: quoted-printable Content-Description: OpenPGP public key Content-Disposition: attachment; filename="OpenPGP_0xEE2664B40E58DA43.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Za= RDP C4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt0G4Ck= Unq 5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0Kh1T4WUW6= NHf EWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+NrSetJlljT0QO= XrX MGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEBAAHNJ01hcmNvIFRpb= G9j YSA8bWFyY28udGlsb2NhODRAZ21haWwuY29tPsLAewQTAQIAJQIbAwYLCQgHAwIGFQgCCQoLB= BYC AwECHgECF4AFAlSNerkCGQEACgkQ7iZktA5Y2kMiuwgAt/bVZKqD92JNWDTX6h1MUsgejwj4R= Xs6 UYqFdWW/4nw4mFHzYS+gBjOQAWCBhzVZLOk6gKcRZ/s86ncVygiDUh9fbSDTcuzOp2qgu9nsc= 8sE sYp1hwmiIEbI6FHPtyeQQNilsfU8+VHX2C9yQtMK/OXlf5qNkJMj9k55u+e1ELQ2sjUXkMB4M= xMh mi/3P3hMz9PDcB66BtQcDFYkx5PIaz/izCST0o28AJq0dionJpPsQ+hFOIAkJi6aCAt3xQf0K= nXl AczWxCD3J3XTFK4MES/b3n3oc2GJY8I+tsfT5jpNsWhfWGBkMaQSKZ939D4oFAhAq3gnNRgZs= zJe TvsMvcLAeAQTAQIAIgUCVI15FQIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ7iZkt= A5Y 2kNZdgf/drEFkXWpz9pPm0/ZwNNfXzHkpGLqcfPlvQaSNFFboHwJaeKZ6s3dCGpzDlV6bLrRM= 9LN /sgNRT0eNiElJHtKDW/fqvzrHl3LCsDKed4LK4Gg2mE0nvWvTno9Nyza8TatJm1+V2S7MbDgS= E/F 26QK2VL9Y/ur5BHgUI34mUar4iE1Aq7nsFbN6NEvamyQPWlkN+rCjtnT0+NLGb5VnDVKAHSgi= YgG QeDvlisWb9NtsxzXf1qge3tlCufadSWXyqa4oOq4hEcD3GBUQVuGfBNa7r0mqHzVZf0qd+Kxz= s6D p9LxTGp7aSjiXN6cBoapz7lSP0wXOgSzIJ1X2UtVssKv28LBYgQTAQoADAUCVZFCzwWDB4Yfg= AAK CRBo+Jp/4mFufTrAEACwA4G0VlNs1JOAMgIOfE96v1lVsJiI9qod5Njc1jlXqItPKDXzvmTJA= Cy7 JfA2UbRbwkym7eCc94jkQU6XdTzv8Qf6rpbVZhzF9tNL38mzm8emh5vV3XDy8arElEP7bE9Jf= gm2 3Lm9OEwubbtjLYf0z7poncThsYUuaEexnxUVF/PXNMIlVBXil/27HkhuWKhpJQU7A35YiJz+l= alf GS+9OSv9nJD9mdoTNk4eSG2sfYKRKs6rmN3X+J9ZITs9Hnpncgu3coayZaL69iicZ4ge1KXAC= iGG 0zpK666d5ByWgWU7PRqiFIkXwHDW1esZ/QHIJFIXN9zpCD5KaSctvj+tFPNTz2+quiVSnWWQF= v/9 2zRTS4SJgxXP6I3nTasuC6KJy+JnMNfzOVpj05Ef1lXuncc4kLCqd2As1S6e/OC5Mdo5jQhe0= Ozj u5IwhRCoqKe1huSj4mbpaTvCjKyh67zVsJR/xDHFDzgtdoCsRRQQxWME8+V95FqsleNd1QfEU= /jM +HS4JWTDwFs+f1kHzzwhDHWs73M0/jvs8mUGlfRwSQVDfN6ygbuCn/i2Lvvtc2RWbxWGJVekG= 8x2 rFxUOQ7B2DqmxBrRX3GLokNJ7eWrLNLlYXGA7ptoGWLKQ1FcNNIgapKbxd0s5+s3ql7EaGViJ= 84o zNX5q52bRceaSihi4s0cTWFyY28gVGlsb2NhIDxtYXJjb0BzaWNzLnNlPsLAeAQTAQIAIgUCV= I16 cwIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ7iZktA5Y2kNxXggAhFyfi+VlqgIj5= a54 npaUoREoQ5Tj8gzUPmqOXddo0q9f1cQn/+ehKpbb3TDVzO35HBXZvuFGn5DHBUYhqBFWTx+H5= zHg GBRhF0imQ9Yi/gHe2StgrSIa5528iV2g47OyDDlSCoCWEM4WwWkJqv9CP2J53Gb63UOPuq5j+= BF9 wtDs6M6YAs9GdHIDhvUJWGDhOZevyp/DWE5d3LCI+HJIajDjhJK02kVg47aBusW40mGXmjWmt= JXP +QtZRfSaabFxCVE3APBn+P4zuyb+mk1gwkN51OiFuYQr1ig3M55kaoGbrs57fVuGtaC9DSc1v= gai cJQrYpCbOrbR/yZAedz3xcLBYgQTAQoADAUCVZFCzgWDB4YfgAAKCRBo+Jp/4mFufWd/D/9PO= 2eZ HdU0Rxr4f0EmNqhMnA6KKIo141DQnpQNqHs0RUgDlDUN1qHjgv1Uxu3gbtJoQ4PbT9rJan4Oe= m7/ NJQxU6tsa/dFjDyn9txVGppd12pVFcnGRcDNhLDzALgZN1ABxfpOh4hQy79qn69Stn0GsSnK6= gEq /+3+KROA0ZKEDWcE2rVEzw4UEv37BUaVnBnHYvNQRQVY8hc43qi3WWUhM3Ot0Z+peAV7D3Y5Z= kaS LN6kFoZPZFhrf0fhlLx0ajFIIRDQ8R8ThXXcRopWhw+ifUFdtXoW0goWPFqOkgJw1HYNbYjT4= G4D vUAYt5ueCOP6MNXEkDS4r1Hz5JDemtee+FIoaIWbma+ccL3gceoQXwvMtNu1MYFN/n13YYlqw= g9A yIkobG56OeW4o9qqkNjb3GlX+cw6f4uf7l29IF7i3jOFh4GXlYoevYiw9EpnqLWkWgm5KbT+J= 9h/ tkgt99GXfGkfLzpyjU563esgxpIwWX586ssWlbJWlAPzCf3do08MiLWTRVcrY6pXVTGAF/c41= uC6 520+RFm4ytAfrefNac1+5eZBG5k84sTdV9aamCAWkUIEaNQkTfMB7xSXAlq2T8I+kHJCsLSKX= XPF djMJtVRWSZ/gzaBE7cbELu9KaHyVRAxNKSsMInAmn/FsxnW6VFaseoT5OtxTMuAnROjB0M02T= WFy Y28gVGlsb2NhIChtYXJjby50aWxvY2FAcmkuc2UpIDxtYXJjby50aWxvY2FAcmkuc2U+wsB3B= BMB CAAhBQJaQCeQAhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEO4mZLQOWNpDAS8IAIko8= kg8 YfSgacsljgbUjYOA2LJUq3UfiSRz95PwHP05JsDGBmjcmTLfzZ7gNtprJatBEV6fRotIW7NtT= gFf g79hFJoipQ7crBQ07WJMLrk4fPReKsaiE9Q6xzRIQy2mb7jN9gbsbynfkwrSH2CnCAYwbSPSZ= lfh EOO7LALzyLVXELAxYZplGVSs9eQLeeoMNFw+24QamdxaEBVC3Zmp7IhO/0oJSYOe2Zcs97q8R= e05 8j1ncd6p4jw6QbBemi1WhuAtr+ZWYWPoQAsPOPscLa61+DEQIEl12ZwMieu8aBORm1cRVvItC= 6Ir bSUmZieY9Y3wNdpVVpDhc/+VdSvOgTPOwE0EVI15FQEIAJaan6TouRjj97Lt4Du6ZhVzbaLJW= oAR ebLANjMSN7BjBFyNOsf83HUSrCMgO5b4EESgwtFk4cKCaOjodGZYi61xhUK32J6iS6W2Siv0E= GhB U+Ij5OnnU6nTaJ+QZysRA1mLurd+Y62EVnBno0mdRsDZvJxopnygKW8MJCPoCMTJ0E+dLvdRo= SgO yqwZWNnAKF84yDk7IWb3RCOkjDybS4NVwLMop/GrdP/Pu3JGC5whR7zgTMG64kERISMr+EXSd= HYs OHVKEPb0VasVlI1VUJW7VRhksBrJ/ygoocekz7CF+MRg7hewOlXjNDXkD4PXkdGIdHoB1/g8O= 08z UMLCCCMAEQEAAcLAXwQYAQIACQUCVI15FQIbDAAKCRDuJmS0DljaQ8YTB/9Y2NPLfPvi8uYfJ= xWw VdehDxbX7znyZHIB3RrwljNjfEHsJW2ojcfLz3hBzDgfobv30DU4v0HUR4DxiPdo7PQ1tTJ/k= Zb6 Ki2veHz4ogI5hnfj8FBo4vN28M2ZGgYef415POEXt5J6I8qLaN7H41Wh2GM5UZfDwSFgaR5ku= /Kc cRuiIszhNvI9tVH0ex1WooZVMPEpITedqajeS+1jqzJEUiJTPlbMl9gC6pu3qbdPEMRvywD2n= Nou 6GZ+clFzXYfk1VkRmYT8SQkVOWQ/jCdnI5J/+vb9V3SIdq4HC/ntyljocUUx7uu8rizswTnNy= 04S XLkLo0K7Vlo211S6oNI8 =3DAOQG -----END PGP PUBLIC KEY BLOCK----- --------------3DD17DB0941FD21B2FEAFC5A-- --hMtllkN3Cm1GkxI7SylrqEAb8kfIp3zcb-- --XyiJEWjOMf4FG0lRiX93uLpl8dJIbVqFQ Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmCbxFgFAwAAAAAACgkQ7iZktA5Y2kMp Xgf/cMIWehJQuX4IM8i3jrvMighOpOh5YoF7G7kMJs8ssLjowxZ6yegrrp1qSk6sidA3Yppia+zJ XjljrPSTaPfgrq8w//KjCRMEC5OcvLNkKgfYNWdGIsBQVF0QA71Zx/paRBECXYtQ+4LhIgK+xwv+ 6KFiP1oLZ9jS+nNLjTy4We+elEAKW6KKs3jmLEdHrXouo3/2iccyMoNxY81shGk9dXugf9chcIkw JZFJoZRJV9ohSg42PKNeZo1/pblHs1isibKWqdxVuOJXq7geOA0jYz/5FT/IFXCd9cJhOeyrpyUY 2ZIWK/f4gd7d71Capf4FeoO6pxF4MoYB7bcKbQMRsw== =n9H/ -----END PGP SIGNATURE----- --XyiJEWjOMf4FG0lRiX93uLpl8dJIbVqFQ-- From nobody Wed May 12 07:59: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 C47F43A0883 for ; Wed, 12 May 2021 07:59:49 -0700 (PDT) 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 JhCX-w7a6wsg for ; Wed, 12 May 2021 07:59:44 -0700 (PDT) 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 839483A0874 for ; Wed, 12 May 2021 07:59:44 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lgqKr-0004UL-4v; Wed, 12 May 2021 15:59:41 +0100 From: To: "'Lars Eggert'" , Cc: , , "'The IESG'" , , References: <162039183121.15574.16597240090409070575@ietfa.amsl.com> <29803_1620395762_609546F2_29803_68_1_787AE7BB302AE849A7480A190F8B9330353787B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <666D5FF1-9E96-4522-A0FB-0A3042225BE7@eggert.org> <17373_1620734755_609A7323_17373_63_1_787AE7BB302AE849A7480A190F8B933035384380@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <47273993-E4D3-4042-85B5-17163C984B18@eggert.org> <17932_1620739727_609A868F_17932_314_1_787AE7BB302AE849A7480A190F8B9330353854D5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <39AC6D5F-0FA3-4FE3-BD59-302B65CFDE49@eggert.org> In-Reply-To: Date: Wed, 12 May 2021 15:59:43 +0100 Message-ID: <041601d7473f$7113e540$533bafc0$@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: AQEp71xGbs3/HDljMxiZ+ChpLivgHgKIHcrlApPqG38CEWvyxQJ3w676AJILkT0BGVdVmQE5F4wPq9ZR+dA= Content-Language: en-gb Archived-At: Subject: Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (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: Wed, 12 May 2021 14:59:50 -0000 Hi Lars, I have come up with some initial draft changes - do these work for you? Please see https://www.ietf.org/rfcdiff?url1=draft-ietf-core-new-block&url2=https://raw .githubusercontent.com/core-wg/new-block/emphasis/draft-ietf-core-new-block. txt Regards Jon > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: 12 May 2021 10:37 > To: 'Lars Eggert'; 'mohamed.boucadair@orange.com' > Cc: 'draft-ietf-core-new-block@ietf.org'; 'core-chairs@ietf.org'; 'The IESG'; > 'core@ietf.org'; 'marco.tiloca@ri.se' > Subject: RE: Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with > DISCUSS and COMMENT) > > Hi Lars, > > I will come up with draft changes if the below is acceptable to you. > > Please see inline. > > Regards > > Jon > > > -----Original Message----- > > From: Lars Eggert [mailto: lars@eggert.org] > > Sent: 11 May 2021 18:27 > > To: mohamed.boucadair@orange.com > > Cc: draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; The IESG; > > core@ietf.org; marco.tiloca@ri.se > > Subject: Re: Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with > > DISCUSS and COMMENT) > > > > Hi, > > > > On 2021-5-11, at 16:28, mohamed.boucadair@orange.com wrote: > > >> 1. The motivation for draft-ietf-core-new-block seems to be a lack of > > >> performance with RFC7959. For a Proposed Standard, I would expect > > >> there to be an evaluation that draft-ietf-core-new-block achieves > > >> that desired level of performance over RFC7959, in a number of > > >> scenarios of interest. This is to establish that the proposed > > >> mechanism is fit for purpose. > > > > > > [Med] We thought that this is covered by this part of the text: > > > > > > == > > > Libcoap was tested with complete packet loss in one direction (for NON) > > confirming data still gets through, albeit more slowly with the > > NON_TIMEOUT timeout for every MAX_PAYLOADS packets adding to the > > overall transmission time. Note that CON fails under these conditions, and > > as such RFC7959 fails to retrieve the body. > > > == > > > > > > The performance comparison is straightforward as RFC7959 (with CON > > messages) fails while the body is successfully retrieved using the new- > > block. > > > > this says that draft-ietf-core-new-block works where RFC7959 fails. While > > it's technically true that this makes draft-ietf-core-new-block infinitely > > faster then RFC7959, I didn't understand that that was what the title, > > abstract and some other places in the document meant - it sounded to me > > that a performance difference compared to RFC7959 was the motivation > for > > draft-ietf-core-new-block? > > [Jon] No- performance was not the original motivation. We appear to have > been focused on highlighting the performance benefits rather that this draft > is supporting a missing piece out RFC7252/RFC7959, namely robustly > supporting of Non-Confirmable using a block-wise transfer. It just > happened that there was a performance benefit (as seen with TCP sliding > window where each packet does not have to be acknowledged before > sending the next one) which we got excited about. > > [Jon] I will look at updating the emphasis in the draft, including the title and > abstract which were there from the initial drafts and never properly > revisited. > > [Jon] The presentation given at Interim Core 13 May 2020 > https://datatracker.ietf.org/meeting/interim-2020-core- > 04/materials/slides-interim-2020-core-04-sessa-new-coap-block-wise- > transfer-options-draft-bosh-core-new-block-01.pdf Slide 4 highlights the > RFC7959 issue when using Non-Confirmable and lossy traffic, Slides 5 - 9 > working through the issues we had found up to that point. > > [Jon] As can be seen the IETF 109 presentation > https://datatracker.ietf.org/meeting/109/materials/slides-109-core-sessa- > draft-ietf-core-new-block-01.pdf Slide 5 there was a lot of debate over the > naming of this Block option and ended up with Q-Block - again implying > performance. > > [Jon] As a side note, if returning acknowledgement traffic from the remote > peer is getting dropped, the large request (or large response) will still get > through, albeit with a timeout of NON_TIMEOUT every MAX_PAYLOADS. It > is more important (certainly in the DOTS case) to get the information > through than how fast could it get there. (Overall transmission rate is kept > low, covered by PROBING_WAIT, with an upper limit wait timeout of > NON_PROBING_WAIT). > > > > > Because if it's purely about not failing, you could make draft-ietf-core- > new- > > block (much) less aggressive and all my issues would go away. Is that a way > > forward here? > > [Jon] Yes, agreed. > > > > If not, and a performance difference is part of the motivation, I think a > > Proposed Standard should refer to some analysis that demonstrates that > in > > a number of scenarios of interest. > > [Jon] I don't think that this is needed now. > > > > > >> 2. For a Proposed Standard, I would also expect to see an evaluation > > >> whether draft-ietf-core-new-block achieves that desired level of > > >> performance in non-DDoS scenarios *without* unduly affecting > > >> competing traffic. (Or else there needs to be an applicability > > >> statement that draft-ietf-core-new-block MUST only be used under > > >> DDoS, and a reference needs to be given for how a DDoS scenario can > > >> be reliably determined.) > > > > > > [Med] We do have the following applicability scope (an excerpt below): > > > > > > The block-wise transfer specified in [RFC7959] covers the general > > > case, but falls short in situations where packet loss is highly > > > asymmetrical. The mechanism specified in this document provides > > > roughly similar features to the Block1/Block2 Options. It provides > > > additional properties that are tailored towards the intended use case > > > of Non-Confirmable transmission. Concretely, this mechanism > > > primarily targets applications such as DDoS Open Threat Signaling > > > (DOTS) that cannot use CON responses to handle potential packet loss > > > and that support application-specific mechanisms to assess whether > > > the remote peer is not overloaded and thus is able to process the > > > messages sent by a CoAP endpoint (e.g., DOTS heartbeats in > > > Section 4.7 of [RFC8782]). > > > ... > > > This mechanism is not intended for general CoAP usage, and any use > > > outside the intended use case should be carefully weighed > > > > > > I think that we do already have the guards clearly explained. If you don't > > think so, can you please share which change you would like see in the > > applicability scope? > > > > This says "only use this for DOTS". But it doesn't discuss whether draft- > ietf- > > core-new-block is only deemed safe for DOTS scenarios in which a DDoS is > > present, or also in cases where a DDoS is absent, and it doesn't cite any > > analysis into *why* this recommendation can safely be made. If DOTS uses > > draft-ietf-core-new-block, what is the impact on crosstraffic? > > [Jon] Good point. I cannot think of any reason as to why it would not be safe > for any environment that supports Q-Block (subject to the noted limitations > list - hence comment about "intended use case should be carefully > weighed") . As Q-Block1 and Q-Block2 are 'Critical', then if an agent does > not support Q-Block, there can be a fall-back to RFC7959 Block. Also see > next comment. > > > > > (Also, in the IESG discussion the point was brought up that draft-ietf-core- > > new-block may form the basis for a revision of RFC7959, so it's a bit odd to > > see this strict limitation on one application and/or a very specific > scenario.) > > > > [Jon] Initially, the WG were concerned that people would see this draft as > an alternative to RFC7959 (e.g. draft name of new-block) and wanted us to > highlight the limitations and indicate that it had come about from the DOTS > requirements. At that point, it was looking as if we may have to alter some > RFC7959 block characteristics to get things working. After much discussion / > brainstorming ways to handle Congestion Control / Recovery there is no > longer any need to violate any of the RFC7252/RFC7959 principles. Hence > the later WG thinking about the possibility of using this draft as material for > a RFC7959-bis. > > > > This is so the proposed mechanism can be > > >> recommended as the IETF solution for a given use case, without too > > >> many restrictions. > > >> > > >> To be clear, that is not material that would be in the specification. > > >> Such material would probably be presented to the WG early during the > > >> standardization process (often at adoption time), and referred to in > > >> the specification. In other words, I'm not asking you or the WG to > > >> now go and perform this analysis - I'm asking whether it has been > > >> performed already, because that is to me the deciding factor in > > >> whether I can ballot "no objection" to publishing this as a Proposed > > >> Standard. > > >> > > >> I hope this clarifies things further? > > >> > > >> Thanks, > > >> Lars From nobody Thu May 13 07:15: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 C305F3A012A for ; Thu, 13 May 2021 07:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 dSc2rU0EBZA8 for ; Thu, 13 May 2021 07:14:56 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0622.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::622]) (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 C4A4C3A0AFD for ; Thu, 13 May 2021 07:14:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IR6ArTeVs7JOXQJ7yBmWKtFdYqyU36N2dBpq+Ut8KVAe0Hn5aOhv7to/nJhyH+yl6jwn0Gftd5s9Ww9IaLsw3cByAAe9sMP9IU/K90LLgVwV1r9dJVpg0MSSFyV8iivz65vZ6RPkSAdRrINmlW9xt3awvtG/EqZmu/E+lhG0bEiZED6LNGxf65BiV3HnE6Dm2S+GLijKhsAavCUCQ2Cxrj95xeoTyAggYAbJ515ZmtdgOokZLexkQx/N8WdWkq7hka2S+N/HXpqHDRZgrRkJ/0BoWO7ZZpOMtlbSzBnSWMOu8g+fl9H9uu77VVSsnf4B2ZptWEAhe6AyMXBynzzhRw== 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=oZCU8Z+lN2yBC+qBn2U0VdYciTeZBseKX2cECQcf6WI=; b=QNiU3ksh0vZDo9EUdY2VFh85Hun9DYKTWsbc6eG9FkBFj1fuJ51jsGtLu2HkkAJtRSYDlc641GozQxkZRKVZcd9ryozxDvNv1nHMJB2v+Vd4J2UBeOBBOPSPRmr+0DxpaSBc87BP0SGk96Fu5FuwXJOCx/jmfWBl1s4w/nj+9C44jmLXVsH+6Eqdk+2lVQw4fbosXIe469AMvk9q3fR7wWKPlTF4SRC5sBXE41PtDW+/tEYdOa4Agxa7nHJOqwo7+VnYTMjUdq99TeYGR83IoRd+o1hzGRzD9b0iNBO8fjevxzNp+4lhu3PefiZZdKg76Tjr2l5fsw/JlanooL9p4g== 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=oZCU8Z+lN2yBC+qBn2U0VdYciTeZBseKX2cECQcf6WI=; b=h7KKLXXrDLCGv/9WfOv4OHaautShbLoqFpDTiiJZC9cKJapSBDGkkmECvyg6s/1O4zHKFvNfPsZkHb4QUAhe0fPlVoPwCmM955SuzFFk3ehWpLBsZUmno7OZUmrTkQC2Lk9amk3ocrX/pBCPJ8TE9pXz2cy4VPEXTf5eEmd8szM= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR0701MB2826.eurprd07.prod.outlook.com (2603:10a6:3:4a::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.23; Thu, 13 May 2021 14:14:46 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3%11]) with mapi id 15.20.4129.026; Thu, 13 May 2021 14:14:46 +0000 From: John Mattsson To: "core@ietf.org" Thread-Topic: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8 Thread-Index: AQHXFxduXoz8+3g8k068F5hdSGPXPqqFSp2AgFyI4YCAACSAgA== Date: Thu, 13 May 2021 14:14:46 +0000 Message-ID: <2EF50329-22AD-4797-B8F5-89684E4CCC29@ericsson.com> References: <46B45227-684C-4CDB-A2B6-20BA70E89DF6@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ff386860-5626-442f-30b7-08d916197633 x-ms-traffictypediagnostic: HE1PR0701MB2826: 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: 62VaYu/hHKQeIVWBgzBos5C0W9mIamooU90lQIKOSOilWPnvWk7uJyjthndvKnW1KSkF/wI4uNcwc1cLFezKQWSBSzIG3HR2O2doPKkHukFhsS34/tkysuO9MiA05dnD3w+LHWoSx61VGPeEu3gHgyfVRkx/h8KXkmmpMOao/M78Xfmw8OBc+DyWEswKsCKO/r4yq81kGRRE64e+6q6g9HvspEQX3B2Me/RifYQGV2NbFFKFsHs+XmAsP5jQsaaKYSs6+Lp0FI1Xhb+53aBqsJlT2JvGf2vcfk8JqOx4KIhlIl+ejL6JsoYwpKU0+5jDfK254n+j76YA2xkvyNsYouI/C6i+zCwJSkYrZs/IXPfKTfcn8znB2XSgATmeKAKJ8ThJt8e/i19NqvjMzApVCk8QD8nCbX81YoJcazLLTn9U29cSBNen7NJJHeoPmzeQYcKEsZ7jhejH2lH1zGs7+tGqRGAkyPEFqiCKxfQbg5YUUZqORmhACXpQuY/axNYV8etODBUUNG+k/dGGqkU1+wF6x5gUuoLlfju8yyjH3esKwkuirrnIdeP1aPDr0p8yGAGfjuO6ryrrRB33Veg9lCM/BAcK1u3NdrxGuXvTvHUgBYYSSGYph8zvPMuQ1w7kHnslifGinz/B1EzOgxfdrUNbBxao9zZ7XjRzHi5Kw5OHvmrMt4a4opWqLJ1+kJNVActsB0T70gJnYqZwth8SGWQyTKQ/u0YNqgwUYPnMoZ8xN+j/iD/mt6Kz6xVBF4AaDmpnY4anl6p+5/ES5PXKPg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(6486002)(66556008)(498600001)(6506007)(5660300002)(33656002)(966005)(53546011)(76116006)(122000001)(66946007)(36756003)(86362001)(8936002)(71200400001)(6512007)(2616005)(44832011)(8676002)(186003)(64756008)(66476007)(66446008)(83380400001)(26005)(38100700002)(6916009)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?d1FjWUZTd05OdTVQL0VtV3NCbGs0UDZOWlUydFRjY0pSTG9CM0xETFEwYkxn?= =?utf-8?B?cXJDMW1saHFTc011Y1NLM29YTFBwRVhSV0tLQzFZSGJjZ1djVXc2Qm5CMFVq?= =?utf-8?B?ZEdxWnVDS0pNMVZxTzQ1Y0hVNW91Mjk1QlFpTHNSQ3VBY0U4eHNpOFlsdFcv?= =?utf-8?B?SktZZHpTMjh4YmZ0ZTBIbjdoUDRNZ2dlRWorNDB6L0RKQzhNNk5oTG1IdStw?= =?utf-8?B?cGFYSWhkcll4WFNodCtMWGpBKy9Edjc3Y0ZaRko2ZzU1ZVQ1cGFDSk1oQVBs?= =?utf-8?B?KzE4NkQxOTUxa0RTcXYvQTMyZm9yZk85UVV5U0xKeUE5UDNtZWVra2tTbmFR?= =?utf-8?B?WnVTTWkrMDBJU2VXUHIxV3M2d1NzejdpQUplWUMxcnlWSFVhekIzQktER2d4?= =?utf-8?B?eXV2ZkVjU251dVYzcUwrdVhZSEtnZ2JVdVlGSTI5VjlYWENXYmlPVWNHNkFn?= =?utf-8?B?S2pmYmIvekZoNzFJNTN3dU8vdWI5alVQVzFKZmdBdmRDcnNDRU1nYkQyWkhq?= =?utf-8?B?SkVMMjMySHloaTJIdDU0eFUyclhjU0RRdVhzNnoxVGNZYkdXekhEQ3UxWUUz?= =?utf-8?B?dHd4bHZ1cEZQZ2llU2s3ZFlIc1pzOUllU0p5eklGejNPUXJLMmJMdkR6Q3c1?= =?utf-8?B?bWRLK2NaSFRUbEZzVFE0cGUwMXNNdnlYd3JyVkVUbU1Qd21hd05LbWxKWFNo?= =?utf-8?B?OUNYdjU1WUtORnJJazV2d3NzSWRwSjMwbGlVK29qQ2dFNUNEVUZlbU5tZm5i?= =?utf-8?B?SDdKMnBvOFZOZ0lOK1JaNEw4SEFYSlBHYm9acGQ2S3BEall4WFh6c2czUjY4?= =?utf-8?B?ZlVYVVZjYXZBLzJlZnVUemgvb1BMWWVoYTBqWnlESFNPallHL0k0ZlQvR09r?= =?utf-8?B?YmhFU3k1MWV3Y2lLMHlHd0tqRnNZZ1pZT2UxSWV4cmZ4WlFmMFdPYmJzVHRz?= =?utf-8?B?eEZpTmlJTzlYZnJnYzBhL21aN2NvSk93NUN5SUN3dlhvUzVaRGJtQ0EyN1V2?= =?utf-8?B?VWVTV1JKemRkR21QYkozRU5RT3VGZVhCeDZXaXJFMHNYZ1VqbDR6ckFROWZX?= =?utf-8?B?ZWhLSnBMQXFNejFYOHB3NlplTGwxQ1pZd2pQczhtRmhVd2Y5WVdLZXljZWt5?= =?utf-8?B?WnN4dXVJQm9sbDl1aEZCUVBBSnFXQ3ArcVF5U1l1R1ZvNVVYcCt0SGJkT3Ax?= =?utf-8?B?Rnp0UGJ5SWtjbXhUQ29uOVFQRGt3N0hERDdtdHIrQVZNODNiRURDdXEwbkpX?= =?utf-8?B?cEMrK0ZidXllSGdUQ1RNbEhKbG5UMmxidC9rVmI5czBvOVJGRkhVOCtpOTdl?= =?utf-8?B?K1RNb2lKK0NkY3JMUlhTODFaVk1McFR4RzZzMC92bkNsU3BpVW5EcXRwNWkr?= =?utf-8?B?bkkxbEl1WndyeVl0S3BVcVR2RjBQR28xbzd1akJ5VlU3VHRDV3RlTUNaZVl3?= =?utf-8?B?TzBGdHNiODJpVlczMVVCSFZ6RzlybUpUUGFncXJoQ2ZvS0M2WGpKUks5bHFh?= =?utf-8?B?dHQxTDhWbXBIalFGbGVEcUxoTXFYYXlWWS9weTVPNFpzc05Xa0ZyYk9hYk5i?= =?utf-8?B?VUI3L2lTczFyTnBBbE9KZWY5elIrUUZ2WUl4Y3JUYktqdE90b3VxZVc2ZGgz?= =?utf-8?B?bzFBTXdnQlBPTGczcVBVQUkydVBkYk14aHRlQWtQdnMzYnZJNVh0dDlxRndG?= =?utf-8?B?Z2k2T3NSanVBK0JmMVljajhSUnV1a1hFMFBqcG9jNzR4blgvTERHRkVTc2N1?= =?utf-8?B?TGI4Q1JrRjVYenVZdVViNUhOcHdpVDJhRVpMSm1VRENVSGJMUHNWdEx1RFJi?= =?utf-8?B?OFdMSlNaVWpqeFpWZEd5UT09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ff386860-5626-442f-30b7-08d916197633 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2021 14:14:46.1136 (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: sxHnOlpeT8UtS+vA5bp1FWlm7cRqfZXe9qmcrzqxuw/aPDpF1zn04SctMR6kGLnHXgaJQIVCc4vNNUifLp0fc9TBktPV2rYvLrVhijjl1CM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2826 Archived-At: Subject: [core] FW: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8 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, 13 May 2021 14:15:02 -0000 SGksDQoNCkkganVzdCBwb3N0ZWQgdGhlIGZvbGxvd2luZyBzdWdnc3RlZCBhZGRpdGlvbiB0byB0 aGUgQ09TRSBjb3VudGVyc2lnbiBkcmFmdA0KDQoiQ291bnRlcnNpZ25hdHVyZXMgb2YgQ09TRV9F bmNyeXB0IGFuZCBDT1NFX01hYyB3aXRoIHNob3J0IHRhZ3MgYW5kIG5vbi1lbXB0eSBleHRlcm5h bF9hYWQgZG8gbm90IGF0IGFsbCBnaXZlIHRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIG5vcm1hbGx5 IGFzc29jaWF0ZWQgd2l0aCB0aGUgc2FtZSBhbGdvcml0aG0gdXNlZCBpbiBDT1NFX1NpZ24uIFRv IHByb3ZpZGUgMTI4LWJpdCBzZWN1cml0eSBhZ2FpbnN0IGNvbGxpc2lvbiBhdHRhY2tzLCB0aGUg dGFnIGxlbmd0aCBNVVNUIGJlIGF0IGxlYXN0IDI1Ni1iaXRzLiBBIGNvdW50ZXJzaWduYXR1cmUg b2YgYSBDT1NFX01hYyB3aXRoIEFFUy1NQUMgMjU2LzEyOCBvbmx5IGdpdmVzIDY0LWJpdCBzZWN1 cml0eSBhbmQgYSBjb3VudGVyc2lnbmF0dXJlIG9mIGEgQ09TRV9FbmNyeXB0IHdpdGggQUVTLUND TS0xNi02NC0xMjggb25seSBnaXZlcyAzMi1iaXQgc2VjdXJpdHkuIEFub3RoZXIgc29sdXRpb24g aXMgdG8gcHJvdmlkZSB0aGUgc2FtZSBleHRlcm5hbF9hYWQgdXNlZCBpbiB0aGUgQ09TRV9FbmNy eXB0IGFuZCBDT1NFX01hYyB0byB0aGUgY291bnRlcnNpZ25hdHVyZSBhbGdvcml0aG0sIGJ1dCB0 aGlzIGV4dGVybmFsX2FhZCBpcyB0eXBpY2FsbHkgbm90IGF2YWlsYWJsZSB0byB0aGUgcGFydHkg cGVyZm9ybWluZyBvciB2ZXJpZnlpbmcgdGhlIGNvdW50ZXJzaWduYXR1cmUuIg0KDQpodHRwczov L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2Nvc2UvOXZ2MERDXzd0TDFfRGZ2SGQ0Vk5w LWRYejM4Lw0KDQpFYXJsaWVyIHZlcnNpb25zIG9mIEdyb3VwIE9TQ09SRSBoYWQgdGhlc2UgcXVp dGUgc2lnbmlmaWNhbnQgdnVsbmVyYWJpbGl0aWVzLiBNeQ0KdW5kZXJzdGFuZGluZyBpcyB0aGF0 IHRoaXMgd2Vha25lc3MgaXMgYWRkcmVzc2VkIGluIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgR3Jv dXANCk9TQ09SRSBieSBhZGRpbmcgbW9yZSBpbmZvcm1hdGlvbiB0byB0aGUgc2lnbmF0dXJlIGV4 dGVybmFsX2FhZC4gDQoNCkhvd2V2ZXIsIEkgc2VlIG5vIHJlYXNvbiB0byBhY3R1YWxseSB1c2Ug Y291bnRlcnNpZ25hdHVyZXMgaW4gR3JvdXAgT1NDT1JFLg0KVGhlIGRlZmluaXRpb24gb2YgY291 bnRlcnNpZ25hdHVyZSBpbiB0aGUgb3hmb3JkIGRpY3Rpb25hcnkgaXMNCiJhIHNpZ25hdHVyZSBh ZGRlZCB0byBhIGRvY3VtZW50IGFscmVhZHkgc2lnbmVkIGJ5IGFub3RoZXIgcGVyc29uLiIgVGhl IHVzZSBpbg0KR3JvdXAgT1NDT1JFIHdoZXJlIHRoZSBzYW1lIGVudGl0eSBjYWxjdWxhdGVzIHRo ZSBBRUFEIGFuZCB0aGUgc2lnbmF0dXJlIHNlZW1zDQp2ZXJ5IHN0cmFuZ2UsIGFuZCB0aGVyZSBz ZWVtcyB0byBiZSBubyBnb29kIHJlYXNvbiBmb3IgaXQuIFdyYXBwaW5nIHRoZSBDT1NFX0VuY3J5 cHQNCmluIGEgQ09TRV9TaWduIHNlZW1zIGxpa2UgYSBtdWNoIG1vcmUgbmF0dXJhbCBzb2x1dGlv bi4gDQoNClRoZSBDT1NFIFdHIHdpbGwgc29vbiByZWdpc3RlciBBRUFEIGFsZ29yaXRobXMgd2l0 aG91dCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBzdWNoDQphcyBBRVMtQ1RSLiBUaGUgaXMgYWZ0ZXIg YSByZXF1ZXN0IGZyb20gRklETyB0aGF0IHdhbnRzIHRvIHdyYXAgYSBDT1NFX0VuY3J5cHQNCmlu IGEgQ09TRV9NQUMuDQoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvY29z ZS9FTGlPYy1FRDlJb2FGaFI1ZDlGUzdLQkMtdmMvDQoNClRoZSB1c2Ugb2YgQUVBRCB0b2dldGhl ciB3aXRoIGEgc2lnbmF0dXJlIHdhc3RlIDgtMTYgYnl0ZXMgaW4gZWFjaCBwYWNrZXQNCndpdGhv dXQgYW55IGJlbmVmaXQgd2hhdHNvZXZlci4gVGhpcyBnb2VzIHZlcnkgbXVjaCBhZ2FpbnN0IHRo ZSBkZXNpZ24NCnBoaWxvc29maWVzIGJlaGluZCBDb0FQIGFuZCBPU0NPUkUsIHdoZXJlIGV2ZXJ5 IGJ5dGUgaGFzIHRvIGJlIGp1c3RpZmllZC4NCg0KTm93IHdoZW4gQ09TRSBXRyBpcyBzcGVjaWZ5 aW5nICJBRUFEIiBhbGdvcml0aG1zIHdpdGhvdXQgaW50ZWdyaXR5IHByb3RlY3Rpb24NCkkgdGhp bmsgQ09SRSBzaG91bGQgdGFrZSB0aGUgdGltZSB0byBtb2RpZnkgdGhlIHNpZ25hdHVyZSBwYXJ0 cyBvZg0KR3JvdXAgT1NDT1JFIGZyb20NCg0KQUVBRCgpIHx8IENvdW50ZXJzaWduYXR1cmUoIEFF QUQoKSApDQoNCnRvIA0KDQpFTkMoKSB8fCBTaWduYXR1cmUgKCBNQUMoIEVOQygpICkgKQ0KDQpD aGVlcnMsDQpKb2huDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2hu IE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4NCkRhdGU6IFRodXJzZGF5LCAx MyBNYXkgMjAyMSBhdCAxNDowNA0KVG86IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5j b20+DQpDYzogY29zZSA8Y29zZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ09TRV0gZHJhZnQt aWV0Zi1jb3NlLWNvdW50ZXJzaWduLTAyIC0gU2VjcnVpdHkgcHJvYmxlbXMgd2l0aCBDT1NFX0Vu Y3J5cHQgYW5kIENPU0VfRW5jcnlwdDAgd2l0aCBDQ01fOA0KDQpIaSBSdXNzLA0KDQpJIG1hZGUg YSBQUiB3aXRoIGEgZmlyc3QgZHJhZnQgb2Ygc3VjaCB0ZXh0DQoNCmh0dHBzOi8vZ2l0aHViLmNv bS9jb3NlLXdnL2NvdW50ZXJzaWduL3B1bGwvNg0KDQoiQ291bnRlcnNpZ25hdHVyZXMgb2YgQ09T RV9FbmNyeXB0IGFuZCBDT1NFX01hYyB3aXRoIHNob3J0IHRhZ3MgYW5kIG5vbi1lbXB0eSBleHRl cm5hbF9hYWQgZG8gbm90IGF0IGFsbCBnaXZlIHRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIG5vcm1h bGx5IGFzc29jaWF0ZWQgd2l0aCB0aGUgc2FtZSBhbGdvcml0aG0gdXNlZCBpbiBDT1NFX1NpZ24u IFRvIHByb3ZpZGUgMTI4LWJpdCBzZWN1cml0eSBhZ2FpbnN0IGNvbGxpc2lvbiBhdHRhY2tzLCB0 aGUgdGFnIGxlbmd0aCBNVVNUIGJlIGF0IGxlYXN0IDI1Ni1iaXRzLiBBIGNvdW50ZXJzaWduYXR1 cmUgb2YgYSBDT1NFX01hYyB3aXRoIEFFUy1NQUMgMjU2LzEyOCBvbmx5IGdpdmVzIDY0LWJpdCBz ZWN1cml0eSBhbmQgYSBjb3VudGVyc2lnbmF0dXJlIG9mIGEgQ09TRV9FbmNyeXB0IHdpdGggQUVT LUNDTS0xNi02NC0xMjggb25seSBnaXZlcyAzMi1iaXQgc2VjdXJpdHkuIEFub3RoZXIgc29sdXRp b24gaXMgdG8gcHJvdmlkZSB0aGUgc2FtZSBleHRlcm5hbF9hYWQgdXNlZCBpbiB0aGUgQ09TRV9F bmNyeXB0IGFuZCBDT1NFX01hYyB0byB0aGUgY291bnRlcnNpZ25hdHVyZSBhbGdvcml0aG0sIGJ1 dCB0aGlzIGV4dGVybmFsX2FhZCBpcyB0eXBpY2FsbHkgbm90IGF2YWlsYWJsZSB0byB0aGUgcGFy dHkgcGVyZm9ybWluZyBvciB2ZXJpZnlpbmcgdGhlIGNvdW50ZXJzaWduYXR1cmUuIg0KDQpDaGVl cnMsDQpKb2huDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSdXNzIEhvdXNs ZXkgPGhvdXNsZXlAdmlnaWxzZWMuY29tPg0KRGF0ZTogTW9uZGF5LCAxNSBNYXJjaCAyMDIxIGF0 IDE3OjU4DQpUbzogSm9obiBNYXR0c3NvbiA8am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20+DQpD YzogY29zZSA8Y29zZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ09TRV0gZHJhZnQtaWV0Zi1j b3NlLWNvdW50ZXJzaWduLTAyIC0gU2VjcnVpdHkgcHJvYmxlbXMgd2l0aCBDT1NFX0VuY3J5cHQg YW5kIENPU0VfRW5jcnlwdDAgd2l0aCBDQ01fOA0KDQpKb2huOg0KDQpBcmUgeW91IGFza2luZyBm b3IgYWRkaXRpb24gdGV4dCBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdG8gd2FybiBh Z2FpbnN0IHNob3J0IE1BQ3M/ICBJZiBzbywgY2FuIHlvdSBwcm92aWRlIHRoZSBmaXJzdCBkcmFm dCBvZiBzdWNoIHRleHQ/DQoNClJ1c3MNCg0KDQo+IE9uIE1hciAxMiwgMjAyMSwgYXQgMzoxMiBB TSwgSm9obiBNYXR0c3NvbiA8am9obi5tYXR0c3Nvbj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRm Lm9yZz4gd3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+IFdoZW4gSSBhbmFseXNlZCBhbiBlYXJsaWVy IHZlcnNpb24gb2YgR3JvdXAgT1NDT1JFIHNvbWUgeWVhcnMgYWdvIGl0IGhhZCBzZXZlcmUgc2Vj dXJpdHkgcHJvYmxlbXMgd2hlbiB1c2VkIHdpdGggQ0NNXzggKyBDb3VudGVyc2lnbmF0dXJlLiBU aGUgYXR0YWNrcyB3ZXJlIHByZXR0eSBiYWQuIDY0LWJpdCBvZmZsaW5lIGNvbXBsZXhpdHkgYWdh aW5zdCBzb3VyY2UgYXV0aGVudGljYXRpb24vYXZhaWxhYmlsaXR5IGZyb20gYSBkaWZmZXJlbnQg cGVyc29uIGluIHRoZSBncm91cCBhbmQgc29tZXRoaW5nIHNsaWdodGx5IG92ZXIgMzItYml0IG9u bGluZSBzZWN1cml0eSAoY29sbGVjdGluZyAyXjMyIG1lc3NhZ2VzKSBhZ2FpbnN0IGEgc291cmNl IGF1dGhlbnRpY2F0aW9uL2F2YWlsYWJpbGl0eSBmcm9tIGEgdGhpcmQgcGFydHkgb3V0c2lkZSBv ZiB0aGUgZ3JvdXAuIFRoZSBwcm9ibGVtIHdhcyB0aGF0IHRoZSBjb3VudGVyc2lnbmF0dXJlIHJl bGllZCBvbiB0aGUgQUVBRCB0YWcgZm9yIGludGVncml0eSBwcm90ZWN0aW9uIG9mIHRoZSBhZGRp dGlvbmFsIGRhdGEuIFRoaXMgd2FzIGZpeGVkIGluIEdyb3VwIE9TQ09SRSBiZSBhZGRpbmcgYWxs IHRoZSBhZGRpdGlvbmFsIGRhdGEgdG8gdGhlIHNpZ25hdHVyZSBhcyB3ZWxsLg0KPiANCj4gVGhl IHVzZSBjYXNlIG9mIENvdW50ZXJzaWduYXR1cmVzIGlzICJDb3VudGVyc2lnbmF0dXJlcyBwcm92 aWRlIGEgbWV0aG9kIG9mIGhhdmluZyBhIHNlY29uZCBwYXJ0eSBzaWduIHNvbWUgZGF0YS4iIElu IHRoaXMgY2FzZSBJIGRvbid0IHRoaW5rIENDTV84ICsgQ291bnRlcnNpZ25hdHVyZSBwcm92aWRl cyB0aGUgZXhwZWN0ZWQgc2VjdXJpdHkuIFVubGVzcyB5b3UgY2FuIHB1dCBhbGwgdGhlIGFkZGl0 aW9uYWwgZGF0YSB0byB0aGUgc2lnbmF0dXJlIGFzIHdlbGwsIEkgdGhpbmsgQ0NNXzggKyBDb3Vu dGVyc2lnbmF0dXJlIG5lZWRzIHRvIGJlIGZvcmJpZGRlbi4NCj4gDQo+IEkgZG9uJ3QgcmVhbGx5 IHNlZSB3aHkgR3JvdXAgT1NDT1JFIGlzIHVzaW5nIGNvdW50ZXJzaWduIGluIHRoZSBmaXJzdCBw bGFjZSwgaXQgc2VlbXMgbGlrZSBhIHJlbGljIGZyb20gYSB0aW1lIHdoZW4gaXQgd2FzIGFzc3Vt ZWQgdGhhdCBPU0NPUkUgd291bGQgYmUgYSBzaW5nbGUgQ09TRSBzdHJ1Y3R1cmUgb24gdGhlIHdp cmUgYXMgd2VsbC4NCj4gDQo+IENoZWVycywNCj4gSm9obg0KDQoNCg0K From nobody Thu May 13 07:34: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 2294E3A0CA8 for ; Thu, 13 May 2021 07:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 qTLqCevjRxCx for ; Thu, 13 May 2021 07:34:33 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30067.outbound.protection.outlook.com [40.107.3.67]) (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 BBB9B3A0C87 for ; Thu, 13 May 2021 07:34:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JxQvM2Y58Ot221n3dAdUQcafqUy3aclhPEGz8qC6t++vrLkwvD00NyZWnKhczTUAzBWrgHUeR6aDhxRA+Srp4sd+/IE1TQSVkipOUmFbhZRwnHCu6fN3W2uZFVnAygDHQMvDN+HoXpz6ZVUxqeyOu8KoeqA3l3ed9sP8ZsgU7w2lC892ltvfeKn1AAn8VEEjZ9q2ElJFAgUyy9cOcic1o4BBe7vV+h3/e9GP1furOC8LuO+RI5eOOQ5LkkHZbU/eTXBZeGkOid6T2kfzlV/yriGLVSNk5OxzFuYGcGj1JIaOlHGDPA8a7nhWJtpexrORs9KpM5i2jg2LVwKZe0oocw== 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=q79NmlOwAOs0mbrYScDSWSX0KkPHFITEYhLPRICGFWc=; b=PM/5Jg5m1+8b+VdPkLbd6Sk8MFU+J15uvYl/6Akn2XeQa8wLq0/KWJLhst56v4uQRzfmUOzQG1wG77+iHIIwDipV42p3f+19Zc/+1DH20IlbZVudmPHhvSF6ClFhXxdxOB7V1tHU3LhTG7OproyTNV8YZKfBsXy4X6tFmGmx7dD6HhG2JC2OpsuwvTnGdOkEyYkFrVR7bBewOHCTUY4xCmK4yvfJwMMDntMtn+kPQOF7PybLetOn4hHiRiBFPznxXuBzegSK4q3wQb9cDlLbPR0R8pxOCgFD6mktDVfV0fF0bA/RBZOAwazigcRJW5i03waMs85RoQBK8DMabldo+A== 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=q79NmlOwAOs0mbrYScDSWSX0KkPHFITEYhLPRICGFWc=; b=QZ03xqqnnrpiMr8HDdyb8OQ5LnuM2SQ197qrKJLN+P72Tyo3CpSn9d0Td8ZEGlEafC6wj6Y4bIJ8OrGohbTgHkEoSKPzG7qOe7TkqaAbDwEZ01u85vQdXLW5h1pvfUyKHM2eC+d/1tyEoS5vueLdZegrz3ii3ZpShpiBdBqkz9w= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR0701MB2203.eurprd07.prod.outlook.com (2603:10a6:3:26::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.23; Thu, 13 May 2021 14:34:26 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3%11]) with mapi id 15.20.4129.026; Thu, 13 May 2021 14:34:26 +0000 From: John Mattsson To: "core@ietf.org" Thread-Topic: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8 Thread-Index: AQHXFxduXoz8+3g8k068F5hdSGPXPqqFSp2AgFyI4YCAACSAgIAABX6A Date: Thu, 13 May 2021 14:34:26 +0000 Message-ID: <61CE5D32-24BF-4973-8034-AD5D9999B421@ericsson.com> References: <46B45227-684C-4CDB-A2B6-20BA70E89DF6@vigilsec.com> <2EF50329-22AD-4797-B8F5-89684E4CCC29@ericsson.com> In-Reply-To: <2EF50329-22AD-4797-B8F5-89684E4CCC29@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d6383ed1-7a47-43ea-b53e-08d9161c358f x-ms-traffictypediagnostic: HE1PR0701MB2203: 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: cjkRHHltbPOS7hJECvYr4uTdGHQenqoYBvwkEnqOOIZrvAydj/WX2VI0LCr/VgD/C1hrixo/2jJhtP606tfsh7O24Qx3nFKZS2MkjOGWL5A4znZ9pGiVbqF9doAiI9ubJMO2dX67QKJ8DKv3Q0D9ZrIZtC4jLF28qCyFYPsQrFDRg8K4ELJY9CBff1w+itvG2cwVuX7+toznuVf9/uAQYG4p1lPMn4dZa4svJfxqriv0QN4p3gfR/YWBrAqe1rK6v3jSaA91cWrG5G2jzcNi/WMccjN23YGj/yhept4VPrWCneFRERSBj7GXr6zSz2F0Da1KBoKoQ80+ubPQmBcfbQhB8r2lQXqpfvyZUMUgdyOBeny9oDeawqGEY7yLjP8Lsy7llQVE1ZAT5j/mmHxODLyATofVU4e8cgpotYVZzzQjHgkIFmRuo20xF/v3DlC/Q3bni4SM4NZA/UxuMBoB/jpeGi62WRbsV0jVXwMoByTrK2vpt2efSofVNCUrcWI4S68ltxpxZjIdoHyXohrzmeG97cmpm0f2CJAx7sMZRr6HJyyRMkyWeI8/2gDzHW2NmuNRLTLZT+5wnGn1QDge9ogREcrpEQJQjtnFbEUlbdr3kaIgmN+sZXCAkx3M8ebYqIVQis7AH49ADRhcSavx1Q2nmYjIH8fLEmucoGAzhoTxq8sQRY62IUn/ow/zUjyJGrhEao7EoCsAejRT6qU+v9c82kygmot0JaI7RakMzXg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(186003)(8676002)(2906002)(76116006)(6512007)(6506007)(71200400001)(86362001)(33656002)(66946007)(83380400001)(44832011)(498600001)(38100700002)(64756008)(66446008)(66556008)(966005)(66476007)(2616005)(8936002)(36756003)(122000001)(5660300002)(53546011)(26005)(6486002)(6916009)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?bUI5WGRmKzFSNlFLYUlQNGd5WFdQQ1lvejFMcDk4VWc3SlZDUExhRGJNUUFH?= =?utf-8?B?dFF6Y3I0ajBPT0lPVFdzbEFyNVAwMTRlU3JMS3pVL1hNcE9PVW5Dd2xjZjV4?= =?utf-8?B?cEJlQmlXbWVwZWIzVDBhWDdka0g4bCtnWUMwS1AzRkYzOWVCbVptdnBZU3ZX?= =?utf-8?B?RnpXemgwZHBTeUtZbVN0bHZKTStuMGpFSnR1MFJLTUFQYnhtV1MxZERnS0h2?= =?utf-8?B?dDVwR1JXVG15NWRaZ0gzUG9DV0d4eU5XaXZlMFBlSDYxb3grTjBrOG16dmVT?= =?utf-8?B?aktqbDZmOEFQR095c2JrNk9mNWxLd2gyUUQxWHdad0xhU0RSQnJCajBlSjFD?= =?utf-8?B?MnlpbXVTQ1NUQWh5TWY4UXI2LzVaaEtFQWVpUlpOTUJCaVh4Ny85STFRWSsx?= =?utf-8?B?R3NOamhta1h1V21FU1hyeVVlQ1pjNURLdDhZeG9pbWhPSWczeXNvbFRoTkVF?= =?utf-8?B?cU4vamRURkJsdVJWM21ScllEZDRiUnIxMVFWWnlpbHozajFJNUhLU2pJV0tD?= =?utf-8?B?SGtIT3U4dnZMWjA3cEg4U3RwRkNrVktUTk9XbFl4YlVQYTlHa0xLQW93NXFX?= =?utf-8?B?eEh6Sm1zbE9GSjZqMmRGT01OZmM0c0wvZHhhZHRmS2NsTGJId3VUZFlneklh?= =?utf-8?B?a0FQcm9JMGpseHJEUnprT01UelpqRHRkRGltcTg1VFdUVXFSZUxUaFJPaGlQ?= =?utf-8?B?TVRYZnhjRCtTMTF3YW5Dc3BtUEZrckFjRThHbUJ0SVZSR0lpNXc4VmwrbGJH?= =?utf-8?B?R3NHWStlc2IrODgybW5LaGxpSjg1RlBiQkxSNkZnUXUrNzlDVjlJaVVlbUFL?= =?utf-8?B?MWg1bWxNQWZpTFZkTmZNVWRVb053YXo0MnM4c3lIckZDT3B0K0dlWityakZq?= =?utf-8?B?UXNLRi90NE53M1RBOS91SmhDV3BtU0dpR01PbGlrY0d2cjhRblV6eXBGZ3E5?= =?utf-8?B?S1VwelNGMForOHBKMTR2Kzc0NWp5MzdjdVhKS1IzTy9tc0J3cjl3MEtVV0x3?= =?utf-8?B?T0dhaWdPK2NzdDF2amEwOE5pVmVDU0J5TzNKKzN0K2RTK1VOSUEzcFNBdFp2?= =?utf-8?B?QjdVeEk3S01pVHpwZFhUcnlkQWxZcW5JYjNvbmo5OG9hOUR4SEhmWVN1dUNF?= =?utf-8?B?aGx5b2RwU1BpRjljNU16OEpCeGFLdmEyR0tPZitJWHUzU1VGc0JyeFI1M3Nj?= =?utf-8?B?ano0cWdva2djR0M0VmFYNktEcEdFcjBYc3NtaUpqQS90MmpQUnlXMGlCUUVs?= =?utf-8?B?aW1uSGxoYzcyTTY5dVpMbElWdE12MDMrSll0ekNyd0lLdm8yVndqaEZ1ajJP?= =?utf-8?B?KzVwTzdIVDRoRytMenYyVXlGU1dybjdKRXBDc3FTaGdVVUZSb0NvMGUveXdJ?= =?utf-8?B?VytGTktjVFJHN28wdkhTUWFSMUdPS3lUZzdtLzVMMngvbWNIMFhIMzloSTVt?= =?utf-8?B?eVh0Y1NGZkJNeTE1a1hQVWhJM1Y2NlViR0xUSlA4TzNiSnkrVXlkZzBNRnIx?= =?utf-8?B?Wm1xQVNCeVZvM20xRTN1RGhqSUFleGk0SGRQeERIaE5KOURDY3E3aFdaWTRS?= =?utf-8?B?NWxxUjlSOWNZQWdRSVhRQ050MWdFVnVRcEdORW9BM3BxU0o4RzRNOFNGV25n?= =?utf-8?B?SmR2VFErYzhtcnRFc241QkJhL0RpeHdUMmRGaVZnbUUzTlJaZkd1d2x0elRm?= =?utf-8?B?MWlnbFA1ZWVVa2puOW9GZm1KUlFmS09JWkFJQm5OaWJlOUQ5SkdFYUJYV1Nn?= =?utf-8?B?OENQUGcwbFk4VDhnQXZ5RmlmakVBdlI0SnYraHVXZXM1NVZUSG9pdHRPYi9D?= =?utf-8?B?dk9BbWVBTkU5Vzl1R0R5UT09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <490890368DCEB648B9A32B27CB8FBC43@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: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d6383ed1-7a47-43ea-b53e-08d9161c358f X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2021 14:34:26.0632 (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: h7iv+/qJYutINoDXJB+6K9WinzDvVqohq8PyrA5S2SS18P90NOw4Mu3UJyFINOw2zrrm88iEMNTo5ntEuBjcSFTJ04TRfENrVAdIv/Wq8Zk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2203 Archived-At: Subject: Re: [core] [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8 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, 13 May 2021 14:34:38 -0000 SGksDQoNCkFub3RoZXIgYmlnIGRpc2FkdmFudGFnZSB3aXRoIHRoZSBjdXJyZW50IGRlc2lnbiBp cyB0aGF0IHRoZSB1c2VyIHRvIGNob3NlIGJldHdlZW4gbW9yZSB1c2VsZXNzIGluIHRoZSBzaWdu YXR1cmUgbW9kZSBhbmQgbGVzcyBzZWN1cml0eSBpbiBwYWlyLXdpc2UuDQoNCkluIHRoZSBzaWdu YXR1cmUgbW9kZSwgdGhlIHRhZyBwcm92aWRlcyBubyBzZWN1cml0eSBhbmQgeW91IHdhbnQgYXMg c21hbGwgYXMgcG9zc2libGUuIEZvciBwYWlyLXdpc2UgbWFueSBhcHBsaWNhdGlvbiB3b3VsZCBk ZWZpbml0bHkgd2FudCB0byB1c2UgMTYgYnl0ZXMgdGFncywgZS5nLiBhcHBsaWNhdGlvbiBhbGln bmluZyB3aXRoIHRoZSBDU05BIHN1aXRlLg0KDQpJIHRoaW5rIDgtMTggYWRkaXRpb25hbCBieXRl cyBvdmVyaGVhZCBmb3IgdGhlIHNpZ25hdHVyZSBtb2RlIG1ha2VzIGEgZGlmZmVyZW5jZS4gT25l IGV4YW1wbGUgd291bGQgYmUgd2FybmluZyBicm9hZGNhc3RzIGluIGNlbGx1bGFyIG5ldHdvcmtz LiBJbiBzb21lIG5ldHdvcmtzIHRoZSBhbW91bnQgb2YgZGF0YSB0aGF0IGNhbiBiZSBicm9hZGNh c3RlbiB3aXRoIGFjY2VwdGFibGUgbGF0ZW5jeSBpcyA3NSBieXRlcy4gR3JvdXAgT1NDT1JFIHdp dGhvdXQgdGhlIHVzZWxlc3MgQUVBRCB0YWcgY291bGQgYmUgdXNlZCwgYnV0IEdyb3VwIE9TQ09S RSB3aXRoIHRoZSB0YWcgY2Fubm90Lg0KDQpDaGVlcnMsDQpKb2huDQoNCu+7vy0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNz c29uLmNvbT4NCkRhdGU6IFRodXJzZGF5LCAxMyBNYXkgMjAyMSBhdCAxNjoxNA0KVG86ICJjb3Jl QGlldGYub3JnIiA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IEZXOiBbQ09TRV0gZHJhZnQtaWV0 Zi1jb3NlLWNvdW50ZXJzaWduLTAyIC0gU2VjcnVpdHkgcHJvYmxlbXMgd2l0aCBDT1NFX0VuY3J5 cHQgYW5kIENPU0VfRW5jcnlwdDAgd2l0aCBDQ01fOA0KDQpIaSwNCg0KSSBqdXN0IHBvc3RlZCB0 aGUgZm9sbG93aW5nIHN1Z2dzdGVkIGFkZGl0aW9uIHRvIHRoZSBDT1NFIGNvdW50ZXJzaWduIGRy YWZ0DQoNCiJDb3VudGVyc2lnbmF0dXJlcyBvZiBDT1NFX0VuY3J5cHQgYW5kIENPU0VfTWFjIHdp dGggc2hvcnQgdGFncyBhbmQgbm9uLWVtcHR5IGV4dGVybmFsX2FhZCBkbyBub3QgYXQgYWxsIGdp dmUgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgbm9ybWFsbHkgYXNzb2NpYXRlZCB3aXRoIHRoZSBz YW1lIGFsZ29yaXRobSB1c2VkIGluIENPU0VfU2lnbi4gVG8gcHJvdmlkZSAxMjgtYml0IHNlY3Vy aXR5IGFnYWluc3QgY29sbGlzaW9uIGF0dGFja3MsIHRoZSB0YWcgbGVuZ3RoIE1VU1QgYmUgYXQg bGVhc3QgMjU2LWJpdHMuIEEgY291bnRlcnNpZ25hdHVyZSBvZiBhIENPU0VfTWFjIHdpdGggQUVT LU1BQyAyNTYvMTI4IG9ubHkgZ2l2ZXMgNjQtYml0IHNlY3VyaXR5IGFuZCBhIGNvdW50ZXJzaWdu YXR1cmUgb2YgYSBDT1NFX0VuY3J5cHQgd2l0aCBBRVMtQ0NNLTE2LTY0LTEyOCBvbmx5IGdpdmVz IDMyLWJpdCBzZWN1cml0eS4gQW5vdGhlciBzb2x1dGlvbiBpcyB0byBwcm92aWRlIHRoZSBzYW1l IGV4dGVybmFsX2FhZCB1c2VkIGluIHRoZSBDT1NFX0VuY3J5cHQgYW5kIENPU0VfTWFjIHRvIHRo ZSBjb3VudGVyc2lnbmF0dXJlIGFsZ29yaXRobSwgYnV0IHRoaXMgZXh0ZXJuYWxfYWFkIGlzIHR5 cGljYWxseSBub3QgYXZhaWxhYmxlIHRvIHRoZSBwYXJ0eSBwZXJmb3JtaW5nIG9yIHZlcmlmeWlu ZyB0aGUgY291bnRlcnNpZ25hdHVyZS4iDQoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvY29zZS85dnYwRENfN3RMMV9EZnZIZDRWTnAtZFh6MzgvDQoNCkVhcmxpZXIgdmVy c2lvbnMgb2YgR3JvdXAgT1NDT1JFIGhhZCB0aGVzZSBxdWl0ZSBzaWduaWZpY2FudCB2dWxuZXJh YmlsaXRpZXMuIE15DQp1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhpcyB3ZWFrbmVzcyBpcyBhZGRy ZXNzZWQgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiBHcm91cA0KT1NDT1JFIGJ5IGFkZGluZyBt b3JlIGluZm9ybWF0aW9uIHRvIHRoZSBzaWduYXR1cmUgZXh0ZXJuYWxfYWFkLiANCg0KSG93ZXZl ciwgSSBzZWUgbm8gcmVhc29uIHRvIGFjdHVhbGx5IHVzZSBjb3VudGVyc2lnbmF0dXJlcyBpbiBH cm91cCBPU0NPUkUuDQpUaGUgZGVmaW5pdGlvbiBvZiBjb3VudGVyc2lnbmF0dXJlIGluIHRoZSBv eGZvcmQgZGljdGlvbmFyeSBpcw0KImEgc2lnbmF0dXJlIGFkZGVkIHRvIGEgZG9jdW1lbnQgYWxy ZWFkeSBzaWduZWQgYnkgYW5vdGhlciBwZXJzb24uIiBUaGUgdXNlIGluDQpHcm91cCBPU0NPUkUg d2hlcmUgdGhlIHNhbWUgZW50aXR5IGNhbGN1bGF0ZXMgdGhlIEFFQUQgYW5kIHRoZSBzaWduYXR1 cmUgc2VlbXMNCnZlcnkgc3RyYW5nZSwgYW5kIHRoZXJlIHNlZW1zIHRvIGJlIG5vIGdvb2QgcmVh c29uIGZvciBpdC4gV3JhcHBpbmcgdGhlIENPU0VfRW5jcnlwdA0KaW4gYSBDT1NFX1NpZ24gc2Vl bXMgbGlrZSBhIG11Y2ggbW9yZSBuYXR1cmFsIHNvbHV0aW9uLiANCg0KVGhlIENPU0UgV0cgd2ls bCBzb29uIHJlZ2lzdGVyIEFFQUQgYWxnb3JpdGhtcyB3aXRob3V0IGludGVncml0eSBwcm90ZWN0 aW9uIHN1Y2gNCmFzIEFFUy1DVFIuIFRoZSBpcyBhZnRlciBhIHJlcXVlc3QgZnJvbSBGSURPIHRo YXQgd2FudHMgdG8gd3JhcCBhIENPU0VfRW5jcnlwdA0KaW4gYSBDT1NFX01BQy4NCg0KaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9jb3NlL0VMaU9jLUVEOUlvYUZoUjVkOUZT N0tCQy12Yy8NCg0KVGhlIHVzZSBvZiBBRUFEIHRvZ2V0aGVyIHdpdGggYSBzaWduYXR1cmUgd2Fz dGUgOC0xNiBieXRlcyBpbiBlYWNoIHBhY2tldA0Kd2l0aG91dCBhbnkgYmVuZWZpdCB3aGF0c29l dmVyLiBUaGlzIGdvZXMgdmVyeSBtdWNoIGFnYWluc3QgdGhlIGRlc2lnbg0KcGhpbG9zb2ZpZXMg YmVoaW5kIENvQVAgYW5kIE9TQ09SRSwgd2hlcmUgZXZlcnkgYnl0ZSBoYXMgdG8gYmUganVzdGlm aWVkLg0KDQpOb3cgd2hlbiBDT1NFIFdHIGlzIHNwZWNpZnlpbmcgIkFFQUQiIGFsZ29yaXRobXMg d2l0aG91dCBpbnRlZ3JpdHkgcHJvdGVjdGlvbg0KSSB0aGluayBDT1JFIHNob3VsZCB0YWtlIHRo ZSB0aW1lIHRvIG1vZGlmeSB0aGUgc2lnbmF0dXJlIHBhcnRzIG9mDQpHcm91cCBPU0NPUkUgZnJv bQ0KDQpBRUFEKCkgfHwgQ291bnRlcnNpZ25hdHVyZSggQUVBRCgpICkNCg0KdG8gDQoNCkVOQygp IHx8IFNpZ25hdHVyZSAoIE1BQyggRU5DKCkgKSApDQoNCkNoZWVycywNCkpvaG4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb25A ZXJpY3Nzb24uY29tPg0KRGF0ZTogVGh1cnNkYXksIDEzIE1heSAyMDIxIGF0IDE0OjA0DQpUbzog UnVzcyBIb3VzbGV5IDxob3VzbGV5QHZpZ2lsc2VjLmNvbT4NCkNjOiBjb3NlIDxjb3NlQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtDT1NFXSBkcmFmdC1pZXRmLWNvc2UtY291bnRlcnNpZ24tMDIg LSBTZWNydWl0eSBwcm9ibGVtcyB3aXRoIENPU0VfRW5jcnlwdCBhbmQgQ09TRV9FbmNyeXB0MCB3 aXRoIENDTV84DQoNCkhpIFJ1c3MsDQoNCkkgbWFkZSBhIFBSIHdpdGggYSBmaXJzdCBkcmFmdCBv ZiBzdWNoIHRleHQNCg0KaHR0cHM6Ly9naXRodWIuY29tL2Nvc2Utd2cvY291bnRlcnNpZ24vcHVs bC82DQoNCiJDb3VudGVyc2lnbmF0dXJlcyBvZiBDT1NFX0VuY3J5cHQgYW5kIENPU0VfTWFjIHdp dGggc2hvcnQgdGFncyBhbmQgbm9uLWVtcHR5IGV4dGVybmFsX2FhZCBkbyBub3QgYXQgYWxsIGdp dmUgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgbm9ybWFsbHkgYXNzb2NpYXRlZCB3aXRoIHRoZSBz YW1lIGFsZ29yaXRobSB1c2VkIGluIENPU0VfU2lnbi4gVG8gcHJvdmlkZSAxMjgtYml0IHNlY3Vy aXR5IGFnYWluc3QgY29sbGlzaW9uIGF0dGFja3MsIHRoZSB0YWcgbGVuZ3RoIE1VU1QgYmUgYXQg bGVhc3QgMjU2LWJpdHMuIEEgY291bnRlcnNpZ25hdHVyZSBvZiBhIENPU0VfTWFjIHdpdGggQUVT LU1BQyAyNTYvMTI4IG9ubHkgZ2l2ZXMgNjQtYml0IHNlY3VyaXR5IGFuZCBhIGNvdW50ZXJzaWdu YXR1cmUgb2YgYSBDT1NFX0VuY3J5cHQgd2l0aCBBRVMtQ0NNLTE2LTY0LTEyOCBvbmx5IGdpdmVz IDMyLWJpdCBzZWN1cml0eS4gQW5vdGhlciBzb2x1dGlvbiBpcyB0byBwcm92aWRlIHRoZSBzYW1l IGV4dGVybmFsX2FhZCB1c2VkIGluIHRoZSBDT1NFX0VuY3J5cHQgYW5kIENPU0VfTWFjIHRvIHRo ZSBjb3VudGVyc2lnbmF0dXJlIGFsZ29yaXRobSwgYnV0IHRoaXMgZXh0ZXJuYWxfYWFkIGlzIHR5 cGljYWxseSBub3QgYXZhaWxhYmxlIHRvIHRoZSBwYXJ0eSBwZXJmb3JtaW5nIG9yIHZlcmlmeWlu ZyB0aGUgY291bnRlcnNpZ25hdHVyZS4iDQoNCkNoZWVycywNCkpvaG4NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+ DQpEYXRlOiBNb25kYXksIDE1IE1hcmNoIDIwMjEgYXQgMTc6NTgNClRvOiBKb2huIE1hdHRzc29u IDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4NCkNjOiBjb3NlIDxjb3NlQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtDT1NFXSBkcmFmdC1pZXRmLWNvc2UtY291bnRlcnNpZ24tMDIgLSBTZWNy dWl0eSBwcm9ibGVtcyB3aXRoIENPU0VfRW5jcnlwdCBhbmQgQ09TRV9FbmNyeXB0MCB3aXRoIEND TV84DQoNCkpvaG46DQoNCkFyZSB5b3UgYXNraW5nIGZvciBhZGRpdGlvbiB0ZXh0IGluIHRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0byB3YXJuIGFnYWluc3Qgc2hvcnQgTUFDcz8gIElmIHNv LCBjYW4geW91IHByb3ZpZGUgdGhlIGZpcnN0IGRyYWZ0IG9mIHN1Y2ggdGV4dD8NCg0KUnVzcw0K DQoNCj4gT24gTWFyIDEyLCAyMDIxLCBhdCAzOjEyIEFNLCBKb2huIE1hdHRzc29uIDxqb2huLm1h dHRzc29uPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4gDQo+IEhpLA0K PiANCj4gV2hlbiBJIGFuYWx5c2VkIGFuIGVhcmxpZXIgdmVyc2lvbiBvZiBHcm91cCBPU0NPUkUg c29tZSB5ZWFycyBhZ28gaXQgaGFkIHNldmVyZSBzZWN1cml0eSBwcm9ibGVtcyB3aGVuIHVzZWQg d2l0aCBDQ01fOCArIENvdW50ZXJzaWduYXR1cmUuIFRoZSBhdHRhY2tzIHdlcmUgcHJldHR5IGJh ZC4gNjQtYml0IG9mZmxpbmUgY29tcGxleGl0eSBhZ2FpbnN0IHNvdXJjZSBhdXRoZW50aWNhdGlv bi9hdmFpbGFiaWxpdHkgZnJvbSBhIGRpZmZlcmVudCBwZXJzb24gaW4gdGhlIGdyb3VwIGFuZCBz b21ldGhpbmcgc2xpZ2h0bHkgb3ZlciAzMi1iaXQgb25saW5lIHNlY3VyaXR5IChjb2xsZWN0aW5n IDJeMzIgbWVzc2FnZXMpIGFnYWluc3QgYSBzb3VyY2UgYXV0aGVudGljYXRpb24vYXZhaWxhYmls aXR5IGZyb20gYSB0aGlyZCBwYXJ0eSBvdXRzaWRlIG9mIHRoZSBncm91cC4gVGhlIHByb2JsZW0g d2FzIHRoYXQgdGhlIGNvdW50ZXJzaWduYXR1cmUgcmVsaWVkIG9uIHRoZSBBRUFEIHRhZyBmb3Ig aW50ZWdyaXR5IHByb3RlY3Rpb24gb2YgdGhlIGFkZGl0aW9uYWwgZGF0YS4gVGhpcyB3YXMgZml4 ZWQgaW4gR3JvdXAgT1NDT1JFIGJlIGFkZGluZyBhbGwgdGhlIGFkZGl0aW9uYWwgZGF0YSB0byB0 aGUgc2lnbmF0dXJlIGFzIHdlbGwuDQo+IA0KPiBUaGUgdXNlIGNhc2Ugb2YgQ291bnRlcnNpZ25h dHVyZXMgaXMgIkNvdW50ZXJzaWduYXR1cmVzIHByb3ZpZGUgYSBtZXRob2Qgb2YgaGF2aW5nIGEg c2Vjb25kIHBhcnR5IHNpZ24gc29tZSBkYXRhLiIgSW4gdGhpcyBjYXNlIEkgZG9uJ3QgdGhpbmsg Q0NNXzggKyBDb3VudGVyc2lnbmF0dXJlIHByb3ZpZGVzIHRoZSBleHBlY3RlZCBzZWN1cml0eS4g VW5sZXNzIHlvdSBjYW4gcHV0IGFsbCB0aGUgYWRkaXRpb25hbCBkYXRhIHRvIHRoZSBzaWduYXR1 cmUgYXMgd2VsbCwgSSB0aGluayBDQ01fOCArIENvdW50ZXJzaWduYXR1cmUgbmVlZHMgdG8gYmUg Zm9yYmlkZGVuLg0KPiANCj4gSSBkb24ndCByZWFsbHkgc2VlIHdoeSBHcm91cCBPU0NPUkUgaXMg dXNpbmcgY291bnRlcnNpZ24gaW4gdGhlIGZpcnN0IHBsYWNlLCBpdCBzZWVtcyBsaWtlIGEgcmVs aWMgZnJvbSBhIHRpbWUgd2hlbiBpdCB3YXMgYXNzdW1lZCB0aGF0IE9TQ09SRSB3b3VsZCBiZSBh IHNpbmdsZSBDT1NFIHN0cnVjdHVyZSBvbiB0aGUgd2lyZSBhcyB3ZWxsLg0KPiANCj4gQ2hlZXJz LA0KPiBKb2huDQoNCg0KDQoNCg== From nobody Thu May 13 11:01: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 0A9AF3A08FE for ; Thu, 13 May 2021 11:01:08 -0700 (PDT) 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 Xtx3THjt0C17 for ; Thu, 13 May 2021 11:01:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC93F3A091B for ; Thu, 13 May 2021 11:01:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D51E639152; Thu, 13 May 2021 14:10:07 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Xo4QdgXRa3TH; Thu, 13 May 2021 14:10:07 -0400 (EDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 616F439147; Thu, 13 May 2021 14:10:07 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DBEE0688; Thu, 13 May 2021 14:01:01 -0400 (EDT) From: Michael Richardson To: John Mattsson , "core\@ietf.org" In-Reply-To: <2EF50329-22AD-4797-B8F5-89684E4CCC29@ericsson.com> References: <46B45227-684C-4CDB-A2B6-20BA70E89DF6@vigilsec.com> <2EF50329-22AD-4797-B8F5-89684E4CCC29@ericsson.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] FW: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8 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, 13 May 2021 18:01:18 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable John Mattsson wrote: > Earlier versions of Group OSCORE had these quite significant > vulnerabilities. My understanding is that this weakness is addressed = in > the current version of Group OSCORE by adding more information to the > signature external_aad. > However, I see no reason to actually use countersignatures in Group > OSCORE. I don't understand the need. I know that the countersignature use in Group OSCORE was compatible with RFC8152, but beyond that, I never quite understa= nd how it was used. I'd like to ask if there are some slides from ACE that might help illuminate this? > Now when COSE WG is specifying "AEAD" algorithms without integrity > protection I think CORE should take the time to modify the signature > parts of Group OSCORE from > AEAD() || Countersignature( AEAD() ) > to > ENC() || Signature ( MAC( ENC() ) ) Hmm. I see your point, I think. I don't have the right pieces of OSCORE paged in to understand the impact to existing protocols, or if they are even far enough along to deal. But, sometimes, better is the enemy of good enough. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmCdaV0ACgkQgItw+93Q 3WWd/Qf8DSKyIrm/NkCJY1l6RY94EAOdCvH5jvtPYoMSFFMf2AfRSFr7+Fgp1lN9 CN7/pwKrwBa1vgz1pvsXxtWTWcE6IFHWD1Rp2ZBU9voN9vifBuoFO5kUhqkD1FFc eZ6+FrXczP/8DJfDX0fYXNx0Ix/eWgIaCJPgnRQcAaFy6KwONbEEazR8qJUn5/rn SGDQioBxuSm2uiFJGLQsYH8E5ozCL8ZQjHj2ojDJCuifT67ZIdq8FnaJ3eI775FK SSDg9Y/SlYrPgZni+xKiwmfnNbLZQy6hpb6mZA822Kbw06I78+PPBvAQC0XlQmzY pQ75dQR2IAdHs7czBvNzUICl99mIMA== =UIg/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 13 14:52:47 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 93F3C3A1584; Thu, 13 May 2021 14:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=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 3lDxwETKPQhK; Thu, 13 May 2021 14:52:36 -0700 (PDT) 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 1E3733A1588; Thu, 13 May 2021 14:52:30 -0700 (PDT) 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 14DLqM0d022229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 May 2021 17:52:26 -0400 Date: Thu, 13 May 2021 14:52:21 -0700 From: Benjamin Kaduk To: mohamed.boucadair@orange.com Cc: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Message-ID: <20210513215221.GH79563@kduck.mit.edu> References: <162026630680.17506.6477675472375470197@ietfa.amsl.com> <12589_1620322520_609428D8_12589_262_1_787AE7BB302AE849A7480A190F8B933035377DD2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <12589_1620322520_609428D8_12589_262_1_787AE7BB302AE849A7480A190F8B933035377DD2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2021 21:52:42 -0000 Hi Med, On Thu, May 06, 2021 at 05:35:19PM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben, > > Thank you for the review. All the changes can be tracked at: https://tinyurl.com/new-block-latest. (Apparently I waited long enough to be able to just use rfcdiff on the published -12; PR #26 posted with a couple nits from that diff.) > Please see inline. > > Cheers, > Jon & Med > > > -----Message d'origine----- > > De: Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org] > > Envoy: jeudi 6 mai 2021 03:58 > > : The IESG > > Cc: draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; > > core@ietf.org; marco.tiloca@ri.se; marco.tiloca@ri.se > > Objet: Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: > > (with DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-core-new-block-11: 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 DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ > > > > > > > > --------------------------------------------------------------------- > > - > > DISCUSS: > > --------------------------------------------------------------------- > > - > > > > I have a concern about the MAX_PAYLOADS congestion-control parameter. > > In Section 7.2 it is stated that both endpoints only SHOULD have the > > same value. I don't see how this can be anything less than MUST, > > given that we attribute semantics to whether NUM modulo MAX_PAYLOADS > > is zero or non-zero in the processing of the Q-Block2 option. If the > > endpoints disagree on the value of MAX_PAYLOADS they will disagree on > > the semantics of Q-Block2 -- how can that be interoperable? > > (Being able to negotiate the value does not seem inherently > > problematic, but since it is relevant for protocol semantics it seems > > like the value must be identical on both endpoints.) This seems > > especially important to have clarity on given that the current > > specification allows for MAX_PAYLOADS to be decreased at runtime in > > response to congestion feedback over a 24-hour period, with no > > synchronization between peers provided ("Note that the CoAP peer will > > not know about the MAX_PAYLOADS change until it is reconfigured".) > > > > > > Implementation testing with MAX_PAYLOAD being different in the peers showed things worked badly (unnecessary timeouts/recovery) but continued to work. > > If the peers were negotiating and installing a new common value (application layer), there was a brief period of instability. I still think there's a fundamental mismatch between "this is a parameter that is part of the protocol and part of request/response semantics" and "this is a parameter that each endpoint is allowed to vary unilaterally". This holds even if we attempt to set things up so in the former case the behavior degrades somewhat gracefully, with one direction transmitting as expected and the other only making slow progress. If this was just a local parameter for how to batch and pace transmissions, that would be fine, and letting it vary (even if not recommended) between peers would also be fine. But the -12 currently has text like (4.4): In a request for any block number, the M bit unset indicates the request is just for that block. If the M bit is set, this has different meanings based on the NUM value: NUM is zero: This is a request for the entire body. 'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero: This is used to confirm that the current MAX_PAYLOADS_SET (the latest block having block number NUM-1) has been successfully received and that, upon receipt of this request, the server can continue to send the next MAX_PAYLOADS_SET (the first block having block number NUM). This is the 'Continue' Q-Block-2 and conceptually has the same usage (i.e., continue sending the next set of data) as the use of 2.31 (Continue) for Q-Block1. Any other value of NUM: This is a request for that block and for all of the remaining blocks in the current MAX_PAYLOADS_SET. That is, the semantics of a request are supposed to depend on the value of MAX_PAYLOADS. The semantics of what the sender sent can disagree with the semantics of what the receiver interprets, if there is skew in this value. Now, maybe it happens that things work out okay if the client and server have different MAX_PAYLOADS values, in that setting the M bit does not have to be tied to a specific MAX_PAYLOADS_SET and rather means "give me a chunk of up to your max-transmit-window of payloads", and the receiver's value determines whether the "up to" means a full window's worth or not, but that's not what we say it means. For Proposed Standards, I think we need to be accurate about what the semantics actually are, not just what they are in the ideal case, if the MAX_PAYLOADS value is allowed to vary between peers. And if skew is allowed, we need to say that behavior degrades in case of skew and how, but that progress will still be made. (Even if the semantics actually are "give me a chunk of up to your max-window", things can still end up behaving badly if the skew is quite significant -- if I think I'm asking for a window of up to 10 blocks but I get back 100, I may not be able to handle the full response.) > Please note that this is a value that is unlikely to change: 1500 byte packets and MAX_PAYLOADS(10) gives a set of 15,000 bytes. With an up to NON_TIMEOUT (2 secs) delay, average data rates are of the order of 60kbps (1500 * 8 * 10 / 2), so providing the congested network can handle 60Kbps, all will be OK. If higher values, then the 'Continue' will come back quicker than the NON_TIMEOUT. If it's unlikely to change, then what's wrong with making it a fixed parameter (subject to change by out-of-band agreement)? > > > --------------------------------------------------------------------- > > - > > COMMENT: > > --------------------------------------------------------------------- > > - > > > > I made some editorial suggestions in a github pull request at > > https://github.com/core-wg/new-block/pull/21 . It seems that there > > are now some merge conflicts; I cannot promise to have availability > > to try to resolve them particularly quickly, but I can do so > > "eventually" if needed. > > > > Fixed the conflict. Went with many of your suggestions. Thanks. > > > Section 1 > > > > There is a requirement for these blocks of data to be transmitted > > at > > higher rates under network conditions where there may be > > asymmetrical > > transient packet loss (i.e., responses may get dropped). An > > example > > is when a network is subject to a Distributed Denial of Service > > (DDoS) attack and there is a need for DDoS mitigation agents > > relying > > upon CoAP to communicate with each other (e.g., > > [RFC8782][I-D.ietf-dots-telemetry]). As a reminder, [RFC7959] > > > > I suppose the RFC Editor will do the right thing about referencing > > 8782 vs 8782bis ... and I am overdue in following up on the IETF LC > > results for the latter :( > > > > Section 2 > > > > We currently introduce the concept of MAX_PAYLOADs by implicit use in > > a few places before it is actually given a proper definition. I > > wonder if mentioning here that it is used to group a batch of blocks > > would help the reader. > > > > Added the following in Section 2: > > NEW: > MAX_PAYLOADS refers to the maximum number of blocks that can be sent > by an endpoint > > > Section 3 > > > > o They support sending an entire body using Non-confirmable (NON) > > messages without requiring a response from the peer. > > > > I put this change in my github PR, but repeating here for visibility > > since I am making an assumption: I propose adding "intermediate" for > > "without requiring an intermediate response from the peer". My > > understanding is that a final message indicaing successful receiption > > is still used (or a selective ack in case of loss), so the contrast > > to RFC > > 7959 is in the (lack of) need for intermediate responses for each > > block. > > > > OK. > > > o Mixing of NON and CON during requests/responses using Q-Block > > is > > not supported. > > > > There is perhaps subtle differences across "not supported", > > "forbidden", and "not defined in this specification". Do we perhaps > > actually mean "forbidden"? > > It is not allowed as per: > > The transmission of all the blocks of a single body over an > unreliable transport MUST either all be Confirmable or all be Non- > confirmable. This is meant to simplify the congestion control > procedure. > > Saying "not supported" is OK in Section 3, though. > > > > > Section 3.2 > > > > (DOTS) that cannot use CON responses to handle potential packet > > loss > > and that support application-specific mechanisms to assess whether > > the remote peer is able to handle the messages sent by a CoAP > > endpoint (e.g., DOTS heartbeats in Section 4.7 of [RFC8782]). > > > > Can we get greater clarity on what "able to handle" is intended to > > mean? > > I can't tell if it's anywhere between "the transport is able to > > deliver message bodies" and "the software stack implements and > > enables a particular feature". > > The issues is to check that we are not overloading the remote peer. I made this change: > > s/able to handle/is not overloaded and is thus able to process Thanks. > > > > Section 4.1 > > > > When the Content-Format Option is present together with the Q- > > Block1 > > or Q-Block2 Option, the option applies to the body not to the > > payload > > (i.e., it must be the same for all payloads of the same body). > > > > Do we have a normative requirement somewhere that the recipient track > > and compare the content-format values across blocks? If not, should > > we? > > No text is included because rfc7959#section-2.9.2 (which defines 4.08 and cited in the spec) already covers that check. > > Likewise, the client side is also covers in RFC7959: > > If blocks of a > response body arrive with different Content-Format Options, it is up > to the client how to handle this error (it will typically abort any > ongoing block-wise transfer). Okay, thanks for the pointer (that part of 7959 is not where I would have started looking, so I appreciate the help). > As a reminder, we do say: > > The deviations from Block1 and Block2 Options are specified in > Section 4. > > > > > Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and > > iPATCH requests and their payload-bearing responses (2.01, 2.02, > > 2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]). > > > > Do we need an "e.g." in front of the list, to account for the > > potential future registration of new payload-bearing response codes? > > Agree. Please note that this is the reason why we are using "or similar" in other sections. > > > > > If Q-Block1 Option is present in a request or Q-Block2 Option in a > > response (i.e., in that message to the payload of which it > > pertains), > > > > Can we reword this parenthetical in a less convoluted way? I'm not > > even sure I'm parsing it properly. > > Changed to: > > "If the Q-Block1 Option is present in a request or the Q-Block2 Option is returned in a response,..." Thank you! > > > > [RFC7252]). To reliably get a rejection message, it is therefore > > REQUIRED that clients use a Confirmable message for determining > > support for Q-Block1 and Q-Block2 Options. > > > > (I know that some other discussion happened on this mechanism, but I > > forget if there are already plans to add a clarification that this is > > only needed once per peer within a given set of exchanges.) > > We have added the following to address some other comments : > > " ...apart from the > initial Q-Block functionality negotiation. " > ^^^^^^^^ > > > > > The Q-Block2 Option is repeatable when requesting retransmission > > of > > missing blocks, but not otherwise. Except that case, any request > > carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled > > following the procedure specified in Section 5.4.5 of [RFC7252]. > > > > Since these are critical options, the referenced procedures involve > > rejecting the message, right? Is that important enough to note > > directly? > > Section 5.4.5 of 7252 includes a pointer to 5.4.1. I don't think a change is needed. > > > > > Note that if Q-Block1 or Q-Block2 Options are included in a packet > > as > > Inner options, Block1 or Block2 Options MUST NOT be included as > > Inner > > options. Similarly there MUST NOT be a mix of Q-Block and Block > > for > > the Outer options. [...] > > > > (Hopefully a silly question, but do we make the analogous prohibition > > against combining Q-Block and regular Block for non-OSCORE cases > > anywhere? I thought we did, but now I can't find it...) > > The outer wrapper covers this in our opinion: if there is no OSCORE option in the outer wrapper, then there is no inner data. > > Also, we do already have: > > If the new options are not supported by a peer, then > transmissions can fall back to using Block1 and Block2 Options > > That's said we can be more explicit. > > > > > Section 4.3 > > > > being transferred. The Request-Tag is opaque, the server still > > treats it as opaque but the client MUST ensure that it is unique > > for > > every different body of transmitted data. > > > > (nit) the structure of this sentence seems off, to me. I may just > > want a comma after "server still treats it as opaque", but looking > > more closely I might rewrite to more like "The Request-Tag is opaque > > to the server, but the client MUST ensure that it is unique for every > > different request body being transmitted". > > > > OK > > > Implementation Note: It is suggested that the client treats the > > Request-Tag as an unsigned integer of 8 bytes in length. An > > implementation may want to consider limiting this to 4 bytes to > > reduce packet overhead size. The initial Request-Tag value > > should > > be randomly generated and then subsequently incremented by the > > client whenever a new body of data is being transmitted between > > peers. > > > > In the vein of draft-gont-numeric-ids-sec-considerations, is the > > increment necessarily 1 or can there be gaps? Similarly, the risk of > > information disclosure (via side channel) is reduced if the initial > > random value is generated anew for each connection. This is maybe > > implied by the current text but could be stated more clearly. > > We don't say "monotonically incremented" or specify an increment unit. So, yes there can be random gaps assuming the resultant values must not clash though. > > Note that the initial value is randomly generated: > > reduce packet overhead size. The initial Request-Tag value should > be randomly generated and then subsequently incremented by the > ^^^^^^^^ > client whenever a new body of data is being transmitted between > peers. > > > > > The client MUST send the payloads with the block numbers > > increasing, > > starting from zero, until the body is complete (subject to any > > congestion control (Section 7)). Any missing payloads requested > > by > > the server must in addition be separately transmitted with > > increasing > > block numbers. > > > > When I first read this, I thought that the block numbers of > > retransmissions needed to continue to increase in the same sequence > > as the original transmission, i.e., retransmitted blocks are assigned > > new block numbers. The examples do not bear this out (and it seems > > like it would be complicated to specify clearly), so I suggest > > rephrasing to "in order of increasing block number". > > ACK. > > > > > If the FETCH request includes the Observe Option, then the > > server > > MUST use the same token as used for the initial response for > > returning any Observe triggered responses so that the client > > can > > match them up. > > > > The client should then release all of the tokens used for this > > body unless a resource is being observed. > > > > If a resource is being observed, should the client release all the > > other tokens (than the one used for the initial response)? > > There is no reason why the client cannot release all the other tokens. > > > > > Also, is the "initial response" the first response for the blockwise > > transfer (which might be a 2.31 or 4.08 for NON requests), or the > > first one with response code 2.05? > > The "initial all data received response" - i.e. 2.01 or 2.05. I'd suggest adding that clarification. > > > > 2.31 (Continue) > > > > This Response Code can be used to indicate that all of the > > blocks > > up to and including the Q-Block1 Option block NUM (all having > > the > > M bit set) have been successfully received. The token used > > MUST > > be one of the tokens that were received in a request for this > > block-wise exchange. However, it is desirable to provide the > > one > > used in the last received request. > > > > Can the client release any tokens upon receipt of such a response? > > Yes. If going with the Implementation Note #6., the lower 32 bits tracker must not be released. Since we mention releasing tokens for other response codes, it would feel natural to mention it here as well, to me. > > > > 4.02 (Bad Option) > > > > This Response Code MUST be returned for a Confirmable request > > if > > the server does not support the Q-Block Options. Note that a > > reset message must be sent in case of Non-confirmable request. > > > > Reset only needs to be sent if the server is not ignoring the request > > entirely, though, right? > > The request will be rejected. Please see: > > A Non-confirmable > message with an unrecognized critical option is either rejected with > a Reset message or just silently ignored (Sections 5.4.1 and 4.3 of > [RFC7252]). I don't think I understand. "either rejected ... or just silently ignored" says that "just silently ignore" is a valid way to handle such a message. So, if "silently ignore" is a valid option for the server, I don't see how we can say "must be sent" without deviating from RFC 7252. > Hence the Q-Block availability check must be a CON. > > > > > > > %%% > > The following few comments are interrelated: > > > > 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 NUM, SZX, and M bit as appropriate. > > > > The new 'M' bit is "as appropriate" for the new flight of messages, > > or as was sent initially? (The examples in 10.x suggest "as was > > sent > > initially".) > > > > The Request-Tag value to use is determined by taking the token > > in > > the 4.08 (Request Entity Incomplete) response, locating the > > matching client request, and then using its Request-Tag. > > > > The "value to use" here seems to be indicating the value to use in > > the retransmitted request... > > Yes. > > > > > The token used MUST be one of the tokens that were received in > > a > > request for this block-wise exchange. However, it is desirable > > to > > provide the one used in the last received request. See Section > > 5 > > for further information. > > > > ... but here the "token used" seems to be indicating the token to be > > used in constructing the response that has response code 4.08. > > This is to token to be used to send the response code: s/token user/token to use > > > > > If my understanding is correct, we really should have more clarity on > > which value is "used" for which message. > > > > Additionally, in the last quoted paragraph we refer to Section 5 for > > further information, which includes a SHOULD-level requirement to > > "provide the [token] used in the last received request". It is very > > surprising to have the normative requirements for behavior split > > across sections in this manner. (Or was the intent that Section 5 > > also use the "desirable" wording?) %%% > > "desirable" is more appropriate. Fixed. > > > > > Section 4.4 > > > > The ETag is opaque, the client still treats it as opaque but the > > server MUST ensure that it is unique for every different body of > > transmitted data. > > > > [analogous comment as for Request-Tag] > > OK > > > > > Implementation Note: It is suggested that the server treats the > > ETag as an unsigned integer of 8 bytes in length. An > > implementation may want to consider limiting this to 4 bytes to > > reduce packet overhead size. The initial ETag value should be > > randomly generated and then subsequently incremented by the > > server > > whenever a new body of data is being transmitted between peers. > > > > [analogous comment as for Request-Tag] > > Noted. > > > > > The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2) > > after the last received payload for NON payloads before issuing a > > GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one > > or > > more Q-Block2 Options that define the missing blocks with the M > > bit > > unset. The client MAY set the M bit to request this and later > > blocks > > from this MAX_PAYLOADS set. Further considerations related to the > > transmission timing for missing requests are discussed in > > Section 7.2. > > > > Does the MAY grant permission to send with M bit set prior to > > NON_RECEIVE_TIMEOUT, or just permission to send with M bit set in > > addition to with M bit unset (but still after the timeout)? > > If the missing blocks are a complete set from last received block, then the MAY allows the M bit to be set indicating 'the rest' as opposed for defining each one that is missing in the request. It was not intended as being an alternative to "The client SHOULD wait". > > > > > For Confirmable responses, the client continues to acknowledge > > each > > packet. Typically, the server acknowledges the initial request > > using > > an ACK with the payload, and then sends the subsequent payloads as > > CON responses. The server will detect failure to send a packet, > > but > > the client can issue, after a MAX_TRANSMIT_SPAN delay, a separate > > GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as > > needed. > > > > Starting out with "for confirmable responses" implies that we're > > going to separately cover non-confirmable responses later, or at some > > point transition to statements of general applicability (to both > > confirmable and non-confirmable responses). Where does that happen? > > It is in this section. The text you quoted is what is specific to CON responses. I would have preferred a more explicit signal that the subsequent paragraphs apply to both the confirmable and non-confirmable cases, but the only option I'm coming up with at the moment ("for both confirmable and non-confirmable responses" to start the subsequent paragraph") is not great. > > > > A client SHOULD maintain a partial body (missing payloads) for up > > to > > NON_PARTIAL_TIMEOUT (Section 7.2) or as defined by the Max-Age > > Option > > (or its default of 60 seconds (Section 5.6.1 of [RFC7252])), > > whichever is the less. On release of the partial body, the client > > should then release all of the tokens used for this body unless a > > resource is being observed. > > > > [as above, can the client release any subset of tokens in the case of > > observe?] > > Yes. > > > > > It is RECOMMENDED that the server maintains a cached copy of the > > body > > when using the Q-Block2 Option to facilitate retransmission of any > > missing payloads. > > > > It's surprising to write that the client SHOULD but it is RECOMMENDED > > that the server cache, when those two requirements keywords have an > > equivalent strength per BCP 14. Can't we used consistent terminology > > for the same requirement level? > > Sure. > > > > > 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 transmission is terminated. Any > > subsequent missing block requests MUST be responded to using the > > latest ETag and Size2 Option values with the updated data. > > > > This sounds like the server starts responding "in the middle" of the > > new representation, so the client would need to go back and re- > > request the initial parts, possibly across multiple groups of > > MAX_PAYLOADS blocks. > > This is only needed if the server does not cache a response and the resource changes mid-flight. The Etag + possible SIZE2 change indicate the resource has hanged and needs to be re-requested from the start (block 0). > > > It seems like this requirement for client behavior should be more > > clearly documented somewhere. We do go on to talk about the client > > removing the stale partial body, but not about completing the new > > body. > > > > Section 4.5 > > > > For a response that uses Q-Block2, the Observe value MUST be the > > same > > for all the payloads of the same body. This is different from > > Block2 > > usage where the Observe value is only present in the first block > > (Section 3.4 of [RFC7959]). This includes payloads transmitted > > following receipt of the 'Continue' Q-Block2 Option (Section 4.4) > > by > > the server. If a missing payload is requested by a client, then > > both > > the request and response MUST NOT include the Observe Option. > > > > (side note?) It seems very surprising to omit Observe from only > > retransmitted payloads but keep it in all initial payload > > transmissions. > > This is different from Block2 in the (first and observe triggered additional) response is that block#0 (and other blocks) may not arrive, so the Observe Option value needs to be in all the packets (including a subsequent MAX_PAYLOADS chunk as the first MAX_PAYLOADS set may not have arrived). Once the client has at least one packet with Observe, then the requesting of missing packets does not need the Observe) as Block2 does not need it when asking for the next packet. Ah, thanks for the explanation. > > > > Section 4.6 > > > > The Size1 or Size2 option values MUST exactly represent the size > > of > > the data on the body so that any missing data can easily be > > determined. > > > > Is this MUST duplicating the behavior already specified by RFC 7959? > > No, 7959 discusses "size estimates" or "size indication". > > > > > Section 5 > > > > The data payload of the 4.08 (Request Entity Incomplete) response > > is > > encoded as a CBOR Sequence [RFC8742]. It comprises of one or more > > > > I think we want some qualifying text that reaffirms that the behavior > > being described is applicable only to the application/missing- > > blocks+cbor-seq content-type case, possibly by having the previous > > discussion state that "this section defines the behavior and > > semantics for 4.08 responses using the new content-type." > > Why is this needed? The data payload of the 4.08 response as specified in RFC 7959 is not a CBOR sequence. The current wording and paragraph structure doesn't provide a clear connection between the new content-type (as mentioned in the first sentence of the section) and this text, so a reader might misread this text (which has no normative keywords) as describing the preexisting situation for 4.08 responses, and that is not correct. Even just adding the word "new" ("data payload of the new 4.08 (Request Entity Incomplete) response") would help clarify that the description is of the new behavior, not the preexisting behavior. > > > > The Concise Data Definition Language [RFC8610] (and see Section > > 4.1 > > [RFC8742]) for the data describing these missing blocks is as > > follows: > > > > (Should we mention that this is only informational and that the prose > > description is normative, in line with RFC 8610 being only an > > informative reference?) > > I'm not sure this is needed. What is authoritative is the CBOR sequence. In my experience, it's quite common for documents to specifically say whether the protocol-description-language version or the prose version is authoritative in case of conflict. Hopefully there is no conflict, but to have a clear and unambiguous specification, we have to say which version to use if there is a conflict. > > > > ; A notional array, the elements of which are to be used > > ; in a CBOR Sequence: > > > > (nit) Is there a reason to use a different wording than the > > referenced example from RFC 8742? > > No. > > > > > Section 6 > > > > Implementation Note: By using 8-byte tokens, it is possible to > > easily minimize the number of tokens that have to be tracked by > > clients, by keeping the bottom 32 bits the same for the same > > body > > and the upper 32 bits containing the current body's request > > number > > (incrementing every request, including every re-transmit). > > This > > allows the client to be alleviated from keeping all the per- > > request-state, e.g., in Section 3 of [RFC8974]. > > > > If we're going to introduce structure into a nominally opaque > > identifier, we need to discuss the consequences of that in the > > security considerations. draft-gont-numeric-ids-sec-considerations > > has some guidance in this regard. > > It is all opaque to the server, the client is just using it to make sure his requests are unique. If one can access the token, it can access more critical information. I'm not sure there is much to say as the messages are not supposed to be sent on clear. Tampering of the token is thus very difficult given we are not using NoSec. It's only NOT RECOMMENDED to use NoSec, which means we still have to accurately document the security considerations if NoSec is used. > > > > Section 7.1 > > > > 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. > > [...] > > > > I thought there had been some discussion in a different AD's ballot > > thread on this text, but I can't find it now. I'm happy to defer to > > the previous discussion if I'm not just imagining it. > > Anyways, I might suggest phrasing this as "if faster transmission > > rates are needed, NSTART will need to be increased from 1". > > Changed to "In order to benefit from faster " > > > > > It is implementation specific as to whether there should be any > > further requests for missing data as there will have been > > significant > > transmission failure as individual payloads will have failed after > > MAX_TRANSMIT_SPAN. > > > > (editorial) I don't think I can successfully parse this sentence. > > There may be a few missing words, and splitting into multiple > > sentences would likely help as well. > > Will update it. > > > > > Section 7.2 > > > > NON_RECEIVE_TIMEOUT is the initial maximum time to wait for a > > missing > > payload before requesting retransmission for the first time. > > Every > > time the missing payload is re-requested, the time to wait value > > doubles. The time to wait is calculated as: > > > > Thank you for being very clear about the exponential backoff > > procedure > > :) > > > > payloads to prevent the client unnecessarily delaying. If not all > > of > > the MAX_PAYLOADS payloads were received, the server SHOULD delay > > for > > NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat > > request > > count for a payload) before sending the 4.08 (Request Entity > > Incomplete) Response Code for the missing payload(s). If this is > > a > > repeat for the 2.31 (Continue) response, the server SHOULD send a > > 4.08 (Request Entity Incomplete) response detailing the missing > > payloads after the block number that would have been indicated in > > the > > 2.31 (Continue). [...] > > > > I don't understand what "if this is a repeat for the 2.31 (Continue) > > response" is intended to mean. > > Does this help? > > OLD > If this is a > repeat for the 2.31 (Continue) response, the server SHOULD send a > 4.08 (Request Entity Incomplete) response detailing the missing > payloads after the block number that would have been indicated in the > 2.31 (Continue). > > NEW > > If all of the > MAX_PAYLOADS were received and a 2.31 (continue) had been sent, but > no more payloads were received for NON_RECEIVE_TIMEOUT (exponentially > scaled), the server SHOULD send a 4.08 (Request Entity Incomplete) > response detailing the missing payloads after the block number that > was indicated in the sent 2.31 (Continue). Yes; thank you! > > > > The client does not need to acknowledge the receipt of the entire > > body. > > > > Does that mean that the last group of response blocks will always be > > retransmitted NON_MAX_RETRANSMIT times? > > No. The server won't retransmit if not request is received from the client. Okay. I assume I got confused about this at some point. > > > > Section 10 > > > > QB1: Q-Block1 Option values NUM/More/SZX > > QB2: Q-Block2 Option values NUM/More/SZX > > > > What's depicted in the figure seems to be the actual block size, and > > not the three-bit SZX value. > > It is actual size. Clarified in the text. > > > > > Section 10.1.3 > > > > Should we indicate somehow in Figure 6 that the 4.08 responses use > > the new content-format? > > > > Also, is there any value in indicating that there might be a race > > between the client continuing to send the next set of payloads and > > the initial 4.08 response? > > Added a pointer to the section where 4.08 is defined. > > > > > Section 10.2.3 > > > > I don't understand why the NON_RECEIVE_TIMEOUT (client) triggers -- > > shouldn't the delivery of the 11th block indicate that the server > > thinks it sent a full MAX_PAYLOADS group and thus a selective ACK, > > after perhaps just a modest reordering delay? > > Fair question for the first the NON_RECEIVE_TIMEOUT. We handle this for Q-Block1 (Figure 6). We do have: > > It is likely that the server will start transmitting the next set of > MAX_PAYLOADS payloads before the client times out on waiting for the > last of the previous MAX_PAYLOADS payloads. Upon receipt of the > first payload from the new set of MAX_PAYLOADS payloads, the client > SHOULD send a request indicating any missing payloads from any > previous set of MAX_PAYLOADS payloads. Upon receipt of such request, > the server SHOULD send the missing payloads before continuing to send > the remainder of the MAX_PAYLOADS payloads and then go into another > NON_TIMEOUT delay prior to sending the next set of payloads. > > OLD: > [[NON_TIMEOUT (server) delay expires]] > | [[Server sends next set of payloads]] > |<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024 > | ... | > [[NON_RECEIVE_TIMEOUT (client) delay expires]] > | [[Client realizes blocks are missing and asks for the > | missing ones in one go]] > +--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\ > | | QB2:9/0/1024 > | X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024 > > NEW: > [[NON_TIMEOUT (server) delay expires]] > | [[Server sends next set of payloads]] > |<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024 > | [[On seeing a payload from the next set of payloads, > | Client realizes blocks are missing and asks for the > | missing ones in one go]] > +--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\ > | | QB2:9/0/1024 > | X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024 Thanks. > > > > > Section 10.3.2 > > > > [[MAX_PAYLOADS has been reached]] > > | [[MAX_PAYLOADS blocks acknowledged by client using > > | 'Continue' Q-Block2]] > > +--------->| NON FETCH /path M:0x3b T:0xab QB2:10/1/1024 > > |<---------+ NON 2.05 M:0x8b T:0xaa O:1334 ET=21 QB2:10/0/1024 > > > > Shouldn't the server switch to using T:0xab now? > > This is a 'Continue' as per: > > The server SHOULD recognize the 'Continue' Q-Block2 request as a > continue request and just continue the transmission of the body > (including Observe Option, if appropriate for an unsolicited > response) rather than as a request for the remaining missing blocks. > > So token does not change. We can add it the text. Thanks for adding the text. > > > > +--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024 > > |<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024 > > > > and 0xac here? > > Idem as previous one. > > > > > Section 10.3.3 > > > > |<---------+ NON 2.05 M:0xa6 T:0xc6 ET=23 QB2:3/0/1024 > > | ... | > > [[NON_RECEIVE_TIMEOUT (client) delay expires]] > > > > Why does the client time out here (at least with the full > > NON_RECEIVE_TIMEOUT); the final-message indication seems like it > > would allow for an ~immediate response (delayed only for some > > reordering threshold)? > > > > We need to observe a delay here in case there is any packet arrival re-ordering. We decided at the time to not have another yet extra timer to cover this. Please note that this is an optimization and even with the current design, the performance is much better than the legacy block-wise. Okay. Thanks for the updates in the -12 and all the responses here; I did not comment on the ones that were clear, but appreciate them nonetheless. -Ben From nobody Sun May 16 23:57: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 2B4023A2A5F for ; Sun, 16 May 2021 23:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, 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 i7K1ctu4GWsT for ; Sun, 16 May 2021 23:57:24 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2076.outbound.protection.outlook.com [40.107.21.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D9F3A2A5C for ; Sun, 16 May 2021 23:57:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZxJ3QsLpqGeHdAc7cB30nuHdVUxYybUdK6fNCgzzNajCy3zlKJiW6iS1x6KVbgh+9nORuPQpCc8G3kkP3BlP2VB786AD402qC8YhQZ4ZLH59ZGIDhZ7JdU6M+jTv/7ddSHRseJXKxEpExmaU8Xlf5fZToQu12c/Iol4STp7Yp+3ny6vNtB29ccdwZexHA2IaDxSjWoCfy8UB14UpPmrzSkhCjGTzQgBISsjKwXibgaxFeqtCdAHkFldxtgQHafHivBD7XZdmDRGONEkzckSoz5gNlBTTKUi2IB4qemGZiNb5tHyJ06NQBM3t+4r85vzGWf8dj1c7JpgLbpjKmNBvPg== 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=ZogdZm3JJWfbh8IudrSa4eYgjk1QG1Jc8YrQCsCD784=; b=m/XdglovcaF885AxRhFt+I9kIuK1aMIC5eU7oZ/m/LuYgecHkWF9Edu8kRYgrHY4c+xLAm351nkaFbZVPswyBAHTYxmFuujZlXfDJDUIjjpEc8VeOIZ8U1A9Shg5U/ZvdwxTGSJ4SFYSeE6zLQTvBYpgW6ROZFF1hxbWHE3odt7VjKv6eGzXndxlK2xL7OJhsLa9XvCRmI80g+O+uA3cweB0uLYEeDx+xKawMh+1ANTD1Uxvd4L00MvHbA1k5KZeoF4mWBL5Qc+0axRRt4TgQnP/5q1oCs8nd3FyXpeLR5RsFbjgs+uZkdzvhKm05iA+TJ/sxX1aiJNrYs8GP6OBsw== 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=ZogdZm3JJWfbh8IudrSa4eYgjk1QG1Jc8YrQCsCD784=; b=DwPSo0fzyzsfalkXse4O4FsfxFOpWod0qIC9aeKUcRTbgFgDPaSBbPMWHwkwYCzFksQBFrme2zVnrBN74+/nWMU3+50bGbqKMd8cu9Ni+6qx+FmK9O/nfUsTUa35BlisueKFXu+i3ME7a7mmw93CQlQ6dbCe9ylpKnu6Wo2EMps= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR07MB3433.eurprd07.prod.outlook.com (2603:10a6:7:38::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.11; Mon, 17 May 2021 06:57:20 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3%11]) with mapi id 15.20.4150.017; Mon, 17 May 2021 06:57:20 +0000 From: John Mattsson To: Michael Richardson , "core@ietf.org" Thread-Topic: [core] FW: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8 Thread-Index: AQHXFxduXoz8+3g8k068F5hdSGPXPqqFSp2AgFyI4YCAACSAgIAAHbCAgAWxbAA= Date: Mon, 17 May 2021 06:57:20 +0000 Message-ID: <13779C5D-7B1C-4D5B-B8B3-402FACAF2A25@ericsson.com> References: <46B45227-684C-4CDB-A2B6-20BA70E89DF6@vigilsec.com> <2EF50329-22AD-4797-B8F5-89684E4CCC29@ericsson.com> <7253.1620928861@localhost> In-Reply-To: <7253.1620928861@localhost> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 557762a9-ed9d-40ae-eec7-08d919010463 x-ms-traffictypediagnostic: HE1PR07MB3433: 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: NBy28Kls1mSPabUENb+mzqZbYbsEEKXzBAPLHA8OsWjqdzOs/mAXftXx0HckplyAICaIZiwVkHxhwOT99sRB43pvKB9GB/xNM79YPGzTS+SX+LZlxSnKV7vzjjqo5JDwcQF0/CVSPiZ6X/TsrrSeXovhxrzuFokLtRfmaNlEaAjOqM5hxuL7dwd4EaDjALhxXRN46YaftZe635hycYPeWCMLOQWYNj57CLLHO7C4EVnY+fhPaDof4wHUKhIhwIz6meeet0ktB4F3NU3SnogPb6Bgx5ucXBuzwNBpphMD+fk3aX+9xPFUUGjpValNXIjfCVD/SZze+KDrKOx3DZTExf2Ok5EmMf1MPx9aolA7YsygUYtJCO3VmrzDdUa6Lh7aRWiUlV8cbSRUcnuOYXaTCIGEnFT7v0FyButYsmL7BndPyN8vfKb09+qWf/oJmRAupJNiM/U4F4L6Wev8dY2F761LJ6dDXgXEk7qjQqd+IpuL7Skda+L7807W30rh5+9lBO+HuIS0FL1LJNUBjoC2+IK+ZHDxh69H4YEmMtAwVih2JTfGq3n6xsI1iUaLYz0+8VkZvspDZh7SLPocjQh2RwTNEXRsWnWr1Hy2HKIlCPbPn7w4N4DCeO8SRnjFrgQZZVKdu3349WMHRyhT0mlHAkOh+4O625IUyyA3ACWtMG4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(346002)(396003)(39860400002)(366004)(83380400001)(66574015)(33656002)(71200400001)(6506007)(86362001)(2906002)(5660300002)(478600001)(53546011)(6486002)(110136005)(316002)(76116006)(122000001)(38100700002)(2616005)(186003)(66946007)(64756008)(8936002)(66446008)(66476007)(6512007)(66556008)(44832011)(8676002)(36756003)(26005)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?cTB1TkplYjdsTGl5dlBFaWM5T3djUlRZMlREOFRmM0dheS9xUEVmNzN6NTBo?= =?utf-8?B?QUVkUDlYWlorR3dqeEx0MFFGZWQ5Qzc5YWZlWWE3NFI3L1FoUjQrZ3diY1pj?= =?utf-8?B?dDhaSnF4VEYxOHZpa2NqRTRzYXRDR2NBc2IyelA3NENuZXBUbXpjRnYvNjM0?= =?utf-8?B?QWt3R2l1d21SZ3JuVlFheDVFdVJ4L2ZvdUJneXp2ODF6KzZGVEhRTTJvVDRk?= =?utf-8?B?M3c3YUhaSVByUWFwVFlLTEI3ZmVtdGRzT29qUGpWc05YTmR6ZlZjbUFPVmpr?= =?utf-8?B?aStwdDk4T0R5OVZsSzI4Y0xWbEdTRmQwT3djcW9jWks3TjRTNE10YlZ6SU44?= =?utf-8?B?d1VOWHdkK25pUFJZMGxhMVllUEZXbDZoL1IxZ1VqMnRDRklkei9hTVNDRFRo?= =?utf-8?B?UndXU1E4eGZVMGJ2VDl3UUtoQUxFMTFsa2hLVHFUSUFmREhpMVRxRGt3M2tJ?= =?utf-8?B?VnZFWTFlb3J2VHI2OUxiSGdVK0JDYk1PTi9pd2tvQ2xTc3lmWFZaQUFjZHZJ?= =?utf-8?B?N0RDRmdGNDloQUt1N0Jnc0U2eVJESi9vSzU3ZUlFd2FDT0JZY000TUhLZ3dT?= =?utf-8?B?QVRTSGFNeGkwODF3eHZPNGhvKzhMZ1I0MTdjZGJLRDNvcHZUVndvT0lKbUJY?= =?utf-8?B?Z2t6VVI2d1pQRk95MGRLS09OMGFQOHMxY2tPSXpZRHJUMnBlcE5yZFMvbnRa?= =?utf-8?B?dThFM0JuSGxET0h1OURDNzdiRkl6RU9yanZtTlFWRGJLQ3RCRytxNytTa3lR?= =?utf-8?B?N2oreU51YXpYNDJkMzY2ZGR6ZDR2aTJ1WWZFV0p5NnhFL0dldkN6VjRYSmdV?= =?utf-8?B?aUpoaEk4VnRFUDJ5UWNiK0NJdExJZTF4ei9EUlRnV00xWmlVeWJYSHhMelE0?= =?utf-8?B?dVUxR1VHVElhZkRrQnc5VFlWb3lBQ3dEV1c3SS9ma01vNlhFR2hrNnB6VVlr?= =?utf-8?B?SnU4Tk1FdFJQMjJTUDYzVHBJbGMrMmlxZEtPWjlLNFJudWlpU2Z1WExvUUht?= =?utf-8?B?OWJYY3RXaWNOZmR2ZXFWRVVzNHRwYmpvNy83a3ZFUFIzQzdKQjRCcC8rVUVj?= =?utf-8?B?dmc0Nms1bnhDNm9aTEx0N3E3T1hwOW9YbXF6anRldUJCeFVyQjRjMGZzM0ZX?= =?utf-8?B?dU1yMmhHVnFYb1Q3MFU1YUhYNkpsRHYzQU5CRHRBdEtONG5aUjRJYlpNaksr?= =?utf-8?B?ODMxSnpISW1tbkVTck5BSElUWmRaNlJTRDdqTXY0RXpZRE81SHR6RUQ3ME43?= =?utf-8?B?UTM3UnpGNHEyOTVNR2ZrZGYwZGlzTXZJVzFtL2Z4Z2RiS2o3WHZSNzZUQ1NS?= =?utf-8?B?Ry9uSk9iQnEwRHZiVVlWcU5PVHVsQ1lqb0RHOEx3a1p0TXdYSXhhUWIxdTF1?= =?utf-8?B?bHA2N3BGSXRPYWNDM0U2QlRJSmJsQnVyRGtVaGJReTR1UlhBcUJaY0JWb0VD?= =?utf-8?B?YVJlaTRablJ5TkxFOXUvVmQwdEtQM2JGWHZVM1NvNzlmd0JZemxJUUR3ZE9n?= =?utf-8?B?NFZiTXpvUTNlQjVkUmVZak9RSSthT0l3enlzb3RJRWFSU2ZsdVdWaThDN0dZ?= =?utf-8?B?L2RnOGQ0RUQrVjRZRGsyc3R5RDgyYUdLZzlnUlYwT2VmRmU5OGE5dzZIS0Vz?= =?utf-8?B?ZEVycGtaMk1DVlZQL28zOU4wd0toTXNLNHh1aE1aWFk3V3RxNjNZSm0yR08w?= =?utf-8?B?WTNINThSYUZWSDQ2U3UxYktqSTl0TVFaMEg0c29aMkVWalRUQnk2Ynpmd0lt?= =?utf-8?Q?ylxot1PAN7aGrzgfHCULr6GupUOF4QbU/NFcR6n?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <85F98CEF72E4A5478FE3E2253D09E194@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: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 557762a9-ed9d-40ae-eec7-08d919010463 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2021 06:57:20.7686 (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: oRv5mk+63Zs1U7re4qP1PX1fmPeZQtMjDFI3jkykFyTSzNRqniAjgUTkbbeRJJoP0fzxLBgc3WudOZt2Ia/hODXWhE8wWf4PAFK144TR0Qs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3433 Archived-At: Subject: Re: [core] FW: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8 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, 17 May 2021 06:57:29 -0000 SGksDQoNCkkgdGhpbmsgdGhlIFJGQyA4NjEzICdBRUFEIEFsZ29yaXRobScgc2hvdWxkIGJlIHJl c2VydmVkIGZvciB0aGUgY2FzZXMgd2VyZSB0aGVyZSBpcyBubyBzaWduYXR1cmUsIGUuZy4gcGFp ci13aXNlLCB0aGVuIHRoZSBncm91cCByZXF1ZXN0IG1vZGUgd2l0aCBzaWduYXR1cmVzIHdvdWxk IGhhdmUgdG8gaGF2ZSBhZGRpdGlvbmFsIGFsZ29yaXRobXMgdG8gYmUgdXNlZCB3aXRoIHRoZSBz aWduYXR1cmUgYWxnb3JpdGhtLiBUaGUgc2lnbmF0dXJlIGNvbnN0cnVjdGlvbiBuZWVkcyB0byBi ZSBjaGFuZ2VkIHNvIHRoYXQgaXQgaXMgc2VjdXJlIHdpdGggQUVTLUNUUiBhbmQgQ2hhQ2hhMjAg d2hlbiBzdGFuZGFyZGl6ZWQgYnkgQ09TRSBXRy4NCg0KLSBJdCB3b3VsZCBiZSB2ZXJ5IHN0cmFu Z2UgdG8gZm9yY2UgcGVvcGxlIHdhbnRpbmcgdG8gdXNlIEFFUy1DQ00sIEFFUy1HQ00sIG9yIENo YUNoYTIwLVBvbHkxMzA1IG9yIG90aGVyIDE2LWJpdCB0YWcgYWxnb3JpdGhtcyBpbiBwYWlyLXdp c2UgdG8gdXNlIDgwLWJ5dGUgc291cmNlIGF1dGhlbnRpY2F0aW9uLCB3aGVuIGl0IGNhbiB0cml2 aWFsbHkgYnkgZG9uZSB3aXRoIDY0IGJ5dGVzLiBXaGlsZSB0aGUgVExTIGNvbmNsdXNpb25zIHJl Z2FyZGluZyBDQ01fOCBpcyBtaXNsZWFkaW5nLCBJIHRoaW5rIHRoZXJlIHdpbGwgYmUgYSB0cmVu ZCB0b3dhcmQgMTI4IGJpdCB0YWdzLiBNYW55IGRlcGxveW1lbnRzIGZvciBnb3Zlcm5tZW50IGFu ZCBmaW5hbmNpYWwgaW5zdGl0dXRpb25zIGFsd2F5cyB1c2UgMTI4IGJpdCB0YWdzLg0KDQotIFNv bWUgYXNwZWN0cyBvZiB0aGUgInZlcmlmeWluZyB0aGUgcmVxdWVzdCIgaXMgbm90IHdlbGwgc3Bl Y2lmaWVkIHRvZGF5LCBtYXliZSBhcyBhIGNvbnNlcXVlbmNlIG9mIHRoZSBzeW1tZXRyaWMgdGFn ICsgc2lnZ25hdHVyZSBjb25zdHJ1Y3Rpb24uIFRoZSBvcmRlciBvZiBkZWNyeXB0LCBzaWduYXR1 cmUgdmVyaWZpY2F0aW9uLCBhbmQgdXBkYXRlIG9mIHRoZSByZXBsYXkgd2luZG93IGlzIG5vdCBk ZWZpbmVkLiBUaGlzIG5lZWQgdG8gYmUgZXhhY3RseSBzcGVjaWZpZWQgb3Igc3RhdGVkIHdoYXQg Y2FuIGJlIGRvbmUgaW4gcGFyYWxsZWwuIFRoZSBjdXJyZW50IHRleHQgYWJvdXQgcmVwbGF5IHdp bmRvdyB1cGRhdGUgaXMgbGlrZWQgdG8gZGVjcnlwdGlvbiwgdGhpcyBuZWVkIHRvIGJlIGNoYW5n ZWQgYXMgdGhlIHJlcGxheSB3aW5kb3cgbGlua2VkIHRvIHRoZSBzZW5kZXIgY2FuIGFic29sdXRl bHkgbm90IGJlIHVwZGF0ZWQgdW5sZXNzIHRoZSBzaWduYXR1cmUgKHNvdXJjZSBhdXRoZW50aWNh dGlvbikgdmVyaWZpZXMuDQoNCkNoZWVycywNCkpvaG4NCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNh Pg0KRGF0ZTogVGh1cnNkYXksIDEzIE1heSAyMDIxIGF0IDIwOjAxDQpUbzogSm9obiBNYXR0c3Nv biA8am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20+LCAiY29yZUBpZXRmLm9yZyIgPGNvcmVAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIEZXOiBbQ09TRV0gZHJhZnQtaWV0Zi1jb3NlLWNv dW50ZXJzaWduLTAyIC0gU2VjcnVpdHkgcHJvYmxlbXMgd2l0aCBDT1NFX0VuY3J5cHQgYW5kIENP U0VfRW5jcnlwdDAgd2l0aCBDQ01fOA0KDQoNCkpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb249 NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KICAgID4gRWFybGllciB2ZXJz aW9ucyBvZiBHcm91cCBPU0NPUkUgaGFkIHRoZXNlIHF1aXRlIHNpZ25pZmljYW50DQogICAgPiB2 dWxuZXJhYmlsaXRpZXMuIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGlzIHdlYWtuZXNzIGlz IGFkZHJlc3NlZCBpbg0KICAgID4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiBHcm91cCBPU0NPUkUg YnkgYWRkaW5nIG1vcmUgaW5mb3JtYXRpb24gdG8gdGhlDQogICAgPiBzaWduYXR1cmUgZXh0ZXJu YWxfYWFkLg0KDQogICAgPiBIb3dldmVyLCBJIHNlZSBubyByZWFzb24gdG8gYWN0dWFsbHkgdXNl IGNvdW50ZXJzaWduYXR1cmVzIGluIEdyb3VwDQogICAgPiBPU0NPUkUuDQoNCkkgZG9uJ3QgdW5k ZXJzdGFuZCB0aGUgbmVlZC4gIEkga25vdyB0aGF0IHRoZSBjb3VudGVyc2lnbmF0dXJlIHVzZSBp biBHcm91cA0KT1NDT1JFIHdhcyBjb21wYXRpYmxlIHdpdGggUkZDODE1MiwgYnV0IGJleW9uZCB0 aGF0LCBJIG5ldmVyIHF1aXRlIHVuZGVyc3RhbmQNCmhvdyBpdCB3YXMgdXNlZC4NCg0KSSdkIGxp a2UgdG8gYXNrIGlmIHRoZXJlIGFyZSBzb21lIHNsaWRlcyBmcm9tIEFDRSB0aGF0IG1pZ2h0IGhl bHAgaWxsdW1pbmF0ZQ0KdGhpcz8NCg0KICAgID4gTm93IHdoZW4gQ09TRSBXRyBpcyBzcGVjaWZ5 aW5nICJBRUFEIiBhbGdvcml0aG1zIHdpdGhvdXQgaW50ZWdyaXR5DQogICAgPiBwcm90ZWN0aW9u IEkgdGhpbmsgQ09SRSBzaG91bGQgdGFrZSB0aGUgdGltZSB0byBtb2RpZnkgdGhlIHNpZ25hdHVy ZQ0KICAgID4gcGFydHMgb2YgR3JvdXAgT1NDT1JFIGZyb20NCg0KICAgID4gQUVBRCgpIHx8IENv dW50ZXJzaWduYXR1cmUoIEFFQUQoKSApDQoNCiAgICA+IHRvDQoNCiAgICA+IEVOQygpIHx8IFNp Z25hdHVyZSAoIE1BQyggRU5DKCkgKSApDQoNCkhtbS4gSSBzZWUgeW91ciBwb2ludCwgSSB0aGlu ay4NCkkgZG9uJ3QgaGF2ZSB0aGUgcmlnaHQgcGllY2VzIG9mIE9TQ09SRSBwYWdlZCBpbiB0byB1 bmRlcnN0YW5kIHRoZSBpbXBhY3QgdG8NCmV4aXN0aW5nIHByb3RvY29scywgb3IgaWYgdGhleSBh cmUgZXZlbiBmYXIgZW5vdWdoIGFsb25nIHRvIGRlYWwuDQoNCkJ1dCwgc29tZXRpbWVzLCBiZXR0 ZXIgaXMgdGhlIGVuZW15IG9mIGdvb2QgZW5vdWdoLg0KDQotLQ0KTWljaGFlbCBSaWNoYXJkc29u IDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ICAgLiBvIE8gKCBJUHY2IEnDuFQgY29uc3VsdGluZyAp DQogICAgICAgICAgIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyBJbmMsIE90dGF3YSBhbmQgV29y bGR3aWRlDQoNCg== From nobody Mon May 17 03:46: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 AC8F73A3296; Mon, 17 May 2021 03:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 teRjh1-UvMFq; Mon, 17 May 2021 03:45:56 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (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 294D53A3294; Mon, 17 May 2021 03:45:56 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 4FkG4y4DZCz2yVW; Mon, 17 May 2021 12:45:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1621248354; bh=V24awEu7MVD5U63R2neblkWA1vIFZ90jmNQbfYhjI5o=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=snEWbvSJSV5xCmU7/OZbb3ruM464/jLd2dMSrPZlZdLNz8Ai94NooojLlquLrtKB1 vLX6mvnar3ksSGy7tReOyqomMwiBdcp5sgmyPG4hSfUwGIW8Z9DWX+jAv1wlv1lWMh M/FQ1fogMbM6UFgyD3lf5zICmpQ4hE2wKdsXWB6WNEq4+3brW2AEhORzDrGmOigXw3 tnRtE36+ObgW176XIYfs3AK4FtPZCJvOaxOA98SYlzGbNsd7G4BegIczr51J3BC3Dv 137HToEQDHixPpjEFvL5FtzvZ2ISwFoFZzIQwwemSm/WF8/ndcF4/V+zh6XezrTN2+ mzMxGRF40N58g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4FkG4y2m1lz3wbR; Mon, 17 May 2021 12:45:54 +0200 (CEST) From: To: Benjamin Kaduk CC: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXSEJAB5Y+u28moUyJRyuXrJWmC6rneIRA Date: Mon, 17 May 2021 10:45:53 +0000 Message-ID: <4685_1621248354_60A24962_4685_382_1_787AE7BB302AE849A7480A190F8B9330353899CD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162026630680.17506.6477675472375470197@ietfa.amsl.com> <12589_1620322520_609428D8_12589_262_1_787AE7BB302AE849A7480A190F8B933035377DD2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20210513215221.GH79563@kduck.mit.edu> In-Reply-To: <20210513215221.GH79563@kduck.mit.edu> 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] Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 10:46:02 -0000 Hi Ben,=20 Please see inline. The latest changes can be tracked at: https://tinyurl.co= m/new-block-latest.=20 Cheers, Jon & Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: jeudi 13 mai 2021 23:52 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: The IESG ; draft-ietf-core-new-block@ietf.org; > core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se > Objet=A0: Re: Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: > (with DISCUSS and COMMENT) >=20 > Hi Med, >=20 > On Thu, May 06, 2021 at 05:35:19PM +0000, > mohamed.boucadair@orange.com wrote: > > Hi Ben, > > > > Thank you for the review. All the changes can be tracked at: > https://tinyurl.com/new-block-latest. >=20 > (Apparently I waited long enough to be able to just use rfcdiff on > the published -12; PR #26 posted with a couple nits from that diff.) >=20 Merged the PR. Thank you. > > Please see inline. > > > > Cheers, > > Jon & Med > > > > > -----Message d'origine----- > > > De=A0: Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org] > Envoy=E9 > > > : jeudi 6 mai 2021 03:58 =C0=A0: The IESG Cc=A0: > > > draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; > > > core@ietf.org; marco.tiloca@ri.se; marco.tiloca@ri.se Objet=A0: > > > Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: > > > (with DISCUSS and COMMENT) > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-core-new-block-11: 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 DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found > here: > > > https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ > > > > > > > > > > > > ----------------------------------------------------------------- > --- > > > - > > > - > > > DISCUSS: > > > ----------------------------------------------------------------- > --- > > > - > > > - > > > > > > I have a concern about the MAX_PAYLOADS congestion-control > parameter. > > > In Section 7.2 it is stated that both endpoints only SHOULD have > the > > > same value. I don't see how this can be anything less than MUST, > > > given that we attribute semantics to whether NUM modulo > MAX_PAYLOADS > > > is zero or non-zero in the processing of the Q-Block2 option. If > > > the endpoints disagree on the value of MAX_PAYLOADS they will > > > disagree on the semantics of Q-Block2 -- how can that be > interoperable? > > > (Being able to negotiate the value does not seem inherently > > > problematic, but since it is relevant for protocol semantics it > > > seems like the value must be identical on both endpoints.) This > > > seems especially important to have clarity on given that the > current > > > specification allows for MAX_PAYLOADS to be decreased at runtime > in > > > response to congestion feedback over a 24-hour period, with no > > > synchronization between peers provided ("Note that the CoAP peer > > > will not know about the MAX_PAYLOADS change until it is > > > reconfigured".) > > > > > > > > > > Implementation testing with MAX_PAYLOAD being different in the > peers showed things worked badly (unnecessary timeouts/recovery) but > continued to work. > > > > If the peers were negotiating and installing a new common value > (application layer), there was a brief period of instability. >=20 > I still think there's a fundamental mismatch between "this is a > parameter that is part of the protocol and part of request/response > semantics" and "this is a parameter that each endpoint is allowed to > vary unilaterally". > This holds even if we attempt to set things up so in the former case > the behavior degrades somewhat gracefully, with one direction > transmitting as expected and the other only making slow progress. >=20 > If this was just a local parameter for how to batch and pace > transmissions, that would be fine, and letting it vary (even if not > recommended) between peers would also be fine. >=20 > But the -12 currently has text like (=A74.4): >=20 > In a request for any block number, the M bit unset indicates the > request is just for that block. If the M bit is set, this has > different meanings based on the NUM value: >=20 > NUM is zero: This is a request for the entire body. >=20 > 'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero: This is > used to confirm that the current MAX_PAYLOADS_SET (the latest > block having block number NUM-1) has been successfully received > and that, upon receipt of this request, the server can continue > to > send the next MAX_PAYLOADS_SET (the first block having block > number NUM). This is the 'Continue' Q-Block-2 and conceptually > has the same usage (i.e., continue sending the next set of > data) > as the use of 2.31 (Continue) for Q-Block1. >=20 > Any other value of NUM: This is a request for that block and for > all > of the remaining blocks in the current MAX_PAYLOADS_SET. >=20 > That is, the semantics of a request are supposed to depend on the > value of MAX_PAYLOADS. The semantics of what the sender sent can > disagree with the semantics of what the receiver interprets, if there > is skew in this value. >=20 > Now, maybe it happens that things work out okay if the client and > server have different MAX_PAYLOADS values, in that setting the M bit > does not have to be tied to a specific MAX_PAYLOADS_SET and rather > means "give me a chunk of up to your max-transmit-window of > payloads", and the receiver's value determines whether the "up to" > means a full window's worth or not, but that's not what we say it > means. For Proposed Standards, I think we need to be accurate about > what the semantics actually are, not just what they are in the ideal > case, if the MAX_PAYLOADS value is allowed to vary between peers. > And if skew is allowed, we need to say that behavior degrades in case > of skew and how, but that progress will still be made. >=20 > (Even if the semantics actually are "give me a chunk of up to your > max-window", things can still end up behaving badly if the skew is > quite significant -- if I think I'm asking for a window of up to 10 > blocks but I get back 100, I may not be able to handle the full > response.) >=20 >=20 > > Please note that this is a value that is unlikely to change: 1500 > byte packets and MAX_PAYLOADS(10) gives a set of 15,000 bytes. With > an up to NON_TIMEOUT (2 secs) delay, average data rates are of the > order of 60kbps (1500 * 8 * 10 / 2), so providing the congested > network can handle 60Kbps, all will be OK. If higher values, then the > 'Continue' will come back quicker than the NON_TIMEOUT. >=20 > If it's unlikely to change, then what's wrong with making it a fixed > parameter (subject to change by out-of-band agreement)? These are fair observations. We made the following changes:=20 (1) OLD: MAX_PAYLOADS should be configurable with a default value of 10. Both CoAP endpoints SHOULD have the same value (otherwise there will be transmission delays in one direction) and the value MAY be negotiated between the endpoints to a common value by using a higher level protocol (out of scope of this document). NEW: MAX_PAYLOADS should be configurable with a default value of 10. Both CoAP endpoints MUST have the same value (otherwise there will be transmission delays in one direction) and the value MAY be negotiated between the endpoints to a common value by using a higher level protocol (out of scope of this document). (2) replaced this text with a note: OLD:=20 If the CoAP peer reports that at least one payload has not arrived for each body for at least a 24-hour period and it is known that there are no other network issues over that period (e.g., DDoS attacks), then the value of MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and the situation re-evaluated for another 24-hour period until there is no report of missing payloads under normal operating conditions. Following a period of 24 hours where no packet recovery was required, the value of MAX_PAYLOADS can be increased by 1 (but without exceeding the default value) for a further 24-hour evaluation. 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 it is reconfigured. As a consequence of the two peers having different MAX_PAYLOADS values, a peer may continue indicating that there are some missing payloads as all of its MAX_PAYLOADS_SET may not have arrived. How the two peer values for MAX_PAYLOADS are synchronized is out of the scope. NEW: Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET having 10 payloads, this corresponds to 1500 * 10 * 8 =3D 120 Kbits. With a maximum delay of 2 seconds between MAX_PAYLOADS_SET, this indicates an average speed requirement of 60 Kbps for a single body should there be no responses. This transmission rate is further reduced by being subject to PROBING_RATE. > > > > > > > > If the FETCH request includes the Observe Option, then the > > > server > > > MUST use the same token as used for the initial response > for > > > returning any Observe triggered responses so that the > client > > > can > > > match them up. > > > > > > The client should then release all of the tokens used for > this > > > body unless a resource is being observed. > > > > > > If a resource is being observed, should the client release all > the > > > other tokens (than the one used for the initial response)? > > > > There is no reason why the client cannot release all the other > tokens. > > > > > > > > Also, is the "initial response" the first response for the > blockwise > > > transfer (which might be a 2.31 or 4.08 for NON requests), or the > > > first one with response code 2.05? > > > > The "initial all data received response" - i.e. 2.01 or 2.05. >=20 > I'd suggest adding that clarification. Sure. We made the following change:=20=20 OLD:=20 If the FETCH request includes the Observe Option, then the server MUST use the same token as used for the initial response for returning any Observe triggered responses so that the client can match them up. NEW: If the FETCH request includes the Observe Option, then the server MUST use the same token as used for the 2.05 (Content) response for returning any Observe triggered responses so that the client can match them up. >=20 > > > > > > 2.31 (Continue) > > > > > > This Response Code can be used to indicate that all of the > > > blocks > > > up to and including the Q-Block1 Option block NUM (all > having > > > the > > > M bit set) have been successfully received. The token used > > > MUST > > > be one of the tokens that were received in a request for > this > > > block-wise exchange. However, it is desirable to provide > the > > > one > > > used in the last received request. > > > > > > Can the client release any tokens upon receipt of such a > response? > > > > Yes. If going with the Implementation Note #6., the lower 32 bits > tracker must not be released. >=20 > Since we mention releasing tokens for other response codes, it would > feel natural to mention it here as well, to me. Added this NEW text:=20 The client should then release all of the tokens used for this MAX_PAYLOADS_SET. >=20 > > > > > > 4.02 (Bad Option) > > > > > > This Response Code MUST be returned for a Confirmable > request > > > if > > > the server does not support the Q-Block Options. Note that > a > > > reset message must be sent in case of Non-confirmable > request. > > > > > > Reset only needs to be sent if the server is not ignoring the > > > request entirely, though, right? > > > > The request will be rejected. Please see: > > > > A Non-confirmable > > message with an unrecognized critical option is either rejected > with > > a Reset message or just silently ignored (Sections 5.4.1 and 4.3 > of > > [RFC7252]). >=20 > I don't think I understand. "either rejected ... or just silently > ignored" > says that "just silently ignore" is a valid way to handle such a > message. > So, if "silently ignore" is a valid option for the server, I don't > see how we can say "must be sent" without deviating from RFC 7252. >=20 Fair point: s/must be sent/may be sent. We don't want to deviate from 7252. > > > For Confirmable responses, the client continues to acknowledge > > > each > > > packet. Typically, the server acknowledges the initial > request > > > using > > > an ACK with the payload, and then sends the subsequent > payloads as > > > CON responses. The server will detect failure to send a > packet, > > > but > > > the client can issue, after a MAX_TRANSMIT_SPAN delay, a > separate > > > GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks > as > > > needed. > > > > > > Starting out with "for confirmable responses" implies that we're > > > going to separately cover non-confirmable responses later, or at > > > some point transition to statements of general applicability (to > > > both confirmable and non-confirmable responses). Where does that > happen? > > > > It is in this section. The text you quoted is what is specific to > CON responses. >=20 > I would have preferred a more explicit signal that the subsequent > paragraphs apply to both the confirmable and non-confirmable cases, > but the only option I'm coming up with at the moment ("for both > confirmable and non-confirmable responses" to start the subsequent > paragraph") is not great. >=20 We reordered the text so that the text about confirmable is positioned at t= he end of the section.=20 > > > Section 5 > > > > > > The data payload of the 4.08 (Request Entity Incomplete) > response > > > is > > > encoded as a CBOR Sequence [RFC8742]. It comprises of one or > > > more > > > > > > I think we want some qualifying text that reaffirms that the > > > behavior being described is applicable only to the > > > application/missing- > > > blocks+cbor-seq content-type case, possibly by having the > previous > > > discussion state that "this section defines the behavior and > > > semantics for 4.08 responses using the new content-type." > > > > Why is this needed? >=20 > The data payload of the 4.08 response as specified in RFC 7959 is not > a CBOR sequence. The current wording and paragraph structure doesn't > provide a clear connection between the new content-type (as mentioned > in the first sentence of the section) and this text, so a reader > might misread this text (which has no normative keywords) as > describing the preexisting situation for 4.08 responses, and that is > not correct. Even just adding the word "new" ("data payload of the > new 4.08 (Request Entity Incomplete) response") would help clarify > that the description is of the new behavior, not the preexisting > behavior. We understand your point better. Thanks. We made this change: OLD:=20 The data payload of the 4.08 (Request Entity Incomplete) response is encoded as a CBOR Sequence [RFC8742]. NEW: The new data payload of the 4.08 (Request Entity Incomplete) response with Content-Type set to "application/missing-blocks+cbor-seq" is encoded as a CBOR Sequence [RFC8742]. >=20 > > > > > > The Concise Data Definition Language [RFC8610] (and see > Section > > > 4.1 > > > [RFC8742]) for the data describing these missing blocks is as > > > follows: > > > > > > (Should we mention that this is only informational and that the > > > prose description is normative, in line with RFC 8610 being only > an > > > informative reference?) > > > > I'm not sure this is needed. What is authoritative is the CBOR > sequence. >=20 > In my experience, it's quite common for documents to specifically say > whether the protocol-description-language version or the prose > version is authoritative in case of conflict. Hopefully there is no > conflict, but to have a clear and unambiguous specification, we have > to say which version to use if there is a conflict. >=20 Let's then make things clear: NEW: This CDDL syntax MUST be followed. > > > Section 6 > > > > > > Implementation Note: By using 8-byte tokens, it is possible > to > > > easily minimize the number of tokens that have to be > tracked by > > > clients, by keeping the bottom 32 bits the same for the > same > > > body > > > and the upper 32 bits containing the current body's request > > > number > > > (incrementing every request, including every re-transmit). > > > This > > > allows the client to be alleviated from keeping all the > per- > > > request-state, e.g., in Section 3 of [RFC8974]. > > > > > > If we're going to introduce structure into a nominally opaque > > > identifier, we need to discuss the consequences of that in the > > > security considerations. draft-gont-numeric-ids-sec- > considerations > > > has some guidance in this regard. > > > > It is all opaque to the server, the client is just using it to make > sure his requests are unique. If one can access the token, it can > access more critical information. I'm not sure there is much to say > as the messages are not supposed to be sent on clear. Tampering of > the token is thus very difficult given we are not using NoSec. >=20 > It's only NOT RECOMMENDED to use NoSec, which means we still have to > accurately document the security considerations if NoSec is used. >=20 Added this NEW text:=20 "However, if using NoSec, Section 5.2 of [RFC8974] needs to be considered= for=09 security implications." Section 11 is also updated with this NEW text:=20 If OSCORE is not used, it is also NOT RECOMMENDED to use the NoSec security mode if either the Q-Block1 or Q-Block2 Options is used. If NoSec is being used, Section D.5 of [RFC8613] discusses the security analysis and considerations for unprotected message fields even if OSCORE is not being used. ___________________________________________________________________________= ______________________________________________ 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 Mon May 17 05:47:00 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 AE2043A369F for ; Mon, 17 May 2021 05:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J83M16fUzb8L for ; Mon, 17 May 2021 05:46:52 -0700 (PDT) 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 1A8783A369E for ; Mon, 17 May 2021 05:46:51 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id CA2E5405EE for ; Mon, 17 May 2021 14:46:48 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5E0AAD3 for ; Mon, 17 May 2021 14:46:47 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a014:89c6:8ba:ba93]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 28E2C10A for ; Mon, 17 May 2021 14:46:47 +0200 (CEST) Received: (nullmailer pid 824796 invoked by uid 1000); Mon, 17 May 2021 12:46:46 -0000 Date: Mon, 17 May 2021 14:46:46 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/GdMLAIfD+hpN69A" Content-Disposition: inline Archived-At: Subject: [core] Tossing around URIs to use outside an application 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, 17 May 2021 12:46:58 -0000 --/GdMLAIfD+hpN69A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable A thing that came up in last week's interim is the usability of URIs that you are just "tossed", with respect to secure usage. (And apologies for the long mail; if I had the clarity of the problem I'd like to have it would be shorter). For reference, a question was whether EDHOC-authenticated CoAP would use its own "coape" scheme, or if not how a user of "coaps" would know whether it's DTLS or EDHOC+OSCORE secured, or (given coaps implies DTLS) how a coap user would know whether to use plain CoAP or try EDHOC, and if so at which authentication endpoint with which credentials. The best answer I remember there being was that it is up to the application to provide an answer. If "the application" is implied to mean the union of API, client and server software, then I'm not happy with this answer, for it implies that a URI is designed for one particular application -- whereas I see a crucial advantage of the web architecture in the ability to access a resource independent of a full API or full application. As locks and light switches still seem to be the canonical use cases for the IoT, let's think about a light configured to indicate the state of a door state. (If this sounds odd, think of a darkroom or a "sorry we are closed" sign in a shop). I'll make a leap and assume that dynlinks will be used to configure that light, and that a dynlink-editor application is used. (Any more bespoke setup method will do just as well, but need the same information). I'm assuming the `coap` scheme intended for use with EDHOC or similar, as that's what provides the least information in the URI. At some point, the URI of the lock (along with any metadata if so required) will leave the "lock management" ecosystem and enter the "dynlink" ecosystem (or a more specific light bulb ecosystem). Some scenarios on what would happen then: * Just the URI is copied into the dynlink target. The lamp obtains the resource in NoSec mode, because nobody told it otherwise and the lock is configured for public visibility (which does make sense in the "Sorry we're closed" case). * Just the URI is copied into the dynlink target. As it finds a DANE record with a public key along with the name it resolves, it initiates EDHOC expecting that public key; for itself it sets a key-by-value as it has no key it expects to be usable for that server. As before, the lock is public-readable so the requests go through. * Same scenario, but the setup tool wants to keep the lamp from ever leaking what it's taling about with the lamp (which would, in the last scenario, happen if an attacker withheld the DANE record or DNSSEC information in general). The setup tool annotates the link to the lock resource with an `;osc` attribute, so that if no security context can be established, the access is not even tried. * Just the URI is copied into the dynlink target. The lamp starts in NoSec mode, but hits a 4.01; it enters an error mode storing the error response. The configuration tool, when verifying that the dynlink was registered, inspects the response, and sends the client's browser through an opaque redirect farm that eventually asks "Do you want to grant Some Lamp read access to Some Lock?". (Suspending the scenario as we continue the same way after the next one...) * The dynlink setup tool obtains the URI from the lock management ecosystem, tries to dereference it as the to-be-configured lamp would, and finds the 4.01 dat as above. (Continuing for both...) Having obtained some clearance from what would probably be ACE, it passes the obtained token on to the device along with the link. I'm unsure how that would be indicated precisely; if ACE is involved, possibly the device would not receive metadata with the link but just succeed in its next attempt because the AS now does hand it a valid token. * The dynlink setup obtains not only a URI but also some token (but it'd be a bearer token so yikes?) from the lock management. This would not be a simple matter of copy-pasting any more, but more like one of these new-fangled "share" buttons. I have little imagination of how this'd play out, but given that that "share" button is (at least on the web) just a link again, maybe that's a link that the dynlink tool could try to dereference, see that it's not yet something it could pass into the constrained device (because it starts with https and has unholy long query strings), and walks through the same "Do you want to grant..." screen again. * By comparison: on the WWW being tossed a URI is commonplace; they are sent over all channels (text print, QR print, radio announcements etc), and usable by virtue of DNS+PKI. They are usable without metadata. If a browser was given a URI of a lock, it may ask the user to go through some login service but then serve from that URI alone. What I'm leaning towards taking from this is that we should be able to support tossable URIs, but what they would look like in practice in a CoREnvironment may need looking into. Do you think that would work? BR Christian --=20 You don't become great by trying to be great. You become great by wanting to do something, and then doing it so hard that you become great in the process. -- Marie Curie (as quoted by Randall Munroe) --/GdMLAIfD+hpN69A Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmCiZbIACgkQOY0REtOk veF8hg/+JCXJHkmuBR83vOwrMcrH6OzfCNKcNGgvHpIqjbGq5YiW26nnSulWrUaH 3Vmsjt5Pl8/BCQXz3o0tatgW3dCE8cwfLqutiAEFvVsSSjNTsm0aTKPxPRh2Zu2i 96prjtCwcTvGSMLLn9d5PG7HETzrq1Y9qI4Hsj/FWldfJKmIkEcnpIH8qxUGt+c3 R5PL7TC+9BYM8xgLPAjQXImHYj4IBvjK+2glW5cZj/+JZTom9dVg3U9qpZnbMb53 I4w/DdTaA5yAGIvhr1ui70E9TBR0y5D358XMiXBcw+Hh3dpg88lR7Kt80CGna7mJ bZfoRLtT8RDzD6bbkkoltgGwXb2UnWK+HxvuSOqpIrtbvWPWHx1axDkjf2Jw1W// yxmN5jGsZ9E41Ec5IO0F4NyBAeeulgP+N5rr0M8laIeQpeOXZN50K9oDVymy3qNZ Z8Yq8bQ++LNCCMwQhJ8DUcwaNkzmA7Qjm0CGDacnFsVvpIAKGcmoM+zEjwrfKHO6 nvmuSP0kHAde8RbLPpzFm8zJJDlLc5m9NOyC5xXLtz0bI4KyuF/m1oEaoWIQZCft 7nNC5X3B772tt1k+f5Cs5xS2DhIfczDwfUYLidSurkY/uaWN8TmNBYOqCxKtrNdW sEX8SXPwSZfvmbmcXSJV31DAy+5TB7NaQvbOi/F0t5FFQJ1tDd4= =8s+U -----END PGP SIGNATURE----- --/GdMLAIfD+hpN69A-- From nobody Mon May 17 06:38: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 B35403A381D for ; Mon, 17 May 2021 06:38:05 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=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=lECthvqV; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=lECthvqV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uRYG8j2L3dV for ; Mon, 17 May 2021 06:38:01 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00082.outbound.protection.outlook.com [40.107.0.82]) (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 6DE7D3A381B for ; Mon, 17 May 2021 06:38:01 -0700 (PDT) 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=Lgj6i1ggmBvhi2UXB5kcVLl5kJPGSdZSc6IKTeQCVs4=; b=lECthvqVwnWHX3jOTiwnA+2nLSyowh2XM2VGBJ+Q/cNsRfl9D0h/uEFCje/7UHCr6KRyWfCotjuZjjDaq9MlSB8ddgN16fs19ybmM+NawByEt2W+xttOhzHbfcfov+MnJgX2duTjECnF7OvGV6pomp8d+YhND5+j5wRTE0b/Jq0= Received: from AM8P191CA0018.EURP191.PROD.OUTLOOK.COM (2603:10a6:20b:21a::23) by AM9PR08MB6897.eurprd08.prod.outlook.com (2603:10a6:20b:304::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.26; Mon, 17 May 2021 13:37:58 +0000 Received: from VE1EUR03FT034.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:21a:cafe::32) by AM8P191CA0018.outlook.office365.com (2603:10a6:20b:21a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.25 via Frontend Transport; Mon, 17 May 2021 13:37:58 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 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 VE1EUR03FT034.mail.protection.outlook.com (10.152.18.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.25 via Frontend Transport; Mon, 17 May 2021 13:37:58 +0000 Received: ("Tessian outbound 3050e7a5b95d:v92"); Mon, 17 May 2021 13:37:58 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: faf554a4b26fde2a X-CR-MTA-TID: 64aa7808 Received: from ee3302626f53.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 83DD23CE-A415-495A-BD9D-66B8C56731FE.1; Mon, 17 May 2021 13:37:36 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id ee3302626f53.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 17 May 2021 13:37:36 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JW8Trle8xvvVwA2LFJtiDAAIo7Dp5VGVX/IGQiYWCjr538dvJ89qAWJWiE/aPgMkO4bSRWD7FhMwSGCwKX0IpEcLxQKmZMafZ0mql1x3C7mTGKOpuX50B4tClvKrr3hy6qbyr6JB2Nn9DNSsmPKA2Jh8EkZku7HCdVpCNwe7rkmdH610R632SUNamWRF9jYbIk/AyvVSwdBzWZe8+S7i42yZYOXS9WEo2DMyicxmuuyMiR+Y0n8UKwro+IdX5d2kHJiInAE1X3SuCFPlzsHczG/nForOdbo0e1sTC8ZeQxlG51HkhevPjv4iQajlusulBKt2HrO3vWdH9bNwJtIuUg== 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=Lgj6i1ggmBvhi2UXB5kcVLl5kJPGSdZSc6IKTeQCVs4=; b=YgOO6IaIewdXG4T7soZbk7nieoE4GHpeFTTymWB01Tn9qFEDCZ7n8jwSIyoS2X9I7kvfC40uA76Pzyo21dmnNVZ+0iL7ezTiaTWqVPpz+S4JIWrDVeFnyWQrnq9fP64jO6lTt0JJ08sa1zEmh7fMNarSvpDedw267Vszd7HzqUbmOw7c41m7WqUFX92EKKY5jLXhecEHzZUFQcEMLsQkhN7NaEw56qxYvdEBAlDuUBReIdK1AfErZDfenrzfYaV0ok4G8H+jX3m4ObjHAq+Ysu889eexU62Ed6fFC0tl7J6vn9VVOflJT6mnuhevEP32ikFPulAn5/h+lwyJCbCppA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.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=Lgj6i1ggmBvhi2UXB5kcVLl5kJPGSdZSc6IKTeQCVs4=; b=lECthvqVwnWHX3jOTiwnA+2nLSyowh2XM2VGBJ+Q/cNsRfl9D0h/uEFCje/7UHCr6KRyWfCotjuZjjDaq9MlSB8ddgN16fs19ybmM+NawByEt2W+xttOhzHbfcfov+MnJgX2duTjECnF7OvGV6pomp8d+YhND5+j5wRTE0b/Jq0= Received: from DB9PR08MB6524.eurprd08.prod.outlook.com (2603:10a6:10:251::8) by DBBPR08MB4553.eurprd08.prod.outlook.com (2603:10a6:10:d2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.28; Mon, 17 May 2021 13:37:34 +0000 Received: from DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::e9e7:ea3a:3bca:5b3c]) by DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::e9e7:ea3a:3bca:5b3c%7]) with mapi id 15.20.4129.031; Mon, 17 May 2021 13:37:34 +0000 From: Thomas Fossati To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , "core@ietf.org" Thread-Topic: [core] Tossing around URIs to use outside an application Thread-Index: AQHXSxrJSX9LH3/p2Eek61Y76fvwNqrnviKA Date: Mon, 17 May 2021 13:37:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 Authentication-Results-Original: amsuess.com; dkim=none (message not signed) header.d=none;amsuess.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.12.10.179] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 9a2350fa-7171-4871-1a63-08d91938fc12 x-ms-traffictypediagnostic: DBBPR08MB4553:|AM9PR08MB6897: x-ms-exchange-transport-forked: True 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: 38E+0HMR5gTcCS2SeoUooPTz8n+TZm3r+wFXjuMhSfFojbGVV/XD9OIfsoMlRMCJYDoOubOkdmQuc4cUmevvdtLs8Sa3X3YzIAuZiJ0lFtftBUSPHaM/D8+4jYKNbYmY3m5j/W35mWGXsrEaR4C2lWlwVBEJLBHqiLfgH2N0faAj7OsOhM9UO5lT4hkxa9PcjOpxFK814tn/eUq8gP1m6f4TVb0EIpNcLr3q6Jkn6R6AiY4i6v5Y7oovaPXNkOf/RvPNk/wByuIvn1K5lMCS7X4AAqcw7djpnxOS8lNngXTnVM4QPbmpy3ej3zgWuvZhAOy4Nuxz35P7nCJV9AjGhiNOSKfL4v7oJ0M8ITOfcqYxSohdbDWL3bGzHCYMYYSkje5UzVLhHdx8ElVPxBq4duedZCK/LsGkhXAUh9WGxU9C2z9YxlelM8Tr0apzJ0iES5CoRSwKdi5mwqOFA0KzZhzFi4nx06sK+y7E3T/O5Y1NPALuA1evliEbga4hAv9oEr4q3fnFNxWro3l0SlDXsmUvbzxweiO0EL5oEgqvtvQzi9QkkApcnikIrFE5IGDbe5N9xtmLgDvvYWKc3o3s4NS6w/re/gFMMFrPSOgV1wTcNg+A72szpXFfcyYgXunjjd6usduRPvzgwKlgqF9lZxtxz6lYFAjxuYzm+ucO6/AquYFcYDn1xE8JzlBqCly1AjV/wIZelHu05yhAOpr4ITE59HvmYBm0i9AE/Kx0ZtY= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR08MB6524.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(366004)(39860400002)(376002)(396003)(2616005)(8676002)(38100700002)(122000001)(6512007)(5660300002)(64756008)(83380400001)(66574015)(66446008)(478600001)(36756003)(66556008)(66476007)(86362001)(186003)(6486002)(66946007)(8936002)(966005)(71200400001)(4326008)(316002)(76116006)(53546011)(2906002)(33656002)(110136005)(26005)(6506007)(91956017)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?WnlYYmJ6VUt3QjE3SjVuK3cyOUNZbEhJVWY1SkZReWUwSFJJSVVCRFhRNVl6?= =?utf-8?B?RkZRbVQ0VUxaTWJjSmx0c0t6NngrOHR2R3lDYXRBdWg0N0NUbW1xTUYyMStI?= =?utf-8?B?YjMzSlRRMU5qdXlxUmkwRGFlNjJmbUh2dzJpMzltQmZ6REtBamlybTIrMEVL?= =?utf-8?B?SjNqUW1ub05nNHRnd1l6eDZ3dldBZ0I2YmRFVS9lQjFLUU82Q2FDc2VzMzh2?= =?utf-8?B?N05JeS9FQVdOSUZEVUNVR1BzSEdTSjJYbDFCSDZoY2ZHV05CT0xxZ2pqa3hK?= =?utf-8?B?ZEo4QS8wN3BKQkhBQ09MMVNEdS82UHZ5VU1xbUpkNmxBY3o3Y1RNV1pReTJs?= =?utf-8?B?R3VadlN0NFFObUJ0QWt2bC9TS2FRNkszR3NGcklZUDAycEZuWEpmM0d5aWgx?= =?utf-8?B?K3R5eCt1TG5vTFJ5ZElmV1gwNjFCSExSdDg5R0w4RW5RUVVSWVIvQkhBVzI4?= =?utf-8?B?bFpONHI2VkFBRk5OWFRJWlp5SkZncERObFhwRTU3Qy94endhSmxiVW5GV1FR?= =?utf-8?B?aTJ5YVIwUG9mbnRkalBFYzZKSW1RNENHNUpQTHFmZExnejMyY0dEdTA1bHJu?= =?utf-8?B?SGNZcy9jbjM5eEpjMy9HU1ZKQ3BWRUFjRHJHRG5kWjFaZGRqa0JKaDBXV0hJ?= =?utf-8?B?NU1US3pHd0hib2JiQncrWXJqMVBMVllQSXFOM3NEeCtSa1FPRGFUUXlSU0hZ?= =?utf-8?B?Q1ZTejRlc3hVUHBqckIwWFlBQjc4NmlMSHN1UFp4MlpWUFdaVTJIWjVxeDJY?= =?utf-8?B?clI5THg4b1l5MXBzN2lXUkNmS2dDaUhTV1J5TTN5QUE1dklwbU9SUkw4eUZW?= =?utf-8?B?OXdMeEZBclBJUGtkK21OMlRMdE4rcll6U1UvNXBOdlJ6eUNRQlBxK2c5SzJX?= =?utf-8?B?NUdJNU1YZ25NUUNyaFhSVGsvMzQyY1JEaTBzU0Q4aUlWZXpJbzFSV1V4Skhw?= =?utf-8?B?eUU2Qk5IU1ZhcDhXUzBSbnF6emkyYTJUNDlRcy9qYXlXdHNtMUdveEtVZ3kz?= =?utf-8?B?bFlac284MjJ6Z3ptZlo0UU14NmxwQkl3TXJ4aEdIVjM3d05qS3FSdTdKU2xN?= =?utf-8?B?ZVA1RXloYjYrZU9iNEgyeDh5VDhoVXJJcUFyTGVyTkVPeEVFVWtTNkIwc3lz?= =?utf-8?B?cDhNQ3I5b2R2aFpKK281TzEvLzdzSUVTY0VvUm1oeUI3TVdYOWt6SUJRZ2NM?= =?utf-8?B?bjVpaTFtaUkwWnQ5NjFRZUpsVjdCQkt5S0RGRndWWi9tVG5pSjV4MG1VQ0dh?= =?utf-8?B?THd1bTBoTlhPRlRQVWdUbk5wckxMODcySjdXM0pFYldoVE1ybTdveWxKSnBs?= =?utf-8?B?bW11Uzd6KzJMVE12Umw0QTkvRHp4MDN0T01taFlzNTdLYm4yOTBVZlFRM0dC?= =?utf-8?B?TXR5N3NjRFM5TTBPdWxsS0MzR3p1TVVIejl4aGM0N2RBanpaNkd5VUI2QzhV?= =?utf-8?B?UWxxdUdzUy9zK1o2TFE2ZlBoaEhBVnlRMzFuTjBYbEV2a0xTaWFzVXRPTHBp?= =?utf-8?B?bUt0K3Z5VzJ3MjdndkgvUUJORC9HcmNPdjhZNmRQeDl0Slk2THlKSkxCQWpL?= =?utf-8?B?a256NlZremo1aEtFZSt2R2hZSERoMTg5K3BEejBuQ0xsR2taSGlLRUtYREtz?= =?utf-8?B?V2g1Z0xtTm8ySGp4dUpINVB5eGFXaklzdlhMSFhzUEQ4QkVGZTFpdjBLcTcy?= =?utf-8?B?OHZxUXFzd1dBWG5HTFpSUWZDMEtIMkZRODZkMG1FZ1pvQ05KU2V0ZVFKemkv?= =?utf-8?Q?ukd7/yrv8qyXD+RcWp3WVbRJoq8liax2NyaW+dg?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4553 Original-Authentication-Results: amsuess.com; dkim=none (message not signed) header.d=none;amsuess.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT034.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 274eb8aa-e3e5-4baa-0334-08d91938ed97 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rRsIm96Gg/+MW5fSabZujhAu17v2du1nZbRK+lkvFMyInIVgd1h7ntIUU100Ven9JSKV9VwR9D8A7bofSZl1RWs4p+gejaHQ7dHhaCqlAOjYPneRv6WRjTI1ZJlJvLWGf2AfqHtYwJuIQiVrEEJ7A9BVsL/jZAhyIic9476XhC32Np11JnT3MzJqOs1q8+a/iPqEEdr3Wbi4JyKDAls+xGwyh1uwlyz5eGOam/UujIR95N+eTROS3lI8yl9T0DMAuLHOeQrdb5RPcYv5XbPRSvXIDYqCZETLvqy1oKyAGxoBCbmkTdkE20jpWWnMnJGQ8OLZ5v8/8ecW9nQQ+zixl2jN9PZvX9/NggoFWBYeLoSJo+B2sD7zubSj3rOkUX69bI431x39ACy2nTs3bYLYWHprhoB7VtW13PKc/oUtZn6ltAnraPYlVgg9A1rnUC87lICkewRRUBErFC2SMsR1YS5CO/PyrrvMSAyUOe4GXWt9k8OLQyM1uGRs9aQi7h0xvokNqq2nhXO6+ZfTJ6fqIwOaGRFJpdsnGTIUJjtgQkD+73bCT4qfBAqspxnPZiAPb2EPnrtOQAleu8brOWFBu3eNQU8apMikexrluCscYLy1xO/9frI6uGULTixhkTKe0EY/SO39RceoFWpO3Pm8vKORy1fhFrXPR1DH/7xhGyheIO/OI/nhgJXKcHBUmBZmh+g+CW0vNOM2K/SbGm8pwrOQO2Mw5yt/CjKMSDN9h+M= 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)(136003)(376002)(396003)(39860400002)(46966006)(36840700001)(336012)(66574015)(2616005)(356005)(33656002)(81166007)(82310400003)(6486002)(966005)(70206006)(36860700001)(70586007)(478600001)(186003)(26005)(83380400001)(4326008)(82740400003)(6506007)(53546011)(8936002)(8676002)(36756003)(5660300002)(316002)(86362001)(6512007)(47076005)(2906002)(110136005); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2021 13:37:58.6284 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9a2350fa-7171-4871-1a63-08d91938fc12 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: VE1EUR03FT034.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6897 Archived-At: Subject: Re: [core] Tossing around URIs to use outside an application 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, 17 May 2021 13:38:06 -0000 SGkgQ2hyaXMsDQoNCk9uIDE3LzA1LzIwMjEsIDEzOjQ3LCAiQ2hyaXN0aWFuIEFtc8O8c3MiIDxj aHJpc3RpYW5AYW1zdWVzcy5jb20+IHdyb3RlOg0KPiAqIEJ5IGNvbXBhcmlzb246IG9uIHRoZSBX V1cgYmVpbmcgdG9zc2VkIGEgVVJJIGlzIGNvbW1vbnBsYWNlOyB0aGV5DQo+ICAgYXJlIHNlbnQg b3ZlciBhbGwgY2hhbm5lbHMgKHRleHQgcHJpbnQsIFFSIHByaW50LCByYWRpbw0KPiAgIGFubm91 bmNlbWVudHMgZXRjKSwgYW5kIHVzYWJsZSBieSB2aXJ0dWUgb2YgRE5TK1BLSS4NCj4NCj4gICBU aGV5IGFyZSB1c2FibGUgd2l0aG91dCBtZXRhZGF0YS4gSWYgYSBicm93c2VyIHdhcyBnaXZlbiBh IFVSSSBvZiBhDQo+ICAgbG9jaywgaXQgbWF5IGFzayB0aGUgdXNlciB0byBnbyB0aHJvdWdoIHNv bWUgbG9naW4gc2VydmljZSBidXQgdGhlbg0KPiAgIHNlcnZlIGZyb20gdGhhdCBVUkkgYWxvbmUu DQoNClRoaXMgd2FzIHByb2JhYmx5IHRydWUgYmVmb3JlIFFVSUMgYW5kIEVDSC4gIE5vdyBhbiBI VFRQUyBVUkkgbmVlZHMgbW9yZQ0KY29udGV4dCB0byBiZSBzdWNjZXNzZnVsbHkgZGVyZWZlcmVu Y2VkLg0KDQo+IFdoYXQgSSdtIGxlYW5pbmcgdG93YXJkcyB0YWtpbmcgZnJvbSB0aGlzIGlzIHRo YXQgd2Ugc2hvdWxkIGJlIGFibGUgdG8NCj4gc3VwcG9ydCB0b3NzYWJsZSBVUklzLCBidXQgd2hh dCB0aGV5IHdvdWxkIGxvb2sgbGlrZSBpbiBwcmFjdGljZSBpbiBhDQo+IENvUkVudmlyb25tZW50 IG1heSBuZWVkIGxvb2tpbmcgaW50by4NCg0KRm9yIGRlcGxveW1lbnRzIHdpdGggRE5TLCBhbiBT VkNCIFsxXSBwcm9maWxlZCBmb3IgdGhlIG5lZWRzIG9mIENvQVAgYW5kDQppdHMgc2VjdXJlIHN1 YnN0cmF0ZXMgbWF5IGJlIGFuIGVmZmljaWVudCB3YXkgdG8gaGFuZGxlIHRoZXNlICJ0b3NzYWJs ZSINClVSSXMuDQoNCmNoZWVycyENCg0KWzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtaWV0Zi1kbnNvcC1zdmNiLWh0dHBzDQoNCg0KDQoNCg0KSU1QT1JUQU5U IE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh cmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv biwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRp b24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Mon May 17 07:38: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 8FF773A3A36 for ; Mon, 17 May 2021 07:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_FAIL=0.001, SPF_HELO_NONE=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 N6ImoTxybyem for ; Mon, 17 May 2021 07:38:02 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04CC33A3A34 for ; Mon, 17 May 2021 07:38:01 -0700 (PDT) Received: from [192.168.217.118] (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FkMDj4VJlz315X; Mon, 17 May 2021 16:37:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) From: Carsten Bormann In-Reply-To: Date: Mon, 17 May 2021 16:37:57 +0200 Cc: =?utf-8?Q?Christian_Ams=C3=BCss?= , "core@ietf.org" X-Mao-Original-Outgoing-Id: 642955077.2320189-e16f78f8f97a12b3e002db6d8b32f132 Content-Transfer-Encoding: quoted-printable Message-Id: <19288F96-6650-4D81-BBFF-19153DB5CE3A@tzi.org> References: To: Thomas Fossati X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: Subject: Re: [core] Tossing around URIs to use outside an application 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, 17 May 2021 14:38:07 -0000 On 2021-05-17, at 15:37, Thomas Fossati wrote: >=20 > For deployments with DNS, an SVCB [1] profiled for the needs of CoAP = and > its secure substrates may be an efficient way to handle these = "tossable" > URIs. >=20 > cheers! >=20 > [1] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https =E2=80=A6 and we should define an information model for this so we = aren=E2=80=99t stuck with DNS for providing that information. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon May 17 07:58:24 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 6AD1C3A3AE6 for ; Mon, 17 May 2021 07:58:21 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=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=QluPxFdC; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=QluPxFdC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COt1wqiqccRh for ; Mon, 17 May 2021 07:58:16 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30046.outbound.protection.outlook.com [40.107.3.46]) (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 A28BF3A3AE4 for ; Mon, 17 May 2021 07:58:16 -0700 (PDT) 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=QdZkJK4MnSnn74lPxDNqfrNdWibkEg3xeNcEKI+p0vw=; b=QluPxFdCts00IoG6mv68MLszwWJ9hHDr7YWXv1utJDVPbM/+ejFvlGkRvgG2PkTNOmWrOf+EvKseTOwTGid/GG8Mrr37O4YqYtaU+tJVuTw+f4DE57br/B/v309URXPjXRntxHyT2pTfh+XCP7dG7YZRJ++u6JnwmPr+AlPnbXM= Received: from AM5PR0301CA0022.eurprd03.prod.outlook.com (2603:10a6:206:14::35) by DB8PR08MB5354.eurprd08.prod.outlook.com (2603:10a6:10:114::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.25; Mon, 17 May 2021 14:58:13 +0000 Received: from VE1EUR03FT044.eop-EUR03.prod.protection.outlook.com (2603:10a6:206:14:cafe::3) by AM5PR0301CA0022.outlook.office365.com (2603:10a6:206:14::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Mon, 17 May 2021 14:58:13 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 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 VE1EUR03FT044.mail.protection.outlook.com (10.152.19.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.25 via Frontend Transport; Mon, 17 May 2021 14:58:13 +0000 Received: ("Tessian outbound 504317ef584c:v92"); Mon, 17 May 2021 14:58:13 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: c3af28b9b93b2e12 X-CR-MTA-TID: 64aa7808 Received: from 84375e317919.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 520D8A1E-7497-4C55-8999-AA84FE781E14.1; Mon, 17 May 2021 14:58:02 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 84375e317919.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 17 May 2021 14:58:02 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dOjLNfwtqwownicgJItJvskB/gvqRCOpUczAgOpnYcU1ZYnV5vmgDz8al7WeG74npCeIIfhU9JEzGNAkSCh78tG5u9P/fGIjUsNIbap1m3fOGRcoW4t+KInpyViCL8o9fksK7gWbdoLxkGH5unv77XcbjjpHC2ZXHrzuFrvZtSIZMcbxMLo6jMcg0X3JidVqrXcE39MSNFKxaP2OGTarXJ6qYQ1GPUq3cBejaSRV1Jr7OuCFbnTx4i2EmDRzoLe2almVzSvBqoQ7uYMmIAgRrgW9Bhr28lRSw59MDa4JqsmDbWojms2Fubx3IbQK9dc/FkoHK01x2wZYYMRYRe+4Cg== 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=QdZkJK4MnSnn74lPxDNqfrNdWibkEg3xeNcEKI+p0vw=; b=hk71PcOtTKlmUkJZSGS19tRyfdiud3oKJeaZ80u6g9k0MRyld/MlgwdnRX1NGBNULRMVpJnOwbqy4iJC9tj0cNOAp+PnlayRUfo/k61uyPLeApLHCtnW4C1Ru1xYOHUNZ3hn6jaC+s6EnvqBOv3LVhl9QX5dHqJdTLlNHivVJyLOzwvRgW+1pCvts3JSsmoZIzKcRW47whQAQh2sw9PUBzUd2Kw6gEYDC1Us01lMHQgYdndfy2lg3QGVNJX46G2SJQBVELPp4E9onqF41Y1VYtkTYV8+9avD3DV6fKiBR2fTQgB+ML+BSgd1eZPASWCuQXRtzq9qWi5ODPF+wFBShQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.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=QdZkJK4MnSnn74lPxDNqfrNdWibkEg3xeNcEKI+p0vw=; b=QluPxFdCts00IoG6mv68MLszwWJ9hHDr7YWXv1utJDVPbM/+ejFvlGkRvgG2PkTNOmWrOf+EvKseTOwTGid/GG8Mrr37O4YqYtaU+tJVuTw+f4DE57br/B/v309URXPjXRntxHyT2pTfh+XCP7dG7YZRJ++u6JnwmPr+AlPnbXM= Received: from DB9PR08MB6524.eurprd08.prod.outlook.com (2603:10a6:10:251::8) by DB6PR0802MB2278.eurprd08.prod.outlook.com (2603:10a6:4:85::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.26; Mon, 17 May 2021 14:58:00 +0000 Received: from DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::e9e7:ea3a:3bca:5b3c]) by DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::e9e7:ea3a:3bca:5b3c%7]) with mapi id 15.20.4129.031; Mon, 17 May 2021 14:58:00 +0000 From: Thomas Fossati To: Carsten Bormann CC: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , "core@ietf.org" , Thomas Fossati Thread-Topic: [core] Tossing around URIs to use outside an application Thread-Index: AQHXSxrJSX9LH3/p2Eek61Y76fvwNqrnviKAgAAAHYCAABZcgA== Date: Mon, 17 May 2021 14:58:00 +0000 Message-ID: References: <19288F96-6650-4D81-BBFF-19153DB5CE3A@tzi.org> In-Reply-To: <19288F96-6650-4D81-BBFF-19153DB5CE3A@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 Authentication-Results-Original: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.12.10.179] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 6619695b-1acf-4616-2db0-08d919443201 x-ms-traffictypediagnostic: DB6PR0802MB2278:|DB8PR08MB5354: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:7219;OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: Z0RwRWMGyWza0/CsN8bkM16985h4w3LiPnCabUHlr6AC5OoPql4qr2L9UjtoqvpBO8GgSRk0XL7Zq+RCRGYq13zYS+8sYEhKItKcGvGeN+V1iT2Y4FiAfIKUsuPUORXGs57qxyMy1TaqY5lvneEI8hB8DscVgyxwwGsrZKNXsttlwNAJsy51EhNZ+66uZCjIbLIPFUe5OUQC0tk0ijlz/o8/dY24q42s5PZIRkX9v6fzK2d+COd06q7sstx/NYm7SELnN7Z1Ky6UnHK92LeWE/RQkiEL0KxZ8dq6cNLEOmyc+G30EVr7oj63ddCEInDdSnua7mYvv9Bb50hD1bLGFeujCorxrSYk1gNfJWQurMK+8y5p5g+hNXQC5jNZZeQI3b5hzgQ3qVvt/BcYU6Av9aEiU5hJnJtPaXJ4bw4vX+wDTUmNawcWg9LzgQRVrNsTjEAd26iG4JLLZyx1z1jlDzlI1ALibJpzJ0XLnMorZzqVVfmUx/cY1iRC7bKmNn9g6Vw/WyNSJrP7Km7LccAN+SNHf/KuVwxo1jqBL0734Z+iFOLs66Mez2BdJpQ/ph9VBzsdAlDBUXc+J6auFNStq89a9RHEwHc2CgZ1liLM3RlRYVsuSZQs3tBlG5hxf1bDMD0x+9tz2kRfbY8xqVt99RgmBsEwNHpZOz0groRnQ5zv4+hSI1HhNnzABZ0MrAdMn60i4UZ55qF32N8iTWo1kU39jg/e7ujR2OQ8v8MsL4Ufuaaqwt2KdjihDdewCqXbdczHhEg9Xc2MBjxaDemZrw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR08MB6524.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(376002)(39850400004)(136003)(396003)(83380400001)(33656002)(71200400001)(6506007)(86362001)(53546011)(2906002)(4744005)(5660300002)(76116006)(478600001)(4326008)(54906003)(6486002)(316002)(966005)(122000001)(38100700002)(91956017)(2616005)(66446008)(186003)(64756008)(66476007)(66946007)(8936002)(6916009)(6512007)(66556008)(8676002)(36756003)(26005)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Q2NRdFNmQ00wNlhkT2N1RkVIYzByR29MQmFFaGthS3lNdm5ETkNkYjJJb0Na?= =?utf-8?B?QTdDdTV5YngwWVh0djZodGxRNkJRZ1oxbUk3VWlUaC9JR3V3WDJsaVJSdEJF?= =?utf-8?B?bldnR3Y4MVVTc09ITmw1SFRGOFNQK3lPMUhqSTZ5Y0lDRTRRWkFKODNlZGVN?= =?utf-8?B?YjdpVWFJa2lNK1ltWmpJNmp5UElVVjVsQW9jWmhTTzd3dW5oQmJENit0UkxB?= =?utf-8?B?elRab0pMc3lMQ1lMUGFTb2MxeUc5MzV5YkMydXg4bmhIVlFENkFUZG9KdEVM?= =?utf-8?B?UFNDNDJMcWczZC9nRHZNQVhMbng2OUpvY3FjcytlbHBIeGVmbUVNYk9rQWNi?= =?utf-8?B?OGZVYVhNNEhiWU1MMkJjNnY4endxdndGaklnZ21rTG91UjNvdTFUU2JIWTdC?= =?utf-8?B?S21manZiUFpDc05jS3ZkbG8vNkhEVU44UVBHRnY0aFgzSHZIM1FURDlzZk5R?= =?utf-8?B?K2RZOUJ0U0N3OTRBR2FpVk56YzRJZHVEYytwa0pUb3BVcXJYdXg3bEZYNWE5?= =?utf-8?B?dWdPUkE3dUVWZ1JaalExb3c1L1pWMllldU5udnJkWHJWTUZPMkN3NS9VODRa?= =?utf-8?B?VGF1OEMzYk1UTnR5WllUNW1xdTdGSVR1RTFyK1B5bWlQbzNkMFhWUzVwcVZn?= =?utf-8?B?SWJQQUFGamxlbm8rRE5qbUVjZWhsZEZiWUxBamRpV04xR2NCcnNZM3NSWXZW?= =?utf-8?B?M1BtS2preVR5NGQ4YjZGcG93Rm5yUUZJN2c0Q25MU3pMRldBdVRIVHFrNFFO?= =?utf-8?B?RTVTMUZHV2dMaVJZT1VNeU51aHl3OER4dHNlOGR4eFJxYWdaMzE2cTc4SHlx?= =?utf-8?B?NlJCaHZIZTZDck9OOHJxaDFDSTJPbWFXZzZoK3V4ampSNVhyQjhvWlNTVXlL?= =?utf-8?B?WmJOU3pyOXVJMnNUcnRBUG1jc3RnU2VIcmNUd2lHMWtWNmFqME9RMnoxbFZS?= =?utf-8?B?TXhnWkFvSlkyaXJsRDZvYytPbzltVnliQmZhYVR5QTFOSGpNQTlTMzkrWXlU?= =?utf-8?B?QzhrR2VZSDhwZWtPeWF3end1VkdVb2NybTRpeUtjdW9aNmJOanh3clU3V1JN?= =?utf-8?B?KzhBMG5CMXZwNTVzWnNiVTZ1a3hQWTdsRFppTG1nYUt0NjR3cDRpTFV6WVRO?= =?utf-8?B?RDE0c1A0K1g1Rm9lRmViT0Jva1JPRUpzNUF4SnBGc041QVhxM29VNE9kTkJl?= =?utf-8?B?WFplUGtqMWtpb294SXhSYlNuRWd5czFSZE5LRTVIRkw2bWNyaUlXSHRMOFpP?= =?utf-8?B?eitaK3NKby9Cc3BIUDhLSUw1bXVRVCtDZ3liMlFLM3RkVVVMenJPYzMvVlBt?= =?utf-8?B?NnhPYk9KQjAwRjVSMFBhemU3RitBbnJNdzNYcHJBMnpMbEJ2RFNvRnJ4MUQ4?= =?utf-8?B?R3ZMYkpWLzdWTlRTZDA5SWFzRzVDdUhWUW0rVVB3NHp6Tk90WWROTGNhVjdZ?= =?utf-8?B?YXVLamVkRS96S0QxeXNiZE9XalF3ODV3enpmZUhFV01iSHMxckpCYmxGcStk?= =?utf-8?B?bXpVTHMvS0xxa2xsUVlkNUErcjd2Qjd3b0lRWHpKTmdBQW00QTI3MW5uWUJ1?= =?utf-8?B?WmZyZzQvOUJwcFBzVmNoYzdwNnRRMFFYRGFLWDE4WmhSNGNvd3ZNOURRTk1V?= =?utf-8?B?UUluekRMN09rbCs5bXgzOTRCVEVINFFXSkFnbk9LS2tUMXpPOTdyczl1QlNJ?= =?utf-8?B?aUhHQUhCc09WajNjY094ZnFIUThIMU50YzR4OTg5RlJvSFVMaHhLMVBDcFJu?= =?utf-8?Q?Z3UzIUrKjqNtX1ZtnlENpHtjGspzeaoz9pVdsgZ?= Content-Type: text/plain; charset="utf-8" Content-ID: <92CF2337A0852F4F9A821CC2A4EA29D8@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2278 Original-Authentication-Results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT044.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 2373ee3a-f058-4246-18df-08d919442a24 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CX4+DKKt0gpiLdW1radFk6mgvl39cIPg+Cwfpxi/I3cVoA+olYFYYAHg1kQ5SU1Srb8s6dbRnxH7l9l7ccHN5viaoViMbCxF3fTKJAXsKNt1Dt23FlYpCJ9EWQ1IZikrmE9lFK77WnWcrJSys5BdPyvSsmDYiP0aT856asX5JhgqfEjjbI1LSlVC6AErvtkPut27zM/8tLo4qW7glcpu2Cwyrfytjt9oSJMDZw29b5EBkhr2eVNuknrdhjV9YJ8rw+k51dI4ZNX00jPpG1aJH5xNHEvCR/6Jw4XweS1pTE7aSNf3FkN8OHNx4iKTiXWsSn1V/bGRaaml2q/HPkkSnWhDE3VubpH4j25uiwKdiml+Y+91kXBmM5T3xJV0NDOUaKD679hxa2voCQHln3VyPbKoHVuG0uD2QPsYkZ8w+5hY7bcSObb7wNOEUE7dtYVkfnmZD2ahwsK6Iw4/PjBzp9L5TAcyFoaWDKwdEsJBP30z1Jl73XUTW6snCe2RcnyWY05Jq9bByXEwYNfoQx3mGE1hmgIpzWIR5kqFkbXHoVFL7FZOnP0+GeEZi6NWPbA8FcklVJmYRyyGbz/GMX+jDM3nrUyu/Xaj9EgGQVxLkw+V9H45NZdY/dCqyfb2cs+Ln8/NX0pPtMHzAR0h8s9PaA7StrZIlLfkWZpoPXjHO37Y1N4elHp4v4gvosEB1GRzRx2l0t1RH6rN7G5p5FjxzKbUroFlGUKyzQ8ZvQXGcD2E3bO9JTd3XGYJuYdTeF/xtbbPvmbvv8DIxwV7dBh37g== 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)(39850400004)(396003)(136003)(376002)(36840700001)(46966006)(5660300002)(8676002)(70206006)(186003)(86362001)(47076005)(82740400003)(8936002)(6486002)(966005)(83380400001)(4744005)(2616005)(36756003)(36860700001)(6506007)(53546011)(4326008)(6512007)(336012)(81166007)(356005)(82310400003)(2906002)(54906003)(26005)(33656002)(316002)(70586007)(6862004)(478600001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2021 14:58:13.5775 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6619695b-1acf-4616-2db0-08d919443201 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: VE1EUR03FT044.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5354 Archived-At: Subject: Re: [core] Tossing around URIs to use outside an application 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, 17 May 2021 14:58:22 -0000 T24gMTcvMDUvMjAyMSwgMTU6MzgsICJDYXJzdGVuIEJvcm1hbm4iIDxjYWJvQHR6aS5vcmc+IHdy b3RlOg0KPiBPbiAyMDIxLTA1LTE3LCBhdCAxNTozNywgVGhvbWFzIEZvc3NhdGkgPHRob21hcy5m b3NzYXRpQGFybS5jb20+IHdyb3RlOg0KPiA+DQo+ID4gRm9yIGRlcGxveW1lbnRzIHdpdGggRE5T LCBhbiBTVkNCIFsxXSBwcm9maWxlZCBmb3IgdGhlIG5lZWRzIG9mIENvQVANCj4gPiBhbmQgaXRz IHNlY3VyZSBzdWJzdHJhdGVzIG1heSBiZSBhbiBlZmZpY2llbnQgd2F5IHRvIGhhbmRsZSB0aGVz ZQ0KPiA+ICJ0b3NzYWJsZSIgVVJJcy4NCj4gPg0KPiA+IGNoZWVycyENCj4gPg0KPiA+IFsxXSBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtZG5zb3Atc3Zj Yi1odHRwcw0KPg0KPiAuLi5hbmQgd2Ugc2hvdWxkIGRlZmluZSBhbiBpbmZvcm1hdGlvbiBtb2Rl bCBmb3IgdGhpcyBzbyB3ZSBhcmVuJ3QNCj4gc3R1Y2sgd2l0aCBETlMgZm9yIHByb3ZpZGluZyB0 aGF0IGluZm9ybWF0aW9uLg0KDQpFbXBoYXRpYyArMQ0KDQoNCg0KDQoNCg0KDQoNCg0KSU1QT1JU QU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3Jt YXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Mon May 17 08: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 30C6F3A3B3B for ; Mon, 17 May 2021 08:10:10 -0700 (PDT) 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 Mp0pVcG_UnTh for ; Mon, 17 May 2021 08:10:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A9F3A3B39 for ; Mon, 17 May 2021 08:10:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 77F2C39058; Mon, 17 May 2021 11:19:23 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gGTeVf6jDZ9z; Mon, 17 May 2021 11:19:19 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5491B39054; Mon, 17 May 2021 11:19:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 38B3E5FB; Mon, 17 May 2021 11:09:59 -0400 (EDT) From: Michael Richardson To: Thomas Fossati , =?us-ascii?Q?=3D=3Futf-8=3FB?= =?us-ascii?Q?=3FQ2hyaXN0aWFuIEFtc8O8c3M=3D=3F=3D?= , "core\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] Tossing around URIs to use outside an application 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, 17 May 2021 15:10:10 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thomas Fossati wrote: > On 17/05/2021, 13:47, "Christian Ams=C3=BCss" = wrote: >> * By comparison: on the WWW being tossed a URI is commonplace; they >> are sent over all channels (text print, QR print, radio announcements >> etc), and usable by virtue of DNS+PKI. >> >> They are usable without metadata. If a browser was given a URI of a >> lock, it may ask the user to go through some login service but then >> serve from that URI alone. > This was probably true before QUIC and ECH. Now an HTTPS URI needs > more context to be successfully dereferenced. Uhm, that's not my understanding. If both ends support QUIC, then the HTTPS is replaced with QUIC, otherwise = it continues with HTTPS. >> What I'm leaning towards taking from this is that we should be able = to >> support tossable URIs, but what they would look like in practice in a >> CoREnvironment may need looking into. > For deployments with DNS, an SVCB [1] profiled for the needs of CoAP > and its secure substrates may be an efficient way to handle these > "tossable" URIs. Yes, so SVCB seems to be just more data like AAAA. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmCih0YACgkQgItw+93Q 3WWDdAgAq9LvRMGEOFDoVAoquFVfo2FA3i1Ov1DYvM6lnMMf7I3+C4/YoWGUglwj I7WyCa3U2B3FMKBw+4SKqB7igOUjQGpG8Dktl7Oqg4fUW8EGb1InRz4n4LkbfWHV tzgXm0oHSrlLhR9N+Dr3sd0o3RblAJkPF2nUr4YsIq6eBWYW43CkCiIpXnuSDaKC z+8rERMmhaBDiQVTjFiIKqrSk0zfkInPRaorKF5vYhfEmGw6BsZp02zBkYyxJN/R fU5f7vKi4MC++cq3B7zpEzKAkYIDQCbWzEFgEBmMhsKqpCsaxxpdmu72v0Mqojie w81xPAdnvDR9lXtUt0qE6Ve9cAmyvg== =h3yO -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 17 09:06:00 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 E8B9B3A3CC3 for ; Mon, 17 May 2021 09:05:57 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=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=Z2W0A4v/; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=Z2W0A4v/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LU2jowDsKFSt for ; Mon, 17 May 2021 09:05:52 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30063.outbound.protection.outlook.com [40.107.3.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 146863A3CC2 for ; Mon, 17 May 2021 09:05:51 -0700 (PDT) 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=ySaaDKfKS90Jy47rNavEaHeksFC4GV0km21qyuh8M2A=; b=Z2W0A4v//hlzYkjTF5VPY4rGqrV92xnOE14VC8KKuvpQ+kPqMUmD7xbJsbJg23rUNKEzL8IY+tq8hDhX/OW8VHW4pD4WEFdwIb+VuW8ovSn2Pc5d1fZDuIHIpLDJ70Z72yEXtqmzhcvrFlSGhbTaB9REubrYlf+f6EXYE8NzulM= Received: from AM5PR0201CA0008.eurprd02.prod.outlook.com (2603:10a6:203:3d::18) by AM0PR08MB4337.eurprd08.prod.outlook.com (2603:10a6:208:13d::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.28; Mon, 17 May 2021 16:05:48 +0000 Received: from AM5EUR03FT004.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:3d:cafe::c1) by AM5PR0201CA0008.outlook.office365.com (2603:10a6:203:3d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Mon, 17 May 2021 16:05:48 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 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 AM5EUR03FT004.mail.protection.outlook.com (10.152.16.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.25 via Frontend Transport; Mon, 17 May 2021 16:05:46 +0000 Received: ("Tessian outbound 3c287b285c95:v92"); Mon, 17 May 2021 16:05:45 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: da01e6ce06922f85 X-CR-MTA-TID: 64aa7808 Received: from 78103e86074f.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 33E1C8A1-ED99-4262-A760-53AFD4B07C45.1; Mon, 17 May 2021 16:05:32 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 78103e86074f.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 17 May 2021 16:05:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WnkV6Tuz4+vCYvm2G8qwQP1f/cQXrFUgPOOJGa8zwyLl23bM7guZe36fvm8bGzs0y28jftDJOQlYkljdbbkszE+zQeOsGVLoutvKv2CDKUW/+kgnhPP4zugQVXYizKsluj/GTy2tZyJ59ezs/kGxERS+2WgDhgbpCrJ4Mm6Axb/G5X2XapPpRseXPJB+HaN4NANX3evCFbln/VBtdkBQ9i5OVl4dhzSACQWe2eaILkeKg4VgCFdkXwB+232ADpAsqMK88XZ0E3GD50inVI6uqEb8F4p81ps6wA1u6BQTbt0Fh6deo5Rrbu43o2wnLg7VH/Ys9MO6ZcjjClkqOrJyug== 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=ySaaDKfKS90Jy47rNavEaHeksFC4GV0km21qyuh8M2A=; b=FBhwD+JoBc8oJDV3NsyVkFA05D4v+/8evxpz8o6Y8/TjMuJ11TpdrGHdccNYna911ex6pYkejCo0hekPeeXdDPJjxKZp9YoxV9NKrzS17314h25dtB3k/6A4TZRwW1QYqm5e25TRuUGr4vq+JqUspkmtojEhZWE26cA1Skb3qyOWXS/tJWaBfUdmHkoRxqGnZE/nkYU2mi2UL4/ZMr8OTMKplRsrdRtaim8DhBwVKWlTEeLSZ7srtxI16M01fbUoH67wNWXeBW/qpZmt+aolbXGxJutr1KPskrfyTYa9ZrZX+iU+c+iJLroBf301UuFUAjRw1o23BO7ZBNL3+UBcwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.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=ySaaDKfKS90Jy47rNavEaHeksFC4GV0km21qyuh8M2A=; b=Z2W0A4v//hlzYkjTF5VPY4rGqrV92xnOE14VC8KKuvpQ+kPqMUmD7xbJsbJg23rUNKEzL8IY+tq8hDhX/OW8VHW4pD4WEFdwIb+VuW8ovSn2Pc5d1fZDuIHIpLDJ70Z72yEXtqmzhcvrFlSGhbTaB9REubrYlf+f6EXYE8NzulM= Received: from DB9PR08MB6524.eurprd08.prod.outlook.com (2603:10a6:10:251::8) by DB8PR08MB5436.eurprd08.prod.outlook.com (2603:10a6:10:111::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.26; Mon, 17 May 2021 16:05:31 +0000 Received: from DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::e9e7:ea3a:3bca:5b3c]) by DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::e9e7:ea3a:3bca:5b3c%7]) with mapi id 15.20.4129.031; Mon, 17 May 2021 16:05:30 +0000 From: Thomas Fossati To: Michael Richardson , =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , "core@ietf.org" Thread-Topic: [core] Tossing around URIs to use outside an application Thread-Index: AQHXSxrJSX9LH3/p2Eek61Y76fvwNqrnviKAgAAJEICAACBGAA== Date: Mon, 17 May 2021 16:05:30 +0000 Message-ID: <10ED75C0-7D08-4E30-B7E0-6A837286E365@arm.com> References: <2433.1621264199@localhost> In-Reply-To: <2433.1621264199@localhost> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 Authentication-Results-Original: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.12.10.179] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: ed82f209-1a2b-4860-2b6d-08d9194da19c x-ms-traffictypediagnostic: DB8PR08MB5436:|AM0PR08MB4337: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8273;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: VjBjMnLy+MhEpqLIma26LAcgnt5EL/6KbLBxdK0LTyc3QsbrgZXoW7+gV9F6fcrGSiWsf6qGWekC4VwSazF2yj1k2x4GNAyItk9blE0+yTEenUODDAOse7byxINEPkLOzOLMeZVDtDFtWVrDIHOmN8sBOsVOJMNj5tZplFvH1DyB5LEskEArN6YNsa6NNkv8AydR/ikx8yMgJbK/VGa5IDpt+QM3BLKl0gXK9mp3vKDUCy7BhBjuadRNw5s8QUhYfH+lMkA5YbOS/ebQDecmRYFRvvHgsoTfrYNRltqp1QwwE8+uUejku6HIkB2fc8AYR6VygxPD4qmiKhQ3rx8FuD1/7O4PQq9OLjtxsjvojPyBihMUmHqfVyEkHdxhauQMZxVPcsKRpQp/fBNigTqBK/IVeQBEGgjLkR2ODUm7P2JcQP8mnnjxtD0sl4OG2z2Bt8vKuDNVYF+Ef/BALy62ueRuS6Efq9QI8g9LZkjksUPEPJzhOXpQdhv/sK2Lk3qxbDmvWI8bP/2TpniERDQaTSUWb+L5jHvEdM4CkPGeHDwTEnciLRY2TknKRkIro4s6LcGORgZrRsfXPrLZqYt25ZCas2eBgr3mR6t8nfnXL01DkP8gHpelLsy6P2zHFmObuh44cey19jogDRFt5tolRbvgFzyphxSgIQdRbTqnRgg= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR08MB6524.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8936002)(110136005)(4326008)(66574015)(8676002)(38100700002)(122000001)(66446008)(6486002)(66946007)(6512007)(71200400001)(66556008)(91956017)(76116006)(5660300002)(2906002)(6506007)(498600001)(26005)(2616005)(53546011)(66476007)(64756008)(33656002)(86362001)(36756003)(83380400001)(186003)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?eGVuUHFOM1ptSFJmeGtwMWVpU3k0OWZKSjFpZE52SWRKWDA0MmwyeW9IRzZy?= =?utf-8?B?ckRJMjFzdlRuQnB2NXJoZmEwUTdjZUhKUllUUEM2Y1NRb0FCRHpwMXhsZVZn?= =?utf-8?B?UHVZSFA0RjU0Z0RPUVRuM2pJbHlmbUZBbjdWc2FlclhCaVI3TktiZzZSRFhj?= =?utf-8?B?bWhwc09aOUEvdERQWStYT25ySEtYZmlJeG9aRWtaQ2I5R3UzTFZzWXREclB1?= =?utf-8?B?bk16NUJxMHhjQVZleFY5VUwvQXJKNHFtbDBkenFVQ21UZHNQZzRqQS9ieERj?= =?utf-8?B?bEFKUTczYmU3NzMxaTBqcTFJL1lMclhpQVVGVUVOQzAwSDRVNDJ0UUpWQ3Av?= =?utf-8?B?VTBQTWU3TzdyYzVrNzNXM2E4b3hCNllpUmwrdmozYjhPUkwra0ZEdEs1dHBx?= =?utf-8?B?WFRaV1NmVGlLYm5PcW40RkJnSy9NOUJGWnpTQjBSRDQvWDBPRVJGdWcvYXFS?= =?utf-8?B?MklaU3FVWWZRU3MyZnRUNS9wdHd0UjBiOFpUeDQ2K0JBWk9LekFPRmhGNThL?= =?utf-8?B?L0EyME80TTdLZ1J3cFBBWHI3TGpCSDIyMmJRdzJhb2FrRjF6YnhOWkVBZHV6?= =?utf-8?B?ZHEvM2laRWZMVDlWbW5EMSt0K2p1RVM0SHNCZFI3eEZSUkF4ZWtGaDFwR01t?= =?utf-8?B?blQ4STZvbERtUDFLNkh2aUZZbmt5UnFBb3c3aGIraThZTER1QndVNmhHSURt?= =?utf-8?B?cVJMcGtHYmxpaDJ2MnA1bTl1SXJRU2lNb0ZCUmtiYWduSjlBS3dza2VObzNU?= =?utf-8?B?M09uTjkwTjlJeGgxUmJrTjdqUWZJZ2l5ZlI2K1RROFgxa2VSTHJEQ1NnM3Nl?= =?utf-8?B?dWxibUl6bGxyVFlZWVlWZ0NiQmxtQU80L0NadmYzUVAwRFJpUVFXcTg3Rzhh?= =?utf-8?B?MXM3MS9XWmNLMzRyMGRBemhheWtWR2NUSHl1UVhzaWQ3RURPVURMVW9TTHBh?= =?utf-8?B?MnZSU1FjSEpINmV3TWs2Uy8wZDZVWm94TzBONmFZZGZJRkhVQkEyOVV3UjJy?= =?utf-8?B?WmV3U0dVVDhJT1E3Ulh4eGNyWEpOb3ltWnFOVU1yVnhFaWgvQjJvS3g4R2hv?= =?utf-8?B?TzVTZktUTXRyTzdtb1NWMkNPbXVsQUVuNlJTU3U2ZE11bnV0YUIrV3p5RkNu?= =?utf-8?B?SlpNVVQvS0ZFL3VJZW1jU29Kci9HSGgyTzlIdnNTR2Q1WE1kWkRTMGdtblhV?= =?utf-8?B?WTlId3hvVXpDOW9Lenc4S2hacVlVYjczbHNLd2o4dUxGUGx6RHYzQjhoNG5J?= =?utf-8?B?WExUdUlqQnlJMzUzRk9KS0ZWd0tPNnRBS1NRL3lUd0dxRGlrNEpUTFpka3NS?= =?utf-8?B?U3FjeFp2bHJNOUF1bTZQVTRUUWJwc0VZMWdvek5TZFR0WnRCZG1wMFpsUDNh?= =?utf-8?B?RVNGOHB6WHdKL3JQOGJQWE0wa1FwRlZYMUZhUWZNcFA1Ui9GK1FNVHpOellH?= =?utf-8?B?cmM2cURKUVJGRVdncG1iWnlCVXFZQlZnb0dSZjNVRWlBUVhaeHU5c1RFeGhs?= =?utf-8?B?Y0ZkamRnZWxQS0VsSHNBeDhBdmcwUlgvdWxMUzJtUW1PQ0lqT0Zab29LS05y?= =?utf-8?B?WTIwVlhLSHl2MzI1OEJ0N1E4V3AvbTJkVm54M0J1eDV1OEhmWXRHVWd1NG8v?= =?utf-8?B?b3NCZmpvdHlHUXpTcXFkRW4yS3FPK2hHMmxhRUVHNDJmYWdsc09xSGdQM0x0?= =?utf-8?B?Uys4eEhzSitYRzRWbkRwdWVFOEJBTmlCNW0yeVdaWXpNbUtxRFo2VUh5NEFH?= =?utf-8?Q?5G+S9GBbFil2LghUjCgi9IcUfY0PmIJkg9wfrFG?= Content-Type: text/plain; charset="utf-8" Content-ID: <6F65E76EDC7EB8448A5A6E0CE419FF14@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5436 Original-Authentication-Results: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT004.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 277f62a7-d520-4ef0-7c2c-08d9194d985f X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: iTIVAcFdbEDyvdCr6XYsSlYF2snieK+reauGRuHQVEFmuycETS8gyNm8uvLyqw87oOIzQZlAJiKCJICxTjlJ6czl4+SSfjmVKszdQfOS2uBc71a8VBA8HGAXIaL4MtkDDyQoBhKh53eq6Geq7oD8cpEwJId9qf4+VKyb8hHkMZo4Q8MsW86Ijbt1Vjq+xjTM9V5LZLzn73wGCEI9mjZjnM+rprqV8HQRCwa3kjOQeuksNR/SsyaAu3NTAwxZUdVduf9rapTO6bouUUCGXL8WSSaZkpTWrb+fdcomA48wjrLd8tU+lUDiFU/8q1vR7gJpiZ4LF0jzIyXMhieDTXer4tVcQPiF/uNFmbKhHfjiXWSG895V/SogQ2oW8cmkRKZPT2p9GJgKjgliLkbq01KvjQVd4APFqy/7A8ST2lY/q07Tf6kiXRd10A8Nnv/H0F7BMb6FxK4voM3Qp8LXty5A+rOBEMK8hwoXnI5qwxa5R1rE3B3huM3U8Z7dwcnjwN/6OD1HNjyxElePQwVGC7e1vJTlMpCgvONeRkLMjWzDJxag4joWy9hQuCSU2WPkb393g37yXXAn+FpxMEs7YCyN0bAVN+BVpDp2sgqcsoLGMmkBxOb7BAuFwoisOQfYtMAZYqrJmhEy+6SFW8BTXUDat4KACWkudWtf1VFA4iY1dLg= 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)(39840400004)(136003)(396003)(346002)(376002)(36840700001)(46966006)(47076005)(336012)(70206006)(186003)(26005)(86362001)(6512007)(6486002)(4326008)(70586007)(8676002)(53546011)(8936002)(2906002)(478600001)(83380400001)(66574015)(36756003)(316002)(33656002)(81166007)(5660300002)(82310400003)(6506007)(110136005)(356005)(36860700001)(2616005); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2021 16:05:46.3574 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ed82f209-1a2b-4860-2b6d-08d9194da19c 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: AM5EUR03FT004.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4337 Archived-At: Subject: Re: [core] Tossing around URIs to use outside an application 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, 17 May 2021 16:05:58 -0000 T24gMTcvMDUvMjAyMSwgMTY6MTAsICJNaWNoYWVsIFJpY2hhcmRzb24iIDxtY3IraWV0ZkBzYW5k ZWxtYW4uY2E+IHdyb3RlOg0KPiBUaG9tYXMgRm9zc2F0aSA8VGhvbWFzLkZvc3NhdGlAYXJtLmNv bT4gd3JvdGU6DQo+ID4gT24gMTcvMDUvMjAyMSwgMTM6NDcsICJDaHJpc3RpYW4gQW1zw7xzcyIg PGNocmlzdGlhbkBhbXN1ZXNzLmNvbT4gd3JvdGU6DQo+ID4gPiAqIEJ5IGNvbXBhcmlzb246IG9u IHRoZSBXV1cgYmVpbmcgdG9zc2VkIGEgVVJJIGlzIGNvbW1vbnBsYWNlOw0KPiA+ID4gICB0aGV5 IGFyZSBzZW50IG92ZXIgYWxsIGNoYW5uZWxzICh0ZXh0IHByaW50LCBRUiBwcmludCwgcmFkaW8N Cj4gPiA+ICAgYW5ub3VuY2VtZW50cyBldGMpLCBhbmQgdXNhYmxlIGJ5IHZpcnR1ZSBvZiBETlMr UEtJLg0KPiA+ID4NCj4gPiA+IFRoZXkgYXJlIHVzYWJsZSB3aXRob3V0IG1ldGFkYXRhLiBJZiBh IGJyb3dzZXIgd2FzIGdpdmVuIGEgVVJJIG9mDQo+ID4gPiBhIGxvY2ssIGl0IG1heSBhc2sgdGhl IHVzZXIgdG8gZ28gdGhyb3VnaCBzb21lIGxvZ2luIHNlcnZpY2UgYnV0DQo+ID4gPiB0aGVuIHNl cnZlIGZyb20gdGhhdCBVUkkgYWxvbmUuDQo+DQo+ID4gVGhpcyB3YXMgcHJvYmFibHkgdHJ1ZSBi ZWZvcmUgUVVJQyBhbmQgRUNILiAgTm93IGFuIEhUVFBTIFVSSSBuZWVkcw0KPiA+IG1vcmUgY29u dGV4dCB0byBiZSBzdWNjZXNzZnVsbHkgZGVyZWZlcmVuY2VkLg0KPg0KPiBVaG0sIHRoYXQncyBu b3QgbXkgdW5kZXJzdGFuZGluZy4NCj4gSWYgYm90aCBlbmRzIHN1cHBvcnQgUVVJQywgdGhlbiB0 aGUgSFRUUFMgaXMgcmVwbGFjZWQgd2l0aCBRVUlDLA0KPiBvdGhlcndpc2UgaXQgY29udGludWVz IHdpdGggSFRUUFMuDQoNCkV2ZW4gaWYgeW91IHN1cHBvcnQgUVVJQywgdGhlIHRyb3VibGUgd2l0 aCBhbiBIVFRQUyBVUkkgKGkuZS4sIG9uZSB3aXRoDQp0aGUgJ2h0dHBzJyBzY2hlbWUpIHRoYXQg aGFzIGJlZW4gZ2l2ZW4gdG8geW91IGlzIHlvdSBjYW4ndCBrbm93IGluDQpnZW5lcmFsIHdoZXRo ZXIgdGhlIG90aGVyIGVuZCB3aWxsIHN1Y2Nlc3NmdWxseSBuZWdvdGlhdGUgUVVJQyB3aXRoIHlv dQ0Kb3Igbm90IGJlZm9yZSB5b3UgYWN0dWFsbHkgdHJ5LCB3aGljaCBpcyBpbmVmZmljaWVudC4g IFRoZSBwcm9ibGVtIHdpdGgNCmFuIEhUVFBTIFVSSSB3aGVyZSB0aGUgc2VydmVyIGVuZHBvaW50 IGlzIEVDSCBjYXBhYmxlIGlzIHByb2JhYmx5IG1vcmUNCmNvbXBlbGxpbmcuICBJbiB0aGF0IGNh c2UgdGhlIGNsaWVudCBkb2Vzbid0IGhhdmUgdGhlIGx1eHVyeSBvZiBhbg0KaW5lZmZpY2llbnQg ZGlzY292ZXJ5IHRoYXQgd2FzdGVzIGEgZmV3IHJvdW5kLXRyaXBzIHRvIGdldCB0aGUgc2VydmVy J3MNCnB1YmxpYyBrZXkgdmlhIEFsdC1TdmMgb3IgQUxQTiwgaXQgb25seSBoYXMgb25lIHNob3Qg Oi0pDQoNCg0KDQoNCg0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBl bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJl IHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBj b250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBz dG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Tue May 18 00:49: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 470273A1014; Tue, 18 May 2021 00:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXArsU0MYNbv; Tue, 18 May 2021 00:49:17 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 4C7E63A1007; Tue, 18 May 2021 00:49:17 -0700 (PDT) Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 1BFDF600C7E; Tue, 18 May 2021 10:49:07 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1621324149; bh=ZxG1iZYCsuG0+45DkQzW35nmwZ2yyZcNPunXqyIi5x4=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=vbjwHXUZ4LJh99I3JENyeiQDowk28EtSIYN8XMsMgMfMazoP5gz4Dtkf9p4WPrpTK ktMahoV+3KjpsKPwDXbyTGT6AZLihubzfijWk1QXmaj/7+oUFHrSJCq+Lf/PxsG1Jy lLyOXK7phtu4Mv2CRnp/ANQy8qtBMvWnjAnLtnUc= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_04B82520-41D3-4E39-A814-AB63A7163327"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Tue, 18 May 2021 10:49:06 +0300 In-Reply-To: <041601d7473f$7113e540$533bafc0$@jpshallow.com> Cc: mohamed.boucadair@orange.com, draft-ietf-core-new-block@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org, marco.tiloca@ri.se To: supjps-ietf@jpshallow.com References: <162039183121.15574.16597240090409070575@ietfa.amsl.com> <29803_1620395762_609546F2_29803_68_1_787AE7BB302AE849A7480A190F8B9330353787B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <666D5FF1-9E96-4522-A0FB-0A3042225BE7@eggert.org> <17373_1620734755_609A7323_17373_63_1_787AE7BB302AE849A7480A190F8B933035384380@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <47273993-E4D3-4042-85B5-17163C984B18@eggert.org> <17932_1620739727_609A868F_17932_314_1_787AE7BB302AE849A7480A190F8B9330353854D5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <39AC6D5F-0FA3-4FE3-BD59-302B65CFDE49@eggert.org> <041601d7473f$7113e540$533bafc0$@jpshallow.com> X-MailScanner-ID: 1BFDF600C7E.A92FA X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 07:49:23 -0000 --Apple-Mail=_04B82520-41D3-4E39-A814-AB63A7163327 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-5-12, at 17:59, supjps-ietf@jpshallow.com wrote: > I have come up with some initial draft changes - do these work for = you? >=20 > Please see > = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-new-block&url2=3Dhttps= ://raw > = .githubusercontent.com/core-wg/new-block/emphasis/draft-ietf-core-new-bloc= k. > txt thanks - these do work for me. I will clear my DISCUSS. Lars --Apple-Mail=_04B82520-41D3-4E39-A814-AB63A7163327 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmCjcXIACgkQVLXDCb9w wVeyUA//VUu0OLgAs7JEZb+tGibkDrODievulFQ7Ft4oWj/ppf7NOCte3VE7biW2 yNjRG66iV/eS6ezI1gsaTXWhMlnqmcy0w8gVYHOisqgZCoK6uDi3q4ge23OyJDwn Fx1l1CJIQWGz6glgKWeqOEcso0ZZXh8JUAUrwl5A8be7a/wrwUkLuOOMJ3TGdjHa YtHVHj2BGj4/5ZAE55mUUIEArrnMbVvg0il+oAsxrJ7H2I7rKGVPZlMjG95Het54 uSmScL0ispoXSlYuCP1PZRVBK+fs7Q5UJFOPjjq7EXNwYqC+d0WqHDJv7ageKJ8A pu9nWRXaO+CNPQCv9Po1SKEMC2xUCGZOOqx7LzZN41XhcjU3iXBhyLo3RntFZ5AC 9FS3gYv8RRhp58mVsVmmr5az0+pvIcndcnbLYr8Pt/VRdMerh2yoFugimyiKf+0y REFydrw+/HRc8iWQXfbR6O7L8FrHm5CBYVUxhFLC67I817IaTJmowoVtbbO7nDcy zxqcUUPTJeCniGyLhLPhlroyUUEkzQj9rzR6QX0UxLUku7PMkGdZmaitMSikae9q 8xi79MiHr+So6WOhgxkyYCBRzMyaUpW0DwEezbmiWl12U33/8BeACTkGRuj3ZCpx AzmxQtP8c2K73EnAl91gDHk7o92wREiXUnk45XczS1Q+Wdl6A+0= =3YmU -----END PGP SIGNATURE----- --Apple-Mail=_04B82520-41D3-4E39-A814-AB63A7163327-- From nobody Tue May 18 01:07: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 653943A10F0; Tue, 18 May 2021 01:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 hsi1s-0yhFqN; Tue, 18 May 2021 01:07:01 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 515E53A10E8; Tue, 18 May 2021 01:07:01 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar20.francetelecom.fr (ESMTP service) with ESMTPS id 4FkpW669Zcz8vC6; Tue, 18 May 2021 10:06:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1621325218; bh=nGfQnMTJJJkBzr4EhDp0MhkrVS1xowVUNf8zcsuedyg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=eUqDK4Pgvj9YqURVKuuGfocGkjPt2dyUfETKIp5carOpBionSAJ677gO0dPGgt5HQ un0Y0lbqzgwiaqrb4x7uRT9mNYO0BX9nzfNsiYSRO/ccwl/G7kiJ5X6hzj+ciCp2w5 X0uRfbcWWjLk8K3M5hTGfOUZ9XwdCYnynShqmxTBXVIdhHU1+VaJE7gM7ih+o1jbYi SO7kFWehpW6Qi9t2n0FS+ZzBFSihRTqnSHm7nJHn14ItKtWx9iWhat75tPM1Wen6PQ ceQMcebxo7WAd9QVWTuwhZ110zxa+1BTZ3y96wNX0q0LH0hJqREcRPxT2G+LG9ALVQ H2IyjuWZ7V9hw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4FkpW64czqzCqkb; Tue, 18 May 2021 10:06:58 +0200 (CEST) From: To: Lars Eggert , "supjps-ietf@jpshallow.com" CC: "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXS7pHbs3/HDljMxiZ+ChpLivgHqro4SkA Date: Tue, 18 May 2021 08:06:57 +0000 Message-ID: <27210_1621325218_60A375A2_27210_211_1_787AE7BB302AE849A7480A190F8B93303538A21F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162039183121.15574.16597240090409070575@ietfa.amsl.com> <29803_1620395762_609546F2_29803_68_1_787AE7BB302AE849A7480A190F8B9330353787B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <666D5FF1-9E96-4522-A0FB-0A3042225BE7@eggert.org> <17373_1620734755_609A7323_17373_63_1_787AE7BB302AE849A7480A190F8B933035384380@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <47273993-E4D3-4042-85B5-17163C984B18@eggert.org> <17932_1620739727_609A868F_17932_314_1_787AE7BB302AE849A7480A190F8B9330353854D5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <39AC6D5F-0FA3-4FE3-BD59-302B65CFDE49@eggert.org> <041601d7473f$7113e540$533bafc0$@jpshallow.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 08:07:07 -0000 Hi Lars,=20 Thank you for checking. I merged the PR. Will wait for Ben before releasing the updated version that includes these = changes.=20 Cheers, Med > -----Message d'origine----- > De=A0: Lars Eggert [mailto:lars@eggert.org] > Envoy=E9=A0: mardi 18 mai 2021 09:49 > =C0=A0: supjps-ietf@jpshallow.com > Cc=A0: BOUCADAIR Mohamed TGI/OLN ; draft- > ietf-core-new-block@ietf.org; core-chairs@ietf.org; The IESG > ; core@ietf.org; marco.tiloca@ri.se > Objet=A0: Re: Lars Eggert's Discuss on draft-ietf-core-new-block-11: > (with DISCUSS and COMMENT) >=20 > Hi, >=20 > On 2021-5-12, at 17:59, supjps-ietf@jpshallow.com wrote: > > I have come up with some initial draft changes - do these work for > you? > > > > Please see > > https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-new- > block&url2=3Dhttps > > ://raw > > .githubusercontent.com/core-wg/new-block/emphasis/draft-ietf-core- > new-block. > > txt >=20 > thanks - these do work for me. I will clear my DISCUSS. >=20 > Lars ___________________________________________________________________________= ______________________________________________ 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 Tue May 18 03:06: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 C008A3A15F1 for ; Tue, 18 May 2021 03:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Jqii0_9XKK-T for ; Tue, 18 May 2021 03:06:12 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9623A15EE for ; Tue, 18 May 2021 03:06:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5CE4C390F0; Tue, 18 May 2021 06:15:32 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2z6x4EjRtTKJ; Tue, 18 May 2021 06:15:31 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8A222390EE; Tue, 18 May 2021 06:15:31 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 758151675; Tue, 18 May 2021 06:06:08 -0400 (EDT) From: Michael Richardson To: Christian =?us-ascii?Q?=3D=3Fiso-8859-1=3FQ=3FAms=3DFCss=3F=3D?= , core@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] Tossing around URIs to use outside an application 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, 18 May 2021 10:06:18 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christian Ams=C3=BCss wrote: > A thing that came up in last week's interim is the usability of URIs > that you are just "tossed", with respect to secure usage. Yes, I agree that this is an issue. I've been thinking about it all day yesterday. (Since I was awake at 4am for RIPE82, and I passed out on the couch in the mid-afternoon, I have to repoprt that I actually kinda dreamt about this. This is a kinda of "day-mare" that I just don't recommend.) > (And apologies for the long mail; if I had the clarity of the problem > I'd like to have it would be shorter). I always thought that Mark Twain first said this, but apparently he might have been quoting, and it might have been Voltaire who first said this. I've omitted your UI thoughts, because I think that they are mostly spot-on, but may be distracting. > For reference, a question was whether EDHOC-authenticated CoAP would > use its own "coape" scheme, or if not how a user of "coaps" would know > whether it's DTLS or EDHOC+OSCORE secured, or (given coaps implies > DTLS) how a coap user would know whether to use plain CoAP or try > EDHOC, and if so at which authentication endpoint with which > credentials. I think that we should just focus the discussion here. I think we probably need a coape:// scheme, but coap->coape upgrade should = be common. EDHOC is unlike DTLS (or HTTPS before it), because doing EDHOC requires transactions at the CoAP layer to resources other than the intended target resource. Given that we do all of this because we think that we might be proxying through other transports (TCP X HTTP X BTLE) I think that any kind of DNS or discovery ahead of time may be a irrelevant. I think that the discovery/dynlink process should create a channel towards the target. The channel might include clues, like those returned b= y DANE. But, I think that we must always be prepared to accept 4.01 (or maybe another new code) says to authenticate. We might get this code even though we already think we have an EDHOC session up, because maybe we used the wrong credential. > As it finds a DANE record with a public key along with the name it > resolves, it initiates EDHOC expecting that public key; for itself it > sets a key-by-value as it has no key it expects to be usable for that > server. I can accept this as a hint process. > What I'm leaning towards taking from this is that we should be able to > support tossable URIs, but what they would look like in practice in a > CoREnvironment may need looking into. > Do you think that would work? If we want to avoid disclosing the URL that we using and then get the 4.01, then we should doing an opportunistic EDHOC to get privacy. How (and if) that is authenticated is something we should discuss. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmCjkZAACgkQgItw+93Q 3WVaigf/Yo3AbYUKznnOX16KnAX8peMY+wzW49X1g9F6d0lbubEIyPhN2UPytMSF eMYSbE0K3jIcqm/PsF6bII3ruffJlkRSgNcUyJKiYHLJ3xiLppu3bfmDJoI05eJl aU7SqBSPhCUvOJmv1euXmMTrlnvsaMNfaHntDCtdgKab2+Bfn/S5FLJiYh44hidk loxZaxOfaUrTFezxuFMEKFh+waksQlnXmP4jfCEW7jQkJaUSuFV3TjBZw8+EF+Bx eSGKCEqLf6Xha7sKkh0rBK9a+LAP/srv1lM4jh89CEI7erZ9wImJEFtfwcP7uusG mHXi8GX9X5xNWmAF3RhDn4TSwjKYzw== =QT42 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 18 03:17: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 225933A1528 for ; Tue, 18 May 2021 03:17:40 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_fYZ2fQ1h14 for ; Tue, 18 May 2021 03:17:38 -0700 (PDT) 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 49A6F3A1505 for ; Tue, 18 May 2021 03:17:37 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 888AC407F3; Tue, 18 May 2021 12:17:35 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A515CD3; Tue, 18 May 2021 12:17:34 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a014:89c6:8ba:ba93]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 5A06810A; Tue, 18 May 2021 12:17:34 +0200 (CEST) Received: (nullmailer pid 940151 invoked by uid 1000); Tue, 18 May 2021 10:17:33 -0000 Date: Tue, 18 May 2021 12:17:33 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: Thomas Fossati , "core@ietf.org" Message-ID: References: <19288F96-6650-4D81-BBFF-19153DB5CE3A@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LnqUfaFcvBibUub/" Content-Disposition: inline In-Reply-To: <19288F96-6650-4D81-BBFF-19153DB5CE3A@tzi.org> Archived-At: Subject: Re: [core] Tossing around URIs to use outside an application 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, 18 May 2021 10:17:40 -0000 --LnqUfaFcvBibUub/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > =E2=80=A6 and we should define an information model for this so we aren= =E2=80=99t > stuck with DNS for providing that information. Whatever comes out of the EDHOC discussion about transferring public keys by value could also serve this purpose. In [82] and [88], contenders for that seem to be stripped-down `COSE_Key`s, C509 "certificates" (AIU they're not necessarily certificates but can be RPKs just as well) and CWTs. This has some overlap with what can currently be expressed in DNS (public-by-value would relate to SubjectPublicKeyInfo). BR c [82]: https://github.com/lake-wg/edhoc/issues/82 [82]: https://github.com/lake-wg/edhoc/issues/88 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --LnqUfaFcvBibUub/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmCjlDcACgkQOY0REtOk veFa/Q//ccWzJgyFza32L5u3/5wEgmjbuC1f2zqve2+kFqIuH8qUEQQ2OrUgqKKR 1I6Wr/G6DxAx9raCDsusUlyCGJRSA7wRwkKUo8g6MxCeHjexWACN5xnyt1Hsp7Ks OTTH1Ahu51hWilwL+3gkriPmpEK+liYpLauYbyqJ2yE5LADw/gFfvLsLARlMOZKS S9E1w/xSEfYaCPgzYTObwlDiDcrlB+EQZhosXDDOyNUOvYnetUZWGrkbUcs7KQNp er7qoJdEkGmlvPn4XCoA9/6zKyHf9z2+5a0Fq5mDB8HV8xKILiQU/UIUphs1BiXz gXDfpBOVgySJkmKHd9tOCz5xQYryehRgv3lThk/BilP5OtefOZ9AmCjKkVS118Dr topFvZbY8mF6uNuZZZyGgGw2y5iVj7JcpU4UMdsHDflXZ6nwiDCXutyRcqf7/eL9 muZXQPYMwuI+SWJWZZo3ozXQdzQ9pxs5sY9z8kOJ4MtzYNGeAlg4QQDe852UYYPJ qK6ssH06cpqKNJDkyRTc4ccNQ7wvikbgCDHivXgpwkRmpMk0BXgMHUL7q76D+A+B Mn9jjEfTfuEjMxDbn05b4D82o62mkjRgr7A71XZIyJfXPEPlp1QKn7VOBocMJXZ1 +Xft129ccwaBaKktg7+VAkW3RIO4XEL5cN6yeoxNDDltxWn7jps= =5gQY -----END PGP SIGNATURE----- --LnqUfaFcvBibUub/-- From nobody Tue May 18 03:31:36 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 E12323A16ED for ; Tue, 18 May 2021 03:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BJH3rvTvivEF for ; Tue, 18 May 2021 03:31:31 -0700 (PDT) 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 8CE5E3A16EA for ; Tue, 18 May 2021 03:31:31 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id AFACE407F3; Tue, 18 May 2021 12:31:28 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id D51D8D3; Tue, 18 May 2021 12:31:27 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a014:89c6:8ba:ba93]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9D47C10A; Tue, 18 May 2021 12:31:27 +0200 (CEST) Received: (nullmailer pid 941278 invoked by uid 1000); Tue, 18 May 2021 10:31:27 -0000 Date: Tue, 18 May 2021 12:31:27 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Richardson Cc: core@ietf.org Message-ID: References: <27386.1621332368@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Sktn/9cP5xkEb8ot" Content-Disposition: inline In-Reply-To: <27386.1621332368@localhost> Archived-At: Subject: Re: [core] Tossing around URIs to use outside an application 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, 18 May 2021 10:31:35 -0000 --Sktn/9cP5xkEb8ot Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, > I think that the discovery/dynlink process should create a channel > towards the target. The channel might include clues, like those returned= by DANE. Agreeing. The URI should suffice -- but if the linking page so happens to send hints (be they DANE records volunteered over DoH, or something COSEish in a more constrained-oriented data model), they allow saving some round-trips. (Same should, by the way, go for protocol negotiation). > If we want to avoid disclosing the URL that we using and then get the 4.0= 1, > then we should doing an opportunistic EDHOC to get privacy. How (and if) > that is authenticated is something we should discuss. *That* is maybe where "is application specific" comes in -- the client application needs to know at some point whom it may disclose its operation to: * the public, doing an exploratory unprotected GET, * only active attackers, when doing opportunistic EDHOC, * or only the authenticated server that is authorized to see the request, in which case eligible trust roots and kinds of edges there have to be configured. Thanks c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --Sktn/9cP5xkEb8ot Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmCjl3sACgkQOY0REtOk veHG5A/+P10Da10ektzst2b6r52RX8cJhtEbwLbuX0HFqbyA2N88D8D2RkqM3Dnh sQHi3PiuWf2Bsl72zSWlNCXVufuVZzjcVUi01qUXm378VI/JFWGyQIDOwjmGgLuR 9R776RK58X/m64VBM4yu7N29HnDjBWRiqhBNbHVJxtW5FkAAjl00koVZCWZfu3Ky EiXYRh9AjMt+w432GBIe4ETJyGU5XydQjMyJHxKtylmiHjZ5h1XyOiu5OZ0PxebU Lc1MvGiP/pTyHtL0Gse/f9v58YEmqF7DtshxezisWoZrgYpucTMqey8IjbF9d1Zz I1wI+Q4VjJik9zGlsOxq7rXY3sK+KwdygG/0K6WTtGa6+6D1ussYjrCE+HCSFoxR P/lHvZyL6EZcWNyf1Pepx9nlxhMn6CsTQD9Gz4uVsYJgnUBLOkCP14TJb6+KKHbT nRMR1dxIqp4OPYUZCdNmsnxD1Qv3NUmC12MZlu6Vtw2YqoJK/nig70DqLBnn463R VnTkes0ShElXpcGHtFZqJtcPP98HHIaOdt7sD4tzwOrofyF9QH9aIK55QVtydQjU zThjVDS8QccnG8rim3c+I6lXv1VoGXlXZXkyAmYIA9QPeAV4dij5io++IbzqhJok UL1t2FlKoP87Zdv3FyfMiF74Hs8XBaYrIuV0f+Hdy/Qn0efDfyk= =wPyh -----END PGP SIGNATURE----- --Sktn/9cP5xkEb8ot-- From nobody Tue May 18 20:08:00 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 54FFB3A1B0C for ; Tue, 18 May 2021 20:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, 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 QzaXMRCvLtQ4 for ; Tue, 18 May 2021 20:07:53 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2069.outbound.protection.outlook.com [40.107.22.69]) (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 F26C93A1B0B for ; Tue, 18 May 2021 20:07:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C+pgUHBJb9gRaBydvDsS/1GjwHKZF6XalX/93IVEeBy/CMMPH81mAWBDleGvbyguIQ944UruT88wOeYUIhiYmmBhlbxmSpn3u828DAIyCMCDq/UwMptsOiVNwa+11F5s9Lcy9f21PvCYPJrA2yhR2cb184BOk58vFXhcEwSL2kgDuAbyx+yGBnp0ivJeXaVxloFqxFA0WvnVVRdutemHSgSJTPUVrKKW6F9f+mP0ewY+YHmD2S0AecTBWy8m4u5sXP0HvsRn4smG3vWqCB+ea9qVdkz5exy1Ajhj1DIqydu+nE7fgRitpoT7HMhjofk62gvnELxJlI3E0sRHsAHaMA== 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=vdBrlp/45SLcCswvwsg06DnhKQPRysryO1UNKTKNQE0=; b=TFn8sb72VfyikIMJCq3fqRCtUchR1LJhjhLoCfVIxEi5sUYGpZECNnUbG9pJe9Ily6AF1VJaFeI9i0/46NPNsJePq4wHus1XBdDLA8FbzPcbCQHragRxXU4JJvUYOqx1YKdtRi/CPb4mnugxnk9Vs7fD5jomUPyvH10No3eagjs9aHbAgtRDzEGMWoVqzVxE+TcUi/HgiQVXNA1162EvTpQfeZwElUzpy7MpQsf1HSUfOhsKZW3rcKu3IN8+NpsSlGz3FMZdSOMrgBk5kuRNbRzmpeEMbf0VVeYZxDAh3ldK3wkLBpHrQvn4nbQ/BiEc43dWY1lc7YZg3kut3V7hCQ== 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=vdBrlp/45SLcCswvwsg06DnhKQPRysryO1UNKTKNQE0=; b=fb7PSlWIIs5UpnMTQc8jekGBjlalWiYwgp1M+kgYonCA/uTXTz3+WmeEOcil5JTo4f3A/YP+Kfwy9O1EYn1tD01fNc30I1auTNBplk8va6ZZrr//6sCoZIofWl81i5GSBgh29lQx+K5LMCb1+qE0EwRBcIs1UM1X+XvrX434HEc= Received: from DB6PR0701MB3047.eurprd07.prod.outlook.com (2603:10a6:4:74::7) by DB6PR07MB3270.eurprd07.prod.outlook.com (2603:10a6:6:17::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.11; Wed, 19 May 2021 03:07:50 +0000 Received: from DB6PR0701MB3047.eurprd07.prod.outlook.com ([fe80::f0fb:72b:8eac:53e8]) by DB6PR0701MB3047.eurprd07.prod.outlook.com ([fe80::f0fb:72b:8eac:53e8%4]) with mapi id 15.20.4150.019; Wed, 19 May 2021 03:07:50 +0000 From: John Mattsson To: "core@ietf.org" CC: Benjamin Kaduk , Roman Danyliw Thread-Topic: New Version Notification for draft-mattsson-core-coap-attacks-00.txt Thread-Index: AQHXSnV4ZAucNTMViUWiB8vAbqceOqrqROWA Date: Wed, 19 May 2021 03:07:50 +0000 Message-ID: <885D9BEC-2A2A-4710-97BB-1BBB0CD6D22D@ericsson.com> References: <162118463178.7394.3689900002808274496@ietfa.amsl.com> In-Reply-To: <162118463178.7394.3689900002808274496@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 82dba3b3-c160-407f-f4c0-08d91a734938 x-ms-traffictypediagnostic: DB6PR07MB3270: 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: hoKStoUNxh5IpbKJI9E6xH24BeRmZBvIufEm7Da9SjkaaN+d1jWsZAe1Ql0STTVw0s1A2taOpvjpvly4iN84LTlDLuQaRKLbmd7dLTE4y/euXlFV2lXiiMmaBo8q6g0KMTTo7yCqQ9CopXAcGqfAsNzOS1ysldParSIbzfm+z2Vv0KkU/A7SDipvLRdG/alUk3LzF2VrOzW4iJyzFbiY4h/Nivfhy6d7KRI9qxqU6NV8xZTMa4/XbYI43TPHw/2iuvj2WLG4YG3BXqQkAEPpnmtZtSkM55pro1fRXwaOXRyHRUUL2EmxtC+Msa8ttetFabZ850nbL0q2xX5+V4ptE1X/4kFRaNKO7SaLpM/JFNsp/sHZwEY32XtEyunKcPCPucQKl4IAqs6uTuB4ccb3WGXeMs69X0A8gjGY4iui8GQsqvxqiMXvwTNeDprInVGDtlX5nvPIY7IByZKJCNj/LOdWY2xDzc2jvWBVz4vVsJwLmsLvMCZLI8DZZcZe5mCxGD9TiQcPgSlumZehOD9QDAy5Hop9eoJ1Qoi6I3tpnJ8M9xBSs4doTXyCYXELBnJvHAFGImcgeX8XJgZaIKv8x16kj9VnzE73xWKLCo3rigA2acjo+ZAens8ruNslAWeC8s4xlUg+b7GVJ6/4GkGgu6XKnLBzy+Pv515Dp85gECwtCNRuPmj/eHPsmcgQdRQ7iOEWRtJ3km5qua1Dc+HbvqVhyzsy/iDb+Q6cgmCJLIw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0701MB3047.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(396003)(366004)(346002)(39860400002)(26005)(66446008)(66574015)(6506007)(86362001)(4326008)(66556008)(64756008)(8936002)(91956017)(2616005)(71200400001)(53546011)(76116006)(6486002)(316002)(186003)(66476007)(6512007)(36756003)(44832011)(2906002)(33656002)(54906003)(8676002)(38100700002)(478600001)(6916009)(66946007)(83380400001)(5660300002)(122000001)(15650500001)(966005)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?SFdLS3VEeUJVZWlHRWlYcE9vT3J2Y1pYdmV4TE10NkZaSzdSQzZGU2ZvVFJt?= =?utf-8?B?Zm8yMVJkb3lKQUZEY3pJeVZaMEJJZlAzemRMVDQ4SE0xM1hiL3o4UGRCOFcw?= =?utf-8?B?bDVKVWswZXlIdG1hc2lHaXRwWWtDeVlvUTg5OFlBWk1mekI4cDhrOTdteEIv?= =?utf-8?B?d1ExQXVnK3kwU1V0VW1xdUZDQmcvUUp0NjlYcld3eVdoVis2TTg3ekJmUmVM?= =?utf-8?B?OG5SYUNwZ2kyRCsxNnhVekVjYjIvbXkxOHcxVGFQNVVmTDlDcG85dzJab3E0?= =?utf-8?B?bVlSVDU0cHY4cFNLaUpmaXZZQUlrWGxhTUh4U3FKd21nTXRtVnoveEFIYjZC?= =?utf-8?B?WTg5dmp1S1Q1WHVqSmtnZkRlbjRnSlZlcHVnbUEyODBEUWdkcURyQ2xBRG9y?= =?utf-8?B?bFV5OTgrTjAxdmFlRTlNNlQxQ1lqeUVMNmYraDdHZUhjRGsvZWlLVTJqQ2Fi?= =?utf-8?B?RlRXQmwvQXAzTmNqVkFXdU9iV1JpVVBFQURtNUZCaS94S0ZYWE4yaXRlSkNT?= =?utf-8?B?NWMrSyt4TUhnRlFiaXhTTkFxK2x0RWhiYnNJNkJzbTFBcXRzQUI5Z0VKc1lK?= =?utf-8?B?TmQxQ1RZNXJnck9jTm4yVVRhMTQyR21vc0pBRHRQZnFIY2N4S3BOZno2SHZv?= =?utf-8?B?RS9ma3d2SmJMbHM1ZCtlYU5LRjl0NG9ROFZUMVgwMmJ4VmpWSTJlVW5ndThq?= =?utf-8?B?QWV0YUtDMm5IVUlzYmpDd093QVV3K0g3RVRDWDlIOHBCODJrTFRDS21RR21r?= =?utf-8?B?bVNjUGthZjYzbWphNW9WMkhnMUlDd0huRFJxWHlneGZsSm1JZFVzdWY0ZTdW?= =?utf-8?B?Yk5WZlk5NDFGT1FHeXhocWh5Sk01bFdEQkVSR1hWbS96NUNadlFVQjREUEhv?= =?utf-8?B?eVNlVi9WaWZKalBOR0s5VUIxMUwvMUhBUldGSEZzTzQzckRFTU1VUE5ORTBq?= =?utf-8?B?bHUxWTBFdE1WL1ZqV1hRVTRhclBobC9zMlcrVTdpU2hUY2dFcmZZZ1JuaGdl?= =?utf-8?B?RlBvdThtTHVIbmJJMEZBbTU1cFdCVUtPcHBHQlNqclRFMGY5ZmkyK3R4QkV1?= =?utf-8?B?a0t6bkhzc0dYallCRnJ1RGc4cGJoeXJpL3BySVcvTXhEb2R2R0ZmU0xQQ3dP?= =?utf-8?B?MDNwaEZjZUpFaFJycEpkY3RsTllYaUQ2bXBzSU5zSXJZSFpxbTI2ZXBEekZa?= =?utf-8?B?NlZ5alFWM2xYYjk4WXJyRlhVVU52ZUhQaUpUWVZ4cXU5MmR1eU1zZm01TmYv?= =?utf-8?B?SitzdjgwUTI3SmVYUUJUZExlVzhJRks2Y1pzQVFzT2xKdkRpNk1CVmc2dzkx?= =?utf-8?B?L04yZkxRV1FkNE5UWkl2ZW8reTJURVh3OUNDTXpPTFN2bFR6cGczWHFPcUdO?= =?utf-8?B?aUFVL3dacmlyQWNaUFBkTm00TGk0WUVzWGNnR21GbzZFZHFxc0s3N3R1WGF2?= =?utf-8?B?YlNhU3VLUmZZZkUvbDdLaU9uUFVDbm5mUk1uTU5kUEhLdnNRc2svK1J0em15?= =?utf-8?B?TGYwVmFyWDFnMFMrRTAzbWdDOVlWMmM3bkVtTGJhQ3paYjNPT05Cd1h0Vkdt?= =?utf-8?B?SkFWb0U3UXFXNnFXeUMxVEtrOFhSbTZIMitVWVZPNVU2aTdnRk5PY3JuVEV1?= =?utf-8?B?dndCSnUyUEJ5aE5qTElITkFtZDc1V1dTM3YxOEhqL3NTbmFvUFNpMlY2UGFq?= =?utf-8?B?dVpoeHIvUmE4VjhsUHRkQnRiSVRqZ3BKUlh4NFVOWDNOWldzV0NScWJ2a005?= =?utf-8?Q?Ah2pJ9iJqdMTJojH3h6DGhKgN5h14TuPwvaZhz/?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <62B20C6F500BDA4AB8AB700ECAE4786B@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: DB6PR0701MB3047.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 82dba3b3-c160-407f-f4c0-08d91a734938 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2021 03:07:50.0776 (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: lw9yzE4VafxO3dCF0k6IbGcD5IPaDA1kF24TOWAXkcQVWObhBGDxMZN7+YhJFQ6PKyxN+O4jTMY3W0SNGZki5p5HL0RHMLinai3GqUQ+vAU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3270 Archived-At: Subject: [core] FW: New Version Notification for draft-mattsson-core-coap-attacks-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: Wed, 19 May 2021 03:07:59 -0000 SGksDQoNCkkgbWFkZSBhbiB1cGRhdGVkIHRvIGRyYWZ0LW1hdHRzc29uLWNvcmUtY29hcC1hY3R1 YXRvcnMsIHJlbmFtZWQgdGhlIGRvY3VtZW50IGFuZCBzdWJtaXR0ZWQgaXQgYXMgZHJhZnQtbWF0 dHNzb24tY29yZS1jb2FwLWF0dGFja3MtMDAuIEV4Y2VwdCBhIGZldyBlZGl0b3JpYWwgdXBkYXRl cywgdGhlIGJpZyBhZGRpdGlvbiBpcyBhIG5ldyBzZWN0aW9uIG9uIGFtcGxpZmljYXRpb24gYXR0 YWNrcy4gSSB0aGluayBkcmFmdC1tYXR0c3Nvbi1jb3JlLWNvYXAtYXR0YWNrcyBzaG91bGQgYmUg cHVibGlzaGVkIGFzIGFuIGluZm9ybWFsIGRvY3VtZW50IHNpbWlsYXIgdG8gZS5nLiBSRkMgNzQ1 Ny4gDQoNCkkgdGhpbmsgQ09SRSBuZWVkcyB0byBkaXNjdXNzIGFuZCB0YWtlIG1vcmUgY29uY3Jl dGUgYWN0aW9uIGFnYWluc3QgYW1wbGlmaWNhdGlvbiBhdHRhY2tzLiBUeXBpY2FsIENvQVAgZGVw bG95bWVudHMgaGF2ZSBxdWl0ZSBoaWdoIGFtcGxpZmljYXRpb24gZmFjdG9ycyAxMC0xMDAsIENv QVAgYW1wbGlmaWNhdGlvbiBhdHRhY2tzIGFyZSBoYXBwZW5pbmcgaW4gdGhlIHdpbGQsIGFuZCB0 aGV5IGFyZSBnZXR0aW5nIHF1aXRlIG11Y2ggbWVkaWEgYXR0ZW50aW9uOiANCg0KaHR0cHM6Ly93 d3cubmV0c2NvdXQuY29tL2Jsb2cvYXNlcnQvY29hcC1hdHRhY2tzLXdpbGQNCg0KaHR0cHM6Ly93 d3cuemRuZXQuY29tL2FydGljbGUvdGhlLWNvYXAtcHJvdG9jb2wtaXMtdGhlLW5leHQtYmlnLXRo aW5nLWZvci1kZG9zLWF0dGFja3MvDQoNCmh0dHBzOi8vd3d3LnpkbmV0LmNvbS9hcnRpY2xlL2Zi aS13YXJucy1vZi1uZXctZGRvcy1hdHRhY2stdmVjdG9ycy1jb2FwLXdzLWRkLWFybXMtYW5kLWpl bmtpbnMvDQoNCmh0dHBzOi8vd3d3LmhlbHBuZXRzZWN1cml0eS5jb20vMjAxOS8wMy8wOC9pb3Qt Y29hcC1kZG9zLXdlYXBvbi8NCg0KaHR0cHM6Ly9ibG9nLm1hemVib2x0LmNvbS91bmRlcnN0YW5k aW5nLXRoZS1jb2FwLWRkb3MtYXR0YWNrLXZlY3Rvcg0KDQpodHRwczovL3d3dy5zZWN1cml0eXdl ZWsuY29tL2F0dGFja2Vycy11c2UtY29hcC1kZG9zLWFtcGxpZmljYXRpb24NCg0KaHR0cHM6Ly9t ZWRpdW0uY29tL25zYzQyL3doYXQtaXMtY29hcC1hbmQtaXMtaXQtdGhlLW5leHQtZGRvcy1mb3It aW90LWRlOGVlOTdlNTdlNg0KDQpodHRwczovL3d3dy5nbG9iYWxkb3RzLmNvbS9yZXNvdXJjZXMv YmxvZy9pb3QtZGV2aWNlcy11c2luZy1jb2FwLWluY3JlYXNpbmdseS11c2VkLWluLWRkb3MtYXR0 YWNrcy8NCg0KQ09SRSBoYXMgY29uc2lkZXJlZCBhbXBsaWZpY2F0aW9uIGF0dGFja3Mgc2luY2Ug dGhlIHN0YXJ0LCBidXQgdGhlIGN1cnJlbnQgcmVjb21tZW5kYXRpb25zIGFyZSBxdWl0ZSBzb2Z0 LiBUaGVyZSBtaWdodCBiZSByZWFzb24gdG8gc3RyZW5ndGhlbiB0aGUgcmVjb21tZW5kYXRpb25z IG9yIGV2ZW4gZW5mb3JjZSBjZXJ0YWluIGJlaGF2aW9yLiBRVUlDIGhhcyBlLmcuIGRlY2lkZWQg b24gYSBtYXhpbXVtIGFtcGxpZmljYXRpb24gZmFjdG9yIG9mIDMuLi4uIE9ic2VydmUgYW5kIG11 bHRpY2FzdCBoYXMgdGhlIHJpc2sgb2Ygc2lnbmlmaWNhbnRseSBpbmNyZWFzaW5nIGFtcGxpZmlj YXRpb24uDQoNCkkgaGF2ZSBhbHJlYWR5IHJlY2VpdmVkIHNvbWUgY29tbWVudHMgZnJvbSBDYXJz dGVuIHdobyBhbHNvIGhlbHBlZCB0cmFuc2Zvcm1pbmcgdGhlIFhNTCB0byBtYXJrZG93bi4gSSB3 aWxsIHN1Ym1pdCAtMDEgdmVyc2lvbiBiZWZvcmUgdGhlIGN1dG9mZi4gQmlnIHRoYW5rcyBDYXJz dGVuISAoSSBuZXZlciB3YW50IHRvIG1hbnVhbGx5IGVkaXQgWE1MIGFnYWluLi4uLikuDQoNCkEg cmVwb3NpdG9yeSBmb3IgdGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9naXRo dWIuY29tL0VyaWNzc29uUmVzZWFyY2gvY29hcC1hY3R1YXRvcnMNCihUaGUgZHJhZnQgZG9lcyBu b3QgY29tcGlsZSBhZnRlciB0aGUgbmFtZSBjaGFuZ2UgYW5kIGZvcm1hdCBjaGFuZ2UsIHdlIHdp bGwgZml4IHRoYXQgaW4gdGhlIGNvbWluZyB3ZWVrcykuDQoNClRoaXMgd2FzIHByZXZpb3VzbHkg ZGlzY3Vzc2VkIGhlcmUNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvY29y ZS9pNmJmOUMwT2JUNUZJcGxrSFBtczlnYUM0N1UvDQoNCkNoZWVycywNCkpvaG4NCg0K77u/LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206ICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmci IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpEYXRlOiBTdW5kYXksIDE2IE1heSAyMDIxIGF0 IDE5OjA0DQpUbzogQ2hyaXN0aWFuIEFtc8O8c3MgPGMuYW1zdWVzc0BlbmVyZ3loYXJ2ZXN0aW5n LmF0PiwgR8O2cmFuIFNlbGFuZGVyIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+LCBKb2hu IE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4sIENocmlzdGlhbiBBbXN1ZXNz IDxjLmFtc3Vlc3NAZW5lcmd5aGFydmVzdGluZy5hdD4sIEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZy YW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tPiwgR8O2cmFuIFNlbGFuZGVyIDxnb3Jhbi5z ZWxhbmRlckBlcmljc3Nvbi5jb20+LCBKb2huIEZvcm5laGVkIDxqb2huLmZvcm5laGVkQGVyaWNz c29uLmNvbT4sIEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPg0KU3Vi amVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tYXR0c3Nvbi1jb3JlLWNv YXAtYXR0YWNrcy0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWF0dHNz b24tY29yZS1jb2FwLWF0dGFja3MtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5ID0/dXRmLTg/cT9Kb2huX1ByZXU9QzM9OUZfTWF0dHNzb24/PSBhbmQgcG9zdGVkIHRv IHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbWF0dHNzb24tY29yZS1jb2Fw LWF0dGFja3MNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlTdW1tYXJpemluZyBLbm93biBBdHRhY2tz IG9uIENvQVANCkRvY3VtZW50IGRhdGU6CTIwMjEtMDUtMTYNCkdyb3VwOgkJSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpQYWdlczoJCTIxDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvYXJjaGl2ZS9pZC9kcmFmdC1tYXR0c3Nvbi1jb3JlLWNvYXAtYXR0YWNrcy0wMC50eHQNClN0 YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYXR0 c3Nvbi1jb3JlLWNvYXAtYXR0YWNrcy8NCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1hdHRzc29uLWNvcmUtY29hcC1hdHRhY2tzDQpI dG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hdHRzc29u LWNvcmUtY29hcC1hdHRhY2tzLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBCZWluZyBhYmxlIHRvIHRy dXN0IGluZm9ybWF0aW9uIGZyb20gc2Vuc29ycyBhbmQgdG8gc2VjdXJlbHkgY29udHJvbA0KICAg YWN0dWF0b3JzIGFyZSBlc3NlbnRpYWwgaW4gYSB3b3JsZCBvZiBjb25uZWN0ZWQgYW5kIG5ldHdv cmtpbmcgdGhpbmdzDQogICBpbnRlcmFjdGluZyB3aXRoIHRoZSBwaHlzaWNhbCB3b3JsZC4gIFRo aXMgZG9jdW1lbnQgc3VtbWFyaXplcyBrbm93bg0KICAgYXR0YWNrcywgYW5kIHNob3cgdGhhdCBq dXN0IHVzaW5nIENvQVAgd2l0aCBhIHNlY3VyaXR5IHByb3RvY29sIGxpa2UNCiAgIERUTFMsIFRM Uywgb3IgT1NDT1JFIGlzIG5vdCBlbm91Z2ggZm9yIHNlY3VyZSBvcGVyYXRpb24uICBUaGUgZ29h bA0KICAgd2l0aCB0aGlzIGRvY3VtZW50IGlzIG1vdGl2YXRpbmcgZ2VuZXJpYyBhbmQgcHJvdG9j b2wtc3BlY2lmaWMNCiAgIHJlY29tbWVuZGF0aW9ucyBvbiB0aGUgdXNhZ2Ugb2YgQ29BUC4gIFNl dmVyYWwgb2YgdGhlIGRpc2N1c3NlZA0KICAgYXR0YWNrcyBjYW4gYmUgbWl0aWdhdGVkIHdpdGgg dGhlIHNvbHV0aW9ucyBpbg0KICAgW0ktRC5pZXRmLWNvcmUtZWNoby1yZXF1ZXN0LXRhZ10uDQoN Cg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCg0KDQo= From nobody Tue May 18 20:19:50 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 00C993A1B29 for ; Tue, 18 May 2021 20:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, 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 O4Ot02owxN1B for ; Tue, 18 May 2021 20:19:44 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2076.outbound.protection.outlook.com [40.107.22.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BADC3A1B78 for ; Tue, 18 May 2021 20:19:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DDwvN/PI79qXSw2TUfWf0ts9Zusdzrfuv1jqopdE2so69dV9115NDsnp1j0wqfQqLbsdN1OYa0a5cfRL9t4T9nsT2QYmetBPxVXnif4+7UEDht4XJUgMMl8hTCpHXd1ML+aQdhIN5e6wtVjjKIXpt+dciFeuL5NBkRV/yVYIga17O3FlKfKL5pH9PTjTLKMQH19ApApf0IVQD1wq0EQ0HBsIFQxe/Sizn6BXv0UFJqe2YuuWiOkFIVFcE90SG7sA7/LBkeKBXWZTLZz4A84TcBGhz6oxkOoSATj63bkez3FA8SSLGZD5C4RmTZ9f6edC1OecmKOqIRPnfVnRxDGJdg== 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=vzGgF5Dx/L010E+t2CWI7PsHp27evvXmFpqAXWL0zP8=; b=n5StQuO7ODLwKskotZrmeFmImN2tSr2QQwdpYJvZkBPoNanpy2XExhxolZJ88e+swayQnVOY6bR76yLJvZ2UD6j0R5iXfi/V1naXKDdNl3a+oE6DwqIYCgM6/rrNAjj6f4nq1nzMKv/H83pLwK27RXG/6ibpOYq4vBZPZH3sNu+/Yf//3laGEPpWqObzAZk2JzL8Hs5ta67ZxIwJseeHWPKEwib+5C3TTn22QEOQcy131/QaKzg4Zk7fsLbqkUYdU2kzcZZoVQWNT6QkBSBXdrSSphHlt9txIBTBnKn0oL/7Xdi7FwYu8hTW92ACe9BosdPDQDGoE/UH+0Y7134wGg== 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=vzGgF5Dx/L010E+t2CWI7PsHp27evvXmFpqAXWL0zP8=; b=SviBwS1vs7XuKsal0sBIcKOYSr6xdhUPz2LNe0L+8Ns6autilwJhBRLQMZt/O+qEsjNZpHxLm2iGio0V4I/4e697tIyctaawWIoKeJs8L3/S+hFSX37tkczUBIT4uzhEm2Q6QPXwf1FDYYgRoal+XD/xeTu3NncdtKumnzjPByM= Received: from DB6PR0701MB3047.eurprd07.prod.outlook.com (2603:10a6:4:74::7) by DB6PR07MB4245.eurprd07.prod.outlook.com (2603:10a6:6:4f::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.13; Wed, 19 May 2021 03:19:41 +0000 Received: from DB6PR0701MB3047.eurprd07.prod.outlook.com ([fe80::f0fb:72b:8eac:53e8]) by DB6PR0701MB3047.eurprd07.prod.outlook.com ([fe80::f0fb:72b:8eac:53e8%4]) with mapi id 15.20.4150.019; Wed, 19 May 2021 03:19:41 +0000 From: John Mattsson To: "core@ietf.org" Thread-Topic: Review of draft-ietf-core-groupcomm-bis-03 Thread-Index: AQHXCwSqc4rdNewjlUGtn83ROTnvRarqxxqA Date: Wed, 19 May 2021 03:19:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6c1645f3-f477-4dac-0517-08d91a74f171 x-ms-traffictypediagnostic: DB6PR07MB4245: 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: 2nNUyJvHXiUMlZuy5USfAofaua5AXUHTL1rt0d5d8A+snmUmsZXmLH8UMQDN7xhq2rBOttuhVdh8gX+nTGMYCjq/EsEq4tHLQURqr4v2u6eoGkb06Wu2JyskFSnPYN1rgvksF6Zai+FCMT7/3c7Thrle4rFlsSOe50G2RbC5tzcAcWQgXFI4+OXpOp2zZTC/wVoOhPQaJnlECtmGcyQVO9BIPDdOiuTOjAGhLyFh8gK2yoSIvM3YUCI0b+uJ/r7Bjjn0EyLifank+Rzj1wI+w++chaTi470hSs/apXng5JWJNXsLTpcRghYN++FcV4n5hwXYtnrb1cHA4zpkUsnr2QOBB2Vq0o+e7fPLZ4V5lHHfOM23dCh96wnB0TLWYTH7XhlsxT17TuaoAuqQHTehn+BVnP4/Hbo+Y97ePjDrZPOmuktI7cYdo5mZUJMOpTEDPDtEYy+X8FuVZTM5VmtmTNQ6nrF5QTokCa3oft6rXLwvikcE/zTF0h3ZkRAmUHjpbj/3d7P8+OwopdjnnsKVRXJD/sNv+oRzcsPmUhrfepj3hB90TkzuFjSFhWHtmMCnxSEpEaJqU/579nFC0j2MAWyUTs1Cp1KtwIFjxkQbqgahEQZC3O5MN90cC/F0wzMeTcSJtbzbUUJJcpeyANXjgk/OjEyQs3okLAfGV6CZw8OF2AGOvk9oTnFxtrVH+ADSjEbHgu5C/voWGkGh6ZOR21vV4LC8ay9T5hvEYlDePcR38QlaB4afOXmQY5b1TCLU3rKCRm2EC9tRHwMiXvc5CZk8vLSXPwyAgEwe0CVpfXrnMBWAwcWqyPw30Kfw8bG0 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0701MB3047.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(376002)(346002)(136003)(39860400002)(8936002)(53546011)(6506007)(66556008)(66476007)(66446008)(64756008)(66946007)(6916009)(44832011)(2616005)(36756003)(38100700002)(966005)(71200400001)(122000001)(76116006)(91956017)(6512007)(33656002)(478600001)(83380400001)(66574015)(26005)(6486002)(86362001)(8676002)(316002)(186003)(2906002)(5660300002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?aVdhVzNsaEI5eTRTazFhOGhHOTk0RmdmOWRmQ1hLMm1mZXF4d2VZSWxLZXBm?= =?utf-8?B?ekRpNVdGSjQ5TTRxRjkwYzRGRXFTZUlEL01sQjJNaHJHZUtsdEE4dVFFbkE0?= =?utf-8?B?VDEzQktoeUd1WjRQdmtNTTlWMUdDdDJuVkVCc1FQZWsrQnVrMEhaM1N2aEo5?= =?utf-8?B?U1JOWnNaRWYrQ2xwNHFReXArZ3h0R0k5bTFTOXlFaG8xVCtmM3ZxeDBOd2hF?= =?utf-8?B?RVEyT0NGV2Zjb00zZTNZNEtPcE04MS9tRU51b0NFN1Q4WUNWa3NwbFV0ZVFh?= =?utf-8?B?SzFmcEI2SXZhL001bFFrS0g4NlMyZzVWSEJpanlTZi9EY1Fya2xEZllNdGhU?= =?utf-8?B?elV5NC9idzBuVUYrc1hMUDQxNDdObmJXMjdSYy85c1lLL25PWlFnVkYyRTNL?= =?utf-8?B?V3A0ekpBYWFjY2RIMU9ObnUwSnJlSDQ2aUFjWUlNcks5aEs1M1pZUzJSSDZm?= =?utf-8?B?ZnkwdXZ1eWVJNFNoSzBXQ3h0SHBCaCtRUnhtbnQrSmR3K3F3M2NkdmZtLzVE?= =?utf-8?B?MC9vWTA5M1hVbXFZVEVkaFE4OUM2WGd4aWNzRU5BM1liVExzeHRWdzJHWkpr?= =?utf-8?B?OFlaQ0RyYmJCSHFaMG8ybnMxc3BLYmw2MmlFS2Uxb1RodmZiaTdaOVV0MERq?= =?utf-8?B?VHpGWjluTC9WZnlFTlMyeUIzUE9mL1htenpWWUJ0cGpBVnR6eVZOZlZ1VmFE?= =?utf-8?B?MThTcndqL05Nd2kxVUxaMm1aSkJuV2tEeWdiMGl3OVhxamR2cFZ5QVFQUlFh?= =?utf-8?B?Nnl6V3dXc3lyRXU3SXhoRDR0M0NESmRDZVdyN0NuYW54MitET2dTaXhPbzhY?= =?utf-8?B?cmVPSlNEc3pVZE95cVFrNWYzWE0weFY0ZjlZWis2WmVEUDJxa1Joamk4NWlZ?= =?utf-8?B?RFB2QWFta2hLQW50cXYvbm9IeHdvbTRtN2UrZDQvMUtNbFNYRUU0R2IraW5v?= =?utf-8?B?UW1GOHoxSzF0NFc0Q1M1YnFJRVhCQTUydStYYTR4TzlwV0ZQUWtjb091YVBK?= =?utf-8?B?dVIzT2xJN1BGSTVrOWdFeUZ1c1ZxNG9ybVY0TUxyL29vRzhyTytCZHhURE13?= =?utf-8?B?QzZ6U0FIOHVEOThHd2dYNVBQcElyZkh3RVNuQk8ybHlSYm90V3NzQjBNbm5S?= =?utf-8?B?U0paQ2ZnQkUwS3oyV1BnTDEwQy9Ca2Y0Z0ZBTnAyT0N1WHFkVWhmWEhwNmRm?= =?utf-8?B?ZGRjblZDcmFWWGNRSUlqN3FCVndabVlEM0Q1aENBc0wvbXpSUlVjODJwVjhS?= =?utf-8?B?ZTIzQzFBcUpQR2hvSzB4ZklvVy9sM0RXbmRDQStsaENlUVV4aEFvdDJibHdS?= =?utf-8?B?WWxsQ3lpa01CdHBNeENEeUR0Y3kxckd3Yk9rcVplWkZJV3lJZDZuSDd5SWZu?= =?utf-8?B?eTQxaS9PT09mZ3lTOWJTNTB0bjk2TDd1N1FyWjl1YTFiejBwb2ZVS2NVSEox?= =?utf-8?B?ZUtUbjJFWnhITVBucDUrcDlLMlhoWUkxa1dBUnFLcWduc2pFZUhHaHBvU0l5?= =?utf-8?B?L21sRk1wNy9kUzNCTEdCR3pqMTFFNnczSnppcUEyS2E2bVIxMWdaTUFyZW1Q?= =?utf-8?B?a1hVZzdpeURtY0cvZTU2ZVM2RWhRWS9Da0g0a1MzRFhBWHBtc3pGVDQxQzl1?= =?utf-8?B?TXlBVmZMVmdxOURBOUtEa1FuYjhYaGk1Y2YxWnVoUXRSUWZiVytZYnlEek14?= =?utf-8?B?K2twT1lmVDlVZGNLMWNIck41d0lCQ0dUUnZnRGEwVzdNWXhlVjY1UTNmQVpk?= =?utf-8?Q?RN7e/bH7hMAW4SvuvqS6bFP5TsdMYY5HFXFld0I?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <716CEE8BFB5E8C4F9A5624F8DE65D44B@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: DB6PR0701MB3047.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6c1645f3-f477-4dac-0517-08d91a74f171 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2021 03:19:41.7261 (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: nVS63yhWNPNweMCe6zrXsZnHbSEvvZK7v4CfRvCmZCym+lMffRAl03LVEG5Z250PGIc3gfFQXviI+62UIb4DZIcjty4xFqK7k1V6zPDsgZY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB4245 Archived-At: Subject: Re: [core] Review of draft-ietf-core-groupcomm-bis-03 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, 19 May 2021 03:19:49 -0000 SGksDQoNCkkganVzdCBzdWJtaXR0ZWQgZHJhZnQtbWF0dHNzb24tY29yZS1jb2FwLWF0dGFja3Mt MDAgd2hpY2ggaGFzIGEgc2VjdGlvbiBvbiBhbXBsaWZpY2F0aW9uIGF0dGFja3Mgd2l0aCBkZXNj cmlwdGlvbnMgb2YgbXVsdGljYXN0IGFuZCBtdWx0aWNhc3Qgb2JzZXJ2ZSBidXQgZG9lcyBub3Qg Z2l2ZSBhbnkgYW5zd2VycyBob3cgdG8gbWl0aWdhdGUgc3VjaCBhbXBsaWZpY2F0aW9uIGF0dGFj a3MuDQoNCkNoZWVycywNCkpvaG4NCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPg0KRGF0ZTogVGh1 cnNkYXksIDI1IEZlYnJ1YXJ5IDIwMjEgYXQgMDA6MjcNClRvOiAiY29yZUBpZXRmLm9yZyIgPGNv cmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29t bS1iaXMtMDMNCg0KUmV2aWV3IG9mIGRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tYmlzLTAzDQoN CkkgdGhpbmsgdGhpcyBsb29rcyB2ZXJ5IHdlbGwtd3JpdHRlbi4gSSByZWFkIHRocm91Z2ggbW9z dCBvZiB0aGUgZG9jdW1lbnQgcXVpY2tseSBhbmQgZm91bmQgdmVyeSBsaXR0bGUgdG8gY29tbWVu dCBhYm91dC4NCg0KLSBJdCBzZWVtcyB1bmNsZWFyIHRvIG1lIGV4YWN0bHkgaG93IHRoaXMgdXBk YXRlcyBSRkMgNzI1Mi4gRG8gZXZlcnl0aGluZyBpbiBSRkMgNzI1MiBzdGlsbCBhcHBseSwgb3Ig YXJlIHNvbWUgbXVsdGljYXN0IHBhcnRzIHJlcGxhY2VkPyBJbiBzdWNoIGNhc2Ugd2hpY2ggcGFy dHM/DQoNCi0gVGhlIGRvY3VtZW50IHNlZW1zIGEgYml0IHRvbyBsb2NrZWQgdG8gIlVEUC9JUCBt dWx0aWNhc3QiIGZvciBteSB0YXN0ZS4gUkZDIDcyNTIgbGVmdCB0aGluZ3MgbXVjaCBtb3JlIG9w ZW4gd2l0aCBzdGF0ZW1lbnRzIGxpa2UgImJ5IGRlZmF1bHQsIGFyZSB0cmFuc3BvcnRlZCBvdmVy IFVEUCIuIENvQVAgaXMgbm93IHBvcHVsYXIgaW4gbWFueSBlbnZpcm9ubWVudCB3aXRob3V0IFVE UC9JUCBhbmQgdGhlIHNhbWUgd2lsbC9pcyB0cnVlIGZvciBHcm91cCBDb0FQLiBJIGRvbid0IHNl ZSBhbnkgcmVhc29uIHdoeSBtb3N0IG9mIHRoZSB0aGluZ3MgaW4gdGhlIGRvY3VtZW50IGNvdWxk IG5vdCBlYXNpbHkgYmUgdXNlZCB3aXRoIGJyb2FkY2FzdCwgZ2VvY2FzdCwgdW5pY2FzdCwgYW5k IG5vbi1JUCBtdWx0aWNhc3QuIE1heWJlIHlvdSBjb3VsZCBzb2Z0ZW4gaXQgZG93biBhIGJpdCBz byBwZW9wbGUgd2FudGluZyB0byB1c2UgR3JvdXAgQ29BUCBvdmVyIEZvbyBjYW4gc3RpbGwgY2xh aW0gdGhleSBhcmUgZG9pbmcgZ3JvdXAgQ29BUCBkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLWJp cy4NCg0KLSBJIHRoaW5rIGdyb3VwIENvQVAgbmVlZHMgcXVpdGUgYSBiaXQgbW9yZSB0ZXh0IG9u IGFwbGlmaWNhdGlvbiBhdHRhY2tzIGFuZCBEb1MuIFRoZXJlIGhhcyBiZWVuIHNldmVyYWwgbmVn YXRpdmUgYXJ0aWNsZXMgcmVnYXJkaW5nIENvQVAgYW5kIEREb1MgaW4gdGhlIGxhc3QgeWVhcnMu IEdyb3VwIENvQVAgd2l0aCBpdCdzIDEgcmVxdWVzdHMgYW5kIE4gcmVzcG9uc2VzIGlzIGEgYW1w bGlmaWNhdGlvbiBpbiBpdHNlbGYuIE11bHRpY2FzdCBPYnNlcnZlIGlzIGV2ZW4gd29yc2UsIDEg cmVxdWVzdHMgYW5kIE5eMiByZXNwb25zZXMuIE11bHRpY2FzdCBjYW4gaG93ZXZlciBub3QgYmUg dXNlZCBvbiB0aGUgcHVibGljIEludGVybmV0IHdoaWNoIGxpbWl0cyBhbnkgYXR0YWNrcy4gVGhl IGN1cnJlbnQgZG9jdW1lbnQgb25seSBtZW50aW9uIGFtcGxpZmljYXRpb24gaW4gc29tZSBzcGVj aWZpYyBjYXNlcy4gSSB0aGluayB0aGUgZHJhZnQgbmVlZHMgdG8gZXhwYW5kIG9uIHRoZSB0ZXh0 IGluIFJGQyA3MjUyOg0KDQogIlRoaXMgc3BlY2lmaWNhdGlvbiBhdHRlbXB0cyB0byByZWR1Y2Ug dGhlDQogICBhbXBsaWZpY2F0aW9uIGVmZmVjdHMgb2YgbXVsdGljYXN0IHJlcXVlc3RzIGJ5IGxp bWl0aW5nIHdoZW4gYQ0KICAgcmVzcG9uc2UgaXMgcmV0dXJuZWQuICBUbyBsaW1pdCB0aGUgcG9z c2liaWxpdHkgb2YgbWFsaWNpb3VzIHVzZSwNCiAgIENvQVAgc2VydmVycyBTSE9VTEQgTk9UIGFj Y2VwdCBtdWx0aWNhc3QgcmVxdWVzdHMgdGhhdCBjYW4gbm90IGJlDQogICBhdXRoZW50aWNhdGVk IGluIHNvbWUgd2F5LCBjcnlwdG9ncmFwaGljYWxseSBvciBieSBzb21lIG11bHRpY2FzdA0KICAg Ym91bmRhcnkgbGltaXRpbmcgdGhlIHBvdGVudGlhbCBzb3VyY2VzLiAgSWYgcG9zc2libGUsIGEg Q29BUCBzZXJ2ZXINCiAgIFNIT1VMRCBsaW1pdCB0aGUgc3VwcG9ydCBmb3IgbXVsdGljYXN0IHJl cXVlc3RzIHRvIHRoZSBzcGVjaWZpYw0KICAgcmVzb3VyY2VzIHdoZXJlIHRoZSBmZWF0dXJlIGlz IHJlcXVpcmVkLiINCg0KQSByZWFkZXIgb2YgZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS1iaXMg bWlnaHQgdGhpbmsgdGhhdCBHcm91cCBPU0NPUkUgYW5kIEVjaG8gaXMgZW5vdWdoIHRvIHN0b3Ag YW1wbGlmaWNhdGlvbiwgd2hpY2ggaXMgbm90IHRoZSBjYXNlLiBFY2hvIG9ubHkgaGVscHMgYSBi aXQgYnkgbGltaXRpbmcgdGhlIHNpemUgb2YgdGhlIHJlc3BvbnNlcyBidXQgbm90IHRoZSBudW1i ZXIgb2YgcmVzcG9uc2VzLiBBbiBhdHRhY2tlciBjYW4gc3Bvb2YgdGhlIHNvdXJjZSBJUCBvZiB0 aGUgcmVxdWVzdCBhbmQgYSBzbWFydCBhdHRhY2tlciB3b3VsZCBzZW5kIGl0IHRvIGEgcmVzb3Vy Y2UgdGhhdCBzdXBwb3J0cyBtdWx0aWNhc3QgcmVxdWVzdHMuIE5vdCBzdXJlIEdyb3VwIE9TQ09S RSBoZWxwcyBtdWNoIGF0IGFsbCBhcyBhbiBhdHRhY2tlciBjYW4gdGFrZSBhbiBleGlzdGluZyBn cm91cCByZXF1ZXN0IGFuZCBjaGFuZ2UgdGhlIHNvdXJjZSBJUC4gDQoNCkNoZWVycywNCkpvaG4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNvcmUgPGNvcmUtYm91bmNlc0Bp ZXRmLm9yZz4gb24gYmVoYWxmIG9mICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc+DQpSZXBseSB0bzogImNvcmVAaWV0Zi5vcmciIDxjb3JlQGlldGYu b3JnPg0KRGF0ZTogTW9uZGF5LCAyMiBGZWJydWFyeSAyMDIxIGF0IDE3OjUxDQpUbzogImktZC1h bm5vdW5jZUBpZXRmLm9yZyIgPGktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCkNjOiAiY29yZUBpZXRm Lm9yZyIgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbY29yZV0gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1jb3JlLWdyb3VwY29tbS1iaXMtMDMudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVz Lg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29uc3RyYWluZWQgUkVTVGZ1bCBF bnZpcm9ubWVudHMgV0cgb2YgdGhlIElFVEYuDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDog R3JvdXAgQ29tbXVuaWNhdGlvbiBmb3IgdGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3Rv Y29sIChDb0FQKQ0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBFc2tvIERpamsNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgQ2hvbmdnYW5nIFdhbmcNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgTWFyY28gVGlsb2NhDQoJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1jb3JlLWdyb3Vw Y29tbS1iaXMtMDMudHh0DQoJUGFnZXMgICAgICAgICAgIDogNTgNCglEYXRlICAgICAgICAgICAg OiAyMDIxLTAyLTIyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhl IHVzZSBvZiB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24NCiAgIFByb3RvY29sIChDb0FQKSBm b3IgZ3JvdXAgY29tbXVuaWNhdGlvbiwgdXNpbmcgVURQL0lQIG11bHRpY2FzdCBhcw0KICAgdGhl IHVuZGVybHlpbmcgZGF0YSB0cmFuc3BvcnQuICBCb3RoIHVuc2VjdXJlZCBhbmQgc2VjdXJlZCBD b0FQIGdyb3VwDQogICBjb21tdW5pY2F0aW9uIGFyZSBzcGVjaWZpZWQuICBTZWN1cml0eSBpcyBh Y2hpZXZlZCBieSB1c2Ugb2YgdGhlDQogICBHcm91cCBPYmplY3QgU2VjdXJpdHkgZm9yIENvbnN0 cmFpbmVkIFJFU1RmdWwgRW52aXJvbm1lbnRzIChHcm91cA0KICAgT1NDT1JFKSBwcm90b2NvbC4g IFRoZSB0YXJnZXQgYXBwbGljYXRpb24gYXJlYSBvZiB0aGlzIHNwZWNpZmljYXRpb24NCiAgIGlz IGFueSBncm91cCBjb21tdW5pY2F0aW9uIHVzZSBjYXNlcyB0aGF0IGludm9sdmUgcmVzb3VyY2Ut DQogICBjb25zdHJhaW5lZCBkZXZpY2VzIG9yIG5ldHdvcmtzLiAgVGhpcyBkb2N1bWVudCByZXBs YWNlcyBSRkM3MzkwLA0KICAgd2hpbGUgaXQgdXBkYXRlcyBSRkM3MjUyIGFuZCBSRkM3NjQxLg0K DQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29t bS1iaXMvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoN Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLWJp cy0wMw0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWNv cmUtZ3JvdXBjb21tLWJpcy0wMw0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBp cyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1jb3JlLWdyb3VwY29tbS1iaXMtMDMNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcg bGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3JlDQoNCg0K From nobody Tue May 18 20:38:36 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 325083A1BBB for ; Tue, 18 May 2021 20:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 cSy-7Absuh9O for ; Tue, 18 May 2021 20:38:19 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2061.outbound.protection.outlook.com [40.107.22.61]) (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 078D43A1B98 for ; Tue, 18 May 2021 20:38:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TFa6Xqlmzrrw+gjw1E7GvqFyphcd18+ZT14HCoOUFq4GJrwDy9cl/Bj9cWsiLiwQgLrOQ14jyKlh5ZEunUovXPjK6AxLuWG7NceP1KzCLQfZLPw1eeY12ZaStut85Ak7hJo6HgxsGNSh4pcdOJCQAZAn8j7k8TMMMreWcMidkhnO+zAU5Vbnm4Nb7gkOHTkusOdJxEcGlMavDIBU6kUWPe80UW371YG3CY4u6dafBRsITQeVzMs2bPAktmmbjcSzRCDUicLdQ2zRRASdHDhkhT385VaUbCwAtoMFGEF+mRGcCB50dZv/R8BRKlmWyN10hMJtY45RZ1YZOw+ZfxsyjA== 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=GqoC3DOVdpYnWQs8d7tp3Tv+wgDC7mhahTN2aoIFI9o=; b=GT5WU+h2iIiM/7vfSZ4EIJCBEe4zubDlRZB5ja0ov9ghgnUu4mKtTBWZATeFvNjQtAe+kRAU9ZAGV0u2E6yY7WTYxJ1NVxmQjW2XGnCuPHyYrQ+a2wyfpH/YiQjA631iohVKntThiMeDLt/264C/aRvNHXa1+aJNCCMiGbRqLC15NkVzLmyp75FGzbjqoYLxmHFQ6z0C5ZjZTyDiOfcTWCyEeXVM5div469GISPGrKmc02FR5itL9MH/rSKNeerCzDlQc2c0+P/lZuTfxJuGTYcbBPfhpVUqYoVTf0uLwIQijbBR5vLa8TIaoyDkEgzlUzNKQWdKbnZk2lAsyUFz9Q== 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=GqoC3DOVdpYnWQs8d7tp3Tv+wgDC7mhahTN2aoIFI9o=; b=Sc3nh/eKcHLdxx2Y0OPwvA+WUtC0dqjfyxz3X+MJdIga74fwuQR8vtDqrc9aBPf8Nwm5F6yVou3vT2h5yLwFBbuzm6fZEMjGX4Hw9o2Ex31VBN1Rjgsy30WrN77kTUOh4RFey63e8rjd1hJcryZiIssjtehvcbqFcvUpKse3F4U= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR0701MB2585.eurprd07.prod.outlook.com (2603:10a6:3:90::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.13; Wed, 19 May 2021 03:38:16 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3%11]) with mapi id 15.20.4173.011; Wed, 19 May 2021 03:38:16 +0000 From: John Mattsson To: "core@ietf.org" Thread-Topic: [core] FW: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8 Thread-Index: AQHXFxduXoz8+3g8k068F5hdSGPXPqqFSp2AgFyI4YCAACSAgIAAHbCAgAWxbACAAu0LgA== Date: Wed, 19 May 2021 03:38:16 +0000 Message-ID: <9178DAF2-277F-4841-8841-C873DB1D20E1@ericsson.com> References: <46B45227-684C-4CDB-A2B6-20BA70E89DF6@vigilsec.com> <2EF50329-22AD-4797-B8F5-89684E4CCC29@ericsson.com> <7253.1620928861@localhost> <13779C5D-7B1C-4D5B-B8B3-402FACAF2A25@ericsson.com> In-Reply-To: <13779C5D-7B1C-4D5B-B8B3-402FACAF2A25@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 264c9f5c-2839-41b7-32ed-08d91a7789d5 x-ms-traffictypediagnostic: HE1PR0701MB2585: 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: xx1g2KF9q6X9q0JePPGg2S5ejRpZYkt0ztey7QuEhqchoqFsJk/eLfP/3L+ibbB5QFNy688sgUikMSLhnECdU/S33tn16ucNfd4zXxyyBSnLlbDb4mKpCELyfXX/HaZ2wDD87k3eh8rbOcpIe9Wzq3U/b7/2+5VJhPPBXAPZJhjw+NdKYE+Ih/vsWxFEj63rHybZFg57awi0s0nhhs5do5/Q4hUVlIvziJUjYcLu8pcVCVvLUhLY6/isynWXGVhaByeu1LOcLOCqut18REHhmTPpNDa30JvlmQwgt/Slr8fZ6v7mhgQbtoR389SjlLhwBTE9HereV5QSLTXmBleKvRir1iF6JIZzE0dKi9pKQjoAzlcnipYZU/qPfYwZy3W0LcGvmOkNK9KgJaZ0eKIWfmFyRVPiPVUdC/K0ZCOo2aluhmprHBjs1st+kx4zIOf3HpkD9BGG36gcMhGwKvDkBQIy8LRJ5ovckNUl7g7YPQlW73UzqqV8j3TXN2nhxCIPH3UU62ehQqmV3Rn4YRU7TQE7qOCgNhL+7ef6V54e6XT4aky4DOMKIqS1NdBszDK3yNnh1/N/UMxSSD3e5NOfT6AbtFv+pNb1ChKIdQjUF4pN/jR+p9cQuBGahR6PI+r6d6lUS2XGUsyFIFsXM5MXPU/iUSjEwUnXuS7jX5wKDpI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(39860400002)(396003)(136003)(366004)(38100700002)(2616005)(122000001)(6916009)(6512007)(33656002)(6486002)(186003)(44832011)(8936002)(8676002)(6506007)(26005)(53546011)(64756008)(66476007)(86362001)(66946007)(66446008)(66556008)(76116006)(478600001)(5660300002)(71200400001)(83380400001)(316002)(2906002)(36756003)(66574015)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?UzY2NmhpMmk4WHEzUG5lV2tZSG8zM0Q2c1NrbklINDJWSENNa3FaYmxTWFZZ?= =?utf-8?B?cm9GTVpodkc3cVROaW5hRkFqZGFjQ2RpUFdoVHMvUWJwa2p0U2h3SEtER0Qw?= =?utf-8?B?bWhZMnlpa3BmS1l0d01xVlVOemtPKzlObWc1S01CRkdVcmVYZGRxV3BBOUcz?= =?utf-8?B?R2NyY3Qvd2RPL0llT2xaODVLRXljemFjS3p0L0wwRVVBb1ZscllSWisrb2Js?= =?utf-8?B?OVBGOExTa05rTGc2MUVDZmIxRGNwN1crTnYwV0xIa0xiTVdieDV3MVZVNHlY?= =?utf-8?B?V2N1TzNRZlJ5WHYyd0s2ZHRBcWZYMTVPL1JaTnBObTlvVDNKbmx0WDJVRUh6?= =?utf-8?B?QzlPWmtGNHZyT0g0OHFzT2JzR3BGZ1lhSnpOdy9FYlo5UElMQUJlOWxoQTN4?= =?utf-8?B?dUZtcGVOR1VvSXFaK2l5L0Exdm8rS0ZqVldVRmhyZDlDNFZ3K0pPY3d6TVRn?= =?utf-8?B?NGZza05pSzJSTUVYQjNzMVAwVkRlL1ROaHpZV2RnTTBkY1htd2lTT1BkVklX?= =?utf-8?B?TzR1WGx3enRpWFdKbUdBeWJhMXBrVDYzTG1FVkNmV1lQRStHR09QeUN0b0pV?= =?utf-8?B?Qk9xUVpOTVNmMnowdHVwM1FXK0pmVnV4STRnV2lvZHIwRnhNUzR5MWp2cjVP?= =?utf-8?B?NGh2cFp6M0JMUHc4WVd1dTl1UjdwYW9Id2hFeDJ3TTl3cVFTeVZKZ2F4VE5p?= =?utf-8?B?ZThyVkd1T1IzS3BqNHJkSVZab3lvNGYvZTZFbXk0UU1kUWp2cmlWWE1nQlN4?= =?utf-8?B?R2JzanBwa3luQWg0LzlXRitMVjQwT2R2bHVVbzUzZVlHOGthRjZOcjh2eVpY?= =?utf-8?B?NkZGMlhPeHd4a3JWUHMrMDdsWnZOcmZxdTBpeGdnb01heFRSUExHYURVbVRV?= =?utf-8?B?N3NsUFc1eGxuSkFDKzJQWWQ5VzBVODMvRTVIeTVUdTNTcVRhemNueHZYSHY0?= =?utf-8?B?TWVEQzJRUVhheU1QYnlnWktybm51dElvUEhzMk44aDZoOHBkei9tMG12bmVj?= =?utf-8?B?RFNsOGp3RGxvR2ZzdktneEwrTVZvYlpwMlZSSlBYWEFKcUdFckl2aFIramtj?= =?utf-8?B?Q2duYTYvZTFWV0pkSk1GRzBHdW5ZaTUrZ1VsSndrTVkxVVdmSnNicytaTmM0?= =?utf-8?B?Wmk3NFhPeXRDSDJiSnk1MzFUeERORzMrUkRLTzJMSWhxYmRKWUVZaEx3VE9p?= =?utf-8?B?SVQ2cEZkUmkwYS9mSzJ5UWZoYThUc1ZzbXVRZGY5K2FQcTY1WXpqcWtiZ0pS?= =?utf-8?B?WlNRcUIwZ0x0c1RLS090RnhUVng1Nmo3bGFRYnJUTlRLTlFTTmFzS0VHeGw4?= =?utf-8?B?dk11MmhEb3JvVFFyMzRKWk4vcTFxamRyYVFwY3A5ZzZNMmZOZFBpR3VPVzhs?= =?utf-8?B?QXlLSWw2RVY2bU1oSVJIRjVnUEdreHNCMlA1UnBwN1ZSTFM2YVdid0dXOVU1?= =?utf-8?B?NnVuaVh6MmNQSngxQjlScllNVzF3NVIzRDkvTGk0Q24wcGJMaTMwWXpPZWxl?= =?utf-8?B?U0dmSk1xc0Rndm4xSzhtaGk3R2VFVXQ3Y2twRUlYdG5tNFVkVkxKVVlsK1Nl?= =?utf-8?B?N01IVTZqR2I4L2JCRGhTRFd6WWkvUGljeGJtM0tIQmNVdFVFVlNPL2c2bldv?= =?utf-8?B?anZlazUycjNaakZhcDZ2YkE3d2VUWVNUbFRWTUVNZTdTclQyQU5vdVJnbVkr?= =?utf-8?B?UDBuTDVmUHlRb3RNVHJmdzNKT1oyb3RiRFpvSzNWcm10TzJGelRqK1h5cDln?= =?utf-8?B?UXBRRStGWWpMV1hBd2NZc1FRVHVycXl1RS9xb2Jpclh1U3BpTUp2M01HdzNJ?= =?utf-8?B?T0FHV3FpN1hCK1BtRlh6UT09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 264c9f5c-2839-41b7-32ed-08d91a7789d5 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2021 03:38:16.3617 (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: EuVEV8+aMWErqdBYz7kekatCUEr/Q49c8ubLBomiMj7vl55N72F8Y9uFCv7fdI32qUZ6ViTOqoc/wtNVtLqacvRGgd/zchsTfSnTr0cVTng= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2585 Archived-At: Subject: Re: [core] FW: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8 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, 19 May 2021 03:38:35 -0000 SGksDQoNCk90aGVyIHNlY3VyaXR5IHByb2JsZW1zIGZvdW5kIGluIHRoZSBwYXN0IHJlbGF0ZWQg dG8gYW4gYXR0YWNrZXIgcmVtb3ZpbmcgdGhlIHNpZ25hdHVyZSB3YXMgcHVyZWx5IHJlbGF0ZWQg dG8gdGhlIHF1ZXN0aW9uYWJsZSBjaG9pY2UgdG8gdXNlIGEgaGF2ZSB0aGUgc2VuZGVyIGNvdW50 ZXJzaWduIGl0J3Mgb3duIEFFQUQgY2lwaGVydGV4dC4gRHVlIHRvIHRoaXMgc29tZSBpbXBvcnRh bnQgZmVhdHVyZXMgd2VyZSByZW1vdmVkIGZyb20gYW4gZWFybGllciB2ZXJzaW9uLg0KDQpBZnRl ciBkaXNjdXNzaW9uIGluIENPU0UgdGhlIGN1cnJlbnRseSBzdWdnZXN0ZWQgdGV4dCBpbiBkcmFm dC1pZXRmLWNvc2UtY291bnRlcnNpZ24gd2lsbCBsaWtlbHkgYmU6DQoNCiJXaGVuIGVpdGhlciBD T1NFX0VuY3J5cHQgYW5kIENPU0VfTWFjIGlzIHVzZWQgYW5kIG1vcmUgdGhhbiB0d28gcGFydGll cyBzaGFyZSB0aGUga2V5LCBkYXRhIG9yaWdpbiBhdXRoZW50aWNhdGlvbiBpcyBub3QgcHJvdmlk ZWQuIEFueSBwYXJ0eSB0aGF0IGtub3dzIHRoZSBtZXNzYWdlLWF1dGhlbnRpY2F0aW9uIGtleSBj YW4gY29tcHV0ZSBhIHZhbGlkIGF1dGhlbnRpY2F0aW9uIHRhZzsgdGhlcmVmb3JlLCB0aGUgY29u dGVudHMgY291bGQgb3JpZ2luYXRlIGZyb20gYW55IG9uZSBvZiB0aGUgcGFydGllcyB0aGF0IHNo YXJlIHRoZSBrZXkuDQoNCkNvdW50ZXJzaWduYXR1cmVzIG9mIENPU0VfRW5jcnlwdCBhbmQgQ09T RV9NYWMgd2l0aCBzaG9ydCBhdXRoZW50aWNhdGlvbiB0YWdzIGRvIG5vdCBwcm92aWRlIHRoZSBz ZWN1cml0eSBwcm9wZXJ0aWVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2FtZSBhbGdvcml0aG0gdXNl ZCBpbiBDT1NFX1NpZ24uIFRvIHByb3ZpZGUgMTI4LWJpdCBzZWN1cml0eSBhZ2FpbnN0IGNvbGxp c2lvbiBhdHRhY2tzLCB0aGUgdGFnIGxlbmd0aCBNVVNUIGJlIGF0IGxlYXN0IDI1Ni1iaXRzLiBB IGNvdW50ZXJzaWduYXR1cmUgb2YgYSBDT1NFX01hYyB3aXRoIEFFUy1NQUMgMjU2LzEyOCBwcm92 aWRlcyBhdCBtb3N0IDY0IGJpdHMgb2YgaW50ZWdyaXR5IHByb3RlY3Rpb24uIFNpbWlsYXJseSwg YSBjb3VudGVyc2lnbmF0dXJlIG9mIGEgQ09TRV9FbmNyeXB0IHdpdGggQUVTLUNDTS0xNi02NC0x MjggcHJvdmlkZXMgYXQgbW9zdCAzMiBiaXRzIGJpdHMgb2YgaW50ZWdyaXR5IHByb3RlY3Rpb24u Ig0KDQpJJ2xsIG1ha2UgYSBQUiB0byBhbGlnbiBkcmFmdC1pZXRmLWNvcmUtb3Njb3JlLWdyb3Vw Y29tbSB3aXRoIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIGluIGRyYWZ0LWlldGYtY29zZS1j b3VudGVyc2lnbiwgc2lnbmlmaWNhbnRseSBsb3dlciB0aGUgb3ZlcmhlYWQsIGFuZCB0cnkgdG8g cmVzdG9yZSB0aGUgaW1wb3J0YW50IGZlYXR1cmVzIHRoYXQgd2VyZSByZW1vdmVkLg0KDQpDaGVl cnMsDQpKb2huDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2huIE1h dHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4NCkRhdGU6IE1vbmRheSwgMTcgTWF5 IDIwMjEgYXQgMDg6NTcNClRvOiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1h bi5jYT4sICJjb3JlQGlldGYub3JnIiA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29y ZV0gRlc6IFtDT1NFXSBkcmFmdC1pZXRmLWNvc2UtY291bnRlcnNpZ24tMDIgLSBTZWNydWl0eSBw cm9ibGVtcyB3aXRoIENPU0VfRW5jcnlwdCBhbmQgQ09TRV9FbmNyeXB0MCB3aXRoIENDTV84DQoN CkhpLA0KDQpJIHRoaW5rIHRoZSBSRkMgODYxMyAnQUVBRCBBbGdvcml0aG0nIHNob3VsZCBiZSBy ZXNlcnZlZCBmb3IgdGhlIGNhc2VzIHdlcmUgdGhlcmUgaXMgbm8gc2lnbmF0dXJlLCBlLmcuIHBh aXItd2lzZSwgdGhlbiB0aGUgZ3JvdXAgcmVxdWVzdCBtb2RlIHdpdGggc2lnbmF0dXJlcyB3b3Vs ZCBoYXZlIHRvIGhhdmUgYWRkaXRpb25hbCBhbGdvcml0aG1zIHRvIGJlIHVzZWQgd2l0aCB0aGUg c2lnbmF0dXJlIGFsZ29yaXRobS4gVGhlIHNpZ25hdHVyZSBjb25zdHJ1Y3Rpb24gbmVlZHMgdG8g YmUgY2hhbmdlZCBzbyB0aGF0IGl0IGlzIHNlY3VyZSB3aXRoIEFFUy1DVFIgYW5kIENoYUNoYTIw IHdoZW4gc3RhbmRhcmRpemVkIGJ5IENPU0UgV0cuDQoNCi0gSXQgd291bGQgYmUgdmVyeSBzdHJh bmdlIHRvIGZvcmNlIHBlb3BsZSB3YW50aW5nIHRvIHVzZSBBRVMtQ0NNLCBBRVMtR0NNLCBvciBD aGFDaGEyMC1Qb2x5MTMwNSBvciBvdGhlciAxNi1iaXQgdGFnIGFsZ29yaXRobXMgaW4gcGFpci13 aXNlIHRvIHVzZSA4MC1ieXRlIHNvdXJjZSBhdXRoZW50aWNhdGlvbiwgd2hlbiBpdCBjYW4gdHJp dmlhbGx5IGJ5IGRvbmUgd2l0aCA2NCBieXRlcy4gV2hpbGUgdGhlIFRMUyBjb25jbHVzaW9ucyBy ZWdhcmRpbmcgQ0NNXzggaXMgbWlzbGVhZGluZywgSSB0aGluayB0aGVyZSB3aWxsIGJlIGEgdHJl bmQgdG93YXJkIDEyOCBiaXQgdGFncy4gTWFueSBkZXBsb3ltZW50cyBmb3IgZ292ZXJubWVudCBh bmQgZmluYW5jaWFsIGluc3RpdHV0aW9ucyBhbHdheXMgdXNlIDEyOCBiaXQgdGFncy4NCg0KLSBT b21lIGFzcGVjdHMgb2YgdGhlICJ2ZXJpZnlpbmcgdGhlIHJlcXVlc3QiIGlzIG5vdCB3ZWxsIHNw ZWNpZmllZCB0b2RheSwgbWF5YmUgYXMgYSBjb25zZXF1ZW5jZSBvZiB0aGUgc3ltbWV0cmljIHRh ZyArIHNpZ2duYXR1cmUgY29uc3RydWN0aW9uLiBUaGUgb3JkZXIgb2YgZGVjcnlwdCwgc2lnbmF0 dXJlIHZlcmlmaWNhdGlvbiwgYW5kIHVwZGF0ZSBvZiB0aGUgcmVwbGF5IHdpbmRvdyBpcyBub3Qg ZGVmaW5lZC4gVGhpcyBuZWVkIHRvIGJlIGV4YWN0bHkgc3BlY2lmaWVkIG9yIHN0YXRlZCB3aGF0 IGNhbiBiZSBkb25lIGluIHBhcmFsbGVsLiBUaGUgY3VycmVudCB0ZXh0IGFib3V0IHJlcGxheSB3 aW5kb3cgdXBkYXRlIGlzIGxpa2VkIHRvIGRlY3J5cHRpb24sIHRoaXMgbmVlZCB0byBiZSBjaGFu Z2VkIGFzIHRoZSByZXBsYXkgd2luZG93IGxpbmtlZCB0byB0aGUgc2VuZGVyIGNhbiBhYnNvbHV0 ZWx5IG5vdCBiZSB1cGRhdGVkIHVubGVzcyB0aGUgc2lnbmF0dXJlIChzb3VyY2UgYXV0aGVudGlj YXRpb24pIHZlcmlmaWVzLg0KDQpDaGVlcnMsDQpKb2huDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT4N CkRhdGU6IFRodXJzZGF5LCAxMyBNYXkgMjAyMSBhdCAyMDowMQ0KVG86IEpvaG4gTWF0dHNzb24g PGpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPiwgImNvcmVAaWV0Zi5vcmciIDxjb3JlQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSBGVzogW0NPU0VdIGRyYWZ0LWlldGYtY29zZS1jb3Vu dGVyc2lnbi0wMiAtIFNlY3J1aXR5IHByb2JsZW1zIHdpdGggQ09TRV9FbmNyeXB0IGFuZCBDT1NF X0VuY3J5cHQwIHdpdGggQ0NNXzgNCg0KDQpKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29uPTQw ZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCiAgICA+IEVhcmxpZXIgdmVyc2lv bnMgb2YgR3JvdXAgT1NDT1JFIGhhZCB0aGVzZSBxdWl0ZSBzaWduaWZpY2FudA0KICAgID4gdnVs bmVyYWJpbGl0aWVzLiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhpcyB3ZWFrbmVzcyBpcyBh ZGRyZXNzZWQgaW4NCiAgICA+IHRoZSBjdXJyZW50IHZlcnNpb24gb2YgR3JvdXAgT1NDT1JFIGJ5 IGFkZGluZyBtb3JlIGluZm9ybWF0aW9uIHRvIHRoZQ0KICAgID4gc2lnbmF0dXJlIGV4dGVybmFs X2FhZC4NCg0KICAgID4gSG93ZXZlciwgSSBzZWUgbm8gcmVhc29uIHRvIGFjdHVhbGx5IHVzZSBj b3VudGVyc2lnbmF0dXJlcyBpbiBHcm91cA0KICAgID4gT1NDT1JFLg0KDQpJIGRvbid0IHVuZGVy c3RhbmQgdGhlIG5lZWQuICBJIGtub3cgdGhhdCB0aGUgY291bnRlcnNpZ25hdHVyZSB1c2UgaW4g R3JvdXANCk9TQ09SRSB3YXMgY29tcGF0aWJsZSB3aXRoIFJGQzgxNTIsIGJ1dCBiZXlvbmQgdGhh dCwgSSBuZXZlciBxdWl0ZSB1bmRlcnN0YW5kDQpob3cgaXQgd2FzIHVzZWQuDQoNCkknZCBsaWtl IHRvIGFzayBpZiB0aGVyZSBhcmUgc29tZSBzbGlkZXMgZnJvbSBBQ0UgdGhhdCBtaWdodCBoZWxw IGlsbHVtaW5hdGUNCnRoaXM/DQoNCiAgICA+IE5vdyB3aGVuIENPU0UgV0cgaXMgc3BlY2lmeWlu ZyAiQUVBRCIgYWxnb3JpdGhtcyB3aXRob3V0IGludGVncml0eQ0KICAgID4gcHJvdGVjdGlvbiBJ IHRoaW5rIENPUkUgc2hvdWxkIHRha2UgdGhlIHRpbWUgdG8gbW9kaWZ5IHRoZSBzaWduYXR1cmUN CiAgICA+IHBhcnRzIG9mIEdyb3VwIE9TQ09SRSBmcm9tDQoNCiAgICA+IEFFQUQoKSB8fCBDb3Vu dGVyc2lnbmF0dXJlKCBBRUFEKCkgKQ0KDQogICAgPiB0bw0KDQogICAgPiBFTkMoKSB8fCBTaWdu YXR1cmUgKCBNQUMoIEVOQygpICkgKQ0KDQpIbW0uIEkgc2VlIHlvdXIgcG9pbnQsIEkgdGhpbmsu DQpJIGRvbid0IGhhdmUgdGhlIHJpZ2h0IHBpZWNlcyBvZiBPU0NPUkUgcGFnZWQgaW4gdG8gdW5k ZXJzdGFuZCB0aGUgaW1wYWN0IHRvDQpleGlzdGluZyBwcm90b2NvbHMsIG9yIGlmIHRoZXkgYXJl IGV2ZW4gZmFyIGVub3VnaCBhbG9uZyB0byBkZWFsLg0KDQpCdXQsIHNvbWV0aW1lcywgYmV0dGVy IGlzIHRoZSBlbmVteSBvZiBnb29kIGVub3VnaC4NCg0KLS0NCk1pY2hhZWwgUmljaGFyZHNvbiA8 bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiAgIC4gbyBPICggSVB2NiBJw7hUIGNvbnN1bHRpbmcgKQ0K ICAgICAgICAgICBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgSW5jLCBPdHRhd2EgYW5kIFdvcmxk d2lkZQ0KDQoNCg== From nobody Wed May 19 14:37: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 640723A200C; Wed, 19 May 2021 14:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net header.b=FNIndS1v; dkim=pass (1024-bit key) header.d=juniper.net header.b=Us+vsvuu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmQsu69GM2n6; Wed, 19 May 2021 14:37:16 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 3BDF73A2003; Wed, 19 May 2021 14:37:16 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14JLP4gb006014; Wed, 19 May 2021 14:37:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=RSKVMfC491LGS57Lamkr5ES7CXLh9up35fWI4Eocl/8=; b=FNIndS1vUNtvxSNHifIG71MSb9AP+4hsAM15A9y7XGReq+SwyhY2Q7bqYmNySQm7PyOT sLePihXFjgrXmdJZA5ExZGb8gY8C+PRfTTvi5qVuHycArdH2eZ0Jh5Fi3bMYwKl8GoS3 MWfQmdudJEacB2WTKThAlUT8IXtf2fJ/F67nhfYdxcFwSNzXbQ8QGP1x0JzGX+JEBgTq Vrn/iFD+qIYx9V7YXcGzyngmrtBa47oXpwtefVG3QRvcpKNKgQuB688bzj7RDzmYlF4S kSi6DGBQCNIngbiW5YtBbmq/hoO6F4UXmaUi6p6SL3QPh0W0nt+5eNE3B2yPr4ZdNd3N AQ== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2176.outbound.protection.outlook.com [104.47.56.176]) by mx0b-00273201.pphosted.com with ESMTP id 38mvxhhjs2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 May 2021 14:37:14 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BlR4chIMs5uBoR2o2aospPMBlRVEzJyztFocq9Zn7jDnJfNNELegK8UeLwIm8D0+iprYh5WUr61nL8+D3RDGwPtOExy3G9awondVY0+b9zqVK/w7xMYd7MJTZ3Cr7AwaeMs0yDbvX9x4Lk0sXmWf/M07KFrhL7OqtPJcw4sngsaqS2GPHKEKIz97kQ+8NBDFKoYwdYLurXkr8Pogq/L8SrOamOki+oeplqj7V8Xio+T314d/pLyk9f7Q8/6zPu+xXI+afnKkVDx0emjVuNop3LVIiaU5+MfvviYKAr4yIM1DRC19JPPF4rPPRBOKzgMRLa+2J1pm9udW59lu/ZZEuQ== 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=RSKVMfC491LGS57Lamkr5ES7CXLh9up35fWI4Eocl/8=; b=eeWoX2u8Ql55IFeKt4S3H/kg2GaNMgDY5+Gvmmesuazeeijtj1z5riz/+ulvt2iJ45gHsHRRBSXnfYdRWkWg6HazKLYdtXe6+D+UbQRL7HHMcBlgwYjxrP3MJRXXIthyNTeUo0cGBcsX6s2VQ7k53OrwFMmWXX+5+AmfXOAesy1ChOA2UYKplemyIt6xCNys+53OhDI8evs27AKJB0FxKjuTDafDkhzYPsyLCMeF6wAK76OLlnn/zT0D/UkpZ03hGChfayQUKzJpW+cmZrwyAWZjKNsUwuS5YGWaUHJBQafmt/w6t/qfyvA90ATdcbL2MNyA9Pgo0HVELZk27IJ1Qw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RSKVMfC491LGS57Lamkr5ES7CXLh9up35fWI4Eocl/8=; b=Us+vsvuu90gcQmaYkKD1QxvKwwBcXsvWPfOBVJ+yNC5fR4rTIFZ/s2mirN2Dtgga5wEGbOVvxr4gpvbQfEeq8gkRI2gqVGv5LwALu8g7G2k+sOM/gvtBMSOFH2UfRgSeAnM+zG2UvzmrpTWRELdroNBu12XLy7ha6RbUFn3OBfA= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6127.namprd05.prod.outlook.com (2603:10b6:208:c4::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.11; Wed, 19 May 2021 21:37:10 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::3020:ac3:590d:83f1]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::3020:ac3:590d:83f1%5]) with mapi id 15.20.4150.017; Wed, 19 May 2021 21:37:10 +0000 From: John Scudder To: "mohamed.boucadair@orange.com" CC: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXQhCbJLPvcFdg/UKru2kURMqcWqrXeDkAgBPx5AA= Date: Wed, 19 May 2021 21:37:10 +0000 Message-ID: <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net> References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@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.6) authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [162.225.191.192] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 52e68760-6f38-41a3-fb5f-08d91b0e4261 x-ms-traffictypediagnostic: MN2PR05MB6127: 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: 3HQC5bBL7UepgKtVaF9OKcqH0/7GMRa91kbzknEecrKXGbByx8M1mvDc2TLQ5bo/ZALCxsNI59fjjmkJ39m615xT+halL2WVippTbPsdzFOnoRTRObrl8t+bRd8KqEAe5VXPce6HF7OINYg7qqY6EboSQ9SP0TrDFfH0pfBgl6yZXIMXY/sQoG2U+swjhOKM2dy5NpeLHwjoQZmqNgN3Ig6ldAgyhmmGyqKWBi0FyNQJsQnH+MlmL+aAAHSv4IBbDLS6uTvQ63aEKP7lLhjXOtCRtCXr4Magk/0U61NW/+CaiNWGnXq0OU7U8yi+e8ES7Sbe3rORz4zxmr1K88OsJTSwkLTfeIzht/92NRmarVZW6Fe+ebT2qKxnA8v18roVmGe8DmMrlmT3mwWyYApU2PHhJCg6aIiGiVuAjkNWjz+9D9VVZfkUkhschXNmsp1LXbs+68Qr+Gr2Olbq5m8WfISlVsGt6nD3Gj0Le2YDzvNTgnNcKpwGk9wUMg61sy82q7hu+6s9Llen4HqmXfynGUSCHL9TuTFNMfWwu6Gxjp7MoE0zXrNqgFYXkq7n31cjX+oYPSvGsS8r+uH5C+uVxtohBA4jrjrF+9wsrfEYAItb88mjbo32VqMs6xM815HB8q//u4uexBpZueygKqIhRRqFKXuW6ni2w/7FpSTokA7qrPO43VlGz/SEaUh9X92u2byS2idwoZtCMLI5frhvoFtObfr2UvtPvjSj/mva96DoKIWiLY6Z1JaRoQZjS0Set1pPuFJhoeA+mIjt3Vg7jQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(396003)(346002)(376002)(366004)(6512007)(478600001)(4326008)(966005)(6486002)(54906003)(316002)(8936002)(6916009)(83380400001)(186003)(8676002)(30864003)(66476007)(86362001)(76116006)(64756008)(2906002)(91956017)(122000001)(38100700002)(66556008)(66946007)(66446008)(71200400001)(26005)(6506007)(5660300002)(2616005)(53546011)(33656002)(36756003)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?azhQV0dVQVNTbjZrOW5OYi9DR09yN09sSDluR0g3UXJOclBEYU9URm5HL3ZP?= =?utf-8?B?MDdKOXhkM05laVJJbXlIUWIyN1o4c1ZKVEljTU9ReHE1M2JsQ2U3dTJ1N2d4?= =?utf-8?B?SWNIVTFBaVpoTFlIRjJmQlptaTk4NVRKK3J5QjZhZHpLMVNzdFJDUEdIK0pD?= =?utf-8?B?U3p4TEpodE10UGUrNG9KL3VkRjFaWkhHbC9QRm02dmQvVVY1WUxBM0s5UW1x?= =?utf-8?B?cEc5NFVMNzEyWDdWQmI5RnRVNVV4OEN6dUJCQnlrQXdIUGFSMnFLQUUwZlRX?= =?utf-8?B?RitreG9MUlRVaExCUFRJYkZkZFhNanVvaFB1bW5FL25OSzBPNFVzckIvOHdO?= =?utf-8?B?ZS9XSC8wa2VOQkRnRXVPb0Z2dFhWVTUvUjRkTTNQQ0ZFMnNMQzAxWTlNZEhM?= =?utf-8?B?M1BUbzVhNDdxcXZ0S1B5cEdEellFbmRHSzIvV0hMNEc0aE5Id1g5by9RVVdN?= =?utf-8?B?b2gxdlNrT0VOUm1adUlOM3lCM1ZZWStJQVZ2dENWc3VFU2lVUlFMY0lvUTdS?= =?utf-8?B?WlBNMGtvcnd0b1Z4aTdxd29kS3RhK0lsdDg3dktIQ1NqOFBXanU1R2R2NEQz?= =?utf-8?B?amRqQ2kxbGc1MDQ0MFI3cnNoaTN5T3ByN0g3Y1J4eTF6MDVycGFNbGkwSjI4?= =?utf-8?B?d0F4QnhLR0wrTFZVYUEzU2NlYmZtNUwrK0lJcTF6ejg0QlgxVmdlU002Tzh1?= =?utf-8?B?VmxTTCtCUnhLQnhyTjFkMlI1NE5yQjYyRFowZVJvZG95bENORUhXU3NVRGx2?= =?utf-8?B?VGx3WGliNytkQWN6bFVNbS9CZHpOekM0UmpvbVNYRlNsNXNlQks3Y0JDNjM5?= =?utf-8?B?dDM0enJpMmwyWGE2a2pYVytVUTlhWDhPUzd6K2FKb0tzMVBTay8ydDBkU0Jn?= =?utf-8?B?bjcrSFRMSURWUmRDM1ZYTjlSdlN5ellGSVZ0a25PVFFVTEIybnJyNzQyWTF2?= =?utf-8?B?VFJ1Q01KaHJ3NG1RSU53cmFKSVRMZnhpWHNDM050UytKSEJKN0haUzlMSG5J?= =?utf-8?B?QmdaODR1TXVncUFHTFk2eWxwcFlBTkFaNmZCbEk4LzYxbTJyc2gvUDZkelFO?= =?utf-8?B?bUI3ODhlNTFHRG5GMWFGMTBKdDZ5NUpQbnRIL0JLRGVxSkhJb0JtTUwySjlQ?= =?utf-8?B?WVVkOEZGOHhvRVEvL2RmNXNsSnBycnJLUEZsdUt5WkptMW1CV3ovdEdXeDVx?= =?utf-8?B?czlIOTdqOFF2Ukd3aFdsUklmRnRVV1lRbk5kVE1HYzRURitORjQxL2lUUi9q?= =?utf-8?B?bE9OUE82L3hTYlN5bGZ4RlROVWM4R1ZQRXcwT2EvVUU4eW0ySENiYjB0elFX?= =?utf-8?B?ZjhkUHRqWHZQOG9JUjkvaWxUejV3TFNQNEQzM3hHTytPeHRJcGU2aXM2N3ZU?= =?utf-8?B?anlBZER1N2RBMkJlL2Q4Y1U5NWJia3Q1TTFxa1N5UmNITzA2RU15bmgxTXFh?= =?utf-8?B?UHVPVXhWMzlVRlRlT1J5VVpTV0w3MXhTbDE2NWpwQ1N6aXp6aU1hTlRTVmYv?= =?utf-8?B?YzdWTklCY3h1NThBUWhzWmpMRnVzY3NSdG95UENJODA5Y3cxckk4UHRlMjl4?= =?utf-8?B?MG9FVUwyR0lsTFlHMXV3SUdIcnJqdWdMS2FZNlZOcTRNaXNRUDc0elpOU3lh?= =?utf-8?B?TmJuWnJWTXpZNi9QSDVXSHVub2hNQ2c5MU5UNkpDem1sSXArMlFIK29TYkZP?= =?utf-8?B?ZzNUdlI1N2ZZSU9VbXUvbmJZRUI3VHlUNTg3VFdHbHh1VjNWZU9sRlc2SFhy?= =?utf-8?B?eHBXN2lRSTJPa05RbGUvNjFsUUlENkYrZ01tVHlKdWRXNTVib29oOXE0c2dK?= =?utf-8?B?TkhmZWZVSEExZ0VXeUtBUT09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52e68760-6f38-41a3-fb5f-08d91b0e4261 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2021 21:37:10.5426 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LfUVGGaCndc0qIU+5yzwzW+LV9Bah8IufNsBrlf8wxQVOA7K85rpByX82Yi3b+AJ X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6127 X-Proofpoint-GUID: YBm37Ju-Kw_g2WSkt_JZYPiQnvURFThC X-Proofpoint-ORIG-GUID: YBm37Ju-Kw_g2WSkt_JZYPiQnvURFThC X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-19_10:2021-05-19, 2021-05-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 mlxscore=0 phishscore=0 adultscore=0 mlxlogscore=999 malwarescore=0 spamscore=0 impostorscore=0 suspectscore=0 lowpriorityscore=0 bulkscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105190131 Archived-At: Subject: Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (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: Wed, 19 May 2021 21:37:32 -0000 SGkgTWVkLCBKb24sDQoNCk15IHJlc3BvbnNlcyBpbi1saW5lLg0KDQo+IE9uIE1heSA3LCAyMDIx LCBhdCAxOjAyIEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPiANCj4g W0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KPiANCj4gDQo+IEhpIEpv aG4sDQo+IA0KPiBUaGFuayB5b3UgZm9yIHRoZSBkZXRhaWxlZCByZXZpZXcuIE11Y2ggYXBwcmVj aWF0ZWQuDQo+IA0KPiBDaGFuZ2VzIGNhbiBiZSB0cmFja2VkIGF0OiBodHRwczovL3VybGRlZmVu c2UuY29tL3YzL19faHR0cHM6Ly90aW55dXJsLmNvbS9uZXctYmxvY2stbGF0ZXN0X187ISFORXQ2 eU1hTy1nayFVUnd1SVVJTHYxLW5pYndPaVI3blhBeFEwZVdiTmZLaUpMQWZmSVk5WFc0ZWVvWWR0 TGlRcVRsT1dUUHZYQSQNCj4gDQo+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiANCj4gQ2hlZXJzLA0K PiBKb24gJiBNZWQNCj4gDQo+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+IERlIDog Sm9obiBTY3VkZGVyIHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+ PiBFbnZvecOpIDogamV1ZGkgNiBtYWkgMjAyMSAwMjo0Mg0KPj4gw4AgOiBUaGUgSUVTRyA8aWVz Z0BpZXRmLm9yZz4NCj4+IENjIDogZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZzsg Y29yZS1jaGFpcnNAaWV0Zi5vcmc7DQo+PiBjb3JlQGlldGYub3JnOyBtYXJjby50aWxvY2FAcmku c2U7IG1hcmNvLnRpbG9jYUByaS5zZQ0KPj4gT2JqZXQgOiBKb2huIFNjdWRkZXIncyBEaXNjdXNz IG9uIGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMTE6ICh3aXRoDQo+PiBESVNDVVNTIGFuZCBD T01NRU5UKQ0KDQpb4oCmXQ0KDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IC0NCj4+IERJU0NVU1M6DQo+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4+IC0NCj4+IA0KPj4gRm9yIHRoZSBtb3N0IHBhcnQgSSBmb3VuZCB0 aGlzIGRvY3VtZW50IHJlbGF0aXZlbHkgZWFzeSB0byBmb2xsb3csDQo+PiBjb25zaWRlcmluZyBt eSBjb21wbGV0ZSBsYWNrIG9mIGJhY2tncm91bmQgaW4gQ29BUC4gSG93ZXZlciwgZGVzcGl0ZQ0K Pj4gYSBjb25jZXJ0ZWQgZWZmb3J0IEkgaGF2ZSBub3QgYmVlbiBhYmxlIHRvIG5haWwgZG93biB3 aXRoIGNvbmZpZGVuY2UNCj4+IHdoYXQgdGhlIGludGVuZGVkIHNlbWFudGljcyBvZiBzZXZlcmFs IG9mIHlvdXIgdGltZW91dHMgYXJlLCBub3RhYmx5DQo+PiBOT05fUkVDRUlWRV9USU1FT1VULiBT b21lIG9mIHRoZSB0ZXh0IChmb3IgZXhhbXBsZSwgwqc0LjQpIGltcGxpZXMNCj4+IHRoYXQgdGhl IHRpbWVvdXQgaXMgYW4gdXBwZXIgYm91bmQgb24gaG93IGxvbmcgYW4gaW1wbGVtZW50YXRpb24N Cj4+IHNob3VsZCB3YWl0IGJlZm9yZSBkZWNsYXJpbmcgYSBibG9jayB0byBoYXZlIGJlZW4gbG9z dCAo4oCcVGhlIGNsaWVudA0KPj4gU0hPVUxEIHdhaXQgZm9yIHVwIHRvIE5PTl9SRUNFSVZFX1RJ TUVPVVTigJ0pLg0KPiANCj4gVGhlIHRleHQgYXJvdW5kIHRoZSB0aW1lb3V0IHZhbHVlcyBoYXZl IGJlZW4gbWFkZSBhYnNvbHV0ZSAoYXMgcGVyIHlvdXIgQ09NTUVOVFMpLCByZW1vdmluZyAidXAg dG8iLCBldGMuLCBhbmQgb25jZSB0aGUgdGltZW91dCBoYXMgZXhwaXJlZCwgdGhlbiB0aGUgbmV4 dCBhY3Rpdml0eSB0YWtlcyBwbGFjZS4gRG9lcyB0aGlzIGhlbHAgY2xhcmlmeSB0aGluZ3M/DQoN ClllcywgdGhvc2UgY2hhbmdlcywgcGx1cyB0aGUgb3RoZXIgcmV3cml0ZXMgdG8gwqc3LjIsIGhl bHAgYSBsb3QuIFRoaXMgRElTQ1VTUyBxdWVzdGlvbiBpcyByZXNvbHZlZCBhcyBmYXIgYXMgSeKA mW0gY29uY2VybmVkLg0KDQpJIHdvdWxkIGNsZWFyIHRoZSBESVNDVVNTLCBidXQgSSBhbSBjb25j ZXJuZWQgYWJvdXQgbXkgY29tbWVudCAjMTEgKHNlZSBiZWxvdykgYW5kIEnigJltIGdvaW5nIHRv IHJhaXNlIHRoYXQgdG8gYSBESVNDVVNTLg0KDQpb4oCmXQ0KDQo+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ IC0NCj4+IENPTU1FTlQ6DQo+PiDigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJQNCg0KW+KApl0NCg0KPj4gMi4gU2VjdGlvbiA0LjENCj4+IA0KPj4gICBRLUJsb2Nr MiBPcHRpb24gaXMgdXNlZnVsIHdpdGggR0VULCBQT1NULCBQVVQsIEZFVENILCBQQVRDSCwgYW5k DQo+PiAgIGlQQVRDSCByZXF1ZXN0cyBhbmQgdGhlaXIgcGF5bG9hZC1iZWFyaW5nIHJlc3BvbnNl cyAoMi4wMSwgMi4wMiwNCj4+ICAgMi4wMywgMi4wNCwgYW5kIDIuMDUpIChTZWN0aW9uIDUuNSBv ZiBbUkZDNzI1Ml0pLg0KPj4gDQo+PiBJIGZvdW5kIHRoZSBsaXN0IG9mIGNvZGVzIGluY29tcHJl aGVuc2libGUgb24gZmlyc3QgZW5jb3VudGVyaW5nIGl0LA0KPj4gc2luY2UgdGhlIGNvbmNlcHQg b2YgcmVzcG9uc2UgY29kZXMgaGFkbuKAmXQgYmVlbiBpbnRyb2R1Y2VkIHlldC4gSSBkbw0KPj4g dW5kZXJzdGFuZCB0aGF0IHRoZSBkb2N1bWVudCBhc3N1bWVzIGZhbWlsaWFyaXR5IHdpdGggQ29B UDsNCj4+IG5vbmV0aGVsZXNzIGZvciBiYXNpYyBjbGFyaXR5IEkgdGhpbmsgdGhpcyBzaG91bGQg c2F5IOKAnChyZXNwb25zZQ0KPj4gY29kZXMgMi4wMSwgMi4wMuKApuKAnS4gQWRkaXRpb25hbGx5 LCB0aGUgcmVmZXJlbmNlIHRvIFJGQyA3MjUyIMKnNS41DQo+PiBkb2VzbuKAmXQgc2VlbSB0byBi ZSBlc3BlY2lhbGx5IGdlcm1hbmU/DQo+IA0KPiBUaGUga2V5IGVsZW1lbnQgaW4gdGhlIHRleHQg eW91IHF1b3RlZCBpcyAicGF5bG9hZC1iZWFyaW5nIHJlc3BvbnNlcyIuIEhlbmNlIHRoZSBwb2lu dGVyIHRvIDUuNSBvZiBSRkM3MjUyLg0KDQpPSy4gSSBzdGlsbCB0aGluayB0aGUgdGV4dCB3b3Vs ZCBiZSBiZXR0ZXIgaWYgeW91IGluc2VydGVkIOKAnHJlc3BvbnNlIGNvZGVz4oCdIHdpdGhpbiB0 aGUgcGFyZW50aGVzZXMsIGFzIGluIOKAnChyZXNwb25zZSBjb2RlcyAyLjAxLCAyLjAxLCDigKbi gJ0gaW5zdGVhZCBvZiB0aGUgY3VycmVudCDigJwoMi4wMSwgMi4wMiwg4oCm4oCdLg0KDQpb4oCm XQ0KDQo+PiA0LiBTZWN0aW9uIDQuMQ0KPj4gDQo+PiAgIFRoZSBRLUJsb2NrMSBhbmQgUS1CbG9j azIgT3B0aW9ucyBhcmUgdW5zYWZlIHRvIGZvcndhcmQuICBUaGF0IGlzLA0KPj4gYQ0KPj4gICBD b0FQIHByb3h5IHRoYXQgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUgUS1CbG9jazEgKG9yIFEtQmxv Y2syKQ0KPj4gT3B0aW9uDQo+PiAgIE1VU1QgcmVqZWN0IHRoZSByZXF1ZXN0IG9yIHJlc3BvbnNl IHRoYXQgdXNlcyBlaXRoZXIgb3B0aW9uLg0KPj4gDQo+PiBQcmVzdW1hYmx5IChob3BlZnVsbHkp IHRoaXMgaXMgc2ltcGx5IGRlc2NyaWJpbmcgdGhlIGJlaGF2aW9yIG9mDQo+PiBleGlzdGluZyBz cGVjLWNvbXBsaWFudCBwcm94aWVzIHdoZW4gcHJvY2Vzc2luZyB0aGUgbmV3IG1lc3NhZ2VzLiBB cw0KPj4gc3VjaCwgaXMgdGhlIE1VU1QgYXBwcm9wcmlhdGU/IEkgd291bGQgdGhpbmsgbm90Lg0K PiANCj4gVGhpcyBpcyBvbmx5IGZvciB0aG9zZSB0aGF0IGFyZSB0YWdnZWQgYXMgdW5zYWZlIHRv IGZvcndhcmQuIFRoZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaXMgT0suDQoNCk15IHBvaW50IGhlcmUg aXMgdGhhdCB0aGUgc2Vjb25kIHNlbnRlbmNlICh0aGUgb25lIHRoYXQgYmVnaW5zIOKAnHRoYXQg aXPigJ0pIGlzIHNpbXBseSBzdGF0aW5nIHRoZSBiZWhhdmlvciB5b3Ugd291bGQgZXhwZWN0IGFu IGV4aXN0aW5nIHByb3h5IHRvIGV4aGliaXQgaWYgaXQgd2VyZSBwcmVzZW50ZWQgd2l0aCB0aGUg 4oCcdW5zYWZlIHRvIGZvcndhcmTigJ0gb3B0aW9ucy4gQ29ycmVjdD8NCg0KSWYgc28sIHRoZW4g SSB0aGluayB0aGUgTVVTVCBpcyBpbmFwcHJvcHJpYXRlLCBzaW5jZSB5b3UgYXJlIG5vdCBzcGVj aWZ5aW5nIG5ldyBiZWhhdmlvciBoZXJlLg0KDQpb4oCmXQ0KDQo+PiAxMS4gR2VuZXJhbA0KPj4g DQo+PiBCeSB0aGUgd2F5LCBub25lIG9mIHRoZSB0aW1lcnMgc3BlY2lmeSBqaXR0ZXIgKGFuZCBp bmRlZWQsIGlmIHJlYWQNCj4+IGxpdGVyYWxseSwgaml0dGVyIHdvdWxkIGJlIGZvcmJpZGRlbiku IElzIHRoaXMgaW50ZW50aW9uYWw/DQo+IA0KPiBObyArLy0gdG9sZXJhbmNlcyBoYXZlIGJlZW4g ZGVmaW5lZC4gV2hlbiBhIHRpbWVyIGV4cGlyZXMsIHRoZW4gdGhlIG5leHQgYWN0aW9uIHRha2Vz IHBsYWNlLg0KDQpJIG5vdGljZSB0aGF0IFJGQyA3MjUyIGppdHRlcnMgaXRzIHRpbWVycywgZm9y IGV4YW1wbGU6DQoNCiAgIGNvdW50ZXIuICBGb3IgYSBuZXcgQ29uZmlybWFibGUgbWVzc2FnZSwg dGhlIGluaXRpYWwgdGltZW91dCBpcyBzZXQNCiAgIHRvIGEgcmFuZG9tIGR1cmF0aW9uIChvZnRl biBub3QgYW4gaW50ZWdyYWwgbnVtYmVyIG9mIHNlY29uZHMpDQogICBiZXR3ZWVuIEFDS19USU1F T1VUIGFuZCAoQUNLX1RJTUVPVVQgKiBBQ0tfUkFORE9NX0ZBQ1RPUikgKHNlZQ0KICAgU2VjdGlv biA0LjgpDQrigKYNCiAgIEFDS19SQU5ET01fRkFDVE9SIE1VU1QgTk9UIGJlIGRlY3JlYXNlZCBi ZWxvdyAxLjAsIGFuZCBpdCBTSE9VTEQgaGF2ZQ0KICAgYSB2YWx1ZSB0aGF0IGlzIHN1ZmZpY2ll bnRseSBkaWZmZXJlbnQgZnJvbSAxLjAgdG8gcHJvdmlkZSBzb21lDQogICBwcm90ZWN0aW9uIGZy b20gc3luY2hyb25pemF0aW9uIGVmZmVjdHMuDQoNCk1BWF9UUkFOU01JVF9TUEFOIGFuZCBNQVhf VFJBTlNNSVRfV0FJVCBhcmUgc2ltaWxhcmx5IGppdHRlcmVkLiBBIG51bWJlciBvZiB5b3VyIGlu dHJvZHVjZWQgcGFyYW1ldGVycyANCg0KICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIG5ldyBw YXJhbWV0ZXJzIE1BWF9QQVlMT0FEUywgTk9OX1RJTUVPVVQsDQogICBOT05fUkVDRUlWRV9USU1F T1VULCBOT05fTUFYX1JFVFJBTlNNSVQsIE5PTl9QUk9CSU5HX1dBSVQsIGFuZA0KICAgTk9OX1BB UlRJQUxfVElNRU9VVCBwcmltYXJpbHkgZm9yIHVzZSB3aXRoIE5PTiAoVGFibGUgMykuDQoNCmFw cGVhciBhdCBsZWFzdCBzdXBlcmZpY2lhbGx5IHNpbWlsYXIgdG8gdGhlIHRpbWVycyB0aGUgYXV0 aG9ycyBvZiBSRkMgNzI1MiBkZWVtZWQgaW1wb3J0YW50IHRvIGppdHRlciB0byBwcmV2ZW50IHN5 bmNocm9uaXphdGlvbiBlZmZlY3RzLiBEaWQgeW91IHNwZWNpZmljYWxseSBjb25zaWRlciBqaXR0 ZXJpbmcgdGhlbSwgYW5kIGRlY2lkZSB0aGF0IGppdHRlciB3YXMgdW5uZWNlc3Nhcnk/IElmIHNv LCBjYW4geW91IGV4cGxhaW4gd2hhdCBpcyBkaWZmZXJlbnQgYWJvdXQgeW91ciBzcGVjaWZpY2F0 aW9uLCBjb21wYXJlZCB0byB0aGUgYmFzZSBzcGVjLCB0aGF0IGVsaW1pbmF0ZXMgdGhlIGNvbmNl cm4/DQoNCj4+IDEyLiBTZWN0aW9uIDcuMg0KPj4gDQo+PiAgIElmIHRoZSBDb0FQIHBlZXIgcmVw b3J0cyBhdCBsZWFzdCBvbmUgcGF5bG9hZCBoYXMgbm90IGFycml2ZWQgZm9yDQo+PiAgIGVhY2gg Ym9keSBmb3IgYXQgbGVhc3QgYSAyNCBob3VyIHBlcmlvZCBhbmQgaXQgaXMga25vd24gdGhhdCB0 aGVyZQ0KPj4gICBhcmUgbm8gb3RoZXIgbmV0d29yayBpc3N1ZXMgb3ZlciB0aGF0IHBlcmlvZCwg dGhlbiB0aGUgdmFsdWUgb2YNCj4+ICAgTUFYX1BBWUxPQURTIGNhbiBiZSByZWR1Y2VkIGJ5IDEg YXQgYSB0aW1lICh0byBhIG1pbmltdW0gb2YgMSkgYW5kDQo+PiAgIHRoZSBzaXR1YXRpb24gcmUt ZXZhbHVhdGVkIGZvciBhbm90aGVyIDI0IGhvdXIgcGVyaW9kIHVudGlsIHRoZXJlDQo+PiBpcw0K Pj4gICBubyByZXBvcnQgb2YgbWlzc2luZyBwYXlsb2FkcyB1bmRlciBub3JtYWwgb3BlcmF0aW5n IGNvbmRpdGlvbnMuDQo+PiBUaGUNCj4+ICAgbmV3bHkgZGVyaXZlZCB2YWx1ZSBmb3IgTUFYX1BB WUxPQURTIHNob3VsZCBiZSB1c2VkIGZvciBib3RoIGVuZHMNCj4+IG9mDQo+PiAgIHRoaXMgcGFy dGljdWxhciBDb0FQIHBlZXIgbGluay4gIE5vdGUgdGhhdCB0aGUgQ29BUCBwZWVyIHdpbGwgbm90 DQo+PiAgIGtub3cgYWJvdXQgdGhlIE1BWF9QQVlMT0FEUyBjaGFuZ2UgdW50aWwgaXQgaXMgcmVj b25maWd1cmVkLiAgQXMgYQ0KPj4gICBjb25zZXF1ZW5jZSBvZiB0aGUgdHdvIHBlZXJzIGhhdmlu ZyBkaWZmZXJlbnQgTUFYX1BBWUxPQURTIHZhbHVlcywNCj4+IGENCj4+ICAgcGVlciBtYXkgY29u dGludWUgaW5kaWNhdGUgdGhhdCB0aGVyZSBhcmUgc29tZSBtaXNzaW5nIHBheWxvYWRzIGFzDQo+ PiAgIGFsbCBvZiBpdHMgTUFYX1BBWUxPQURTIHNldCBtYXkgbm90IGhhdmUgYXJyaXZlZC4gIEhv dyB0aGUgdHdvDQo+PiBwZWVyDQo+PiAgIHZhbHVlcyBmb3IgTUFYX1BBWUxPQURTIGFyZSBzeW5j aHJvbml6ZWQgaXMgb3V0IG9mIHRoZSBzY29wZS4NCj4+IA0KPj4gSSB0YWtlIGl0IHRoaXMgaXMg anVzdCB0aHJvd24gaW4gaGVyZSBhcyBhbiBvcGVyYXRpb25hbCBzdWdnZXN0aW9uPw0KPj4gSXTi gJlzIG5vdCBzcGVjaWZ5aW5nIHByb3RvY29sLCByaWdodD8gSXQgc2VlbXMgYSBsaXR0bGUgbWlz cGxhY2VkLCBpZg0KPj4gc28uDQo+IA0KPiBUaGlzIGlzIGEgZ3VpZGFuY2UgdG8gYWRqdXN0IHRo ZSBtYXhfcGF5bG9hZHMgdG8gYXZvaWQgbG9zc2VzIHVuZGVyIG5vcm1hbCBjb25kaXRpb25zLg0K DQpPSywgYnV0IHlvdSBoYXZlbuKAmXQgc2FpZCB3aGV0aGVyIHRoaXMgaXMgb3BlcmF0aW9uYWwg Z3VpZGFuY2UgKGkuZS4sIHlvdSBleHBlY3QgdGhpcyB0byBiZSBkb25lIGJ5IGh1bWFucyBhZGp1 c3RpbmcgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzKSBvciBpZiBpdOKAmXMgcG90ZW50aWFsbHkg dG8gYmUgZG9uZSBhdXRvbWF0aWNhbGx5IHRoZSBpbXBsZW1lbnRhdGlvbi4gR2l2ZW4gdGhhdCAi SG93IHRoZSB0d28gcGVlciB2YWx1ZXMgZm9yIE1BWF9QQVlMT0FEUyBhcmUgc3luY2hyb25pemVk IGlzIG91dCBvZiB0aGUgc2NvcGXigJ0gSSB3b3VsZCB0aGluayBpdOKAmXMgc3RyaWN0bHkgb3Bl cmF0aW9uYWwgZ3VpZGFuY2UuIElmIHRoYXTigJlzIGNvcnJlY3QgYW5kIGl04oCZcyBvcGVyYXRp b25hbCBndWlkYW5jZSBleGNsdXNpdmVseSwgSSB0aGluayBpdCBzaG91bGQgbm90IGJlIHBhcnQg b2Ygwqc3LjIuIFNlY3Rpb24gNy4yIHNwZWNpZmllcyBwcm90b2NvbDsgbWl4aW5nIGluIG9wZXJh dGlvbmFsIGFkdmljZSBwb3RlbnRpYWxseSBjb25mdXNlcyB0aGUgcmVhZGVyLiBZb3UgY291bGQg YWRkIGFuIOKAnE9wZXJhdGlvbmFsIEFkdmljZSBmb3IgVHVuaW5nIFBhcmFtZXRlcnPigJ0gbWFq b3Igc2VjdGlvbiwgb3IgZXZlbiBhIHN1YnNlY3Rpb24gYmVsb3cgNy4yLCBhbmQgdGhlIGNvbmNl cm4gd291bGQgYmUgcmVzb2x2ZWQuDQoNCkJ5IHRoZSB3YXksIG5pdDoNCg0KICAgbm90IGhhdmUg YXJyaXZlZC4gIEhvdyB0aGUgdHdvIHBlZXIgdmFsdWVzIGZvciBNQVhfUEFZTE9BRFMgYXJlCQ0K ICAgc3luY2hyb25pemVkIGlzIG91dCBvZiB0aGUgc2NvcGUuDQoNCuKAnE91dCBvZiB0aGUgc2Nv cGXigJ0gLT4g4oCcb3V0IG9mIHNjb3Bl4oCdIG9yIOKAnG91dCBvZiB0aGUgc2NvcGUgb2YgdGhp cyBkb2N1bWVudCINCg0KPj4gMTMuIFNlY3Rpb24gMTAuMS4zDQo+PiANCj4+IChUaGlzIGNvbW1l bnQgcmVsYXRlcyB0byB0aGUgYXNpZGUgaW4gbXkgRElTQ1VTUy4gWW91IG1heSB3YW50IHRvDQo+ PiBza2lwIG92ZXIgaXQgdW50aWwgd2XigJl2ZSByZXNvbHZlZCB0aGUgRElTQ1VTUywgYWZ0ZXIg d2hpY2ggdGhpcyBtYXksDQo+PiBvciBtYXkgbm90LCBiZQ0KPj4gcmVsZXZhbnQuKQ0KPj4gDQo+ PiBXaHkgZG9lc27igJl0IHRoZSBzZXJ2ZXIgcmVxdWVzdCAxLDksMTAgaW4gb25lIGdvPyBTaW5j ZSBpdHMgcnhtdA0KPj4gcmVxdWVzdCBpcyB0cmlnZ2VyZWQgYnkgcnggb2YgMTEsIG9uZSB3b3Vs ZCB0aGluayBpdCBjb3VsZCBpbmZlciAxMA0KPj4gaGFkIGJlZW4gbG9zdC4NCj4gDQo+IEJlY2F1 c2Ugb25seSB0aGUgbWlzc2luZyBibG9ja3Mgb2YgdGhlIHByZXZpb3VzIHNldCBhcmUgaW5jbHVk ZWQgYW5kIHRoZXJlIG1heSBoYXZlIGJlZW4gc29tZSBwYWNrZXQgYXJyaXZhbCByZS1vcmRlcmlu ZyBmb3IgMTAgYW5kIDExLg0KDQpJIHNlZS4gSSBndWVzcyBJIHdhcyB0aGlua2luZyBvZiB0aGlz IGluIHRlcm1zIG9mIGEgc2xpZGluZy13aW5kb3cgcHJvdG9jb2wsIGJ1dCB5b3VyIHByb3RvY29s IGlzIHJlYWxseSBzdGlsbCBhbG1vc3Qgc3RvcC1hbmQtd2FpdCwgYnV0IHdpdGggbXVjaCBsYXJn ZXIgYmxvY2tzLiBZb3VyIHJld3JpdGUgaGVscGVkIGEgbG90IHdpdGggdGhpcywgdGhhbmtzLg0K DQpb4oCmXQ0KDQo+PiAxNS4gU2VjdGlvbiAxMC4yLjMNCj4+IA0KPj4gKFRoaXMgY29tbWVudCBy ZWxhdGVzIHRvIG15IERJU0NVU1MuIFlvdSBtYXkgd2FudCB0byBza2lwIG92ZXIgaXQNCj4+IHVu dGlsIHdl4oCZdmUgcmVzb2x2ZWQgdGhlIERJU0NVU1MsIGFmdGVyIHdoaWNoIHRoaXMgbWF5LCBv ciBtYXkgbm90LA0KPj4gYmUgcmVsZXZhbnQuKQ0KPj4gDQo+PiBXaHkgZG9lc27igJl0IHJlY2Vw dGlvbiBvZiBRQjI6MTAvMC8xMDI0IHRyaWdnZXIgdGhlIGNsaWVudCB0byByZXF1ZXN0DQo+PiBy ZXRyYW5zbWlzc2lvbj8gV2h5IGRvZXMgaXQgaGF2ZSB0byB3YWl0IGZvciB0aW1lb3V0Pw0KPiAN Cj4gVGhpcyBpcyBmaXhlZCBhcyBwZXIgYSBzaW1pbGFyIGNvbW1lbnQgZnJvbSBCZW46DQo+IA0K PiBPTEQ6DQo+ICAgICAgIFtbTk9OX1RJTUVPVVQgKHNlcnZlcikgZGVsYXkgZXhwaXJlc11dDQo+ ICAgICAgICAgIHwgICAgIFtbU2VydmVyIHNlbmRzIG5leHQgc2V0IG9mIHBheWxvYWRzXV0NCj4g ICAgICAgICAgfDwtLS0tLS0tLS0rIE5PTiAyLjA1IE06MHhhYiBUOjB4ZjAgTzoxMjM2IEVUPTIz IFFCMjoxMC8wLzEwMjQNCj4gICAgICAgICAgfCAgIC4uLiAgICB8DQo+ICAgICAgIFtbTk9OX1JF Q0VJVkVfVElNRU9VVCAoY2xpZW50KSBkZWxheSBleHBpcmVzXV0NCj4gICAgICAgICAgfCAgICAg W1tDbGllbnQgcmVhbGl6ZXMgYmxvY2tzIGFyZSBtaXNzaW5nIGFuZCBhc2tzIGZvciB0aGUNCj4g ICAgICAgICAgfCAgICAgICBtaXNzaW5nIG9uZXMgaW4gb25lIGdvXV0NCj4gICAgICAgICAgKy0t LS0tLS0tLT58IE5PTiBHRVQgL3BhdGggTToweDA0IFQ6MHhmMyBRQjI6MS8wLzEwMjRcDQo+ICAg ICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUUIyOjkvMC8x MDI0DQo+ICAgICAgICAgIHwgICAgIFg8LS0tKyBOT04gMi4wNSBNOjB4YWMgVDoweGYzIEVUPTIz IFFCMjoxLzEvMTAyNA0KPiANCj4gTkVXOg0KPiAgICAgICBbW05PTl9USU1FT1VUIChzZXJ2ZXIp IGRlbGF5IGV4cGlyZXNdXQ0KPiAgICAgICAgICB8ICAgICBbW1NlcnZlciBzZW5kcyBuZXh0IHNl dCBvZiBwYXlsb2Fkc11dDQo+ICAgICAgICAgIHw8LS0tLS0tLS0tKyBOT04gMi4wNSBNOjB4YWIg VDoweGYwIE86MTIzNiBFVD0yMyBRQjI6MTAvMC8xMDI0DQo+ICAgICAgICAgIHwgICAgIFtbT24g c2VlaW5nIGEgcGF5bG9hZCBmcm9tIHRoZSBuZXh0IHNldCBvZiBwYXlsb2FkcywNCj4gICAgICAg ICAgfCAgICAgIENsaWVudCByZWFsaXplcyBibG9ja3MgYXJlIG1pc3NpbmcgYW5kIGFza3MgZm9y IHRoZQ0KPiAgICAgICAgICB8ICAgICAgIG1pc3Npbmcgb25lcyBpbiBvbmUgZ29dXQ0KPiAgICAg ICAgICArLS0tLS0tLS0tPnwgTk9OIEdFVCAvcGF0aCBNOjB4MDQgVDoweGYzIFFCMjoxLzAvMTAy NFwNCj4gICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBR QjI6OS8wLzEwMjQNCj4gICAgICAgICAgfCAgICAgWDwtLS0rIE5PTiAyLjA1IE06MHhhYyBUOjB4 ZjMgRVQ9MjMgUUIyOjEvMS8xMDI0DQoNCg0KSSBwcmVzdW1lIHlvdeKAmXJlIG5vdCBjb25jZXJu ZWQgYWJvdXQgcmUtb3JkZXJpbmcgYmV0d2VlbiBwYXlsb2FkIDkgYW5kIDEwIGJlY2F1c2UgTk9O X1RJTUVPVVQgaXMgYWx3YXlzIGd1YXJhbnRlZWQgdG8gYmUgaW5zZXJ0ZWQgYmV0d2VlbiBmbGln aHRzIG9mIHBheWxvYWRzICh1bmxlc3MgdGhlIG90aGVyIHNpZGUgaGFzIHNlbnQgYSAyLjMxIENv bnRpbnVlLCB3aGljaCBtZWFucyBub3RoaW5nIHdhcyBsb3N0KSwgdGhlcmVmb3JlIHRoZXJl4oCZ cyBhIGRlbGF5IGluc2VydGVkIG9uIHRoZSBzZXJ2ZXIgc2lkZSBiZXR3ZWVuIDkgYW5kIDEwLg0K DQpPbmUgY29uY2VybiByZWxhdGVkIHRvIHRoYXQ6IHdhaXRpbmcgTk9OX1RJTUVPVVQgaXNu4oCZ dCBhY3R1YWxseSByZXF1aXJlZCwgaXTigJlzIG9ubHkgUkVDT01NRU5ERUQsIHRoZXJlZm9yZSB0 aGlzIGlzbuKAmXQgYWN0dWFsbHkgYSBndWFyYW50ZWUuIEZyb20gwqc3LjI6DQoNCiAgIEFzIHRo ZSBzZW5kaW5nIG9mIG1hbnkgcGF5bG9hZHMgb2YgYSBzaW5nbGUgYm9keSBtYXkgaXRzZWxmIGNh dXNlDQogICBjb25nZXN0aW9uLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGFmdGVyIHRyYW5zbWlz c2lvbiBvZiBldmVyeQ0KICAgTUFYX1BBWUxPQURTX1NFVCBvZiBhIHNpbmdsZSBib2R5LCBhIGRl bGF5IGlzIGludHJvZHVjZWQgb2YNCiAgIE5PTl9USU1FT1VUIGJlZm9yZSBzZW5kaW5nIHRoZSBu ZXh0IE1BWF9QQVlMT0FEU19TRVQgdG8gbWFuYWdlDQogICBwb3RlbnRpYWwgY29uZ2VzdGlvbiBp c3N1ZXMuDQoNCkkgYW0gY3VyaW91cyB3aHkgeW91IG1hZGUgdGhpcyBhIFJFQ09NTUVOREVEIGlu c3RlYWQgb2YgYSBNVVNULiBJbiBhIHNpdHVhdGlvbiBsaWtlIHRoaXMgaXQgd291bGQgYmUgcHJl ZmVyYWJsZSBmb3IgeW91IHRvIGV4cGxhaW4gdG8gdGhlIGltcGxlbWVudG9yIHdoYXQgc2l0dWF0 aW9uIHRoZXkgY2FuIGlnbm9yZSB0aGUgUkVDT01NRU5ERUQgaW4gYW5kIHdoYXQgdGhleSBzaG91 bGQgZG8gaW5zdGVhZCwgb3Igb2YgY291cnNlIHRvIG1ha2UgaXQgaW50byBhIE1VU1QuDQoNCk5v dyB0aGF0IEnigJltIGxvb2tpbmcgYXQgUkVDT01NRU5ERUQgYW5kIFNIT1VMRCBhZ2FpbiwgSSBu b3RpY2UgdGhhdCB0aGUgc3BlY2lmaWNhdGlvbiBmb3IgdXNlIG9mIDIuMzEgaW4gwqc0LjMgaGFz IGEgc2ltaWxhciBwb3RlbnRpYWwgaXNzdWU6DQoNCiAgICAgIEEgcmVzcG9uc2UgdXNpbmcgdGhp cyBSZXNwb25zZSBDb2RlIFNIT1VMRCBOT1QgYmUgZ2VuZXJhdGVkIGZvcg0KICAgICAgZXZlcnkg cmVjZWl2ZWQgUS1CbG9jazEgT3B0aW9uIHJlcXVlc3QgKFNlY3Rpb24gNy4yKS4gIEl0IFNIT1VM RA0KICAgICAgb25seSBiZSBnZW5lcmF0ZWQgd2hlbiBhbGwgdGhlIHBheWxvYWQgcmVxdWVzdHMg YXJlIE5vbi0NCiAgICAgIGNvbmZpcm1hYmxlIGFuZCBhIE1BWF9QQVlMT0FEU19TRVQgaGFzIGJl ZW4gcmVjZWl2ZWQgYnkgdGhlDQogICAgICBzZXJ2ZXIuICBNb3JlIGRldGFpbHMgYWJvdXQgdGhl IG1vdGl2YXRpb25zIGZvciB0aGlzIG9wdGltaXphdGlvbg0KICAgICAgYXJlIGRpc2N1c3NlZCBp biBTZWN0aW9uIDcuMi4NCg0KSSBjYW4gaW1hZ2luZSB3aGVuIGFuIGltcGxlbWVudGF0aW9uIG1p Z2h0IGlnbm9yZSB0aGUgZmlyc3QgU0hPVUxEIE5PVDogZm9yIGV4YW1wbGUgaWYgaXTigJlzIGEg dmVyeSBzbWFsbCBpbXBsZW1lbnRhdGlvbiB0aGF0IGRvZXNu4oCZdCB3YW50IHRvIGtlZXAgZXh0 cmEgc3RhdGUuIEJ1dCBob3cgYWJvdXQgdGhlIFNIT1VMRD8gVW5kZXIgd2hhdCBjaXJjdW1zdGFu Y2VzIGlzIGl0IE9LIGZvciBhbiBpbXBsZW1lbnRhdGlvbiB0byB1c2UgUmVzcG9uc2UgQ29kZSAy LjMxIHdoZW4gbm90IGFsbCB0aGUgcGF5bG9hZHMgaW4gYSBzZXQgaGF2ZSBiZWVuIHJlY2VpdmVk PyBJZiB0aGVyZSBhcmUgbm8gc3VjaCBjaXJjdW1zdGFuY2VzLCB0aGlzIG91Z2h0IHRvIGJlIGEg TVVTVCAob3IgdHVybiBpdCBhcm91bmQgYW5kIHNheSDigJxNVVNUIE5PVCBiZSBnZW5lcmF0ZWQg dW5sZXNz4oCm4oCdKS4NCg0KQSBzaW1pbGFyIGNvbmNlcm4gZXhpc3RzIGZvciB0aGUgc3BlY2lm aWNhdGlvbiBvZiByZXNwb25zZSA0LjA4Lg0KDQpJIHF1aWNrbHkgc2tpbW1lZCB0aGUgcmVzdCBv ZiB0aGUgZG9jdW1lbnQgZm9yIFNIT1VMRC9SRUNPTU1FTkRFRCBhbmQgZGlkbuKAmXQgZmluZCBv dGhlcnMgdGhhdCBzZWVtZWQgZXF1YWxseSBwcm9ibGVtYXRpYzsgaG93ZXZlciBJ4oCZbSBvZiB0 aGUgc2Nob29sIG9mIHRob3VnaHQgdGhhdCBzYXlzIHlvdSBzaG91bGQgYXNrIHlvdXJzZWxmIGFi b3V0IGV2ZXJ5IFNIT1VMRCwg4oCcd2h5IGlzbuKAmXQgdGhpcyBhIE1VU1Q/4oCdIGFuZCBpZiB5 b3UgZG9u4oCZdCBoYXZlIGEgZ29vZCBhbnN3ZXIsIGNoYW5nZSBpdC4NCg0KW+KApl0NCg0KPj4g MTYuIFNlY3Rpb24gMTAuMi40DQo+PiANCj4+IFNpbmNlIE1BWF9QQVlMT0FEUyBpcyAxMCwgd2h5 IGRvZXMgdGhlIGV4YW1wbGUgc2F5IOKAnE1BWF9QQVlMT0FEUyBoYXMNCj4+IGJlZW4gcmVhY2hl ZOKAnSBhZnRlciBwYXlsb2FkcyAyLTkgaGF2ZSBiZWVuIHJldHJhbnNtaXR0ZWQ/IFRoYXTigJlz IG9ubHkNCj4+IDggcGF5bG9hZHMuDQo+PiANCj4gDQo+IE1BWF9QQVlMT0FEUyBpcyBub3QgYSBz bGlkaW5nIHdpbmRvdy4gSXQgaXMgYSBzcGVjaWZpYyBzZXQgb2YgYmxvY2tzLCBibG9ja3MgIzAg LSAjOSAocGF5bG9hZHMgMSB0byAxMCkgaW4gdGhpcyBjYXNlLCB0aGVuIGJsb2NrcyAjMTAgLSAj MTkgYW5kIHNvIG9uLg0KDQpNb3JlIG9yIGxlc3MgYSBtZXRhLWJsb2NrLCBhcyBJIG1lbnRpb24g aW4gbXkgY29tbWVudCBvbiAjMTMsIGFib3ZlLiBPSy4NCg0KSSBoYXZlIHNvbWUgbmV3IHF1ZXN0 aW9ucyBhbmQgY29tbWVudHMgcmVsYXRlZCB0byB5b3VyIG5ldyByZXZpc2lvbjoNCg0KMTcuIFNl Y3Rpb24gMToNCg0KICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIHRoZSBDb0FQIFEtQmxvY2sx IGFuZCBRLUJsb2NrMiBPcHRpb25zIHdoaWNoDQogICBhbGxvdyBibG9jay13aXNlIHRyYW5zZmVy IHRvIHdvcmsgd2l0aCBzZXJpZXMgb2YgTm9uLWNvbmZpcm1hYmxlDQogICBtZXNzYWdlcywgaW5z dGVhZCBvZiBsb2NrLXN0ZXBwaW5nIHVzaW5nIENvbmZpcm1hYmxlIG1lc3NhZ2VzDQogICAoU2Vj dGlvbiAzKS4gIEluIG90aGVyIHdvcmRzLCB0aGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgbWlzc2lu ZyBwaWVjZQ0KICAgb2YgW1JGQzc5NTldLCBuYW1lbHkgdGhlIHN1cHBvcnQgb2YgYmxvY2std2lz ZSB0cmFuc2ZlciB1c2luZyBOb24tDQogICBjb25maXJtYWJsZSB3aGVyZSBhbiBlbnRpcmUgYm9k eSBvZiBkYXRhIGNhbiBiZSB0cmFuc21pdHRlZCB3aXRob3V0DQogICB0aGUgcmVxdWlyZW1lbnQg Zm9yIGFuIGFja25vd2xlZGdlbWVudCAoYnV0IHJlY292ZXJ5IGlzIGF2YWlsYWJsZQ0KICAgc2hv dWxkIGl0IGJlIG5lZWRlZCkuDQoNCkFzIGZhciBhcyBJIGNhbiB0ZWxsIHRoZSBzcGVjIGRvZXMg bm90IHJlYWxseSByZW1vdmUgdGhlIHJlcXVpcmVtZW50IGZvciBhY2tub3dsZWRnZW1lbnQsIGl0 IGp1c3QgYW1vcnRpemVzIHRoZSBhY2tub3dsZWRnZW1lbnRzIGJ5IG9ubHkgc2VuZGluZyB0aGVt IGV2ZXJ5IE1BWF9QQVlMT0FEU19TRVQuIFJlc3BvbnNlIENvZGUgMi4zMSBpcyBlc3NlbnRpYWxs eSBhbiBhY2tub3dsZWRnZW1lbnQsIGFuZCBpdCBnZXRzIHNlbnQgdGhhdCBmcmVxdWVudGx5LCBy aWdodD8gVGhlcmXigJlzIGFsc28gKGlmIEkgcmVjYWxsIGNvcnJlY3RseSkgc29tZSBmbGF2b3Ig b2YgYWNrbm93bGVkZ2VtZW50IHRoYXQgaXMgc2VudCB3aGVuIHRoZSBlbnRpcmUgYm9keSBoYXMg YmVlbiB0cmFuc2ZlcnJlZC4gU28sIEkgdGhpbmsgdGhlIG5ldyBwYXJhZ3JhcGggaXNu4oCZdCBh Y2N1cmF0ZS4NCg0KVGhpcyBvYnNlcnZhdGlvbiBhbHNvIGFwcGxpZXMgdG8gdGhpcyBjbGFpbWVk IGJlbmVmaXQgaW4gwqczOg0KDQogICBvICBUaGV5IHN1cHBvcnQgc2VuZGluZyBhbiBlbnRpcmUg Ym9keSB1c2luZyBOT04gbWVzc2FnZXMgd2l0aG91dA0KICAgICAgcmVxdWlyaW5nIGFuIGludGVy bWVkaWF0ZSByZXNwb25zZSBmcm9tIHRoZSBwZWVyLg0KDQpSZXNwb25zZSBDb2RlIDIuMzEgaXMg ZXhhY3RseSBhbiBpbnRlcm1lZGlhdGUgcmVzcG9uc2UuIEkgZ3Vlc3MgbWF5YmUgeW91ciBmb2N1 cyBpcyB0aGF0IGlmIHRoZSBpbnRlcm1lZGlhdGUgcmVzcG9uc2UgaXNu4oCZdCByZWNlaXZlZCwg dHJhbnNtaXNzaW9uIGNvbnRpbnVlcywgYWxiZWl0IG1vcmUgc2xvd2x5IHRoYW4gaXQgd291bGQg b3RoZXJ3aXNlLCBhbmQgdW5yZWxpYWJseSB0b28sIHNvIGluIHRoYXQgc2Vuc2UgdGhlIHJlc3Bv bnNlcyBhcmVu4oCZdCDigJxyZXF1aXJlZOKAnS4gSSB0aGluayB0aGlzIHJlcXVpcmVzIGF3ZnVs bHkgY2xvc2UgcGFyc2luZyBvZiB0aGUgd29yZCDigJxyZXF1aXJlZOKAnSwgdGhvdWdoLg0KDQox OC4gU2VjdGlvbiAyOg0KDQogICBNQVhfUEFZTE9BRFNfU0VUIGlzIHRoZSBzZXQgb2YgYmxvY2tz IGlkZW50aWZpZWQgYnkgYmxvY2sgbnVtYmVycw0KICAgdGhhdCwgd2hlbiBkaXZpZGVkIGJ5IE1B WF9QQVlMT0FEUywgdGhleSBoYXZlIHRoZSBzYW1lIG51bWVyaWMNCg0KUmVtb3ZlIOKAnHRoZXni gJ0gDQoNCiAgIHJlc3VsdC4gIEZvciBleGFtcGxlLCBpZiBNQVhfUEFZTE9BRFMgaXMgc2V0IHRv ICcxMCcsIGENCiAgIE1BWF9QQVlMT0FEU19TRVQgY291bGQgYmUgYmxvY2tzICMwIHRvICM5LCAj MTAgdG8gIzE5LCBldGMuDQogICBEZXBlbmRpbmcgb24gdGhlIGRhdGEgc2l6ZSwgdGhlIE1BWF9Q QVlMT0FEU19TRVQgbWF5IG5vdCBjb21wcmlzZSBhbGwNCiAgIHRoZSBNQVhfUEFZTE9BRFMgYmxv Y2tzLg0KDQpJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgbGFzdCBzZW50ZW5jZSAoIkRlcGVuZGlu ZyBvbiB0aGUgZGF0YSBzaXplLCB0aGUgTUFYX1BBWUxPQURTX1NFVCBtYXkgbm90IGNvbXByaXNl IGFsbCB0aGUgTUFYX1BBWUxPQURTIGJsb2Nrcy7igJ0pIEFyZSB5b3UgdHJ5aW5nIHRvIHNheSB0 aGF0IGlmIHRoZSBib2R5IHNpemUgaXNu4oCZdCBldmVubHkgZGl2aXNpYmxlIGJ5IE1BWF9QQVlM T0FEUyB0aGVuIHRoZSBmaW5hbCBNQVhfUEFZTE9BRFNfU0VUIHdpbGwgaGF2ZSBmZXdlciB0aGFu IE1BWF9QQVlMT0FEUyBibG9ja3MgaW4gaXQ/DQoNCihJIGRvIHRoaW5rIHRoaXMgY2hhbmdlLCB0 byBpbnRyb2R1Y2UgdGhlIHRlcm0gTUFYX1BBWUxPQURTX1NFVCwgaXMgZ2VuZXJhbGx5IGhlbHBm dWw7IHRoYW5rcy4pDQoNClRoYW5rcywNCg0K4oCUSm9obg== From nobody Wed May 19 14:45:11 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 709A63A2036; Wed, 19 May 2021 14:45:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: John Scudder via Datatracker To: "The IESG" Cc: draft-ietf-core-new-block@ietf.org, core-chairs@ietf.org, core@ietf.org, marco.tiloca@ri.se, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.29.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: John Scudder Message-ID: <162146070942.4611.10782831630327617932@ietfa.amsl.com> Date: Wed, 19 May 2021 14:45:09 -0700 Archived-At: Subject: [core] John Scudder's Discuss on draft-ietf-core-new-block-12: (with DISCUSS and 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, 19 May 2021 21:45:10 -0000 John Scudder has entered the following ballot position for draft-ietf-core-new-block-12: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I am raising my comment #11 to a DISCUSS. I notice that RFC 7252 jitters its timers, for example: counter. For a new Confirmable message, the initial timeout is set to a random duration (often not an integral number of seconds) between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR) (see Section 4.8) … ACK_RANDOM_FACTOR MUST NOT be decreased below 1.0, and it SHOULD have a value that is sufficiently different from 1.0 to provide some protection from synchronization effects. MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT are similarly jittered. A number of your introduced parameters This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT, NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3). appear at least superficially similar to the timers the authors of RFC 7252 deemed important to jitter to prevent synchronization effects. Did you specifically consider jittering them, and decide that jitter was unnecessary? If so, can you explain what is different about your specification, compared to the base spec, that eliminates the concern? -- Version 12 resolves the concerns in the DISCUSS point below; I am retaining it for posterity only: For the most part I found this document relatively easy to follow, considering my complete lack of background in CoAP. However, despite a concerted effort I have not been able to nail down with confidence what the intended semantics of several of your timeouts are, notably NON_RECEIVE_TIMEOUT. Some of the text (for example, §4.4) implies that the timeout is an upper bound on how long an implementation should wait before declaring a block to have been lost (“The client SHOULD wait for up to NON_RECEIVE_TIMEOUT”). At the very least, this is imprecise because the timeout increases exponentially with repeated timeouts — but this is a relatively minor matter, discussed further in my comments. Later, in §7.2, you say that expiry of the timeout is not the only trigger for a 4.08 response: It is likely that the client will start transmitting the next set of MAX_PAYLOADS payloads before the server times out on waiting for the last of the previous MAX_PAYLOADS payloads. On receipt of the first payload from the new set of MAX_PAYLOADS payloads, the server SHOULD send a 4.08 (Request Entity Incomplete) Response Code indicating any missing payloads from any previous MAX_PAYLOADS payloads. It makes sense to me that you use this additional trigger. At this point in my reading of the spec, my understanding of the retransmission algorithm was that a 4.08 should be sent when either a payload is received from a new set of MAX_PAYLOADS, or NON_RECEIVE_TIMEOUT expires. But then I got to the example in 10.2.3, which shows the client waiting for the expiration of NON_RECEIVE_TIMEOUT even though it has received the first of a new set of MAX_PAYLOADS, and I concluded that either I’ve missed something basic, or the document is internally inconsistent. As an aside, I’m also unclear as to why the only trigger you specify for sending a 4.08 is the arrival of the first of a new MAX_PAYLOADS flight. Other possible triggers I noticed include a gap in the sequence, and reception of a payload with More=0. Some of these issues are repeated in my comments, below — I’ve noted those in the comment. Possibly in addressing this DISCUSS we’ll clear up some of those comments too. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My initial comments have been resolved or partially resolved in version 12, see https://mailarchive.ietf.org/arch/msg/core/6geK8P9I0jZBPp9a5qSrQwQNhUo/. Note I've added two new ones at the end of the list. (draft-ietf-core-new-block-11) 1. Section 3.2 This mechanism is not intended for general CoAP usage, and any use outside the intended use case should be carefully weighed against the loss of interoperability with generic CoAP applications. I’m curious: is the only reason the mechanism isn’t intended for general usage, the fact some implementations won’t support it? Or does it have other deficiencies that also make it unsuitable? 2. Section 4.1 Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and iPATCH requests and their payload-bearing responses (2.01, 2.02, 2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]). I found the list of codes incomprehensible on first encountering it, since the concept of response codes hadn’t been introduced yet. I do understand that the document assumes familiarity with CoAP; nonetheless for basic clarity I think this should say “(response codes 2.01, 2.02…”. Additionally, the reference to RFC 7252 §5.5 doesn’t seem to be especially germane? By the way, is 2.03 indeed a payload-bearing response? The only other place the spec touches on it is in §4.4, which says “the server could respond with a 2.03 (Valid) response with no payload”. 3. Section 4.1 To indicate support for Q-Block2 responses, the CoAP client MUST include the Q-Block2 Option in a GET or similar request (FETCH, for example), the Q-Block2 Option in a PUT or similar request, or the Q-Block1 Option in a PUT or similar request so that the server knows that the client supports this Q-Block functionality should it need to send back a body that spans multiple payloads. Otherwise, the server would use the Block2 Option (if supported) to send back a message body that is too large to fit into a single IP packet [RFC7959]. Is this paragraph really supposed to mention both Q-Block2 and Q-Block1? In particular, I’m confused by the mention of both of these in relation to PUT. 4. Section 4.1 The Q-Block1 and Q-Block2 Options are unsafe to forward. That is, a CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option MUST reject the request or response that uses either option. Presumably (hopefully) this is simply describing the behavior of existing spec-compliant proxies when processing the new messages. As such, is the MUST appropriate? I would think not. 5. Section 4.3 body. Note that the last received payload may not be the one with the highest block number. “Might not” would be less ambiguous than “may not”. 6. Section 4.4 (also two places in §4.3) (This comment rehashes, in more detail, the difficulty explained in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.) The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2) I read this as meaning the client should wait for as little as zero, or as long as NON_RECEIVE_TIMEOUT — that’s my understanding of “up to”. Is that the intended meaning? If it is, I think it’s worth writing out as I’ve done, for clarity. If it’s not, it definitely needs to be fixed. There’s a similar issue with “up to NON_PARTIAL_TIMEOUT” later in the section. Referring ahead to Section 7.2 muddies the waters further. Even though the text quoted above says NON_RECEIVE_TIMEOUT is an upper limit on how long to wait, §7.2 says it’s a lower limit instead... maybe? From §7.2: NON_RECEIVE_TIMEOUT is the initial maximum time to wait for a missing “Maximum”, ok great, that means “upper bound” and so lines up with §4.4 although the “initial” is surprising since §4.4 doesn’t say anything about the upper limit increasing. It continues: payload before requesting retransmission for the first time. Every time the missing payload is re-requested, the time to wait value doubles. The time to wait is calculated as: Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1)) But this part says it’s (a) an exact time-to-wait, not a “maximum”, and (b) it says it increases exponentially, so NON_RECEIVE_TIMEOUT isn’t a maximum at all, but a minimum. This later text in §7.2 implies that perhaps the problem in the above passages is the word “maximum”, and it should simply be deleted: For the server receiving NON Q-Block1 requests, it SHOULD send back a 2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS payloads to prevent the client unnecessarily delaying. If not all of the MAX_PAYLOADS payloads were received, the server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request count for a payload) before sending the 4.08 (Request Entity Incomplete) Response Code for the missing payload(s). Similarly “up to” in the quote that began this comment should be “at least”. Whether you adopt those suggestions or not, it seems as though all this needs to be rewritten with careful attention to conveying what the desired behavior is. But the plot thickens. Later in §7.2 we have It is likely that the client will start transmitting the next set of MAX_PAYLOADS payloads before the server times out on waiting for the last of the previous MAX_PAYLOADS payloads. On receipt of the first payload from the new set of MAX_PAYLOADS payloads, the server SHOULD send a 4.08 (Request Entity Incomplete) Response Code indicating any missing payloads from any previous MAX_PAYLOADS payloads. The point being that the retransmission request can be triggered by an event other than timer expiration. So in that sense, “maximum” is right — it provides an upper bound on how long to wait before requesting a retransmission — but in another sense it’s wrong because the exponential increase is applied to it. I think the word “maximum” is trying to do too much work, and more words are probably required in order to make this clear. I also think the problem is exacerbated by the fact both §4.4 and §7.2 are talking normatively about how to use NON_RECEIVE_TIMEOUT. It seems as though the main description is found in §7.2, and some confusion would be avoided by making §4.4 less specific, and simply referring forward to §7.2. And, as noted in my DISCUSS, example 10.2.3 muddies the waters still further since it illustrates yet another behavior. 7. Section 4.4 The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2) after the last received payload for NON payloads before issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or more Q-Block2 Options that define the missing blocks with the M bit unset. The client MAY set the M bit to request this and later blocks from this MAX_PAYLOADS set. Further considerations related to the transmission timing for missing requests are discussed in Section 7.2. I find this whole paragraph pretty confusing with the dueling SHOULD and MAY, where it appears the SHOULD might be doing two jobs at once. I *think* your intent is something like the following? “The client SHOULD wait as specified in Section 7.2 for NON payloads before requesting retransmission of any missing blocks. Retransmission is requested by issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or more Q-Block2 Options that define the missing block(s). Generally the M bit on the Q-Block option(s) SHOULD be unset, although the M bit MAY be set to request this and later blocks from this MAX_PAYLOADS set, see Section 10.2.4 for an example of this in operation.” 8. Section 5 If the size of the 4.08 (Request Entity Incomplete) response packet is larger than that defined by Section 4.6 [RFC7252], then the number of missing blocks MUST be limited so that the response can fit into a single packet. If this is the case, then the server can send Suggestion: “then the number of missing blocks reported MUST...” (The thing being limited is not the actual number of missing blocks. You’re limiting the number you report on.) 9. Section 7.1 It is implementation specific as to whether there should be any further requests for missing data as there will have been significant transmission failure as individual payloads will have failed after MAX_TRANSMIT_SPAN. This paragraph seems as though it’s a non-sequitur. It just doesn’t make sense to me. :-( 10. Section 7.2 (This comment relates to the difficulty explained in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.) NON_TIMEOUT is the maximum period of delay between sending sets of MAX_PAYLOADS payloads for the same body. By default, NON_TIMEOUT has the same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]). Presumably the use of “maximum” means it’s fine to delay zero seconds (or any value lower than NON_TIMEOUT). 11. General By the way, none of the timers specify jitter (and indeed, if read literally, jitter would be forbidden). Is this intentional? 12. Section 7.2 If the CoAP peer reports at least one payload has not arrived for each body for at least a 24 hour period and it is known that there are no other network issues over that period, then the value of MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and the situation re-evaluated for another 24 hour period until there is no 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 it is reconfigured. As a consequence of the two peers having different MAX_PAYLOADS values, a peer may continue indicate that there are some missing payloads as all of its MAX_PAYLOADS set may not have arrived. How the two peer values for MAX_PAYLOADS are synchronized is out of the scope. I take it this is just thrown in here as an operational suggestion? It’s not specifying protocol, right? It seems a little misplaced, if so. 13. Section 10.1.3 (This comment relates to the aside in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.) Why doesn’t the server request 1,9,10 in one go? Since its rxmt request is triggered by rx of 11, one would think it could infer 10 had been lost. 14. Section 10.1.4 (also 10.3.3) (This comment relates to the aside in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.) Why doesn’t reception of a message with More=0 trigger the server to request retransmission of the missing block? Why does it have to wait for timeout? 15. Section 10.2.3 (This comment relates to my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.) Why doesn’t reception of QB2:10/0/1024 trigger the client to request retransmission? Why does it have to wait for timeout? Similarly reception of QB2:9/1/1024 later in the example. 16. Section 10.2.4 Since MAX_PAYLOADS is 10, why does the example say “MAX_PAYLOADS has been reached” after payloads 2-9 have been retransmitted? That’s only 8 payloads. -- I do have a couple new comments raised during my review of the changes in version 12: (draft-ietf-core-new-block-12) 17. Section 1: This document introduces the CoAP Q-Block1 and Q-Block2 Options which allow block-wise transfer to work with series of Non-confirmable messages, instead of lock-stepping using Confirmable messages (Section 3). In other words, this document provides a missing piece of [RFC7959], namely the support of block-wise transfer using Non- confirmable where an entire body of data can be transmitted without the requirement for an acknowledgement (but recovery is available should it be needed). As far as I can tell the spec does not really remove the requirement for acknowledgement, it just amortizes the acknowledgements by only sending them every MAX_PAYLOADS_SET. Response Code 2.31 is essentially an acknowledgement, and it gets sent that frequently, right? There’s also (if I recall correctly) some flavor of acknowledgement that is sent when the entire body has been transferred. So, I think the new paragraph isn’t accurate. This observation also applies to this claimed benefit in §3: o They support sending an entire body using NON messages without requiring an intermediate response from the peer. Response Code 2.31 is exactly an intermediate response. I guess maybe your focus is that if the intermediate response isn’t received, transmission continues, albeit more slowly than it would otherwise, and unreliably too, so in that sense the responses aren’t “required”. I think this requires awfully close parsing of the word “required”, though. 18. Section 2: MAX_PAYLOADS_SET is the set of blocks identified by block numbers that, when divided by MAX_PAYLOADS, they have the same numeric Remove “they” result. For example, if MAX_PAYLOADS is set to '10', a MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc. Depending on the data size, the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS blocks. I don’t understand the last sentence ("Depending on the data size, the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS blocks.”) Are you trying to say that if the body size isn’t evenly divisible by MAX_PAYLOADS then the final MAX_PAYLOADS_SET will have fewer than MAX_PAYLOADS blocks in it? (I do think this change, to introduce the term MAX_PAYLOADS_SET, is generally helpful; thanks.) From nobody Thu May 20 06:17:47 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 B10353A16B3; Thu, 20 May 2021 06:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_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_H2=-0.001, 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 bX3LBtzTufcE; Thu, 20 May 2021 06:17:36 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 87C9F3A16B0; Thu, 20 May 2021 06:17:35 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 4Fm9JX24k7z24Sv; Thu, 20 May 2021 15:17:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1621516652; bh=RquqwuQldJjeVLjta1FEF5pUNNiCAUQggEbtZEhd3DM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=TKoc3k0XmIhTL7/aWix194YJuwnGtxcBJnVDJ0JyFAyjs6IbhD42s81nc/r5fB9KE 0VUAnOK/C2/5d5YS0BUsM59y4q250AFjo2q3uWCCefz8QMoeF0PWTUlrZK8NI4Qq+N jLBbjf8FssSAb8hVnGkew7RXIZQKALV3ySJZzlEzH8CQHUm7qaYayolou2jSwJW+q8 vVSEU+PJRUJ3b49WZc39WxZwYnMHdutNMwavLBtTHq2mzOYz1/v2X/CQFnLBjPj6BL 4LEK5ASMBiHfKRusumy1CSARaFPXhLNdz79rB3b3MrFNtt5oP6wvTY5R5mVMqSkShP Z4DxxJ/+2V1uQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 4Fm9JX0c46zFpWV; Thu, 20 May 2021 15:17:32 +0200 (CEST) From: To: John Scudder CC: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXQhCbJLPvcFdg/UKru2kURMqcWqrXeDkAgBPx5ACAAQGlMA== Date: Thu, 20 May 2021 13:17:31 +0000 Message-ID: <23771_1621516652_60A6616C_23771_79_1_787AE7BB302AE849A7480A190F8B93303538BB63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net> In-Reply-To: <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net> 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] John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2021 13:17:41 -0000 SGkgSm9obiwgDQoNClBsZWFzZSBzZWUgaW5saW5lLiANCg0KQ2hlZXJzLA0KSm9uICYgTWVkDQoN Cj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEpvaG4gU2N1ZGRlciBbbWFp bHRvOmpnc0BqdW5pcGVyLm5ldF0NCj4gRW52b3nDqcKgOiBtZXJjcmVkaSAxOSBtYWkgMjAyMSAy MzozNw0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIDxtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPg0KPiBDY8KgOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGRyYWZ0LWll dGYtY29yZS1uZXctYmxvY2tAaWV0Zi5vcmc7DQo+IGNvcmUtY2hhaXJzQGlldGYub3JnOyBjb3Jl QGlldGYub3JnOyBtYXJjby50aWxvY2FAcmkuc2UNCj4gT2JqZXTCoDogUmU6IEpvaG4gU2N1ZGRl cidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay0xMToNCj4gKHdpdGggRElT Q1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IEhpIE1lZCwgSm9uLA0KPiANCj4gTXkgcmVzcG9uc2Vz IGluLWxpbmUuDQo+IA0KWy4uLl0NCj4gPg0KPiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCj4gPj4gRGUgOiBKb2huIFNjdWRkZXIgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBs eUBpZXRmLm9yZ10gRW52b3nDqQ0KPiA6DQo+ID4+IGpldWRpIDYgbWFpIDIwMjEgMDI6NDIgw4Ag OiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4gQ2MgOg0KPiA+PiBkcmFmdC1pZXRmLWNvcmUtbmV3 LWJsb2NrQGlldGYub3JnOyBjb3JlLWNoYWlyc0BpZXRmLm9yZzsNCj4gPj4gY29yZUBpZXRmLm9y ZzsgbWFyY28udGlsb2NhQHJpLnNlOyBtYXJjby50aWxvY2FAcmkuc2UgT2JqZXQgOiBKb2huDQo+ ID4+IFNjdWRkZXIncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMTE6ICh3 aXRoIERJU0NVU1MNCj4gYW5kDQo+ID4+IENPTU1FTlQpDQo+IA0KPiBb4oCmXQ0KPiANCj4gPj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IC0tLQ0KPiA+PiAtDQo+ID4+IERJU0NVU1M6DQo+ID4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiAtLS0NCj4gPj4gLQ0KPiA+Pg0KPiA+PiBGb3IgdGhlIG1vc3QgcGFydCBJIGZvdW5kIHRoaXMg ZG9jdW1lbnQgcmVsYXRpdmVseSBlYXN5IHRvIGZvbGxvdywNCj4gPj4gY29uc2lkZXJpbmcgbXkg Y29tcGxldGUgbGFjayBvZiBiYWNrZ3JvdW5kIGluIENvQVAuIEhvd2V2ZXIsDQo+IGRlc3BpdGUN Cj4gPj4gYSBjb25jZXJ0ZWQgZWZmb3J0IEkgaGF2ZSBub3QgYmVlbiBhYmxlIHRvIG5haWwgZG93 biB3aXRoDQo+IGNvbmZpZGVuY2UNCj4gPj4gd2hhdCB0aGUgaW50ZW5kZWQgc2VtYW50aWNzIG9m IHNldmVyYWwgb2YgeW91ciB0aW1lb3V0cyBhcmUsDQo+IG5vdGFibHkNCj4gPj4gTk9OX1JFQ0VJ VkVfVElNRU9VVC4gU29tZSBvZiB0aGUgdGV4dCAoZm9yIGV4YW1wbGUsIMKnNC40KSBpbXBsaWVz DQo+ID4+IHRoYXQgdGhlIHRpbWVvdXQgaXMgYW4gdXBwZXIgYm91bmQgb24gaG93IGxvbmcgYW4g aW1wbGVtZW50YXRpb24NCj4gPj4gc2hvdWxkIHdhaXQgYmVmb3JlIGRlY2xhcmluZyBhIGJsb2Nr IHRvIGhhdmUgYmVlbiBsb3N0ICjigJxUaGUNCj4gY2xpZW50DQo+ID4+IFNIT1VMRCB3YWl0IGZv ciB1cCB0byBOT05fUkVDRUlWRV9USU1FT1VU4oCdKS4NCj4gPg0KPiA+IFRoZSB0ZXh0IGFyb3Vu ZCB0aGUgdGltZW91dCB2YWx1ZXMgaGF2ZSBiZWVuIG1hZGUgYWJzb2x1dGUgKGFzIHBlcg0KPiB5 b3VyIENPTU1FTlRTKSwgcmVtb3ZpbmcgInVwIHRvIiwgZXRjLiwgYW5kIG9uY2UgdGhlIHRpbWVv dXQgaGFzDQo+IGV4cGlyZWQsIHRoZW4gdGhlIG5leHQgYWN0aXZpdHkgdGFrZXMgcGxhY2UuIERv ZXMgdGhpcyBoZWxwIGNsYXJpZnkNCj4gdGhpbmdzPw0KPiANCj4gWWVzLCB0aG9zZSBjaGFuZ2Vz LCBwbHVzIHRoZSBvdGhlciByZXdyaXRlcyB0byDCpzcuMiwgaGVscCBhIGxvdC4gVGhpcw0KPiBE SVNDVVNTIHF1ZXN0aW9uIGlzIHJlc29sdmVkIGFzIGZhciBhcyBJ4oCZbSBjb25jZXJuZWQuDQo+ IA0KPiBJIHdvdWxkIGNsZWFyIHRoZSBESVNDVVNTLCBidXQgSSBhbSBjb25jZXJuZWQgYWJvdXQg bXkgY29tbWVudCAjMTENCj4gKHNlZSBiZWxvdykgYW5kIEnigJltIGdvaW5nIHRvIHJhaXNlIHRo YXQgdG8gYSBESVNDVVNTLg0KPiANCg0KVGhhbmtzLg0KDQo+IFvigKZdDQo+IA0KPiA+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gLS0tDQo+ID4+IC0NCj4gPj4gQ09NTUVOVDoNCj4gPj4g4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCUDQo+IA0KPiBb4oCmXQ0KPiANCj4gPj4gMi4g U2VjdGlvbiA0LjENCj4gPj4NCj4gPj4gICBRLUJsb2NrMiBPcHRpb24gaXMgdXNlZnVsIHdpdGgg R0VULCBQT1NULCBQVVQsIEZFVENILCBQQVRDSCwgYW5kDQo+ID4+ICAgaVBBVENIIHJlcXVlc3Rz IGFuZCB0aGVpciBwYXlsb2FkLWJlYXJpbmcgcmVzcG9uc2VzICgyLjAxLCAyLjAyLA0KPiA+PiAg IDIuMDMsIDIuMDQsIGFuZCAyLjA1KSAoU2VjdGlvbiA1LjUgb2YgW1JGQzcyNTJdKS4NCj4gPj4N Cj4gPj4gSSBmb3VuZCB0aGUgbGlzdCBvZiBjb2RlcyBpbmNvbXByZWhlbnNpYmxlIG9uIGZpcnN0 IGVuY291bnRlcmluZw0KPiBpdCwNCj4gPj4gc2luY2UgdGhlIGNvbmNlcHQgb2YgcmVzcG9uc2Ug Y29kZXMgaGFkbuKAmXQgYmVlbiBpbnRyb2R1Y2VkIHlldC4gSQ0KPiBkbw0KPiA+PiB1bmRlcnN0 YW5kIHRoYXQgdGhlIGRvY3VtZW50IGFzc3VtZXMgZmFtaWxpYXJpdHkgd2l0aCBDb0FQOw0KPiA+ PiBub25ldGhlbGVzcyBmb3IgYmFzaWMgY2xhcml0eSBJIHRoaW5rIHRoaXMgc2hvdWxkIHNheSDi gJwocmVzcG9uc2UNCj4gPj4gY29kZXMgMi4wMSwgMi4wMuKApuKAnS4gQWRkaXRpb25hbGx5LCB0 aGUgcmVmZXJlbmNlIHRvIFJGQyA3MjUyIMKnNS41DQo+ID4+IGRvZXNu4oCZdCBzZWVtIHRvIGJl IGVzcGVjaWFsbHkgZ2VybWFuZT8NCj4gPg0KPiA+IFRoZSBrZXkgZWxlbWVudCBpbiB0aGUgdGV4 dCB5b3UgcXVvdGVkIGlzICJwYXlsb2FkLWJlYXJpbmcNCj4gcmVzcG9uc2VzIi4gSGVuY2UgdGhl IHBvaW50ZXIgdG8gNS41IG9mIFJGQzcyNTIuDQo+IA0KPiBPSy4gSSBzdGlsbCB0aGluayB0aGUg dGV4dCB3b3VsZCBiZSBiZXR0ZXIgaWYgeW91IGluc2VydGVkIOKAnHJlc3BvbnNlDQo+IGNvZGVz 4oCdIHdpdGhpbiB0aGUgcGFyZW50aGVzZXMsIGFzIGluIOKAnChyZXNwb25zZSBjb2RlcyAyLjAx LCAyLjAxLCDigKbigJ0NCj4gaW5zdGVhZCBvZiB0aGUgY3VycmVudCDigJwoMi4wMSwgMi4wMiwg 4oCm4oCdLg0KPiANCg0KT0suIEZpeGVkLg0KDQo+IFvigKZdDQo+IA0KPiA+PiA0LiBTZWN0aW9u IDQuMQ0KPiA+Pg0KPiA+PiAgIFRoZSBRLUJsb2NrMSBhbmQgUS1CbG9jazIgT3B0aW9ucyBhcmUg dW5zYWZlIHRvIGZvcndhcmQuICBUaGF0DQo+IGlzLA0KPiA+PiBhDQo+ID4+ICAgQ29BUCBwcm94 eSB0aGF0IGRvZXMgbm90IHVuZGVyc3RhbmQgdGhlIFEtQmxvY2sxIChvciBRLUJsb2NrMikNCj4g Pj4gT3B0aW9uDQo+ID4+ICAgTVVTVCByZWplY3QgdGhlIHJlcXVlc3Qgb3IgcmVzcG9uc2UgdGhh dCB1c2VzIGVpdGhlciBvcHRpb24uDQo+ID4+DQo+ID4+IFByZXN1bWFibHkgKGhvcGVmdWxseSkg dGhpcyBpcyBzaW1wbHkgZGVzY3JpYmluZyB0aGUgYmVoYXZpb3Igb2YNCj4gPj4gZXhpc3Rpbmcg c3BlYy1jb21wbGlhbnQgcHJveGllcyB3aGVuIHByb2Nlc3NpbmcgdGhlIG5ldyBtZXNzYWdlcy4N Cj4gQXMNCj4gPj4gc3VjaCwgaXMgdGhlIE1VU1QgYXBwcm9wcmlhdGU/IEkgd291bGQgdGhpbmsg bm90Lg0KPiA+DQo+ID4gVGhpcyBpcyBvbmx5IGZvciB0aG9zZSB0aGF0IGFyZSB0YWdnZWQgYXMg dW5zYWZlIHRvIGZvcndhcmQuIFRoZQ0KPiBub3JtYXRpdmUgbGFuZ3VhZ2UgaXMgT0suDQo+IA0K PiBNeSBwb2ludCBoZXJlIGlzIHRoYXQgdGhlIHNlY29uZCBzZW50ZW5jZSAodGhlIG9uZSB0aGF0 IGJlZ2lucyDigJx0aGF0DQo+IGlz4oCdKSBpcyBzaW1wbHkgc3RhdGluZyB0aGUgYmVoYXZpb3Ig eW91IHdvdWxkIGV4cGVjdCBhbiBleGlzdGluZw0KPiBwcm94eSB0byBleGhpYml0IGlmIGl0IHdl cmUgcHJlc2VudGVkIHdpdGggdGhlIOKAnHVuc2FmZSB0byBmb3J3YXJk4oCdDQo+IG9wdGlvbnMu IENvcnJlY3Q/DQo+IA0KPiBJZiBzbywgdGhlbiBJIHRoaW5rIHRoZSBNVVNUIGlzIGluYXBwcm9w cmlhdGUsIHNpbmNlIHlvdSBhcmUgbm90DQo+IHNwZWNpZnlpbmcgbmV3IGJlaGF2aW9yIGhlcmUu DQo+IA0KDQpDaGFuZ2VkIHRoZSB0ZXh0IGFuZCBhZGRlZCBhIHBvaW50ZXIgdG8gU2VjdGlvbiA1 LjcuMSBvZiBSRkM3MjUyLg0KDQo+IFvigKZdDQo+IA0KPiA+PiAxMS4gR2VuZXJhbA0KPiA+Pg0K PiA+PiBCeSB0aGUgd2F5LCBub25lIG9mIHRoZSB0aW1lcnMgc3BlY2lmeSBqaXR0ZXIgKGFuZCBp bmRlZWQsIGlmIHJlYWQNCj4gPj4gbGl0ZXJhbGx5LCBqaXR0ZXIgd291bGQgYmUgZm9yYmlkZGVu KS4gSXMgdGhpcyBpbnRlbnRpb25hbD8NCj4gPg0KPiA+IE5vICsvLSB0b2xlcmFuY2VzIGhhdmUg YmVlbiBkZWZpbmVkLiBXaGVuIGEgdGltZXIgZXhwaXJlcywgdGhlbiB0aGUNCj4gbmV4dCBhY3Rp b24gdGFrZXMgcGxhY2UuDQo+IA0KPiBJIG5vdGljZSB0aGF0IFJGQyA3MjUyIGppdHRlcnMgaXRz IHRpbWVycywgZm9yIGV4YW1wbGU6DQo+IA0KPiAgICBjb3VudGVyLiAgRm9yIGEgbmV3IENvbmZp cm1hYmxlIG1lc3NhZ2UsIHRoZSBpbml0aWFsIHRpbWVvdXQgaXMNCj4gc2V0DQo+ICAgIHRvIGEg cmFuZG9tIGR1cmF0aW9uIChvZnRlbiBub3QgYW4gaW50ZWdyYWwgbnVtYmVyIG9mIHNlY29uZHMp DQo+ICAgIGJldHdlZW4gQUNLX1RJTUVPVVQgYW5kIChBQ0tfVElNRU9VVCAqIEFDS19SQU5ET01f RkFDVE9SKSAoc2VlDQo+ICAgIFNlY3Rpb24gNC44KQ0KPiDigKYNCj4gICAgQUNLX1JBTkRPTV9G QUNUT1IgTVVTVCBOT1QgYmUgZGVjcmVhc2VkIGJlbG93IDEuMCwgYW5kIGl0IFNIT1VMRA0KPiBo YXZlDQo+ICAgIGEgdmFsdWUgdGhhdCBpcyBzdWZmaWNpZW50bHkgZGlmZmVyZW50IGZyb20gMS4w IHRvIHByb3ZpZGUgc29tZQ0KPiAgICBwcm90ZWN0aW9uIGZyb20gc3luY2hyb25pemF0aW9uIGVm ZmVjdHMuDQo+IA0KPiBNQVhfVFJBTlNNSVRfU1BBTiBhbmQgTUFYX1RSQU5TTUlUX1dBSVQgYXJl IHNpbWlsYXJseSBqaXR0ZXJlZC4gQQ0KPiBudW1iZXIgb2YgeW91ciBpbnRyb2R1Y2VkIHBhcmFt ZXRlcnMNCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBuZXcgcGFyYW1ldGVycyBN QVhfUEFZTE9BRFMsIE5PTl9USU1FT1VULA0KPiAgICBOT05fUkVDRUlWRV9USU1FT1VULCBOT05f TUFYX1JFVFJBTlNNSVQsIE5PTl9QUk9CSU5HX1dBSVQsIGFuZA0KPiAgICBOT05fUEFSVElBTF9U SU1FT1VUIHByaW1hcmlseSBmb3IgdXNlIHdpdGggTk9OIChUYWJsZSAzKS4NCj4gDQo+IGFwcGVh ciBhdCBsZWFzdCBzdXBlcmZpY2lhbGx5IHNpbWlsYXIgdG8gdGhlIHRpbWVycyB0aGUgYXV0aG9y cyBvZg0KPiBSRkMgNzI1MiBkZWVtZWQgaW1wb3J0YW50IHRvIGppdHRlciB0byBwcmV2ZW50IHN5 bmNocm9uaXphdGlvbg0KPiBlZmZlY3RzLiBEaWQgeW91IHNwZWNpZmljYWxseSBjb25zaWRlciBq aXR0ZXJpbmcgdGhlbSwgYW5kIGRlY2lkZQ0KPiB0aGF0IGppdHRlciB3YXMgdW5uZWNlc3Nhcnk/ IElmIHNvLCBjYW4geW91IGV4cGxhaW4gd2hhdCBpcyBkaWZmZXJlbnQNCj4gYWJvdXQgeW91ciBz cGVjaWZpY2F0aW9uLCBjb21wYXJlZCB0byB0aGUgYmFzZSBzcGVjLCB0aGF0IGVsaW1pbmF0ZXMN Cj4gdGhlIGNvbmNlcm4/DQoNClJGQzcyNTIgaW50cm9kdWNlcyBBQ0tfUkFORE9NX0ZBQ1RPUiBq aXR0ZXIgYW5kIHNlcGFyYXRlbHkgaml0dGVyIGZvciBtdWx0aWNhc3QgcmVzcG9uc2VzICh3aGlj aCBpcyBub3QgcmVsZXZhbnQgaGVyZSkuDQoNClRoZSBBQ0tfUkFORE9NX0ZBQ1RPUiBpcyB0aGVy ZSBmb3Igd2hlbiByZS10cmFuc21pdHRpbmcgYSBwYWNrZXQgdGhhdCBoYXMgbm90IGJlZW4gYWNr bm93bGVkZ2VkIGZvciBzb21lIHJlYXNvbiBieSBpdHMgcGVlci4gTk9OX1RJTUVPVVQgaXMgZm9y IHdoZW4gdGhlIG5leHQgTUFYX1BBWUxPQURTX1NFVCBjYW4gc3RhcnQgdHJhbnNtaXNzaW9uIChu b3QgcmUtdHJhbnNtaXNzaW9uKSBhc3N1bWluZyBhICdDb250aW51ZScgaGFzIG5vdCBhcnJpdmVk IGluIHRoZSBpbnRlcmltLCBhbmQgc28gd2FzIG5vdCB0aG91Z2h0IG5lY2Vzc2FyeSB0byBhZGQg aW4gQUNLX1JBTkRPTV9GQUNUT1Igc3R5bGUgaml0dGVyIGhlcmUuDQoNCkZvciBOT05fUkVDRUlW RV9USU1FT1VULCB3aGF0IGlzIGltcG9ydGFudCBpcyB0aGF0IE5PTl9SRUNFSVZFX1RJTUVPVVQg aXMgZ3JlYXRlciB0aGFuIE5PTl9USU1FT1VUIChXZSBzYXkgaW4gdGhlIHNwZWMgYSBtaW5pbXVt IG9mIG9uZSBzZWNvbmQpIHNvIHRoYXQgYSBwZWVyIGRvZXMgbm90IGZpcmUgb2ZmIGEgcmUtdHJh bnNtaXNzaW9uIHJlcXVlc3QgYmVmb3JlIHRoZSBsb2NhbCBhZ2VudCBoYXMgYSBjaGFuY2UgdG8g c3RhcnQgdG8gdHJhbnNtaXQgdGhlIG5leHQgTUFYX1BBWUxPQURTX1NFVC4gIE5PTl9SRUNFSVZF X1RJTUVPVVQgaXMgZXhwb25lbnRpYWxseSBzY2FsZWQgZm9yIGVhY2ggcmV0cnkgdG8gbWFrZSBz dXJlIHRoYXQgc3RhYmlsaXR5IGlzIHByZXNlcnZlZC4gU28sIGFnYWluLCBBQ0tfUkFORE9NX0ZB Q1RPUiBqaXR0ZXIgd2FzIG5vdCB0aG91Z2h0IHRvIGJlIG5lY2Vzc2FyeSBoZXJlLg0KDQpOT05f TUFYX1JFVFJBTlNNSVQgaXMgYSBmaXhlZCBjb3VudC4NCg0KTk9OX1BST0JJTkdfV0FJVCBpcyB1 c2VkIHRvIHB1dCBhIGxpbWl0IG9uIHRoZSBwb3RlbnRpYWwgZGVsYXkgdGhhdCBjb3VsZCBpbmN1 ciB3aGVuIG9iZXlpbmcgUFJPQklOR19XQUlUIHdoZW4gdGhlcmUgaXMgbm8gcGVlciByZXNwb25z ZS4gSWYgdGhlIGltcGxlbWVudGF0aW9uIGdvZXMgd2l0aCB0aGUgZGVmYXVsdCBFWENIQU5HRV9M SUZFVElNRSBjb21wdXRhdGlvbiwgdGhlbiBOT05fUFJPQklOR19XQUlUIGluY2x1ZGVzIEFDS19S QU5ET01fRkFDVE9SIGluIHRoZSBtYXRoLg0KDQpOT05fUEFSVElBTF9USU1FT1VUIGlmIGNvbXB1 dGVkIHVzaW5nIHRoZSBkZWZhdWx0IEVYQ0hBTkdFX0xJRkVUSU1FIGluY2x1ZGVzIEFDS19SQU5E T01fRkFDVE9SLg0KDQo+IA0KPiA+PiAxMi4gU2VjdGlvbiA3LjINCj4gPj4NCj4gPj4gICBJZiB0 aGUgQ29BUCBwZWVyIHJlcG9ydHMgYXQgbGVhc3Qgb25lIHBheWxvYWQgaGFzIG5vdCBhcnJpdmVk DQo+IGZvcg0KPiA+PiAgIGVhY2ggYm9keSBmb3IgYXQgbGVhc3QgYSAyNCBob3VyIHBlcmlvZCBh bmQgaXQgaXMga25vd24gdGhhdA0KPiB0aGVyZQ0KPiA+PiAgIGFyZSBubyBvdGhlciBuZXR3b3Jr IGlzc3VlcyBvdmVyIHRoYXQgcGVyaW9kLCB0aGVuIHRoZSB2YWx1ZSBvZg0KPiA+PiAgIE1BWF9Q QVlMT0FEUyBjYW4gYmUgcmVkdWNlZCBieSAxIGF0IGEgdGltZSAodG8gYSBtaW5pbXVtIG9mIDEp DQo+IGFuZA0KPiA+PiAgIHRoZSBzaXR1YXRpb24gcmUtZXZhbHVhdGVkIGZvciBhbm90aGVyIDI0 IGhvdXIgcGVyaW9kIHVudGlsDQo+IHRoZXJlDQo+ID4+IGlzDQo+ID4+ICAgbm8gcmVwb3J0IG9m IG1pc3NpbmcgcGF5bG9hZHMgdW5kZXIgbm9ybWFsIG9wZXJhdGluZyBjb25kaXRpb25zLg0KPiA+ PiBUaGUNCj4gPj4gICBuZXdseSBkZXJpdmVkIHZhbHVlIGZvciBNQVhfUEFZTE9BRFMgc2hvdWxk IGJlIHVzZWQgZm9yIGJvdGgNCj4gZW5kcw0KPiA+PiBvZg0KPiA+PiAgIHRoaXMgcGFydGljdWxh ciBDb0FQIHBlZXIgbGluay4gIE5vdGUgdGhhdCB0aGUgQ29BUCBwZWVyIHdpbGwNCj4gbm90DQo+ ID4+ICAga25vdyBhYm91dCB0aGUgTUFYX1BBWUxPQURTIGNoYW5nZSB1bnRpbCBpdCBpcyByZWNv bmZpZ3VyZWQuICBBcw0KPiBhDQo+ID4+ICAgY29uc2VxdWVuY2Ugb2YgdGhlIHR3byBwZWVycyBo YXZpbmcgZGlmZmVyZW50IE1BWF9QQVlMT0FEUw0KPiB2YWx1ZXMsDQo+ID4+IGENCj4gPj4gICBw ZWVyIG1heSBjb250aW51ZSBpbmRpY2F0ZSB0aGF0IHRoZXJlIGFyZSBzb21lIG1pc3NpbmcgcGF5 bG9hZHMNCj4gYXMNCj4gPj4gICBhbGwgb2YgaXRzIE1BWF9QQVlMT0FEUyBzZXQgbWF5IG5vdCBo YXZlIGFycml2ZWQuICBIb3cgdGhlIHR3bw0KPiBwZWVyDQo+ID4+ICAgdmFsdWVzIGZvciBNQVhf UEFZTE9BRFMgYXJlIHN5bmNocm9uaXplZCBpcyBvdXQgb2YgdGhlIHNjb3BlLg0KPiA+Pg0KPiA+ PiBJIHRha2UgaXQgdGhpcyBpcyBqdXN0IHRocm93biBpbiBoZXJlIGFzIGFuIG9wZXJhdGlvbmFs DQo+IHN1Z2dlc3Rpb24/DQo+ID4+IEl04oCZcyBub3Qgc3BlY2lmeWluZyBwcm90b2NvbCwgcmln aHQ/IEl0IHNlZW1zIGEgbGl0dGxlIG1pc3BsYWNlZCwNCj4gaWYNCj4gPj4gc28uDQo+ID4NCj4g PiBUaGlzIGlzIGEgZ3VpZGFuY2UgdG8gYWRqdXN0IHRoZSBtYXhfcGF5bG9hZHMgdG8gYXZvaWQg bG9zc2VzIHVuZGVyDQo+IG5vcm1hbCBjb25kaXRpb25zLg0KPiANCj4gT0ssIGJ1dCB5b3UgaGF2 ZW7igJl0IHNhaWQgd2hldGhlciB0aGlzIGlzIG9wZXJhdGlvbmFsIGd1aWRhbmNlIChpLmUuLA0K PiB5b3UgZXhwZWN0IHRoaXMgdG8gYmUgZG9uZSBieSBodW1hbnMgYWRqdXN0aW5nIGNvbmZpZ3Vy YXRpb24NCj4gcGFyYW1ldGVycykgb3IgaWYgaXTigJlzIHBvdGVudGlhbGx5IHRvIGJlIGRvbmUg YXV0b21hdGljYWxseSB0aGUNCj4gaW1wbGVtZW50YXRpb24uIEdpdmVuIHRoYXQgIkhvdyB0aGUg dHdvIHBlZXIgdmFsdWVzIGZvciBNQVhfUEFZTE9BRFMNCj4gYXJlIHN5bmNocm9uaXplZCBpcyBv dXQgb2YgdGhlIHNjb3Bl4oCdIEkgd291bGQgdGhpbmsgaXTigJlzIHN0cmljdGx5DQo+IG9wZXJh dGlvbmFsIGd1aWRhbmNlLiBJZiB0aGF04oCZcyBjb3JyZWN0IGFuZCBpdOKAmXMgb3BlcmF0aW9u YWwgZ3VpZGFuY2UNCj4gZXhjbHVzaXZlbHksIEkgdGhpbmsgaXQgc2hvdWxkIG5vdCBiZSBwYXJ0 IG9mIMKnNy4yLiBTZWN0aW9uIDcuMg0KPiBzcGVjaWZpZXMgcHJvdG9jb2w7IG1peGluZyBpbiBv cGVyYXRpb25hbCBhZHZpY2UgcG90ZW50aWFsbHkgY29uZnVzZXMNCj4gdGhlIHJlYWRlci4gWW91 IGNvdWxkIGFkZCBhbiDigJxPcGVyYXRpb25hbCBBZHZpY2UgZm9yIFR1bmluZw0KPiBQYXJhbWV0 ZXJz4oCdIG1ham9yIHNlY3Rpb24sIG9yIGV2ZW4gYSBzdWJzZWN0aW9uIGJlbG93IDcuMiwgYW5k IHRoZQ0KPiBjb25jZXJuIHdvdWxkIGJlIHJlc29sdmVkLg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHdl IHJlbW92ZWQgdGhpcyB0ZXh0IGFzIHBlciB0aGUgZGlzY3Vzc2lvbiB3aXRoIEJlbi4NCg0KPiAN Cj4gQnkgdGhlIHdheSwgbml0Og0KPiANCj4gICAgbm90IGhhdmUgYXJyaXZlZC4gIEhvdyB0aGUg dHdvIHBlZXIgdmFsdWVzIGZvciBNQVhfUEFZTE9BRFMgYXJlDQo+ICAgIHN5bmNocm9uaXplZCBp cyBvdXQgb2YgdGhlIHNjb3BlLg0KPiANCj4g4oCcT3V0IG9mIHRoZSBzY29wZeKAnSAtPiDigJxv dXQgb2Ygc2NvcGXigJ0gb3Ig4oCcb3V0IG9mIHRoZSBzY29wZSBvZiB0aGlzDQo+IGRvY3VtZW50 Ig0KPiANCj4gPj4gMTMuIFNlY3Rpb24gMTAuMS4zDQo+ID4+DQo+ID4+IChUaGlzIGNvbW1lbnQg cmVsYXRlcyB0byB0aGUgYXNpZGUgaW4gbXkgRElTQ1VTUy4gWW91IG1heSB3YW50IHRvDQo+ID4+ IHNraXAgb3ZlciBpdCB1bnRpbCB3ZeKAmXZlIHJlc29sdmVkIHRoZSBESVNDVVNTLCBhZnRlciB3 aGljaCB0aGlzDQo+IG1heSwNCj4gPj4gb3IgbWF5IG5vdCwgYmUNCj4gPj4gcmVsZXZhbnQuKQ0K PiA+Pg0KPiA+PiBXaHkgZG9lc27igJl0IHRoZSBzZXJ2ZXIgcmVxdWVzdCAxLDksMTAgaW4gb25l IGdvPyBTaW5jZSBpdHMgcnhtdA0KPiA+PiByZXF1ZXN0IGlzIHRyaWdnZXJlZCBieSByeCBvZiAx MSwgb25lIHdvdWxkIHRoaW5rIGl0IGNvdWxkIGluZmVyDQo+IDEwDQo+ID4+IGhhZCBiZWVuIGxv c3QuDQo+ID4NCj4gPiBCZWNhdXNlIG9ubHkgdGhlIG1pc3NpbmcgYmxvY2tzIG9mIHRoZSBwcmV2 aW91cyBzZXQgYXJlIGluY2x1ZGVkDQo+IGFuZCB0aGVyZSBtYXkgaGF2ZSBiZWVuIHNvbWUgcGFj a2V0IGFycml2YWwgcmUtb3JkZXJpbmcgZm9yIDEwIGFuZA0KPiAxMS4NCj4gDQo+IEkgc2VlLiBJ IGd1ZXNzIEkgd2FzIHRoaW5raW5nIG9mIHRoaXMgaW4gdGVybXMgb2YgYSBzbGlkaW5nLXdpbmRv dw0KPiBwcm90b2NvbCwgYnV0IHlvdXIgcHJvdG9jb2wgaXMgcmVhbGx5IHN0aWxsIGFsbW9zdCBz dG9wLWFuZC13YWl0LCBidXQNCj4gd2l0aCBtdWNoIGxhcmdlciBibG9ja3MuIFlvdXIgcmV3cml0 ZSBoZWxwZWQgYSBsb3Qgd2l0aCB0aGlzLCB0aGFua3MuDQo+IA0KPiBb4oCmXQ0KPiANCj4gPj4g MTUuIFNlY3Rpb24gMTAuMi4zDQo+ID4+DQo+ID4+IChUaGlzIGNvbW1lbnQgcmVsYXRlcyB0byBt eSBESVNDVVNTLiBZb3UgbWF5IHdhbnQgdG8gc2tpcCBvdmVyIGl0DQo+ID4+IHVudGlsIHdl4oCZ dmUgcmVzb2x2ZWQgdGhlIERJU0NVU1MsIGFmdGVyIHdoaWNoIHRoaXMgbWF5LCBvciBtYXkNCj4g bm90LA0KPiA+PiBiZSByZWxldmFudC4pDQo+ID4+DQo+ID4+IFdoeSBkb2VzbuKAmXQgcmVjZXB0 aW9uIG9mIFFCMjoxMC8wLzEwMjQgdHJpZ2dlciB0aGUgY2xpZW50IHRvDQo+IHJlcXVlc3QNCj4g Pj4gcmV0cmFuc21pc3Npb24/IFdoeSBkb2VzIGl0IGhhdmUgdG8gd2FpdCBmb3IgdGltZW91dD8N Cj4gPg0KPiA+IFRoaXMgaXMgZml4ZWQgYXMgcGVyIGEgc2ltaWxhciBjb21tZW50IGZyb20gQmVu Og0KPiA+DQo+ID4gT0xEOg0KPiA+ICAgICAgIFtbTk9OX1RJTUVPVVQgKHNlcnZlcikgZGVsYXkg ZXhwaXJlc11dDQo+ID4gICAgICAgICAgfCAgICAgW1tTZXJ2ZXIgc2VuZHMgbmV4dCBzZXQgb2Yg cGF5bG9hZHNdXQ0KPiA+ICAgICAgICAgIHw8LS0tLS0tLS0tKyBOT04gMi4wNSBNOjB4YWIgVDow eGYwIE86MTIzNiBFVD0yMw0KPiBRQjI6MTAvMC8xMDI0DQo+ID4gICAgICAgICAgfCAgIC4uLiAg ICB8DQo+ID4gICAgICAgW1tOT05fUkVDRUlWRV9USU1FT1VUIChjbGllbnQpIGRlbGF5IGV4cGly ZXNdXQ0KPiA+ICAgICAgICAgIHwgICAgIFtbQ2xpZW50IHJlYWxpemVzIGJsb2NrcyBhcmUgbWlz c2luZyBhbmQgYXNrcyBmb3INCj4gdGhlDQo+ID4gICAgICAgICAgfCAgICAgICBtaXNzaW5nIG9u ZXMgaW4gb25lIGdvXV0NCj4gPiAgICAgICAgICArLS0tLS0tLS0tPnwgTk9OIEdFVCAvcGF0aCBN OjB4MDQgVDoweGYzIFFCMjoxLzAvMTAyNFwNCj4gPiAgICAgICAgICB8ICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFFCMjo5LzAvMTAyNA0KPiA+ICAgICAgICAgIHwgICAg IFg8LS0tKyBOT04gMi4wNSBNOjB4YWMgVDoweGYzIEVUPTIzIFFCMjoxLzEvMTAyNA0KPiA+DQo+ ID4gTkVXOg0KPiA+ICAgICAgIFtbTk9OX1RJTUVPVVQgKHNlcnZlcikgZGVsYXkgZXhwaXJlc11d DQo+ID4gICAgICAgICAgfCAgICAgW1tTZXJ2ZXIgc2VuZHMgbmV4dCBzZXQgb2YgcGF5bG9hZHNd XQ0KPiA+ICAgICAgICAgIHw8LS0tLS0tLS0tKyBOT04gMi4wNSBNOjB4YWIgVDoweGYwIE86MTIz NiBFVD0yMw0KPiBRQjI6MTAvMC8xMDI0DQo+ID4gICAgICAgICAgfCAgICAgW1tPbiBzZWVpbmcg YSBwYXlsb2FkIGZyb20gdGhlIG5leHQgc2V0IG9mIHBheWxvYWRzLA0KPiA+ICAgICAgICAgIHwg ICAgICBDbGllbnQgcmVhbGl6ZXMgYmxvY2tzIGFyZSBtaXNzaW5nIGFuZCBhc2tzIGZvciB0aGUN Cj4gPiAgICAgICAgICB8ICAgICAgIG1pc3Npbmcgb25lcyBpbiBvbmUgZ29dXQ0KPiA+ICAgICAg ICAgICstLS0tLS0tLS0+fCBOT04gR0VUIC9wYXRoIE06MHgwNCBUOjB4ZjMgUUIyOjEvMC8xMDI0 XA0KPiA+ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg UUIyOjkvMC8xMDI0DQo+ID4gICAgICAgICAgfCAgICAgWDwtLS0rIE5PTiAyLjA1IE06MHhhYyBU OjB4ZjMgRVQ9MjMgUUIyOjEvMS8xMDI0DQo+IA0KPiANCj4gSSBwcmVzdW1lIHlvdeKAmXJlIG5v dCBjb25jZXJuZWQgYWJvdXQgcmUtb3JkZXJpbmcgYmV0d2VlbiBwYXlsb2FkIDkNCj4gYW5kIDEw IGJlY2F1c2UgTk9OX1RJTUVPVVQgaXMgYWx3YXlzIGd1YXJhbnRlZWQgdG8gYmUgaW5zZXJ0ZWQN Cj4gYmV0d2VlbiBmbGlnaHRzIG9mIHBheWxvYWRzICh1bmxlc3MgdGhlIG90aGVyIHNpZGUgaGFz IHNlbnQgYSAyLjMxDQo+IENvbnRpbnVlLCB3aGljaCBtZWFucyBub3RoaW5nIHdhcyBsb3N0KSwg dGhlcmVmb3JlIHRoZXJl4oCZcyBhIGRlbGF5DQo+IGluc2VydGVkIG9uIHRoZSBzZXJ2ZXIgc2lk ZSBiZXR3ZWVuIDkgYW5kIDEwLg0KPiANCj4gT25lIGNvbmNlcm4gcmVsYXRlZCB0byB0aGF0OiB3 YWl0aW5nIE5PTl9USU1FT1VUIGlzbuKAmXQgYWN0dWFsbHkNCj4gcmVxdWlyZWQsIGl04oCZcyBv bmx5IFJFQ09NTUVOREVELCB0aGVyZWZvcmUgdGhpcyBpc27igJl0IGFjdHVhbGx5IGENCj4gZ3Vh cmFudGVlLiBGcm9tIMKnNy4yOg0KPiANCj4gICAgQXMgdGhlIHNlbmRpbmcgb2YgbWFueSBwYXls b2FkcyBvZiBhIHNpbmdsZSBib2R5IG1heSBpdHNlbGYgY2F1c2UNCj4gICAgY29uZ2VzdGlvbiwg aXQgaXMgUkVDT01NRU5ERUQgdGhhdCBhZnRlciB0cmFuc21pc3Npb24gb2YgZXZlcnkNCj4gICAg TUFYX1BBWUxPQURTX1NFVCBvZiBhIHNpbmdsZSBib2R5LCBhIGRlbGF5IGlzIGludHJvZHVjZWQg b2YNCj4gICAgTk9OX1RJTUVPVVQgYmVmb3JlIHNlbmRpbmcgdGhlIG5leHQgTUFYX1BBWUxPQURT X1NFVCB0byBtYW5hZ2UNCj4gICAgcG90ZW50aWFsIGNvbmdlc3Rpb24gaXNzdWVzLg0KPiANCj4g SSBhbSBjdXJpb3VzIHdoeSB5b3UgbWFkZSB0aGlzIGEgUkVDT01NRU5ERUQgaW5zdGVhZCBvZiBh IE1VU1QuIEluIGENCj4gc2l0dWF0aW9uIGxpa2UgdGhpcyBpdCB3b3VsZCBiZSBwcmVmZXJhYmxl IGZvciB5b3UgdG8gZXhwbGFpbiB0byB0aGUNCj4gaW1wbGVtZW50b3Igd2hhdCBzaXR1YXRpb24g dGhleSBjYW4gaWdub3JlIHRoZSBSRUNPTU1FTkRFRCBpbiBhbmQNCj4gd2hhdCB0aGV5IHNob3Vs ZCBkbyBpbnN0ZWFkLCBvciBvZiBjb3Vyc2UgdG8gbWFrZSBpdCBpbnRvIGEgTVVTVC4NCg0KQmVj YXVzZSBhIGNvbnRpbnVlIHNpZ25hbCBtYXkgYmUgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBhbmQg dGhlbiBjb250aW51ZSB3aXRob3V0IHdhaXRpbmcgZm9yIHRoZSB0aW1lb3V0IHRvIGV4cGlyZS4g DQoNClRoaXMgaXMgdG8gYmUgbGlua2VkIHdpdGggdGhpcyB0ZXh0OiANCg0KICAgICAgQSByZXNw b25zZSB1c2luZyB0aGlzIFJlc3BvbnNlIENvZGUgU0hPVUxEIE5PVCBiZSBnZW5lcmF0ZWQgZm9y DQogICAgICBldmVyeSByZWNlaXZlZCBRLUJsb2NrMSBPcHRpb24gcmVxdWVzdCAoU2VjdGlvbiA3 LjIpLiAgSXQgU0hPVUxEDQogICAgICBvbmx5IGJlIGdlbmVyYXRlZCB3aGVuIGFsbCB0aGUgcGF5 bG9hZCByZXF1ZXN0cyBhcmUgTm9uLQ0KICAgICAgY29uZmlybWFibGUgYW5kIGEgTUFYX1BBWUxP QURTX1NFVCBoYXMgYmVlbiByZWNlaXZlZCBieSB0aGUNCiAgICAgICBzZXJ2ZXIuICBNb3JlIGRl dGFpbHMgYWJvdXQgdGhlIG1vdGl2YXRpb25zIGZvciB0aGlzIG9wdGltaXphdGlvbg0KICAgICAg ICAgICAgICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eIA0KICAgICAgYXJlIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDcuMi4NCiAgICAgIF5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCg0KV2UgY291bGQgdXNlICoqTVVTVCB1bmxlc3Mg YSAnQ29udGludWUnIGlzIHJlY2VpdmVkKiosIGUuZy4sDQoNCk9MRDoNCiAgIEFzIHRoZSBzZW5k aW5nIG9mIG1hbnkgcGF5bG9hZHMgb2YgYSBzaW5nbGUgYm9keSBtYXkgaXRzZWxmIGNhdXNlDQog ICBjb25nZXN0aW9uLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGFmdGVyIHRyYW5zbWlzc2lvbiBv ZiBldmVyeQ0KICAgTUFYX1BBWUxPQURTX1NFVCBvZiBhIHNpbmdsZSBib2R5LCBhIGRlbGF5IGlz IGludHJvZHVjZWQgb2YNCiAgIE5PTl9USU1FT1VUIGJlZm9yZSBzZW5kaW5nIHRoZSBuZXh0IE1B WF9QQVlMT0FEU19TRVQgdG8gbWFuYWdlDQogICBwb3RlbnRpYWwgY29uZ2VzdGlvbiBpc3N1ZXMu DQoNCk5FVzoNCiAgIEFzIHRoZSBzZW5kaW5nIG9mIG1hbnkgcGF5bG9hZHMgb2YgYSBzaW5nbGUg Ym9keSBtYXkgaXRzZWxmIGNhdXNlDQogICBjb25nZXN0aW9uLCBhZnRlciB0cmFuc21pc3Npb24g b2YgZXZlcnkgTUFYX1BBWUxPQURTX1NFVCBvZiBhIHNpbmdsZQ0KICAgYm9keSwgYSBkZWxheSBN VVNUIGJlIGludHJvZHVjZWQgb2YgTk9OX1RJTUVPVVQgYmVmb3JlIHNlbmRpbmcgdGhlDQogICBu ZXh0IE1BWF9QQVlMT0FEU19TRVQgdG8gbWFuYWdlIHBvdGVudGlhbCBjb25nZXN0aW9uIGlzc3Vl cy4NCiAgIEhvd2V2ZXIsIGlmIGEgJ0NvbnRpbnVlJyBpcyByZWNlaXZlZCBmcm9tIHRoZSBwZWVy IGZvciB0aGUgY3VycmVudA0KICAgTUFYX1BBWUxPQURTX1NFVCwgdGhlbiB0aGUgbmV4dCBNQVhf UEFZTE9BRFNfU0VUIGNhbiBzdGFydA0KICAgdHJhbnNtaXNzaW9uIGltbWVkaWF0ZWx5Lg0KDQou Li4gYnV0IEkga25vdyB0aGF0IG1hbnkgd291bGQgYXJndWUgdGhpcyBpcyBhIFNIT1VMRC4gDQoN Cj4gDQo+IE5vdyB0aGF0IEnigJltIGxvb2tpbmcgYXQgUkVDT01NRU5ERUQgYW5kIFNIT1VMRCBh Z2FpbiwgSSBub3RpY2UgdGhhdA0KPiB0aGUgc3BlY2lmaWNhdGlvbiBmb3IgdXNlIG9mIDIuMzEg aW4gwqc0LjMgaGFzIGEgc2ltaWxhciBwb3RlbnRpYWwNCj4gaXNzdWU6DQo+IA0KPiAgICAgICBB IHJlc3BvbnNlIHVzaW5nIHRoaXMgUmVzcG9uc2UgQ29kZSBTSE9VTEQgTk9UIGJlIGdlbmVyYXRl ZCBmb3INCj4gICAgICAgZXZlcnkgcmVjZWl2ZWQgUS1CbG9jazEgT3B0aW9uIHJlcXVlc3QgKFNl Y3Rpb24gNy4yKS4gIEl0DQo+IFNIT1VMRA0KPiAgICAgICBvbmx5IGJlIGdlbmVyYXRlZCB3aGVu IGFsbCB0aGUgcGF5bG9hZCByZXF1ZXN0cyBhcmUgTm9uLQ0KPiAgICAgICBjb25maXJtYWJsZSBh bmQgYSBNQVhfUEFZTE9BRFNfU0VUIGhhcyBiZWVuIHJlY2VpdmVkIGJ5IHRoZQ0KPiAgICAgICBz ZXJ2ZXIuICBNb3JlIGRldGFpbHMgYWJvdXQgdGhlIG1vdGl2YXRpb25zIGZvciB0aGlzDQo+IG9w dGltaXphdGlvbg0KPiAgICAgICBhcmUgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNy4yLg0KPiANCj4g SSBjYW4gaW1hZ2luZSB3aGVuIGFuIGltcGxlbWVudGF0aW9uIG1pZ2h0IGlnbm9yZSB0aGUgZmly c3QgU0hPVUxEDQo+IE5PVDogZm9yIGV4YW1wbGUgaWYgaXTigJlzIGEgdmVyeSBzbWFsbCBpbXBs ZW1lbnRhdGlvbiB0aGF0IGRvZXNu4oCZdA0KPiB3YW50IHRvIGtlZXAgZXh0cmEgc3RhdGUuDQoN CkZZSSwgd2UgY2hhbmdlZCB0aGUgZmlyc3QgIlNIT1VMRCBOT1QiIHRvICJNVVNUIE5PVCIgYXMg d2UgcmVtb3ZlZCBhdXRvLXNjYWxpbmcgKGRvd24gdG8gMSkuDQoNCiBCdXQgaG93IGFib3V0IHRo ZSBTSE9VTEQ/IFVuZGVyIHdoYXQNCj4gY2lyY3Vtc3RhbmNlcyBpcyBpdCBPSyBmb3IgYW4gaW1w bGVtZW50YXRpb24gdG8gdXNlIFJlc3BvbnNlIENvZGUNCj4gMi4zMSB3aGVuIG5vdCBhbGwgdGhl IHBheWxvYWRzIGluIGEgc2V0IGhhdmUgYmVlbiByZWNlaXZlZD8NCg0KQW4gZXhhbXBsZSB3b3Vs ZCBiZTogSWYgdGhlIHBlZXIgaXMgb3ZlcmxvYWRlZC9jYW4ndCBwcm9jZXNzIG1vcmUgYmxvY2tz LCBpdCB3b24ndCBzZW5kIHRoZSBjb250aW51ZSBzaWduYWwuICANCg0KIElmIHRoZXJlDQo+IGFy ZSBubyBzdWNoIGNpcmN1bXN0YW5jZXMsIHRoaXMgb3VnaHQgdG8gYmUgYSBNVVNUIChvciB0dXJu IGl0IGFyb3VuZA0KPiBhbmQgc2F5IOKAnE1VU1QgTk9UIGJlIGdlbmVyYXRlZCB1bmxlc3PigKbi gJ0pLg0KDQpUaGUgcHJvY2VkdXJlIGRvZXMgbm90IG1hbmRhdGUgdGhlIGNvbnRpbnVlIHNpZ25h bCB0byBiZSByZWNlaXZlZCwgYnV0IGl0IGFsbG93cyBmb3IgaXQgYXMgYW4gb3B0aW1pemF0aW9u IHRvIHNob3J0ZW4gdGhlIGRlbGF5IGJldHdlZW4gdGhlIHNldHMuIEhlbmNlIHRoZSBjdXJyZW50 IHdvcmRpbmcuDQoNCj4gDQo+IEEgc2ltaWxhciBjb25jZXJuIGV4aXN0cyBmb3IgdGhlIHNwZWNp ZmljYXRpb24gb2YgcmVzcG9uc2UgNC4wOC4NCj4gDQo+IEkgcXVpY2tseSBza2ltbWVkIHRoZSBy ZXN0IG9mIHRoZSBkb2N1bWVudCBmb3IgU0hPVUxEL1JFQ09NTUVOREVEIGFuZA0KPiBkaWRu4oCZ dCBmaW5kIG90aGVycyB0aGF0IHNlZW1lZCBlcXVhbGx5IHByb2JsZW1hdGljOyBob3dldmVyIEni gJltIG9mDQo+IHRoZSBzY2hvb2wgb2YgdGhvdWdodCB0aGF0IHNheXMgeW91IHNob3VsZCBhc2sg eW91cnNlbGYgYWJvdXQgZXZlcnkNCj4gU0hPVUxELCDigJx3aHkgaXNu4oCZdCB0aGlzIGEgTVVT VD/igJ0gYW5kIGlmIHlvdSBkb27igJl0IGhhdmUgYSBnb29kIGFuc3dlciwNCj4gY2hhbmdlIGl0 Lg0KPiANCj4gW+KApl0NCj4gDQo+ID4+IDE2LiBTZWN0aW9uIDEwLjIuNA0KPiA+Pg0KPiA+PiBT aW5jZSBNQVhfUEFZTE9BRFMgaXMgMTAsIHdoeSBkb2VzIHRoZSBleGFtcGxlIHNheSDigJxNQVhf UEFZTE9BRFMNCj4gaGFzDQo+ID4+IGJlZW4gcmVhY2hlZOKAnSBhZnRlciBwYXlsb2FkcyAyLTkg aGF2ZSBiZWVuIHJldHJhbnNtaXR0ZWQ/IFRoYXTigJlzDQo+IG9ubHkNCj4gPj4gOCBwYXlsb2Fk cy4NCj4gPj4NCj4gPg0KPiA+IE1BWF9QQVlMT0FEUyBpcyBub3QgYSBzbGlkaW5nIHdpbmRvdy4g SXQgaXMgYSBzcGVjaWZpYyBzZXQgb2YNCj4gYmxvY2tzLCBibG9ja3MgIzAgLSAjOSAocGF5bG9h ZHMgMSB0byAxMCkgaW4gdGhpcyBjYXNlLCB0aGVuIGJsb2Nrcw0KPiAjMTAgLSAjMTkgYW5kIHNv IG9uLg0KPiANCj4gTW9yZSBvciBsZXNzIGEgbWV0YS1ibG9jaywgYXMgSSBtZW50aW9uIGluIG15 IGNvbW1lbnQgb24gIzEzLCBhYm92ZS4NCj4gT0suDQo+IA0KPiBJIGhhdmUgc29tZSBuZXcgcXVl c3Rpb25zIGFuZCBjb21tZW50cyByZWxhdGVkIHRvIHlvdXIgbmV3IHJldmlzaW9uOg0KPiANCj4g MTcuIFNlY3Rpb24gMToNCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUgQ29B UCBRLUJsb2NrMSBhbmQgUS1CbG9jazIgT3B0aW9ucw0KPiB3aGljaA0KPiAgICBhbGxvdyBibG9j ay13aXNlIHRyYW5zZmVyIHRvIHdvcmsgd2l0aCBzZXJpZXMgb2YgTm9uLWNvbmZpcm1hYmxlDQo+ ICAgIG1lc3NhZ2VzLCBpbnN0ZWFkIG9mIGxvY2stc3RlcHBpbmcgdXNpbmcgQ29uZmlybWFibGUg bWVzc2FnZXMNCj4gICAgKFNlY3Rpb24gMykuICBJbiBvdGhlciB3b3JkcywgdGhpcyBkb2N1bWVu dCBwcm92aWRlcyBhIG1pc3NpbmcNCj4gcGllY2UNCj4gICAgb2YgW1JGQzc5NTldLCBuYW1lbHkg dGhlIHN1cHBvcnQgb2YgYmxvY2std2lzZSB0cmFuc2ZlciB1c2luZyBOb24tDQo+ICAgIGNvbmZp cm1hYmxlIHdoZXJlIGFuIGVudGlyZSBib2R5IG9mIGRhdGEgY2FuIGJlIHRyYW5zbWl0dGVkDQo+ IHdpdGhvdXQNCj4gICAgdGhlIHJlcXVpcmVtZW50IGZvciBhbiBhY2tub3dsZWRnZW1lbnQgKGJ1 dCByZWNvdmVyeSBpcyBhdmFpbGFibGUNCj4gICAgc2hvdWxkIGl0IGJlIG5lZWRlZCkuDQo+IA0K PiBBcyBmYXIgYXMgSSBjYW4gdGVsbCB0aGUgc3BlYyBkb2VzIG5vdCByZWFsbHkgcmVtb3ZlIHRo ZSByZXF1aXJlbWVudA0KPiBmb3IgYWNrbm93bGVkZ2VtZW50LA0KDQpUaGVzZSBhcmUgbm90IHJl cXVpcmVkLiBUaGV5IHdlcmUgYWRkZWQgYXMgYW4gb3B0aW1pemF0aW9uIHRvIGF2b2lkIHRoZSBu b24tdGltZW91dCBpZiB0aGUgcGVlciBkZWNpZGVzIHRvIHVzZSBpdC4NCg0KDQogaXQganVzdCBh bW9ydGl6ZXMgdGhlIGFja25vd2xlZGdlbWVudHMgYnkgb25seQ0KPiBzZW5kaW5nIHRoZW0gZXZl cnkgTUFYX1BBWUxPQURTX1NFVC4gUmVzcG9uc2UgQ29kZSAyLjMxIGlzDQo+IGVzc2VudGlhbGx5 IGFuIGFja25vd2xlZGdlbWVudCwgYW5kIGl0IGdldHMgc2VudCB0aGF0IGZyZXF1ZW50bHksDQo+ IHJpZ2h0PyBUaGVyZeKAmXMgYWxzbyAoaWYgSSByZWNhbGwgY29ycmVjdGx5KSBzb21lIGZsYXZv ciBvZg0KPiBhY2tub3dsZWRnZW1lbnQgdGhhdCBpcyBzZW50IHdoZW4gdGhlIGVudGlyZSBib2R5 IGhhcyBiZWVuDQo+IHRyYW5zZmVycmVkLiBTbywgSSB0aGluayB0aGUgbmV3IHBhcmFncmFwaCBp c27igJl0IGFjY3VyYXRlLg0KPiANCj4gVGhpcyBvYnNlcnZhdGlvbiBhbHNvIGFwcGxpZXMgdG8g dGhpcyBjbGFpbWVkIGJlbmVmaXQgaW4gwqczOg0KPiANCj4gICAgbyAgVGhleSBzdXBwb3J0IHNl bmRpbmcgYW4gZW50aXJlIGJvZHkgdXNpbmcgTk9OIG1lc3NhZ2VzIHdpdGhvdXQNCj4gICAgICAg cmVxdWlyaW5nIGFuIGludGVybWVkaWF0ZSByZXNwb25zZSBmcm9tIHRoZSBwZWVyLg0KPiANCj4g UmVzcG9uc2UgQ29kZSAyLjMxIGlzIGV4YWN0bHkgYW4gaW50ZXJtZWRpYXRlIHJlc3BvbnNlLiBJ IGd1ZXNzIG1heWJlDQo+IHlvdXIgZm9jdXMgaXMgdGhhdCBpZiB0aGUgaW50ZXJtZWRpYXRlIHJl c3BvbnNlIGlzbuKAmXQgcmVjZWl2ZWQsDQo+IHRyYW5zbWlzc2lvbiBjb250aW51ZXMsIGFsYmVp dCBtb3JlIHNsb3dseSB0aGFuIGl0IHdvdWxkIG90aGVyd2lzZSwNCj4gYW5kIHVucmVsaWFibHkg dG9vLCBzbyBpbiB0aGF0IHNlbnNlIHRoZSByZXNwb25zZXMgYXJlbuKAmXQg4oCccmVxdWlyZWTi gJ0uDQo+IEkgdGhpbmsgdGhpcyByZXF1aXJlcyBhd2Z1bGx5IGNsb3NlIHBhcnNpbmcgb2YgdGhl IHdvcmQg4oCccmVxdWlyZWTigJ0sDQo+IHRob3VnaC4NCj4gDQo+IDE4LiBTZWN0aW9uIDI6DQo+ IA0KPiAgICBNQVhfUEFZTE9BRFNfU0VUIGlzIHRoZSBzZXQgb2YgYmxvY2tzIGlkZW50aWZpZWQg YnkgYmxvY2sgbnVtYmVycw0KPiAgICB0aGF0LCB3aGVuIGRpdmlkZWQgYnkgTUFYX1BBWUxPQURT LCB0aGV5IGhhdmUgdGhlIHNhbWUgbnVtZXJpYw0KPiANCj4gUmVtb3ZlIOKAnHRoZXnigJ0NCg0K Rml4ZWQuIFRoYW5rcy4gDQoNCj4gDQo+ICAgIHJlc3VsdC4gIEZvciBleGFtcGxlLCBpZiBNQVhf UEFZTE9BRFMgaXMgc2V0IHRvICcxMCcsIGENCj4gICAgTUFYX1BBWUxPQURTX1NFVCBjb3VsZCBi ZSBibG9ja3MgIzAgdG8gIzksICMxMCB0byAjMTksIGV0Yy4NCj4gICAgRGVwZW5kaW5nIG9uIHRo ZSBkYXRhIHNpemUsIHRoZSBNQVhfUEFZTE9BRFNfU0VUIG1heSBub3QgY29tcHJpc2UNCj4gYWxs DQo+ICAgIHRoZSBNQVhfUEFZTE9BRFMgYmxvY2tzLg0KPiANCj4gSSBkb27igJl0IHVuZGVyc3Rh bmQgdGhlIGxhc3Qgc2VudGVuY2UgKCJEZXBlbmRpbmcgb24gdGhlIGRhdGEgc2l6ZSwNCj4gdGhl IE1BWF9QQVlMT0FEU19TRVQgbWF5IG5vdCBjb21wcmlzZSBhbGwgdGhlIE1BWF9QQVlMT0FEUyBi bG9ja3Mu4oCdKQ0KPiBBcmUgeW91IHRyeWluZyB0byBzYXkgdGhhdCBpZiB0aGUgYm9keSBzaXpl IGlzbuKAmXQgZXZlbmx5IGRpdmlzaWJsZSBieQ0KPiBNQVhfUEFZTE9BRFMgdGhlbiB0aGUgZmlu YWwgTUFYX1BBWUxPQURTX1NFVCB3aWxsIGhhdmUgZmV3ZXIgdGhhbg0KPiBNQVhfUEFZTE9BRFMg YmxvY2tzIGluIGl0Pw0KDQpXZSBtZWFudCB0aGF0IHRoZSBsYXN0IHNldCBtYXkgaW5jbHVkZSBm ZXdlciBibG9ja3MgdGhhbiBNQVhfUEFZTE9BRFMuIENoYW5nZWQgdG86DQoNCiAiIERlcGVuZGlu ZyBvbiB0aGUgb3ZlcmFsbCBkYXRhDQogICAgICAgICAgICAgICAgICAgIF5eXl5eXl5eIA0KICAg c2l6ZSwgdGhlIGZpbmFsIE1BWF9QQVlMT0FEU19TRVQgbWF5IG5vdCBjb21wcmlzZSBhbGwgdGhl DQogICAgICAgICAgICAgXl5eXl4NCiAgIE1BWF9QQVlMT0FEUyBibG9ja3MuICINCg0KQmV0dGVy Pw0KDQo+IA0KPiAoSSBkbyB0aGluayB0aGlzIGNoYW5nZSwgdG8gaW50cm9kdWNlIHRoZSB0ZXJt IE1BWF9QQVlMT0FEU19TRVQsIGlzDQo+IGdlbmVyYWxseSBoZWxwZnVsOyB0aGFua3MuKQ0KPiAN Cj4gVGhhbmtzLA0KPiANCj4g4oCUSm9obg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkg YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi ZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Thu May 20 06:35: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 25D093A1732; Thu, 20 May 2021 06:35:05 -0700 (PDT) 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 aCWZu-BmyLHd; Thu, 20 May 2021 06:34:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 AFD0F3A172E; Thu, 20 May 2021 06:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1621517682; bh=C4mvzyrhXI4u/+IUwg58IhvH+AOG08lk1mhKf+Uc06E=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=S9Vsv6pLlbzuOkroeyNeZ0EnvdYDhfHjX1g0mN06/xXaL224HGW+NBOTO4cebnuHr Q0vSH81aaS/1SqwRu0pP+u8ISAUAGns5r3yPS1fQbQtMKli/Pq5C+IMZs/HfktnVTs qNZruSyNQjclsXb7qoLL/4pBNgogIBJn3nHqDVuA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([88.152.184.201]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MnJhO-1l0ixC00m4-00jMsy; Thu, 20 May 2021 15:34:42 +0200 To: John Mattsson , "core@ietf.org" Cc: Benjamin Kaduk References: <162118463178.7394.3689900002808274496@ietfa.amsl.com> <885D9BEC-2A2A-4710-97BB-1BBB0CD6D22D@ericsson.com> From: Achim Kraus Message-ID: <0b473b47-c689-a0e5-c68c-585ce496bbce@gmx.net> Date: Thu, 20 May 2021 15:34:40 +0200 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: <885D9BEC-2A2A-4710-97BB-1BBB0CD6D22D@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:jEP5hKPtuF0YIHpnEcgnXSAy5uudUaZwvNUZY5XGuu0bgVCSV+I xoJZ1IkwAxG4TqnjR0KYgoLxOAdPxQQK5mAqamHiu2Xea7cMSG4Ey2wnOP5o8ayntmn77tc xH4G8qrsz3K17RChwkio4VMKZ2oGQICpEdgGw9UxZk9sJAfwilacgMlO6+1yj5UYYGhQe1f 4pwHxUU0Nra9fyp1sph/w== X-UI-Out-Filterresults: notjunk:1;V03:K0:z6GMjQwgLdM=:+tDm37NPFEQSbZnMN1Zt8D LnlqVxQbaBIKf3FKTGS8bj0mL2u7zlKnloxIoHRNcUVejn4Jhm6+ubmjz4s6GtMG37/1Ozv0h YvYzGxyvDJCuYccduOsO8JXMexjt3nggx2+pvtJK1FW+/sHwvlrzI6TcAz5uNnax3zsl+yjHo B/3eNYApGOhLNbhIWss4jzbNLqIago0L2bPQReR68hoNVvN6/dJqO67xzuREsh6EkV+CZLoJy c5HrC80epLZzm6rApFkb8q6MCmtbRVo/GpVQPsoQUTnbccIIFBIcFBQk58MRkFpIYe3ziKotr +gFxUAjRNiPb4FEfZxYGNP8B6b1ZypP04YHI1/HsbpFQiqSSt7I1IYtHD0cN4IgQJbp31E+gO q8LOHARvkVh+dKNotpJ2/xANDu9x0NsHXrA2QVmNaS0X1DWAoib/fHWBpaHQyZwD2G37jnxLX uDRw4kxiYm0oxGdavbY+jW6qCnM6AIvn10zcM/I9J7yzd2ziSvRTYhAS4fH3pTsTqValdvA51 ioREvHw5dEoGZlw1fBOej2jhvdkbYF4mPYHk7Dkw4SlFgXKyHhP5RX92yzfniueNQh7wAXF8q mvSXznI8Fp+rjDG/577PwCu4y+7iMBVGbtd8VwezCnQHxpwIpfQ09jVJfqmczDYPfhcOJT9Wh oLEKKBHib/JwBnP7OLBbnxp+iXsmCJ+Yqh/hCA9lmzuKR7aiGYtZqSqwjQXXuMoDxh/ijwASJ KgQ1TwCIdB85n2QZuqvj5uZtwmRoQOWvD6C2Ex36zwZ/nQx/p0cCeCB0CseU8D59aazknjrRk ohKYNN93mCod6aUKQXM1ko3vvHert10MfOHHN8v6xrNC0BhEDLueuIqA/53r74Cawx9Dss4jh PaNFpeIGCKRfjVq/V1WBy4EhK6gwSBivCEcIVNIYRm96bFb7Ang0yKIxTTbt8EDhrA2AsW4+b wfFhuyqs5k9rVRB6o3xn/Bo/mLV5a8SOx5uLSy/6WhT9aM0ap1GLyUwu2CILKgoniBijbVEdX Kmt4WpMI4zsu+CmxfUzpguW/MOmmG34xqP0Qe6SSSogk0l++oG8jL0S8KPqgXNHRee+21Sta6 +o+S/HE2yCCaC8VGTjjRaCT9gSn9JQgm4ryTeA4J/l0F67p4MipXzKOCzyKDEqUFl37prt4NZ vVml+TPCo+eWt/EuAfesDAL1A4o7nZWrp0A52JgsGibF1QDF9gFQJrF3D+oC5lEAWRVbo= Archived-At: Subject: Re: [core] FW: New Version Notification for draft-mattsson-core-coap-attacks-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: Thu, 20 May 2021 13:35:05 -0000 Hello John, great work! I left some comments as issue in https://github.com/EricssonResearch/coap-actuators Generally, I personally prefer, if the attack's descriptions also includes, if some assumption tends to be "can not be excluded" or "can be demonstrated". best regards Achim Kraus Am 19.05.21 um 05:07 schrieb John Mattsson: > Hi, > > I made an updated to draft-mattsson-core-coap-actuators, renamed the doc= ument and submitted it as draft-mattsson-core-coap-attacks-00. Except a fe= w editorial updates, the big addition is a new section on amplification at= tacks. I think draft-mattsson-core-coap-attacks should be published as an = informal document similar to e.g. RFC 7457. > > I think CORE needs to discuss and take more concrete action against ampl= ification attacks. Typical CoAP deployments have quite high amplification = factors 10-100, CoAP amplification attacks are happening in the wild, and = they are getting quite much media attention: > > https://www.netscout.com/blog/asert/coap-attacks-wild > > https://www.zdnet.com/article/the-coap-protocol-is-the-next-big-thing-fo= r-ddos-attacks/ > > https://www.zdnet.com/article/fbi-warns-of-new-ddos-attack-vectors-coap-= ws-dd-arms-and-jenkins/ > > https://www.helpnetsecurity.com/2019/03/08/iot-coap-ddos-weapon/ > > https://blog.mazebolt.com/understanding-the-coap-ddos-attack-vector > > https://www.securityweek.com/attackers-use-coap-ddos-amplification > > https://medium.com/nsc42/what-is-coap-and-is-it-the-next-ddos-for-iot-de= 8ee97e57e6 > > https://www.globaldots.com/resources/blog/iot-devices-using-coap-increas= ingly-used-in-ddos-attacks/ > > CORE has considered amplification attacks since the start, but the curre= nt recommendations are quite soft. There might be reason to strengthen the= recommendations or even enforce certain behavior. QUIC has e.g. decided o= n a maximum amplification factor of 3.... Observe and multicast has the ri= sk of significantly increasing amplification. > > I have already received some comments from Carsten who also helped trans= forming the XML to markdown. I will submit -01 version before the cutoff. = Big thanks Carsten! (I never want to manually edit XML again....). > > A repository for the draft can be found here: > https://github.com/EricssonResearch/coap-actuators > (The draft does not compile after the name change and format change, we = will fix that in the coming weeks). > > This was previously discussed here > https://mailarchive.ietf.org/arch/msg/core/i6bf9C0ObT5FIplkHPms9gaC47U/ > > Cheers, > John > > =EF=BB=BF-----Original Message----- > From: "internet-drafts@ietf.org" > Date: Sunday, 16 May 2021 at 19:04 > To: Christian Ams=C3=BCss , G=C3=B6ran Se= lander , John Mattsson , Christian Amsuess , Francesca Palom= bini , G=C3=B6ran Selander , John Fornehed , John Mattsso= n > Subject: New Version Notification for draft-mattsson-core-coap-attacks-0= 0.txt > > > A new version of I-D, draft-mattsson-core-coap-attacks-00.txt > has been successfully submitted by =3D?utf-8?q?John_Preu=3DC3=3D9F_Matts= son?=3D and posted to the > IETF repository. > > Name: draft-mattsson-core-coap-attacks > Revision: 00 > Title: Summarizing Known Attacks on CoAP > Document date: 2021-05-16 > Group: Individual Submission > Pages: 21 > URL: https://www.ietf.org/archive/id/draft-mattsson-core-coap= -attacks-00.txt > Status: https://datatracker.ietf.org/doc/draft-mattsson-core-coa= p-attacks/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-mattsson-cor= e-coap-attacks > Htmlized: https://tools.ietf.org/html/draft-mattsson-core-coap-att= acks-00 > > > Abstract: > Being able to trust information from sensors and to securely control > actuators are essential in a world of connected and networking thing= s > interacting with the physical world. This document summarizes known > attacks, and show that just using CoAP with a security protocol like > DTLS, TLS, or OSCORE is not enough for secure operation. The goal > with this document is motivating generic and protocol-specific > recommendations on the usage of CoAP. Several of the discussed > attacks can be mitigated with the solutions in > [I-D.ietf-core-echo-request-tag]. > > > > > Please note that it may take a couple of minutes from the time of submis= sion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Thu May 20 15:03: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 023913A0A2E; Thu, 20 May 2021 15:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net header.b=AX2Q8Epe; dkim=pass (1024-bit key) header.d=juniper.net header.b=V6QmwRtD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpRlTvM5r0Va; Thu, 20 May 2021 15:03:29 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 1B8BC3A0A2C; Thu, 20 May 2021 15:03:28 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14KM34iG026356; Thu, 20 May 2021 15:03:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=WFK+JscuJ1SGG+qU6U0s1n3Sf/9CEIIBhIPXG4ZkTa0=; b=AX2Q8Epe9HElkfjz10WYDTDHWnakJXsomXx8I34cCM4BwHsNpZFq08lQyVsiF5O6VFu5 a1Wq9OD9BDrrrN97+lMw5jf/NsHIxXBkHxqIoadMYWENIxgAiphojd/OEO2l3SnzNTnj JibG/ZZ47II+kkxFoLOo8cjKu+8WX51bnXTDLQWRKLe48EdcJUJmlabWIUC1LjWvwmBQ nsaYaclOhU5d58RL1DsWiAcAF/BtP5e3XMgGv4EUOQ4m47jpuFWU5Benp+33tdjB5q3Y JS3acjIVCC6OhT2hzJzGp7+4QBphi4+smCaYC9/MckjSXcwy3b6bdnrvBF8q7joz6D6z 0w== Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2101.outbound.protection.outlook.com [104.47.55.101]) by mx0b-00273201.pphosted.com with ESMTP id 38nq4q94fy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 May 2021 15:03:27 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fbGaOh6MAo3weoTpyfTxjtlc1V95F6v/5tEgaJhREFJ7iKs2oFOVRPQoe6IHnpov2TE0nKkKe/WUJtfaP4CKULcfXNKcfiyzOaXjXuwpE+ZSI3AOTn8+3meQm0ex49pSUXw9KpWnTh+Sf/IPxHMPVmVRNY5pzI9ZBto1Q2esIF9tQe+YCDV6zC+Kz22e9Lh0/C1nMZc37o+vi6bi2860E3hYNXpmT++RCZfIYLJIc+ihh5ELi9gLfVyTRSKEQGhpdv/pWYlIC0Ws0fxyOCX4Bv6eV0Hc1hQ+Bc2XnrD12p89R54xhIzyQI2VLQmIEmoDUNgewootTdqdXzNavz8KGg== 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=WFK+JscuJ1SGG+qU6U0s1n3Sf/9CEIIBhIPXG4ZkTa0=; b=kJsgG/+0Nw7abTqTfyVseQhKrCFA0zHkWxk8//dVW2a+eBmT802ytJmhzNI/o5n3JUao+iOU5r9GswYUJfeiVfUzwYQb24q4uW3w4IvfvQTHcFk/dcoGnCzMFratm9Z45/6kzqCx9jlKlAWL68OKN3sLd9n6QaAtgUJ7UuOBNl+EAVMYFhMo/VzQIpFlI/oziPfQGhm4z2TAbLHkflRX65CthypX1J25HpDV8ZjFw8Le+7AtrFDrRIRANCbjRzOYsSDmSQMWtVFdxUT62pQOCqZ7SPIEFjxtfSwpBO2ZWA1a8JMubbOMesGskPJ7R7GUev0bMBakRyHw/GR2946OoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WFK+JscuJ1SGG+qU6U0s1n3Sf/9CEIIBhIPXG4ZkTa0=; b=V6QmwRtDm98hTt9LAkMtjkqMyySLh/0Jo8HRWD5a6p1Th/t/N/viWDOjE26EQ4+IHhREIeLyIm9XhZTadR545Cb0HLp140+UCvlnOOZ8+VYfo5D3QnBazLNmpvKnMoV1Cu8kvm9hr6+YhYyJEtkWdj7XxEs05io18Sjur302tTI= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6431.namprd05.prod.outlook.com (2603:10b6:208:dc::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.12; Thu, 20 May 2021 22:03:22 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::3020:ac3:590d:83f1]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::3020:ac3:590d:83f1%5]) with mapi id 15.20.4150.017; Thu, 20 May 2021 22:03:22 +0000 From: John Scudder To: "mohamed.boucadair@orange.com" CC: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXQhCbJLPvcFdg/UKru2kURMqcWqrXeDkAgBPx5ACAAQGlMIAAmAIA Date: Thu, 20 May 2021 22:03:22 +0000 Message-ID: References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net> <23771_1621516652_60A6616C_23771_79_1_787AE7BB302AE849A7480A190F8B93303538BB63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <23771_1621516652_60A6616C_23771_79_1_787AE7BB302AE849A7480A190F8B93303538BB63@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.6) authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [162.225.191.192] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f53c6626-6bd0-412a-73db-08d91bdb15da x-ms-traffictypediagnostic: MN2PR05MB6431: 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: EGXWTPCscGScOhxLdjLQIYieGfSJmZySD35opNootHYeI7U0MVzknSehYnq387GcnMeqbgtt1VFs5UlF9TfnmN0Acr0HgsNpUGcXjyWF+k9c04HNW7Ao2QLhstseWGaY96zzaz72eBifiQYOzwe90El75TI7kzKKF0GnAtbgM5IHvt0UxRTIQwDZE8tZSPb2vPELW7ZOiouTnkxvhfuZV6KI2k1664ArLsms1Oue68bRHPgCaGqgBdZDPlxqR4eznNk3+vjBTAjeEgnxe61yXHoYP3i5uP0fTcI1gfjgPDk4K6Vi/COhfbHEa2rv1S89bVxIxdx17f9OUVJ2Mcayr575gxB0j1YRo2yVuh/JMgcnjLKQJvwFA0y4tZiaIWh1VleR41B3WU783nyJ5kmtEH6qfl/SpH18ApARxlC0APYKNT3GbpkLR5OM1r6i3uvFoxgZnLH2UQCot13R+vLfex/lH7ILE0ViyPnl0/lj82rKd4wHtiPohGVWmyUh01SdXEuXzL9exnZTkGJrCEg0YZGcT0mRCjcSUp8ECfnp+irtGaA8RnuMbV//NWyDZB4b8H+wXNWbM3dqwB4EHLNckXLVUNSZnQUJhKvlU5vbKPvd7sjvx9Vqigsu0jtxT8Wf17pAKfCUEX3OYmAAhfyMAvnFkkhi7PFmWsGkavx4gcc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(396003)(346002)(136003)(39860400002)(76116006)(91956017)(66556008)(66476007)(38100700002)(6916009)(33656002)(2906002)(122000001)(5660300002)(4326008)(83380400001)(86362001)(66946007)(64756008)(66446008)(8676002)(53546011)(6486002)(186003)(316002)(6512007)(478600001)(8936002)(26005)(71200400001)(36756003)(54906003)(6506007)(2616005)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?Q0hkYlY4R1BXcW1HZTJ6QkFTSy9BcE5adlVUOGF4TlZucFdGaEY3SEg1UmVX?= =?utf-8?B?S0o1QTE2MHJzTFJsWmd2dnBaaU9Fa3RQYWlUVEF2aXZ0V05FQ2N0YUxPMWc2?= =?utf-8?B?d3pHd3lhMGUvUG9YNXdGNkJsSHc5V0w5bDk5eVc3NTJRVzErNGRrN0lJdXJQ?= =?utf-8?B?Z0lyTklqVU9Pbi9pcWNrREJpU0FkRWRoUzJFbkdQMTVPQWVBZ3RrQk5Id2Nr?= =?utf-8?B?cEl0NnFPT3ZSSEw2ekg1MGZVcjlyOWxINDViQmYyWnNKTFRnaUZjeVRQZGdw?= =?utf-8?B?L1VMakRKeWFYT3QzZHJUWS9UM3d0WXgvckRzUTRtMlBLTDg5TEJxeTJpSTJV?= =?utf-8?B?MW4zclFDM01NWFZQTExDY3Y3Y0NmRnRvVFlsUHRaWndkcWZsNzZxczRqbURM?= =?utf-8?B?K2l1Umk2RWQvS3JreTNOWWRnRDVEWW1JUzRvUEdCbkZNdDRyVXM1bHQzUURt?= =?utf-8?B?TXdqc0NtSUtuYXVaMytjcWhZNnpTRHhNRFFzUkE3TnJwV0g5ODFhaFg3ZVhy?= =?utf-8?B?cHRTVCs2ZzNZLzU0RU1sYkw4cHVIQU5vOVRIQ3doRzhRdUJBVGR5SnJaUXpS?= =?utf-8?B?Z1J6VTFPcVFOSHplTWZOb1NjVk9OcnFOd2ZoTFIrUmlGT2FiNExHSHE5V2k5?= =?utf-8?B?UjFUUWc2T1B6SWlna3d0dU9mZGxqYWF3eXNON2NkSERITTNjY0ZESUZka3Ni?= =?utf-8?B?WTFoVXJ1bXRZc05OOWdoWFl5N2VvT2pJdzUyWGw4NXZSczZhenZTOHNNT3pZ?= =?utf-8?B?Y3ZkalRPaDBWZ2hRRkM3Yis1cEhiTjVMakZ1Y2pxRmRVV3JGNlJCQjdVVU41?= =?utf-8?B?aTcvUjNUSklmWklyaDRFVFpuR25PejZ2RE5wWXdSM1RYVG5vOGtpSGpWOHlj?= =?utf-8?B?cGFXVGxKRmR3U3piN2ViWUk1ZXN2U2RibkVvaS9iT0lVMWNDeUgzTjAzQVdx?= =?utf-8?B?WEFRbXNuVVppVGx3ekd6cHg5SnRyNU4wWTNZMzN6M0M3NTRoamQ4aEZkbmFW?= =?utf-8?B?TlJzRjBGMERxWnQzWWdVUDN1R2VBZFpFMTAxSW1VVForQ1V3OGxiUWJnVDFk?= =?utf-8?B?Vno5Q0VFR1lHbExqb0RCK200QktERkh3RXo5bGxTMURWYURpcDRPYmNCa0pa?= =?utf-8?B?VUdLMmZIa1pqNVp3bnhXUDlKcUNBa0NhQmlsdEJ4OTBSUFI4bjRuQkxCcjNu?= =?utf-8?B?anBlcGhaYU5KQmhaWWtCN2JaZUVzNmNZRVg5NmFNSDhnQ2tCK3hiT0dmSGNm?= =?utf-8?B?UHNPQmk0bmF3T291ZlB6Z0h2RTdvZXpqRENjS3Zub3FXR0NEMlhnaXVZRHVS?= =?utf-8?B?NzNJd3VjQnV0RWlJS1crb2NiaUVaSjZaZENjeXZIMnA2MHFBcms2dDN2YUwy?= =?utf-8?B?ME1HVXRKVW8zeEpHUzNKSzN2UGl5WWV5Um4yaWFPSjVuem5ndkYvSkVaeitW?= =?utf-8?B?WTdUTFFQeWY4SlZmRkdHdFFORFMxWktaL24yOURveXplcy8zOXZTcndlLytl?= =?utf-8?B?Zi9IcVo2d0p0V3p1ZXpIRDRUbXlrTVU2N1RXdGVjZlZlbmJVM0xpOFRBQkNh?= =?utf-8?B?cU9vNnM1a3dJWTRNZFlsS3lsNU9DRjM4Vm4va1RyOWNlN0lXWE5oSE9GVW9W?= =?utf-8?B?ODZhODJ3c3A5MS9TNDNZcFV5OStEbW83QnZxOHB5TkpoQVZFUUQzQ20vdXlV?= =?utf-8?B?UVpTRWJXRHAzK3FwSVFrRGhhREhyZTdpUjIyL1E0Wnd6ZFIzUzhsZUF3ejVF?= =?utf-8?B?WEVWOWgyTGxZbGhvODI2SlpQbmxMZWlDM3FzemNoenptenl2Y3k4L2ZGYkRq?= =?utf-8?B?SGpERmdMWW5RSWhOQXpGdz09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f53c6626-6bd0-412a-73db-08d91bdb15da X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2021 22:03:22.6222 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /yfazu0L6OGFen6M4fLKJ28bcUe78LynO33Y/ZFRB0DRbBs1oKeX9tlgWWuE1Ahs X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6431 X-Proofpoint-ORIG-GUID: 7m-tcSgV_e_pxVfBpyYze5sffbsjuwpz X-Proofpoint-GUID: 7m-tcSgV_e_pxVfBpyYze5sffbsjuwpz X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-20_06:2021-05-20, 2021-05-20 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 priorityscore=1501 mlxlogscore=999 malwarescore=0 mlxscore=0 suspectscore=0 phishscore=0 spamscore=0 bulkscore=0 impostorscore=0 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105200137 Archived-At: Subject: Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2021 22:03:35 -0000 SGkgTW9oYW1lZCwNCg0KSSB0aGluayB3ZSBhcmUgY29udmVyZ2luZy4gTXkgY29tbWVudHMgaW4g bGluZS4gSeKAmXZlIHNuaXBwZWQgYWdyZWVkIHBvaW50cyBmb3IgYnJldml0eSwgaW5kaWNhdGVk IGJ5IFvigKZdLiANCg0KPiBPbiBNYXkgMjAsIDIwMjEsIGF0IDk6MTcgQU0sIG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQoNClvigKZdDQoNCj4+Pj4gMTEuIEdlbmVyYWwNCj4+ Pj4gDQo+Pj4+IEJ5IHRoZSB3YXksIG5vbmUgb2YgdGhlIHRpbWVycyBzcGVjaWZ5IGppdHRlciAo YW5kIGluZGVlZCwgaWYgcmVhZA0KPj4+PiBsaXRlcmFsbHksIGppdHRlciB3b3VsZCBiZSBmb3Ji aWRkZW4pLiBJcyB0aGlzIGludGVudGlvbmFsPw0KPj4+IA0KPj4+IE5vICsvLSB0b2xlcmFuY2Vz IGhhdmUgYmVlbiBkZWZpbmVkLiBXaGVuIGEgdGltZXIgZXhwaXJlcywgdGhlbiB0aGUNCj4+IG5l eHQgYWN0aW9uIHRha2VzIHBsYWNlLg0KPj4gDQo+PiBJIG5vdGljZSB0aGF0IFJGQyA3MjUyIGpp dHRlcnMgaXRzIHRpbWVycywgZm9yIGV4YW1wbGU6DQo+PiANCj4+ICAgY291bnRlci4gIEZvciBh IG5ldyBDb25maXJtYWJsZSBtZXNzYWdlLCB0aGUgaW5pdGlhbCB0aW1lb3V0IGlzDQo+PiBzZXQN Cj4+ICAgdG8gYSByYW5kb20gZHVyYXRpb24gKG9mdGVuIG5vdCBhbiBpbnRlZ3JhbCBudW1iZXIg b2Ygc2Vjb25kcykNCj4+ICAgYmV0d2VlbiBBQ0tfVElNRU9VVCBhbmQgKEFDS19USU1FT1VUICog QUNLX1JBTkRPTV9GQUNUT1IpIChzZWUNCj4+ICAgU2VjdGlvbiA0LjgpDQo+PiDigKYNCj4+ICAg QUNLX1JBTkRPTV9GQUNUT1IgTVVTVCBOT1QgYmUgZGVjcmVhc2VkIGJlbG93IDEuMCwgYW5kIGl0 IFNIT1VMRA0KPj4gaGF2ZQ0KPj4gICBhIHZhbHVlIHRoYXQgaXMgc3VmZmljaWVudGx5IGRpZmZl cmVudCBmcm9tIDEuMCB0byBwcm92aWRlIHNvbWUNCj4+ICAgcHJvdGVjdGlvbiBmcm9tIHN5bmNo cm9uaXphdGlvbiBlZmZlY3RzLg0KPj4gDQo+PiBNQVhfVFJBTlNNSVRfU1BBTiBhbmQgTUFYX1RS QU5TTUlUX1dBSVQgYXJlIHNpbWlsYXJseSBqaXR0ZXJlZC4gQQ0KPj4gbnVtYmVyIG9mIHlvdXIg aW50cm9kdWNlZCBwYXJhbWV0ZXJzDQo+PiANCj4+ICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2Vz IG5ldyBwYXJhbWV0ZXJzIE1BWF9QQVlMT0FEUywgTk9OX1RJTUVPVVQsDQo+PiAgIE5PTl9SRUNF SVZFX1RJTUVPVVQsIE5PTl9NQVhfUkVUUkFOU01JVCwgTk9OX1BST0JJTkdfV0FJVCwgYW5kDQo+ PiAgIE5PTl9QQVJUSUFMX1RJTUVPVVQgcHJpbWFyaWx5IGZvciB1c2Ugd2l0aCBOT04gKFRhYmxl IDMpLg0KPj4gDQo+PiBhcHBlYXIgYXQgbGVhc3Qgc3VwZXJmaWNpYWxseSBzaW1pbGFyIHRvIHRo ZSB0aW1lcnMgdGhlIGF1dGhvcnMgb2YNCj4+IFJGQyA3MjUyIGRlZW1lZCBpbXBvcnRhbnQgdG8g aml0dGVyIHRvIHByZXZlbnQgc3luY2hyb25pemF0aW9uDQo+PiBlZmZlY3RzLiBEaWQgeW91IHNw ZWNpZmljYWxseSBjb25zaWRlciBqaXR0ZXJpbmcgdGhlbSwgYW5kIGRlY2lkZQ0KPj4gdGhhdCBq aXR0ZXIgd2FzIHVubmVjZXNzYXJ5PyBJZiBzbywgY2FuIHlvdSBleHBsYWluIHdoYXQgaXMgZGlm ZmVyZW50DQo+PiBhYm91dCB5b3VyIHNwZWNpZmljYXRpb24sIGNvbXBhcmVkIHRvIHRoZSBiYXNl IHNwZWMsIHRoYXQgZWxpbWluYXRlcw0KPj4gdGhlIGNvbmNlcm4/DQo+IA0KPiBSRkM3MjUyIGlu dHJvZHVjZXMgQUNLX1JBTkRPTV9GQUNUT1Igaml0dGVyIGFuZCBzZXBhcmF0ZWx5IGppdHRlciBm b3IgbXVsdGljYXN0IHJlc3BvbnNlcyAod2hpY2ggaXMgbm90IHJlbGV2YW50IGhlcmUpLg0KPiAN Cj4gVGhlIEFDS19SQU5ET01fRkFDVE9SIGlzIHRoZXJlIGZvciB3aGVuIHJlLXRyYW5zbWl0dGlu ZyBhIHBhY2tldCB0aGF0IGhhcyBub3QgYmVlbiBhY2tub3dsZWRnZWQgZm9yIHNvbWUgcmVhc29u IGJ5IGl0cyBwZWVyLiBOT05fVElNRU9VVCBpcyBmb3Igd2hlbiB0aGUgbmV4dCBNQVhfUEFZTE9B RFNfU0VUIGNhbiBzdGFydCB0cmFuc21pc3Npb24gKG5vdCByZS10cmFuc21pc3Npb24pIGFzc3Vt aW5nIGEgJ0NvbnRpbnVlJyBoYXMgbm90IGFycml2ZWQgaW4gdGhlIGludGVyaW0sIGFuZCBzbyB3 YXMgbm90IHRob3VnaHQgbmVjZXNzYXJ5IHRvIGFkZCBpbiBBQ0tfUkFORE9NX0ZBQ1RPUiBzdHls ZSBqaXR0ZXIgaGVyZS4NCj4gDQo+IEZvciBOT05fUkVDRUlWRV9USU1FT1VULCB3aGF0IGlzIGlt cG9ydGFudCBpcyB0aGF0IE5PTl9SRUNFSVZFX1RJTUVPVVQgaXMgZ3JlYXRlciB0aGFuIE5PTl9U SU1FT1VUIChXZSBzYXkgaW4gdGhlIHNwZWMgYSBtaW5pbXVtIG9mIG9uZSBzZWNvbmQpIHNvIHRo YXQgYSBwZWVyIGRvZXMgbm90IGZpcmUgb2ZmIGEgcmUtdHJhbnNtaXNzaW9uIHJlcXVlc3QgYmVm b3JlIHRoZSBsb2NhbCBhZ2VudCBoYXMgYSBjaGFuY2UgdG8gc3RhcnQgdG8gdHJhbnNtaXQgdGhl IG5leHQgTUFYX1BBWUxPQURTX1NFVC4gIE5PTl9SRUNFSVZFX1RJTUVPVVQgaXMgZXhwb25lbnRp YWxseSBzY2FsZWQgZm9yIGVhY2ggcmV0cnkgdG8gbWFrZSBzdXJlIHRoYXQgc3RhYmlsaXR5IGlz IHByZXNlcnZlZC4gU28sIGFnYWluLCBBQ0tfUkFORE9NX0ZBQ1RPUiBqaXR0ZXIgd2FzIG5vdCB0 aG91Z2h0IHRvIGJlIG5lY2Vzc2FyeSBoZXJlLg0KPiANCj4gTk9OX01BWF9SRVRSQU5TTUlUIGlz IGEgZml4ZWQgY291bnQuDQo+IA0KPiBOT05fUFJPQklOR19XQUlUIGlzIHVzZWQgdG8gcHV0IGEg bGltaXQgb24gdGhlIHBvdGVudGlhbCBkZWxheSB0aGF0IGNvdWxkIGluY3VyIHdoZW4gb2JleWlu ZyBQUk9CSU5HX1dBSVQgd2hlbiB0aGVyZSBpcyBubyBwZWVyIHJlc3BvbnNlLiBJZiB0aGUgaW1w bGVtZW50YXRpb24gZ29lcyB3aXRoIHRoZSBkZWZhdWx0IEVYQ0hBTkdFX0xJRkVUSU1FIGNvbXB1 dGF0aW9uLCB0aGVuIE5PTl9QUk9CSU5HX1dBSVQgaW5jbHVkZXMgQUNLX1JBTkRPTV9GQUNUT1Ig aW4gdGhlIG1hdGguDQo+IA0KPiBOT05fUEFSVElBTF9USU1FT1VUIGlmIGNvbXB1dGVkIHVzaW5n IHRoZSBkZWZhdWx0IEVYQ0hBTkdFX0xJRkVUSU1FIGluY2x1ZGVzIEFDS19SQU5ET01fRkFDVE9S Lg0KDQpUaGFua3MgZm9yIHRha2luZyB0aGUgdGltZSB0byBleHBsYWluLiBZb3UgZG9u4oCZdCBj b21tZW50IHJlZ2FyZGluZyB3aGV0aGVyIE5PTl9QUk9CSU5HX1dBSVQgYW5kIE5PTl9QQVJUSUFM X1RJTUVPVVQgc2hvdWxkIGJlIGppdHRlcmVkIG9yIG5vdCwgeW91IGp1c3QgZXhwbGFpbiB0aGF0 IGlmIHRoZXkgdXNlIHRoZSBkZWZhdWx0IHRoZXkgZ2V0IGppdHRlciDigJxmb3IgZnJlZeKAnS4g VGhlIG1pc3NpbmcgZGV0YWlsIGlzIHRoYXQgaWYgdGhleSBkb27igJl0IHVzZSB0aGUgZGVmYXVs dCB0aGV5IGRvbuKAmXQgZ2V0IGppdHRlcmVkLCBzbyBJIHRoaW5rIHNvbWUgY29uc2lkZXJhdGlv biBpcyBzdGlsbCBjYWxsZWQgZm9yIHJlZ2FyZGluZyB3aGV0aGVyIGhhdmluZyB0aGVtIG5vdCBi ZSBqaXR0ZXJlZCBpcyBPSy4NCg0KW+KApl0NCg0KPj4+PiAxNS4gU2VjdGlvbiAxMC4yLjMNCg0K W+KApl0NCg0KPj4gT25lIGNvbmNlcm4gcmVsYXRlZCB0byB0aGF0OiB3YWl0aW5nIE5PTl9USU1F T1VUIGlzbuKAmXQgYWN0dWFsbHkNCj4+IHJlcXVpcmVkLCBpdOKAmXMgb25seSBSRUNPTU1FTkRF RCwgdGhlcmVmb3JlIHRoaXMgaXNu4oCZdCBhY3R1YWxseSBhDQo+PiBndWFyYW50ZWUuIEZyb20g wqc3LjI6DQo+PiANCj4+ICAgQXMgdGhlIHNlbmRpbmcgb2YgbWFueSBwYXlsb2FkcyBvZiBhIHNp bmdsZSBib2R5IG1heSBpdHNlbGYgY2F1c2UNCj4+ICAgY29uZ2VzdGlvbiwgaXQgaXMgUkVDT01N RU5ERUQgdGhhdCBhZnRlciB0cmFuc21pc3Npb24gb2YgZXZlcnkNCj4+ICAgTUFYX1BBWUxPQURT X1NFVCBvZiBhIHNpbmdsZSBib2R5LCBhIGRlbGF5IGlzIGludHJvZHVjZWQgb2YNCj4+ICAgTk9O X1RJTUVPVVQgYmVmb3JlIHNlbmRpbmcgdGhlIG5leHQgTUFYX1BBWUxPQURTX1NFVCB0byBtYW5h Z2UNCj4+ICAgcG90ZW50aWFsIGNvbmdlc3Rpb24gaXNzdWVzLg0KPj4gDQo+PiBJIGFtIGN1cmlv dXMgd2h5IHlvdSBtYWRlIHRoaXMgYSBSRUNPTU1FTkRFRCBpbnN0ZWFkIG9mIGEgTVVTVC4gSW4g YQ0KPj4gc2l0dWF0aW9uIGxpa2UgdGhpcyBpdCB3b3VsZCBiZSBwcmVmZXJhYmxlIGZvciB5b3Ug dG8gZXhwbGFpbiB0byB0aGUNCj4+IGltcGxlbWVudG9yIHdoYXQgc2l0dWF0aW9uIHRoZXkgY2Fu IGlnbm9yZSB0aGUgUkVDT01NRU5ERUQgaW4gYW5kDQo+PiB3aGF0IHRoZXkgc2hvdWxkIGRvIGlu c3RlYWQsIG9yIG9mIGNvdXJzZSB0byBtYWtlIGl0IGludG8gYSBNVVNULg0KPiANCj4gQmVjYXVz ZSBhIGNvbnRpbnVlIHNpZ25hbCBtYXkgYmUgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBhbmQgdGhl biBjb250aW51ZSB3aXRob3V0IHdhaXRpbmcgZm9yIHRoZSB0aW1lb3V0IHRvIGV4cGlyZS4NCj4g DQo+IFRoaXMgaXMgdG8gYmUgbGlua2VkIHdpdGggdGhpcyB0ZXh0Og0KPiANCj4gICAgICBBIHJl c3BvbnNlIHVzaW5nIHRoaXMgUmVzcG9uc2UgQ29kZSBTSE9VTEQgTk9UIGJlIGdlbmVyYXRlZCBm b3INCj4gICAgICBldmVyeSByZWNlaXZlZCBRLUJsb2NrMSBPcHRpb24gcmVxdWVzdCAoU2VjdGlv biA3LjIpLiAgSXQgU0hPVUxEDQo+ICAgICAgb25seSBiZSBnZW5lcmF0ZWQgd2hlbiBhbGwgdGhl IHBheWxvYWQgcmVxdWVzdHMgYXJlIE5vbi0NCj4gICAgICBjb25maXJtYWJsZSBhbmQgYSBNQVhf UEFZTE9BRFNfU0VUIGhhcyBiZWVuIHJlY2VpdmVkIGJ5IHRoZQ0KPiAgICAgICBzZXJ2ZXIuICBN b3JlIGRldGFpbHMgYWJvdXQgdGhlIG1vdGl2YXRpb25zIGZvciB0aGlzIG9wdGltaXphdGlvbg0K PiAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXg0KPiAgICAgIGFyZSBkaXNjdXNzZWQgaW4gU2VjdGlvbiA3LjIuDQo+ ICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KPiANCj4gV2UgY291bGQgdXNlICoq TVVTVCB1bmxlc3MgYSAnQ29udGludWUnIGlzIHJlY2VpdmVkKiosIGUuZy4sDQo+IA0KPiBPTEQ6 DQo+ICAgQXMgdGhlIHNlbmRpbmcgb2YgbWFueSBwYXlsb2FkcyBvZiBhIHNpbmdsZSBib2R5IG1h eSBpdHNlbGYgY2F1c2UNCj4gICBjb25nZXN0aW9uLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGFm dGVyIHRyYW5zbWlzc2lvbiBvZiBldmVyeQ0KPiAgIE1BWF9QQVlMT0FEU19TRVQgb2YgYSBzaW5n bGUgYm9keSwgYSBkZWxheSBpcyBpbnRyb2R1Y2VkIG9mDQo+ICAgTk9OX1RJTUVPVVQgYmVmb3Jl IHNlbmRpbmcgdGhlIG5leHQgTUFYX1BBWUxPQURTX1NFVCB0byBtYW5hZ2UNCj4gICBwb3RlbnRp YWwgY29uZ2VzdGlvbiBpc3N1ZXMuDQo+IA0KPiBORVc6DQo+ICAgQXMgdGhlIHNlbmRpbmcgb2Yg bWFueSBwYXlsb2FkcyBvZiBhIHNpbmdsZSBib2R5IG1heSBpdHNlbGYgY2F1c2UNCj4gICBjb25n ZXN0aW9uLCBhZnRlciB0cmFuc21pc3Npb24gb2YgZXZlcnkgTUFYX1BBWUxPQURTX1NFVCBvZiBh IHNpbmdsZQ0KPiAgIGJvZHksIGEgZGVsYXkgTVVTVCBiZSBpbnRyb2R1Y2VkIG9mIE5PTl9USU1F T1VUIGJlZm9yZSBzZW5kaW5nIHRoZQ0KPiAgIG5leHQgTUFYX1BBWUxPQURTX1NFVCB0byBtYW5h Z2UgcG90ZW50aWFsIGNvbmdlc3Rpb24gaXNzdWVzLg0KPiAgIEhvd2V2ZXIsIGlmIGEgJ0NvbnRp bnVlJyBpcyByZWNlaXZlZCBmcm9tIHRoZSBwZWVyIGZvciB0aGUgY3VycmVudA0KPiAgIE1BWF9Q QVlMT0FEU19TRVQsIHRoZW4gdGhlIG5leHQgTUFYX1BBWUxPQURTX1NFVCBjYW4gc3RhcnQNCj4g ICB0cmFuc21pc3Npb24gaW1tZWRpYXRlbHkuDQo+IA0KPiAuLi4gYnV0IEkga25vdyB0aGF0IG1h bnkgd291bGQgYXJndWUgdGhpcyBpcyBhIFNIT1VMRC4NCg0KSSB3b3VsZCBiZSBPSyB3aXRoIGVp dGhlciB5b3VyIHByb3Bvc2VkIG5ldyB0ZXh0LCBvciBhIFNIT1VMRC9NQVkgcGFpciBhcyBpbiAN Cg0KTkVXOg0KICBBcyB0aGUgc2VuZGluZyBvZiBtYW55IHBheWxvYWRzIG9mIGEgc2luZ2xlIGJv ZHkgbWF5IGl0c2VsZiBjYXVzZQ0KICBjb25nZXN0aW9uLCBhZnRlciB0cmFuc21pc3Npb24gb2Yg ZXZlcnkgTUFYX1BBWUxPQURTX1NFVCBvZiBhIHNpbmdsZQ0KICBib2R5LCBhIGRlbGF5IFNIT1VM RCBiZSBpbnRyb2R1Y2VkIG9mIE5PTl9USU1FT1VUIGJlZm9yZSBzZW5kaW5nIHRoZQ0KICBuZXh0 IE1BWF9QQVlMT0FEU19TRVQgdG8gbWFuYWdlIHBvdGVudGlhbCBjb25nZXN0aW9uIGlzc3Vlcy4N CiAgSG93ZXZlciwgaWYgYSAnQ29udGludWUnIGlzIHJlY2VpdmVkIGZyb20gdGhlIHBlZXIgZm9y IHRoZSBjdXJyZW50DQogIE1BWF9QQVlMT0FEU19TRVQsIHRoZW4gdGhlIG5leHQgTUFYX1BBWUxP QURTX1NFVCBNQVkgc3RhcnQNCiAgdHJhbnNtaXNzaW9uIGltbWVkaWF0ZWx5Lg0KDQpJZiB5b3Ug d2FudCB0byBzdGljayB3aXRoIE1VU1QgSSB0aGluayB5b3UgY2FuIGNsZWFyIHVwIHRoZSBwYWlu IHdpdGggc29tZXRoaW5nIGxpa2UNCg0KTkVXOg0KICBBcyB0aGUgc2VuZGluZyBvZiBtYW55IHBh eWxvYWRzIG9mIGEgc2luZ2xlIGJvZHkgbWF5IGl0c2VsZiBjYXVzZQ0KICBjb25nZXN0aW9uLCBh ZnRlciB0cmFuc21pc3Npb24gb2YgZXZlcnkgTUFYX1BBWUxPQURTX1NFVCBvZiBhIHNpbmdsZQ0K ICBib2R5LCBhIGRlbGF5IE1VU1QgYmUgaW50cm9kdWNlZCBvZiBOT05fVElNRU9VVCBiZWZvcmUg c2VuZGluZyB0aGUNCiAgbmV4dCBNQVhfUEFZTE9BRFNfU0VUIHVubGVzcyBhICdDb250aW51ZScg aXMgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciANCiAgZm9yIHRoZSBjdXJyZW50IE1BWF9QQVlMT0FE U19TRVQsIGluIHdoaWNoIGNhc2UgdGhlIG5leHQgDQogIE1BWF9QQVlMT0FEU19TRVQgTUFZIHN0 YXJ0IHRyYW5zbWlzc2lvbiBpbW1lZGlhdGVseS4NCg0KKFRvIG15IGV5ZSBwcmVzZW50aW5nIHRo ZSBvcHRpb24gaW4gdGhpcyB3YXkgbWFrZXMgaXQgY2xlYXIgd2hlbiB0aGUgTVVTVCBkb2VzLCBh bmQgZG9lc27igJl0LCBhcHBseS4gVGhpcyBpcyBteSBwcmVmZXJyZWQgZm9ybSBidXQgSSBkb27i gJl0IGluc2lzdC4pDQoNClvigKZdDQoNCj4+IDE3LiBTZWN0aW9uIDE6DQo+PiANCj4+ICAgVGhp cyBkb2N1bWVudCBpbnRyb2R1Y2VzIHRoZSBDb0FQIFEtQmxvY2sxIGFuZCBRLUJsb2NrMiBPcHRp b25zDQo+PiB3aGljaA0KPj4gICBhbGxvdyBibG9jay13aXNlIHRyYW5zZmVyIHRvIHdvcmsgd2l0 aCBzZXJpZXMgb2YgTm9uLWNvbmZpcm1hYmxlDQo+PiAgIG1lc3NhZ2VzLCBpbnN0ZWFkIG9mIGxv Y2stc3RlcHBpbmcgdXNpbmcgQ29uZmlybWFibGUgbWVzc2FnZXMNCj4+ICAgKFNlY3Rpb24gMyku ICBJbiBvdGhlciB3b3JkcywgdGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIG1pc3NpbmcNCj4+IHBp ZWNlDQo+PiAgIG9mIFtSRkM3OTU5XSwgbmFtZWx5IHRoZSBzdXBwb3J0IG9mIGJsb2NrLXdpc2Ug dHJhbnNmZXIgdXNpbmcgTm9uLQ0KPj4gICBjb25maXJtYWJsZSB3aGVyZSBhbiBlbnRpcmUgYm9k eSBvZiBkYXRhIGNhbiBiZSB0cmFuc21pdHRlZA0KPj4gd2l0aG91dA0KPj4gICB0aGUgcmVxdWly ZW1lbnQgZm9yIGFuIGFja25vd2xlZGdlbWVudCAoYnV0IHJlY292ZXJ5IGlzIGF2YWlsYWJsZQ0K Pj4gICBzaG91bGQgaXQgYmUgbmVlZGVkKS4NCj4+IA0KPj4gQXMgZmFyIGFzIEkgY2FuIHRlbGwg dGhlIHNwZWMgZG9lcyBub3QgcmVhbGx5IHJlbW92ZSB0aGUgcmVxdWlyZW1lbnQNCj4+IGZvciBh Y2tub3dsZWRnZW1lbnQsDQo+IA0KPiBUaGVzZSBhcmUgbm90IHJlcXVpcmVkLiBUaGV5IHdlcmUg YWRkZWQgYXMgYW4gb3B0aW1pemF0aW9uIHRvIGF2b2lkIHRoZSBub24tdGltZW91dCBpZiB0aGUg cGVlciBkZWNpZGVzIHRvIHVzZSBpdC4NCg0KQXMgSSBtZW50aW9uZWQgYmVsb3cgKOKAnGF3ZnVs bHkgY2xvc2UgcGFyc2luZ+KAnSksIEkgdGhpbmsgdGhhdCBhbHRob3VnaCB5b3UgY2FuIGZpbmQg c29tZSBqdXN0aWZpY2F0aW9uIGZvciB0aGlzIHJlYWRpbmcsIGl04oCZcyBkZWJhdGFibGUuIFRy YW5zbWlzc2lvbiBvZiB0aGUgYWNrbm93bGVkZ2VtZW50IChhdCBsZWFzdCB0aGUgZmluYWwgYWNr bm93bGVkZ2VtZW50IG9mIHRoZSBlbnRpcmUgYm9keSwgaW4gdGhlIGZvcm0gb2YgYSBSZXNwb25z ZSBDb2RlKSBpcyByZXF1aXJlZCwgaXMgaXQgbm90PyBSZWNlcHRpb24gaXNu4oCZdCByZXF1aXJl ZCB0aG91Z2guIFdpdGhvdXQgdGhlIHZlcmIsIEnigJltIG5vdCBzdXJlIHdoZXRoZXIgSSBjYW4g c2F5IHdoZXRoZXIgYWNrbm93bGVkZ2VtZW50IGlzLCBvciBpc27igJl0LCByZXF1aXJlZC4NCg0K SSBkb27igJl0IGluc2lzdCB0aGF0IHlvdSBjaGFuZ2UgdGhpcywgYnV0IEkgZG8gdGhpbmsgeW91 IGNvdWxkIGltcHJvdmUgdGhlIGNsYXJpdHkgb2YgdGhlIGRvY3VtZW50LCBpZiB5b3UgZWRpdGVk IHRoZSBhYm92ZSB0byByZWFkIOKAnOKApiB3aXRob3V0IHRoZSByZXF1aXJlbWVudCB0aGF0IGFu IGFja25vd2xlZGdtZW50IGJlIHJlY2VpdmVkIGZyb20gdGhlIHBlZXIiDQoNCj4+IGl0IGp1c3Qg YW1vcnRpemVzIHRoZSBhY2tub3dsZWRnZW1lbnRzIGJ5IG9ubHkNCj4+IHNlbmRpbmcgdGhlbSBl dmVyeSBNQVhfUEFZTE9BRFNfU0VULiBSZXNwb25zZSBDb2RlIDIuMzEgaXMNCj4+IGVzc2VudGlh bGx5IGFuIGFja25vd2xlZGdlbWVudCwgYW5kIGl0IGdldHMgc2VudCB0aGF0IGZyZXF1ZW50bHks DQo+PiByaWdodD8gVGhlcmXigJlzIGFsc28gKGlmIEkgcmVjYWxsIGNvcnJlY3RseSkgc29tZSBm bGF2b3Igb2YNCj4+IGFja25vd2xlZGdlbWVudCB0aGF0IGlzIHNlbnQgd2hlbiB0aGUgZW50aXJl IGJvZHkgaGFzIGJlZW4NCj4+IHRyYW5zZmVycmVkLiBTbywgSSB0aGluayB0aGUgbmV3IHBhcmFn cmFwaCBpc27igJl0IGFjY3VyYXRlLg0KPj4gDQo+PiBUaGlzIG9ic2VydmF0aW9uIGFsc28gYXBw bGllcyB0byB0aGlzIGNsYWltZWQgYmVuZWZpdCBpbiDCpzM6DQo+PiANCj4+ICAgbyAgVGhleSBz dXBwb3J0IHNlbmRpbmcgYW4gZW50aXJlIGJvZHkgdXNpbmcgTk9OIG1lc3NhZ2VzIHdpdGhvdXQN Cj4+ICAgICAgcmVxdWlyaW5nIGFuIGludGVybWVkaWF0ZSByZXNwb25zZSBmcm9tIHRoZSBwZWVy Lg0KDQpBbmQgc2ltaWxhcmx5LCDigJzigKYgd2l0aG91dCByZXF1aXJpbmcgdGhhdCBhbiBpbnRl cm1lZGlhdGUgcmVzcG9uc2UgYmUgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlci7igJ0NCg0KW+KApl0N Cg0KPj4gMTguIFNlY3Rpb24gMjoNCj4+IA0KPj4gICBNQVhfUEFZTE9BRFNfU0VUIGlzIHRoZSBz ZXQgb2YgYmxvY2tzIGlkZW50aWZpZWQgYnkgYmxvY2sgbnVtYmVycw0KPj4gICB0aGF0LCB3aGVu IGRpdmlkZWQgYnkgTUFYX1BBWUxPQURTLCB0aGV5IGhhdmUgdGhlIHNhbWUgbnVtZXJpYw0KPj4g DQo+PiBSZW1vdmUg4oCcdGhleeKAnQ0KPiANCj4gRml4ZWQuIFRoYW5rcy4NCj4gDQo+PiANCj4+ ICAgcmVzdWx0LiAgRm9yIGV4YW1wbGUsIGlmIE1BWF9QQVlMT0FEUyBpcyBzZXQgdG8gJzEwJywg YQ0KPj4gICBNQVhfUEFZTE9BRFNfU0VUIGNvdWxkIGJlIGJsb2NrcyAjMCB0byAjOSwgIzEwIHRv ICMxOSwgZXRjLg0KPj4gICBEZXBlbmRpbmcgb24gdGhlIGRhdGEgc2l6ZSwgdGhlIE1BWF9QQVlM T0FEU19TRVQgbWF5IG5vdCBjb21wcmlzZQ0KPj4gYWxsDQo+PiAgIHRoZSBNQVhfUEFZTE9BRFMg YmxvY2tzLg0KPj4gDQo+PiBJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgbGFzdCBzZW50ZW5jZSAo IkRlcGVuZGluZyBvbiB0aGUgZGF0YSBzaXplLA0KPj4gdGhlIE1BWF9QQVlMT0FEU19TRVQgbWF5 IG5vdCBjb21wcmlzZSBhbGwgdGhlIE1BWF9QQVlMT0FEUyBibG9ja3Mu4oCdKQ0KPj4gQXJlIHlv dSB0cnlpbmcgdG8gc2F5IHRoYXQgaWYgdGhlIGJvZHkgc2l6ZSBpc27igJl0IGV2ZW5seSBkaXZp c2libGUgYnkNCj4+IE1BWF9QQVlMT0FEUyB0aGVuIHRoZSBmaW5hbCBNQVhfUEFZTE9BRFNfU0VU IHdpbGwgaGF2ZSBmZXdlciB0aGFuDQo+PiBNQVhfUEFZTE9BRFMgYmxvY2tzIGluIGl0Pw0KPiAN Cj4gV2UgbWVhbnQgdGhhdCB0aGUgbGFzdCBzZXQgbWF5IGluY2x1ZGUgZmV3ZXIgYmxvY2tzIHRo YW4gTUFYX1BBWUxPQURTLiBDaGFuZ2VkIHRvOg0KPiANCj4gIiBEZXBlbmRpbmcgb24gdGhlIG92 ZXJhbGwgZGF0YQ0KPiAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl4NCj4gICBzaXplLCB0aGUg ZmluYWwgTUFYX1BBWUxPQURTX1NFVCBtYXkgbm90IGNvbXByaXNlIGFsbCB0aGUNCj4gICAgICAg ICAgICAgXl5eXl4NCj4gICBNQVhfUEFZTE9BRFMgYmxvY2tzLiAiDQo+IA0KPiBCZXR0ZXI/DQoN CkltcHJvdmluZy4gVGhlIHdvcmQg4oCcY29tcHJpc2XigJ0gaXMgcHJvbmUgdG8gbWlzaW50ZXJw cmV0YXRpb24gaW4gbXkgZXhwZXJpZW5jZSwgSSB3b3VsZCBzdWdnZXN0IHNvbWV0aGluZyBsaWtl IOKAnOKApiB0aGVyZSBjb3VsZCBiZSBmZXdlciB0aGFuIE1BWF9QQVlMT0FEUyBibG9ja3MgaW4g dGhlIGZpbmFsIE1BWF9QQVlMT0FEU19TRVQu4oCdDQoNClRoYW5rcywNCg0K4oCUSm9obg== From nobody Fri May 21 05:42:10 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 36C113A0CB0; Fri, 21 May 2021 05:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 mY9c3WX0m4uk; Fri, 21 May 2021 05:42:03 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (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 A3E543A0CA8; Fri, 21 May 2021 05:42:02 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 4FmmT309MjzFqsJ; Fri, 21 May 2021 14:41:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1621600919; bh=fhuJk/dQsHwWg9aIg2ysiCwrAkQP+GjX74uKHzg7Z2U=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=cykoZzPGKQ6RSBhZ7Wmfl47rMvROjNpFSGK14Qbf7l8Krj6jpNmDx04hOwmMOKchb Tfz7TxywV+4OQibafleTts/iCw8SUBriGRMXxVhk53Ze95mHey32wObisqWqx2zInT v50AUktFSbBGv27Wm7Xf9y6K4fVOFxE7d6P+i4iuXSw1BHgvMYO+0LDfNuKJ35y+WX 9TeCUmWBlY6P9bx/sS2xMuY5Rc74ZX03QZwBwTl/jL/08G+kwS3Pvnx08tIPRJSyhl Oe4nMXQhl/M3N8H7lo3TiTIEc2omEu73ttClw8x08va98KlSltlBdS0di3ioHocrDL 5/Gx5wc4vXVhw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 4FmmT25lmLzCqkZ; Fri, 21 May 2021 14:41:58 +0200 (CEST) From: To: John Scudder CC: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXQhCbJLPvcFdg/UKru2kURMqcWqrXeDkAgBPx5ACAAQGlMIAAmAIAgADwZ6A= Date: Fri, 21 May 2021 12:41:57 +0000 Message-ID: <4833_1621600918_60A7AA96_4833_485_3_787AE7BB302AE849A7480A190F8B93303538C272@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net> <23771_1621516652_60A6616C_23771_79_1_787AE7BB302AE849A7480A190F8B93303538BB63@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] John Scudder's Discuss on draft-ietf-core-new-block-11: (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, 21 May 2021 12:42:08 -0000 SGkgSm9obiwNCg0KQXMgeW91IGNhbiBzZWUgaW4gaHR0cHM6Ly90aW55dXJsLmNvbS9uZXctYmxv Y2stbGF0ZXN0LCB3ZSB3ZW50IHdpdGggdGhlIGZvbGxvd2luZyBjaGFuZ2VzIHRvIGJldHRlciBh ZGRyZXNzIHlvdXIgbGF0ZXN0IGNvbW1lbnQgb24gdGhlIGppdHRlcjoNCg0KKDEpIGJlIGV4cGxp Y2l0IGFib3V0IHRoZSBmb3JtdWxhIHVzZWQgZm9yIGRlZmF1bHQgdmFsdWVzOiANCg0KT0xEOiAN CiAgIE5PTl9QUk9CSU5HX1dBSVQgaXMgdXNlZCB0byBsaW1pdCB0aGUgcG90ZW50aWFsIHdhaXQg bmVlZGVkIHdoZW4NCiAgIHVzaW5nIFBST0JJTkdfUkFURS4gIEJ5IGRlZmF1bHQsIE5PTl9QUk9C SU5HX1dBSVQgaGFzIHRoZSBzYW1lIHZhbHVlDQogICBhcyBFWENIQU5HRV9MSUZFVElNRSAoU2Vj dGlvbiA0LjguMiBvZiBbUkZDNzI1Ml0pLg0KDQogICBOT05fUEFSVElBTF9USU1FT1VUIGlzIHVz ZWQgZm9yIGV4cGlyaW5nIHBhcnRpYWxseSByZWNlaXZlZCBib2RpZXMuDQogICBCeSBkZWZhdWx0 LCBOT05fUEFSVElBTF9USU1FT1VUIGhhcyB0aGUgc2FtZSB2YWx1ZSBhcw0KICAgRVhDSEFOR0Vf TElGRVRJTUUgKFNlY3Rpb24gNC44LjIgb2YgW1JGQzcyNTJdKS4NCg0KTkVXOg0KICAgTk9OX1BS T0JJTkdfV0FJVCBpcyB1c2VkIHRvIGxpbWl0IHRoZSBwb3RlbnRpYWwgd2FpdCBuZWVkZWQgd2hl bg0KICAgdXNpbmcgUFJPQklOR19SQVRFLiAgQnkgZGVmYXVsdCwgTk9OX1BST0JJTkdfV0FJVCBp cyBjb21wdXRlZCBpbiB0aGUNCiAgIHNhbWUgd2F5IGFzIEVYQ0hBTkdFX0xJRkVUSU1FIChTZWN0 aW9uIDQuOC4yIG9mIFtSRkM3MjUyXSkgYnV0IHdpdGgNCiAgIEFDS19USU1FT1VUIGFuZCBNQVhf UkVUUkFOU01JVCBzdWJzdGl0dXRlZCB3aXRoIE5PTl9USU1FT1VUIGFuZA0KICAgTk9OX01BWF9S RVRSQU5TTUlULCByZXNwZWN0aXZlbHk6DQoNCiAgICAgIE5PTl9QUk9CSU5HX1dBSVQgPSBOT05f VElNRU9VVCAqICgoMiAqKiBOT05fTUFYX1JFVFJBTlNNSVQpIC0gMSkgKg0KICAgICAgQUNLX1JB TkRPTV9GQUNUT1IgKyAoMiAqIE1BWF9MQVRFTkNZKSArIE5PTl9USU1FT1VUDQoNCiAgIE5PTl9Q QVJUSUFMX1RJTUVPVVQgaXMgdXNlZCBmb3IgZXhwaXJpbmcgcGFydGlhbGx5IHJlY2VpdmVkIGJv ZGllcy4NCiAgIEJ5IGRlZmF1bHQsIE5PTl9QQVJUSUFMX1RJTUVPVVQgaXMgY29tcHV0ZWQgaW4g dGhlIHNhbWUgd2F5IGFzDQogICBFWENIQU5HRV9MSUZFVElNRSAoU2VjdGlvbiA0LjguMiBvZiBb UkZDNzI1Ml0pLiAgVGhpcyBkZWZhdWx0IHZhbHVlDQogICBpcyBjYWxjdWxhdGVkIGluIHRoZSBz YW1lIHdheSBhcyBOT05fUFJPQklOR19XQUlULg0KDQooMikgV2UgZG9u4oCZdCBzZWUgYSBuZWVk IHRvIGFwcGx5IGEgaml0dGVyIHdoZW4gYSB2YWx1ZSBpcyBleHBsaWNpdGx5IGNvbmZpZ3VyZWQg KHRoZXNlIGFyZSBleHBlY3RlZCB0byBiZSBsYXJnZSBudW1iZXJzLCB3ZSBkb24ndCBjYXJlIHRo YXQgbXVjaCBvbiB0aGUgaml0dGVyKS4gV2UgYWRkZWQgdGhpcyB0ZXh0IHRvIGJlIGNsZWFyIGFi b3V0IHRoZSBpbnRlbnQsIGFuZCB3aGljaCBCVFcgcmVmbGVjdHMgdGhlIGN1cnJlbnQgaW1wbGVt ZW50YXRpb246ICANCg0KTkVXOg0KICAgICAgV2hlbiBleHBsaWNpdCB2YWx1ZXMgYXJlDQogICAg ICBjb25maWd1cmVkIGZvciBOT05fUFJPQklOR19XQUlUIGFuZCBOT05fUEFSVElBTF9USU1FT1VU LCB0aGVzZQ0KICAgICAgdmFsdWVzIGFyZSB1c2VkIHdpdGhvdXQgYXBwbHlpbmcgYW55IGppdHRl ci4NCg0KV2UgYWxzbyBhZG9wdGVkIHlvdXIgcHJvcG9zZWQgZWRpdHMgaW4gdGhlIG1lc3NhZ2Ug YmVsb3cuIA0KDQpUaGFuayB5b3UgYWdhaW4gZm9yIHRoZSBjYXJlZnVsIHJldmlldy4gVGhpcyBp cyBoaWdobHkgYXBwcmVjaWF0ZWQuIA0KDQpDaGVlcnMsDQpKb2huICYgTWVkDQoNCj4gLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEpvaG4gU2N1ZGRlciBbbWFpbHRvOmpnc0Bq dW5pcGVyLm5ldF0NCj4gRW52b3nDqcKgOiB2ZW5kcmVkaSAyMSBtYWkgMjAyMSAwMDowMw0KPiDD gMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPg0KPiBDY8KgOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtY29yZS1u ZXctYmxvY2tAaWV0Zi5vcmc7DQo+IGNvcmUtY2hhaXJzQGlldGYub3JnOyBjb3JlQGlldGYub3Jn OyBtYXJjby50aWxvY2FAcmkuc2UNCj4gT2JqZXTCoDogUmU6IEpvaG4gU2N1ZGRlcidzIERpc2N1 c3Mgb24gZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay0xMToNCj4gKHdpdGggRElTQ1VTUyBhbmQg Q09NTUVOVCkNCj4gDQo+IEhpIE1vaGFtZWQsDQo+IA0KPiBJIHRoaW5rIHdlIGFyZSBjb252ZXJn aW5nLiBNeSBjb21tZW50cyBpbiBsaW5lLiBJ4oCZdmUgc25pcHBlZCBhZ3JlZWQNCj4gcG9pbnRz IGZvciBicmV2aXR5LCBpbmRpY2F0ZWQgYnkgW+KApl0uDQo+IA0KPiA+IE9uIE1heSAyMCwgMjAy MSwgYXQgOToxNyBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gDQo+ IFvigKZdDQo+IA0KPiA+Pj4+IDExLiBHZW5lcmFsDQo+ID4+Pj4NCj4gPj4+PiBCeSB0aGUgd2F5 LCBub25lIG9mIHRoZSB0aW1lcnMgc3BlY2lmeSBqaXR0ZXIgKGFuZCBpbmRlZWQsIGlmDQo+IHJl YWQNCj4gPj4+PiBsaXRlcmFsbHksIGppdHRlciB3b3VsZCBiZSBmb3JiaWRkZW4pLiBJcyB0aGlz IGludGVudGlvbmFsPw0KPiA+Pj4NCj4gPj4+IE5vICsvLSB0b2xlcmFuY2VzIGhhdmUgYmVlbiBk ZWZpbmVkLiBXaGVuIGEgdGltZXIgZXhwaXJlcywgdGhlbg0KPiB0aGUNCj4gPj4gbmV4dCBhY3Rp b24gdGFrZXMgcGxhY2UuDQo+ID4+DQo+ID4+IEkgbm90aWNlIHRoYXQgUkZDIDcyNTIgaml0dGVy cyBpdHMgdGltZXJzLCBmb3IgZXhhbXBsZToNCj4gPj4NCj4gPj4gICBjb3VudGVyLiAgRm9yIGEg bmV3IENvbmZpcm1hYmxlIG1lc3NhZ2UsIHRoZSBpbml0aWFsIHRpbWVvdXQgaXMNCj4gc2V0DQo+ ID4+ICAgdG8gYSByYW5kb20gZHVyYXRpb24gKG9mdGVuIG5vdCBhbiBpbnRlZ3JhbCBudW1iZXIg b2Ygc2Vjb25kcykNCj4gPj4gICBiZXR3ZWVuIEFDS19USU1FT1VUIGFuZCAoQUNLX1RJTUVPVVQg KiBBQ0tfUkFORE9NX0ZBQ1RPUikgKHNlZQ0KPiA+PiAgIFNlY3Rpb24gNC44KQ0KPiA+PiDigKYN Cj4gPj4gICBBQ0tfUkFORE9NX0ZBQ1RPUiBNVVNUIE5PVCBiZSBkZWNyZWFzZWQgYmVsb3cgMS4w LCBhbmQgaXQgU0hPVUxEDQo+ID4+IGhhdmUNCj4gPj4gICBhIHZhbHVlIHRoYXQgaXMgc3VmZmlj aWVudGx5IGRpZmZlcmVudCBmcm9tIDEuMCB0byBwcm92aWRlIHNvbWUNCj4gPj4gICBwcm90ZWN0 aW9uIGZyb20gc3luY2hyb25pemF0aW9uIGVmZmVjdHMuDQo+ID4+DQo+ID4+IE1BWF9UUkFOU01J VF9TUEFOIGFuZCBNQVhfVFJBTlNNSVRfV0FJVCBhcmUgc2ltaWxhcmx5IGppdHRlcmVkLiBBDQo+ ID4+IG51bWJlciBvZiB5b3VyIGludHJvZHVjZWQgcGFyYW1ldGVycw0KPiA+Pg0KPiA+PiAgIFRo aXMgZG9jdW1lbnQgaW50cm9kdWNlcyBuZXcgcGFyYW1ldGVycyBNQVhfUEFZTE9BRFMsDQo+IE5P Tl9USU1FT1VULA0KPiA+PiAgIE5PTl9SRUNFSVZFX1RJTUVPVVQsIE5PTl9NQVhfUkVUUkFOU01J VCwgTk9OX1BST0JJTkdfV0FJVCwgYW5kDQo+ID4+ICAgTk9OX1BBUlRJQUxfVElNRU9VVCBwcmlt YXJpbHkgZm9yIHVzZSB3aXRoIE5PTiAoVGFibGUgMykuDQo+ID4+DQo+ID4+IGFwcGVhciBhdCBs ZWFzdCBzdXBlcmZpY2lhbGx5IHNpbWlsYXIgdG8gdGhlIHRpbWVycyB0aGUgYXV0aG9ycyBvZg0K PiA+PiBSRkMgNzI1MiBkZWVtZWQgaW1wb3J0YW50IHRvIGppdHRlciB0byBwcmV2ZW50IHN5bmNo cm9uaXphdGlvbg0KPiA+PiBlZmZlY3RzLiBEaWQgeW91IHNwZWNpZmljYWxseSBjb25zaWRlciBq aXR0ZXJpbmcgdGhlbSwgYW5kIGRlY2lkZQ0KPiA+PiB0aGF0IGppdHRlciB3YXMgdW5uZWNlc3Nh cnk/IElmIHNvLCBjYW4geW91IGV4cGxhaW4gd2hhdCBpcw0KPiBkaWZmZXJlbnQNCj4gPj4gYWJv dXQgeW91ciBzcGVjaWZpY2F0aW9uLCBjb21wYXJlZCB0byB0aGUgYmFzZSBzcGVjLCB0aGF0DQo+ IGVsaW1pbmF0ZXMNCj4gPj4gdGhlIGNvbmNlcm4/DQo+ID4NCj4gPiBSRkM3MjUyIGludHJvZHVj ZXMgQUNLX1JBTkRPTV9GQUNUT1Igaml0dGVyIGFuZCBzZXBhcmF0ZWx5IGppdHRlcg0KPiBmb3Ig bXVsdGljYXN0IHJlc3BvbnNlcyAod2hpY2ggaXMgbm90IHJlbGV2YW50IGhlcmUpLg0KPiA+DQo+ ID4gVGhlIEFDS19SQU5ET01fRkFDVE9SIGlzIHRoZXJlIGZvciB3aGVuIHJlLXRyYW5zbWl0dGlu ZyBhIHBhY2tldA0KPiB0aGF0IGhhcyBub3QgYmVlbiBhY2tub3dsZWRnZWQgZm9yIHNvbWUgcmVh c29uIGJ5IGl0cyBwZWVyLg0KPiBOT05fVElNRU9VVCBpcyBmb3Igd2hlbiB0aGUgbmV4dCBNQVhf UEFZTE9BRFNfU0VUIGNhbiBzdGFydA0KPiB0cmFuc21pc3Npb24gKG5vdCByZS10cmFuc21pc3Np b24pIGFzc3VtaW5nIGEgJ0NvbnRpbnVlJyBoYXMgbm90DQo+IGFycml2ZWQgaW4gdGhlIGludGVy aW0sIGFuZCBzbyB3YXMgbm90IHRob3VnaHQgbmVjZXNzYXJ5IHRvIGFkZCBpbg0KPiBBQ0tfUkFO RE9NX0ZBQ1RPUiBzdHlsZSBqaXR0ZXIgaGVyZS4NCj4gPg0KPiA+IEZvciBOT05fUkVDRUlWRV9U SU1FT1VULCB3aGF0IGlzIGltcG9ydGFudCBpcyB0aGF0DQo+IE5PTl9SRUNFSVZFX1RJTUVPVVQg aXMgZ3JlYXRlciB0aGFuIE5PTl9USU1FT1VUIChXZSBzYXkgaW4gdGhlIHNwZWMgYQ0KPiBtaW5p bXVtIG9mIG9uZSBzZWNvbmQpIHNvIHRoYXQgYSBwZWVyIGRvZXMgbm90IGZpcmUgb2ZmIGEgcmUt DQo+IHRyYW5zbWlzc2lvbiByZXF1ZXN0IGJlZm9yZSB0aGUgbG9jYWwgYWdlbnQgaGFzIGEgY2hh bmNlIHRvIHN0YXJ0IHRvDQo+IHRyYW5zbWl0IHRoZSBuZXh0IE1BWF9QQVlMT0FEU19TRVQuICBO T05fUkVDRUlWRV9USU1FT1VUIGlzDQo+IGV4cG9uZW50aWFsbHkgc2NhbGVkIGZvciBlYWNoIHJl dHJ5IHRvIG1ha2Ugc3VyZSB0aGF0IHN0YWJpbGl0eSBpcw0KPiBwcmVzZXJ2ZWQuIFNvLCBhZ2Fp biwgQUNLX1JBTkRPTV9GQUNUT1Igaml0dGVyIHdhcyBub3QgdGhvdWdodCB0byBiZQ0KPiBuZWNl c3NhcnkgaGVyZS4NCj4gPg0KPiA+IE5PTl9NQVhfUkVUUkFOU01JVCBpcyBhIGZpeGVkIGNvdW50 Lg0KPiA+DQo+ID4gTk9OX1BST0JJTkdfV0FJVCBpcyB1c2VkIHRvIHB1dCBhIGxpbWl0IG9uIHRo ZSBwb3RlbnRpYWwgZGVsYXkgdGhhdA0KPiBjb3VsZCBpbmN1ciB3aGVuIG9iZXlpbmcgUFJPQklO R19XQUlUIHdoZW4gdGhlcmUgaXMgbm8gcGVlciByZXNwb25zZS4NCj4gSWYgdGhlIGltcGxlbWVu dGF0aW9uIGdvZXMgd2l0aCB0aGUgZGVmYXVsdCBFWENIQU5HRV9MSUZFVElNRQ0KPiBjb21wdXRh dGlvbiwgdGhlbiBOT05fUFJPQklOR19XQUlUIGluY2x1ZGVzIEFDS19SQU5ET01fRkFDVE9SIGlu IHRoZQ0KPiBtYXRoLg0KPiA+DQo+ID4gTk9OX1BBUlRJQUxfVElNRU9VVCBpZiBjb21wdXRlZCB1 c2luZyB0aGUgZGVmYXVsdCBFWENIQU5HRV9MSUZFVElNRQ0KPiBpbmNsdWRlcyBBQ0tfUkFORE9N X0ZBQ1RPUi4NCj4gDQo+IFRoYW5rcyBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIGV4cGxhaW4uIFlv dSBkb27igJl0IGNvbW1lbnQgcmVnYXJkaW5nDQo+IHdoZXRoZXIgTk9OX1BST0JJTkdfV0FJVCBh bmQgTk9OX1BBUlRJQUxfVElNRU9VVCBzaG91bGQgYmUgaml0dGVyZWQNCj4gb3Igbm90LCB5b3Ug anVzdCBleHBsYWluIHRoYXQgaWYgdGhleSB1c2UgdGhlIGRlZmF1bHQgdGhleSBnZXQgaml0dGVy DQo+IOKAnGZvciBmcmVl4oCdLiBUaGUgbWlzc2luZyBkZXRhaWwgaXMgdGhhdCBpZiB0aGV5IGRv buKAmXQgdXNlIHRoZSBkZWZhdWx0DQo+IHRoZXkgZG9u4oCZdCBnZXQgaml0dGVyZWQsIHNvIEkg dGhpbmsgc29tZSBjb25zaWRlcmF0aW9uIGlzIHN0aWxsDQo+IGNhbGxlZCBmb3IgcmVnYXJkaW5n IHdoZXRoZXIgaGF2aW5nIHRoZW0gbm90IGJlIGppdHRlcmVkIGlzIE9LLg0KPiANCj4gW+KApl0N Cj4gDQo+ID4+Pj4gMTUuIFNlY3Rpb24gMTAuMi4zDQo+IA0KPiBb4oCmXQ0KPiANCj4gPj4gT25l IGNvbmNlcm4gcmVsYXRlZCB0byB0aGF0OiB3YWl0aW5nIE5PTl9USU1FT1VUIGlzbuKAmXQgYWN0 dWFsbHkNCj4gPj4gcmVxdWlyZWQsIGl04oCZcyBvbmx5IFJFQ09NTUVOREVELCB0aGVyZWZvcmUg dGhpcyBpc27igJl0IGFjdHVhbGx5IGENCj4gPj4gZ3VhcmFudGVlLiBGcm9tIMKnNy4yOg0KPiA+ Pg0KPiA+PiAgIEFzIHRoZSBzZW5kaW5nIG9mIG1hbnkgcGF5bG9hZHMgb2YgYSBzaW5nbGUgYm9k eSBtYXkgaXRzZWxmDQo+IGNhdXNlDQo+ID4+ICAgY29uZ2VzdGlvbiwgaXQgaXMgUkVDT01NRU5E RUQgdGhhdCBhZnRlciB0cmFuc21pc3Npb24gb2YgZXZlcnkNCj4gPj4gICBNQVhfUEFZTE9BRFNf U0VUIG9mIGEgc2luZ2xlIGJvZHksIGEgZGVsYXkgaXMgaW50cm9kdWNlZCBvZg0KPiA+PiAgIE5P Tl9USU1FT1VUIGJlZm9yZSBzZW5kaW5nIHRoZSBuZXh0IE1BWF9QQVlMT0FEU19TRVQgdG8gbWFu YWdlDQo+ID4+ICAgcG90ZW50aWFsIGNvbmdlc3Rpb24gaXNzdWVzLg0KPiA+Pg0KPiA+PiBJIGFt IGN1cmlvdXMgd2h5IHlvdSBtYWRlIHRoaXMgYSBSRUNPTU1FTkRFRCBpbnN0ZWFkIG9mIGEgTVVT VC4gSW4NCj4gYQ0KPiA+PiBzaXR1YXRpb24gbGlrZSB0aGlzIGl0IHdvdWxkIGJlIHByZWZlcmFi bGUgZm9yIHlvdSB0byBleHBsYWluIHRvDQo+IHRoZQ0KPiA+PiBpbXBsZW1lbnRvciB3aGF0IHNp dHVhdGlvbiB0aGV5IGNhbiBpZ25vcmUgdGhlIFJFQ09NTUVOREVEIGluIGFuZA0KPiA+PiB3aGF0 IHRoZXkgc2hvdWxkIGRvIGluc3RlYWQsIG9yIG9mIGNvdXJzZSB0byBtYWtlIGl0IGludG8gYSBN VVNULg0KPiA+DQo+ID4gQmVjYXVzZSBhIGNvbnRpbnVlIHNpZ25hbCBtYXkgYmUgcmVjZWl2ZWQg ZnJvbSB0aGUgcGVlciBhbmQgdGhlbg0KPiBjb250aW51ZSB3aXRob3V0IHdhaXRpbmcgZm9yIHRo ZSB0aW1lb3V0IHRvIGV4cGlyZS4NCj4gPg0KPiA+IFRoaXMgaXMgdG8gYmUgbGlua2VkIHdpdGgg dGhpcyB0ZXh0Og0KPiA+DQo+ID4gICAgICBBIHJlc3BvbnNlIHVzaW5nIHRoaXMgUmVzcG9uc2Ug Q29kZSBTSE9VTEQgTk9UIGJlIGdlbmVyYXRlZA0KPiBmb3INCj4gPiAgICAgIGV2ZXJ5IHJlY2Vp dmVkIFEtQmxvY2sxIE9wdGlvbiByZXF1ZXN0IChTZWN0aW9uIDcuMikuICBJdA0KPiBTSE9VTEQN Cj4gPiAgICAgIG9ubHkgYmUgZ2VuZXJhdGVkIHdoZW4gYWxsIHRoZSBwYXlsb2FkIHJlcXVlc3Rz IGFyZSBOb24tDQo+ID4gICAgICBjb25maXJtYWJsZSBhbmQgYSBNQVhfUEFZTE9BRFNfU0VUIGhh cyBiZWVuIHJlY2VpdmVkIGJ5IHRoZQ0KPiA+ICAgICAgIHNlcnZlci4gIE1vcmUgZGV0YWlscyBh Ym91dCB0aGUgbW90aXZhdGlvbnMgZm9yIHRoaXMNCj4gb3B0aW1pemF0aW9uDQo+ID4NCj4gXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCj4g PiAgICAgIGFyZSBkaXNjdXNzZWQgaW4gU2VjdGlvbiA3LjIuDQo+ID4gICAgICBeXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eDQo+ID4NCj4gPiBXZSBjb3VsZCB1c2UgKipNVVNUIHVubGVzcyBh ICdDb250aW51ZScgaXMgcmVjZWl2ZWQqKiwgZS5nLiwNCj4gPg0KPiA+IE9MRDoNCj4gPiAgIEFz IHRoZSBzZW5kaW5nIG9mIG1hbnkgcGF5bG9hZHMgb2YgYSBzaW5nbGUgYm9keSBtYXkgaXRzZWxm IGNhdXNlDQo+ID4gICBjb25nZXN0aW9uLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGFmdGVyIHRy YW5zbWlzc2lvbiBvZiBldmVyeQ0KPiA+ICAgTUFYX1BBWUxPQURTX1NFVCBvZiBhIHNpbmdsZSBi b2R5LCBhIGRlbGF5IGlzIGludHJvZHVjZWQgb2YNCj4gPiAgIE5PTl9USU1FT1VUIGJlZm9yZSBz ZW5kaW5nIHRoZSBuZXh0IE1BWF9QQVlMT0FEU19TRVQgdG8gbWFuYWdlDQo+ID4gICBwb3RlbnRp YWwgY29uZ2VzdGlvbiBpc3N1ZXMuDQo+ID4NCj4gPiBORVc6DQo+ID4gICBBcyB0aGUgc2VuZGlu ZyBvZiBtYW55IHBheWxvYWRzIG9mIGEgc2luZ2xlIGJvZHkgbWF5IGl0c2VsZiBjYXVzZQ0KPiA+ ICAgY29uZ2VzdGlvbiwgYWZ0ZXIgdHJhbnNtaXNzaW9uIG9mIGV2ZXJ5IE1BWF9QQVlMT0FEU19T RVQgb2YgYQ0KPiBzaW5nbGUNCj4gPiAgIGJvZHksIGEgZGVsYXkgTVVTVCBiZSBpbnRyb2R1Y2Vk IG9mIE5PTl9USU1FT1VUIGJlZm9yZSBzZW5kaW5nDQo+IHRoZQ0KPiA+ICAgbmV4dCBNQVhfUEFZ TE9BRFNfU0VUIHRvIG1hbmFnZSBwb3RlbnRpYWwgY29uZ2VzdGlvbiBpc3N1ZXMuDQo+ID4gICBI b3dldmVyLCBpZiBhICdDb250aW51ZScgaXMgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBmb3IgdGhl DQo+IGN1cnJlbnQNCj4gPiAgIE1BWF9QQVlMT0FEU19TRVQsIHRoZW4gdGhlIG5leHQgTUFYX1BB WUxPQURTX1NFVCBjYW4gc3RhcnQNCj4gPiAgIHRyYW5zbWlzc2lvbiBpbW1lZGlhdGVseS4NCj4g Pg0KPiA+IC4uLiBidXQgSSBrbm93IHRoYXQgbWFueSB3b3VsZCBhcmd1ZSB0aGlzIGlzIGEgU0hP VUxELg0KPiANCj4gSSB3b3VsZCBiZSBPSyB3aXRoIGVpdGhlciB5b3VyIHByb3Bvc2VkIG5ldyB0 ZXh0LCBvciBhIFNIT1VMRC9NQVkNCj4gcGFpciBhcyBpbg0KPiANCj4gTkVXOg0KPiAgIEFzIHRo ZSBzZW5kaW5nIG9mIG1hbnkgcGF5bG9hZHMgb2YgYSBzaW5nbGUgYm9keSBtYXkgaXRzZWxmIGNh dXNlDQo+ICAgY29uZ2VzdGlvbiwgYWZ0ZXIgdHJhbnNtaXNzaW9uIG9mIGV2ZXJ5IE1BWF9QQVlM T0FEU19TRVQgb2YgYQ0KPiBzaW5nbGUNCj4gICBib2R5LCBhIGRlbGF5IFNIT1VMRCBiZSBpbnRy b2R1Y2VkIG9mIE5PTl9USU1FT1VUIGJlZm9yZSBzZW5kaW5nDQo+IHRoZQ0KPiAgIG5leHQgTUFY X1BBWUxPQURTX1NFVCB0byBtYW5hZ2UgcG90ZW50aWFsIGNvbmdlc3Rpb24gaXNzdWVzLg0KPiAg IEhvd2V2ZXIsIGlmIGEgJ0NvbnRpbnVlJyBpcyByZWNlaXZlZCBmcm9tIHRoZSBwZWVyIGZvciB0 aGUgY3VycmVudA0KPiAgIE1BWF9QQVlMT0FEU19TRVQsIHRoZW4gdGhlIG5leHQgTUFYX1BBWUxP QURTX1NFVCBNQVkgc3RhcnQNCj4gICB0cmFuc21pc3Npb24gaW1tZWRpYXRlbHkuDQo+IA0KPiBJ ZiB5b3Ugd2FudCB0byBzdGljayB3aXRoIE1VU1QgSSB0aGluayB5b3UgY2FuIGNsZWFyIHVwIHRo ZSBwYWluIHdpdGgNCj4gc29tZXRoaW5nIGxpa2UNCj4gDQo+IE5FVzoNCj4gICBBcyB0aGUgc2Vu ZGluZyBvZiBtYW55IHBheWxvYWRzIG9mIGEgc2luZ2xlIGJvZHkgbWF5IGl0c2VsZiBjYXVzZQ0K PiAgIGNvbmdlc3Rpb24sIGFmdGVyIHRyYW5zbWlzc2lvbiBvZiBldmVyeSBNQVhfUEFZTE9BRFNf U0VUIG9mIGENCj4gc2luZ2xlDQo+ICAgYm9keSwgYSBkZWxheSBNVVNUIGJlIGludHJvZHVjZWQg b2YgTk9OX1RJTUVPVVQgYmVmb3JlIHNlbmRpbmcgdGhlDQo+ICAgbmV4dCBNQVhfUEFZTE9BRFNf U0VUIHVubGVzcyBhICdDb250aW51ZScgaXMgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlcg0KPiAgIGZv ciB0aGUgY3VycmVudCBNQVhfUEFZTE9BRFNfU0VULCBpbiB3aGljaCBjYXNlIHRoZSBuZXh0DQo+ ICAgTUFYX1BBWUxPQURTX1NFVCBNQVkgc3RhcnQgdHJhbnNtaXNzaW9uIGltbWVkaWF0ZWx5Lg0K PiANCj4gKFRvIG15IGV5ZSBwcmVzZW50aW5nIHRoZSBvcHRpb24gaW4gdGhpcyB3YXkgbWFrZXMg aXQgY2xlYXIgd2hlbiB0aGUNCj4gTVVTVCBkb2VzLCBhbmQgZG9lc27igJl0LCBhcHBseS4gVGhp cyBpcyBteSBwcmVmZXJyZWQgZm9ybSBidXQgSSBkb27igJl0DQo+IGluc2lzdC4pDQo+IA0KPiBb 4oCmXQ0KPiANCj4gPj4gMTcuIFNlY3Rpb24gMToNCj4gPj4NCj4gPj4gICBUaGlzIGRvY3VtZW50 IGludHJvZHVjZXMgdGhlIENvQVAgUS1CbG9jazEgYW5kIFEtQmxvY2syIE9wdGlvbnMNCj4gPj4g d2hpY2gNCj4gPj4gICBhbGxvdyBibG9jay13aXNlIHRyYW5zZmVyIHRvIHdvcmsgd2l0aCBzZXJp ZXMgb2YgTm9uLWNvbmZpcm1hYmxlDQo+ID4+ICAgbWVzc2FnZXMsIGluc3RlYWQgb2YgbG9jay1z dGVwcGluZyB1c2luZyBDb25maXJtYWJsZSBtZXNzYWdlcw0KPiA+PiAgIChTZWN0aW9uIDMpLiAg SW4gb3RoZXIgd29yZHMsIHRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBtaXNzaW5nDQo+ID4+IHBp ZWNlDQo+ID4+ICAgb2YgW1JGQzc5NTldLCBuYW1lbHkgdGhlIHN1cHBvcnQgb2YgYmxvY2std2lz ZSB0cmFuc2ZlciB1c2luZw0KPiBOb24tDQo+ID4+ICAgY29uZmlybWFibGUgd2hlcmUgYW4gZW50 aXJlIGJvZHkgb2YgZGF0YSBjYW4gYmUgdHJhbnNtaXR0ZWQNCj4gd2l0aG91dA0KPiA+PiAgIHRo ZSByZXF1aXJlbWVudCBmb3IgYW4gYWNrbm93bGVkZ2VtZW50IChidXQgcmVjb3ZlcnkgaXMNCj4g YXZhaWxhYmxlDQo+ID4+ICAgc2hvdWxkIGl0IGJlIG5lZWRlZCkuDQo+ID4+DQo+ID4+IEFzIGZh ciBhcyBJIGNhbiB0ZWxsIHRoZSBzcGVjIGRvZXMgbm90IHJlYWxseSByZW1vdmUgdGhlDQo+IHJl cXVpcmVtZW50DQo+ID4+IGZvciBhY2tub3dsZWRnZW1lbnQsDQo+ID4NCj4gPiBUaGVzZSBhcmUg bm90IHJlcXVpcmVkLiBUaGV5IHdlcmUgYWRkZWQgYXMgYW4gb3B0aW1pemF0aW9uIHRvIGF2b2lk DQo+IHRoZSBub24tdGltZW91dCBpZiB0aGUgcGVlciBkZWNpZGVzIHRvIHVzZSBpdC4NCj4gDQo+ IEFzIEkgbWVudGlvbmVkIGJlbG93ICjigJxhd2Z1bGx5IGNsb3NlIHBhcnNpbmfigJ0pLCBJIHRo aW5rIHRoYXQgYWx0aG91Z2gNCj4geW91IGNhbiBmaW5kIHNvbWUganVzdGlmaWNhdGlvbiBmb3Ig dGhpcyByZWFkaW5nLCBpdOKAmXMgZGViYXRhYmxlLg0KPiBUcmFuc21pc3Npb24gb2YgdGhlIGFj a25vd2xlZGdlbWVudCAoYXQgbGVhc3QgdGhlIGZpbmFsDQo+IGFja25vd2xlZGdlbWVudCBvZiB0 aGUgZW50aXJlIGJvZHksIGluIHRoZSBmb3JtIG9mIGEgUmVzcG9uc2UgQ29kZSkNCj4gaXMgcmVx dWlyZWQsIGlzIGl0IG5vdD8gUmVjZXB0aW9uIGlzbuKAmXQgcmVxdWlyZWQgdGhvdWdoLiBXaXRo b3V0IHRoZQ0KPiB2ZXJiLCBJ4oCZbSBub3Qgc3VyZSB3aGV0aGVyIEkgY2FuIHNheSB3aGV0aGVy IGFja25vd2xlZGdlbWVudCBpcywgb3INCj4gaXNu4oCZdCwgcmVxdWlyZWQuDQo+IA0KPiBJIGRv buKAmXQgaW5zaXN0IHRoYXQgeW91IGNoYW5nZSB0aGlzLCBidXQgSSBkbyB0aGluayB5b3UgY291 bGQgaW1wcm92ZQ0KPiB0aGUgY2xhcml0eSBvZiB0aGUgZG9jdW1lbnQsIGlmIHlvdSBlZGl0ZWQg dGhlIGFib3ZlIHRvIHJlYWQg4oCc4oCmDQo+IHdpdGhvdXQgdGhlIHJlcXVpcmVtZW50IHRoYXQg YW4gYWNrbm93bGVkZ21lbnQgYmUgcmVjZWl2ZWQgZnJvbSB0aGUNCj4gcGVlciINCj4gDQo+ID4+ IGl0IGp1c3QgYW1vcnRpemVzIHRoZSBhY2tub3dsZWRnZW1lbnRzIGJ5IG9ubHkgc2VuZGluZyB0 aGVtIGV2ZXJ5DQo+ID4+IE1BWF9QQVlMT0FEU19TRVQuIFJlc3BvbnNlIENvZGUgMi4zMSBpcyBl c3NlbnRpYWxseSBhbg0KPiA+PiBhY2tub3dsZWRnZW1lbnQsIGFuZCBpdCBnZXRzIHNlbnQgdGhh dCBmcmVxdWVudGx5LCByaWdodD8gVGhlcmXigJlzDQo+ID4+IGFsc28gKGlmIEkgcmVjYWxsIGNv cnJlY3RseSkgc29tZSBmbGF2b3Igb2YgYWNrbm93bGVkZ2VtZW50IHRoYXQNCj4gaXMNCj4gPj4g c2VudCB3aGVuIHRoZSBlbnRpcmUgYm9keSBoYXMgYmVlbiB0cmFuc2ZlcnJlZC4gU28sIEkgdGhp bmsgdGhlDQo+IG5ldw0KPiA+PiBwYXJhZ3JhcGggaXNu4oCZdCBhY2N1cmF0ZS4NCj4gPj4NCj4g Pj4gVGhpcyBvYnNlcnZhdGlvbiBhbHNvIGFwcGxpZXMgdG8gdGhpcyBjbGFpbWVkIGJlbmVmaXQg aW4gwqczOg0KPiA+Pg0KPiA+PiAgIG8gIFRoZXkgc3VwcG9ydCBzZW5kaW5nIGFuIGVudGlyZSBi b2R5IHVzaW5nIE5PTiBtZXNzYWdlcw0KPiB3aXRob3V0DQo+ID4+ICAgICAgcmVxdWlyaW5nIGFu IGludGVybWVkaWF0ZSByZXNwb25zZSBmcm9tIHRoZSBwZWVyLg0KPiANCj4gQW5kIHNpbWlsYXJs eSwg4oCc4oCmIHdpdGhvdXQgcmVxdWlyaW5nIHRoYXQgYW4gaW50ZXJtZWRpYXRlIHJlc3BvbnNl IGJlDQo+IHJlY2VpdmVkIGZyb20gdGhlIHBlZXIu4oCdDQo+IA0KPiBb4oCmXQ0KPiANCj4gPj4g MTguIFNlY3Rpb24gMjoNCj4gPj4NCj4gPj4gICBNQVhfUEFZTE9BRFNfU0VUIGlzIHRoZSBzZXQg b2YgYmxvY2tzIGlkZW50aWZpZWQgYnkgYmxvY2sNCj4gbnVtYmVycw0KPiA+PiAgIHRoYXQsIHdo ZW4gZGl2aWRlZCBieSBNQVhfUEFZTE9BRFMsIHRoZXkgaGF2ZSB0aGUgc2FtZSBudW1lcmljDQo+ ID4+DQo+ID4+IFJlbW92ZSDigJx0aGV54oCdDQo+ID4NCj4gPiBGaXhlZC4gVGhhbmtzLg0KPiA+ DQo+ID4+DQo+ID4+ICAgcmVzdWx0LiAgRm9yIGV4YW1wbGUsIGlmIE1BWF9QQVlMT0FEUyBpcyBz ZXQgdG8gJzEwJywgYQ0KPiA+PiAgIE1BWF9QQVlMT0FEU19TRVQgY291bGQgYmUgYmxvY2tzICMw IHRvICM5LCAjMTAgdG8gIzE5LCBldGMuDQo+ID4+ICAgRGVwZW5kaW5nIG9uIHRoZSBkYXRhIHNp emUsIHRoZSBNQVhfUEFZTE9BRFNfU0VUIG1heSBub3QNCj4gY29tcHJpc2UNCj4gPj4gYWxsDQo+ ID4+ICAgdGhlIE1BWF9QQVlMT0FEUyBibG9ja3MuDQo+ID4+DQo+ID4+IEkgZG9u4oCZdCB1bmRl cnN0YW5kIHRoZSBsYXN0IHNlbnRlbmNlICgiRGVwZW5kaW5nIG9uIHRoZSBkYXRhIHNpemUsDQo+ ID4+IHRoZSBNQVhfUEFZTE9BRFNfU0VUIG1heSBub3QgY29tcHJpc2UgYWxsIHRoZSBNQVhfUEFZ TE9BRFMNCj4gYmxvY2tzLuKAnSkNCj4gPj4gQXJlIHlvdSB0cnlpbmcgdG8gc2F5IHRoYXQgaWYg dGhlIGJvZHkgc2l6ZSBpc27igJl0IGV2ZW5seSBkaXZpc2libGUNCj4gYnkNCj4gPj4gTUFYX1BB WUxPQURTIHRoZW4gdGhlIGZpbmFsIE1BWF9QQVlMT0FEU19TRVQgd2lsbCBoYXZlIGZld2VyIHRo YW4NCj4gPj4gTUFYX1BBWUxPQURTIGJsb2NrcyBpbiBpdD8NCj4gPg0KPiA+IFdlIG1lYW50IHRo YXQgdGhlIGxhc3Qgc2V0IG1heSBpbmNsdWRlIGZld2VyIGJsb2NrcyB0aGFuDQo+IE1BWF9QQVlM T0FEUy4gQ2hhbmdlZCB0bzoNCj4gPg0KPiA+ICIgRGVwZW5kaW5nIG9uIHRoZSBvdmVyYWxsIGRh dGENCj4gPiAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl4NCj4gPiAgIHNpemUsIHRoZSBmaW5h bCBNQVhfUEFZTE9BRFNfU0VUIG1heSBub3QgY29tcHJpc2UgYWxsIHRoZQ0KPiA+ICAgICAgICAg ICAgIF5eXl5eDQo+ID4gICBNQVhfUEFZTE9BRFMgYmxvY2tzLiAiDQo+ID4NCj4gPiBCZXR0ZXI/ DQo+IA0KPiBJbXByb3ZpbmcuIFRoZSB3b3JkIOKAnGNvbXByaXNl4oCdIGlzIHByb25lIHRvIG1p c2ludGVycHJldGF0aW9uIGluIG15DQo+IGV4cGVyaWVuY2UsIEkgd291bGQgc3VnZ2VzdCBzb21l dGhpbmcgbGlrZSDigJzigKYgdGhlcmUgY291bGQgYmUgZmV3ZXINCj4gdGhhbiBNQVhfUEFZTE9B RFMgYmxvY2tzIGluIHRoZSBmaW5hbCBNQVhfUEFZTE9BRFNfU0VULuKAnQ0KPiANCj4gVGhhbmtz LA0KPiANCj4g4oCUSm9obg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVz ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Fri May 21 09:17: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 13D363A132E; Fri, 21 May 2021 09:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=wPG1dgD5; dkim=pass (1024-bit key) header.d=juniper.net header.b=ST1Mb930 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qu7CxHGjnoNr; Fri, 21 May 2021 09:16:51 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4DC3A1661; Fri, 21 May 2021 09:16:51 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14LGCbsT019757; Fri, 21 May 2021 09:16:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=aRM3caPXg6dCBUQ3y1UUsbb2uqW2EV7dxt2uGtsxdo8=; b=wPG1dgD5t3u8U6afOF+a+iUySKHlJ1vi3P/VEXjntSTylF6lBlk1CGdUZFH2XSHvVyzK jYoUUTGODKldpHAdlYpf2yEcnaVUeNfzEZ+/i6/Q7MEbrMWFDmXYeMYWiQlUb6bdPUkC oRE3Lb3YpkerIjc2SMfGBKFCY9gLxC7LlfODcyIpJHhdEH/gaPRamjdIH1rOyjd2UT3K /92a6Grf59NBhLJHli27cw3IAu0XFAJli3fMcmF61VvbmZFR0lGfu3GeNrDEP6CUl9Si 9fjPqVsKhF5I235z9lD9ch0P6MQ29bPDheThU7O2pFLQKTN+TgusY0k+Emq1AHiU/gHi cw== Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2043.outbound.protection.outlook.com [104.47.66.43]) by mx0a-00273201.pphosted.com with ESMTP id 38nyus1e5c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 May 2021 09:16:50 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CgSYldYdlixJVKQGQgqFAGcNcBLq4EZ1+8MU9PSnHwyax1bwxC/mFYSFJicrli0E5OYmAJEf2MI1RA4nFwYOshe8Iv5XpFH8nVmKiXTG5rb3PtxbJXSmSMztvgFBxUb2XzR+79qZGS8LxOxEJ+o8onhXEM+hWJcmDCKrIAHpmBAxLR13WVTOqLZipM5JePYx3yifzY1VSci65hv4dnd/t3RbgguksOcyt6Tdjx4WwLrXL4+vrB2dbTNsucPTonP4WWtBnpkWtYjb03lD0zYTT6c9PuUM3hWtU+c4MuRxd3VfyIf1SJKiz1n6p6Ost5G+s7Mw7YRlz35AKPHS4nAI3Q== 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=aRM3caPXg6dCBUQ3y1UUsbb2uqW2EV7dxt2uGtsxdo8=; b=eRP+kz5dI42sWXxXdUleREYZtGJ85+vCIUzm7AnKaVAN4oGTX0P35p9vtQHfXBqAJ1YKZapjrEBc7jq9EhyrVWlBzAR7W1zOwLUtAR9uXmea4I65JvuLTXE3caLI4KE/rS44LEkt3TV4WPxLcq5gjeXMO3nmVQaiHtgb1L1zrWW5Ld9rn+c/IdchXYWxR9rQoIxi0zWCQw03P0QenF5A13lfEGHsp1EU5l2YjDhHF5bvduiSTBFBeQruJQeTJU+jlspmfyytQLngJA67Ypat11vbbjTfHHCsN3sJKLLBwMFWuiKKnCYw/v9AFY7Msl2t3bPzMRCRnvLFj4aCLTSSBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aRM3caPXg6dCBUQ3y1UUsbb2uqW2EV7dxt2uGtsxdo8=; b=ST1Mb930KCR73irGs5t+EQCTYqhJlfTUhh+IvbcrZUG6imypQpDROiSTa1bCofviwTKqJJgEOpIwz0sOnNKgnaUAJ4g9bw6dyHIGh1CysowBoMVijszsmfXWzHwmNFU/ChVzWTYj3mb4LU3DsiiCCor1svwbgdPviWdr+6D8Rro= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6174.namprd05.prod.outlook.com (2603:10b6:208:c2::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.11; Fri, 21 May 2021 16:16:47 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::3020:ac3:590d:83f1]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::3020:ac3:590d:83f1%5]) with mapi id 15.20.4173.013; Fri, 21 May 2021 16:16:47 +0000 From: John Scudder To: "mohamed.boucadair@orange.com" CC: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXQhCbJLPvcFdg/UKru2kURMqcWqrXeDkAgBPx5ACAAQGlMIAAmAIAgADwZ6CAAEEXAA== Date: Fri, 21 May 2021 16:16:47 +0000 Message-ID: <36A5A92C-AD99-4554-8A09-4E76E60BA98A@juniper.net> References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net> <23771_1621516652_60A6616C_23771_79_1_787AE7BB302AE849A7480A190F8B93303538BB63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4833_1621600918_60A7AA96_4833_485_3_787AE7BB302AE849A7480A190F8B93303538C272@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <4833_1621600918_60A7AA96_4833_485_3_787AE7BB302AE849A7480A190F8B93303538C272@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.6) authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [162.225.191.192] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f530887-c709-4515-42b5-08d91c73d53b x-ms-traffictypediagnostic: MN2PR05MB6174: 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: W9XP8jHdH9kZN//egRsDKgAMhssBMG1u+DXyWwhF6W2YXUoHCfGwhOWv2IwS+sN5SNTYJOBi+EJvx7KoVa+IzTSGt0+oxQYpV7vS2/e18JLCaF+nylx5Xxe0JjfwWaZag4NSjPdbqawGYdbNdkRclEbKzNnmtT2XKhSJMgCJHgAXGCjdwmf6R25Gg3fDX7UAUIvMU4jc53fkyqNz+W+ENxd1cKYLuU75ICpT3lBtz8/eXRxHWFZyDJUDGQ2SfyKFGIfOMbXnMMdpU4eHgQ34XdwLXpFtsdpDCaLLqQyr346Qj12wIIR5Na49s0X+th9nnHWsDGC+hWP/860/YoRiOe1pFgpsmBbMIHG5Q5wSWcehRPyqxU4glc3JF8eXEtyf2wLK84CXEkVt5VCO9YFJGKsN2p0LJg+aRy6POd70ZRvSK83gKaggYPgALl+0zDZjKWqctOcqg2tuPCgbBP0BI+1A+U/bYUcWoA38BIx5pZe7oCChroz5BGPfcJFNocPgNf37a6Npdfg7GWUIqPOg+ujTIZlsmgAsCIvf6h3exqI+6O84kV54mXD4n9HxqLYUIxP19tpTjXo8PnLgchmKCVIquSss/gQT4jHoLD2ZeL0mXqhuWi0qXhYebOlh9JgHWVN3Ye8dyXZ0ayb/fEIuGeVHItZFRNKAlk+3eSlaAZkfwfeWNb4j3R5EonId0pFQ12o7qlOGZKHKXhS5IhrdQKSKNPrH/R7lSZE6a9rhDq6c796H8HGIoSWOrXW893giv6rl0hUMa7lZcdSpVr53IQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(136003)(346002)(366004)(396003)(376002)(316002)(478600001)(6506007)(966005)(6512007)(30864003)(54906003)(91956017)(64756008)(66556008)(76116006)(66446008)(2616005)(66946007)(53546011)(2906002)(66476007)(186003)(71200400001)(26005)(33656002)(8676002)(8936002)(86362001)(83380400001)(6916009)(4326008)(122000001)(38100700002)(6486002)(5660300002)(36756003)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?T2d6S1loblM0Z2pBVTNhOFdub1FVV0pTOXhKeTVXZkZPc0tUWnQ1VVNyS1Nj?= =?utf-8?B?d3NIczFhU1ZKVEM4MUJnOGtTbmxGQmtsZVU5ZVRDQTNFUlpaRy9hSDhzV284?= =?utf-8?B?VzBxNUF0MmVURjl5UjRWN2FpaVhkWnYvMWFqZGRuQkxXTkFZQWlaWG02RlNM?= =?utf-8?B?aFNhTjJiQWdGVFBrSEp1bzJXcXdzdVhScjNHU0dqbjVtRXdCRTlwY0FDVnY2?= =?utf-8?B?Nk1abk9IK2FDUXVNcnpLSHIzOVVmVmo5Y2lmbjRVTEpJbnByUm5Ua1NoQ2RH?= =?utf-8?B?RzhSWkpVRmNIMER5QUtWMTVrWVBWU1BJVEhMbXFobi9uM2h2ZVNXS1I1THo2?= =?utf-8?B?RGFxdERReDFjbGNwL2drcE5CUVhPWWNDTXY2U2ZQMzdkQlJ2WnBTaGRjVXRJ?= =?utf-8?B?cEtZdnVTN0w1NkkzMHN1OEthQU9qRW5qTVlzM0NVNXpNcVZWRkY0UTdUNDhK?= =?utf-8?B?RnJCSHFIR3o0aWhVUVNJUG9QUzBlSE1SelA1QU05MHdaSmJLMXRxb1NmcEFB?= =?utf-8?B?MjB1YkZMRDJSaTdlY3d4N0t3UmJybWsxQ1lqd2RXb3NacEJzbXJrb3FWcmcx?= =?utf-8?B?UXRYeG4yR3B5SlJMK1FlT3lWUjE5ODUyKy9GNFBnYk15YVNYRzVDVCs4c2pI?= =?utf-8?B?bmI3a2hOTW5Gd2NKczhxRnBXQ2Z2UFlLeTliR2Ftd040dWJvRXBlbUcwRmpu?= =?utf-8?B?VkVPU2svNTluQlRHa3NBU1QzbUZYMUJTc1lMZ05IM1djS0ZVbFFJMFFZakJC?= =?utf-8?B?N0tBREVUUHl6SWgxUkxFanZhVnM3R1J5VjZjdFFqRzk1RnozdkpSZmxiU2FQ?= =?utf-8?B?RUQ3VitMQjkzR0Fqa0lGM3MwQTdPUnN2aWt6MGhIRERoQnBDbjFHNTlMaE9L?= =?utf-8?B?bVpSM095TCtLSmlaTHFPeGhoWGc5MG5ZU1pqNFU4d0hzR3JXRkU2bVZ5R0dN?= =?utf-8?B?dnZqVkwxSmh0a251OFZjZ2hEUnRKaVQ1NjZseHRKdzRsUnVYMmJoTXcrRkNE?= =?utf-8?B?dXlkYjI2YnFzNkdrL0hyNjk1SVM4bmNsNm9hTEFrWTNDbXUyQm8xUGl5OEdG?= =?utf-8?B?UTBQRVF6Y1ZhSHJlbThxWXhLWUJlbHRma1BjTFZNeG1vQThRYXlNaEJETk5r?= =?utf-8?B?QkNnYjZFWjliN1dRZTZESysvMEJoVC9DR1NCN3VQemxDT283UmFwWVVsc2k0?= =?utf-8?B?RG9ZbUsvNi91R0ppMVZJbjdyZGMycUtWZGpZQVd4cGdVUzlyUXlLeTkzaVp6?= =?utf-8?B?clk5ODRVaS83UHFKSllnNkY5VGtROXVOYkt2aXM3cHRoNWluUXUyMGFtMmxP?= =?utf-8?B?TWZGUFp1amhqR3Z1RjRncGF6RTgzUEo4QXFVKy84N0x1QzExWlkyQTV5dy9H?= =?utf-8?B?OUsyTEFRWE1iSDhmVlE1TU02aEJ2dCtaUVB5dy9qZ1M4WGRTSi9WdzJ1cHh1?= =?utf-8?B?Q2taR1UwOHYraldnRmd5djl0VytZbFAxV2JnVUlvOUxXMVg5UnNadDVTN2N6?= =?utf-8?B?cGd5bnFPTlRmTHIyWEVCWnZiU1NNK0xpY1NDc3FscENtdDJ3NzJuUFZqQXJS?= =?utf-8?B?Z2hMV0kyTWM1ZHRNb1lrUEFZSW1JdkVSbkk1cVk3bnZHa3NDOWN2MUFHRTlw?= =?utf-8?B?STVFcEJwZmpaRHlzUWVzbmhTQTNXbXZoQlYvQk5qYkYrcGJXQURtTWlKSlVz?= =?utf-8?B?V3JBZWtLQm9EWWcreklWSkIvcUVNMWlFUzVwVHJwUGx6akpYWGhqWGdoVGpJ?= =?utf-8?B?eEdNVk1HUXhaOFIvM1dNRUIySjRPelF1Z1dkNEdEZko4a0N1eGFWYVhvT3pO?= =?utf-8?B?WkdHdVNQZ2dyNTd3RFBWUT09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f530887-c709-4515-42b5-08d91c73d53b X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2021 16:16:47.2544 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9HElvaMbODJKZTFNz7DX0Y+NM7CsoRCn0joWyP8s8Z2JV+0OThuqoKR3Lafchd2G X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6174 X-Proofpoint-GUID: pZ0tZb9CydSfnBsGNaSWgHFFqggIxg3H X-Proofpoint-ORIG-GUID: pZ0tZb9CydSfnBsGNaSWgHFFqggIxg3H X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-21_07:2021-05-20, 2021-05-21 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 clxscore=1015 priorityscore=1501 mlxscore=0 suspectscore=0 impostorscore=0 malwarescore=0 phishscore=0 mlxlogscore=999 bulkscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105210086 Archived-At: Subject: Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (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, 21 May 2021 16:16:57 -0000 SGkgTWVkLA0KDQpZb3VyIGN1cnJlbnQgd29ya2luZyBjb3B5IGxvb2tzIGdvb2QuIEnigJl2ZSBj bGVhcmVkIG15IGRpc2N1c3MuDQoNCuKAlEpvaG4NCg0KPiBPbiBNYXkgMjEsIDIwMjEsIGF0IDg6 NDEgQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+IA0KPiBbRXh0ZXJu YWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdDQo+IA0KPiANCj4gSGkgSm9obiwNCj4g DQo+IEFzIHlvdSBjYW4gc2VlIGluIGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczov L3Rpbnl1cmwuY29tL25ldy1ibG9jay1sYXRlc3RfXzshIU5FdDZ5TWFPLWdrIVJsRGs3R01jYnhs RnNUMlFHbDhtYTA0czFDZ2dtUVpRSGNJUDlhdzJSMkVQMXJXa2ZRREFiSXB6T2d5UjZnJCAsIHdl IHdlbnQgd2l0aCB0aGUgZm9sbG93aW5nIGNoYW5nZXMgdG8gYmV0dGVyIGFkZHJlc3MgeW91ciBs YXRlc3QgY29tbWVudCBvbiB0aGUgaml0dGVyOg0KPiANCj4gKDEpIGJlIGV4cGxpY2l0IGFib3V0 IHRoZSBmb3JtdWxhIHVzZWQgZm9yIGRlZmF1bHQgdmFsdWVzOg0KPiANCj4gT0xEOg0KPiAgIE5P Tl9QUk9CSU5HX1dBSVQgaXMgdXNlZCB0byBsaW1pdCB0aGUgcG90ZW50aWFsIHdhaXQgbmVlZGVk IHdoZW4NCj4gICB1c2luZyBQUk9CSU5HX1JBVEUuICBCeSBkZWZhdWx0LCBOT05fUFJPQklOR19X QUlUIGhhcyB0aGUgc2FtZSB2YWx1ZQ0KPiAgIGFzIEVYQ0hBTkdFX0xJRkVUSU1FIChTZWN0aW9u IDQuOC4yIG9mIFtSRkM3MjUyXSkuDQo+IA0KPiAgIE5PTl9QQVJUSUFMX1RJTUVPVVQgaXMgdXNl ZCBmb3IgZXhwaXJpbmcgcGFydGlhbGx5IHJlY2VpdmVkIGJvZGllcy4NCj4gICBCeSBkZWZhdWx0 LCBOT05fUEFSVElBTF9USU1FT1VUIGhhcyB0aGUgc2FtZSB2YWx1ZSBhcw0KPiAgIEVYQ0hBTkdF X0xJRkVUSU1FIChTZWN0aW9uIDQuOC4yIG9mIFtSRkM3MjUyXSkuDQo+IA0KPiBORVc6DQo+ICAg Tk9OX1BST0JJTkdfV0FJVCBpcyB1c2VkIHRvIGxpbWl0IHRoZSBwb3RlbnRpYWwgd2FpdCBuZWVk ZWQgd2hlbg0KPiAgIHVzaW5nIFBST0JJTkdfUkFURS4gIEJ5IGRlZmF1bHQsIE5PTl9QUk9CSU5H X1dBSVQgaXMgY29tcHV0ZWQgaW4gdGhlDQo+ICAgc2FtZSB3YXkgYXMgRVhDSEFOR0VfTElGRVRJ TUUgKFNlY3Rpb24gNC44LjIgb2YgW1JGQzcyNTJdKSBidXQgd2l0aA0KPiAgIEFDS19USU1FT1VU IGFuZCBNQVhfUkVUUkFOU01JVCBzdWJzdGl0dXRlZCB3aXRoIE5PTl9USU1FT1VUIGFuZA0KPiAg IE5PTl9NQVhfUkVUUkFOU01JVCwgcmVzcGVjdGl2ZWx5Og0KPiANCj4gICAgICBOT05fUFJPQklO R19XQUlUID0gTk9OX1RJTUVPVVQgKiAoKDIgKiogTk9OX01BWF9SRVRSQU5TTUlUKSAtIDEpICoN Cj4gICAgICBBQ0tfUkFORE9NX0ZBQ1RPUiArICgyICogTUFYX0xBVEVOQ1kpICsgTk9OX1RJTUVP VVQNCj4gDQo+ICAgTk9OX1BBUlRJQUxfVElNRU9VVCBpcyB1c2VkIGZvciBleHBpcmluZyBwYXJ0 aWFsbHkgcmVjZWl2ZWQgYm9kaWVzLg0KPiAgIEJ5IGRlZmF1bHQsIE5PTl9QQVJUSUFMX1RJTUVP VVQgaXMgY29tcHV0ZWQgaW4gdGhlIHNhbWUgd2F5IGFzDQo+ICAgRVhDSEFOR0VfTElGRVRJTUUg KFNlY3Rpb24gNC44LjIgb2YgW1JGQzcyNTJdKS4gIFRoaXMgZGVmYXVsdCB2YWx1ZQ0KPiAgIGlz IGNhbGN1bGF0ZWQgaW4gdGhlIHNhbWUgd2F5IGFzIE5PTl9QUk9CSU5HX1dBSVQuDQo+IA0KPiAo MikgV2UgZG9u4oCZdCBzZWUgYSBuZWVkIHRvIGFwcGx5IGEgaml0dGVyIHdoZW4gYSB2YWx1ZSBp cyBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgKHRoZXNlIGFyZSBleHBlY3RlZCB0byBiZSBsYXJnZSBu dW1iZXJzLCB3ZSBkb24ndCBjYXJlIHRoYXQgbXVjaCBvbiB0aGUgaml0dGVyKS4gV2UgYWRkZWQg dGhpcyB0ZXh0IHRvIGJlIGNsZWFyIGFib3V0IHRoZSBpbnRlbnQsIGFuZCB3aGljaCBCVFcgcmVm bGVjdHMgdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb246DQo+IA0KPiBORVc6DQo+ICAgICAgV2hl biBleHBsaWNpdCB2YWx1ZXMgYXJlDQo+ICAgICAgY29uZmlndXJlZCBmb3IgTk9OX1BST0JJTkdf V0FJVCBhbmQgTk9OX1BBUlRJQUxfVElNRU9VVCwgdGhlc2UNCj4gICAgICB2YWx1ZXMgYXJlIHVz ZWQgd2l0aG91dCBhcHBseWluZyBhbnkgaml0dGVyLg0KPiANCj4gV2UgYWxzbyBhZG9wdGVkIHlv dXIgcHJvcG9zZWQgZWRpdHMgaW4gdGhlIG1lc3NhZ2UgYmVsb3cuDQo+IA0KPiBUaGFuayB5b3Ug YWdhaW4gZm9yIHRoZSBjYXJlZnVsIHJldmlldy4gVGhpcyBpcyBoaWdobHkgYXBwcmVjaWF0ZWQu DQo+IA0KPiBDaGVlcnMsDQo+IEpvaG4gJiBNZWQNCj4gDQo+PiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4+IERlIDogSm9obiBTY3VkZGVyIFttYWlsdG86amdzQGp1bmlwZXIubmV0XQ0K Pj4gRW52b3nDqSA6IHZlbmRyZWRpIDIxIG1haSAyMDIxIDAwOjAzDQo+PiDDgCA6IEJPVUNBREFJ UiBNb2hhbWVkIFRHSS9PTE4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+PiBDYyA6 IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRm Lm9yZzsNCj4+IGNvcmUtY2hhaXJzQGlldGYub3JnOyBjb3JlQGlldGYub3JnOyBtYXJjby50aWxv Y2FAcmkuc2UNCj4+IE9iamV0IDogUmU6IEpvaG4gU2N1ZGRlcidzIERpc2N1c3Mgb24gZHJhZnQt aWV0Zi1jb3JlLW5ldy1ibG9jay0xMToNCj4+ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ PiANCj4+IEhpIE1vaGFtZWQsDQo+PiANCj4+IEkgdGhpbmsgd2UgYXJlIGNvbnZlcmdpbmcuIE15 IGNvbW1lbnRzIGluIGxpbmUuIEnigJl2ZSBzbmlwcGVkIGFncmVlZA0KPj4gcG9pbnRzIGZvciBi cmV2aXR5LCBpbmRpY2F0ZWQgYnkgW+KApl0uDQo+PiANCj4+PiBPbiBNYXkgMjAsIDIwMjEsIGF0 IDk6MTcgQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+PiANCj4+IFvi gKZdDQo+PiANCj4+Pj4+PiAxMS4gR2VuZXJhbA0KPj4+Pj4+IA0KPj4+Pj4+IEJ5IHRoZSB3YXks IG5vbmUgb2YgdGhlIHRpbWVycyBzcGVjaWZ5IGppdHRlciAoYW5kIGluZGVlZCwgaWYNCj4+IHJl YWQNCj4+Pj4+PiBsaXRlcmFsbHksIGppdHRlciB3b3VsZCBiZSBmb3JiaWRkZW4pLiBJcyB0aGlz IGludGVudGlvbmFsPw0KPj4+Pj4gDQo+Pj4+PiBObyArLy0gdG9sZXJhbmNlcyBoYXZlIGJlZW4g ZGVmaW5lZC4gV2hlbiBhIHRpbWVyIGV4cGlyZXMsIHRoZW4NCj4+IHRoZQ0KPj4+PiBuZXh0IGFj dGlvbiB0YWtlcyBwbGFjZS4NCj4+Pj4gDQo+Pj4+IEkgbm90aWNlIHRoYXQgUkZDIDcyNTIgaml0 dGVycyBpdHMgdGltZXJzLCBmb3IgZXhhbXBsZToNCj4+Pj4gDQo+Pj4+ICBjb3VudGVyLiAgRm9y IGEgbmV3IENvbmZpcm1hYmxlIG1lc3NhZ2UsIHRoZSBpbml0aWFsIHRpbWVvdXQgaXMNCj4+IHNl dA0KPj4+PiAgdG8gYSByYW5kb20gZHVyYXRpb24gKG9mdGVuIG5vdCBhbiBpbnRlZ3JhbCBudW1i ZXIgb2Ygc2Vjb25kcykNCj4+Pj4gIGJldHdlZW4gQUNLX1RJTUVPVVQgYW5kIChBQ0tfVElNRU9V VCAqIEFDS19SQU5ET01fRkFDVE9SKSAoc2VlDQo+Pj4+ICBTZWN0aW9uIDQuOCkNCj4+Pj4g4oCm DQo+Pj4+ICBBQ0tfUkFORE9NX0ZBQ1RPUiBNVVNUIE5PVCBiZSBkZWNyZWFzZWQgYmVsb3cgMS4w LCBhbmQgaXQgU0hPVUxEDQo+Pj4+IGhhdmUNCj4+Pj4gIGEgdmFsdWUgdGhhdCBpcyBzdWZmaWNp ZW50bHkgZGlmZmVyZW50IGZyb20gMS4wIHRvIHByb3ZpZGUgc29tZQ0KPj4+PiAgcHJvdGVjdGlv biBmcm9tIHN5bmNocm9uaXphdGlvbiBlZmZlY3RzLg0KPj4+PiANCj4+Pj4gTUFYX1RSQU5TTUlU X1NQQU4gYW5kIE1BWF9UUkFOU01JVF9XQUlUIGFyZSBzaW1pbGFybHkgaml0dGVyZWQuIEENCj4+ Pj4gbnVtYmVyIG9mIHlvdXIgaW50cm9kdWNlZCBwYXJhbWV0ZXJzDQo+Pj4+IA0KPj4+PiAgVGhp cyBkb2N1bWVudCBpbnRyb2R1Y2VzIG5ldyBwYXJhbWV0ZXJzIE1BWF9QQVlMT0FEUywNCj4+IE5P Tl9USU1FT1VULA0KPj4+PiAgTk9OX1JFQ0VJVkVfVElNRU9VVCwgTk9OX01BWF9SRVRSQU5TTUlU LCBOT05fUFJPQklOR19XQUlULCBhbmQNCj4+Pj4gIE5PTl9QQVJUSUFMX1RJTUVPVVQgcHJpbWFy aWx5IGZvciB1c2Ugd2l0aCBOT04gKFRhYmxlIDMpLg0KPj4+PiANCj4+Pj4gYXBwZWFyIGF0IGxl YXN0IHN1cGVyZmljaWFsbHkgc2ltaWxhciB0byB0aGUgdGltZXJzIHRoZSBhdXRob3JzIG9mDQo+ Pj4+IFJGQyA3MjUyIGRlZW1lZCBpbXBvcnRhbnQgdG8gaml0dGVyIHRvIHByZXZlbnQgc3luY2hy b25pemF0aW9uDQo+Pj4+IGVmZmVjdHMuIERpZCB5b3Ugc3BlY2lmaWNhbGx5IGNvbnNpZGVyIGpp dHRlcmluZyB0aGVtLCBhbmQgZGVjaWRlDQo+Pj4+IHRoYXQgaml0dGVyIHdhcyB1bm5lY2Vzc2Fy eT8gSWYgc28sIGNhbiB5b3UgZXhwbGFpbiB3aGF0IGlzDQo+PiBkaWZmZXJlbnQNCj4+Pj4gYWJv dXQgeW91ciBzcGVjaWZpY2F0aW9uLCBjb21wYXJlZCB0byB0aGUgYmFzZSBzcGVjLCB0aGF0DQo+ PiBlbGltaW5hdGVzDQo+Pj4+IHRoZSBjb25jZXJuPw0KPj4+IA0KPj4+IFJGQzcyNTIgaW50cm9k dWNlcyBBQ0tfUkFORE9NX0ZBQ1RPUiBqaXR0ZXIgYW5kIHNlcGFyYXRlbHkgaml0dGVyDQo+PiBm b3IgbXVsdGljYXN0IHJlc3BvbnNlcyAod2hpY2ggaXMgbm90IHJlbGV2YW50IGhlcmUpLg0KPj4+ IA0KPj4+IFRoZSBBQ0tfUkFORE9NX0ZBQ1RPUiBpcyB0aGVyZSBmb3Igd2hlbiByZS10cmFuc21p dHRpbmcgYSBwYWNrZXQNCj4+IHRoYXQgaGFzIG5vdCBiZWVuIGFja25vd2xlZGdlZCBmb3Igc29t ZSByZWFzb24gYnkgaXRzIHBlZXIuDQo+PiBOT05fVElNRU9VVCBpcyBmb3Igd2hlbiB0aGUgbmV4 dCBNQVhfUEFZTE9BRFNfU0VUIGNhbiBzdGFydA0KPj4gdHJhbnNtaXNzaW9uIChub3QgcmUtdHJh bnNtaXNzaW9uKSBhc3N1bWluZyBhICdDb250aW51ZScgaGFzIG5vdA0KPj4gYXJyaXZlZCBpbiB0 aGUgaW50ZXJpbSwgYW5kIHNvIHdhcyBub3QgdGhvdWdodCBuZWNlc3NhcnkgdG8gYWRkIGluDQo+ PiBBQ0tfUkFORE9NX0ZBQ1RPUiBzdHlsZSBqaXR0ZXIgaGVyZS4NCj4+PiANCj4+PiBGb3IgTk9O X1JFQ0VJVkVfVElNRU9VVCwgd2hhdCBpcyBpbXBvcnRhbnQgaXMgdGhhdA0KPj4gTk9OX1JFQ0VJ VkVfVElNRU9VVCBpcyBncmVhdGVyIHRoYW4gTk9OX1RJTUVPVVQgKFdlIHNheSBpbiB0aGUgc3Bl YyBhDQo+PiBtaW5pbXVtIG9mIG9uZSBzZWNvbmQpIHNvIHRoYXQgYSBwZWVyIGRvZXMgbm90IGZp cmUgb2ZmIGEgcmUtDQo+PiB0cmFuc21pc3Npb24gcmVxdWVzdCBiZWZvcmUgdGhlIGxvY2FsIGFn ZW50IGhhcyBhIGNoYW5jZSB0byBzdGFydCB0bw0KPj4gdHJhbnNtaXQgdGhlIG5leHQgTUFYX1BB WUxPQURTX1NFVC4gIE5PTl9SRUNFSVZFX1RJTUVPVVQgaXMNCj4+IGV4cG9uZW50aWFsbHkgc2Nh bGVkIGZvciBlYWNoIHJldHJ5IHRvIG1ha2Ugc3VyZSB0aGF0IHN0YWJpbGl0eSBpcw0KPj4gcHJl c2VydmVkLiBTbywgYWdhaW4sIEFDS19SQU5ET01fRkFDVE9SIGppdHRlciB3YXMgbm90IHRob3Vn aHQgdG8gYmUNCj4+IG5lY2Vzc2FyeSBoZXJlLg0KPj4+IA0KPj4+IE5PTl9NQVhfUkVUUkFOU01J VCBpcyBhIGZpeGVkIGNvdW50Lg0KPj4+IA0KPj4+IE5PTl9QUk9CSU5HX1dBSVQgaXMgdXNlZCB0 byBwdXQgYSBsaW1pdCBvbiB0aGUgcG90ZW50aWFsIGRlbGF5IHRoYXQNCj4+IGNvdWxkIGluY3Vy IHdoZW4gb2JleWluZyBQUk9CSU5HX1dBSVQgd2hlbiB0aGVyZSBpcyBubyBwZWVyIHJlc3BvbnNl Lg0KPj4gSWYgdGhlIGltcGxlbWVudGF0aW9uIGdvZXMgd2l0aCB0aGUgZGVmYXVsdCBFWENIQU5H RV9MSUZFVElNRQ0KPj4gY29tcHV0YXRpb24sIHRoZW4gTk9OX1BST0JJTkdfV0FJVCBpbmNsdWRl cyBBQ0tfUkFORE9NX0ZBQ1RPUiBpbiB0aGUNCj4+IG1hdGguDQo+Pj4gDQo+Pj4gTk9OX1BBUlRJ QUxfVElNRU9VVCBpZiBjb21wdXRlZCB1c2luZyB0aGUgZGVmYXVsdCBFWENIQU5HRV9MSUZFVElN RQ0KPj4gaW5jbHVkZXMgQUNLX1JBTkRPTV9GQUNUT1IuDQo+PiANCj4+IFRoYW5rcyBmb3IgdGFr aW5nIHRoZSB0aW1lIHRvIGV4cGxhaW4uIFlvdSBkb27igJl0IGNvbW1lbnQgcmVnYXJkaW5nDQo+ PiB3aGV0aGVyIE5PTl9QUk9CSU5HX1dBSVQgYW5kIE5PTl9QQVJUSUFMX1RJTUVPVVQgc2hvdWxk IGJlIGppdHRlcmVkDQo+PiBvciBub3QsIHlvdSBqdXN0IGV4cGxhaW4gdGhhdCBpZiB0aGV5IHVz ZSB0aGUgZGVmYXVsdCB0aGV5IGdldCBqaXR0ZXINCj4+IOKAnGZvciBmcmVl4oCdLiBUaGUgbWlz c2luZyBkZXRhaWwgaXMgdGhhdCBpZiB0aGV5IGRvbuKAmXQgdXNlIHRoZSBkZWZhdWx0DQo+PiB0 aGV5IGRvbuKAmXQgZ2V0IGppdHRlcmVkLCBzbyBJIHRoaW5rIHNvbWUgY29uc2lkZXJhdGlvbiBp cyBzdGlsbA0KPj4gY2FsbGVkIGZvciByZWdhcmRpbmcgd2hldGhlciBoYXZpbmcgdGhlbSBub3Qg YmUgaml0dGVyZWQgaXMgT0suDQo+PiANCj4+IFvigKZdDQo+PiANCj4+Pj4+PiAxNS4gU2VjdGlv biAxMC4yLjMNCj4+IA0KPj4gW+KApl0NCj4+IA0KPj4+PiBPbmUgY29uY2VybiByZWxhdGVkIHRv IHRoYXQ6IHdhaXRpbmcgTk9OX1RJTUVPVVQgaXNu4oCZdCBhY3R1YWxseQ0KPj4+PiByZXF1aXJl ZCwgaXTigJlzIG9ubHkgUkVDT01NRU5ERUQsIHRoZXJlZm9yZSB0aGlzIGlzbuKAmXQgYWN0dWFs bHkgYQ0KPj4+PiBndWFyYW50ZWUuIEZyb20gwqc3LjI6DQo+Pj4+IA0KPj4+PiAgQXMgdGhlIHNl bmRpbmcgb2YgbWFueSBwYXlsb2FkcyBvZiBhIHNpbmdsZSBib2R5IG1heSBpdHNlbGYNCj4+IGNh dXNlDQo+Pj4+ICBjb25nZXN0aW9uLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGFmdGVyIHRyYW5z bWlzc2lvbiBvZiBldmVyeQ0KPj4+PiAgTUFYX1BBWUxPQURTX1NFVCBvZiBhIHNpbmdsZSBib2R5 LCBhIGRlbGF5IGlzIGludHJvZHVjZWQgb2YNCj4+Pj4gIE5PTl9USU1FT1VUIGJlZm9yZSBzZW5k aW5nIHRoZSBuZXh0IE1BWF9QQVlMT0FEU19TRVQgdG8gbWFuYWdlDQo+Pj4+ICBwb3RlbnRpYWwg Y29uZ2VzdGlvbiBpc3N1ZXMuDQo+Pj4+IA0KPj4+PiBJIGFtIGN1cmlvdXMgd2h5IHlvdSBtYWRl IHRoaXMgYSBSRUNPTU1FTkRFRCBpbnN0ZWFkIG9mIGEgTVVTVC4gSW4NCj4+IGENCj4+Pj4gc2l0 dWF0aW9uIGxpa2UgdGhpcyBpdCB3b3VsZCBiZSBwcmVmZXJhYmxlIGZvciB5b3UgdG8gZXhwbGFp biB0bw0KPj4gdGhlDQo+Pj4+IGltcGxlbWVudG9yIHdoYXQgc2l0dWF0aW9uIHRoZXkgY2FuIGln bm9yZSB0aGUgUkVDT01NRU5ERUQgaW4gYW5kDQo+Pj4+IHdoYXQgdGhleSBzaG91bGQgZG8gaW5z dGVhZCwgb3Igb2YgY291cnNlIHRvIG1ha2UgaXQgaW50byBhIE1VU1QuDQo+Pj4gDQo+Pj4gQmVj YXVzZSBhIGNvbnRpbnVlIHNpZ25hbCBtYXkgYmUgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBhbmQg dGhlbg0KPj4gY29udGludWUgd2l0aG91dCB3YWl0aW5nIGZvciB0aGUgdGltZW91dCB0byBleHBp cmUuDQo+Pj4gDQo+Pj4gVGhpcyBpcyB0byBiZSBsaW5rZWQgd2l0aCB0aGlzIHRleHQ6DQo+Pj4g DQo+Pj4gICAgIEEgcmVzcG9uc2UgdXNpbmcgdGhpcyBSZXNwb25zZSBDb2RlIFNIT1VMRCBOT1Qg YmUgZ2VuZXJhdGVkDQo+PiBmb3INCj4+PiAgICAgZXZlcnkgcmVjZWl2ZWQgUS1CbG9jazEgT3B0 aW9uIHJlcXVlc3QgKFNlY3Rpb24gNy4yKS4gIEl0DQo+PiBTSE9VTEQNCj4+PiAgICAgb25seSBi ZSBnZW5lcmF0ZWQgd2hlbiBhbGwgdGhlIHBheWxvYWQgcmVxdWVzdHMgYXJlIE5vbi0NCj4+PiAg ICAgY29uZmlybWFibGUgYW5kIGEgTUFYX1BBWUxPQURTX1NFVCBoYXMgYmVlbiByZWNlaXZlZCBi eSB0aGUNCj4+PiAgICAgIHNlcnZlci4gIE1vcmUgZGV0YWlscyBhYm91dCB0aGUgbW90aXZhdGlv bnMgZm9yIHRoaXMNCj4+IG9wdGltaXphdGlvbg0KPj4+IA0KPj4gXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCj4+PiAgICAgYXJlIGRpc2N1 c3NlZCBpbiBTZWN0aW9uIDcuMi4NCj4+PiAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xg0KPj4+IA0KPj4+IFdlIGNvdWxkIHVzZSAqKk1VU1QgdW5sZXNzIGEgJ0NvbnRpbnVlJyBpcyBy ZWNlaXZlZCoqLCBlLmcuLA0KPj4+IA0KPj4+IE9MRDoNCj4+PiAgQXMgdGhlIHNlbmRpbmcgb2Yg bWFueSBwYXlsb2FkcyBvZiBhIHNpbmdsZSBib2R5IG1heSBpdHNlbGYgY2F1c2UNCj4+PiAgY29u Z2VzdGlvbiwgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCBhZnRlciB0cmFuc21pc3Npb24gb2YgZXZl cnkNCj4+PiAgTUFYX1BBWUxPQURTX1NFVCBvZiBhIHNpbmdsZSBib2R5LCBhIGRlbGF5IGlzIGlu dHJvZHVjZWQgb2YNCj4+PiAgTk9OX1RJTUVPVVQgYmVmb3JlIHNlbmRpbmcgdGhlIG5leHQgTUFY X1BBWUxPQURTX1NFVCB0byBtYW5hZ2UNCj4+PiAgcG90ZW50aWFsIGNvbmdlc3Rpb24gaXNzdWVz Lg0KPj4+IA0KPj4+IE5FVzoNCj4+PiAgQXMgdGhlIHNlbmRpbmcgb2YgbWFueSBwYXlsb2FkcyBv ZiBhIHNpbmdsZSBib2R5IG1heSBpdHNlbGYgY2F1c2UNCj4+PiAgY29uZ2VzdGlvbiwgYWZ0ZXIg dHJhbnNtaXNzaW9uIG9mIGV2ZXJ5IE1BWF9QQVlMT0FEU19TRVQgb2YgYQ0KPj4gc2luZ2xlDQo+ Pj4gIGJvZHksIGEgZGVsYXkgTVVTVCBiZSBpbnRyb2R1Y2VkIG9mIE5PTl9USU1FT1VUIGJlZm9y ZSBzZW5kaW5nDQo+PiB0aGUNCj4+PiAgbmV4dCBNQVhfUEFZTE9BRFNfU0VUIHRvIG1hbmFnZSBw b3RlbnRpYWwgY29uZ2VzdGlvbiBpc3N1ZXMuDQo+Pj4gIEhvd2V2ZXIsIGlmIGEgJ0NvbnRpbnVl JyBpcyByZWNlaXZlZCBmcm9tIHRoZSBwZWVyIGZvciB0aGUNCj4+IGN1cnJlbnQNCj4+PiAgTUFY X1BBWUxPQURTX1NFVCwgdGhlbiB0aGUgbmV4dCBNQVhfUEFZTE9BRFNfU0VUIGNhbiBzdGFydA0K Pj4+ICB0cmFuc21pc3Npb24gaW1tZWRpYXRlbHkuDQo+Pj4gDQo+Pj4gLi4uIGJ1dCBJIGtub3cg dGhhdCBtYW55IHdvdWxkIGFyZ3VlIHRoaXMgaXMgYSBTSE9VTEQuDQo+PiANCj4+IEkgd291bGQg YmUgT0sgd2l0aCBlaXRoZXIgeW91ciBwcm9wb3NlZCBuZXcgdGV4dCwgb3IgYSBTSE9VTEQvTUFZ DQo+PiBwYWlyIGFzIGluDQo+PiANCj4+IE5FVzoNCj4+ICBBcyB0aGUgc2VuZGluZyBvZiBtYW55 IHBheWxvYWRzIG9mIGEgc2luZ2xlIGJvZHkgbWF5IGl0c2VsZiBjYXVzZQ0KPj4gIGNvbmdlc3Rp b24sIGFmdGVyIHRyYW5zbWlzc2lvbiBvZiBldmVyeSBNQVhfUEFZTE9BRFNfU0VUIG9mIGENCj4+ IHNpbmdsZQ0KPj4gIGJvZHksIGEgZGVsYXkgU0hPVUxEIGJlIGludHJvZHVjZWQgb2YgTk9OX1RJ TUVPVVQgYmVmb3JlIHNlbmRpbmcNCj4+IHRoZQ0KPj4gIG5leHQgTUFYX1BBWUxPQURTX1NFVCB0 byBtYW5hZ2UgcG90ZW50aWFsIGNvbmdlc3Rpb24gaXNzdWVzLg0KPj4gIEhvd2V2ZXIsIGlmIGEg J0NvbnRpbnVlJyBpcyByZWNlaXZlZCBmcm9tIHRoZSBwZWVyIGZvciB0aGUgY3VycmVudA0KPj4g IE1BWF9QQVlMT0FEU19TRVQsIHRoZW4gdGhlIG5leHQgTUFYX1BBWUxPQURTX1NFVCBNQVkgc3Rh cnQNCj4+ICB0cmFuc21pc3Npb24gaW1tZWRpYXRlbHkuDQo+PiANCj4+IElmIHlvdSB3YW50IHRv IHN0aWNrIHdpdGggTVVTVCBJIHRoaW5rIHlvdSBjYW4gY2xlYXIgdXAgdGhlIHBhaW4gd2l0aA0K Pj4gc29tZXRoaW5nIGxpa2UNCj4+IA0KPj4gTkVXOg0KPj4gIEFzIHRoZSBzZW5kaW5nIG9mIG1h bnkgcGF5bG9hZHMgb2YgYSBzaW5nbGUgYm9keSBtYXkgaXRzZWxmIGNhdXNlDQo+PiAgY29uZ2Vz dGlvbiwgYWZ0ZXIgdHJhbnNtaXNzaW9uIG9mIGV2ZXJ5IE1BWF9QQVlMT0FEU19TRVQgb2YgYQ0K Pj4gc2luZ2xlDQo+PiAgYm9keSwgYSBkZWxheSBNVVNUIGJlIGludHJvZHVjZWQgb2YgTk9OX1RJ TUVPVVQgYmVmb3JlIHNlbmRpbmcgdGhlDQo+PiAgbmV4dCBNQVhfUEFZTE9BRFNfU0VUIHVubGVz cyBhICdDb250aW51ZScgaXMgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlcg0KPj4gIGZvciB0aGUgY3Vy cmVudCBNQVhfUEFZTE9BRFNfU0VULCBpbiB3aGljaCBjYXNlIHRoZSBuZXh0DQo+PiAgTUFYX1BB WUxPQURTX1NFVCBNQVkgc3RhcnQgdHJhbnNtaXNzaW9uIGltbWVkaWF0ZWx5Lg0KPj4gDQo+PiAo VG8gbXkgZXllIHByZXNlbnRpbmcgdGhlIG9wdGlvbiBpbiB0aGlzIHdheSBtYWtlcyBpdCBjbGVh ciB3aGVuIHRoZQ0KPj4gTVVTVCBkb2VzLCBhbmQgZG9lc27igJl0LCBhcHBseS4gVGhpcyBpcyBt eSBwcmVmZXJyZWQgZm9ybSBidXQgSSBkb27igJl0DQo+PiBpbnNpc3QuKQ0KPj4gDQo+PiBb4oCm XQ0KPj4gDQo+Pj4+IDE3LiBTZWN0aW9uIDE6DQo+Pj4+IA0KPj4+PiAgVGhpcyBkb2N1bWVudCBp bnRyb2R1Y2VzIHRoZSBDb0FQIFEtQmxvY2sxIGFuZCBRLUJsb2NrMiBPcHRpb25zDQo+Pj4+IHdo aWNoDQo+Pj4+ICBhbGxvdyBibG9jay13aXNlIHRyYW5zZmVyIHRvIHdvcmsgd2l0aCBzZXJpZXMg b2YgTm9uLWNvbmZpcm1hYmxlDQo+Pj4+ICBtZXNzYWdlcywgaW5zdGVhZCBvZiBsb2NrLXN0ZXBw aW5nIHVzaW5nIENvbmZpcm1hYmxlIG1lc3NhZ2VzDQo+Pj4+ICAoU2VjdGlvbiAzKS4gIEluIG90 aGVyIHdvcmRzLCB0aGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgbWlzc2luZw0KPj4+PiBwaWVjZQ0K Pj4+PiAgb2YgW1JGQzc5NTldLCBuYW1lbHkgdGhlIHN1cHBvcnQgb2YgYmxvY2std2lzZSB0cmFu c2ZlciB1c2luZw0KPj4gTm9uLQ0KPj4+PiAgY29uZmlybWFibGUgd2hlcmUgYW4gZW50aXJlIGJv ZHkgb2YgZGF0YSBjYW4gYmUgdHJhbnNtaXR0ZWQNCj4+IHdpdGhvdXQNCj4+Pj4gIHRoZSByZXF1 aXJlbWVudCBmb3IgYW4gYWNrbm93bGVkZ2VtZW50IChidXQgcmVjb3ZlcnkgaXMNCj4+IGF2YWls YWJsZQ0KPj4+PiAgc2hvdWxkIGl0IGJlIG5lZWRlZCkuDQo+Pj4+IA0KPj4+PiBBcyBmYXIgYXMg SSBjYW4gdGVsbCB0aGUgc3BlYyBkb2VzIG5vdCByZWFsbHkgcmVtb3ZlIHRoZQ0KPj4gcmVxdWly ZW1lbnQNCj4+Pj4gZm9yIGFja25vd2xlZGdlbWVudCwNCj4+PiANCj4+PiBUaGVzZSBhcmUgbm90 IHJlcXVpcmVkLiBUaGV5IHdlcmUgYWRkZWQgYXMgYW4gb3B0aW1pemF0aW9uIHRvIGF2b2lkDQo+ PiB0aGUgbm9uLXRpbWVvdXQgaWYgdGhlIHBlZXIgZGVjaWRlcyB0byB1c2UgaXQuDQo+PiANCj4+ IEFzIEkgbWVudGlvbmVkIGJlbG93ICjigJxhd2Z1bGx5IGNsb3NlIHBhcnNpbmfigJ0pLCBJIHRo aW5rIHRoYXQgYWx0aG91Z2gNCj4+IHlvdSBjYW4gZmluZCBzb21lIGp1c3RpZmljYXRpb24gZm9y IHRoaXMgcmVhZGluZywgaXTigJlzIGRlYmF0YWJsZS4NCj4+IFRyYW5zbWlzc2lvbiBvZiB0aGUg YWNrbm93bGVkZ2VtZW50IChhdCBsZWFzdCB0aGUgZmluYWwNCj4+IGFja25vd2xlZGdlbWVudCBv ZiB0aGUgZW50aXJlIGJvZHksIGluIHRoZSBmb3JtIG9mIGEgUmVzcG9uc2UgQ29kZSkNCj4+IGlz IHJlcXVpcmVkLCBpcyBpdCBub3Q/IFJlY2VwdGlvbiBpc27igJl0IHJlcXVpcmVkIHRob3VnaC4g V2l0aG91dCB0aGUNCj4+IHZlcmIsIEnigJltIG5vdCBzdXJlIHdoZXRoZXIgSSBjYW4gc2F5IHdo ZXRoZXIgYWNrbm93bGVkZ2VtZW50IGlzLCBvcg0KPj4gaXNu4oCZdCwgcmVxdWlyZWQuDQo+PiAN Cj4+IEkgZG9u4oCZdCBpbnNpc3QgdGhhdCB5b3UgY2hhbmdlIHRoaXMsIGJ1dCBJIGRvIHRoaW5r IHlvdSBjb3VsZCBpbXByb3ZlDQo+PiB0aGUgY2xhcml0eSBvZiB0aGUgZG9jdW1lbnQsIGlmIHlv dSBlZGl0ZWQgdGhlIGFib3ZlIHRvIHJlYWQg4oCc4oCmDQo+PiB3aXRob3V0IHRoZSByZXF1aXJl bWVudCB0aGF0IGFuIGFja25vd2xlZGdtZW50IGJlIHJlY2VpdmVkIGZyb20gdGhlDQo+PiBwZWVy Ig0KPj4gDQo+Pj4+IGl0IGp1c3QgYW1vcnRpemVzIHRoZSBhY2tub3dsZWRnZW1lbnRzIGJ5IG9u bHkgc2VuZGluZyB0aGVtIGV2ZXJ5DQo+Pj4+IE1BWF9QQVlMT0FEU19TRVQuIFJlc3BvbnNlIENv ZGUgMi4zMSBpcyBlc3NlbnRpYWxseSBhbg0KPj4+PiBhY2tub3dsZWRnZW1lbnQsIGFuZCBpdCBn ZXRzIHNlbnQgdGhhdCBmcmVxdWVudGx5LCByaWdodD8gVGhlcmXigJlzDQo+Pj4+IGFsc28gKGlm IEkgcmVjYWxsIGNvcnJlY3RseSkgc29tZSBmbGF2b3Igb2YgYWNrbm93bGVkZ2VtZW50IHRoYXQN Cj4+IGlzDQo+Pj4+IHNlbnQgd2hlbiB0aGUgZW50aXJlIGJvZHkgaGFzIGJlZW4gdHJhbnNmZXJy ZWQuIFNvLCBJIHRoaW5rIHRoZQ0KPj4gbmV3DQo+Pj4+IHBhcmFncmFwaCBpc27igJl0IGFjY3Vy YXRlLg0KPj4+PiANCj4+Pj4gVGhpcyBvYnNlcnZhdGlvbiBhbHNvIGFwcGxpZXMgdG8gdGhpcyBj bGFpbWVkIGJlbmVmaXQgaW4gwqczOg0KPj4+PiANCj4+Pj4gIG8gIFRoZXkgc3VwcG9ydCBzZW5k aW5nIGFuIGVudGlyZSBib2R5IHVzaW5nIE5PTiBtZXNzYWdlcw0KPj4gd2l0aG91dA0KPj4+PiAg ICAgcmVxdWlyaW5nIGFuIGludGVybWVkaWF0ZSByZXNwb25zZSBmcm9tIHRoZSBwZWVyLg0KPj4g DQo+PiBBbmQgc2ltaWxhcmx5LCDigJzigKYgd2l0aG91dCByZXF1aXJpbmcgdGhhdCBhbiBpbnRl cm1lZGlhdGUgcmVzcG9uc2UgYmUNCj4+IHJlY2VpdmVkIGZyb20gdGhlIHBlZXIu4oCdDQo+PiAN Cj4+IFvigKZdDQo+PiANCj4+Pj4gMTguIFNlY3Rpb24gMjoNCj4+Pj4gDQo+Pj4+ICBNQVhfUEFZ TE9BRFNfU0VUIGlzIHRoZSBzZXQgb2YgYmxvY2tzIGlkZW50aWZpZWQgYnkgYmxvY2sNCj4+IG51 bWJlcnMNCj4+Pj4gIHRoYXQsIHdoZW4gZGl2aWRlZCBieSBNQVhfUEFZTE9BRFMsIHRoZXkgaGF2 ZSB0aGUgc2FtZSBudW1lcmljDQo+Pj4+IA0KPj4+PiBSZW1vdmUg4oCcdGhleeKAnQ0KPj4+IA0K Pj4+IEZpeGVkLiBUaGFua3MuDQo+Pj4gDQo+Pj4+IA0KPj4+PiAgcmVzdWx0LiAgRm9yIGV4YW1w bGUsIGlmIE1BWF9QQVlMT0FEUyBpcyBzZXQgdG8gJzEwJywgYQ0KPj4+PiAgTUFYX1BBWUxPQURT X1NFVCBjb3VsZCBiZSBibG9ja3MgIzAgdG8gIzksICMxMCB0byAjMTksIGV0Yy4NCj4+Pj4gIERl cGVuZGluZyBvbiB0aGUgZGF0YSBzaXplLCB0aGUgTUFYX1BBWUxPQURTX1NFVCBtYXkgbm90DQo+ PiBjb21wcmlzZQ0KPj4+PiBhbGwNCj4+Pj4gIHRoZSBNQVhfUEFZTE9BRFMgYmxvY2tzLg0KPj4+ PiANCj4+Pj4gSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIGxhc3Qgc2VudGVuY2UgKCJEZXBlbmRp bmcgb24gdGhlIGRhdGEgc2l6ZSwNCj4+Pj4gdGhlIE1BWF9QQVlMT0FEU19TRVQgbWF5IG5vdCBj b21wcmlzZSBhbGwgdGhlIE1BWF9QQVlMT0FEUw0KPj4gYmxvY2tzLuKAnSkNCj4+Pj4gQXJlIHlv dSB0cnlpbmcgdG8gc2F5IHRoYXQgaWYgdGhlIGJvZHkgc2l6ZSBpc27igJl0IGV2ZW5seSBkaXZp c2libGUNCj4+IGJ5DQo+Pj4+IE1BWF9QQVlMT0FEUyB0aGVuIHRoZSBmaW5hbCBNQVhfUEFZTE9B RFNfU0VUIHdpbGwgaGF2ZSBmZXdlciB0aGFuDQo+Pj4+IE1BWF9QQVlMT0FEUyBibG9ja3MgaW4g aXQ/DQo+Pj4gDQo+Pj4gV2UgbWVhbnQgdGhhdCB0aGUgbGFzdCBzZXQgbWF5IGluY2x1ZGUgZmV3 ZXIgYmxvY2tzIHRoYW4NCj4+IE1BWF9QQVlMT0FEUy4gQ2hhbmdlZCB0bzoNCj4+PiANCj4+PiAi IERlcGVuZGluZyBvbiB0aGUgb3ZlcmFsbCBkYXRhDQo+Pj4gICAgICAgICAgICAgICAgICAgXl5e Xl5eXl4NCj4+PiAgc2l6ZSwgdGhlIGZpbmFsIE1BWF9QQVlMT0FEU19TRVQgbWF5IG5vdCBjb21w cmlzZSBhbGwgdGhlDQo+Pj4gICAgICAgICAgICBeXl5eXg0KPj4+ICBNQVhfUEFZTE9BRFMgYmxv Y2tzLiAiDQo+Pj4gDQo+Pj4gQmV0dGVyPw0KPj4gDQo+PiBJbXByb3ZpbmcuIFRoZSB3b3JkIOKA nGNvbXByaXNl4oCdIGlzIHByb25lIHRvIG1pc2ludGVycHJldGF0aW9uIGluIG15DQo+PiBleHBl cmllbmNlLCBJIHdvdWxkIHN1Z2dlc3Qgc29tZXRoaW5nIGxpa2Ug4oCc4oCmIHRoZXJlIGNvdWxk IGJlIGZld2VyDQo+PiB0aGFuIE1BWF9QQVlMT0FEUyBibG9ja3MgaW4gdGhlIGZpbmFsIE1BWF9Q QVlMT0FEU19TRVQu4oCdDQo+PiANCj4+IFRoYW5rcywNCj4+IA0KPj4g4oCUSm9obg0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiANCj4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jDQo+IHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29w aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBl cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQo+IGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQo+IE9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS4NCj4gDQo+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQo+IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiBUaGFuayB5b3UuDQo+IA0K DQo= From nobody Fri May 21 09:22:32 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 861523A168A; Fri, 21 May 2021 09:22:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: John Scudder via Datatracker To: "The IESG" Cc: draft-ietf-core-new-block@ietf.org, core-chairs@ietf.org, core@ietf.org, marco.tiloca@ri.se, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: John Scudder Message-ID: <162161414645.14500.9969284754936809565@ietfa.amsl.com> Date: Fri, 21 May 2021 09:22:26 -0700 Archived-At: Subject: [core] John Scudder's No Objection on draft-ietf-core-new-block-12: (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, 21 May 2021 16:22:27 -0000 John Scudder has entered the following ballot position for draft-ietf-core-new-block-12: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My further comments are resolved in the current GitHub copy of the document, so once it's published as version 13 I think we're good to go as far as I'm concerned. Thanks for the discussion and changes. -- My initial comments have been resolved or partially resolved in version 12, see https://mailarchive.ietf.org/arch/msg/core/6geK8P9I0jZBPp9a5qSrQwQNhUo/. Note I've added two new ones at the end of the list. (draft-ietf-core-new-block-11) 1. Section 3.2 This mechanism is not intended for general CoAP usage, and any use outside the intended use case should be carefully weighed against the loss of interoperability with generic CoAP applications. I’m curious: is the only reason the mechanism isn’t intended for general usage, the fact some implementations won’t support it? Or does it have other deficiencies that also make it unsuitable? 2. Section 4.1 Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and iPATCH requests and their payload-bearing responses (2.01, 2.02, 2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]). I found the list of codes incomprehensible on first encountering it, since the concept of response codes hadn’t been introduced yet. I do understand that the document assumes familiarity with CoAP; nonetheless for basic clarity I think this should say “(response codes 2.01, 2.02…”. Additionally, the reference to RFC 7252 §5.5 doesn’t seem to be especially germane? By the way, is 2.03 indeed a payload-bearing response? The only other place the spec touches on it is in §4.4, which says “the server could respond with a 2.03 (Valid) response with no payload”. 3. Section 4.1 To indicate support for Q-Block2 responses, the CoAP client MUST include the Q-Block2 Option in a GET or similar request (FETCH, for example), the Q-Block2 Option in a PUT or similar request, or the Q-Block1 Option in a PUT or similar request so that the server knows that the client supports this Q-Block functionality should it need to send back a body that spans multiple payloads. Otherwise, the server would use the Block2 Option (if supported) to send back a message body that is too large to fit into a single IP packet [RFC7959]. Is this paragraph really supposed to mention both Q-Block2 and Q-Block1? In particular, I’m confused by the mention of both of these in relation to PUT. 4. Section 4.1 The Q-Block1 and Q-Block2 Options are unsafe to forward. That is, a CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option MUST reject the request or response that uses either option. Presumably (hopefully) this is simply describing the behavior of existing spec-compliant proxies when processing the new messages. As such, is the MUST appropriate? I would think not. 5. Section 4.3 body. Note that the last received payload may not be the one with the highest block number. “Might not” would be less ambiguous than “may not”. 6. Section 4.4 (also two places in §4.3) (This comment rehashes, in more detail, the difficulty explained in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.) The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2) I read this as meaning the client should wait for as little as zero, or as long as NON_RECEIVE_TIMEOUT — that’s my understanding of “up to”. Is that the intended meaning? If it is, I think it’s worth writing out as I’ve done, for clarity. If it’s not, it definitely needs to be fixed. There’s a similar issue with “up to NON_PARTIAL_TIMEOUT” later in the section. Referring ahead to Section 7.2 muddies the waters further. Even though the text quoted above says NON_RECEIVE_TIMEOUT is an upper limit on how long to wait, §7.2 says it’s a lower limit instead... maybe? From §7.2: NON_RECEIVE_TIMEOUT is the initial maximum time to wait for a missing “Maximum”, ok great, that means “upper bound” and so lines up with §4.4 although the “initial” is surprising since §4.4 doesn’t say anything about the upper limit increasing. It continues: payload before requesting retransmission for the first time. Every time the missing payload is re-requested, the time to wait value doubles. The time to wait is calculated as: Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1)) But this part says it’s (a) an exact time-to-wait, not a “maximum”, and (b) it says it increases exponentially, so NON_RECEIVE_TIMEOUT isn’t a maximum at all, but a minimum. This later text in §7.2 implies that perhaps the problem in the above passages is the word “maximum”, and it should simply be deleted: For the server receiving NON Q-Block1 requests, it SHOULD send back a 2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS payloads to prevent the client unnecessarily delaying. If not all of the MAX_PAYLOADS payloads were received, the server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request count for a payload) before sending the 4.08 (Request Entity Incomplete) Response Code for the missing payload(s). Similarly “up to” in the quote that began this comment should be “at least”. Whether you adopt those suggestions or not, it seems as though all this needs to be rewritten with careful attention to conveying what the desired behavior is. But the plot thickens. Later in §7.2 we have It is likely that the client will start transmitting the next set of MAX_PAYLOADS payloads before the server times out on waiting for the last of the previous MAX_PAYLOADS payloads. On receipt of the first payload from the new set of MAX_PAYLOADS payloads, the server SHOULD send a 4.08 (Request Entity Incomplete) Response Code indicating any missing payloads from any previous MAX_PAYLOADS payloads. The point being that the retransmission request can be triggered by an event other than timer expiration. So in that sense, “maximum” is right — it provides an upper bound on how long to wait before requesting a retransmission — but in another sense it’s wrong because the exponential increase is applied to it. I think the word “maximum” is trying to do too much work, and more words are probably required in order to make this clear. I also think the problem is exacerbated by the fact both §4.4 and §7.2 are talking normatively about how to use NON_RECEIVE_TIMEOUT. It seems as though the main description is found in §7.2, and some confusion would be avoided by making §4.4 less specific, and simply referring forward to §7.2. And, as noted in my DISCUSS, example 10.2.3 muddies the waters still further since it illustrates yet another behavior. 7. Section 4.4 The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2) after the last received payload for NON payloads before issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or more Q-Block2 Options that define the missing blocks with the M bit unset. The client MAY set the M bit to request this and later blocks from this MAX_PAYLOADS set. Further considerations related to the transmission timing for missing requests are discussed in Section 7.2. I find this whole paragraph pretty confusing with the dueling SHOULD and MAY, where it appears the SHOULD might be doing two jobs at once. I *think* your intent is something like the following? “The client SHOULD wait as specified in Section 7.2 for NON payloads before requesting retransmission of any missing blocks. Retransmission is requested by issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or more Q-Block2 Options that define the missing block(s). Generally the M bit on the Q-Block option(s) SHOULD be unset, although the M bit MAY be set to request this and later blocks from this MAX_PAYLOADS set, see Section 10.2.4 for an example of this in operation.” 8. Section 5 If the size of the 4.08 (Request Entity Incomplete) response packet is larger than that defined by Section 4.6 [RFC7252], then the number of missing blocks MUST be limited so that the response can fit into a single packet. If this is the case, then the server can send Suggestion: “then the number of missing blocks reported MUST...” (The thing being limited is not the actual number of missing blocks. You’re limiting the number you report on.) 9. Section 7.1 It is implementation specific as to whether there should be any further requests for missing data as there will have been significant transmission failure as individual payloads will have failed after MAX_TRANSMIT_SPAN. This paragraph seems as though it’s a non-sequitur. It just doesn’t make sense to me. :-( 10. Section 7.2 (This comment relates to the difficulty explained in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.) NON_TIMEOUT is the maximum period of delay between sending sets of MAX_PAYLOADS payloads for the same body. By default, NON_TIMEOUT has the same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]). Presumably the use of “maximum” means it’s fine to delay zero seconds (or any value lower than NON_TIMEOUT). 11. General By the way, none of the timers specify jitter (and indeed, if read literally, jitter would be forbidden). Is this intentional? 12. Section 7.2 If the CoAP peer reports at least one payload has not arrived for each body for at least a 24 hour period and it is known that there are no other network issues over that period, then the value of MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and the situation re-evaluated for another 24 hour period until there is no 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 it is reconfigured. As a consequence of the two peers having different MAX_PAYLOADS values, a peer may continue indicate that there are some missing payloads as all of its MAX_PAYLOADS set may not have arrived. How the two peer values for MAX_PAYLOADS are synchronized is out of the scope. I take it this is just thrown in here as an operational suggestion? It’s not specifying protocol, right? It seems a little misplaced, if so. 13. Section 10.1.3 (This comment relates to the aside in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.) Why doesn’t the server request 1,9,10 in one go? Since its rxmt request is triggered by rx of 11, one would think it could infer 10 had been lost. 14. Section 10.1.4 (also 10.3.3) (This comment relates to the aside in my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.) Why doesn’t reception of a message with More=0 trigger the server to request retransmission of the missing block? Why does it have to wait for timeout? 15. Section 10.2.3 (This comment relates to my DISCUSS. You may want to skip over it until we’ve resolved the DISCUSS, after which this may, or may not, be relevant.) Why doesn’t reception of QB2:10/0/1024 trigger the client to request retransmission? Why does it have to wait for timeout? Similarly reception of QB2:9/1/1024 later in the example. 16. Section 10.2.4 Since MAX_PAYLOADS is 10, why does the example say “MAX_PAYLOADS has been reached” after payloads 2-9 have been retransmitted? That’s only 8 payloads. -- I do have a couple new comments raised during my review of the changes in version 12: (draft-ietf-core-new-block-12) 17. Section 1: This document introduces the CoAP Q-Block1 and Q-Block2 Options which allow block-wise transfer to work with series of Non-confirmable messages, instead of lock-stepping using Confirmable messages (Section 3). In other words, this document provides a missing piece of [RFC7959], namely the support of block-wise transfer using Non- confirmable where an entire body of data can be transmitted without the requirement for an acknowledgement (but recovery is available should it be needed). As far as I can tell the spec does not really remove the requirement for acknowledgement, it just amortizes the acknowledgements by only sending them every MAX_PAYLOADS_SET. Response Code 2.31 is essentially an acknowledgement, and it gets sent that frequently, right? There’s also (if I recall correctly) some flavor of acknowledgement that is sent when the entire body has been transferred. So, I think the new paragraph isn’t accurate. This observation also applies to this claimed benefit in §3: o They support sending an entire body using NON messages without requiring an intermediate response from the peer. Response Code 2.31 is exactly an intermediate response. I guess maybe your focus is that if the intermediate response isn’t received, transmission continues, albeit more slowly than it would otherwise, and unreliably too, so in that sense the responses aren’t “required”. I think this requires awfully close parsing of the word “required”, though. 18. Section 2: MAX_PAYLOADS_SET is the set of blocks identified by block numbers that, when divided by MAX_PAYLOADS, they have the same numeric Remove “they” result. For example, if MAX_PAYLOADS is set to '10', a MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc. Depending on the data size, the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS blocks. I don’t understand the last sentence ("Depending on the data size, the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS blocks.”) Are you trying to say that if the body size isn’t evenly divisible by MAX_PAYLOADS then the final MAX_PAYLOADS_SET will have fewer than MAX_PAYLOADS blocks in it? (I do think this change, to introduce the term MAX_PAYLOADS_SET, is generally helpful; thanks.) From nobody Fri May 21 09:28: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 0CB8C3A16CC; Fri, 21 May 2021 09:28:40 -0700 (PDT) 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 XSKtEPGOM_-G; Fri, 21 May 2021 09:28:35 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 82B003A16CA; Fri, 21 May 2021 09:28:34 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id o21so20695181iow.13; Fri, 21 May 2021 09:28:34 -0700 (PDT) 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=NID2OeeL169r+QR6Vel0Ag0Es6Rg+2IaiuH6A8vhGTs=; b=XKqaLeHYg7jXqTZ7vXyEwgXOtBfFbIQSFWeMKmtERdhN4RjWg/V7DIuAtRwEnXQGo/ FC7swH08+uEq/aAMcUhKg5mbbG3UeUU30hAjksuDg0mSF2O3jjLPi7LzxXFg0/CCamjx VloJOV5CMvl99/E48uIizccoG2kgKiCTzTbX6ZZnkl4LKtZpTOqQR8TIpCe1TH8onCIC M/tReVLQVZPAURndGExIqlKaDxD9WsIaCkhbYweeZNyKoIDsdWxY2gW92kCwg4vw1RLG moq8bp9dGyn2yX7WO6EuZfgEYKWADBCugdbi+dCQRmpLoTLCH5VLg7Y9Yq8d5R5fbJ/b HwAg== 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=NID2OeeL169r+QR6Vel0Ag0Es6Rg+2IaiuH6A8vhGTs=; b=tYs39LWhXzUf6ChpHH7iYFrzs3uMaBOJBvsouYRf3oWr9C9el/7gJeDG93TOzJ7Rcu XEMJqegEyztFCawJv6xGSgmU5+D0S/QvgzAyL+8njDj1IpuddCko2ae3UJgAA0uKZLjL yFj7Hr7vnA80h+0Khe5c4nQ0IZSQCydT3tM+bTOFYJkKCZVesKkInES/rdKGFrjnHtTD rxm6KRQgFQeNGSWV97DB2E5XL02RoQQsDDL7QD7BTvVp36AGg1/sTZb0lG/bGQrD64Sz nsAKx6b8kMUOnEbjHxZi56diuFZvg4QYRf+JjT9Nt6EYWmf14kmLzBS7f3HAoJIjTkJg dzUg== X-Gm-Message-State: AOAM533fnHj7z/b1ggdZFr+B7DkMPEDVQIIc/EmzYWSP2IcgxAukhCRo p9NesLy1uR6uwJTZWqLa9eEKGslFVoBZYo3LRMI= X-Google-Smtp-Source: ABdhPJyi40ru6IrYN5WuT7q+c0vmRNJYw3XgzguRFxD7kFMdwl4zC3tkSKGSsSOhSeamLq3I1sWy4RbGM8Egmw58tYA= X-Received: by 2002:a02:354c:: with SMTP id y12mr5733688jae.144.1621614513309; Fri, 21 May 2021 09:28:33 -0700 (PDT) MIME-Version: 1.0 References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net> <23771_1621516652_60A6616C_23771_79_1_787AE7BB302AE849A7480A190F8B93303538BB63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4833_1621600918_60A7AA96_4833_485_3_787AE7BB302AE849A7480A190F8B93303538C272@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <36A5A92C-AD99-4554-8A09-4E76E60BA98A@juniper.net> In-Reply-To: <36A5A92C-AD99-4554-8A09-4E76E60BA98A@juniper.net> From: Martin Duke Date: Fri, 21 May 2021 09:28:22 -0700 Message-ID: To: John Scudder Cc: "mohamed.boucadair@orange.com" , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "marco.tiloca@ri.se" Content-Type: multipart/alternative; boundary="000000000000074c5c05c2d98d85" Archived-At: Subject: Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (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, 21 May 2021 16:28:40 -0000 --000000000000074c5c05c2d98d85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So I'm not sure that "large numbers" are a sufficient reason to not worry about jitter. If two hosts simultaneously transmit on a quiet network, and cause losses with each other. They both set the same retransmission timeout, and in spite of no other traffic around cause the same collision, etc. If an explicit configuration doesn't result in common round numbers, it's an OK substitute, but I don't see any encouragement of that choice. On Fri, May 21, 2021 at 9:17 AM John Scudder wrote: > Hi Med, > > Your current working copy looks good. I=E2=80=99ve cleared my discuss. > > =E2=80=94John > > > On May 21, 2021, at 8:41 AM, mohamed.boucadair@orange.com wrote: > > > > [External Email. Be cautious of content] > > > > > > Hi John, > > > > As you can see in > https://urldefense.com/v3/__https://tinyurl.com/new-block-latest__;!!NEt6= yMaO-gk!RlDk7GMcbxlFsT2QGl8ma04s1CggmQZQHcIP9aw2R2EP1rWkfQDAbIpzOgyR6g$ > , we went with the following changes to better address your latest commen= t > on the jitter: > > > > (1) be explicit about the formula used for default values: > > > > OLD: > > NON_PROBING_WAIT is used to limit the potential wait needed when > > using PROBING_RATE. By default, NON_PROBING_WAIT has the same value > > as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). > > > > NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. > > By default, NON_PARTIAL_TIMEOUT has the same value as > > EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). > > > > NEW: > > NON_PROBING_WAIT is used to limit the potential wait needed when > > using PROBING_RATE. By default, NON_PROBING_WAIT is computed in the > > same way as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but with > > ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOUT and > > NON_MAX_RETRANSMIT, respectively: > > > > NON_PROBING_WAIT =3D NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1)= * > > ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT > > > > NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. > > By default, NON_PARTIAL_TIMEOUT is computed in the same way as > > EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). This default value > > is calculated in the same way as NON_PROBING_WAIT. > > > > (2) We don=E2=80=99t see a need to apply a jitter when a value is expli= citly > configured (these are expected to be large numbers, we don't care that mu= ch > on the jitter). We added this text to be clear about the intent, and whic= h > BTW reflects the current implementation: > > > > NEW: > > When explicit values are > > configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these > > values are used without applying any jitter. > > > > We also adopted your proposed edits in the message below. > > > > Thank you again for the careful review. This is highly appreciated. > > > > Cheers, > > John & Med > > > >> -----Message d'origine----- > >> De : John Scudder [mailto:jgs@juniper.net] > >> Envoy=C3=A9 : vendredi 21 mai 2021 00:03 > >> =C3=80 : BOUCADAIR Mohamed TGI/OLN > >> Cc : The IESG ; draft-ietf-core-new-block@ietf.org; > >> core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se > >> Objet : Re: John Scudder's Discuss on draft-ietf-core-new-block-11: > >> (with DISCUSS and COMMENT) > >> > >> Hi Mohamed, > >> > >> I think we are converging. My comments in line. I=E2=80=99ve snipped a= greed > >> points for brevity, indicated by [=E2=80=A6]. > >> > >>> On May 20, 2021, at 9:17 AM, mohamed.boucadair@orange.com wrote: > >> > >> [=E2=80=A6] > >> > >>>>>> 11. General > >>>>>> > >>>>>> By the way, none of the timers specify jitter (and indeed, if > >> read > >>>>>> literally, jitter would be forbidden). Is this intentional? > >>>>> > >>>>> No +/- tolerances have been defined. When a timer expires, then > >> the > >>>> next action takes place. > >>>> > >>>> I notice that RFC 7252 jitters its timers, for example: > >>>> > >>>> counter. For a new Confirmable message, the initial timeout is > >> set > >>>> to a random duration (often not an integral number of seconds) > >>>> between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR) (see > >>>> Section 4.8) > >>>> =E2=80=A6 > >>>> ACK_RANDOM_FACTOR MUST NOT be decreased below 1.0, and it SHOULD > >>>> have > >>>> a value that is sufficiently different from 1.0 to provide some > >>>> protection from synchronization effects. > >>>> > >>>> MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT are similarly jittered. A > >>>> number of your introduced parameters > >>>> > >>>> This document introduces new parameters MAX_PAYLOADS, > >> NON_TIMEOUT, > >>>> NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and > >>>> NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3). > >>>> > >>>> appear at least superficially similar to the timers the authors of > >>>> RFC 7252 deemed important to jitter to prevent synchronization > >>>> effects. Did you specifically consider jittering them, and decide > >>>> that jitter was unnecessary? If so, can you explain what is > >> different > >>>> about your specification, compared to the base spec, that > >> eliminates > >>>> the concern? > >>> > >>> RFC7252 introduces ACK_RANDOM_FACTOR jitter and separately jitter > >> for multicast responses (which is not relevant here). > >>> > >>> The ACK_RANDOM_FACTOR is there for when re-transmitting a packet > >> that has not been acknowledged for some reason by its peer. > >> NON_TIMEOUT is for when the next MAX_PAYLOADS_SET can start > >> transmission (not re-transmission) assuming a 'Continue' has not > >> arrived in the interim, and so was not thought necessary to add in > >> ACK_RANDOM_FACTOR style jitter here. > >>> > >>> For NON_RECEIVE_TIMEOUT, what is important is that > >> NON_RECEIVE_TIMEOUT is greater than NON_TIMEOUT (We say in the spec a > >> minimum of one second) so that a peer does not fire off a re- > >> transmission request before the local agent has a chance to start to > >> transmit the next MAX_PAYLOADS_SET. NON_RECEIVE_TIMEOUT is > >> exponentially scaled for each retry to make sure that stability is > >> preserved. So, again, ACK_RANDOM_FACTOR jitter was not thought to be > >> necessary here. > >>> > >>> NON_MAX_RETRANSMIT is a fixed count. > >>> > >>> NON_PROBING_WAIT is used to put a limit on the potential delay that > >> could incur when obeying PROBING_WAIT when there is no peer response. > >> If the implementation goes with the default EXCHANGE_LIFETIME > >> computation, then NON_PROBING_WAIT includes ACK_RANDOM_FACTOR in the > >> math. > >>> > >>> NON_PARTIAL_TIMEOUT if computed using the default EXCHANGE_LIFETIME > >> includes ACK_RANDOM_FACTOR. > >> > >> Thanks for taking the time to explain. You don=E2=80=99t comment regar= ding > >> whether NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT should be jittered > >> or not, you just explain that if they use the default they get jitter > >> =E2=80=9Cfor free=E2=80=9D. The missing detail is that if they don=E2= =80=99t use the default > >> they don=E2=80=99t get jittered, so I think some consideration is stil= l > >> called for regarding whether having them not be jittered is OK. > >> > >> [=E2=80=A6] > >> > >>>>>> 15. Section 10.2.3 > >> > >> [=E2=80=A6] > >> > >>>> One concern related to that: waiting NON_TIMEOUT isn=E2=80=99t actua= lly > >>>> required, it=E2=80=99s only RECOMMENDED, therefore this isn=E2=80=99= t actually a > >>>> guarantee. From =C2=A77.2: > >>>> > >>>> As the sending of many payloads of a single body may itself > >> cause > >>>> congestion, it is RECOMMENDED that after transmission of every > >>>> MAX_PAYLOADS_SET of a single body, a delay is introduced of > >>>> NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage > >>>> potential congestion issues. > >>>> > >>>> I am curious why you made this a RECOMMENDED instead of a MUST. In > >> a > >>>> situation like this it would be preferable for you to explain to > >> the > >>>> implementor what situation they can ignore the RECOMMENDED in and > >>>> what they should do instead, or of course to make it into a MUST. > >>> > >>> Because a continue signal may be received from the peer and then > >> continue without waiting for the timeout to expire. > >>> > >>> This is to be linked with this text: > >>> > >>> A response using this Response Code SHOULD NOT be generated > >> for > >>> every received Q-Block1 Option request (Section 7.2). It > >> SHOULD > >>> only be generated when all the payload requests are Non- > >>> confirmable and a MAX_PAYLOADS_SET has been received by the > >>> server. More details about the motivations for this > >> optimization > >>> > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>> are discussed in Section 7.2. > >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>> > >>> We could use **MUST unless a 'Continue' is received**, e.g., > >>> > >>> OLD: > >>> As the sending of many payloads of a single body may itself cause > >>> congestion, it is RECOMMENDED that after transmission of every > >>> MAX_PAYLOADS_SET of a single body, a delay is introduced of > >>> NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage > >>> potential congestion issues. > >>> > >>> NEW: > >>> As the sending of many payloads of a single body may itself cause > >>> congestion, after transmission of every MAX_PAYLOADS_SET of a > >> single > >>> body, a delay MUST be introduced of NON_TIMEOUT before sending > >> the > >>> next MAX_PAYLOADS_SET to manage potential congestion issues. > >>> However, if a 'Continue' is received from the peer for the > >> current > >>> MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET can start > >>> transmission immediately. > >>> > >>> ... but I know that many would argue this is a SHOULD. > >> > >> I would be OK with either your proposed new text, or a SHOULD/MAY > >> pair as in > >> > >> NEW: > >> As the sending of many payloads of a single body may itself cause > >> congestion, after transmission of every MAX_PAYLOADS_SET of a > >> single > >> body, a delay SHOULD be introduced of NON_TIMEOUT before sending > >> the > >> next MAX_PAYLOADS_SET to manage potential congestion issues. > >> However, if a 'Continue' is received from the peer for the current > >> MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET MAY start > >> transmission immediately. > >> > >> If you want to stick with MUST I think you can clear up the pain with > >> something like > >> > >> NEW: > >> As the sending of many payloads of a single body may itself cause > >> congestion, after transmission of every MAX_PAYLOADS_SET of a > >> single > >> body, a delay MUST be introduced of NON_TIMEOUT before sending the > >> next MAX_PAYLOADS_SET unless a 'Continue' is received from the peer > >> for the current MAX_PAYLOADS_SET, in which case the next > >> MAX_PAYLOADS_SET MAY start transmission immediately. > >> > >> (To my eye presenting the option in this way makes it clear when the > >> MUST does, and doesn=E2=80=99t, apply. This is my preferred form but I= don=E2=80=99t > >> insist.) > >> > >> [=E2=80=A6] > >> > >>>> 17. Section 1: > >>>> > >>>> This document introduces the CoAP Q-Block1 and Q-Block2 Options > >>>> which > >>>> allow block-wise transfer to work with series of Non-confirmable > >>>> messages, instead of lock-stepping using Confirmable messages > >>>> (Section 3). In other words, this document provides a missing > >>>> piece > >>>> of [RFC7959], namely the support of block-wise transfer using > >> Non- > >>>> confirmable where an entire body of data can be transmitted > >> without > >>>> the requirement for an acknowledgement (but recovery is > >> available > >>>> should it be needed). > >>>> > >>>> As far as I can tell the spec does not really remove the > >> requirement > >>>> for acknowledgement, > >>> > >>> These are not required. They were added as an optimization to avoid > >> the non-timeout if the peer decides to use it. > >> > >> As I mentioned below (=E2=80=9Cawfully close parsing=E2=80=9D), I thin= k that although > >> you can find some justification for this reading, it=E2=80=99s debatab= le. > >> Transmission of the acknowledgement (at least the final > >> acknowledgement of the entire body, in the form of a Response Code) > >> is required, is it not? Reception isn=E2=80=99t required though. Witho= ut the > >> verb, I=E2=80=99m not sure whether I can say whether acknowledgement i= s, or > >> isn=E2=80=99t, required. > >> > >> I don=E2=80=99t insist that you change this, but I do think you could = improve > >> the clarity of the document, if you edited the above to read =E2=80=9C= =E2=80=A6 > >> without the requirement that an acknowledgment be received from the > >> peer" > >> > >>>> it just amortizes the acknowledgements by only sending them every > >>>> MAX_PAYLOADS_SET. Response Code 2.31 is essentially an > >>>> acknowledgement, and it gets sent that frequently, right? There=E2= =80=99s > >>>> also (if I recall correctly) some flavor of acknowledgement that > >> is > >>>> sent when the entire body has been transferred. So, I think the > >> new > >>>> paragraph isn=E2=80=99t accurate. > >>>> > >>>> This observation also applies to this claimed benefit in =C2=A73: > >>>> > >>>> o They support sending an entire body using NON messages > >> without > >>>> requiring an intermediate response from the peer. > >> > >> And similarly, =E2=80=9C=E2=80=A6 without requiring that an intermedia= te response be > >> received from the peer.=E2=80=9D > >> > >> [=E2=80=A6] > >> > >>>> 18. Section 2: > >>>> > >>>> MAX_PAYLOADS_SET is the set of blocks identified by block > >> numbers > >>>> that, when divided by MAX_PAYLOADS, they have the same numeric > >>>> > >>>> Remove =E2=80=9Cthey=E2=80=9D > >>> > >>> Fixed. Thanks. > >>> > >>>> > >>>> result. For example, if MAX_PAYLOADS is set to '10', a > >>>> MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc. > >>>> Depending on the data size, the MAX_PAYLOADS_SET may not > >> comprise > >>>> all > >>>> the MAX_PAYLOADS blocks. > >>>> > >>>> I don=E2=80=99t understand the last sentence ("Depending on the data= size, > >>>> the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS > >> blocks.=E2=80=9D) > >>>> Are you trying to say that if the body size isn=E2=80=99t evenly div= isible > >> by > >>>> MAX_PAYLOADS then the final MAX_PAYLOADS_SET will have fewer than > >>>> MAX_PAYLOADS blocks in it? > >>> > >>> We meant that the last set may include fewer blocks than > >> MAX_PAYLOADS. Changed to: > >>> > >>> " Depending on the overall data > >>> ^^^^^^^^ > >>> size, the final MAX_PAYLOADS_SET may not comprise all the > >>> ^^^^^ > >>> MAX_PAYLOADS blocks. " > >>> > >>> Better? > >> > >> Improving. The word =E2=80=9Ccomprise=E2=80=9D is prone to misinterpre= tation in my > >> experience, I would suggest something like =E2=80=9C=E2=80=A6 there co= uld be fewer > >> than MAX_PAYLOADS blocks in the final MAX_PAYLOADS_SET.=E2=80=9D > >> > >> Thanks, > >> > >> =E2=80=94John > > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles 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 > been modified, changed or falsified. > > Thank you. > > > > --000000000000074c5c05c2d98d85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So I'm not sure that "large numbers" ar= e a sufficient reason to not worry about jitter.

I= f two hosts simultaneously transmit on a quiet network, and cause losses wi= th each other. They both set the same retransmission timeout, and in spite = of no other traffic around cause the same collision, etc.

If an explicit configuration doesn't result in common round num= bers, it's an OK substitute, but I don't see any encouragement of t= hat choice.

On Fri, May 21, 2021 at 9:17 AM John Scudder <jgs= =3D40juniper.net@dmarc.ietf= .org> wrote:
Hi Med,

Your current working copy looks good. I=E2=80=99ve cleared my discuss.

=E2=80=94John

> On May 21, 2021, at 8:41 AM, mohamed.boucadair@orange.com wrote:
>
> [External Email. Be cautious of content]
>
>
> Hi John,
>
> As you can see in https://= urldefense.com/v3/__https://tinyurl.com/new-block-latest__;!!NEt6yMaO-gk!Rl= Dk7GMcbxlFsT2QGl8ma04s1CggmQZQHcIP9aw2R2EP1rWkfQDAbIpzOgyR6g$ , we went= with the following changes to better address your latest comment on the ji= tter:
>
> (1) be explicit about the formula used for default values:
>
> OLD:
>=C2=A0 =C2=A0NON_PROBING_WAIT is used to limit the potential wait neede= d when
>=C2=A0 =C2=A0using PROBING_RATE.=C2=A0 By default, NON_PROBING_WAIT has= the same value
>=C2=A0 =C2=A0as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
>
>=C2=A0 =C2=A0NON_PARTIAL_TIMEOUT is used for expiring partially receive= d bodies.
>=C2=A0 =C2=A0By default, NON_PARTIAL_TIMEOUT has the same value as
>=C2=A0 =C2=A0EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
>
> NEW:
>=C2=A0 =C2=A0NON_PROBING_WAIT is used to limit the potential wait neede= d when
>=C2=A0 =C2=A0using PROBING_RATE.=C2=A0 By default, NON_PROBING_WAIT is = computed in the
>=C2=A0 =C2=A0same way as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252])= but with
>=C2=A0 =C2=A0ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOU= T and
>=C2=A0 =C2=A0NON_MAX_RETRANSMIT, respectively:
>
>=C2=A0 =C2=A0 =C2=A0 NON_PROBING_WAIT =3D NON_TIMEOUT * ((2 ** NON_MAX_= RETRANSMIT) - 1) *
>=C2=A0 =C2=A0 =C2=A0 ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOU= T
>
>=C2=A0 =C2=A0NON_PARTIAL_TIMEOUT is used for expiring partially receive= d bodies.
>=C2=A0 =C2=A0By default, NON_PARTIAL_TIMEOUT is computed in the same wa= y as
>=C2=A0 =C2=A0EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).=C2=A0 This= default value
>=C2=A0 =C2=A0is calculated in the same way as NON_PROBING_WAIT.
>
> (2) We don=E2=80=99t see a need to apply a jitter when a value is expl= icitly configured (these are expected to be large numbers, we don't car= e that much on the jitter). We added this text to be clear about the intent= , and which BTW reflects the current implementation:
>
> NEW:
>=C2=A0 =C2=A0 =C2=A0 When explicit values are
>=C2=A0 =C2=A0 =C2=A0 configured for NON_PROBING_WAIT and NON_PARTIAL_TI= MEOUT, these
>=C2=A0 =C2=A0 =C2=A0 values are used without applying any jitter.
>
> We also adopted your proposed edits in the message below.
>
> Thank you again for the careful review. This is highly appreciated. >
> Cheers,
> John & Med
>
>> -----Message d'origine-----
>> De : John Scudder [mailto:jgs@juniper.net]
>> Envoy=C3=A9 : vendredi 21 mai 2021 00:03
>> =C3=80 : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>=
>> Cc : The IESG <iesg@ietf.org>; draft-ietf-core-new-block@ietf.org;
>> core-cha= irs@ietf.org; core@i= etf.org; marco.= tiloca@ri.se
>> Objet : Re: John Scudder's Discuss on draft-ietf-core-new-bloc= k-11:
>> (with DISCUSS and COMMENT)
>>
>> Hi Mohamed,
>>
>> I think we are converging. My comments in line. I=E2=80=99ve snipp= ed agreed
>> points for brevity, indicated by [=E2=80=A6].
>>
>>> On May 20, 2021, at 9:17 AM, mohamed.boucadair@orange.com wrote: >>
>> [=E2=80=A6]
>>
>>>>>> 11. General
>>>>>>
>>>>>> By the way, none of the timers specify jitter (and= indeed, if
>> read
>>>>>> literally, jitter would be forbidden). Is this int= entional?
>>>>>
>>>>> No +/- tolerances have been defined. When a timer expi= res, then
>> the
>>>> next action takes place.
>>>>
>>>> I notice that RFC 7252 jitters its timers, for example: >>>>
>>>>=C2=A0 counter.=C2=A0 For a new Confirmable message, the in= itial timeout is
>> set
>>>>=C2=A0 to a random duration (often not an integral number o= f seconds)
>>>>=C2=A0 between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FA= CTOR) (see
>>>>=C2=A0 Section 4.8)
>>>> =E2=80=A6
>>>>=C2=A0 ACK_RANDOM_FACTOR MUST NOT be decreased below 1.0, a= nd it SHOULD
>>>> have
>>>>=C2=A0 a value that is sufficiently different from 1.0 to p= rovide some
>>>>=C2=A0 protection from synchronization effects.
>>>>
>>>> MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT are similarly jitt= ered. A
>>>> number of your introduced parameters
>>>>
>>>>=C2=A0 This document introduces new parameters MAX_PAYLOADS= ,
>> NON_TIMEOUT,
>>>>=C2=A0 NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING= _WAIT, and
>>>>=C2=A0 NON_PARTIAL_TIMEOUT primarily for use with NON (Tabl= e 3).
>>>>
>>>> appear at least superficially similar to the timers the au= thors of
>>>> RFC 7252 deemed important to jitter to prevent synchroniza= tion
>>>> effects. Did you specifically consider jittering them, and= decide
>>>> that jitter was unnecessary? If so, can you explain what i= s
>> different
>>>> about your specification, compared to the base spec, that<= br> >> eliminates
>>>> the concern?
>>>
>>> RFC7252 introduces ACK_RANDOM_FACTOR jitter and separately jit= ter
>> for multicast responses (which is not relevant here).
>>>
>>> The ACK_RANDOM_FACTOR is there for when re-transmitting a pack= et
>> that has not been acknowledged for some reason by its peer.
>> NON_TIMEOUT is for when the next MAX_PAYLOADS_SET can start
>> transmission (not re-transmission) assuming a 'Continue' h= as not
>> arrived in the interim, and so was not thought necessary to add in=
>> ACK_RANDOM_FACTOR style jitter here.
>>>
>>> For NON_RECEIVE_TIMEOUT, what is important is that
>> NON_RECEIVE_TIMEOUT is greater than NON_TIMEOUT (We say in the spe= c a
>> minimum of one second) so that a peer does not fire off a re-
>> transmission request before the local agent has a chance to start = to
>> transmit the next MAX_PAYLOADS_SET.=C2=A0 NON_RECEIVE_TIMEOUT is >> exponentially scaled for each retry to make sure that stability is=
>> preserved. So, again, ACK_RANDOM_FACTOR jitter was not thought to = be
>> necessary here.
>>>
>>> NON_MAX_RETRANSMIT is a fixed count.
>>>
>>> NON_PROBING_WAIT is used to put a limit on the potential delay= that
>> could incur when obeying PROBING_WAIT when there is no peer respon= se.
>> If the implementation goes with the default EXCHANGE_LIFETIME
>> computation, then NON_PROBING_WAIT includes ACK_RANDOM_FACTOR in t= he
>> math.
>>>
>>> NON_PARTIAL_TIMEOUT if computed using the default EXCHANGE_LIF= ETIME
>> includes ACK_RANDOM_FACTOR.
>>
>> Thanks for taking the time to explain. You don=E2=80=99t comment r= egarding
>> whether NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT should be jittere= d
>> or not, you just explain that if they use the default they get jit= ter
>> =E2=80=9Cfor free=E2=80=9D. The missing detail is that if they don= =E2=80=99t use the default
>> they don=E2=80=99t get jittered, so I think some consideration is = still
>> called for regarding whether having them not be jittered is OK. >>
>> [=E2=80=A6]
>>
>>>>>> 15. Section 10.2.3
>>
>> [=E2=80=A6]
>>
>>>> One concern related to that: waiting NON_TIMEOUT isn=E2=80= =99t actually
>>>> required, it=E2=80=99s only RECOMMENDED, therefore this is= n=E2=80=99t actually a
>>>> guarantee. From =C2=A77.2:
>>>>
>>>>=C2=A0 As the sending of many payloads of a single body may= itself
>> cause
>>>>=C2=A0 congestion, it is RECOMMENDED that after transmissio= n of every
>>>>=C2=A0 MAX_PAYLOADS_SET of a single body, a delay is introd= uced of
>>>>=C2=A0 NON_TIMEOUT before sending the next MAX_PAYLOADS_SET= to manage
>>>>=C2=A0 potential congestion issues.
>>>>
>>>> I am curious why you made this a RECOMMENDED instead of a = MUST. In
>> a
>>>> situation like this it would be preferable for you to expl= ain to
>> the
>>>> implementor what situation they can ignore the RECOMMENDED= in and
>>>> what they should do instead, or of course to make it into = a MUST.
>>>
>>> Because a continue signal may be received from the peer and th= en
>> continue without waiting for the timeout to expire.
>>>
>>> This is to be linked with this text:
>>>
>>>=C2=A0 =C2=A0 =C2=A0A response using this Response Code SHOULD = NOT be generated
>> for
>>>=C2=A0 =C2=A0 =C2=A0every received Q-Block1 Option request (Sec= tion 7.2).=C2=A0 It
>> SHOULD
>>>=C2=A0 =C2=A0 =C2=A0only be generated when all the payload requ= ests are Non-
>>>=C2=A0 =C2=A0 =C2=A0confirmable and a MAX_PAYLOADS_SET has been= received by the
>>>=C2=A0 =C2=A0 =C2=A0 server.=C2=A0 More details about the motiv= ations for this
>> optimization
>>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>=C2=A0 =C2=A0 =C2=A0are discussed in Section 7.2.
>>>=C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>
>>> We could use **MUST unless a 'Continue' is received**,= e.g.,
>>>
>>> OLD:
>>>=C2=A0 As the sending of many payloads of a single body may its= elf cause
>>>=C2=A0 congestion, it is RECOMMENDED that after transmission of= every
>>>=C2=A0 MAX_PAYLOADS_SET of a single body, a delay is introduced= of
>>>=C2=A0 NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to = manage
>>>=C2=A0 potential congestion issues.
>>>
>>> NEW:
>>>=C2=A0 As the sending of many payloads of a single body may its= elf cause
>>>=C2=A0 congestion, after transmission of every MAX_PAYLOADS_SET= of a
>> single
>>>=C2=A0 body, a delay MUST be introduced of NON_TIMEOUT before s= ending
>> the
>>>=C2=A0 next MAX_PAYLOADS_SET to manage potential congestion iss= ues.
>>>=C2=A0 However, if a 'Continue' is received from the pe= er for the
>> current
>>>=C2=A0 MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET can sta= rt
>>>=C2=A0 transmission immediately.
>>>
>>> ... but I know that many would argue this is a SHOULD.
>>
>> I would be OK with either your proposed new text, or a SHOULD/MAY<= br> >> pair as in
>>
>> NEW:
>>=C2=A0 As the sending of many payloads of a single body may itself = cause
>>=C2=A0 congestion, after transmission of every MAX_PAYLOADS_SET of = a
>> single
>>=C2=A0 body, a delay SHOULD be introduced of NON_TIMEOUT before sen= ding
>> the
>>=C2=A0 next MAX_PAYLOADS_SET to manage potential congestion issues.=
>>=C2=A0 However, if a 'Continue' is received from the peer f= or the current
>>=C2=A0 MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET MAY start >>=C2=A0 transmission immediately.
>>
>> If you want to stick with MUST I think you can clear up the pain w= ith
>> something like
>>
>> NEW:
>>=C2=A0 As the sending of many payloads of a single body may itself = cause
>>=C2=A0 congestion, after transmission of every MAX_PAYLOADS_SET of = a
>> single
>>=C2=A0 body, a delay MUST be introduced of NON_TIMEOUT before sendi= ng the
>>=C2=A0 next MAX_PAYLOADS_SET unless a 'Continue' is receive= d from the peer
>>=C2=A0 for the current MAX_PAYLOADS_SET, in which case the next
>>=C2=A0 MAX_PAYLOADS_SET MAY start transmission immediately.
>>
>> (To my eye presenting the option in this way makes it clear when t= he
>> MUST does, and doesn=E2=80=99t, apply. This is my preferred form b= ut I don=E2=80=99t
>> insist.)
>>
>> [=E2=80=A6]
>>
>>>> 17. Section 1:
>>>>
>>>>=C2=A0 This document introduces the CoAP Q-Block1 and Q-Blo= ck2 Options
>>>> which
>>>>=C2=A0 allow block-wise transfer to work with series of Non= -confirmable
>>>>=C2=A0 messages, instead of lock-stepping using Confirmable= messages
>>>>=C2=A0 (Section 3).=C2=A0 In other words, this document pro= vides a missing
>>>> piece
>>>>=C2=A0 of [RFC7959], namely the support of block-wise trans= fer using
>> Non-
>>>>=C2=A0 confirmable where an entire body of data can be tran= smitted
>> without
>>>>=C2=A0 the requirement for an acknowledgement (but recovery= is
>> available
>>>>=C2=A0 should it be needed).
>>>>
>>>> As far as I can tell the spec does not really remove the >> requirement
>>>> for acknowledgement,
>>>
>>> These are not required. They were added as an optimization to = avoid
>> the non-timeout if the peer decides to use it.
>>
>> As I mentioned below (=E2=80=9Cawfully close parsing=E2=80=9D), I = think that although
>> you can find some justification for this reading, it=E2=80=99s deb= atable.
>> Transmission of the acknowledgement (at least the final
>> acknowledgement of the entire body, in the form of a Response Code= )
>> is required, is it not? Reception isn=E2=80=99t required though. W= ithout the
>> verb, I=E2=80=99m not sure whether I can say whether acknowledgeme= nt is, or
>> isn=E2=80=99t, required.
>>
>> I don=E2=80=99t insist that you change this, but I do think you co= uld improve
>> the clarity of the document, if you edited the above to read =E2= =80=9C=E2=80=A6
>> without the requirement that an acknowledgment be received from th= e
>> peer"
>>
>>>> it just amortizes the acknowledgements by only sending the= m every
>>>> MAX_PAYLOADS_SET. Response Code 2.31 is essentially an
>>>> acknowledgement, and it gets sent that frequently, right? = There=E2=80=99s
>>>> also (if I recall correctly) some flavor of acknowledgemen= t that
>> is
>>>> sent when the entire body has been transferred. So, I thin= k the
>> new
>>>> paragraph isn=E2=80=99t accurate.
>>>>
>>>> This observation also applies to this claimed benefit in = =C2=A73:
>>>>
>>>>=C2=A0 o=C2=A0 They support sending an entire body using NO= N messages
>> without
>>>>=C2=A0 =C2=A0 =C2=A0requiring an intermediate response from= the peer.
>>
>> And similarly, =E2=80=9C=E2=80=A6 without requiring that an interm= ediate response be
>> received from the peer.=E2=80=9D
>>
>> [=E2=80=A6]
>>
>>>> 18. Section 2:
>>>>
>>>>=C2=A0 MAX_PAYLOADS_SET is the set of blocks identified by = block
>> numbers
>>>>=C2=A0 that, when divided by MAX_PAYLOADS, they have the sa= me numeric
>>>>
>>>> Remove =E2=80=9Cthey=E2=80=9D
>>>
>>> Fixed. Thanks.
>>>
>>>>
>>>>=C2=A0 result.=C2=A0 For example, if MAX_PAYLOADS is set to= '10', a
>>>>=C2=A0 MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #1= 9, etc.
>>>>=C2=A0 Depending on the data size, the MAX_PAYLOADS_SET may= not
>> comprise
>>>> all
>>>>=C2=A0 the MAX_PAYLOADS blocks.
>>>>
>>>> I don=E2=80=99t understand the last sentence ("Depend= ing on the data size,
>>>> the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS=
>> blocks.=E2=80=9D)
>>>> Are you trying to say that if the body size isn=E2=80=99t = evenly divisible
>> by
>>>> MAX_PAYLOADS then the final MAX_PAYLOADS_SET will have few= er than
>>>> MAX_PAYLOADS blocks in it?
>>>
>>> We meant that the last set may include fewer blocks than
>> MAX_PAYLOADS. Changed to:
>>>
>>> " Depending on the overall data
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0^^^^^^^^
>>>=C2=A0 size, the final MAX_PAYLOADS_SET may not comprise all th= e
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^
>>>=C2=A0 MAX_PAYLOADS blocks. "
>>>
>>> Better?
>>
>> Improving. The word =E2=80=9Ccomprise=E2=80=9D is prone to misinte= rpretation in my
>> experience, I would suggest something like =E2=80=9C=E2=80=A6 ther= e could be fewer
>> than MAX_PAYLOADS blocks in the final MAX_PAYLOADS_SET.=E2=80=9D >>
>> Thanks,
>>
>> =E2=80=94John
>
> ______________________________________________________________________= ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 me= ssages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privilege= d information that may be protected by law;
> they should not be distributed, used or copied without authorisation.<= br> > 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 = been modified, changed or falsified.
> Thank you.
>

--000000000000074c5c05c2d98d85-- From nobody Fri May 21 10:27:24 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 2358E3A18B5; Fri, 21 May 2021 10:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 Uh4JREs1Dm2u; Fri, 21 May 2021 10:27:13 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (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 55F9E3A18B2; Fri, 21 May 2021 10:27:12 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 4Fmtp45cmVz7vgt; Fri, 21 May 2021 19:27:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1621618028; bh=J5p5vPs1bJ3vEgE+zjpzm7HzpAs7HdXVqc9heazxtjg=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=TWD1HCBF0Bzw71My09FXDUTiCvaOym2A965qIKcqYa4vXuHj9EZku8suQG97S1Cmm pZNDdsPUuwzgBQSjAZjgQ/LsngNhaXyrh9sfBl+IAuFnxE3YQPALKvN2EKxtMMt3it BnZuhGOsdWaI8xve/lm7zoZN4zXXduRo3MMk8mKNxU7Rw56oiJw9orWUO+TvyOpIDR Lnl/DORnLbF0AFIZkwl+cMUY4M/2p0j0h6lNzqpkHI9GCuoIw9a4eeCqmNUEwn/hZz Ke6f7zIHi0UHCmzmjG/We+ktJjUz2jQ5kzzx8Ji9fZJDtRI0VsjeO88HF2RK3WDzQn oEXiVlpzdFtPQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 4Fmtp43rDVzCqkc; Fri, 21 May 2021 19:27:08 +0200 (CEST) From: To: Martin Duke , John Scudder CC: "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXQhCbJLPvcFdg/UKru2kURMqcWqrXeDkAgBPx5ACAAQGlMIAAmAIAgADwZ6CAAEEXAP//4bcAgAAsbMA= Date: Fri, 21 May 2021 17:27:08 +0000 Message-ID: <17420_1621618028_60A7ED6C_17420_17_28_787AE7BB302AE849A7480A190F8B93303538C6AB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net> <23771_1621516652_60A6616C_23771_79_1_787AE7BB302AE849A7480A190F8B93303538BB63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4833_1621600918_60A7AA96_4833_485_3_787AE7BB302AE849A7480A190F8B93303538C272@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <36A5A92C-AD99-4554-8A09-4E76E60BA98A@juniper.net> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303538C6ABOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (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, 21 May 2021 17:27:18 -0000 --_000_787AE7BB302AE849A7480A190F8B93303538C6ABOPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFydGluLA0KDQpUaGUgY29tbWVudCBhYm91dCBsYXJnZSBudW1iZXJzIHNob3VsZCBiZSBw dXQgaW4gdGhlIGNvbnRleHQgb2YgdGhlIHR3byB0aW1lb3V0cyBkaXNjdXNzZWQgd2l0aCBKb2hu OiBOT05fUEFSVElBTF9USU1FT1VUIGFuZCBOT05fUFJPQklOR19XQUlULiBDb25zaWRlciB0aGUg ZXhhbXBsZSBvZiBOT05fUEFSVElBTF9USU1FT1VULCBhZGRpbmcgc29tZSBqaXR0ZXIgdG8gaXQg aXMgdW5saWtlbHkgdG8gaGF2ZSBhbiBlZmZlY3QgYXMgdGhhdCB0aW1lciBpcyBhYm91dCBjb250 cm9sbGluZyB3aGVuIGEgcmVjZWl2ZWQgcGFydGlhbCBib2R5IHdpbGwgYmUgZGlzY2FyZGVkIGxv Y2FsbHkuDQoNCk5PTl9QUk9CSU5HX1dBSVQgaXMgYWJvdXQgbGltaXRpbmcgdGhlIGVmZmVjdCBv ZiBQUk9CSU5HX1JBVEUgd2hlbiBhIHBlZXIgZG9lcyBub3QgcmVwbHkuIEFzIGEgcmVtaW5kZXIs IHByb2JpbmcgcmF0ZSBpcyBkZWZpbmVkIGFzIGZvbGxvd3M6DQoNCiAgIFRoZSBQUk9CSU5HX1JB VEUgcGFyYW1ldGVyIGluIENvQVAgaW5kaWNhdGVzIHRoZSBhdmVyYWdlIGRhdGEgcmF0ZQ0KICAg dGhhdCBtdXN0IG5vdCBiZSBleGNlZWRlZCBieSBhIENvQVAgZW5kcG9pbnQgaW4gc2VuZGluZyB0 byBhIHBlZXINCiAgIGVuZHBvaW50IHRoYXQgZG9lcyBub3QgcmVzcG9uZC4NCg0KQ2hlZXJzLA0K TWVkDQoNCkRlIDogTWFydGluIER1a2UgW21haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbV0N CkVudm95w6kgOiB2ZW5kcmVkaSAyMSBtYWkgMjAyMSAxODoyOA0Kw4AgOiBKb2huIFNjdWRkZXIg PGpncz00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPg0KQ2MgOiBCT1VDQURBSVIgTW9oYW1l ZCBUR0kvT0xOIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPjsgZHJhZnQtaWV0Zi1jb3Jl LW5ldy1ibG9ja0BpZXRmLm9yZzsgY29yZS1jaGFpcnNAaWV0Zi5vcmc7IFRoZSBJRVNHIDxpZXNn QGlldGYub3JnPjsgY29yZUBpZXRmLm9yZzsgbWFyY28udGlsb2NhQHJpLnNlDQpPYmpldCA6IFJl OiBKb2huIFNjdWRkZXIncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMTE6 ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNClNvIEknbSBub3Qgc3VyZSB0aGF0ICJsYXJn ZSBudW1iZXJzIiBhcmUgYSBzdWZmaWNpZW50IHJlYXNvbiB0byBub3Qgd29ycnkgYWJvdXQgaml0 dGVyLg0KDQpJZiB0d28gaG9zdHMgc2ltdWx0YW5lb3VzbHkgdHJhbnNtaXQgb24gYSBxdWlldCBu ZXR3b3JrLCBhbmQgY2F1c2UgbG9zc2VzIHdpdGggZWFjaCBvdGhlci4gVGhleSBib3RoIHNldCB0 aGUgc2FtZSByZXRyYW5zbWlzc2lvbiB0aW1lb3V0LCBhbmQgaW4gc3BpdGUgb2Ygbm8gb3RoZXIg dHJhZmZpYyBhcm91bmQgY2F1c2UgdGhlIHNhbWUgY29sbGlzaW9uLCBldGMuDQoNCklmIGFuIGV4 cGxpY2l0IGNvbmZpZ3VyYXRpb24gZG9lc24ndCByZXN1bHQgaW4gY29tbW9uIHJvdW5kIG51bWJl cnMsIGl0J3MgYW4gT0sgc3Vic3RpdHV0ZSwgYnV0IEkgZG9uJ3Qgc2VlIGFueSBlbmNvdXJhZ2Vt ZW50IG9mIHRoYXQgY2hvaWNlLg0KDQpPbiBGcmksIE1heSAyMSwgMjAyMSBhdCA5OjE3IEFNIEpv aG4gU2N1ZGRlciA8amdzPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwanVu aXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkhpIE1lZCwNCg0KWW91ciBjdXJyZW50 IHdvcmtpbmcgY29weSBsb29rcyBnb29kLiBJ4oCZdmUgY2xlYXJlZCBteSBkaXNjdXNzLg0KDQri gJRKb2huDQoNCj4gT24gTWF5IDIxLCAyMDIxLCBhdCA4OjQxIEFNLCBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToN Cj4NCj4gW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KPg0KPg0KPiBI aSBKb2huLA0KPg0KPiBBcyB5b3UgY2FuIHNlZSBpbiBodHRwczovL3VybGRlZmVuc2UuY29tL3Yz L19faHR0cHM6Ly90aW55dXJsLmNvbS9uZXctYmxvY2stbGF0ZXN0X187ISFORXQ2eU1hTy1nayFS bERrN0dNY2J4bEZzVDJRR2w4bWEwNHMxQ2dnbVFaUUhjSVA5YXcyUjJFUDFyV2tmUURBYklwek9n eVI2ZyQ8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi90aW55dXJsLmNvbS9uZXct YmxvY2stbGF0ZXN0X187ISFORXQ2eU1hTy1nayFSbERrN0dNY2J4bEZzVDJRR2w4bWEwNHMxQ2dn bVFaUUhjSVA5YXcyUjJFUDFyV2tmUURBYklwek9neVI2ZyQ+ICwgd2Ugd2VudCB3aXRoIHRoZSBm b2xsb3dpbmcgY2hhbmdlcyB0byBiZXR0ZXIgYWRkcmVzcyB5b3VyIGxhdGVzdCBjb21tZW50IG9u IHRoZSBqaXR0ZXI6DQo+DQo+ICgxKSBiZSBleHBsaWNpdCBhYm91dCB0aGUgZm9ybXVsYSB1c2Vk IGZvciBkZWZhdWx0IHZhbHVlczoNCj4NCj4gT0xEOg0KPiAgIE5PTl9QUk9CSU5HX1dBSVQgaXMg dXNlZCB0byBsaW1pdCB0aGUgcG90ZW50aWFsIHdhaXQgbmVlZGVkIHdoZW4NCj4gICB1c2luZyBQ Uk9CSU5HX1JBVEUuICBCeSBkZWZhdWx0LCBOT05fUFJPQklOR19XQUlUIGhhcyB0aGUgc2FtZSB2 YWx1ZQ0KPiAgIGFzIEVYQ0hBTkdFX0xJRkVUSU1FIChTZWN0aW9uIDQuOC4yIG9mIFtSRkM3MjUy XSkuDQo+DQo+ICAgTk9OX1BBUlRJQUxfVElNRU9VVCBpcyB1c2VkIGZvciBleHBpcmluZyBwYXJ0 aWFsbHkgcmVjZWl2ZWQgYm9kaWVzLg0KPiAgIEJ5IGRlZmF1bHQsIE5PTl9QQVJUSUFMX1RJTUVP VVQgaGFzIHRoZSBzYW1lIHZhbHVlIGFzDQo+ICAgRVhDSEFOR0VfTElGRVRJTUUgKFNlY3Rpb24g NC44LjIgb2YgW1JGQzcyNTJdKS4NCj4NCj4gTkVXOg0KPiAgIE5PTl9QUk9CSU5HX1dBSVQgaXMg dXNlZCB0byBsaW1pdCB0aGUgcG90ZW50aWFsIHdhaXQgbmVlZGVkIHdoZW4NCj4gICB1c2luZyBQ Uk9CSU5HX1JBVEUuICBCeSBkZWZhdWx0LCBOT05fUFJPQklOR19XQUlUIGlzIGNvbXB1dGVkIGlu IHRoZQ0KPiAgIHNhbWUgd2F5IGFzIEVYQ0hBTkdFX0xJRkVUSU1FIChTZWN0aW9uIDQuOC4yIG9m IFtSRkM3MjUyXSkgYnV0IHdpdGgNCj4gICBBQ0tfVElNRU9VVCBhbmQgTUFYX1JFVFJBTlNNSVQg c3Vic3RpdHV0ZWQgd2l0aCBOT05fVElNRU9VVCBhbmQNCj4gICBOT05fTUFYX1JFVFJBTlNNSVQs IHJlc3BlY3RpdmVseToNCj4NCj4gICAgICBOT05fUFJPQklOR19XQUlUID0gTk9OX1RJTUVPVVQg KiAoKDIgKiogTk9OX01BWF9SRVRSQU5TTUlUKSAtIDEpICoNCj4gICAgICBBQ0tfUkFORE9NX0ZB Q1RPUiArICgyICogTUFYX0xBVEVOQ1kpICsgTk9OX1RJTUVPVVQNCj4NCj4gICBOT05fUEFSVElB TF9USU1FT1VUIGlzIHVzZWQgZm9yIGV4cGlyaW5nIHBhcnRpYWxseSByZWNlaXZlZCBib2RpZXMu DQo+ICAgQnkgZGVmYXVsdCwgTk9OX1BBUlRJQUxfVElNRU9VVCBpcyBjb21wdXRlZCBpbiB0aGUg c2FtZSB3YXkgYXMNCj4gICBFWENIQU5HRV9MSUZFVElNRSAoU2VjdGlvbiA0LjguMiBvZiBbUkZD NzI1Ml0pLiAgVGhpcyBkZWZhdWx0IHZhbHVlDQo+ICAgaXMgY2FsY3VsYXRlZCBpbiB0aGUgc2Ft ZSB3YXkgYXMgTk9OX1BST0JJTkdfV0FJVC4NCj4NCj4gKDIpIFdlIGRvbuKAmXQgc2VlIGEgbmVl ZCB0byBhcHBseSBhIGppdHRlciB3aGVuIGEgdmFsdWUgaXMgZXhwbGljaXRseSBjb25maWd1cmVk ICh0aGVzZSBhcmUgZXhwZWN0ZWQgdG8gYmUgbGFyZ2UgbnVtYmVycywgd2UgZG9uJ3QgY2FyZSB0 aGF0IG11Y2ggb24gdGhlIGppdHRlcikuIFdlIGFkZGVkIHRoaXMgdGV4dCB0byBiZSBjbGVhciBh Ym91dCB0aGUgaW50ZW50LCBhbmQgd2hpY2ggQlRXIHJlZmxlY3RzIHRoZSBjdXJyZW50IGltcGxl bWVudGF0aW9uOg0KPg0KPiBORVc6DQo+ICAgICAgV2hlbiBleHBsaWNpdCB2YWx1ZXMgYXJlDQo+ ICAgICAgY29uZmlndXJlZCBmb3IgTk9OX1BST0JJTkdfV0FJVCBhbmQgTk9OX1BBUlRJQUxfVElN RU9VVCwgdGhlc2UNCj4gICAgICB2YWx1ZXMgYXJlIHVzZWQgd2l0aG91dCBhcHBseWluZyBhbnkg aml0dGVyLg0KPg0KPiBXZSBhbHNvIGFkb3B0ZWQgeW91ciBwcm9wb3NlZCBlZGl0cyBpbiB0aGUg bWVzc2FnZSBiZWxvdy4NCj4NCj4gVGhhbmsgeW91IGFnYWluIGZvciB0aGUgY2FyZWZ1bCByZXZp ZXcuIFRoaXMgaXMgaGlnaGx5IGFwcHJlY2lhdGVkLg0KPg0KPiBDaGVlcnMsDQo+IEpvaG4gJiBN ZWQNCj4NCj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gRGUgOiBKb2huIFNjdWRk ZXIgW21haWx0bzpqZ3NAanVuaXBlci5uZXQ8bWFpbHRvOmpnc0BqdW5pcGVyLm5ldD5dDQo+PiBF bnZvecOpIDogdmVuZHJlZGkgMjEgbWFpIDIwMjEgMDA6MDMNCj4+IMOAIDogQk9VQ0FEQUlSIE1v aGFtZWQgVEdJL09MTiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+DQo+PiBDYyA6IFRoZSBJRVNHIDxpZXNnQGlldGYub3Jn PG1haWx0bzppZXNnQGlldGYub3JnPj47IGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2tAaWV0Zi5v cmc8bWFpbHRvOmRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2tAaWV0Zi5vcmc+Ow0KPj4gY29yZS1j aGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmNvcmUtY2hhaXJzQGlldGYub3JnPjsgY29yZUBpZXRmLm9y ZzxtYWlsdG86Y29yZUBpZXRmLm9yZz47IG1hcmNvLnRpbG9jYUByaS5zZTxtYWlsdG86bWFyY28u dGlsb2NhQHJpLnNlPg0KPj4gT2JqZXQgOiBSZTogSm9obiBTY3VkZGVyJ3MgRGlzY3VzcyBvbiBk cmFmdC1pZXRmLWNvcmUtbmV3LWJsb2NrLTExOg0KPj4gKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVO VCkNCj4+DQo+PiBIaSBNb2hhbWVkLA0KPj4NCj4+IEkgdGhpbmsgd2UgYXJlIGNvbnZlcmdpbmcu IE15IGNvbW1lbnRzIGluIGxpbmUuIEnigJl2ZSBzbmlwcGVkIGFncmVlZA0KPj4gcG9pbnRzIGZv ciBicmV2aXR5LCBpbmRpY2F0ZWQgYnkgW+KApl0uDQo+Pg0KPj4+IE9uIE1heSAyMCwgMjAyMSwg YXQgOToxNyBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQo+Pg0KPj4gW+KApl0NCj4+DQo+Pj4+Pj4gMTEu IEdlbmVyYWwNCj4+Pj4+Pg0KPj4+Pj4+IEJ5IHRoZSB3YXksIG5vbmUgb2YgdGhlIHRpbWVycyBz cGVjaWZ5IGppdHRlciAoYW5kIGluZGVlZCwgaWYNCj4+IHJlYWQNCj4+Pj4+PiBsaXRlcmFsbHks IGppdHRlciB3b3VsZCBiZSBmb3JiaWRkZW4pLiBJcyB0aGlzIGludGVudGlvbmFsPw0KPj4+Pj4N Cj4+Pj4+IE5vICsvLSB0b2xlcmFuY2VzIGhhdmUgYmVlbiBkZWZpbmVkLiBXaGVuIGEgdGltZXIg ZXhwaXJlcywgdGhlbg0KPj4gdGhlDQo+Pj4+IG5leHQgYWN0aW9uIHRha2VzIHBsYWNlLg0KPj4+ Pg0KPj4+PiBJIG5vdGljZSB0aGF0IFJGQyA3MjUyIGppdHRlcnMgaXRzIHRpbWVycywgZm9yIGV4 YW1wbGU6DQo+Pj4+DQo+Pj4+ICBjb3VudGVyLiAgRm9yIGEgbmV3IENvbmZpcm1hYmxlIG1lc3Nh Z2UsIHRoZSBpbml0aWFsIHRpbWVvdXQgaXMNCj4+IHNldA0KPj4+PiAgdG8gYSByYW5kb20gZHVy YXRpb24gKG9mdGVuIG5vdCBhbiBpbnRlZ3JhbCBudW1iZXIgb2Ygc2Vjb25kcykNCj4+Pj4gIGJl dHdlZW4gQUNLX1RJTUVPVVQgYW5kIChBQ0tfVElNRU9VVCAqIEFDS19SQU5ET01fRkFDVE9SKSAo c2VlDQo+Pj4+ICBTZWN0aW9uIDQuOCkNCj4+Pj4g4oCmDQo+Pj4+ICBBQ0tfUkFORE9NX0ZBQ1RP UiBNVVNUIE5PVCBiZSBkZWNyZWFzZWQgYmVsb3cgMS4wLCBhbmQgaXQgU0hPVUxEDQo+Pj4+IGhh dmUNCj4+Pj4gIGEgdmFsdWUgdGhhdCBpcyBzdWZmaWNpZW50bHkgZGlmZmVyZW50IGZyb20gMS4w IHRvIHByb3ZpZGUgc29tZQ0KPj4+PiAgcHJvdGVjdGlvbiBmcm9tIHN5bmNocm9uaXphdGlvbiBl ZmZlY3RzLg0KPj4+Pg0KPj4+PiBNQVhfVFJBTlNNSVRfU1BBTiBhbmQgTUFYX1RSQU5TTUlUX1dB SVQgYXJlIHNpbWlsYXJseSBqaXR0ZXJlZC4gQQ0KPj4+PiBudW1iZXIgb2YgeW91ciBpbnRyb2R1 Y2VkIHBhcmFtZXRlcnMNCj4+Pj4NCj4+Pj4gIFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBuZXcg cGFyYW1ldGVycyBNQVhfUEFZTE9BRFMsDQo+PiBOT05fVElNRU9VVCwNCj4+Pj4gIE5PTl9SRUNF SVZFX1RJTUVPVVQsIE5PTl9NQVhfUkVUUkFOU01JVCwgTk9OX1BST0JJTkdfV0FJVCwgYW5kDQo+ Pj4+ICBOT05fUEFSVElBTF9USU1FT1VUIHByaW1hcmlseSBmb3IgdXNlIHdpdGggTk9OIChUYWJs ZSAzKS4NCj4+Pj4NCj4+Pj4gYXBwZWFyIGF0IGxlYXN0IHN1cGVyZmljaWFsbHkgc2ltaWxhciB0 byB0aGUgdGltZXJzIHRoZSBhdXRob3JzIG9mDQo+Pj4+IFJGQyA3MjUyIGRlZW1lZCBpbXBvcnRh bnQgdG8gaml0dGVyIHRvIHByZXZlbnQgc3luY2hyb25pemF0aW9uDQo+Pj4+IGVmZmVjdHMuIERp ZCB5b3Ugc3BlY2lmaWNhbGx5IGNvbnNpZGVyIGppdHRlcmluZyB0aGVtLCBhbmQgZGVjaWRlDQo+ Pj4+IHRoYXQgaml0dGVyIHdhcyB1bm5lY2Vzc2FyeT8gSWYgc28sIGNhbiB5b3UgZXhwbGFpbiB3 aGF0IGlzDQo+PiBkaWZmZXJlbnQNCj4+Pj4gYWJvdXQgeW91ciBzcGVjaWZpY2F0aW9uLCBjb21w YXJlZCB0byB0aGUgYmFzZSBzcGVjLCB0aGF0DQo+PiBlbGltaW5hdGVzDQo+Pj4+IHRoZSBjb25j ZXJuPw0KPj4+DQo+Pj4gUkZDNzI1MiBpbnRyb2R1Y2VzIEFDS19SQU5ET01fRkFDVE9SIGppdHRl ciBhbmQgc2VwYXJhdGVseSBqaXR0ZXINCj4+IGZvciBtdWx0aWNhc3QgcmVzcG9uc2VzICh3aGlj aCBpcyBub3QgcmVsZXZhbnQgaGVyZSkuDQo+Pj4NCj4+PiBUaGUgQUNLX1JBTkRPTV9GQUNUT1Ig aXMgdGhlcmUgZm9yIHdoZW4gcmUtdHJhbnNtaXR0aW5nIGEgcGFja2V0DQo+PiB0aGF0IGhhcyBu b3QgYmVlbiBhY2tub3dsZWRnZWQgZm9yIHNvbWUgcmVhc29uIGJ5IGl0cyBwZWVyLg0KPj4gTk9O X1RJTUVPVVQgaXMgZm9yIHdoZW4gdGhlIG5leHQgTUFYX1BBWUxPQURTX1NFVCBjYW4gc3RhcnQN Cj4+IHRyYW5zbWlzc2lvbiAobm90IHJlLXRyYW5zbWlzc2lvbikgYXNzdW1pbmcgYSAnQ29udGlu dWUnIGhhcyBub3QNCj4+IGFycml2ZWQgaW4gdGhlIGludGVyaW0sIGFuZCBzbyB3YXMgbm90IHRo b3VnaHQgbmVjZXNzYXJ5IHRvIGFkZCBpbg0KPj4gQUNLX1JBTkRPTV9GQUNUT1Igc3R5bGUgaml0 dGVyIGhlcmUuDQo+Pj4NCj4+PiBGb3IgTk9OX1JFQ0VJVkVfVElNRU9VVCwgd2hhdCBpcyBpbXBv cnRhbnQgaXMgdGhhdA0KPj4gTk9OX1JFQ0VJVkVfVElNRU9VVCBpcyBncmVhdGVyIHRoYW4gTk9O X1RJTUVPVVQgKFdlIHNheSBpbiB0aGUgc3BlYyBhDQo+PiBtaW5pbXVtIG9mIG9uZSBzZWNvbmQp IHNvIHRoYXQgYSBwZWVyIGRvZXMgbm90IGZpcmUgb2ZmIGEgcmUtDQo+PiB0cmFuc21pc3Npb24g cmVxdWVzdCBiZWZvcmUgdGhlIGxvY2FsIGFnZW50IGhhcyBhIGNoYW5jZSB0byBzdGFydCB0bw0K Pj4gdHJhbnNtaXQgdGhlIG5leHQgTUFYX1BBWUxPQURTX1NFVC4gIE5PTl9SRUNFSVZFX1RJTUVP VVQgaXMNCj4+IGV4cG9uZW50aWFsbHkgc2NhbGVkIGZvciBlYWNoIHJldHJ5IHRvIG1ha2Ugc3Vy ZSB0aGF0IHN0YWJpbGl0eSBpcw0KPj4gcHJlc2VydmVkLiBTbywgYWdhaW4sIEFDS19SQU5ET01f RkFDVE9SIGppdHRlciB3YXMgbm90IHRob3VnaHQgdG8gYmUNCj4+IG5lY2Vzc2FyeSBoZXJlLg0K Pj4+DQo+Pj4gTk9OX01BWF9SRVRSQU5TTUlUIGlzIGEgZml4ZWQgY291bnQuDQo+Pj4NCj4+PiBO T05fUFJPQklOR19XQUlUIGlzIHVzZWQgdG8gcHV0IGEgbGltaXQgb24gdGhlIHBvdGVudGlhbCBk ZWxheSB0aGF0DQo+PiBjb3VsZCBpbmN1ciB3aGVuIG9iZXlpbmcgUFJPQklOR19XQUlUIHdoZW4g dGhlcmUgaXMgbm8gcGVlciByZXNwb25zZS4NCj4+IElmIHRoZSBpbXBsZW1lbnRhdGlvbiBnb2Vz IHdpdGggdGhlIGRlZmF1bHQgRVhDSEFOR0VfTElGRVRJTUUNCj4+IGNvbXB1dGF0aW9uLCB0aGVu IE5PTl9QUk9CSU5HX1dBSVQgaW5jbHVkZXMgQUNLX1JBTkRPTV9GQUNUT1IgaW4gdGhlDQo+PiBt YXRoLg0KPj4+DQo+Pj4gTk9OX1BBUlRJQUxfVElNRU9VVCBpZiBjb21wdXRlZCB1c2luZyB0aGUg ZGVmYXVsdCBFWENIQU5HRV9MSUZFVElNRQ0KPj4gaW5jbHVkZXMgQUNLX1JBTkRPTV9GQUNUT1Iu DQo+Pg0KPj4gVGhhbmtzIGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gZXhwbGFpbi4gWW91IGRvbuKA mXQgY29tbWVudCByZWdhcmRpbmcNCj4+IHdoZXRoZXIgTk9OX1BST0JJTkdfV0FJVCBhbmQgTk9O X1BBUlRJQUxfVElNRU9VVCBzaG91bGQgYmUgaml0dGVyZWQNCj4+IG9yIG5vdCwgeW91IGp1c3Qg ZXhwbGFpbiB0aGF0IGlmIHRoZXkgdXNlIHRoZSBkZWZhdWx0IHRoZXkgZ2V0IGppdHRlcg0KPj4g 4oCcZm9yIGZyZWXigJ0uIFRoZSBtaXNzaW5nIGRldGFpbCBpcyB0aGF0IGlmIHRoZXkgZG9u4oCZ dCB1c2UgdGhlIGRlZmF1bHQNCj4+IHRoZXkgZG9u4oCZdCBnZXQgaml0dGVyZWQsIHNvIEkgdGhp bmsgc29tZSBjb25zaWRlcmF0aW9uIGlzIHN0aWxsDQo+PiBjYWxsZWQgZm9yIHJlZ2FyZGluZyB3 aGV0aGVyIGhhdmluZyB0aGVtIG5vdCBiZSBqaXR0ZXJlZCBpcyBPSy4NCj4+DQo+PiBb4oCmXQ0K Pj4NCj4+Pj4+PiAxNS4gU2VjdGlvbiAxMC4yLjMNCj4+DQo+PiBb4oCmXQ0KPj4NCj4+Pj4gT25l IGNvbmNlcm4gcmVsYXRlZCB0byB0aGF0OiB3YWl0aW5nIE5PTl9USU1FT1VUIGlzbuKAmXQgYWN0 dWFsbHkNCj4+Pj4gcmVxdWlyZWQsIGl04oCZcyBvbmx5IFJFQ09NTUVOREVELCB0aGVyZWZvcmUg dGhpcyBpc27igJl0IGFjdHVhbGx5IGENCj4+Pj4gZ3VhcmFudGVlLiBGcm9tIMKnNy4yOg0KPj4+ Pg0KPj4+PiAgQXMgdGhlIHNlbmRpbmcgb2YgbWFueSBwYXlsb2FkcyBvZiBhIHNpbmdsZSBib2R5 IG1heSBpdHNlbGYNCj4+IGNhdXNlDQo+Pj4+ICBjb25nZXN0aW9uLCBpdCBpcyBSRUNPTU1FTkRF RCB0aGF0IGFmdGVyIHRyYW5zbWlzc2lvbiBvZiBldmVyeQ0KPj4+PiAgTUFYX1BBWUxPQURTX1NF VCBvZiBhIHNpbmdsZSBib2R5LCBhIGRlbGF5IGlzIGludHJvZHVjZWQgb2YNCj4+Pj4gIE5PTl9U SU1FT1VUIGJlZm9yZSBzZW5kaW5nIHRoZSBuZXh0IE1BWF9QQVlMT0FEU19TRVQgdG8gbWFuYWdl DQo+Pj4+ICBwb3RlbnRpYWwgY29uZ2VzdGlvbiBpc3N1ZXMuDQo+Pj4+DQo+Pj4+IEkgYW0gY3Vy aW91cyB3aHkgeW91IG1hZGUgdGhpcyBhIFJFQ09NTUVOREVEIGluc3RlYWQgb2YgYSBNVVNULiBJ bg0KPj4gYQ0KPj4+PiBzaXR1YXRpb24gbGlrZSB0aGlzIGl0IHdvdWxkIGJlIHByZWZlcmFibGUg Zm9yIHlvdSB0byBleHBsYWluIHRvDQo+PiB0aGUNCj4+Pj4gaW1wbGVtZW50b3Igd2hhdCBzaXR1 YXRpb24gdGhleSBjYW4gaWdub3JlIHRoZSBSRUNPTU1FTkRFRCBpbiBhbmQNCj4+Pj4gd2hhdCB0 aGV5IHNob3VsZCBkbyBpbnN0ZWFkLCBvciBvZiBjb3Vyc2UgdG8gbWFrZSBpdCBpbnRvIGEgTVVT VC4NCj4+Pg0KPj4+IEJlY2F1c2UgYSBjb250aW51ZSBzaWduYWwgbWF5IGJlIHJlY2VpdmVkIGZy b20gdGhlIHBlZXIgYW5kIHRoZW4NCj4+IGNvbnRpbnVlIHdpdGhvdXQgd2FpdGluZyBmb3IgdGhl IHRpbWVvdXQgdG8gZXhwaXJlLg0KPj4+DQo+Pj4gVGhpcyBpcyB0byBiZSBsaW5rZWQgd2l0aCB0 aGlzIHRleHQ6DQo+Pj4NCj4+PiAgICAgQSByZXNwb25zZSB1c2luZyB0aGlzIFJlc3BvbnNlIENv ZGUgU0hPVUxEIE5PVCBiZSBnZW5lcmF0ZWQNCj4+IGZvcg0KPj4+ICAgICBldmVyeSByZWNlaXZl ZCBRLUJsb2NrMSBPcHRpb24gcmVxdWVzdCAoU2VjdGlvbiA3LjIpLiAgSXQNCj4+IFNIT1VMRA0K Pj4+ICAgICBvbmx5IGJlIGdlbmVyYXRlZCB3aGVuIGFsbCB0aGUgcGF5bG9hZCByZXF1ZXN0cyBh cmUgTm9uLQ0KPj4+ICAgICBjb25maXJtYWJsZSBhbmQgYSBNQVhfUEFZTE9BRFNfU0VUIGhhcyBi ZWVuIHJlY2VpdmVkIGJ5IHRoZQ0KPj4+ICAgICAgc2VydmVyLiAgTW9yZSBkZXRhaWxzIGFib3V0 IHRoZSBtb3RpdmF0aW9ucyBmb3IgdGhpcw0KPj4gb3B0aW1pemF0aW9uDQo+Pj4NCj4+IF5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQo+Pj4g ICAgIGFyZSBkaXNjdXNzZWQgaW4gU2VjdGlvbiA3LjIuDQo+Pj4gICAgIF5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl4NCj4+Pg0KPj4+IFdlIGNvdWxkIHVzZSAqKk1VU1QgdW5sZXNzIGEgJ0Nv bnRpbnVlJyBpcyByZWNlaXZlZCoqLCBlLmcuLA0KPj4+DQo+Pj4gT0xEOg0KPj4+ICBBcyB0aGUg c2VuZGluZyBvZiBtYW55IHBheWxvYWRzIG9mIGEgc2luZ2xlIGJvZHkgbWF5IGl0c2VsZiBjYXVz ZQ0KPj4+ICBjb25nZXN0aW9uLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGFmdGVyIHRyYW5zbWlz c2lvbiBvZiBldmVyeQ0KPj4+ICBNQVhfUEFZTE9BRFNfU0VUIG9mIGEgc2luZ2xlIGJvZHksIGEg ZGVsYXkgaXMgaW50cm9kdWNlZCBvZg0KPj4+ICBOT05fVElNRU9VVCBiZWZvcmUgc2VuZGluZyB0 aGUgbmV4dCBNQVhfUEFZTE9BRFNfU0VUIHRvIG1hbmFnZQ0KPj4+ICBwb3RlbnRpYWwgY29uZ2Vz dGlvbiBpc3N1ZXMuDQo+Pj4NCj4+PiBORVc6DQo+Pj4gIEFzIHRoZSBzZW5kaW5nIG9mIG1hbnkg cGF5bG9hZHMgb2YgYSBzaW5nbGUgYm9keSBtYXkgaXRzZWxmIGNhdXNlDQo+Pj4gIGNvbmdlc3Rp b24sIGFmdGVyIHRyYW5zbWlzc2lvbiBvZiBldmVyeSBNQVhfUEFZTE9BRFNfU0VUIG9mIGENCj4+ IHNpbmdsZQ0KPj4+ICBib2R5LCBhIGRlbGF5IE1VU1QgYmUgaW50cm9kdWNlZCBvZiBOT05fVElN RU9VVCBiZWZvcmUgc2VuZGluZw0KPj4gdGhlDQo+Pj4gIG5leHQgTUFYX1BBWUxPQURTX1NFVCB0 byBtYW5hZ2UgcG90ZW50aWFsIGNvbmdlc3Rpb24gaXNzdWVzLg0KPj4+ICBIb3dldmVyLCBpZiBh ICdDb250aW51ZScgaXMgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBmb3IgdGhlDQo+PiBjdXJyZW50 DQo+Pj4gIE1BWF9QQVlMT0FEU19TRVQsIHRoZW4gdGhlIG5leHQgTUFYX1BBWUxPQURTX1NFVCBj YW4gc3RhcnQNCj4+PiAgdHJhbnNtaXNzaW9uIGltbWVkaWF0ZWx5Lg0KPj4+DQo+Pj4gLi4uIGJ1 dCBJIGtub3cgdGhhdCBtYW55IHdvdWxkIGFyZ3VlIHRoaXMgaXMgYSBTSE9VTEQuDQo+Pg0KPj4g SSB3b3VsZCBiZSBPSyB3aXRoIGVpdGhlciB5b3VyIHByb3Bvc2VkIG5ldyB0ZXh0LCBvciBhIFNI T1VMRC9NQVkNCj4+IHBhaXIgYXMgaW4NCj4+DQo+PiBORVc6DQo+PiAgQXMgdGhlIHNlbmRpbmcg b2YgbWFueSBwYXlsb2FkcyBvZiBhIHNpbmdsZSBib2R5IG1heSBpdHNlbGYgY2F1c2UNCj4+ICBj b25nZXN0aW9uLCBhZnRlciB0cmFuc21pc3Npb24gb2YgZXZlcnkgTUFYX1BBWUxPQURTX1NFVCBv ZiBhDQo+PiBzaW5nbGUNCj4+ICBib2R5LCBhIGRlbGF5IFNIT1VMRCBiZSBpbnRyb2R1Y2VkIG9m IE5PTl9USU1FT1VUIGJlZm9yZSBzZW5kaW5nDQo+PiB0aGUNCj4+ICBuZXh0IE1BWF9QQVlMT0FE U19TRVQgdG8gbWFuYWdlIHBvdGVudGlhbCBjb25nZXN0aW9uIGlzc3Vlcy4NCj4+ICBIb3dldmVy LCBpZiBhICdDb250aW51ZScgaXMgcmVjZWl2ZWQgZnJvbSB0aGUgcGVlciBmb3IgdGhlIGN1cnJl bnQNCj4+ICBNQVhfUEFZTE9BRFNfU0VULCB0aGVuIHRoZSBuZXh0IE1BWF9QQVlMT0FEU19TRVQg TUFZIHN0YXJ0DQo+PiAgdHJhbnNtaXNzaW9uIGltbWVkaWF0ZWx5Lg0KPj4NCj4+IElmIHlvdSB3 YW50IHRvIHN0aWNrIHdpdGggTVVTVCBJIHRoaW5rIHlvdSBjYW4gY2xlYXIgdXAgdGhlIHBhaW4g d2l0aA0KPj4gc29tZXRoaW5nIGxpa2UNCj4+DQo+PiBORVc6DQo+PiAgQXMgdGhlIHNlbmRpbmcg b2YgbWFueSBwYXlsb2FkcyBvZiBhIHNpbmdsZSBib2R5IG1heSBpdHNlbGYgY2F1c2UNCj4+ICBj b25nZXN0aW9uLCBhZnRlciB0cmFuc21pc3Npb24gb2YgZXZlcnkgTUFYX1BBWUxPQURTX1NFVCBv ZiBhDQo+PiBzaW5nbGUNCj4+ICBib2R5LCBhIGRlbGF5IE1VU1QgYmUgaW50cm9kdWNlZCBvZiBO T05fVElNRU9VVCBiZWZvcmUgc2VuZGluZyB0aGUNCj4+ICBuZXh0IE1BWF9QQVlMT0FEU19TRVQg dW5sZXNzIGEgJ0NvbnRpbnVlJyBpcyByZWNlaXZlZCBmcm9tIHRoZSBwZWVyDQo+PiAgZm9yIHRo ZSBjdXJyZW50IE1BWF9QQVlMT0FEU19TRVQsIGluIHdoaWNoIGNhc2UgdGhlIG5leHQNCj4+ICBN QVhfUEFZTE9BRFNfU0VUIE1BWSBzdGFydCB0cmFuc21pc3Npb24gaW1tZWRpYXRlbHkuDQo+Pg0K Pj4gKFRvIG15IGV5ZSBwcmVzZW50aW5nIHRoZSBvcHRpb24gaW4gdGhpcyB3YXkgbWFrZXMgaXQg Y2xlYXIgd2hlbiB0aGUNCj4+IE1VU1QgZG9lcywgYW5kIGRvZXNu4oCZdCwgYXBwbHkuIFRoaXMg aXMgbXkgcHJlZmVycmVkIGZvcm0gYnV0IEkgZG9u4oCZdA0KPj4gaW5zaXN0LikNCj4+DQo+PiBb 4oCmXQ0KPj4NCj4+Pj4gMTcuIFNlY3Rpb24gMToNCj4+Pj4NCj4+Pj4gIFRoaXMgZG9jdW1lbnQg aW50cm9kdWNlcyB0aGUgQ29BUCBRLUJsb2NrMSBhbmQgUS1CbG9jazIgT3B0aW9ucw0KPj4+PiB3 aGljaA0KPj4+PiAgYWxsb3cgYmxvY2std2lzZSB0cmFuc2ZlciB0byB3b3JrIHdpdGggc2VyaWVz IG9mIE5vbi1jb25maXJtYWJsZQ0KPj4+PiAgbWVzc2FnZXMsIGluc3RlYWQgb2YgbG9jay1zdGVw cGluZyB1c2luZyBDb25maXJtYWJsZSBtZXNzYWdlcw0KPj4+PiAgKFNlY3Rpb24gMykuICBJbiBv dGhlciB3b3JkcywgdGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIG1pc3NpbmcNCj4+Pj4gcGllY2UN Cj4+Pj4gIG9mIFtSRkM3OTU5XSwgbmFtZWx5IHRoZSBzdXBwb3J0IG9mIGJsb2NrLXdpc2UgdHJh bnNmZXIgdXNpbmcNCj4+IE5vbi0NCj4+Pj4gIGNvbmZpcm1hYmxlIHdoZXJlIGFuIGVudGlyZSBi b2R5IG9mIGRhdGEgY2FuIGJlIHRyYW5zbWl0dGVkDQo+PiB3aXRob3V0DQo+Pj4+ICB0aGUgcmVx dWlyZW1lbnQgZm9yIGFuIGFja25vd2xlZGdlbWVudCAoYnV0IHJlY292ZXJ5IGlzDQo+PiBhdmFp bGFibGUNCj4+Pj4gIHNob3VsZCBpdCBiZSBuZWVkZWQpLg0KPj4+Pg0KPj4+PiBBcyBmYXIgYXMg SSBjYW4gdGVsbCB0aGUgc3BlYyBkb2VzIG5vdCByZWFsbHkgcmVtb3ZlIHRoZQ0KPj4gcmVxdWly ZW1lbnQNCj4+Pj4gZm9yIGFja25vd2xlZGdlbWVudCwNCj4+Pg0KPj4+IFRoZXNlIGFyZSBub3Qg cmVxdWlyZWQuIFRoZXkgd2VyZSBhZGRlZCBhcyBhbiBvcHRpbWl6YXRpb24gdG8gYXZvaWQNCj4+ IHRoZSBub24tdGltZW91dCBpZiB0aGUgcGVlciBkZWNpZGVzIHRvIHVzZSBpdC4NCj4+DQo+PiBB cyBJIG1lbnRpb25lZCBiZWxvdyAo4oCcYXdmdWxseSBjbG9zZSBwYXJzaW5n4oCdKSwgSSB0aGlu ayB0aGF0IGFsdGhvdWdoDQo+PiB5b3UgY2FuIGZpbmQgc29tZSBqdXN0aWZpY2F0aW9uIGZvciB0 aGlzIHJlYWRpbmcsIGl04oCZcyBkZWJhdGFibGUuDQo+PiBUcmFuc21pc3Npb24gb2YgdGhlIGFj a25vd2xlZGdlbWVudCAoYXQgbGVhc3QgdGhlIGZpbmFsDQo+PiBhY2tub3dsZWRnZW1lbnQgb2Yg dGhlIGVudGlyZSBib2R5LCBpbiB0aGUgZm9ybSBvZiBhIFJlc3BvbnNlIENvZGUpDQo+PiBpcyBy ZXF1aXJlZCwgaXMgaXQgbm90PyBSZWNlcHRpb24gaXNu4oCZdCByZXF1aXJlZCB0aG91Z2guIFdp dGhvdXQgdGhlDQo+PiB2ZXJiLCBJ4oCZbSBub3Qgc3VyZSB3aGV0aGVyIEkgY2FuIHNheSB3aGV0 aGVyIGFja25vd2xlZGdlbWVudCBpcywgb3INCj4+IGlzbuKAmXQsIHJlcXVpcmVkLg0KPj4NCj4+ IEkgZG9u4oCZdCBpbnNpc3QgdGhhdCB5b3UgY2hhbmdlIHRoaXMsIGJ1dCBJIGRvIHRoaW5rIHlv dSBjb3VsZCBpbXByb3ZlDQo+PiB0aGUgY2xhcml0eSBvZiB0aGUgZG9jdW1lbnQsIGlmIHlvdSBl ZGl0ZWQgdGhlIGFib3ZlIHRvIHJlYWQg4oCc4oCmDQo+PiB3aXRob3V0IHRoZSByZXF1aXJlbWVu dCB0aGF0IGFuIGFja25vd2xlZGdtZW50IGJlIHJlY2VpdmVkIGZyb20gdGhlDQo+PiBwZWVyIg0K Pj4NCj4+Pj4gaXQganVzdCBhbW9ydGl6ZXMgdGhlIGFja25vd2xlZGdlbWVudHMgYnkgb25seSBz ZW5kaW5nIHRoZW0gZXZlcnkNCj4+Pj4gTUFYX1BBWUxPQURTX1NFVC4gUmVzcG9uc2UgQ29kZSAy LjMxIGlzIGVzc2VudGlhbGx5IGFuDQo+Pj4+IGFja25vd2xlZGdlbWVudCwgYW5kIGl0IGdldHMg c2VudCB0aGF0IGZyZXF1ZW50bHksIHJpZ2h0PyBUaGVyZeKAmXMNCj4+Pj4gYWxzbyAoaWYgSSBy ZWNhbGwgY29ycmVjdGx5KSBzb21lIGZsYXZvciBvZiBhY2tub3dsZWRnZW1lbnQgdGhhdA0KPj4g aXMNCj4+Pj4gc2VudCB3aGVuIHRoZSBlbnRpcmUgYm9keSBoYXMgYmVlbiB0cmFuc2ZlcnJlZC4g U28sIEkgdGhpbmsgdGhlDQo+PiBuZXcNCj4+Pj4gcGFyYWdyYXBoIGlzbuKAmXQgYWNjdXJhdGUu DQo+Pj4+DQo+Pj4+IFRoaXMgb2JzZXJ2YXRpb24gYWxzbyBhcHBsaWVzIHRvIHRoaXMgY2xhaW1l ZCBiZW5lZml0IGluIMKnMzoNCj4+Pj4NCj4+Pj4gIG8gIFRoZXkgc3VwcG9ydCBzZW5kaW5nIGFu IGVudGlyZSBib2R5IHVzaW5nIE5PTiBtZXNzYWdlcw0KPj4gd2l0aG91dA0KPj4+PiAgICAgcmVx dWlyaW5nIGFuIGludGVybWVkaWF0ZSByZXNwb25zZSBmcm9tIHRoZSBwZWVyLg0KPj4NCj4+IEFu ZCBzaW1pbGFybHksIOKAnOKApiB3aXRob3V0IHJlcXVpcmluZyB0aGF0IGFuIGludGVybWVkaWF0 ZSByZXNwb25zZSBiZQ0KPj4gcmVjZWl2ZWQgZnJvbSB0aGUgcGVlci7igJ0NCj4+DQo+PiBb4oCm XQ0KPj4NCj4+Pj4gMTguIFNlY3Rpb24gMjoNCj4+Pj4NCj4+Pj4gIE1BWF9QQVlMT0FEU19TRVQg aXMgdGhlIHNldCBvZiBibG9ja3MgaWRlbnRpZmllZCBieSBibG9jaw0KPj4gbnVtYmVycw0KPj4+ PiAgdGhhdCwgd2hlbiBkaXZpZGVkIGJ5IE1BWF9QQVlMT0FEUywgdGhleSBoYXZlIHRoZSBzYW1l IG51bWVyaWMNCj4+Pj4NCj4+Pj4gUmVtb3ZlIOKAnHRoZXnigJ0NCj4+Pg0KPj4+IEZpeGVkLiBU aGFua3MuDQo+Pj4NCj4+Pj4NCj4+Pj4gIHJlc3VsdC4gIEZvciBleGFtcGxlLCBpZiBNQVhfUEFZ TE9BRFMgaXMgc2V0IHRvICcxMCcsIGENCj4+Pj4gIE1BWF9QQVlMT0FEU19TRVQgY291bGQgYmUg YmxvY2tzICMwIHRvICM5LCAjMTAgdG8gIzE5LCBldGMuDQo+Pj4+ICBEZXBlbmRpbmcgb24gdGhl IGRhdGEgc2l6ZSwgdGhlIE1BWF9QQVlMT0FEU19TRVQgbWF5IG5vdA0KPj4gY29tcHJpc2UNCj4+ Pj4gYWxsDQo+Pj4+ICB0aGUgTUFYX1BBWUxPQURTIGJsb2Nrcy4NCj4+Pj4NCj4+Pj4gSSBkb27i gJl0IHVuZGVyc3RhbmQgdGhlIGxhc3Qgc2VudGVuY2UgKCJEZXBlbmRpbmcgb24gdGhlIGRhdGEg c2l6ZSwNCj4+Pj4gdGhlIE1BWF9QQVlMT0FEU19TRVQgbWF5IG5vdCBjb21wcmlzZSBhbGwgdGhl IE1BWF9QQVlMT0FEUw0KPj4gYmxvY2tzLuKAnSkNCj4+Pj4gQXJlIHlvdSB0cnlpbmcgdG8gc2F5 IHRoYXQgaWYgdGhlIGJvZHkgc2l6ZSBpc27igJl0IGV2ZW5seSBkaXZpc2libGUNCj4+IGJ5DQo+ Pj4+IE1BWF9QQVlMT0FEUyB0aGVuIHRoZSBmaW5hbCBNQVhfUEFZTE9BRFNfU0VUIHdpbGwgaGF2 ZSBmZXdlciB0aGFuDQo+Pj4+IE1BWF9QQVlMT0FEUyBibG9ja3MgaW4gaXQ/DQo+Pj4NCj4+PiBX ZSBtZWFudCB0aGF0IHRoZSBsYXN0IHNldCBtYXkgaW5jbHVkZSBmZXdlciBibG9ja3MgdGhhbg0K Pj4gTUFYX1BBWUxPQURTLiBDaGFuZ2VkIHRvOg0KPj4+DQo+Pj4gIiBEZXBlbmRpbmcgb24gdGhl IG92ZXJhbGwgZGF0YQ0KPj4+ICAgICAgICAgICAgICAgICAgIF5eXl5eXl5eDQo+Pj4gIHNpemUs IHRoZSBmaW5hbCBNQVhfUEFZTE9BRFNfU0VUIG1heSBub3QgY29tcHJpc2UgYWxsIHRoZQ0KPj4+ ICAgICAgICAgICAgXl5eXl4NCj4+PiAgTUFYX1BBWUxPQURTIGJsb2Nrcy4gIg0KPj4+DQo+Pj4g QmV0dGVyPw0KPj4NCj4+IEltcHJvdmluZy4gVGhlIHdvcmQg4oCcY29tcHJpc2XigJ0gaXMgcHJv bmUgdG8gbWlzaW50ZXJwcmV0YXRpb24gaW4gbXkNCj4+IGV4cGVyaWVuY2UsIEkgd291bGQgc3Vn Z2VzdCBzb21ldGhpbmcgbGlrZSDigJzigKYgdGhlcmUgY291bGQgYmUgZmV3ZXINCj4+IHRoYW4g TUFYX1BBWUxPQURTIGJsb2NrcyBpbiB0aGUgZmluYWwgTUFYX1BBWUxPQURTX1NFVC7igJ0NCj4+ DQo+PiBUaGFua3MsDQo+Pg0KPj4g4oCUSm9obg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+DQo+IENlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KPiBw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcg0KPiBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLA0KPiBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+DQo+ IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 DQo+IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91 dCBhdXRob3Jpc2F0aW9uLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cy4NCj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLg0KPiBUaGFuayB5b3UuDQo+DQoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBz ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRp ZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s Ck9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_787AE7BB302AE849A7480A190F8B93303538C6ABOPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1hcnRp biwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBjb21tZW50IGFib3V0IGxhcmdl IG51bWJlcnMgc2hvdWxkIGJlIHB1dCBpbiB0aGUgY29udGV4dCBvZiB0aGUgdHdvIHRpbWVvdXRz IGRpc2N1c3NlZCB3aXRoIEpvaG46IE5PTl9QQVJUSUFMX1RJTUVPVVQgYW5kIE5PTl9QUk9CSU5H X1dBSVQuIENvbnNpZGVyIHRoZSBleGFtcGxlDQogb2YgTk9OX1BBUlRJQUxfVElNRU9VVCwgYWRk aW5nIHNvbWUgaml0dGVyIHRvIGl0IGlzIHVubGlrZWx5IHRvIGhhdmUgYW4gZWZmZWN0IGFzIHRo YXQgdGltZXIgaXMgYWJvdXQgY29udHJvbGxpbmcgd2hlbiBhIHJlY2VpdmVkIHBhcnRpYWwgYm9k eSB3aWxsIGJlIGRpc2NhcmRlZCBsb2NhbGx5Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Tk9OX1BST0JJTkdfV0FJVCBpcyBhYm91dCBsaW1pdGluZyB0aGUgZWZmZWN0IG9mIFBST0JJ TkdfUkFURSB3aGVuIGEgcGVlciBkb2VzIG5vdCByZXBseS4gQXMgYSByZW1pbmRlciwgcHJvYmlu ZyByYXRlIGlzIGRlZmluZWQgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsgVGhlIFBST0JJTkdfUkFURSBwYXJhbWV0ZXIgaW4gQ29BUCBpbmRpY2F0 ZXMgdGhlIGF2ZXJhZ2UgZGF0YSByYXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IHRoYXQgbXVz dCBub3QgYmUgZXhjZWVkZWQgYnkgYSBDb0FQIGVuZHBvaW50IGluIHNlbmRpbmcgdG8gYSBwZWVy PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGVuZHBvaW50IHRoYXQgZG9lcyBub3QgcmVzcG9uZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWVkPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNYXJ0aW4gRHVrZSBbbWFpbHRvOm1hcnRpbi5oLmR1a2VA Z21haWwuY29tXQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IHZlbmRyZWRpIDIxIG1haSAy MDIxIDE4OjI4PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBKb2huIFNjdWRkZXIgJmx0O2pncz00MGp1 bmlwZXIubmV0QGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkNjJm5ic3A7OjwvYj4gQk9VQ0FE QUlSIE1vaGFtZWQgVEdJL09MTiAmbHQ7bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSZndDs7 IGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2tAaWV0Zi5vcmc7IGNvcmUtY2hhaXJzQGlldGYub3Jn OyBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs7IGNvcmVAaWV0Zi5vcmc7IG1hcmNvLnRp bG9jYUByaS5zZTxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IEpvaG4gU2N1ZGRlcidzIERp c2N1c3Mgb24gZHJhZnQtaWV0Zi1jb3JlLW5ldy1ibG9jay0xMTogKHdpdGggRElTQ1VTUyBhbmQg Q09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNvIEknbSBub3Qgc3VyZSB0aGF0ICZxdW90O2xhcmdlIG51bWJlcnMmcXVv dDsgYXJlIGEgc3VmZmljaWVudCByZWFzb24gdG8gbm90IHdvcnJ5IGFib3V0IGppdHRlci48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdHdv IGhvc3RzIHNpbXVsdGFuZW91c2x5IHRyYW5zbWl0IG9uIGEgcXVpZXQgbmV0d29yaywgYW5kIGNh dXNlIGxvc3NlcyB3aXRoIGVhY2ggb3RoZXIuIFRoZXkgYm90aCBzZXQgdGhlIHNhbWUgcmV0cmFu c21pc3Npb24gdGltZW91dCwgYW5kIGluIHNwaXRlIG9mIG5vIG90aGVyIHRyYWZmaWMgYXJvdW5k IGNhdXNlIHRoZSBzYW1lIGNvbGxpc2lvbiwgZXRjLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBhbiBleHBsaWNpdCBjb25maWd1cmF0aW9u IGRvZXNuJ3QgcmVzdWx0IGluIGNvbW1vbiByb3VuZCBudW1iZXJzLCBpdCdzIGFuIE9LIHN1YnN0 aXR1dGUsIGJ1dCBJIGRvbid0IHNlZSBhbnkgZW5jb3VyYWdlbWVudCBvZiB0aGF0IGNob2ljZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g RnJpLCBNYXkgMjEsIDIwMjEgYXQgOToxNyBBTSBKb2huIFNjdWRkZXIgJmx0O2pncz08YSBocmVm PSJtYWlsdG86NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZyI+NDBqdW5pcGVyLm5ldEBkbWFy Yy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5I aSBNZWQsPGJyPg0KPGJyPg0KWW91ciBjdXJyZW50IHdvcmtpbmcgY29weSBsb29rcyBnb29kLiBJ 4oCZdmUgY2xlYXJlZCBteSBkaXNjdXNzLjxicj4NCjxicj4NCuKAlEpvaG48YnI+DQo8YnI+DQom Z3Q7IE9uIE1heSAyMSwgMjAyMSwgYXQgODo0MSBBTSwgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj4NCm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb208L2E+IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBbRXh0ZXJuYWwgRW1h aWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgSGkgSm9obiw8YnI+DQomZ3Q7IDxicj4NCiZndDsgQXMgeW91IGNhbiBzZWUgaW4gPGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi90aW55dXJsLmNvbS9uZXctYmxv Y2stbGF0ZXN0X187ISFORXQ2eU1hTy1nayFSbERrN0dNY2J4bEZzVDJRR2w4bWEwNHMxQ2dnbVFa UUhjSVA5YXcyUjJFUDFyV2tmUURBYklwek9neVI2ZyQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3Rpbnl1cmwuY29tL25ldy1ibG9jay1sYXRl c3RfXzshIU5FdDZ5TWFPLWdrIVJsRGs3R01jYnhsRnNUMlFHbDhtYTA0czFDZ2dtUVpRSGNJUDlh dzJSMkVQMXJXa2ZRREFiSXB6T2d5UjZnJDwvYT4gLCB3ZSB3ZW50IHdpdGggdGhlIGZvbGxvd2lu ZyBjaGFuZ2VzIHRvIGJldHRlciBhZGRyZXNzIHlvdXIgbGF0ZXN0IGNvbW1lbnQgb24gdGhlIGpp dHRlcjo8YnI+DQomZ3Q7IDxicj4NCiZndDsgKDEpIGJlIGV4cGxpY2l0IGFib3V0IHRoZSBmb3Jt dWxhIHVzZWQgZm9yIGRlZmF1bHQgdmFsdWVzOjxicj4NCiZndDsgPGJyPg0KJmd0OyBPTEQ6PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDtOT05fUFJPQklOR19XQUlUIGlzIHVzZWQgdG8gbGltaXQgdGhl IHBvdGVudGlhbCB3YWl0IG5lZWRlZCB3aGVuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDt1c2luZyBQ Uk9CSU5HX1JBVEUuJm5ic3A7IEJ5IGRlZmF1bHQsIE5PTl9QUk9CSU5HX1dBSVQgaGFzIHRoZSBz YW1lIHZhbHVlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDthcyBFWENIQU5HRV9MSUZFVElNRSAoU2Vj dGlvbiA0LjguMiBvZiBbUkZDNzI1Ml0pLjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDtOT05fUEFSVElBTF9USU1FT1VUIGlzIHVzZWQgZm9yIGV4cGlyaW5nIHBhcnRpYWxseSByZWNl aXZlZCBib2RpZXMuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtCeSBkZWZhdWx0LCBOT05fUEFSVElB TF9USU1FT1VUIGhhcyB0aGUgc2FtZSB2YWx1ZSBhczxicj4NCiZndDsmbmJzcDsgJm5ic3A7RVhD SEFOR0VfTElGRVRJTUUgKFNlY3Rpb24gNC44LjIgb2YgW1JGQzcyNTJdKS48YnI+DQomZ3Q7IDxi cj4NCiZndDsgTkVXOjxicj4NCiZndDsmbmJzcDsgJm5ic3A7Tk9OX1BST0JJTkdfV0FJVCBpcyB1 c2VkIHRvIGxpbWl0IHRoZSBwb3RlbnRpYWwgd2FpdCBuZWVkZWQgd2hlbjxicj4NCiZndDsmbmJz cDsgJm5ic3A7dXNpbmcgUFJPQklOR19SQVRFLiZuYnNwOyBCeSBkZWZhdWx0LCBOT05fUFJPQklO R19XQUlUIGlzIGNvbXB1dGVkIGluIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7c2FtZSB3YXkg YXMgRVhDSEFOR0VfTElGRVRJTUUgKFNlY3Rpb24gNC44LjIgb2YgW1JGQzcyNTJdKSBidXQgd2l0 aDxicj4NCiZndDsmbmJzcDsgJm5ic3A7QUNLX1RJTUVPVVQgYW5kIE1BWF9SRVRSQU5TTUlUIHN1 YnN0aXR1dGVkIHdpdGggTk9OX1RJTUVPVVQgYW5kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtOT05f TUFYX1JFVFJBTlNNSVQsIHJlc3BlY3RpdmVseTo8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyBOT05fUFJPQklOR19XQUlUID0gTk9OX1RJTUVPVVQgKiAoKDIgKiogTk9O X01BWF9SRVRSQU5TTUlUKSAtIDEpICo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgQUNL X1JBTkRPTV9GQUNUT1IgJiM0MzsgKDIgKiBNQVhfTEFURU5DWSkgJiM0MzsgTk9OX1RJTUVPVVQ8 YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7Tk9OX1BBUlRJQUxfVElNRU9VVCBpcyB1 c2VkIGZvciBleHBpcmluZyBwYXJ0aWFsbHkgcmVjZWl2ZWQgYm9kaWVzLjxicj4NCiZndDsmbmJz cDsgJm5ic3A7QnkgZGVmYXVsdCwgTk9OX1BBUlRJQUxfVElNRU9VVCBpcyBjb21wdXRlZCBpbiB0 aGUgc2FtZSB3YXkgYXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO0VYQ0hBTkdFX0xJRkVUSU1FIChT ZWN0aW9uIDQuOC4yIG9mIFtSRkM3MjUyXSkuJm5ic3A7IFRoaXMgZGVmYXVsdCB2YWx1ZTxicj4N CiZndDsmbmJzcDsgJm5ic3A7aXMgY2FsY3VsYXRlZCBpbiB0aGUgc2FtZSB3YXkgYXMgTk9OX1BS T0JJTkdfV0FJVC48YnI+DQomZ3Q7IDxicj4NCiZndDsgKDIpIFdlIGRvbuKAmXQgc2VlIGEgbmVl ZCB0byBhcHBseSBhIGppdHRlciB3aGVuIGEgdmFsdWUgaXMgZXhwbGljaXRseSBjb25maWd1cmVk ICh0aGVzZSBhcmUgZXhwZWN0ZWQgdG8gYmUgbGFyZ2UgbnVtYmVycywgd2UgZG9uJ3QgY2FyZSB0 aGF0IG11Y2ggb24gdGhlIGppdHRlcikuIFdlIGFkZGVkIHRoaXMgdGV4dCB0byBiZSBjbGVhciBh Ym91dCB0aGUgaW50ZW50LCBhbmQgd2hpY2ggQlRXIHJlZmxlY3RzIHRoZSBjdXJyZW50IGltcGxl bWVudGF0aW9uOjxicj4NCiZndDsgPGJyPg0KJmd0OyBORVc6PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7IFdoZW4gZXhwbGljaXQgdmFsdWVzIGFyZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyBjb25maWd1cmVkIGZvciBOT05fUFJPQklOR19XQUlUIGFuZCBOT05fUEFSVElBTF9U SU1FT1VULCB0aGVzZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyB2YWx1ZXMgYXJlIHVz ZWQgd2l0aG91dCBhcHBseWluZyBhbnkgaml0dGVyLjxicj4NCiZndDsgPGJyPg0KJmd0OyBXZSBh bHNvIGFkb3B0ZWQgeW91ciBwcm9wb3NlZCBlZGl0cyBpbiB0aGUgbWVzc2FnZSBiZWxvdy48YnI+ DQomZ3Q7IDxicj4NCiZndDsgVGhhbmsgeW91IGFnYWluIGZvciB0aGUgY2FyZWZ1bCByZXZpZXcu IFRoaXMgaXMgaGlnaGx5IGFwcHJlY2lhdGVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBDaGVlcnMs PGJyPg0KJmd0OyBKb2huICZhbXA7IE1lZDxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tPGJyPg0KJmd0OyZndDsgRGUgOiBKb2huIFNjdWRkZXIgW21h aWx0bzo8YSBocmVmPSJtYWlsdG86amdzQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+amdz QGp1bmlwZXIubmV0PC9hPl08YnI+DQomZ3Q7Jmd0OyBFbnZvecOpIDogdmVuZHJlZGkgMjEgbWFp IDIwMjEgMDA6MDM8YnI+DQomZ3Q7Jmd0OyDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4g Jmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9 Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZn dDsgQ2MgOiBUaGUgSUVTRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5pZXNnQGlldGYub3JnPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86ZHJhZnQt aWV0Zi1jb3JlLW5ldy1ibG9ja0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LWlldGYt Y29yZS1uZXctYmxvY2tAaWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0 bzpjb3JlLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNvcmUtY2hhaXJzQGlldGYu b3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ Y29yZUBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzptYXJjby50aWxvY2FAcmkuc2UiIHRh cmdldD0iX2JsYW5rIj4NCm1hcmNvLnRpbG9jYUByaS5zZTwvYT48YnI+DQomZ3Q7Jmd0OyBPYmpl dCA6IFJlOiBKb2huIFNjdWRkZXIncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtY29yZS1uZXctYmxv Y2stMTE6PGJyPg0KJmd0OyZndDsgKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8YnI+DQomZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBIaSBNb2hhbWVkLDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsm Z3Q7IEkgdGhpbmsgd2UgYXJlIGNvbnZlcmdpbmcuIE15IGNvbW1lbnRzIGluIGxpbmUuIEnigJl2 ZSBzbmlwcGVkIGFncmVlZDxicj4NCiZndDsmZ3Q7IHBvaW50cyBmb3IgYnJldml0eSwgaW5kaWNh dGVkIGJ5IFvigKZdLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBPbiBNYXkgMjAs IDIwMjEsIGF0IDk6MTcgQU0sIDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9h PiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBb4oCmXTxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxMS4gR2VuZXJhbDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQnkgdGhlIHdh eSwgbm9uZSBvZiB0aGUgdGltZXJzIHNwZWNpZnkgaml0dGVyIChhbmQgaW5kZWVkLCBpZjxicj4N CiZndDsmZ3Q7IHJlYWQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGl0ZXJhbGx5LCBq aXR0ZXIgd291bGQgYmUgZm9yYmlkZGVuKS4gSXMgdGhpcyBpbnRlbnRpb25hbD88YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBObyAmIzQzOy8tIHRv bGVyYW5jZXMgaGF2ZSBiZWVuIGRlZmluZWQuIFdoZW4gYSB0aW1lciBleHBpcmVzLCB0aGVuPGJy Pg0KJmd0OyZndDsgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBuZXh0IGFjdGlvbiB0YWtlcyBw bGFjZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSSBub3Rp Y2UgdGhhdCBSRkMgNzI1MiBqaXR0ZXJzIGl0cyB0aW1lcnMsIGZvciBleGFtcGxlOjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBjb3VudGVyLiZuYnNw OyBGb3IgYSBuZXcgQ29uZmlybWFibGUgbWVzc2FnZSwgdGhlIGluaXRpYWwgdGltZW91dCBpczxi cj4NCiZndDsmZ3Q7IHNldDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgdG8gYSByYW5kb20g ZHVyYXRpb24gKG9mdGVuIG5vdCBhbiBpbnRlZ3JhbCBudW1iZXIgb2Ygc2Vjb25kcyk8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IGJldHdlZW4gQUNLX1RJTUVPVVQgYW5kIChBQ0tfVElNRU9V VCAqIEFDS19SQU5ET01fRkFDVE9SKSAoc2VlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBT ZWN0aW9uIDQuOCk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IOKApjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsgQUNLX1JBTkRPTV9GQUNUT1IgTVVTVCBOT1QgYmUgZGVjcmVhc2VkIGJlbG93IDEu MCwgYW5kIGl0IFNIT1VMRDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgaGF2ZTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsgYSB2YWx1ZSB0aGF0IGlzIHN1ZmZpY2llbnRseSBkaWZmZXJlbnQgZnJv bSAxLjAgdG8gcHJvdmlkZSBzb21lPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBwcm90ZWN0 aW9uIGZyb20gc3luY2hyb25pemF0aW9uIGVmZmVjdHMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE1BWF9UUkFOU01JVF9TUEFOIGFuZCBNQVhfVFJBTlNNSVRf V0FJVCBhcmUgc2ltaWxhcmx5IGppdHRlcmVkLiBBPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBudW1i ZXIgb2YgeW91ciBpbnRyb2R1Y2VkIHBhcmFtZXRlcnM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIG5ldyBw YXJhbWV0ZXJzIE1BWF9QQVlMT0FEUyw8YnI+DQomZ3Q7Jmd0OyBOT05fVElNRU9VVCw8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IE5PTl9SRUNFSVZFX1RJTUVPVVQsIE5PTl9NQVhfUkVUUkFO U01JVCwgTk9OX1BST0JJTkdfV0FJVCwgYW5kPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBO T05fUEFSVElBTF9USU1FT1VUIHByaW1hcmlseSBmb3IgdXNlIHdpdGggTk9OIChUYWJsZSAzKS48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgYXBwZWFyIGF0IGxl YXN0IHN1cGVyZmljaWFsbHkgc2ltaWxhciB0byB0aGUgdGltZXJzIHRoZSBhdXRob3JzIG9mPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBSRkMgNzI1MiBkZWVtZWQgaW1wb3J0YW50IHRvIGppdHRlciB0 byBwcmV2ZW50IHN5bmNocm9uaXphdGlvbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgZWZmZWN0cy4g RGlkIHlvdSBzcGVjaWZpY2FsbHkgY29uc2lkZXIgaml0dGVyaW5nIHRoZW0sIGFuZCBkZWNpZGU8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQgaml0dGVyIHdhcyB1bm5lY2Vzc2FyeT8gSWYgc28s IGNhbiB5b3UgZXhwbGFpbiB3aGF0IGlzPGJyPg0KJmd0OyZndDsgZGlmZmVyZW50PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyBhYm91dCB5b3VyIHNwZWNpZmljYXRpb24sIGNvbXBhcmVkIHRvIHRoZSBi YXNlIHNwZWMsIHRoYXQ8YnI+DQomZ3Q7Jmd0OyBlbGltaW5hdGVzPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyB0aGUgY29uY2Vybj88YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IFJG QzcyNTIgaW50cm9kdWNlcyBBQ0tfUkFORE9NX0ZBQ1RPUiBqaXR0ZXIgYW5kIHNlcGFyYXRlbHkg aml0dGVyPGJyPg0KJmd0OyZndDsgZm9yIG11bHRpY2FzdCByZXNwb25zZXMgKHdoaWNoIGlzIG5v dCByZWxldmFudCBoZXJlKS48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IFRo ZSBBQ0tfUkFORE9NX0ZBQ1RPUiBpcyB0aGVyZSBmb3Igd2hlbiByZS10cmFuc21pdHRpbmcgYSBw YWNrZXQ8YnI+DQomZ3Q7Jmd0OyB0aGF0IGhhcyBub3QgYmVlbiBhY2tub3dsZWRnZWQgZm9yIHNv bWUgcmVhc29uIGJ5IGl0cyBwZWVyLjxicj4NCiZndDsmZ3Q7IE5PTl9USU1FT1VUIGlzIGZvciB3 aGVuIHRoZSBuZXh0IE1BWF9QQVlMT0FEU19TRVQgY2FuIHN0YXJ0PGJyPg0KJmd0OyZndDsgdHJh bnNtaXNzaW9uIChub3QgcmUtdHJhbnNtaXNzaW9uKSBhc3N1bWluZyBhICdDb250aW51ZScgaGFz IG5vdDxicj4NCiZndDsmZ3Q7IGFycml2ZWQgaW4gdGhlIGludGVyaW0sIGFuZCBzbyB3YXMgbm90 IHRob3VnaHQgbmVjZXNzYXJ5IHRvIGFkZCBpbjxicj4NCiZndDsmZ3Q7IEFDS19SQU5ET01fRkFD VE9SIHN0eWxlIGppdHRlciBoZXJlLjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZn dDsgRm9yIE5PTl9SRUNFSVZFX1RJTUVPVVQsIHdoYXQgaXMgaW1wb3J0YW50IGlzIHRoYXQ8YnI+ DQomZ3Q7Jmd0OyBOT05fUkVDRUlWRV9USU1FT1VUIGlzIGdyZWF0ZXIgdGhhbiBOT05fVElNRU9V VCAoV2Ugc2F5IGluIHRoZSBzcGVjIGE8YnI+DQomZ3Q7Jmd0OyBtaW5pbXVtIG9mIG9uZSBzZWNv bmQpIHNvIHRoYXQgYSBwZWVyIGRvZXMgbm90IGZpcmUgb2ZmIGEgcmUtPGJyPg0KJmd0OyZndDsg dHJhbnNtaXNzaW9uIHJlcXVlc3QgYmVmb3JlIHRoZSBsb2NhbCBhZ2VudCBoYXMgYSBjaGFuY2Ug dG8gc3RhcnQgdG88YnI+DQomZ3Q7Jmd0OyB0cmFuc21pdCB0aGUgbmV4dCBNQVhfUEFZTE9BRFNf U0VULiZuYnNwOyBOT05fUkVDRUlWRV9USU1FT1VUIGlzPGJyPg0KJmd0OyZndDsgZXhwb25lbnRp YWxseSBzY2FsZWQgZm9yIGVhY2ggcmV0cnkgdG8gbWFrZSBzdXJlIHRoYXQgc3RhYmlsaXR5IGlz PGJyPg0KJmd0OyZndDsgcHJlc2VydmVkLiBTbywgYWdhaW4sIEFDS19SQU5ET01fRkFDVE9SIGpp dHRlciB3YXMgbm90IHRob3VnaHQgdG8gYmU8YnI+DQomZ3Q7Jmd0OyBuZWNlc3NhcnkgaGVyZS48 YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IE5PTl9NQVhfUkVUUkFOU01JVCBp cyBhIGZpeGVkIGNvdW50Ljxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgTk9O X1BST0JJTkdfV0FJVCBpcyB1c2VkIHRvIHB1dCBhIGxpbWl0IG9uIHRoZSBwb3RlbnRpYWwgZGVs YXkgdGhhdDxicj4NCiZndDsmZ3Q7IGNvdWxkIGluY3VyIHdoZW4gb2JleWluZyBQUk9CSU5HX1dB SVQgd2hlbiB0aGVyZSBpcyBubyBwZWVyIHJlc3BvbnNlLjxicj4NCiZndDsmZ3Q7IElmIHRoZSBp bXBsZW1lbnRhdGlvbiBnb2VzIHdpdGggdGhlIGRlZmF1bHQgRVhDSEFOR0VfTElGRVRJTUU8YnI+ DQomZ3Q7Jmd0OyBjb21wdXRhdGlvbiwgdGhlbiBOT05fUFJPQklOR19XQUlUIGluY2x1ZGVzIEFD S19SQU5ET01fRkFDVE9SIGluIHRoZTxicj4NCiZndDsmZ3Q7IG1hdGguPGJyPg0KJmd0OyZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBOT05fUEFSVElBTF9USU1FT1VUIGlmIGNvbXB1dGVkIHVz aW5nIHRoZSBkZWZhdWx0IEVYQ0hBTkdFX0xJRkVUSU1FPGJyPg0KJmd0OyZndDsgaW5jbHVkZXMg QUNLX1JBTkRPTV9GQUNUT1IuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgVGhhbmtzIGZv ciB0YWtpbmcgdGhlIHRpbWUgdG8gZXhwbGFpbi4gWW91IGRvbuKAmXQgY29tbWVudCByZWdhcmRp bmc8YnI+DQomZ3Q7Jmd0OyB3aGV0aGVyIE5PTl9QUk9CSU5HX1dBSVQgYW5kIE5PTl9QQVJUSUFM X1RJTUVPVVQgc2hvdWxkIGJlIGppdHRlcmVkPGJyPg0KJmd0OyZndDsgb3Igbm90LCB5b3UganVz dCBleHBsYWluIHRoYXQgaWYgdGhleSB1c2UgdGhlIGRlZmF1bHQgdGhleSBnZXQgaml0dGVyPGJy Pg0KJmd0OyZndDsg4oCcZm9yIGZyZWXigJ0uIFRoZSBtaXNzaW5nIGRldGFpbCBpcyB0aGF0IGlm IHRoZXkgZG9u4oCZdCB1c2UgdGhlIGRlZmF1bHQ8YnI+DQomZ3Q7Jmd0OyB0aGV5IGRvbuKAmXQg Z2V0IGppdHRlcmVkLCBzbyBJIHRoaW5rIHNvbWUgY29uc2lkZXJhdGlvbiBpcyBzdGlsbDxicj4N CiZndDsmZ3Q7IGNhbGxlZCBmb3IgcmVnYXJkaW5nIHdoZXRoZXIgaGF2aW5nIHRoZW0gbm90IGJl IGppdHRlcmVkIGlzIE9LLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFvigKZdPGJyPg0K Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDE1LiBTZWN0aW9uIDEwLjIu Mzxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFvigKZdPGJyPg0KJmd0OyZndDsgPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyBPbmUgY29uY2VybiByZWxhdGVkIHRvIHRoYXQ6IHdhaXRpbmcgTk9O X1RJTUVPVVQgaXNu4oCZdCBhY3R1YWxseTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgcmVxdWlyZWQs IGl04oCZcyBvbmx5IFJFQ09NTUVOREVELCB0aGVyZWZvcmUgdGhpcyBpc27igJl0IGFjdHVhbGx5 IGE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGd1YXJhbnRlZS4gRnJvbSDCpzcuMjo8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgQXMgdGhlIHNlbmRpbmcg b2YgbWFueSBwYXlsb2FkcyBvZiBhIHNpbmdsZSBib2R5IG1heSBpdHNlbGY8YnI+DQomZ3Q7Jmd0 OyBjYXVzZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgY29uZ2VzdGlvbiwgaXQgaXMgUkVD T01NRU5ERUQgdGhhdCBhZnRlciB0cmFuc21pc3Npb24gb2YgZXZlcnk8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7IE1BWF9QQVlMT0FEU19TRVQgb2YgYSBzaW5nbGUgYm9keSwgYSBkZWxheSBp cyBpbnRyb2R1Y2VkIG9mPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBOT05fVElNRU9VVCBi ZWZvcmUgc2VuZGluZyB0aGUgbmV4dCBNQVhfUEFZTE9BRFNfU0VUIHRvIG1hbmFnZTxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsgcG90ZW50aWFsIGNvbmdlc3Rpb24gaXNzdWVzLjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJIGFtIGN1cmlvdXMgd2h5IHlv dSBtYWRlIHRoaXMgYSBSRUNPTU1FTkRFRCBpbnN0ZWFkIG9mIGEgTVVTVC4gSW48YnI+DQomZ3Q7 Jmd0OyBhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBzaXR1YXRpb24gbGlrZSB0aGlzIGl0IHdvdWxk IGJlIHByZWZlcmFibGUgZm9yIHlvdSB0byBleHBsYWluIHRvPGJyPg0KJmd0OyZndDsgdGhlPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBpbXBsZW1lbnRvciB3aGF0IHNpdHVhdGlvbiB0aGV5IGNhbiBp Z25vcmUgdGhlIFJFQ09NTUVOREVEIGluIGFuZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgd2hhdCB0 aGV5IHNob3VsZCBkbyBpbnN0ZWFkLCBvciBvZiBjb3Vyc2UgdG8gbWFrZSBpdCBpbnRvIGEgTVVT VC48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IEJlY2F1c2UgYSBjb250aW51 ZSBzaWduYWwgbWF5IGJlIHJlY2VpdmVkIGZyb20gdGhlIHBlZXIgYW5kIHRoZW48YnI+DQomZ3Q7 Jmd0OyBjb250aW51ZSB3aXRob3V0IHdhaXRpbmcgZm9yIHRoZSB0aW1lb3V0IHRvIGV4cGlyZS48 YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IFRoaXMgaXMgdG8gYmUgbGlua2Vk IHdpdGggdGhpcyB0ZXh0Ojxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwO0EgcmVzcG9uc2UgdXNpbmcgdGhpcyBSZXNwb25zZSBDb2RlIFNIT1VM RCBOT1QgYmUgZ2VuZXJhdGVkPGJyPg0KJmd0OyZndDsgZm9yPGJyPg0KJmd0OyZndDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDtldmVyeSByZWNlaXZlZCBRLUJsb2NrMSBPcHRpb24gcmVxdWVzdCAo U2VjdGlvbiA3LjIpLiZuYnNwOyBJdDxicj4NCiZndDsmZ3Q7IFNIT1VMRDxicj4NCiZndDsmZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7b25seSBiZSBnZW5lcmF0ZWQgd2hlbiBhbGwgdGhlIHBh eWxvYWQgcmVxdWVzdHMgYXJlIE5vbi08YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwO2NvbmZpcm1hYmxlIGFuZCBhIE1BWF9QQVlMT0FEU19TRVQgaGFzIGJlZW4gcmVjZWl2ZWQg YnkgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc2VydmVyLiZuYnNw OyBNb3JlIGRldGFpbHMgYWJvdXQgdGhlIG1vdGl2YXRpb25zIGZvciB0aGlzPGJyPg0KJmd0OyZn dDsgb3B0aW1pemF0aW9uPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IF5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5ePGJyPg0KJmd0 OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDthcmUgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNy4y Ljxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Xl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgV2UgY291bGQg dXNlICoqTVVTVCB1bmxlc3MgYSAnQ29udGludWUnIGlzIHJlY2VpdmVkKiosIGUuZy4sPGJyPg0K Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBPTEQ6PGJyPg0KJmd0OyZndDsmZ3Q7Jm5i c3A7IEFzIHRoZSBzZW5kaW5nIG9mIG1hbnkgcGF5bG9hZHMgb2YgYSBzaW5nbGUgYm9keSBtYXkg aXRzZWxmIGNhdXNlPGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7IGNvbmdlc3Rpb24sIGl0IGlzIFJF Q09NTUVOREVEIHRoYXQgYWZ0ZXIgdHJhbnNtaXNzaW9uIG9mIGV2ZXJ5PGJyPg0KJmd0OyZndDsm Z3Q7Jm5ic3A7IE1BWF9QQVlMT0FEU19TRVQgb2YgYSBzaW5nbGUgYm9keSwgYSBkZWxheSBpcyBp bnRyb2R1Y2VkIG9mPGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7IE5PTl9USU1FT1VUIGJlZm9yZSBz ZW5kaW5nIHRoZSBuZXh0IE1BWF9QQVlMT0FEU19TRVQgdG8gbWFuYWdlPGJyPg0KJmd0OyZndDsm Z3Q7Jm5ic3A7IHBvdGVudGlhbCBjb25nZXN0aW9uIGlzc3Vlcy48YnI+DQomZ3Q7Jmd0OyZndDsg PGJyPg0KJmd0OyZndDsmZ3Q7IE5FVzo8YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgQXMgdGhlIHNl bmRpbmcgb2YgbWFueSBwYXlsb2FkcyBvZiBhIHNpbmdsZSBib2R5IG1heSBpdHNlbGYgY2F1c2U8 YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgY29uZ2VzdGlvbiwgYWZ0ZXIgdHJhbnNtaXNzaW9uIG9m IGV2ZXJ5IE1BWF9QQVlMT0FEU19TRVQgb2YgYTxicj4NCiZndDsmZ3Q7IHNpbmdsZTxicj4NCiZn dDsmZ3Q7Jmd0OyZuYnNwOyBib2R5LCBhIGRlbGF5IE1VU1QgYmUgaW50cm9kdWNlZCBvZiBOT05f VElNRU9VVCBiZWZvcmUgc2VuZGluZzxicj4NCiZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7Jmd0 OyZuYnNwOyBuZXh0IE1BWF9QQVlMT0FEU19TRVQgdG8gbWFuYWdlIHBvdGVudGlhbCBjb25nZXN0 aW9uIGlzc3Vlcy48YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgSG93ZXZlciwgaWYgYSAnQ29udGlu dWUnIGlzIHJlY2VpdmVkIGZyb20gdGhlIHBlZXIgZm9yIHRoZTxicj4NCiZndDsmZ3Q7IGN1cnJl bnQ8YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgTUFYX1BBWUxPQURTX1NFVCwgdGhlbiB0aGUgbmV4 dCBNQVhfUEFZTE9BRFNfU0VUIGNhbiBzdGFydDxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyB0cmFu c21pc3Npb24gaW1tZWRpYXRlbHkuPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0 OyAuLi4gYnV0IEkga25vdyB0aGF0IG1hbnkgd291bGQgYXJndWUgdGhpcyBpcyBhIFNIT1VMRC48 YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJIHdvdWxkIGJlIE9LIHdpdGggZWl0aGVyIHlv dXIgcHJvcG9zZWQgbmV3IHRleHQsIG9yIGEgU0hPVUxEL01BWTxicj4NCiZndDsmZ3Q7IHBhaXIg YXMgaW48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBORVc6PGJyPg0KJmd0OyZndDsmbmJz cDsgQXMgdGhlIHNlbmRpbmcgb2YgbWFueSBwYXlsb2FkcyBvZiBhIHNpbmdsZSBib2R5IG1heSBp dHNlbGYgY2F1c2U8YnI+DQomZ3Q7Jmd0OyZuYnNwOyBjb25nZXN0aW9uLCBhZnRlciB0cmFuc21p c3Npb24gb2YgZXZlcnkgTUFYX1BBWUxPQURTX1NFVCBvZiBhPGJyPg0KJmd0OyZndDsgc2luZ2xl PGJyPg0KJmd0OyZndDsmbmJzcDsgYm9keSwgYSBkZWxheSBTSE9VTEQgYmUgaW50cm9kdWNlZCBv ZiBOT05fVElNRU9VVCBiZWZvcmUgc2VuZGluZzxicj4NCiZndDsmZ3Q7IHRoZTxicj4NCiZndDsm Z3Q7Jm5ic3A7IG5leHQgTUFYX1BBWUxPQURTX1NFVCB0byBtYW5hZ2UgcG90ZW50aWFsIGNvbmdl c3Rpb24gaXNzdWVzLjxicj4NCiZndDsmZ3Q7Jm5ic3A7IEhvd2V2ZXIsIGlmIGEgJ0NvbnRpbnVl JyBpcyByZWNlaXZlZCBmcm9tIHRoZSBwZWVyIGZvciB0aGUgY3VycmVudDxicj4NCiZndDsmZ3Q7 Jm5ic3A7IE1BWF9QQVlMT0FEU19TRVQsIHRoZW4gdGhlIG5leHQgTUFYX1BBWUxPQURTX1NFVCBN QVkgc3RhcnQ8YnI+DQomZ3Q7Jmd0OyZuYnNwOyB0cmFuc21pc3Npb24gaW1tZWRpYXRlbHkuPGJy Pg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSWYgeW91IHdhbnQgdG8gc3RpY2sgd2l0aCBNVVNU IEkgdGhpbmsgeW91IGNhbiBjbGVhciB1cCB0aGUgcGFpbiB3aXRoPGJyPg0KJmd0OyZndDsgc29t ZXRoaW5nIGxpa2U8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBORVc6PGJyPg0KJmd0OyZn dDsmbmJzcDsgQXMgdGhlIHNlbmRpbmcgb2YgbWFueSBwYXlsb2FkcyBvZiBhIHNpbmdsZSBib2R5 IG1heSBpdHNlbGYgY2F1c2U8YnI+DQomZ3Q7Jmd0OyZuYnNwOyBjb25nZXN0aW9uLCBhZnRlciB0 cmFuc21pc3Npb24gb2YgZXZlcnkgTUFYX1BBWUxPQURTX1NFVCBvZiBhPGJyPg0KJmd0OyZndDsg c2luZ2xlPGJyPg0KJmd0OyZndDsmbmJzcDsgYm9keSwgYSBkZWxheSBNVVNUIGJlIGludHJvZHVj ZWQgb2YgTk9OX1RJTUVPVVQgYmVmb3JlIHNlbmRpbmcgdGhlPGJyPg0KJmd0OyZndDsmbmJzcDsg bmV4dCBNQVhfUEFZTE9BRFNfU0VUIHVubGVzcyBhICdDb250aW51ZScgaXMgcmVjZWl2ZWQgZnJv bSB0aGUgcGVlcjxicj4NCiZndDsmZ3Q7Jm5ic3A7IGZvciB0aGUgY3VycmVudCBNQVhfUEFZTE9B RFNfU0VULCBpbiB3aGljaCBjYXNlIHRoZSBuZXh0PGJyPg0KJmd0OyZndDsmbmJzcDsgTUFYX1BB WUxPQURTX1NFVCBNQVkgc3RhcnQgdHJhbnNtaXNzaW9uIGltbWVkaWF0ZWx5Ljxicj4NCiZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7IChUbyBteSBleWUgcHJlc2VudGluZyB0aGUgb3B0aW9uIGluIHRo aXMgd2F5IG1ha2VzIGl0IGNsZWFyIHdoZW4gdGhlPGJyPg0KJmd0OyZndDsgTVVTVCBkb2VzLCBh bmQgZG9lc27igJl0LCBhcHBseS4gVGhpcyBpcyBteSBwcmVmZXJyZWQgZm9ybSBidXQgSSBkb27i gJl0PGJyPg0KJmd0OyZndDsgaW5zaXN0Lik8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBb 4oCmXTxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgMTcuIFNlY3Rpb24gMTo8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgVGhpcyBk b2N1bWVudCBpbnRyb2R1Y2VzIHRoZSBDb0FQIFEtQmxvY2sxIGFuZCBRLUJsb2NrMiBPcHRpb25z PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyB3aGljaDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsg YWxsb3cgYmxvY2std2lzZSB0cmFuc2ZlciB0byB3b3JrIHdpdGggc2VyaWVzIG9mIE5vbi1jb25m aXJtYWJsZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgbWVzc2FnZXMsIGluc3RlYWQgb2Yg bG9jay1zdGVwcGluZyB1c2luZyBDb25maXJtYWJsZSBtZXNzYWdlczxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsgKFNlY3Rpb24gMykuJm5ic3A7IEluIG90aGVyIHdvcmRzLCB0aGlzIGRvY3Vt ZW50IHByb3ZpZGVzIGEgbWlzc2luZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgcGllY2U8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IG9mIFtSRkM3OTU5XSwgbmFtZWx5IHRoZSBzdXBwb3J0IG9m IGJsb2NrLXdpc2UgdHJhbnNmZXIgdXNpbmc8YnI+DQomZ3Q7Jmd0OyBOb24tPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyBjb25maXJtYWJsZSB3aGVyZSBhbiBlbnRpcmUgYm9keSBvZiBkYXRh IGNhbiBiZSB0cmFuc21pdHRlZDxicj4NCiZndDsmZ3Q7IHdpdGhvdXQ8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7IHRoZSByZXF1aXJlbWVudCBmb3IgYW4gYWNrbm93bGVkZ2VtZW50IChidXQg cmVjb3ZlcnkgaXM8YnI+DQomZ3Q7Jmd0OyBhdmFpbGFibGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7IHNob3VsZCBpdCBiZSBuZWVkZWQpLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyBBcyBmYXIgYXMgSSBjYW4gdGVsbCB0aGUgc3BlYyBkb2VzIG5vdCBy ZWFsbHkgcmVtb3ZlIHRoZTxicj4NCiZndDsmZ3Q7IHJlcXVpcmVtZW50PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyBmb3IgYWNrbm93bGVkZ2VtZW50LDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7 Jmd0OyZndDsgVGhlc2UgYXJlIG5vdCByZXF1aXJlZC4gVGhleSB3ZXJlIGFkZGVkIGFzIGFuIG9w dGltaXphdGlvbiB0byBhdm9pZDxicj4NCiZndDsmZ3Q7IHRoZSBub24tdGltZW91dCBpZiB0aGUg cGVlciBkZWNpZGVzIHRvIHVzZSBpdC48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBBcyBJ IG1lbnRpb25lZCBiZWxvdyAo4oCcYXdmdWxseSBjbG9zZSBwYXJzaW5n4oCdKSwgSSB0aGluayB0 aGF0IGFsdGhvdWdoPGJyPg0KJmd0OyZndDsgeW91IGNhbiBmaW5kIHNvbWUganVzdGlmaWNhdGlv biBmb3IgdGhpcyByZWFkaW5nLCBpdOKAmXMgZGViYXRhYmxlLjxicj4NCiZndDsmZ3Q7IFRyYW5z bWlzc2lvbiBvZiB0aGUgYWNrbm93bGVkZ2VtZW50IChhdCBsZWFzdCB0aGUgZmluYWw8YnI+DQom Z3Q7Jmd0OyBhY2tub3dsZWRnZW1lbnQgb2YgdGhlIGVudGlyZSBib2R5LCBpbiB0aGUgZm9ybSBv ZiBhIFJlc3BvbnNlIENvZGUpPGJyPg0KJmd0OyZndDsgaXMgcmVxdWlyZWQsIGlzIGl0IG5vdD8g UmVjZXB0aW9uIGlzbuKAmXQgcmVxdWlyZWQgdGhvdWdoLiBXaXRob3V0IHRoZTxicj4NCiZndDsm Z3Q7IHZlcmIsIEnigJltIG5vdCBzdXJlIHdoZXRoZXIgSSBjYW4gc2F5IHdoZXRoZXIgYWNrbm93 bGVkZ2VtZW50IGlzLCBvcjxicj4NCiZndDsmZ3Q7IGlzbuKAmXQsIHJlcXVpcmVkLjxicj4NCiZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEkgZG9u4oCZdCBpbnNpc3QgdGhhdCB5b3UgY2hhbmdlIHRo aXMsIGJ1dCBJIGRvIHRoaW5rIHlvdSBjb3VsZCBpbXByb3ZlPGJyPg0KJmd0OyZndDsgdGhlIGNs YXJpdHkgb2YgdGhlIGRvY3VtZW50LCBpZiB5b3UgZWRpdGVkIHRoZSBhYm92ZSB0byByZWFkIOKA nOKApjxicj4NCiZndDsmZ3Q7IHdpdGhvdXQgdGhlIHJlcXVpcmVtZW50IHRoYXQgYW4gYWNrbm93 bGVkZ21lbnQgYmUgcmVjZWl2ZWQgZnJvbSB0aGU8YnI+DQomZ3Q7Jmd0OyBwZWVyJnF1b3Q7PGJy Pg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBpdCBqdXN0IGFtb3J0aXplcyB0aGUg YWNrbm93bGVkZ2VtZW50cyBieSBvbmx5IHNlbmRpbmcgdGhlbSBldmVyeTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsgTUFYX1BBWUxPQURTX1NFVC4gUmVzcG9uc2UgQ29kZSAyLjMxIGlzIGVzc2VudGlh bGx5IGFuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBhY2tub3dsZWRnZW1lbnQsIGFuZCBpdCBnZXRz IHNlbnQgdGhhdCBmcmVxdWVudGx5LCByaWdodD8gVGhlcmXigJlzPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyBhbHNvIChpZiBJIHJlY2FsbCBjb3JyZWN0bHkpIHNvbWUgZmxhdm9yIG9mIGFja25vd2xl ZGdlbWVudCB0aGF0PGJyPg0KJmd0OyZndDsgaXM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHNlbnQg d2hlbiB0aGUgZW50aXJlIGJvZHkgaGFzIGJlZW4gdHJhbnNmZXJyZWQuIFNvLCBJIHRoaW5rIHRo ZTxicj4NCiZndDsmZ3Q7IG5ldzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgcGFyYWdyYXBoIGlzbuKA mXQgYWNjdXJhdGUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IFRoaXMgb2JzZXJ2YXRpb24gYWxzbyBhcHBsaWVzIHRvIHRoaXMgY2xhaW1lZCBiZW5lZml0IGlu IMKnMzo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsg byZuYnNwOyBUaGV5IHN1cHBvcnQgc2VuZGluZyBhbiBlbnRpcmUgYm9keSB1c2luZyBOT04gbWVz c2FnZXM8YnI+DQomZ3Q7Jmd0OyB3aXRob3V0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7cmVxdWlyaW5nIGFuIGludGVybWVkaWF0ZSByZXNwb25zZSBmcm9tIHRoZSBw ZWVyLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEFuZCBzaW1pbGFybHksIOKAnOKApiB3 aXRob3V0IHJlcXVpcmluZyB0aGF0IGFuIGludGVybWVkaWF0ZSByZXNwb25zZSBiZTxicj4NCiZn dDsmZ3Q7IHJlY2VpdmVkIGZyb20gdGhlIHBlZXIu4oCdPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0 OyZndDsgW+KApl08YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDE4LiBTZWN0 aW9uIDI6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 IE1BWF9QQVlMT0FEU19TRVQgaXMgdGhlIHNldCBvZiBibG9ja3MgaWRlbnRpZmllZCBieSBibG9j azxicj4NCiZndDsmZ3Q7IG51bWJlcnM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IHRoYXQs IHdoZW4gZGl2aWRlZCBieSBNQVhfUEFZTE9BRFMsIHRoZXkgaGF2ZSB0aGUgc2FtZSBudW1lcmlj PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFJlbW92ZSDigJx0 aGV54oCdPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBGaXhlZC4gVGhhbmtz Ljxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsgcmVzdWx0LiZuYnNwOyBGb3IgZXhhbXBsZSwgaWYgTUFYX1BBWUxPQURT IGlzIHNldCB0byAnMTAnLCBhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBNQVhfUEFZTE9B RFNfU0VUIGNvdWxkIGJlIGJsb2NrcyAjMCB0byAjOSwgIzEwIHRvICMxOSwgZXRjLjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsgRGVwZW5kaW5nIG9uIHRoZSBkYXRhIHNpemUsIHRoZSBNQVhf UEFZTE9BRFNfU0VUIG1heSBub3Q8YnI+DQomZ3Q7Jmd0OyBjb21wcmlzZTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsgYWxsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyB0aGUgTUFYX1BBWUxPQURT IGJsb2Nrcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSSBk b27igJl0IHVuZGVyc3RhbmQgdGhlIGxhc3Qgc2VudGVuY2UgKCZxdW90O0RlcGVuZGluZyBvbiB0 aGUgZGF0YSBzaXplLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgdGhlIE1BWF9QQVlMT0FEU19TRVQg bWF5IG5vdCBjb21wcmlzZSBhbGwgdGhlIE1BWF9QQVlMT0FEUzxicj4NCiZndDsmZ3Q7IGJsb2Nr cy7igJ0pPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBBcmUgeW91IHRyeWluZyB0byBzYXkgdGhhdCBp ZiB0aGUgYm9keSBzaXplIGlzbuKAmXQgZXZlbmx5IGRpdmlzaWJsZTxicj4NCiZndDsmZ3Q7IGJ5 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBNQVhfUEFZTE9BRFMgdGhlbiB0aGUgZmluYWwgTUFYX1BB WUxPQURTX1NFVCB3aWxsIGhhdmUgZmV3ZXIgdGhhbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgTUFY X1BBWUxPQURTIGJsb2NrcyBpbiBpdD88YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm Z3Q7IFdlIG1lYW50IHRoYXQgdGhlIGxhc3Qgc2V0IG1heSBpbmNsdWRlIGZld2VyIGJsb2NrcyB0 aGFuPGJyPg0KJmd0OyZndDsgTUFYX1BBWUxPQURTLiBDaGFuZ2VkIHRvOjxicj4NCiZndDsmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgJnF1b3Q7IERlcGVuZGluZyBvbiB0aGUgb3ZlcmFsbCBk YXRhPGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Xl5eXl5eXl48YnI+DQomZ3Q7Jmd0OyZn dDsmbmJzcDsgc2l6ZSwgdGhlIGZpbmFsIE1BWF9QQVlMT0FEU19TRVQgbWF5IG5vdCBjb21wcmlz ZSBhbGwgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgXl5eXl48YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgTUFYX1BBWUxPQURTIGJs b2Nrcy4gJnF1b3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBCZXR0ZXI/ PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSW1wcm92aW5nLiBUaGUgd29yZCDigJxjb21w cmlzZeKAnSBpcyBwcm9uZSB0byBtaXNpbnRlcnByZXRhdGlvbiBpbiBteTxicj4NCiZndDsmZ3Q7 IGV4cGVyaWVuY2UsIEkgd291bGQgc3VnZ2VzdCBzb21ldGhpbmcgbGlrZSDigJzigKYgdGhlcmUg Y291bGQgYmUgZmV3ZXI8YnI+DQomZ3Q7Jmd0OyB0aGFuIE1BWF9QQVlMT0FEUyBibG9ja3MgaW4g dGhlIGZpbmFsIE1BWF9QQVlMT0FEU19TRVQu4oCdPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZn dDsgVGhhbmtzLDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IOKAlEpvaG48YnI+DQomZ3Q7 IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgPGJyPg0KJmd0OyBDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8YnI+DQomZ3Q7IHBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyPGJyPg0KJmd0OyBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLDxicj4NCiZndDsgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ozxicj4NCiZndDsgdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPGJyPg0K Jmd0OyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy48YnI+DQomZ3Q7IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC48YnI+DQomZ3Q7IFRoYW5rIHlvdS48YnI+DQomZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlv dS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93303538C6ABOPEXCAUBMA2corp_-- From nobody Fri May 21 10:53:01 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 044753A1960; Fri, 21 May 2021 10:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=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 jpLPFnTk90jO; Fri, 21 May 2021 10:52:54 -0700 (PDT) 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 9DAFD3A1979; Fri, 21 May 2021 10:52:47 -0700 (PDT) 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 14LHqbRt004666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 May 2021 13:52:43 -0400 Date: Fri, 21 May 2021 10:52:37 -0700 From: Benjamin Kaduk To: mohamed.boucadair@orange.com Cc: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Message-ID: <20210521175237.GS32395@kduck.mit.edu> References: <162026630680.17506.6477675472375470197@ietfa.amsl.com> <12589_1620322520_609428D8_12589_262_1_787AE7BB302AE849A7480A190F8B933035377DD2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20210513215221.GH79563@kduck.mit.edu> <4685_1621248354_60A24962_4685_382_1_787AE7BB302AE849A7480A190F8B9330353899CD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4685_1621248354_60A24962_4685_382_1_787AE7BB302AE849A7480A190F8B9330353899CD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: (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, 21 May 2021 17:52:59 -0000 Hi Med, Jon, Thanks for the diff and commentary. My concerns have been addressed (so no further remarks inline). I guess I'm the last discuss-holder for this one, so presumably it's time to upload a new I-D and then Francesca and I get to push buttons in the datatracker... Thanks again, Ben On Mon, May 17, 2021 at 10:45:53AM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben, > > Please see inline. The latest changes can be tracked at: https://tinyurl.com/new-block-latest. > > Cheers, > Jon & Med > > > -----Message d'origine----- > > De: Benjamin Kaduk [mailto:kaduk@mit.edu] > > Envoy: jeudi 13 mai 2021 23:52 > > : BOUCADAIR Mohamed TGI/OLN > > Cc: The IESG ; draft-ietf-core-new-block@ietf.org; > > core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se > > Objet: Re: Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: > > (with DISCUSS and COMMENT) > > > > Hi Med, > > > > On Thu, May 06, 2021 at 05:35:19PM +0000, > > mohamed.boucadair@orange.com wrote: > > > Hi Ben, > > > > > > Thank you for the review. All the changes can be tracked at: > > https://tinyurl.com/new-block-latest. > > > > (Apparently I waited long enough to be able to just use rfcdiff on > > the published -12; PR #26 posted with a couple nits from that diff.) > > > > Merged the PR. Thank you. > > > > Please see inline. > > > > > > Cheers, > > > Jon & Med > > > > > > > -----Message d'origine----- > > > > De: Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org] > > Envoy > > > > : jeudi 6 mai 2021 03:58 : The IESG Cc: > > > > draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; > > > > core@ietf.org; marco.tiloca@ri.se; marco.tiloca@ri.se Objet: > > > > Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: > > > > (with DISCUSS and COMMENT) > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-core-new-block-11: 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 DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found > > here: > > > > https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ > > > > > > > > > > > > > > > > ----------------------------------------------------------------- > > --- > > > > - > > > > - > > > > DISCUSS: > > > > ----------------------------------------------------------------- > > --- > > > > - > > > > - > > > > > > > > I have a concern about the MAX_PAYLOADS congestion-control > > parameter. > > > > In Section 7.2 it is stated that both endpoints only SHOULD have > > the > > > > same value. I don't see how this can be anything less than MUST, > > > > given that we attribute semantics to whether NUM modulo > > MAX_PAYLOADS > > > > is zero or non-zero in the processing of the Q-Block2 option. If > > > > the endpoints disagree on the value of MAX_PAYLOADS they will > > > > disagree on the semantics of Q-Block2 -- how can that be > > interoperable? > > > > (Being able to negotiate the value does not seem inherently > > > > problematic, but since it is relevant for protocol semantics it > > > > seems like the value must be identical on both endpoints.) This > > > > seems especially important to have clarity on given that the > > current > > > > specification allows for MAX_PAYLOADS to be decreased at runtime > > in > > > > response to congestion feedback over a 24-hour period, with no > > > > synchronization between peers provided ("Note that the CoAP peer > > > > will not know about the MAX_PAYLOADS change until it is > > > > reconfigured".) > > > > > > > > > > > > > > Implementation testing with MAX_PAYLOAD being different in the > > peers showed things worked badly (unnecessary timeouts/recovery) but > > continued to work. > > > > > > If the peers were negotiating and installing a new common value > > (application layer), there was a brief period of instability. > > > > I still think there's a fundamental mismatch between "this is a > > parameter that is part of the protocol and part of request/response > > semantics" and "this is a parameter that each endpoint is allowed to > > vary unilaterally". > > This holds even if we attempt to set things up so in the former case > > the behavior degrades somewhat gracefully, with one direction > > transmitting as expected and the other only making slow progress. > > > > If this was just a local parameter for how to batch and pace > > transmissions, that would be fine, and letting it vary (even if not > > recommended) between peers would also be fine. > > > > But the -12 currently has text like (4.4): > > > > In a request for any block number, the M bit unset indicates the > > request is just for that block. If the M bit is set, this has > > different meanings based on the NUM value: > > > > NUM is zero: This is a request for the entire body. > > > > 'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero: This is > > used to confirm that the current MAX_PAYLOADS_SET (the latest > > block having block number NUM-1) has been successfully received > > and that, upon receipt of this request, the server can continue > > to > > send the next MAX_PAYLOADS_SET (the first block having block > > number NUM). This is the 'Continue' Q-Block-2 and conceptually > > has the same usage (i.e., continue sending the next set of > > data) > > as the use of 2.31 (Continue) for Q-Block1. > > > > Any other value of NUM: This is a request for that block and for > > all > > of the remaining blocks in the current MAX_PAYLOADS_SET. > > > > That is, the semantics of a request are supposed to depend on the > > value of MAX_PAYLOADS. The semantics of what the sender sent can > > disagree with the semantics of what the receiver interprets, if there > > is skew in this value. > > > > Now, maybe it happens that things work out okay if the client and > > server have different MAX_PAYLOADS values, in that setting the M bit > > does not have to be tied to a specific MAX_PAYLOADS_SET and rather > > means "give me a chunk of up to your max-transmit-window of > > payloads", and the receiver's value determines whether the "up to" > > means a full window's worth or not, but that's not what we say it > > means. For Proposed Standards, I think we need to be accurate about > > what the semantics actually are, not just what they are in the ideal > > case, if the MAX_PAYLOADS value is allowed to vary between peers. > > And if skew is allowed, we need to say that behavior degrades in case > > of skew and how, but that progress will still be made. > > > > (Even if the semantics actually are "give me a chunk of up to your > > max-window", things can still end up behaving badly if the skew is > > quite significant -- if I think I'm asking for a window of up to 10 > > blocks but I get back 100, I may not be able to handle the full > > response.) > > > > > > > Please note that this is a value that is unlikely to change: 1500 > > byte packets and MAX_PAYLOADS(10) gives a set of 15,000 bytes. With > > an up to NON_TIMEOUT (2 secs) delay, average data rates are of the > > order of 60kbps (1500 * 8 * 10 / 2), so providing the congested > > network can handle 60Kbps, all will be OK. If higher values, then the > > 'Continue' will come back quicker than the NON_TIMEOUT. > > > > If it's unlikely to change, then what's wrong with making it a fixed > > parameter (subject to change by out-of-band agreement)? > > These are fair observations. We made the following changes: > > (1) > > OLD: > MAX_PAYLOADS should be configurable with a default value of 10. Both > CoAP endpoints SHOULD have the same value (otherwise there will be > transmission delays in one direction) and the value MAY be negotiated > between the endpoints to a common value by using a higher level > protocol (out of scope of this document). > > NEW: > MAX_PAYLOADS should be configurable with a default value of 10. Both > CoAP endpoints MUST have the same value (otherwise there will be > transmission delays in one direction) and the value MAY be negotiated > between the endpoints to a common value by using a higher level > protocol (out of scope of this document). > > (2) replaced this text with a note: > > OLD: > If the CoAP peer reports that at least one payload has not arrived > for each body for at least a 24-hour period and it is known that > there are no other network issues over that period (e.g., DDoS > attacks), then the value of MAX_PAYLOADS can be reduced by 1 at a > time (to a minimum of 1) and the situation re-evaluated for another > 24-hour period until there is no report of missing payloads under > normal operating conditions. Following a period of 24 hours where no > packet recovery was required, the value of MAX_PAYLOADS can be > increased by 1 (but without exceeding the default value) for a > further 24-hour evaluation. 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 > it is reconfigured. As a consequence of the two peers having > different MAX_PAYLOADS values, a peer may continue indicating that > there are some missing payloads as all of its MAX_PAYLOADS_SET may > not have arrived. How the two peer values for MAX_PAYLOADS are > synchronized is out of the scope. > > NEW: > Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET having > 10 payloads, this corresponds to 1500 * 10 * 8 = 120 Kbits. With > a maximum delay of 2 seconds between MAX_PAYLOADS_SET, this > indicates an average speed requirement of 60 Kbps for a single > body should there be no responses. This transmission rate is > further reduced by being subject to PROBING_RATE. > > > > > > > > > > > > If the FETCH request includes the Observe Option, then the > > > > server > > > > MUST use the same token as used for the initial response > > for > > > > returning any Observe triggered responses so that the > > client > > > > can > > > > match them up. > > > > > > > > The client should then release all of the tokens used for > > this > > > > body unless a resource is being observed. > > > > > > > > If a resource is being observed, should the client release all > > the > > > > other tokens (than the one used for the initial response)? > > > > > > There is no reason why the client cannot release all the other > > tokens. > > > > > > > > > > > Also, is the "initial response" the first response for the > > blockwise > > > > transfer (which might be a 2.31 or 4.08 for NON requests), or the > > > > first one with response code 2.05? > > > > > > The "initial all data received response" - i.e. 2.01 or 2.05. > > > > I'd suggest adding that clarification. > > Sure. We made the following change: > > OLD: > If the FETCH request includes the Observe Option, then the server > MUST use the same token as used for the initial response for > returning any Observe triggered responses so that the client can > match them up. > > NEW: > If the FETCH request includes the Observe Option, then the server > MUST use the same token as used for the 2.05 (Content) response > for returning any Observe triggered responses so that the client > can match them up. > > > > > > > > > > > 2.31 (Continue) > > > > > > > > This Response Code can be used to indicate that all of the > > > > blocks > > > > up to and including the Q-Block1 Option block NUM (all > > having > > > > the > > > > M bit set) have been successfully received. The token used > > > > MUST > > > > be one of the tokens that were received in a request for > > this > > > > block-wise exchange. However, it is desirable to provide > > the > > > > one > > > > used in the last received request. > > > > > > > > Can the client release any tokens upon receipt of such a > > response? > > > > > > Yes. If going with the Implementation Note #6., the lower 32 bits > > tracker must not be released. > > > > Since we mention releasing tokens for other response codes, it would > > feel natural to mention it here as well, to me. > > Added this NEW text: > > The client should then release all of the tokens used for this > MAX_PAYLOADS_SET. > > > > > > > > > > > 4.02 (Bad Option) > > > > > > > > This Response Code MUST be returned for a Confirmable > > request > > > > if > > > > the server does not support the Q-Block Options. Note that > > a > > > > reset message must be sent in case of Non-confirmable > > request. > > > > > > > > Reset only needs to be sent if the server is not ignoring the > > > > request entirely, though, right? > > > > > > The request will be rejected. Please see: > > > > > > A Non-confirmable > > > message with an unrecognized critical option is either rejected > > with > > > a Reset message or just silently ignored (Sections 5.4.1 and 4.3 > > of > > > [RFC7252]). > > > > I don't think I understand. "either rejected ... or just silently > > ignored" > > says that "just silently ignore" is a valid way to handle such a > > message. > > So, if "silently ignore" is a valid option for the server, I don't > > see how we can say "must be sent" without deviating from RFC 7252. > > > > Fair point: s/must be sent/may be sent. We don't want to deviate from 7252. > > > > > > For Confirmable responses, the client continues to acknowledge > > > > each > > > > packet. Typically, the server acknowledges the initial > > request > > > > using > > > > an ACK with the payload, and then sends the subsequent > > payloads as > > > > CON responses. The server will detect failure to send a > > packet, > > > > but > > > > the client can issue, after a MAX_TRANSMIT_SPAN delay, a > > separate > > > > GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks > > as > > > > needed. > > > > > > > > Starting out with "for confirmable responses" implies that we're > > > > going to separately cover non-confirmable responses later, or at > > > > some point transition to statements of general applicability (to > > > > both confirmable and non-confirmable responses). Where does that > > happen? > > > > > > It is in this section. The text you quoted is what is specific to > > CON responses. > > > > I would have preferred a more explicit signal that the subsequent > > paragraphs apply to both the confirmable and non-confirmable cases, > > but the only option I'm coming up with at the moment ("for both > > confirmable and non-confirmable responses" to start the subsequent > > paragraph") is not great. > > > > We reordered the text so that the text about confirmable is positioned at the end of the section. > > > > > Section 5 > > > > > > > > The data payload of the 4.08 (Request Entity Incomplete) > > response > > > > is > > > > encoded as a CBOR Sequence [RFC8742]. It comprises of one or > > > > more > > > > > > > > I think we want some qualifying text that reaffirms that the > > > > behavior being described is applicable only to the > > > > application/missing- > > > > blocks+cbor-seq content-type case, possibly by having the > > previous > > > > discussion state that "this section defines the behavior and > > > > semantics for 4.08 responses using the new content-type." > > > > > > Why is this needed? > > > > The data payload of the 4.08 response as specified in RFC 7959 is not > > a CBOR sequence. The current wording and paragraph structure doesn't > > provide a clear connection between the new content-type (as mentioned > > in the first sentence of the section) and this text, so a reader > > might misread this text (which has no normative keywords) as > > describing the preexisting situation for 4.08 responses, and that is > > not correct. Even just adding the word "new" ("data payload of the > > new 4.08 (Request Entity Incomplete) response") would help clarify > > that the description is of the new behavior, not the preexisting > > behavior. > > We understand your point better. Thanks. We made this change: > > OLD: > The data payload of the 4.08 (Request Entity Incomplete) response is > encoded as a CBOR Sequence [RFC8742]. > > NEW: > The new data payload of the 4.08 (Request Entity Incomplete) response > with Content-Type set to "application/missing-blocks+cbor-seq" is > encoded as a CBOR Sequence [RFC8742]. > > > > > > > > > > > The Concise Data Definition Language [RFC8610] (and see > > Section > > > > 4.1 > > > > [RFC8742]) for the data describing these missing blocks is as > > > > follows: > > > > > > > > (Should we mention that this is only informational and that the > > > > prose description is normative, in line with RFC 8610 being only > > an > > > > informative reference?) > > > > > > I'm not sure this is needed. What is authoritative is the CBOR > > sequence. > > > > In my experience, it's quite common for documents to specifically say > > whether the protocol-description-language version or the prose > > version is authoritative in case of conflict. Hopefully there is no > > conflict, but to have a clear and unambiguous specification, we have > > to say which version to use if there is a conflict. > > > > Let's then make things clear: > > NEW: > This CDDL syntax MUST be followed. > > > > > Section 6 > > > > > > > > Implementation Note: By using 8-byte tokens, it is possible > > to > > > > easily minimize the number of tokens that have to be > > tracked by > > > > clients, by keeping the bottom 32 bits the same for the > > same > > > > body > > > > and the upper 32 bits containing the current body's request > > > > number > > > > (incrementing every request, including every re-transmit). > > > > This > > > > allows the client to be alleviated from keeping all the > > per- > > > > request-state, e.g., in Section 3 of [RFC8974]. > > > > > > > > If we're going to introduce structure into a nominally opaque > > > > identifier, we need to discuss the consequences of that in the > > > > security considerations. draft-gont-numeric-ids-sec- > > considerations > > > > has some guidance in this regard. > > > > > > It is all opaque to the server, the client is just using it to make > > sure his requests are unique. If one can access the token, it can > > access more critical information. I'm not sure there is much to say > > as the messages are not supposed to be sent on clear. Tampering of > > the token is thus very difficult given we are not using NoSec. > > > > It's only NOT RECOMMENDED to use NoSec, which means we still have to > > accurately document the security considerations if NoSec is used. > > > > Added this NEW text: > > "However, if using NoSec, Section 5.2 of [RFC8974] needs to be considered for > security implications." > > Section 11 is also updated with this NEW text: > > If OSCORE is not used, it is also NOT RECOMMENDED to use the NoSec > security mode if either the Q-Block1 or Q-Block2 Options is used. > > If NoSec is being used, Section D.5 of [RFC8613] discusses the > security analysis and considerations for unprotected message fields > even if OSCORE is not being used. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 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 been modified, changed or falsified. > Thank you. > From nobody Fri May 21 11:02:00 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 4DAB03A18A7; Fri, 21 May 2021 11:01:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162162011828.11745.11713846030520215336@ietfa.amsl.com> Date: Fri, 21 May 2021 11:01:58 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-new-block-13.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, 21 May 2021 18:01: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 : Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission Authors : Mohamed Boucadair Jon Shallow Filename : draft-ietf-core-new-block-13.txt Pages : 48 Date : 2021-05-21 Abstract: This document specifies alternative Constrained Application Protocol (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. These options are similar to, but distinct from, the CoAP Block1 and Block2 Options defined in RFC 7959. Q-Block1 and Q-Block2 Options are not intended to replace Block1 and Block2 Options, but rather have the goal of supporting Non-confirmable messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 Options support 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 is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 21 11:05: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 3557F3A19DF; Fri, 21 May 2021 11:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 D8P2jn_7p7Q1; Fri, 21 May 2021 11:05:46 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 289603A19DB; Fri, 21 May 2021 11:05:46 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 4Fmvfb52B7z27HC; Fri, 21 May 2021 20:05:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1621620343; bh=qofMFypULNn5XXXUUMGzop1czOxxqf3RjoqJ3U+mUg4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=QmHTWeffjPUqqRCyhVmbsS3eapkbEx2/7/l2jOTdwhNKyS1HSnwjJ/9eGDgKWdhUn PZbrCPhmtglg/LR120HzFFvHS+z5aHRE0XzmiaNklhwLDkTOoNSjui5uHXaqWAFUqY dBtMscShX6GvMoG48a6r68GbVTDhIQ7zdlVZTHIcqWKHa8mDVmkMFMsJkbywjkqAnR seQ327JVt3Xz2Vv4xoHugrOY3Qut216jQC3yNTAnTEhhCFZtSOfAA3eQwrEcA+9L/n AGp5+zsiCRvhsvuJkeIuHstrH4bUM0klCIydmCsleHc+3wsxKA/xAKbTOjsOpCv1rP efCSkV8p5o7kg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4Fmvfb4HYyzDq8K; Fri, 21 May 2021 20:05:43 +0200 (CEST) From: To: Benjamin Kaduk CC: The IESG , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXTmoqSKiI2D9+NUG0sjjiJXnxT6ruOlWw Date: Fri, 21 May 2021 18:05:42 +0000 Message-ID: <20402_1621620343_60A7F677_20402_265_1_787AE7BB302AE849A7480A190F8B93303538D4FC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162026630680.17506.6477675472375470197@ietfa.amsl.com> <12589_1620322520_609428D8_12589_262_1_787AE7BB302AE849A7480A190F8B933035377DD2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20210513215221.GH79563@kduck.mit.edu> <4685_1621248354_60A24962_4685_382_1_787AE7BB302AE849A7480A190F8B9330353899CD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20210521175237.GS32395@kduck.mit.edu> In-Reply-To: <20210521175237.GS32395@kduck.mit.edu> 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] Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: (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, 21 May 2021 18:05:51 -0000 Hi Ben,=20 Great. Done: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-new-block-= 13. Thank you for the very useful review.=20 Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: vendredi 21 mai 2021 19:53 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: The IESG ; draft-ietf-core-new-block@ietf.org; > core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se > Objet=A0: Re: Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11: > (with DISCUSS and COMMENT) >=20 > Hi Med, Jon, >=20 > Thanks for the diff and commentary. > My concerns have been addressed (so no further remarks inline). >=20 > I guess I'm the last discuss-holder for this one, so presumably it's > time to upload a new I-D and then Francesca and I get to push buttons > in the datatracker... >=20 > Thanks again, >=20 > Ben ___________________________________________________________________________= ______________________________________________ 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 Fri May 21 11:16: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 86B723A1A2E; Fri, 21 May 2021 11:16:06 -0700 (PDT) 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-new-block@ietf.org, core-chairs@ietf.org, core@ietf.org, marco.tiloca@ri.se, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <162162096651.11745.11475318344342658600@ietfa.amsl.com> Date: Fri, 21 May 2021 11:16:06 -0700 Archived-At: Subject: [core] Benjamin Kaduk's No Objection on draft-ietf-core-new-block-13: (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, 21 May 2021 18:16:07 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-core-new-block-13: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my discuss and comment points! In reviewing the latest updates, I briefly tried to cross-reference the formula in section 7.2: NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1) * ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT My initial attempt found that the corresponding formulae in RFC 7252 used PROCESSING_DELAY instead of NON_TIMEOUT for the last term, but I did not go back to double-check. It's possible I'm just misreading something. From nobody Fri May 21 11:38: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 8EF823A1AD5; Fri, 21 May 2021 11:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 taPy2e5BN02g; Fri, 21 May 2021 11:38:48 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 E71083A1ADB; Fri, 21 May 2021 11:38:47 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id e14so19022862ils.12; Fri, 21 May 2021 11:38:47 -0700 (PDT) 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=Rqe4ZP2SbhhLJOPHV0Pwlg7cGchPsWsGmh799bpCy9E=; b=e7CWkQF1ghUuqnIYnRxxRrsHVwPxFfDAeBg8lyiwUiDA7q8t5CGba819s7E8/jOutC USOHJCN0MEw1FyqadkcOvGfswan7mIkDnpruUjqU9LNvJE8R5WaqYsUG6hLfhjv1PvsU 6dOIMXguSDafDXdtiK5rQB+oLWSEChSA8UUO9lCQGknaXy9SeZfZgcotC/4YngzVz303 xW7RR6Pn5sxSYp7gtvy6v8EpRuFN0xm48yylJmizCKmxnqsB4OvApMfKG+AqYIeicJ4y GGGY0Q1a617TR/eF5Aj/n+OM9yOBuxN2XMnc3GxqYE2/O3tIgxUF5HOYfsJkWmgJITNe z8pQ== 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=Rqe4ZP2SbhhLJOPHV0Pwlg7cGchPsWsGmh799bpCy9E=; b=UTNt1yd6zPhM/80FS9GM94soc4CeoSfAs26p+ijVDnRmRsGLue7WD85cS20O7pz/0f jhZKsjiIe+cP79UDnC8hVdNTvZ/Jao+WMWAgk6o8O7bGOsLokqpFi4iKdGOqHc2gAOuZ JaXzppvMtq3bSgpVhWSGqRQisCGGTtsTTU3JSp6ZOCykLpOdx+/WdhRZmaErCh3hdHtM HqspCYR+xYauQdxt5trQGBztn8HFNP/erk6tX3xCUPX5qkLOj4G8q8kZn7vz7YxNjsfJ t2NllwLSfYFvToxDTMxQrTATzbxVPvh6gMgbShzBR5b03vGRSFk7HwYjXhwHtr7UR2ln zIsA== X-Gm-Message-State: AOAM533FKKCgV54fh9FWZYUxfHmE84rag2PiasPmD7kIhmJcUEICB1w3 RVnKQRiDO2n80krRh3gfTFi8CHHp8BqvsCteBZU= X-Google-Smtp-Source: ABdhPJx5224YBGIH08YylZJku+GHdnxUhWotkVCZDa1D6jZO0a9Orx1wmRWhH+Xi7RzALRfhk2Sp0Lg2j2IYSwhefeE= X-Received: by 2002:a05:6e02:2162:: with SMTP id s2mr83162ilv.237.1621622326248; Fri, 21 May 2021 11:38:46 -0700 (PDT) MIME-Version: 1.0 References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net> <23771_1621516652_60A6616C_23771_79_1_787AE7BB302AE849A7480A190F8B93303538BB63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4833_1621600918_60A7AA96_4833_485_3_787AE7BB302AE849A7480A190F8B93303538C272@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <36A5A92C-AD99-4554-8A09-4E76E60BA98A@juniper.net> <17420_1621618028_60A7ED6C_17420_17_28_787AE7BB302AE849A7480A190F8B93303538C6AB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <17420_1621618028_60A7ED6C_17420_17_28_787AE7BB302AE849A7480A190F8B93303538C6AB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Martin Duke Date: Fri, 21 May 2021 11:38:35 -0700 Message-ID: To: mohamed.boucadair@orange.com Cc: John Scudder , "draft-ietf-core-new-block@ietf.org" , "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "marco.tiloca@ri.se" Content-Type: multipart/alternative; boundary="000000000000b7499d05c2db5e62" Archived-At: Subject: Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (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, 21 May 2021 18:38:54 -0000 --000000000000b7499d05c2db5e62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that those two parameters have no need for jitter. However, NON_TIMEOUT and NON_RECEIVE_TIMEOUT would appear to, but derive from 7252 formulae that don't have the jitter included. On Fri, May 21, 2021 at 10:27 AM wrote: > Hi Martin, > > > > The comment about large numbers should be put in the context of the two > timeouts discussed with John: NON_PARTIAL_TIMEOUT and NON_PROBING_WAIT. > Consider the example of NON_PARTIAL_TIMEOUT, adding some jitter to it is > unlikely to have an effect as that timer is about controlling when a > received partial body will be discarded locally. > > > > NON_PROBING_WAIT is about limiting the effect of PROBING_RATE when a peer > does not reply. As a reminder, probing rate is defined as follows: > > > > The 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. > > > > Cheers, > > Med > > > > *De :* Martin Duke [mailto:martin.h.duke@gmail.com] > *Envoy=C3=A9 :* vendredi 21 mai 2021 18:28 > *=C3=80 :* John Scudder > *Cc :* BOUCADAIR Mohamed TGI/OLN ; > draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; The IESG < > iesg@ietf.org>; core@ietf.org; marco.tiloca@ri.se > *Objet :* Re: John Scudder's Discuss on draft-ietf-core-new-block-11: > (with DISCUSS and COMMENT) > > > > So I'm not sure that "large numbers" are a sufficient reason to not worry > about jitter. > > > > If two hosts simultaneously transmit on a quiet network, and cause losses > with each other. They both set the same retransmission timeout, and in > spite of no other traffic around cause the same collision, etc. > > > > If an explicit configuration doesn't result in common round numbers, it's > an OK substitute, but I don't see any encouragement of that choice. > > > > On Fri, May 21, 2021 at 9:17 AM John Scudder 40juniper.net@dmarc.ietf.org> wrote: > > Hi Med, > > Your current working copy looks good. I=E2=80=99ve cleared my discuss. > > =E2=80=94John > > > On May 21, 2021, at 8:41 AM, mohamed.boucadair@orange.com wrote: > > > > [External Email. Be cautious of content] > > > > > > Hi John, > > > > As you can see in > https://urldefense.com/v3/__https://tinyurl.com/new-block-latest__;!!NEt6= yMaO-gk!RlDk7GMcbxlFsT2QGl8ma04s1CggmQZQHcIP9aw2R2EP1rWkfQDAbIpzOgyR6g$ > > , we went with the following changes to better address your latest commen= t > on the jitter: > > > > (1) be explicit about the formula used for default values: > > > > OLD: > > NON_PROBING_WAIT is used to limit the potential wait needed when > > using PROBING_RATE. By default, NON_PROBING_WAIT has the same value > > as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). > > > > NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. > > By default, NON_PARTIAL_TIMEOUT has the same value as > > EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). > > > > NEW: > > NON_PROBING_WAIT is used to limit the potential wait needed when > > using PROBING_RATE. By default, NON_PROBING_WAIT is computed in the > > same way as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but with > > ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOUT and > > NON_MAX_RETRANSMIT, respectively: > > > > NON_PROBING_WAIT =3D NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1)= * > > ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT > > > > NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. > > By default, NON_PARTIAL_TIMEOUT is computed in the same way as > > EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). This default value > > is calculated in the same way as NON_PROBING_WAIT. > > > > (2) We don=E2=80=99t see a need to apply a jitter when a value is expli= citly > configured (these are expected to be large numbers, we don't care that mu= ch > on the jitter). We added this text to be clear about the intent, and whic= h > BTW reflects the current implementation: > > > > NEW: > > When explicit values are > > configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these > > values are used without applying any jitter. > > > > We also adopted your proposed edits in the message below. > > > > Thank you again for the careful review. This is highly appreciated. > > > > Cheers, > > John & Med > > > >> -----Message d'origine----- > >> De : John Scudder [mailto:jgs@juniper.net] > >> Envoy=C3=A9 : vendredi 21 mai 2021 00:03 > >> =C3=80 : BOUCADAIR Mohamed TGI/OLN > >> Cc : The IESG ; draft-ietf-core-new-block@ietf.org; > >> core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se > >> Objet : Re: John Scudder's Discuss on draft-ietf-core-new-block-11: > >> (with DISCUSS and COMMENT) > >> > >> Hi Mohamed, > >> > >> I think we are converging. My comments in line. I=E2=80=99ve snipped a= greed > >> points for brevity, indicated by [=E2=80=A6]. > >> > >>> On May 20, 2021, at 9:17 AM, mohamed.boucadair@orange.com wrote: > >> > >> [=E2=80=A6] > >> > >>>>>> 11. General > >>>>>> > >>>>>> By the way, none of the timers specify jitter (and indeed, if > >> read > >>>>>> literally, jitter would be forbidden). Is this intentional? > >>>>> > >>>>> No +/- tolerances have been defined. When a timer expires, then > >> the > >>>> next action takes place. > >>>> > >>>> I notice that RFC 7252 jitters its timers, for example: > >>>> > >>>> counter. For a new Confirmable message, the initial timeout is > >> set > >>>> to a random duration (often not an integral number of seconds) > >>>> between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR) (see > >>>> Section 4.8) > >>>> =E2=80=A6 > >>>> ACK_RANDOM_FACTOR MUST NOT be decreased below 1.0, and it SHOULD > >>>> have > >>>> a value that is sufficiently different from 1.0 to provide some > >>>> protection from synchronization effects. > >>>> > >>>> MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT are similarly jittered. A > >>>> number of your introduced parameters > >>>> > >>>> This document introduces new parameters MAX_PAYLOADS, > >> NON_TIMEOUT, > >>>> NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and > >>>> NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3). > >>>> > >>>> appear at least superficially similar to the timers the authors of > >>>> RFC 7252 deemed important to jitter to prevent synchronization > >>>> effects. Did you specifically consider jittering them, and decide > >>>> that jitter was unnecessary? If so, can you explain what is > >> different > >>>> about your specification, compared to the base spec, that > >> eliminates > >>>> the concern? > >>> > >>> RFC7252 introduces ACK_RANDOM_FACTOR jitter and separately jitter > >> for multicast responses (which is not relevant here). > >>> > >>> The ACK_RANDOM_FACTOR is there for when re-transmitting a packet > >> that has not been acknowledged for some reason by its peer. > >> NON_TIMEOUT is for when the next MAX_PAYLOADS_SET can start > >> transmission (not re-transmission) assuming a 'Continue' has not > >> arrived in the interim, and so was not thought necessary to add in > >> ACK_RANDOM_FACTOR style jitter here. > >>> > >>> For NON_RECEIVE_TIMEOUT, what is important is that > >> NON_RECEIVE_TIMEOUT is greater than NON_TIMEOUT (We say in the spec a > >> minimum of one second) so that a peer does not fire off a re- > >> transmission request before the local agent has a chance to start to > >> transmit the next MAX_PAYLOADS_SET. NON_RECEIVE_TIMEOUT is > >> exponentially scaled for each retry to make sure that stability is > >> preserved. So, again, ACK_RANDOM_FACTOR jitter was not thought to be > >> necessary here. > >>> > >>> NON_MAX_RETRANSMIT is a fixed count. > >>> > >>> NON_PROBING_WAIT is used to put a limit on the potential delay that > >> could incur when obeying PROBING_WAIT when there is no peer response. > >> If the implementation goes with the default EXCHANGE_LIFETIME > >> computation, then NON_PROBING_WAIT includes ACK_RANDOM_FACTOR in the > >> math. > >>> > >>> NON_PARTIAL_TIMEOUT if computed using the default EXCHANGE_LIFETIME > >> includes ACK_RANDOM_FACTOR. > >> > >> Thanks for taking the time to explain. You don=E2=80=99t comment regar= ding > >> whether NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT should be jittered > >> or not, you just explain that if they use the default they get jitter > >> =E2=80=9Cfor free=E2=80=9D. The missing detail is that if they don=E2= =80=99t use the default > >> they don=E2=80=99t get jittered, so I think some consideration is stil= l > >> called for regarding whether having them not be jittered is OK. > >> > >> [=E2=80=A6] > >> > >>>>>> 15. Section 10.2.3 > >> > >> [=E2=80=A6] > >> > >>>> One concern related to that: waiting NON_TIMEOUT isn=E2=80=99t actua= lly > >>>> required, it=E2=80=99s only RECOMMENDED, therefore this isn=E2=80=99= t actually a > >>>> guarantee. From =C2=A77.2: > >>>> > >>>> As the sending of many payloads of a single body may itself > >> cause > >>>> congestion, it is RECOMMENDED that after transmission of every > >>>> MAX_PAYLOADS_SET of a single body, a delay is introduced of > >>>> NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage > >>>> potential congestion issues. > >>>> > >>>> I am curious why you made this a RECOMMENDED instead of a MUST. In > >> a > >>>> situation like this it would be preferable for you to explain to > >> the > >>>> implementor what situation they can ignore the RECOMMENDED in and > >>>> what they should do instead, or of course to make it into a MUST. > >>> > >>> Because a continue signal may be received from the peer and then > >> continue without waiting for the timeout to expire. > >>> > >>> This is to be linked with this text: > >>> > >>> A response using this Response Code SHOULD NOT be generated > >> for > >>> every received Q-Block1 Option request (Section 7.2). It > >> SHOULD > >>> only be generated when all the payload requests are Non- > >>> confirmable and a MAX_PAYLOADS_SET has been received by the > >>> server. More details about the motivations for this > >> optimization > >>> > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>> are discussed in Section 7.2. > >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>> > >>> We could use **MUST unless a 'Continue' is received**, e.g., > >>> > >>> OLD: > >>> As the sending of many payloads of a single body may itself cause > >>> congestion, it is RECOMMENDED that after transmission of every > >>> MAX_PAYLOADS_SET of a single body, a delay is introduced of > >>> NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage > >>> potential congestion issues. > >>> > >>> NEW: > >>> As the sending of many payloads of a single body may itself cause > >>> congestion, after transmission of every MAX_PAYLOADS_SET of a > >> single > >>> body, a delay MUST be introduced of NON_TIMEOUT before sending > >> the > >>> next MAX_PAYLOADS_SET to manage potential congestion issues. > >>> However, if a 'Continue' is received from the peer for the > >> current > >>> MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET can start > >>> transmission immediately. > >>> > >>> ... but I know that many would argue this is a SHOULD. > >> > >> I would be OK with either your proposed new text, or a SHOULD/MAY > >> pair as in > >> > >> NEW: > >> As the sending of many payloads of a single body may itself cause > >> congestion, after transmission of every MAX_PAYLOADS_SET of a > >> single > >> body, a delay SHOULD be introduced of NON_TIMEOUT before sending > >> the > >> next MAX_PAYLOADS_SET to manage potential congestion issues. > >> However, if a 'Continue' is received from the peer for the current > >> MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET MAY start > >> transmission immediately. > >> > >> If you want to stick with MUST I think you can clear up the pain with > >> something like > >> > >> NEW: > >> As the sending of many payloads of a single body may itself cause > >> congestion, after transmission of every MAX_PAYLOADS_SET of a > >> single > >> body, a delay MUST be introduced of NON_TIMEOUT before sending the > >> next MAX_PAYLOADS_SET unless a 'Continue' is received from the peer > >> for the current MAX_PAYLOADS_SET, in which case the next > >> MAX_PAYLOADS_SET MAY start transmission immediately. > >> > >> (To my eye presenting the option in this way makes it clear when the > >> MUST does, and doesn=E2=80=99t, apply. This is my preferred form but I= don=E2=80=99t > >> insist.) > >> > >> [=E2=80=A6] > >> > >>>> 17. Section 1: > >>>> > >>>> This document introduces the CoAP Q-Block1 and Q-Block2 Options > >>>> which > >>>> allow block-wise transfer to work with series of Non-confirmable > >>>> messages, instead of lock-stepping using Confirmable messages > >>>> (Section 3). In other words, this document provides a missing > >>>> piece > >>>> of [RFC7959], namely the support of block-wise transfer using > >> Non- > >>>> confirmable where an entire body of data can be transmitted > >> without > >>>> the requirement for an acknowledgement (but recovery is > >> available > >>>> should it be needed). > >>>> > >>>> As far as I can tell the spec does not really remove the > >> requirement > >>>> for acknowledgement, > >>> > >>> These are not required. They were added as an optimization to avoid > >> the non-timeout if the peer decides to use it. > >> > >> As I mentioned below (=E2=80=9Cawfully close parsing=E2=80=9D), I thin= k that although > >> you can find some justification for this reading, it=E2=80=99s debatab= le. > >> Transmission of the acknowledgement (at least the final > >> acknowledgement of the entire body, in the form of a Response Code) > >> is required, is it not? Reception isn=E2=80=99t required though. Witho= ut the > >> verb, I=E2=80=99m not sure whether I can say whether acknowledgement i= s, or > >> isn=E2=80=99t, required. > >> > >> I don=E2=80=99t insist that you change this, but I do think you could = improve > >> the clarity of the document, if you edited the above to read =E2=80=9C= =E2=80=A6 > >> without the requirement that an acknowledgment be received from the > >> peer" > >> > >>>> it just amortizes the acknowledgements by only sending them every > >>>> MAX_PAYLOADS_SET. Response Code 2.31 is essentially an > >>>> acknowledgement, and it gets sent that frequently, right? There=E2= =80=99s > >>>> also (if I recall correctly) some flavor of acknowledgement that > >> is > >>>> sent when the entire body has been transferred. So, I think the > >> new > >>>> paragraph isn=E2=80=99t accurate. > >>>> > >>>> This observation also applies to this claimed benefit in =C2=A73: > >>>> > >>>> o They support sending an entire body using NON messages > >> without > >>>> requiring an intermediate response from the peer. > >> > >> And similarly, =E2=80=9C=E2=80=A6 without requiring that an intermedia= te response be > >> received from the peer.=E2=80=9D > >> > >> [=E2=80=A6] > >> > >>>> 18. Section 2: > >>>> > >>>> MAX_PAYLOADS_SET is the set of blocks identified by block > >> numbers > >>>> that, when divided by MAX_PAYLOADS, they have the same numeric > >>>> > >>>> Remove =E2=80=9Cthey=E2=80=9D > >>> > >>> Fixed. Thanks. > >>> > >>>> > >>>> result. For example, if MAX_PAYLOADS is set to '10', a > >>>> MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc. > >>>> Depending on the data size, the MAX_PAYLOADS_SET may not > >> comprise > >>>> all > >>>> the MAX_PAYLOADS blocks. > >>>> > >>>> I don=E2=80=99t understand the last sentence ("Depending on the data= size, > >>>> the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS > >> blocks.=E2=80=9D) > >>>> Are you trying to say that if the body size isn=E2=80=99t evenly div= isible > >> by > >>>> MAX_PAYLOADS then the final MAX_PAYLOADS_SET will have fewer than > >>>> MAX_PAYLOADS blocks in it? > >>> > >>> We meant that the last set may include fewer blocks than > >> MAX_PAYLOADS. Changed to: > >>> > >>> " Depending on the overall data > >>> ^^^^^^^^ > >>> size, the final MAX_PAYLOADS_SET may not comprise all the > >>> ^^^^^ > >>> MAX_PAYLOADS blocks. " > >>> > >>> Better? > >> > >> Improving. The word =E2=80=9Ccomprise=E2=80=9D is prone to misinterpre= tation in my > >> experience, I would suggest something like =E2=80=9C=E2=80=A6 there co= uld be fewer > >> than MAX_PAYLOADS blocks in the final MAX_PAYLOADS_SET.=E2=80=9D > >> > >> Thanks, > >> > >> =E2=80=94John > > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles 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 > been modified, changed or falsified. > > Thank you. > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --000000000000b7499d05c2db5e62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that those two parameters have no need for ji= tter.

However, NON_TIMEOUT and NON_RECEIVE_TIMEOUT= would appear to, but derive from 7252 formulae that don't have the jit= ter included.

On Fri, May 21, 2021 at 10:27 AM <mohamed.boucadair@orange.com> wrote= :

Hi Martin,

=C2=A0

The comment about large numbers should = be put in the context of the two timeouts discussed with John: NON_PARTIAL_= TIMEOUT and NON_PROBING_WAIT. Consider the example of NON_PARTIAL_TIMEOUT, adding some jitter to it is unlikely to have an ef= fect as that timer is about controlling when a received partial body will b= e discarded locally.

=C2=A0

NON_PROBING_WAIT is about limiting the = effect of PROBING_RATE when a peer does not reply. As a reminder, probing r= ate is defined as follows:

=C2=A0

=C2=A0=C2=A0 The PROBING_RATE parameter= in CoAP indicates the average data rate

=C2=A0=C2=A0 that must not be exceeded = by a CoAP endpoint in sending to a peer

=C2=A0=C2=A0 endpoint that does not res= pond.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Martin= Duke [mailto:= martin.h.duke@gmail.com]
Envoy=C3=A9=C2=A0: vendredi 21 mai 2021 18:28
=C3=80=C2=A0: John Scudder <jgs=3D40juniper.net@dmarc.ietf.org>
Cc=C2=A0: BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>;= dr= aft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; The IESG <iesg@ietf.org>; core@ietf.org; marco.tiloca@ri.se
Objet=C2=A0: Re: John Scudder's Discuss on draft-ietf-core-new-b= lock-11: (with DISCUSS and COMMENT)

=C2=A0

So I'm not sure that "large numbers" a= re a sufficient reason to not worry about jitter.

=C2=A0

If two hosts simultaneously transmit on a quiet netw= ork, and cause losses with each other. They both set the same retransmissio= n timeout, and in spite of no other traffic around cause the same collision= , etc.

=C2=A0

If an explicit configuration doesn't result in c= ommon round numbers, it's an OK substitute, but I don't see any enc= ouragement of that choice.

=C2=A0

On Fri, May 21, 2021 at 9:17 AM John Scudder <jgs= =3D40juni= per.net@dmarc.ietf.org> wrote:

Hi Med,

Your current working copy looks good. I=E2=80=99ve cleared my discuss.

=E2=80=94John

> On May 21, 2021, at 8:41 AM, mohamed.boucadair@orange.com wrote:
>
> [External Email. Be cautious of content]
>
>
> Hi John,
>
> As you can see in https://urldefense.com/v3/__https://tinyurl.com/new-block-latest__;!!NEt6yM= aO-gk!RlDk7GMcbxlFsT2QGl8ma04s1CggmQZQHcIP9aw2R2EP1rWkfQDAbIpzOgyR6g$ ,= we went with the following changes to better address your latest comment o= n the jitter:
>
> (1) be explicit about the formula used for default values:
>
> OLD:
>=C2=A0 =C2=A0NON_PROBING_WAIT is used to limit the potential wait neede= d when
>=C2=A0 =C2=A0using PROBING_RATE.=C2=A0 By default, NON_PROBING_WAIT has= the same value
>=C2=A0 =C2=A0as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
>
>=C2=A0 =C2=A0NON_PARTIAL_TIMEOUT is used for expiring partially receive= d bodies.
>=C2=A0 =C2=A0By default, NON_PARTIAL_TIMEOUT has the same value as
>=C2=A0 =C2=A0EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
>
> NEW:
>=C2=A0 =C2=A0NON_PROBING_WAIT is used to limit the potential wait neede= d when
>=C2=A0 =C2=A0using PROBING_RATE.=C2=A0 By default, NON_PROBING_WAIT is = computed in the
>=C2=A0 =C2=A0same way as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252])= but with
>=C2=A0 =C2=A0ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOU= T and
>=C2=A0 =C2=A0NON_MAX_RETRANSMIT, respectively:
>
>=C2=A0 =C2=A0 =C2=A0 NON_PROBING_WAIT =3D NON_TIMEOUT * ((2 ** NON_MAX_= RETRANSMIT) - 1) *
>=C2=A0 =C2=A0 =C2=A0 ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOU= T
>
>=C2=A0 =C2=A0NON_PARTIAL_TIMEOUT is used for expiring partially receive= d bodies.
>=C2=A0 =C2=A0By default, NON_PARTIAL_TIMEOUT is computed in the same wa= y as
>=C2=A0 =C2=A0EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).=C2=A0 This= default value
>=C2=A0 =C2=A0is calculated in the same way as NON_PROBING_WAIT.
>
> (2) We don=E2=80=99t see a need to apply a jitter when a value is expl= icitly configured (these are expected to be large numbers, we don't car= e that much on the jitter). We added this text to be clear about the intent= , and which BTW reflects the current implementation:
>
> NEW:
>=C2=A0 =C2=A0 =C2=A0 When explicit values are
>=C2=A0 =C2=A0 =C2=A0 configured for NON_PROBING_WAIT and NON_PARTIAL_TI= MEOUT, these
>=C2=A0 =C2=A0 =C2=A0 values are used without applying any jitter.
>
> We also adopted your proposed edits in the message below.
>
> Thank you again for the careful review. This is highly appreciated. >
> Cheers,
> John & Med
>
>> -----Message d'origine-----
>> De : John Scudder [mailto:jgs@juniper.net]
>> Envoy=C3=A9 : vendredi 21 mai 2021 00:03
>> =C3=80 : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>=
>> Cc : The IESG <iesg@ietf.org>; dra= ft-ietf-core-new-block@ietf.org;
>> core-cha= irs@ietf.org; core@ietf.org; marco.tiloca@ri.se
>> Objet : Re: John Scudder's Discuss on draft-ietf-core-new-bloc= k-11:
>> (with DISCUSS and COMMENT)
>>
>> Hi Mohamed,
>>
>> I think we are converging. My comments in line. I=E2=80=99ve snipp= ed agreed
>> points for brevity, indicated by [=E2=80=A6].
>>
>>> On May 20, 2021, at 9:17 AM, mohamed.boucadair@orange.com wrote:
>>
>> [=E2=80=A6]
>>
>>>>>> 11. General
>>>>>>
>>>>>> By the way, none of the timers specify jitter (and= indeed, if
>> read
>>>>>> literally, jitter would be forbidden). Is this int= entional?
>>>>>
>>>>> No +/- tolerances have been defined. When a timer expi= res, then
>> the
>>>> next action takes place.
>>>>
>>>> I notice that RFC 7252 jitters its timers, for example: >>>>
>>>>=C2=A0 counter.=C2=A0 For a new Confirmable message, the in= itial timeout is
>> set
>>>>=C2=A0 to a random duration (often not an integral number o= f seconds)
>>>>=C2=A0 between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FA= CTOR) (see
>>>>=C2=A0 Section 4.8)
>>>> =E2=80=A6
>>>>=C2=A0 ACK_RANDOM_FACTOR MUST NOT be decreased below 1.0, a= nd it SHOULD
>>>> have
>>>>=C2=A0 a value that is sufficiently different from 1.0 to p= rovide some
>>>>=C2=A0 protection from synchronization effects.
>>>>
>>>> MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT are similarly jitt= ered. A
>>>> number of your introduced parameters
>>>>
>>>>=C2=A0 This document introduces new parameters MAX_PAYLOADS= ,
>> NON_TIMEOUT,
>>>>=C2=A0 NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING= _WAIT, and
>>>>=C2=A0 NON_PARTIAL_TIMEOUT primarily for use with NON (Tabl= e 3).
>>>>
>>>> appear at least superficially similar to the timers the au= thors of
>>>> RFC 7252 deemed important to jitter to prevent synchroniza= tion
>>>> effects. Did you specifically consider jittering them, and= decide
>>>> that jitter was unnecessary? If so, can you explain what i= s
>> different
>>>> about your specification, compared to the base spec, that<= br> >> eliminates
>>>> the concern?
>>>
>>> RFC7252 introduces ACK_RANDOM_FACTOR jitter and separately jit= ter
>> for multicast responses (which is not relevant here).
>>>
>>> The ACK_RANDOM_FACTOR is there for when re-transmitting a pack= et
>> that has not been acknowledged for some reason by its peer.
>> NON_TIMEOUT is for when the next MAX_PAYLOADS_SET can start
>> transmission (not re-transmission) assuming a 'Continue' h= as not
>> arrived in the interim, and so was not thought necessary to add in=
>> ACK_RANDOM_FACTOR style jitter here.
>>>
>>> For NON_RECEIVE_TIMEOUT, what is important is that
>> NON_RECEIVE_TIMEOUT is greater than NON_TIMEOUT (We say in the spe= c a
>> minimum of one second) so that a peer does not fire off a re-
>> transmission request before the local agent has a chance to start = to
>> transmit the next MAX_PAYLOADS_SET.=C2=A0 NON_RECEIVE_TIMEOUT is >> exponentially scaled for each retry to make sure that stability is=
>> preserved. So, again, ACK_RANDOM_FACTOR jitter was not thought to = be
>> necessary here.
>>>
>>> NON_MAX_RETRANSMIT is a fixed count.
>>>
>>> NON_PROBING_WAIT is used to put a limit on the potential delay= that
>> could incur when obeying PROBING_WAIT when there is no peer respon= se.
>> If the implementation goes with the default EXCHANGE_LIFETIME
>> computation, then NON_PROBING_WAIT includes ACK_RANDOM_FACTOR in t= he
>> math.
>>>
>>> NON_PARTIAL_TIMEOUT if computed using the default EXCHANGE_LIF= ETIME
>> includes ACK_RANDOM_FACTOR.
>>
>> Thanks for taking the time to explain. You don=E2=80=99t comment r= egarding
>> whether NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT should be jittere= d
>> or not, you just explain that if they use the default they get jit= ter
>> =E2=80=9Cfor free=E2=80=9D. The missing detail is that if they don= =E2=80=99t use the default
>> they don=E2=80=99t get jittered, so I think some consideration is = still
>> called for regarding whether having them not be jittered is OK. >>
>> [=E2=80=A6]
>>
>>>>>> 15. Section 10.2.3
>>
>> [=E2=80=A6]
>>
>>>> One concern related to that: waiting NON_TIMEOUT isn=E2=80= =99t actually
>>>> required, it=E2=80=99s only RECOMMENDED, therefore this is= n=E2=80=99t actually a
>>>> guarantee. From =C2=A77.2:
>>>>
>>>>=C2=A0 As the sending of many payloads of a single body may= itself
>> cause
>>>>=C2=A0 congestion, it is RECOMMENDED that after transmissio= n of every
>>>>=C2=A0 MAX_PAYLOADS_SET of a single body, a delay is introd= uced of
>>>>=C2=A0 NON_TIMEOUT before sending the next MAX_PAYLOADS_SET= to manage
>>>>=C2=A0 potential congestion issues.
>>>>
>>>> I am curious why you made this a RECOMMENDED instead of a = MUST. In
>> a
>>>> situation like this it would be preferable for you to expl= ain to
>> the
>>>> implementor what situation they can ignore the RECOMMENDED= in and
>>>> what they should do instead, or of course to make it into = a MUST.
>>>
>>> Because a continue signal may be received from the peer and th= en
>> continue without waiting for the timeout to expire.
>>>
>>> This is to be linked with this text:
>>>
>>>=C2=A0 =C2=A0 =C2=A0A response using this Response Code SHOULD = NOT be generated
>> for
>>>=C2=A0 =C2=A0 =C2=A0every received Q-Block1 Option request (Sec= tion 7.2).=C2=A0 It
>> SHOULD
>>>=C2=A0 =C2=A0 =C2=A0only be generated when all the payload requ= ests are Non-
>>>=C2=A0 =C2=A0 =C2=A0confirmable and a MAX_PAYLOADS_SET has been= received by the
>>>=C2=A0 =C2=A0 =C2=A0 server.=C2=A0 More details about the motiv= ations for this
>> optimization
>>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>=C2=A0 =C2=A0 =C2=A0are discussed in Section 7.2.
>>>=C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>
>>> We could use **MUST unless a 'Continue' is received**,= e.g.,
>>>
>>> OLD:
>>>=C2=A0 As the sending of many payloads of a single body may its= elf cause
>>>=C2=A0 congestion, it is RECOMMENDED that after transmission of= every
>>>=C2=A0 MAX_PAYLOADS_SET of a single body, a delay is introduced= of
>>>=C2=A0 NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to = manage
>>>=C2=A0 potential congestion issues.
>>>
>>> NEW:
>>>=C2=A0 As the sending of many payloads of a single body may its= elf cause
>>>=C2=A0 congestion, after transmission of every MAX_PAYLOADS_SET= of a
>> single
>>>=C2=A0 body, a delay MUST be introduced of NON_TIMEOUT before s= ending
>> the
>>>=C2=A0 next MAX_PAYLOADS_SET to manage potential congestion iss= ues.
>>>=C2=A0 However, if a 'Continue' is received from the pe= er for the
>> current
>>>=C2=A0 MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET can sta= rt
>>>=C2=A0 transmission immediately.
>>>
>>> ... but I know that many would argue this is a SHOULD.
>>
>> I would be OK with either your proposed new text, or a SHOULD/MAY<= br> >> pair as in
>>
>> NEW:
>>=C2=A0 As the sending of many payloads of a single body may itself = cause
>>=C2=A0 congestion, after transmission of every MAX_PAYLOADS_SET of = a
>> single
>>=C2=A0 body, a delay SHOULD be introduced of NON_TIMEOUT before sen= ding
>> the
>>=C2=A0 next MAX_PAYLOADS_SET to manage potential congestion issues.=
>>=C2=A0 However, if a 'Continue' is received from the peer f= or the current
>>=C2=A0 MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET MAY start >>=C2=A0 transmission immediately.
>>
>> If you want to stick with MUST I think you can clear up the pain w= ith
>> something like
>>
>> NEW:
>>=C2=A0 As the sending of many payloads of a single body may itself = cause
>>=C2=A0 congestion, after transmission of every MAX_PAYLOADS_SET of = a
>> single
>>=C2=A0 body, a delay MUST be introduced of NON_TIMEOUT before sendi= ng the
>>=C2=A0 next MAX_PAYLOADS_SET unless a 'Continue' is receive= d from the peer
>>=C2=A0 for the current MAX_PAYLOADS_SET, in which case the next
>>=C2=A0 MAX_PAYLOADS_SET MAY start transmission immediately.
>>
>> (To my eye presenting the option in this way makes it clear when t= he
>> MUST does, and doesn=E2=80=99t, apply. This is my preferred form b= ut I don=E2=80=99t
>> insist.)
>>
>> [=E2=80=A6]
>>
>>>> 17. Section 1:
>>>>
>>>>=C2=A0 This document introduces the CoAP Q-Block1 and Q-Blo= ck2 Options
>>>> which
>>>>=C2=A0 allow block-wise transfer to work with series of Non= -confirmable
>>>>=C2=A0 messages, instead of lock-stepping using Confirmable= messages
>>>>=C2=A0 (Section 3).=C2=A0 In other words, this document pro= vides a missing
>>>> piece
>>>>=C2=A0 of [RFC7959], namely the support of block-wise trans= fer using
>> Non-
>>>>=C2=A0 confirmable where an entire body of data can be tran= smitted
>> without
>>>>=C2=A0 the requirement for an acknowledgement (but recovery= is
>> available
>>>>=C2=A0 should it be needed).
>>>>
>>>> As far as I can tell the spec does not really remove the >> requirement
>>>> for acknowledgement,
>>>
>>> These are not required. They were added as an optimization to = avoid
>> the non-timeout if the peer decides to use it.
>>
>> As I mentioned below (=E2=80=9Cawfully close parsing=E2=80=9D), I = think that although
>> you can find some justification for this reading, it=E2=80=99s deb= atable.
>> Transmission of the acknowledgement (at least the final
>> acknowledgement of the entire body, in the form of a Response Code= )
>> is required, is it not? Reception isn=E2=80=99t required though. W= ithout the
>> verb, I=E2=80=99m not sure whether I can say whether acknowledgeme= nt is, or
>> isn=E2=80=99t, required.
>>
>> I don=E2=80=99t insist that you change this, but I do think you co= uld improve
>> the clarity of the document, if you edited the above to read =E2= =80=9C=E2=80=A6
>> without the requirement that an acknowledgment be received from th= e
>> peer"
>>
>>>> it just amortizes the acknowledgements by only sending the= m every
>>>> MAX_PAYLOADS_SET. Response Code 2.31 is essentially an
>>>> acknowledgement, and it gets sent that frequently, right? = There=E2=80=99s
>>>> also (if I recall correctly) some flavor of acknowledgemen= t that
>> is
>>>> sent when the entire body has been transferred. So, I thin= k the
>> new
>>>> paragraph isn=E2=80=99t accurate.
>>>>
>>>> This observation also applies to this claimed benefit in = =C2=A73:
>>>>
>>>>=C2=A0 o=C2=A0 They support sending an entire body using NO= N messages
>> without
>>>>=C2=A0 =C2=A0 =C2=A0requiring an intermediate response from= the peer.
>>
>> And similarly, =E2=80=9C=E2=80=A6 without requiring that an interm= ediate response be
>> received from the peer.=E2=80=9D
>>
>> [=E2=80=A6]
>>
>>>> 18. Section 2:
>>>>
>>>>=C2=A0 MAX_PAYLOADS_SET is the set of blocks identified by = block
>> numbers
>>>>=C2=A0 that, when divided by MAX_PAYLOADS, they have the sa= me numeric
>>>>
>>>> Remove =E2=80=9Cthey=E2=80=9D
>>>
>>> Fixed. Thanks.
>>>
>>>>
>>>>=C2=A0 result.=C2=A0 For example, if MAX_PAYLOADS is set to= '10', a
>>>>=C2=A0 MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #1= 9, etc.
>>>>=C2=A0 Depending on the data size, the MAX_PAYLOADS_SET may= not
>> comprise
>>>> all
>>>>=C2=A0 the MAX_PAYLOADS blocks.
>>>>
>>>> I don=E2=80=99t understand the last sentence ("Depend= ing on the data size,
>>>> the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS=
>> blocks.=E2=80=9D)
>>>> Are you trying to say that if the body size isn=E2=80=99t = evenly divisible
>> by
>>>> MAX_PAYLOADS then the final MAX_PAYLOADS_SET will have few= er than
>>>> MAX_PAYLOADS blocks in it?
>>>
>>> We meant that the last set may include fewer blocks than
>> MAX_PAYLOADS. Changed to:
>>>
>>> " Depending on the overall data
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0^^^^^^^^
>>>=C2=A0 size, the final MAX_PAYLOADS_SET may not comprise all th= e
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^
>>>=C2=A0 MAX_PAYLOADS blocks. "
>>>
>>> Better?
>>
>> Improving. The word =E2=80=9Ccomprise=E2=80=9D is prone to misinte= rpretation in my
>> experience, I would suggest something like =E2=80=9C=E2=80=A6 ther= e could be fewer
>> than MAX_PAYLOADS blocks in the final MAX_PAYLOADS_SET.=E2=80=9D >>
>> Thanks,
>>
>> =E2=80=94John
>
> ______________________________________________________________________= ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 me= ssages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privilege= d information that may be protected by law;
> they should not be distributed, used or copied without authorisation.<= br> > 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 = been modified, changed or falsified.
> Thank you.
> 

______________________________________________________________________=
___________________________________________________

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 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 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.
--000000000000b7499d05c2db5e62-- From nobody Fri May 21 11:40: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 E0B4B3A1AE1 for ; Fri, 21 May 2021 11:40:47 -0700 (PDT) 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 Y3J-QVlhdlKC for ; Fri, 21 May 2021 11:40:43 -0700 (PDT) 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 3AAC83A1ADC for ; Fri, 21 May 2021 11:40:43 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lkA4d-00075A-IJ; Fri, 21 May 2021 19:40:39 +0100 From: To: "'Benjamin Kaduk'" , "'The IESG'" Cc: , , , References: <162162096651.11745.11475318344342658600@ietfa.amsl.com> In-Reply-To: <162162096651.11745.11475318344342658600@ietfa.amsl.com> Date: Fri, 21 May 2021 19:40:41 +0100 Message-ID: <093401d74e70$ccfd1240$66f736c0$@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: AQIlO8cBtQaQUeahZBG4mS/wV7bzG6pSaJVA Content-Language: en-gb Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-new-block-13: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2021 18:40:48 -0000 Hi Ben See inline. Regards Jon > -----Original Message----- > From: Benjamin Kaduk via Datatracker [mailto: noreply@ietf.org] > Sent: 21 May 2021 19:16 > To: The IESG > Cc: draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; = core@ietf.org; > marco.tiloca@ri.se; marco.tiloca@ri.se > Subject: Benjamin Kaduk's No Objection on = draft-ietf-core-new-block-13: > (with COMMENT) >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-core-new-block-13: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for addressing my discuss and comment points! >=20 > In reviewing the latest updates, I briefly tried to cross-reference > the formula in section 7.2: >=20 > NON_PROBING_WAIT =3D NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) > - 1) * > ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT >=20 > My initial attempt found that the corresponding formulae in RFC 7252 = used > PROCESSING_DELAY instead of NON_TIMEOUT for the last term, but I did = not > go back to double-check. It's possible I'm just misreading something. [Jon] RFC7253 4.8.2 o PROCESSING_DELAY is the time a node takes to turn around a Confirmable message into an acknowledgement. We assume the node will attempt to send an ACK before having the sender time out, so as a conservative assumption we set it equal to ACK_TIMEOUT. And hence NON_TIMEOUT. >=20 >=20 From nobody Fri May 21 12:16: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 AA7A43A1D60 for ; Fri, 21 May 2021 12:16:17 -0700 (PDT) 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, HTML_MESSAGE=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 4XztImwlQq3V for ; Fri, 21 May 2021 12:16:12 -0700 (PDT) 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 02FAE3A1D64 for ; Fri, 21 May 2021 12:16:11 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lkAcy-00076q-R4; Fri, 21 May 2021 20:16:09 +0100 From: To: "'Martin Duke'" , Cc: "'John Scudder'" , , , "'The IESG'" , , References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net> <23771_1621516652_60A6616C_23771_79_1_787AE7BB302AE849A7480A190F8B93303538BB63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4833_1621600918_60A7AA96_4833_485_3_787AE7BB302AE849A7480A190F8B93303538C272@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <36A5A92C-AD99-4554-8A09-4E76E60BA98A@juniper.net> <17420_1621618028_60A7ED6C_17420_17_28_787AE7BB302AE849A7480A190F8B93303538C6AB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Fri, 21 May 2021 20:16:10 +0100 Message-ID: <093901d74e75$c21e6130$465b2390$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_093A_01D74E7E.23E51320" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrgABkq/EcYVcSZwErAmCBxootVwEr1TnsAWWfO68BQp6XRAGT977eAqAdLFICQV7nLwCO/KFAAri1JFEBsChEpqpL2xNw Content-Language: en-gb Archived-At: Subject: Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (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, 21 May 2021 19:16:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_093A_01D74E7E.23E51320 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Martin, =20 NON_TIMEOUT has the same default value as ACK_TIMEOUT (Section 7.2 of = the draft). RFC7252 Section 4.2 =E2=80=9CMessages Transmitted = Reliably=E2=80=9D has =20 For a new Confirmable message, the initial timeout is set to a random duration (often not an integral number of seconds) between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR) =20 As mentioned previously in this thread =E2=80=9C RFC7252 introduces ACK_RANDOM_FACTOR jitter and separately jitter for = multicast responses (which is not relevant here). =20 The ACK_RANDOM_FACTOR is there for when re-transmitting a packet that = has not been acknowledged for some reason by its peer. NON_TIMEOUT is = for when the next MAX_PAYLOADS_SET can start transmission (not = re-transmission) assuming a 'Continue' has not arrived in the interim, = and so was not thought necessary to add in ACK_RANDOM_FACTOR style = jitter here. =20 For NON_RECEIVE_TIMEOUT, what is important is that NON_RECEIVE_TIMEOUT = is greater than NON_TIMEOUT (We say in the spec a minimum of one second) = so that a peer does not fire off a re-transmission request before the = local agent has a chance to start to transmit the next MAX_PAYLOADS_SET. = NON_RECEIVE_TIMEOUT is exponentially scaled for each retry to make sure = that stability is preserved. So, again, ACK_RANDOM_FACTOR jitter was not = thought to be necessary here. =E2=80=9C =20 Does that help? =20 Regards =20 Jon =20 From: Martin Duke [mailto: martin.h.duke@gmail.com]=20 Sent: 21 May 2021 19:39 To: mohamed.boucadair@orange.com Cc: John Scudder; draft-ietf-core-new-block@ietf.org; = core-chairs@ietf.org; The IESG; core@ietf.org; marco.tiloca@ri.se Subject: Re: John Scudder's Discuss on draft-ietf-core-new-block-11: = (with DISCUSS and COMMENT) =20 I agree that those two parameters have no need for jitter. =20 However, NON_TIMEOUT and NON_RECEIVE_TIMEOUT would appear to, but derive = from 7252 formulae that don't have the jitter included. =20 On Fri, May 21, 2021 at 10:27 AM wrote: Hi Martin,=20 =20 The comment about large numbers should be put in the context of the two = timeouts discussed with John: NON_PARTIAL_TIMEOUT and NON_PROBING_WAIT. = Consider the example of NON_PARTIAL_TIMEOUT, adding some jitter to it is = unlikely to have an effect as that timer is about controlling when a = received partial body will be discarded locally.=20 =20 NON_PROBING_WAIT is about limiting the effect of PROBING_RATE when a = peer does not reply. As a reminder, probing rate is defined as follows: =20 The 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. =20 Cheers, Med =20 De : Martin Duke [mailto:martin.h.duke@gmail.com]=20 Envoy=C3=A9 : vendredi 21 mai 2021 18:28 =C3=80 : John Scudder Cc : BOUCADAIR Mohamed TGI/OLN ; = draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; The IESG = ; core@ietf.org; marco.tiloca@ri.se Objet : Re: John Scudder's Discuss on draft-ietf-core-new-block-11: = (with DISCUSS and COMMENT) =20 So I'm not sure that "large numbers" are a sufficient reason to not = worry about jitter. =20 If two hosts simultaneously transmit on a quiet network, and cause = losses with each other. They both set the same retransmission timeout, = and in spite of no other traffic around cause the same collision, etc. =20 If an explicit configuration doesn't result in common round numbers, = it's an OK substitute, but I don't see any encouragement of that choice. =20 On Fri, May 21, 2021 at 9:17 AM John Scudder = wrote: Hi Med, Your current working copy looks good. I=E2=80=99ve cleared my discuss. =E2=80=94John > On May 21, 2021, at 8:41 AM, mohamed.boucadair@orange.com wrote: >=20 > [External Email. Be cautious of content] >=20 >=20 > Hi John, >=20 > As you can see in = https://urldefense.com/v3/__https://tinyurl.com/new-block-latest__;!!NEt6= yMaO-gk!RlDk7GMcbxlFsT2QGl8ma04s1CggmQZQHcIP9aw2R2EP1rWkfQDAbIpzOgyR6g$ = = , we went with the following changes to better address your latest = comment on the jitter: >=20 > (1) be explicit about the formula used for default values: >=20 > OLD: > NON_PROBING_WAIT is used to limit the potential wait needed when > using PROBING_RATE. By default, NON_PROBING_WAIT has the same value > as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). >=20 > NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. > By default, NON_PARTIAL_TIMEOUT has the same value as > EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). >=20 > NEW: > NON_PROBING_WAIT is used to limit the potential wait needed when > using PROBING_RATE. By default, NON_PROBING_WAIT is computed in the > same way as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but with > ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOUT and > NON_MAX_RETRANSMIT, respectively: >=20 > NON_PROBING_WAIT =3D NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - = 1) * > ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT >=20 > NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. > By default, NON_PARTIAL_TIMEOUT is computed in the same way as > EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). This default value > is calculated in the same way as NON_PROBING_WAIT. >=20 > (2) We don=E2=80=99t see a need to apply a jitter when a value is = explicitly configured (these are expected to be large numbers, we don't = care that much on the jitter). We added this text to be clear about the = intent, and which BTW reflects the current implementation: >=20 > NEW: > When explicit values are > configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these > values are used without applying any jitter. >=20 > We also adopted your proposed edits in the message below. >=20 > Thank you again for the careful review. This is highly appreciated. >=20 > Cheers, > John & Med >=20 >> -----Message d'origine----- >> De : John Scudder [mailto:jgs@juniper.net] >> Envoy=C3=A9 : vendredi 21 mai 2021 00:03 >> =C3=80 : BOUCADAIR Mohamed TGI/OLN >> Cc : The IESG ; draft-ietf-core-new-block@ietf.org; >> core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se >> Objet : Re: John Scudder's Discuss on draft-ietf-core-new-block-11: >> (with DISCUSS and COMMENT) >>=20 >> Hi Mohamed, >>=20 >> I think we are converging. My comments in line. I=E2=80=99ve snipped = agreed >> points for brevity, indicated by [=E2=80=A6]. >>=20 >>> On May 20, 2021, at 9:17 AM, mohamed.boucadair@orange.com wrote: >>=20 >> [=E2=80=A6] >>=20 >>>>>> 11. General >>>>>>=20 >>>>>> By the way, none of the timers specify jitter (and indeed, if >> read >>>>>> literally, jitter would be forbidden). Is this intentional? >>>>>=20 >>>>> No +/- tolerances have been defined. When a timer expires, then >> the >>>> next action takes place. >>>>=20 >>>> I notice that RFC 7252 jitters its timers, for example: >>>>=20 >>>> counter. For a new Confirmable message, the initial timeout is >> set >>>> to a random duration (often not an integral number of seconds) >>>> between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR) (see >>>> Section 4.8) >>>> =E2=80=A6 >>>> ACK_RANDOM_FACTOR MUST NOT be decreased below 1.0, and it SHOULD >>>> have >>>> a value that is sufficiently different from 1.0 to provide some >>>> protection from synchronization effects. >>>>=20 >>>> MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT are similarly jittered. A >>>> number of your introduced parameters >>>>=20 >>>> This document introduces new parameters MAX_PAYLOADS, >> NON_TIMEOUT, >>>> NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and >>>> NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3). >>>>=20 >>>> appear at least superficially similar to the timers the authors of >>>> RFC 7252 deemed important to jitter to prevent synchronization >>>> effects. Did you specifically consider jittering them, and decide >>>> that jitter was unnecessary? If so, can you explain what is >> different >>>> about your specification, compared to the base spec, that >> eliminates >>>> the concern? >>>=20 >>> RFC7252 introduces ACK_RANDOM_FACTOR jitter and separately jitter >> for multicast responses (which is not relevant here). >>>=20 >>> The ACK_RANDOM_FACTOR is there for when re-transmitting a packet >> that has not been acknowledged for some reason by its peer. >> NON_TIMEOUT is for when the next MAX_PAYLOADS_SET can start >> transmission (not re-transmission) assuming a 'Continue' has not >> arrived in the interim, and so was not thought necessary to add in >> ACK_RANDOM_FACTOR style jitter here. >>>=20 >>> For NON_RECEIVE_TIMEOUT, what is important is that >> NON_RECEIVE_TIMEOUT is greater than NON_TIMEOUT (We say in the spec a >> minimum of one second) so that a peer does not fire off a re- >> transmission request before the local agent has a chance to start to >> transmit the next MAX_PAYLOADS_SET. NON_RECEIVE_TIMEOUT is >> exponentially scaled for each retry to make sure that stability is >> preserved. So, again, ACK_RANDOM_FACTOR jitter was not thought to be >> necessary here. >>>=20 >>> NON_MAX_RETRANSMIT is a fixed count. >>>=20 >>> NON_PROBING_WAIT is used to put a limit on the potential delay that >> could incur when obeying PROBING_WAIT when there is no peer response. >> If the implementation goes with the default EXCHANGE_LIFETIME >> computation, then NON_PROBING_WAIT includes ACK_RANDOM_FACTOR in the >> math. >>>=20 >>> NON_PARTIAL_TIMEOUT if computed using the default EXCHANGE_LIFETIME >> includes ACK_RANDOM_FACTOR. >>=20 >> Thanks for taking the time to explain. You don=E2=80=99t comment = regarding >> whether NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT should be jittered >> or not, you just explain that if they use the default they get jitter >> =E2=80=9Cfor free=E2=80=9D. The missing detail is that if they = don=E2=80=99t use the default >> they don=E2=80=99t get jittered, so I think some consideration is = still >> called for regarding whether having them not be jittered is OK. >>=20 >> [=E2=80=A6] >>=20 >>>>>> 15. Section 10.2.3 >>=20 >> [=E2=80=A6] >>=20 >>>> One concern related to that: waiting NON_TIMEOUT isn=E2=80=99t = actually >>>> required, it=E2=80=99s only RECOMMENDED, therefore this = isn=E2=80=99t actually a >>>> guarantee. From =C2=A77.2: >>>>=20 >>>> As the sending of many payloads of a single body may itself >> cause >>>> congestion, it is RECOMMENDED that after transmission of every >>>> MAX_PAYLOADS_SET of a single body, a delay is introduced of >>>> NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage >>>> potential congestion issues. >>>>=20 >>>> I am curious why you made this a RECOMMENDED instead of a MUST. In >> a >>>> situation like this it would be preferable for you to explain to >> the >>>> implementor what situation they can ignore the RECOMMENDED in and >>>> what they should do instead, or of course to make it into a MUST. >>>=20 >>> Because a continue signal may be received from the peer and then >> continue without waiting for the timeout to expire. >>>=20 >>> This is to be linked with this text: >>>=20 >>> A response using this Response Code SHOULD NOT be generated >> for >>> every received Q-Block1 Option request (Section 7.2). It >> SHOULD >>> only be generated when all the payload requests are Non- >>> confirmable and a MAX_PAYLOADS_SET has been received by the >>> server. More details about the motivations for this >> optimization >>>=20 >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> are discussed in Section 7.2. >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>=20 >>> We could use **MUST unless a 'Continue' is received**, e.g., >>>=20 >>> OLD: >>> As the sending of many payloads of a single body may itself cause >>> congestion, it is RECOMMENDED that after transmission of every >>> MAX_PAYLOADS_SET of a single body, a delay is introduced of >>> NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage >>> potential congestion issues. >>>=20 >>> NEW: >>> As the sending of many payloads of a single body may itself cause >>> congestion, after transmission of every MAX_PAYLOADS_SET of a >> single >>> body, a delay MUST be introduced of NON_TIMEOUT before sending >> the >>> next MAX_PAYLOADS_SET to manage potential congestion issues. >>> However, if a 'Continue' is received from the peer for the >> current >>> MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET can start >>> transmission immediately. >>>=20 >>> ... but I know that many would argue this is a SHOULD. >>=20 >> I would be OK with either your proposed new text, or a SHOULD/MAY >> pair as in >>=20 >> NEW: >> As the sending of many payloads of a single body may itself cause >> congestion, after transmission of every MAX_PAYLOADS_SET of a >> single >> body, a delay SHOULD be introduced of NON_TIMEOUT before sending >> the >> next MAX_PAYLOADS_SET to manage potential congestion issues. >> However, if a 'Continue' is received from the peer for the current >> MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET MAY start >> transmission immediately. >>=20 >> If you want to stick with MUST I think you can clear up the pain with >> something like >>=20 >> NEW: >> As the sending of many payloads of a single body may itself cause >> congestion, after transmission of every MAX_PAYLOADS_SET of a >> single >> body, a delay MUST be introduced of NON_TIMEOUT before sending the >> next MAX_PAYLOADS_SET unless a 'Continue' is received from the peer >> for the current MAX_PAYLOADS_SET, in which case the next >> MAX_PAYLOADS_SET MAY start transmission immediately. >>=20 >> (To my eye presenting the option in this way makes it clear when the >> MUST does, and doesn=E2=80=99t, apply. This is my preferred form but = I don=E2=80=99t >> insist.) >>=20 >> [=E2=80=A6] >>=20 >>>> 17. Section 1: >>>>=20 >>>> This document introduces the CoAP Q-Block1 and Q-Block2 Options >>>> which >>>> allow block-wise transfer to work with series of Non-confirmable >>>> messages, instead of lock-stepping using Confirmable messages >>>> (Section 3). In other words, this document provides a missing >>>> piece >>>> of [RFC7959], namely the support of block-wise transfer using >> Non- >>>> confirmable where an entire body of data can be transmitted >> without >>>> the requirement for an acknowledgement (but recovery is >> available >>>> should it be needed). >>>>=20 >>>> As far as I can tell the spec does not really remove the >> requirement >>>> for acknowledgement, >>>=20 >>> These are not required. They were added as an optimization to avoid >> the non-timeout if the peer decides to use it. >>=20 >> As I mentioned below (=E2=80=9Cawfully close parsing=E2=80=9D), I = think that although >> you can find some justification for this reading, it=E2=80=99s = debatable. >> Transmission of the acknowledgement (at least the final >> acknowledgement of the entire body, in the form of a Response Code) >> is required, is it not? Reception isn=E2=80=99t required though. = Without the >> verb, I=E2=80=99m not sure whether I can say whether acknowledgement = is, or >> isn=E2=80=99t, required. >>=20 >> I don=E2=80=99t insist that you change this, but I do think you could = improve >> the clarity of the document, if you edited the above to read = =E2=80=9C=E2=80=A6 >> without the requirement that an acknowledgment be received from the >> peer" >>=20 >>>> it just amortizes the acknowledgements by only sending them every >>>> MAX_PAYLOADS_SET. Response Code 2.31 is essentially an >>>> acknowledgement, and it gets sent that frequently, right? = There=E2=80=99s >>>> also (if I recall correctly) some flavor of acknowledgement that >> is >>>> sent when the entire body has been transferred. So, I think the >> new >>>> paragraph isn=E2=80=99t accurate. >>>>=20 >>>> This observation also applies to this claimed benefit in =C2=A73: >>>>=20 >>>> o They support sending an entire body using NON messages >> without >>>> requiring an intermediate response from the peer. >>=20 >> And similarly, =E2=80=9C=E2=80=A6 without requiring that an = intermediate response be >> received from the peer.=E2=80=9D >>=20 >> [=E2=80=A6] >>=20 >>>> 18. Section 2: >>>>=20 >>>> MAX_PAYLOADS_SET is the set of blocks identified by block >> numbers >>>> that, when divided by MAX_PAYLOADS, they have the same numeric >>>>=20 >>>> Remove =E2=80=9Cthey=E2=80=9D >>>=20 >>> Fixed. Thanks. >>>=20 >>>>=20 >>>> result. For example, if MAX_PAYLOADS is set to '10', a >>>> MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc. >>>> Depending on the data size, the MAX_PAYLOADS_SET may not >> comprise >>>> all >>>> the MAX_PAYLOADS blocks. >>>>=20 >>>> I don=E2=80=99t understand the last sentence ("Depending on the = data size, >>>> the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS >> blocks.=E2=80=9D) >>>> Are you trying to say that if the body size isn=E2=80=99t evenly = divisible >> by >>>> MAX_PAYLOADS then the final MAX_PAYLOADS_SET will have fewer than >>>> MAX_PAYLOADS blocks in it? >>>=20 >>> We meant that the last set may include fewer blocks than >> MAX_PAYLOADS. Changed to: >>>=20 >>> " Depending on the overall data >>> ^^^^^^^^ >>> size, the final MAX_PAYLOADS_SET may not comprise all the >>> ^^^^^ >>> MAX_PAYLOADS blocks. " >>>=20 >>> Better? >>=20 >> Improving. The word =E2=80=9Ccomprise=E2=80=9D is prone to = misinterpretation in my >> experience, I would suggest something like =E2=80=9C=E2=80=A6 there = could be fewer >> than MAX_PAYLOADS blocks in the final MAX_PAYLOADS_SET.=E2=80=9D >>=20 >> Thanks, >>=20 >> =E2=80=94John >=20 > = _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles 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 electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > 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 = been modified, changed or falsified. > Thank you. >=20 _________________________________________________________________________= ________________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations = confidentielles 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 = electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 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 = been modified, changed or falsified. Thank you. ------=_NextPart_000_093A_01D74E7E.23E51320 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Martin,

 

NON_TIMEOUT has the same default value as ACK_TIMEOUT (Section 7.2 of = the draft).=C2=A0 RFC7252 Section 4.2 =E2=80=9CMessages Transmitted = Reliably=E2=80=9D has

 

=C2=A0=C2=A0 For a new Confirmable message, the initial timeout is = set

=C2=A0=C2=A0 to a random duration (often not an integral number of = seconds)

=C2=A0=C2=A0 between ACK_TIMEOUT and (ACK_TIMEOUT * = ACK_RANDOM_FACTOR)

 

As mentioned previously in this thread

=E2=80=9C

RFC7252 = introduces ACK_RANDOM_FACTOR jitter and separately jitter for multicast = responses (which is not relevant here).

 

The = ACK_RANDOM_FACTOR is there for when re-transmitting a packet that has = not been acknowledged for some reason by its peer. NON_TIMEOUT is for = when the next MAX_PAYLOADS_SET can start transmission (not = re-transmission) assuming a 'Continue' has not arrived in the interim, = and so was not thought necessary to add in ACK_RANDOM_FACTOR style = jitter here.

 

For = NON_RECEIVE_TIMEOUT, what is important is that NON_RECEIVE_TIMEOUT is = greater than NON_TIMEOUT (We say in the spec a minimum of one second) so = that a peer does not fire off a re-transmission request before the local = agent has a chance to start to transmit the next MAX_PAYLOADS_SET.=C2=A0 = NON_RECEIVE_TIMEOUT is exponentially scaled for each retry to make sure = that stability is preserved. So, again, ACK_RANDOM_FACTOR jitter was not = thought to be necessary here.

=E2=80=9C

 

Does that help?

 

Regards

 

Jon

 

From:= Martin = Duke [mailto: martin.h.duke@gmail.com]
Sent: 21 May 2021 = 19:39
To: mohamed.boucadair@orange.com
Cc: John = Scudder; draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; The = IESG; core@ietf.org; marco.tiloca@ri.se
Subject: Re: John = Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and = COMMENT)

 

I = agree that those two parameters have no need for = jitter.

 

However, NON_TIMEOUT and NON_RECEIVE_TIMEOUT would = appear to, but derive from 7252 formulae that don't have the jitter = included.

 

On = Fri, May 21, 2021 at 10:27 AM <mohamed.boucadair@orange.com= > wrote:

Hi Martin,

 

The comment about large numbers should be put in the = context of the two timeouts discussed with John: NON_PARTIAL_TIMEOUT and = NON_PROBING_WAIT. Consider the example of NON_PARTIAL_TIMEOUT, adding = some jitter to it is unlikely to have an effect as that timer is about = controlling when a received partial body will be discarded locally. =

 

NON_PROBING_WAIT is about limiting the effect of = PROBING_RATE when a peer does not reply. As a reminder, probing rate is = defined as follows:

 

   The 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.

 

Cheers,

Med

 

De : Martin = Duke [mailto:martin.h.duke@gmail.com] =
Envoy=C3=A9 : vendredi 21 mai 2021 = 18:28
=C3=80 : John Scudder <jgs=3D40juniper.net@dmarc.ietf.org>
Cc : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>; draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; The IESG <iesg@ietf.org>; = core@ietf.org; marco.tiloca@ri.se
Objet : Re: John = Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and = COMMENT)

 

So I'm not sure that "large numbers" are a = sufficient reason to not worry about = jitter.

 

If two hosts simultaneously transmit on a quiet network, = and cause losses with each other. They both set the same retransmission = timeout, and in spite of no other traffic around cause the same = collision, etc.

 

If an explicit configuration doesn't result in common round = numbers, it's an OK substitute, but I don't see any encouragement of = that choice.

 

On Fri, May 21, 2021 at 9:17 AM John Scudder <jgs=3D40juniper.net@dmarc.ietf.org> = wrote:

Hi Med,

Your current working copy looks good. = I=E2=80=99ve cleared my discuss.

=E2=80=94John

> On May = 21, 2021, at 8:41 AM, mohamed.boucadair@orange.com wrote:
> =
> [External Email. Be cautious of content]
>
> =
> Hi John,
>
> As you can see in https://urldefense.com/v3/__https://tinyurl.com/new-blo= ck-latest__;!!NEt6yMaO-gk!RlDk7GMcbxlFsT2QGl8ma04s1CggmQZQHcIP9aw2R2EP1rW= kfQDAbIpzOgyR6g$ , we went with the following changes to better = address your latest comment on the jitter:
>
> (1) be = explicit about the formula used for default values:
>
> = OLD:
>   NON_PROBING_WAIT is used to limit the potential = wait needed when
>   using PROBING_RATE.  By = default, NON_PROBING_WAIT has the same value
>   as = EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
>
>  =  NON_PARTIAL_TIMEOUT is used for expiring partially received = bodies.
>   By default, NON_PARTIAL_TIMEOUT has the same = value as
>   EXCHANGE_LIFETIME (Section 4.8.2 of = [RFC7252]).
>
> NEW:
>   NON_PROBING_WAIT = is used to limit the potential wait needed when
>  =  using PROBING_RATE.  By default, NON_PROBING_WAIT is computed = in the
>   same way as EXCHANGE_LIFETIME (Section 4.8.2 = of [RFC7252]) but with
>   ACK_TIMEOUT and = MAX_RETRANSMIT substituted with NON_TIMEOUT and
>  =  NON_MAX_RETRANSMIT, respectively:
>
>    =   NON_PROBING_WAIT =3D NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - = 1) *
>      ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + = NON_TIMEOUT
>
>   NON_PARTIAL_TIMEOUT is used for = expiring partially received bodies.
>   By default, = NON_PARTIAL_TIMEOUT is computed in the same way as
>  =  EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).  This default = value
>   is calculated in the same way as = NON_PROBING_WAIT.
>
> (2) We don=E2=80=99t see a need to = apply a jitter when a value is explicitly configured (these are expected = to be large numbers, we don't care that much on the jitter). We added = this text to be clear about the intent, and which BTW reflects the = current implementation:
>
> NEW:
>    =   When explicit values are
>      configured = for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these
>    =   values are used without applying any jitter.
>
> We = also adopted your proposed edits in the message below.
>
> = Thank you again for the careful review. This is highly = appreciated.
>
> Cheers,
> John & Med
> =
>> -----Message d'origine-----
>> De : John Scudder = [mailto:jgs@juniper.net]
>> Envoy=C3=A9 : = vendredi 21 mai 2021 00:03
>> =C3=80 : BOUCADAIR Mohamed = TGI/OLN <mohamed.boucadair@orange.com>
>> Cc : = The IESG <iesg@ietf.org>; draft-ietf-core-new-block@ietf.org;
>> core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se
>> Objet : Re: John = Scudder's Discuss on draft-ietf-core-new-block-11:
>> (with = DISCUSS and COMMENT)
>>
>> Hi Mohamed,
>> =
>> I think we are converging. My comments in line. = I=E2=80=99ve snipped agreed
>> points for brevity, indicated by = [=E2=80=A6].
>>
>>> On May 20, 2021, at 9:17 AM, = mohamed.boucadair@orange.com wrote:
>> =
>> [=E2=80=A6]
>>
>>>>>> 11. = General
>>>>>>
>>>>>> By the = way, none of the timers specify jitter (and indeed, if
>> = read
>>>>>> literally, jitter would be forbidden). = Is this intentional?
>>>>>
>>>>> No = +/- tolerances have been defined. When a timer expires, then
>> = the
>>>> next action takes place.
>>>> =
>>>> I notice that RFC 7252 jitters its timers, for = example:
>>>>
>>>>  counter.  = For a new Confirmable message, the initial timeout is
>> = set
>>>>  to a random duration (often not an = integral number of seconds)
>>>>  between = ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR) = (see
>>>>  Section 4.8)
>>>> = =E2=80=A6
>>>>  ACK_RANDOM_FACTOR MUST NOT be = decreased below 1.0, and it SHOULD
>>>> = have
>>>>  a value that is sufficiently different = from 1.0 to provide some
>>>>  protection from = synchronization effects.
>>>>
>>>> = MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT are similarly jittered. = A
>>>> number of your introduced = parameters
>>>>
>>>>  This document = introduces new parameters MAX_PAYLOADS,
>> = NON_TIMEOUT,
>>>>  NON_RECEIVE_TIMEOUT, = NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and
>>>>  = NON_PARTIAL_TIMEOUT primarily for use with NON (Table = 3).
>>>>
>>>> appear at least = superficially similar to the timers the authors of
>>>> = RFC 7252 deemed important to jitter to prevent = synchronization
>>>> effects. Did you specifically = consider jittering them, and decide
>>>> that jitter was = unnecessary? If so, can you explain what is
>> = different
>>>> about your specification, compared to the = base spec, that
>> eliminates
>>>> the = concern?
>>>
>>> RFC7252 introduces = ACK_RANDOM_FACTOR jitter and separately jitter
>> for multicast = responses (which is not relevant here).
>>>
>>> = The ACK_RANDOM_FACTOR is there for when re-transmitting a = packet
>> that has not been acknowledged for some reason by its = peer.
>> NON_TIMEOUT is for when the next MAX_PAYLOADS_SET can = start
>> transmission (not re-transmission) assuming a = 'Continue' has not
>> arrived in the interim, and so was not = thought necessary to add in
>> ACK_RANDOM_FACTOR style jitter = here.
>>>
>>> For NON_RECEIVE_TIMEOUT, what is = important is that
>> NON_RECEIVE_TIMEOUT is greater than = NON_TIMEOUT (We say in the spec a
>> minimum of one second) so = that a peer does not fire off a re-
>> transmission request = before the local agent has a chance to start to
>> transmit the = next MAX_PAYLOADS_SET.  NON_RECEIVE_TIMEOUT is
>> = exponentially scaled for each retry to make sure that stability = is
>> preserved. So, again, ACK_RANDOM_FACTOR jitter was not = thought to be
>> necessary here.
>>> =
>>> NON_MAX_RETRANSMIT is a fixed count.
>>> =
>>> NON_PROBING_WAIT is used to put a limit on the = potential delay that
>> could incur when obeying PROBING_WAIT = when there is no peer response.
>> If the implementation goes = with the default EXCHANGE_LIFETIME
>> computation, then = NON_PROBING_WAIT includes ACK_RANDOM_FACTOR in the
>> = math.
>>>
>>> NON_PARTIAL_TIMEOUT if computed = using the default EXCHANGE_LIFETIME
>> includes = ACK_RANDOM_FACTOR.
>>
>> Thanks for taking the time = to explain. You don=E2=80=99t comment regarding
>> whether = NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT should be jittered
>> = or not, you just explain that if they use the default they get = jitter
>> =E2=80=9Cfor free=E2=80=9D. The missing detail is = that if they don=E2=80=99t use the default
>> they = don=E2=80=99t get jittered, so I think some consideration is = still
>> called for regarding whether having them not be = jittered is OK.
>>
>> [=E2=80=A6]
>> =
>>>>>> 15. Section 10.2.3
>>
>> = [=E2=80=A6]
>>
>>>> One concern related to = that: waiting NON_TIMEOUT isn=E2=80=99t actually
>>>> = required, it=E2=80=99s only RECOMMENDED, therefore this isn=E2=80=99t = actually a
>>>> guarantee. From = =C2=A77.2:
>>>>
>>>>  As the sending = of many payloads of a single body may itself
>> = cause
>>>>  congestion, it is RECOMMENDED that after = transmission of every
>>>>  MAX_PAYLOADS_SET of a = single body, a delay is introduced of
>>>>  = NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to = manage
>>>>  potential congestion = issues.
>>>>
>>>> I am curious why you = made this a RECOMMENDED instead of a MUST. In
>> = a
>>>> situation like this it would be preferable for you = to explain to
>> the
>>>> implementor what = situation they can ignore the RECOMMENDED in and
>>>> = what they should do instead, or of course to make it into a = MUST.
>>>
>>> Because a continue signal may be = received from the peer and then
>> continue without waiting for = the timeout to expire.
>>>
>>> This is to be = linked with this text:
>>>
>>>    =  A response using this Response Code SHOULD NOT be = generated
>> for
>>>     every = received Q-Block1 Option request (Section 7.2).  It
>> = SHOULD
>>>     only be generated when all the = payload requests are Non-
>>>     confirmable = and a MAX_PAYLOADS_SET has been received by the
>>>  =     server.  More details about the motivations for = this
>> optimization
>>>
>> = ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>&= nbsp;    are discussed in Section 7.2.
>>>  =    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> =
>>> We could use **MUST unless a 'Continue' is received**, = e.g.,
>>>
>>> OLD:
>>>  As the = sending of many payloads of a single body may itself = cause
>>>  congestion, it is RECOMMENDED that after = transmission of every
>>>  MAX_PAYLOADS_SET of a single = body, a delay is introduced of
>>>  NON_TIMEOUT before = sending the next MAX_PAYLOADS_SET to manage
>>>  = potential congestion issues.
>>>
>>> = NEW:
>>>  As the sending of many payloads of a single = body may itself cause
>>>  congestion, after = transmission of every MAX_PAYLOADS_SET of a
>> = single
>>>  body, a delay MUST be introduced of = NON_TIMEOUT before sending
>> the
>>>  next = MAX_PAYLOADS_SET to manage potential congestion = issues.
>>>  However, if a 'Continue' is received from = the peer for the
>> current
>>>  = MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET can = start
>>>  transmission immediately.
>>> =
>>> ... but I know that many would argue this is a = SHOULD.
>>
>> I would be OK with either your proposed = new text, or a SHOULD/MAY
>> pair as in
>> =
>> NEW:
>>  As the sending of many payloads of a = single body may itself cause
>>  congestion, after = transmission of every MAX_PAYLOADS_SET of a
>> = single
>>  body, a delay SHOULD be introduced of = NON_TIMEOUT before sending
>> the
>>  next = MAX_PAYLOADS_SET to manage potential congestion = issues.
>>  However, if a 'Continue' is received from the = peer for the current
>>  MAX_PAYLOADS_SET, then the next = MAX_PAYLOADS_SET MAY start
>>  transmission = immediately.
>>
>> If you want to stick with MUST I = think you can clear up the pain with
>> something = like
>>
>> NEW:
>>  As the sending of = many payloads of a single body may itself cause
>>  = congestion, after transmission of every MAX_PAYLOADS_SET of = a
>> single
>>  body, a delay MUST be introduced = of NON_TIMEOUT before sending the
>>  next = MAX_PAYLOADS_SET unless a 'Continue' is received from the = peer
>>  for the current MAX_PAYLOADS_SET, in which case = the next
>>  MAX_PAYLOADS_SET MAY start transmission = immediately.
>>
>> (To my eye presenting the option = in this way makes it clear when the
>> MUST does, and = doesn=E2=80=99t, apply. This is my preferred form but I = don=E2=80=99t
>> insist.)
>>
>> = [=E2=80=A6]
>>
>>>> 17. Section = 1:
>>>>
>>>>  This document = introduces the CoAP Q-Block1 and Q-Block2 Options
>>>> = which
>>>>  allow block-wise transfer to work with = series of Non-confirmable
>>>>  messages, instead of = lock-stepping using Confirmable messages
>>>>  = (Section 3).  In other words, this document provides a = missing
>>>> piece
>>>>  of = [RFC7959], namely the support of block-wise transfer using
>> = Non-
>>>>  confirmable where an entire body of data = can be transmitted
>> without
>>>>  the = requirement for an acknowledgement (but recovery is
>> = available
>>>>  should it be = needed).
>>>>
>>>> As far as I can tell = the spec does not really remove the
>> = requirement
>>>> for acknowledgement,
>>> =
>>> These are not required. They were added as an = optimization to avoid
>> the non-timeout if the peer decides to = use it.
>>
>> As I mentioned below (=E2=80=9Cawfully = close parsing=E2=80=9D), I think that although
>> you can find = some justification for this reading, it=E2=80=99s debatable.
>> = Transmission of the acknowledgement (at least the final
>> = acknowledgement of the entire body, in the form of a Response = Code)
>> is required, is it not? Reception isn=E2=80=99t = required though. Without the
>> verb, I=E2=80=99m not sure = whether I can say whether acknowledgement is, or
>> = isn=E2=80=99t, required.
>>
>> I don=E2=80=99t insist = that you change this, but I do think you could improve
>> the = clarity of the document, if you edited the above to read = =E2=80=9C=E2=80=A6
>> without the requirement that an = acknowledgment be received from the
>> peer"
>> =
>>>> it just amortizes the acknowledgements by only = sending them every
>>>> MAX_PAYLOADS_SET. Response Code = 2.31 is essentially an
>>>> acknowledgement, and it gets = sent that frequently, right? There=E2=80=99s
>>>> also = (if I recall correctly) some flavor of acknowledgement that
>> = is
>>>> sent when the entire body has been transferred. = So, I think the
>> new
>>>> paragraph = isn=E2=80=99t accurate.
>>>>
>>>> This = observation also applies to this claimed benefit in = =C2=A73:
>>>>
>>>>  o  They = support sending an entire body using NON messages
>> = without
>>>>     requiring an intermediate = response from the peer.
>>
>> And similarly, = =E2=80=9C=E2=80=A6 without requiring that an intermediate response = be
>> received from the peer.=E2=80=9D
>>
>> = [=E2=80=A6]
>>
>>>> 18. Section = 2:
>>>>
>>>>  MAX_PAYLOADS_SET is = the set of blocks identified by block
>> = numbers
>>>>  that, when divided by MAX_PAYLOADS, = they have the same numeric
>>>>
>>>> = Remove =E2=80=9Cthey=E2=80=9D
>>>
>>> Fixed. = Thanks.
>>>
>>>>
>>>>  = result.  For example, if MAX_PAYLOADS is set to '10', = a
>>>>  MAX_PAYLOADS_SET could be blocks #0 to #9, = #10 to #19, etc.
>>>>  Depending on the data size, = the MAX_PAYLOADS_SET may not
>> comprise
>>>> = all
>>>>  the MAX_PAYLOADS = blocks.
>>>>
>>>> I don=E2=80=99t = understand the last sentence ("Depending on the data = size,
>>>> the MAX_PAYLOADS_SET may not comprise all the = MAX_PAYLOADS
>> blocks.=E2=80=9D)
>>>> Are you = trying to say that if the body size isn=E2=80=99t evenly = divisible
>> by
>>>> MAX_PAYLOADS then the final = MAX_PAYLOADS_SET will have fewer than
>>>> MAX_PAYLOADS = blocks in it?
>>>
>>> We meant that the last = set may include fewer blocks than
>> MAX_PAYLOADS. Changed = to:
>>>
>>> " Depending on the overall = data
>>>              =      ^^^^^^^^
>>>  size, the final = MAX_PAYLOADS_SET may not comprise all the
>>>    =         ^^^^^
>>>  MAX_PAYLOADS = blocks. "
>>>
>>> Better?
>> =
>> Improving. The word =E2=80=9Ccomprise=E2=80=9D is prone to = misinterpretation in my
>> experience, I would suggest = something like =E2=80=9C=E2=80=A6 there could be fewer
>> than = MAX_PAYLOADS blocks in the final MAX_PAYLOADS_SET.=E2=80=9D
>> =
>> Thanks,
>>
>> =E2=80=94John
> =
> = _________________________________________________________________________= ________________________________________________
>
> Ce = message et ses pieces jointes peuvent contenir des informations = confidentielles 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 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 been modified, changed or = falsified.
> Thank you.
> = 

____________________________________________________________=
_____________________________________________________________<=
/span>
 
Ce =
message et ses pieces jointes peuvent contenir des informations =
confidentielles 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 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 been modified, changed or =
falsified.
Thank =
you.
<= /html> ------=_NextPart_000_093A_01D74E7E.23E51320-- From nobody Fri May 21 15:03: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 BC1903A2253; Fri, 21 May 2021 15:03:40 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 VbawVVegRDl8; Fri, 21 May 2021 15:03:35 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 076F93A2250; Fri, 21 May 2021 15:03:34 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id a8so13502263ioa.12; Fri, 21 May 2021 15:03:34 -0700 (PDT) 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=qqb7N3AzrAARJmBpfQzmBhqDUSohM0K8FJC8GW2nFoM=; b=lkpwDbkQkUb6zVZ0pD5zTrBijA01jIoM5vBkr5DBOgXIKRHEKyVrEx+mvzbrIfijs1 dAYLP8lg7EPHgQOSk1wWltDWvFvDG0D9bbCDw4xDSlCAbfOE4p5jJ+CQ/XiAtRNhHw9H jI8N6NUoKdallWqll1S5MObfAkl0STdgoNaDA1dHHKqt1dUyzBLOON5kaZYDg+1I++ns /RvIJTGMmpIMZ0VsKMdOa17yPyQoLdkLBAFNjfY9310cfGAkwBRuHNxrbv2ZyzEZ6G/4 uYhY+VGBcpaNNopQTK8JK5PTeZQnU/gCoAQ789Rqcok9aUChJSg/PGbfqqwEfj2mWn54 SREw== 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=qqb7N3AzrAARJmBpfQzmBhqDUSohM0K8FJC8GW2nFoM=; b=QP/rxtwS00udrxRdlLRHJdY2CKuyHF2O4s4uVuOsntOQoEScPQvbwHqt/Xhxn/aAwZ 9SrIP8ogFhkJsurHSvNkpn7XHz5qqIbjE/DMwIldrlfjADRXnporRYmCqUubhuRvzYyW 0uggzpUfPmh+GeoFuTfwFoRmK7tsY5VTYj2t2PLLYKUH+67AUFZCXiDRMqbfXPmxU1c1 Y1M+G/f47fIEzdnERc8h0tIkbHfxz4yaGSO1OgMH81VK08u9ORmfoimC/YJtxeWBB5px 3xTUuKnvjjte7cBmgDOIyFkvK72zXTuy8j3Ylo0qxrk1AM7DNFk4O0UwmTTgoWaF7FbM ioGg== X-Gm-Message-State: AOAM532lwSswbFRZ+leZZifYhwS5G/YCoqT7weI6b5TgsQ4GXCGmCX5g XJEDWxYRjhcvDpKKMFO5um3twROfq8DCxdaRs2I= X-Google-Smtp-Source: ABdhPJzMXTumcbdspn2zBntCvH2ThZFvTYTYwCrNqtaLzVk+sxkDXSBGx2Ab2b8dRarEuIVUNPnIwpK48Q01IOnD5UU= X-Received: by 2002:a02:354c:: with SMTP id y12mr7758063jae.144.1621634613597; Fri, 21 May 2021 15:03:33 -0700 (PDT) MIME-Version: 1.0 References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net> <23771_1621516652_60A6616C_23771_79_1_787AE7BB302AE849A7480A190F8B93303538BB63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4833_1621600918_60A7AA96_4833_485_3_787AE7BB302AE849A7480A190F8B93303538C272@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <36A5A92C-AD99-4554-8A09-4E76E60BA98A@juniper.net> <17420_1621618028_60A7ED6C_17420_17_28_787AE7BB302AE849A7480A190F8B93303538C6AB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <093901d74e75$c21e6130$465b2390$@jpshallow.com> In-Reply-To: <093901d74e75$c21e6130$465b2390$@jpshallow.com> From: Martin Duke Date: Fri, 21 May 2021 15:03:22 -0700 Message-ID: To: supjps-ietf@jpshallow.com Cc: mohamed.boucadair@orange.com, core-chairs@ietf.org, John Scudder , draft-ietf-core-new-block@ietf.org, The IESG , core@ietf.org, marco.tiloca@ri.se Content-Type: multipart/alternative; boundary="0000000000001959af05c2de3bfe" Archived-At: Subject: Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (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, 21 May 2021 22:03:41 -0000 --0000000000001959af05c2de3bfe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for humoring me as I try to verify that there isn't a problem here! I think we've collapsed the potential problem to NON_TIMEOUT and NON_RECEIVE_TIMEOUT. Some scenarios: (1) Let's say two senders simultaneously send MAX_PAYLOAD bursts over a radio medium that causes them to interfere with each other. With no response from the receiver at all, they both wait for NON_TIMEOUT and send another burst, causing the same effect. Can this not happen? (2) Two receivers send bursts that arrive at a bottleneck at the same time, causing congestion losses The receivers will request missing blocks, wait NON_RECEIVE_TIMEOUT, and trigger retransmission. For these to also collide, that would imply that (1) the RTTs are similar, and (2) the timing of the first missing packet signal is roughly simultaneous. Is that correct? Martin On Fri, May 21, 2021 at 12:17 PM wrote: > Hi Martin, > > > > NON_TIMEOUT has the same default value as ACK_TIMEOUT (Section 7.2 of the > draft). RFC7252 Section 4.2 =E2=80=9CMessages Transmitted Reliably=E2=80= =9D has > > > > For a new Confirmable message, the initial timeout is set > > to a random duration (often not an integral number of seconds) > > between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR) > > > > As mentioned previously in this thread > > =E2=80=9C > > RFC7252 introduces ACK_RANDOM_FACTOR jitter and separately jitter for > multicast responses (which is not relevant here). > > > > The ACK_RANDOM_FACTOR is there for when re-transmitting a packet that has > not been acknowledged for some reason by its peer. NON_TIMEOUT is for whe= n > the next MAX_PAYLOADS_SET can start transmission (not re-transmission) > assuming a 'Continue' has not arrived in the interim, and so was not > thought necessary to add in ACK_RANDOM_FACTOR style jitter here. > > > > For NON_RECEIVE_TIMEOUT, what is important is that NON_RECEIVE_TIMEOUT is > greater than NON_TIMEOUT (We say in the spec a minimum of one second) so > that a peer does not fire off a re-transmission request before the local > agent has a chance to start to transmit the next MAX_PAYLOADS_SET. > NON_RECEIVE_TIMEOUT is exponentially scaled for each retry to make sure > that stability is preserved. So, again, ACK_RANDOM_FACTOR jitter was not > thought to be necessary here. > > =E2=80=9C > > > > Does that help? > > > > Regards > > > > Jon > > > > *From:* Martin Duke [mailto: martin.h.duke@gmail.com] > *Sent:* 21 May 2021 19:39 > *To:* mohamed.boucadair@orange.com > *Cc:* John Scudder; draft-ietf-core-new-block@ietf.org; > core-chairs@ietf.org; The IESG; core@ietf.org; marco.tiloca@ri.se > *Subject:* Re: John Scudder's Discuss on draft-ietf-core-new-block-11: > (with DISCUSS and COMMENT) > > > > I agree that those two parameters have no need for jitter. > > > > However, NON_TIMEOUT and NON_RECEIVE_TIMEOUT would appear to, but derive > from 7252 formulae that don't have the jitter included. > > > > On Fri, May 21, 2021 at 10:27 AM wrote: > > Hi Martin, > > > > The comment about large numbers should be put in the context of the two > timeouts discussed with John: NON_PARTIAL_TIMEOUT and NON_PROBING_WAIT. > Consider the example of NON_PARTIAL_TIMEOUT, adding some jitter to it is > unlikely to have an effect as that timer is about controlling when a > received partial body will be discarded locally. > > > > NON_PROBING_WAIT is about limiting the effect of PROBING_RATE when a peer > does not reply. As a reminder, probing rate is defined as follows: > > > > The 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. > > > > Cheers, > > Med > > > > *De :* Martin Duke [mailto:martin.h.duke@gmail.com] > *Envoy=C3=A9 :* vendredi 21 mai 2021 18:28 > *=C3=80 :* John Scudder > *Cc :* BOUCADAIR Mohamed TGI/OLN ; > draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; The IESG < > iesg@ietf.org>; core@ietf.org; marco.tiloca@ri.se > *Objet :* Re: John Scudder's Discuss on draft-ietf-core-new-block-11: > (with DISCUSS and COMMENT) > > > > So I'm not sure that "large numbers" are a sufficient reason to not worry > about jitter. > > > > If two hosts simultaneously transmit on a quiet network, and cause losses > with each other. They both set the same retransmission timeout, and in > spite of no other traffic around cause the same collision, etc. > > > > If an explicit configuration doesn't result in common round numbers, it's > an OK substitute, but I don't see any encouragement of that choice. > > > > On Fri, May 21, 2021 at 9:17 AM John Scudder 40juniper.net@dmarc.ietf.org> wrote: > > Hi Med, > > Your current working copy looks good. I=E2=80=99ve cleared my discuss. > > =E2=80=94John > > > On May 21, 2021, at 8:41 AM, mohamed.boucadair@orange.com wrote: > > > > [External Email. Be cautious of content] > > > > > > Hi John, > > > > As you can see in > https://urldefense.com/v3/__https://tinyurl.com/new-block-latest__;!!NEt6= yMaO-gk!RlDk7GMcbxlFsT2QGl8ma04s1CggmQZQHcIP9aw2R2EP1rWkfQDAbIpzOgyR6g$ > > , we went with the following changes to better address your latest commen= t > on the jitter: > > > > (1) be explicit about the formula used for default values: > > > > OLD: > > NON_PROBING_WAIT is used to limit the potential wait needed when > > using PROBING_RATE. By default, NON_PROBING_WAIT has the same value > > as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). > > > > NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. > > By default, NON_PARTIAL_TIMEOUT has the same value as > > EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). > > > > NEW: > > NON_PROBING_WAIT is used to limit the potential wait needed when > > using PROBING_RATE. By default, NON_PROBING_WAIT is computed in the > > same way as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but with > > ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOUT and > > NON_MAX_RETRANSMIT, respectively: > > > > NON_PROBING_WAIT =3D NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1)= * > > ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT > > > > NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. > > By default, NON_PARTIAL_TIMEOUT is computed in the same way as > > EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]). This default value > > is calculated in the same way as NON_PROBING_WAIT. > > > > (2) We don=E2=80=99t see a need to apply a jitter when a value is expli= citly > configured (these are expected to be large numbers, we don't care that mu= ch > on the jitter). We added this text to be clear about the intent, and whic= h > BTW reflects the current implementation: > > > > NEW: > > When explicit values are > > configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these > > values are used without applying any jitter. > > > > We also adopted your proposed edits in the message below. > > > > Thank you again for the careful review. This is highly appreciated. > > > > Cheers, > > John & Med > > > >> -----Message d'origine----- > >> De : John Scudder [mailto:jgs@juniper.net] > >> Envoy=C3=A9 : vendredi 21 mai 2021 00:03 > >> =C3=80 : BOUCADAIR Mohamed TGI/OLN > >> Cc : The IESG ; draft-ietf-core-new-block@ietf.org; > >> core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se > >> Objet : Re: John Scudder's Discuss on draft-ietf-core-new-block-11: > >> (with DISCUSS and COMMENT) > >> > >> Hi Mohamed, > >> > >> I think we are converging. My comments in line. I=E2=80=99ve snipped a= greed > >> points for brevity, indicated by [=E2=80=A6]. > >> > >>> On May 20, 2021, at 9:17 AM, mohamed.boucadair@orange.com wrote: > >> > >> [=E2=80=A6] > >> > >>>>>> 11. General > >>>>>> > >>>>>> By the way, none of the timers specify jitter (and indeed, if > >> read > >>>>>> literally, jitter would be forbidden). Is this intentional? > >>>>> > >>>>> No +/- tolerances have been defined. When a timer expires, then > >> the > >>>> next action takes place. > >>>> > >>>> I notice that RFC 7252 jitters its timers, for example: > >>>> > >>>> counter. For a new Confirmable message, the initial timeout is > >> set > >>>> to a random duration (often not an integral number of seconds) > >>>> between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR) (see > >>>> Section 4.8) > >>>> =E2=80=A6 > >>>> ACK_RANDOM_FACTOR MUST NOT be decreased below 1.0, and it SHOULD > >>>> have > >>>> a value that is sufficiently different from 1.0 to provide some > >>>> protection from synchronization effects. > >>>> > >>>> MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT are similarly jittered. A > >>>> number of your introduced parameters > >>>> > >>>> This document introduces new parameters MAX_PAYLOADS, > >> NON_TIMEOUT, > >>>> NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and > >>>> NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3). > >>>> > >>>> appear at least superficially similar to the timers the authors of > >>>> RFC 7252 deemed important to jitter to prevent synchronization > >>>> effects. Did you specifically consider jittering them, and decide > >>>> that jitter was unnecessary? If so, can you explain what is > >> different > >>>> about your specification, compared to the base spec, that > >> eliminates > >>>> the concern? > >>> > >>> RFC7252 introduces ACK_RANDOM_FACTOR jitter and separately jitter > >> for multicast responses (which is not relevant here). > >>> > >>> The ACK_RANDOM_FACTOR is there for when re-transmitting a packet > >> that has not been acknowledged for some reason by its peer. > >> NON_TIMEOUT is for when the next MAX_PAYLOADS_SET can start > >> transmission (not re-transmission) assuming a 'Continue' has not > >> arrived in the interim, and so was not thought necessary to add in > >> ACK_RANDOM_FACTOR style jitter here. > >>> > >>> For NON_RECEIVE_TIMEOUT, what is important is that > >> NON_RECEIVE_TIMEOUT is greater than NON_TIMEOUT (We say in the spec a > >> minimum of one second) so that a peer does not fire off a re- > >> transmission request before the local agent has a chance to start to > >> transmit the next MAX_PAYLOADS_SET. NON_RECEIVE_TIMEOUT is > >> exponentially scaled for each retry to make sure that stability is > >> preserved. So, again, ACK_RANDOM_FACTOR jitter was not thought to be > >> necessary here. > >>> > >>> NON_MAX_RETRANSMIT is a fixed count. > >>> > >>> NON_PROBING_WAIT is used to put a limit on the potential delay that > >> could incur when obeying PROBING_WAIT when there is no peer response. > >> If the implementation goes with the default EXCHANGE_LIFETIME > >> computation, then NON_PROBING_WAIT includes ACK_RANDOM_FACTOR in the > >> math. > >>> > >>> NON_PARTIAL_TIMEOUT if computed using the default EXCHANGE_LIFETIME > >> includes ACK_RANDOM_FACTOR. > >> > >> Thanks for taking the time to explain. You don=E2=80=99t comment regar= ding > >> whether NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT should be jittered > >> or not, you just explain that if they use the default they get jitter > >> =E2=80=9Cfor free=E2=80=9D. The missing detail is that if they don=E2= =80=99t use the default > >> they don=E2=80=99t get jittered, so I think some consideration is stil= l > >> called for regarding whether having them not be jittered is OK. > >> > >> [=E2=80=A6] > >> > >>>>>> 15. Section 10.2.3 > >> > >> [=E2=80=A6] > >> > >>>> One concern related to that: waiting NON_TIMEOUT isn=E2=80=99t actua= lly > >>>> required, it=E2=80=99s only RECOMMENDED, therefore this isn=E2=80=99= t actually a > >>>> guarantee. From =C2=A77.2: > >>>> > >>>> As the sending of many payloads of a single body may itself > >> cause > >>>> congestion, it is RECOMMENDED that after transmission of every > >>>> MAX_PAYLOADS_SET of a single body, a delay is introduced of > >>>> NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage > >>>> potential congestion issues. > >>>> > >>>> I am curious why you made this a RECOMMENDED instead of a MUST. In > >> a > >>>> situation like this it would be preferable for you to explain to > >> the > >>>> implementor what situation they can ignore the RECOMMENDED in and > >>>> what they should do instead, or of course to make it into a MUST. > >>> > >>> Because a continue signal may be received from the peer and then > >> continue without waiting for the timeout to expire. > >>> > >>> This is to be linked with this text: > >>> > >>> A response using this Response Code SHOULD NOT be generated > >> for > >>> every received Q-Block1 Option request (Section 7.2). It > >> SHOULD > >>> only be generated when all the payload requests are Non- > >>> confirmable and a MAX_PAYLOADS_SET has been received by the > >>> server. More details about the motivations for this > >> optimization > >>> > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>> are discussed in Section 7.2. > >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>> > >>> We could use **MUST unless a 'Continue' is received**, e.g., > >>> > >>> OLD: > >>> As the sending of many payloads of a single body may itself cause > >>> congestion, it is RECOMMENDED that after transmission of every > >>> MAX_PAYLOADS_SET of a single body, a delay is introduced of > >>> NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage > >>> potential congestion issues. > >>> > >>> NEW: > >>> As the sending of many payloads of a single body may itself cause > >>> congestion, after transmission of every MAX_PAYLOADS_SET of a > >> single > >>> body, a delay MUST be introduced of NON_TIMEOUT before sending > >> the > >>> next MAX_PAYLOADS_SET to manage potential congestion issues. > >>> However, if a 'Continue' is received from the peer for the > >> current > >>> MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET can start > >>> transmission immediately. > >>> > >>> ... but I know that many would argue this is a SHOULD. > >> > >> I would be OK with either your proposed new text, or a SHOULD/MAY > >> pair as in > >> > >> NEW: > >> As the sending of many payloads of a single body may itself cause > >> congestion, after transmission of every MAX_PAYLOADS_SET of a > >> single > >> body, a delay SHOULD be introduced of NON_TIMEOUT before sending > >> the > >> next MAX_PAYLOADS_SET to manage potential congestion issues. > >> However, if a 'Continue' is received from the peer for the current > >> MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET MAY start > >> transmission immediately. > >> > >> If you want to stick with MUST I think you can clear up the pain with > >> something like > >> > >> NEW: > >> As the sending of many payloads of a single body may itself cause > >> congestion, after transmission of every MAX_PAYLOADS_SET of a > >> single > >> body, a delay MUST be introduced of NON_TIMEOUT before sending the > >> next MAX_PAYLOADS_SET unless a 'Continue' is received from the peer > >> for the current MAX_PAYLOADS_SET, in which case the next > >> MAX_PAYLOADS_SET MAY start transmission immediately. > >> > >> (To my eye presenting the option in this way makes it clear when the > >> MUST does, and doesn=E2=80=99t, apply. This is my preferred form but I= don=E2=80=99t > >> insist.) > >> > >> [=E2=80=A6] > >> > >>>> 17. Section 1: > >>>> > >>>> This document introduces the CoAP Q-Block1 and Q-Block2 Options > >>>> which > >>>> allow block-wise transfer to work with series of Non-confirmable > >>>> messages, instead of lock-stepping using Confirmable messages > >>>> (Section 3). In other words, this document provides a missing > >>>> piece > >>>> of [RFC7959], namely the support of block-wise transfer using > >> Non- > >>>> confirmable where an entire body of data can be transmitted > >> without > >>>> the requirement for an acknowledgement (but recovery is > >> available > >>>> should it be needed). > >>>> > >>>> As far as I can tell the spec does not really remove the > >> requirement > >>>> for acknowledgement, > >>> > >>> These are not required. They were added as an optimization to avoid > >> the non-timeout if the peer decides to use it. > >> > >> As I mentioned below (=E2=80=9Cawfully close parsing=E2=80=9D), I thin= k that although > >> you can find some justification for this reading, it=E2=80=99s debatab= le. > >> Transmission of the acknowledgement (at least the final > >> acknowledgement of the entire body, in the form of a Response Code) > >> is required, is it not? Reception isn=E2=80=99t required though. Witho= ut the > >> verb, I=E2=80=99m not sure whether I can say whether acknowledgement i= s, or > >> isn=E2=80=99t, required. > >> > >> I don=E2=80=99t insist that you change this, but I do think you could = improve > >> the clarity of the document, if you edited the above to read =E2=80=9C= =E2=80=A6 > >> without the requirement that an acknowledgment be received from the > >> peer" > >> > >>>> it just amortizes the acknowledgements by only sending them every > >>>> MAX_PAYLOADS_SET. Response Code 2.31 is essentially an > >>>> acknowledgement, and it gets sent that frequently, right? There=E2= =80=99s > >>>> also (if I recall correctly) some flavor of acknowledgement that > >> is > >>>> sent when the entire body has been transferred. So, I think the > >> new > >>>> paragraph isn=E2=80=99t accurate. > >>>> > >>>> This observation also applies to this claimed benefit in =C2=A73: > >>>> > >>>> o They support sending an entire body using NON messages > >> without > >>>> requiring an intermediate response from the peer. > >> > >> And similarly, =E2=80=9C=E2=80=A6 without requiring that an intermedia= te response be > >> received from the peer.=E2=80=9D > >> > >> [=E2=80=A6] > >> > >>>> 18. Section 2: > >>>> > >>>> MAX_PAYLOADS_SET is the set of blocks identified by block > >> numbers > >>>> that, when divided by MAX_PAYLOADS, they have the same numeric > >>>> > >>>> Remove =E2=80=9Cthey=E2=80=9D > >>> > >>> Fixed. Thanks. > >>> > >>>> > >>>> result. For example, if MAX_PAYLOADS is set to '10', a > >>>> MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc. > >>>> Depending on the data size, the MAX_PAYLOADS_SET may not > >> comprise > >>>> all > >>>> the MAX_PAYLOADS blocks. > >>>> > >>>> I don=E2=80=99t understand the last sentence ("Depending on the data= size, > >>>> the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS > >> blocks.=E2=80=9D) > >>>> Are you trying to say that if the body size isn=E2=80=99t evenly div= isible > >> by > >>>> MAX_PAYLOADS then the final MAX_PAYLOADS_SET will have fewer than > >>>> MAX_PAYLOADS blocks in it? > >>> > >>> We meant that the last set may include fewer blocks than > >> MAX_PAYLOADS. Changed to: > >>> > >>> " Depending on the overall data > >>> ^^^^^^^^ > >>> size, the final MAX_PAYLOADS_SET may not comprise all the > >>> ^^^^^ > >>> MAX_PAYLOADS blocks. " > >>> > >>> Better? > >> > >> Improving. The word =E2=80=9Ccomprise=E2=80=9D is prone to misinterpre= tation in my > >> experience, I would suggest something like =E2=80=9C=E2=80=A6 there co= uld be fewer > >> than MAX_PAYLOADS blocks in the final MAX_PAYLOADS_SET.=E2=80=9D > >> > >> Thanks, > >> > >> =E2=80=94John > > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles 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 > been modified, changed or falsified. > > Thank you. > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > --0000000000001959af05c2de3bfe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for humoring me as I try to verify that there = isn't a problem here!

I think we've collap= sed the potential problem to NON_TIMEOUT and NON_RECEIVE_TIMEOUT.

Some scenarios:
(1) Let's say two senders sim= ultaneously send MAX_PAYLOAD bursts over a radio medium that causes them to= interfere with each other. With no response from the receiver at all, they= both wait for NON_TIMEOUT and send another burst, causing the same effect.=

Can this not happen?

(2)= Two receivers send bursts that arrive at a bottleneck at the same time, ca= using congestion losses

The receivers will req= uest missing blocks, wait NON_RECEIVE_TIMEOUT, and trigger retransmission. = For these to also collide, that would imply that (1) the RTTs are similar, = and (2) the timing of the first missing packet signal is roughly simultaneo= us.

Is that correct?

Mart= in

On Fri, May 21, 2021 at 12:17 PM <supjps-ietf@jpshallow.com> wrote:

Hi Martin,

=C2=A0

NON_TIMEOUT has the sam= e default value as ACK_TIMEOUT (Section 7.2 of the draft).=C2=A0 RFC7252 Se= ction 4.2 =E2=80=9CMessages Transmitted Reliably=E2=80=9D has=

= =C2=A0

=C2=A0=C2=A0 For a new Confirmable message, the initial timeout is set<= u>

=C2=A0=C2=A0 to a random duration (often not an integral number of seco= nds)

=C2=A0=C2=A0 between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FAC= TOR)

=C2=A0

As mentioned previously in this thread

=E2=80=9C

RFC7252 introduces ACK_RANDOM_FACTOR jitter and separately jitter for mul= ticast responses (which is not relevant here).

=C2=A0

The ACK_RANDOM_FACTOR is ther= e for when re-transmitting a packet that has not been acknowledged for some= reason by its peer. NON_TIMEOUT is for when the next MAX_PAYLOADS_SET can = start transmission (not re-transmission) assuming a 'Continue' has = not arrived in the interim, and so was not thought necessary to add in ACK_= RANDOM_FACTOR style jitter here.

=C2=A0

For NON_RECEIVE_TIMEOUT, what is important = is that NON_RECEIVE_TIMEOUT is greater than NON_TIMEOUT (We say in the spec= a minimum of one second) so that a peer does not fire off a re-transmissio= n request before the local agent has a chance to start to transmit the next= MAX_PAYLOADS_SET.=C2=A0 NON_RECEIVE_TIMEOUT is exponentially scaled for ea= ch retry to make sure that stability is preserved. So, again, ACK_RANDOM_FA= CTOR jitter was not thought to be necessary here.

=E2=80=9C

=C2=A0<= u>

Doe= s that help?

=C2=A0

Regards

=C2=A0

Jon=

=C2=A0=

From: Martin Duke [mai= lto: martin.h.= duke@gmail.com]
Sent: 21 May 2021 19:39
To: mohamed.boucada= ir@orange.com
Cc: John Scudder; draft-ietf-core-new-block@ietf.o= rg; core-chai= rs@ietf.org; The IESG; core@ietf.org; marco.tiloca@ri.se
Subject: Re: John Scudder's Discuss= on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)<= /span>

=C2=A0

<= div>

I agree that those two parameters have no need f= or jitter.

=C2=A0=

However, NON_TIMEOUT and NON_R= ECEIVE_TIMEOUT would appear to, but derive from 7252 formulae that don'= t have the jitter included.

=C2=A0

On Fri, May 2= 1, 2021 at 10:27 AM <mohamed.boucadair@orange.com> wrote:

Hi Martin,=

=C2=A0<= /u>

The commen= t about large numbers should be put in the context of the two timeouts disc= ussed with John: NON_PARTIAL_TIMEOUT and NON_PROBING_WAIT. Consider the exa= mple of NON_PARTIAL_TIMEOUT, adding some jitter to it is unlikely to have a= n effect as that timer is about controlling when a received partial body wi= ll be discarded locally. <= /p>

=C2=A0

NON_PROBING_WAIT is about limiting the effect of PROBING_RATE= when a peer does not reply. As a reminder, probing rate is defined as foll= ows:

=C2=A0<= u>

=C2=A0= =C2=A0 The PROBING_RATE parameter in CoAP indicates the average data rate

<= span style=3D"font-size:11pt;font-family:"Courier New";color:rgb(= 31,73,125)" lang=3D"EN-US">=C2=A0=C2=A0 that must not be exceeded by a CoAP= endpoint in sending to a peer

=C2=A0=C2=A0 end= point that does not respond.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Martin Duke [mailto:martin.h.duke@gmail.com]
Envoy=C3=A9=C2=A0: = vendredi 21 mai 2021 18:28
=C3=80=C2=A0: John Scudder <jgs=3D<= a href=3D"mailto:40juniper.net@dmarc.ietf.org" target=3D"_blank">40juniper.= net@dmarc.ietf.org>
Cc=C2=A0: BOUCADAIR Mohamed TGI/OLN &l= t;mohamed= .boucadair@orange.com>; draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org= ; The IESG <iesg@ietf= .org>; core@ietf.= org; marco.tilo= ca@ri.se
Objet=C2=A0: Re: John Scudder's Discuss on draft= -ietf-core-new-block-11: (with DISCUSS and COMMENT)

=C2=A0

= So I'm not sure that "large numbers" are= a sufficient reason to not worry about jitter.

=C2=A0

If two hosts= simultaneously transmit on a quiet network, and cause losses with each oth= er. They both set the same retransmission timeout, and in spite of no other= traffic around cause the same collision, etc.

=C2=A0

If an explici= t configuration doesn't result in common round numbers, it's an OK = substitute, but I don't see any encouragement of that choice.=

=C2= =A0

On Fri, May 21, 2021 at 9:17 AM John Scudder <jgs=3D40juniper.net@dmarc.ie= tf.org> wrote:

Hi Med,

Your current working co= py looks good. I=E2=80=99ve cleared my discuss.

=E2=80=94John
> On May 21, 2021, at 8:41 AM, mohamed.boucadair@orange.com wrote:
> <= br>> [External Email. Be cautious of content]
>
>
> = Hi John,
>
> As you can see in https:/= /urldefense.com/v3/__https://tinyurl.com/new-block-latest__;!!NEt6yMaO-gk!R= lDk7GMcbxlFsT2QGl8ma04s1CggmQZQHcIP9aw2R2EP1rWkfQDAbIpzOgyR6g$ , we wen= t with the following changes to better address your latest comment on the j= itter:
>
> (1) be explicit about the formula used for default = values:
>
> OLD:
>=C2=A0 =C2=A0NON_PROBING_WAIT is used = to limit the potential wait needed when
>=C2=A0 =C2=A0using PROBING_R= ATE.=C2=A0 By default, NON_PROBING_WAIT has the same value
>=C2=A0 = =C2=A0as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
>
>= =C2=A0 =C2=A0NON_PARTIAL_TIMEOUT is used for expiring partially received bo= dies.
>=C2=A0 =C2=A0By default, NON_PARTIAL_TIMEOUT has the same valu= e as
>=C2=A0 =C2=A0EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).>
> NEW:
>=C2=A0 =C2=A0NON_PROBING_WAIT is used to limit t= he potential wait needed when
>=C2=A0 =C2=A0using PROBING_RATE.=C2=A0= By default, NON_PROBING_WAIT is computed in the
>=C2=A0 =C2=A0same w= ay as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but with
>=C2=A0= =C2=A0ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOUT and
&= gt;=C2=A0 =C2=A0NON_MAX_RETRANSMIT, respectively:
>
>=C2=A0 = =C2=A0 =C2=A0 NON_PROBING_WAIT =3D NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT)= - 1) *
>=C2=A0 =C2=A0 =C2=A0 ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) += NON_TIMEOUT
>
>=C2=A0 =C2=A0NON_PARTIAL_TIMEOUT is used for e= xpiring partially received bodies.
>=C2=A0 =C2=A0By default, NON_PART= IAL_TIMEOUT is computed in the same way as
>=C2=A0 =C2=A0EXCHANGE_LIF= ETIME (Section 4.8.2 of [RFC7252]).=C2=A0 This default value
>=C2=A0 = =C2=A0is calculated in the same way as NON_PROBING_WAIT.
>
> (= 2) We don=E2=80=99t see a need to apply a jitter when a value is explicitly= configured (these are expected to be large numbers, we don't care that= much on the jitter). We added this text to be clear about the intent, and = which BTW reflects the current implementation:
>
> NEW:
>= ;=C2=A0 =C2=A0 =C2=A0 When explicit values are
>=C2=A0 =C2=A0 =C2=A0 = configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these
>=C2= =A0 =C2=A0 =C2=A0 values are used without applying any jitter.
>
= > We also adopted your proposed edits in the message below.
>
= > Thank you again for the careful review. This is highly appreciated.>
> Cheers,
> John & Med
>
>> -----Mes= sage d'origine-----
>> De : John Scudder [mailto:jgs@juniper.net]
>> En= voy=C3=A9 : vendredi 21 mai 2021 00:03
>> =C3=80 : BOUCADAIR Moham= ed TGI/OLN <mohamed.boucadair@orange.com>
>> Cc : The IESG <iesg@ietf.org>; draft-= ietf-core-new-block@ietf.org;
>> core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se
>> Objet : R= e: John Scudder's Discuss on draft-ietf-core-new-block-11:
>> = (with DISCUSS and COMMENT)
>>
>> Hi Mohamed,
>>=
>> I think we are converging. My comments in line. I=E2=80=99ve = snipped agreed
>> points for brevity, indicated by [=E2=80=A6].>>
>>> On May 20, 2021, at 9:17 AM, mohamed.boucadair@orange.com= wrote:
>>
>> [=E2=80=A6]
>>
>>&g= t;>>> 11. General
>>>>>>
>>>>= >> By the way, none of the timers specify jitter (and indeed, if
&= gt;> read
>>>>>> literally, jitter would be forbidd= en). Is this intentional?
>>>>>
>>>>> = No +/- tolerances have been defined. When a timer expires, then
>>= the
>>>> next action takes place.
>>>>
&= gt;>>> I notice that RFC 7252 jitters its timers, for example:
= >>>>
>>>>=C2=A0 counter.=C2=A0 For a new Confir= mable message, the initial timeout is
>> set
>>>>= =C2=A0 to a random duration (often not an integral number of seconds)
&g= t;>>>=C2=A0 between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACT= OR) (see
>>>>=C2=A0 Section 4.8)
>>>> =E2=80= =A6
>>>>=C2=A0 ACK_RANDOM_FACTOR MUST NOT be decreased below= 1.0, and it SHOULD
>>>> have
>>>>=C2=A0 a va= lue that is sufficiently different from 1.0 to provide some
>>>= >=C2=A0 protection from synchronization effects.
>>>> >>>> MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT are similarly jit= tered. A
>>>> number of your introduced parameters
>&g= t;>>
>>>>=C2=A0 This document introduces new paramete= rs MAX_PAYLOADS,
>> NON_TIMEOUT,
>>>>=C2=A0 NON_REC= EIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and
>>>>= =C2=A0 NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3).
>>= ;>>
>>>> appear at least superficially similar to the= timers the authors of
>>>> RFC 7252 deemed important to jit= ter to prevent synchronization
>>>> effects. Did you specifi= cally consider jittering them, and decide
>>>> that jitter w= as unnecessary? If so, can you explain what is
>> different
>= ;>>> about your specification, compared to the base spec, that
= >> eliminates
>>>> the concern?
>>>
&g= t;>> RFC7252 introduces ACK_RANDOM_FACTOR jitter and separately jitte= r
>> for multicast responses (which is not relevant here).
>= >>
>>> The ACK_RANDOM_FACTOR is there for when re-transm= itting a packet
>> that has not been acknowledged for some reason = by its peer.
>> NON_TIMEOUT is for when the next MAX_PAYLOADS_SET = can start
>> transmission (not re-transmission) assuming a 'Co= ntinue' has not
>> arrived in the interim, and so was not thou= ght necessary to add in
>> ACK_RANDOM_FACTOR style jitter here.>>>
>>> For NON_RECEIVE_TIMEOUT, what is important i= s that
>> NON_RECEIVE_TIMEOUT is greater than NON_TIMEOUT (We say = in the spec a
>> minimum of one second) so that a peer does not fi= re off a re-
>> transmission request before the local agent has a = chance to start to
>> transmit the next MAX_PAYLOADS_SET.=C2=A0 NO= N_RECEIVE_TIMEOUT is
>> exponentially scaled for each retry to mak= e sure that stability is
>> preserved. So, again, ACK_RANDOM_FACTO= R jitter was not thought to be
>> necessary here.
>>> =
>>> NON_MAX_RETRANSMIT is a fixed count.
>>>
&= gt;>> NON_PROBING_WAIT is used to put a limit on the potential delay = that
>> could incur when obeying PROBING_WAIT when there is no pee= r response.
>> If the implementation goes with the default EXCHANG= E_LIFETIME
>> computation, then NON_PROBING_WAIT includes ACK_RAND= OM_FACTOR in the
>> math.
>>>
>>> NON_PAR= TIAL_TIMEOUT if computed using the default EXCHANGE_LIFETIME
>> in= cludes ACK_RANDOM_FACTOR.
>>
>> Thanks for taking the ti= me to explain. You don=E2=80=99t comment regarding
>> whether NON_= PROBING_WAIT and NON_PARTIAL_TIMEOUT should be jittered
>> or not,= you just explain that if they use the default they get jitter
>> = =E2=80=9Cfor free=E2=80=9D. The missing detail is that if they don=E2=80=99= t use the default
>> they don=E2=80=99t get jittered, so I think s= ome consideration is still
>> called for regarding whether having = them not be jittered is OK.
>>
>> [=E2=80=A6]
>>= ;
>>>>>> 15. Section 10.2.3
>>
>> = [=E2=80=A6]
>>
>>>> One concern related to that: w= aiting NON_TIMEOUT isn=E2=80=99t actually
>>>> required, it= =E2=80=99s only RECOMMENDED, therefore this isn=E2=80=99t actually a
>= ;>>> guarantee. From =C2=A77.2:
>>>>
>>&g= t;>=C2=A0 As the sending of many payloads of a single body may itself>> cause
>>>>=C2=A0 congestion, it is RECOMMENDED tha= t after transmission of every
>>>>=C2=A0 MAX_PAYLOADS_SET of= a single body, a delay is introduced of
>>>>=C2=A0 NON_TIME= OUT before sending the next MAX_PAYLOADS_SET to manage
>>>>= =C2=A0 potential congestion issues.
>>>>
>>>>= ; I am curious why you made this a RECOMMENDED instead of a MUST. In
>= ;> a
>>>> situation like this it would be preferable for = you to explain to
>> the
>>>> implementor what situ= ation they can ignore the RECOMMENDED in and
>>>> what they = should do instead, or of course to make it into a MUST.
>>> >>> Because a continue signal may be received from the peer and t= hen
>> continue without waiting for the timeout to expire.
>= >>
>>> This is to be linked with this text:
>>&= gt;
>>>=C2=A0 =C2=A0 =C2=A0A response using this Response Code= SHOULD NOT be generated
>> for
>>>=C2=A0 =C2=A0 =C2= =A0every received Q-Block1 Option request (Section 7.2).=C2=A0 It
>&g= t; SHOULD
>>>=C2=A0 =C2=A0 =C2=A0only be generated when all the= payload requests are Non-
>>>=C2=A0 =C2=A0 =C2=A0confirmable a= nd a MAX_PAYLOADS_SET has been received by the
>>>=C2=A0 =C2=A0= =C2=A0 server.=C2=A0 More details about the motivations for this
>&g= t; optimization
>>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>=C2=A0 =C2=A0 =C2=A0are discussed= in Section 7.2.
>>>=C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^
>>>
>>> We could use **MUST unless a 'Co= ntinue' is received**, e.g.,
>>>
>>> OLD:
&= gt;>>=C2=A0 As the sending of many payloads of a single body may itse= lf cause
>>>=C2=A0 congestion, it is RECOMMENDED that after tra= nsmission of every
>>>=C2=A0 MAX_PAYLOADS_SET of a single body,= a delay is introduced of
>>>=C2=A0 NON_TIMEOUT before sending = the next MAX_PAYLOADS_SET to manage
>>>=C2=A0 potential congest= ion issues.
>>>
>>> NEW:
>>>=C2=A0 As = the sending of many payloads of a single body may itself cause
>>&= gt;=C2=A0 congestion, after transmission of every MAX_PAYLOADS_SET of a
= >> single
>>>=C2=A0 body, a delay MUST be introduced of N= ON_TIMEOUT before sending
>> the
>>>=C2=A0 next MAX_PA= YLOADS_SET to manage potential congestion issues.
>>>=C2=A0 How= ever, if a 'Continue' is received from the peer for the
>>= current
>>>=C2=A0 MAX_PAYLOADS_SET, then the next MAX_PAYLOADS= _SET can start
>>>=C2=A0 transmission immediately.
>>&= gt;
>>> ... but I know that many would argue this is a SHOULD.=
>>
>> I would be OK with either your proposed new text,= or a SHOULD/MAY
>> pair as in
>>
>> NEW:
&g= t;>=C2=A0 As the sending of many payloads of a single body may itself ca= use
>>=C2=A0 congestion, after transmission of every MAX_PAYLOADS_= SET of a
>> single
>>=C2=A0 body, a delay SHOULD be intro= duced of NON_TIMEOUT before sending
>> the
>>=C2=A0 next = MAX_PAYLOADS_SET to manage potential congestion issues.
>>=C2=A0 H= owever, if a 'Continue' is received from the peer for the current>>=C2=A0 MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET MAY start=
>>=C2=A0 transmission immediately.
>>
>> If yo= u want to stick with MUST I think you can clear up the pain with
>>= ; something like
>>
>> NEW:
>>=C2=A0 As the sen= ding of many payloads of a single body may itself cause
>>=C2=A0 c= ongestion, after transmission of every MAX_PAYLOADS_SET of a
>> si= ngle
>>=C2=A0 body, a delay MUST be introduced of NON_TIMEOUT befo= re sending the
>>=C2=A0 next MAX_PAYLOADS_SET unless a 'Contin= ue' is received from the peer
>>=C2=A0 for the current MAX_PAY= LOADS_SET, in which case the next
>>=C2=A0 MAX_PAYLOADS_SET MAY st= art transmission immediately.
>>
>> (To my eye presentin= g the option in this way makes it clear when the
>> MUST does, and= doesn=E2=80=99t, apply. This is my preferred form but I don=E2=80=99t
&= gt;> insist.)
>>
>> [=E2=80=A6]
>>
>&= gt;>> 17. Section 1:
>>>>
>>>>=C2=A0 T= his document introduces the CoAP Q-Block1 and Q-Block2 Options
>>&= gt;> which
>>>>=C2=A0 allow block-wise transfer to work w= ith series of Non-confirmable
>>>>=C2=A0 messages, instead o= f lock-stepping using Confirmable messages
>>>>=C2=A0 (Secti= on 3).=C2=A0 In other words, this document provides a missing
>>&g= t;> piece
>>>>=C2=A0 of [RFC7959], namely the support of = block-wise transfer using
>> Non-
>>>>=C2=A0 confir= mable where an entire body of data can be transmitted
>> without>>>>=C2=A0 the requirement for an acknowledgement (but recove= ry is
>> available
>>>>=C2=A0 should it be needed).=
>>>>
>>>> As far as I can tell the spec doe= s not really remove the
>> requirement
>>>> for ack= nowledgement,
>>>
>>> These are not required. They= were added as an optimization to avoid
>> the non-timeout if the = peer decides to use it.
>>
>> As I mentioned below (=E2= =80=9Cawfully close parsing=E2=80=9D), I think that although
>> yo= u can find some justification for this reading, it=E2=80=99s debatable.
= >> Transmission of the acknowledgement (at least the final
>>= ; acknowledgement of the entire body, in the form of a Response Code)
&g= t;> is required, is it not? Reception isn=E2=80=99t required though. Wit= hout the
>> verb, I=E2=80=99m not sure whether I can say whether a= cknowledgement is, or
>> isn=E2=80=99t, required.
>>
= >> I don=E2=80=99t insist that you change this, but I do think you co= uld improve
>> the clarity of the document, if you edited the abov= e to read =E2=80=9C=E2=80=A6
>> without the requirement that an ac= knowledgment be received from the
>> peer"
>>
&g= t;>>> it just amortizes the acknowledgements by only sending them = every
>>>> MAX_PAYLOADS_SET. Response Code 2.31 is essential= ly an
>>>> acknowledgement, and it gets sent that frequently= , right? There=E2=80=99s
>>>> also (if I recall correctly) s= ome flavor of acknowledgement that
>> is
>>>> sent = when the entire body has been transferred. So, I think the
>> new<= br>>>>> paragraph isn=E2=80=99t accurate.
>>>> <= br>>>>> This observation also applies to this claimed benefit i= n =C2=A73:
>>>>
>>>>=C2=A0 o=C2=A0 They supp= ort sending an entire body using NON messages
>> without
>&g= t;>>=C2=A0 =C2=A0 =C2=A0requiring an intermediate response from the p= eer.
>>
>> And similarly, =E2=80=9C=E2=80=A6 without req= uiring that an intermediate response be
>> received from the peer.= =E2=80=9D
>>
>> [=E2=80=A6]
>>
>>>= > 18. Section 2:
>>>>
>>>>=C2=A0 MAX_PAYL= OADS_SET is the set of blocks identified by block
>> numbers
&g= t;>>>=C2=A0 that, when divided by MAX_PAYLOADS, they have the same= numeric
>>>>
>>>> Remove =E2=80=9Cthey=E2= =80=9D
>>>
>>> Fixed. Thanks.
>>>
= >>>>
>>>>=C2=A0 result.=C2=A0 For example, if M= AX_PAYLOADS is set to '10', a
>>>>=C2=A0 MAX_PAYLOAD= S_SET could be blocks #0 to #9, #10 to #19, etc.
>>>>=C2=A0 = Depending on the data size, the MAX_PAYLOADS_SET may not
>> compri= se
>>>> all
>>>>=C2=A0 the MAX_PAYLOADS block= s.
>>>>
>>>> I don=E2=80=99t understand the = last sentence ("Depending on the data size,
>>>> the MA= X_PAYLOADS_SET may not comprise all the MAX_PAYLOADS
>> blocks.=E2= =80=9D)
>>>> Are you trying to say that if the body size isn= =E2=80=99t evenly divisible
>> by
>>>> MAX_PAYLOADS= then the final MAX_PAYLOADS_SET will have fewer than
>>>> M= AX_PAYLOADS blocks in it?
>>>
>>> We meant that th= e last set may include fewer blocks than
>> MAX_PAYLOADS. Changed = to:
>>>
>>> " Depending on the overall data>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0^^^^^^^^
>>>=C2=A0 size, the final MAX_PAYLOADS_SET m= ay not comprise all the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ^^^^^
>>>=C2=A0 MAX_PAYLOADS blocks. "
>>&= gt;
>>> Better?
>>
>> Improving. The word = =E2=80=9Ccomprise=E2=80=9D is prone to misinterpretation in my
>> = experience, I would suggest something like =E2=80=9C=E2=80=A6 there could b= e fewer
>> than MAX_PAYLOADS blocks in the final MAX_PAYLOADS_SET.= =E2=80=9D
>>
>> Thanks,
>>
>> =E2=80= =94John
>
> __________________________________________________= _______________________________________________________________________
= >
> Ce message et ses pieces jointes peuvent contenir des informa= tions confidentielles ou privilegiees et ne doivent donc
> pas etre d= iffuses, exploites ou copies sans autorisation. Si vous avez recu ce messag= e par erreur, veuillez le signaler
> a l'expediteur et le detruir= e ainsi que les pieces jointes. Les messages electroniques etant susceptibl= es d'alteration,
> Orange decline toute responsabilite si ce mess= age a ete altere, deforme ou falsifie. Merci.
>
> This message= and its attachments may contain confidential or privileged information tha= t may be protected by law;
> they should not be distributed, used or = copied without authorisation.
> If you have received this email in er= ror, please notify the sender and delete this message and its attachments.<= br>> As emails may be altered, Orange is not liable for messages that ha= ve been modified, changed or falsified.
> Thank you.
> <= u>

_=
___________________________________________________________________________=
_____________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir des informations c=
onfidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans auto=
risation. Si vous avez recu ce message par erreur, veuillez le signaler<=
/u>
a l'expediteur et le d=
etruire ainsi que les pieces jointes. Les messages electroniques etant susc=
eptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme=
 ou falsifie. Merci.
=C2=A0
This message and i=
ts attachments may contain confidential or privileged information that may =
be protected by law;
th=
ey should not be distributed, used or copied without authorisation.<=
u>
If you have received this emai=
l in error, please notify the sender and delete this message and its attach=
ments.
As emails may be=
 altered, Orange is not liable for messages that have been modified, change=
d or falsified.
Thank y=
ou.
--0000000000001959af05c2de3bfe-- From nobody Sat May 22 05:45: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 34CF73A23C1 for ; Sat, 22 May 2021 05:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 z6BnhmOpeIr0 for ; Sat, 22 May 2021 05:45:13 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 CA1BF3A23BF for ; Sat, 22 May 2021 05:45:12 -0700 (PDT) Received: from mail-pf1-f181.google.com ([209.85.210.181]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1lkR08-0004UO-Ae; Sat, 22 May 2021 14:45:08 +0200 Received: by mail-pf1-f181.google.com with SMTP id 10so16992143pfl.1 for ; Sat, 22 May 2021 05:45:08 -0700 (PDT) X-Gm-Message-State: AOAM531Kroi2CkKLLFCAqzMp25yzKugsUe2aLcui3iGYO65JziFE7KNz ih3OgBdQiua3s2X87Pi9yP50QEk9NKdRDfLsDp4= X-Google-Smtp-Source: ABdhPJzc1jImxxAucy0i+PLKHtrk5FSK3tB38qEKRLwcwOPSGrO84Nu65n32SDmyZrUOaio0NDhZYpDJu2XKV7pxvEw= X-Received: by 2002:aa7:8a85:0:b029:2db:484c:de1a with SMTP id a5-20020aa78a850000b02902db484cde1amr14978548pfc.2.1621687506893; Sat, 22 May 2021 05:45:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Klaus Hartke Date: Sat, 22 May 2021 14:44:32 +0200 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1621687512; f1b5fa11; X-HE-SMSGID: 1lkR08-0004UO-Ae Archived-At: Subject: Re: [core] Tossing around URIs to use outside an application X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2021 12:45:14 -0000 Christian Ams=C3=BCss wrote: > A thing that came up in last week's interim is the usability of URIs > that you are just "tossed", with respect to secure usage. In addition to secure usage, this came also up with respect to the vocabularies used e.g. in CoRAL documents. I.e., if we need to pass more than just a URI, such as security-related information, could we also pass vocabulary-related information in the same way? > What I'm leaning towards taking from this is that we should be able to > support tossable URIs, but what they would look like in practice in a > CoREnvironment may need looking into. That might be closely related to the question what a tossable URI in a CoREnvironment is precisely... When a Web browser is tossed a URI, it's preconfigured with a set of root certificates and a single purpose: Make a GET request to that URI and render the resulting HTML document. In a CoREnvironment, there are probably no root certificates and no predefined purpose. At a minimum, you probably always toss a URI together with something like "Your resource directory is at this URI" or "Please POST your sensor data to this URI". Additionally, you probably also need to configure some certificate/PSK and the intents/wills of the stakeholders/principals involved. Maybe some of that needs to be set directly, maybe some could be discovered through a layer of indirection. Is there something we could standardize here? Klaus From nobody Sat May 22 13:09: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 64E753A1BBC for ; Sat, 22 May 2021 13:09:16 -0700 (PDT) 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_FAIL=0.001, SPF_HELO_NONE=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 MtXNYAIsSMMs for ; Sat, 22 May 2021 13:09:10 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3DC3A1BBB for ; Sat, 22 May 2021 13:09:09 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FnZLS6DVRz315r; Sat, 22 May 2021 22:09:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) From: Carsten Bormann In-Reply-To: Date: Sat, 22 May 2021 22:09:04 +0200 Cc: =?utf-8?Q?Christian_Ams=C3=BCss?= , "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 643406944.4733-b8fdff370f382fc9f222f746e307826d Content-Transfer-Encoding: quoted-printable Message-Id: <2D41F5BE-A83A-4C73-95D0-E2CD2B57FA5B@tzi.org> References: To: Klaus Hartke X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: Subject: Re: [core] Tossing around URIs to use outside an application X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2021 20:09:17 -0000 I think we are reinventing link relationships, just better. You can=E2=80=99t really =E2=80=9Ctoss=E2=80=9D a URI, you are tossing a = document (that contains the URI). If that document does not specify a link relationship (a purpose), you = need application state going along with that or you don=E2=80=99t know = what to do with the URI. If that document does contain a link relationship (and possibly further = parameters), these become part of the application state, hopefully = together with the provenance of that tossed document. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun May 23 03:17: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 CE7393A1005 for ; Sun, 23 May 2021 03:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xqsseGEQMBt8 for ; Sun, 23 May 2021 03:17:48 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 3EC803A1004 for ; Sun, 23 May 2021 03:17:47 -0700 (PDT) Received: from mail-pf1-f177.google.com ([209.85.210.177]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1lklB1-0003Td-JG; Sun, 23 May 2021 12:17:43 +0200 Received: by mail-pf1-f177.google.com with SMTP id c17so18436216pfn.6 for ; Sun, 23 May 2021 03:17:43 -0700 (PDT) X-Gm-Message-State: AOAM532sSnjxx7ZkwfMdv+aaJ/VIeqUi0NJCGjEwn65uRseIi1I7om8Y ZqBwx7oJ3hTo96DWuk/5iiVzY3g2imHJdkdIbvA= X-Google-Smtp-Source: ABdhPJzB6fRnpjxWcVMRJBiqK6saSrwKKfSqggWRpu/vCn57JknHP5pwLh8uwOycHwI1Cu7tR42FfkynxQJhJnlGVb0= X-Received: by 2002:a63:ed41:: with SMTP id m1mr8047458pgk.252.1621765062236; Sun, 23 May 2021 03:17:42 -0700 (PDT) MIME-Version: 1.0 References: <2D41F5BE-A83A-4C73-95D0-E2CD2B57FA5B@tzi.org> In-Reply-To: <2D41F5BE-A83A-4C73-95D0-E2CD2B57FA5B@tzi.org> From: Klaus Hartke Date: Sun, 23 May 2021 12:17:07 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Cc: =?UTF-8?Q?Christian_Ams=C3=BCss?= , "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1621765068; 1c379091; X-HE-SMSGID: 1lklB1-0003Td-JG Archived-At: Subject: Re: [core] Tossing around URIs to use outside an application X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 May 2021 10:17:50 -0000 Carsten Bormann wrote: > I think we are reinventing link relationships, just better. > > You can=E2=80=99t really =E2=80=9Ctoss=E2=80=9D a URI, you are tossing a = document (that contains the URI). > If that document does not specify a link relationship (a purpose), you ne= ed application state going along with that or you don=E2=80=99t know what t= o do with the URI. > If that document does contain a link relationship (and possibly further p= arameters), these become part of the application state, hopefully together = with the provenance of that tossed document. That's an interesting thought. I guess, a fully self-contained document could then look a bit like this: Please register your resources with the resource directory at * But I don't fully trust it, so better only register your public resources (will of the device owner) * Also, the resource directory allows you to register only resources related to YetAnotherEcosystem (will of the RD owner) * To access the URI, you'll need to have an OSCORE security association with example.org * example.org has the RPK certificate h'...' (certificate pinning) * Please set up the security association using EDHOC at * But I don't want you to use any ciphersuite based on SHA-1 * To access the URI, you'll also need an authorization (bearer) token * Specifically, you need a token with the scope "Register YetAnotherEcosystem resources in a resource directory" * You can obtain the token using ACE from the authorization server at * Please connect to as.example using DTLS * Use these X.509 root certificates for that: ... * When you access the URI, you'll need to understand the CoRAL vocabularies 'coreapps.org:resource-directory' and 'coreapps.org:problem-details' This could even be part of a CoRAL document. For example, if server A serves a CoRAL document with a link to a resource on server B, then server A could tell the client what it thinks is server B's RPK. That would give the client immediately feedback if it's actually talking to the server that server A intended (rather than, for example, a server B that has changed ownership in the meantime). Of course, then the question is, how server B could update all the links on other servers pointing to it if it legitimately wants to change its keys, authorization policies, or CoRAL vocabularies... Klaus From nobody Mon May 24 11:13: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 669283A314A for ; Mon, 24 May 2021 11:13:41 -0700 (PDT) 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 epKf5VE0KqZE for ; Mon, 24 May 2021 11:13:36 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140070.outbound.protection.outlook.com [40.107.14.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34DB13A3148 for ; Mon, 24 May 2021 11:13:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iFnivJRgjZWpZ5m8/MZpjbjT9T64VarBaL79uJ/iAJZVt/ELFuf1uhnydTCy9Agk+U2tD7MI9pIqHpOy3SEbGZUaoY68m/Am0zY3Ks4vnQehRnqzMb30Cjae7PpRFWJ8BKAf1S8q6Y9ANy5xnsvhBbf63hC8P3JQarojY9Sb9PUGporlua9Rc8BkiPwVkZK3ZyNQoOiHysXmfKK2ihZpW/av5fpm5n0oulS1nVbiZcrRpoVW56/DRZGhB7VWBi8TGCDqn/ax/0aKgDCqxqfYqxGfVkBT5S9bmzJSG08YfbQPHc+zIgO6c+JUVSkz1s1wQy/XJVRpkXtmoSOD2w1bDg== 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=nhgVs12uSqIaG4/30+NDWYF3lwkXz4+kGKZF0faGnnU=; b=Sjh25x7mW6vhbLn/pcOPc9oUFMKqDZrIhO5XbMYB07E7KG+8cmZHDiMPJLC0izlmQ3C5DNFA89MYztoApR8NO573u2Fyval3MN5kxEcju/gWu99L1R20DsL3cSBr1E5bzyyGz/ESAjX7RY2VD3+8F9Xqgamxq42jq4kyHBgQ0EwQfwDP7Rc4zS/SaMZgkje782Uc97iUMjFEJJCxcWjIR+WVsNV/oqn7RWMZ+LbCVb/p/MyVO2vfzn7mVPw89MCAsmg4c1Hy/WzPrag1PgZC44RWR3yV3ixXX3pI5FOV2mppv89MWqA/RjbJuCj9nu130TuGC5f7m8ze4AFqvH+/eQ== 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=nhgVs12uSqIaG4/30+NDWYF3lwkXz4+kGKZF0faGnnU=; b=ZuMTQikISevrkM1chv084epXY6ezGpIVqTLk2K71D/QogZZRHMGmIc7AspSZHw5CK9XkXOtlXA6YBZ+prb4niSMvClr95VIwL8ODKbt/CdpnKHbF9QsKKJJ09brEEewgpVnbYuSSuc8E2EWoQTL+mKh3n58/C2x7vw49i487Sxg= 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 DB8P189MB1030.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:14b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.27; Mon, 24 May 2021 18:13:31 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1913:bcf7:e20a:a4e6]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1913:bcf7:e20a:a4e6%7]) with mapi id 15.20.4150.027; Mon, 24 May 2021 18:13:31 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: Date: Mon, 24 May 2021 20:13:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ILOR0ZKjuje0VvMQx5EUhOYuM5rJYeK1d" X-Originating-IP: [45.83.91.52] X-ClientProxiedBy: HE1PR0902CA0054.eurprd09.prod.outlook.com (2603:10a6:7:15::43) 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] (45.83.91.52) by HE1PR0902CA0054.eurprd09.prod.outlook.com (2603:10a6:7:15::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.23 via Frontend Transport; Mon, 24 May 2021 18:13:30 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 11994fe9-d6af-436b-3a9d-08d91edfa2e8 X-MS-TrafficTypeDiagnostic: DB8P189MB1030: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:1360; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OI5qiH1a/kDkMwLxxiBui7xFzQlPdSUstIk8AlTJYEotDyNsuNfSZlb55g1sDlHrrLB5cYxbhEQetKRGgp0xZiQe0UatBJEOqVwDMrbxBbXqVDqcUeM+F12dbOUgAFLTTlkpmviHbvzAOXIYoXKWjqelcz4cwEIVcECK3xEXCHk6cbqjrAr1PwJlzbUQ6y7xpe79JpnlB0QjyM7z/0s6VrxxP1gRucdeEulYruKmRsEe2OL721g3RDRYKFv/P7lAOKrUR7vpwH7kwBzensCdcoaQ3079/sawLtY6PFnaEehEXaeDE6cvDYj3YRk4gPWKN1qDAbkHW3DxC+uaikweGCjS9HUT2CcSvC2+payfiU8KGAWN2ckuMkZ4q2xkPOvc0azOovUGYs2n22HPu5Y+XZaoh7cGg43YXg7m4Rj8gR6rEsFO74fixruut32PG9TyLxanYccH4Pizkg4DoxBRDalvUdbEUZijjLy/DcLsBEoC20JKSC0FiIkTV0HsrTPZtcZ+zR8eUDZlT0NPlu4qQ7MCktJJ4usnmhmZFAm1VdKRs5eLUbG1B9QIAUtIM4bklQxKyBdg8QMIdgynaLXHixvmngTe+NEd10woWpMAJyGNCIJfoXMKxJmY6vXPdFdxJKK3zGZZQpB7GcMH28NudqREwrayKBXR37VTYyd7pMIfBsm03NoLzvymDqi76d9p3Lwm8TrBO87Cj1t+yhHDT5Hk5Ak3iSD+KZHqx4wrtJtyEv1ojvNwF7WugUWRGJcaq84YvkTIGs8bC7N0dg+CQFStDy/qIi9CC44jisivQBoYGvr/OhuOD2JYNMk24PRx 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)(136003)(39840400004)(396003)(376002)(21480400003)(44832011)(66476007)(66946007)(31696002)(6916009)(8936002)(966005)(83380400001)(31686004)(66556008)(956004)(86362001)(16526019)(66574015)(186003)(6486002)(2616005)(26005)(5660300002)(478600001)(38100700002)(16576012)(8676002)(36756003)(235185007)(33964004)(2906002)(316002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?WHU0eGdGRnlhLzB3UzNOODBtenVFOUNPeWJ6b1dVSytDL3pOYjJXSmlBWk5O?= =?utf-8?B?Q1RWSWp1a0JZK3dtMlNreXRHTytRZnhrNkp1a2VmWkNJc0VqMVJvclhEVU9P?= =?utf-8?B?SUljN1ZwMTZPbEVyWFBxWnNsY3NaOHpQV0M5SkNqaEZuWVNUYUt2eWUrTm14?= =?utf-8?B?b1ZISjY3Qy9XdkxreER4TDV4MTJCbFZlWVVnVitkVGxuc2k3cTdWM0pjcmxR?= =?utf-8?B?eDhsQUVwVnN0TmZrRjlPaVpNK09zUGNKS2JaWGxwUDNpays3Qy9PMUpVRDgw?= =?utf-8?B?QzEzLzFxYk04eXZvNlRpS1Nld2ZiS28xQ0l2eFhBVGQxTlNETlNEWnczY1U0?= =?utf-8?B?Ymc0cDdBVUVqZzQvVVhWQzF5RFVpdyt2RUZnRXFrZUxaL3J2d050NmpUSHF5?= =?utf-8?B?Qy9jdU8zWDhXU0hWUnZzUzZGQktqZWNGMnQxT0VZSU1kRHB6OEZkT3o1d1h3?= =?utf-8?B?cDFOWTRwOXpmbWcyVllONUlrbFJGVDluZURkMkRVOVB6cjlzNFBtR2VFVEZi?= =?utf-8?B?L2FhUVR5cHdWdW0rbEcwaHEyUTBCWnZUNGY5Y1BJMlhicDNPVk9tMnZMRlJs?= =?utf-8?B?ejNTV1Ftcm9PRlNYc292UmdQQU5JbWtUQ2hwTVFEY0lseDVMTU1uRmpKVXda?= =?utf-8?B?cWtXL2p0ZjF5UXJZRG1yeDJHaC9qQURvajdEU1pQci9samQxeG9yTFo1RjZY?= =?utf-8?B?Zk1rUmFEOEk5REVlaFlkSUg3MUtjdVB2OFNkUEZxcWVzdEJOTkh4NDhGSGJ1?= =?utf-8?B?UWt4Q0FsdXRsekNZNmtVTTltRUF4SkRSam5CYm9ZeFZ5WnJ5VHJaRnBqZDh0?= =?utf-8?B?Y052ZS9BaEpzTmk1VGc2anNML0UxNU9TSCttcndpQVVqMmlkNks5T1BobHdV?= =?utf-8?B?ZzZKMkdHeU0yWUYwSGpYLzlDL3Y5VXZzYjJjWEk1d3BhY2xQcHBkSDlCQmxF?= =?utf-8?B?dm50Um9RL0N4WDRSK2IxaElpMXIrendyeDBvb1RIOHBNUWVJL3dqNXgrRlBp?= =?utf-8?B?NXNKcXljWC9DdXVweUxpalpLVWhjRUtHZHIzTnJzVGlrNFJQdlJDNCtGM3RC?= =?utf-8?B?cDVmM0lnaFMwcnZOMmhFTDRNem9mVWNyckgzVHNHREV2dDRPSXgvNGxWQVdi?= =?utf-8?B?MmxpOHRZNXBUYUppTWV5djZQaTFMOFcxQ1krTVN1L0djSEt0dUZWeVdDS2RN?= =?utf-8?B?Z1BDb1YyaURTNnNmVzl1N0ZBcU5tM2JrZGVQRjhRQkR2em5Ud2hnTk4wY2VE?= =?utf-8?B?VU1JLzFOOVZTU3UvdndnNU9YRjV1dGpuWWV6dzlXUXRJR0xPeWp3aDV1cC9s?= =?utf-8?B?Sy9jMEVWb2NiZjIyYjdiZDNncENNUUttcm9STW4xd3JDc1ErdjkzTVZRY0pL?= =?utf-8?B?ZW53bWJ5eEZ5anRiY3lKWTlxRjF0d2VMUlZRZk5uQmNxRDJzUXJWQ2N2M1Br?= =?utf-8?B?WXNvZUlMWGZQeXA3ZTFjSlRWd2NUSFRld0d4M3NzREd1NVVqQmJXaVZmbUh6?= =?utf-8?B?UG43emNsNUpKT3ZVd3FUWU5Pa2xpV2FFUWZKRTc2RDVJaVhyOEJSYnpJU0Jr?= =?utf-8?B?SG5NcEZBTHI3aU1rMFdKcWdIbUdZUXRBNGJ4amVkVlcrWVF6b0xVMFJXMkhH?= =?utf-8?B?bzhmbXUzNVE4cFEvV0dYc3JkNzM0bnAwdDNrQU11ZEFCMVZSZlR6WENDcmxy?= =?utf-8?B?TXFFcTI5TzlUbmR5TlJuUUZnSDdMWGRxSVlzTmtkVUJqSmxqMVJYOG1uQ0pz?= =?utf-8?Q?tahN6sBGl7ycMRyc1cKYnR9uIN3s2LFzcSOTt6i?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 11994fe9-d6af-436b-3a9d-08d91edfa2e8 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 May 2021 18:13:31.0857 (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: ahd0U8gqZMDCO+DpuXb5r7xEx7GVdE1ZQPUtlWmp1BtfC2U5xmwgGp8j0PQ79OCK2lDlTR1dOpxrFBhv/sPpNg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB1030 Archived-At: Subject: [core] CoRE WG Virtual Interim 2021-05-26 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, 24 May 2021 18:13:42 -0000 --ILOR0ZKjuje0VvMQx5EUhOYuM5rJYeK1d Content-Type: multipart/mixed; boundary="tPrg37eIx4liCzuZHb1Ugv3Q6J18HcBly"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: [core] CoRE WG Virtual Interim 2021-05-26 --tPrg37eIx4liCzuZHb1Ugv3Q6J18HcBly Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that we'll have a virtual interim meeting on Wednesday,=20 May 26th at 14:00 UTC. The agenda and other pointers are available at [1]. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/interim-2021-core-06/session/cor= e --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --tPrg37eIx4liCzuZHb1Ugv3Q6J18HcBly-- --ILOR0ZKjuje0VvMQx5EUhOYuM5rJYeK1d Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmCr7MgFAwAAAAAACgkQ7iZktA5Y2kMH CQgAlQh3GZj1pyw4IC53MHD57pemvB5nMvqxU32c2lHL6G4Q1wPT9r+lRuSG1fw8L+OOwDtCNwHV pmiGo4n7lYSVuRBTZ6xc49YV+K90F+/C9nDsROB5aY/RhD7V2EJNMGSgEn+cVNWo6RjJwrkKkNvw bTwSCYF7GLQkKUGRgrd9Suly5lIDjKuCkMpFufxtpJAykpvefjqsmu/93V+oHu3V8uanyaL3HSZo ie1oqcTYsr02GnZ3CPr1ODWOJGWEPCELe5+fetPB5POOo/USPHyNiY2Vv+84NsRE7WZc8pJ3cnvT 6IYqPdUTgLQToYHZhjJyrbrVOPsncpMDgqUaoDa0Uw== =2QxL -----END PGP SIGNATURE----- --ILOR0ZKjuje0VvMQx5EUhOYuM5rJYeK1d-- From nobody Tue May 25 02:30: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 36D4F3A1E0D for ; Tue, 25 May 2021 02:30:33 -0700 (PDT) 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 dwxNMpj7DP9Q for ; Tue, 25 May 2021 02:30:27 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0948C3A1E07 for ; Tue, 25 May 2021 02:30:26 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7754E4073E; Tue, 25 May 2021 11:30:17 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 66A7F108; Tue, 25 May 2021 11:30:15 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [141.244.86.219]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 32629CD; Tue, 25 May 2021 11:30:15 +0200 (CEST) Received: (nullmailer pid 1749731 invoked by uid 1000); Tue, 25 May 2021 09:30:14 -0000 Date: Tue, 25 May 2021 11:30:14 +0200 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: Klaus Hartke , Carsten Bormann Cc: "core@ietf.org WG" Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Bl7awLLtwY1G8qht" Content-Disposition: inline In-Reply-To: <2D41F5BE-A83A-4C73-95D0-E2CD2B57FA5B@tzi.org> Archived-At: Subject: Re: [core] Tossing around URIs to use outside an application 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, 25 May 2021 09:30:33 -0000 --Bl7awLLtwY1G8qht Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Sat, May 22, 2021 at 02:44:32PM +0200, Klaus Hartke wrote: > In addition to secure usage, this came also up with respect to the > vocabularies used e.g. in CoRAL documents. I.e., if we need to pass > more than just a URI, such as security-related information, could we > also pass vocabulary-related information in the same way? Well we already *have* methods for hint-level metadata, as in ct=3D"0 40". (Not sure whether we'll want to use content format numbers there or something on a more detailed level, but I think it should be hint-level negotiation just the same, with multiple possible representations of a resource). > When a Web browser is tossed a URI, it's preconfigured with a set of > root certificates and a single purpose: Make a GET request to that URI > and render the resulting HTML document. In a CoREnvironment, there are > probably no root certificates and no predefined purpose. There may not be root certificates, but I think that the same semantics can still be applied: If someone requests, say, that a resource's representation be shown on a display, and gives the resource's name as "https://exmaple.com/logo.png" or "coap://example.com/logo.png", in both cases a PKI'd certificate is a sane default to provide. Sure, for most plain IP addresses, no such guarantee ca be made, but even that may not hold: If the IP address is part of a VPN, host authentication would be such a sane default. Similarly, "https://3g2upl4pq6kufc4m.onion/" is also self-contained in that any host that can access the resource can also make sure the server's identity is what whoever sent the URI intended. (Same goes for URNs, by the way: When someone hands over a blob and claims that to be identified by urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6b= f6 that can not be verified without more context. But nih:sha-256-32;53269057;b can be used to verify alleged representations). > At a minimum, you probably always toss a URI together with something > like "Your resource directory is at this URI" or "Please POST your > sensor data to this URI". Yes -- either (as Carsten observed) in a link relation, or by the precise point you place the URI. (Even if a system were not to work with link-format or CoRAL style links: If, on a thusly defined system, you PUT a plain URI to /2/0/1/3/2, that may *mean* "this is the resource to POST your sensor data to"). On Sat, May 22, 2021 at 10:09:04PM +0200, Carsten Bormann wrote: > If that document does contain a link relationship (and possibly > further parameters), these become part of the application state, > hopefully together with the provenance of that tossed document. On Sat, May 22, 2021 at 02:44:32PM +0200, Klaus Hartke wrote: > Additionally, you probably also need to configure some certificate/PSK > and the intents/wills of the stakeholders/principals involved. Maybe > some of that needs to be set directly, maybe some could be discovered > through a layer of indirection. Is there something we could > standardize here? Sure, the link relation is part of the document (or its context), but anything more should be as-necessary. I'd like to reach a point where you *can* add some information about the link (or the target?), but that'd be optional add-in because wherever it makes sense there are good defaults. These configurations may be separate even: Setting the address(es) of the light switches may be done by a different entity (say, an RD through which things are discovered) than setting the requirement that switching commands must carry this or that authorization. > That's an interesting thought. I guess, a fully self-contained > document could then look a bit like this: >=20 > Please register your resources with the resource > directory at > * But I don't fully trust it, so better only > register your public resources > (will of the device owner) > * Also, the resource directory allows you to > register only resources related to > YetAnotherEcosystem > (will of the RD owner) > * To access the URI, you'll need to have an > OSCORE security association with example.org > * example.org has the RPK certificate h'...' > (certificate pinning) > * Please set up the security association > using EDHOC at > * But I don't want you to use any ciphersuite > based on SHA-1 > * To access the URI, you'll also need an > authorization (bearer) token > * Specifically, you need a token with the > scope "Register YetAnotherEcosystem > resources in a resource directory" > * You can obtain the token using ACE > from the authorization server at > > * Please connect to as.example using DTLS > * Use these X.509 root certificates for > that: ... > * When you access the URI, you'll need to > understand the CoRAL vocabularies > 'coreapps.org:resource-directory' and > 'coreapps.org:problem-details' These are all good things to express. Most of these are all hint-level -- it's good to have all these in advance (saving long back-and-forths), but things should just as well work out if not (in the order as above, not in the order in which it would fail): * Trying to register anything outside of YetAnotherEcosystem would err with an understandable problem detail of "sorry wrong dictionary, use YetAnotherEcosystem" * Accessing the RD without EDHOC-initiated OSCORE would be Unauthorized and contain a hint as to the EDHOC resource. * Failure to use an ACE token (we don't have anything ACE+EDHOC yet, do we?) would result in 4.01 with an application/ace+cbor payload (which AFAIR can indicate the AS and necessary claims) * The CoRAL vocabularies should be indicated in the message in some way (like content-formats are; if you request without Accept and get something you don't understand, better request again). Of those that are not, I'm not sure they're best expressed here: * the "better only register your public resources" could be grouped with "register your resources" command * "No SHA-1" sounds like something decided per device, or part of the pinned certificate (we don't do hashes anyway without indicating the hash function). * Certificate pinning: If we don't mean example.org to mean "whoever has a good claim through DNSSec or PKI to example.org", maybe we shouldn't say example.org here, but use a named device identifier in the first place. (rdlink comes to mind, but so do all systems that influenced it, including Tor, IPFS and magnet URIs). Otherwise, what good is the URI in the first place? If it's only usable with metadata, we could just as well split it up into "contact the server resolved from example.org, require RPK this-and-that, use path "/rd" -- the URI alone has no value then any more, and I'm not ready to concede that point yet. (In particular, if any input vector of URIs can make conflicting requirements on their authentication properties, this defeats collaboration between components inside a system, as the URI is no usable cache key any more). BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --Bl7awLLtwY1G8qht Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmCsw6MACgkQOY0REtOk veFIghAAlUMNCscncdBr2Suf+U3WZQOsAKaK5UP5hecmBjOSXECb1IgAmEsjK+JC ZbjUkvzC5pWRPzUy65BruMYRlfCQRa9mX9O6Sbydx5O02FJh2QpQDUBi+BYFyOoX +66dZPh/0RancFTyxMdU4/a/4bJujIHmGNWgf3kXysiFcGE1m4P4iec48iCuRTYx wTgH5Ni+5MeLinpmG6GplpEJzcaOeYMV3jg1rlh76HnXHo6Cx2QupcVdv94aK10H FE7B3Nh3p7mI0d5P0OgYQo9LJ+hMrnaKbpuki4+ns8Gz8RAu6DmyrFi46FV9z3+F bJ6JPrKLBBuoXQ2uVnrrGwTjjOla5LV47FG4Ge/O6PN/V0gvO/VpJrODzOMvbykQ SHEy6tNCqGYxUluyUhesLFVSb8c27c5UEcyU2UcMEY8Um+vYgzTKzIfAH9ZZe2xt 2Xhof2xnGfGlULCMLzTHl8Qkf/1vP/MSl/Avkz6SNfUAc6dZ2W2Ib9aYcW1d6v6O j7Hv5RDjhHtzRSgjUFUIan79iA5hVYwyQ7Yk5p8RsBOZUlESM/52BFT+evdzDqwR jxGVhA4j4oSYD8IHy4Pv70sTgOKLINxKqtZS/Ayo+S8/iDEA2uYHYC9D5BGdR1T0 r7Klt4OS0NAl0rHZgeliWBkPUaogKVL2BXQ+cOu6dUA3fCQz7m0= =8xK0 -----END PGP SIGNATURE----- --Bl7awLLtwY1G8qht-- From nobody Tue May 25 05:15:23 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 7849B3A10CA; Tue, 25 May 2021 05:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 HZ4UVbBtHXLT; Tue, 25 May 2021 05:15:15 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 B02AE3A10C5; Tue, 25 May 2021 05:15:14 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4FqChJ6SQHz8vqb; Tue, 25 May 2021 14:15:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1621944912; bh=lTYis9eDp17asGy81lDPYthMQrdyCZy18SYEfqdsv3c=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=svXbwbIlDPpx6wzqZElaNqkvSdYDjcUxnsqLmBYyfIWHCeB0+s9y4BCYxSUHmORLk Y4rAnkhaMvGbpYrlb89C8zFZIK0wR5/RWL/HMqJYOWAMnvGlJHql5zNFj0X4kVwgJC 8tQiErrYIJW+bFKbQ2CChVGOPvDw+hl+d6TASZtv8+AKHM0qiHENCzEEQRRdk2+tZo 1gSKudF6+JQIKjUyGZFRVJ6X/1GXz6CG0IRIgbaLHelqRPPDp89qUC7H4CUw43mhuE paV51+LGnlDyrdr2ryAf5schR6rrCU7lHMMtUDo2XCtjtmduDIKB5qn0/OXmDu58J+ qjALr4jlfUePA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4FqChJ4XhNz5vN9; Tue, 25 May 2021 14:15:12 +0200 (CEST) From: To: Martin Duke , "supjps-ietf@jpshallow.com" CC: "core-chairs@ietf.org" , John Scudder , "draft-ietf-core-new-block@ietf.org" , The IESG , "core@ietf.org" , "marco.tiloca@ri.se" Thread-Topic: John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Thread-Index: AQHXQhCbJLPvcFdg/UKru2kURMqcWqrXeDkAgBPx5ACAAQGlMIAAmAIAgADwZ6CAAEEXAP//4bcAgAAsbMD///f2gIAACoAAgAAutwCABbJJoA== Date: Tue, 25 May 2021 12:15:11 +0000 Message-ID: <4815_1621944912_60ACEA50_4815_29_1_787AE7BB302AE849A7480A190F8B93303538E781@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net> <23771_1621516652_60A6616C_23771_79_1_787AE7BB302AE849A7480A190F8B93303538BB63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4833_1621600918_60A7AA96_4833_485_3_787AE7BB302AE849A7480A190F8B93303538C272@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <36A5A92C-AD99-4554-8A09-4E76E60BA98A@juniper.net> <17420_1621618028_60A7ED6C_17420_17_28_787AE7BB302AE849A7480A190F8B93303538C6AB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <093901d74e75$c21e6130$465b2390$@jpshallow.com> 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_787AE7BB302AE849A7480A190F8B93303538E781OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2021 12:15:22 -0000 --_000_787AE7BB302AE849A7480A190F8B93303538E781OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFydGluLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBmb2xsb3ctdXAuDQoNClBsZWFzZSBzZWUg aW5saW5lLg0KDQpDaGVlcnMsDQpKb24gJiBNZWQNCg0KRGUgOiBNYXJ0aW4gRHVrZSBbbWFpbHRv Om1hcnRpbi5oLmR1a2VAZ21haWwuY29tXQ0KRW52b3nDqSA6IHNhbWVkaSAyMiBtYWkgMjAyMSAw MDowMw0Kw4AgOiBzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tDQpDYyA6IEJPVUNBREFJUiBNb2hh bWVkIFRHSS9PTE4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBjb3JlLWNoYWlyc0Bp ZXRmLm9yZzsgSm9obiBTY3VkZGVyIDxqZ3M9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz47 IGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2tAaWV0Zi5vcmc7IFRoZSBJRVNHIDxpZXNnQGlldGYu b3JnPjsgY29yZUBpZXRmLm9yZzsgbWFyY28udGlsb2NhQHJpLnNlDQpPYmpldCA6IFJlOiBKb2hu IFNjdWRkZXIncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtY29yZS1uZXctYmxvY2stMTE6ICh3aXRo IERJU0NVU1MgYW5kIENPTU1FTlQpDQoNClRoYW5rcyBmb3IgaHVtb3JpbmcgbWUgYXMgSSB0cnkg dG8gdmVyaWZ5IHRoYXQgdGhlcmUgaXNuJ3QgYSBwcm9ibGVtIGhlcmUhDQoNCkkgdGhpbmsgd2Un dmUgY29sbGFwc2VkIHRoZSBwb3RlbnRpYWwgcHJvYmxlbSB0byBOT05fVElNRU9VVCBhbmQgTk9O X1JFQ0VJVkVfVElNRU9VVC4NCg0KU29tZSBzY2VuYXJpb3M6DQooMSkgTGV0J3Mgc2F5IHR3byBz ZW5kZXJzIHNpbXVsdGFuZW91c2x5IHNlbmQgTUFYX1BBWUxPQUQgYnVyc3RzIG92ZXIgYSByYWRp byBtZWRpdW0gdGhhdCBjYXVzZXMgdGhlbSB0byBpbnRlcmZlcmUgd2l0aCBlYWNoIG90aGVyLiBX aXRoIG5vIHJlc3BvbnNlIGZyb20gdGhlIHJlY2VpdmVyIGF0IGFsbCwgdGhleSBib3RoIHdhaXQg Zm9yIE5PTl9USU1FT1VUIGFuZCBzZW5kIGFub3RoZXIgYnVyc3QsIGNhdXNpbmcgdGhlIHNhbWUg ZWZmZWN0Lg0KDQpDYW4gdGhpcyBub3QgaGFwcGVuPw0KDQpGaXJzdCwgcGxlYXNlIG5vdGUgdGhh dCBzb21lIG5hdHVyYWwgcmFuZG9tbmVzcyB3aWxsIGJlIG9ic2VydmVkIGJ5IHBlZXJzIChpbmNs dWRpbmcgdGhlIGVmZmVjdCBvZiBwcm9iaW5nLXJhdGUgbG9ja2luZy91bmxvY2tpbmcgYW5kIHRy YWZmaWMgZXhjaGFuZ2UgcHJvZmlsZSBvZiBlYWNoIHBlZXIpLiBQbGVhc2UgcmVtZW1iZXIgdGhh dCBQUk9CSU5HX1JBVEUgaXMgZGVmaW5lZCBpbiBSRkM3MjUyIGFzICoqIGFuIGF2ZXJhZ2UgKiog ZGF0YSByYXRlIGxldCBhbG9uZSB0aGlzIGFzc3VtcHRpb24gaW4gdGhlIGFwcGxpY2FiaWxpdHkg c2NvcGU6DQoNCiAg4oCcQ29uY3JldGVseSwgdGhpcyBtZWNoYW5pc20gcHJpbWFyaWx5DQogICB0 YXJnZXRzIGFwcGxpY2F0aW9ucyBzdWNoIGFzIEREb1MgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIChE T1RTKSB0aGF0DQogICBjYW5ub3QgdXNlIENPTiByZXF1ZXN0cy9yZXNwb25zZXMgYmVjYXVzZSBv ZiBwb3RlbnRpYWwgcGFja2V0IGxvc3MNCiAgIGFuZCB0aGF0IHN1cHBvcnQgYXBwbGljYXRpb24t c3BlY2lmaWMgbWVjaGFuaXNtcyB0byBhc3Nlc3Mgd2hldGhlcg0KICAgdGhlIHJlbW90ZSBwZWVy IGlzIG5vdCBvdmVybG9hZGVkIGFuZCB0aHVzIGlzIGFibGUgdG8gcHJvY2VzcyB0aGUNCiAgIG1l c3NhZ2VzIHNlbnQgYnkgYSBDb0FQIGVuZHBvaW50IChlLmcuLCBET1RTIGhlYXJ0YmVhdHMgaW4N CiAgIFNlY3Rpb24gNC43IG9mIFtSRkM4NzgyXSku4oCdDQoNClNvLCB0aGUgZnVsbCBzeW5jIGNh c2UgdG8gaGFwcGVuIHJlcXVpcmVzIG1hbnkgY29uZGl0aW9ucyB0aGF0IG1pZ2h0IGJlIGRpZmZp Y3VsdCB0byBzYXRpc2Z5Lg0KDQpCYWNrIHRvIHlvdXIgcXVlc3Rpb246IElmIHRoZXJlIGlzICoq IGFueSByZXNwb25zZSAqKiAod2hpY2ggY2FuIGJlIGR1cmluZyBvciBqdXN0IGFmdGVyIHRoZSBz ZWNvbmQgYnVyc3QpLCBzdWNoIHJlc3BvbnNlcyB3aWxsIGNvbWUgc2VyaWFsbHkgb3V0IG9mIHRo ZSBzbG93IGxpbmssIHNvIGhhdmluZyBkaWZmZXJlbnQgdGltZXN0YW1wcyBhbmQgaGVuY2UgdGhl IHRoaXJkIGFuZCBzdWJzZXF1ZW50IHRyaWdnZXJlZCBidXJzdHMgb2YgdGhlIHNhbWUgYm9keSB3 aWxsIG5vdyBiZSBvdXQgb2YgcGhhc2UuIFRoZXJlIGlzIGFsc28gYSBjaGFuY2UgaWYgaml0dGVy IGlzIGFkZGVkIHRoYXQgdGhlcmUgbWF5IGJlIGEgdGltaW5nIGVxdWFsaXR5IG9uIGEgc3Vic2Vx dWVudCBidXJzdCBpZiB0aGUgaW5pdGlhbCBidXJzdCBpcyBjbG9zZWx5IGFsaWduZWQuDQoNCkhv d2V2ZXIsIGlmIHRoZXJlIGlzICoqIG5vIHJlc3BvbnNlICoqIGF0IGFsbCBvdmVyIG11bHRpcGxl IGJ1cnN0cyBvZiBhIGJvZHksIHRoZW4gdGhlIHNjZW5hcmlvIHlvdSByYWlzZSBpcyBwcm9ibGVt YXRpYy4NCg0KV2UgYWRkZWQgdGhpcyBub3RlOg0KDQogICAgICBOb3RlOiBSYW5kb21uZXNzIG1h eSBuYXR1cmFsbHkgYmUgcHJvdmlkZWQgYmFzZWQgb24gdGhlIHRyYWZmaWMNCiAgICAgIHByb2Zp bGUsIGhvdyBwcm9iaW5nLXJhdGUgaXMgY29tcHV0ZWQgKGFzIHRoaXMgaXMgYW4gYXZlcmFnZSks IGFuZA0KICAgICAgd2hlbiB0aGUgcGVlciByZXNwb25kcy4gIFJhbmRvbW5lc3MgaXMgZXhwbGlj aXRseSBhZGRlZCBmb3Igc29tZQ0KICAgICAgb2YgdGhlIGNvbmdlc3Rpb24gY29udHJvbCBwYXJh bWV0ZXJzIHRvIGhhbmRsZSBzaXR1YXRpb25zIHdoZXJlDQogICAgICBldmVyeXRoaW5nIGlzIGlu IHN5bmMgd2hlbiByZXRyeWluZy4NCg0KYW5kIG90aGVyIGNoYW5nZXMgdGhhdCB5b3UgY2FuIHNl ZSBhdDogaHR0cHM6Ly90aW55dXJsLmNvbS9uZXctYmxvY2stbGF0ZXN0Lg0KDQooMikgVHdvIHJl Y2VpdmVycyBzZW5kIGJ1cnN0cyB0aGF0IGFycml2ZSBhdCBhIGJvdHRsZW5lY2sgYXQgdGhlIHNh bWUgdGltZSwgY2F1c2luZyBjb25nZXN0aW9uIGxvc3Nlcw0KDQpUaGUgcmVjZWl2ZXJzIHdpbGwg cmVxdWVzdCBtaXNzaW5nIGJsb2Nrcywgd2FpdCBOT05fUkVDRUlWRV9USU1FT1VULCBhbmQgdHJp Z2dlciByZXRyYW5zbWlzc2lvbi4gRm9yIHRoZXNlIHRvIGFsc28gY29sbGlkZSwgdGhhdCB3b3Vs ZCBpbXBseSB0aGF0ICgxKSB0aGUgUlRUcyBhcmUgc2ltaWxhciwgYW5kICgyKSB0aGUgdGltaW5n IG9mIHRoZSBmaXJzdCBtaXNzaW5nIHBhY2tldCBzaWduYWwgaXMgcm91Z2hseSBzaW11bHRhbmVv dXMuDQoNCklzIHRoYXQgY29ycmVjdD8NCg0KQXMgdGhlIOKAmHJlcXVlc3QgbWlzc2luZ+KAmSBn b2luZyBiYWNrIHRvIHRoZSB0cmFuc21pdHRlcnMgd2lsbCBjb21lIG91dCBvZiB0aGUgc2xvdyBs aW5rIHNlcmlhbGx5IHdpdGggZGlmZmVyZW50IHRpbWVzdGFtcHMsIHRoZSB0cmFuc21pdHRlcnMg YXJlIHVubGlrZWx5IHRvIHJlc2VuZCB0aGUgbWlzc2luZyBwYWNrZXRzIGF0IHRoZSBzYW1lIHRp bWUuDQoNCldlIGRvIGhhdmUgdGhlIGZvbGxvd2luZyBpbiB0aGUgc3BlYzoNCg0KICAgSXQgaXMg bGlrZWx5IHRoYXQgdGhlIGNsaWVudCB3aWxsIHN0YXJ0IHRyYW5zbWl0dGluZyB0aGUgbmV4dA0K ICAgTUFYX1BBWUxPQURTX1NFVCBiZWZvcmUgdGhlIHNlcnZlciB0aW1lcyBvdXQgb24gd2FpdGlu ZyBmb3IgdGhlIGxhc3QNCiAgIG9mIHRoZSBwcmV2aW91cyBNQVhfUEFZTE9BRFNfU0VULiAgT24g cmVjZWlwdCBvZiBhIHBheWxvYWQgZnJvbSB0aGUNCiAgIG5leHQgTUFYX1BBWUxPQURTX1NFVCwg dGhlIHNlcnZlciBTSE9VTEQgc2VuZCBhIDQuMDggKFJlcXVlc3QgRW50aXR5DQogICBJbmNvbXBs ZXRlKSBSZXNwb25zZSBDb2RlIGluZGljYXRpbmcgYW55IG1pc3NpbmcgcGF5bG9hZHMgZnJvbSBh bnkNCiAgIHByZXZpb3VzIE1BWF9QQVlMT0FEU19TRVQuICBVcG9uIHJlY2VpcHQgb2YgdGhlIDQu MDggKFJlcXVlc3QgRW50aXR5DQogICBJbmNvbXBsZXRlKSBSZXNwb25zZSBDb2RlLCB0aGUgY2xp ZW50IFNIT1VMRCBzZW5kIHRoZSBtaXNzaW5nDQogICBwYXlsb2FkcyBiZWZvcmUgY29udGludWlu ZyB0byBzZW5kIHRoZSByZW1haW5kZXIgb2YgdGhlDQogICBNQVhfUEFZTE9BRFNfU0VUIGFuZCB0 aGVuIGdvIGludG8gYW5vdGhlciBOT05fVElNRU9VVCBkZWxheSBwcmlvciB0bw0KICAgc2VuZGlu ZyB0aGUgbmV4dCBNQVhfUEFZTE9BRFNfU0VULg0KDQpvcg0KDQogICBJdCBpcyBsaWtlbHkgdGhh dCB0aGUgc2VydmVyIHdpbGwgc3RhcnQgdHJhbnNtaXR0aW5nIHRoZSBuZXh0DQogICBNQVhfUEFZ TE9BRFNfU0VUIGJlZm9yZSB0aGUgY2xpZW50IHRpbWVzIG91dCBvbiB3YWl0aW5nIGZvciB0aGUg bGFzdA0KICAgb2YgdGhlIHByZXZpb3VzIE1BWF9QQVlMT0FEU19TRVQuICBVcG9uIHJlY2VpcHQg b2YgYSBwYXlsb2FkIGZyb20gdGhlDQogICBuZXcgTUFYX1BBWUxPQURTX1NFVCwgdGhlIGNsaWVu dCBTSE9VTEQgc2VuZCBhIHJlcXVlc3QgaW5kaWNhdGluZyBhbnkNCiAgIG1pc3NpbmcgcGF5bG9h ZHMgZnJvbSBhbnkgcHJldmlvdXMgTUFYX1BBWUxPQURTX1NFVC4gIFVwb24gcmVjZWlwdCBvZg0K ICAgc3VjaCByZXF1ZXN0LCB0aGUgc2VydmVyIFNIT1VMRCBzZW5kIHRoZSBtaXNzaW5nIHBheWxv YWRzIGJlZm9yZQ0KICAgY29udGludWluZyB0byBzZW5kIHRoZSByZW1haW5kZXIgb2YgdGhlIE1B WF9QQVlMT0FEU19TRVQgYW5kIHRoZW4gZ28NCiAgIGludG8gYW5vdGhlciBOT05fVElNRU9VVCBk ZWxheSBwcmlvciB0byBzZW5kaW5nIHRoZSBuZXh0DQogICBNQVhfUEFZTE9BRFNfU0VULg0Kd2hp Y2ggd2lsbCBhZGQgaW4gYW5vdGhlciBkZWdyZWUgb2YgcmFuZG9tbmVzcyBkZXBlbmRpbmcgd2hp Y2ggcGF5bG9hZCBnZXRzIHRocm91Z2ggdG8gdGhlIHJlY2VpdmVyLg0KDQpXZSBkb27igJl0IHRo aW5rIHRoYXQgYSBjaGFuZ2UgaXMgbmVlZGVkIGhlcmUgb3RoZXIgdGhhbiB1cGRhdGluZyB0aGUg cXVvdGVkIHRleHQgdG8gcmVmZXIgdG8gTk9OX1RJTUVPVVRfUkFORE9NIGluc3RlYWQgb2YgTk9O X1RJTUVPVVQuDQoNCg0KTWFydGluDQoNCk9uIEZyaSwgTWF5IDIxLCAyMDIxIGF0IDEyOjE3IFBN IDxzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPG1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cu Y29tPj4gd3JvdGU6DQpIaSBNYXJ0aW4sDQogTk9OX1RJTUVPVVQgaGFzIHRoZSBzYW1lIGRlZmF1 bHQgdmFsdWUgYXMgQUNLX1RJTUVPVVQgKFNlY3Rpb24gNy4yIG9mIHRoZSBkcmFmdCkuICBSRkM3 MjUyIFNlY3Rpb24gNC4yIOKAnE1lc3NhZ2VzIFRyYW5zbWl0dGVkIFJlbGlhYmx54oCdIGhhcw0K ICAgIEZvciBhIG5ldyBDb25maXJtYWJsZSBtZXNzYWdlLCB0aGUgaW5pdGlhbCB0aW1lb3V0IGlz IHNldA0KICAgdG8gYSByYW5kb20gZHVyYXRpb24gKG9mdGVuIG5vdCBhbiBpbnRlZ3JhbCBudW1i ZXIgb2Ygc2Vjb25kcykNCiAgIGJldHdlZW4gQUNLX1RJTUVPVVQgYW5kIChBQ0tfVElNRU9VVCAq IEFDS19SQU5ET01fRkFDVE9SKQ0KIEFzIG1lbnRpb25lZCBwcmV2aW91c2x5IGluIHRoaXMgdGhy ZWFkDQrigJwNCg0KUkZDNzI1MiBpbnRyb2R1Y2VzIEFDS19SQU5ET01fRkFDVE9SIGppdHRlciBh bmQgc2VwYXJhdGVseSBqaXR0ZXIgZm9yIG11bHRpY2FzdCByZXNwb25zZXMgKHdoaWNoIGlzIG5v dCByZWxldmFudCBoZXJlKS4NCg0KIFRoZSBBQ0tfUkFORE9NX0ZBQ1RPUiBpcyB0aGVyZSBmb3Ig d2hlbiByZS10cmFuc21pdHRpbmcgYSBwYWNrZXQgdGhhdCBoYXMgbm90IGJlZW4gYWNrbm93bGVk Z2VkIGZvciBzb21lIHJlYXNvbiBieSBpdHMgcGVlci4gTk9OX1RJTUVPVVQgaXMgZm9yIHdoZW4g dGhlIG5leHQgTUFYX1BBWUxPQURTX1NFVCBjYW4gc3RhcnQgdHJhbnNtaXNzaW9uIChub3QgcmUt dHJhbnNtaXNzaW9uKSBhc3N1bWluZyBhICdDb250aW51ZScgaGFzIG5vdCBhcnJpdmVkIGluIHRo ZSBpbnRlcmltLCBhbmQgc28gd2FzIG5vdCB0aG91Z2h0IG5lY2Vzc2FyeSB0byBhZGQgaW4gQUNL X1JBTkRPTV9GQUNUT1Igc3R5bGUgaml0dGVyIGhlcmUuDQoNCiBGb3IgTk9OX1JFQ0VJVkVfVElN RU9VVCwgd2hhdCBpcyBpbXBvcnRhbnQgaXMgdGhhdCBOT05fUkVDRUlWRV9USU1FT1VUIGlzIGdy ZWF0ZXIgdGhhbiBOT05fVElNRU9VVCAoV2Ugc2F5IGluIHRoZSBzcGVjIGEgbWluaW11bSBvZiBv bmUgc2Vjb25kKSBzbyB0aGF0IGEgcGVlciBkb2VzIG5vdCBmaXJlIG9mZiBhIHJlLXRyYW5zbWlz c2lvbiByZXF1ZXN0IGJlZm9yZSB0aGUgbG9jYWwgYWdlbnQgaGFzIGEgY2hhbmNlIHRvIHN0YXJ0 IHRvIHRyYW5zbWl0IHRoZSBuZXh0IE1BWF9QQVlMT0FEU19TRVQuICBOT05fUkVDRUlWRV9USU1F T1VUIGlzIGV4cG9uZW50aWFsbHkgc2NhbGVkIGZvciBlYWNoIHJldHJ5IHRvIG1ha2Ugc3VyZSB0 aGF0IHN0YWJpbGl0eSBpcyBwcmVzZXJ2ZWQuIFNvLCBhZ2FpbiwgQUNLX1JBTkRPTV9GQUNUT1Ig aml0dGVyIHdhcyBub3QgdGhvdWdodCB0byBiZSBuZWNlc3NhcnkgaGVyZS4NCuKAnA0KIERvZXMg dGhhdCBoZWxwPw0KIFJlZ2FyZHMNCiBKb24NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_787AE7BB302AE849A7480A190F8B93303538E781OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBI VE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuZ21haWwtbS03OTM3 NjA4MTc0ODE4NjIzMzk3bXNvcGxhaW50ZXh0LCBsaS5nbWFpbC1tLTc5Mzc2MDgxNzQ4MTg2MjMz OTdtc29wbGFpbnRleHQsIGRpdi5nbWFpbC1tLTc5Mzc2MDgxNzQ4MTg2MjMzOTdtc29wbGFpbnRl eHQNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8tNzkzNzYwODE3NDgxODYyMzM5N21zb3BsYWlu dGV4dDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uUHJm b3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhU TUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTWFydGluLA0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmsgeW91IGZvciB0aGUgZm9sbG93LXVwLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIHNlZSBpbmxpbmUuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Sm9uICZhbXA7IE1lZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTWFydGluIER1a2UgW21haWx0bzptYXJ0aW4uaC5k dWtlQGdtYWlsLmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBzYW1lZGkgMjIgbWFp IDIwMjEgMDA6MDM8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IHN1cGpwcy1pZXRmQGpwc2hhbGxvdy5j b208YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gJmx0O21v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20mZ3Q7OyBjb3JlLWNoYWlyc0BpZXRmLm9yZzsgSm9o biBTY3VkZGVyICZsdDtqZ3M9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZyZndDs7IGRyYWZ0 LWlldGYtY29yZS1uZXctYmxvY2tAaWV0Zi5vcmc7IFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3Jn Jmd0OzsgY29yZUBpZXRmLm9yZzsgbWFyY28udGlsb2NhQHJpLnNlPGJyPg0KPGI+T2JqZXQmbmJz cDs6PC9iPiBSZTogSm9obiBTY3VkZGVyJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWNvcmUtbmV3 LWJsb2NrLTExOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciBodW1v cmluZyBtZSBhcyBJIHRyeSB0byB2ZXJpZnkgdGhhdCB0aGVyZSBpc24ndCBhIHByb2JsZW0gaGVy ZSE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSB0aGluayB3ZSd2ZSBjb2xsYXBzZWQgdGhlIHBvdGVudGlhbCBwcm9ibGVtIHRvIE5PTl9USU1F T1VUIGFuZCBOT05fUkVDRUlWRV9USU1FT1VULjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21lIHNjZW5hcmlvczo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPigxKSBMZXQncyBzYXkgdHdvIHNl bmRlcnMgc2ltdWx0YW5lb3VzbHkgc2VuZCBNQVhfUEFZTE9BRCBidXJzdHMgb3ZlciBhIHJhZGlv IG1lZGl1bSB0aGF0IGNhdXNlcyB0aGVtIHRvIGludGVyZmVyZSB3aXRoIGVhY2ggb3RoZXIuIFdp dGggbm8gcmVzcG9uc2UgZnJvbSB0aGUgcmVjZWl2ZXIgYXQgYWxsLCB0aGV5IGJvdGggd2FpdCBm b3IgTk9OX1RJTUVPVVQgYW5kIHNlbmQgYW5vdGhlciBidXJzdCwgY2F1c2luZw0KIHRoZSBzYW1l IGVmZmVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Q2FuIHRoaXMgbm90IGhhcHBlbj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Rmlyc3QsIHBsZWFzZSBub3RlIHRoYXQgc29tZSBuYXR1cmFsIHJhbmRvbW5lc3Mg d2lsbCBiZSBvYnNlcnZlZCBieSBwZWVycyAoaW5jbHVkaW5nIHRoZSBlZmZlY3Qgb2YgcHJvYmlu Zy1yYXRlIGxvY2tpbmcvdW5sb2NraW5nIGFuZCB0cmFmZmljIGV4Y2hhbmdlIHByb2ZpbGUgb2YN CiBlYWNoIHBlZXIpLiBQbGVhc2UgcmVtZW1iZXIgdGhhdCBQUk9CSU5HX1JBVEUgaXMgZGVmaW5l ZCBpbiBSRkM3MjUyIGFzICoqIGFuIGF2ZXJhZ2UgKiogZGF0YSByYXRlIGxldCBhbG9uZSB0aGlz IGFzc3VtcHRpb24gaW4gdGhlIGFwcGxpY2FiaWxpdHkgc2NvcGU6PG86cD48L286cD48L3NwYW4+ PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjVwdCI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjVwdCI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IOKAnENvbmNyZXRlbHksIHRoaXMgbWVjaGFuaXNt IHByaW1hcmlseTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS41cHQiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyB0YXJnZXRzIGFwcGxpY2F0aW9ucyBzdWNoIGFzIEREb1MgT3BlbiBUaHJlYXQg U2lnbmFsaW5nIChET1RTKSB0aGF0PG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjVwdCI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGNhbm5vdCB1c2UgQ09OIHJlcXVlc3RzL3Jlc3BvbnNlcyBi ZWNhdXNlIG9mIHBvdGVudGlhbCBwYWNrZXQgbG9zczxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS41cHQiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBhbmQgdGhhdCBzdXBwb3J0IGFwcGxpY2F0 aW9uLXNwZWNpZmljIG1lY2hhbmlzbXMgdG8gYXNzZXNzIHdoZXRoZXI8bzpwPjwvbzpwPjwvc3Bh bj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuNXB0 Ij48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgdGhlIHJlbW90ZSBwZWVy IGlzIG5vdCBvdmVybG9hZGVkIGFuZCB0aHVzIGlzIGFibGUgdG8gcHJvY2VzcyB0aGU8bzpwPjwv bzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjUuNXB0Ij48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgbWVzc2Fn ZXMgc2VudCBieSBhIENvQVAgZW5kcG9pbnQgKGUuZy4sIERPVFMgaGVhcnRiZWF0cyBpbjxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NS41cHQiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBTZWN0 aW9uIDQuNyBvZiBbUkZDODc4Ml0pLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS41cHQiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5TbywgdGhlIGZ1bGwgc3luYyBj YXNlIHRvIGhhcHBlbiByZXF1aXJlcyBtYW55IGNvbmRpdGlvbnMgdGhhdCBtaWdodCBiZSBkaWZm aWN1bHQgdG8gc2F0aXNmeS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj5CYWNrIHRvIHlvdXIgcXVlc3Rpb246IElmIHRoZXJlIGlzICoqIGFueSByZXNw b25zZSAqKiAod2hpY2ggY2FuIGJlIGR1cmluZyBvciBqdXN0IGFmdGVyIHRoZSBzZWNvbmQgYnVy c3QpLCBzdWNoIHJlc3BvbnNlcyB3aWxsIGNvbWUgc2VyaWFsbHkgb3V0IG9mIHRoZSBzbG93IGxp bmssDQogc28gaGF2aW5nIGRpZmZlcmVudCB0aW1lc3RhbXBzIGFuZCBoZW5jZSB0aGUgdGhpcmQg YW5kIHN1YnNlcXVlbnQgdHJpZ2dlcmVkIGJ1cnN0cyBvZiB0aGUgc2FtZSBib2R5IHdpbGwgbm93 IGJlIG91dCBvZiBwaGFzZS4gVGhlcmUgaXMgYWxzbyBhIGNoYW5jZSBpZiBqaXR0ZXIgaXMgYWRk ZWQgdGhhdCB0aGVyZSBtYXkgYmUgYSB0aW1pbmcgZXF1YWxpdHkgb24gYSBzdWJzZXF1ZW50IGJ1 cnN0IGlmIHRoZSBpbml0aWFsIGJ1cnN0IGlzIGNsb3NlbHkNCiBhbGlnbmVkLiA8bzpwPjwvbzpw Pjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIGlmIHRoZXJlIGlzICoq IG5vIHJlc3BvbnNlICoqIGF0IGFsbCBvdmVyIG11bHRpcGxlIGJ1cnN0cyBvZiBhIGJvZHksIHRo ZW4gdGhlIHNjZW5hcmlvIHlvdSByYWlzZSBpcyBwcm9ibGVtYXRpYy4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UgYWRkZWQgdGhpcyBub3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuNXB0Ij48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTm90ZTogUmFuZG9tbmVzcyBtYXkg bmF0dXJhbGx5IGJlIHByb3ZpZGVkIGJhc2VkIG9uIHRoZSB0cmFmZmljPG86cD48L286cD48L3Nw YW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjVw dCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHByb2ZpbGUsIGhvdyBwcm9iaW5nLXJhdGUgaXMgY29tcHV0ZWQgKGFzIHRoaXMgaXMgYW4g YXZlcmFnZSksIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS41cHQiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aGVuIHRoZSBwZWVyIHJlc3BvbmRzLiZu YnNwOyBSYW5kb21uZXNzIGlzIGV4cGxpY2l0bHkgYWRkZWQgZm9yIHNvbWU8bzpwPjwvbzpwPjwv c3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUu NXB0Ij48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgb2YgdGhlIGNvbmdlc3Rpb24gY29udHJvbCBwYXJhbWV0ZXJzIHRvIGhhbmRsZSBzaXR1 YXRpb25zIHdoZXJlPG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO2V2ZXJ5dGhpbmcgaXMgaW4gc3luYyB3aGVuIHJldHJ5aW5nLjxvOnA+PC9vOnA+ PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YW5kIG90aGVyIGNoYW5nZXMgdGhhdCB5 b3UgY2FuIHNlZSBhdDo8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KPC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vdGlueXVybC5jb20vbmV3LWJsb2NrLWxhdGVzdCI+aHR0cHM6Ly90 aW55dXJsLmNvbS9uZXctYmxvY2stbGF0ZXN0PC9hPi48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+KDIpIFR3byByZWNlaXZlcnMgc2VuZCBidXJzdHMgdGhhdCBhcnJpdmUgYXQgYSBib3R0 bGVuZWNrIGF0IHRoZSBzYW1lIHRpbWUsIGNhdXNpbmcgY29uZ2VzdGlvbiBsb3NzZXM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHJlY2Vp dmVycyB3aWxsIHJlcXVlc3QgbWlzc2luZyBibG9ja3MsIHdhaXQgTk9OX1JFQ0VJVkVfVElNRU9V VCwgYW5kIHRyaWdnZXIgcmV0cmFuc21pc3Npb24uIEZvciB0aGVzZSB0byBhbHNvIGNvbGxpZGUs IHRoYXQgd291bGQgaW1wbHkgdGhhdCAoMSkgdGhlIFJUVHMgYXJlIHNpbWlsYXIsIGFuZCAoMikg dGhlIHRpbWluZyBvZiB0aGUgZmlyc3QgbWlzc2luZyBwYWNrZXQgc2lnbmFsIGlzIHJvdWdobHkN CiBzaW11bHRhbmVvdXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPklzIHRoYXQgY29ycmVjdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgdGhlIOKAmHJlcXVlc3QgbWlzc2luZ+KA mSBnb2luZyBiYWNrIHRvIHRoZSB0cmFuc21pdHRlcnMgd2lsbCBjb21lIG91dCBvZiB0aGUgc2xv dyBsaW5rIHNlcmlhbGx5IHdpdGggZGlmZmVyZW50IHRpbWVzdGFtcHMsIHRoZSB0cmFuc21pdHRl cnMgYXJlIHVubGlrZWx5DQogdG8gcmVzZW5kIHRoZSBtaXNzaW5nIHBhY2tldHMgYXQgdGhlIHNh bWUgdGltZS4gPG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGRvIGhhdmUgdGhlIGZvbGxvd2luZyBpbiB0aGUgc3Bl Yzo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBJdCBpcyBsaWtlbHkgdGhhdCB0aGUg Y2xpZW50IHdpbGwgc3RhcnQgdHJhbnNtaXR0aW5nIHRoZSBuZXh0PG86cD48L286cD48L3NwYW4+ PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgTUFYX1BBWUxPQURTX1NFVCBiZWZvcmUgdGhlIHNl cnZlciB0aW1lcyBvdXQgb24gd2FpdGluZyBmb3IgdGhlIGxhc3Q8bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBvZiB0aGUgcHJldmlvdXMgTUFYX1BBWUxPQURTX1NF VC4mbmJzcDsgT24gcmVjZWlwdCBvZiBhIHBheWxvYWQgZnJvbSB0aGU8bzpwPjwvbzpwPjwvc3Bh bj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBuZXh0IE1BWF9QQVlMT0FEU19TRVQsIHRoZSBz ZXJ2ZXIgU0hPVUxEIHNlbmQgYSA0LjA4IChSZXF1ZXN0IEVudGl0eTxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IEluY29tcGxldGUpIFJlc3BvbnNlIENvZGUgaW5k aWNhdGluZyBhbnkgbWlzc2luZyBwYXlsb2FkcyBmcm9tIGFueTxvOnA+PC9vOnA+PC9zcGFuPjwv aT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IHByZXZpb3VzIE1BWF9QQVlMT0FEU19TRVQuJm5ic3A7 IFVwb24gcmVjZWlwdCBvZiB0aGUgNC4wOCAoUmVxdWVzdCBFbnRpdHk8bzpwPjwvbzpwPjwvc3Bh bj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBJbmNvbXBsZXRlKSBSZXNwb25zZSBDb2RlLCB0 aGUgY2xpZW50IFNIT1VMRCBzZW5kIHRoZSBtaXNzaW5nPG86cD48L286cD48L3NwYW4+PC9pPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsgcGF5bG9hZHMgYmVmb3JlIGNvbnRpbnVpbmcgdG8gc2VuZCB0 aGUgcmVtYWluZGVyIG9mIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7IE1BWF9QQVlMT0FEU19TRVQgYW5kIHRoZW4gZ28gaW50byBhbm90aGVyIE5PTl9USU1F T1VUIGRlbGF5IHByaW9yIHRvPG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsgc2VuZGluZyB0aGUgbmV4dCBNQVhfUEFZTE9BRFNfU0VULjxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+b3I8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBJdCBpcyBsaWtlbHkgdGhhdCB0 aGUgc2VydmVyIHdpbGwgc3RhcnQgdHJhbnNtaXR0aW5nIHRoZSBuZXh0PG86cD48L286cD48L3Nw YW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgTUFYX1BBWUxPQURTX1NFVCBiZWZvcmUgdGhl IGNsaWVudCB0aW1lcyBvdXQgb24gd2FpdGluZyBmb3IgdGhlIGxhc3Q8bzpwPjwvbzpwPjwvc3Bh bj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBvZiB0aGUgcHJldmlvdXMgTUFYX1BBWUxPQURT X1NFVC4mbmJzcDsgVXBvbiByZWNlaXB0IG9mIGEgcGF5bG9hZCBmcm9tIHRoZTxvOnA+PC9vOnA+ PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG5ldyBNQVhfUEFZTE9BRFNfU0VULCB0 aGUgY2xpZW50IFNIT1VMRCBzZW5kIGEgcmVxdWVzdCBpbmRpY2F0aW5nIGFueTxvOnA+PC9vOnA+ PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG1pc3NpbmcgcGF5bG9hZHMgZnJvbSBh bnkgcHJldmlvdXMgTUFYX1BBWUxPQURTX1NFVC4mbmJzcDsgVXBvbiByZWNlaXB0IG9mPG86cD48 L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgc3VjaCByZXF1ZXN0LCB0aGUg c2VydmVyIFNIT1VMRCBzZW5kIHRoZSBtaXNzaW5nIHBheWxvYWRzIGJlZm9yZTxvOnA+PC9vOnA+ PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGNvbnRpbnVpbmcgdG8gc2VuZCB0aGUg cmVtYWluZGVyIG9mIHRoZSBNQVhfUEFZTE9BRFNfU0VUIGFuZCB0aGVuIGdvPG86cD48L286cD48 L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgaW50byBhbm90aGVyIE5PTl9USU1FT1VU IGRlbGF5IHByaW9yIHRvIHNlbmRpbmcgdGhlIG5leHQ8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyBNQVhfUEFZTE9BRFNfU0VULjxvOnA+PC9vOnA+PC9zcGFuPjwv aT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PC9zcGFuPjwvaT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPndoaWNoIHdpbGwgYWRkIGluIGFub3RoZXIgZGVncmVl IG9mIHJhbmRvbW5lc3MgZGVwZW5kaW5nIHdoaWNoIHBheWxvYWQgZ2V0cyB0aHJvdWdoIHRvIHRo ZSByZWNlaXZlci4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBkb27igJl0IHRoaW5rIHRoYXQgYSBjaGFuZ2Ug aXMgbmVlZGVkIGhlcmUgb3RoZXIgdGhhbiB1cGRhdGluZyB0aGUgcXVvdGVkIHRleHQgdG8gcmVm ZXIgdG8gTk9OX1RJTUVPVVRfUkFORE9NIGluc3RlYWQgb2YNCjwvc3Bhbj48L2k+PGk+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5PTl9USU1FT1VUPC9zcGFuPjwvaT48aT48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LjxvOnA+PC9vOnA+PC9zcGFuPjwv aT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1hcnRpbjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE1heSAyMSwg MjAyMSBhdCAxMjoxNyBQTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxv dy5jb20iPnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIE1h cnRpbiw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDtOT05fVElNRU9VVCBoYXMgdGhlIHNhbWUgZGVmYXVsdCB2YWx1ZSBhcyBB Q0tfVElNRU9VVCAoU2VjdGlvbiA3LjIgb2YgdGhlIGRyYWZ0KS4mbmJzcDsgUkZDNzI1Mg0KIFNl Y3Rpb24gNC4yIOKAnE1lc3NhZ2VzIFRyYW5zbWl0dGVkIFJlbGlhYmx54oCdIGhhczwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyBGb3IgYSBuZXcgQ29uZmlybWFibGUgbWVzc2FnZSwgdGhlIGluaXRpYWwg dGltZW91dCBpcyBzZXQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgdG8gYSByYW5kb20gZHVyYXRpb24gKG9mdGVu IG5vdCBhbiBpbnRlZ3JhbCBudW1iZXIgb2Ygc2Vjb25kcyk8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgYmV0d2Vl biBBQ0tfVElNRU9VVCBhbmQgKEFDS19USU1FT1VUICogQUNLX1JBTkRPTV9GQUNUT1IpPC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7QXMgbWVudGlvbmVkIHByZXZpb3VzbHkgaW4gdGhpcyB0aHJlYWQ8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJw8L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1t LTc5Mzc2MDgxNzQ4MTg2MjMzOTdtc29wbGFpbnRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj5SRkM3 MjUyIGludHJvZHVjZXMgQUNLX1JBTkRPTV9GQUNUT1Igaml0dGVyIGFuZCBzZXBhcmF0ZWx5IGpp dHRlciBmb3IgbXVsdGljYXN0IHJlc3BvbnNlcyAod2hpY2ggaXMgbm90IHJlbGV2YW50IGhlcmUp LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTc5Mzc2MDgxNzQ4MTg2 MjMzOTdtc29wbGFpbnRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDtUaGUgQUNLX1JBTkRP TV9GQUNUT1IgaXMgdGhlcmUgZm9yIHdoZW4gcmUtdHJhbnNtaXR0aW5nIGEgcGFja2V0IHRoYXQg aGFzIG5vdCBiZWVuIGFja25vd2xlZGdlZCBmb3Igc29tZSByZWFzb24gYnkgaXRzIHBlZXIuIE5P Tl9USU1FT1VUIGlzIGZvciB3aGVuIHRoZSBuZXh0IE1BWF9QQVlMT0FEU19TRVQgY2FuIHN0YXJ0 IHRyYW5zbWlzc2lvbg0KIChub3QgcmUtdHJhbnNtaXNzaW9uKSBhc3N1bWluZyBhICdDb250aW51 ZScgaGFzIG5vdCBhcnJpdmVkIGluIHRoZSBpbnRlcmltLCBhbmQgc28gd2FzIG5vdCB0aG91Z2h0 IG5lY2Vzc2FyeSB0byBhZGQgaW4gQUNLX1JBTkRPTV9GQUNUT1Igc3R5bGUgaml0dGVyIGhlcmUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNzkzNzYwODE3NDgxODYy MzM5N21zb3BsYWludGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwO0ZvciBOT05fUkVDRUlW RV9USU1FT1VULCB3aGF0IGlzIGltcG9ydGFudCBpcyB0aGF0IE5PTl9SRUNFSVZFX1RJTUVPVVQg aXMgZ3JlYXRlciB0aGFuIE5PTl9USU1FT1VUIChXZSBzYXkgaW4gdGhlIHNwZWMgYSBtaW5pbXVt IG9mIG9uZSBzZWNvbmQpIHNvIHRoYXQgYSBwZWVyIGRvZXMgbm90IGZpcmUgb2ZmIGEgcmUtdHJh bnNtaXNzaW9uDQogcmVxdWVzdCBiZWZvcmUgdGhlIGxvY2FsIGFnZW50IGhhcyBhIGNoYW5jZSB0 byBzdGFydCB0byB0cmFuc21pdCB0aGUgbmV4dCBNQVhfUEFZTE9BRFNfU0VULiZuYnNwOyBOT05f UkVDRUlWRV9USU1FT1VUIGlzIGV4cG9uZW50aWFsbHkgc2NhbGVkIGZvciBlYWNoIHJldHJ5IHRv IG1ha2Ugc3VyZSB0aGF0IHN0YWJpbGl0eSBpcyBwcmVzZXJ2ZWQuIFNvLCBhZ2FpbiwgQUNLX1JB TkRPTV9GQUNUT1Igaml0dGVyIHdhcyBub3QgdGhvdWdodCB0byBiZSBuZWNlc3NhcnkNCiBoZXJl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJw8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDtEb2VzIHRoYXQg aGVscD88L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDtSZWdhcmRzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Sm9uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9i b2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93303538E781OPEXCAUBMA2corp_-- From nobody Tue May 25 09:26: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 8C79E3A13F1; Tue, 25 May 2021 09:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLcOAbDemE6h; Tue, 25 May 2021 09:26:27 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150072.outbound.protection.outlook.com [40.107.15.72]) (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 2D3143A13EF; Tue, 25 May 2021 09:26:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V2KD4oZayGbNHYctvk0XsAVqdYSJJOW5kYiGnKJjcbKf3RWhsdPwHU72xDVXTuCap6EGRy4SCvNdgios1Q7/xhtc2G2bNFb4J4OGiXR8SP72kH9UurFfb8Ee6Ng7j5mmXQlq3QZe+3gBiwBKYUDZoKpJuPU5dX+g4u9+9QWxERq2QkNHpat3vjb+hMAfEYwK/Bcp2JaEpwsbkm0V+jB0bnDPVpAYsKOfhv52mz9W87oet7CsNDS8KVSd5lqgRm4mhAUjVcre17lTguC3jepUwEB6bvdHhGeuNiQCDnN+0uFmKx53cFSESvF0aUa6WOknHNe7i6KDynZbTAlpTd9WUA== 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=B39Q1DKqjdRlG0uANTFauz/LsM/cLVnDYPPybyk72t4=; b=RdLbOKdaedXD51J8PIFGInTWvCSDnpNWpGS51Q9GipE1WnUwRGux2y8qXLLYVJ8Sikrh3qpNxLEy1h04f7pe2YZKxvlkYshyEiFG1TSUAO5s0MKbAtTBz0dd74LPU8d7D7ZpzEsJptZUX/mDbnurOlyX1JHrzXaAYLs1KU93LWXYaHaViGS7zAzlsnxr1E5IIEXKHZei+4BytRuH+fjJzlkx/n1Cw3GwHAOT33eQNCouvF7RFRBWVCMdBAVPk5dYIJEqX5oPnoyMXEEa4x9WhFAWMTk3BJnaDKwmE4b7UEAhag/WfSCtdXaESDvY6M3f3DfeldyepCgcXrgGj3ts7A== 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=B39Q1DKqjdRlG0uANTFauz/LsM/cLVnDYPPybyk72t4=; b=UFdpf2xQsT2CcrIPxElcgVov2tGg9+LDzPIXP7V8e5RD2ke03YYGI3/qK3b2NRGUjoToMbbqFnpDoOgKu2ZTKqMxTlxqOPJPH2aKaAP28yS2BylkSNGkPPRdW961ohfpCYweNMUkETltrdo6BC0l53SdfOnqpzB+x0O/5QeVV0I= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR0701MB2092.eurprd07.prod.outlook.com (2603:10a6:3:20::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.13; Tue, 25 May 2021 16:26:24 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3%11]) with mapi id 15.20.4173.020; Tue, 25 May 2021 16:26:24 +0000 From: John Mattsson To: "core@ietf.org" , "TLS@ietf.org" , "lake@ietf.org" , "uta@ietf.org" , "spasm@ietf.org" Thread-Topic: Open source implementation of CBOR Encoded X.509 Certificates (C509 Certificates) Thread-Index: AQHXUYGE5UKBeIolhE6yCsbfZoKwmA== Date: Tue, 25 May 2021 16:26:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 30a57282-f4ad-4b7b-56bd-08d91f99d70d x-ms-traffictypediagnostic: HE1PR0701MB2092: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JjM0lPoguN7bkkrC+G0PoIkTPX73Tkq7xlIkbdVCpIS3vLbWbrHdKAgncoD5yPZ9ZPXJikdTkPGEoDROPaSL+vOfECHR3rrV7Y8zeNZRD7IKhiRwPImeDFr8RApeojxsnsmLjbQ9Ry45N4WsGpzzHKHJ2E7LadaAvayzZcewVXJy8CJ7BnDkw0gk8vLgLkZQEW7dfWDPa7uBVXF4AK8n6GKgHrTcGD3kjWaDcjwO7CKTRj1zB3k56N3LtKucpd5VMnnA1oD6QDE6K1TiTa+TDHKb+tERcu5RbY0lvJueBzBe97IS5ct+bBAjWKoYvXUc8AX1tx3L4wVWS4SCWvxVMZjZ+kIyID8PqBr3N+SmswOYhcAlyejpiTkLQFMYN20e6XI0czKYTED87anRX0l4aX3uM6wrq7o7Ac61D3Zydyy1v+bQWv/GyPmkuFG4W0pKIER5okBwQRpCR9jjeqRvCqc8dHaskCzT7i7HiEUr1pgiRbKWCrGE+SRGF7VvzzGGp+Se16AWjqbKNTllLA9/sYZWxNOxo4uR3d3oXvukgXOHbr2jMvtb65eKBfNbdGlTgzECB2aq2cC7VbxE+d0vLoSuODH9d6Z9hmZsUv3zUZPnGc2sj62qlFJa6aVmVLN6sye8nBblFt8jIDKqNfKj8EGWSXtdtfV0xZrY+mByxoJpDDlGMFzf4KAP3pzUVvIe/RjUQWH4H2Fi7pO815eSMA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(136003)(376002)(39860400002)(396003)(316002)(55016002)(9686003)(52536014)(110136005)(33656002)(122000001)(38100700002)(966005)(66476007)(6506007)(8676002)(66946007)(66556008)(64756008)(2906002)(76116006)(66446008)(7696005)(71200400001)(86362001)(26005)(450100002)(478600001)(186003)(8936002)(44832011)(83380400001)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?fnqq0NvaJWq+Jp4HlQ+Mq7LIParj8PQqeKMgQdaY1jxl+caSktaNN0VU/tEe?= =?us-ascii?Q?YnUlLYYLm1ZV+juDnw7iO6DrX8t59an7ZJ3OBshdpO7JFiyV8zUS38FLsVYU?= =?us-ascii?Q?vWKqycjxD3HdjMYB9i+BW/tsPu4CYTnzPTcckhHSdQllX3PIvLOYO0hFBcJ6?= =?us-ascii?Q?E23XeuyeDj+LwteEEISurvtRxzV6RADan1sop9VqOTLknKX9PtnESuShtQ/x?= =?us-ascii?Q?Wr2Ph7yhAqmAm9/43955QnrL2+/RrvV47VEhwF3cUrd6JoDvbPxWYPakr7KJ?= =?us-ascii?Q?BD89rfKzlTkBxl0wyb5E+QhDrPuXdi8Uq/f0hCUaeoohosgMFHbCX2zeuEf8?= =?us-ascii?Q?aeSVAcFZNbGudXMPsoY6O3UIiJVxeoa1hNsukiOeFyLgOpdCr+NEp4s0gKjK?= =?us-ascii?Q?TtTzBJHrPq2RZG9Nk6svsJRdjLcQDwfzGaR10EXQM+TZ0D98hP+XXYItMItC?= =?us-ascii?Q?zbiVczBSiV1fFx+WizaBlqVCu9JbnPLJ3fgrm48qPHhTAOaB1oIKv8W7gNKv?= =?us-ascii?Q?s3NHuC5hnapWwHuR+ozPGpRl2A/RMAvV/Xnxsfn1+ZzXZE6b3YpsJTl9pCxF?= =?us-ascii?Q?Jk4yDePwAgJRIzBIm3HuxjgonSsZSXWCE00OC76cUw9ovrQX9ThdZwgcb8W0?= =?us-ascii?Q?YD1JBG3ULyQM+FoDrJ2t2leUe2psNeB+eSPMUqwk0AO9Kw/8HzyoH4t2FJRo?= =?us-ascii?Q?6uK/G0qrbaohFlMDvMZYLSHEB5Ae8Ig5R3l1YZhN/SdCzv4GRNgzC/IDwsYm?= =?us-ascii?Q?kgZJH+qjKHbF6cYM4NwIWLzlp8Rcqlofj2YDkM3quRQCb+xoNPcwsqEIdaVk?= =?us-ascii?Q?dMh9Z63N4PksBB2vCRzijJtFCqeAJALh97tkP3RT0MMClRzJT6ApJ5hY+3ID?= =?us-ascii?Q?YtfE46mLwO1MiMILp9AWULnLHdZhfZ/v+iPcyiosAq0jrdpRZVkzPOYo6wkH?= =?us-ascii?Q?bTYRXp/9kdz4/2QXaPY6MzUXHDZ18UQceHnRCSuy+setR73dG4LSDpOZLKDa?= =?us-ascii?Q?NQnuxdCDRso7fzgi5mc5L283Yq+XQiXenD3ugPSF1041p9EswkoOcmXFb1xf?= =?us-ascii?Q?y2ArPkh9w8Dr2xBhs9cyxjdM3JDWIY9OvwsZm76xwoNrmcCayCbZmB3LYfZk?= =?us-ascii?Q?EgMo3sYz2kkGTQFNRRFKyMmpta4dIMA9zdbwCMP4/HL2wERBLdZK4kyS4VJq?= =?us-ascii?Q?v4bXJtSmndFf+rAVCSBvbOs+3EKacOPL1qFuOimYQos1GUG9DJHxFqeFk8Xg?= =?us-ascii?Q?GQW8h5Q6hW7Mp4vM96qXVPrufIV0mIA5czJ77VRP+Sch4j1axAgtEA2KtG4o?= =?us-ascii?Q?kKXEoY0RAuIe/df3i6yXuRMbzlazH7GdSSZpOKNSxrXDjQ=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB3050A74FF321033B5EBBDDAE89259HE1PR0701MB3050_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 30a57282-f4ad-4b7b-56bd-08d91f99d70d X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2021 16:26:24.7209 (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: mANa+g+G7T4XX0fYMleHW388FK0newfLJUb6lBVbXt/faOJlwfl8o/+sGR8DkSDzfx1cTCYFRRA2C0hAUVAzdpQHVuaEVqZKKy9ClQy6lP0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2092 Archived-At: Subject: [core] Open source implementation of CBOR Encoded X.509 Certificates (C509 Certificates) 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, 25 May 2021 16:26:33 -0000 --_000_HE1PR0701MB3050A74FF321033B5EBBDDAE89259HE1PR0701MB3050_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There has been a lot requests from people in different working groups for s= ouce code to try out C509 certificates. I just released my example implemen= tation of a DER X509 to CBOR C509 encoder written in Rust. CBOR encoded X509 (RFC 5280) is one of the main future work item for the CO= SE WG. C509 is specified as a CBOR encoding of the DER TBSCertificate seque= nce, which is then combined with a signature over the DER or CBOR encoding.= C509 can be used as a compression mechanism complementing RFC 8879, or as = a "natively signed" CBOR certificatice encoding still following RFC 5280. The Rust implementation supports reading a certificate from file or downloa= ding a certificate chain from a HTTPS server. The certificate chain is enco= ded to COSE_X509, COSE_C509, as well as TLS Certificate and CompressedCerti= ficate messages with X509 and C509. Size comparisions can be found in the d= raft. The Rust implementation can be found here: https://github.com/cose-wg/CBOR-certificates/tree/master/c509 The latest version of the draft: https://datatracker.ietf.org/doc/draft-ietf-cose-cbor-encoded-cert/ Please send comments and suggestions to core@ietf.org only, which is where = discussion should take place. Cheers, John --_000_HE1PR0701MB3050A74FF321033B5EBBDDAE89259HE1PR0701MB3050_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

There has been a lot requests from people in differe= nt working groups for souce code to try out C509 certificates. I just relea= sed my example implementation of a DER X509 to CBOR C5= 09 encoder written in Rust.

 

CBOR encoded X509 (RFC 5280) is one of the main futu= re work item for the COSE WG. C509 is specified as a CBOR encoding of the D= ER TBSCertificate sequence, which is then combined with a signature over th= e DER or CBOR encoding. C509 can be used as a compression mechanism complementing RFC 8879, or as a "nati= vely signed" CBOR certificatice encoding still following RFC 5280.

 

The Rust implementation supports reading a certifica= te from file or downloading a certificate chain from a HTTPS server. The ce= rtificate chain is encoded to COSE_X509, COSE_C509, as well as TLS Certific= ate and CompressedCertificate messages with X509 and C509. Size comparisions can be found in the draft.

 

The Rust implementation can be found here:

https://github.com/cose-wg/CBOR-certificates/tree/ma= ster/c509

 

The latest version of the draft:

https://datatracker.ietf.org/doc/draft-ietf-cose-cbo= r-encoded-cert/

 

Please send comments and suggestions to core@ietf.or= g only, which is where discussion should take place.

 

Cheers,

John

--_000_HE1PR0701MB3050A74FF321033B5EBBDDAE89259HE1PR0701MB3050_-- From nobody Wed May 26 02:59: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 ED3563A2888; Wed, 26 May 2021 02:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awiHNT9Y3EF7; Wed, 26 May 2021 02:58:49 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 97ED03A2879; Wed, 26 May 2021 02:58:48 -0700 (PDT) Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id A39AD600047; Wed, 26 May 2021 12:58:39 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1622023119; bh=UvVbk6itdI4gKEyloi3HUTWVUjeqJp+Ww/bUkg/Lkss=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=NkUHc8tMDKG8NKrIkFoeky3NsvQJwOXMK4MztdFoQShW2KZphoO2FkqIrAfXjLIj4 lBuYTIbzsyxRgfCqaF6N6j3y+OkH80pnwLTVthWLXAxeCKMScoNih3A9db1xk2Lq6g veD4BqmCzS4VCdnNrRhGrGRjD/8s+C01HdO1BDe0= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0F521FE0-CA28-4184-901A-545EA710896B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 26 May 2021 12:58:38 +0300 In-Reply-To: Cc: Elwyn Davies , draft-ietf-core-senml-versions.all@ietf.org, last-call@ietf.org, General Area Review Team , core@ietf.org To: Carsten Bormann References: <162006820882.8146.574742678195359661@ietfa.amsl.com> X-MailScanner-ID: A39AD600047.A219A X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [core] [Last-Call] Genart last call review of draft-ietf-core-senml-versions-02 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, 26 May 2021 09:58:54 -0000 --Apple-Mail=_0F521FE0-CA28-4184-901A-545EA710896B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Elwyn, have you had a chance to check whether the -03 version of the I-D = addresses your review? Thanks, Lars On 2021-5-9, at 22:51, Carsten Bormann wrote: >=20 > Hi Elwyn, >=20 > I finally got around to process your review. >=20 > I have submitted a new version -03 based on this review. > I could make direct use of your text suggestions, but did edit them a = little. > So you may want to have another look at the second paragraph of 1 = (introduction) and the new section 2.2, which address your main points. >=20 > https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ > https://www.ietf.org/archive/id/draft-ietf-core-senml-versions-03.html > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-versions-03.txt >=20 > That was a great, thoughtful review. > Thanks again! >=20 > CoRE WG: Please also check the above documents and diffs! >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On 2021-05-03, at 20:56, Elwyn Davies via Datatracker = wrote: >>=20 >> Reviewer: Elwyn Davies >> Review result: Almost Ready >>=20 >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >>=20 >> For more information, please see the FAQ at >>=20 >> . >>=20 >> Document: draft-ietf-core-senml-versions-02 >> Reviewer: Elwyn Davies >> Review Date: 2021-05-03 >> IETF LC End Date: 2021-05-03 >> IESG Telechat date: Not scheduled for a telechat >>=20 >> Summary: Almost ready. There is one issue that needs to be sorted = out. This >> document removes the ordering relationship between the values of = version.. >> Section 4.4 of RFC 8428 relies on that ordering relationahip. = Accordingly >> there needs to be explicit new text for Section 4.4 in this document. = Also the >> concept of 'must understand' items is used in this document but is = not >> explicitly defined in RFC 8428. This needs to be fixed - which could = happen in >> the new version of Setion 4.4. >>=20 >> Major issues: >> None >>=20 >> Minor issues: >>=20 >> The redefinition of version means that this document should contain = an explicit >> update of (at least) paragraph 3 of Section 4.4 of RFC 8428, That = section >> assumes that there is an ordering relationship between version field = values >> which is invalidated by this document. >>=20 >> Also the concept of 'must understand' fields is supposed to be = explained in >> that section as well as discussed in s2.1 of this document. That = term is not >> explicitly used in RFC 8428 but I take it that it is supposed to = refer to field >> names ending wth an underscore character ('_'). This should be fixed = with a >> rewrite of s4.4 of RFC 8428. >>=20 >> Nits/editorial comments: >>=20 >> General: The RFC Editor preferes the US convention for quoting items = using >> exclusively singe quote rather than double quote marks. >>=20 >> s1, para 2: I found this paragraph difficult to parse, especially = the second >> sentence. Here is an alternative suggestion. OLD: The traditional = idea of >> using a version number for evolving an interchange format presupposes = a linear >> progression of that format. A more likely form of evolution of SenML = is the >> addition of independently selectable _features_ that can be added to = the base >> version (version 10) in a fashion that these are mostly independent = of each >> other. A recipient of a SenML pack can check the features it = implements against >> those required by the pack, processing the pack only if all required = features >> are provided in the implementation. NEW: The traditional idea of = using a >> version number to indicate the evolution of an interchage format = generally >> assmes an incremental progression of the version number as the format = develops >> over time. However in the case of SenML it is expected that the = likely >> evolution mechanism will be for independently selectable capabiity = _features_ >> to be added to the basic system indicated by 'version' 10. To support = this >> model, this document repurposes the single version number = accompanying a pack >> of SenML records so that it is interpreted as a bitmap indicating the = set of >> features a recipient would need to have implemented to be able to = process the >> pack. ENDS >>=20 >> s2: Personally I would have used the left shift operator rather then = 2^fc but >> that is a personal view. >>=20 >> s2,1, para 2: s/lower-most bit positions Section 3./least significant = bit >> positions for the base version as described in Section 3./ >>=20 >> s2.1, para 2: s/Section 4/by the feature defined in Section 4/ >>=20 >> s2.1, para 2: 'boutique' is slang: s/boutique/less generally = applicable/ >>=20 >> s3: s/already/effectively already/ >>=20 >> s6: I am not we really care but are feature names case sensitve? >>=20 >>=20 >>=20 >=20 > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --Apple-Mail=_0F521FE0-CA28-4184-901A-545EA710896B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmCuG84ACgkQVLXDCb9w wVfRWg/9G6W6BPNEAl2ZzvfhSfawMvbm3OkP1pY6tyGV4NvHHxFkko+O+bv/BvaS Ik8Al066rUyQHTUKyWmZD0zu9lpLU/7eKkDTLsBFwSCsTb5s/I6M/gZK0zf6mkQ7 aShtjayjdygalpM4IXF2pWlwiFPb7BFYUkIkKQm2KO7i7mTlRRQU/z/kdFbJ+5It YQV6wD2BeBEgWsX7YsLekjcfwsLtv641yyp+XQ3b9jRrRBh0LTVLK+gAWemZHjEH zC1KzKXw1onmg1FaXyGHyUHVLTzc5aZ3E++s4LFYLxE5JfbaQY2+NRwzQnmtvs/p PvzqPVLVZUoh41/G24iOmM9bG6spr1no3LaFc0RwHPXl9u0g7cOuLjPPmgetd/NC aTSS7/1NhdmMJwkIwT9QQOYtDjRS5kXe8n98FeLZ90NRnovEiu4JRoNSsXyPJCu/ blunpBsKL3+FpdEZX3aoIlXdu8fzqkQ40XDMqL1B2YCyHGtCxYvR2lf9HQmC77yu 8btWQ/K5BQxGkoGwvk7KLo57WAE4YxXdCcTQ6f9q4IuiKmiGToE99IDLaNHJAV34 y0hSw4Fk5B8J4QYZyHeMepglYqzhNzDdFU7X0cgzCiHP6NcubhG6r9r6oVvdDPD5 QX/USgpsMS9VP1iUxs+hkBmLGMUKvGRqbsS86x6I2FJ43Fetx1s= =7DEU -----END PGP SIGNATURE----- --Apple-Mail=_0F521FE0-CA28-4184-901A-545EA710896B-- From nobody Wed May 26 05:02: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 BDF003A2C12 for ; Wed, 26 May 2021 05:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_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 rseapV1oIzLd for ; Wed, 26 May 2021 05:02:50 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2063.outbound.protection.outlook.com [40.107.22.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 17D183A2C0B for ; Wed, 26 May 2021 05:02:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lmcmGS20S6/n4F1AqofhzEKAJ/hEV52H6OQCD7ofE+g48pxwkZncvqxYsSLt+ZxCNg9TUcXFP1ESVKJrbD9+ZjYJfFi200IDdQ0cheuf9ziSBJ3Zd2bjgvdwm0K7cMj2HFQolH8nxDtxu6Mo5hkH00DUBXIO3tStrX0Rb0Ol9jthLlQiVrk9TkvU24YGCASPssnrVFEXIpO3q/uAS8UIDs4/SV9HvwN6WskXKS2AtLLq4G4iAjVJg9/8k01+rjg3tHzR2e/tpeEtXYKPTFB/AV9KO6t5/UrFlF6xiu0Ejx8tUALYgyjXx6jgNJ6XXXyZmVdbmdraXYut9vqaEG6dNg== 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=aCGf1chRNTuhA5dVQAuDWvBg7ldKUbWA70igqOPnKoQ=; b=SN5gtfxKx0BkPTbAsGGPi3G567/X6aaRStP/s4Rnsh06uwbywk8IhwcHgL6SnmRhkBnpdgmu63rx0ZHdPyb296kY7p1AempJ7mqACP0vitLV1RWuMtIYASMZsyeDMonmEfqgFzkIVUTWpF5DjZ3RctMQx2iwfQtfPbOiHjL/5ZduODBtoKYgYEievglWyErktpXGFMoq/M2yTPrFV/NR57OQfsQJ0x+yIg4ZeiDsHjKpPzdmdWmCIO5/8sx+n4JQGwuiflBN5FaM0fjl/KYlD0vGQ3X0TVoN6UVn1oTZW2CFzfd08Kh2CQNSVmY3xaqF8KXK9qmD+/4/HvSoOIYyhA== 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=aCGf1chRNTuhA5dVQAuDWvBg7ldKUbWA70igqOPnKoQ=; b=Kny4g1VjVFlbjQpyh0bBAL7KvtjXF3SvgaNKCOW8WHSecqvh0KCu9m/ef3Pb65CML6mOwxMQv6y/2IgNUjRrFdP+SOaLBV8nVbSHQdwSF15On0OhkCw84r2Z9QH6pxe9In1E9HHD3R6RUErHwcgavqEvQdx17/CtCUWIL4ifGhM= 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 DB8P189MB0967.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:166::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.20; Wed, 26 May 2021 12:02:46 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1913:bcf7:e20a:a4e6]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1913:bcf7:e20a:a4e6%9]) with mapi id 15.20.4173.020; Wed, 26 May 2021 12:02:46 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: Message-ID: Date: Wed, 26 May 2021 14:02:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rZx6H9Me385t4qIhqgfdWGHb62b9FgxvB" X-Originating-IP: [45.12.220.196] X-ClientProxiedBy: HE1PR0401CA0117.eurprd04.prod.outlook.com (2603:10a6:7:54::46) 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.5] (45.12.220.196) by HE1PR0401CA0117.eurprd04.prod.outlook.com (2603:10a6:7:54::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.20 via Frontend Transport; Wed, 26 May 2021 12:02:45 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: de8a3a63-4103-493c-2808-08d9203e2ca3 X-MS-TrafficTypeDiagnostic: DB8P189MB0967: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:1013; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: wBR5GviPe0mlOSLMkdAaPcgHf0phpsg9qRGeem4hxsF6icZnWuncukRC9CLJbZWpGNTkL+5/NKQJiLWyJy4C3wm4E7FHWYH2j85Dot73F06zU+DTbAn6s6i1g/NjZFuh87GtmSTSMxVd87uWwAuqTwZsWZmdcoQ9nJ6AbC5SNhVEog/9GovoWsMviO4/MF/WAvWkMnRfaVs3NDwYpSdPe2BEpZwcDKX5EJsicKUyvF0b7SVk99vMhVCF0pGvIvgOFguBuy6fN+6WfKacRAOEXy2ATUG0yOzVLBWvlRwrf/nJA9tTjKjhJSRYVfHnGNwLWhvOiZ2NFnUfXWRoRT6Uv3SIKM1ad5dmLNMK6NlICN/93cBc1SQ5IyrasYOKB+Lpc75SsJejoxmFj6K88mvM0iI4sEsWaa4JlUNi+RIh/Bx6AtXFKahRvdEuxjRkrvlhiGozg3SoqyHWCtqcsHacxOojeHaJvN7QWQuxqUJfr0eeSuW7aueP7ukCr6Gx0g+0vl/ZEn0zubTnOubW40z2TqwSp3rFO2lPb67KMrFEBISG4Ew3fa1RpZbtXqv69yWx+1xq+HRJ8M8vFvJFnIHF6l+xsz2k/AUqUf4Qgr9rer4pbEado/Qbpxg521sgreaMOlqfRWqSOKbqvc17ebHntymu7y7+rSbsFrkS4Zoua5caZZVmTYwY1TptlYOTOwK8F/0EBFX8fkGBB6xijvjFz/M+l6fdfVTXSylb9yJtrwDpIc/+oyr3sW44veoBvH2+f9AY5nYNsqkXysRxXXXcGVRSg2TVwHp3Dz7DsFWtFh8= 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)(376002)(396003)(136003)(346002)(366004)(86362001)(2906002)(53546011)(235185007)(83380400001)(31686004)(6916009)(6486002)(5660300002)(38100700002)(31696002)(6666004)(33964004)(316002)(44832011)(66556008)(21480400003)(8676002)(66946007)(16799955002)(186003)(478600001)(26005)(16526019)(66476007)(66616009)(966005)(66574015)(2616005)(956004)(8936002)(16576012)(36756003)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?Q2V6aTZDdHYwYkN4UHJuUXVXeGFSelBNM1lQelZ2bHkxZDM2eUJ2YmJnZDI3?= =?utf-8?B?cVRDSmRtb2JHeWtZRWhKSGErb2RZNzJPWGpxaWVNdm4xcGlsVVhsVnY3b0d2?= =?utf-8?B?clZaSWFXSm91VzI1UVlTcUhRU0dFQ2lWMWhHZU1jSGdua3A2YmtkbkdUOGxH?= =?utf-8?B?dXB5UDRHbWtTamUvM1F5RDRabmlPTGFtVENad1AwOGxZdVBaVVRLQkh5TENT?= =?utf-8?B?eEtLTkpiV2VYaEVjbnUyTm1QK3F5bTNNeDNNL0pMYXdSYzQ4eEVBanNSVWlI?= =?utf-8?B?VHM5ekVmQ1F0dVBVLzRiYjFZTVZGYWVOWnMvZXBORDJ6OTlDcDFmSlNtak5R?= =?utf-8?B?MXVkcU9iblppWU1Yb3EzQkliM0xhSmFsaHJpSlo1RWV1MWtkL2RIYkd5ME5N?= =?utf-8?B?ZlNVL1ltaVNlS2t6ZEl6YkhnM0hjVU1aeVhvZEVPZkhSL2VKaXUyb1E2cDJm?= =?utf-8?B?NVJtOFhHcnpGdGc1TkVibkZaN096VG1lYmYyNUUxVkh2T1JBeWF5THAvZWVF?= =?utf-8?B?SmdHVXVsOEI4Qm5veEdxVjB3S3ZYQTNsR2hCeWlQMko4Q1F6Rk5vQmtYSlBl?= =?utf-8?B?YkRVaUI3U0ROU0pwbUwwNUNJQlFJUzhrL3pLMHRBK05iK1RCRHB5aHBNeXlK?= =?utf-8?B?Z05OY1F5bUlLbGRkK0VCM25qdFo1eGZzRHJ6K0lWd3pBODEveUw3UmtOYXV4?= =?utf-8?B?VDBhQ1IvUVd1OE9PbTkzT1dGcHMyMkZkb2ZnaHdsako3NFhDRDgyMjBoMzh4?= =?utf-8?B?bXVybXVtWnA0dkVHNXV3ZWVGeWFDUFYvL2loN2dlWVRHRHZ3VFg2M1Z3WFZF?= =?utf-8?B?aTBCeWs0T2ZMc2tXNnk3VittN1NhSHNobFFHdVNIS3poZk9IdmZwZklPVURp?= =?utf-8?B?M3N1dzdHVVNTQ25WQU5WOUFiTFF1VWdsMkRuaTlvV0txRlhjSENBaFgwZE14?= =?utf-8?B?ZFp6RUU1SFhiSTRMRDlZUTd3SmVrWnd5Tk11bDU2UktmcjVHbWsrSWJHaklC?= =?utf-8?B?bGxKODFVek1maUY0SVhqK0Y2Q3kwaFBoNWdEV1pXaTlveFdBRDBUOW1BVGlL?= =?utf-8?B?QlpBSGVvQi92RlU5ZElSYWluT1hnemlJa2NmYThVeElkVFZyTklxaVBkVVNk?= =?utf-8?B?S0pWZzBhUzVRcWVRZjVOUFlIc05abDZKdnRJcEpncTJMV254UXpMclhtUTI4?= =?utf-8?B?cjkvcHpVQ1d1dE5LRWFadGxoMXJ5NGJYZmd3UkY4ZzM3TnJmWlBnTzQ4TEFB?= =?utf-8?B?STNSV3B3dDhiMWZKZmVoUkdBM2tjdEZhYzdjOGxaY3Z3UGdSYVNwZ2JseTE5?= =?utf-8?B?dmUyUWkwdlc0aXUzTlZ4MDVyKy9DdmxDOXpwQ3VnRDJkODlyTk91WEpnTXJl?= =?utf-8?B?b0s5UnRvdnVKMkhOUUI2TnlQQXB3SUNzVStzUEdUUTVvbDJIRktCSVpsOXdI?= =?utf-8?B?VEljc3ZHcExsSWZzbU03cmhPVTBzK3hvR0RWcWNQQVptYmtJeWRsS2kwclNo?= =?utf-8?B?MEZXVWtoejlldFZpTGg4N0IrK1FFK1UvOVQ3ZVlXTEUyZHJkYzJwcTExQ2hK?= =?utf-8?B?bU1MSGc5UW9BdEJnVDRNamlzenZPL2lXVW9tYWVReE4zbGZJN2FON2RnZTlK?= =?utf-8?B?cVdlOFB0TUxhVjBXTmU0bTRvYTlLd0M1UWxBYTJFSlJFUm1FVGtPTzQ1a2oz?= =?utf-8?B?NjR0K3M1NnZEMFFFbmRrdG5vZ210bjhNbjk2dFNRcXZKaTI0RmtacFlJdGpm?= =?utf-8?Q?bXwcTWaQq60IEf6XPWjqaPfwwjfHY2GTjY68sJA?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: de8a3a63-4103-493c-2808-08d9203e2ca3 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2021 12:02:46.1374 (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: z/OIyCtK9n2dUe+fbUsW4OL6FgOiVbEhQ5Djk1DFShVYJepSybILYDD/wezNb4LSukclZnof/dlv2M/DL/175Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0967 Archived-At: Subject: Re: [core] CoRE WG Virtual Interim 2021-05-26 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, 26 May 2021 12:02:56 -0000 --rZx6H9Me385t4qIhqgfdWGHb62b9FgxvB Content-Type: multipart/mixed; boundary="BQMfMingheZ8E6ewXYk2cupVLL6bJHaF6"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: Re: [core] CoRE WG Virtual Interim 2021-05-26 References: In-Reply-To: --BQMfMingheZ8E6ewXYk2cupVLL6bJHaF6 Content-Type: multipart/mixed; boundary="------------6B8E84034DC0EEEDEE8464D4" Content-Language: en-US This is a multi-part message in MIME format. --------------6B8E84034DC0EEEDEE8464D4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Dear all, Just a reminder that we are having our virtual interim meeting in=20 slightly less than 2 hours [1]. Please find below the information to join. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/interim-2021-core-06/session/cor= e =3D=3D=3D Meeting Information =3D=3D=3D Jabber: core@jabber.ietf.org Etherpad: https://codimd.ietf.org/notes-ietf-interim-2021-core-06-core Meeting link:=20 https://ietf.webex.com/ietf/j.php?MTID=3Dmba8c947cd147f3335a5455cfbcc067d= c Meeting number: 185 992 1344 Password: constrained More ways to join Join by video system Dial 1859921344@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: 185 992 1344 On 2021-05-24 20:13, Marco Tiloca wrote: > Dear all, > > Just a reminder that we'll have a virtual interim meeting on=20 > Wednesday, May 26th at 14:00 UTC. > > The agenda and other pointers are available at [1]. > > Best, > Marco and Jaime > > [1]=20 > https://datatracker.ietf.org/meeting/interim-2021-core-06/session/core > --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --------------6B8E84034DC0EEEDEE8464D4 Content-Type: application/pgp-keys; name="OpenPGP_0xEE2664B40E58DA43.asc" Content-Transfer-Encoding: quoted-printable Content-Description: OpenPGP public key Content-Disposition: attachment; filename="OpenPGP_0xEE2664B40E58DA43.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Za= RDP C4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt0G4Ck= Unq 5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0Kh1T4WUW6= NHf EWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+NrSetJlljT0QO= XrX MGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEBAAHNJ01hcmNvIFRpb= G9j YSA8bWFyY28udGlsb2NhODRAZ21haWwuY29tPsLAewQTAQIAJQIbAwYLCQgHAwIGFQgCCQoLB= BYC AwECHgECF4AFAlSNerkCGQEACgkQ7iZktA5Y2kMiuwgAt/bVZKqD92JNWDTX6h1MUsgejwj4R= Xs6 UYqFdWW/4nw4mFHzYS+gBjOQAWCBhzVZLOk6gKcRZ/s86ncVygiDUh9fbSDTcuzOp2qgu9nsc= 8sE sYp1hwmiIEbI6FHPtyeQQNilsfU8+VHX2C9yQtMK/OXlf5qNkJMj9k55u+e1ELQ2sjUXkMB4M= xMh mi/3P3hMz9PDcB66BtQcDFYkx5PIaz/izCST0o28AJq0dionJpPsQ+hFOIAkJi6aCAt3xQf0K= nXl AczWxCD3J3XTFK4MES/b3n3oc2GJY8I+tsfT5jpNsWhfWGBkMaQSKZ939D4oFAhAq3gnNRgZs= zJe TvsMvcLAeAQTAQIAIgUCVI15FQIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ7iZkt= A5Y 2kNZdgf/drEFkXWpz9pPm0/ZwNNfXzHkpGLqcfPlvQaSNFFboHwJaeKZ6s3dCGpzDlV6bLrRM= 9LN /sgNRT0eNiElJHtKDW/fqvzrHl3LCsDKed4LK4Gg2mE0nvWvTno9Nyza8TatJm1+V2S7MbDgS= E/F 26QK2VL9Y/ur5BHgUI34mUar4iE1Aq7nsFbN6NEvamyQPWlkN+rCjtnT0+NLGb5VnDVKAHSgi= YgG QeDvlisWb9NtsxzXf1qge3tlCufadSWXyqa4oOq4hEcD3GBUQVuGfBNa7r0mqHzVZf0qd+Kxz= s6D p9LxTGp7aSjiXN6cBoapz7lSP0wXOgSzIJ1X2UtVssKv28LBYgQTAQoADAUCVZFCzwWDB4Yfg= AAK CRBo+Jp/4mFufTrAEACwA4G0VlNs1JOAMgIOfE96v1lVsJiI9qod5Njc1jlXqItPKDXzvmTJA= Cy7 JfA2UbRbwkym7eCc94jkQU6XdTzv8Qf6rpbVZhzF9tNL38mzm8emh5vV3XDy8arElEP7bE9Jf= gm2 3Lm9OEwubbtjLYf0z7poncThsYUuaEexnxUVF/PXNMIlVBXil/27HkhuWKhpJQU7A35YiJz+l= alf GS+9OSv9nJD9mdoTNk4eSG2sfYKRKs6rmN3X+J9ZITs9Hnpncgu3coayZaL69iicZ4ge1KXAC= iGG 0zpK666d5ByWgWU7PRqiFIkXwHDW1esZ/QHIJFIXN9zpCD5KaSctvj+tFPNTz2+quiVSnWWQF= v/9 2zRTS4SJgxXP6I3nTasuC6KJy+JnMNfzOVpj05Ef1lXuncc4kLCqd2As1S6e/OC5Mdo5jQhe0= Ozj u5IwhRCoqKe1huSj4mbpaTvCjKyh67zVsJR/xDHFDzgtdoCsRRQQxWME8+V95FqsleNd1QfEU= /jM +HS4JWTDwFs+f1kHzzwhDHWs73M0/jvs8mUGlfRwSQVDfN6ygbuCn/i2Lvvtc2RWbxWGJVekG= 8x2 rFxUOQ7B2DqmxBrRX3GLokNJ7eWrLNLlYXGA7ptoGWLKQ1FcNNIgapKbxd0s5+s3ql7EaGViJ= 84o zNX5q52bRceaSihi4s0cTWFyY28gVGlsb2NhIDxtYXJjb0BzaWNzLnNlPsLAeAQTAQIAIgUCV= I16 cwIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ7iZktA5Y2kNxXggAhFyfi+VlqgIj5= a54 npaUoREoQ5Tj8gzUPmqOXddo0q9f1cQn/+ehKpbb3TDVzO35HBXZvuFGn5DHBUYhqBFWTx+H5= zHg GBRhF0imQ9Yi/gHe2StgrSIa5528iV2g47OyDDlSCoCWEM4WwWkJqv9CP2J53Gb63UOPuq5j+= BF9 wtDs6M6YAs9GdHIDhvUJWGDhOZevyp/DWE5d3LCI+HJIajDjhJK02kVg47aBusW40mGXmjWmt= JXP +QtZRfSaabFxCVE3APBn+P4zuyb+mk1gwkN51OiFuYQr1ig3M55kaoGbrs57fVuGtaC9DSc1v= gai cJQrYpCbOrbR/yZAedz3xcLBYgQTAQoADAUCVZFCzgWDB4YfgAAKCRBo+Jp/4mFufWd/D/9PO= 2eZ HdU0Rxr4f0EmNqhMnA6KKIo141DQnpQNqHs0RUgDlDUN1qHjgv1Uxu3gbtJoQ4PbT9rJan4Oe= m7/ NJQxU6tsa/dFjDyn9txVGppd12pVFcnGRcDNhLDzALgZN1ABxfpOh4hQy79qn69Stn0GsSnK6= gEq /+3+KROA0ZKEDWcE2rVEzw4UEv37BUaVnBnHYvNQRQVY8hc43qi3WWUhM3Ot0Z+peAV7D3Y5Z= kaS LN6kFoZPZFhrf0fhlLx0ajFIIRDQ8R8ThXXcRopWhw+ifUFdtXoW0goWPFqOkgJw1HYNbYjT4= G4D vUAYt5ueCOP6MNXEkDS4r1Hz5JDemtee+FIoaIWbma+ccL3gceoQXwvMtNu1MYFN/n13YYlqw= g9A yIkobG56OeW4o9qqkNjb3GlX+cw6f4uf7l29IF7i3jOFh4GXlYoevYiw9EpnqLWkWgm5KbT+J= 9h/ tkgt99GXfGkfLzpyjU563esgxpIwWX586ssWlbJWlAPzCf3do08MiLWTRVcrY6pXVTGAF/c41= uC6 520+RFm4ytAfrefNac1+5eZBG5k84sTdV9aamCAWkUIEaNQkTfMB7xSXAlq2T8I+kHJCsLSKX= XPF djMJtVRWSZ/gzaBE7cbELu9KaHyVRAxNKSsMInAmn/FsxnW6VFaseoT5OtxTMuAnROjB0M02T= WFy Y28gVGlsb2NhIChtYXJjby50aWxvY2FAcmkuc2UpIDxtYXJjby50aWxvY2FAcmkuc2U+wsB3B= BMB CAAhBQJaQCeQAhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEO4mZLQOWNpDAS8IAIko8= kg8 YfSgacsljgbUjYOA2LJUq3UfiSRz95PwHP05JsDGBmjcmTLfzZ7gNtprJatBEV6fRotIW7NtT= gFf g79hFJoipQ7crBQ07WJMLrk4fPReKsaiE9Q6xzRIQy2mb7jN9gbsbynfkwrSH2CnCAYwbSPSZ= lfh EOO7LALzyLVXELAxYZplGVSs9eQLeeoMNFw+24QamdxaEBVC3Zmp7IhO/0oJSYOe2Zcs97q8R= e05 8j1ncd6p4jw6QbBemi1WhuAtr+ZWYWPoQAsPOPscLa61+DEQIEl12ZwMieu8aBORm1cRVvItC= 6Ir bSUmZieY9Y3wNdpVVpDhc/+VdSvOgTPOwE0EVI15FQEIAJaan6TouRjj97Lt4Du6ZhVzbaLJW= oAR ebLANjMSN7BjBFyNOsf83HUSrCMgO5b4EESgwtFk4cKCaOjodGZYi61xhUK32J6iS6W2Siv0E= GhB U+Ij5OnnU6nTaJ+QZysRA1mLurd+Y62EVnBno0mdRsDZvJxopnygKW8MJCPoCMTJ0E+dLvdRo= SgO yqwZWNnAKF84yDk7IWb3RCOkjDybS4NVwLMop/GrdP/Pu3JGC5whR7zgTMG64kERISMr+EXSd= HYs OHVKEPb0VasVlI1VUJW7VRhksBrJ/ygoocekz7CF+MRg7hewOlXjNDXkD4PXkdGIdHoB1/g8O= 08z UMLCCCMAEQEAAcLAXwQYAQIACQUCVI15FQIbDAAKCRDuJmS0DljaQ8YTB/9Y2NPLfPvi8uYfJ= xWw VdehDxbX7znyZHIB3RrwljNjfEHsJW2ojcfLz3hBzDgfobv30DU4v0HUR4DxiPdo7PQ1tTJ/k= Zb6 Ki2veHz4ogI5hnfj8FBo4vN28M2ZGgYef415POEXt5J6I8qLaN7H41Wh2GM5UZfDwSFgaR5ku= /Kc cRuiIszhNvI9tVH0ex1WooZVMPEpITedqajeS+1jqzJEUiJTPlbMl9gC6pu3qbdPEMRvywD2n= Nou 6GZ+clFzXYfk1VkRmYT8SQkVOWQ/jCdnI5J/+vb9V3SIdq4HC/ntyljocUUx7uu8rizswTnNy= 04S XLkLo0K7Vlo211S6oNI8 =3DAOQG -----END PGP PUBLIC KEY BLOCK----- --------------6B8E84034DC0EEEDEE8464D4-- --BQMfMingheZ8E6ewXYk2cupVLL6bJHaF6-- --rZx6H9Me385t4qIhqgfdWGHb62b9FgxvB Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmCuOOIFAwAAAAAACgkQ7iZktA5Y2kO+ Kwf+PN0lTMkJ1BuB89PDxQ5oKFbW/zUwksVxrdv2suH2/+Zn+cRrt/UfnvlwAycu9qyv1FE2GxVE k//aWbUQyJUDpZ1hcIZX5f+UAp0BPG3w65/0vho/0Mtx8jCN+wICS0DnxollG9oa0La4ItHjdLR+ sU+3zIo7vRtzTh+OkzmhnMTscsnDDC2x21Cv9OeUp7xSaDmFMmgnaImQKLixL4qpFFaATPjkknwz 4bZ3Jkzhn03+jdtn18CtIx8vIGXgevdOAERJa3yTWZloCG/gLXz3Uq5/3wD+ycj+2D+XH48KJBbz kOTZ9Aacoc5ZDU1+euD5h0uSmf3ZdDMbb7vE7BpypA== =guqq -----END PGP SIGNATURE----- --rZx6H9Me385t4qIhqgfdWGHb62b9FgxvB-- From nobody Wed May 26 05:33: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 722C23A2D19; Wed, 26 May 2021 05:33:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-core-senml-versions@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <162203242344.29582.10148358869813812866@ietfa.amsl.com> Date: Wed, 26 May 2021 05:33:43 -0700 Archived-At: Subject: [core] Lars Eggert's No Objection on draft-ietf-core-senml-versions-03: (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, 26 May 2021 12:33:44 -0000 Lars Eggert has entered the following ballot position for draft-ietf-core-senml-versions-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 7.1, paragraph 4, comment: > [IANA.senml] > IANA, "Sensor Measurement Lists (SenML)", > . Not sure if a normative reference to an IANA registry page is technically OK; it should probably cite the RFC that created that registry instead, and maybe add an informative reference to the registry page? ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2.1, paragraph 4, nit: - decimal numbers, e.g. 26 (0b11010, 0x1a) for a version that adds the + decimal numbers, e.g., 26 (0b11010, 0x1a) for a version that adds the + + The text version of this document contains these HTML entities, which might indicate issues with its XML source:   Section 1, paragraph 2, nit: > es additional features over time. However in the case of SenML it is expecte > ^^^^^^^ Did you forget a comma after a conjunctive/linking adverb? Section 3, paragraph 2, nit: > secondary unit names [RFC8798] MAY be be used in the "u" field of SenML Reco > ^^^^^ Possible typo: you repeated a word These URLs in the document can probably be converted to HTTPS: * http://www.iana.org/assignments/senml From nobody Wed May 26 05:34: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 3F43E3A2D19; Wed, 26 May 2021 05:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_BLOCKED=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 (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6rml0ZeSlzF; Wed, 26 May 2021 05:34:43 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 39F673A2D1A; Wed, 26 May 2021 05:34:43 -0700 (PDT) Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id E39DB600303; Wed, 26 May 2021 15:34:35 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1622032476; bh=40NmERBIoI2ibADY+5T+RgZAltqheV2rkzsUUx1tbKU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=bNuJ7RS/de46pKfU3odNYQDf3Um+4rcs/BxwEHjyEg0mX83x6JqK8277FOFoESF5q GNIGsy10xyrHsQ2CxMJE6olhaJ0dw/blxFEiqQIlLNi/tlQRwR110J038eNN5lNQYB AU2jt+8OW/K4FBMkVsXRGSGzDoJXy1QnniITMUvs= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_10A6FDB3-FAEA-4C72-980D-732EC460BDF4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 26 May 2021 15:34:35 +0300 In-Reply-To: <162006820882.8146.574742678195359661@ietfa.amsl.com> Cc: General Area Review Team , draft-ietf-core-senml-versions.all@ietf.org, last-call@ietf.org, core@ietf.org To: Elwyn Davies References: <162006820882.8146.574742678195359661@ietfa.amsl.com> X-MailScanner-ID: E39DB600303.A29DB X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [core] [Gen-art] Genart last call review of draft-ietf-core-senml-versions-02 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, 26 May 2021 12:34:49 -0000 --Apple-Mail=_10A6FDB3-FAEA-4C72-980D-732EC460BDF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Elwyn, thank you for your review and thank you all for the following = discussion. I have entered a No Objection ballot for this document. = Based on my checks, the latest version addresses your review issues; = please let me know if you disagree. Lars > On 2021-5-3, at 21:56, Elwyn Davies via Datatracker = wrote: >=20 > Reviewer: Elwyn Davies > Review result: Almost Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-core-senml-versions-02 > Reviewer: Elwyn Davies > Review Date: 2021-05-03 > IETF LC End Date: 2021-05-03 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Almost ready. There is one issue that needs to be sorted = out. This > document removes the ordering relationship between the values of = version.. > Section 4.4 of RFC 8428 relies on that ordering relationahip. = Accordingly > there needs to be explicit new text for Section 4.4 in this document. = Also the > concept of 'must understand' items is used in this document but is not > explicitly defined in RFC 8428. This needs to be fixed - which could = happen in > the new version of Setion 4.4. >=20 > Major issues: > None >=20 > Minor issues: >=20 > The redefinition of version means that this document should contain an = explicit > update of (at least) paragraph 3 of Section 4.4 of RFC 8428, That = section > assumes that there is an ordering relationship between version field = values > which is invalidated by this document. >=20 > Also the concept of 'must understand' fields is supposed to be = explained in > that section as well as discussed in s2.1 of this document. That term = is not > explicitly used in RFC 8428 but I take it that it is supposed to refer = to field > names ending wth an underscore character ('_'). This should be fixed = with a > rewrite of s4.4 of RFC 8428. >=20 > Nits/editorial comments: >=20 > General: The RFC Editor preferes the US convention for quoting items = using > exclusively singe quote rather than double quote marks. >=20 > s1, para 2: I found this paragraph difficult to parse, especially the = second > sentence. Here is an alternative suggestion. OLD: The traditional = idea of > using a version number for evolving an interchange format presupposes = a linear > progression of that format. A more likely form of evolution of SenML = is the > addition of independently selectable _features_ that can be added to = the base > version (version 10) in a fashion that these are mostly independent of = each > other. A recipient of a SenML pack can check the features it = implements against > those required by the pack, processing the pack only if all required = features > are provided in the implementation. NEW: The traditional idea of using = a > version number to indicate the evolution of an interchage format = generally > assmes an incremental progression of the version number as the format = develops > over time. However in the case of SenML it is expected that the likely > evolution mechanism will be for independently selectable capabiity = _features_ > to be added to the basic system indicated by 'version' 10. To support = this > model, this document repurposes the single version number accompanying = a pack > of SenML records so that it is interpreted as a bitmap indicating the = set of > features a recipient would need to have implemented to be able to = process the > pack. ENDS >=20 > s2: Personally I would have used the left shift operator rather then = 2^fc but > that is a personal view. >=20 > s2,1, para 2: s/lower-most bit positions Section 3./least significant = bit > positions for the base version as described in Section 3./ >=20 > s2.1, para 2: s/Section 4/by the feature defined in Section 4/ >=20 > s2.1, para 2: 'boutique' is slang: s/boutique/less generally = applicable/ >=20 > s3: s/already/effectively already/ >=20 > s6: I am not we really care but are feature names case sensitve? >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_10A6FDB3-FAEA-4C72-980D-732EC460BDF4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmCuQFsACgkQVLXDCb9w wVdcLg//ebPnYNMVRZST+texM4povP5SUHWZK4iMk7QwblnZ1+UO6P9PgSeWMEF1 FX3ue16dSkM0yyAk3DcDYoIcNTfHmXPC3ZEJ+jqvmgAmGQmJlUqPHflDSTnGphe5 T5iM5mwa7vmM3qyEtWiPIrgk3VHr8IzvdJVog4rW04sSocvCNLmR4lW6CMM/5Xb1 XZwt1EvjpiLAg3qe9OVsJ+YspRFPdX8AyZHv3W+p0bl2DBH5CvfkFOiWAV18nO1n gOGCNQKyER2i7DZUdKtaMRNTCbUwQULPGSxBFLZFRa9EfWD9+PblVOHpBgGdDUpM iqfIKHL4xqe3VD2/zLC5vnF84t5RuQhNdg6KCpI7J9t5OlwZHd+pzoU0xFLhxpwJ 17obcmY/9nWgBmgHs8PfNCKGg8trPrO31wwCWfeKlAfrThcO31WvEYMaUAHBgkPF bAMkKXVC9uMQwuBxPWnCF6dVuC/fLlffrGWYAFgRdCPJMk7WUY1d8koErTrOxPL8 qcwRwbEl0a/JIvCeM7r0AHUbxlrByIi/XUMa+GCNyOZZG2s2b2mhga79fw0zdUwq xGgv5Kh9D6dL/cOAIk3X5IgnV5gYDgi0ALOVMMJT/8tnIuGwxFTmtWuWseyh6GTS Ae4Ru49SE7zHQ0aavuHtAsiJTKFH25EltrbvI3BH4YTe39odo68= =9WDK -----END PGP SIGNATURE----- --Apple-Mail=_10A6FDB3-FAEA-4C72-980D-732EC460BDF4-- From nobody Wed May 26 06:49: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 F1B1D3A2F69; Wed, 26 May 2021 06:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZdLxFgX9LsW; Wed, 26 May 2021 06:49:16 -0700 (PDT) Received: from wforward4-smtp.messagingengine.com (wforward4-smtp.messagingengine.com [64.147.123.34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99FEA3A2F49; Wed, 26 May 2021 06:49:15 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailforward.west.internal (Postfix) with ESMTP id 3F5A810F7; Wed, 26 May 2021 09:49:14 -0400 (EDT) Received: from imap3 ([10.202.2.53]) by compute6.internal (MEProxy); Wed, 26 May 2021 09:49:14 -0400 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=fm2; bh=+MBdXqFLHidUmqG1ZmMuB7VWCe/O/UB/AHgxIMJif qQ=; b=pX7uW7jLvRwACWwu4bFqEgDPM6KrCqunXP8Y6WiGHx8O9UC5R7gAQYi6V jCNNeDR2S00Gpfpdz6z0O2Hvh0yzEowOFQSvb1mT9lNBQMTlNRua+RJF7zAOZZ+7 +0lK+piMf9VF/6Guhy23+NigP5Q4m6B0xUomWyrqLyWZdvJfJ3KV8vPUqFLWmN27 baXV6k+FLsGZkEHNIV5hp4AXIhSIPVuXUi4kw7M+R+ajymZ/h4GqMPtSgE7KmWjL 0mgSeBg3BiLyFuNsc1wMsTnt318ZJWSsfa5YWxS9ijOPXjSAdy6JTzmU8crxGNlT vGtOUHy40v52uP2j5jQl3nyMC/7Ew== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdekfedgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpeflrghi mhgvpgflihhmrohnvgiiuceojhgrihhmvgesihhkihdrfhhiqeenucggtffrrghtthgvrh hnpeetffejffegvefhgeegfffhuefhiedvhfefleefvdetgfefleehudffgffggfdtuden ucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepjhgrihhmvgesihhkihdrfhhi X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 88365420453; Wed, 26 May 2021 09:49:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416 Mime-Version: 1.0 Message-Id: <2f560969-0df0-4bd0-aded-34e202221067@www.fastmail.com> In-Reply-To: References: <162006820882.8146.574742678195359661@ietfa.amsl.com> Date: Wed, 26 May 2021 16:48:51 +0300 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: "Carsten Bormann" , "Elwyn Davies" Cc: gen-art@ietf.org, core@ietf.org, draft-ietf-core-senml-versions.all@ietf.org, last-call@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-senml-versions-02 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, 26 May 2021 13:49:22 -0000 Hi Carsten,=20 Small nit. I had a quick read of the diff and although section 2 looks g= ood with the new HTML and CSS, the formula looks mangled in the data tra= cker format ("present(fc) =E2=8B=85 2"). https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-versions-03.tx= t Ciao! --=20 Jaime Jim=C3=A9nez On Sun, May 9, 2021, at 10:51 PM, Carsten Bormann wrote: > Hi Elwyn, >=20 > I finally got around to process your review. >=20 > I have submitted a new version -03 based on this review. > I could make direct use of your text suggestions, but did edit them a=20= > little. > So you may want to have another look at the second paragraph of 1=20 > (introduction) and the new section 2.2, which address your main points= . >=20 > https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ > https://www.ietf.org/archive/id/draft-ietf-core-senml-versions-03.html= > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-versions-03.= txt >=20 > That was a great, thoughtful review. > Thanks again! >=20 > CoRE WG: Please also check the above documents and diffs! >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > On 2021-05-03, at 20:56, Elwyn Davies via Datatracker wrote: > >=20 > > Reviewer: Elwyn Davies > > Review result: Almost Ready > >=20 > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > >=20 > > For more information, please see the FAQ at > >=20 > > . > >=20 > > Document: draft-ietf-core-senml-versions-02 > > Reviewer: Elwyn Davies > > Review Date: 2021-05-03 > > IETF LC End Date: 2021-05-03 > > IESG Telechat date: Not scheduled for a telechat > >=20 > > Summary: Almost ready. There is one issue that needs to be sorted = out. This > > document removes the ordering relationship between the values of ver= sion.. > > Section 4.4 of RFC 8428 relies on that ordering relationahip. Accor= dingly > > there needs to be explicit new text for Section 4.4 in this document= . Also the > > concept of 'must understand' items is used in this document but is n= ot > > explicitly defined in RFC 8428. This needs to be fixed - which coul= d happen in > > the new version of Setion 4.4. > >=20 > > Major issues: > > None > >=20 > > Minor issues: > >=20 > > The redefinition of version means that this document should contain = an explicit > > update of (at least) paragraph 3 of Section 4.4 of RFC 8428, That = section > > assumes that there is an ordering relationship between version field= values > > which is invalidated by this document. > >=20 > > Also the concept of 'must understand' fields is supposed to be expla= ined in > > that section as well as discussed in s2.1 of this document. That te= rm is not > > explicitly used in RFC 8428 but I take it that it is supposed to ref= er to field > > names ending wth an underscore character ('_'). This should be fixe= d with a > > rewrite of s4.4 of RFC 8428. > >=20 > > Nits/editorial comments: > >=20 > > General: The RFC Editor preferes the US convention for quoting item= s using > > exclusively singe quote rather than double quote marks. > >=20 > > s1, para 2: I found this paragraph difficult to parse, especially t= he second > > sentence. Here is an alternative suggestion. OLD: The traditional i= dea of > > using a version number for evolving an interchange format presuppose= s a linear > > progression of that format. A more likely form of evolution of SenML= is the > > addition of independently selectable _features_ that can be added to= the base > > version (version 10) in a fashion that these are mostly independent = of each > > other. A recipient of a SenML pack can check the features it impleme= nts against > > those required by the pack, processing the pack only if all required= features > > are provided in the implementation. NEW: The traditional idea of usi= ng a > > version number to indicate the evolution of an interchage format gen= erally > > assmes an incremental progression of the version number as the forma= t develops > > over time. However in the case of SenML it is expected that the like= ly > > evolution mechanism will be for independently selectable capabiity _= features_ > > to be added to the basic system indicated by 'version' 10. To suppor= t this > > model, this document repurposes the single version number accompanyi= ng a pack > > of SenML records so that it is interpreted as a bitmap indicating th= e set of > > features a recipient would need to have implemented to be able to pr= ocess the > > pack. ENDS > >=20 > > s2: Personally I would have used the left shift operator rather the= n 2^fc but > > that is a personal view. > >=20 > > s2,1, para 2: s/lower-most bit positions Section 3./least significan= t bit > > positions for the base version as described in Section 3./ > >=20 > > s2.1, para 2: s/Section 4/by the feature defined in Section 4/ > >=20 > > s2.1, para 2: 'boutique' is slang: s/boutique/less generally applic= able/ > >=20 > > s3: s/already/effectively already/ > >=20 > > s6: I am not we really care but are feature names case sensitve? > >=20 > >=20 > >=20 >=20 >=20 From nobody Wed May 26 07:14: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 0F9983A2FE1; Wed, 26 May 2021 07:14:19 -0700 (PDT) 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_FAIL=0.001, SPF_HELO_NONE=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 UJliN-sDEA1y; Wed, 26 May 2021 07:14:14 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455933A2FE4; Wed, 26 May 2021 07:14:14 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FqtH71PT9z316N; Wed, 26 May 2021 16:14:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <162203242344.29582.10148358869813812866@ietfa.amsl.com> Date: Wed, 26 May 2021 16:14:10 +0200 Cc: The IESG , draft-ietf-core-senml-versions@ietf.org, core-chairs@ietf.org, "core@ietf.org WG" , jaime@iki.fi X-Mao-Original-Outgoing-Id: 643731250.333391-7806e01e61e1bdee4c70be78c1e44b67 Content-Transfer-Encoding: quoted-printable Message-Id: References: <162203242344.29582.10148358869813812866@ietfa.amsl.com> To: Lars Eggert X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Lars Eggert's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2021 14:14:19 -0000 Hi Lars, thank you for these details! > On 2021-05-26, at 14:33, Lars Eggert via Datatracker = wrote: >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Section 7.1, paragraph 4, comment: >> [IANA.senml] >> IANA, "Sensor Measurement Lists (SenML)", >> . >=20 > Not sure if a normative reference to an IANA registry page is = technically OK; it > should probably cite the RFC that created that registry instead, and = maybe add > an informative reference to the registry page? I find dozens of recent RFCs with normative references to IANA = registries, and I do believe this practice is both OK and makes a lot of = sense (in particular for registries like the present one that have been = set up successively over time in multiple RFCs =E2=80=94 even if those = RFCs are also being references normatively, as they are here). If you think we should change this practice, I think some guidance by = the IESG would be useful. The nits are fixed in the editor copy; except for the http:// URI =E2=80=94= I have written a note to tools-discuss about the generation of http:// = URIs in bibxml8. Gr=C3=BC=C3=9Fe, Carsten >=20 > = --------------------------------------------------------------------------= ----- > All comments below are about very minor potential issues that you may = choose to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), = so there > will likely be some false positives. There is no need to let me know = what you > did with these suggestions. >=20 > Section 2.1, paragraph 4, nit: > - decimal numbers, e.g. 26 (0b11010, 0x1a) for a version that adds = the > + decimal numbers, e.g., 26 (0b11010, 0x1a) for a version that adds = the > + + >=20 > The text version of this document contains these HTML entities, which = might > indicate issues with its XML source:   >=20 > Section 1, paragraph 2, nit: >> es additional features over time. However in the case of SenML it is = expecte >> ^^^^^^^ > Did you forget a comma after a conjunctive/linking adverb? >=20 > Section 3, paragraph 2, nit: >> secondary unit names [RFC8798] MAY be be used in the "u" field of = SenML Reco >> ^^^^^ > Possible typo: you repeated a word >=20 > These URLs in the document can probably be converted to HTTPS: > * http://www.iana.org/assignments/senml >=20 >=20 >=20 From nobody Wed May 26 07:26:00 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 3AA3F3A3036; Wed, 26 May 2021 07:25:57 -0700 (PDT) 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 QCXIwBg_K5nQ; Wed, 26 May 2021 07:25:53 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5323A302C; Wed, 26 May 2021 07:25:52 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FqtXY6bFGz316L; Wed, 26 May 2021 16:25:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <2f560969-0df0-4bd0-aded-34e202221067@www.fastmail.com> Date: Wed, 26 May 2021 16:25:49 +0200 Cc: Elwyn Davies , gen-art@ietf.org, core@ietf.org, draft-ietf-core-senml-versions.all@ietf.org, last-call@ietf.org X-Mao-Original-Outgoing-Id: 643731949.31156-f1bd24de6f94ca3ce558a3bc8b28d2a6 Content-Transfer-Encoding: quoted-printable Message-Id: References: <162006820882.8146.574742678195359661@ietfa.amsl.com> <2f560969-0df0-4bd0-aded-34e202221067@www.fastmail.com> To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-senml-versions-02 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, 26 May 2021 14:25:57 -0000 Hi Jaime, Beautiful. This problem is not in the XML generated by kramdown-rfc or in the TXT = or HTML generated from that by xml2rfc, it occurs from scratch only in = xml2rfc=E2=80=99s (v 3.7.0) v2v3 conversion output generated from that. = This appears to be new, I haven=E2=80=99t seen it before. Tracking down the bug now=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten > On 2021-05-26, at 15:48, Jaime Jim=C3=A9nez wrote: >=20 > Hi Carsten,=20 >=20 > Small nit. I had a quick read of the diff and although section 2 looks = good with the new HTML and CSS, the formula looks mangled in the data = tracker format ("present(fc) =E2=8B=85 2"). >=20 > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-versions-03.txt >=20 > Ciao! > --=20 > Jaime Jim=C3=A9nez >=20 > On Sun, May 9, 2021, at 10:51 PM, Carsten Bormann wrote: >> Hi Elwyn, >>=20 >> I finally got around to process your review. >>=20 >> I have submitted a new version -03 based on this review. >> I could make direct use of your text suggestions, but did edit them a=20= >> little. >> So you may want to have another look at the second paragraph of 1=20 >> (introduction) and the new section 2.2, which address your main = points. >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ >> = https://www.ietf.org/archive/id/draft-ietf-core-senml-versions-03.html >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-versions-03.txt >>=20 >> That was a great, thoughtful review. >> Thanks again! >>=20 >> CoRE WG: Please also check the above documents and diffs! >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>> On 2021-05-03, at 20:56, Elwyn Davies via Datatracker = wrote: >>>=20 >>> Reviewer: Elwyn Davies >>> Review result: Almost Ready >>>=20 >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>>=20 >>> For more information, please see the FAQ at >>>=20 >>> . >>>=20 >>> Document: draft-ietf-core-senml-versions-02 >>> Reviewer: Elwyn Davies >>> Review Date: 2021-05-03 >>> IETF LC End Date: 2021-05-03 >>> IESG Telechat date: Not scheduled for a telechat >>>=20 >>> Summary: Almost ready. There is one issue that needs to be sorted = out. This >>> document removes the ordering relationship between the values of = version.. >>> Section 4.4 of RFC 8428 relies on that ordering relationahip. = Accordingly >>> there needs to be explicit new text for Section 4.4 in this = document. Also the >>> concept of 'must understand' items is used in this document but is = not >>> explicitly defined in RFC 8428. This needs to be fixed - which = could happen in >>> the new version of Setion 4.4. >>>=20 >>> Major issues: >>> None >>>=20 >>> Minor issues: >>>=20 >>> The redefinition of version means that this document should contain = an explicit >>> update of (at least) paragraph 3 of Section 4.4 of RFC 8428, That = section >>> assumes that there is an ordering relationship between version field = values >>> which is invalidated by this document. >>>=20 >>> Also the concept of 'must understand' fields is supposed to be = explained in >>> that section as well as discussed in s2.1 of this document. That = term is not >>> explicitly used in RFC 8428 but I take it that it is supposed to = refer to field >>> names ending wth an underscore character ('_'). This should be = fixed with a >>> rewrite of s4.4 of RFC 8428. >>>=20 >>> Nits/editorial comments: >>>=20 >>> General: The RFC Editor preferes the US convention for quoting = items using >>> exclusively singe quote rather than double quote marks. >>>=20 >>> s1, para 2: I found this paragraph difficult to parse, especially = the second >>> sentence. Here is an alternative suggestion. OLD: The traditional = idea of >>> using a version number for evolving an interchange format = presupposes a linear >>> progression of that format. A more likely form of evolution of SenML = is the >>> addition of independently selectable _features_ that can be added to = the base >>> version (version 10) in a fashion that these are mostly independent = of each >>> other. A recipient of a SenML pack can check the features it = implements against >>> those required by the pack, processing the pack only if all required = features >>> are provided in the implementation. NEW: The traditional idea of = using a >>> version number to indicate the evolution of an interchage format = generally >>> assmes an incremental progression of the version number as the = format develops >>> over time. However in the case of SenML it is expected that the = likely >>> evolution mechanism will be for independently selectable capabiity = _features_ >>> to be added to the basic system indicated by 'version' 10. To = support this >>> model, this document repurposes the single version number = accompanying a pack >>> of SenML records so that it is interpreted as a bitmap indicating = the set of >>> features a recipient would need to have implemented to be able to = process the >>> pack. ENDS >>>=20 >>> s2: Personally I would have used the left shift operator rather = then 2^fc but >>> that is a personal view. >>>=20 >>> s2,1, para 2: s/lower-most bit positions Section 3./least = significant bit >>> positions for the base version as described in Section 3./ >>>=20 >>> s2.1, para 2: s/Section 4/by the feature defined in Section 4/ >>>=20 >>> s2.1, para 2: 'boutique' is slang: s/boutique/less generally = applicable/ >>>=20 >>> s3: s/already/effectively already/ >>>=20 >>> s6: I am not we really care but are feature names case sensitve? >>>=20 >>>=20 >>>=20 >>=20 >>=20 From nobody Wed May 26 08:33:05 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 5A8893A3225; Wed, 26 May 2021 08:33:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-core-senml-versions@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <162204318386.5937.225407037704905384@ietfa.amsl.com> Date: Wed, 26 May 2021 08:33:04 -0700 Archived-At: Subject: [core] Martin Duke's No Objection on draft-ietf-core-senml-versions-03: (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, 26 May 2021 15:33:05 -0000 Martin Duke has entered the following ballot position for draft-ietf-core-senml-versions-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Given the very constrained space, I wonder if it's wise to reserve 0 and 2 for no real purpose. IIUC these would still result in version numbers > 10 and therefore not break anything, yes? From nobody Wed May 26 11:01: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 23E373A0812 for ; Wed, 26 May 2021 11:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXlgICmO4mPN for ; Wed, 26 May 2021 11:01:11 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150078.outbound.protection.outlook.com [40.107.15.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9397B3A07F5 for ; Wed, 26 May 2021 11:01:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jgsnvUEFOEwvKbaN2elgOW8gbZ6p94lRHg1mNXeh8x6zRUZzJKCJ2JcSk+Thyau766uYomHTNOneZnqxOXF5Q4bbwPF2zaJ3blyLMnITq5Eg8leW3jGq4c84IMt6SuUhm7wfmYXKYXExMiLke3WKmIU0OZ2JRuzDRqHapWsz7Kw0LhvVry2rHPjDy1BE5fFFjA7Urms3LKEtYDJ/l+HkFL8Q6sgUKYu19TDEu5tSu+8GRztRshh9CJwe9MKUd//lB2u4OFTYW16J+69NVenRjy3nOu2WUZiBEWHhycddLdW5zG4ZlftkkyTK7s1Xr5nYD0GXP8VaS8WXL8J7Cpar8g== 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=b7TWLQjmSkcMGi6AG7K+Hf+c7FSFJhDibJmNa5NPfTg=; b=D40pkUtlkLnZnHnDiHzGYMqHi9GK0pQVNC6JIhRI1eTraK39cCfDkp8DwTJX9DF8xrRdR1QIOXsaYO4V4+2IHCyX5rvkTJ+gOexKdYdT5ZY2thAKJ0XsTu1nNikN4c2rjuJlf3YqK9DhMLv+M79PatUKO/I1Zppi4SC8WUoZuLWYDtAP9qHaZw/jaLrrIDoy0KSsnnqqFO+A9dfYUA5koqq7eWBjVM4dDCpVByb2bxk5RUufx7Dvn/sWVz5sDCT2T7LIce9qtx0i8yzR2lAT5MbXnSNAhPeWtA69BxUZZyHUVBVk+FcWGUnCSxId4rwBHqZqLVOglK2653hApwqMoA== 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=b7TWLQjmSkcMGi6AG7K+Hf+c7FSFJhDibJmNa5NPfTg=; b=NEYkNfrYEyhDk/MFmBhLKwIMlKKWkFdw2MlqrE+ErQ+tMz+CNg7Uktd7Om4C8CyQ/Ww5l1uKgz2X2o22vdYH8n7D0cRZOVVouc31ktLFP97ZEtbFGq5IzGkPl8nkJynl7hETdYjmUuiSa5/rNH6ktWBKOc1mi+XEh23sK9iWO9U= 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 DB9P189MB1579.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:2a4::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.26; Wed, 26 May 2021 18:01:08 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1913:bcf7:e20a:a4e6]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1913:bcf7:e20a:a4e6%9]) with mapi id 15.20.4173.020; Wed, 26 May 2021 18:01:08 +0000 References: <004401d7524d$b74809b0$25d81d10$@yahoo.com> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca X-Forwarded-Message-Id: <004401d7524d$b74809b0$25d81d10$@yahoo.com> Message-ID: <43acbc18-aa0b-b097-6b75-ae000c4abd41@ri.se> Date: Wed, 26 May 2021 20:01:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 In-Reply-To: <004401d7524d$b74809b0$25d81d10$@yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9JIxnIP06q3NL6rODHF5IkAhrodO2Elkx" X-Originating-IP: [45.12.220.188] X-ClientProxiedBy: PR3P189CA0029.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:52::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.2.9] (45.12.220.188) by PR3P189CA0029.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:52::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.20 via Frontend Transport; Wed, 26 May 2021 18:01:07 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f79be36e-a6cf-4883-2bef-08d920703ccf X-MS-TrafficTypeDiagnostic: DB9P189MB1579: 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: pqXh1dWYBC97U/+cHLb2Oj0m2AimyiVo+hHpSZ0DSCwpsDRCg9gZpbkDMEM5n9dB6oTOCwguvhW0Afl06xGAyUIG1MnXyYOXGeWGfFW1RI+RmH1eIPUsLvvjawyV1LpHwcQVhYDATAzAGonHuRal+ED5kYV8bsQd9JXZhGlwyy1UhLrhiXtAOfxJQjn+jGAakhJpJzW3cWpV2KhSsfK4t7gouRyMIOVcpKc2ElyrlXSvv0p6SblIaNanmYCPwQ8uU1tNY3ibamE2UhAVRmRqy2XYiT3b//rru+/AXisFZAr84hWPJF/KNIvgaGzRxs+utyJsqUr6c1ydBx3olai8KI5y22nqOWWvOXG63baWzqvt6vvk7O9hP9Pvn4N6Jgoa3/JmqtG++kD1k+bN8KQGPNLuIdkkfG5TZuH5wTazdpZTKVsIsA7hWOcScdthJxy/o1+bvbTIR4rQ9NGtR0vIkeAWjP4vxp+b0XzFtTUsOpakX4opP5uGf4IhynZjZQiPmod81/kyrrfJ0RmJVhFZ3lkvu5bpVD77+DD99QrmPmLr5VnP2+OJ60yRp5w9Tku0CFZ6aSMIfTCjdCSTczOQTwCFFS2NDXe2pbC0VBADaPJLEF+NFWRA4VkU6ewsCKN3iGtt2CuAYXWU+2Ol8OLANCRWmsLG2g5tzpiCb5RTX6yCQXzc1hPfkn+f1xwrmxnwMP3HJHz0JdRvwntrQmucyFcUfQIZQcgvjz9kvZNIXrazao288jNpJAzFzFiHK3KnMjYM3jbBuWC9OFNEsyxXTWQ1C5U+NrXOQdV5ROj6Rc3GIYEGqZYA67cLXS50Gz4P 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)(136003)(346002)(39850400004)(396003)(376002)(186003)(16526019)(26005)(36756003)(2616005)(66946007)(5660300002)(956004)(2906002)(44832011)(8936002)(21480400003)(66476007)(66556008)(16576012)(86362001)(235185007)(45080400002)(166002)(6916009)(31696002)(38100700002)(316002)(8676002)(31686004)(966005)(6486002)(478600001)(83380400001)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?Windows-1252?Q?goMRRWCzSlj/WIlsnEBa82RvJQKYF7DlLY7SmoFQ5DLduWDORExeXyqc?= =?Windows-1252?Q?mtOCESM8I6/QLiMEqw9HMsbeOxXLDkO70K626SmZuRxhXi25X+yus8ew?= =?Windows-1252?Q?UGrU7qPQSBGfqk2Ph6jaNmV0rweED84isihi64BA3q+iiQ8gnUYFf61P?= =?Windows-1252?Q?7Q7G59/+B3D8MUprrOwZejgy2Zn1PKRXozk7Zu7IFHb4/W0rJkWUzZUl?= =?Windows-1252?Q?+otMSTyFJjeLOjN7L4GRQTTXtHxqc5OdWtZdXBw8wGLeLmC06q/lApMa?= =?Windows-1252?Q?WK7toQOr7Ro73T6Ypt8kCCJkXgDUZEhhgqRDmGutpkSc9fTa/94IGkJ/?= =?Windows-1252?Q?9zuwmvkL47iGjsA61/ciBx9KIWsORAh+fEQCQwGVw9g+lUuAUxJXnBIO?= =?Windows-1252?Q?2lAfqJIvZ1RQuZJ8YGM6ZCy2y01AYnsoXydCpeetZtdS6w3GGuNkcMOm?= =?Windows-1252?Q?21CRj+svb+GtCiHUXvDVGPrsyhKMLopeJ4FjN5nMo5nFEt7RnAjLGs1c?= =?Windows-1252?Q?oh/WRtlO5GK2a54k0CsAlvPRlLjpZv8OTTVt0EK9RS6ndM0JI2z16tUd?= =?Windows-1252?Q?Q1crY7j1HEGwfKVc+voJPUB1uvzV2dDvtpXf/ahZpgM/hA0KWNCRiDDX?= =?Windows-1252?Q?LZn652vik8kDr/OCrRwrd5iCYbQXs3Zjn6hg6rOqtRdad7A1s58tL3Oa?= =?Windows-1252?Q?+MdjpQS0TANt3Lfy4/XouSCNoLbXor4PVoUcGoZggeA7S1nxT0GW0/fv?= =?Windows-1252?Q?SaCOm9LaH8Mx1smpS6/cJEBCmD4GVutFwIhOKHx3b6L9XoilaFmXRvhM?= =?Windows-1252?Q?OW1WRQfpZFad5zive/dydo1CvRr9hs1BFfrVE3ZImFNVjpUBhThvxrBZ?= =?Windows-1252?Q?cb/LxyBHMUqkVKmMeKU9xxasNnyKlYd4H3LZkvJbT8gzFhPxyWj8oG7y?= =?Windows-1252?Q?t36LhDUAyZjuwdFUxgmJbvltM4SJntp1hI/yWotE6WxrcSks2fKRYdk1?= =?Windows-1252?Q?amPZY/PEMPqA+I72lzlkqtYolwy06RsxQ3oFrZSfRArGMWd5l8yPktGz?= =?Windows-1252?Q?N1pYKmaE7uaU8PtoCux9ywNSfRBnqPDa6zeyfiWXSnqQUDEaKmtc+5hk?= =?Windows-1252?Q?OVq4xxGOEeQauTXsc2WHBwE81it0pdp0TC5KYTIWn/Tb1IUa5vfs7BEo?= =?Windows-1252?Q?tcMbgYETnOkkguYmFA8OZ/lJWwPZJ35nKVeF4QKCBszGnwcrm/o8FdBC?= =?Windows-1252?Q?4Ivy36wkl0AQvZBIVoisu7mhSAvhicmYWccqBCCSaj7w9vwzOlZeBzNQ?= =?Windows-1252?Q?pyHWnjd275cW7p3pp/a6a9HSN16xTosGppiRCvEurLKXUuXbAyzEkgHW?= =?Windows-1252?Q?hsRlMCO37wqvhQG4K4HY6ZKRQG2Xm02oEMlx1K+NmlB03NbcZRNywWU2?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: f79be36e-a6cf-4883-2bef-08d920703ccf X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2021 18:01:08.1109 (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: mcGmuIrr8GN6cP1JP1WJ9lzctkpFaRs3xGD3JYmvQdw1h0WIVf0Nnz6P+2QqesITxyheqgSAoXTL2CRV1v0AQg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P189MB1579 Archived-At: Subject: [core] Fwd: NomCom 2021-2022 Call for Volunteers 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, 26 May 2021 18:01:17 -0000 --9JIxnIP06q3NL6rODHF5IkAhrodO2Elkx Content-Type: multipart/mixed; boundary="VKbIE7CdW6FKMhubhlKxkvWOK0l6vAkJ6"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <43acbc18-aa0b-b097-6b75-ae000c4abd41@ri.se> Subject: Fwd: NomCom 2021-2022 Call for Volunteers References: <004401d7524d$b74809b0$25d81d10$@yahoo.com> In-Reply-To: <004401d7524d$b74809b0$25d81d10$@yahoo.com> --VKbIE7CdW6FKMhubhlKxkvWOK0l6vAkJ6 Content-Type: multipart/alternative; boundary="------------8D83F15EE88739CA5987D216" Content-Language: en-US This is a multi-part message in MIME format. --------------8D83F15EE88739CA5987D216 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Dear all, The NomCom 2021-2022 Call for Volunteers went out today. https://mailarchive.ietf.org/arch/msg/ietf-announce/T_WVH96pH-5QVTRqd0yTT= 1TaPaU/ The IETF benefits from having a good, sizable pool of volunteers to be=20 NomCom members. Please, volunteer if you think you can serve on NomCom. Best, /Marco -------- Forwarded Message -------- Subject: NomCom 2021-2022 Call for Volunteers Date: Wed, 26 May 2021 12:39:36 -0400 From: g_e_montenegro=3D40yahoo.com@dmarc.ietf.org To: wgchairs@ietf.org Hi, As you may have seen, the NomCom 2021-2022 Call for Volunteers went out=20 today: https://mailarchive.ietf.org/arch/msg/ietf-announce/T_WVH96pH-5QVTRqd0yTT= 1TaPaU/=20 The IETF benefits from having a good, sizable pool of volunteers to be=20 NomCom members. Please consider publicizing the announcement in your respective WGs. Thanks, Gabriel (as NomCom Chair) --------------8D83F15EE88739CA5987D216 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear all,

The NomCom 2021-2022 Call for Volunteers went out today.

https://mailarchive.i= etf.org/arch/msg/ietf-announce/T_WVH96pH-5QVTRqd0yTT1TaPaU/

The IETF benefits from having a good, sizable pool of volunteers to be NomCom members. Please, volunteer if you think you can serve on NomCom.

Best,
/Marco


-------- Forwarded Message --------
Sub= ject: NomCom 2021-2022 Call for Volunteers
Dat= e: Wed, 26 May 2021 12:39:36 -0400
Fro= m: g_e_montenegro=3D40yahoo.com@dma= rc.ietf.org
To:= wgchairs@ietf.org


Hi,

=A0

As you may have seen, the NomCom 2021-2022= Call for Volunteers went out today:

=A0

https://mailarchive.ietf.org/arch/ms= g/ietf-announce/T_WVH96pH-5QVTRqd0yTT1TaPaU/

=A0

The IETF benefits from having a good, sizable pool of volunteers to be NomCom members.

=

=A0

Please consider publicizing the announcement in your respective WGs.

=A0

Thanks,

=A0

Gabriel

(as NomCom Chair)

=A0

=A0

=A0

--------------8D83F15EE88739CA5987D216-- --VKbIE7CdW6FKMhubhlKxkvWOK0l6vAkJ6-- --9JIxnIP06q3NL6rODHF5IkAhrodO2Elkx Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmCujOEFAwAAAAAACgkQ7iZktA5Y2kOP PwgAhmLBGvKNA0MN+0ZdeRHkha6whfpSPOqFfUo5xhxHBf/xsopCkeB5G/avHLIjtDiT/VXDZlVY +Py3K/V0HVlsLUTH97FBFkBLWaiTqS4oN7PhZQzC5x7GXNqgGs1JalmOZTkOXYKSHDNYmXxsXjvj irmUmYu0sn+pWRG8DqXhMSngLeZa/rt2kCWVYqJpK+/SHRPkLDJBNf0D9NmPTJVf0IXloVr3F1sM jC6W0aqiZbCqaqjVN3U2H6OcC9zygdIN81NVNEhp+pOVNvosf6sHi2XeT8/QC1m+DSaRF16Sa9Sk pTrRrnKfukJ48jLv8PwC53oO/yQzFOcR48gDxbckbw== =/nTw -----END PGP SIGNATURE----- --9JIxnIP06q3NL6rODHF5IkAhrodO2Elkx-- From nobody Wed May 26 22:15:45 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 9D2BB3A0A29; Wed, 26 May 2021 22:15:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162209250556.22156.4946674613534413511@ietfa.amsl.com> Date: Wed, 26 May 2021 22:15:05 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-new-block-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: Thu, 27 May 2021 05:15: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 Supporting Robust Transmission Authors : Mohamed Boucadair Jon Shallow Filename : draft-ietf-core-new-block-14.txt Pages : 49 Date : 2021-05-26 Abstract: This document specifies alternative Constrained Application Protocol (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options. These options are similar to, but distinct from, the CoAP Block1 and Block2 Options defined in RFC 7959. Q-Block1 and Q-Block2 Options are not intended to replace Block1 and Block2 Options, but rather have the goal of supporting Non-confirmable messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 Options support 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 is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 27 06:59:47 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 307C93A0D77; Thu, 27 May 2021 06:59:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , core-chairs@ietf.org, core@ietf.org, draft-ietf-core-new-block@ietf.org, francesca.palombini@ericsson.com, marco.tiloca@ri.se, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <162212398217.16226.18240301507257321784@ietfa.amsl.com> Date: Thu, 27 May 2021 06:59:42 -0700 Archived-At: Subject: [core] Protocol Action: 'Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission' to Proposed Standard (draft-ietf-core-new-block-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: Thu, 27 May 2021 13:59:42 -0000 The IESG has approved the following document: - 'Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission' (draft-ietf-core-new-block-14.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-new-block/ Technical Summary The document defines two new options for the Constrained Application Protocol (CoAP), namely Q-Block1 and Q-Block2. The two options enable effective block-wise transfers of large data payload, also under network conditions where asymmetrical transient packet loss may be experienced. The main use case addressed by this document is a network under Distributed Denial of Service (DDoS) attack, where DDoS mitigation agents are still required to exchange large amount of data using CoAP. This use case is especially targeted in the DOTS Working Group, where the use of the two new options is suggested in its DOTS Telemetry, see https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ Compared to the similar options Block1 and Block2 defined in RFC 7959 --- which are based on synchronous, lock-step exchanges of blocks, and thus can be ineffective or even prohibitive to use under a DDoS situation --- the new options enable faster transmission rates with less packet interchanges, as well as faster recovery of lost blocks. The document also defines congestion control procedures to be used when the Q-Block1 and Q-Block2 Options are used over an unreliable transport. Working Group Summary The document has been discussed on multiple IETF meetings and CoRE interim meetings, and has gone through multiple expert reviews. During and after Working Group Last Call, effort was also put in better reflecting how design choices align with the intended scope of the document, i.e. to serve especially use cases with asymmetrical transient packet loss and particularly the DOTS Telemetry, see https://datatracker.ietf.org/doc/html/rfc8782 and https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ Consensus has been reached on the scope, content and level of detail of the document. Document Quality A Pull-Request of an author's implementation to "libcoap" is available at https://github.com/obgm/libcoap/pull/611 Feedback from the implementation activity has contributed to the design and refinement of specific aspects, notably: - Limiting new mechanics for congestion control only to CoAP Non-Confirmable messages. - Not mixing CoAP Confirmable and Non-Confirmable messages for a same request/response body. - The 'Continue' indication of successfully received blocks. - The discovery of server support for the Q-Block1 and Q-Block2 Options. - Further lessons learned highlighted as "Implementation note" in the document. Personnel Document Shepherd: Marco Tiloca Area Director: Francesca Palombini From nobody Fri May 28 07:50:00 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 19D693A2B34 for ; Fri, 28 May 2021 07:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yu83pTH8GAVg for ; Fri, 28 May 2021 07:49:54 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80041.outbound.protection.outlook.com [40.107.8.41]) (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 32C553A2B32 for ; Fri, 28 May 2021 07:49:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H4+uuT5e+kGhNanNCGVuZpznqr3kZdsZv/KXmagnMmtarCcZ49z0eOIkeHkC6l9tJ/vwwZ6KwLK4yXufuDezB92Lwjrs5fv8WElwVf2J3Ukl/pLQ0yDk/9mo55toAFPBFDhZ6ZEOoOaM74vXj5Nj1PYsuq9jlK1VmqH1L6DSvrdmV8dk4aBPH68AolAx3kMJDb0Gxj6oQ48lxZU/1uwVd+sVAavAcdMToMCjBQi0HKzLfTnKxO7ORN8UgjUEFmuNRGi7iVXNsLL2IcGGbgVhy/7D5iwz1/P/g7hKwhKZGGhWBlcTQ7dNctAsXDEiUhlDOKN5v3ACXDm+JtHVI8e3Jw== 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=GLtdTS/eIb9p6hxwY9QoeviDaYLqNSoFC+q+WCvGTBY=; b=INfI3S9osoQOaYyrJjLMeXUMkNhDQWLDw5pgeFH1Yfyc1EUGDTpdxKTTiAnAPFHifcyyHVE62e6y76SQ9yCe4XM0fMLdIoLswseN6rV0+od7u99tzGol32WP6fujacO5FBeC0xpuDqDPzFXZVWx2zsScL71nO4VW+vdwLO39dmEaf1KXafzjbX9aAt3iazNVgOC9BxE4fcbr8UILV8oqw2YyQASBsNWObNA6PvQjwpkUFeAbCFXdn6d9dQJVE2bwtaS3145deQgCln+vINR/HHGXCsNviu99as0AXhRMUYArWXbDgaSLZulFIknY/btIYFbL2cQ+7Fcrul2cMaN6Pg== 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=GLtdTS/eIb9p6hxwY9QoeviDaYLqNSoFC+q+WCvGTBY=; b=beZ1QhFBBiXa/nGBeRre5AWmR+fey+4tiZIQuFki4XBU7fiBZ06jcdXsY62YumVKZ+9KNRqogu3xASki09OedzZ/evWM9j1MvfuGHzB1etj4BB/ZLjx80jey7vHQEU/Uw9sxzmIK/HDs9KzTD2Vn3qBnKGD35LaCDWUBtXqTdMg= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR0702MB3564.eurprd07.prod.outlook.com (2603:10a6:7:8c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.17; Fri, 28 May 2021 14:49:51 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3%11]) with mapi id 15.20.4195.012; Fri, 28 May 2021 14:49:51 +0000 From: John Mattsson To: "core@ietf.org" Thread-Topic: [core] Milestones changed for core WG Thread-Index: AQHTXO5AZbq8L7ulAEuPiR9VF4lwlqsA5ipL Date: Fri, 28 May 2021 14:49:51 +0000 Message-ID: References: <151062561736.6001.11273048980610632399.idtracker@ietfa.amsl.com> In-Reply-To: <151062561736.6001.11273048980610632399.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2aea53a0-c81d-47f5-0c14-08d921e7d96b x-ms-traffictypediagnostic: HE1PR0702MB3564: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +3N1OFX7H2O3bq4XXSezSKvFxqLjbYfqIXTFF23Hz7sLr+8OonLy3xmagXzszJofFI7KaWrgtYvT51hvh/pcLgyHlgXPtVofOb/6FknouPaS1sMVKBGli//V9tKm7dkIi6Qeat9kwgooHvamkZVovxvk95kotW7X7apaHtpsYq5MG3iLLPOWNo3/yTq8Tkx/uolfqzbkPlUAdOMXgmhb85qGBAiMmPeiw9ZXNNLtJj6Q04jH6s624p7ZPKBgr0Uvdaz8P4SunV4z5ivR/LIjbfPSTBCn4PUMGdsBLTVBkuuyrEPkZn+sCb00Bq3jHBceDOKLFsaXfDL8VV4TXSNUPzrD1i4O46de2O1nHmECSKcpvca+4Zi6JczOU+wqEFw9YNdgItOBCE4laascuhLyeP6VBfe7vmgZzBUgAPcG+Epmm98pp35JLj71/jw/UtUdLNxi5bKDZ4m3Pc80+u9vkrTEPRERElM8PUJFdIEuDh+UhI6JsZUyRiOBTahIzHQc7MqGreK1rTv6rICNBvBvgqod0JnPOlZYois4lvk/PyjiRSXV40ahHvcLWr3Nr39zlHNDzwNpreXYmBKY8VHuBoXLSKABB+J2x1pv3Fq0kZg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(376002)(396003)(346002)(39860400002)(83380400001)(316002)(66946007)(38100700002)(64756008)(66446008)(66476007)(122000001)(186003)(9686003)(52536014)(66556008)(33656002)(76116006)(71200400001)(8676002)(8936002)(55016002)(26005)(7696005)(6506007)(53546011)(44832011)(478600001)(4744005)(6916009)(2906002)(5660300002)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?8yawQu4m3Yfwws1wO8bwr63kQx6zBVBhEADYv3odV9V/DSo0YToNdYrNqU+w?= =?us-ascii?Q?tDZVjPJ9OFPV1zZYyKnsj7KFXf3L3d/teBseYYNDVyrPxhkQYqM8UCZwxV5V?= =?us-ascii?Q?vPSjh9vtBe+8n8QaLKAXb1rfMiQ5XXPEKT3L0USILqL7RbNY6TfmSBIdxNBt?= =?us-ascii?Q?7MU1HVCTko2HCscMnHf7DRni77TjVpzG9j2iLK7tXW9UWdLrAbjU2xcEZQjD?= =?us-ascii?Q?NQWf2hcs7rSQoFsPDI1jhZWUVQRW6b96Xf85MO1nhJ4+eH2UuMoQDFLkpZlV?= =?us-ascii?Q?HlhOPPh9ID6Ol6qdcmxeNm7hyn1Ecn7LT9DzI6CXKiCNTASay/LFIuUnKWp3?= =?us-ascii?Q?OPX6KBYuCP1RYb86oLhBeoIywl19ohVkql1yFGL0rQSkDB1jYBXC4EL3jIi8?= =?us-ascii?Q?tAJ+H3FjFrVUQS0M1RFb0Iq9lTW1e2IsxVS4OKmGdcriv4I4km4GOOMrju/V?= =?us-ascii?Q?pk2+ZlN56OPZSc0vCkrl58S38Eosfpic7uCs2aiSM6ucg1mjFn3Z4iTApFzN?= =?us-ascii?Q?brnZ0zC7MGiyJDF5Y8kNlcEEFvEm1eF4tvjWBJkbVmAPWeo9xC3YfM1ewziQ?= =?us-ascii?Q?u42zgq+kaVczuCuvvZD+HdC2stadUmcNJXBHi6G7qU1QyJYykQ0sjVoQx6Tf?= =?us-ascii?Q?NbIw2gDIJo6Ba/eknTIiPhouxT2QxQhKEugCCAF1wxpjJGSU9JECjfbJWaZb?= =?us-ascii?Q?FnRjAlzbk65nTqg8Yz5V0o6fLPUwttmjtidjYCeQZv2p/ORU5lWgUP1FmndG?= =?us-ascii?Q?T17C03udKMHF6vSBL/wjTNuHO/w1Wr9PEtKsfBKNR1MBphxPDflnmbhaFMEx?= =?us-ascii?Q?mhc/GRC/wAhvxRP5EJC03vKgfCEyzH6W+4/B2prhjU8aYRmJn6u1LvlFsyGd?= =?us-ascii?Q?GoBGCKWc3kwdfKwM5u2qvt1eaOFe+a+iuH+krUaATGhjJdd9BdSBfOcOpzLn?= =?us-ascii?Q?h7REFdbC9h26475VeC3rFlI3zjiK1orou2IAt8wASss/cxEYSLskOMflueLn?= =?us-ascii?Q?zvOJ7Cc4Sc5rdRkVfk5YkfOMlxkSEOP+XrFdHYWB/6j9HvvJwfwtnr8rkFKL?= =?us-ascii?Q?PSCSz988fsYgcs4JWWFJcVheSkbu3knHVcd1NORkL+/7m3ULMUbwoQ3jTn+n?= =?us-ascii?Q?YFBAPCWWHM4vkOcPmQFF5O81QpqLNVJolZ1ehyYhn2+Tu4axXQ5gaMyyxPsA?= =?us-ascii?Q?Fn4K68Wu8rNHkOkvGG3SRCI6NLmEY2wiDByWpqvIVTcElmTbq2rmSXDu+o0y?= =?us-ascii?Q?w8XKnYMhKJ5o/qPrr37x0oGN0LJP+FCbzNM6pbD09V79VwgE4R/9q7M0l/Dv?= =?us-ascii?Q?vRCBSpnW8f3+JgzuwwbVrUUou5ndLRclTHyzM5uh5z0PTg=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB3050CF31C1C163C6548DEFD789229HE1PR0701MB3050_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2aea53a0-c81d-47f5-0c14-08d921e7d96b X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2021 14:49:51.7419 (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: o/sMWDGaBoBs3d1Z1jYzc3VSDQyVZDSv4nhYEXNURUfgVVZuj46PxXiYQxgIn4wc3LbeDapwvKyk6EU4wVzku9ce4E4TJOrfJxiLOc61oyA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3564 Archived-At: Subject: Re: [core] Milestones changed for core WG 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, 28 May 2021 14:49:59 -0000 --_000_HE1PR0701MB3050CF31C1C163C6548DEFD789229HE1PR0701MB3050_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maybe time for CORE to update its milestones. It is 42 months since last ti= me :) John From: core on behalf of IETF Secretariat Date: Tuesday, 14 November 2017 at 03:14 To: core@ietf.org Subject: [core] Milestones changed for core WG --_000_HE1PR0701MB3050CF31C1C163C6548DEFD789229HE1PR0701MB3050_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Maybe time for CORE to update its milestones. It is 42 months since l= ast time :)

 

John

 

From: core <core-bounces@ietf.org> on be= half of IETF Secretariat <ietf-secretariat-reply@ietf.org>
Date: Tuesday, 14 November 2017 at 03:14
To: core@ietf.org <core@ietf.org>
Subject: [core] Milestones changed for core WG

--_000_HE1PR0701MB3050CF31C1C163C6548DEFD789229HE1PR0701MB3050_-- From nobody Mon May 31 00:08:52 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 731B73A2235; Mon, 31 May 2021 00:08:47 -0700 (PDT) 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-senml-versions@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <162244492744.31415.2969596725789001184@ietfa.amsl.com> Date: Mon, 31 May 2021 00:08:47 -0700 Archived-At: Subject: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-senml-versions-03=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, 31 May 2021 07:08:48 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-core-senml-versions-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below one non-blocking COMMENT points (but replies would be appreciated), and some nits. Thanks to Jaime Jiménez for his shepherd's write-up (including the WG consensus) even if I regret that no motivation is given about the intended RFC status. Thank you Carsten for acknowledging Jaime's work. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 2.2 -- While the motivation for the update is explained, is there any reason why the usual OLD TEXT / NEW TEXT is not used here? == NITS == -- Section 2 -- Even with the warning in section 1.1, it took me a while to 'see' the Sigma sign (and the   were not helping). Suggest to 'show' it in section 1.1. OTOH, congratulations for using the XMLv3 features for the SVG equivalent, quite neat. The whole text of this section is quite convoluted as it is a plain bit mask. From nobody Mon May 31 02:32: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 B702D3A0CE8 for ; Mon, 31 May 2021 02:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9UCaz3F-Khi for ; Mon, 31 May 2021 02:32:07 -0700 (PDT) Received: from wforward5-smtp.messagingengine.com (wforward5-smtp.messagingengine.com [64.147.123.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A636A3A0CE2 for ; Mon, 31 May 2021 02:32:07 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailforward.west.internal (Postfix) with ESMTP id AEB421216 for ; Mon, 31 May 2021 05:32:05 -0400 (EDT) Received: from imap3 ([10.202.2.53]) by compute6.internal (MEProxy); Mon, 31 May 2021 05:32:05 -0400 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=fm2; bh=A+iW2r puEr/u8QFHbMVES1wuD82nOUKVTSGX2ttamFA=; b=T2R46wiyB6bwhhYmfloLDo 5F6kJGi15WT88V1/UWX7pKp2z5WHvDPoZCz7hcoUGEy0Lr2EbR+phPV3snM86nEL XfaU/2cDsZkgJf6uDpiVwN2FLIlD6qf4pGrb/IQjfI5aj13wPONRGiJR1QdBtXZC ird+B5qWw0Ip7hOan2Vwm+wUuiMjbRk8sTfggQiwo+zXEJH1Jz8MKfbyA2IMDpYD AYpvla03RRj7KF8xbxBqSJuG+Nf/rirKJTJRBYAxxfY6zPP9EM+aDVKQ7Wt8hoF5 B1afUx75IPL5sZKMYS/XkdYiYSpk9NjEMO1WlM1ju7m/a/5iePCxQzOYA2jGYdPw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdelfedgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpeflrghimhgvpgflihhmrohnvgiiuceojhgrihhmvgesihhk ihdrfhhiqeenucggtffrrghtthgvrhhnpedvkefgveevgfdvgfffhfdvfeeutdefffdtge duheevudejuddvteeuheevkeelgeenucffohhmrghinhepihgvthhfrdhorhhgnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjhgrihhmvgesih hkihdrfhhi X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A3B25420082; Mon, 31 May 2021 05:32:04 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-519-g27a961944e-fm-20210531.001-g27a96194 Mime-Version: 1.0 Message-Id: <740226a3-c2ab-44b3-b7cc-fbd4748f9e7b@www.fastmail.com> In-Reply-To: References: <151062561736.6001.11273048980610632399.idtracker@ietfa.amsl.com> Date: Mon, 31 May 2021 12:31:43 +0300 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: core@ietf.org Content-Type: multipart/alternative; boundary=075b436b0b3b4579820c436b98950636 Archived-At: Subject: Re: [core] Milestones changed for core WG 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, 31 May 2021 09:32:13 -0000 --075b436b0b3b4579820c436b98950636 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi John, Marco and I did a small update few months ago, marking some items as "do= ne".=20 We should probably do another round soon.=20 Ciao! --=20 Jaime Jim=C3=A9nez On Fri, May 28, 2021, at 5:49 PM, John Mattsson wrote: > Maybe time for CORE to update its milestones. It is 42 months since la= st time :) > =20 > John > =20 > *From: *core on behalf of IETF Secretariat > *Date: *Tuesday, 14 November 2017 at 03:14 > *To: *core@ietf.org > *Subject: *[core] Milestones changed for core WG > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --075b436b0b3b4579820c436b98950636 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi John,

Marco and I did a small update few months ag= o, marking some items as "done".
We should probably do another round= soon. 

Ciao!
-- 
Jaime Jim=C3=A9nez



On Fri, May 28, 2021, at 5:49 PM, John = Mattsson wrote:

Maybe time for CORE to update its = milestones. It is 42 months since last time :)

 

John

 =

From:= core <core-bounces@ietf.org> on behalf of I= ETF Secretariat <ietf-secretariat-reply@ietf.org>
Date: Tuesday, 14 November 2017 at 03:14
To: core@ietf.org <cor= e@ietf.org>
Subject: [core] Milestones changed for core WG=

_______________________________= ________________
core mailing list


--075b436b0b3b4579820c436b98950636--