From nobody Wed Apr 1 01:19:06 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AA43A0FBC for ; Wed, 1 Apr 2020 01:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6snGpJti1THk for ; Wed, 1 Apr 2020 01:19:02 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30125.outbound.protection.outlook.com [40.107.3.125]) (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 6BBCE3A0FBB for ; Wed, 1 Apr 2020 01:19:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NnfaxEMpEB9PkiNBobZnQpOxf0wKAxdUqrLs3pcazD/ZcIpy84qTs0NXRivkB2FU0P03JFgDGRCxceADs9Cr5nNVXVx5xP9opXqAXoemUz5BX3E9HEDbEF1uROMO7tnUkXnjH9kt3dESpSfAJoedPvTReay3/mwRGFVAj9luQtkjtCIM9V+QDljb+MfxAWmPftD+tePjLPYXLkYNj6AzDkbJJ8eV4/KJ/2kHSYvK01rofXCQvAwXXbEeoTpHb8aYoh2w6IMMNq/jxXs6MPAxihMJmMg1Hh6SMu6zEZf/3i5Rfyd5NK2i8oXPaBIdVYiUG2L8Fqr4jDhMMSLeBwGAag== 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=Z2S68kkntxpQtS0yEjHjjgBn9bSlE1tWkz5ZmC171YQ=; b=RU5Bf06voFjU4YDfpqRIocBd2fILGFra2GQFMFOZ/fk81bTAIUdgQgsQ/68sAwWZpHFgz+IVmZAVsxj4JEsW9tpvvmva82t1bhZpQSrJmIDF1TExiN2ui6VPn6oMYmOErjutcOtuBl6T138SqYZBgajxERZ098UE4PPznpkBgmELqCZ/BvvQkTw9aTQ/k7LtBYluHuF0CddRx3sy2EW37BXNbNzhJFPdPkhDK7q+pyWlNDMLfh4y9UCUuS/AzUO472jNXlyNxQIZTEXw/UjFhb2aWWTCrxouL6IJ9Nkj0Y/O+RMo7bgTvIRGFTjvhina3k4MYNQBkwu20yQ77o+n5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector2-iotconsultancynl-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z2S68kkntxpQtS0yEjHjjgBn9bSlE1tWkz5ZmC171YQ=; b=WtrTJfqX2UZQMoPZ5pPzWcdHMc7UkE2i0ZrPSi4+PR330nTHraqUh/lBdYN8GU7aayWFXTaT0PA0nW7qQpIKQxHAueObnj8apEhsogP7ldWIrvyTgM9CwrcT7gJMLArQ407mGoP57WWXxlLFBEqIb/TYTL2Yq7M66EYlDHsFNe8= Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM (10.161.62.28) by AM5P190MB0244.EURP190.PROD.OUTLOOK.COM (10.161.62.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Wed, 1 Apr 2020 08:18:59 +0000 Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::8c96:a66b:e170:bf8f]) by AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::8c96:a66b:e170:bf8f%3]) with mapi id 15.20.2856.019; Wed, 1 Apr 2020 08:18:59 +0000 From: Esko Dijk To: Jim Schaad , 'Klaus Hartke' CC: 'Achim Kraus' , "core@ietf.org" Thread-Topic: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top Thread-Index: AQHWBAJ4QQxxhgNVoE6+AM1rLNkaVahcnYmAgAAdZICABcLe8IAAHjWAgABVYQCAAP5CIA== Date: Wed, 1 Apr 2020 08:18:58 +0000 Message-ID: References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> In-Reply-To: <011301d6077c$b5d347b0$2179d710$@augustcellars.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl; x-originating-ip: [85.147.167.236] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e9f3f9ef-5a61-48f9-6fb1-08d7d6155423 x-ms-traffictypediagnostic: AM5P190MB0244: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM5P190MB0275.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(396003)(366004)(39830400003)(136003)(346002)(376002)(6506007)(71200400001)(316002)(66446008)(66946007)(64756008)(55016002)(66556008)(44832011)(4326008)(8936002)(7696005)(9686003)(66476007)(26005)(508600001)(110136005)(86362001)(33656002)(81166006)(54906003)(186003)(53546011)(76116006)(8676002)(52536014)(2906002)(5660300002)(81156014); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 32t7o7pr//VbzDALBqh0okFwE7RVhiK0TfdXq3lbans4Tv6NlU+Hnw9XNQT+n4s5eKYAGmfprY7511V7eEEdZg7O6YnW32j8WEK6ho4ZhKj7bCK4EaUR4Q+EzHcH3LgFNsf6pNbPuZfl0wHXaBeRF0Od0vZkDv5Zbb8MDo5gOVBSDDNft0fg8+8VTgOlDsDNN9hpq6haw3vNDnh+PLDv6VTx7Zv63VLQ9fvkG8fIzdaQO63CMTY7D4OD1u+mjNxsVKXqSUTCO/cwIVph1RqtjSLCEI5sQbYtIXB0CfnTnmqZZnybwfwPrL4kmFXybn8r93SrBcGZNl8o3eCruwsShTk/wkClDOEBvTFgW+fulrZGfYKuaEEhHIUu/rs1J1ILy3b4IBSa5fBEH77q4ZojiYccUQyr7KKmawAWLlWipbSXQ+obpdXujA3C7pBfQyZN x-ms-exchange-antispam-messagedata: qFNWtXQC1/hbImgWiaUJy/IV9U+Lof7PubmlkrgEqc1Wt+8OKEr3HSxskfPp8I+SOeQw4TbJABcE9XsR6w+L40wPee5Tl0u2zp42SdnXi/AfHH9Wsn1tj8uMVfULD6/o7D6I7FWKNngJ9m+x+kumbg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-Network-Message-Id: e9f3f9ef-5a61-48f9-6fb1-08d7d6155423 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 08:18:58.9322 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qNlpdXL6fppMY2QxVLf7RoP1+7e46zcuUOnvVHGhsmJPwIi/bfTv2WvtOLo856KdwROn4bbZSJkmrN0ltHMFn417gIZows45etIhXBVO2Yc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0244 Archived-At: Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top 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, 01 Apr 2020 08:19:05 -0000 VGhhbmtzIEtsYXVzICYgSmltLCANCg0KaXQgaXMgY2xlYXIgdG8gbWUgbm93IGhvdyB5b3Ugdmll dyB0aGUgZW5kcG9pbnQgY29uY2VwdCBmb3IgbXVsdGljYXN0IG1lc3NhZ2VzLiBCZWNhdXNlICh0 byBtZSkgdGhpcyBpcyBub3QgZnVsbHkgY29tcGF0aWJsZSB3aXRoIHRoZSBkZWZpbml0aW9ucyBv ZiAiZW5kcG9pbnQiIGFuZCBtZXNzYWdpbmcgbW9kZWwgaW4gUkZDIDcyNTIgdGhhdCBJIHF1b3Rl ZCwgaXQgd291bGQgYmUgZ29vZCB0byBjbGFyaWZ5IHRoaXMgYXNwZWN0IG1vcmUgaW4gZHJhZnQt aWV0Zi1jb3JlLWdyb3VwY29tbS1iaXMgaS5lLiByZWZpbmUgdGhlIFJGQyA3MjUyIGVuZHBvaW50 IGRlZmluaXRpb25zIGZvciB0aGUgbXVsdGljYXN0IGNhc2UgYW5kIGNsYXJpZnkgdGhlIG11bHRp Y2FzdCBtZXNzYWdpbmcgbW9kZWwuICBJIGd1ZXNzIHRoZSByYXRpb25hbGUgZm9yIHRoZSAibWFp bGluZyBsaXN0IiB0eXBlIGJlaGF2aW9yIGlzIHRoYXQgdGhlIHJlY2VpdmluZyBub2RlIGFueWhv dyBjaGFuZ2VzIHRoZSBlbmRwb2ludCAoYnkgY2hhbmdpbmcgbXVsdGljYXN0IElQIGFkZHJlc3Mg dG8gYSB1bmljYXN0IElQIGFkZHJlc3MpIHNvIGl0IGNvdWxkIGNoYW5nZSB0aGUgcG9ydCBudW1i ZXIgYXMgd2VsbCwgdGhlIHJlc3BvbmRpbmcgZW5kcG9pbnQgd2lsbCBhbnlob3cgYmUgZGlmZmVy ZW50LiAoVG8gbWUgdGhhdCB3YXMgdW5leHBlY3RlZCBhbmQgZmVlbHMgbm90IGVudGlyZWx5IHJp Z2h0ICAtIHBvcnQgbnVtYmVyIHNob3VsZCBub3QgbmVlZCB0byBjaGFuZ2UsIGJ1dCBJIGNhbiBs aXZlIHdpdGggaXQuKQ0KDQpJJ20gYXNzdW1pbmcgYnkgbm93IHRoZXJlIGFyZSBubyBkaWZmZXJl bnQgb3BpbmlvbnMgZnJvbSB0aGUgbGlzdCBvbiB0aGlzIHF1ZXN0aW9uIGFueW1vcmUsIHNvIEkn bGwgcHJvY2VlZCB3aXRoIHNvbWUgdGV4dCBmb3IgZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS1i aXMuIE1heWJlIGEgIlNIT1VMRCIgbGV2ZWwgcmVxdWlyZW1lbnQgb24ga2VlcGluZyB0aGUgVURQ IHBvcnQgbnVtYmVyIHRoZSBzYW1lPyBBbmQgaW5kaWNhdGUgaWYgdGhlcmUgYXJlIGFueSBnb29k IHJlYXNvbnMgdG8gY2hhbmdlIHBvcnQgbnVtYmVyIHRoZSBzZXJ2ZXIgY2FuIGRvIGp1c3QgdGhh dC4NCg0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSmltIFNjaGFh ZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4gDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAzMSwgMjAy MCAxODo1Mg0KVG86ICdLbGF1cyBIYXJ0a2UnIDxoYXJ0a2VAcHJvamVjdGNvb2wuZGU+OyBFc2tv IERpamsgPGVza28uZGlqa0Bpb3Rjb25zdWx0YW5jeS5ubD4NCkNjOiAnQWNoaW0gS3JhdXMnIDxh Y2hpbWtyYXVzQGdteC5uZXQ+OyBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW2NvcmVdIFJG QyA3MjUyIC0gOC4yIC0gTXVsdGljYXN0IC0gUmVxdWVzdCAvIFJlc3BvbnNlIExheWVyLCBwYWdl IDY3LCB0b3ANCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBLbGF1cyBI YXJ0a2UgPGhhcnRrZUBwcm9qZWN0Y29vbC5kZT4gDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAzMSwg MjAyMCA0OjQ2IEFNDQpUbzogRXNrbyBEaWprIDxlc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmw+ DQpDYzogQWNoaW0gS3JhdXMgPGFjaGlta3JhdXNAZ214Lm5ldD47IEppbSBTY2hhYWQgPGlldGZA YXVndXN0Y2VsbGFycy5jb20+OyBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIFJG QyA3MjUyIC0gOC4yIC0gTXVsdGljYXN0IC0gUmVxdWVzdCAvIFJlc3BvbnNlIExheWVyLCBwYWdl IDY3LCB0b3ANCg0KRXNrbyBEaWprIHdyb3RlOg0KPiBIb3dldmVyIENvQVAgZG9lcyBkZWZpbmUg dGhhdCBhIFNlcnZlciByZXNwb25kcyBmcm9tIHRoZSBzYW1lIGVuZHBvaW50IHRoYXQgcmVjZWl2 ZWQgdGhlIHJlcXVlc3QsIEkgYmVsaWV2ZS4gU2VlIGJlbG93IHRleHQgcXVvdGVzIGFuZCBhbmFs eXNpcy4NCg0KWWVzLiBJbiB0aGUgc2ltcGxlIENvQVAtb3Zlci1VRFAgdW5pY2FzdCBOb1NlYyBj YXNlLCBpZiBhIHJlcXVlc3QgbWVzc2FnZSBpcyBzZW50IGZyb20gYW4gZW5kcG9pbnQgMTkyLjE2 OC4wLjE6NTQzMjEgKCJjbGllbnQiKSB0byBhbiBlbmRwb2ludCAxOTIuMTY4LjAuMTAwOjU2ODMg KCJzZXJ2ZXIiKSwgdGhlIHJlc3BvbnNlIG1lc3NhZ2UgbXVzdCBiZSBzZW50IGZyb20gdGhlIGVu ZHBvaW50IDE5Mi4xNjguMC4xMDA6NTY4MyB0byB0aGUgZW5kcG9pbnQgMTkyLjE2OC4wLjE6NTQz MjEuDQoNClRoZSByZXNwb25zZSBtZXNzYWdlIGNhbm5vdCBiZSBzZW50IGZyb20gYW55IG90aGVy IGVuZHBvaW50LCBiZWNhdXNlIHRoZW4gdGhlIGNsaWVudCBjb3VsZG4ndCBtYXRjaCB0aGUgaW5j b21pbmcgbWVzc2FnZSB0byBpdHMgcGVuZGluZyByZXF1ZXN0IChpdCB3b3VsZCBhcHBlYXIgdG8g Y29tZSBmcm9tIGEgZGlmZmVyZW50IHNlcnZlcikuIFRoZSByZXNwb25zZSBtZXNzYWdlIGFsc28g Y2Fubm90IGJlIHNlbnQgdG8gYW55IG90aGVyIGVuZHBvaW50LCBiZWNhdXNlIHRoZW4gdGhlIGNs aWVudCB3b3VsZG4ndCBnZXQgdGhlIG1lc3NhZ2UgKGl0IHdvdWxkIGJlIHNlbnQgdG8gYSBkaWZm ZXJlbnQgY2xpZW50KS4NCg0KSSB2aWV3IG11bHRpY2FzdCBtZXNzYWdlcyBiYXNpY2FsbHkgbGlr ZSBlLW1haWwgbWFpbGluZyBsaXN0cy4gRS5nLg0KKElNTyk6IEEgcmVxdWVzdCBtZXNzYWdlIGlz IHNlbnQgZnJvbSB0aGUgZW5kcG9pbnQgMTkyLjE2OC4wLjE6NTQzMjEgdG8gdGhlIHNwZWNpYWwg ZW5kcG9pbnQgMjI0LjAuMS4xODc6OTk5OSwgdGhlIG1lc3NhZ2UgbWFnaWNhbGx5IHNob3dzIHVw IGFzIGluY29taW5nIG1lc3NhZ2UgYXQgdGhlIGVuZHBvaW50IDE5Mi4xNjguMC4xMDA6NTY4Mywg YW5kIHRoZSByZXNwb25zZSBtZXNzYWdlIG11c3QgYmUgc2VudCBmcm9tIHRoZSBlbmRwb2ludCAx OTIuMTY4LjAuMTAwOjU2ODMgdG8gdGhlIGVuZHBvaW50IDE5Mi4xNjguMC4xOjU0MzIxLg0KDQpb SkxTXSBXaGF0IGhlIHNhaWQuICBBbmQgdGhlbiBhZnRlciB0aGUgZmlyc3QgbWVzc2FnZSBjb21l cyBpbiBmcm9tIDE5Mi4xNjguMC4xMDA6NTY4MywgYWxsIG9mIHRoZSBtZXNzYWdlcyBmcm9tIHRo YXQgZW5kcG9pbnQgYXJlIGNvcnJlbGF0ZWQgdG9nZXRoZXIgc28gdGhhdCB5b3UgY2FuIGRvIHRo aW5ncyBsaWtlIGJsb2Nrd2lzZS4NCg0KS2xhdXMNCg0K From nobody Wed Apr 1 01:45:48 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4203A0736 for ; Wed, 1 Apr 2020 01:45:47 -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, FREEMAIL_FROM=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 2OB7M7M6PMG3 for ; Wed, 1 Apr 2020 01:45:45 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 C681E3A073E for ; Wed, 1 Apr 2020 01:45:45 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id f16so22231210ilj.9 for ; Wed, 01 Apr 2020 01:45:45 -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=omgtOdwtY1qf0L8DBixSxsIcvsRroOKVzPHXU6dEAJE=; b=rF2zo2a6UyBk7D7unlnRzXaL9yzHwrMkMsce0BmCUOKNF56twRBqPuY0oDrxu0e0JY jgu31pD9Crvf1rq8gOoBaYBCOyt3/3tt5SvD/gNoL48xsLgu8DhpWiE1JJnigZ9fdis4 hSv+n2jVOqKrWyb9zhYoo7ih+Lvy5xKZZ1PKMkBMnl1u1rz9JL0LoD9aWWgJ1HwZKdWc 27xByzrEv/9Cob8SloDC6/dyofBkwOetHBfSfhjcps4gNvCXhrSvuP/X80I7Pdv8vxdQ W1FU5fFD5xCl9QyZoaHVNAENCoZH+wITgUb62Wc5mxFffVQmXWOQTPBuUA4mPvrF8ziY mOxQ== 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=omgtOdwtY1qf0L8DBixSxsIcvsRroOKVzPHXU6dEAJE=; b=qHKYqM5xd0SsYE0k4tpnzKMDie2KeafYn4YkFvvhM0zZGNTKW3dxXwfdOAxLF9J9gn 1CLE30Zvy80jwVtewS4IZ7f6VuOA2gJV/uL6Uvk8KCkCUTfBm1LGuiK4cEfjmbcd/C+U NwlOmoccQwzFQgWK5Z+UU8rQTqtVUxqG/EY+A0Dd/qcG0UpoT47RcQ7Yi8r4KvOGLx2A kjCAxS/LTPav73KR+wkx3ZzRdqcQlMvZZyz92wkodarYRpDt6VWLkyQyXmvXGUsa8YWo WyBud87Q8WI90pi6XdQiDgNcgSX2IdnF1LDJfdwaTpMwQaKOFHsfyOcEKboi8TnTnq/8 LY5w== X-Gm-Message-State: ANhLgQ08NoCzcRJjkfJnOgwYYIxT2+D0l8iajaZqbv1WYzCZm2RxckQG KXFzg5FQXCB8h3WijHsXrwJ5ygOISB3bo8e/iTV+4lmp X-Google-Smtp-Source: ADFU+vvqR27678OdlbTmEwNqQpHfdc304URW9Oq1sl7RsUt53bXcDoXAe1D7VeS/fk0WOiaVZLMQSd2FPp/1OfgUXhA= X-Received: by 2002:a05:6e02:90:: with SMTP id l16mr21389721ilm.294.1585730745044; Wed, 01 Apr 2020 01:45:45 -0700 (PDT) MIME-Version: 1.0 References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> In-Reply-To: From: Thomas Fossati Date: Wed, 1 Apr 2020 09:45:33 +0100 Message-ID: To: Esko Dijk Cc: Jim Schaad , Klaus Hartke , "core@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top 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, 01 Apr 2020 08:45:47 -0000 Hi Esko, all, On Wed, Apr 1, 2020 at 9:19 AM Esko Dijk wrote: > (To me that was unexpected and feels not entirely right - port number should not need to change, but I can live with it.) I have the same trouble as you understanding the port mapping part. Where is that supposed to happen (kernel, CoAP stack, application)? And why is it needed? > I'm assuming by now there are no different opinions from the list on this question anymore, so I'll proceed with some text for draft-ietf-core-groupcomm-bis. I don't have an opinion yet, but I'd need some clarification about the above before feeling comfortable with the direction... Cheers, thank you! From nobody Wed Apr 1 01:49:52 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5614D3A0778; Wed, 1 Apr 2020 01:49:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu via Datatracker To: Cc: draft-ietf-core-stateless.all@ietf.org, last-call@ietf.org, core@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158573098630.30833.17715509721846547699@ietfa.amsl.com> Reply-To: Dan Romascanu Date: Wed, 01 Apr 2020 01:49:46 -0700 Archived-At: Subject: [core] Genart last call review of draft-ietf-core-stateless-05 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, 01 Apr 2020 08:49:47 -0000 Reviewer: Dan Romascanu Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-core-stateless-05 Reviewer: Dan Romascanu Review Date: 2020-04-01 IETF LC End Date: 2020-04-02 IESG Telechat date: Not scheduled for a telechat Summary: READY with Issues. This is a very clear and well-written document. I have a few minor issues that I suggest to clarify before approval and publication. Major issues: Minor issues: 1. It would be useful to include some considerations whether the authors consider useful / possible / allowed that the mechanism (extended token lengths) presented in this document can be used for other purposed than the by-design the use case (avoiding per-request state). 2. In Section 2.2: > The idea is that a server implementing this document should at least support large tokens in its first few processing steps, enough to return an error response rather than a Reset message. Why is not this 'should' capitalized? What happens if the server does not support large tokens in the first processing steps? 3. In Section 5.2: > The use of encryption, integrity protection, and replay protection of serialized state is recommended in general, unless a careful analysis of any potential attacks to security and privacy is performed. AES- CCM with a 64 bit tag is recommended, combined with a sequence number and a replay window. Where encryption is not needed, HMAC-SHA-256, combined with a sequence number and a replay window, may be used. A few issues with this paragraph. Why are not 'recommended' and 'may' capitalized? The formulation 'is recommended in general' seems odd, and the rest of the sentence does not clarify. What does 'a careful analysis of any potential attacks' mean? Who is supposed to perform this analysis and who can ensure it is 'careful enough' at any given point in time for any potential attacks? Nits/editorial comments: 1. I do not believe there is a need to mention in the Abstract that 'This document updates RFCs 7252 and 8323.'. This is shown in the header of the text on the front page, and also is part of the metadata. 2. Are the message formats defined in Appendix A for different transports considered normative or examples? It would be useful to specify. From nobody Wed Apr 1 03:27:58 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9923A046A; Wed, 1 Apr 2020 03:27:56 -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, DKIMWL_WL_HIGH=-0.001, 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 YgVrrX3-PirQ; Wed, 1 Apr 2020 03:27:54 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2060a.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::60a]) (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 5085B3A045E; Wed, 1 Apr 2020 03:27:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E1gYs0SNZqhghA1SKvfzDKojVaSTSnqm2mORI31j5e9xxgpDHaVGT5AP1G/OVRhSeTEHgAFbAzn4QxhfLHhNnIzRJ0CLMM7MqdcVeAK2hKvPuN6lvWw8WgtoPLq+QveO+EcnNnt0mIVxpit3ReJJeiva0jHqxCTyVRS/Pa/l7RpUXDg2DnlZzeY9p4iVw8rCccSKqENQkP17bEfV1ExolefVTWEJsj1vGGblF44cV4cMmCCWwxrbVGgHTW69//JS3jEfVtvRA/W2TFVijGwMkB9JUUXPWZMqJDE7vQ27jagHGSJXo5LrhpC0X/Y/nNDv2UjWi14maJYxDOoY8ZyoXw== 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=irPgiowTZuM3JZ9zvoUUkvlfAbuZdbkjtZWCJcfBouI=; b=JK6dHSm9+skUXLGwe3ywcrm2IMUcgOx25Yvi6BBRIjyz6W0SjBIgdengtOvZTHrsf1lbei0ur/+abtEP2xEVNUC4yvw8H2HlZZa8HMbXq4CWiWbtR2HJbw4y6qzT0ozEFVAwF9W9DiUqz34A0CYh7bEeJuZMjlmBnRw63/NHFwroEn3A0NklIKFTo2oQsGk9LOeDgGDMkuvVd5nWuZHbWl0gb7XTHs8rEGeRpFsiV7EXTLayzUxVKdX7r37ayWRNH7nFmNl329/yHRC3ECoNmMl3qruyk1DI4UiDjJX78yj3g4pgOX+u8FLtgK3VDIwvFf1QpvNr115PJspM9W+0MA== 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=irPgiowTZuM3JZ9zvoUUkvlfAbuZdbkjtZWCJcfBouI=; b=fNbZBcY2/fiwHZGN4/3g71hjJYsXn4z7nA/znExB6nMOOuvgSEeuQ3xxHm2h2IgXV3pGAHRgyxbojQseQ800YQIZrVHvC7zP/8eyxZfnpfM5NBPdZ4bp6lMOzp9IYau82Q6x6wg9lso7Ezp6LEFQ6c8ljrXCqAkraiKtNw0O7dc= Received: from HE1PR07MB4346.eurprd07.prod.outlook.com (20.176.162.138) by HE1PR07MB4345.eurprd07.prod.outlook.com (20.176.164.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.13; Wed, 1 Apr 2020 10:27:51 +0000 Received: from HE1PR07MB4346.eurprd07.prod.outlook.com ([fe80::e15f:e9fc:6df3:addb]) by HE1PR07MB4346.eurprd07.prod.outlook.com ([fe80::e15f:e9fc:6df3:addb%4]) with mapi id 15.20.2878.014; Wed, 1 Apr 2020 10:27:51 +0000 From: Klaus Hartke To: Dan Romascanu , "gen-art@ietf.org" CC: "draft-ietf-core-stateless.all@ietf.org" , "last-call@ietf.org" , "core@ietf.org" Thread-Topic: Genart last call review of draft-ietf-core-stateless-05 Thread-Index: AQHWCAKD8N/HP8w1VEasHYVJq2mkJ6hj94eQ Date: Wed, 1 Apr 2020 10:27:51 +0000 Message-ID: References: <158573098630.30833.17715509721846547699@ietfa.amsl.com> In-Reply-To: <158573098630.30833.17715509721846547699@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=klaus.hartke@ericsson.com; x-originating-ip: [145.14.112.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 31d281f2-7318-42b9-62fc-08d7d6275525 x-ms-traffictypediagnostic: HE1PR07MB4345: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4346.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(346002)(376002)(366004)(316002)(64756008)(5660300002)(52536014)(110136005)(44832011)(55016002)(2906002)(66946007)(66446008)(76116006)(66476007)(66556008)(186003)(26005)(33656002)(8936002)(54906003)(81166006)(9686003)(478600001)(6506007)(86362001)(81156014)(8676002)(7696005)(71200400001)(4326008); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FFLGP1opJpBOVZbPebYfdj/cSy/Hjee+GgaLZ4SwRPhbNGsVd/rSey7WaHXsWtFzwFyhMTPJwhGc7GZAm6Lbn6dD41es1GhiI+ruywP1Jha0BkgZBzB4FIYfgiwA9UxXaq+dDUF1W78tA0s6Xj33McY/biCTDyB3W0I5Dp5QCllwHKYEMnmM4alEi0Nn976YNz9h6o2hDQTpJktidoIijHJF0c7e2r0o6dCYLMIncNytmuTa+nSxFYMoLD8xAQK9imiPmbhiGlCxYHkVa+MrvIa4TZ1gx2/SZ+3dKbQneUIbnP8d+X7RZGX/RV03geqjQbyuTLyVCq78alyOwr8LiVwOdaUvQvLQxOr1chH+p4VNwVo12aNYDKnJvSNwjR8MsjluLYsGjm5m9zoNavKnJhDIx2tyWIGYAX2dUp/wiYRHpEnycpoqgI73QSkLCrRg x-ms-exchange-antispam-messagedata: dAvLWXkmlzPzxERRj10IQtxNlnyEiKq7DOg9Yuu6PMzihZceK7Mi9E1mtrgmu0VF+pXPIDQt9G0B/er/3vRiwxPQTtW02nYUY21zjVV8DhGg8IRr3pr1uaMHnr9rNTnSltJypegW/0EehgQyuGweVw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 31d281f2-7318-42b9-62fc-08d7d6275525 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 10:27:51.5207 (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: 7OSQMLlEtovTImMkxXzD8Wce3WcDlnXCaVVDHGa7JKxzCTNWq8Jw3jrj+COWMCtCZNFit+Yo3qEvDvD5Qb92Y8fDY2aIG2JmodxDh3Kks6Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4345 Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-stateless-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 10:27:56 -0000 RGFuIFJvbWFzY2FudSB3cm90ZToNCj4gVGhpcyBpcyBhIHZlcnkgY2xlYXIgYW5kIHdlbGwtd3Jp dHRlbiBkb2N1bWVudC4gSSBoYXZlIGEgZmV3IG1pbm9yIGlzc3VlcyB0aGF0DQo+IEkgc3VnZ2Vz dCB0byBjbGFyaWZ5IGJlZm9yZSBhcHByb3ZhbCBhbmQgcHVibGljYXRpb24uDQoNCk1hbnkgdGhh bmtzIGZvciB5b3VyIHJldmlldyENCg0KPiAxLiBJdCB3b3VsZCBiZSB1c2VmdWwgdG8gaW5jbHVk ZSBzb21lIGNvbnNpZGVyYXRpb25zIHdoZXRoZXIgdGhlIGF1dGhvcnMNCj4gY29uc2lkZXIgdXNl ZnVsIC8gcG9zc2libGUgLyBhbGxvd2VkIHRoYXQgdGhlIG1lY2hhbmlzbSAoZXh0ZW5kZWQgdG9r ZW4NCj4gbGVuZ3RocykgcHJlc2VudGVkIGluIHRoaXMgZG9jdW1lbnQgY2FuIGJlIHVzZWQgZm9y IG90aGVyIHB1cnBvc2VkIHRoYW4NCj4gdGhlIGJ5LWRlc2lnbiB0aGUgdXNlIGNhc2UgKGF2b2lk aW5nIHBlci1yZXF1ZXN0IHN0YXRlKS4NCg0KVGhlIGxhc3QgcGFyYWdyYXBoIGluIFNlY3Rpb24g MSBzYXlzOg0KDQogICBXaGlsZSB0aGUgdXNlIGNhc2UgKGF2b2lkaW5nIHBlci1yZXF1ZXN0IHN0 YXRlKSBhbmQgdGhlIG1lY2hhbmlzbQ0KICAgKGV4dGVuZGVkIHRva2VuIGxlbmd0aHMpIHByZXNl bnRlZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBjbG9zZWx5DQogICByZWxhdGVkLCBib3RoIGNhbiBi ZSB1c2VkIGluZGVwZW5kZW50bHkgb2YgZWFjaCBvdGhlcjogU29tZQ0KICAgaW1wbGVtZW50YXRp b25zIG1heSBiZSBhYmxlIHRvIGZpdCB0aGVpciBzdGF0ZSBpbiBqdXN0IDggYnl0ZXM7IHNvbWUN CiAgIGltcGxlbWVudGF0aW9ucyBtYXkgaGF2ZSBvdGhlciB1c2UgY2FzZXMgZm9yIGV4dGVuZGVk IHRva2VuIGxlbmd0aHMuDQoNCkRvZXMgdGhhdCBzb2x2ZSB5b3VyIGlzc3VlPw0KDQo+IDIuIElu IFNlY3Rpb24gMi4yOg0KPg0KPiA+ICBUaGUgaWRlYSBpcyB0aGF0IGEgc2VydmVyIGltcGxlbWVu dGluZw0KPiAgICAgICB0aGlzIGRvY3VtZW50IHNob3VsZCBhdCBsZWFzdCBzdXBwb3J0IGxhcmdl IHRva2VucyBpbiBpdHMgZmlyc3QNCj4gICAgICAgZmV3IHByb2Nlc3Npbmcgc3RlcHMsIGVub3Vn aCB0byByZXR1cm4gYW4gZXJyb3IgcmVzcG9uc2UgcmF0aGVyDQo+ICAgICAgIHRoYW4gYSBSZXNl dCBtZXNzYWdlLg0KPg0KPiBXaHkgaXMgbm90IHRoaXMgJ3Nob3VsZCcgY2FwaXRhbGl6ZWQ/IFdo YXQgaGFwcGVucyBpZiB0aGUgc2VydmVyIGRvZXMgbm90DQo+IHN1cHBvcnQgbGFyZ2UgdG9rZW5z IGluIHRoZSBmaXJzdCBwcm9jZXNzaW5nIHN0ZXBzPw0KDQpJZiB0aGUgc2VydmVyIGRvZXMgbm90 IHN1cHBvcnQgbGFyZ2UgdG9rZW5zIGluIHRoZSBmaXJzdCBwcm9jZXNzaW5nIHN0ZXBzLCBpdCB3 aWxsIGxpa2VseSBpbmNvcnJlY3RseSBpbmRpY2F0ZSB0aGF0IGV4dGVuZGVkIHRva2VuIGxlbmd0 aHMgYXJlIG5vdCBzdXBwb3J0ZWQgYXQgYWxsLiBUaGlzIGlzIHdoYXQgdGhlICdNVVNUIE5PVCcg aW4gdGhlIHByZWNlZGluZyBwYXJhZ3JhcGggcHJldmVudHM6DQoNCiAgIElmIGEgc2VydmVyIHN1 cHBvcnRzIGV4dGVuZGVkIHRva2VuIGxlbmd0aHMgYnV0IHJlY2VpdmVzIGEgcmVxdWVzdA0KICAg d2l0aCBhIHRva2VuIG9mIGEgbGVuZ3RoIGl0IGlzIHVud2lsbGluZyBvciB1bmFibGUgdG8gaGFu ZGxlLCBpdCBNVVNUDQogICBOT1QgcmVqZWN0IHRoZSBtZXNzYWdlLCBhcyB0aGF0IHdvdWxkIGlt cGx5IHRoYXQgZXh0ZW5kZWQgdG9rZW4NCiAgIGxlbmd0aHMgYXJlIG5vdCBzdXBwb3J0ZWQgYXQg YWxsLg0KDQpUaGUgZGVzaWduIG5vdGUgcHJvdmlkZXMganVzdCBhZGRpdGlvbmFsIGNvbW1lbnRh cnkgb24gdGhpcyAnTVVTVCBOT1QnOyBpdCBkb2Vzbid0IGFkZCBhbnkgbmV3IHJlcXVpcmVtZW50 cy4NCg0KPiAzLiBJbiBTZWN0aW9uIDUuMjoNCj4NCj4gPiBUaGUgdXNlIG9mIGVuY3J5cHRpb24s IGludGVncml0eSBwcm90ZWN0aW9uLCBhbmQgcmVwbGF5IHByb3RlY3Rpb24gb2YNCj4gICAgc2Vy aWFsaXplZCBzdGF0ZSBpcyByZWNvbW1lbmRlZCBpbiBnZW5lcmFsLCB1bmxlc3MgYSBjYXJlZnVs IGFuYWx5c2lzDQo+ICAgIG9mIGFueSBwb3RlbnRpYWwgYXR0YWNrcyB0byBzZWN1cml0eSBhbmQg cHJpdmFjeSBpcyBwZXJmb3JtZWQuICBBRVMtDQo+ICAgIENDTSB3aXRoIGEgNjQgYml0IHRhZyBp cyByZWNvbW1lbmRlZCwgY29tYmluZWQgd2l0aCBhIHNlcXVlbmNlIG51bWJlcg0KPiAgICBhbmQg YSByZXBsYXkgd2luZG93LiAgV2hlcmUgZW5jcnlwdGlvbiBpcyBub3QgbmVlZGVkLCBITUFDLVNI QS0yNTYsDQo+ICAgIGNvbWJpbmVkIHdpdGggYSBzZXF1ZW5jZSBudW1iZXIgYW5kIGEgcmVwbGF5 IHdpbmRvdywgbWF5IGJlIHVzZWQuDQo+DQo+IEEgZmV3IGlzc3VlcyB3aXRoIHRoaXMgcGFyYWdy YXBoLiBXaHkgYXJlIG5vdCAncmVjb21tZW5kZWQnIGFuZCAnbWF5Jw0KPiBjYXBpdGFsaXplZD8g VGhlIGZvcm11bGF0aW9uICdpcyByZWNvbW1lbmRlZCBpbiBnZW5lcmFsJyBzZWVtcyBvZGQsIGFu ZA0KPiB0aGUgcmVzdCBvZiB0aGUgc2VudGVuY2UgZG9lcyBub3QgY2xhcmlmeS4gV2hhdCBkb2Vz ICdhIGNhcmVmdWwgYW5hbHlzaXMgb2YgYW55DQo+IHBvdGVudGlhbCBhdHRhY2tzJyBtZWFuPyBX aG8gaXMgc3VwcG9zZWQgdG8gcGVyZm9ybSB0aGlzIGFuYWx5c2lzIGFuZCB3aG8NCj4gY2FuIGVu c3VyZSBpdCBpcyAnY2FyZWZ1bCBlbm91Z2gnIGF0IGFueSBnaXZlbiBwb2ludCBpbiB0aW1lIGZv ciBhbnkgcG90ZW50aWFsDQo+IGF0dGFja3M/DQoNCkFGQUlLLCB0aGUgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgc2VjdGlvbiBpcyBzdXBwb3NlZCB0byBkaXNjdXNzIHNlY3VyaXR5LXJlbGF0ZWQg aXNzdWVzIHRoYXQgdXNlcnMgbmVlZCB0byBiZSBhd2FyZSBvZiwgYnV0IG5vdCBtYWtlIG5vcm1h dGl2ZSBzdGF0ZW1lbnRzLiBTbyBhbGwgdGhlIG5vcm1hdGl2ZSByZXF1aXJlbWVudHMgYXJlIGlu IFNlY3Rpb24gMy4xLiAoV2hlcmUgJ3VzZXJzJyBpbiB0aGlzIGNhc2UgYXJlIGltcGxlbWVudGF0 aW9ucyBhbmQgc3BlY2lmaWNhdGlvbnMgdGhhdCBkZWNpZGUgdG8gbWFrZSB1c2Ugb2YgdGhpcyBp bXBsZW1lbnRhdGlvbiBzdHJhdGVneSBpbiBjbGllbnRzLikNCg0KT3ZlcmFsbCwgaXQncyBhIGJp dCBkaWZmaWN1bHQgdG8gbWFrZSBub3JtYXRpdmUgcmVxdWlyZW1lbnRzIGhlcmUsIGJlY2F1c2Ug dGhlc2UgYXJlIHVzdWFsbHkgYWJvdXQgdGhlIGludGVyb3BlcmFiaWxpdHkgZS5nLiBvZiBhIGNs aWVudCBhbmQgYSBzZXJ2ZXIuIEJ1dCBpbiB0aGlzIGNhc2UsIHRoZSBjbGllbnQgb25seSBuZWVk cyB0byBpbnRlcm9wZXJhdGUgd2l0aCBpdHNlbGYgKGl0IG5lZWRzIHRvIGFjY2VwdCBhIHRva2Vu IHRoYXQgaXQgY3JlYXRlZCBpdHNlbGYpIGFuZCB0aGUgb25seSByZWFsIHJlcXVpcmVtZW50IGlz IHRoYXQgImNsaWVudCBpbXBsZW1lbnRhdGlvbnMgTVVTVCBOT1QgYmUgdnVsbmVyYWJsZSB0byBt YWxpY2lvdXNseSBjcmFmdGVkIHRva2VucyIuIFRoZSBtZWFuaW5nIG9mICJ2dWxuZXJhYmxlIiBh bmQgIm1hbGljaW91cyIgaGVyZSBkZXBlbmRzIGEgbG90IG9uIHRoZSBhcHBsaWNhdGlvbi9kZXBs b3ltZW50LXNwZWNpZmljIGNvbnRleHQ7IHRoZSBkb2N1bWVudCBjYW4gcmVhbGx5IGp1c3QgaGln aGxpZ2h0IHNvbWUgcG90ZW50aWFsIGlzc3VlcyB0aGF0IHVzZXJzIHNob3VsZCB0YWtlIGludG8g Y29uc2lkZXJhdGlvbi4NCg0KSSdtIG9wZW4gdG8gY29uY3JldGUgc3VnZ2VzdGlvbnMgZm9yIHRl eHQgaW1wcm92ZW1lbnRzLCB0aG91Z2guDQoNCj4gMS4gSSBkbyBub3QgYmVsaWV2ZSB0aGVyZSBp cyBhIG5lZWQgdG8gbWVudGlvbiBpbiB0aGUgQWJzdHJhY3QgdGhhdCAnVGhpcw0KPiBkb2N1bWVu dCB1cGRhdGVzIFJGQ3MgNzI1MiBhbmQgODMyMy4nLiBUaGlzIGlzIHNob3duIGluIHRoZSBoZWFk ZXIgb2YgdGhlDQo+IHRleHQgb24gdGhlIGZyb250IHBhZ2UsIGFuZCBhbHNvIGlzIHBhcnQgb2Yg dGhlIG1ldGFkYXRhLg0KDQpXaXRob3V0LCBpZG5pdHMgcmVwb3J0czoNCg0KICAtLSBUaGUgZHJh ZnQgaGVhZGVyIGluZGljYXRlcyB0aGF0IHRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkM3MjUyLCBi dXQgdGhlDQogICAgIGFic3RyYWN0IGRvZXNuJ3Qgc2VlbSB0byBtZW50aW9uIHRoaXMsIHdoaWNo IGl0IHNob3VsZC4NCg0KICAtLSBUaGUgZHJhZnQgaGVhZGVyIGluZGljYXRlcyB0aGF0IHRoaXMg ZG9jdW1lbnQgdXBkYXRlcyBSRkM4MzIzLCBidXQgdGhlDQogICAgIGFic3RyYWN0IGRvZXNuJ3Qg c2VlbSB0byBtZW50aW9uIHRoaXMsIHdoaWNoIGl0IHNob3VsZC4NCg0KPiAyLiBBcmUgdGhlIG1l c3NhZ2UgZm9ybWF0cyBkZWZpbmVkIGluIEFwcGVuZGl4IEEgZm9yIGRpZmZlcmVudCB0cmFuc3Bv cnRzDQo+IGNvbnNpZGVyZWQgbm9ybWF0aXZlIG9yIGV4YW1wbGVzPyBJdCB3b3VsZCBiZSB1c2Vm dWwgdG8gc3BlY2lmeS4NCg0KU2VjdGlvbiAyLjEgbm9ybWF0aXZlbHkgZGVmaW5lcyB0aGUgbmV3 IG1lc3NhZ2UgZm9ybWF0cyBhcyBhICJkZWx0YSIgdG8gUkZDcyA3MjUyIGFuZCA4MzIzLiBUaGUg YXBwZW5kaXggc2hvd3MgdGhlIHJlc3VsdCBvZiBhcHBseWluZyB0aGF0ICJkZWx0YSIuIFNvLCBi b3RoIGFyZSBqdXN0IGRpZmZlcmVudCB3YXlzIHRvIHByZXNlbnQgdGhlIHNhbWUgbm9ybWF0aXZl IGluZm9ybWF0aW9uLiBJJ2xsIGFkZCBhIHNlbnRlbmNlIGNsYXJpZnlpbmcgdGhhdC4NCg0KQmVz dCByZWdhcmRzLA0KS2xhdXMNCg0K From nobody Wed Apr 1 03:36:27 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B3F3A079E; Wed, 1 Apr 2020 03:36:25 -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, 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=ZyRuHF+w; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=ZyRuHF+w Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5rwpf74Alxk; Wed, 1 Apr 2020 03:36:23 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0608.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::608]) (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 7376C3A0794; Wed, 1 Apr 2020 03:36:22 -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=W/6Q3xYNqmEy4IsVgqz1ktMUr87UToeUut/N73IUjwc=; b=ZyRuHF+wOP6GfSE0Yvxp4ag5ZQbOUbkisVT8piMfoZwhFML6eBVHNdtA0JSSv674Ck1rOY52T2ovt3lSrvlU7RNtdu8MWgQE5PChJQDlO5IsGQyCaDeG6wqZ4s1h+XA/Bb1/JK2nY6F3NZZLDZDC3XDYUz5mnKaxAuBLRx/ddi4= Received: from AM5PR0701CA0072.eurprd07.prod.outlook.com (2603:10a6:203:2::34) by HE1PR0802MB2553.eurprd08.prod.outlook.com (2603:10a6:3:df::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Wed, 1 Apr 2020 10:36:19 +0000 Received: from VE1EUR03FT023.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:2:cafe::b7) by AM5PR0701CA0072.outlook.office365.com (2603:10a6:203:2::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.12 via Frontend Transport; Wed, 1 Apr 2020 10:36:19 +0000 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=bestguesspass 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 VE1EUR03FT023.mail.protection.outlook.com (10.152.18.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Wed, 1 Apr 2020 10:36:19 +0000 Received: ("Tessian outbound e2c88df8bbbe:v50"); Wed, 01 Apr 2020 10:36:19 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 7d08154c18906c68 X-CR-MTA-TID: 64aa7808 Received: from 406958c7fa6d.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F692BFF2-B5FA-4442-9EA1-46935F64B256.1; Wed, 01 Apr 2020 10:36:13 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 406958c7fa6d.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 01 Apr 2020 10:36:13 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DUyaBb/Sas1aAK8HVFWPNlkLdiDdpdMpT7eDYGRI1Z9+Hu/C9FHXmT4AKpJfsd9vhvkzFE4QE4IrZa4/AvAdG9A2WhTFiquS0rImo7Hv9UDm8JuwhmcvFz8m663FDoKd/o2TwS1ifRwYWyV6/WXCgX95u02GYNIfMZsETGNqx3zcljUzdOR/gkBJ0g7qc5p8xpP+1mxfRo4Uc4iC32Nh9zT0cjsoylyjCD/Qx6Pv1rzAYlbe7jXF0CvkS/dTO6nwIEyqHoW8A76YxBdSZVO6364ULhddel35jcVNApIAu0YA0zWOUhI3qq/+/T4YxqP1LO6vvEzmbKa21MIkpvzNBA== 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=W/6Q3xYNqmEy4IsVgqz1ktMUr87UToeUut/N73IUjwc=; b=BMa2/9BGlvEpGOQ+3Crgy6wZD97jm45+aNaij9cfVrVdLu9fhbSyhboXxrGKRsjkcDtfuLEXsQhoJ8UqH4qY0fsahTZqS8xHV9JgzKPQr/RlrLz+wRl0EFt8IBe4qVSZbQHY3d5azF7RllHKlD2Ar07JOy3TVeMik0UrWZobZx4ikYhQlo9Qc29sLXiIGAFd4fZwRwz8OFkBhE0pRL3TuagJBBk6Q7n/fB9pPKOi5UHj8k0E0i9pr+sSC1rH9vtjFbqudpz+PxcgWtsMMvG9uZimSI+bTFaem9Pb+hptaTAhFmbpbFTW0DGuKcZBEFMNiys/1DDpfKqlvSeYgtBxJA== 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=W/6Q3xYNqmEy4IsVgqz1ktMUr87UToeUut/N73IUjwc=; b=ZyRuHF+wOP6GfSE0Yvxp4ag5ZQbOUbkisVT8piMfoZwhFML6eBVHNdtA0JSSv674Ck1rOY52T2ovt3lSrvlU7RNtdu8MWgQE5PChJQDlO5IsGQyCaDeG6wqZ4s1h+XA/Bb1/JK2nY6F3NZZLDZDC3XDYUz5mnKaxAuBLRx/ddi4= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (20.179.18.151) by AM6PR08MB4072.eurprd08.prod.outlook.com (20.179.1.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.18; Wed, 1 Apr 2020 10:36:11 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f%7]) with mapi id 15.20.2856.019; Wed, 1 Apr 2020 10:36:10 +0000 From: Thomas Fossati To: Jim Schaad , "draft-fossati-core-coap-problem@ietf.org" CC: "core@ietf.org" , Thomas Fossati Thread-Topic: Review of draft-fossati-core-coap-problem-02 Thread-Index: AdYGycO1MeWT5q/ZR2SRe86TscydwAAogoeAAAB26YAAKwUAAA== Date: Wed, 1 Apr 2020 10:36:10 +0000 Message-ID: <703EAB3E-A9CC-4260-8B52-6690BACFA62C@arm.com> References: <00cd01d606da$9815a1c0$c840e540$@augustcellars.com> <766A1380-F2C9-4C8E-869F-8E1B3DDB4A22@arm.com> <010b01d6076d$ab36bfd0$01a43f70$@augustcellars.com> In-Reply-To: <010b01d6076d$ab36bfd0$01a43f70$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 0f7353fe-7b54-4d3d-2407-08d7d62883b3 x-ms-traffictypediagnostic: AM6PR08MB4072:|AM6PR08MB4072:|HE1PR0802MB2553: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 03607C04F0 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(136003)(396003)(346002)(366004)(376002)(2906002)(53546011)(6486002)(66476007)(4326008)(86362001)(6512007)(478600001)(66556008)(5660300002)(66446008)(66946007)(2616005)(64756008)(91956017)(36756003)(33656002)(81166006)(76116006)(186003)(8936002)(81156014)(8676002)(110136005)(316002)(26005)(54906003)(6506007)(71200400001); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 4EFW11ARwI0TTkp0YBXMJ9tBFHA6kL21S9TGveDQgId0DlN4+wSN5VKMTdzlaNXu/UsA+6jlJTmMxQyhurqSfKrD8aGomiAYvMEULB5a+7Cc4evdlqvRtWEzJcs/Sj82u6FNrLfOaT26mH0hTWlGBohLtk/SV3C8TNOwLGS/xTXx36IvG0BX/Uox34yIumAuo3azRoiMG+vfI0n4fZMOrmhWf/4TyROifkVW4w7yj1NQ+ZnploQtC/3hWu0ptivWXkDq9hd+cOR+PxKNfjmo2to9UpzJZSiUiURwNmXqsp5BCLcNeARPl921jvO3Zt4Ky0YC425pP4TTpv+pLaZB9KBSUhdkcS/T+zrpl9d5LcJ9dLS1TQsUdg+mDdc3IvNGDeBM0S/nYt4QGP9Y47ENtDPIe1VzxeMGYqVwZ9ZxgBnzaGDoK57ghCxsJD9ymywd x-ms-exchange-antispam-messagedata: ljuTp85CakllCzzt412MSfIK3AEhggDDb6DbE99tvWmw22WoeS5WZ/iMlqdn7b//g7DrVHT6WNlch7de3CxJ1/sgEEFBXLzPPXf2vtweZv4h30N3ShJKHsQJ/xHXKpZgneedsdzKTP9UNvgzDcsRzQ== Content-Type: text/plain; charset="utf-8" Content-ID: <538613A42A2F4F4AB9B1A8972DECEF7D@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4072 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT023.eop-EUR03.prod.protection.outlook.com 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; SFTY:; SFS:(10009020)(4636009)(136003)(39860400002)(396003)(376002)(346002)(46966005)(478600001)(36756003)(70586007)(186003)(110136005)(2906002)(54906003)(70206006)(26005)(316002)(5660300002)(6486002)(336012)(8936002)(33656002)(2616005)(6506007)(356004)(53546011)(47076004)(36906005)(450100002)(81156014)(26826003)(86362001)(8676002)(4326008)(81166006)(6512007)(82740400003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 47bee689-5f42-4ff5-fac0-08d7d6287ec0 X-Forefront-PRVS: 03607C04F0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ECF3IO9sbP2jtgLL7Ljn8C0vBCPPookzYjjFKewGlCRE0yeH6bBB/Dw5wRVr5yehD9GFtpjZmpg/3Hl8+ABevsY5C2LoA0v9pPqpmzEpCmhyaXh7FH67TBYTdGxjeBdcB5NUiCIQhJGQTUpOXi9aJDJXFRkCfaIWm5BktWG4hiReEtxoltRotTyeuszIV1xEIEloBC8C5YqZw5CMfxCvIn8gcMXj+dX3Lzr0I/ZweTbEAe3dQYgLZkgjpRaGo9f63j6ZNUJZgFV5VXiopsbm4we3usIATRlpg156NsyCdqzMfIxuyriPeDv7kJ/gwIIucdR61HMAfqUpqHohC/aAjk/e2XXxXS5qpp1Os4YfRb+NmSt+jGto3SYll90BB8t0Yk+PuRreVISDn3jChSDz6/4FaiDGP310w/8Uh/XtXKUDpMduSPm7eeaOpDO0XZ5EBoBQHwxkA3QdT2j2s0vMjiSEICb9lHPTYfNneLLNEJ+vfmPGOYffMEglKTcOV7Ii2CsN7/nn79hYaJKL7qnpNg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Apr 2020 10:36:19.1041 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0f7353fe-7b54-4d3d-2407-08d7d62883b3 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-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2553 Archived-At: Subject: Re: [core] Review of draft-fossati-core-coap-problem-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, 01 Apr 2020 10:36:25 -0000 T24gMzEvMDMvMjAyMCwgMTY6MDQsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNv bT4gd3JvdGU6DQo+ID4gSSBhbSB0b3JuIGJldHdlZW4gdGhhdCBhbmQgU2VjdGlvbiA0LjMgb2Yg UkZDIDczMjIsIGxhc3QgcGFyYToNCj4gPiAiWy4uLl0gdGhlIEFic3RyYWN0IG11c3Qgbm90IGNv bnRhaW4gY2l0YXRpb25zIg0KPg0KPiBbSkxTXSAgVGhlIHJ1bGUgaXMgdGhhdCB0aGUgdGV4dCBv ZiB0aGUgYWJzdHJhY3QgaXMgdG8gYmUgYWJsZSB0bw0KPiBzdGFuZGFsb25lLiAgVGhpcyBtZWFu cyB0aGF0ICJbUkZDNzMyMl0iIGlzIG5vdCBwZXJtaXR0ZWQsIGJ1dCAiUkZDDQo+IDczMjIiIGlz IHBlcm1pdHRlZC4gICBSZWZlcnJpbmcgdG8gYSBkb2N1bWVudCBieSBhICJ3ZWxsIGRlZmluZWQi DQo+IGxvb2t1cCBzdHJpbmcgaXMgb2suICBUaGlzIG1lYW5zIHRoYXQgcmVmZXJyaW5nIHRvIGFu IGVwcmludCB3b3VsZCBiZQ0KPiBkaXNjb3VyYWdlZC4gIE5vdGUgdGhhdCBtb3N0IG9mIHVzIGp1 c3QgdXNlIGFuIDx4cmVmPiBpbiB0aGUgYWJzdHJhY3QNCj4gYW5kIG1ha2UgdGhlIFJGQyBFZGl0 b3Igc3RhZmYgY2xlYW4gdGhpcyB1cC4gIEJ1dCB5b3UgbWlnaHQgZ2V0DQo+IGNvbXBsYWludHMg ZnJvbSB0aGF0IHVzYWdlIGR1cmluZyBmaW5hbCByZXZpZXcuDQoNClRoYW5rcyBmb3IgdGhlIGV4 cGxhbmF0aW9uLiAgV2lsbCBkby4NCg0KPiA+IFllcCwgYXBwbGljYXRpb24vY29hcC1wcm9ibGVt K2Nib3IgYW5kIGRpYWdub3N0aWMgcGF5bG9hZHMgYXJlDQo+ID4gbXV0dWFsbHkgZXhjbHVzaXZl LiAgVGhpcyB3YXMgYSBwcmVjaXNlIGNob2ljZSBiZWNhdXNlIHRoZXkgc2VlbWVkDQo+ID4gdG8g aGF2ZSBkaWZmZXJlbnQgYXVkaWVuY2VzIChBUEkgdXNlciB2cyBBUEkgZGV2ZWxvcGVyKS4gIFRo YXQgc2FpZCwNCj4gPiB0aGUgaW50ZXJzZWN0aW9uIGJldHdlZW4gQVBJIHVzZXJzIGFuZCBkZXZl bG9wZXJzIGlzIG5vdCBlbXB0eSwgc28NCj4gPiB0aGlzIG1pZ2h0IGFjdHVhbGx5IGJlIGluIHNj b3BlLCBhcGFydCBmcm9tIGJlaW5nIG9idmlvdXNseSB1c2VmdWwuDQo+DQo+IFtKTFNdIEdpdmVu IHRoYXQgSSB3b3VsZCB3YW50IHRvIHRlc3QgdGhlIHByb2JsZW0gaW5mbyBiZWluZyByZXR1cm5l ZCwNCj4gZ2V0dGluZyB1bmV4cGVjdGVkIGVycm9ycyB3aXRoIGluZm9ybWF0aW9uIGlzIHVzZWZ1 bCBmb3IgbWUuICBUaGlzIGlzDQo+IHRoZSBiYXNpYyBtZXRob2QgdGhhdCBJIGhhdmUgYmVlbiB1 c2luZyBmb3IgbXkgQUNFIHNlcnZlciB3aGVyZSBhDQo+IGRpYWdub3N0aWMgc3RyaW5nIHdpdGgg dGhlIHByb2JsZW0gZGV0YWlscyBpcyByZXR1cm5lZCwgYnV0IGEgc3RhY2sNCj4gdHJhY2UgaXMg aW5jbHVkZWQgaW4gdW5leHBlY3RlZCBjb25kaXRpb25zIChpLmUuIHRoZSBjb2RlIHRocmV3IGFu DQo+IGV4Y2VwdGlvbikuDQoNCkkgYW0gY2VydGFpbmx5IG5vdCBvcHBvc2VkIHRvIHRoYXQuICBI YXBweSB0byBjYWxsIGl0ICJkaWFnbm9zdGljIj8NCg0KPiA+IEdvb2QgcG9pbnQsIHdlIGhhdmVu J3QgdGhvdWdodCBhYm91dCB0aGlzLiAgTm90IHN1cmUgaG93IG9uZSBjYW4NCj4gPiBzdWNjZXNz ZnVsbHkgaGFuZGxlIGxvY2FsaXNhdGlvbiBpbiBDb0FQIHRob3VnaC4gIEl0IHNlZW1zIGxpa2Ug dGhlDQo+ID4gb25seSBzZW5zaWJsZSByZWNvbW1lbmRhdGlvbiB3ZSBjb3VsZCBtYWtlIGhlcmUg aXMgInRyeSB0byBjaG9vc2UNCj4gPiBiYXNlZCBvbiBwcmVzZW50IGFuZCBmdXR1cmUgYXVkaWVu Y2UuIi4gICBUaGF0LCBvciBmb3JjZSBFbmdsaXNoDQo+ID4gZnJvbSB0aGUgb25zZXQ/DQo+DQo+ IFtKTFNdIEluIHNvbWUgd2F5cyB0aGUgbWV0aG9kIHRoYXQgaXMgdXNlZCBieSBXaW5kb3dzIHRv IGxvZyBldmVudHMNCj4gd29ya3Mgb3V0IHByZXR0eSB3ZWxsLCBidXQgbWlnaHQgYmUgdG9vIHdl aWdodHkgZm9yIHRoaXMuICBJbiB0aGF0DQo+IGNhc2UgYSBsaXN0IG9mIGluZm9ybWF0aW9uIHdp dGggdGhlIHRpdGxlIGFuZCBhIHNldCBvZiBhdHRyaWJ1dGVzIGFyZQ0KPiByZXR1cm5lZCBmcm9t IHRoZSBzZXJ2ZXIgKGV2ZW50KSBhbmQgdGhlc2UgYXJlIHRoZW4gcGxhY2VkIGludG8gYQ0KPiBs b2NhbGl6ZWQgc3RyaW5nLiAgSXQgbWlnaHQgYmUgcG9zc2libGUgdG8gcHJvdmlkZSBhIGRlZmF1 bHQgc3RyaW5nLCBhDQo+IHNldCBvZiBhdHRyaWJ1dGVzIGFuZCBhIG1ldGhvZCBvZiBnZXR0aW5n IGEgbG9jYWxpemVkIHN0cmluZyBpZg0KPiBuZWVkZWQuDQoNClNvdW5kcyBsaWtlIHdlIGNvdWxk IGRvIHNvbWV0aGluZyBzbGlnaHRseSBsZXNzIHNvcGhpc3RpY2F0ZWQgYnV0IG1heWJlDQpzdWZm aWNpZW50IGluIG1vc3Qgc2l0dWF0aW9ucyBieSBsZXR0aW5nIHRoZSBhcHBsaWNhdGlvbiBtYXAg Im5zIiBhbmQNCiJ0eXBlIiBpbnRvIGEgbG9jYWxpc2VkICJ0aXRsZSIuDQoNCj4gPiA+IElmIG5l Z2F0aXZlIHZhbHVlcyBhcmUgdXNlZCBmb3IgcHJpdmF0ZSBkZXRhaWxzIGZvciBhIHB1YmxpYw0K PiA+ID4gbmFtZXNwYWNlIGluIHNlY3Rpb24gNS4yLjEgLSBIb3cgSSBhbSB0byB1bmRlcnN0YW5k IHdoaWNoIHRoZQ0KPiA+ID4gZGlmZmVyZW50IHByaXZhdGUgcmVnaXN0cmF0aW9ucyBhcmUgYmVp bmcgcmVmZXJyZWQgdG8/ICBPciBhcmUNCj4gPiA+IHRoZXNlIGFsbCBleHBlY3RlZCB0byBiZSBy ZWdpc3RlcmVkPw0KPg0KPiA+IFllcywgdGhlIGlkZWEgaXMgdGhhdCB3aGVuIHlvdSBnbyBwdWJs aWMsIHlvdSBuZWVkIHRvIHJlZ2lzdGVyIGFsbA0KPiA+IHRoZSAiZXh0cmEiIGRldGFpbHMgeW91 ciBBUEkgaXMgdXNpbmcgcGlja2luZyBmcm9tIHRoZSB1bnVzZWQgcGFydHMNCj4gPiBvZiB0aGUg MC4uNDI5NDk2NzI5NSBzcGFjZS4NCj4NCj4gW0pMU10gQnV0IGluIHRoYXQgY2FzZSB5b3Ugd291 bGQgbm90IGhhdmUgcHJpdmF0ZSBkZXRhaWxzIGZvciBhIHB1YmxpYw0KPiBuYW1lc3BhY2U/ICBJ ZiB0aGUgQ29SRSBncm91cCBjcmVhdGVzIGEgYmFzaWMgcHVibGljIG5hbWVzcGFjZSBhbmQNCj4g c2V0dXBzIHVwIGEgdHlwZSBGT08uICBJcyBpdCBsZWdhbCBmb3IgbWUsIGFzIGFuIGluZGl2aWR1 YWwgb3INCj4gY29tcGFueSwgdG8gYXVnbWVudCB0aGF0IGFuZCByZXR1cm4gbmVnYXRpdmUgYXR0 cmlidXRlcyBmb3IgdGhhdCB0eXBlPw0KPiBUaGluayBhYm91dCB0aGUgZXhhbXBsZSBpbiBBLjIg YmVpbmcgaW4gYSBwdWJsaWMgcmF0aGVyIHRoYW4gaW4gYQ0KPiBwcml2YXRlIG5hbWVzcGFjZS4g IElzIHRoZSAtMSBhdHRyaWJ1dGUgbGVnYWw/DQoNCkkgdGhpbmsgbm93IEkgZ2V0IHdoYXQgeW91 IGFyZSBzYXlpbmcuICBXZSBuZWVkIHRvIGJlIGFibGUgdG8gY2xlYXJseQ0Kc2VwYXJhdGUgdHdv IGNhc2VzOg0KKDEpIHN0YWNrIFggd2FudHMgdG8gZW5yaWNoIGFuICpleGlzdGluZyogcHJvYmxl bSB0eXBlIHdpdGggc29tZSBleHRyYQ0KICAgIGtleXM7DQooMikgcHJpdmF0ZSBBUEkgWSBpcyBt YWtpbmcgdXNlIG9mIGEgbnVtYmVyIG9mICJuZWdhdGl2ZSIga2V5cyBhbmQgbm93DQogICAgbmVl ZHMgdG8gZ28gcHVibGljLg0KDQpJIGd1ZXNzIHdlIGNvdWxkIGhhdmUgdGhhdCBraW5kIG9mIGNs ZWFuIGN1dCBpZiB3ZSBncm91cGVkICgxKSBpbnRvIGENCm5lc3RlZCBtYXAgYW5kIGhhbmRsZSAo MikgdXNpbmcgdGhlIGtpbmQgb2YgcHJvbW90aW9uIHZpYSByZWdpc3RyYXRpb24NCkkgd2FzIGhp bnRpbmcgYmVmb3JlLg0KDQpXRFlUPw0KDQpjaGVlcnMhDQotLQ0KDQpJTVBPUlRBTlQgTk9USUNF OiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2Ug aXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBh bnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Wed Apr 1 03:56:29 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EBF3A0867 for ; Wed, 1 Apr 2020 03:56:27 -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 0TxRAmVildKj for ; Wed, 1 Apr 2020 03:56:25 -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-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D6F3A086A for ; Wed, 1 Apr 2020 03:56:25 -0700 (PDT) Received: from mail-qk1-f178.google.com ([209.85.222.178]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1jJb2l-0003Z7-1l; Wed, 01 Apr 2020 12:56:23 +0200 Received: by mail-qk1-f178.google.com with SMTP id q188so26473637qke.8 for ; Wed, 01 Apr 2020 03:56:23 -0700 (PDT) X-Gm-Message-State: ANhLgQ3cODmKcJ/yuYUOVYBojnejCUYspMSJBe3Pos7pBgwnfWlEmJqN eXH3Law2dqPTV80rZs2e5fHLd2nhLzGgtI9XrSE= X-Google-Smtp-Source: ADFU+vt8fvrpueaofqxRocp454rokNziDzf1FvcYPVqn25F5eArCXM+wuRFrkBLsmt/q0qsk8KnNpwrUI7KesDfE7Og= X-Received: by 2002:a05:620a:2f7:: with SMTP id a23mr8584476qko.303.1585738581944; Wed, 01 Apr 2020 03:56:21 -0700 (PDT) MIME-Version: 1.0 References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> In-Reply-To: From: Klaus Hartke Date: Wed, 1 Apr 2020 12:55:45 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Thomas Fossati Cc: Esko Dijk , Jim Schaad , "core@ietf.org" Content-Type: multipart/mixed; boundary="000000000000e24f1005a2388832" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1585738585; 10dc3dd0; X-HE-SMSGID: 1jJb2l-0003Z7-1l Archived-At: Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top 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, 01 Apr 2020 10:56:28 -0000 --000000000000e24f1005a2388832 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thomas Fossati wrote: > I don't have an opinion yet, but I'd need some clarification about the > above before feeling comfortable with the direction... I guess there is some room for debate on what a CoAP endpoint with a multicast IP address precisely means... RFC 7252 defines 224.0.1.187 as the "All CoAP Nodes" address. So I see at least two possible interpretations for the endpoint 224.0.1.187:9999: 1. All CoAP nodes that are listening on port 9999 on their unicast IP addre= ss. 2. All CoAP nodes that are "subscribed" to mailing list 9999. Both seem to have advantages and disadvantages. Maybe there are even more interpretations? > I have the same trouble as you understanding the port mapping part. > Where is that supposed to happen (kernel, CoAP stack, application)? > And why is it needed? I always imagined multicast CoAP to work roughly like this: +---------------+ +-----------------+ | | request _|_ | | | .---> / \ 224.0.1.187 | | _|_ / \___/ --. :9999 | | 192.168.0.1 / \ ---=C2=B4 | \ | | :54321 \___/ <---. _|_ / rewrite | | | \ / \ <-=C2=B4 | | | `--- \___/ 192.168.0.100 | | | response | :5683 | +---------------+ +-----------------+ Client Server So, a server is listening for request messages on both a unicast IP address/port and a multicast IP address/port. If a request message arrives on the multicast IP address/port, it "rewrites" the UDP destination to its unicast IP address/port and then processes the message as if it had received it on its unicast IP address/port. The "rewrite" is at least needed for the IP address, because the server cannot send its response from the multicast IP address. Klaus --000000000000e24f1005a2388832 Content-Type: text/plain; charset="ISO-8859-1"; name="illustration.txt" Content-Disposition: attachment; filename="illustration.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_k8h7m3ve0 Ky0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKw0KfCAg ICAgICAgICAgICAgIHwgICAgcmVxdWVzdCAgICBffF8gICAgICAgICAgICAgICAgfA0KfCAgICAg ICAgICAgICAgIHwgICAgICAgIC4tLS0+IC8gICBcICAgMjI0LjAuMS4xODcgfA0KfCAgICAgICAg ICAgICAgX3xfICAgICAgLyAgICAgIFxfX18vIC0tLiAgIDo5OTk5ICAgfA0KfCAxOTIuMTY4LjAu MSAvICAgXCAtLS20ICAgICAgICAgfCAgICAgIFwgICAgICAgICAgfA0KfCAgIDo1NDMyMSAgICBc X19fLyA8LS0tLiAgICAgICBffF8gICAgIC8gIHJld3JpdGUgfA0KfCAgICAgICAgICAgICAgIHwg ICAgICAgIFwgICAgIC8gICBcIDwttCAgICAgICAgICAgfA0KfCAgICAgICAgICAgICAgIHwgICAg ICAgICBgLS0tIFxfX18vIDE5Mi4xNjguMC4xMDAgfA0KfCAgICAgICAgICAgICAgIHwgICAgcmVz cG9uc2UgICAgfCAgICAgICAgIDo1NjgzICAgfA0KKy0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgQ2xpZW50ICAgICAgICAgICAgICAgICAg ICAgICAgICAgU2VydmVyDQo= --000000000000e24f1005a2388832-- From nobody Wed Apr 1 04:31:01 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC0F3A0BD8 for ; Wed, 1 Apr 2020 04:31:00 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ITCgJ_vAzS8Y for ; Wed, 1 Apr 2020 04:30:59 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 50A953A0BD7 for ; Wed, 1 Apr 2020 04:30:59 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id i16so28250008edy.11 for ; Wed, 01 Apr 2020 04:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SM9j4FwrETH1a/D6NbHqlOOQp6gUYlfTsBakUIHjMpY=; b=aXZkY4I8EA2C7ybA4j9ONpv1iU3DpaCqV7ymgtWxedrmEdhyLJrR0mguvf33p9E/Qw nt0A6g0/QMgp7QMlu2HIXyANMvYxneGe9BkHMSksmvU1rq8Treieip4SO1QqjT6EjHua RLWJJ+dgWUMTAPv7CDpWllka0S17gaz7r/nzF1+4ZucJXgPbZeOEdrsSgLTvKTYc8O01 TlKNU9OqD1+Dr4Acjs1FzdPkuRGGLRz6bIQDcGcjwwyjnJjTEpuXZqbSilyvbdBeY9Cn /6n0sHB9g8bPddP/iUSCNak3W8a1yqsWBxk7ovURKBH2CAVPurE3X6+tnkmnKM36TyGb NvqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SM9j4FwrETH1a/D6NbHqlOOQp6gUYlfTsBakUIHjMpY=; b=aZ+NA63Odljj/gf4Shpq+dyWVggusJ0eNDD4AbVmHeVbWIHXovPwceJP5LirStjAT8 H9QOKIsEVMoluzkta5fTnPxd9AgHvnUeDrLO22R9+pi/gbw2pf8NDBW1ec0VhahJ7SVI TsS1pX2pv89+FgWYp/tbN8pEzuynAGrchc/jVNHDNjk8icUcoK4DS3TWlFlb+yykKln+ zyp87OTtSllIEiw/ZNbhFeaI4UHC6W+aB2eb7BAUckPz6nkBXlyv4LuDGJO29PsS8PBD U79nm0rxr6JpGnuHQbYDw4L9u6lRYtVwYNN6DqJ2bRq5UYzd/vV4A6INnICEa2x1Hd/S +DNg== X-Gm-Message-State: ANhLgQ351JtZY2NSFZa6O69bVip+cuT6roCq9K9VfNSIaYKBWoy0FRcP lWVAcvWjiYOHOcMDtnEYlXlicYPwP+cERhSsgNQ4EQ== X-Google-Smtp-Source: ADFU+vsfiWTzBLq1eosWb6ILS6KVfPI8Ud4l4Hzg0YSNt6/NZImy/WLWXMdrWB2MSKYuwR53b5BPZzWFciTesAk0VFY= X-Received: by 2002:a17:906:4f94:: with SMTP id o20mr13194430eju.354.1585740657522; Wed, 01 Apr 2020 04:30:57 -0700 (PDT) MIME-Version: 1.0 From: Abhijan Bhattacharyya Date: Wed, 1 Apr 2020 17:00:46 +0530 Message-ID: To: core Content-Type: multipart/alternative; boundary="00000000000098fd7805a23904f8" Archived-At: Subject: [core] Using CoAP for P2P 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, 01 Apr 2020 11:31:01 -0000 --00000000000098fd7805a23904f8 Content-Type: text/plain; charset="UTF-8" Hi, Is there any standardized mechanism to use CoAP for a P2P connection? Thanks. -- Regards, Abhijan Bhattacharyya, *Technologist by profession [IoT| Internet Protocols| 5G]* --00000000000098fd7805a23904f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
Is there any standardized mechanism to use CoAP fo= r a P2P connection?=C2=A0
Thanks.

--
Regards,
Abhijan Bhattacharyya,
Technologist by professi= on [IoT| Internet Protocols| 5G]
--00000000000098fd7805a23904f8-- From nobody Wed Apr 1 05:02:45 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16283A0CAE for ; Wed, 1 Apr 2020 05:02:43 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=1QkBImZo; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=1QkBImZo Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKDGjLAJnhGs for ; Wed, 1 Apr 2020 05:02:42 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150059.outbound.protection.outlook.com [40.107.15.59]) (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 517B13A0CB8 for ; Wed, 1 Apr 2020 05:02:21 -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=CrN/a9W8uR6nz00L1u+3K7wDcjR4FUNfPi93IGtv8kk=; b=1QkBImZoFP7z7k+AZPrlyBKG3Oos5ropkwf1O/uy2I/tBwBGETczdWIUqqrMpV3I38h5D/uiEzqDV38Z2rYgHDVf0zFY+DyZX6r15p6GYJM/SUVgFjY+zBqSDke3MpYCGPj97nUtiylPQu1jHPmfWRd1ITddT+BluifpfW1O2Cw= Received: from AM6P193CA0109.EURP193.PROD.OUTLOOK.COM (2603:10a6:209:85::14) by HE1PR0801MB1820.eurprd08.prod.outlook.com (2603:10a6:3:85::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Wed, 1 Apr 2020 12:02:19 +0000 Received: from VE1EUR03FT017.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:85::4) by AM6P193CA0109.outlook.office365.com (2603:10a6:209:85::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Wed, 1 Apr 2020 12:02:18 +0000 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=bestguesspass 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 VE1EUR03FT017.mail.protection.outlook.com (10.152.18.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Wed, 1 Apr 2020 12:02:18 +0000 Received: ("Tessian outbound af37c2b81632:v50"); Wed, 01 Apr 2020 12:02:17 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 4b2aa1054e16cfde X-CR-MTA-TID: 64aa7808 Received: from 6cde2da7d7c6.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id BD337F4B-22FC-41B9-8E8F-76A2E7BF0B11.1; Wed, 01 Apr 2020 12:02:12 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 6cde2da7d7c6.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 01 Apr 2020 12:02:12 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QSbetFOy04Z7Ifoszw03H5ZK1Kbcdsc/GXCqoQw/0mEKC+mkJYDcNg6r5uimQK+BtyQvPdn9USjZYAQEOdm8umscdraISkA9wOmmR4Uxne/ndMOB8NdESvF/0Jxsmchxusx0rIceMgbMA8crU9P4z4N9A6zopUKb6FgMAl116l6Gv8U1j1ctvpIPOhiM2LZKJPBJi5SP9xjs7zV9Y4NwUVEeG2Fs2vyXnv0O+H1fERpBGOTZCgSiNF/NEAKoWwBnwHqitZL7RipI7kGObjt8K4dkYP++15Z4qYvlPouMlLEn6o58a8SVLlJlB1KeZzOomkgNp9W4YU76E5UqGftrDw== 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=CrN/a9W8uR6nz00L1u+3K7wDcjR4FUNfPi93IGtv8kk=; b=Z+Corv3n/CcrE+/ol2On5rgoDV0H1Gr+EqSsSwHaIuIST4qbTpaYWLz+axq8taz3BK3xY5UhrDJw2TOY8zZSvA2YGF54DLOzNl+IslSqslQLk6gsv0AeM/xKNS2nQgZwuUZvLG6akPWLtTxrr1Diu+ruPxcXjQ1DNLdNoV+MqqkYVFwLBKJYY6NDJEXLnidR5/tR1DRc3qvl4p95ePGiAaoQ3N3XcC34jL+6G7aFNXM1H7JqZaevTvbMa4DFqPk1KJI8a2v0JP2Uh86csnL/DRJWWVDi25GJbz48u2vqb/19kQPxSmp4jsEQRiZPj5l+iU+OBhKv0hFCQZE8IQHG0Q== 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=CrN/a9W8uR6nz00L1u+3K7wDcjR4FUNfPi93IGtv8kk=; b=1QkBImZoFP7z7k+AZPrlyBKG3Oos5ropkwf1O/uy2I/tBwBGETczdWIUqqrMpV3I38h5D/uiEzqDV38Z2rYgHDVf0zFY+DyZX6r15p6GYJM/SUVgFjY+zBqSDke3MpYCGPj97nUtiylPQu1jHPmfWRd1ITddT+BluifpfW1O2Cw= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (20.179.18.151) by AM6PR08MB4392.eurprd08.prod.outlook.com (20.179.7.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Wed, 1 Apr 2020 12:02:10 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f%7]) with mapi id 15.20.2856.019; Wed, 1 Apr 2020 12:02:10 +0000 From: Thomas Fossati To: Abhijan Bhattacharyya , core Thread-Topic: [core] Using CoAP for P2P Thread-Index: AQHWCBkKd/ADH0oe/0iISsi9X2hLJ6hkO1AA Date: Wed, 1 Apr 2020 12:02:10 +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.35.20030802 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 05e58186-acca-4372-f884-08d7d63486ce x-ms-traffictypediagnostic: AM6PR08MB4392:|AM6PR08MB4392:|HE1PR0801MB1820: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:4502;OLM:10000; x-forefront-prvs: 03607C04F0 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(346002)(396003)(39860400002)(376002)(136003)(81156014)(8676002)(81166006)(8936002)(186003)(86362001)(66446008)(64756008)(91956017)(66556008)(66476007)(76116006)(66946007)(6486002)(71200400001)(6512007)(478600001)(36756003)(5660300002)(110136005)(316002)(26005)(2906002)(4744005)(6506007)(53546011)(4326008)(2616005)(33656002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 9YDXXWgnQrYsnzOgXqGf8yWnS3M4DjIV2FBe9nwmVwpCYj2yPdhGWn/UyCyhBKD0lBzn2eOSz6m8dW5XFpOOH1jdiMMw/Q+ilSQELEjL6X0U/eig+4/w7Mt1c/JPSH+bYgN8w/d25t3602l49fljXu8ms8Iz2zy4q/diwP93pCeC2QEU6HE5YD0iZEKTXWvUdDX/MJdHQ3pZvivnt+qjNqQWBKGDR/vY1ea29tlN+LEgUahhCXtrxsBr7Xa3YL7vhRJbeOnApdmc1T1eY2NyBT1SheFweeByErVeEqXa7REmc8TiEaBSYlBCGGkGELTdiP6qDAMPZyZYTzsKmkPu0MiAbycyk8klGR/U2+gxn9DrluWoejLwDeqKvFV/Nzgvkm/YrdlYo5FIL54QXKEBPX3F7xE3RsmV4QJXpFkka5iD/TRaDJnIsKDM/eVa7eo9 x-ms-exchange-antispam-messagedata: HDMH/kezJo3BWkZAdRsAcutpy3mFccrF8iKjqvWXQQKgqAJOqAQ3AG3GglWuJJWJe1RCyH3RDiPtmW6/w9VvhiJ8RRqdz1mwCdzpBEJPGISIM8/Guei2H1Kr3ysIcujFmAvowgUxhB5+sJplKyRUVg== Content-Type: text/plain; charset="utf-8" Content-ID: <1A6D37E717917B4D90945E07782DC718@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4392 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT017.eop-EUR03.prod.protection.outlook.com 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; SFTY:; SFS:(10009020)(4636009)(39860400002)(376002)(346002)(136003)(396003)(46966005)(478600001)(316002)(6486002)(2616005)(70586007)(186003)(70206006)(26005)(2906002)(336012)(110136005)(33656002)(8936002)(53546011)(47076004)(86362001)(5660300002)(36756003)(81156014)(81166006)(26826003)(4326008)(6512007)(6506007)(4744005)(8676002)(356004)(82740400003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 070c1a8c-5b02-4dbe-5953-08d7d6348230 X-Forefront-PRVS: 03607C04F0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: C4JOQpZ4470B9mniGZuuTc15wEwdxSpuNHOa8RZq9mzEE8GKLOmXoL9DdJlIu0lfGEOglAOn040AB8DTMIudIjIykpkhH7W5Y+n7KXZlRxjvI3QwCwOJaB4C1CVpaA3PZjMQ0sqVIH9dP68939pZfeW124usM4PyL3IjBe4Muq2yCxc+Owl2b6ejPSC1NVQINvtXRNb82/rHuN0xzA+qFEl6cQHkp1WHClSvPgRRtlk4vPjlP+WQ4DaYNzMcrr/rrbDAo5KdcbdIt7miNMexA2ISj6QDLCoBTteRiKVki3Lb65+zDeQ2Kzf20dDnMGTtOsENnH5tt97Yz+wD+J9syHRAzuOlKMK+Ax6gC3XaR4Los+rAq9GaKtf85c/4YwkJDLYL3IE9vn/7HgLBcsNuYGknDSoVA0HmWg3FPlOwqUCdlgNS6dQc/e4GhL1ZTTHTtgCrJGcIPvApOzwuRxaGPsLgb4uOi26t5Yjczw03hF/r9YERad6WXgsU9MP+Q3IdCIK6q4im7vrAwoyorw74zQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Apr 2020 12:02:18.3518 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 05e58186-acca-4372-f884-08d7d63486ce 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-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1820 Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 01 Apr 2020 12:02:44 -0000 SGkgQWJoaWphbiwNCg0KT24gMDEvMDQvMjAyMCwgMTI6MzEsIEFiaGlqYW4gQmhhdHRhY2hhcnl5 YSA8YWJoaWphbi5iaGF0dGFjaGFyeXlhQGdtYWlsLmNvbT4gd3JvdGU6DQo+IElzIHRoZXJlIGFu eSBzdGFuZGFyZGl6ZWQgbWVjaGFuaXNtIHRvIHVzZSBDb0FQIGZvciBhIFAyUCBjb25uZWN0aW9u Pw0KDQpOb3Qgc3VyZSB3aGV0aGVyIFJGQyA3NjUwIHdvdWxkIGZpdCB5b3VyIG5lZWRzIGJ1dCB3 b3J0aCBoYXZpbmcgYQ0KbG9vayAtLSBpZiB5b3UgaGF2ZW4ndCBhbHJlYWR5Lg0KDQpjaGVlcnMN Ci0tDQoNCg0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJp dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRl bnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3Jl IG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Wed Apr 1 08:28:54 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541B23A11B4; Wed, 1 Apr 2020 08:28:39 -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 woyGKapPe86N; Wed, 1 Apr 2020 08:28:37 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 100E03A114F; Wed, 1 Apr 2020 08:28:36 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id y14so3415iol.12; Wed, 01 Apr 2020 08:28:36 -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=OPE5UHrkWQsJp+Du7l9lFOslq380bP/z7XjMa1+sCF0=; b=lzhPW4coxe6U8j/7UeiktHNL+Eu5qlM+0/ycTuz45V0E5oyonbrpymb558RLWxx/D9 4F7UfStUaz0pNdQeNawJepEGnWOmaa7bSHKwJ7Nd/oR4WuPeZLG9yB/AuhOxknF0hWFe bOKMv6f9C/WMSKEEn2MkCCSqo/OlLUhbuky50GBFJpR4Hu+Xqgkssd8SIqBUPfd/7r9b SDLy1Zbs7fboO4rzZg+L/0p5S+p+Lc9/ECBRzY5ZjNbKSvkN3JMHvbaRxFBVwgveR5H5 1yBK+Pf95In4KdIDY1CmllaD6zt8snncI1Jf44jvnhK+8nmXEoBjE8MGUW37G5+LQDv2 APSQ== 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=OPE5UHrkWQsJp+Du7l9lFOslq380bP/z7XjMa1+sCF0=; b=kLXF23BC/HBNSqJpQWKDaOaWKoIooC4ehWPv+o/5IlD+SupQwuDh9DR49f0YOqPkdi xlJtTDliwSUpvpY+LBmzSwH5VipdWxDnKji8Xpik+JWEfuzPv0prFMGZz6D0o2npRA0I /I8ESIB27HO565piJaC7Qr0DCg1mATzexq+IniNqZwpE0VZgKmvNRm04kBbmJ7NymYAO 4Us357k5ZuRzBQ/WsW/adjILaoNYg3s6Snz1Cty1hmZwP+xx3NHnBbdCUClsedW3wWQP 7u97crhSlsN5pfZ6xVeLadbpJtoB9aEt60tlpkMOKSUoRWR7Rm7v6Wtj4v0RP3JFlwei D47A== X-Gm-Message-State: ANhLgQ2DgAJxL6brFdkb1Yt4FH4v6R/HerLSvnJt47HJ0YRRsj9nVeX9 TLtaxH6BaNI3IhV/lnX285qi+Mlqt3OsVyn59aI= X-Google-Smtp-Source: ADFU+vsfjKvkPf6GA0ZfB3HRAGnxMXS0UZkVU1V94Zmu37EhjkGpwVMcCVflbLF3AJUn8DPzKHPhccrI9f7a7fXman0= X-Received: by 2002:a02:634e:: with SMTP id j75mr21186576jac.23.1585754914937; Wed, 01 Apr 2020 08:28:34 -0700 (PDT) MIME-Version: 1.0 References: <158573098630.30833.17715509721846547699@ietfa.amsl.com> In-Reply-To: From: Dan Romascanu Date: Wed, 1 Apr 2020 18:28:22 +0300 Message-ID: To: Klaus Hartke Cc: "gen-art@ietf.org" , "draft-ietf-core-stateless.all@ietf.org" , "last-call@ietf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="00000000000067e1b505a23c564e" Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-stateless-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 15:28:41 -0000 --00000000000067e1b505a23c564e Content-Type: text/plain; charset="UTF-8" Hi Klaus, Thanks for your quick reply and for addressing the issues raised in my review. See below my short comments on a couple of issues. Regards, Dan On Wed, Apr 1, 2020 at 1:27 PM Klaus Hartke wrote: > Dan Romascanu wrote: > > This is a very clear and well-written document. I have a few minor > issues that > > I suggest to clarify before approval and publication. > > Many thanks for your review! > > > 1. It would be useful to include some considerations whether the authors > > consider useful / possible / allowed that the mechanism (extended token > > lengths) presented in this document can be used for other purposed than > > the by-design the use case (avoiding per-request state). > > The last paragraph in Section 1 says: > > While the use case (avoiding per-request state) and the mechanism > (extended token lengths) presented in this document are closely > related, both can be used independently of each other: Some > implementations may be able to fit their state in just 8 bytes; some > implementations may have other use cases for extended token lengths. > > Does that solve your issue? > Actually this is exactly the paragraph that triggered my concern. Does 'using independently' mean that you encourage or do not care implementations in the future dealing with other use cases? If the answer is yes, maybe the current text is fine. If the answer is 'rather not' than a discussion would be welcome. ... > > > 3. In Section 5.2: > > > > > The use of encryption, integrity protection, and replay protection of > > serialized state is recommended in general, unless a careful analysis > > of any potential attacks to security and privacy is performed. AES- > > CCM with a 64 bit tag is recommended, combined with a sequence number > > and a replay window. Where encryption is not needed, HMAC-SHA-256, > > combined with a sequence number and a replay window, may be used. > > > > A few issues with this paragraph. Why are not 'recommended' and 'may' > > capitalized? The formulation 'is recommended in general' seems odd, and > > the rest of the sentence does not clarify. What does 'a careful analysis > of any > > potential attacks' mean? Who is supposed to perform this analysis and who > > can ensure it is 'careful enough' at any given point in time for any > potential > > attacks? > > AFAIK, the Security Considerations section is supposed to discuss > security-related issues that users need to be aware of, but not make > normative statements. So all the normative requirements are in Section 3.1. > (Where 'users' in this case are implementations and specifications that > decide to make use of this implementation strategy in clients.) > > Overall, it's a bit difficult to make normative requirements here, because > these are usually about the interoperability e.g. of a client and a server. > But in this case, the client only needs to interoperate with itself (it > needs to accept a token that it created itself) and the only real > requirement is that "client implementations MUST NOT be vulnerable to > maliciously crafted tokens". The meaning of "vulnerable" and "malicious" > here depends a lot on the application/deployment-specific context; the > document can really just highlight some potential issues that users should > take into consideration. > > I'm open to concrete suggestions for text improvements, though. > I believe that I understood the point that you are making. If I am to suggest text improvements, I would: - s/recommended in general/recommended/ - clarify, maybe in this very words that "the requirement is that client implementations must not be vulnerable to maliciously crafted tokens" .... --00000000000067e1b505a23c564e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Klaus,

<= div>Thanks for your quick reply and for addressing the issues raised in my = review.

See below my short comments on a coup= le of issues.

Regards,

Dan


On Wed, Apr 1, 2020 at 1:27 PM Klaus Hartke <= klaus.hartke@ericsson.com&= gt; wrote:
Dan R= omascanu wrote:
> This is a very clear and well-written document. I have a few minor iss= ues that
> I suggest to clarify before approval and publication.

Many thanks for your review!

> 1. It would be useful to include some considerations whether the autho= rs
> consider useful / possible / allowed that the mechanism (extended toke= n
> lengths) presented in this document can be used for other purposed tha= n
> the by-design the use case (avoiding per-request state).

The last paragraph in Section 1 says:

=C2=A0 =C2=A0While the use case (avoiding per-request state) and the mechan= ism
=C2=A0 =C2=A0(extended token lengths) presented in this document are closel= y
=C2=A0 =C2=A0related, both can be used independently of each other: Some =C2=A0 =C2=A0implementations may be able to fit their state in just 8 bytes= ; some
=C2=A0 =C2=A0implementations may have other use cases for extended token le= ngths.

Does that solve your issue?

Actually th= is is exactly the paragraph that triggered my concern. Does 'using inde= pendently' mean that you encourage or do not care implementations in th= e future dealing with other use cases? If the answer is yes, maybe the curr= ent text is fine. If the answer is 'rather not' than a discussion w= ould be welcome.

...



> 3. In Section 5.2:
>
> > The use of encryption, integrity protection, and replay protectio= n of
>=C2=A0 =C2=A0 serialized state is recommended in general, unless a care= ful analysis
>=C2=A0 =C2=A0 of any potential attacks to security and privacy is perfo= rmed.=C2=A0 AES-
>=C2=A0 =C2=A0 CCM with a 64 bit tag is recommended, combined with a seq= uence number
>=C2=A0 =C2=A0 and a replay window.=C2=A0 Where encryption is not needed= , HMAC-SHA-256,
>=C2=A0 =C2=A0 combined with a sequence number and a replay window, may = be used.
>
> A few issues with this paragraph. Why are not 'recommended' an= d 'may'
> capitalized? The formulation 'is recommended in general' seems= odd, and
> the rest of the sentence does not clarify. What does 'a careful an= alysis of any
> potential attacks' mean? Who is supposed to perform this analysis = and who
> can ensure it is 'careful enough' at any given point in time f= or any potential
> attacks?

AFAIK, the Security Considerations section is supposed to discuss security-= related issues that users need to be aware of, but not make normative state= ments. So all the normative requirements are in Section 3.1. (Where 'us= ers' in this case are implementations and specifications that decide to= make use of this implementation strategy in clients.)

Overall, it's a bit difficult to make normative requirements here, beca= use these are usually about the interoperability e.g. of a client and a ser= ver. But in this case, the client only needs to interoperate with itself (i= t needs to accept a token that it created itself) and the only real require= ment is that "client implementations MUST NOT be vulnerable to malicio= usly crafted tokens". The meaning of "vulnerable" and "= malicious" here depends a lot on the application/deployment-specific c= ontext; the document can really just highlight some potential issues that u= sers should take into consideration.

I'm open to concrete suggestions for text improvements, though.

I believe that I understood the point that you= are making. If I am to suggest text improvements, I would:
=
- s/recommended in general/recommended/
- clarify,= maybe in this very words that "the requirement is that client impleme= ntations must not be vulnerable to maliciously crafted tokens"
..= ..

--00000000000067e1b505a23c564e-- From nobody Wed Apr 1 08:41:33 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD3E3A114B for ; Wed, 1 Apr 2020 08:41:31 -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, FREEMAIL_FROM=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 amybRzCTRCAm for ; Wed, 1 Apr 2020 08:41:30 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 688553A114A for ; Wed, 1 Apr 2020 08:41:30 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id n10so144341iom.3 for ; Wed, 01 Apr 2020 08:41:30 -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:content-transfer-encoding; bh=6s4deMO0qNju8QVxWm+ilbfg947Dhy4E30O5bXiMSeQ=; b=QLwImT0HihGlXols0f0yoye63oEppePuNOH7T2LOAz9GzFqc96cFR7zKIcG/9XGnIJ UbdND/9XghUPtUvxExIeQM2PP30Iv/MNJY1WrrD6joXrox92QRIu11iJ1zeI6Ttpuxb/ ECUdUOLMgU3GeTzQgUsHoc2EHz5aPoWebj7triHFdlO51ULcxtjZxXxHH/WLukgLQFrc pE2vEyyuRiADi7gzunAXHe0f5svFJxd+psTUTDKwup0hY2J2nWOVhENPyw2Jf3GUf+4r mjRbylP2xayfXrBA+9FB1fVhLuJvgbb2dg6aOftqxuEno/lR9WRLkd0LnWtNgbzbiy+6 t/qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6s4deMO0qNju8QVxWm+ilbfg947Dhy4E30O5bXiMSeQ=; b=eonsoVujr6VTJtlBKrAtOwFV1l3xoXR1sQ8BZD/DGE4fQGBctiCc1FQXuaXLlyF3g+ BR8qIW6tKiheBqXYQtYJKDr0jFlpS1sSp/Yz4t6fNCic9GfsvTMCnuMihdh2s3AxOxjL IawAQ0GbZ1v4zzF3S1/RD3g5bCaswcU8osIlYxa1pV44mADDRYILhyBpCraQSduilzn2 NVbPUOLs5ezMH63inxzi06VHIau3IpeVeRKvUE2MuOAAvm/F4bbjYg7ohH83Gk9NHO5M M+kisZB5n6DCx6X4pxHNNLAGXiOW6hAsyksjG90BxtngDAsWApnPJtn8HpDOD4Q3Mo4N 20yQ== X-Gm-Message-State: ANhLgQ39ixnnFPko+2t9YpFPF//6fJZzasiwxssJuwSxDwPdxulo4XGm 4dVBbcFlgTIZhBG/WxYFmWDGJA9i6nj2m2U/Aey1zkPb X-Google-Smtp-Source: ADFU+vsL5/VODD2Q1OOYVClalHoVFHtacBTGA+f/ufkJRjUCCtHwXvH3kmA1VX+RjR/6CQY6gSj37sb4o8IQ+dC3GkY= X-Received: by 2002:a6b:8fd7:: with SMTP id r206mr21099898iod.109.1585755689542; Wed, 01 Apr 2020 08:41:29 -0700 (PDT) MIME-Version: 1.0 References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> In-Reply-To: From: Thomas Fossati Date: Wed, 1 Apr 2020 16:41:18 +0100 Message-ID: To: Klaus Hartke Cc: Esko Dijk , Jim Schaad , "core@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top 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, 01 Apr 2020 15:41:32 -0000 Hey Klaus, On Wed, Apr 1, 2020 at 11:56 AM Klaus Hartke wrote: > Thomas Fossati wrote: > > I don't have an opinion yet, but I'd need some clarification about the > > above before feeling comfortable with the direction... > > I guess there is some room for debate on what a CoAP endpoint with a > multicast IP address precisely means... RFC 7252 defines 224.0.1.187 > as the "All CoAP Nodes" address. So I see at least two possible > interpretations for the endpoint 224.0.1.187:9999: > > 1. All CoAP nodes that are listening on port 9999 on their unicast IP add= ress. This interpretation doesn't look right to me. > 2. All CoAP nodes that are "subscribed" to mailing list 9999. This is how I interpret it. > > I have the same trouble as you understanding the port mapping part. > > Where is that supposed to happen (kernel, CoAP stack, application)? > > And why is it needed? > > I always imagined multicast CoAP to work roughly like this: > > +---------------+ +-----------------+ > | | request _|_ | > | | .---> / \ 224.0.1.187 | > | _|_ / \___/ --. :9999 | > | 192.168.0.1 / \ ---=C2=B4 | \ | > | :54321 \___/ <---. _|_ / rewrite | > | | \ / \ <-=C2=B4 | > | | `--- \___/ 192.168.0.100 | > | | response | :5683 | > +---------------+ +-----------------+ > Client Server > > So, a server is listening for request messages on both a unicast IP > address/port and a multicast IP address/port. If a request message > arrives on the multicast IP address/port, it "rewrites" the UDP > destination to its unicast IP address/port and then processes the > message as if it had received it on its unicast IP address/port. > > The "rewrite" is at least needed for the IP address, because the > server cannot send its response from the multicast IP address. Not sure why you would also want to rewrite the transport endpoint? cheers, thanks! From nobody Wed Apr 1 13:28:09 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E263A07BF for ; Wed, 1 Apr 2020 13:28:08 -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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DL1wgb7HMRXX for ; Wed, 1 Apr 2020 13:28:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A413A07CB for ; Wed, 1 Apr 2020 13:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1585772882; bh=KmrpQijEwdiJgWZX4NUrFTRaoRdpmQ8+0wLvun4p+hM=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=SH1jCNNAch16mVa3qZRBd1H9iUcc/tAnwyR65osyLy35vlp5a84CrL/bf0QiLkBim Tsx/yKM/baTGcIT1Uh5oagQEpnejkIc1DWWgj4gUbfc9SbzSxEoYpzl8lNDjVfw0GE yB6xacGXNSfpPuSd7E2H+D4hmnJ8EcaLtc1xfYl8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([178.2.215.6]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MK3Rs-1jcuyt3APm-00LWRD; Wed, 01 Apr 2020 22:28:01 +0200 To: Thomas Fossati , Klaus Hartke Cc: "core@ietf.org" References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> From: Achim Kraus Message-ID: <02ec5628-3f7d-ff5d-620c-c0a90a4b89b0@gmx.net> Date: Wed, 1 Apr 2020 22:28:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:eBdRj2IIgGaNQFniRAWB8ZKWmULhdA+U6IRhMFB/uMdO+fx9tb4 nQmzIVxgD+BqxUfUCtNuelUyvgZ5qOggEPd/0z7MjAk+XhgvyCtzOcIpPpaEklOCtmuNMPu CbxBFs6EXDTUtZYglnftnnx1VLIftITnppO47y9QrE0JeXv2F9cmPCbRYFdTj3+KeXhrbGR pDIO7Oljks/rG5f6XLo3g== X-UI-Out-Filterresults: notjunk:1;V03:K0:Jx3/3S54B6g=:+bK2GISlKEuaPl8Pj+B6ZT o2dj3rBprvVjtSgcLa6kUZVJtBm8MKqekCiIiDzRT3TpP3Trwqen/vC1upcqtRB74qfraHwtl XmueHjsej2pepbvKa9/VSx0dd8+3XPoRK2nYOrU3/wjRJT+l5msP6pZGK9LPeXi2nLzJYbHe9 ZySfx4VY4JkWJiJwg0vrYV8M6iMUqmwzjn7kzLUGDmlh2t7cVqFZHe3CrH1CWEpOTwYnBL3MA 0GiA3qrhRQpbRQm8v6VWrLrCBseEvxBm6MZR8tVxqeQK3rpSv6WlPpCGtjVFyvKJBzxWLeAfr hf1yNYQIeOBoKmfxKUAi9QSyNBGXJJpMheIn4dsdZ4gqpnL/b0TiEa0NXxTzty4qDI4IUUlnk w5TZZ/k+poSoG7UVq9Ukpz2VtQB2smuEbiyRcJlwXRMO0Eo0Kp1jbAjcM0atvzQ/Yek8HEaA0 PkvNpBnAOsz1HlS7nI8MNj/SYo3P1t6jcvpALMgLbCel3uYFZko3tbUiRcrjC/VqjNshx4eTI 9c2iVuRtUAWGPy4AMRqiw/1COUNSz9LkmxYNcOTfMrhh/jvFuv/pKrjNtyUQFBKRGhmyQ/hH7 WG+tp3Qq/IGnx0XeyOIYC/aae084kLLGOAKPDrQMq5I5IsiKtYsn9IS4Q0T4V4paqIzjd2Ln+ zW6eLZZ4RJWTUekkZaSKg73y9/Yd+QW3D32TjGcuWPRpPcS4MPhoH0DzkZQOr0rPhAtPvygG4 2uAaMeK6Y3KbSGlraS5SH8yEneLcnAEjgsgnFDP7DUCRhvrQaH0Ah8uN2Z+OEyOirExOePZnZ 7IkZ/hVCFPJIPLHWEvM5KKMhh9ih3K7NPI3FBBlt6Yct/xpy2JUsDBfpz8aHeMCedyPXi7THg AVZ91wDN7wDPlMkbXb2AaASY7A/NtUgrldVEyJgjH0FHhBdGEzTC7HlQaIwTnCysFkLePPWNM l4q/WbppDHZ+FKN1cfBwTDjViUztSr+1YXwfg+8ukDp0Wrwn2y61UTuwEInKRwAxHlqTtSgU4 tlCrGYI9vFBPNaV5WGEEp1tohMJfJD0LOpDdYaYPbTGbneRVIw05nh4iaWRxaa1LPGT2WaYn9 IqXVdT3uTe40FbpWSaEU3gpSh4shjD0584SWrL9wd1bPB2nvmyMDFpK42aFmKlUKLj7pGJEck n2e1vB/8AxqNzQYv2h/nJQabp85iuwmlXIbyrC95jySDE8xqwUv/jraTI9v7ebdyYa5RYMneE Bwk2sybpsmZUgHBWC Archived-At: Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top 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, 01 Apr 2020 20:28:08 -0000 Hi, >> +---------------+ +-----------------+ >> | | request _|_ | >> | | .---> / \ 224.0.1.187 | >> | _|_ / \___/ --. :9999 | >> | 192.168.0.1 / \ ---=C2=B4 | \ | >> | :54321 \___/ <---. _|_ / rewrite | >> | | \ / \ <-=C2=B4 | >> | | `--- \___/ 192.168.0.100 | >> | | response | :5683 | >> +---------------+ +-----------------+ >> Client Server Nice diagram. > Not sure why you would also want to rewrite the transport endpoint? I tried to follow the discussion. The idea to change the port as well enables java (and I guess some more) to differentiate between multicast and unicast requests. Jim also mentioned, that it enables the use of multiple servers on the same host. I have not enough experience with multicast in different environments to see, if that may cause more trouble (e.g. firewall etc.). I would guess, that some implementations will just offer that variant, at least as configurable option (I would try do so for Californium). So my favorite for now is just implement it and see, what the user's feedback will be. If that idea gets declined (may be by negative feedback of users), I still think, that there is a demand for other means to distinguish between multicast and unicast requests. Maybe, either the usage of the uri-host option or a new option will help. This maybe considered as "too pragmatically", but on the other side I also don't see the "great benefit" in insist not to change the port. best regards Achim From nobody Wed Apr 1 14:35:27 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A835C3A0BD9 for ; Wed, 1 Apr 2020 14:35:25 -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 twN6msxVWRMQ for ; Wed, 1 Apr 2020 14:35:23 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26ED83A0BD7 for ; Wed, 1 Apr 2020 14:35:22 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 1 Apr 2020 14:35:10 -0700 From: Jim Schaad To: 'Esko Dijk' , 'Klaus Hartke' CC: 'Achim Kraus' , References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> In-Reply-To: Date: Wed, 1 Apr 2020 14:35:09 -0700 Message-ID: <01bc01d6086d$6ca1d150$45e573f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIXVeiVC1e4HIxpxUNqDgp/ppWwxwLeBdy3AlRjDEICXv5oEAIsRnhBAgGYZE4CNTatAadyiDoQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top 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, 01 Apr 2020 21:35:26 -0000 -----Original Message----- From: Esko Dijk =20 Sent: Wednesday, April 1, 2020 1:19 AM To: Jim Schaad ; 'Klaus Hartke' = Cc: 'Achim Kraus' ; core@ietf.org Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response = Layer, page 67, top Thanks Klaus & Jim,=20 it is clear to me now how you view the endpoint concept for multicast = messages. Because (to me) this is not fully compatible with the = definitions of "endpoint" and messaging model in RFC 7252 that I quoted, = it would be good to clarify this aspect more in = draft-ietf-core-groupcomm-bis i.e. refine the RFC 7252 endpoint = definitions for the multicast case and clarify the multicast messaging = model. I guess the rationale for the "mailing list" type behavior is = that the receiving node anyhow changes the endpoint (by changing = multicast IP address to a unicast IP address) so it could change the = port number as well, the responding endpoint will anyhow be different. = (To me that was unexpected and feels not entirely right - port number = should not need to change, but I can live with it.) I'm assuming by now there are no different opinions from the list on = this question anymore, so I'll proceed with some text for = draft-ietf-core-groupcomm-bis. Maybe a "SHOULD" level requirement on = keeping the UDP port number the same? And indicate if there are any good = reasons to change port number the server can do just that. [JLS] I do not believe that there is any reason to have a "SHOULD" = requirement on keeping the port number the same. If you want to say on = the allocated multicast address that has been registered with IANA, then = you are going to end up with different applications living on different = ports. There are trade offs for using different ports than different = addresses. The biggest being the idea of a well known address - using = the default port and default multicast address, vs making sure that you = minimize the traffic that a server needs to process by using different = addresses rather than different ports. =20 Jim Esko -----Original Message----- From: Jim Schaad =20 Sent: Tuesday, March 31, 2020 18:52 To: 'Klaus Hartke' ; Esko Dijk = Cc: 'Achim Kraus' ; core@ietf.org Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response = Layer, page 67, top -----Original Message----- From: Klaus Hartke =20 Sent: Tuesday, March 31, 2020 4:46 AM To: Esko Dijk Cc: Achim Kraus ; Jim Schaad = ; core@ietf.org Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response = Layer, page 67, top Esko Dijk wrote: > However CoAP does define that a Server responds from the same endpoint = that received the request, I believe. See below text quotes and = analysis. Yes. In the simple CoAP-over-UDP unicast NoSec case, if a request = message is sent from an endpoint 192.168.0.1:54321 ("client") to an = endpoint 192.168.0.100:5683 ("server"), the response message must be = sent from the endpoint 192.168.0.100:5683 to the endpoint = 192.168.0.1:54321. The response message cannot be sent from any other endpoint, because = then the client couldn't match the incoming message to its pending = request (it would appear to come from a different server). The response = message also cannot be sent to any other endpoint, because then the = client wouldn't get the message (it would be sent to a different = client). I view multicast messages basically like e-mail mailing lists. E.g. (IMO): A request message is sent from the endpoint 192.168.0.1:54321 to = the special endpoint 224.0.1.187:9999, the message magically shows up as = incoming message at the endpoint 192.168.0.100:5683, and the response = message must be sent from the endpoint 192.168.0.100:5683 to the = endpoint 192.168.0.1:54321. [JLS] What he said. And then after the first message comes in from = 192.168.0.100:5683, all of the messages from that endpoint are = correlated together so that you can do things like blockwise. Klaus From nobody Thu Apr 2 01:04:03 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB9A3A0D17 for ; Thu, 2 Apr 2020 01:04:01 -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 RXj5OjLqP8D1 for ; Thu, 2 Apr 2020 01:04:00 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 4944D3A0D16 for ; Thu, 2 Apr 2020 01:04:00 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id a43so3019740edf.6 for ; Thu, 02 Apr 2020 01:04:00 -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=Ri6ei4cgDguqv469TVwbh91Tii7GFlRcq4f6G7QLlA8=; b=UmuzyEJkFPSpjKNGiXisKx8ZOTQeg82YBvCUou9lIq/0g3Tpp8WFcxdmMN/0fapF42 IG9isk8c56FChas9XPhNqypwOVARj/qtT8FGiIWtXApNvwcUp6sdVIOOqaW2iWAHvW/5 McNWyJGTyYXCzDAzksu69VdHzwJjmFT+fGbkOWHxNz9qgNkOc+sh02SRAZPTszv6oE+A 4MSIgw27kpZkTy+yhqXKaWTeY9gE8CMz0JZDfAgta/KuXR99VOXWtSIieyvJx5KVglFU hTHi4QjiDxyw0CBJmK6BinuF9EgDORrN0VuFT895rlRt87TGiKpveLOSAcgm9Lh/a+wq L2aA== 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=Ri6ei4cgDguqv469TVwbh91Tii7GFlRcq4f6G7QLlA8=; b=MOK2EdqAldrzLFL3eYEsIRsK2qpLa8wc8tQsS7kQj54j/ZGIR0oEpivHpRBV2coqih 91MWmeRCwna1vodb1rl25vFvisMyvxXDI8i+c274bb9vC7ACogJgKUTShlz62K7lkBtI Am2rhQKlgifdeVHPaLSWHgzb63FcnBSib09tHlw7w8dLccDnHvt5bGDfYDZ0A4H+BPcu hDC2VI8JpYMyy8JxAxfAP8GjYaZo9wGuhe9mcKn2lu0bk0iaOcpBp/IIA8EfBj3gnyBh /CYsZ93qAfEXu3npEA8sThUhxwok87Mw4FuE8D3QHP+gfzR2i7RIHf5J+88Mwe3TQs5Q 2DKw== X-Gm-Message-State: AGi0PuZ40MJTu73xanF8hv9q++nL6KW/sWlQp0BktChAiD5JY73LyT1n kx0jBZBJyb4Dz2TZObV+QRixb0VoeXayxQIj+Tw= X-Google-Smtp-Source: APiQypLWupfIUo8BCSamTh4lfS5DOTe9mvlhZDwj4hwoMQ0/O7F1l2H6LRzPN3EOVptREieRwIUUZE1XvNEUWU1vXSs= X-Received: by 2002:a50:9e45:: with SMTP id z63mr1607718ede.338.1585814638637; Thu, 02 Apr 2020 01:03:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Abhijan Bhattacharyya Date: Thu, 2 Apr 2020 13:33:47 +0530 Message-ID: To: Thomas Fossati Cc: core Content-Type: multipart/alternative; boundary="0000000000003734d005a24a3eae" Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 02 Apr 2020 08:04:02 -0000 --0000000000003734d005a24a3eae Content-Type: text/plain; charset="UTF-8" Hi Thomas, What I am looking at is a situation where I have two nodes each having a time-varying resource. Both want to push the states of the respective resource to the other node within a common application context. However, these exchanges are naturally asynchronous. May be I can think of it more like a chat. A typical client-server or observe relationship will not serve the purpose. Actually both should have a client and server instance running under a common application. Then either each can *observe* the other, or can *post* the other. That is how we can do that without a central server. If my understanding is right, according to CoAP specification, the nodes which can have both server and client (to the origin server) are "intermediary" nodes. The only example of "intermediary" considered in the spec is the proxy node. But, anyway the situation in this case does not concern with intermediary. Both are origin server and end-client together. Is there any standardized mechanism to handle this situation? Thanks. On Wed, Apr 1, 2020 at 5:32 PM Thomas Fossati wrote: > Hi Abhijan, > > On 01/04/2020, 12:31, Abhijan Bhattacharyya < > abhijan.bhattacharyya@gmail.com> wrote: > > Is there any standardized mechanism to use CoAP for a P2P connection? > > Not sure whether RFC 7650 would fit your needs but worth having a > look -- if you haven't already. > > cheers > -- > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > -- Regards, Abhijan Bhattacharyya, *Technologist by profession [IoT| Internet Protocols| 5G]* --0000000000003734d005a24a3eae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Thomas,
What I am= looking at is a situation where I have two nodes each having a time-varyin= g resource. Both want=C2=A0to push the states of the respective resource to= the other node within a common application context. However, these exchan= ges are naturally asynchronous. May be I can think of it more like a chat. = A typical client-server or observe relationship will not serve the purpose.= Actually both should have a client and server instance running under a com= mon application. Then either each can *observe* the other, or can *post* th= e other. That is how we can do that without a central server.
If my understanding is right, according to CoAP specification, = the nodes which can have both server and client (to the origin=C2=A0server= ) are "intermediary" nodes. The only example of "intermediar= y" considered in the spec is the proxy node. But, anyway the situation= in this case does not concern with intermediary. Both are origin server an= d end-client together.

Is there any standardized m= echanism to handle this situation?

Thanks.

On Wed, Apr 1, 2020 at 5:32 PM Thomas Fossati <Thomas.Fossati@arm.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Hi Abhijan,

On 01/04/2020, 12:31, Abhijan Bhattacharyya <abhijan.bhattacharyya@gmail.com> wrote:
> Is there any standardized mechanism to use CoAP for a P2P connection?<= br>
Not sure whether RFC 7650 would fit your needs but worth having a
look -- if you haven't already.

cheers
--




IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you.


--
Regards,
Abhijan Bhattacharyya,
Technolo= gist by profession [IoT| Internet Protocols| 5G]
--0000000000003734d005a24a3eae-- From nobody Thu Apr 2 01:14:22 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5683A0D3C for ; Thu, 2 Apr 2020 01:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMRyQYgMC8Wu for ; Thu, 2 Apr 2020 01:14:17 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::718]) (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 911B73A0D3A for ; Thu, 2 Apr 2020 01:14:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UP1lupinZxEwdztbEYA/71Gecsu+zhZKhZrjXt1ZDXKAq7qf+12JXFExeep1ZVoD42nHOiBAELUXQ+ctFSVs5GvIIq3TxwFVYUFbgr5rfS8FrYvJP2kZKypzed28j8Back6kRXD8W9apV4XXm6SIOYs5rQLOaFt7hCyyE6zZq0Csu6ris/oZ2GNiu7O8Xaq/GEWU3N9cKk+7ug2qpMaCJIUU0lhV9k1G6YJB1xhpECkDSAQ1nDsu7NU/Nyh8dYCK8H2rwYHxFiB6qaadqdcGgPNVmyMU7aG6+ANsrThpgqisKBFwFFuw9sPWbNZyJliyUmynVBKB6nymO+QMZaAVqg== 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=vRKKmAVVu/gUVnbGjxMk3eF/x/F3hBPH1jqgKhJ83WU=; b=YRCDiD1oVwHwK5trZsGFgQveI1XEC74JCZZWSJVO6N2aSCBQPowq/MbzKL1TBLPqOdIEVghQ5QnORVAX+yvTyCfHYt0QBGTmeuaYbKQOibpj6aARESVJCYBlNhdvr90Sw9p8lK/0VWTLcAdM7wVnDNS41abeURM2+1aVESjoOZr+7/8JQcBduBhO9emG98Psg/GII6xVtwall7ro1m4LQqViNdAOMWlPU0nkExANToCbXVwORYcbBvkSih35SIKmmIThMiQwQsBFQSe5XlEliE9GtZIJ68QFLjertZgLUXA77XC+FwAldPaO40NRvgGO/zC2/jSqEYf/7Xj906iIDA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector2-iotconsultancynl-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vRKKmAVVu/gUVnbGjxMk3eF/x/F3hBPH1jqgKhJ83WU=; b=XSTnXlMSmHZlXN8Uzi7snyISgQTTdCa707d/GBXW4GBBRPu2CUqx+1J/7979GtFZJV6m570DclRIZSsLPBYEv75eaemeABD5zbP+RNmIjpM9zYMtltafXHLJVqZNlUCMoJPNddWozNZTpgTIovX87kvzSTNIZ8dJ7ON7P/eJIMs= Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM (10.161.62.28) by AM5P190MB0483.EURP190.PROD.OUTLOOK.COM (10.161.64.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Thu, 2 Apr 2020 08:14:14 +0000 Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::8c96:a66b:e170:bf8f]) by AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::8c96:a66b:e170:bf8f%3]) with mapi id 15.20.2856.019; Thu, 2 Apr 2020 08:14:13 +0000 From: Esko Dijk To: Jim Schaad , 'Klaus Hartke' CC: 'Achim Kraus' , "core@ietf.org" Thread-Topic: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top Thread-Index: AQHWBAJ4QQxxhgNVoE6+AM1rLNkaVahcnYmAgAAdZICABcLe8IAAHjWAgABVYQCAAP5CIIAA4y2AgACa8sA= Date: Thu, 2 Apr 2020 08:14:13 +0000 Message-ID: References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> <01bc01d6086d$6ca1d150$45e573f0$@augustcellars.com> In-Reply-To: <01bc01d6086d$6ca1d150$45e573f0$@augustcellars.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl; x-originating-ip: [85.147.167.236] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 996551ff-cd03-4f89-f9d9-08d7d6ddd496 x-ms-traffictypediagnostic: AM5P190MB0483: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM5P190MB0275.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(396003)(39830400003)(136003)(366004)(376002)(346002)(508600001)(5660300002)(81156014)(81166006)(110136005)(9686003)(8676002)(26005)(33656002)(186003)(86362001)(2906002)(52536014)(66446008)(66476007)(66556008)(64756008)(76116006)(316002)(44832011)(7696005)(4326008)(6506007)(53546011)(55016002)(54906003)(66946007)(71200400001)(8936002); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gfePY98s89GfIlyxf6epVMbOoW/jAw7a6d/iWc4KcRFfXsoFNatAnajHAlyTqnnvzQiiv61idRcYz6VyCa2NZQ4YW2XmZZjzP9yU6MLAH8ddbifLG48yuxlp82neayToNU/ykFhYGByrso7Li7AogARivyPTJdRT6YoU3ug2SllAC7CETjtBnqZVVsjPAaGL7Wqu6mrXN6pqAW7wLs2aXeRbRleGsUbn533XPbkg8CIEu/oSnlQ8ZPzYVAe2Mzl3H02aT7dB+3SaHS82c6GHqvdVXABVs4dQnX4S3+oC1qhL1cIhZ19Q0KtcYlQ96+Rhr9KuoZVD4Ab76xKugCaJZy236aKlQSTL62xIsF2WK2xziRMz73pqv6ino850MFSArOhuy2PLggFx3lwtCow4QABodhk1CphqxZJE6VeBA1Nhy+GuCuF+HdjnZGr5c+1j x-ms-exchange-antispam-messagedata: ODgm8GU4hwIDmg80b7HwWWCCFEKH/ZD+50YEnfKkrqRG4/oK9dSS7EbwQMmq2jUl3XNkfRd4/DLZVCz6xSw7g6/ujAczyiMY4QfmxPR5f7x/x2+c3R1zTDSUn5RaMfcCwZT3rsGSNVYG4Hxs5TcUqw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-Network-Message-Id: 996551ff-cd03-4f89-f9d9-08d7d6ddd496 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2020 08:14:13.7238 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ya4FvZvzI9vWDLd3WdZ6Bt/CC0t+ovxzulPbtvotHWMVWaMgBxzZ1CkGNvlhsWeD/Zzxh0B+3DY88bM4a/Tnq5tYhkxY7QQtEYnAZhjTHXk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0483 Archived-At: Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top 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, 02 Apr 2020 08:14:20 -0000 SGVsbG8gSmltLA0KDQo+IFtKTFNdIEkgZG8gbm90IGJlbGlldmUgdGhhdCB0aGVyZSBpcyBhbnkg cmVhc29uIHRvIGhhdmUgYSAiU0hPVUxEIiByZXF1aXJlbWVudCBvbiBrZWVwaW5nIHRoZSBwb3J0 IG51bWJlciB0aGUgc2FtZS4gIA0KPiBJZiB5b3Ugd2FudCB0byBzYXkgb24gdGhlIGFsbG9jYXRl ZCBtdWx0aWNhc3QgYWRkcmVzcyB0aGF0IGhhcyBiZWVuIHJlZ2lzdGVyZWQgd2l0aCBJQU5BLCB0 aGVuIHlvdSBhcmUgZ29pbmcgdG8gZW5kIHVwIA0KPiB3aXRoIGRpZmZlcmVudCBhcHBsaWNhdGlv bnMgbGl2aW5nIG9uIGRpZmZlcmVudCBwb3J0cy4gIFRoZXJlIGFyZSB0cmFkZSBvZmZzIGZvciB1 c2luZyBkaWZmZXJlbnQgcG9ydHMgdGhhbiBkaWZmZXJlbnQgDQo+IGFkZHJlc3Nlcy4gIFRoZSBi aWdnZXN0IGJlaW5nIHRoZSBpZGVhIG9mIGEgd2VsbCBrbm93biBhZGRyZXNzIC0gdXNpbmcgdGhl IGRlZmF1bHQgcG9ydCBhbmQgZGVmYXVsdCBtdWx0aWNhc3QgYWRkcmVzcywgDQo+IHZzIG1ha2lu ZyBzdXJlIHRoYXQgeW91IG1pbmltaXplIHRoZSB0cmFmZmljIHRoYXQgYSBzZXJ2ZXIgbmVlZHMg dG8gcHJvY2VzcyBieSB1c2luZyBkaWZmZXJlbnQgYWRkcmVzc2VzIHJhdGhlciB0aGFuIGRpZmZl cmVudCBwb3J0cy4gIA0KDQpObyBJIHdhcyBub3QgcmVmZXJyaW5nIHNwZWNpZmljYWxseSB0byBJ QU5BIGFsbG9jYXRlZCBtdWx0aWNhc3QgYWRkcmVzc2VzIC0gSSBtZWFudCBmb3IgYW55IG11bHRp Y2FzdCBhZGRyZXNzZXMuIEJlY2F1c2UgdGhlICJ1c3VhbCIgYXBwcm9hY2ggb2YgdW5pY2FzdCBp cyB0byByZXNwb25kIGZyb20gdGhlIHNhbWUgZW5kcG9pbnQgKGFkZHJlc3MgKyBVRFAgcG9ydCkg dGhhdCB3YXMgcmVjZWl2aW5nIHRoZSByZXF1ZXN0LCB0aGUgcnVsZSBzaG91bGQgYmUgZm9yIG11 bHRpY2FzdCB0aGUgc2FtZSB3aGVyZSBwb3NzaWJsZS4gTm93IGZvciB0aGUgYWRkcmVzcyB0aGF0 J3Mgb2J2aW91c2x5IG5vdCBwb3NzaWJsZSBidXQgdGhlIFVEUCBwb3J0IHZhbHVlIGNhbiBhdCBs ZWFzdCByZW1haW4gdGhlIHNhbWUuIFNvIHRoZSBpZGVhIGlzIHRvIHJlY29tbWVuZCB0byBrZWVw IHRoYXQgdGhlIHNhbWUgKnVubGVzcyogdGhlcmUncyBhIGdvb2QgcmVhc29uIHRvIGNoYW5nZSBp dCBvbiB0aGUgc2VydmVyIHNpZGUuIA0KDQpTb21lIHJlYXNvbnMgdG8gZG8gc28gd2VyZSBtZW50 aW9uZWQgYnkgeW91IGFuZCBkaXNjdXNzZWQgaW4gdGhpcyB0aHJlYWQsIGUuZy4gYXMgYSB3YXkg dG8gZGlmZmVyZW50aWF0ZSBhIHVuaWNhc3QgdnMgYSBtdWx0aWNhc3QgcmVxdWVzdC4gT3IgdG8g ImludGVybmFsbHkgZGVsZWdhdGUiIGluIHRoZSBzZXJ2ZXIgYSByZXF1ZXN0IHRvIGEgc2VydmVy IG9uIGFub3RoZXIgZW5kcG9pbnQuDQpJZiBhICJTSE9VTEQiIGlzIG5vdCByaWdodCB0aGVuIHBl cmhhcHMgYSAicmVjb21tZW5kZWQiIHdpdGhvdXQgY2FwaXRhbHMgaXMgcmlnaHQuIEEgIk1BWSIg aXMgbm90IG5lZWRlZCBoZXJlIGJlY2F1c2UgcGVyIFJGQyA3MjUyIHRoZSBjbGllbnQgYWxyZWFk eSBoYXMgYSBsZW5pZW50IG1hdGNoaW5nIGFsZ29yaXRobSAtIHVzaW5nIG9ubHkgdGhlIFRva2Vu IHZhbHVlLiBTbyB3ZSBkb24ndCBuZWVkIGFuIGFkZGl0aW9uYWwgInNlcnZlciBNQVkgY2hhbmdl IHBvcnQgbnVtYmVyIiBhcyBhIG1lYW5zIHRvIGZvcmNlIHRoZSBjbGllbnQgdG8gbm90IG1hdGNo IHJlc3BvbnNlcyBiYXNlZCBvbiB0aGUgc291cmNlIFVEUCBwb3J0IG51bWJlciwgYmVjYXVzZSBS RkMgNzI1MiBhbHJlYWR5IHRlbGxzIHRoYXQuDQoNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+IA0KU2Vu dDogV2VkbmVzZGF5LCBBcHJpbCAxLCAyMDIwIDIzOjM1DQpUbzogRXNrbyBEaWprIDxlc2tvLmRp amtAaW90Y29uc3VsdGFuY3kubmw+OyAnS2xhdXMgSGFydGtlJyA8aGFydGtlQHByb2plY3Rjb29s LmRlPg0KQ2M6ICdBY2hpbSBLcmF1cycgPGFjaGlta3JhdXNAZ214Lm5ldD47IGNvcmVAaWV0Zi5v cmcNClN1YmplY3Q6IFJFOiBbY29yZV0gUkZDIDcyNTIgLSA4LjIgLSBNdWx0aWNhc3QgLSBSZXF1 ZXN0IC8gUmVzcG9uc2UgTGF5ZXIsIHBhZ2UgNjcsIHRvcA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEVza28gRGlqayA8ZXNrby5kaWprQGlvdGNvbnN1bHRhbmN5Lm5s PiANClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMSwgMjAyMCAxOjE5IEFNDQpUbzogSmltIFNjaGFh ZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47ICdLbGF1cyBIYXJ0a2UnIDxoYXJ0a2VAcHJvamVj dGNvb2wuZGU+DQpDYzogJ0FjaGltIEtyYXVzJyA8YWNoaW1rcmF1c0BnbXgubmV0PjsgY29yZUBp ZXRmLm9yZw0KU3ViamVjdDogUkU6IFtjb3JlXSBSRkMgNzI1MiAtIDguMiAtIE11bHRpY2FzdCAt IFJlcXVlc3QgLyBSZXNwb25zZSBMYXllciwgcGFnZSA2NywgdG9wDQoNClRoYW5rcyBLbGF1cyAm IEppbSwgDQoNCml0IGlzIGNsZWFyIHRvIG1lIG5vdyBob3cgeW91IHZpZXcgdGhlIGVuZHBvaW50 IGNvbmNlcHQgZm9yIG11bHRpY2FzdCBtZXNzYWdlcy4gQmVjYXVzZSAodG8gbWUpIHRoaXMgaXMg bm90IGZ1bGx5IGNvbXBhdGlibGUgd2l0aCB0aGUgZGVmaW5pdGlvbnMgb2YgImVuZHBvaW50IiBh bmQgbWVzc2FnaW5nIG1vZGVsIGluIFJGQyA3MjUyIHRoYXQgSSBxdW90ZWQsIGl0IHdvdWxkIGJl IGdvb2QgdG8gY2xhcmlmeSB0aGlzIGFzcGVjdCBtb3JlIGluIGRyYWZ0LWlldGYtY29yZS1ncm91 cGNvbW0tYmlzIGkuZS4gcmVmaW5lIHRoZSBSRkMgNzI1MiBlbmRwb2ludCBkZWZpbml0aW9ucyBm b3IgdGhlIG11bHRpY2FzdCBjYXNlIGFuZCBjbGFyaWZ5IHRoZSBtdWx0aWNhc3QgbWVzc2FnaW5n IG1vZGVsLiAgSSBndWVzcyB0aGUgcmF0aW9uYWxlIGZvciB0aGUgIm1haWxpbmcgbGlzdCIgdHlw ZSBiZWhhdmlvciBpcyB0aGF0IHRoZSByZWNlaXZpbmcgbm9kZSBhbnlob3cgY2hhbmdlcyB0aGUg ZW5kcG9pbnQgKGJ5IGNoYW5naW5nIG11bHRpY2FzdCBJUCBhZGRyZXNzIHRvIGEgdW5pY2FzdCBJ UCBhZGRyZXNzKSBzbyBpdCBjb3VsZCBjaGFuZ2UgdGhlIHBvcnQgbnVtYmVyIGFzIHdlbGwsIHRo ZSByZXNwb25kaW5nIGVuZHBvaW50IHdpbGwgYW55aG93IGJlIGRpZmZlcmVudC4gKFRvIG1lIHRo YXQgd2FzIHVuZXhwZWN0ZWQgYW5kIGZlZWxzIG5vdCBlbnRpcmVseSByaWdodCAgLSBwb3J0IG51 bWJlciBzaG91bGQgbm90IG5lZWQgdG8gY2hhbmdlLCBidXQgSSBjYW4gbGl2ZSB3aXRoIGl0LikN Cg0KSSdtIGFzc3VtaW5nIGJ5IG5vdyB0aGVyZSBhcmUgbm8gZGlmZmVyZW50IG9waW5pb25zIGZy b20gdGhlIGxpc3Qgb24gdGhpcyBxdWVzdGlvbiBhbnltb3JlLCBzbyBJJ2xsIHByb2NlZWQgd2l0 aCBzb21lIHRleHQgZm9yIGRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tYmlzLiBNYXliZSBhICJT SE9VTEQiIGxldmVsIHJlcXVpcmVtZW50IG9uIGtlZXBpbmcgdGhlIFVEUCBwb3J0IG51bWJlciB0 aGUgc2FtZT8gQW5kIGluZGljYXRlIGlmIHRoZXJlIGFyZSBhbnkgZ29vZCByZWFzb25zIHRvIGNo YW5nZSBwb3J0IG51bWJlciB0aGUgc2VydmVyIGNhbiBkbyBqdXN0IHRoYXQuDQoNCltKTFNdIEkg ZG8gbm90IGJlbGlldmUgdGhhdCB0aGVyZSBpcyBhbnkgcmVhc29uIHRvIGhhdmUgYSAiU0hPVUxE IiByZXF1aXJlbWVudCBvbiBrZWVwaW5nIHRoZSBwb3J0IG51bWJlciB0aGUgc2FtZS4gIElmIHlv dSB3YW50IHRvIHNheSBvbiB0aGUgYWxsb2NhdGVkIG11bHRpY2FzdCBhZGRyZXNzIHRoYXQgaGFz IGJlZW4gcmVnaXN0ZXJlZCB3aXRoIElBTkEsIHRoZW4geW91IGFyZSBnb2luZyB0byBlbmQgdXAg d2l0aCBkaWZmZXJlbnQgYXBwbGljYXRpb25zIGxpdmluZyBvbiBkaWZmZXJlbnQgcG9ydHMuICBU aGVyZSBhcmUgdHJhZGUgb2ZmcyBmb3IgdXNpbmcgZGlmZmVyZW50IHBvcnRzIHRoYW4gZGlmZmVy ZW50IGFkZHJlc3Nlcy4gIFRoZSBiaWdnZXN0IGJlaW5nIHRoZSBpZGVhIG9mIGEgd2VsbCBrbm93 biBhZGRyZXNzIC0gdXNpbmcgdGhlIGRlZmF1bHQgcG9ydCBhbmQgZGVmYXVsdCBtdWx0aWNhc3Qg YWRkcmVzcywgdnMgbWFraW5nIHN1cmUgdGhhdCB5b3UgbWluaW1pemUgdGhlIHRyYWZmaWMgdGhh dCBhIHNlcnZlciBuZWVkcyB0byBwcm9jZXNzIGJ5IHVzaW5nIGRpZmZlcmVudCBhZGRyZXNzZXMg cmF0aGVyIHRoYW4gZGlmZmVyZW50IHBvcnRzLiAgDQoNCglKaW0NCg0KDQpFc2tvDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxh cnMuY29tPiANClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDMxLCAyMDIwIDE4OjUyDQpUbzogJ0tsYXVz IEhhcnRrZScgPGhhcnRrZUBwcm9qZWN0Y29vbC5kZT47IEVza28gRGlqayA8ZXNrby5kaWprQGlv dGNvbnN1bHRhbmN5Lm5sPg0KQ2M6ICdBY2hpbSBLcmF1cycgPGFjaGlta3JhdXNAZ214Lm5ldD47 IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbY29yZV0gUkZDIDcyNTIgLSA4LjIgLSBNdWx0 aWNhc3QgLSBSZXF1ZXN0IC8gUmVzcG9uc2UgTGF5ZXIsIHBhZ2UgNjcsIHRvcA0KDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEtsYXVzIEhhcnRrZSA8aGFydGtlQHByb2pl Y3Rjb29sLmRlPiANClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDMxLCAyMDIwIDQ6NDYgQU0NClRvOiBF c2tvIERpamsgPGVza28uZGlqa0Bpb3Rjb25zdWx0YW5jeS5ubD4NCkNjOiBBY2hpbSBLcmF1cyA8 YWNoaW1rcmF1c0BnbXgubmV0PjsgSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47 IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29yZV0gUkZDIDcyNTIgLSA4LjIgLSBNdWx0 aWNhc3QgLSBSZXF1ZXN0IC8gUmVzcG9uc2UgTGF5ZXIsIHBhZ2UgNjcsIHRvcA0KDQpFc2tvIERp amsgd3JvdGU6DQo+IEhvd2V2ZXIgQ29BUCBkb2VzIGRlZmluZSB0aGF0IGEgU2VydmVyIHJlc3Bv bmRzIGZyb20gdGhlIHNhbWUgZW5kcG9pbnQgdGhhdCByZWNlaXZlZCB0aGUgcmVxdWVzdCwgSSBi ZWxpZXZlLiBTZWUgYmVsb3cgdGV4dCBxdW90ZXMgYW5kIGFuYWx5c2lzLg0KDQpZZXMuIEluIHRo ZSBzaW1wbGUgQ29BUC1vdmVyLVVEUCB1bmljYXN0IE5vU2VjIGNhc2UsIGlmIGEgcmVxdWVzdCBt ZXNzYWdlIGlzIHNlbnQgZnJvbSBhbiBlbmRwb2ludCAxOTIuMTY4LjAuMTo1NDMyMSAoImNsaWVu dCIpIHRvIGFuIGVuZHBvaW50IDE5Mi4xNjguMC4xMDA6NTY4MyAoInNlcnZlciIpLCB0aGUgcmVz cG9uc2UgbWVzc2FnZSBtdXN0IGJlIHNlbnQgZnJvbSB0aGUgZW5kcG9pbnQgMTkyLjE2OC4wLjEw MDo1NjgzIHRvIHRoZSBlbmRwb2ludCAxOTIuMTY4LjAuMTo1NDMyMS4NCg0KVGhlIHJlc3BvbnNl IG1lc3NhZ2UgY2Fubm90IGJlIHNlbnQgZnJvbSBhbnkgb3RoZXIgZW5kcG9pbnQsIGJlY2F1c2Ug dGhlbiB0aGUgY2xpZW50IGNvdWxkbid0IG1hdGNoIHRoZSBpbmNvbWluZyBtZXNzYWdlIHRvIGl0 cyBwZW5kaW5nIHJlcXVlc3QgKGl0IHdvdWxkIGFwcGVhciB0byBjb21lIGZyb20gYSBkaWZmZXJl bnQgc2VydmVyKS4gVGhlIHJlc3BvbnNlIG1lc3NhZ2UgYWxzbyBjYW5ub3QgYmUgc2VudCB0byBh bnkgb3RoZXIgZW5kcG9pbnQsIGJlY2F1c2UgdGhlbiB0aGUgY2xpZW50IHdvdWxkbid0IGdldCB0 aGUgbWVzc2FnZSAoaXQgd291bGQgYmUgc2VudCB0byBhIGRpZmZlcmVudCBjbGllbnQpLg0KDQpJ IHZpZXcgbXVsdGljYXN0IG1lc3NhZ2VzIGJhc2ljYWxseSBsaWtlIGUtbWFpbCBtYWlsaW5nIGxp c3RzLiBFLmcuDQooSU1PKTogQSByZXF1ZXN0IG1lc3NhZ2UgaXMgc2VudCBmcm9tIHRoZSBlbmRw b2ludCAxOTIuMTY4LjAuMTo1NDMyMSB0byB0aGUgc3BlY2lhbCBlbmRwb2ludCAyMjQuMC4xLjE4 Nzo5OTk5LCB0aGUgbWVzc2FnZSBtYWdpY2FsbHkgc2hvd3MgdXAgYXMgaW5jb21pbmcgbWVzc2Fn ZSBhdCB0aGUgZW5kcG9pbnQgMTkyLjE2OC4wLjEwMDo1NjgzLCBhbmQgdGhlIHJlc3BvbnNlIG1l c3NhZ2UgbXVzdCBiZSBzZW50IGZyb20gdGhlIGVuZHBvaW50IDE5Mi4xNjguMC4xMDA6NTY4MyB0 byB0aGUgZW5kcG9pbnQgMTkyLjE2OC4wLjE6NTQzMjEuDQoNCltKTFNdIFdoYXQgaGUgc2FpZC4g IEFuZCB0aGVuIGFmdGVyIHRoZSBmaXJzdCBtZXNzYWdlIGNvbWVzIGluIGZyb20gMTkyLjE2OC4w LjEwMDo1NjgzLCBhbGwgb2YgdGhlIG1lc3NhZ2VzIGZyb20gdGhhdCBlbmRwb2ludCBhcmUgY29y cmVsYXRlZCB0b2dldGhlciBzbyB0aGF0IHlvdSBjYW4gZG8gdGhpbmdzIGxpa2UgYmxvY2t3aXNl Lg0KDQpLbGF1cw0KDQoNCg== From nobody Thu Apr 2 01:22:57 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951DA3A0D5F for ; Thu, 2 Apr 2020 01:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-m1zgJR-imv for ; Thu, 2 Apr 2020 01:22:55 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60132.outbound.protection.outlook.com [40.107.6.132]) (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 CE61B3A0D5D for ; Thu, 2 Apr 2020 01:22:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T4H8frLnIk+qEcK7jVw3+LIuApvnj/5o0sBV546aUZsPvXPV4b1v74bohxiRcSPFMJN2mZxz/tHhfkG0hTlgImffnoFCeb4NvKAXAhE+e7/kWDerJK4Iy6b06SJMGrGm5X2liSQjvMrozj/yuXeO47W2YZQChmOxOIrHijZnZYAT3KaACcwVEE84pCZyo5iupfMg7neYEScDfvIaKo/NQXD2MgVit4t5XtjoEtyN0rEx4G8xj9Vrs/QTi9dUoDBW+XmtN2G/3B07WSS+1/6uhe8IUIELgM/0sp5SBxw27dl/zdMaK+mftk417WSod6kZcIgRpx+ByuNdhPriWc8qig== 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=sYEw7eJcFdMRK+iksi2KHphMZ12WLCGr5t/uJ3BiESg=; b=hcu3FC00lfoi2thgIulOfcH3YlFWaQlz2xvQEic3vBo79EHc2xL7/62zdHRRXO6IOMpmllp/yrNo9geFDCCcUEWsGtp74RnTmy0uWQm0mW30KVdCzZyGdBqC9Q1xy9I8Rse8LYCbzh97lKtHYo65diM5CvKBDg3UWlN8KZvGmAD3wQv1RiPXUT2JKKiIQkPvgOBBoUgCkFy/dDtYMtz+sU+slRyL8q1I+PNQ87t9GtyR0p9okvy6CH6Mdl8/bru9xlTq7xQaCXZ4mdEP0m+NS+xEo883WvkvB6qT3BjG8r9+zM8ExK1FhjuB1OroxG+67n/1tKiRP5w8cdb+Wqd0Iw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector2-iotconsultancynl-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sYEw7eJcFdMRK+iksi2KHphMZ12WLCGr5t/uJ3BiESg=; b=chlWRpBntrY2n6MM6uaR72RYGG6L3YhO6vvAlO9m1d0m6leASJG4fbkbbIeEABxJo4mSOjdITxa6wuA8zitlsMx8YmgllLd9yDvNgfBMoEL50TygFjY3nIn6rm+Rjl/PwcfCajR8FOPnKWem+ltVoK6aepe2mIeXnrUp4MULoVA= Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM (10.161.62.28) by AM5P190MB0562.EURP190.PROD.OUTLOOK.COM (10.161.81.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.19; Thu, 2 Apr 2020 08:22:52 +0000 Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::8c96:a66b:e170:bf8f]) by AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::8c96:a66b:e170:bf8f%3]) with mapi id 15.20.2856.019; Thu, 2 Apr 2020 08:22:52 +0000 From: Esko Dijk To: Achim Kraus , Thomas Fossati , Klaus Hartke CC: "core@ietf.org" Thread-Topic: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top Thread-Index: AQHWBAJ4QQxxhgNVoE6+AM1rLNkaVahcnYmAgAAdZICABcLe8IAAHjWAgABVYQCAAP5CIIAADCeAgAAkYYCAAE/IAIAAUBuAgADFdpA= Date: Thu, 2 Apr 2020 08:22:51 +0000 Message-ID: References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> <02ec5628-3f7d-ff5d-620c-c0a90a4b89b0@gmx.net> In-Reply-To: <02ec5628-3f7d-ff5d-620c-c0a90a4b89b0@gmx.net> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl; x-originating-ip: [85.147.167.236] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bbf7ddc0-e5d8-4027-c7ab-08d7d6df096b x-ms-traffictypediagnostic: AM5P190MB0562: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM5P190MB0275.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(376002)(39830400003)(136003)(396003)(346002)(366004)(8676002)(71200400001)(53546011)(44832011)(2906002)(186003)(33656002)(66476007)(81156014)(81166006)(52536014)(66946007)(7696005)(76116006)(8936002)(55016002)(26005)(6506007)(9686003)(966005)(4326008)(66446008)(64756008)(5660300002)(86362001)(316002)(110136005)(508600001)(66556008); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Bkqklk8+V94i7MNoUmA7K0NqOBwVxc9Qv91JVXPzjQ4iilAbFiUcgPIEvHoPyyNw1ZEeRWqkWfFPfsJZ5rtvLsWGFXnA758U2gtYJGxuzKPa9JL5faEXGPoMWHGRMD5qjWQDfnwBVbAbjqYZBtRRx8/7cOPzxMZQAou1BsOKBP/dOd2Bl1MgL/wkPwlQaWYU4UQvWW2UuKai0hVMQ3CIod5rx71B44wZu6NoLTgoOOQNbLOVMePw0N0OMRk1vzdlRApgeoOHgDPNiCUuvRYRWgRA6YoufBByuJoB6SPlXarK0DiNMQY61MtZ8DV/YCmKV5o4TIVFGQ4tqeAmfpgZ5D/Yd/Ddboq9McDxljx+5/yKmiAZh2huzNChQ6Ms4JxtTorRyDzPLHoJqMumNhJ+f5qcipjrC9hCR3GpHuYBh2u14io8LMWjfSIUvRGxHqYrW/iWxnCC0MwfIHYI8GJzuGCWvheAyyJhh04iIPZhXrSTWZuIxVJLp+JHUFbx0mAC7OZP85Ssfh5R76VxcCRpjA== x-ms-exchange-antispam-messagedata: qaCXnpaYey9VayhNESLN8e+LOT7xw/g+8YM7DLfYrRplrsU/7sl8OJtHHdjf6ekuknMacfruQv6cDCjnHkeEzfvU6PLg088ULhbdW+4GkhurAKWFM7ITMN98ChmHQGW+oQycnfA0ulhbhYQkOS0+uA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-Network-Message-Id: bbf7ddc0-e5d8-4027-c7ab-08d7d6df096b X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2020 08:22:51.8956 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SWpiCzVlIiLNnO2p/2RoMgQ6cOgjNKywFO/TcTgl2G+Sh3E4jHu3vpxfflodP3tTMPSDZ1P+dQt3gs3bECGxTpQ0Awcf4HB4YT8ubJV1W6c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0562 Archived-At: Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top 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, 02 Apr 2020 08:22:57 -0000 SGVsbG8gQWNoaW0sDQoNCihzZWUgYWxzbyBteSByZXNwb25zZSB0byBKaW0pDQpVc2luZyB0aGUg VURQIHBvcnQgbnVtYmVyIHRvIGRldGVjdCBhIG11bHRpY2FzdCByZXF1ZXN0IHZzIGEgdW5pY2Fz dCByZXF1ZXN0IHNvdW5kcyBsaWtlIGEgZ29vZCB1c2UgY2FzZS4gSnVzdCBjdXJpb3VzIC0gSSBh c3N1bWUgdGhlIHNlY3VyaXR5IGFzcGVjdCByZXF1aXJlbWVudHMgb2YgUkZDIDcyNTIgYXJlIHRh a2VuIGNhcmUgb2YgaW4gdGhpcyB1c2UgY2FzZT8NCg0KVGhhdCBpcywgYSBwcm9wZXIgY2xpZW50 IHNlbmRzIGl0cyBtdWx0aWNhc3QgcmVxdWVzdHMgYWx3YXlzIHRvIHBvcnQgOjk5OTkgYW5kIHRo ZSBzZXJ2ZXIgdHJlYXRzIHRoZXNlIGFzIG11bHRpY2FzdCByZXF1ZXN0cyAoZS5nLiBvbmx5IGFs bG93IHRoZSByZXF1ZXN0IGZvciBzcGVjaWZpYyByZXNvdXJjZXMpLg0KQSBtYWxpY2lvdXMgY2xp ZW50IG1heSBzZW5kcyBpdHMgbXVsdGljYXN0IHJlcXVlc3QgdG8gcG9ydCA6NTY4MyB0byBieXBh c3MgdGhlIGFib3ZlIGNoZWNrcy4gSSBhc3N1bWUgdGhlIHNlcnZlciBkb2Vzbid0IHJlc3BvbmQg dG8gdGhpcyByZXF1ZXN0LCBiZWNhdXNlIHRoZSBtdWx0aWNhc3QgYWRkcmVzcyBpcyBub3QgYm91 bmQgdG8gcG9ydCA1NjgzIGJ1dCB0byBzYXkgOTk5OSBvbmx5Lg0KSWYgdGhlIENvQVAgc2VydmVy IGF0IHBvcnQgNTY4MyBjYW5ub3QgZGlzdGluZ3Vpc2ggYmV0d2VlbiB1bmljYXN0L211bHRpY2Fz dCB0aGF0IHdvdWxkIGJlIGEgYmFkIHNpdHVhdGlvbiBhbmQgdGhlIHNlY3VyaXR5IHJlcXVpcmVt ZW50cyBvZiBSRkMgNzI1MiBhcmUgbm90IG1ldC4NCg0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogY29yZSA8Y29yZS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYg T2YgQWNoaW0gS3JhdXMNClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMSwgMjAyMCAyMjoyOA0KVG86 IFRob21hcyBGb3NzYXRpIDx0aG8uaWV0ZkBnbWFpbC5jb20+OyBLbGF1cyBIYXJ0a2UgPGhhcnRr ZUBwcm9qZWN0Y29vbC5kZT4NCkNjOiBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVd IFJGQyA3MjUyIC0gOC4yIC0gTXVsdGljYXN0IC0gUmVxdWVzdCAvIFJlc3BvbnNlIExheWVyLCBw YWdlIDY3LCB0b3ANCg0KSGksDQoNCj4+ICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAg ICstLS0tLS0tLS0tLS0tLS0tLSsNCj4+IHwgICAgICAgICAgICAgICB8ICAgIHJlcXVlc3QgICAg X3xfICAgICAgICAgICAgICAgIHwNCj4+IHwgICAgICAgICAgICAgICB8ICAgICAgICAuLS0tPiAv ICAgXCAgIDIyNC4wLjEuMTg3IHwNCj4+IHwgICAgICAgICAgICAgIF98XyAgICAgIC8gICAgICBc X19fLyAtLS4gICA6OTk5OSAgIHwNCj4+IHwgMTkyLjE2OC4wLjEgLyAgIFwgLS0twrQgICAgICAg ICB8ICAgICAgXCAgICAgICAgICB8DQo+PiB8ICAgOjU0MzIxICAgIFxfX18vIDwtLS0uICAgICAg IF98XyAgICAgLyAgcmV3cml0ZSB8DQo+PiB8ICAgICAgICAgICAgICAgfCAgICAgICAgXCAgICAg LyAgIFwgPC3CtCAgICAgICAgICAgfA0KPj4gfCAgICAgICAgICAgICAgIHwgICAgICAgICBgLS0t IFxfX18vIDE5Mi4xNjguMC4xMDAgfA0KPj4gfCAgICAgICAgICAgICAgIHwgICAgcmVzcG9uc2Ug ICAgfCAgICAgICAgIDo1NjgzICAgfA0KPj4gKy0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0tKw0KPj4gICAgICAgIENsaWVudCAgICAgICAgICAgICAgICAg ICAgICAgICAgIFNlcnZlcg0KDQpOaWNlIGRpYWdyYW0uDQoNCj4gTm90IHN1cmUgd2h5IHlvdSB3 b3VsZCBhbHNvIHdhbnQgdG8gcmV3cml0ZSB0aGUgdHJhbnNwb3J0IGVuZHBvaW50Pw0KDQpJIHRy aWVkIHRvIGZvbGxvdyB0aGUgZGlzY3Vzc2lvbi4NClRoZSBpZGVhIHRvIGNoYW5nZSB0aGUgcG9y dCBhcyB3ZWxsIGVuYWJsZXMgamF2YSAoYW5kIEkgZ3Vlc3Mgc29tZSBtb3JlKQ0KdG8gZGlmZmVy ZW50aWF0ZSBiZXR3ZWVuIG11bHRpY2FzdCBhbmQgdW5pY2FzdCByZXF1ZXN0cy4gSmltIGFsc28N Cm1lbnRpb25lZCwgdGhhdCBpdCBlbmFibGVzIHRoZSB1c2Ugb2YgbXVsdGlwbGUgc2VydmVycyBv biB0aGUgc2FtZSBob3N0Lg0KSSBoYXZlIG5vdCBlbm91Z2ggZXhwZXJpZW5jZSB3aXRoIG11bHRp Y2FzdCBpbiBkaWZmZXJlbnQgZW52aXJvbm1lbnRzIHRvDQpzZWUsIGlmIHRoYXQgbWF5IGNhdXNl IG1vcmUgdHJvdWJsZSAoZS5nLiBmaXJld2FsbCBldGMuKS4gSSB3b3VsZCBndWVzcywNCnRoYXQg c29tZSAgaW1wbGVtZW50YXRpb25zIHdpbGwganVzdCBvZmZlciB0aGF0IHZhcmlhbnQsIGF0IGxl YXN0IGFzDQpjb25maWd1cmFibGUgb3B0aW9uIChJIHdvdWxkIHRyeSBkbyBzbyBmb3IgQ2FsaWZv cm5pdW0pLg0KU28gbXkgZmF2b3JpdGUgZm9yIG5vdyBpcyBqdXN0IGltcGxlbWVudCBpdCBhbmQg c2VlLCB3aGF0IHRoZSB1c2VyJ3MNCmZlZWRiYWNrIHdpbGwgYmUuDQoNCklmIHRoYXQgaWRlYSBn ZXRzIGRlY2xpbmVkIChtYXkgYmUgYnkgbmVnYXRpdmUgZmVlZGJhY2sgb2YgdXNlcnMpLCBJDQpz dGlsbCB0aGluaywgdGhhdCB0aGVyZSBpcyBhIGRlbWFuZCBmb3Igb3RoZXIgbWVhbnMgdG8gZGlz dGluZ3Vpc2gNCmJldHdlZW4gbXVsdGljYXN0IGFuZCB1bmljYXN0IHJlcXVlc3RzLiBNYXliZSwg ZWl0aGVyIHRoZSB1c2FnZSBvZiB0aGUNCnVyaS1ob3N0IG9wdGlvbiBvciBhIG5ldyBvcHRpb24g d2lsbCBoZWxwLg0KDQpUaGlzIG1heWJlIGNvbnNpZGVyZWQgYXMgInRvbyBwcmFnbWF0aWNhbGx5 IiwgYnV0IG9uIHRoZSBvdGhlciBzaWRlIEkNCmFsc28gZG9uJ3Qgc2VlIHRoZSAiZ3JlYXQgYmVu ZWZpdCIgaW4gaW5zaXN0IG5vdCB0byBjaGFuZ2UgdGhlIHBvcnQuDQoNCmJlc3QgcmVnYXJkcw0K QWNoaW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== From nobody Thu Apr 2 03:19:53 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76653A0F31 for ; Thu, 2 Apr 2020 03:19:50 -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, FREEMAIL_FROM=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 wqWkDPs_-AWU for ; Thu, 2 Apr 2020 03:19:49 -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 641823A0F2E for ; Thu, 2 Apr 2020 03:19:49 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id o3so3066044ioh.2 for ; Thu, 02 Apr 2020 03:19:49 -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=AQvS/8EkJ7qyLSOPYUjBjunS6HhhZMbNLVLnMOTua+Q=; b=cNKTIQQyAxs5gJOxcAE4dG80UsGYUtIIUcBtxJxes49GXbmjaO3OPccY8ZoH1HJcQJ pV/C409sX8IuWNH7yDJ21AlfdMpktMOArDW9L9p+XVUnrquHWcSU/f8mclxQlFROVNsZ dALKrY6lYwEl1alh5mcmeT2Cvhpth8x1+5k/UWTuYuehpej4T9p59rIml15RyelF5mET BTtI3dwtYaQGDJvKRljCsc3ya6Fl4KJcFKex5l+CAc6NcLCC0n+yxlRQm0QrkE1xjKdg oWpnONBaqt/Gh7nb1mXBD6HFs1oT9eGUL4FsYEfd31ZLIeyiE0ZEkMp9EZ5b3gjCal+r 0Zaw== 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=AQvS/8EkJ7qyLSOPYUjBjunS6HhhZMbNLVLnMOTua+Q=; b=t0ZqUEVDjpICaVw1K70QfSWIsxfcbw6tPWjg6a9C04pau1GzXVUA7tqXPstnZfgDsS eFiMDqZGdHkFqWvtsb95a4YE9IyMakAKxUW9raeljGCaBcCqGktfhtHCarsVg5Pi3tBi aDzKw9f2pQxiRCwXcm02RNWT0/no3NMAv0MpG4i2mdjd0XKY9P0T2GpQmPLVK9iQmh/z rP5Hv/UXq8X8mKC/CsNKnidNbYG+2BU6athqlAnXoLduq6AFBdJ26TxapjKOaCo29PjG nYv3BF/rXXtyDoi1tzNw/JITpwa1A6NS6QHpksldDloLbUdxXu1TTflSleFjQ8hKlYa2 vhSA== X-Gm-Message-State: AGi0PuYPxpuT0Ud+BA8rbO6gxxttyBVuvwyTyhgM3sMkWpNhj0tK3V83 9MIn57aOEOdz/pAAg40aAn9ooMv8Lt6mR0wGVY5sMef2evA= X-Google-Smtp-Source: APiQypLAs/KNoZvJUFYhb37geDi1wyeifGCWsH0t/nFMUuXxFn8eF9yUshi1AGGfr63zdmKHMPX9ZxD3EiyGsUqHGqY= X-Received: by 2002:a6b:8fd7:: with SMTP id r206mr2087529iod.109.1585822788584; Thu, 02 Apr 2020 03:19:48 -0700 (PDT) MIME-Version: 1.0 References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> In-Reply-To: From: Thomas Fossati Date: Thu, 2 Apr 2020 11:19:37 +0100 Message-ID: To: Esko Dijk Cc: Jim Schaad , Klaus Hartke , "core@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top 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, 02 Apr 2020 10:19:51 -0000 On Wed, Apr 1, 2020 at 9:19 AM Esko Dijk wrote: > Because (to me) this is not fully compatible with the definitions of > "endpoint" and messaging model in RFC 7252 that I quoted, it would be > good to clarify this aspect more in draft-ietf-core-groupcomm-bis i.e. > refine the RFC 7252 endpoint definitions for the multicast case and > clarify the multicast messaging model. +1 Ideally, this new "multicast CoAP endpoint" definition should also include an explanation why source address and port of the unicast response are irrelevant to the successful processing at the client. If we can express that clearly I don't think we need "SHOULD keep the same UDP port": an implementation is left with its own local choice. As a bonus we could also have implementation (in which scenario port translation is a useful technique) as well as operational considerations (Achim's wireshark filtering argument). My two cents, cheers! From nobody Thu Apr 2 03:45:42 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D79E3A0F9C for ; Thu, 2 Apr 2020 03:45:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=HK6qrxTo; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=HK6qrxTo Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OitZnZcHfp4u for ; Thu, 2 Apr 2020 03:45:39 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20073.outbound.protection.outlook.com [40.107.2.73]) (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 8C5643A0F9A for ; Thu, 2 Apr 2020 03:45:38 -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=4oHj+S/1TIa3Ozh/kL5B6cFNLgJS/1EO1mo9ehBeafs=; b=HK6qrxToxC9gZwX0xyGJQ7hDiCGz6sDFV90zchh6aZiasBFULE8vUeUTeszwGrVkX5i6yV+zM6xHxXW65yRH+sYusqoTiQDH37K+AGV3k8Grji7XEFoPRY7EDcXTxcifbvXThuV0aGD73dwC68NnaPwoS19LakcRG3bsdROWg3E= Received: from DBBPR09CA0036.eurprd09.prod.outlook.com (2603:10a6:10:d4::24) by DB6PR0802MB2504.eurprd08.prod.outlook.com (2603:10a6:4:a1::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.19; Thu, 2 Apr 2020 10:45:35 +0000 Received: from DB5EUR03FT030.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:d4:cafe::47) by DBBPR09CA0036.outlook.office365.com (2603:10a6:10:d4::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Thu, 2 Apr 2020 10:45:35 +0000 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=bestguesspass 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 DB5EUR03FT030.mail.protection.outlook.com (10.152.20.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Thu, 2 Apr 2020 10:45:35 +0000 Received: ("Tessian outbound 4b84da486446:v50"); Thu, 02 Apr 2020 10:45:35 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 51df4aaa97243b09 X-CR-MTA-TID: 64aa7808 Received: from 87fb19e76f6e.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 2BB2F757-FFFB-4681-8623-E51F3539BC80.1; Thu, 02 Apr 2020 10:45:30 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 87fb19e76f6e.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 02 Apr 2020 10:45:30 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BEFhblKSvrj/uUWQe2UUsokqxY9K+hd9JoZnPOGrYBv2SjT2mNjzY6BgRCJ7h9y4RVD6/McIrCdUk+NgF29fkLo5ZUt9BETtUWJLNpE0zX8fB1Vcqea+1bmsrmsk8S2FXmszrNdalYZOX+JlGCkLPjeS+IoqIl0UAGbMVCpcyvXiIGpgUroALADCp73ZoSxXkyWs0dkwxh/cPqL1Qiv0lqYG2q9Cd5J+m0aq8L2S95eaRPDNR7azYrYAlQQagF7iPbhXssguZSIDxqsu8hMOHiXmH/Qs6OfG4PLxacmVU9K2vcRntVxuDs+nH0Oj2wzfczdiOM7RCGxzYFSvfeFupw== 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=4oHj+S/1TIa3Ozh/kL5B6cFNLgJS/1EO1mo9ehBeafs=; b=IC8RLMyFg0/+HjIXwRTgpRMDcjI1zOBdgoUnKhqWCom/BOVzOP1EU5itdEfuJjySKE+HsjxaeVyAbsRH3T/dkSajkmzsSAQlEpj7LI1M8gIeURCZ+hJgwP0Jb9MNp3jagl72l+vwP/HoTZPwVqk5Wda4WgnF/qFLWXFXy0vs1XleUIsmXdyQTMSl7HebiiKZCgvxQ4yfzqAS6a10r6hroEsyhFpYB1veIzpGfZT5HTVkw7kAzI91Q5ARFXVYM1ayVkhJxmC8KnCI+uEIwjLHKjhuoJagt+5ZC4nNBCGKu8IHb6+mSiUkizdMSfHEhRAaxD1NUoc+cXgyI55QW0VXxg== 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=4oHj+S/1TIa3Ozh/kL5B6cFNLgJS/1EO1mo9ehBeafs=; b=HK6qrxToxC9gZwX0xyGJQ7hDiCGz6sDFV90zchh6aZiasBFULE8vUeUTeszwGrVkX5i6yV+zM6xHxXW65yRH+sYusqoTiQDH37K+AGV3k8Grji7XEFoPRY7EDcXTxcifbvXThuV0aGD73dwC68NnaPwoS19LakcRG3bsdROWg3E= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (20.179.18.151) by AM6PR08MB4785.eurprd08.prod.outlook.com (10.255.22.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Thu, 2 Apr 2020 10:45:28 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f%7]) with mapi id 15.20.2856.019; Thu, 2 Apr 2020 10:45:28 +0000 From: Thomas Fossati To: Abhijan Bhattacharyya CC: core , Thomas Fossati Thread-Topic: [core] Using CoAP for P2P Thread-Index: AQHWCBkKd/ADH0oe/0iISsi9X2hLJ6hkO1AAgAE+9oCAAD3vgA== Date: Thu, 2 Apr 2020 10:45:27 +0000 Message-ID: <32B768C0-BE02-4597-96DD-2835312DAF8B@arm.com> 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.35.20030802 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 74f5281c-3da9-461f-f60f-08d7d6f2f9c6 x-ms-traffictypediagnostic: AM6PR08MB4785:|AM6PR08MB4785:|DB6PR0802MB2504: 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-forefront-prvs: 0361212EA8 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(396003)(136003)(39860400002)(376002)(346002)(2616005)(81156014)(6916009)(4326008)(5660300002)(66476007)(64756008)(66946007)(36756003)(6486002)(6512007)(86362001)(33656002)(66446008)(91956017)(76116006)(66556008)(54906003)(26005)(316002)(81166006)(8936002)(8676002)(2906002)(478600001)(186003)(6506007)(53546011)(71200400001); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: ddA91CsHAXcR4s7Xy4KDPhEQR73JqqfFlzZEZhjXnLVqSUBw7saU9DjYWpJ/c/fBDAtNjK8jJaDIlmjPACr+/9wE9XbhZMU3zb05eXgyimS+zpatQOCtFBawBqcPXwyurhrEagkxo/7D/skrH/v2IuAcXg2jKU+gQqRHK3Igp6TrJh2IQQ3V3+BBpVkom4MJqoi60Qi2HSBJlb2ufNlg4xbgBuBQSZJ6AhEIRNkpASRCBZbekM92gf3SDlk0RgxGU16qjEVx0p826K9Qh0H3gkQDaYViqZ4KCX6xuiONx+zaBTRM7Q/ZeJr0XuL/BjOC6oUj3RyVZwYlOPRfyCpMiJom819Hm2iJeiecJNcCBEEWpZHY7/A+ZWirG02PoAjAY41UFDlTWpdfAh85BaLftXqaNt0iFe2IGbMdwTmaMNX57Dj4df8KUn0OiWu47aWA x-ms-exchange-antispam-messagedata: bj2W4Xcp9CDfc5m/OuXbWPFQOo7y8geUeiWTc7kAf1aeNUsTVg4Xh4Mdid0/kGIkd/KckCnZ+vA2Pjyan1JcpzVgQ8pwDvBxmrwiLLOBG7u6WfbWDu3q3bJiq0Gqh+YyD5GMDvVJNgUNTQN0Pt5rbA== Content-Type: text/plain; charset="utf-8" Content-ID: <099E1C3AFFDDB945A2F083E4E14FA7C8@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4785 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT030.eop-EUR03.prod.protection.outlook.com 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; SFTY:; SFS:(10009020)(4636009)(39860400002)(346002)(396003)(136003)(376002)(46966005)(86362001)(6862004)(316002)(81166006)(70586007)(8676002)(8936002)(54906003)(70206006)(4326008)(26826003)(478600001)(81156014)(5660300002)(82740400003)(53546011)(36756003)(2616005)(336012)(6512007)(6486002)(356004)(47076004)(6506007)(26005)(33656002)(2906002)(186003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: ba2d80bf-f3ff-4957-395e-08d7d6f2f534 X-Forefront-PRVS: 0361212EA8 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ImJlntujlbaDEPlnBUqpFKbhhqViZSr8gAcfGe30neBvX1t0TUzYOw22scc3nKSzqQ7OPktbRHS3ZiIZhv0Gwy+oOg79qfqI98eYLXCZNaA4bij7jIOIt6+rAHW/j0s2MLvOnEAPv93vWUobW99XFwVcJlvuVqi2ZxtEN+byoU/vJXqgXT6IQL9Ug9wuUtal4FPMV1tJeHATvotIDpYaUMS2920WZ14221uIJV2ankJeRJG8HrINKzLWmVRw06al7xeP3Pl9uicR9wQz6QpjehEbBwQvULrTfSPE+hOYv1xy4wbsF9wWf874wk3QlwDqEmCKub9Ab3bBIE6DEDuRJM/E0Sb3BG7fPtX/2iDM2YZt9xisNU3fb3QH7PyQMBWMPCCq0QBONkbYP8Jgy6Z29fFG7s7gsRYShyT/EuAzmCmoYTJunu/OHsDq72J374vHAL0WD+GlnkCZgxtPiBuI+jl1rTT5GJ+tJYoQ3OMY2Wgdv5F0xD7AwSVi96/7V1SiGGNDowuR6HYJNNU5fPjdgw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Apr 2020 10:45:35.7130 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 74f5281c-3da9-461f-f60f-08d7d6f2f9c6 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-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2504 Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 02 Apr 2020 10:45:41 -0000 DQpIaSBBYmhpamFuLA0KDQpPbiAwMi8wNC8yMDIwLCAwOTowNCwgIkFiaGlqYW4gQmhhdHRhY2hh cnl5YSINCjxhYmhpamFuLmJoYXR0YWNoYXJ5eWFAZ21haWwuY29tPiB3cm90ZToNCj4gV2hhdCBJ IGFtIGxvb2tpbmcgYXQgaXMgYSBzaXR1YXRpb24gd2hlcmUgSSBoYXZlIHR3byBub2RlcyBlYWNo IGhhdmluZw0KPiBhIHRpbWUtdmFyeWluZyByZXNvdXJjZS4gQm90aCB3YW50IHRvIHB1c2ggdGhl IHN0YXRlcyBvZiB0aGUNCj4gcmVzcGVjdGl2ZSByZXNvdXJjZSB0byB0aGUgb3RoZXIgbm9kZSB3 aXRoaW4gYSBjb21tb24gYXBwbGljYXRpb24NCj4gY29udGV4dC4gSG93ZXZlciwgdGhlc2UgZXhj aGFuZ2VzIGFyZSBuYXR1cmFsbHkgYXN5bmNocm9ub3VzLiAgTWF5IGJlDQo+IEkgY2FuIHRoaW5r IG9mIGl0IG1vcmUgbGlrZSBhIGNoYXQuIEEgdHlwaWNhbCBjbGllbnQtc2VydmVyIG9yIG9ic2Vy dmUNCj4gcmVsYXRpb25zaGlwIHdpbGwgbm90IHNlcnZlIHRoZSBwdXJwb3NlLiBBY3R1YWxseSBi b3RoIHNob3VsZCBoYXZlIGENCj4gY2xpZW50IGFuZCBzZXJ2ZXIgaW5zdGFuY2UgcnVubmluZyB1 bmRlciBhIGNvbW1vbiBhcHBsaWNhdGlvbi4gVGhlbg0KPiBlaXRoZXIgZWFjaCBjYW4gKm9ic2Vy dmUqIHRoZSBvdGhlciwgb3IgY2FuICpwb3N0KiB0aGUgb3RoZXIuIFRoYXQgaXMNCj4gaG93IHdl IGNhbiBkbyB0aGF0IHdpdGhvdXQgYSBjZW50cmFsIHNlcnZlci4NCg0KV2hhdCB5b3UgZGVzY3Jp YmUgYWJvdmUgaXMgYSBwZXJmZWN0bHkgcmVhc29uYWJsZSBpbXBsZW1lbnRhdGlvbjogZWFjaA0K bm9kZSBoYXMgYm90aCBjbGllbnQgYW5kIHNlcnZlciBlbmRwb2ludHMgd2hlcmUgdGhlIGZvcm1l ciBvYnNlcnZlIHRoZQ0KbGF0dGVyIG9uIHRoZSBwZWVyLiAgVG8gc2hhcmUgc3RhdGUgYWNyb3Nz IGNvLWxvY2F0ZWQgZW5kcG9pbnRzIG9uZSBjYW4NCnVzZSBhbiBJUEMgb2YgY2hvaWNlIGluY2x1 ZGluZyBzaGFyZWQgbWVtb3J5IGJldHdlZW4gdGhyZWFkcy4NCg0KPiBJZiBteSB1bmRlcnN0YW5k aW5nIGlzIHJpZ2h0LCBhY2NvcmRpbmcgdG8gQ29BUCBzcGVjaWZpY2F0aW9uLCB0aGUNCj4gbm9k ZXMgd2hpY2ggY2FuIGhhdmUgYm90aCBzZXJ2ZXIgYW5kIGNsaWVudCAodG8gdGhlIG9yaWdpbiBz ZXJ2ZXIpIGFyZQ0KPiAiaW50ZXJtZWRpYXJ5IiBub2Rlcy4gVGhlIG9ubHkgZXhhbXBsZSBvZiAi aW50ZXJtZWRpYXJ5IiBjb25zaWRlcmVkIGluDQo+IHRoZSBzcGVjIGlzIHRoZSBwcm94eSBub2Rl LiBCdXQsIGFueXdheSB0aGUgc2l0dWF0aW9uIGluIHRoaXMgY2FzZQ0KPiBkb2VzIG5vdCBjb25j ZXJuIHdpdGggaW50ZXJtZWRpYXJ5LiBCb3RoIGFyZSBvcmlnaW4gc2VydmVyIGFuZA0KPiBlbmQt Y2xpZW50IHRvZ2V0aGVyLg0KDQo3MjUyIHNheXMgdGhhdCBhbiBpbnRlcm1lZGlhcnkgaGFzIGJv dGggY2xpZW50IGFuZCBzZXJ2ZXIgZW5kcG9pbnRzLCBub3QNCnRoYXQgYW55IG5vZGUgd2l0aCBi b3RoIGNsaWVudCBhbmQgc2VydmVyIGVuZHBvaW50cyBpcyBhbiBpbnRlcm1lZGlhcnkuDQoNCj4g SXMgdGhlcmUgYW55IHN0YW5kYXJkaXplZCBtZWNoYW5pc20gdG8gaGFuZGxlIHRoaXMgc2l0dWF0 aW9uPw0KDQpUaGUgZGVzaWduIHlvdSd2ZSBkZXNjcmliZWQgYWJvdmUgaXMgYSBzdGFuZGFyZGlz ZWQgKGFuZCBsb2dpY2FsKSB3YXkgdG8NCmhhbmRsZSB5b3VyIGNhc2UuDQoNCmNoZWVycywgdA0K LS0NCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2Vk LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8g YW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29w eSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Thu Apr 2 09:01:42 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107A73A16E4 for ; Thu, 2 Apr 2020 09:01:41 -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 auzqa62WjYlP for ; Thu, 2 Apr 2020 09:01:39 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA023A16E2 for ; Thu, 2 Apr 2020 09:01:38 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 2 Apr 2020 09:01:31 -0700 From: Jim Schaad To: 'Esko Dijk' , 'Achim Kraus' , 'Thomas Fossati' , 'Klaus Hartke' CC: References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> <02ec5628-3f7d-ff5d-620c-c0a90a4b89b0@gmx.net> In-Reply-To: Date: Thu, 2 Apr 2020 09:01:30 -0700 Message-ID: <020701d60907$fb3ba720$f1b2f560$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIXVeiVC1e4HIxpxUNqDgp/ppWwxwLeBdy3AlRjDEICXv5oEAIsRnhBAgGYZE4CNTatAQF2e0MvAkUv4JkCiP5R4AEu4xDAAWkjoBWnLNcFQA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top 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, 02 Apr 2020 16:01:41 -0000 Esko, That idea strikes me as a very bad idea. If you build your code on = this basis you will fall over the first time you come across a multicast = channel which uses the same port as the unicast server. The IP address = is different for a multicast vs a unicast message received at the = server. This needs to be the distinction as well as the fact that some = resources may only want to be on a single multicast address even if the = server is listening on multiple unicast addresses. Jim -----Original Message----- From: core On Behalf Of Esko Dijk Sent: Thursday, April 2, 2020 1:23 AM To: Achim Kraus ; Thomas Fossati = ; Klaus Hartke Cc: core@ietf.org Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response = Layer, page 67, top Hello Achim, (see also my response to Jim) Using the UDP port number to detect a multicast request vs a unicast = request sounds like a good use case. Just curious - I assume the = security aspect requirements of RFC 7252 are taken care of in this use = case? That is, a proper client sends its multicast requests always to port = :9999 and the server treats these as multicast requests (e.g. only allow = the request for specific resources). A malicious client may sends its multicast request to port :5683 to = bypass the above checks. I assume the server doesn't respond to this = request, because the multicast address is not bound to port 5683 but to = say 9999 only. If the CoAP server at port 5683 cannot distinguish between = unicast/multicast that would be a bad situation and the security = requirements of RFC 7252 are not met. Esko -----Original Message----- From: core On Behalf Of Achim Kraus Sent: Wednesday, April 1, 2020 22:28 To: Thomas Fossati ; Klaus Hartke = Cc: core@ietf.org Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response = Layer, page 67, top Hi, >> +---------------+ +-----------------+ >> | | request _|_ | >> | | .---> / \ 224.0.1.187 | >> | _|_ / \___/ --. :9999 | >> | 192.168.0.1 / \ ---=C2=B4 | \ | >> | :54321 \___/ <---. _|_ / rewrite | >> | | \ / \ <-=C2=B4 | >> | | `--- \___/ 192.168.0.100 | >> | | response | :5683 | >> +---------------+ +-----------------+ >> Client Server Nice diagram. > Not sure why you would also want to rewrite the transport endpoint? I tried to follow the discussion. The idea to change the port as well enables java (and I guess some more) = to differentiate between multicast and unicast requests. Jim also = mentioned, that it enables the use of multiple servers on the same host. I have not enough experience with multicast in different environments to = see, if that may cause more trouble (e.g. firewall etc.). I would guess, = that some implementations will just offer that variant, at least as = configurable option (I would try do so for Californium). So my favorite for now is just implement it and see, what the user's = feedback will be. If that idea gets declined (may be by negative feedback of users), I = still think, that there is a demand for other means to distinguish = between multicast and unicast requests. Maybe, either the usage of the = uri-host option or a new option will help. This maybe considered as "too pragmatically", but on the other side I = also don't see the "great benefit" in insist not to change the port. best regards Achim _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Apr 2 11:00:50 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348F13A0FCD for ; Thu, 2 Apr 2020 11:00: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 AdsRNlsIxeoy for ; Thu, 2 Apr 2020 11:00:41 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034AA3A0FC3 for ; Thu, 2 Apr 2020 11:00:40 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 2 Apr 2020 11:00:31 -0700 From: Jim Schaad To: Date: Thu, 2 Apr 2020 11:00:29 -0700 Message-ID: <022401d60918$9a2d3f50$ce87bdf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdYIWnsiWRxZxUYsSFC1zgO0qK7v8A== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Questions dealing with Blockwise Transfer 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, 02 Apr 2020 18:00:49 -0000 I am running into a couple of issues when getting my OSCORE secure blockwise transfer debugged. I accidentally introduced an error in my OSCORE decryption code and that caused my blockwise code to fall over. 1. Based on the below text, I am not sure if this is saying that only success status codes are permitted to use blockwise or if you can use this for error status codes as well. This question comes about partly due to the draft https://www.ietf.org/id/draft-fossati-core-coap-problem-02.html which might return some "large" size error resources. Hence, for the methods defined in [RFC7252], Block1 is useful with the payload-bearing POST and PUT requests and their responses. Block2 is useful with GET, POST, and PUT requests and their payload- bearing responses (2.01, 2.02, 2.04, and 2.05 -- see Section 5.5 of [RFC7252]). 2. The document does not explicitly give any way for a server to stop a block transfer half way through. While it would make sense to an error status is returned, I do not know if the block option is also supposed to be returned or not. Note that this would not necessarily interact well with the idea of doing a blockwise return for an error status content. Jim From nobody Thu Apr 2 11:41:40 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF26E3A0141 for ; Thu, 2 Apr 2020 11:41:38 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 eJca5DvykVa1 for ; Thu, 2 Apr 2020 11:41:35 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70083.outbound.protection.outlook.com [40.107.7.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE583A003B for ; Thu, 2 Apr 2020 11:41:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BYRwurQGU1T3p/3GT0yEToF21Hy4M9UFm4Oyu/Ah/6jK+VkDGjscm2J9KadXgDttH+R0xPqVZnKpkVQLdicJ28p4XPl5l6y235cFojRbb/SAKwpb49dH14xWQHF0qEt86Ft6M7XWcubmlCaCXbt5UsfTfjuNzl/i2bpVOOWI8lJRJmmBI78oLl3BVmYQBIJn2yDMJJvu+JlxHoFnUBnJB7Uonvl212hCiuOZ6WTBf7nj2LexWJjDXRL1pIZKDz3t7MTr4fSJWzCPyZnLT/7q4V+54au376cPKkU/8apiu3sX0tvJz6jaCgroJDzL0ESXaMKxuQSF3LBLqbqZjAMfJw== 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=jvWbcEsIHfuGSj9zz65zRMb6RnRs1Kb7Fr/g2feipqQ=; b=akRchHOEU5q4DOGZs4Exbmg1uOQV6EafvId/vGeU5tixXEu4UEyJl40EAvvQ76mTTFZu4/DhloJx2wACmR2TPJNl6BXJ8MnUCcJ5PriMCzHhIwXoPIcdGM7Nvp5o0eP2REI354+Tai3A/MEKyLxQ+NKHIZpKQIJOdDegsyyChkVL7ye5CmapO5r2dgobgQ+D+5f3j7831lZg3CVHLYxDu3DxtKPW0h+hoHF4y6N7UcwSWc8jeRl019DGwLKWyzxx09SgNTEuLFFfsOzHZZmdLJFhxJqVtlMhFoFhbAiB1sf3puT4cARJFQeXWfhvwSHeVCDP1EJXv+jYX3d5Oe6s/g== 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=jvWbcEsIHfuGSj9zz65zRMb6RnRs1Kb7Fr/g2feipqQ=; b=F/WrAuXKYzADElyCkFe9Anlg2JZNeeIZMC3SMl4Ut1tzUQP/34+bncSCONRR/uiFl9IGCRwnGAhmdBtqyRvOSlfBVec3YwrKzKY6CJiyqLzv30mQqBsiyvMFX927+89YxliULENPC70dNxCisqtgGhVUEcBZd0jsLYg9FRnnQ9Q= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (52.134.82.159) by AM0PR07MB4148.eurprd07.prod.outlook.com (52.133.59.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.14; Thu, 2 Apr 2020 18:41:32 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512%7]) with mapi id 15.20.2878.014; Thu, 2 Apr 2020 18:41:32 +0000 From: Christer Holmberg To: Abhijan Bhattacharyya , Thomas Fossati CC: core Thread-Topic: [core] Using CoAP for P2P Thread-Index: AQHWCMVROB2ppf3kDkGCzoMwIoGd3KhmXWeA Date: Thu, 2 Apr 2020 18:41:32 +0000 Message-ID: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 055ab732-89cd-4738-9fc3-08d7d7357707 x-ms-traffictypediagnostic: AM0PR07MB4148: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(39860400002)(346002)(376002)(366004)(136003)(66476007)(2906002)(966005)(316002)(6506007)(33656002)(6486002)(53546011)(478600001)(36756003)(4326008)(8676002)(8936002)(110136005)(81156014)(81166006)(2616005)(86362001)(71200400001)(44832011)(26005)(66946007)(64756008)(66446008)(66574012)(5660300002)(66556008)(6512007)(76116006)(186003); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GaqY17p4uj/SfIfgrXMdLYoggwY/1KiGVk9aEsRpCTWdan5N1+g+xw0ytsJu4SfJIYNFju0FpcsV1vmM5Zhue3zIhrY6kbLOBJiXohDKuN+tttVnMzhXRrxhCzsZvePXA9zDtC8cgku8HfnLeColq3wuUinjz4iDinVustJquFG6hKloDYdQuB8DSZ93FK4gRey47/XOSOmhMruYNO/1TeGN/kCEQJBC1b+XBQlcfogvNnuSiJL09iVxJWQBpGEJoocZoHyzVRF0ya1s6P9OdQMl/mYvYc807vqZL8bAqPSwH0VxsUzGVFydrLJyTa4n349LxaFZ4h8prmq+/Gd/OlIhKB7cXc3GzbAAvQ7qzbrffaKWTxOykx8JmRUFUgNO8rX2098//epLSfgyb1xHL7i/POGxq16jSoE0z4dFJ8PFJMJfFYVc4dLB775ZSFLUvx6qqY19Yob8mUiGa9SpZi8EIXscelZoQ9Q5wABNwQm93uRLhBzL3+M5euPVSqTL4syQRM3tiy/NBIAJ3DMZyw== x-ms-exchange-antispam-messagedata: tiDKzHVReNHdeaOn0+XMqLpIO12EknciYWTEnAih2a5S+9W8TPQ5sgSM5BE0YGkAiPVUBsNcLpis8CJIBhnXP8nJT19Uf2/b9LvM3HRrwetnVE5hZoC5F5NtEs6LpoE0j5mByORB7G5xxnQfG/mAiA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_7B20E77FCFF44735A0C299121CD352D3ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 055ab732-89cd-4738-9fc3-08d7d7357707 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2020 18:41:32.5881 (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: zQ4qYV9W1m00EtzlU2h+MdeHstO04vRPdmSS9kXBF5cD/YCHWnXaqpV8nupw5B8FTNkGK+vQhi59Fuw04+Jto9PUgFtds9yg4IBHElPAe94= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4148 Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 02 Apr 2020 18:41:39 -0000 --_000_7B20E77FCFF44735A0C299121CD352D3ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCklmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBQMlAsIHlvdSBtaWdodCBiZSBpbnRlcmVz dGVkIGluIHRoZSB0aGluLUlDRSBwcmVzZW50YXRpb24gdGhhdCB3YXMgZ2l2ZW4gYXQgdGhlIFQy VFJHIG1lZXRpbmcgaW4gU2luZ2Fwb3JlOg0KDQpodHRwczovL2dpdGh1Yi5jb20vdDJ0cmcvMjAx OS0xMS1zaW5nYXBvcmUvYmxvYi9tYXN0ZXIvc2xpZGVzLzQ0LXRoaW4tSUNFLTE1MTExOS1TaW5n YXBvcmUucGRmDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTogY29yZSA8Y29yZS1i b3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQWJoaWphbiBCaGF0dGFjaGFyeXlhIDxhYmhp amFuLmJoYXR0YWNoYXJ5eWFAZ21haWwuY29tPg0KRGF0ZTogVGh1cnNkYXksIDIgQXByaWwgMjAy MCBhdCAxMS4wNA0KVG86IFRob21hcyBGb3NzYXRpIDxUaG9tYXMuRm9zc2F0aUBhcm0uY29tPg0K Q2M6IGNvcmUgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIFVzaW5nIENvQVAg Zm9yIFAyUA0KDQpIaSBUaG9tYXMsDQpXaGF0IEkgYW0gbG9va2luZyBhdCBpcyBhIHNpdHVhdGlv biB3aGVyZSBJIGhhdmUgdHdvIG5vZGVzIGVhY2ggaGF2aW5nIGEgdGltZS12YXJ5aW5nIHJlc291 cmNlLiBCb3RoIHdhbnQgdG8gcHVzaCB0aGUgc3RhdGVzIG9mIHRoZSByZXNwZWN0aXZlIHJlc291 cmNlIHRvIHRoZSBvdGhlciBub2RlIHdpdGhpbiBhIGNvbW1vbiBhcHBsaWNhdGlvbiBjb250ZXh0 LiBIb3dldmVyLCB0aGVzZSBleGNoYW5nZXMgYXJlIG5hdHVyYWxseSBhc3luY2hyb25vdXMuIE1h eSBiZSBJIGNhbiB0aGluayBvZiBpdCBtb3JlIGxpa2UgYSBjaGF0LiBBIHR5cGljYWwgY2xpZW50 LXNlcnZlciBvciBvYnNlcnZlIHJlbGF0aW9uc2hpcCB3aWxsIG5vdCBzZXJ2ZSB0aGUgcHVycG9z ZS4gQWN0dWFsbHkgYm90aCBzaG91bGQgaGF2ZSBhIGNsaWVudCBhbmQgc2VydmVyIGluc3RhbmNl IHJ1bm5pbmcgdW5kZXIgYSBjb21tb24gYXBwbGljYXRpb24uIFRoZW4gZWl0aGVyIGVhY2ggY2Fu ICpvYnNlcnZlKiB0aGUgb3RoZXIsIG9yIGNhbiAqcG9zdCogdGhlIG90aGVyLiBUaGF0IGlzIGhv dyB3ZSBjYW4gZG8gdGhhdCB3aXRob3V0IGEgY2VudHJhbCBzZXJ2ZXIuDQoNCklmIG15IHVuZGVy c3RhbmRpbmcgaXMgcmlnaHQsIGFjY29yZGluZyB0byBDb0FQIHNwZWNpZmljYXRpb24sIHRoZSBu b2RlcyB3aGljaCBjYW4gaGF2ZSBib3RoIHNlcnZlciBhbmQgY2xpZW50ICh0byB0aGUgb3JpZ2lu IHNlcnZlcikgYXJlICJpbnRlcm1lZGlhcnkiIG5vZGVzLiBUaGUgb25seSBleGFtcGxlIG9mICJp bnRlcm1lZGlhcnkiIGNvbnNpZGVyZWQgaW4gdGhlIHNwZWMgaXMgdGhlIHByb3h5IG5vZGUuIEJ1 dCwgYW55d2F5IHRoZSBzaXR1YXRpb24gaW4gdGhpcyBjYXNlIGRvZXMgbm90IGNvbmNlcm4gd2l0 aCBpbnRlcm1lZGlhcnkuIEJvdGggYXJlIG9yaWdpbiBzZXJ2ZXIgYW5kIGVuZC1jbGllbnQgdG9n ZXRoZXIuDQoNCklzIHRoZXJlIGFueSBzdGFuZGFyZGl6ZWQgbWVjaGFuaXNtIHRvIGhhbmRsZSB0 aGlzIHNpdHVhdGlvbj8NCg0KVGhhbmtzLg0KDQpPbiBXZWQsIEFwciAxLCAyMDIwIGF0IDU6MzIg UE0gVGhvbWFzIEZvc3NhdGkgPFRob21hcy5Gb3NzYXRpQGFybS5jb208bWFpbHRvOlRob21hcy5G b3NzYXRpQGFybS5jb20+PiB3cm90ZToNCkhpIEFiaGlqYW4sDQoNCk9uIDAxLzA0LzIwMjAsIDEy OjMxLCBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgPGFiaGlqYW4uYmhhdHRhY2hhcnl5YUBnbWFpbC5j b208bWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUBnbWFpbC5jb20+PiB3cm90ZToNCj4gSXMg dGhlcmUgYW55IHN0YW5kYXJkaXplZCBtZWNoYW5pc20gdG8gdXNlIENvQVAgZm9yIGEgUDJQIGNv bm5lY3Rpb24/DQoNCk5vdCBzdXJlIHdoZXRoZXIgUkZDIDc2NTAgd291bGQgZml0IHlvdXIgbmVl ZHMgYnV0IHdvcnRoIGhhdmluZyBhDQpsb29rIC0tIGlmIHlvdSBoYXZlbid0IGFscmVhZHkuDQoN CmNoZWVycw0KLS0NCg0KDQoNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0 aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwg b3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91 Lg0KDQoNCi0tDQpSZWdhcmRzLA0KQWJoaWphbiBCaGF0dGFjaGFyeXlhLA0KVGVjaG5vbG9naXN0 IGJ5IHByb2Zlc3Npb24gW0lvVHwgSW50ZXJuZXQgUHJvdG9jb2xzfCA1R10NCg== --_000_7B20E77FCFF44735A0C299121CD352D3ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <13BAE43C873DF64189D2966D3E76ABB5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcmlhbCBC bGFjayI7DQoJcGFub3NlLTE6MiAxMSAxMCA0IDIgMSAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRkkiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JZiB5b3UgYXJlIGludGVy ZXN0ZWQgaW4gUDJQLCB5b3UgbWlnaHQgYmUgaW50ZXJlc3RlZCBpbiB0aGUgdGhpbi1JQ0UgcHJl c2VudGF0aW9uIHRoYXQgd2FzIGdpdmVuIGF0IHRoZSBUMlRSRyBtZWV0aW5nIGluIFNpbmdhcG9y ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2dp dGh1Yi5jb20vdDJ0cmcvMjAxOS0xMS1zaW5nYXBvcmUvYmxvYi9tYXN0ZXIvc2xpZGVzLzQ0LXRo aW4tSUNFLTE1MTExOS1TaW5nYXBvcmUucGRmIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly9n aXRodWIuY29tL3QydHJnLzIwMTktMTEtc2luZ2Fwb3JlL2Jsb2IvbWFzdGVyL3NsaWRlcy80NC10 aGluLUlDRS0xNTExMTktU2luZ2Fwb3JlLnBkZjwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+Y29yZSAmbHQ7Y29yZS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhh bGYgb2YgQWJoaWphbiBCaGF0dGFjaGFyeXlhICZsdDthYmhpamFuLmJoYXR0YWNoYXJ5eWFAZ21h aWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgMiBBcHJpbCAyMDIwIGF0IDEx LjA0PGJyPg0KPGI+VG86IDwvYj5UaG9tYXMgRm9zc2F0aSAmbHQ7VGhvbWFzLkZvc3NhdGlAYXJt LmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPmNvcmUgJmx0O2NvcmVAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+U3ViamVjdDogPC9iPlJlOiBbY29yZV0gVXNpbmcgQ29BUCBmb3IgUDJQPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIFRob21hcywgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2hhdCBJIGFtIGxvb2tpbmcgYXQgaXMgYSBzaXR1YXRpb24gd2hlcmUgSSBoYXZlIHR3 byBub2RlcyBlYWNoIGhhdmluZyBhIHRpbWUtdmFyeWluZyByZXNvdXJjZS4gQm90aCB3YW50Jm5i c3A7dG8gcHVzaCB0aGUgc3RhdGVzIG9mIHRoZSByZXNwZWN0aXZlIHJlc291cmNlIHRvIHRoZSBv dGhlciBub2RlIHdpdGhpbiBhIGNvbW1vbiBhcHBsaWNhdGlvbiBjb250ZXh0LiBIb3dldmVyLCB0 aGVzZSBleGNoYW5nZXMgYXJlDQogbmF0dXJhbGx5IGFzeW5jaHJvbm91cy4gTWF5IGJlIEkgY2Fu IHRoaW5rIG9mIGl0IG1vcmUgbGlrZSBhIGNoYXQuIEEgdHlwaWNhbCBjbGllbnQtc2VydmVyIG9y IG9ic2VydmUgcmVsYXRpb25zaGlwIHdpbGwgbm90IHNlcnZlIHRoZSBwdXJwb3NlLiBBY3R1YWxs eSBib3RoIHNob3VsZCBoYXZlIGEgY2xpZW50IGFuZCBzZXJ2ZXIgaW5zdGFuY2UgcnVubmluZyB1 bmRlciBhIGNvbW1vbiBhcHBsaWNhdGlvbi4gVGhlbiBlaXRoZXIgZWFjaCBjYW4gKm9ic2VydmUq DQogdGhlIG90aGVyLCBvciBjYW4gKnBvc3QqIHRoZSBvdGhlci4gVGhhdCBpcyBob3cgd2UgY2Fu IGRvIHRoYXQgd2l0aG91dCBhIGNlbnRyYWwgc2VydmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBteSB1bmRlcnN0YW5kaW5nIGlzIHJp Z2h0LCBhY2NvcmRpbmcgdG8gQ29BUCBzcGVjaWZpY2F0aW9uLCB0aGUgbm9kZXMgd2hpY2ggY2Fu IGhhdmUgYm90aCBzZXJ2ZXIgYW5kIGNsaWVudCAodG8gdGhlIG9yaWdpbiZuYnNwO3NlcnZlcikg YXJlICZxdW90O2ludGVybWVkaWFyeSZxdW90OyBub2Rlcy4gVGhlIG9ubHkgZXhhbXBsZSBvZiAm cXVvdDtpbnRlcm1lZGlhcnkmcXVvdDsgY29uc2lkZXJlZCBpbiB0aGUgc3BlYyBpcyB0aGUgcHJv eHkgbm9kZS4NCiBCdXQsIGFueXdheSB0aGUgc2l0dWF0aW9uIGluIHRoaXMgY2FzZSBkb2VzIG5v dCBjb25jZXJuIHdpdGggaW50ZXJtZWRpYXJ5LiBCb3RoIGFyZSBvcmlnaW4gc2VydmVyIGFuZCBl bmQtY2xpZW50IHRvZ2V0aGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JcyB0aGVyZSBhbnkgc3RhbmRhcmRpemVkIG1lY2hhbmlzbSB0byBo YW5kbGUgdGhpcyBzaXR1YXRpb24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXByIDEsIDIw MjAgYXQgNTozMiBQTSBUaG9tYXMgRm9zc2F0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRob21hcy5G b3NzYXRpQGFybS5jb20iPlRob21hcy5Gb3NzYXRpQGFybS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp IEFiaGlqYW4sPGJyPg0KPGJyPg0KT24gMDEvMDQvMjAyMCwgMTI6MzEsIEFiaGlqYW4gQmhhdHRh Y2hhcnl5YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5hYmhpamFuLmJoYXR0YWNoYXJ5eWFAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PGJyPg0KJmd0OyBJcyB0aGVyZSBhbnkgc3RhbmRhcmRpemVkIG1lY2hhbmlzbSB0 byB1c2UgQ29BUCBmb3IgYSBQMlAgY29ubmVjdGlvbj88YnI+DQo8YnI+DQpOb3Qgc3VyZSB3aGV0 aGVyIFJGQyA3NjUwIHdvdWxkIGZpdCB5b3VyIG5lZWRzIGJ1dCB3b3J0aCBoYXZpbmcgYTxicj4N Cmxvb2sgLS0gaWYgeW91IGhhdmVuJ3QgYWxyZWFkeS48YnI+DQo8YnI+DQpjaGVlcnM8YnI+DQot LTxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250 ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBh bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3Qg ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55 IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1 bS4gVGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCBCbGFjayZxdW90OyxzYW5z LXNlcmlmIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwgQmxhY2smcXVvdDssc2Fucy1zZXJpZiI+QWJoaWphbiBCaGF0dGFjaGFyeXlhLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwgQmxhY2sm cXVvdDssc2Fucy1zZXJpZiI+VGVjaG5vbG9naXN0IGJ5IHByb2Zlc3Npb24gW0lvVHwgSW50ZXJu ZXQgUHJvdG9jb2xzfCA1R108L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7B20E77FCFF44735A0C299121CD352D3ericssoncom_-- From nobody Thu Apr 2 12:24:02 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555033A0FEA for ; Thu, 2 Apr 2020 12:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=yahoo.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 h1GQHMQd7f3w for ; Thu, 2 Apr 2020 12:23:58 -0700 (PDT) Received: from sonic316-19.consmr.mail.bf2.yahoo.com (sonic316-19.consmr.mail.bf2.yahoo.com [74.6.130.193]) (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 8E6DD3A0FE9 for ; Thu, 2 Apr 2020 12:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1585855436; bh=blGaC12YsyjgVHy3uuT1nV/iaRwa3eZCTNDrKfT164A=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=ObQT/FBFQ4vr4Khzmlny3wG4+aBhE7etvyz6bCmwwcn54BOPsklQ7iSdGYJX7qDcDGybgekfsmVIfbWUNVnvS1RTenbRBnsXKdSrCC2k+/AFtR2Tm7f8Smbnr+EV3G1YCMsK6LaQq03GtQY4tUjVPYOUMderAUAbdUGHBo4+vW+KXveuTVEegd4DLmVn2GrbX2pf2PAMMN6Yz1IkfrAy8Pc33sM2mDnco0AjdaZs0CcyNc6JLd4VID871arKIM0ugL9tePLVGSUBFLCIAbzfDeQmXFof2rJ9uC6U2xP08PF4NB0SuZiPAInn+QFBWByKpAA0ngkE+OUobFNnPKHACw== X-YMail-OSG: YVydqMMVM1kVzthflo244Uy_UEcZYiMDIrjfg5bjvxg6bzQlCU1yo9lDcF.QjdK y0J9rFNtGvoXy48bUhZmgDfeUiBDCebvPfKIFTYAi2zSC.UDs7Z9uR.rya_kVrTPWFmGnqVQor4k C.Yy447ubDpTn31deYIk8tjggzU1rx0vDNz67mNkWi2DpJgi06503X5XFmcTZnugxOzOcyxEmC0J Vw36JWtRtZELCtxE2TyXzzrIh3LGqY88DKCqf1B7copkdJmYwIrgse2d8OscaQbQLimixP9ZrPtn tntWH3cTs6wznxE420VQ_VIKB8c4y7fFAb0WNizeLzeYRutzjF1MZf.VtNrV9AWF7IGF0k6g4gPW tJc1idnIV_RJTJEOtktUuGAXsIN26jh5foFZIljsapUiJ6WMBLecOBf1l8tj0CAFFTPCn82YRn2F 98BdOxtWj1c3ofxtHAT0J5oW8O8k5HCcQHJaoxELl9_ZgBmZFy20iLgxMW44YkUkZcAOZxZs.5M5 EuXKNWwa_BRzwnQGmlb.6WJngcL5.rYfdjsK9OQgrcqoPFw_FpCpV.r6lx15gXowQ5IVW3bGG.Vp vh5O1Y3NI9JcXGH0SSRUyXGpfAVD4RNV60Np0L8lGXAc3kxKx6d907Yt3BelSiDDywhUtBBoyw4W XwwTJ7FI.4WoVGPrut3CfnoOahmQLszpeJsH5ztjQjoQ.c4zcXK35p4y5QrSFoqfvDuURHobg1F. A4JjCDB.VYij5k7qjVl6u7yHgwUsHL7Aa_.oF4KSzoOvbj5.QWqfQgQM.GZPVT7rLvYH6u0olDYv 2QdDIh5LSVJ56GcPPAxoAhdh5.vADY4FUkwT1pWxOLzEUQjDiM_IR3h0N59cc4.Pyd8X3AWMKuUj b0f9wG4_lLt8c6b2hsKrMye0SWJRLNoRzEpI6mT0FUlq9X7KJfamFS.vh2yumf2UVUbtoTntoRJG ImtWpsS8zwJwRxHSYPCPJiTQLS1BzDEMAn_SU9krBUhtfK4Lx61A1eRrPGpCvMobOUGwRplaGox8 G30LoiJoNGcdwr_30e_ekJSNyDOAKJaQffFQzkjZTdurje8GqTIRJIKVd5CpkvYtY9ZtgvhfnYLT 3231Oz5sZvHRZXs7PtSQhd52i56keLEyFL12PDNkxZ6.yX6Adp3E7PvdjQEUloInSjQkQZKGRnUH lmT4Za8QNHJobQYJuyj7wMiFCV8zaES9MrsR6Siuu4uUIPiNaaBHzMstILJWoYfF8eEToMy4BAzu 6WKcC3SbptZTBU5XAXwMO4OcTdo7Cnayo_3atBosWRnjOquaaUDE0ai17s3zvaTGADyzruub0NBB i.Gf74g4Nd.Uc.HomeIELOTgMyNdCyIvKJ__unbaInPj7edvhkOxfUHyUhpBr6degsm4O4txsT4h XXmTUI12GDn.YKFoVtA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Thu, 2 Apr 2020 19:23:56 +0000 Received: by smtp425.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2e32dbf72d90c93a6239272075dea051; Thu, 02 Apr 2020 19:23:52 +0000 (UTC) User-Agent: Microsoft-MacOutlook/10.20.0.191208 Date: Thu, 02 Apr 2020 12:23:49 -0700 From: Mehmet Adalier To: Christer Holmberg , Abhijan Bhattacharyya , Thomas Fossati CC: core Message-ID: <7D444BF0-FD37-4A97-A833-5DC9F3788A30@antarateknik.com> Thread-Topic: [core] Using CoAP for P2P References: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> In-Reply-To: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3668675032_6601585" X-Mailer: WebService/1.1.15585 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 02 Apr 2020 19:24:00 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3668675032_6601585 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable As far as I know, a CoAP node can be provisioned to provide both client and= server functionality and change the behavior as required (i.e. act as a cli= ent when it is doing client work and act as a server/resource when doing ser= ver work). Our implementation runs a daemon that can instantiate multiple cl= ients/servers on a single computing node. =20 If you do not want to set up a Broker/Intermediary as a separate node (e.g.= , pubsub), then you can make one of your nodes also a =E2=80=9Ca broker=E2=80=9D and create your topics on that one (e.g., chatboard topic). Then each node = can subscribe to the topic as well as publish to the topic.=20 The described approach will support P2P and reduce traffic. =20 mehmet =20 From: core on behalf of Christer Holmberg Date: Thursday, April 2, 2020 at 11:41 AM To: Abhijan Bhattacharyya , Thomas Fossati= Cc: core Subject: Re: [core] Using CoAP for P2P =20 Hi, =20 If you are interested in P2P, you might be interested in the thin-ICE prese= ntation that was given at the T2TRG meeting in Singapore: =20 https://github.com/t2trg/2019-11-singapore/blob/master/slides/44-thin-ICE-1= 51119-Singapore.pdf =20 Regards, =20 Christer =20 =20 From: core on behalf of Abhijan Bhattacharyya Date: Thursday, 2 April 2020 at 11.04 To: Thomas Fossati Cc: core Subject: Re: [core] Using CoAP for P2P =20 Hi Thomas,=20 What I am looking at is a situation where I have two nodes each having a ti= me-varying resource. Both want to push the states of the respective resource= to the other node within a common application context. However, these excha= nges are naturally asynchronous. May be I can think of it more like a chat. = A typical client-server or observe relationship will not serve the purpose. = Actually both should have a client and server instance running under a commo= n application. Then either each can *observe* the other, or can *post* the o= ther. That is how we can do that without a central server. =20 If my understanding is right, according to CoAP specification, the nodes wh= ich can have both server and client (to the origin server) are "intermediary= " nodes. The only example of "intermediary" considered in the spec is the pr= oxy node. But, anyway the situation in this case does not concern with inter= mediary. Both are origin server and end-client together. =20 Is there any standardized mechanism to handle this situation? =20 Thanks. =20 On Wed, Apr 1, 2020 at 5:32 PM Thomas Fossati wrot= e: Hi Abhijan, On 01/04/2020, 12:31, Abhijan Bhattacharyya wrote: > Is there any standardized mechanism to use CoAP for a P2P connection? Not sure whether RFC 7650 would fit your needs but worth having a look -- if you haven't already. cheers -- IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, pl= ease notify the sender immediately and do not disclose the contents to any o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you. =20 --=20 Regards, Abhijan Bhattacharyya, Technologist by profession [IoT| Internet Protocols| 5G] _______________________________________________ core mailing list core@ietf= .org https://www.ietf.org/mailman/listinfo/core=20 --B_3668675032_6601585 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

As far as I know, a CoAP node can be provisioned t= o provide both client and server functionality and change the behavior as re= quired (i.e. act as a client when it is doing client work and act as a serve= r/resource when doing server work). Our implementation runs a daemon that ca= n instantiate multiple clients/servers on a single computing node.

 

If you do no= t want to set up a Broker/Intermediary as a separate node (e.g., pubsub), th= en you can make one of your nodes also a =E2=80=9Ca broker=E2=80=9D

and create your topics on that one (e.g., chatboard topic). The= n each node can subscribe to the topic as well as publish to the topic.

The described approach will support P2P and re= duce traffic.

 

mehmet

 

From: core <core-bounces@iet= f.org> on behalf of Christer Holmberg <christer.holmberg=3D40ericsson.co= m@dmarc.ietf.org>
Date: Thursday, April 2, 2020 at 11:41 AM
= To: Abhijan Bhattacharyya <abhijan.bhattacharyya@gmail.com>, Th= omas Fossati <Thomas.Fossati@arm.com>
Cc: core <core@ietf= .org>
Subject: Re: [core] Using CoAP for P2P<= /p>

 

Hi,

 

If you are interested in P2P, you might be interested in the thin-ICE pr= esentation that was given at the T2TRG meeting in Singapore:

<= p class=3DMsoNormal> 

https://github.com/t2trg/2019-11-singapore/blob/master/slides/44-= thin-ICE-151119-Singapore.pdf

 

Regards,

&nb= sp;

Christer

 

 

From: = core <core-bounces@ietf.org>= ; on behalf of Abhijan Bhattacharyya <abhijan.bhattacharyya@gmail.com>=
Date: Thursday, 2 April 2020 at 11.04
To: Thomas Fossat= i <Thomas.Fossati@arm.com>
Cc: core <core@ietf.org>Subject: Re: [core] Using CoAP for P2P

 

Hi Thomas,

What I am looking a= t is a situation where I have two nodes each having a time-varying resource.= Both want to push the states of the respective resource to the other n= ode within a common application context. However, these exchanges are natura= lly asynchronous. May be I can think of it more like a chat. A typical clien= t-server or observe relationship will not serve the purpose. Actually both s= hould have a client and server instance running under a common application. = Then either each can *observe* the other, or can *post* the other. That is h= ow we can do that without a central server.

 

If my underst= anding is right, according to CoAP specification, the nodes which can have b= oth server and client (to the origin server) are "intermediary&quo= t; nodes. The only example of "intermediary" considered in the spe= c is the proxy node. But, anyway the situation in this case does not concern= with intermediary. Both are origin server and end-client together.

 

Is there any standardized mechanism to handle this situation?

 

Thanks.

 

On Wed, Apr 1, 2020 a= t 5:32 PM Thomas Fossati <Thomas.= Fossati@arm.com> wrote:

Hi Abhijan,

On 01/04/2020, 12:31, Abhijan Bhattacharyya <abhijan.bhattach= aryya@gmail.com> wrote:
> Is there any standardized mechanism t= o use CoAP for a P2P connection?

Not sure whether RFC 7650 would fit = your needs but worth having a
look -- if you haven't already.

chee= rs
--




IMPORTANT NOTICE: The contents of this email and= any attachments are confidential and may also be privileged. If you are not= the intended recipient, please notify the sender immediately and do not dis= close the contents to any other person, use it for any purpose, or store or = copy the information in any medium. Thank you.


=  

--

Regards,

= Abhijan Bhattacharyya,

Technologist= by profession [IoT| Internet Protocols| 5G]

=

_______________________________________= ________ core mailing list core@ietf.org https://www.ietf.org/mailman/listin= fo/core

--B_3668675032_6601585-- From nobody Thu Apr 2 12:24:08 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA833A0FEB for ; Thu, 2 Apr 2020 12:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=yahoo.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 OhPeq0pLUw1t for ; Thu, 2 Apr 2020 12:23:59 -0700 (PDT) Received: from sonic316-19.consmr.mail.bf2.yahoo.com (sonic316-19.consmr.mail.bf2.yahoo.com [74.6.130.193]) (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 81AD83A0FE6 for ; Thu, 2 Apr 2020 12:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1585855436; bh=blGaC12YsyjgVHy3uuT1nV/iaRwa3eZCTNDrKfT164A=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject; b=ObQT/FBFQ4vr4Khzmlny3wG4+aBhE7etvyz6bCmwwcn54BOPsklQ7iSdGYJX7qDcDGybgekfsmVIfbWUNVnvS1RTenbRBnsXKdSrCC2k+/AFtR2Tm7f8Smbnr+EV3G1YCMsK6LaQq03GtQY4tUjVPYOUMderAUAbdUGHBo4+vW+KXveuTVEegd4DLmVn2GrbX2pf2PAMMN6Yz1IkfrAy8Pc33sM2mDnco0AjdaZs0CcyNc6JLd4VID871arKIM0ugL9tePLVGSUBFLCIAbzfDeQmXFof2rJ9uC6U2xP08PF4NB0SuZiPAInn+QFBWByKpAA0ngkE+OUobFNnPKHACw== X-YMail-OSG: YVydqMMVM1kVzthflo244Uy_UEcZYiMDIrjfg5bjvxg6bzQlCU1yo9lDcF.QjdK y0J9rFNtGvoXy48bUhZmgDfeUiBDCebvPfKIFTYAi2zSC.UDs7Z9uR.rya_kVrTPWFmGnqVQor4k C.Yy447ubDpTn31deYIk8tjggzU1rx0vDNz67mNkWi2DpJgi06503X5XFmcTZnugxOzOcyxEmC0J Vw36JWtRtZELCtxE2TyXzzrIh3LGqY88DKCqf1B7copkdJmYwIrgse2d8OscaQbQLimixP9ZrPtn tntWH3cTs6wznxE420VQ_VIKB8c4y7fFAb0WNizeLzeYRutzjF1MZf.VtNrV9AWF7IGF0k6g4gPW tJc1idnIV_RJTJEOtktUuGAXsIN26jh5foFZIljsapUiJ6WMBLecOBf1l8tj0CAFFTPCn82YRn2F 98BdOxtWj1c3ofxtHAT0J5oW8O8k5HCcQHJaoxELl9_ZgBmZFy20iLgxMW44YkUkZcAOZxZs.5M5 EuXKNWwa_BRzwnQGmlb.6WJngcL5.rYfdjsK9OQgrcqoPFw_FpCpV.r6lx15gXowQ5IVW3bGG.Vp vh5O1Y3NI9JcXGH0SSRUyXGpfAVD4RNV60Np0L8lGXAc3kxKx6d907Yt3BelSiDDywhUtBBoyw4W XwwTJ7FI.4WoVGPrut3CfnoOahmQLszpeJsH5ztjQjoQ.c4zcXK35p4y5QrSFoqfvDuURHobg1F. A4JjCDB.VYij5k7qjVl6u7yHgwUsHL7Aa_.oF4KSzoOvbj5.QWqfQgQM.GZPVT7rLvYH6u0olDYv 2QdDIh5LSVJ56GcPPAxoAhdh5.vADY4FUkwT1pWxOLzEUQjDiM_IR3h0N59cc4.Pyd8X3AWMKuUj b0f9wG4_lLt8c6b2hsKrMye0SWJRLNoRzEpI6mT0FUlq9X7KJfamFS.vh2yumf2UVUbtoTntoRJG ImtWpsS8zwJwRxHSYPCPJiTQLS1BzDEMAn_SU9krBUhtfK4Lx61A1eRrPGpCvMobOUGwRplaGox8 G30LoiJoNGcdwr_30e_ekJSNyDOAKJaQffFQzkjZTdurje8GqTIRJIKVd5CpkvYtY9ZtgvhfnYLT 3231Oz5sZvHRZXs7PtSQhd52i56keLEyFL12PDNkxZ6.yX6Adp3E7PvdjQEUloInSjQkQZKGRnUH lmT4Za8QNHJobQYJuyj7wMiFCV8zaES9MrsR6Siuu4uUIPiNaaBHzMstILJWoYfF8eEToMy4BAzu 6WKcC3SbptZTBU5XAXwMO4OcTdo7Cnayo_3atBosWRnjOquaaUDE0ai17s3zvaTGADyzruub0NBB i.Gf74g4Nd.Uc.HomeIELOTgMyNdCyIvKJ__unbaInPj7edvhkOxfUHyUhpBr6degsm4O4txsT4h XXmTUI12GDn.YKFoVtA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Thu, 2 Apr 2020 19:23:56 +0000 Received: by smtp425.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2e32dbf72d90c93a6239272075dea051; Thu, 02 Apr 2020 19:23:52 +0000 (UTC) User-Agent: Microsoft-MacOutlook/10.20.0.191208 Date: Thu, 02 Apr 2020 12:23:49 -0700 From: Mehmet Adalier To: Christer Holmberg , Abhijan Bhattacharyya , Thomas Fossati CC: core Message-ID: <7D444BF0-FD37-4A97-A833-5DC9F3788A30@antarateknik.com> Thread-Topic: [core] Using CoAP for P2P References: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> In-Reply-To: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3668675032_6601585" X-Mailer: WebService/1.1.15585 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 02 Apr 2020 19:24:00 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3668675032_6601585 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable As far as I know, a CoAP node can be provisioned to provide both client and= server functionality and change the behavior as required (i.e. act as a cli= ent when it is doing client work and act as a server/resource when doing ser= ver work). Our implementation runs a daemon that can instantiate multiple cl= ients/servers on a single computing node. =20 If you do not want to set up a Broker/Intermediary as a separate node (e.g.= , pubsub), then you can make one of your nodes also a =E2=80=9Ca broker=E2=80=9D and create your topics on that one (e.g., chatboard topic). Then each node = can subscribe to the topic as well as publish to the topic.=20 The described approach will support P2P and reduce traffic. =20 mehmet =20 From: core on behalf of Christer Holmberg Date: Thursday, April 2, 2020 at 11:41 AM To: Abhijan Bhattacharyya , Thomas Fossati= Cc: core Subject: Re: [core] Using CoAP for P2P =20 Hi, =20 If you are interested in P2P, you might be interested in the thin-ICE prese= ntation that was given at the T2TRG meeting in Singapore: =20 https://github.com/t2trg/2019-11-singapore/blob/master/slides/44-thin-ICE-1= 51119-Singapore.pdf =20 Regards, =20 Christer =20 =20 From: core on behalf of Abhijan Bhattacharyya Date: Thursday, 2 April 2020 at 11.04 To: Thomas Fossati Cc: core Subject: Re: [core] Using CoAP for P2P =20 Hi Thomas,=20 What I am looking at is a situation where I have two nodes each having a ti= me-varying resource. Both want to push the states of the respective resource= to the other node within a common application context. However, these excha= nges are naturally asynchronous. May be I can think of it more like a chat. = A typical client-server or observe relationship will not serve the purpose. = Actually both should have a client and server instance running under a commo= n application. Then either each can *observe* the other, or can *post* the o= ther. That is how we can do that without a central server. =20 If my understanding is right, according to CoAP specification, the nodes wh= ich can have both server and client (to the origin server) are "intermediary= " nodes. The only example of "intermediary" considered in the spec is the pr= oxy node. But, anyway the situation in this case does not concern with inter= mediary. Both are origin server and end-client together. =20 Is there any standardized mechanism to handle this situation? =20 Thanks. =20 On Wed, Apr 1, 2020 at 5:32 PM Thomas Fossati wrot= e: Hi Abhijan, On 01/04/2020, 12:31, Abhijan Bhattacharyya wrote: > Is there any standardized mechanism to use CoAP for a P2P connection? Not sure whether RFC 7650 would fit your needs but worth having a look -- if you haven't already. cheers -- IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, pl= ease notify the sender immediately and do not disclose the contents to any o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you. =20 --=20 Regards, Abhijan Bhattacharyya, Technologist by profession [IoT| Internet Protocols| 5G] _______________________________________________ core mailing list core@ietf= .org https://www.ietf.org/mailman/listinfo/core=20 --B_3668675032_6601585 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

As far as I know, a CoAP node can be provisioned t= o provide both client and server functionality and change the behavior as re= quired (i.e. act as a client when it is doing client work and act as a serve= r/resource when doing server work). Our implementation runs a daemon that ca= n instantiate multiple clients/servers on a single computing node.

 

If you do no= t want to set up a Broker/Intermediary as a separate node (e.g., pubsub), th= en you can make one of your nodes also a =E2=80=9Ca broker=E2=80=9D

and create your topics on that one (e.g., chatboard topic). The= n each node can subscribe to the topic as well as publish to the topic.

The described approach will support P2P and re= duce traffic.

 

mehmet

 

From: core <core-bounces@iet= f.org> on behalf of Christer Holmberg <christer.holmberg=3D40ericsson.co= m@dmarc.ietf.org>
Date: Thursday, April 2, 2020 at 11:41 AM
= To: Abhijan Bhattacharyya <abhijan.bhattacharyya@gmail.com>, Th= omas Fossati <Thomas.Fossati@arm.com>
Cc: core <core@ietf= .org>
Subject: Re: [core] Using CoAP for P2P<= /p>

 

Hi,

 

If you are interested in P2P, you might be interested in the thin-ICE pr= esentation that was given at the T2TRG meeting in Singapore:

<= p class=3DMsoNormal> 

https://github.com/t2trg/2019-11-singapore/blob/master/slides/44-= thin-ICE-151119-Singapore.pdf

 

Regards,

&nb= sp;

Christer

 

 

From: = core <core-bounces@ietf.org>= ; on behalf of Abhijan Bhattacharyya <abhijan.bhattacharyya@gmail.com>=
Date: Thursday, 2 April 2020 at 11.04
To: Thomas Fossat= i <Thomas.Fossati@arm.com>
Cc: core <core@ietf.org>Subject: Re: [core] Using CoAP for P2P

 

Hi Thomas,

What I am looking a= t is a situation where I have two nodes each having a time-varying resource.= Both want to push the states of the respective resource to the other n= ode within a common application context. However, these exchanges are natura= lly asynchronous. May be I can think of it more like a chat. A typical clien= t-server or observe relationship will not serve the purpose. Actually both s= hould have a client and server instance running under a common application. = Then either each can *observe* the other, or can *post* the other. That is h= ow we can do that without a central server.

 

If my underst= anding is right, according to CoAP specification, the nodes which can have b= oth server and client (to the origin server) are "intermediary&quo= t; nodes. The only example of "intermediary" considered in the spe= c is the proxy node. But, anyway the situation in this case does not concern= with intermediary. Both are origin server and end-client together.

 

Is there any standardized mechanism to handle this situation?

 

Thanks.

 

On Wed, Apr 1, 2020 a= t 5:32 PM Thomas Fossati <Thomas.= Fossati@arm.com> wrote:

Hi Abhijan,

On 01/04/2020, 12:31, Abhijan Bhattacharyya <abhijan.bhattach= aryya@gmail.com> wrote:
> Is there any standardized mechanism t= o use CoAP for a P2P connection?

Not sure whether RFC 7650 would fit = your needs but worth having a
look -- if you haven't already.

chee= rs
--




IMPORTANT NOTICE: The contents of this email and= any attachments are confidential and may also be privileged. If you are not= the intended recipient, please notify the sender immediately and do not dis= close the contents to any other person, use it for any purpose, or store or = copy the information in any medium. Thank you.


=  

--

Regards,

= Abhijan Bhattacharyya,

Technologist= by profession [IoT| Internet Protocols| 5G]

=

_______________________________________= ________ core mailing list core@ietf.org https://www.ietf.org/mailman/listin= fo/core

--B_3668675032_6601585-- From nobody Fri Apr 3 04:04:19 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7693A17BD for ; Fri, 3 Apr 2020 04:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-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 JVNfLlv1V9JP for ; Fri, 3 Apr 2020 04:04:10 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50088.outbound.protection.outlook.com [40.107.5.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE84E3A17BB for ; Fri, 3 Apr 2020 04:04:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WhddMS3NIfyKXYUjPCyNQybSRyviYaG2neAsWLJ+9npMS8kjJ1WHswagbuzAQvcuz/ZtVZro4WbhJeAh5u8Z7XWg1TualMvMuXz2j+YXZWtMMrmxLbC7L+DZIAiqq6gFwgYZM8Xvb0wJQAeyvwzK7kmlfr/IU67mSmeX+Lpub96hQjuMAKONwpvzwmX0xjaCI4FW54AAybHPy3YQTtIMs6MWtQmMdq2/Y7Lag5DT17zpVpLy9xR+0u5OU15CL3DEojPCVbEHKWRCL1c4viYjwz1jPxSX5B4BeJDZY9CRnckYodFVRICAyCZcpfRVE2x8TGVHuxCMcsqcLwRkqmKTkQ== 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=CNvA+66Zs6wB9oq4o9EwaLhw7V1k64ST3jh5pAiR1wg=; b=XT3BS3YFQpHsKMIsmfD9CzPodJkKwUp4eT1BDTok3ADPo5msMAM9m7MR9zpPmnyFyQ7JKSBjDxYyHaKxGFRhoXiVmXwymL4U1ctSLDHgksRksm8IA/0bSAWO2fwmlvO9Z4eXMUn3Hxhe8X2aEp2t70JwXuotrorsw8cWOba1JuK2ugWzqP6MBH8Bj2NgCwwsVvppmlf/gacGYHhU4y3Xb0gHkhvqlxleuU+yuYUFwMYwCjXy1+hayiaB3m2yr3UYZLcYXSwaIgTpKkTCbZKDWyCaBFG1TlE0sUMlEGgxGmYDGQ08oQm98W6c996m8h/0PYvasyF6wrPRYCnJtURZFw== 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=CNvA+66Zs6wB9oq4o9EwaLhw7V1k64ST3jh5pAiR1wg=; b=Kojxy9FIC/VP0WrdMGLnyq8Q1vKf2kpEqv4oPE/JTqdRwDBeDvouRki8zUFUS+bka3kxGKnbRPdZon30e8DgcenB9NLDW3c4+8bnATbcR+1qJkFy2T8X7wO5STzCofLT7TV67/nyDcCZjRyi4id34EXvxJQuZCiUAhXQoA0ZMPo= Received: from AM6PR07MB4584.eurprd07.prod.outlook.com (20.177.37.216) by AM6PR07MB5576.eurprd07.prod.outlook.com (20.178.90.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.13; Fri, 3 Apr 2020 11:03:55 +0000 Received: from AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::928:dc19:896b:4b91]) by AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::928:dc19:896b:4b91%6]) with mapi id 15.20.2878.014; Fri, 3 Apr 2020 11:03:54 +0000 From: John Mattsson To: "core@ietf.org" Thread-Topic: Allowing non-HMAC based KDF in OSCORE Thread-Index: AQHWCaeQBKQ/R/PrJ0CpFz210vCuHQ== Date: Fri, 3 Apr 2020 11:03:54 +0000 Message-ID: <5CD4BE47-4E21-4E00-8BE7-752917CBAF51@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 035948b9-8259-4041-d912-08d7d7beb365 x-ms-traffictypediagnostic: AM6PR07MB5576: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB4584.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(136003)(346002)(396003)(39860400002)(376002)(478600001)(81156014)(2616005)(81166006)(8676002)(8936002)(6512007)(36756003)(6506007)(316002)(86362001)(44832011)(6486002)(66556008)(66476007)(2906002)(33656002)(186003)(6916009)(91956017)(66946007)(64756008)(26005)(71200400001)(5660300002)(76116006)(66446008); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: e7UaZXOCBi1vUVeQpGzvhVcf5/XnckGPDwA6vGCqfdM4G+neb4y0Nd/67zjYjHvqz1JZWkZCd5hGbDILvwtrTMLzPeRXFzq8yYl3rI1CBsU3D3ZPx/smkSg+XfJF2UFTyXJKlgYMTDJdgiwI2exQBnyiqW91UwewPpf7G8f6oBhTR2uklG3jCtzz+4Rwkva/PDkOorHCIaCmI6O5RjQwQdctaux4THRlM9Q5ZtXzI+1YK5D1/xBZNYJzjEFgfBVAKUG780+e94DvyzmVPvLCynnz5zlC+5G7x3OUWR5cNm48tJ+xXjOn3hFg0QF9uowYdDLWaGyfM3+T8g2gD8FHNnIaad9QsdVQH98emO6lopOsQpNb1F/BHLe8P3BzV5zO76+6jnTu3aHgEPppXyX99zzgothfwbz0mQv2NIxGKw7lpteww1/ZKsHZwv5OS4M1 x-ms-exchange-antispam-messagedata: XOqCrnXJB19xeF169tgpgHhNYIXAA4Bmhhi7pm7v00QbMThCKlOpVqm/rjvhnaxBrPeEgihzYUWdGmKk2XQWYA4T4UwnBvFVI58ySD7aLT0RcX0Uaa3o6U+VFJYulUWd2rWyuKdqv7ICrYca0JpO2g== 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-Network-Message-Id: 035948b9-8259-4041-d912-08d7d7beb365 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 11:03:54.8819 (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: RNT89w8mapdL9k/n83OT2CdyR64FnKznG/8Lj1PXtAuxyVw+4CMEuVO199IZiKNU7mFTF7ajI+XPRwLzY3FlRxpf6fQ065YE7dFQ5sJ9PhY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5576 Archived-At: Subject: [core] Allowing non-HMAC based KDF in OSCORE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 11:04:18 -0000 IEhpLA0KDQpBcyBwb2ludGVkIG91dCBieSBKaW0gaW4gdGhlIENPU0UgdmlydHVhbCBpbnRlcmlt IHllc3RlcmRheSwgT1NDT1JFIHJlc3RyaWN0cyB0aGUgdHlwZSBvZiBLREYgdG8gSE1BQy1iYXNl ZCBIS0RGIGFsZ29yaXRobXMuIEkgZG8gbm90IGtub3cgKG9yIHJlbWVtYmVyKSB3aHkgdGhlIHJl c3RyaWN0aW9uIGlzIHRoZXJlLg0KDQotIFRoZXJlIGFyZSBubyBzZWN1cml0eSByZWFzb25zIGZv ciB0aGUgbGltaXRhdGlvbiAoYXQgbGVhc3Qgbm90IGlmIE1hc3RlciBTZWNyZXQgaXMgdW5pZm9y bWx5IHJhbmRvbSksIGFuZCBpdCBjdXJyZW50bHkgaGluZGVycyBPU0NPUkUgdG8gYmUgdXNlZCB3 aXRoIHRoZSBDT1NFIEFFUyBiYXNlZCBLREZzLg0KLSBUaGUgcmVzdHJpY3Rpb24gaXMgY3VycmVu dGx5IGEgcHJhY3RpY2FsIHByb2JsZW0uIDZUaVNDSCBwZW9wbGUgaGF2ZSBzdGF0ZWQgdGhhdCB1 c2luZyBBRVMgYW5kIFNIQS0yNTYgaXMgbm90IGEgcHJvYmxlbSBhdCBhbGwuDQotIGhvd2V2ZXIs IHRoZSByZXN0cmljdGlvbiBtYXkgYmUgbW9yZSBsaW1pdGluZyBpbiB0aGUgZnV0dXJlLiBDT1NF IGlzIGN1cnJlbnRseSBkaXNjdXNzaW5nIGFkZGluZyBLTUFDLiBGb3IgYSBub2RlIGltcGxlbWVu dGlnbiBTSEFLRTEyOCwgSE1BQyBpcyBvdmVya2lsbCwgYW5kIEtNQUMgaXMgYSBzaW1wbGVyIGFu ZCBtb3JlIGxpZ2h0d2VpZ2h0IGFsdGVybmF0aXZlLiBITUFDIHdhcyBzcGVjaWZpY2FsbHkgZGVz aWduIHRvIG1pdGlnYXRlIHRoZSBsZW5ndGggZXh0ZW5zaW9uIGF0dGFja3Mgb2YgZWFybHkgaGFz aCBmdW5jdGlvbnMgYW5kIGlzIG5vdCBuZWVkZWQgZm9yIFNIQS0zLiBOSVNUIGxpZ2h0d2VpZ2h0 IGNyeXB0byBjb21wZXRpdGlvbiBoYXZlIG1hbnkgcHJpbWl0aXZlcyB0aGF0IGNhbiBiZSB1c2Vk IGZvciBib3RoIEFFQUQgYW5kIGhhc2hpbmcsIHRoZXkgd2lsbCBsaWtlbHkgaGF2ZSBsaWdodHdl aWdodCBLREYgbW9kZXMgZGlmZmVyZW50IGZyb20gSE1BQyBtb2RlLg0KDQpJIGRvbid0IHRoaW5r IHRoZXJlIGlzIGFueSBodXJyeSB0byBjaGFuZ2UgdGhpcyByZXN0cmljdGlvbiBidXQgSSB0aGlu ayBpdCBzaG91bGQgYmUgY2hhbmdlZCBhdCBzb21lIHBvaW50LiBJdCBtYWtlcyBzZW5zZSBmb3Ig T1NDT1JFIHRvIGFsbG93IGFueSBLREYgc3BlY2lmaWVkIGluIENPU0UuIEkgd291bGQgc3VnZ2Vz dCB0aGF0IEdyb3VwIE9TQ09SRSAod2hpY2ggdXBkYXRlcyBPU0NPUkUpIGxpZnRzIHRoaXMgbGlt aXRhdGlvbiBhbHNvIGZvciBSRkMgODYxMy4gQW5vdGhlciBwb3NzaWJpbGl0eSBpcyB0byB3cml0 ZSBhIG5ldyBkcmFmdCwgYnV0IGl0IHNlZW1zIGVhc2llciB0byBqdXN0IHB1dCBpdCBpbiBHcm91 cCBPU0NPUkUuDQoNCkNoZWVycywNCkpvaG4NCg0K From nobody Fri Apr 3 05:38:29 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5896D3A174A for ; Fri, 3 Apr 2020 05:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UU2nCutyD-nX for ; Fri, 3 Apr 2020 05:38:22 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2096.outbound.protection.outlook.com [40.107.22.96]) (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 3BA423A10C3 for ; Fri, 3 Apr 2020 05:38:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UtUqIsfGVxycqFrsigHJS1QRJeSflOa6VAvAz4qeXJVz9+9uPE7Z12dRYAlQw1rCsxFb5yaZgD0r/0VoZ43AOu/UC4ICuU6bm6St6LvMv3U7jV3vI6eO1gXg71hSt7QYH+HONDbcyv2UpWU8sK9Z6vTrL/v9CIJvbFiSqU5byIQNW0Qxi6ygGvyJynrD2FCoJrt8DvhDgYZZeSjEQZbM9ZCAasMWF9GBX1QCi2wZ3jChWPSwBjboXW9EPmZBUPZ2hpSqW8AsKtvuhDQowaI0xLEcMR8Lfz94GVecfgHWca0x320mrY31v03pPbf8g8y4BXQdo9V3K3jhlK51mjjlRg== 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=1ephWU0aflFqpK76B5Y5mh4eyg6oV4rb2yqGmfTzVjA=; b=c7rvJCO7OzwQJKsNGRZKl8eWHBai4YAsMmKukimy7pxEBeFO7/aAVJs8wBU8HYBoUktOFYAFuNUfdLCRjvFOTOFJqhsdrAT+EcAM5bYe3iVnIDYsvqRNI/jzehqwaAXiKrnEsykrevL2SEgKZhVNEf18Clhc4uDl5/qzvfrNPIrZgN/lt9CXli5gDjb6RUNWO1BlcTjMOqdHZn+vgz7nARg/vtlj9hLa62cLJ/JqDyopoMldPvDIBcOOO1j0Q7e+FUft3Of++EDwdiQG6RJdQzk+/c6UfU2gSKqT3VXQ6+ZHa+sBTMy5KQbXEETmsyBVKLfdpuOtCB1PM2xRRQQg9g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector2-iotconsultancynl-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1ephWU0aflFqpK76B5Y5mh4eyg6oV4rb2yqGmfTzVjA=; b=MjpoiESydQ5bFE3b85YyimDFIzfGSckp7WZV1T34XZuTpYI7V73yVLm7+Bov3vjtk3ihkhiPwYCezajkurq+gJ8c2dJBvRQxZ3u0KOnHb/Us+e6/E+gK6PqqIv+GVwbJAz+psZOdHZZUVhKdOTr6Z3r4JqL2CcTlttNpvK7xhTU= Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM (10.161.62.28) by AM5P190MB0561.EURP190.PROD.OUTLOOK.COM (10.161.66.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Fri, 3 Apr 2020 12:38:18 +0000 Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::8c96:a66b:e170:bf8f]) by AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::8c96:a66b:e170:bf8f%3]) with mapi id 15.20.2878.018; Fri, 3 Apr 2020 12:38:18 +0000 From: Esko Dijk To: Jim Schaad , 'Achim Kraus' , 'Thomas Fossati' , 'Klaus Hartke' CC: "core@ietf.org" Thread-Topic: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top Thread-Index: AQHWBAJ4QQxxhgNVoE6+AM1rLNkaVahcnYmAgAAdZICABcLe8IAAHjWAgABVYQCAAP5CIIAADCeAgAAkYYCAAE/IAIAAUBuAgADFdpCAAIJoAIABVUGg Date: Fri, 3 Apr 2020 12:38:18 +0000 Message-ID: References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> <02ec5628-3f7d-ff5d-620c-c0a90a4b89b0@gmx.net> <020701d60907$fb3ba720$f1b2f560$@augustcellars.com> In-Reply-To: <020701d60907$fb3ba720$f1b2f560$@augustcellars.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:6d00:48bf:f11d:8f40:12c4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0f4eeeaf-591d-49b6-54ed-08d7d7cbe321 x-ms-traffictypediagnostic: AM5P190MB0561: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM5P190MB0275.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(376002)(39830400003)(396003)(346002)(136003)(366004)(8936002)(71200400001)(52536014)(110136005)(186003)(4326008)(5660300002)(86362001)(316002)(44832011)(9686003)(66446008)(2906002)(76116006)(508600001)(81166006)(966005)(6506007)(33656002)(64756008)(7696005)(66476007)(55016002)(81156014)(8676002)(66556008)(53546011)(66946007); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LUERJC+IABD8g6x3yLnQOaL5KmKggGybvj9q1ke+9fGxL7hNJ8SUv6A+ajwDUAPc1d2diU2SbQU7E4zCdm67Pnyf/oQWK/AngOe0lZDutoAH5Jwt9m6NMwKZBRON6SEdAIBQv5jlte8Biji51X790TQ+rwGRMpo09xAbu9NZXTZUdCvEAPrw8ipnMILaKhHpbo/xR6vW7DFnxM2DgTLsSSGaiKEghL3UyeYmuOt8JRRhGlM0n8BDWWGc696JM/pN98ET9qasKDkSijlgaca/dXIQb9VfI/D1O0g1f55e8/LELTBYnotlUgUe+jRbALcN6/ZIP0R2hZ+NWilA77pOauEXaUMOvwZxu5e2RqukuUuPTkmYZ8zWUXEkydd9PoVia/fYa+Jvlw186MOujkZjo8+bWBtm9E1YaVqc3kyv01wL2t6r1X4gI2V8mu+stDAydcP3wwaJ9mULQIkOHIE5VznScoOydH4fRxdbeAToasHaWMDxac6Vc2RxBYq9Y8NJz1kFPFDodiJ5iehwwn87Ag== x-ms-exchange-antispam-messagedata: XjZ1ur5Yzc7FSMsbFr4ssCnma5lYtMG3vrhGp4LXDtUAEyx1kwm4Vga3WdixLL9ifYG+qADsKpOENvDnTOpo1CFL18Q9ZlPxlu+rG3KAJL0U4f/TO4GKCt+F3XzwoErgRR93VHbY+SNZbTjdXVGHHrFxpNcMwNu6JVs7D3eWQTp8YUUVSi6+Vc0m1cCcD46vToxL4P9Z5YNGOXFsuK3FtA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-Network-Message-Id: 0f4eeeaf-591d-49b6-54ed-08d7d7cbe321 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 12:38:18.4180 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KIPKY9FBUstwTM5trd/PatZbG8SPgbNiVhJPt5FS+cCWDwsJlyQQJm/1k5r/FZiHNs5O5TWCQ7iPQ0lvPrZtSoiI8QZm7OrC7di74K2V3CY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0561 Archived-At: Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top 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, 03 Apr 2020 12:38:28 -0000 SGVsbG8gSmltLA0KDQpDb3VsZCB5b3UgY2xhcmlmeSB5b3VyIHBvaW50IGZ1cnRoZXI/IA0KLSB3 aGF0IGlzIGEgYmFkIGlkZWEgLSBoYXZpbmcgYSBkZWRpY2F0ZWQgcG9ydCB3aXRoIGRlZGljYXRl ZCBmb3IgaGFuZGxpbmcgbXVsdGljYXN0IHJlcXVlc3RzPyAgT3IgdGhlIHN1YnNlcXVlbnQgImlu dGVybmFsIHJvdXRpbmciIG9mIHRoZSByZXF1ZXN0IHRvIHRoZSB1bmljYXN0IHNlcnZlciBhdCBh IGRpZmZlcmVudCBwb3J0PyBPciBib3RoPw0KLSB3aGF0IGlzIGEgIm11bHRpY2FzdCBjaGFubmVs IiAsIGRvIHlvdSBtZWFuIGFuIGVuZHBvaW50IGJvdW5kIHRvIGEgbXVsdGljYXN0IGFkZHJlc3Mg Pw0KDQo+IHNvbWUgcmVzb3VyY2VzIG1heSBvbmx5IHdhbnQgdG8gYmUgb24gYSBzaW5nbGUgbXVs dGljYXN0IGFkZHJlc3MgZXZlbiBpZiB0aGUgc2VydmVyIGlzIGxpc3RlbmluZyBvbiBtdWx0aXBs ZSB1bmljYXN0IGFkZHJlc3Nlcw0KDQpTdXJlLCB5b3UgY2FuIGFsc28gaGF2ZSBhIGRlZGljYXRl ZCBzZXJ2ZXIgb24gc2F5IHBvcnQgOjk5OTkgdGhhdCBsaXN0ZW5zIHRvIG11bHRpY2FzdCBkZXN0 aW5hdGlvbiBhZGRyZXNzZXMgb25seSwgYmVjYXVzZSBpdCBpcyBib3VuZCBvbmx5IHRvIGEgbXVs dGljYXN0IGFkZHJlc3Mgbm90IGEgdW5pY2FzdCBhZGRyZXNzLiBUaGlzIGRlZGljYXRlZCBzZXJ2 ZXIgY2FuIHRoZW4gaGFuZGxlIHJlc291cmNlcyB0aGF0IG9ubHkgYXJlIHRvIGJlIGFjY2Vzc2Vk IHZpYSBtdWx0aWNhc3QuDQpCdXQgaW4gdGhpcyBjYXNlLCB0aGVyZSdzIG5vICJpbnRlcm5hbCBy b3V0aW5nIiBuZWVkZWQgdG8gYW5vdGhlciBzZXJ2ZXIgaW5zaWRlIHRoZSBub2RlIGJlY2F1c2Ug dGhlIHJlc291cmNlIGlzIG9ubHkgaG9zdGVkIGF0IHNheSBwb3J0IDo5OTk5Lg0KDQo+IFRoZSBJ UCBhZGRyZXNzIGlzIGRpZmZlcmVudCBmb3IgYSBtdWx0aWNhc3QgdnMgYSB1bmljYXN0IG1lc3Nh Z2UgcmVjZWl2ZWQgYXQgdGhlIHNlcnZlci4gIFRoaXMgbmVlZHMgdG8gYmUgdGhlIGRpc3RpbmN0 aW9uDQoNCkJ1dCB0aGUgY2FzZSB0aGUgQWNoaW0gaW5kaWNhdGVkIGlzIHRoYXQgdGhlIHNlcnZl ciBtYXkgbm90IGJlIGFibGUgdG8gZGV0ZWN0IHdoZXRoZXIgYSByZXF1ZXN0IGNhbWUgaW4gdmlh IHVuaWNhc3Qgb2YgbXVsdGljYXN0LiBTbyB0aGlzIGNhbm5vdCBiZSB0aGUgZGlzdGluY3Rpb24s IGUuZy4gaW4gdGhlIGZvbGxvd2luZyBjYXNlOg0KMSkgQ29BUCBzZXJ2ZXIgYXQgcG9ydCA1Njgz IGlzIGJvdW5kIHRvIHVuaWNhc3QgYWRkcmVzcyBVDQoyKSBhdCBzYW1lIG5vZGUsIHNhbWUgQ29B UCBzZXJ2ZXIgYXQgcG9ydCA1NjgzIGlzIGJvdW5kIHRvIG11bHRpY2FzdCBhZGRyZXNzIE0NCg0K Tm93IGluIHRoaXMgY2FzZSBpZiBhIHJlcXVlc3QgY29tZXMgaW4gdmlhIG11bHRpY2FzdCBncm91 cCBNIGRlc3RpbmVkICB0byBwb3J0IDU2ODMsIHRoZSBzZXJ2ZXIgaGFuZGxpbmcgdGhpcyBjYW5u b3QgdGVsbCB3aGV0aGVyIGl0IHdhcyB1bmljYXN0IG9yIG11bHRpY2FzdC4gQW5kIGlmIGEgdW5p Y2FzdCByZXF1ZXN0IGNvbWVzIGluIHRvIGRlc3RpbmF0aW9uIGFkZHJlc3MgVSBhbmQgcG9ydCA1 NjgzLCB0aGUgc2VydmVyIGNhbm5vdCB0ZWxsIGFsc28gd2hldGhlciB0aGF0IHdhcyB1bmljYXN0 IG9yIG11bHRpY2FzdC4NCg0KQnkgc2V0dGluZyBpdCB1cCBsaWtlIHRoaXMgaW5zdGVhZCB0aGF0 IHByb2JsZW0gaXMgYXZvaWRlZDoNCjEpIENvQVAgc2VydmVyIGF0IHBvcnQgNTY4MyBpcyBib3Vu ZCB0byB1bmljYXN0IGFkZHJlc3MgVQ0KMikgYXQgc2FtZSBub2RlLCBzYW1lIENvQVAgc2VydmVy IGF0IHBvcnQgOTk5OSBpcyBib3VuZCB0byBtdWx0aWNhc3QgYWRkcmVzcyBNDQpUaGVuIHRoZSBz ZXJ2ZXIgYXQgcG9ydCA1NjgzIHRyZWF0cyBldmVyeXRoaW5nIGFzIHVuaWNhc3QuIChCZWNhdXNl IGl0IGlzIG5vdCBib3VuZCB0byBhIG11bHRpY2FzdCBhZGRyZXNzLCBpdCB3b24ndCByZWNlaXZl IGFueSBtdWx0aWNhc3QgcmVxdWVzdHMgZGlyZWN0bHkuKQ0KQW5kIHRoZSBzZXJ2ZXIgYXQgcG9y dCA5OTk5IHRyZWF0cyBldmVyeXRoaW5nIGFzIG11bHRpY2FzdC4gKEFuZCB0aGlzIGVuZHBvaW50 IDk5OTkgaGFuZGxlcyBtb3N0IHJlcXVlc3RzIGJ5IGludGVybmFsbHkgcmVkaXJlY3RpbmcgdG8g c2VydmVyIDo1NjgzLCBidXQgb25seSBmb3IgdGhvc2UgcmVzb3VyY2VzIHdoZXJlIG11bHRpY2Fz dCBpcyBhbGxvd2VkLiBTb21lIHJlcXVlc3QgZm9yIG11bHRpY2FzdC1vbmx5IHJlc291cmNlcyBp dCBjYW4gaGFuZGxlIGl0c2VsZiBkaXJlY3RseS4pDQoNClNvIHRoZSBhYm92ZSAid29ya2Fyb3Vu ZCIgc2VlbXMgaGFuZHkgZm9yIGNhc2VzIHdoZXJlIGEgc2VydmVyIGF0IG9uZSBzcGVjaWZpYyBV RFAgY2Fubm90IGl0c2VsZiBkZXRlcm1pbmUgdGhlIGVuZHBvaW50IHRoZSByZXF1ZXN0IGNhbWUg aW4gZnJvbSAoY291bGQgYmUgZWl0aGVyIG11bHRpY2FzdCBsaWtlIE0gb3IgdW5pY2FzdCBsaWtl IFUpLg0KDQpAQWNoaW0gbWF5YmUgeW91IGNvdWxkIGNvbW1lbnQgaWYgSSd2ZSB1bmRlcnN0b29k IHlvdXIgdXNlIGNhc2UgcHJvcGVybHkuICBUbyBtZSB0aGUgYWJvdmUgc2VlbXMgbW9yZSBzZWN1 cmUgdGhhbiB0cnVzdGluZyB0aGF0IGEgY2xpZW50IHdpbGwgaW5jbHVkZSBhICJUaGlzIGlzIG11 bHRpY2FzdCIgQ29BUCBPcHRpb24gaW4gYW4gaG9uZXN0IHdheSwgd2hpY2ggY291bGQgZWFzaWx5 IGJlIG1pc3VzZWQuDQoNCnRoYW5rcw0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4gDQpTZW50OiBUaHVy c2RheSwgQXByaWwgMiwgMjAyMCAxODowMg0KVG86IEVza28gRGlqayA8ZXNrby5kaWprQGlvdGNv bnN1bHRhbmN5Lm5sPjsgJ0FjaGltIEtyYXVzJyA8YWNoaW1rcmF1c0BnbXgubmV0PjsgJ1Rob21h cyBGb3NzYXRpJyA8dGhvLmlldGZAZ21haWwuY29tPjsgJ0tsYXVzIEhhcnRrZScgPGhhcnRrZUBw cm9qZWN0Y29vbC5kZT4NCkNjOiBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW2NvcmVdIFJG QyA3MjUyIC0gOC4yIC0gTXVsdGljYXN0IC0gUmVxdWVzdCAvIFJlc3BvbnNlIExheWVyLCBwYWdl IDY3LCB0b3ANCg0KRXNrbywNCg0KVGhhdCBpZGVhIHN0cmlrZXMgbWUgYXMgYSB2ZXJ5IGJhZCBp ZGVhLiAgIElmIHlvdSBidWlsZCB5b3VyIGNvZGUgb24gdGhpcyBiYXNpcyB5b3Ugd2lsbCBmYWxs IG92ZXIgdGhlIGZpcnN0IHRpbWUgeW91IGNvbWUgYWNyb3NzIGEgbXVsdGljYXN0IGNoYW5uZWwg d2hpY2ggdXNlcyB0aGUgc2FtZSBwb3J0IGFzIHRoZSB1bmljYXN0IHNlcnZlci4gICBUaGUgSVAg YWRkcmVzcyBpcyBkaWZmZXJlbnQgZm9yIGEgbXVsdGljYXN0IHZzIGEgdW5pY2FzdCBtZXNzYWdl IHJlY2VpdmVkIGF0IHRoZSBzZXJ2ZXIuICBUaGlzIG5lZWRzIHRvIGJlIHRoZSBkaXN0aW5jdGlv biBhcyB3ZWxsIGFzIHRoZSBmYWN0IHRoYXQgc29tZSByZXNvdXJjZXMgbWF5IG9ubHkgd2FudCB0 byBiZSBvbiBhIHNpbmdsZSBtdWx0aWNhc3QgYWRkcmVzcyBldmVuIGlmIHRoZSBzZXJ2ZXIgaXMg bGlzdGVuaW5nIG9uIG11bHRpcGxlIHVuaWNhc3QgYWRkcmVzc2VzLg0KDQpKaW0NCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZSA8Y29yZS1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgRXNrbyBEaWprDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMiwgMjAyMCAx OjIzIEFNDQpUbzogQWNoaW0gS3JhdXMgPGFjaGlta3JhdXNAZ214Lm5ldD47IFRob21hcyBGb3Nz YXRpIDx0aG8uaWV0ZkBnbWFpbC5jb20+OyBLbGF1cyBIYXJ0a2UgPGhhcnRrZUBwcm9qZWN0Y29v bC5kZT4NCkNjOiBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIFJGQyA3MjUyIC0g OC4yIC0gTXVsdGljYXN0IC0gUmVxdWVzdCAvIFJlc3BvbnNlIExheWVyLCBwYWdlIDY3LCB0b3AN Cg0KSGVsbG8gQWNoaW0sDQoNCihzZWUgYWxzbyBteSByZXNwb25zZSB0byBKaW0pDQpVc2luZyB0 aGUgVURQIHBvcnQgbnVtYmVyIHRvIGRldGVjdCBhIG11bHRpY2FzdCByZXF1ZXN0IHZzIGEgdW5p Y2FzdCByZXF1ZXN0IHNvdW5kcyBsaWtlIGEgZ29vZCB1c2UgY2FzZS4gSnVzdCBjdXJpb3VzIC0g SSBhc3N1bWUgdGhlIHNlY3VyaXR5IGFzcGVjdCByZXF1aXJlbWVudHMgb2YgUkZDIDcyNTIgYXJl IHRha2VuIGNhcmUgb2YgaW4gdGhpcyB1c2UgY2FzZT8NCg0KVGhhdCBpcywgYSBwcm9wZXIgY2xp ZW50IHNlbmRzIGl0cyBtdWx0aWNhc3QgcmVxdWVzdHMgYWx3YXlzIHRvIHBvcnQgOjk5OTkgYW5k IHRoZSBzZXJ2ZXIgdHJlYXRzIHRoZXNlIGFzIG11bHRpY2FzdCByZXF1ZXN0cyAoZS5nLiBvbmx5 IGFsbG93IHRoZSByZXF1ZXN0IGZvciBzcGVjaWZpYyByZXNvdXJjZXMpLg0KQSBtYWxpY2lvdXMg Y2xpZW50IG1heSBzZW5kcyBpdHMgbXVsdGljYXN0IHJlcXVlc3QgdG8gcG9ydCA6NTY4MyB0byBi eXBhc3MgdGhlIGFib3ZlIGNoZWNrcy4gSSBhc3N1bWUgdGhlIHNlcnZlciBkb2Vzbid0IHJlc3Bv bmQgdG8gdGhpcyByZXF1ZXN0LCBiZWNhdXNlIHRoZSBtdWx0aWNhc3QgYWRkcmVzcyBpcyBub3Qg Ym91bmQgdG8gcG9ydCA1NjgzIGJ1dCB0byBzYXkgOTk5OSBvbmx5Lg0KSWYgdGhlIENvQVAgc2Vy dmVyIGF0IHBvcnQgNTY4MyBjYW5ub3QgZGlzdGluZ3Vpc2ggYmV0d2VlbiB1bmljYXN0L211bHRp Y2FzdCB0aGF0IHdvdWxkIGJlIGEgYmFkIHNpdHVhdGlvbiBhbmQgdGhlIHNlY3VyaXR5IHJlcXVp cmVtZW50cyBvZiBSRkMgNzI1MiBhcmUgbm90IG1ldC4NCg0KRXNrbw0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZSA8Y29yZS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhh bGYgT2YgQWNoaW0gS3JhdXMNClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMSwgMjAyMCAyMjoyOA0K VG86IFRob21hcyBGb3NzYXRpIDx0aG8uaWV0ZkBnbWFpbC5jb20+OyBLbGF1cyBIYXJ0a2UgPGhh cnRrZUBwcm9qZWN0Y29vbC5kZT4NCkNjOiBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2Nv cmVdIFJGQyA3MjUyIC0gOC4yIC0gTXVsdGljYXN0IC0gUmVxdWVzdCAvIFJlc3BvbnNlIExheWVy LCBwYWdlIDY3LCB0b3ANCg0KSGksDQoNCj4+ICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0tLSsNCj4+IHwgICAgICAgICAgICAgICB8ICAgIHJlcXVlc3Qg ICAgX3xfICAgICAgICAgICAgICAgIHwNCj4+IHwgICAgICAgICAgICAgICB8ICAgICAgICAuLS0t PiAvICAgXCAgIDIyNC4wLjEuMTg3IHwNCj4+IHwgICAgICAgICAgICAgIF98XyAgICAgIC8gICAg ICBcX19fLyAtLS4gICA6OTk5OSAgIHwNCj4+IHwgMTkyLjE2OC4wLjEgLyAgIFwgLS0twrQgICAg ICAgICB8ICAgICAgXCAgICAgICAgICB8DQo+PiB8ICAgOjU0MzIxICAgIFxfX18vIDwtLS0uICAg ICAgIF98XyAgICAgLyAgcmV3cml0ZSB8DQo+PiB8ICAgICAgICAgICAgICAgfCAgICAgICAgXCAg ICAgLyAgIFwgPC3CtCAgICAgICAgICAgfA0KPj4gfCAgICAgICAgICAgICAgIHwgICAgICAgICBg LS0tIFxfX18vIDE5Mi4xNjguMC4xMDAgfA0KPj4gfCAgICAgICAgICAgICAgIHwgICAgcmVzcG9u c2UgICAgfCAgICAgICAgIDo1NjgzICAgfA0KPj4gKy0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKw0KPj4gICAgICAgIENsaWVudCAgICAgICAgICAgICAg ICAgICAgICAgICAgIFNlcnZlcg0KDQpOaWNlIGRpYWdyYW0uDQoNCj4gTm90IHN1cmUgd2h5IHlv dSB3b3VsZCBhbHNvIHdhbnQgdG8gcmV3cml0ZSB0aGUgdHJhbnNwb3J0IGVuZHBvaW50Pw0KDQpJ IHRyaWVkIHRvIGZvbGxvdyB0aGUgZGlzY3Vzc2lvbi4NClRoZSBpZGVhIHRvIGNoYW5nZSB0aGUg cG9ydCBhcyB3ZWxsIGVuYWJsZXMgamF2YSAoYW5kIEkgZ3Vlc3Mgc29tZSBtb3JlKSB0byBkaWZm ZXJlbnRpYXRlIGJldHdlZW4gbXVsdGljYXN0IGFuZCB1bmljYXN0IHJlcXVlc3RzLiBKaW0gYWxz byBtZW50aW9uZWQsIHRoYXQgaXQgZW5hYmxlcyB0aGUgdXNlIG9mIG11bHRpcGxlIHNlcnZlcnMg b24gdGhlIHNhbWUgaG9zdC4NCkkgaGF2ZSBub3QgZW5vdWdoIGV4cGVyaWVuY2Ugd2l0aCBtdWx0 aWNhc3QgaW4gZGlmZmVyZW50IGVudmlyb25tZW50cyB0byBzZWUsIGlmIHRoYXQgbWF5IGNhdXNl IG1vcmUgdHJvdWJsZSAoZS5nLiBmaXJld2FsbCBldGMuKS4gSSB3b3VsZCBndWVzcywgdGhhdCBz b21lICBpbXBsZW1lbnRhdGlvbnMgd2lsbCBqdXN0IG9mZmVyIHRoYXQgdmFyaWFudCwgYXQgbGVh c3QgYXMgY29uZmlndXJhYmxlIG9wdGlvbiAoSSB3b3VsZCB0cnkgZG8gc28gZm9yIENhbGlmb3Ju aXVtKS4NClNvIG15IGZhdm9yaXRlIGZvciBub3cgaXMganVzdCBpbXBsZW1lbnQgaXQgYW5kIHNl ZSwgd2hhdCB0aGUgdXNlcidzIGZlZWRiYWNrIHdpbGwgYmUuDQoNCklmIHRoYXQgaWRlYSBnZXRz IGRlY2xpbmVkIChtYXkgYmUgYnkgbmVnYXRpdmUgZmVlZGJhY2sgb2YgdXNlcnMpLCBJIHN0aWxs IHRoaW5rLCB0aGF0IHRoZXJlIGlzIGEgZGVtYW5kIGZvciBvdGhlciBtZWFucyB0byBkaXN0aW5n dWlzaCBiZXR3ZWVuIG11bHRpY2FzdCBhbmQgdW5pY2FzdCByZXF1ZXN0cy4gTWF5YmUsIGVpdGhl ciB0aGUgdXNhZ2Ugb2YgdGhlIHVyaS1ob3N0IG9wdGlvbiBvciBhIG5ldyBvcHRpb24gd2lsbCBo ZWxwLg0KDQpUaGlzIG1heWJlIGNvbnNpZGVyZWQgYXMgInRvbyBwcmFnbWF0aWNhbGx5IiwgYnV0 IG9uIHRoZSBvdGhlciBzaWRlIEkgYWxzbyBkb24ndCBzZWUgdGhlICJncmVhdCBiZW5lZml0IiBp biBpbnNpc3Qgbm90IHRvIGNoYW5nZSB0aGUgcG9ydC4NCg0KYmVzdCByZWdhcmRzDQpBY2hpbQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBt YWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY29yZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0K From nobody Fri Apr 3 08:46:46 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB903A1952 for ; Fri, 3 Apr 2020 08:46:42 -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 n4VAfph6cSwf for ; Fri, 3 Apr 2020 08:46:40 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 0983B3A1943 for ; Fri, 3 Apr 2020 08:46:39 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id e5so9792794edq.5 for ; Fri, 03 Apr 2020 08:46:39 -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=N2iWSsVa4ye2RF1kh+ucTx1PT0Dcm9yb8AjtPvfBmgs=; b=sjmY7rM/nyITxazvECOy0XjDTS+YIQWiFmjjd2gVq41IceOgEhFUF+HFj0RSorSvXs iTez+U9Ot1VA5/wvGml0S6X1/orrJpr2lmXIkIf+OtE9xmuNxJU+hJjUeAGB5qjNqGDL Jf2afppauiMK/rrPP1WP3387Uq9An/bshZ3wl0kM7H3T2D2ZjnWPZNWkzXeD1PwMLXLx XJm/lnZAkC3fonjC8Qy63o4jKyt5tRK0usFw+LAj3fZC+ctGMJEb2ygZ1z7V9S9Oj71l mAkxZ4lymjBEI/bv06luiMNu4ppqaitk21lo3qWIhp0MjVOt6udHe6/fbcynQS5DXZZW /ksg== 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=N2iWSsVa4ye2RF1kh+ucTx1PT0Dcm9yb8AjtPvfBmgs=; b=GBJGXSo2oBKZ+8xUlsj4CH6zi+j3lOKkbFCwDUTqIqs4Zvo+l7SaEdhxEiU6yg+ab5 j9adtRalfL4Z3nNmbpSWdsqOmmYdP4I8g2azzY0pdtTMJvk5vZR1sbFtm2raCPccWvK6 uXhgo5N3Ejv5DlC1YdnVIJdr8fjVchLxOluIxfNS2GpUHT9Uyehhwr9kBySojryBjLDx 5iUX1wo9Cg0AINDZ7FNU/NTr3NLhvlz0dWA/UtCCSzro1MygVFNmJlRMgNCM33p+c/pn z/Ce+x4F5D5aml4WRL3wjoI9r9ZMDrQB5/edGoEmVgI4EAAskfAds/jLZK+n9okE2iEJ Ek6w== X-Gm-Message-State: AGi0PubQvMOn2qq/Gg6QlJnt8J8D2gmmcKS4Foa5LRHHYUnKyPgbINu2 PjQ6BsMHMRI/aJ+EYGuImiHmbCdIRo7R+1oMqRM= X-Google-Smtp-Source: APiQypIeElTqj8GYwzezp68Df85Wvv6XnzNBMbXlX1Qbb+ptoYqKEjSV/suxFTe+u4uFXL6p2nvbtUn7AbIducjQsNA= X-Received: by 2002:a50:cc87:: with SMTP id q7mr8151581edi.96.1585928798349; Fri, 03 Apr 2020 08:46:38 -0700 (PDT) MIME-Version: 1.0 References: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> In-Reply-To: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> From: Abhijan Bhattacharyya Date: Fri, 3 Apr 2020 21:16:22 +0530 Message-ID: To: Christer Holmberg Cc: Thomas Fossati , core Content-Type: multipart/alternative; boundary="000000000000aa2e7605a264d2a5" Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 03 Apr 2020 15:46:43 -0000 --000000000000aa2e7605a264d2a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable HI Thomas, Thank you for your response. It helps understand the spec better. Hi Christer, Thanks for sharing the slides. So, if both the nodes host a resource which the other one is interested in, then, following the diagram in the slides, Device #2 should also post and create a resource and Device #1 should do a GET. Then both the devices can access each other, right? Can we then think of a situation when the RD and the TURN server merges together? One thing that I find special in this case than usual P2P establishment scenario is that, the TURN server has the responsibility of notifying the URI as well and not only the ip:port mapping. This is because of the RESTful semantics. Can we find any document elaborating these slides? And, is there any opensource implementation available of this proposal please? A bit of more inputs: We proposed a delay-sensitive time-series streaming mechanism by extending CoAP and presented in last Bangkok IETF. We called it A-REaLiST (Adaptive RESTful Real-time Live Streaming for Things). The draft is here: https://tools.ietf.org/html/draft-bhattacharyya-core-a-realist-00 The relevant research work was published in 2018 Globecom workshop: Abhijan Bhattacharyya, Suvrat Agrawal, Hemant Kumar Rath, Arpan Pal: "Improving Live-Streaming Experience for Delay-Sensitive IoT Applications: A RESTful Approach" (https://ieeexplore.ieee.org/document/8644521). We then further extended this solution for a two way communication for tele-medicine use case under constrained environment and published in 2019 EuCNC: Abhijan Bhattacharyya, Suvrat Agrawal, Hemant Kumar Rath, Arpan Pal: "Towards Democratizing E-health Under Constrained ICT Infrastructure Through =E2=80=98A- REaLiST=E2=80=99 Solution" ( https://ieeexplore.ieee.org/abstract/document/8802034/) A standardized mechanism to establish P2P connection would be beneficial in such a case. Regards, Abhijan On Fri, Apr 3, 2020 at 12:11 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > If you are interested in P2P, you might be interested in the thin-ICE > presentation that was given at the T2TRG meeting in Singapore: > > > > > https://github.com/t2trg/2019-11-singapore/blob/master/slides/44-thin-ICE= -151119-Singapore.pdf > > > > Regards, > > > > Christer > > > > > > *From: *core on behalf of Abhijan Bhattacharyya < > abhijan.bhattacharyya@gmail.com> > *Date: *Thursday, 2 April 2020 at 11.04 > *To: *Thomas Fossati > *Cc: *core > *Subject: *Re: [core] Using CoAP for P2P > > > > Hi Thomas, > > What I am looking at is a situation where I have two nodes each having a > time-varying resource. Both want to push the states of the respective > resource to the other node within a common application context. However, > these exchanges are naturally asynchronous. May be I can think of it more > like a chat. A typical client-server or observe relationship will not ser= ve > the purpose. Actually both should have a client and server instance runni= ng > under a common application. Then either each can *observe* the other, or > can *post* the other. That is how we can do that without a central server= . > > > > If my understanding is right, according to CoAP specification, the nodes > which can have both server and client (to the origin server) are > "intermediary" nodes. The only example of "intermediary" considered in th= e > spec is the proxy node. But, anyway the situation in this case does not > concern with intermediary. Both are origin server and end-client together= . > > > > Is there any standardized mechanism to handle this situation? > > > > Thanks. > > > > On Wed, Apr 1, 2020 at 5:32 PM Thomas Fossati > wrote: > > Hi Abhijan, > > On 01/04/2020, 12:31, Abhijan Bhattacharyya < > abhijan.bhattacharyya@gmail.com> wrote: > > Is there any standardized mechanism to use CoAP for a P2P connection? > > Not sure whether RFC 7650 would fit your needs but worth having a > look -- if you haven't already. > > cheers > -- > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > > > > -- > > Regards, > > Abhijan Bhattacharyya, > > *Technologist by profession [IoT| Internet Protocols| 5G]* > --=20 Regards, Abhijan Bhattacharyya, *Technologist by profession [IoT| Internet Protocols| 5G]* --000000000000aa2e7605a264d2a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
HI Thomas,
Thank you for y= our response. It helps understand the spec better.

Hi Christer,
Thanks for sharing the slides.
So, if bot= h the nodes host a resource which the other one is interested in, then, fol= lowing the diagram in the slides, Device #2 should also post and create a r= esource and Device #1 should do a GET. Then both the devices can access eac= h other, right? Can we then think of a situation when the RD and the TURN s= erver merges together?

One thing that I find speci= al in this case than usual P2P establishment scenario is that, the TURN ser= ver has the responsibility=C2=A0of notifying the URI as well and not only t= he ip:port mapping. This is because of the RESTful semantics.
Can we find any document elaborating these slides?=C2=A0
<= div>And, is there any opensource=C2=A0implementation available of this prop= osal please?

A bit of more inputs:
We pr= oposed a delay-sensitive time-series streaming mechanism by extending CoAP = and presented=C2=A0in last Bangkok IETF. We called it A-REaLiST (Adaptive R= ESTful Real-time Live Streaming for Things).=C2=A0
The relevant research work was published in 2018 Globecom= workshop:=C2=A0Abhijan Bhattacharyya, Suvrat Agrawal, Hemant Kumar Rath, A= rpan Pal: "Improving Live-Streaming Experience for Delay-Sensitive IoT= Applications: A RESTful Approach" (https://ieeexplore.ieee.org/document/8644521).

We then further extended this solution for a two wa= y communication for tele-medicine use case under constrained environment an= d published in 2019 EuCNC:=C2=A0Abhijan Bhattacharyya, Suvrat Agrawal, Hema= nt Kumar Rath, Arpan Pal: "Towards Democratizing E-health Under Constr= ained ICT Infrastructure Through =E2=80=98A- REaLiST=E2=80=99 Solution"= ; (https= ://ieeexplore.ieee.org/abstract/document/8802034/)

=
A standardized mechanism to establish P2P connection would be benefici= al in such a case.

Regards,
Abhijan

<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 3, 2020 at 12:11 AM Christ= er Holmberg <christer.= holmberg@ericsson.com> wrote:

Hi,

=C2=A0

If you are interested in P2P, y= ou might be interested in the thin-ICE presentation that was given at the T= 2TRG meeting in Singapore:

=C2=A0

https://github.com/t2trg/2019-11-singapore/blob/master/s= lides/44-thin-ICE-151119-Singapore.pdf

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: = core <core-bounces@ietf.org>= ; on behalf of Abhijan Bhattacharyya <abhijan.bhattacharyya@gmail.com><= br> Date: Thursday, 2 April 2020 at 11.04
To: Thomas Fossati <Thomas.Fossati@arm.com>
Cc: core <core= @ietf.org>
Subject: Re: [core] Using CoAP for P2P

=C2=A0

Hi Thomas,

What I am looking at is a situation where I have two= nodes each having a time-varying resource. Both want=C2=A0to push the stat= es of the respective resource to the other node within a common application= context. However, these exchanges are naturally asynchronous. May be I can think of it more like a chat. A typic= al client-server or observe relationship will not serve the purpose. Actual= ly both should have a client and server instance running under a common app= lication. Then either each can *observe* the other, or can *post* the other. That is how we can do that without a c= entral server.

=C2=A0

If my understanding is right, according to CoAP spec= ification, the nodes which can have both server and client (to the origin= =C2=A0server) are "intermediary" nodes. The only example of "= ;intermediary" considered in the spec is the proxy node. But, anyway the situation in this case does not concern with intermediary.= Both are origin server and end-client together.

=C2=A0

Is there any standardized mechanism to handle this s= ituation?

=C2=A0

Thanks.

=C2=A0


=C2=A0

--

Regards,

Abhijan Bhattacharyya,

Technologist by profession [IoT| Internet Pr= otocols| 5G]



--
Regards,
Abhijan Bhattacharyya,
Technolo= gist by profession [IoT| Internet Protocols| 5G]
--000000000000aa2e7605a264d2a5-- From nobody Fri Apr 3 10:54:19 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57F63A097D for ; Fri, 3 Apr 2020 10:54:17 -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 1I0L8NeUK-CU for ; Fri, 3 Apr 2020 10:54:15 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAABD3A0979 for ; Fri, 3 Apr 2020 10:54:14 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 3 Apr 2020 10:54:08 -0700 From: Jim Schaad To: 'Esko Dijk' CC: References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> <02ec5628-3f7d-ff5d-620c-c0a90a4b89b0@gmx.net> <020701d60907$fb3ba720$f1b2f560$@augustcellars.com> In-Reply-To: Date: Fri, 3 Apr 2020 10:54:07 -0700 Message-ID: <02c601d609e0$e0afcbf0$a20f63d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIXVeiVC1e4HIxpxUNqDgp/ppWwxwLeBdy3AlRjDEICXv5oEAIsRnhBAgGYZE4CNTatAQF2e0MvAkUv4JkCiP5R4AEu4xDAAWkjoBUCf5lrcgGypwu/pwzydmA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top 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, 03 Apr 2020 17:54:18 -0000 -----Original Message----- From: Esko Dijk =20 Sent: Friday, April 3, 2020 5:38 AM To: Jim Schaad ; 'Achim Kraus' = ; 'Thomas Fossati' ; 'Klaus = Hartke' Cc: core@ietf.org Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response = Layer, page 67, top Hello Jim, Could you clarify your point further?=20 - what is a bad idea - having a dedicated port with dedicated for = handling multicast requests? Or the subsequent "internal routing" of = the request to the unicast server at a different port? Or both? [JLS] I think it is a bad idea to use the port number as a means of = distinguishing multicast and unicast message. If you do something = like this completely internal to your own code, then it is an = implementation detail but would not map to any type of text for an IETF = document. - what is a "multicast channel" , do you mean an endpoint bound to a = multicast address ? [JLS] I use the word channel because it maps from my code base in many = ways. A "multicast channel" would map to an endpoint bound to a = pair. An analogy for those of us who are = really old would be to consider UHF and VHF on your TV to be different = multicast addresses, but you still need to choose the channel number = (port number) in order to get a flow of information that is usable. The = analogy of course breaks down because you cannot send information back = to the TV stations. > some resources may only want to be on a single multicast address even=20 > if the server is listening on multiple unicast addresses Sure, you can also have a dedicated server on say port :9999 that = listens to multicast destination addresses only, because it is bound = only to a multicast address not a unicast address. This dedicated server = can then handle resources that only are to be accessed via multicast. But in this case, there's no "internal routing" needed to another server = inside the node because the resource is only hosted at say port :9999. [JLS] You can have a dedicated server on say that = lists for multicast traffic. You always have the address and port as a = pair. =20 > The IP address is different for a multicast vs a unicast message=20 > received at the server. This needs to be the distinction But the case the Achim indicated is that the server may not be able to = detect whether a request came in via unicast of multicast. So this = cannot be the distinction, e.g. in the following case: 1) CoAP server at port 5683 is bound to unicast address U 2) at same node, same CoAP server at port 5683 is bound to multicast = address M [JLS] If this is really true, and I am not sure that I believe that to = be the case, then the JAVA library is completely broken and needs to get = fixed. The fast look that I had at the JAVA library looks like you = need to create a distinct socket for every pair that you = are dealing with. I think that should give you all of the info that you = need, but like I said, I have not done the JAVA programming itself. Now in this case if a request comes in via multicast group M destined = to port 5683, the server handling this cannot tell whether it was = unicast or multicast. And if a unicast request comes in to destination = address U and port 5683, the server cannot tell also whether that was = unicast or multicast. [JLS] What is the address that is associated with the port number? You = cannot have a bare port number you also must have an IP address. The IP = address is how you distinguish unicast/multicast. [JLS] Jim By setting it up like this instead that problem is avoided: 1) CoAP server at port 5683 is bound to unicast address U 2) at same node, same CoAP server at port 9999 is bound to multicast = address M Then the server at port 5683 treats everything as unicast. = (Because it is not bound to a multicast address, it won't receive any = multicast requests directly.) And the server at port 9999 treats = everything as multicast. (And this endpoint 9999 handles most requests = by internally redirecting to server :5683, but only for those resources = where multicast is allowed. Some request for multicast-only resources it = can handle itself directly.) So the above "workaround" seems handy for cases where a server at one = specific UDP cannot itself determine the endpoint the request came in = from (could be either multicast like M or unicast like U). @Achim maybe you could comment if I've understood your use case = properly. To me the above seems more secure than trusting that a client = will include a "This is multicast" CoAP Option in an honest way, which = could easily be misused. thanks Esko -----Original Message----- From: Jim Schaad Sent: Thursday, April 2, 2020 18:02 To: Esko Dijk ; 'Achim Kraus' = ; 'Thomas Fossati' ; 'Klaus = Hartke' Cc: core@ietf.org Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response = Layer, page 67, top Esko, That idea strikes me as a very bad idea. If you build your code on = this basis you will fall over the first time you come across a multicast = channel which uses the same port as the unicast server. The IP address = is different for a multicast vs a unicast message received at the = server. This needs to be the distinction as well as the fact that some = resources may only want to be on a single multicast address even if the = server is listening on multiple unicast addresses. Jim -----Original Message----- From: core On Behalf Of Esko Dijk Sent: Thursday, April 2, 2020 1:23 AM To: Achim Kraus ; Thomas Fossati = ; Klaus Hartke Cc: core@ietf.org Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response = Layer, page 67, top Hello Achim, (see also my response to Jim) Using the UDP port number to detect a multicast request vs a unicast = request sounds like a good use case. Just curious - I assume the = security aspect requirements of RFC 7252 are taken care of in this use = case? That is, a proper client sends its multicast requests always to port = :9999 and the server treats these as multicast requests (e.g. only allow = the request for specific resources). A malicious client may sends its multicast request to port :5683 to = bypass the above checks. I assume the server doesn't respond to this = request, because the multicast address is not bound to port 5683 but to = say 9999 only. If the CoAP server at port 5683 cannot distinguish between = unicast/multicast that would be a bad situation and the security = requirements of RFC 7252 are not met. Esko -----Original Message----- From: core On Behalf Of Achim Kraus Sent: Wednesday, April 1, 2020 22:28 To: Thomas Fossati ; Klaus Hartke = Cc: core@ietf.org Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response = Layer, page 67, top Hi, >> +---------------+ +-----------------+ >> | | request _|_ | >> | | .---> / \ 224.0.1.187 | >> | _|_ / \___/ --. :9999 | >> | 192.168.0.1 / \ ---=C2=B4 | \ | >> | :54321 \___/ <---. _|_ / rewrite | >> | | \ / \ <-=C2=B4 | >> | | `--- \___/ 192.168.0.100 | >> | | response | :5683 | >> +---------------+ +-----------------+ >> Client Server Nice diagram. > Not sure why you would also want to rewrite the transport endpoint? I tried to follow the discussion. The idea to change the port as well enables java (and I guess some more) = to differentiate between multicast and unicast requests. Jim also = mentioned, that it enables the use of multiple servers on the same host. I have not enough experience with multicast in different environments to = see, if that may cause more trouble (e.g. firewall etc.). I would guess, = that some implementations will just offer that variant, at least as = configurable option (I would try do so for Californium). So my favorite for now is just implement it and see, what the user's = feedback will be. If that idea gets declined (may be by negative feedback of users), I = still think, that there is a demand for other means to distinguish = between multicast and unicast requests. Maybe, either the usage of the = uri-host option or a new option will help. This maybe considered as "too pragmatically", but on the other side I = also don't see the "great benefit" in insist not to change the port. best regards Achim _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Sat Apr 4 05:23:17 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1883A0B5D for ; Sat, 4 Apr 2020 05:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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 jtkKJLlaLa7Z for ; Sat, 4 Apr 2020 05:23:15 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2078.outbound.protection.outlook.com [40.107.21.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 81D603A0B41 for ; Sat, 4 Apr 2020 05:23:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bnXJ6c6etLiuzQ04lsxQ6uYyR3/ayImCQ9nzUwOSdkoXiQ3H49ACMx2p79Uy8+QYmP9Q65pOJJ4fGc1gyW6Wycocdg0Hx2Q5KCwaAjh1gbbZIrDj4vveRzsvyrEhGOH8Rs+8cPvdOGJasQFe0w8pkByRVd8/ishBjdc9r2lo82PfYcJTAj1mVqVBnO0r6HWeAF49qeDRFpKzPNMqskquW17fS9Q9aSA2kbJzsaw3cDcBsV4e8fOqUcBnBjg3Yb70GPt0kMvFwnYtxE7WGEfYCrNwf10mGKowIlt6T/WjYMRf4iqeKY/qBOX7S/q0RDPkKcmTjAyWO4tp1tP+lytbMw== 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=wnxKx4b2WrPnSlR3eTop9ua7nfgLitlPyEAS3GmJHyY=; b=V8iJO9S4BccSs4ft+BBozi0J2C9Zfy5MQao+TzMVDOEJiqWfWDhdxaQbEnQ3FAtGUvzH1ljg4n+4v+6hpAAfpA3dDCI9loml4+DtPfNXbb22TNAsKTWjd6bzqdUq2BC/0op5kQiCrJv1w9lDAxXdrEqHynqwK0+n/3NNL8pqwI3qpXCAccN4aoGn74dxOCwJyrZrBtnTcvot4UVQCc0iPoPBYpNbDF7+lon92/s2La4VS0fn5oVpz6BiBhMorKB9aq7w3kMi60DMALp1ZWGVK/wC4grfwRK7YQtQAIHhZFkAhEnBMfDKq5In5gsJ5uitZ+5n2cbPZCGWX9RDe/SXnw== 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=wnxKx4b2WrPnSlR3eTop9ua7nfgLitlPyEAS3GmJHyY=; b=N9a3wuk1A0L/Q4o8ZTK2wWyccgxq1s+Xn5DHANkv2mi1+p5dYEheWXWmzE5fr6I3UHopSPIP/ae80lZLZkVFYfJO3srd42bY/SJiKsUUnnCAVeSj7/ZgvO3LKetSAFZxQd6onxFbJyZ3iwBlCCHZpWYslRW3wqZs/wNWOGRHKYk= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (52.134.82.159) by AM0PR07MB5139.eurprd07.prod.outlook.com (20.178.19.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.11; Sat, 4 Apr 2020 12:23:11 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512%7]) with mapi id 15.20.2900.012; Sat, 4 Apr 2020 12:23:11 +0000 From: Christer Holmberg To: Abhijan Bhattacharyya CC: Thomas Fossati , core Thread-Topic: [core] Using CoAP for P2P: thin-ICE Thread-Index: AQHWCnvOvRwVXrVfdU6sUF31AU5OKA== Date: Sat, 4 Apr 2020 12:23:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3e27ee12-116f-499c-5ef9-08d7d892f105 x-ms-traffictypediagnostic: AM0PR07MB5139: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03630A6A4A x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(376002)(39860400002)(396003)(136003)(346002)(8676002)(66556008)(26005)(66446008)(66574012)(76116006)(91956017)(54906003)(5660300002)(186003)(66476007)(316002)(6506007)(71200400001)(66946007)(6916009)(53546011)(44832011)(966005)(64756008)(86362001)(478600001)(6512007)(33656002)(36756003)(6486002)(8936002)(81166006)(2906002)(81156014)(4326008)(2616005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XMbZB/WsGlQ2Q/av8p9clVszYnn7PNCq5pAZujKENlNeUZe7ST5XAxJKTqy6jOpP+W+QcTfPgHydLp+YhrmJTsOJLLftl+F/0INw5afZjkuDUS6h+PaI80fBjxPKrINl01cUQNL7hzHxDXgb67M9gyfyfNCUkBB1CwzoawhKceVPiqXZSZKkM8cgbs8h6x5UWJxO9RoHTPcxWDwL0Oa0oTRbZ+eCahPMO8Nwn0ck1d89VU5Y4Ja02JnIbQoXD6bLXpe8toewNo0toavhNri1/m+9oS54mcFZy+Cf+P0wYpZ5yzfQC/Fz03M3hSgOKDFqVgT/S0bd5SjxgSVs7ntIbihyKzKGXa5wZgtllyCTqiuH0Mi3YP9FtanV6OCNX3TtBx/oO6T95JGzI8TKW278/591rGMiSSQGmrRuZiZTSjOgS6O0aiX/9ipQqF01jhAXUgf2YZMvI8xKdVJrLE/AdXLYXG4CKvQ7fzZekSlPNfQ+puOHz9y184VwJw9YOgFXZvsSEGB1LHHfvvxfrRHSVQ== x-ms-exchange-antispam-messagedata: a/R78HLCm7dJsHcjju0PwFa62Q+wQalNNpx9jeI3wkNchlr+h/ac/BHzDxMovaiXUubYxl3n9a0YFIL3kIwf5kXwRNoJ7F6NyEdsJ6HXAwXVB4iE/BxF2uozCIs1lGXYaVj0EOr4vhJaRiZoNGFnJg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_D920651491F44DDB8ED0C609F3DD6582ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3e27ee12-116f-499c-5ef9-08d7d892f105 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2020 12:23:11.5311 (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: +iuhegPVyWmwRBdSB3ChvqEmlXQ3VIfNQeD4d4TqURAGTLlo9zHE3T9guRb/WIz6bcp0acYOOG8fM0iT1BvQLmm8LOI5FpfdqJj//deroTA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5139 Archived-At: Subject: Re: [core] Using CoAP for P2P: thin-ICE 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, 04 Apr 2020 12:23:17 -0000 --_000_D920651491F44DDB8ED0C609F3DD6582ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj4gVGhhbmtzIGZvciBzaGFyaW5nIHRoZSBzbGlkZXMuDQo+IFNvLCBpZiBib3RoIHRo ZSBub2RlcyBob3N0IGEgcmVzb3VyY2Ugd2hpY2ggdGhlIG90aGVyIG9uZSBpcyBpbnRlcmVzdGVk IGluLCB0aGVuLCBmb2xsb3dpbmcgdGhlIGRpYWdyYW0gaW4gdGhlIHNsaWRlcywgRGV2aWNlICMy IHNob3VsZA0KPiBhbHNvIHBvc3QgYW5kIGNyZWF0ZSBhIHJlc291cmNlIGFuZCBEZXZpY2UgIzEg c2hvdWxkIGRvIGEgR0VULiBUaGVuIGJvdGggdGhlIGRldmljZXMgY2FuIGFjY2VzcyBlYWNoIG90 aGVyLCByaWdodD8NCg0KQ29ycmVjdC4NCg0KKE9mIGNvdXJzZSwgd2hlbiBEZXZpY2UgIzEgaGFz IHJlY2VpdmVkIHRoZSBHRVQgZnJvbSBEZXZpY2UgIzIsIERldmljZSAjMSBjb3VsZCB0cnkgdG8g cmVhY2ggRGV2aWNlICMyIHVzaW5nIHRoZSBhZGRyZXNzIGZyb20gd2hlcmUgdGhlIEdFVCB3YXMg cmVjZWl2ZWQuIFRoYXQgaXMgcmVmZXJyZWQgdG8gYXMgYSBwZWVyIHJlZmxleGl2ZSBjYW5kaWRh dGUgaW4gSUNFLCBidXQgd2UgaGF2ZSBub3QgbG9va2VkIGludG8gdGhhdCBpbiBkZXRhaWwgeWV0 LikNCg0KPiBDYW4gd2UgdGhlbiB0aGluayBvZiBhIHNpdHVhdGlvbiB3aGVuIHRoZSBSRCBhbmQg dGhlIFRVUk4gc2VydmVyIG1lcmdlcyB0b2dldGhlcj8NCg0KTm90IHN1cmUgd2hhdCB5b3UgbWVh biBiZSDigJxtZXJnZXMgdG9nZXRoZXLigJ0sIGJ1dCBtdWx0aXBsZSBkZXZpY2VzIGNhbiBmb3Ig c3VyZSB1c2UgdGhlIHNhbWUgUkQgYW5kL29yIFQtU1RVTiBzZXJ2ZXIuIFRoYXQgaXMgaG93IGl0 IG5vcm1hbGx5IHdvcmtzLg0KDQooV2hlbiB5b3Ugc2F5IFRVUk4gc2VydmVyLCBJIGFzc3VtZSB5 b3UgcmVmZXIgdG8gdGhlIFQtU1RVTiBzZXJ2ZXIuIFRoZSBzbGlkZXMgZG9u4oCZdCBkZXNjcmli ZSB0aGUgdXNhZ2Ugb2YgYSBUVVJOIHNlcnZlci9yZWxheSwgYnV0IHRoYXQgd291bGQgZm9yIHN1 cmUgYmUgcG9zc2libGUpDQoNCj5PbmUgdGhpbmcgdGhhdCBJIGZpbmQgc3BlY2lhbCBpbiB0aGlz IGNhc2UgdGhhbiB1c3VhbCBQMlAgZXN0YWJsaXNobWVudCBzY2VuYXJpbyBpcyB0aGF0LCB0aGUg VFVSTiBzZXJ2ZXIgaGFzIHRoZSByZXNwb25zaWJpbGl0eSBvZiBub3RpZnlpbmcgdGhlIFVSSSBh cyB3ZWxsIGFuZA0KPm5vdCBvbmx5IHRoZSBpcDpwb3J0IG1hcHBpbmcuIFRoaXMgaXMgYmVjYXVz ZSBvZiB0aGUgUkVTVGZ1bCBzZW1hbnRpY3MuDQoNCk5vdCBzdXJlIEkgdW5kZXJzdGFuZC4gVGhl IFQtU1RVTiBzZXJ2ZXIgb25seSBwcm92aWRlcyB0aGUgcHVibGljIElQIGFkZHJlc3M6cG9ydCBv ZiB0aGUgZGV2aWNlLiBUaGUgZGV2aWNlIGNyZWF0ZXMgdGhlIFVSSS4NCg0KPkNhbiB3ZSBmaW5k IGFueSBkb2N1bWVudCBlbGFib3JhdGluZyB0aGVzZSBzbGlkZXM/DQoNCkF0IHRoZSBtb21lbnQg dGhlcmUgaXMgbm8gSUVURiBkcmFmdCBkZXNjcmliaW5nIHRoaXMsIG1vc3RseSBiZWNhdXNlIHNv IGZhciBwZW9wbGUgaGF2ZW7igJl0IHNob3duIHRvbyBtdWNoIGludGVyZXN0IGluIGl0Lg0KDQpJ dCBpcyBkZXNjcmliZWQgaW4gbXkgdGhlc2lzLCBzbyBpZiB5b3Ugd2FudCBJIGNhbiBnaXZlIHlv dSB0aGUgbGluayBmb3IgdGhhdCA6KQ0KDQo+QW5kLCBpcyB0aGVyZSBhbnkgb3BlbnNvdXJjZSBp bXBsZW1lbnRhdGlvbiBhdmFpbGFibGUgb2YgdGhpcyBwcm9wb3NhbCBwbGVhc2U/DQoNCkN1cnJl bnRseSBub3QsIHVuZm9ydHVuYXRlbHksIGFzIGZhciBhcyBJIGtub3cuDQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQoNCg0KDQoNCk9uIEZyaSwgQXByIDMsIDIwMjAgYXQgMTI6MTEgQU0gQ2hyaXN0 ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KSWYgeW91IGFyZSBpbnRl cmVzdGVkIGluIFAyUCwgeW91IG1pZ2h0IGJlIGludGVyZXN0ZWQgaW4gdGhlIHRoaW4tSUNFIHBy ZXNlbnRhdGlvbiB0aGF0IHdhcyBnaXZlbiBhdCB0aGUgVDJUUkcgbWVldGluZyBpbiBTaW5nYXBv cmU6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS90MnRyZy8yMDE5LTExLXNpbmdhcG9yZS9ibG9iL21h c3Rlci9zbGlkZXMvNDQtdGhpbi1JQ0UtMTUxMTE5LVNpbmdhcG9yZS5wZGY8aHR0cHM6Ly9wcm90 ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az03YTQzMmRlYS0yNjk3MjA5OC03YTQzNmQ3MS04Njg1 OWIyOTMxYjMtYTkxZjJkMmVkOTlkYTk1MSZxPTEmZT1iMzI5YjA4OC1kNmQwLTQ0NDYtOGRkZi01 NTg5YTllM2FiY2QmdT1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZ0MnRyZyUyRjIwMTktMTEt c2luZ2Fwb3JlJTJGYmxvYiUyRm1hc3RlciUyRnNsaWRlcyUyRjQ0LXRoaW4tSUNFLTE1MTExOS1T aW5nYXBvcmUucGRmPg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IGNvcmUgPGNv cmUtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVo YWxmIG9mIEFiaGlqYW4gQmhhdHRhY2hhcnl5YSA8YWJoaWphbi5iaGF0dGFjaGFyeXlhQGdtYWls LmNvbTxtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQGdtYWlsLmNvbT4+DQpEYXRlOiBUaHVy c2RheSwgMiBBcHJpbCAyMDIwIGF0IDExLjA0DQpUbzogVGhvbWFzIEZvc3NhdGkgPFRob21hcy5G b3NzYXRpQGFybS5jb208bWFpbHRvOlRob21hcy5Gb3NzYXRpQGFybS5jb20+Pg0KQ2M6IGNvcmUg PGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtjb3Jl XSBVc2luZyBDb0FQIGZvciBQMlANCg0KSGkgVGhvbWFzLA0KV2hhdCBJIGFtIGxvb2tpbmcgYXQg aXMgYSBzaXR1YXRpb24gd2hlcmUgSSBoYXZlIHR3byBub2RlcyBlYWNoIGhhdmluZyBhIHRpbWUt dmFyeWluZyByZXNvdXJjZS4gQm90aCB3YW50IHRvIHB1c2ggdGhlIHN0YXRlcyBvZiB0aGUgcmVz cGVjdGl2ZSByZXNvdXJjZSB0byB0aGUgb3RoZXIgbm9kZSB3aXRoaW4gYSBjb21tb24gYXBwbGlj YXRpb24gY29udGV4dC4gSG93ZXZlciwgdGhlc2UgZXhjaGFuZ2VzIGFyZSBuYXR1cmFsbHkgYXN5 bmNocm9ub3VzLiBNYXkgYmUgSSBjYW4gdGhpbmsgb2YgaXQgbW9yZSBsaWtlIGEgY2hhdC4gQSB0 eXBpY2FsIGNsaWVudC1zZXJ2ZXIgb3Igb2JzZXJ2ZSByZWxhdGlvbnNoaXAgd2lsbCBub3Qgc2Vy dmUgdGhlIHB1cnBvc2UuIEFjdHVhbGx5IGJvdGggc2hvdWxkIGhhdmUgYSBjbGllbnQgYW5kIHNl cnZlciBpbnN0YW5jZSBydW5uaW5nIHVuZGVyIGEgY29tbW9uIGFwcGxpY2F0aW9uLiBUaGVuIGVp dGhlciBlYWNoIGNhbiAqb2JzZXJ2ZSogdGhlIG90aGVyLCBvciBjYW4gKnBvc3QqIHRoZSBvdGhl ci4gVGhhdCBpcyBob3cgd2UgY2FuIGRvIHRoYXQgd2l0aG91dCBhIGNlbnRyYWwgc2VydmVyLg0K DQpJZiBteSB1bmRlcnN0YW5kaW5nIGlzIHJpZ2h0LCBhY2NvcmRpbmcgdG8gQ29BUCBzcGVjaWZp Y2F0aW9uLCB0aGUgbm9kZXMgd2hpY2ggY2FuIGhhdmUgYm90aCBzZXJ2ZXIgYW5kIGNsaWVudCAo dG8gdGhlIG9yaWdpbiBzZXJ2ZXIpIGFyZSAiaW50ZXJtZWRpYXJ5IiBub2Rlcy4gVGhlIG9ubHkg ZXhhbXBsZSBvZiAiaW50ZXJtZWRpYXJ5IiBjb25zaWRlcmVkIGluIHRoZSBzcGVjIGlzIHRoZSBw cm94eSBub2RlLiBCdXQsIGFueXdheSB0aGUgc2l0dWF0aW9uIGluIHRoaXMgY2FzZSBkb2VzIG5v dCBjb25jZXJuIHdpdGggaW50ZXJtZWRpYXJ5LiBCb3RoIGFyZSBvcmlnaW4gc2VydmVyIGFuZCBl bmQtY2xpZW50IHRvZ2V0aGVyLg0KDQpJcyB0aGVyZSBhbnkgc3RhbmRhcmRpemVkIG1lY2hhbmlz bSB0byBoYW5kbGUgdGhpcyBzaXR1YXRpb24/DQoNClRoYW5rcy4NCg0KT24gV2VkLCBBcHIgMSwg MjAyMCBhdCA1OjMyIFBNIFRob21hcyBGb3NzYXRpIDxUaG9tYXMuRm9zc2F0aUBhcm0uY29tPG1h aWx0bzpUaG9tYXMuRm9zc2F0aUBhcm0uY29tPj4gd3JvdGU6DQpIaSBBYmhpamFuLA0KDQpPbiAw MS8wNC8yMDIwLCAxMjozMSwgQWJoaWphbiBCaGF0dGFjaGFyeXlhIDxhYmhpamFuLmJoYXR0YWNo YXJ5eWFAZ21haWwuY29tPG1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAZ21haWwuY29tPj4g d3JvdGU6DQo+IElzIHRoZXJlIGFueSBzdGFuZGFyZGl6ZWQgbWVjaGFuaXNtIHRvIHVzZSBDb0FQ IGZvciBhIFAyUCBjb25uZWN0aW9uPw0KDQpOb3Qgc3VyZSB3aGV0aGVyIFJGQyA3NjUwIHdvdWxk IGZpdCB5b3VyIG5lZWRzIGJ1dCB3b3J0aCBoYXZpbmcgYQ0KbG9vayAtLSBpZiB5b3UgaGF2ZW4n dCBhbHJlYWR5Lg0KDQpjaGVlcnMNCi0tDQoNCg0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBj b250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlh bCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBu b3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3Ig YW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRp dW0uIFRoYW5rIHlvdS4NCg0KDQotLQ0KUmVnYXJkcywNCkFiaGlqYW4gQmhhdHRhY2hhcnl5YSwN ClRlY2hub2xvZ2lzdCBieSBwcm9mZXNzaW9uIFtJb1R8IEludGVybmV0IFByb3RvY29sc3wgNUdd DQoNCg0KLS0NClJlZ2FyZHMsDQpBYmhpamFuIEJoYXR0YWNoYXJ5eWEsDQpUZWNobm9sb2dpc3Qg YnkgcHJvZmVzc2lvbiBbSW9UfCBJbnRlcm5ldCBQcm90b2NvbHN8IDVHXQ0K --_000_D920651491F44DDB8ED0C609F3DD6582ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcmlhbCBC bGFjayI7DQoJcGFub3NlLTE6MiAxMSAxMCA0IDIgMSAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4t bGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcw Ljg1cHQgMi4wY207fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkkiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jmd0 OyA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MgZm9yIHNoYXJpbmcgdGhlIHNs aWRlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBTbywgaWYgYm90aCB0aGUgbm9kZXMgaG9z dCBhIHJlc291cmNlIHdoaWNoIHRoZSBvdGhlciBvbmUgaXMgaW50ZXJlc3RlZCBpbiwgdGhlbiwg Zm9sbG93aW5nIHRoZSBkaWFncmFtIGluIHRoZSBzbGlkZXMsIERldmljZSAjMiBzaG91bGQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPmFsc28gcG9zdCBhbmQgY3JlYXRlIGEg cmVzb3VyY2UgYW5kIERldmljZSAjMSBzaG91bGQgZG8gYSBHRVQuDQo8L3NwYW4+VGhlbiBib3Ro IHRoZSBkZXZpY2VzIGNhbiBhY2Nlc3MgZWFjaCBvdGhlciwgcmlnaHQ/IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q29ycmVjdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PihPZiBjb3Vyc2UsIHdoZW4gRGV2aWNlICMxIGhhcyByZWNlaXZlZCB0aGUgR0VUIGZyb20gRGV2 aWNlICMyLCBEZXZpY2UgIzEgY291bGQgdHJ5IHRvIHJlYWNoIERldmljZSAjMiB1c2luZyB0aGUg YWRkcmVzcyBmcm9tIHdoZXJlIHRoZSBHRVQgd2FzIHJlY2VpdmVkLiBUaGF0IGlzIHJlZmVycmVk IHRvIGFzIGEgcGVlciByZWZsZXhpdmUgY2FuZGlkYXRlIGluIElDRSwgYnV0IHdlDQogaGF2ZSBu b3QgbG9va2VkIGludG8gdGhhdCBpbiBkZXRhaWwgeWV0Lik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZn dDsgQ2FuIHdlIHRoZW4gdGhpbmsgb2YgYSBzaXR1YXRpb24gd2hlbiB0aGUgUkQgYW5kIHRoZSBU VVJOIHNlcnZlciBtZXJnZXMgdG9nZXRoZXI/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYmUg 4oCcbWVyZ2VzIHRvZ2V0aGVy4oCdLCBidXQgbXVsdGlwbGUgZGV2aWNlcyBjYW4gZm9yIHN1cmUg dXNlIHRoZSBzYW1lIFJEIGFuZC9vciBULVNUVU4gc2VydmVyLiBUaGF0IGlzIGhvdyBpdCBub3Jt YWxseSB3b3Jrcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPihXaGVuIHlvdSBzYXkgVFVSTiBzZXJ2ZXIs IEkgYXNzdW1lIHlvdSByZWZlciB0byB0aGUgVC1TVFVOIHNlcnZlci4gVGhlIHNsaWRlcyBkb27i gJl0IGRlc2NyaWJlIHRoZSB1c2FnZSBvZiBhIFRVUk4gc2VydmVyL3JlbGF5LCBidXQgdGhhdCB3 b3VsZCBmb3Igc3VyZSBiZSBwb3NzaWJsZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZndDtPbmUgdGhpbmcgdGhhdCBJIGZpbmQgc3BlY2lhbCBpbiB0aGlzIGNhc2UgdGhhbiB1 c3VhbCBQMlAgZXN0YWJsaXNobWVudCBzY2VuYXJpbyBpcyB0aGF0LCB0aGUgVFVSTiBzZXJ2ZXIg aGFzIHRoZSByZXNwb25zaWJpbGl0eSZuYnNwO29mIG5vdGlmeWluZyB0aGUgVVJJIGFzIHdlbGwg YW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPm5vdCBvbmx5IHRoZSBpcDpw b3J0IG1hcHBpbmcuDQo8L3NwYW4+VGhpcyBpcyBiZWNhdXNlIG9mIHRoZSBSRVNUZnVsIHNlbWFu dGljcy48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Tm90IHN1cmUgSSB1bmRlcnN0YW5kLiBU aGUgVC1TVFVOIHNlcnZlciBvbmx5IHByb3ZpZGVzIHRoZSBwdWJsaWMgSVAgYWRkcmVzczpwb3J0 IG9mIHRoZSBkZXZpY2UuIFRoZSBkZXZpY2UgY3JlYXRlcyB0aGUgVVJJLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0O0NhbiB3ZSBmaW5kIGFueSBkb2N1bWVudCBlbGFib3Jh dGluZyB0aGVzZSBzbGlkZXM/Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5BdCB0aGUgbW9tZW50IHRoZXJlIGlzIG5vIElFVEYgZHJhZnQgZGVzY3JpYmluZyB0aGlzLCBt b3N0bHkgYmVjYXVzZSBzbyBmYXIgcGVvcGxlIGhhdmVu4oCZdCBzaG93biB0b28gbXVjaCBpbnRl cmVzdCBpbiBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkl0IGlzIGRlc2NyaWJlZCBpbiBteSB0aGVz aXMsIHNvIGlmIHlvdSB3YW50IEkgY2FuIGdpdmUgeW91IHRoZSBsaW5rIGZvciB0aGF0IDopDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtBbmQsIGlzIHRoZXJlIGFueSBvcGVuc291cmNlJm5ic3A7 aW1wbGVtZW50YXRpb24gYXZhaWxhYmxlIG9mIHRoaXMgcHJvcG9zYWwgcGxlYXNlPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q3VycmVudGx5IG5vdCwgdW5mb3J0dW5hdGVseSwg YXMgZmFyIGFzIEkga25vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBGcmksIEFwciAz LCAyMDIwIGF0IDEyOjExIEFNIENocmlzdGVyIEhvbG1iZXJnICZsdDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+PHNwYW4gbGFuZz0iRU4tVVMi PmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4t VVMiPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHlvdSBhcmUgaW50ZXJlc3RlZCBp biBQMlAsIHlvdSBtaWdodCBiZSBpbnRlcmVzdGVkIGluIHRoZSB0aGluLUlDRSBwcmVzZW50YXRp b24gdGhhdCB3YXMgZ2l2ZW4gYXQgdGhlIFQyVFJHIG1lZXRpbmcgaW4gU2luZ2Fwb3JlOjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGEgaHJlZj0iaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az03YTQzMmRlYS0y Njk3MjA5OC03YTQzNmQ3MS04Njg1OWIyOTMxYjMtYTkxZjJkMmVkOTlkYTk1MSZhbXA7cT0xJmFt cDtlPWIzMjliMDg4LWQ2ZDAtNDQ0Ni04ZGRmLTU1ODlhOWUzYWJjZCZhbXA7dT1odHRwcyUzQSUy RiUyRmdpdGh1Yi5jb20lMkZ0MnRyZyUyRjIwMTktMTEtc2luZ2Fwb3JlJTJGYmxvYiUyRm1hc3Rl ciUyRnNsaWRlcyUyRjQ0LXRoaW4tSUNFLTE1MTExOS1TaW5nYXBvcmUucGRmIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vZ2l0aHViLmNvbS90MnRyZy8yMDE5LTEx LXNpbmdhcG9yZS9ibG9iL21hc3Rlci9zbGlkZXMvNDQtdGhpbi1JQ0UtMTUxMTE5LVNpbmdhcG9y ZS5wZGY8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206 DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5j b3JlICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+Y29yZS1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIEFiaGlqYW4g QmhhdHRhY2hhcnl5YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5hYmhpamFuLmJoYXR0YWNoYXJ5eWFAZ21haWwuY29t PC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIDIgQXByaWwgMjAyMCBhdCAxMS4w NDxicj4NCjxiPlRvOiA8L2I+VGhvbWFzIEZvc3NhdGkgJmx0OzxhIGhyZWY9Im1haWx0bzpUaG9t YXMuRm9zc2F0aUBhcm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+VGhvbWFzLkZvc3NhdGlAYXJtLmNv bTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5jb3JlICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZUBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNvcmVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5SZTogW2NvcmVdIFVzaW5nIENvQVAgZm9yIFAyUDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SGkgVGhvbWFzLA0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5XaGF0IEkgYW0gbG9va2luZyBhdCBpcyBhIHNpdHVhdGlvbiB3aGVyZSBJIGhhdmUg dHdvIG5vZGVzIGVhY2ggaGF2aW5nIGEgdGltZS12YXJ5aW5nIHJlc291cmNlLiBCb3RoIHdhbnQm bmJzcDt0byBwdXNoIHRoZSBzdGF0ZXMgb2YgdGhlIHJlc3BlY3RpdmUgcmVzb3VyY2UgdG8gdGhl IG90aGVyIG5vZGUgd2l0aGluDQogYSBjb21tb24gYXBwbGljYXRpb24gY29udGV4dC4gSG93ZXZl ciwgdGhlc2UgZXhjaGFuZ2VzIGFyZSBuYXR1cmFsbHkgYXN5bmNocm9ub3VzLiBNYXkgYmUgSSBj YW4gdGhpbmsgb2YgaXQgbW9yZSBsaWtlIGEgY2hhdC4gQSB0eXBpY2FsIGNsaWVudC1zZXJ2ZXIg b3Igb2JzZXJ2ZSByZWxhdGlvbnNoaXAgd2lsbCBub3Qgc2VydmUgdGhlIHB1cnBvc2UuIEFjdHVh bGx5IGJvdGggc2hvdWxkIGhhdmUgYSBjbGllbnQgYW5kIHNlcnZlciBpbnN0YW5jZQ0KIHJ1bm5p bmcgdW5kZXIgYSBjb21tb24gYXBwbGljYXRpb24uIFRoZW4gZWl0aGVyIGVhY2ggY2FuICpvYnNl cnZlKiB0aGUgb3RoZXIsIG9yIGNhbiAqcG9zdCogdGhlIG90aGVyLiBUaGF0IGlzIGhvdyB3ZSBj YW4gZG8gdGhhdCB3aXRob3V0IGEgY2VudHJhbCBzZXJ2ZXIuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiBteSB1bmRlcnN0YW5kaW5n IGlzIHJpZ2h0LCBhY2NvcmRpbmcgdG8gQ29BUCBzcGVjaWZpY2F0aW9uLCB0aGUgbm9kZXMgd2hp Y2ggY2FuIGhhdmUgYm90aCBzZXJ2ZXIgYW5kIGNsaWVudCAodG8gdGhlIG9yaWdpbiZuYnNwO3Nl cnZlcikgYXJlICZxdW90O2ludGVybWVkaWFyeSZxdW90OyBub2Rlcy4gVGhlIG9ubHkgZXhhbXBs ZQ0KIG9mICZxdW90O2ludGVybWVkaWFyeSZxdW90OyBjb25zaWRlcmVkIGluIHRoZSBzcGVjIGlz IHRoZSBwcm94eSBub2RlLiBCdXQsIGFueXdheSB0aGUgc2l0dWF0aW9uIGluIHRoaXMgY2FzZSBk b2VzIG5vdCBjb25jZXJuIHdpdGggaW50ZXJtZWRpYXJ5LiBCb3RoIGFyZSBvcmlnaW4gc2VydmVy IGFuZCBlbmQtY2xpZW50IHRvZ2V0aGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXMgdGhlcmUgYW55IHN0YW5kYXJkaXplZCBtZWNo YW5pc20gdG8gaGFuZGxlIHRoaXMgc2l0dWF0aW9uPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk9uIFdlZCwgQXByIDEsIDIwMjAgYXQgNTozMiBQTSBUaG9tYXMgRm9zc2F0aSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOlRob21hcy5Gb3NzYXRpQGFybS5jb20iIHRhcmdldD0iX2JsYW5rIj5UaG9tYXMu Rm9zc2F0aUBhcm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5IaSBBYmhpamFuLDxicj4NCjxicj4NCk9uIDAxLzA0LzIwMjAsIDEyOjMx LCBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgJmx0OzxhIGhyZWY9Im1haWx0bzphYmhpamFuLmJoYXR0 YWNoYXJ5eWFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWJoaWphbi5iaGF0dGFjaGFyeXlh QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgSXMgdGhlcmUgYW55IHN0YW5kYXJk aXplZCBtZWNoYW5pc20gdG8gdXNlIENvQVAgZm9yIGEgUDJQIGNvbm5lY3Rpb24/PGJyPg0KPGJy Pg0KTm90IHN1cmUgd2hldGhlciBSRkMgNzY1MCB3b3VsZCBmaXQgeW91ciBuZWVkcyBidXQgd29y dGggaGF2aW5nIGE8YnI+DQpsb29rIC0tIGlmIHlvdSBoYXZlbid0IGFscmVhZHkuPGJyPg0KPGJy Pg0KY2hlZXJzPGJyPg0KLS08YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpJTVBPUlRBTlQg Tk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFy ZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29u LCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0 aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwgQmxhY2smcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwgQmxhY2smcXVvdDssc2Fucy1zZXJp ZiI+QWJoaWphbiBCaGF0dGFjaGFyeXlhLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCBCbGFjayZxdW90OyxzYW5zLXNlcmlmIj5UZWNobm9sb2dp c3QgYnkgcHJvZmVzc2lvbiBbSW9UfCBJbnRlcm5ldCBQcm90b2NvbHN8IDVHXTwvc3Bhbj48L2k+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBj bGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsIEJsYWNrJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCBCbGFjayZxdW90Oyxz YW5zLXNlcmlmIj5BYmhpamFuIEJoYXR0YWNoYXJ5eWEsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEz LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCBCbGFjayZxdW90OyxzYW5zLXNlcmlmIj5UZWNo bm9sb2dpc3QgYnkgcHJvZmVzc2lvbiBbSW9UfCBJbnRlcm5ldCBQcm90b2NvbHN8IDVHXTwvc3Bh bj48L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D920651491F44DDB8ED0C609F3DD6582ericssoncom_-- From nobody Sat Apr 4 05:26:10 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FD73A0B69 for ; Sat, 4 Apr 2020 05:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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 U13WFpldTakj for ; Sat, 4 Apr 2020 05:26:07 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2060.outbound.protection.outlook.com [40.107.21.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D5D3A0B68 for ; Sat, 4 Apr 2020 05:26:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RiqX7yoYWZPi3/ylpzLz5+ReUBVH5wrJr7La09mk/EVlPcYvtlWr2cmuobq+3+5n1uy5qkyjSbolm54xSpLINcfx1LLevEY2UTgFkQuc13tOylyPCP7M/yJiAnXEGoeDPIvqzNZAGVjMR2tX8wmzsXZy2IVtUNnwmQOFv6KiQMzLcEKoA7GePL7yMPXOdA0sBsOy5yoljBdf6m5wA419Ws35Uf1BDIwuJg477hSK4J78tOVvc/aJAlMeI+wxVChQqL81NSdPzsYKcTh1/FyMNCgGh36QBQ1LrW0CzSy1BS/N5VovXwdARlim+5CtwwdAV2Bw99pov+AufjPee9k9WQ== 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=wz+r5Os0vXykaN+VcX2Z1+Pv4/KUHQgkAXSEGoA4eSY=; b=XO+whClvk3KrY/Cu41ogHp8FN23RPlWHd0V971h3TIFELPvVz2ZavCSE/FswdPbPrFCndy73fFjRRdf6M/GRwh5kAY4orFocK+SuM7JRuhsUWFYpUACP8A82NSOF12gx3LhovpIKtLrZTYb+MVy9MV8erlvmTNN8rRjfaN1TKP0499ZbCQi89el31NFVNLpTtjX9HJwMEbQte4Jb6fix+HYZDTE4u9gqSeVpfOzyDwHoSAkKVoAiP8XEDLCTftXp3NKhkEUaN5Xlj45QiaS1I6jMv3VPrI7ao1oArR4uyTH3QNxLiZRKPc7BBXx7OMQ0Mi4hkWwR4QSh3r0M+enDUw== 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=wz+r5Os0vXykaN+VcX2Z1+Pv4/KUHQgkAXSEGoA4eSY=; b=fuuZsMsjjsEvL1sUyRupp2r8r6brdJHEoHZa25CwBf3Pb0g5JOamfG8/YeJVeJGprUlG5I3jXFHfmhWagdPmT0oxDMQfCgccNKvBgQET3AiYHfv6Dawe6m/IAR1QE5ioNLT/ptYhc8d/WhElEe34ZotlnSr59+HNh1YET4FrvKY= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (52.134.82.159) by AM0PR07MB5139.eurprd07.prod.outlook.com (20.178.19.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.11; Sat, 4 Apr 2020 12:26:03 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512%7]) with mapi id 15.20.2900.012; Sat, 4 Apr 2020 12:26:03 +0000 From: Christer Holmberg To: Abhijan Bhattacharyya CC: Thomas Fossati , core Thread-Topic: [core] Using CoAP for P2P Thread-Index: AQHWCMVROB2ppf3kDkGCzoMwIoGd3KhmXWeAgAEvGgCAAYynAA== Date: Sat, 4 Apr 2020 12:26:03 +0000 Message-ID: References: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b1f1527f-4465-43cf-164c-08d7d89357ac x-ms-traffictypediagnostic: AM0PR07MB5139: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03630A6A4A x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(376002)(39860400002)(396003)(136003)(346002)(8676002)(66556008)(26005)(66446008)(66574012)(76116006)(91956017)(54906003)(5660300002)(186003)(66476007)(316002)(6506007)(71200400001)(66946007)(6916009)(53546011)(44832011)(966005)(64756008)(86362001)(478600001)(6512007)(33656002)(36756003)(6486002)(8936002)(81166006)(2906002)(81156014)(4326008)(2616005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +IGmAejH8RAZ5rMboPDZ5XTwdz5qAT95N+kOPr0VGOzV1DUE3rEsk8RIba9/sY0WFr4alddgPTSiDPQFW57brp9M+w2kZUT1ZL7ogq/cgdrrWYDPQyDXEgfUHPSLKUMC3LSDxv0ZeFN+g7a347QXUFV8ojxGrkm6X+UgNnsCedyokFccnH2Ofa5EcbpyC5G6xtjkcted3RrWAwBdrK52R9RqRcg8nAQI1vMbRjLRuYrlQESouh1sMrPwNVvQsIjYWPSa4W1/khseojUUX1wjGQRkcwtFSkVxkGKQSyXTco7SZnJKW5XxRos2xTdLveH7BPRIPGgcakXKn/kL/QNdpIeoEjSt78MBAvxATofDntDkD/rMFHee9f1eSoJKgY+LwmJZg1K1uwv+tWPqM/ZrjAvxVRznfJXuiPR95oPPeHhmXye+TiUCPXekOEdgqoV5yWtFr1xo36ssIFLi8IMeyisdi/JzYerLfIBUhrrpAKSjnAZvwWxbTWnrvfHRgWHZDvOQdkz0BffJQe18qVRt6Q== x-ms-exchange-antispam-messagedata: cDlMTy1vyfzkAaMNpZeCeUUfZB9A07jY6pjLzZb5Bg/860Yh4NwHqwws/lJKdi4is6bRbkGQ0iUj1TH7Onz6rFU4viWmHz4LKjf8E+aMzCmLkOtyJ2ccC9tOdLmN5PDxktObzBCvbeHS1bRrYLat6Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CF1E6A23243F47A39DFBBB244E96302Bericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b1f1527f-4465-43cf-164c-08d7d89357ac X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2020 12:26:03.8082 (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: jO9y6YKBgI1GzVIr8x1y7ZZLO4lWo/OarEhTDe2cww4b9hfw9ojW6LjVN1Lm3WVJM6ZMNEBo5xCUWQjcp9R6seX7KwVgn3rS/QtiHZ19EgQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5139 Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 04 Apr 2020 12:26:09 -0000 --_000_CF1E6A23243F47A39DFBBB244E96302Bericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5BIGJpdCBvZiBtb3JlIGlucHV0czoNCj5XZSBwcm9wb3NlZCBhIGRlbGF5LXNlbnNp dGl2ZSB0aW1lLXNlcmllcyBzdHJlYW1pbmcgbWVjaGFuaXNtIGJ5IGV4dGVuZGluZyBDb0FQIGFu ZCBwcmVzZW50ZWQgaW4gbGFzdCBCYW5na29rIElFVEYuIFdlIGNhbGxlZCBpdCBBLVJFYUxpU1Qg KEFkYXB0aXZlIFJFU1RmdWwgUmVhbC10aW1lIExpdmUgU3RyZWFtaW5nIGZvciBUaGluZ3MpLg0K PlRoZSBkcmFmdCBpcyBoZXJlOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmhh dHRhY2hhcnl5YS1jb3JlLWEtcmVhbGlzdC0wMA0KPlRoZSByZWxldmFudCByZXNlYXJjaCB3b3Jr IHdhcyBwdWJsaXNoZWQgaW4gMjAxOCBHbG9iZWNvbSB3b3Jrc2hvcDogQWJoaWphbiBCaGF0dGFj aGFyeXlhLCBTdXZyYXQgQWdyYXdhbCwgSGVtYW50IEt1bWFyIFJhdGgsIEFycGFuIFBhbDogIklt cHJvdmluZyBMaXZlLVN0cmVhbWluZyBFeHBlcmllbmNlIGZvciBEZWxheS1TZW5zaXRpdmUgSW9U ID5BcHBsaWNhdGlvbnM6IEEgUkVTVGZ1bCBBcHByb2FjaCIgKGh0dHBzOi8vaWVlZXhwbG9yZS5p ZWVlLm9yZy9kb2N1bWVudC84NjQ0NTIxKS4NCg0KV2hhdCBleGFjdGx5IGRvIHlvdSB3YW50IHRv IHN0YW5kYXJkaXplPyBBcyBsb25nIGFzIG9uZSBkZXZpY2UgYWN0cyBhcyBhIGNsaWVudCwgYW5k IHRoZSBvdGhlciBhcyBhIHNlcnZlciwgdGhlIGN1cnJlbnQgbWVjaGFuaXNtcyBzaG91bGQgd29y ay4NCg0KTm93LCBpZiB5b3Ugd2FudCB0byBzZW5kIEdFVHMgZXRjIGluIGJvdGggZGlyZWN0aW9u cywgSSBhc3N1bWUgdGhhdCBlYWNoIGVuZHBvaW50cyB3b3VsZCBhY3QgYXMgYm90aCBjbGllbnQg YW5kIHNlcnZlci4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQpPbiBGcmksIEFw ciAzLCAyMDIwIGF0IDEyOjExIEFNIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdy b3RlOg0KSGksDQoNCklmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBQMlAsIHlvdSBtaWdodCBiZSBp bnRlcmVzdGVkIGluIHRoZSB0aGluLUlDRSBwcmVzZW50YXRpb24gdGhhdCB3YXMgZ2l2ZW4gYXQg dGhlIFQyVFJHIG1lZXRpbmcgaW4gU2luZ2Fwb3JlOg0KDQpodHRwczovL2dpdGh1Yi5jb20vdDJ0 cmcvMjAxOS0xMS1zaW5nYXBvcmUvYmxvYi9tYXN0ZXIvc2xpZGVzLzQ0LXRoaW4tSUNFLTE1MTEx OS1TaW5nYXBvcmUucGRmPGh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdjEvdXJsP2s9N2E0 MzJkZWEtMjY5NzIwOTgtN2E0MzZkNzEtODY4NTliMjkzMWIzLWE5MWYyZDJlZDk5ZGE5NTEmcT0x JmU9YjMyOWIwODgtZDZkMC00NDQ2LThkZGYtNTU4OWE5ZTNhYmNkJnU9aHR0cHMlM0ElMkYlMkZn aXRodWIuY29tJTJGdDJ0cmclMkYyMDE5LTExLXNpbmdhcG9yZSUyRmJsb2IlMkZtYXN0ZXIlMkZz bGlkZXMlMkY0NC10aGluLUlDRS0xNTExMTktU2luZ2Fwb3JlLnBkZj4NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KDQpGcm9tOiBjb3JlIDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNv cmUtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEg PGFiaGlqYW4uYmhhdHRhY2hhcnl5YUBnbWFpbC5jb208bWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hh cnl5YUBnbWFpbC5jb20+Pg0KRGF0ZTogVGh1cnNkYXksIDIgQXByaWwgMjAyMCBhdCAxMS4wNA0K VG86IFRob21hcyBGb3NzYXRpIDxUaG9tYXMuRm9zc2F0aUBhcm0uY29tPG1haWx0bzpUaG9tYXMu Rm9zc2F0aUBhcm0uY29tPj4NCkNjOiBjb3JlIDxjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGll dGYub3JnPj4NClN1YmplY3Q6IFJlOiBbY29yZV0gVXNpbmcgQ29BUCBmb3IgUDJQDQoNCkhpIFRo b21hcywNCldoYXQgSSBhbSBsb29raW5nIGF0IGlzIGEgc2l0dWF0aW9uIHdoZXJlIEkgaGF2ZSB0 d28gbm9kZXMgZWFjaCBoYXZpbmcgYSB0aW1lLXZhcnlpbmcgcmVzb3VyY2UuIEJvdGggd2FudCB0 byBwdXNoIHRoZSBzdGF0ZXMgb2YgdGhlIHJlc3BlY3RpdmUgcmVzb3VyY2UgdG8gdGhlIG90aGVy IG5vZGUgd2l0aGluIGEgY29tbW9uIGFwcGxpY2F0aW9uIGNvbnRleHQuIEhvd2V2ZXIsIHRoZXNl IGV4Y2hhbmdlcyBhcmUgbmF0dXJhbGx5IGFzeW5jaHJvbm91cy4gTWF5IGJlIEkgY2FuIHRoaW5r IG9mIGl0IG1vcmUgbGlrZSBhIGNoYXQuIEEgdHlwaWNhbCBjbGllbnQtc2VydmVyIG9yIG9ic2Vy dmUgcmVsYXRpb25zaGlwIHdpbGwgbm90IHNlcnZlIHRoZSBwdXJwb3NlLiBBY3R1YWxseSBib3Ro IHNob3VsZCBoYXZlIGEgY2xpZW50IGFuZCBzZXJ2ZXIgaW5zdGFuY2UgcnVubmluZyB1bmRlciBh IGNvbW1vbiBhcHBsaWNhdGlvbi4gVGhlbiBlaXRoZXIgZWFjaCBjYW4gKm9ic2VydmUqIHRoZSBv dGhlciwgb3IgY2FuICpwb3N0KiB0aGUgb3RoZXIuIFRoYXQgaXMgaG93IHdlIGNhbiBkbyB0aGF0 IHdpdGhvdXQgYSBjZW50cmFsIHNlcnZlci4NCg0KSWYgbXkgdW5kZXJzdGFuZGluZyBpcyByaWdo dCwgYWNjb3JkaW5nIHRvIENvQVAgc3BlY2lmaWNhdGlvbiwgdGhlIG5vZGVzIHdoaWNoIGNhbiBo YXZlIGJvdGggc2VydmVyIGFuZCBjbGllbnQgKHRvIHRoZSBvcmlnaW4gc2VydmVyKSBhcmUgImlu dGVybWVkaWFyeSIgbm9kZXMuIFRoZSBvbmx5IGV4YW1wbGUgb2YgImludGVybWVkaWFyeSIgY29u c2lkZXJlZCBpbiB0aGUgc3BlYyBpcyB0aGUgcHJveHkgbm9kZS4gQnV0LCBhbnl3YXkgdGhlIHNp dHVhdGlvbiBpbiB0aGlzIGNhc2UgZG9lcyBub3QgY29uY2VybiB3aXRoIGludGVybWVkaWFyeS4g Qm90aCBhcmUgb3JpZ2luIHNlcnZlciBhbmQgZW5kLWNsaWVudCB0b2dldGhlci4NCg0KSXMgdGhl cmUgYW55IHN0YW5kYXJkaXplZCBtZWNoYW5pc20gdG8gaGFuZGxlIHRoaXMgc2l0dWF0aW9uPw0K DQpUaGFua3MuDQoNCk9uIFdlZCwgQXByIDEsIDIwMjAgYXQgNTozMiBQTSBUaG9tYXMgRm9zc2F0 aSA8VGhvbWFzLkZvc3NhdGlAYXJtLmNvbTxtYWlsdG86VGhvbWFzLkZvc3NhdGlAYXJtLmNvbT4+ IHdyb3RlOg0KSGkgQWJoaWphbiwNCg0KT24gMDEvMDQvMjAyMCwgMTI6MzEsIEFiaGlqYW4gQmhh dHRhY2hhcnl5YSA8YWJoaWphbi5iaGF0dGFjaGFyeXlhQGdtYWlsLmNvbTxtYWlsdG86YWJoaWph bi5iaGF0dGFjaGFyeXlhQGdtYWlsLmNvbT4+IHdyb3RlOg0KPiBJcyB0aGVyZSBhbnkgc3RhbmRh cmRpemVkIG1lY2hhbmlzbSB0byB1c2UgQ29BUCBmb3IgYSBQMlAgY29ubmVjdGlvbj8NCg0KTm90 IHN1cmUgd2hldGhlciBSRkMgNzY1MCB3b3VsZCBmaXQgeW91ciBuZWVkcyBidXQgd29ydGggaGF2 aW5nIGENCmxvb2sgLS0gaWYgeW91IGhhdmVuJ3QgYWxyZWFkeS4NCg0KY2hlZXJzDQotLQ0KDQoN Cg0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55 IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBh bnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5 IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQoNCg0KLS0NClJlZ2Fy ZHMsDQpBYmhpamFuIEJoYXR0YWNoYXJ5eWEsDQpUZWNobm9sb2dpc3QgYnkgcHJvZmVzc2lvbiBb SW9UfCBJbnRlcm5ldCBQcm90b2NvbHN8IDVHXQ0KDQoNCi0tDQpSZWdhcmRzLA0KQWJoaWphbiBC aGF0dGFjaGFyeXlhLA0KVGVjaG5vbG9naXN0IGJ5IHByb2Zlc3Npb24gW0lvVHwgSW50ZXJuZXQg UHJvdG9jb2xzfCA1R10NCg== --_000_CF1E6A23243F47A39DFBBB244E96302Bericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcmlhbCBC bGFjayI7DQoJcGFub3NlLTE6MiAxMSAxMCA0IDIgMSAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRkkiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7QSBiaXQgb2YgbW9yZSBpbnB1dHM6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtXZSBwcm9wb3NlZCBhIGRlbGF5LXNlbnNpdGl2ZSB0aW1l LXNlcmllcyBzdHJlYW1pbmcgbWVjaGFuaXNtIGJ5IGV4dGVuZGluZyBDb0FQIGFuZCBwcmVzZW50 ZWQmbmJzcDtpbiBsYXN0IEJhbmdrb2sgSUVURi4NCjwvc3Bhbj5XZSBjYWxsZWQgaXQgQS1SRWFM aVNUIChBZGFwdGl2ZSBSRVNUZnVsIFJlYWwtdGltZSBMaXZlIFN0cmVhbWluZyBmb3IgVGhpbmdz KS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7VGhlIGRyYWZ0IGlzIGhlcmU6Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaGF0dGFjaGFyeXlh LWNvcmUtYS1yZWFsaXN0LTAwIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWJoYXR0YWNoYXJ5eWEtY29yZS1hLXJlYWxpc3QtMDA8L3NwYW4+PC9h PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0O1RoZSByZWxldmFu dCByZXNlYXJjaCB3b3JrIHdhcyBwdWJsaXNoZWQgaW4gMjAxOCBHbG9iZWNvbSB3b3Jrc2hvcDom bmJzcDtBYmhpamFuIEJoYXR0YWNoYXJ5eWEsIFN1dnJhdCBBZ3Jhd2FsLCBIZW1hbnQgS3VtYXIg UmF0aCwgQXJwYW4gUGFsOiAmcXVvdDtJbXByb3ZpbmcgTGl2ZS1TdHJlYW1pbmcgRXhwZXJpZW5j ZSBmb3IgRGVsYXktU2Vuc2l0aXZlIElvVCAmZ3Q7QXBwbGljYXRpb25zOiBBIFJFU1RmdWwNCiBB cHByb2FjaCZxdW90OyAoPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vaWVlZXhwbG9yZS5pZWVlLm9y Zy9kb2N1bWVudC84NjQ0NTIxIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly9pZWVleHBsb3Jl LmllZWUub3JnL2RvY3VtZW50Lzg2NDQ1MjE8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj4p LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hhdCBleGFjdGx5IGRvIHlvdSB3 YW50IHRvIHN0YW5kYXJkaXplPyBBcyBsb25nIGFzIG9uZSBkZXZpY2UgYWN0cyBhcyBhIGNsaWVu dCwgYW5kIHRoZSBvdGhlciBhcyBhIHNlcnZlciwgdGhlIGN1cnJlbnQgbWVjaGFuaXNtcyBzaG91 bGQgd29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5vdywgaWYgeW91IHdhbnQgdG8gc2VuZCBHRVRz IGV0YyBpbiBib3RoIGRpcmVjdGlvbnMsIEkgYXNzdW1lIHRoYXQgZWFjaCBlbmRwb2ludHMgd291 bGQgYWN0IGFzIGJvdGggY2xpZW50IGFuZCBzZXJ2ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gRnJpLCBBcHIgMywgMjAyMCBhdCAxMjoxMSBBTSBDaHJp c3RlciBIb2xtYmVyZyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20iPjxzcGFuIGxhbmc9IkVOLVVTIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj5JZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4gUDJQLCB5b3UgbWlnaHQgYmUgaW50 ZXJlc3RlZCBpbiB0aGUgdGhpbi1JQ0UgcHJlc2VudGF0aW9uIHRoYXQgd2FzIGdpdmVuIGF0IHRo ZSBUMlRSRyBtZWV0aW5nIGluIFNpbmdhcG9yZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vcHJvdGVj dDIuZmlyZWV5ZS5jb20vdjEvdXJsP2s9N2E0MzJkZWEtMjY5NzIwOTgtN2E0MzZkNzEtODY4NTli MjkzMWIzLWE5MWYyZDJlZDk5ZGE5NTEmYW1wO3E9MSZhbXA7ZT1iMzI5YjA4OC1kNmQwLTQ0NDYt OGRkZi01NTg5YTllM2FiY2QmYW1wO3U9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGdDJ0cmcl MkYyMDE5LTExLXNpbmdhcG9yZSUyRmJsb2IlMkZtYXN0ZXIlMkZzbGlkZXMlMkY0NC10aGluLUlD RS0xNTExMTktU2luZ2Fwb3JlLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVT Ij5odHRwczovL2dpdGh1Yi5jb20vdDJ0cmcvMjAxOS0xMS1zaW5nYXBvcmUvYmxvYi9tYXN0ZXIv c2xpZGVzLzQ0LXRoaW4tSUNFLTE1MTExOS1TaW5nYXBvcmUucGRmPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2hyaXN0ZXI8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Y29yZSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmNvcmUtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNvcmUtYm91bmNlc0BpZXRm Lm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgJmx0OzxhIGhy ZWY9Im1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+YWJoaWphbi5iaGF0dGFjaGFyeXlhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPlRodXJzZGF5LCAyIEFwcmlsIDIwMjAgYXQgMTEuMDQ8YnI+DQo8Yj5UbzogPC9iPlRob21h cyBGb3NzYXRpICZsdDs8YSBocmVmPSJtYWlsdG86VGhvbWFzLkZvc3NhdGlAYXJtLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPlRob21hcy5Gb3NzYXRpQGFybS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8 L2I+Y29yZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5jb3JlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtjb3JlXSBV c2luZyBDb0FQIGZvciBQMlA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIFRob21hcywNCjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hhdCBJIGFtIGxvb2tp bmcgYXQgaXMgYSBzaXR1YXRpb24gd2hlcmUgSSBoYXZlIHR3byBub2RlcyBlYWNoIGhhdmluZyBh IHRpbWUtdmFyeWluZyByZXNvdXJjZS4gQm90aCB3YW50Jm5ic3A7dG8gcHVzaCB0aGUgc3RhdGVz IG9mIHRoZSByZXNwZWN0aXZlIHJlc291cmNlIHRvIHRoZSBvdGhlciBub2RlIHdpdGhpbg0KIGEg Y29tbW9uIGFwcGxpY2F0aW9uIGNvbnRleHQuIEhvd2V2ZXIsIHRoZXNlIGV4Y2hhbmdlcyBhcmUg bmF0dXJhbGx5IGFzeW5jaHJvbm91cy4gTWF5IGJlIEkgY2FuIHRoaW5rIG9mIGl0IG1vcmUgbGlr ZSBhIGNoYXQuIEEgdHlwaWNhbCBjbGllbnQtc2VydmVyIG9yIG9ic2VydmUgcmVsYXRpb25zaGlw IHdpbGwgbm90IHNlcnZlIHRoZSBwdXJwb3NlLiBBY3R1YWxseSBib3RoIHNob3VsZCBoYXZlIGEg Y2xpZW50IGFuZCBzZXJ2ZXIgaW5zdGFuY2UNCiBydW5uaW5nIHVuZGVyIGEgY29tbW9uIGFwcGxp Y2F0aW9uLiBUaGVuIGVpdGhlciBlYWNoIGNhbiAqb2JzZXJ2ZSogdGhlIG90aGVyLCBvciBjYW4g KnBvc3QqIHRoZSBvdGhlci4gVGhhdCBpcyBob3cgd2UgY2FuIGRvIHRoYXQgd2l0aG91dCBhIGNl bnRyYWwgc2VydmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SWYgbXkgdW5kZXJzdGFuZGluZyBpcyByaWdodCwgYWNjb3JkaW5nIHRv IENvQVAgc3BlY2lmaWNhdGlvbiwgdGhlIG5vZGVzIHdoaWNoIGNhbiBoYXZlIGJvdGggc2VydmVy IGFuZCBjbGllbnQgKHRvIHRoZSBvcmlnaW4mbmJzcDtzZXJ2ZXIpIGFyZSAmcXVvdDtpbnRlcm1l ZGlhcnkmcXVvdDsgbm9kZXMuIFRoZSBvbmx5IGV4YW1wbGUNCiBvZiAmcXVvdDtpbnRlcm1lZGlh cnkmcXVvdDsgY29uc2lkZXJlZCBpbiB0aGUgc3BlYyBpcyB0aGUgcHJveHkgbm9kZS4gQnV0LCBh bnl3YXkgdGhlIHNpdHVhdGlvbiBpbiB0aGlzIGNhc2UgZG9lcyBub3QgY29uY2VybiB3aXRoIGlu dGVybWVkaWFyeS4gQm90aCBhcmUgb3JpZ2luIHNlcnZlciBhbmQgZW5kLWNsaWVudCB0b2dldGhl ci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPklzIHRoZXJlIGFueSBzdGFuZGFyZGl6ZWQgbWVjaGFuaXNtIHRvIGhhbmRsZSB0aGlzIHNp dHVhdGlvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIEFwciAxLCAyMDIwIGF0 IDU6MzIgUE0gVGhvbWFzIEZvc3NhdGkgJmx0OzxhIGhyZWY9Im1haWx0bzpUaG9tYXMuRm9zc2F0 aUBhcm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+VGhvbWFzLkZvc3NhdGlAYXJtLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBj bTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgQWJoaWph biw8YnI+DQo8YnI+DQpPbiAwMS8wNC8yMDIwLCAxMjozMSwgQWJoaWphbiBCaGF0dGFjaGFyeXlh ICZsdDs8YSBocmVmPSJtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmFiaGlqYW4uYmhhdHRhY2hhcnl5YUBnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7IElzIHRoZXJlIGFueSBzdGFuZGFyZGl6ZWQgbWVjaGFuaXNtIHRvIHVzZSBD b0FQIGZvciBhIFAyUCBjb25uZWN0aW9uPzxicj4NCjxicj4NCk5vdCBzdXJlIHdoZXRoZXIgUkZD IDc2NTAgd291bGQgZml0IHlvdXIgbmVlZHMgYnV0IHdvcnRoIGhhdmluZyBhPGJyPg0KbG9vayAt LSBpZiB5b3UgaGF2ZW4ndCBhbHJlYWR5Ljxicj4NCjxicj4NCmNoZWVyczxicj4NCi0tPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9m IHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkg YWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9z ZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9z ZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFu ayB5b3UuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4tLQ0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsIEJsYWNrJnF1b3Q7LHNh bnMtc2VyaWYiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsIEJsYWNrJnF1b3Q7LHNhbnMtc2VyaWYiPkFiaGlqYW4gQmhhdHRhY2hhcnl5 YSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwg QmxhY2smcXVvdDssc2Fucy1zZXJpZiI+VGVjaG5vbG9naXN0IGJ5IHByb2Zlc3Npb24gW0lvVHwg SW50ZXJuZXQgUHJvdG9jb2xzfCA1R108L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCBCbGFj ayZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwgQmxhY2smcXVvdDssc2Fucy1zZXJpZiI+QWJoaWphbiBCaGF0 dGFjaGFyeXlhLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwgQmxhY2smcXVvdDssc2Fucy1zZXJpZiI+VGVjaG5vbG9naXN0IGJ5IHByb2Zlc3Npb24g W0lvVHwgSW50ZXJuZXQgUHJvdG9jb2xzfCA1R108L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_CF1E6A23243F47A39DFBBB244E96302Bericssoncom_-- From nobody Sun Apr 5 05:17:09 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE993A040B for ; Sun, 5 Apr 2020 05:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTTPS_HTTP_MISMATCH=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=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 dSqpOnfOYM76 for ; Sun, 5 Apr 2020 05:17:03 -0700 (PDT) Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (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 33D6C3A0408 for ; Sun, 5 Apr 2020 05:17:01 -0700 (PDT) Received: by mail-ed1-x544.google.com with SMTP id v1so15370099edq.8 for ; Sun, 05 Apr 2020 05:17:01 -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=1pK7To42QsMQ0NlGkRM5/LtNDtX1wEJSWLTGKk2wH04=; b=D0uctmusqL26+6zjE30bOyFZxfUVzOMw4eHmIwvMs2na4cwtLH5JDMB7FhgAPmHDAH d5NVRH78Ps7FB8n9brCuHp1xELMppH9nuYHgqt5u3erMsBT3Gq/7JUYXzLkQYhFnx2qt ce2r3EENMQW+Uzyu7xyF+Yrth5my4fUAi2GohGPSL8LthDn87KNPuIx01oyTvOmy0jzX DGAdFDxEFu10JX9dl0DcOk9uiMOWq8jZm/IwYRPlV4gdwYpDWFjIXF6l4gIiqRkhF8bR pglyViuvmCWFXe4Z6RDDBC6ydcCVGEEbjRC7JNTN/rqIGHkMlFlYyCwT0P+phvkqbzNt 6X+A== 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=1pK7To42QsMQ0NlGkRM5/LtNDtX1wEJSWLTGKk2wH04=; b=GeePohZXz/A4NK0YnLw81ALoRNjzmTJhQRp5yOLarOpyCI5YArLerZYTvEEY7hGD/X RmbNX+kIxclo3ByMnOku2MqT/Vj9B46hP3ID0WETCmdJAvzriITNwnlizGuGx5iegZ6W 2+I2X4Ey3MP9IcsF6ZJycm/yzVjU1zVF1WvKxpoSpHWSpzWwyXYdqBjhpzldcr6U7UO7 yPDy+ytxgHT5Y6YkH9ka9wiR4cX14gaehZA0hdkxR2I2aJXKVi4RMEX5E9KtAwvucpjI DVaT0e9cH+TiiDM40SzrpkUw+MNivy8Y/v4qm7OlsOYhkkLFCmJD+eLtAgWt86EUPGcz wfzQ== X-Gm-Message-State: AGi0PubuziKL2W1IC4R4kZUDU/98KVcy3OZhBhdfAUQZGbUj+s717w77 RFM4dia0HzVXFhrL+yPTdZxJKvb4OSR2Tq/rK4wEsg== X-Google-Smtp-Source: APiQypL7lS2I6F6XUNJmuVNmsQnyQaN5T4P0ok92GKauA9Igdju5KZX92bINes1vavWvvABHfc1tBNS4Ckg05fHUwxM= X-Received: by 2002:a05:6402:b14:: with SMTP id bm20mr14605597edb.365.1586089019548; Sun, 05 Apr 2020 05:16:59 -0700 (PDT) MIME-Version: 1.0 References: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> In-Reply-To: From: Abhijan Bhattacharyya Date: Sun, 5 Apr 2020 17:46:46 +0530 Message-ID: To: Christer Holmberg Cc: Thomas Fossati , core Content-Type: multipart/alternative; boundary="00000000000097a8d805a28a20d2" Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 05 Apr 2020 12:17:07 -0000 --00000000000097a8d805a28a20d2 Content-Type: text/plain; charset="UTF-8" Hi Christer, Probably what can be standardized is a method for signalling and exchanging the ICE candidates so that end nodes can mutually push the data to the other. Signalling may include resource discovery. Your proposal looks useful for the purpose. Extending the example towards two sided exchange might help. We shall be interested to try it out if there is any open-source implementation. Thanks. On Sat, 4 Apr 2020, 17:56 Christer Holmberg, wrote: > Hi, > > > > >A bit of more inputs: > > >We proposed a delay-sensitive time-series streaming mechanism by > extending CoAP and presented in last Bangkok IETF. We called it A-REaLiST > (Adaptive RESTful Real-time Live Streaming for Things). > > >The draft is here: > https://tools.ietf.org/html/draft-bhattacharyya-core-a-realist-00 > > >The relevant research work was published in 2018 Globecom > workshop: Abhijan Bhattacharyya, Suvrat Agrawal, Hemant Kumar Rath, Arpan > Pal: "Improving Live-Streaming Experience for Delay-Sensitive IoT > >Applications: A RESTful Approach" ( > https://ieeexplore.ieee.org/document/8644521). > > > > What exactly do you want to standardize? As long as one device acts as a > client, and the other as a server, the current mechanisms should work. > > > > Now, if you want to send GETs etc in both directions, I assume that each > endpoints would act as both client and server. > > > > Regards, > > > > Christer > > > > > > > > > > > > On Fri, Apr 3, 2020 at 12:11 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > If you are interested in P2P, you might be interested in the thin-ICE > presentation that was given at the T2TRG meeting in Singapore: > > > > > https://github.com/t2trg/2019-11-singapore/blob/master/slides/44-thin-ICE-151119-Singapore.pdf > > > > > Regards, > > > > Christer > > > > > > *From: *core on behalf of Abhijan Bhattacharyya < > abhijan.bhattacharyya@gmail.com> > *Date: *Thursday, 2 April 2020 at 11.04 > *To: *Thomas Fossati > *Cc: *core > *Subject: *Re: [core] Using CoAP for P2P > > > > Hi Thomas, > > What I am looking at is a situation where I have two nodes each having a > time-varying resource. Both want to push the states of the respective > resource to the other node within a common application context. However, > these exchanges are naturally asynchronous. May be I can think of it more > like a chat. A typical client-server or observe relationship will not serve > the purpose. Actually both should have a client and server instance running > under a common application. Then either each can *observe* the other, or > can *post* the other. That is how we can do that without a central server. > > > > If my understanding is right, according to CoAP specification, the nodes > which can have both server and client (to the origin server) are > "intermediary" nodes. The only example of "intermediary" considered in the > spec is the proxy node. But, anyway the situation in this case does not > concern with intermediary. Both are origin server and end-client together. > > > > Is there any standardized mechanism to handle this situation? > > > > Thanks. > > > > On Wed, Apr 1, 2020 at 5:32 PM Thomas Fossati > wrote: > > Hi Abhijan, > > On 01/04/2020, 12:31, Abhijan Bhattacharyya < > abhijan.bhattacharyya@gmail.com> wrote: > > Is there any standardized mechanism to use CoAP for a P2P connection? > > Not sure whether RFC 7650 would fit your needs but worth having a > look -- if you haven't already. > > cheers > -- > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > > > > -- > > Regards, > > Abhijan Bhattacharyya, > > *Technologist by profession [IoT| Internet Protocols| 5G]* > > > > > -- > > Regards, > > Abhijan Bhattacharyya, > > *Technologist by profession [IoT| Internet Protocols| 5G]* > --00000000000097a8d805a28a20d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christer,
Probably what can=C2=A0 be = standardized is a method for signalling and exchanging the ICE candidates s= o that end nodes can mutually push the data to the other. Signalling may in= clude resource discovery.

Your proposal looks useful for the purpose. Extending the example towards= two sided exchange might help.

We shall be interested to try it out if there is any open-source = implementation.

Thanks.<= /div>

On Sat, 4 Apr 2020, 17:56 Christer Holmberg, <christer.holmberg@ericsson.com&= gt; wrote:

Hi,

=C2=A0

>A bit of more inputs:

>We proposed a delay-sensiti= ve time-series streaming mechanism by extending CoAP and presented=C2=A0in = last Bangkok IETF. We called it A-REaLiST (Adaptive RESTful Real-time Live Streaming fo= r Things).=C2=A0

>The relevant research work = was published in 2018 Globecom workshop:=C2=A0Abhijan Bhattacharyya, Suvrat= Agrawal, Hemant Kumar Rath, Arpan Pal: "Improving Live-Streaming Expe= rience for Delay-Sensitive IoT >Applications: A RESTful Approach" (https://iee= explore.ieee.org/document/8644521).<= u>

=C2=A0

What exactly do you want to sta= ndardize? As long as one device acts as a client, and the other as a server= , the current mechanisms should work.

=C2=A0

Now, if you want to send GETs e= tc in both directions, I assume that each endpoints would act as both clien= t and server.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Apr 3, 2020 at 12:11 AM= Christer Holmberg <christer.hol= mberg@ericsson.com> wrote:=

Hi,

=C2=A0

If you are interested in P2P, y= ou might be interested in the thin-ICE presentation that was given at the T= 2TRG meeting in Singapore:

=C2=A0

https://g= ithub.com/t2trg/2019-11-singapore/blob/master/slides/44-thin-ICE-151119-Sin= gapore.pdf

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From= : core <core-bo= unces@ietf.org> on behalf of Abhijan Bhattacharyya <= abhijan.bhattacharyya@gmail.com>
Date: Thursday, 2 April 2020 at 11.04
To: Thomas Fossati <Thomas.Fossati@arm.com>
Cc: core <core@ietf.org>
Subject: Re: [core] Using CoAP for P2P

=C2=A0

Hi Thomas,

What I am looking at is a situation where I have two= nodes each having a time-varying resource. Both want=C2=A0to push the stat= es of the respective resource to the other node within a common application context. However, these exchanges are naturally async= hronous. May be I can think of it more like a chat. A typical client-server= or observe relationship will not serve the purpose. Actually both should h= ave a client and server instance running under a common application. Then either each can *observe* the oth= er, or can *post* the other. That is how we can do that without a central s= erver.

=C2=A0

If my understanding is right, according to CoAP spec= ification, the nodes which can have both server and client (to the origin= =C2=A0server) are "intermediary" nodes. The only example of "intermediary" considered in the spec is the proxy node. But,= anyway the situation in this case does not concern with intermediary. Both= are origin server and end-client together.

=C2=A0

Is there any standardized mechanism to handle this s= ituation?

=C2=A0

Thanks.

=C2=A0

On Wed, Apr 1, 2020 at 5:32 PM Thomas Fossati <Thomas.Fossati@arm.com> wrote:

Hi Abhijan,

On 01/04/2020, 12:31, Abhijan Bhattacharyya <abhijan.bhatta= charyya@gmail.com> wrote:
> Is there any standardized mechanism to use CoAP for a P2P connection?<= br>
Not sure whether RFC 7650 would fit your needs but worth having a
look -- if you haven't already.

cheers
--




IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.


=C2=A0

--

Regards,

Abhijan Bhattacharyya,

Technologist by profession [IoT| Internet Pr= otocols| 5G]


=C2=A0

--

Regards,

Abhijan Bhattacharyya,

Technologist by profession [IoT| Internet Pr= otocols| 5G]

--00000000000097a8d805a28a20d2-- From nobody Mon Apr 6 04:11:21 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0E83A0E8D for ; Mon, 6 Apr 2020 04:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 d4Ely0i5rV0U for ; Mon, 6 Apr 2020 04:11:16 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D523A0E88 for ; Mon, 6 Apr 2020 04:11:15 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0447D5C00A9; Mon, 6 Apr 2020 07:11:15 -0400 (EDT) Received: from imap3 ([10.202.2.53]) by compute7.internal (MEProxy); Mon, 06 Apr 2020 07:11:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=x/K4RI 9kSUMB/EDUsOb4oj7O6kVkK/DmLQIDL6eCkdg=; b=HpyDqJj9FvbZ3c5NWuxle5 N4rgeiVJhrS5r3DTVK+VAZ7k1ulJAYbRw3+5CYLKXrmoC8+Z8BDQRopwsaYQH1I7 j+r/HK9qpDrg4krAHSx7q5L6Cvbqqt+sFk+bmS7SnkDtnmUZCx2spbrDpgLepu8k tvHlOS3F7BFoWfwXAsXc4kOs+MQQ+CmBpoyezfBUgQdQjotfpA7MbAcQW73ZafCE vFCQsCBcmC6D1uEo20y2Jng/wbr9/2z/APet/Q3i7ux9ECVRYSt7Y3u0eZv1rWVH lVlOTLosQI+ma1NQbXnMOkXz+A0zAqki85TOoRi5W+ceezkt/22f6vm5s1OW3URA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudefgdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomheplfgrihhmvggplfhimhornhgviicuoehjrghimhgvsehikhhi rdhfiheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgpdifvg gsvgigrdgtohhmpdhtihhmvggrnhguuggrthgvrdgtohhmpdhrihdrshgvnecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjhgrihhmvgesihhkih drfhhi X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E27BC4E00A1; Mon, 6 Apr 2020 07:11:13 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1084-gdc5e709-fmstable-20200406v2 Mime-Version: 1.0 Message-Id: <4e258729-37d1-46fd-9907-a43354af50d5@www.fastmail.com> In-Reply-To: <789d189c-619c-7f06-0f0a-fc68b2262a51@ri.se> References: <789d189c-619c-7f06-0f0a-fc68b2262a51@ri.se> Date: Mon, 06 Apr 2020 14:10:53 +0300 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: core@ietf.org Content-Type: multipart/alternative; boundary=12808b073fda47c1a90fe7de32d135e7 Archived-At: Subject: Re: [core] Upcoming CoRE Virtual Meetings 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, 06 Apr 2020 11:11:19 -0000 --12808b073fda47c1a90fe7de32d135e7 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear core,=20 in order to run the CoRE Virtual meetings smoothly we'd like to send a r= eminder of the following: - Those who are going to be presenting slides on Wednesday the 8th. Plea= se send us the slides already *today* at the latest. You can use pptx or= pdf format. We will upload them to https://github.com/core-wg/wg-materi= als/tree/master/ietf107 . - We will be using Webex for the virtual meetings, however the queue man= agement will be done over jabber. If you haven't already, please set up = a jabber account (https://ietf.org/how/meetings/jabber/ ) and join the g= roup core@jabber.ietf.org group. If you cannot, you can still use the we= bex chat during the meeting and we'll add you manually to the queue. We = will explain about this during the meeting too. Ciao! --=20 Jaime Jim=C3=A9nez On Tue, Mar 31, 2020, at 12:01 AM, Marco Tiloca wrote: > Hello CoRE, >=20 > The two virtual meetings replacing IETF 107 are confirmed for the > intended days and times, as summarized below. >=20 > [Meeting 1] > Date and time: 8th of April 2020, 13:00-15:00 UTC [1] > Webex link: > https://ietf.webex.com/webappng/sites/ietf/meeting/info/12f03cd44d7d40= 79b925586135df03ee >=20 > [Meeting 2] > Date and time: 16th of April 2020, 13:00-14:30 UTC [2] > Webex link: > https://ietf.webex.com/webappng/sites/ietf/meeting/info/1ccf8929f40d4f= f2a6ff4a6b46521a12 >=20 > Like in regular IETF meetings, we plan to also use Jabber. In particul= ar > also for the virtual microphone queue, you may want to say =E2=80=9Che= lp q=E2=80=9D in > xmpp:core@jabber.ietf.org?join >=20 >=20 > The planned agenda for both meetings is available at: >=20 > https://github.com/core-wg/wg-materials/blob/master/ietf107/core-107-a= genda.md >=20 > Please, provide the chairs with the intended objectives for your > pertaining time slot and the name of the intended discussion > leader/presenter, if they are not included already. >=20 > Finally, please send your slides to the chairs: >=20 > - By the 6th of April for the first meeting. > - By the 14th of April for the second meeting. >=20 > Consolidated slides will be also made available at: > https://github.com/core-wg/wg-materials/tree/master/ietf107 >=20 > Best, > Marco and Jaime >=20 >=20 > [1] > https://www.timeanddate.com/worldclock/meetingdetails.html?year=3D2020= &month=3D4&day=3D8&hour=3D13&min=3D0&sec=3D0&p1=3D239&p2=3D179 >=20 > [2] > https://www.timeanddate.com/worldclock/meetingdetails.html?year=3D2020= &month=3D4&day=3D16&hour=3D13&min=3D0&sec=3D0&p1=3D239&p2=3D179 >=20 > --=20 > Marco Tiloca > Ph.D., Senior Researcher >=20 > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) >=20 > Phone: +46 (0)70 60 46 501 > https://www.ri.se >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 > *Attachments:* > * signature.asc --12808b073fda47c1a90fe7de32d135e7 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear core,=

in order to run the CoRE Virtual meetings= smoothly we'd like to send a reminder of the following:
<= br>
- Those who are going to be presenting slides on Wednesday= the 8th. Please send us the slides already today at the lat= est.  You can use pptx or pdf format. We will upload them to <= a href=3D"https://github.com/core-wg/wg-materials/tree/master/ietf107">h= ttps://github.com/core-wg/wg-materials/tree/master/ietf107 .

- We will be using Webex for the virtual meet= ings, however the queue management will be done over jabber. If you have= n't already, please set up a jabber account (https://ietf.org/how/meetings/jabber/ ) = and join the group core@jab= ber.ietf.org group. If you cannot, you can still use the webex = chat during the meeting and we'll add you manually to the queue. We will= explain about this during the meeting too.

Ciao!
-- 
Ja= ime Jim=C3=A9nez



<= /div>
On Tue, Mar 31, 2020, at 12:01 AM, Marco Tiloca wrote:
Hello CoRE,
The two virtual meetings replacing IETF 107 are confirmed fo= r the
intended days and times, as summarized below.

[Meeting 1]
Date and time: 8th of A= pril 2020, 13:00-15:00 UTC [1]
Webex link:
h= ttps://ietf.webex.com/webappng/sites/ietf/meeting/info/12f03cd44d7d4079b= 925586135df03ee

[Meeting 2]
D= ate and time: 16th of April 2020, 13:00-14:30 UTC [2]
Webe= x link:
https://ietf.webex.com/webappng/sites/ietf/meeting= /info/1ccf8929f40d4ff2a6ff4a6b46521a12

Like= in regular IETF meetings, we plan to also use Jabber. In particular
=
also for the virtual microphone queue, you may want to say =E2= =80=9Chelp q=E2=80=9D in
xmpp:core@jabber.ietf.org?join


The planned agenda for both me= etings is available at:

https://github.com/= core-wg/wg-materials/blob/master/ietf107/core-107-agenda.md

Please, provide the chairs with the intended objectives= for your
pertaining time slot and the name of the intende= d discussion
leader/presenter, if they are not included al= ready.

Finally, please send your slides to = the chairs:

- By the 6th of April for the f= irst meeting.
- By the 14th of April for the second meetin= g.

Consolidated slides will be also made av= ailable at:
https://github.com/core-wg/wg-materials/tree/m= aster/ietf107

Best,
Marco and= Jaime


[1]
htt= ps://www.timeanddate.com/worldclock/meetingdetails.html?year=3D2020&= month=3D4&day=3D8&hour=3D13&min=3D0&sec=3D0&p1=3D239= &p2=3D179

[2]
https://www= .timeanddate.com/worldclock/meetingdetails.html?year=3D2020&month=3D= 4&day=3D16&hour=3D13&min=3D0&sec=3D0&p1=3D239&p2= =3D179

-- 
Marco Tiloca<= br>
Ph.D., Senior Researcher

RISE= Research Institutes of Sweden
Division ICT
= Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (S= weden)

Phone: +46 (0)70 60 46 501
=
https://www.ri.se



<= /div>
_______________________________________________
= core mailing list
core@ietf.org
https://www.= ietf.org/mailman/listinfo/core


Attachments:
  • signature.asc

--12808b073fda47c1a90fe7de32d135e7-- From nobody Mon Apr 6 04:26:03 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38D13A0EE2 for ; Mon, 6 Apr 2020 04:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, 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, 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 7Sc5cfp6xqHN for ; Mon, 6 Apr 2020 04:25:58 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2062c.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1a::62c]) (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 9D1A33A0EDC for ; Mon, 6 Apr 2020 04:25:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Kn1sNpC/u5FGmANSczmUvlcahc8BoQ+2KaUufaZPTZr0cuCQA/1Ag3gVzK9Df6l6TTqAZmySTJZFAAgo8TYFRfucGaTGVwLoRkTw732b2lsUJHhEZFKNaJXkBNxYJzN0YhPOQbIGsOixjWu+fDDfdnOyG5znA0VEkTGDsck5e6kgTFbn/UThCq51q/SBxVwsUGTXyMSqw7Tvv0mbL/xSO0TA/NRo+++NEzxBjly6ND4UiWi4dOq+KRxuFVO87DnE/o1aAgQYHcAfds2gStL1EnVDky/DKWGTiuls7yo0JY2yanUv1Y+gRVpKHPq7Acu4ieN6IXlC+yE8OA804SGx5A== 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=NcF+a6l77hXOcrvQehQiGE5H6JzOuZE5yla6COSa+/0=; b=bqoEBNZxtS4pQk+vbXNF4geSY7338GRGz5kTyjlumEOi5PDmHgtqSPiApFZmglm5Pyiw4V1DxtpYJZgcQ+jkSBNslR39xWxVOq3+QsegDMIw5GT45wQEf8ffi5MxbpRNMul+oj4aZj2o1iE1uDPS2EBS3xXgBedtnUau7xrSllS3aYP6fqvlN5zMb/SjpCFE2YDARZ+LJ/rLsVZeXlibABB+uFbSoW4Igk631R6WUwCyvR/Z8UYH+Z7e1GsnxA46Hg1JhWUnDcwlebd0+h8P0lB0v2swcXfUoo3gb0G2X8KBWjVM61HNyajoNJopuYWXG6fMhEz4M7A7vuKB3XTSWg== 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=NcF+a6l77hXOcrvQehQiGE5H6JzOuZE5yla6COSa+/0=; b=T7cXwTTwsaN8a77zeYcfh8oDVZddRRzHtqKUv47Itnuya0vgjPAbTLSD2PpUofqwEl4twl388kPiCVdgMTtUS4fZUOCvWATRtmzghX9A6eYJe76lLbiHllCDE6/uFd3RhXQSI6zG1N0lcatJeAakksjdnjSDVg98V3hLsmzHEWU= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (52.134.82.159) by AM0PR07MB6131.eurprd07.prod.outlook.com (20.178.115.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.14; Mon, 6 Apr 2020 11:25:55 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512%7]) with mapi id 15.20.2900.012; Mon, 6 Apr 2020 11:25:55 +0000 From: Christer Holmberg To: Abhijan Bhattacharyya CC: Thomas Fossati , core Thread-Topic: [core] Using CoAP for P2P Thread-Index: AQHWCMVROB2ppf3kDkGCzoMwIoGd3KhmXWeAgAEvGgCAAYynAIABXXMAgAG2aQA= Date: Mon, 6 Apr 2020 11:25:55 +0000 Message-ID: <7DA395A7-0A3E-4EC7-9F2A-D37FDEA2AB5C@ericsson.com> References: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 389c5c8f-baee-43d8-afeb-08d7da1d45b8 x-ms-traffictypediagnostic: AM0PR07MB6131: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(39860400002)(136003)(396003)(376002)(366004)(44832011)(53546011)(66476007)(66946007)(6506007)(2906002)(8936002)(6486002)(33656002)(186003)(66446008)(64756008)(66556008)(76116006)(86362001)(478600001)(36756003)(2616005)(5660300002)(81156014)(71200400001)(966005)(81166006)(316002)(54906003)(26005)(66574012)(6512007)(6916009)(4326008)(8676002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VG6VkZ4xXSgl/JJo5gEwGfczJuy/mj/uNE+b4uzbM76Kb3i5U1zsK38KD8IQh9MIORI3VWumQgSHXsylz3yM1sxraSX25FmusuuxLeE2zjMgg5qbs9Z0GAN0lz9b3EulL6M9o61DkVe39o1fRLNFEU2vJ9X2rpRvrzEJADwoS2LoPzJ4lrAPFJsCUw46QOBHf1JYfTxYYN/m1Qky39m+e7FXf3+b8rE0ybAIGx+9nddYoS8friPaGKAtOTvQKUhu7GrleRbN6Ck2Ea/+B9EaFHGmjchOAW1lvJcyYzKloWwM00yVCmc6UTitcFkWqThHb5EJsCR+xXiPbm0eRBs4PmuFBudrAQwSN8oCVxOeGoIOjkOpGcldoC599N7J6QZ0y5X+tpP+2z/2SPH8LzxGeezaX9yPNaa8F/q2dyS628VCRda46Eeb4lT5X+JGFgAEMrY+oQ54E6awoAn8mBY6obdwz8G7QCRJyUCWjALfffpAOfux99hF1uXSyVmrUXrEpZoLJOzMm++pOd7wZ48YUw== x-ms-exchange-antispam-messagedata: 5c9fEiMqADcCwLXr1jpk3PbL2JNZ5tzqKcPfEMAtNGeOsS/2lBzmBW3Xqbo/zH8CQjyY/BFUqSwKCmr0gcqNy/VmBIzlp1bq1uJbP45GwUZCsvvy4z5HKs/SCQZDW+2FOIauLoiYWisZvv8+C8D/Ww== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_7DA395A70A3E4EC79F2AD37FDEA2AB5Cericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 389c5c8f-baee-43d8-afeb-08d7da1d45b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2020 11:25:55.3883 (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: eEXfmdGgYYyLyFTeS+geLi/GsBfAE7RmlM+EgKx2sikxa0Y4px2EILns/SXhxcl3HBh53djXNFY3BujrkggIPb4SrJqpMvlECISzqpH7Azs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6131 Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 06 Apr 2020 11:26:01 -0000 --_000_7DA395A70A3E4EC79F2AD37FDEA2AB5Cericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj4gUHJvYmFibHkgd2hhdCBjYW4gIGJlIHN0YW5kYXJkaXplZCBpcyBhIG1ldGhvZCBm b3Igc2lnbmFsbGluZyBhbmQgZXhjaGFuZ2luZyB0aGUgSUNFIGNhbmRpZGF0ZXMgc28gdGhhdCBl bmQgbm9kZXMgY2FuDQo+IG11dHVhbGx5IHB1c2ggdGhlIGRhdGEgdG8gdGhlIG90aGVyLiBTaWdu YWxsaW5nIG1heSBpbmNsdWRlIHJlc291cmNlIGRpc2NvdmVyeS4NCg0KWWVzLCBvbmUgY291bGQg c3BsaXQgdGhpbmdzIHVwIGludG8gc2VwYXJhdGUgcGllY2VzIGFzIGZhciBhcyBzdGFuZGFyZGl6 YXRpb24gaXMgY29uY2VybmVkLg0KDQpPbmUgcGllY2UgaXMgdG8gc2ltcGx5IGNvbGxlY3QgY2Fu ZGlkYXRlcyB1c2luZyBDb0FQLiBBbm90aGVyIHBpZWNlIGlzIHRoZSBjYW5kaWRhdGUgZXhjaGFu Z2UuDQoNCj4gWW91ciBwcm9wb3NhbCBsb29rcyB1c2VmdWwgZm9yIHRoZSBwdXJwb3NlLiBFeHRl bmRpbmcgdGhlIGV4YW1wbGUgdG93YXJkcyB0d28gc2lkZWQgZXhjaGFuZ2UgbWlnaHQgaGVscC4N Cg0KU3VyZS4gSWYgdGhpcyB3b3VsZCBiZSBzdGFuZGFyZGl6ZWQsIHRoYXQgc2hvdWxkIGF0IGxl YXN0IGJlIGNvbnNpZGVyZWQuDQoNCj4gV2Ugc2hhbGwgYmUgaW50ZXJlc3RlZCB0byB0cnkgaXQg b3V0IGlmIHRoZXJlIGlzIGFueSBvcGVuLXNvdXJjZSBpbXBsZW1lbnRhdGlvbi4NCg0KTWUgdG9v IDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KT24gU2F0LCA0IEFwciAyMDIwLCAxNzo1 NiBDaHJpc3RlciBIb2xtYmVyZywgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KPkEgYml0 IG9mIG1vcmUgaW5wdXRzOg0KPldlIHByb3Bvc2VkIGEgZGVsYXktc2Vuc2l0aXZlIHRpbWUtc2Vy aWVzIHN0cmVhbWluZyBtZWNoYW5pc20gYnkgZXh0ZW5kaW5nIENvQVAgYW5kIHByZXNlbnRlZCBp biBsYXN0IEJhbmdrb2sgSUVURi4gV2UgY2FsbGVkIGl0IEEtUkVhTGlTVCAoQWRhcHRpdmUgUkVT VGZ1bCBSZWFsLXRpbWUgTGl2ZSBTdHJlYW1pbmcgZm9yIFRoaW5ncykuDQo+VGhlIGRyYWZ0IGlz IGhlcmU6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaGF0dGFjaGFyeXlhLWNv cmUtYS1yZWFsaXN0LTAwDQo+VGhlIHJlbGV2YW50IHJlc2VhcmNoIHdvcmsgd2FzIHB1Ymxpc2hl ZCBpbiAyMDE4IEdsb2JlY29tIHdvcmtzaG9wOiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEsIFN1dnJh dCBBZ3Jhd2FsLCBIZW1hbnQgS3VtYXIgUmF0aCwgQXJwYW4gUGFsOiAiSW1wcm92aW5nIExpdmUt U3RyZWFtaW5nIEV4cGVyaWVuY2UgZm9yIERlbGF5LVNlbnNpdGl2ZSBJb1QgPkFwcGxpY2F0aW9u czogQSBSRVNUZnVsIEFwcHJvYWNoIiAoaHR0cHM6Ly9pZWVleHBsb3JlLmllZWUub3JnL2RvY3Vt ZW50Lzg2NDQ1MjEpLg0KDQpXaGF0IGV4YWN0bHkgZG8geW91IHdhbnQgdG8gc3RhbmRhcmRpemU/ IEFzIGxvbmcgYXMgb25lIGRldmljZSBhY3RzIGFzIGEgY2xpZW50LCBhbmQgdGhlIG90aGVyIGFz IGEgc2VydmVyLCB0aGUgY3VycmVudCBtZWNoYW5pc21zIHNob3VsZCB3b3JrLg0KDQpOb3csIGlm IHlvdSB3YW50IHRvIHNlbmQgR0VUcyBldGMgaW4gYm90aCBkaXJlY3Rpb25zLCBJIGFzc3VtZSB0 aGF0IGVhY2ggZW5kcG9pbnRzIHdvdWxkIGFjdCBhcyBib3RoIGNsaWVudCBhbmQgc2VydmVyLg0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCk9uIEZyaSwgQXByIDMsIDIwMjAgYXQg MTI6MTEgQU0gQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0K SWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIFAyUCwgeW91IG1pZ2h0IGJlIGludGVyZXN0ZWQgaW4g dGhlIHRoaW4tSUNFIHByZXNlbnRhdGlvbiB0aGF0IHdhcyBnaXZlbiBhdCB0aGUgVDJUUkcgbWVl dGluZyBpbiBTaW5nYXBvcmU6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS90MnRyZy8yMDE5LTExLXNp bmdhcG9yZS9ibG9iL21hc3Rlci9zbGlkZXMvNDQtdGhpbi1JQ0UtMTUxMTE5LVNpbmdhcG9yZS5w ZGY8aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az03YTQzMmRlYS0yNjk3MjA5 OC03YTQzNmQ3MS04Njg1OWIyOTMxYjMtYTkxZjJkMmVkOTlkYTk1MSZxPTEmZT1iMzI5YjA4OC1k NmQwLTQ0NDYtOGRkZi01NTg5YTllM2FiY2QmdT1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZ0 MnRyZyUyRjIwMTktMTEtc2luZ2Fwb3JlJTJGYmxvYiUyRm1hc3RlciUyRnNsaWRlcyUyRjQ0LXRo aW4tSUNFLTE1MTExOS1TaW5nYXBvcmUucGRmPg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoN CkZyb206IGNvcmUgPGNvcmUtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Y29yZS1ib3VuY2VzQGll dGYub3JnPj4gb24gYmVoYWxmIG9mIEFiaGlqYW4gQmhhdHRhY2hhcnl5YSA8YWJoaWphbi5iaGF0 dGFjaGFyeXlhQGdtYWlsLmNvbTxtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQGdtYWlsLmNv bT4+DQpEYXRlOiBUaHVyc2RheSwgMiBBcHJpbCAyMDIwIGF0IDExLjA0DQpUbzogVGhvbWFzIEZv c3NhdGkgPFRob21hcy5Gb3NzYXRpQGFybS5jb208bWFpbHRvOlRob21hcy5Gb3NzYXRpQGFybS5j b20+Pg0KQ2M6IGNvcmUgPGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFtjb3JlXSBVc2luZyBDb0FQIGZvciBQMlANCg0KSGkgVGhvbWFzLA0KV2hhdCBJ IGFtIGxvb2tpbmcgYXQgaXMgYSBzaXR1YXRpb24gd2hlcmUgSSBoYXZlIHR3byBub2RlcyBlYWNo IGhhdmluZyBhIHRpbWUtdmFyeWluZyByZXNvdXJjZS4gQm90aCB3YW50IHRvIHB1c2ggdGhlIHN0 YXRlcyBvZiB0aGUgcmVzcGVjdGl2ZSByZXNvdXJjZSB0byB0aGUgb3RoZXIgbm9kZSB3aXRoaW4g YSBjb21tb24gYXBwbGljYXRpb24gY29udGV4dC4gSG93ZXZlciwgdGhlc2UgZXhjaGFuZ2VzIGFy ZSBuYXR1cmFsbHkgYXN5bmNocm9ub3VzLiBNYXkgYmUgSSBjYW4gdGhpbmsgb2YgaXQgbW9yZSBs aWtlIGEgY2hhdC4gQSB0eXBpY2FsIGNsaWVudC1zZXJ2ZXIgb3Igb2JzZXJ2ZSByZWxhdGlvbnNo aXAgd2lsbCBub3Qgc2VydmUgdGhlIHB1cnBvc2UuIEFjdHVhbGx5IGJvdGggc2hvdWxkIGhhdmUg YSBjbGllbnQgYW5kIHNlcnZlciBpbnN0YW5jZSBydW5uaW5nIHVuZGVyIGEgY29tbW9uIGFwcGxp Y2F0aW9uLiBUaGVuIGVpdGhlciBlYWNoIGNhbiAqb2JzZXJ2ZSogdGhlIG90aGVyLCBvciBjYW4g KnBvc3QqIHRoZSBvdGhlci4gVGhhdCBpcyBob3cgd2UgY2FuIGRvIHRoYXQgd2l0aG91dCBhIGNl bnRyYWwgc2VydmVyLg0KDQpJZiBteSB1bmRlcnN0YW5kaW5nIGlzIHJpZ2h0LCBhY2NvcmRpbmcg dG8gQ29BUCBzcGVjaWZpY2F0aW9uLCB0aGUgbm9kZXMgd2hpY2ggY2FuIGhhdmUgYm90aCBzZXJ2 ZXIgYW5kIGNsaWVudCAodG8gdGhlIG9yaWdpbiBzZXJ2ZXIpIGFyZSAiaW50ZXJtZWRpYXJ5IiBu b2Rlcy4gVGhlIG9ubHkgZXhhbXBsZSBvZiAiaW50ZXJtZWRpYXJ5IiBjb25zaWRlcmVkIGluIHRo ZSBzcGVjIGlzIHRoZSBwcm94eSBub2RlLiBCdXQsIGFueXdheSB0aGUgc2l0dWF0aW9uIGluIHRo aXMgY2FzZSBkb2VzIG5vdCBjb25jZXJuIHdpdGggaW50ZXJtZWRpYXJ5LiBCb3RoIGFyZSBvcmln aW4gc2VydmVyIGFuZCBlbmQtY2xpZW50IHRvZ2V0aGVyLg0KDQpJcyB0aGVyZSBhbnkgc3RhbmRh cmRpemVkIG1lY2hhbmlzbSB0byBoYW5kbGUgdGhpcyBzaXR1YXRpb24/DQoNClRoYW5rcy4NCg0K T24gV2VkLCBBcHIgMSwgMjAyMCBhdCA1OjMyIFBNIFRob21hcyBGb3NzYXRpIDxUaG9tYXMuRm9z c2F0aUBhcm0uY29tPG1haWx0bzpUaG9tYXMuRm9zc2F0aUBhcm0uY29tPj4gd3JvdGU6DQpIaSBB YmhpamFuLA0KDQpPbiAwMS8wNC8yMDIwLCAxMjozMSwgQWJoaWphbiBCaGF0dGFjaGFyeXlhIDxh YmhpamFuLmJoYXR0YWNoYXJ5eWFAZ21haWwuY29tPG1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5 eWFAZ21haWwuY29tPj4gd3JvdGU6DQo+IElzIHRoZXJlIGFueSBzdGFuZGFyZGl6ZWQgbWVjaGFu aXNtIHRvIHVzZSBDb0FQIGZvciBhIFAyUCBjb25uZWN0aW9uPw0KDQpOb3Qgc3VyZSB3aGV0aGVy IFJGQyA3NjUwIHdvdWxkIGZpdCB5b3VyIG5lZWRzIGJ1dCB3b3J0aCBoYXZpbmcgYQ0KbG9vayAt LSBpZiB5b3UgaGF2ZW4ndCBhbHJlYWR5Lg0KDQpjaGVlcnMNCi0tDQoNCg0KDQoNCklNUE9SVEFO VCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg YXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJz b24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0 aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg0KDQotLQ0KUmVnYXJkcywNCkFiaGlqYW4g QmhhdHRhY2hhcnl5YSwNClRlY2hub2xvZ2lzdCBieSBwcm9mZXNzaW9uIFtJb1R8IEludGVybmV0 IFByb3RvY29sc3wgNUddDQoNCg0KLS0NClJlZ2FyZHMsDQpBYmhpamFuIEJoYXR0YWNoYXJ5eWEs DQpUZWNobm9sb2dpc3QgYnkgcHJvZmVzc2lvbiBbSW9UfCBJbnRlcm5ldCBQcm90b2NvbHN8IDVH XQ0K --_000_7DA395A70A3E4EC79F2AD37FDEA2AB5Cericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <7081F36491DDCE41B07A2AAD6751796E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcmlhbCBC bGFjayI7DQoJcGFub3NlLTE6MiAxMSAxMCA0IDIgMSAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4t bGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcw Ljg1cHQgMi4wY207fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkkiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+Jmd0OyA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj5Qcm9iYWJs eSB3aGF0IGNhbiZuYnNwOyBiZSBzdGFuZGFyZGl6ZWQgaXMgYSBtZXRob2QgZm9yIHNpZ25hbGxp bmcgYW5kIGV4Y2hhbmdpbmcgdGhlIElDRSBjYW5kaWRhdGVzIHNvIHRoYXQgZW5kIG5vZGVzIGNh bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+bXV0dWFsbHkgcHVzaCB0aGUg ZGF0YSB0byB0aGUgb3RoZXIuDQo8L3NwYW4+U2lnbmFsbGluZyBtYXkgaW5jbHVkZSByZXNvdXJj ZSBkaXNjb3ZlcnkuPHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlllcywgb25lIGNvdWxkIHNw bGl0IHRoaW5ncyB1cCBpbnRvIHNlcGFyYXRlIHBpZWNlcyBhcyBmYXIgYXMgc3RhbmRhcmRpemF0 aW9uIGlzIGNvbmNlcm5lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uZSBwaWVjZSBpcyB0byBzaW1w bHkgY29sbGVjdCBjYW5kaWRhdGVzIHVzaW5nIENvQVAuIEFub3RoZXIgcGllY2UgaXMgdGhlIGNh bmRpZGF0ZSBleGNoYW5nZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg WW91ciBwcm9wb3NhbCBsb29rcyB1c2VmdWwgZm9yIHRoZSBwdXJwb3NlLg0KPC9zcGFuPkV4dGVu ZGluZyB0aGUgZXhhbXBsZSB0b3dhcmRzIHR3byBzaWRlZCBleGNoYW5nZSBtaWdodCBoZWxwLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ U3VyZS4gSWYgdGhpcyB3b3VsZCBiZSBzdGFuZGFyZGl6ZWQsIHRoYXQgc2hvdWxkIGF0IGxlYXN0 IGJlIGNvbnNpZGVyZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFdl IHNoYWxsIGJlIGludGVyZXN0ZWQgdG8gdHJ5IGl0IG91dCBpZiB0aGVyZSBpcyBhbnkgb3Blbi1z b3VyY2UgaW1wbGVtZW50YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5N ZSB0b28gOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5D aHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgNCBB cHIgMjAyMCwgMTc6NTYgQ2hyaXN0ZXIgSG9sbWJlcmcsICZsdDs8YSBocmVmPSJtYWlsdG86Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtBIGJpdCBvZiBt b3JlIGlucHV0czo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7V2UgcHJvcG9zZWQgYSBkZWxh eS1zZW5zaXRpdmUgdGltZS1zZXJpZXMgc3RyZWFtaW5nIG1lY2hhbmlzbSBieSBleHRlbmRpbmcg Q29BUCBhbmQgcHJlc2VudGVkJm5ic3A7aW4gbGFzdCBCYW5na29rIElFVEYuDQo8L3NwYW4+V2Ug Y2FsbGVkIGl0IEEtUkVhTGlTVCAoQWRhcHRpdmUgUkVTVGZ1bCBSZWFsLXRpbWUgTGl2ZSBTdHJl YW1pbmcgZm9yIFRoaW5ncykuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7VGhlIGRyYWZ0IGlz IGhlcmU6Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1iaGF0dGFjaGFyeXlhLWNvcmUtYS1yZWFsaXN0LTAwIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaGF0dGFj aGFyeXlhLWNvcmUtYS1yZWFsaXN0LTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtU aGUgcmVsZXZhbnQgcmVzZWFyY2ggd29yayB3YXMgcHVibGlzaGVkIGluIDIwMTggR2xvYmVjb20g d29ya3Nob3A6Jm5ic3A7QWJoaWphbiBCaGF0dGFjaGFyeXlhLCBTdXZyYXQgQWdyYXdhbCwgSGVt YW50IEt1bWFyIFJhdGgsIEFycGFuIFBhbDogJnF1b3Q7SW1wcm92aW5nIExpdmUtU3RyZWFtaW5n DQogRXhwZXJpZW5jZSBmb3IgRGVsYXktU2Vuc2l0aXZlIElvVCAmZ3Q7QXBwbGljYXRpb25zOiBB IFJFU1RmdWwgQXBwcm9hY2gmcXVvdDsgKDwvc3Bhbj48YSBocmVmPSJodHRwczovL2llZWV4cGxv cmUuaWVlZS5vcmcvZG9jdW1lbnQvODY0NDUyMSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9 IkVOLVVTIj5odHRwczovL2llZWV4cGxvcmUuaWVlZS5vcmcvZG9jdW1lbnQvODY0NDUyMTwvc3Bh bj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPikuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+V2hhdCBleGFjdGx5IGRvIHlvdSB3YW50IHRvIHN0YW5kYXJkaXplPyBBcyBsb25n IGFzIG9uZSBkZXZpY2UgYWN0cyBhcyBhIGNsaWVudCwgYW5kIHRoZSBvdGhlciBhcyBhIHNlcnZl ciwgdGhlIGN1cnJlbnQgbWVjaGFuaXNtcyBzaG91bGQgd29yay48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5Ob3csIGlmIHlvdSB3YW50IHRvIHNlbmQgR0VUcyBldGMgaW4gYm90aCBkaXJlY3Rpb25z LCBJIGFzc3VtZSB0aGF0IGVhY2ggZW5kcG9pbnRzIHdvdWxkIGFjdCBhcyBib3RoIGNsaWVudCBh bmQgc2VydmVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+T24gRnJpLCBBcHIgMywgMjAyMCBhdCAxMjoxMSBBTSBDaHJpc3Rl ciBIb2xtYmVyZyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0Ow0K IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SGksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+SWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIFAyUCwgeW91IG1pZ2h0IGJlIGludGVyZXN0 ZWQgaW4gdGhlIHRoaW4tSUNFIHByZXNlbnRhdGlvbiB0aGF0IHdhcyBnaXZlbiBhdCB0aGUgVDJU UkcgbWVldGluZyBpbiBTaW5nYXBvcmU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL3Byb3RlY3QyLmZp cmVleWUuY29tL3YxL3VybD9rPTdhNDMyZGVhLTI2OTcyMDk4LTdhNDM2ZDcxLTg2ODU5YjI5MzFi My1hOTFmMmQyZWQ5OWRhOTUxJmFtcDtxPTEmYW1wO2U9YjMyOWIwODgtZDZkMC00NDQ2LThkZGYt NTU4OWE5ZTNhYmNkJmFtcDt1PWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRnQydHJnJTJGMjAx OS0xMS1zaW5nYXBvcmUlMkZibG9iJTJGbWFzdGVyJTJGc2xpZGVzJTJGNDQtdGhpbi1JQ0UtMTUx MTE5LVNpbmdhcG9yZS5wZGYiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0 cHM6Ly9naXRodWIuY29tL3QydHJnLzIwMTktMTEtc2luZ2Fwb3JlL2Jsb2IvbWFzdGVyL3NsaWRl cy80NC10aGluLUlDRS0xNTExMTktU2luZ2Fwb3JlLnBkZjwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkNocmlzdGVyPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPmNvcmUgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3Jl LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jb3JlLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQWJoaWphbiBCaGF0dGFjaGFyeXlhICZsdDs8YSBocmVmPSJt YWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFi aGlqYW4uYmhhdHRhY2hhcnl5YUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5U aHVyc2RheSwgMiBBcHJpbCAyMDIwIGF0IDExLjA0PGJyPg0KPGI+VG86IDwvYj5UaG9tYXMgRm9z c2F0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRob21hcy5Gb3NzYXRpQGFybS5jb20iIHRhcmdldD0i X2JsYW5rIj5UaG9tYXMuRm9zc2F0aUBhcm0uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPmNv cmUgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y29y ZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbY29yZV0gVXNpbmcg Q29BUCBmb3IgUDJQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBUaG9tYXMsDQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldoYXQgSSBhbSBsb29raW5nIGF0 IGlzIGEgc2l0dWF0aW9uIHdoZXJlIEkgaGF2ZSB0d28gbm9kZXMgZWFjaCBoYXZpbmcgYSB0aW1l LXZhcnlpbmcgcmVzb3VyY2UuIEJvdGggd2FudCZuYnNwO3RvIHB1c2ggdGhlIHN0YXRlcyBvZiB0 aGUgcmVzcGVjdGl2ZSByZXNvdXJjZSB0byB0aGUgb3RoZXIgbm9kZSB3aXRoaW4NCiBhIGNvbW1v biBhcHBsaWNhdGlvbiBjb250ZXh0LiBIb3dldmVyLCB0aGVzZSBleGNoYW5nZXMgYXJlIG5hdHVy YWxseSBhc3luY2hyb25vdXMuIE1heSBiZSBJIGNhbiB0aGluayBvZiBpdCBtb3JlIGxpa2UgYSBj aGF0LiBBIHR5cGljYWwgY2xpZW50LXNlcnZlciBvciBvYnNlcnZlIHJlbGF0aW9uc2hpcCB3aWxs IG5vdCBzZXJ2ZSB0aGUgcHVycG9zZS4gQWN0dWFsbHkgYm90aCBzaG91bGQgaGF2ZSBhIGNsaWVu dCBhbmQgc2VydmVyIGluc3RhbmNlDQogcnVubmluZyB1bmRlciBhIGNvbW1vbiBhcHBsaWNhdGlv bi4gVGhlbiBlaXRoZXIgZWFjaCBjYW4gKm9ic2VydmUqIHRoZSBvdGhlciwgb3IgY2FuICpwb3N0 KiB0aGUgb3RoZXIuIFRoYXQgaXMgaG93IHdlIGNhbiBkbyB0aGF0IHdpdGhvdXQgYSBjZW50cmFs IHNlcnZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPklmIG15IHVuZGVyc3RhbmRpbmcgaXMgcmlnaHQsIGFjY29yZGluZyB0byBDb0FQ IHNwZWNpZmljYXRpb24sIHRoZSBub2RlcyB3aGljaCBjYW4gaGF2ZSBib3RoIHNlcnZlciBhbmQg Y2xpZW50ICh0byB0aGUgb3JpZ2luJm5ic3A7c2VydmVyKSBhcmUgJnF1b3Q7aW50ZXJtZWRpYXJ5 JnF1b3Q7IG5vZGVzLiBUaGUgb25seSBleGFtcGxlDQogb2YgJnF1b3Q7aW50ZXJtZWRpYXJ5JnF1 b3Q7IGNvbnNpZGVyZWQgaW4gdGhlIHNwZWMgaXMgdGhlIHByb3h5IG5vZGUuIEJ1dCwgYW55d2F5 IHRoZSBzaXR1YXRpb24gaW4gdGhpcyBjYXNlIGRvZXMgbm90IGNvbmNlcm4gd2l0aCBpbnRlcm1l ZGlhcnkuIEJvdGggYXJlIG9yaWdpbiBzZXJ2ZXIgYW5kIGVuZC1jbGllbnQgdG9nZXRoZXIuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J cyB0aGVyZSBhbnkgc3RhbmRhcmRpemVkIG1lY2hhbmlzbSB0byBoYW5kbGUgdGhpcyBzaXR1YXRp b24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaGFua3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBBcHIgMSwgMjAyMCBhdCA1OjMy IFBNIFRob21hcyBGb3NzYXRpICZsdDs8YSBocmVmPSJtYWlsdG86VGhvbWFzLkZvc3NhdGlAYXJt LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlRob21hcy5Gb3NzYXRpQGFybS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIEFiaGlqYW4sPGJy Pg0KPGJyPg0KT24gMDEvMDQvMjAyMCwgMTI6MzEsIEFiaGlqYW4gQmhhdHRhY2hhcnl5YSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5hYmhpamFuLmJoYXR0YWNoYXJ5eWFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJy Pg0KJmd0OyBJcyB0aGVyZSBhbnkgc3RhbmRhcmRpemVkIG1lY2hhbmlzbSB0byB1c2UgQ29BUCBm b3IgYSBQMlAgY29ubmVjdGlvbj88YnI+DQo8YnI+DQpOb3Qgc3VyZSB3aGV0aGVyIFJGQyA3NjUw IHdvdWxkIGZpdCB5b3VyIG5lZWRzIGJ1dCB3b3J0aCBoYXZpbmcgYTxicj4NCmxvb2sgLS0gaWYg eW91IGhhdmVuJ3QgYWxyZWFkeS48YnI+DQo8YnI+DQpjaGVlcnM8YnI+DQotLTxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlz IGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28g YmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhl IGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQog b3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91 LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+LS0NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCBCbGFjayZxdW90OyxzYW5zLXNl cmlmIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCBCbGFjayZxdW90OyxzYW5zLXNlcmlmIj5BYmhpamFuIEJoYXR0YWNoYXJ5eWEsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsIEJsYWNr JnF1b3Q7LHNhbnMtc2VyaWYiPlRlY2hub2xvZ2lzdCBieSBwcm9mZXNzaW9uIFtJb1R8IEludGVy bmV0IFByb3RvY29sc3wgNUddPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwg QmxhY2smcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwgQmxhY2smcXVvdDssc2Fucy1zZXJpZiI+QWJoaWph biBCaGF0dGFjaGFyeXlhLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCBCbGFjayZxdW90OyxzYW5zLXNlcmlmIj5UZWNobm9sb2dpc3QgYnkgcHJv ZmVzc2lvbiBbSW9UfCBJbnRlcm5ldCBQcm90b2NvbHN8IDVHXTwvc3Bhbj48L2k+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7DA395A70A3E4EC79F2AD37FDEA2AB5Cericssoncom_-- From nobody Mon Apr 6 04:47:15 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E683A0F71 for ; Mon, 6 Apr 2020 04:47:13 -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 n3IMoDNd_e3b for ; Mon, 6 Apr 2020 04:47:11 -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 228813A0F70 for ; Mon, 6 Apr 2020 04:47:10 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48wpfz5dlJzysM; Mon, 6 Apr 2020 13:47:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Mon, 6 Apr 2020 13:47:07 +0200 Cc: core X-Mao-Original-Outgoing-Id: 607866427.135388-8334f518b4853badf555743462f0eb85 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> To: Abhijan Bhattacharyya X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 06 Apr 2020 11:47:14 -0000 Hi Abhijan, > On 2020-04-05, at 14:16, Abhijan Bhattacharyya = wrote: >=20 > Probably what can be standardized is a method for signalling and = exchanging the ICE candidates so that end nodes can mutually push the = data to the other.=20 Have we already established that you do need ICE? I agree that in a NATted, IPv4 environment ICE is a good way to obtain = useful address pairs. Can you run your application in a clean IPv6 environment? Then you don=E2=80=99t need ICE; everything just falls into place. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 6 04:52:31 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B803A0F7B for ; Mon, 6 Apr 2020 04:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, 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 I2aLSd-w8p0X for ; Mon, 6 Apr 2020 04:52:24 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2061.outbound.protection.outlook.com [40.107.20.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 B5E093A0F7D for ; Mon, 6 Apr 2020 04:52:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UYXbNPkdqZf1aDMZ2ZWgtF+bn4/QZ0b7QablfXHCEeBXdTVT+OZVrSA5tN+wbyeJwwwEXwCfKbsv3cYZ9m+tXuev8zW+JzdqctrXUxxXr7+zEaTVWb0T2tf40qOyZLYPVJWqCkZBbBMOJGAiMzEKGt36NbwBwE9IRJWHLXoediS8tEZkz1cdhfTNFUA7vpxMxV9WKk18hWwmG93RZsZSvkCfXIa4Fhq0B7r0k8pLmQNDXbSyURwQccIeJaNtEcP6emO5WwfqBKLximZ2ehXvag1Zh4Io2hbeYlONWe7w4rvthg++otXO9yAP+6M3H/F19sjVdE7ArKyucN8YUX+d9w== 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=HyqwGeTB077M4aX/lBqXawbBBead7O5I4Pe8Z/vCwqo=; b=RFdUNt5BKMyz5S0c0euEpGQWTvCE09mM9OT5UoQHeO9EmXbiBLOY3oLwCc8maZlpYUV/CizUdyCDC4vR+NQo4R8hLbWLFi9i5zrEfyhvaAi0H+jenNUVQjQATWRgYDcW3CjiBW1QWDPMprTW16uNwvSeV8WVrvuSX0lC/NbLeeImMjazBDBF7AweIc+sXhhQPMoVkJN6NAT75fHYxfm3O42FCi7fkh6myg3Z8d91gZLQro/6KTqJwc/QYe3ifj3uu0L/tcEyqshMtcz9UAcUU3gVm48NkcuXm93ERCuyAl8Mrlu3fKtGaBMlxDaXY1Y22LEjma/KWaot+RpKahAzgQ== 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=HyqwGeTB077M4aX/lBqXawbBBead7O5I4Pe8Z/vCwqo=; b=rFYVQTI+AtBE2bdNUsvsvVqPv5Yja5ofMmx99WAv/7E4181P2IIv1eKGqGkz3Dn2PKPJgJmAb7b7d5S7+xM7CdA3VTPJiuj1KWV18FSL0u3YHOkVvhdSPNVnalfjzWUi+ERj3Wo6fyqGNADhbUWDPXIwsqMWR+eMi1FOMUxDtxs= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (52.134.82.159) by AM0PR07MB3875.eurprd07.prod.outlook.com (52.134.82.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.12; Mon, 6 Apr 2020 11:52:21 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::57b:b81e:33ec:5512%7]) with mapi id 15.20.2900.012; Mon, 6 Apr 2020 11:52:21 +0000 From: Christer Holmberg To: Carsten Bormann , Abhijan Bhattacharyya CC: core Thread-Topic: [core] Using CoAP for P2P Thread-Index: AQHWCMVROB2ppf3kDkGCzoMwIoGd3KhmXWeAgAEvGgCAAYynAIABXXMAgAGKDICAADPAAA== Date: Mon, 6 Apr 2020 11:52:21 +0000 Message-ID: <8012E8F3-F21D-455E-B888-24C996D9C509@ericsson.com> References: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 171002df-f63a-4c60-dc67-08d7da20f744 x-ms-traffictypediagnostic: AM0PR07MB3875: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(396003)(39860400002)(346002)(366004)(376002)(33656002)(4326008)(71200400001)(36756003)(6486002)(6506007)(66946007)(64756008)(66446008)(478600001)(6512007)(66556008)(66476007)(86362001)(5660300002)(76116006)(4744005)(2906002)(8676002)(26005)(186003)(110136005)(316002)(81166006)(81156014)(2616005)(8936002)(44832011); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PXqHvfYpma8l4dSqRIMv7y75rP/FryP9C/yeFW13cgNskzpH2uA5LQVnu8BXlcf06AzapdTicI0jR/rdYr74VCHNEew2nljbZBnQlX8eQxz9y7id5wrOq+IgqU2DufyWC/vQdydxSmoRJ2WC9qmQ8CQKtNIipNDacCKPoiMqqLzkTUFbHQQmGhSC0TP6zK6d9RjpD78s5S9ryvJreq5TBrdlvK6TJ3Z4wJxY4C8sRl9+VDT1EQTpT+Bl1ekcMVaJejO4ID34gaNaATRJpi9jY5RPnqCwRuINemEAyiw07LlHoD0nuTkUGCdrclVuNva5fDInJTiI4t0nUijycpwcaxdOOURdpEYBDLUNuGh/bbt2S13zrnCw2rbXvVSwS5wOPsjmbRsTtet6BJMs+wNkU6bJ1SB2MJTfRitHGBmpmssDZ6tYl0+9MyLTwT4uOHw3 x-ms-exchange-antispam-messagedata: UnDYOaoD4IjqEb8Adg3/nTx57I6xKHkJujX7QnghcsV6A7t4PPPBIOGZgCPxNWwYHjtA9+dj2g0rM6ov5ZCZvWJplnLsgv186+sj1ue1B2Bd2WJBy3jdMbGsnno2IAdTzeKpxNjeKx1ZgkzVKLKazw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <215B95DD4D84F444AC565F6205E35A9F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 171002df-f63a-4c60-dc67-08d7da20f744 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2020 11:52:21.7568 (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: qqXpvRkJzjz9zAXcNvd+MdQoGL+OcgkZqYlKlabHXY3Wjet844a2KrBcf4/fbXJ9laplLoZnWSZeYQhRsogRJfTVBokvogxaRb5zzfFenIo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3875 Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 06 Apr 2020 11:52:29 -0000 SGksDQoNCiAgICA+PiBQcm9iYWJseSB3aGF0IGNhbiAgYmUgc3RhbmRhcmRpemVkIGlzIGEgbWV0 aG9kIGZvciBzaWduYWxsaW5nIGFuZCBleGNoYW5naW5nIHRoZSBJQ0UgY2FuZGlkYXRlcyBzbyB0 aGF0IGVuZCBub2RlcyBjYW4gbXV0dWFsbHkgcHVzaCB0aGUgZGF0YSB0byB0aGUgb3RoZXIuIA0K ICAgID4NCiAgICA+IEhhdmUgd2UgYWxyZWFkeSBlc3RhYmxpc2hlZCB0aGF0IHlvdSBkbyBuZWVk IElDRT8NCiAgICA+SSBhZ3JlZSB0aGF0IGluIGEgTkFUdGVkLCBJUHY0IGVudmlyb25tZW50IElD RSBpcyBhIGdvb2Qgd2F5IHRvIG9idGFpbiB1c2VmdWwgYWRkcmVzcyBwYWlycy4NCiAgICA+Q2Fu IHlvdSBydW4geW91ciBhcHBsaWNhdGlvbiBpbiBhIGNsZWFuIElQdjYgZW52aXJvbm1lbnQ/DQog ICAgPlRoZW4geW91IGRvbuKAmXQgbmVlZCBJQ0U7IGV2ZXJ5dGhpbmcganVzdCBmYWxscyBpbnRv IHBsYWNlLg0KDQpJIGFtIG5vdCBnb2luZyB0byBnZXQgaW52b2x2ZWQgaW4gYSBkaXNjdXNzaW9u IGFib3V0IHRoYXQsIGJlY2F1c2UgaXQgaXMgbm90IENPUkUgc3BlY2lmaWMsIGJ1dCBJUHY2IGlz ICpOT1QqIGdvaW5nIHRvIHJlbW92ZSB0aGUgbmVlZCBmb3IgTkFUcyA6KQ0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQogICAgDQoNCg== From nobody Mon Apr 6 05:13:32 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63793A0FD2 for ; Mon, 6 Apr 2020 05:13:29 -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 oiMXBOWxTxhr for ; Mon, 6 Apr 2020 05:13:26 -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 1CA4E3A10A4 for ; Mon, 6 Apr 2020 05:13:08 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48wqDy5KDQzys2; Mon, 6 Apr 2020 14:13:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <8012E8F3-F21D-455E-B888-24C996D9C509@ericsson.com> Date: Mon, 6 Apr 2020 14:13:06 +0200 Cc: Abhijan Bhattacharyya , core X-Mao-Original-Outgoing-Id: 607867986.2101001-b0c43071fbf4ba82bd33711d5d3a3d31 Content-Transfer-Encoding: quoted-printable Message-Id: <99FAF8E8-D93B-4AAC-919D-BEC9F614ED28@tzi.org> References: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> <8012E8F3-F21D-455E-B888-24C996D9C509@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 06 Apr 2020 12:13:30 -0000 On 2020-04-06, at 13:52, Christer Holmberg = wrote: >=20 > I am not going to get involved in a discussion about that, because it = is not CORE specific, but IPv6 is *NOT* going to remove the need for = NATs :) Of course not, IPv6 is not removing IPv4=E2=80=A6 :-) (That=E2=80=99s why I talked about a =E2=80=9Cclean=E2=80=9D = environment.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 6 05:32:00 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8EA3A0B55 for ; Mon, 6 Apr 2020 05:31:58 -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 OiVJykBH63zZ for ; Mon, 6 Apr 2020 05:31:57 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 8710D3A0B54 for ; Mon, 6 Apr 2020 05:31:56 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id cf14so18927147edb.13 for ; Mon, 06 Apr 2020 05:31:56 -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=0E5cuvCUbbeA5Ht7VOiH3h94B/JEmEPBcvp4l8IhlVc=; b=j1rSsX+FYWwmBHoMBT2Boh17iC+IxwUQVqAzT/di8/ldJvOtzPK5ry0lZJhhsq1CQ0 oYYepIphsxX1SvGVSE8qv/+2R79orxTGZLqoUnUaJ+EImE1X10oGL/qA/8cDnnw1TtBY P7fokjrNJDveVVM4cWr7I3pSE3QlMsAHvsDRjDI2DHeu/kTaDuQQ+0YuR4GgDIMqrX2i GnAhrp6fc7cKr1DzI0w2GMv0XdPdI6VspbKV8FBGnqlv8utxesGmJ+IywM19KvB1nQQJ iMj+2rv1hX/uxNhsoFt1hT7Bs2XG0LUf1yQL5jf/ocPm49p+DwXZykpOVcjxAOywh8oz E+vQ== 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=0E5cuvCUbbeA5Ht7VOiH3h94B/JEmEPBcvp4l8IhlVc=; b=AJUDLmDH8OnXqsZ59kti4pRgP3AKvtgfrQAsbBDjhGybVarZnefHjG2B4bHhIICHGf BVqmyFM4449O1JGQE16HgfQTVBgpxfKvJYUWZn1vHnNiGllW1jwOQ4n+8aUDjHF5T3k8 mdvdIiRypaTPaJ1mTPh5S2utyoWBl4s5IR1OImfNUntcn1YVtBCNaniVgRmUoegS/CmD NtuuQYTqtrkLzO47T9c8Qosjh/4XeJ1DUxoz0eeDuJqfRwesIPSCj35BYY3j+PsQmpI+ WenVyb5DYQC2QRJItVI3Aic9UcbA2pqSRjX32CtY2tOwBPRAzLN7jLMfH2AzCHTXa1jm Mqiw== X-Gm-Message-State: AGi0PubcEmSzPvOIoEfZl0Q4F8UHT8fMTI5FLAgrMgrw2eaftzU9dQ2H uG8CpJxEN4TQ2jh2vMiUtJEt7UCox5cTQrXboIQ= X-Google-Smtp-Source: APiQypIXYY1Ox3B/VvRrnppegGvD0ABqDd9NnIMpQY9i0Nf+qFybHpYlPIi9VA7UXlx9/0LM5FVRSt/H3UmXR8I0wfY= X-Received: by 2002:a17:907:20ad:: with SMTP id pw13mr14524665ejb.9.1586176313295; Mon, 06 Apr 2020 05:31:53 -0700 (PDT) MIME-Version: 1.0 References: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> <8012E8F3-F21D-455E-B888-24C996D9C509@ericsson.com> <99FAF8E8-D93B-4AAC-919D-BEC9F614ED28@tzi.org> In-Reply-To: <99FAF8E8-D93B-4AAC-919D-BEC9F614ED28@tzi.org> From: Abhijan Bhattacharyya Date: Mon, 6 Apr 2020 18:01:42 +0530 Message-ID: To: Carsten Bormann Cc: Christer Holmberg , core Content-Type: multipart/alternative; boundary="000000000000b4851b05a29e7387" Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 06 Apr 2020 12:31:59 -0000 --000000000000b4851b05a29e7387 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carsten, Considering the practical deployment possibilities, I think we are quite far from expecting a clean IPv6 path. My home broadband service provider still serves IPv4 only. :) Apart from that there may always be some firewall in place considering enterprise use cases and we would need to punch a hole. Thanks. On Mon, Apr 6, 2020 at 5:43 PM Carsten Bormann wrote: > > On 2020-04-06, at 13:52, Christer Holmberg > wrote: > > > > I am not going to get involved in a discussion about that, because it i= s > not CORE specific, but IPv6 is *NOT* going to remove the need for NATs :) > > Of course not, IPv6 is not removing IPv4=E2=80=A6 :-) > > (That=E2=80=99s why I talked about a =E2=80=9Cclean=E2=80=9D environment.= ) > > Gr=C3=BC=C3=9Fe, Carsten > > --=20 Regards, Abhijan Bhattacharyya, *Technologist by profession [IoT| Internet Protocols| 5G]* --000000000000b4851b05a29e7387 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carsten,
Considering the practical deployment possi= bilities, I think we are quite far from expecting a clean IPv6 path. My hom= e broadband service provider still serves IPv4 only. :)=C2=A0
Apa= rt from that there may always be some firewall in place considering enterpr= ise use cases and we would need to punch a hole.
Thanks.

On = Mon, Apr 6, 2020 at 5:43 PM Carsten Bormann <cabo@tzi.org> wrote:

On 2020-04-06, at 13:52, Christer Holmberg <christer.holmberg@ericsson.com&= gt; wrote:
>
> I am not going to get involved in a discussion about that, because it = is not CORE specific, but IPv6 is *NOT* going to remove the need for NATs := )

Of course not, IPv6 is not removing IPv4=E2=80=A6 :-)

(That=E2=80=99s why I talked about a =E2=80=9Cclean=E2=80=9D environment.)<= br>
Gr=C3=BC=C3=9Fe, Carsten



--
Regards,
Abhijan Bhattacharyya,
Technolo= gist by profession [IoT| Internet Protocols| 5G]
--000000000000b4851b05a29e7387-- From nobody Mon Apr 6 06:31:57 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE853A1AEF for ; Mon, 6 Apr 2020 06:29:16 -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, FREEMAIL_FROM=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 (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 AB7W_O0JGYz9 for ; Mon, 6 Apr 2020 06:29:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 11FEC3A0408 for ; Mon, 6 Apr 2020 06:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586179443; bh=ty5zdqNF6QPaZ25vCD36CvlEdTmx/IRfL53jb5a/Kas=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=ENgdS+OMBs23QJ/f83v4SQKc5qUCg2y5pCnZBshCTkeoiZEJltxJsF5gyrDQc22yK +0qTKnG/s7V3v03tnREGhOJvJ0f0N4rAeXOS4pLMEFmMbyTMzbI2rcGnJHRBhMyWQJ btpdHx3gVtx2hkDWrN/LHLhirBpFIYbEs8GgNzuU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([178.2.223.124]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1McpNy-1ilq403vqU-00ZyRZ for ; Mon, 06 Apr 2020 15:24:03 +0200 To: core@ietf.org References: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> <8012E8F3-F21D-455E-B888-24C996D9C509@ericsson.com> <99FAF8E8-D93B-4AAC-919D-BEC9F614ED28@tzi.org> From: Achim Kraus Message-ID: Date: Mon, 6 Apr 2020 15:23:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:k5JiM23URU19OqeZeCKghO7fMJjan+tvzRk4yl+tQrkW1R/NAO3 gBej7cpyemHgMlrS02vR+bFdFkuWa5HlMTlFbaua+jSD96D95Un5Q8rsc+Ml3MmEEWTiRmO Kkhz97q6hUo5gq75Ly7lZAcNVcY6/WBExqdXljTDXLizEdx929ELatoDB4sVCgvXCDhISx0 mCF01xUN2DpjbDZ8ZYIGw== X-UI-Out-Filterresults: notjunk:1;V03:K0:rH7672brutg=:kPhroG57G/infB5/1XC1ab SUDtmllnKuwrLOnIGyY3jTexOhHHJMSnIi7FWRJbbh6HfRGgn8lBAVnBeoAZgQYFnu5tTGAb+ h/zbX/Bepz3FRrdcm/2qaSCp2tUNEnwNI5+fA56JCflk8nKDH7ERKGvn8GGBqNu0pjTEOOln2 zij09fszTF1cjH5GT0VrJIeLLTCiAgXAxGq9plaoBLLeB1i+M7izFPaiApFPM5O9Gj/gEqJxz JAsRds8nOdxksH5sJdK218w2JjA2M5dQDiof/M+BvTLeDeYcdMC8y6frxVUbEY0hX3GoPd6Ff 42kTV4m/bmARO9HrBecQp6njVUKdQXiuHscihbffFua3kuKnpIuVToxsbgniqom9mrL9gqwsu VIMlv7ouv6hgQfcYHFJ4aNoUnIkeOmhUJkLr3eqPA0ai2fgxHJu/MiS0W36TBia1IiWzxWS4n +Rt2WG+pI9PGUHQZgnSznpZiiWZIXbYVmnXAjTiF9jAXZN0g/lZI++LDc9C0IqTEvf4sSTRsp RFF1TuUckrFJ277Du6wDGr7/jJVnaA6U+s3m9JPuaxslVhsLOqdbsmaR31yIIi7KDR9hYdIIQ wqNiFuzPwGzmZ7+l5EPKjFyfw+ASXGz+eZ04+hUA6vSVEY08HfbXZptAXHQxQh//G5GeqpABf ESD5QrETFVyBzAW29gnoZ7Tx+rIzW/bz94r2CaD+x0atsl96iWSGDCPAR6kTRjJ0FaWEJcCkp kHQQB6eRCJ6vsC5LIglGg6t+BVaTEVAvLTtImPo9J0EmtXgq9O8tnPHpld5RQVoIOLTa1/bDt K0gPQrPKwgnyObRESIo2GE68Nb8g2OMp7A22D26j5RWMCBhtOoQrLgj2yjpirNkukGYwR2Q2n K4jQWkH0j0ZApXZVUf964MtnmsWMLpw4XV3JIfwkT2IOdiDTGrXLGc9J+KWBm4eocM9MV8l22 6afwPKTOv43IOj+JmBN7/2LvxC8OsF2iuFqL8nAVTJjfRlt20nidPSabis+ZUdRL3mFe5da44 X7GY5LfwemYVvqRAfcK9yyqa5Qh+CcaAfyH0dMd6UhYslxGcsJ9o8uWkna8az3MUhrYUrZsZ1 hSLGMygRhFZ1OgNKxO2GhN+UfILFEAowpDTywQzXjTi3aKElYbto+7b1sBgQImlO7ba/72SDE 5Jk2ZnxheZYZs7hFf4K8nVh2WxffrSpWlFisRVKiN4kVm31qPFhNMMAhFUPko+UIHnop9ls4B jrC1h0blW1XLOhDOO Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 06 Apr 2020 13:29:21 -0000 Hi Abhijan, in my experience it's not about IPv4 or IPv6 (and the feature assumed to be included with both technologies). It's about the nature of the network you use for your peers to communicate. CoAP over UDP (also over DTLS/UDP) works without the need of additional parts, if your peers can exchange messages using UDP. So, is that network your peers are using fully under your control? As a home-network maybe considered. So, you know, if your peers have static or mainly static addresses. And there is nothing on the path between your peers, which may block or modify your traffic? Then you have a very good chance, that you don't need something additionally. But, if your peers can't reach each other without additional parts, e.g. because both in "their home network" and so communicate over a path, which uses a "public internet link", then you need more. Therefore, please try to describe first the network(s) and the communication paths you plan to use for your peers. best regards Achim Am 06.04.20 um 14:31 schrieb Abhijan Bhattacharyya: > Hi Carsten, > Considering the practical deployment possibilities, I think we are quite > far from expecting a clean IPv6 path. My home broadband service provider > still serves IPv4 only. :) > Apart from that there may always be some firewall in place considering > enterprise use cases and we would need to punch a hole. > Thanks. > > On Mon, Apr 6, 2020 at 5:43 PM Carsten Bormann > wrote: > > > On 2020-04-06, at 13:52, Christer Holmberg > > wrote: > > > > I am not going to get involved in a discussion about that, > because it is not CORE specific, but IPv6 is *NOT* going to remove > the need for NATs :) > > Of course not, IPv6 is not removing IPv4=E2=80=A6 :-) > > (That=E2=80=99s why I talked about a =E2=80=9Cclean=E2=80=9D environ= ment.) > > Gr=C3=BC=C3=9Fe, Carsten > > > > -- > Regards, > Abhijan Bhattacharyya, > /Technologist by profession [IoT| Internet Protocols| 5G]/ > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Mon Apr 6 06:43:00 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307543A05A0 for ; Mon, 6 Apr 2020 06:42:54 -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, FREEMAIL_FROM=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 QmyKrL82HOwe for ; Mon, 6 Apr 2020 06:42:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2848A3A0597 for ; Mon, 6 Apr 2020 06:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586180540; bh=6KrFcsgkM8NOviWHJ+ylWeGRpwQ2SRUcML61FkfpTCw=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=AoSauWUkaCKkzesUuZOJH6k8bEXb67OruPME1u5U39GfFQbDcokm1cuqSas6BcTC+ CL+ogG5kL1D6Kony4kLJIZiODD7XCG79Zo3uAmKfNqvnMf3HGuyCkiZof9R+DKsx8T SEVHsxM1Wope2vB2WZ1lpVNJEPit2Ka9IS/iHg24= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([178.2.223.124]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N49hB-1jCXy12INN-0103fm; Mon, 06 Apr 2020 15:42:20 +0200 To: Jim Schaad , 'Esko Dijk' Cc: core@ietf.org References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> <02ec5628-3f7d-ff5d-620c-c0a90a4b89b0@gmx.net> <020701d60907$fb3ba720$f1b2f560$@augustcellars.com> <02c601d609e0$e0afcbf0$a20f63d0$@augustcellars.com> From: Achim Kraus Message-ID: <85fcff3a-0ce6-f255-c023-d5b49cd3589b@gmx.net> Date: Mon, 6 Apr 2020 15:42:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <02c601d609e0$e0afcbf0$a20f63d0$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:m3/cL+cuOBrZBNvQ/AHneqXbJTlnFBDJ+khPMpAKV25aRDO43Oq jAx1F5JpNOmxVp0WBrMupuBf775noYAL4DI6T088fGK3tvuniLqR2dvR4e0lXQ7o7Unp8bS kgxOuj8tqsAQIbfJ8gbkcor1Jr6MgZOiIOaq2V4NSDGrdCKzLtnYUQVT8wzJORUW2OhzdK9 78QAPZ2ujIefW35W8Rt3Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:1/15FwVw9RE=:V3ESoxjn9diu5EjsVLMHVe wRiZH01kQJszzgi+wHvGsVe+XdN2f66LugElRj0W/5kpFt/XX8uF0vQuFYsIUl7uHU4uVY2Jf PUqkoYbR3tURtfNSqc/5DCHRNacxsu6UxlFikWRFK2hzth3h0lEagNhK5T1A5FB+cEEcs0OBB /5P0KzBGJymtwzc3XrFn9LFbc0q0awpaipfItNccl5fDYHA190yuYpeG6PP1PjRl6dnOWlcFn j0wQose+cQEdGyCgaItbLsx8BW7LNrNavhXhds+VuMdlyq1L19Ql0WTtAVLac9uZlJRYfB97o ZIIXIoB+GXBiL8fwN3Dmkj/70RrYDIOOtJsFix/6KJn/TlacVWcgxyIdQqok4DBuqpcUvzkTy RW5DQNSy2dPqtVqNUk3Y7mWVMIc3zJOAJxjZhlrur4RlYlm0h8jtIHyt4akEgvDpNCx5U/hJL elz1uu2h3V4bEq6PLZD1DwvXPQWV36T6qwp0aeNoBlpJPByb8fI0qBZSLfF1czOoX6bso2SsY HQueRNQpCSAVKC3/FfPrePxtGsCEF57s2u5a8D7JzuFR1bF4pAod7l9PtWiP7gUs0T/2m4Mh4 lXP4+jkJ5i1BzyE7YnC6FQfM7MUVH5biJ8wRMST8swtAlJGZbmbBlGhOOv59gdBxkt1RYx7mT 1vvVRzCvl6oLFdFD5/NSSgNpj0uRrNDtyk8ZCngpslxn8BGJNxbQVZ1QG+LlVW8W+TSAaaUPw Oxbx2gh+9IHCVMl3E6LGnxoL0mhf2jwF1DQ7l73QRIDQ3sR9dEdQVfGqC7Br4j3T0VHE/EvMV SPE5UBVpWM04Qax2PlqsCUtZi7POJc8PDAEp91ygyBuaQjoXcHKjKE+16YKX0a53LHOeaQVUu 9B1pdgSDHojfN1gILnjeeiwm5ahhHmOSEls1dDdft998E/c4zKgbKd2JliqVx3/zGUaYfT6Or uDRkR86nHN773/ShU24bcCZnCPF9aPfGarDIjj1drDMZEvXoBBUyIYjtbRcIqM1I9gluDtBoW 8Dr7q/tbosfY8FZ++dmDJePokszQtnWQYwYV7BsvdtDonpx7YJDUBP/8iDk332Le61M9dsFca Zqzju43ARGBtiHTmezVU4zCM02dhUaOxSvwy2EfiD90lvhOjkpr8N8Os6LUZ9uVumbptn8dVm vU41LuQKIFrYRshculbBKcm4FiQhSOYs3tgf4SvR9qTIZHbEqHkqwgtkLUsxYZsvHFPYI55ul FwM1VggvgL2PWtxE1 Archived-At: Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top 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, 06 Apr 2020 13:42:55 -0000 Hi Esko, Hi Jim, as I promised to Jim, I spent some time over the weekend to investigate more about the java-multicast features. A prepared a Californium PR with my results. Generall I still feel, that it is much easier, to use a differnt ports for multicast and unicast, than to try to use the same port for multicast and unicast simultaneously. Over the weekend I failed frequently, sometimes it ended even in situations, where the multicast request reaches all endpoints (multicast and unicast) and the deduplication then got activated. It's not even easy to see, if the server really differentiate between unicast und multicast reliable. On my experiments it first shows as "random", if the response indicates a unicast or multicast request. Then I found, that the request was delivered to all endpoints and just the first response was also used for the other requests. When I introduced a warning in the deduplication, I saw much more frequently, that the setup is still broken or got broken again. Therefore I would consider, that using the same port requires intensive test or much more guidance how to setup the multicast endpoint in order to work reliable. So I'm everything else than sure, that the current setup in Califonium will work reliable for different OS and java versions. We will see. Somehow my personal feeling is, that other protocols don't distinguish the processing of received records based on receiving them via unicast or multicast. If so, that pattern using a different ports for multicast and unicast in order to reliable distinguish between multicast and unicast, would be easier to support. best regards Achim Am 03.04.20 um 19:54 schrieb Jim Schaad: > > > -----Original Message----- > From: Esko Dijk > Sent: Friday, April 3, 2020 5:38 AM > To: Jim Schaad ; 'Achim Kraus' ; 'Thomas Fossati' ; 'Klaus Hartke' > Cc: core@ietf.org > Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Laye= r, page 67, top > > Hello Jim, > > Could you clarify your point further? > - what is a bad idea - having a dedicated port with dedicated for handli= ng multicast requests? Or the subsequent "internal routing" of the reques= t to the unicast server at a different port? Or both? > [JLS] I think it is a bad idea to use the port number as a means of dist= inguishing multicast and unicast message. If you do something like this= completely internal to your own code, then it is an implementation detail= but would not map to any type of text for an IETF document. > > - what is a "multicast channel" , do you mean an endpoint bound to a mul= ticast address ? > [JLS] I use the word channel because it maps from my code base in many w= ays. A "multicast channel" would map to an endpoint bound to a pair. An analogy for those of us who are really old would= be to consider UHF and VHF on your TV to be different multicast addresses= , but you still need to choose the channel number (port number) in order t= o get a flow of information that is usable. The analogy of course breaks d= own because you cannot send information back to the TV stations. > >> some resources may only want to be on a single multicast address even >> if the server is listening on multiple unicast addresses > > Sure, you can also have a dedicated server on say port :9999 that listen= s to multicast destination addresses only, because it is bound only to a m= ulticast address not a unicast address. This dedicated server can then han= dle resources that only are to be accessed via multicast. > But in this case, there's no "internal routing" needed to another server= inside the node because the resource is only hosted at say port :9999. > [JLS] You can have a dedicated server on say that= lists for multicast traffic. You always have the address and port as a p= air. > >> The IP address is different for a multicast vs a unicast message >> received at the server. This needs to be the distinction > > But the case the Achim indicated is that the server may not be able to d= etect whether a request came in via unicast of multicast. So this cannot b= e the distinction, e.g. in the following case: > 1) CoAP server at port 5683 is bound to unicast address U > 2) at same node, same CoAP server at port 5683 is bound to multicast add= ress M > [JLS] If this is really true, and I am not sure that I believe that to = be the case, then the JAVA library is completely broken and needs to get f= ixed. The fast look that I had at the JAVA library looks like you need = to create a distinct socket for every pair that you are de= aling with. I think that should give you all of the info that you need, b= ut like I said, I have not done the JAVA programming itself. > > Now in this case if a request comes in via multicast group M destined t= o port 5683, the server handling this cannot tell whether it was unicast o= r multicast. And if a unicast request comes in to destination address U an= d port 5683, the server cannot tell also whether that was unicast or multi= cast. > [JLS] What is the address that is associated with the port number? You = cannot have a bare port number you also must have an IP address. The IP a= ddress is how you distinguish unicast/multicast. > > [JLS] Jim > > By setting it up like this instead that problem is avoided: > 1) CoAP server at port 5683 is bound to unicast address U > 2) at same node, same CoAP server at port 9999 is bound to multicast add= ress M Then the server at port 5683 treats everything as unicast. (Because= it is not bound to a multicast address, it won't receive any multicast re= quests directly.) And the server at port 9999 treats everything as multica= st. (And this endpoint 9999 handles most requests by internally redirectin= g to server :5683, but only for those resources where multicast is allowed= . Some request for multicast-only resources it can handle itself directly.= ) > > So the above "workaround" seems handy for cases where a server at one sp= ecific UDP cannot itself determine the endpoint the request came in from (= could be either multicast like M or unicast like U). > > @Achim maybe you could comment if I've understood your use case properly= . To me the above seems more secure than trusting that a client will incl= ude a "This is multicast" CoAP Option in an honest way, which could easily= be misused. > > thanks > Esko > > -----Original Message----- > From: Jim Schaad > Sent: Thursday, April 2, 2020 18:02 > To: Esko Dijk ; 'Achim Kraus' ; 'Thomas Fossati' ; 'Klaus Hartke' > Cc: core@ietf.org > Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Laye= r, page 67, top > > Esko, > > That idea strikes me as a very bad idea. If you build your code on thi= s basis you will fall over the first time you come across a multicast chan= nel which uses the same port as the unicast server. The IP address is di= fferent for a multicast vs a unicast message received at the server. This= needs to be the distinction as well as the fact that some resources may o= nly want to be on a single multicast address even if the server is listeni= ng on multiple unicast addresses. > > Jim > > > -----Original Message----- > From: core On Behalf Of Esko Dijk > Sent: Thursday, April 2, 2020 1:23 AM > To: Achim Kraus ; Thomas Fossati ; Klaus Hartke > Cc: core@ietf.org > Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Laye= r, page 67, top > > Hello Achim, > > (see also my response to Jim) > Using the UDP port number to detect a multicast request vs a unicast req= uest sounds like a good use case. Just curious - I assume the security asp= ect requirements of RFC 7252 are taken care of in this use case? > > That is, a proper client sends its multicast requests always to port :99= 99 and the server treats these as multicast requests (e.g. only allow the = request for specific resources). > A malicious client may sends its multicast request to port :5683 to bypa= ss the above checks. I assume the server doesn't respond to this request, = because the multicast address is not bound to port 5683 but to say 9999 on= ly. > If the CoAP server at port 5683 cannot distinguish between unicast/multi= cast that would be a bad situation and the security requirements of RFC 72= 52 are not met. > > Esko > > -----Original Message----- > From: core On Behalf Of Achim Kraus > Sent: Wednesday, April 1, 2020 22:28 > To: Thomas Fossati ; Klaus Hartke > Cc: core@ietf.org > Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Laye= r, page 67, top > > Hi, > >>> +---------------+ +-----------------+ >>> | | request _|_ | >>> | | .---> / \ 224.0.1.187 | >>> | _|_ / \___/ --. :9999 | >>> | 192.168.0.1 / \ ---=C2=B4 | \ | >>> | :54321 \___/ <---. _|_ / rewrite | >>> | | \ / \ <-=C2=B4 | >>> | | `--- \___/ 192.168.0.100 | >>> | | response | :5683 | >>> +---------------+ +-----------------+ >>> Client Server > > Nice diagram. > >> Not sure why you would also want to rewrite the transport endpoint? > > I tried to follow the discussion. > The idea to change the port as well enables java (and I guess some more)= to differentiate between multicast and unicast requests. Jim also mention= ed, that it enables the use of multiple servers on the same host. > I have not enough experience with multicast in different environments to= see, if that may cause more trouble (e.g. firewall etc.). I would guess, = that some implementations will just offer that variant, at least as confi= gurable option (I would try do so for Californium). > So my favorite for now is just implement it and see, what the user's fee= dback will be. > > If that idea gets declined (may be by negative feedback of users), I sti= ll think, that there is a demand for other means to distinguish between mu= lticast and unicast requests. Maybe, either the usage of the uri-host opti= on or a new option will help. > > This maybe considered as "too pragmatically", but on the other side I al= so don't see the "great benefit" in insist not to change the port. > > best regards > Achim > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Mon Apr 6 08:15:48 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE55F3A09A4 for ; Mon, 6 Apr 2020 08:15:26 -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_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6XHkc9ysyEx for ; Mon, 6 Apr 2020 08:15:23 -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 C3BE03A07F8 for ; Mon, 6 Apr 2020 08:15:23 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 012B040146; Mon, 6 Apr 2020 17:15:20 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id E67E179; Mon, 6 Apr 2020 17:15:19 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:2d54:7976:cdc9:1eab]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 3D0A1367; Mon, 6 Apr 2020 17:15:19 +0200 (CEST) Received: (nullmailer pid 2696486 invoked by uid 1000); Mon, 06 Apr 2020 15:15:18 -0000 Date: Mon, 6 Apr 2020 17:15:18 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Esko Dijk Cc: Marco Tiloca , "core@ietf.org" Message-ID: <20200406151518.GA2688660@hephaistos.amsuess.com> References: <20200312155829.GA346418@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] New draft-tiloca-core-groupcomm-proxy on proxied CoAP multicast operation 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, 06 Apr 2020 15:15:27 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Esko, thanks for your responses, I'll add where I think there should be more discussion: > * Response-Forwarding: Is this expected to be extensible to any other > CoAP transport that may come up that supports multicast? The use of > CBOR tags seems to imply that, but then there's the question of how > the client would arrive at a URI for follow-up unicast communication. >=20 > Have you considered just using values that'd go into Uri-Host in a > follow-up request? >=20 > [GP] The use of CBOR tags was not on purpose to be prepared for future > transports. It was more re-using a convention that was already there. > But by doing it this way we are prepared for potential future > transports, in which something else than an IPv4 or IPv6 or MAC > address needs to be sent back to the client. > > The current encoding is expected to be more efficient than providing > an IP address as a Uri-Host string. The current encoding can also be > re-used in a Uri-Host or Uri-Proxy Option sent towards a proxy, > although the client needs to do some transcoding to get it into the > string format used by CoAP. > > If the client uses a direct unicast connection to reach the server > (maybe this use case is less common?) then it doesn't use the returned > IP address in the CoAP request; it will only use it in the destination > IP address of the IP packet that is sent and then having it in a > byte-by-byte format is quite useful. I see the point of not having to deal with the human-readable encoding; still I'd prefer more consistency with the return CoAP options. (And I agree that proxy-then-direct would be a rare case, though I can imagine cases). We might consider (possibly outside this document) the introduction of a Uri-Host-Binary option, which would be mutually exclusive with Uri-Host and 1:1 mappable (at any time by any intermediary) to the subset of Uri-Hosts that are IP literals and ideally compatible with the host.ip production of CoRAL. Then, a Response-Forwarding response option (or something from it, if typing stays or the below is added) could be used directly in the follow-up request as part of the request URI. By the way, as the topic of multicast responses from a different port has come up recently, how would those be expressed? > * Why is the information about the client being behind a proxy > forwarded? We don't to this in other proxying cases, and it just puts > an additional burden on the origin server I don't see a compelling > need for. >=20 > [...] > We opted for the current end-to-end solution to have the extra > information (in both ways) secured so the Proxy can't tamper with it. > (This works in combination with OSCORE.) OSCORE itself does not protect the address with good reason, one of them being that the actual OSCORE server might be proxied behind the node. If we let the proxy change the source address, there's no harm done to later communication (as the proxy can just as well send the messages somewhere else again). > * At some point, as a WG we will need to think of whether we really want > to have another option with Observe-like multiresponses; Block-wise > and Observe being the two extensions so early everyone knew from > RFC7252 they would come does put them into a special position. >=20 > [...] >=20 > [GP] The concept of multiple responses (by the Proxy) to a client's > request is already defined in RFC 7252 so it is not 'new' in that > sense. The use of the Options as we define it, doesn't change that > behavior. Indeed, but groupcomm (to which is referred for details there; similar in groupcomm-bis) says that this SHOULD NOT be done unless there is explicit configuration and the client. If we introduce this option here to be that configuration, this is what enables the behavior in the first place for out-of-the-box configurations. (That is still not saying I'm not OK with making this one of the two options that an intermediary may recognize as "expects more than one response", just looking to explore the space.) > Also in draft-ietf-core-groupcomm-bis we discuss the longer-lived > Tokens issue; so that's inherently present in multicast situations > (proxied or not). > > Maybe we could use draft-ietf-core-groupcomm-bis to define the more > general long-lived-token mechanisms? (Not sure yet what these would > be, in general.) For multicast that's good to have; a summary of cases ("expects one response", "expects arbitrarily many responses inside MIN_TOKEN_REUSE_TIME", "expects aribitrarily many responses as long as there's always an older almost-still-fresh response") might be material for clar-corr. KR c --=20 Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -- Terry Pratchett (attributed) --gKMricLos+KVdGMg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl6LR4MACgkQOY0REtOk veEKlhAAkEIMmUVQA1q71ygmpS9c9Bt3yR1BdQRQEwkMMAuwm/6UY/8m+0/nlUVH 53ZvhbvHIFcqzM+cHtCPIk00Okn6n2hmF9r3kaDuynkOmGO/5Y6MiigId8Cv/bEX pUvjTEDwyqS9ba27iglwUz5OJB5NVCnsbdZrHFNzJibHg4dzfZTGxAz/yKBQBFxd djQXK20P6g88tuCTjaHxeDpDc5HgG7yzpWiWpsAOxNk6Ha60+snIk2uwPb1s9ivY BMDYID73qx98RlHszrpHeqjcbksHhJwcOFKqcmbdOXfgtOY4Ct7hUVZe+1GRDX95 N/70Elz6pcJr5fxCzBGjuZ74OZqNzzZDp2xXdn++u/vzHqisX+di22710udHxk63 TGsjyK/t/rL+L6OraCyOu5uiemBB7ZxPFcmHF1zLw0ljpBio2WvMFMekjmkNA6g8 pJgd1d5KpWiTz9EHcginEhYRQLuyVRCZ/+oGIyQQ9I4ZKmPHGTg/p6HIwVIAM+xe c5xJEM2cSZ1xLqEMF35wWv0nL7SEBpdSsJ/W0dHgINaMi/t37/UboUcQ1Kwh5QKm vPxyIDgCEX0w6oScg+Pg6lG5pqH0t1PzaGI2fAGjSc+vkoi5Me0CRpXb7Gv8TVDA c9Pq/iio5cSMZ6DIT8kLKktTr4tBhhYndidnNGrTprWKMnyBwYU= =4Dmz -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From nobody Mon Apr 6 08:20:41 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA75C3A09FA; Mon, 6 Apr 2020 08:20:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <158618641862.23500.5895986666402220667@ietfa.amsl.com> Date: Mon, 06 Apr 2020 08:20:18 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-oscore-groupcomm-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 15:20:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Group OSCORE - Secure Group Communication for CoAP Authors : Marco Tiloca Goeran Selander Francesca Palombini Jiye Park Filename : draft-ietf-core-oscore-groupcomm-08.txt Pages : 65 Date : 2020-04-06 Abstract: This document defines Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g. using IP multicast. In particular, the described approach defines how OSCORE should be used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and the corresponding CoAP responses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-08 https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-oscore-groupcomm-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 6 08:30:36 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923493A0A6A for ; Mon, 6 Apr 2020 08:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDydRVeJWolQ for ; Mon, 6 Apr 2020 08:30:16 -0700 (PDT) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 826583A0A68 for ; Mon, 6 Apr 2020 08:30:10 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id 204so55296ybw.5 for ; Mon, 06 Apr 2020 08:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0in0Ftizq/LaHclxfHgO0dgsLe0gJkTXQqBcFNTtkrc=; b=riSc4RY4R6WI7bxtk3HDHzJOfEL4Wsj5ahPUMAqLBjMy4PHVd6lMkOXFBgLam9TJU1 vCXdJGWQ9ofWo0/LHlLs2q4WYDlSYcZ21R34cf6EDuOfyCTT5e9oTRwGSN+yv3q/iM/x iqbXAWgdsXKf/Y+vX7/poVHfQTzn83nT+lmdpT3Yyc/Cg/z22jJBUhH6BKrSsb23gB27 wmlJ6ZJo6SSmQFI9hbKPz/YpE38AWB4byBnv3b8tKzwaY/broL+Cb8EPkjynZOpZF9fU SE/A/DUPRFcAUFYKZ2IpQX7eEDeuxsUUk7xFKf/1YEbzrD+tyKgGY6jkYl8xgmZP3auI e6pQ== 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=0in0Ftizq/LaHclxfHgO0dgsLe0gJkTXQqBcFNTtkrc=; b=A9qGfdw3AkmPq4ufVFjdlczv9CiKLMCLK9WwmL5g3iCcfVUZyCdhlpNnCX+bpIdmG5 Nfs/1lqa+ymJ2aLuxWwTImb5BDgTKjOvwY3Op5n7WCjKGC9IaEaoj/KFkxwORKQ83tQw zICY4Q07X+HJbyyrAs/uOQW4OYwVgkhUXSNtPKQYesgBby/x07zNslxReOnFczwmwKUx ppxnk6/Q6o/t22bxL5GRpGInCLUtfkLmhQLicJmEEUuUQcqlMzb7z6wk38R3CD1Wzo0z Yd/zRN/30FZQcMcGR2RWApWY3XgkgIaqLUE5X20HW3PDGroiF+6KumYbpKbAKjPXWbmx E+mg== X-Gm-Message-State: AGi0PuYUZJ+YbDxSSKQnYw8hKBZaFjicBmMAPpxZShQNoixC17/pg8Zg goCA88kgxbwmvmkIuR4ypETTj/teXekM9aCduDYHd01O X-Google-Smtp-Source: APiQypLxsII9WWB21aZPmuNHpOhTi/k2wkUeK8s+V2id7G8NoTql4cb3DeIH9HP0QhXF7oM2+rNueCV/liYSJKCpaR0= X-Received: by 2002:a25:a281:: with SMTP id c1mr17316972ybi.234.1586187009274; Mon, 06 Apr 2020 08:30:09 -0700 (PDT) MIME-Version: 1.0 References: <9AD3C4BB-7965-4776-84C4-6B5BFDCAA262@tzi.org> <15C8F1D1-B560-4D52-8D77-377C6B1C0518@tzi.org> In-Reply-To: <15C8F1D1-B560-4D52-8D77-377C6B1C0518@tzi.org> From: Andy Bierman Date: Mon, 6 Apr 2020 08:29:58 -0700 Message-ID: To: "core@ietf.org WG" Cc: NetMod WG Content-Type: multipart/alternative; boundary="0000000000003c3f5e05a2a0f156" Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_CORECONF_drafts=3A?= =?utf-8?q?_draft-ietf-core-yang-cbor-12=2C_-sid-11=2C_-comi-09=2C_-yang-l?= =?utf-8?q?ibrary-01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 15:30:18 -0000 --0000000000003c3f5e05a2a0f156 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 9, 2020 at 6:05 AM Carsten Bormann wrote: > It took us a long time to get the four CORECONF drafts in sync, > but now we are ready for WGLC. > > This starts a working group last call for > =E2=80=94 draft-ietf-core-yang-cbor-12 > =E2=80=94 draft-ietf-core-sid-11 > =E2=80=94 draft-ietf-core-comi-09 > =E2=80=94 draft-ietf-core-yang-library-01 > > Sorry these comments are late. I reviewed these drafts. All my comments on sid-11 have been addressed. We plan to use CBOR+SID with YANG-Push in the near future and may implement CoMI later on. I believe all documents are ready for publication. Andy > ending on > > 24:00 UTC on Tuesday, March 31, 2020. > > (This includes some extra time for the IETF week and for cross-WG > coordination.) > > This WGLC is copied to the netmod WG mailing list; please do have a look > at these drafts as they are slated to become a part of the greater > YANG/NETCONF/RESTCONF family. We intend the discussion to be on the > CoRE mailing list, but if you find a fundamental issue with YANG or > RESTCONF, feel free to discuss that on netmod instead. > > Please start a new email thread for each major issue that will need > discussion and make sure the subject line includes the draft name and > some sort of name for the issue. (Minor issues such as typos can also > be sent to the authors.) > > If you read the draft and think it looks fine, please send a one line > email to the list or to the chairs letting us know that so we can get > a feel of how broad the review has been. > > (To reviewers and authors:) If you are aware of any patent claims that > might apply to systems that implement these drafts, please review BCP 78 > and BCP 79 and make any appropriate IPR declaration before the last-call > ends. If you are not sure whether you need to make a declaration or not, > please talk to the chairs and we will help. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0000000000003c3f5e05a2a0f156 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Mar 9, 2020 at 6:05 AM Carste= n Bormann <cabo@tzi.org> wrote:
It took us a long= time to get the four CORECONF drafts in sync,
but now we are ready for WGLC.

This starts a working group last call for
=E2=80=94 draft-ietf-core-yang-cbor-12
=E2=80=94 draft-ietf-core-sid-11
=E2=80=94 draft-ietf-core-comi-09
=E2=80=94 draft-ietf-core-yang-library-01



Sorry these comments ar= e late.

I reviewed these drafts.
All my = comments on sid-11 have been addressed.
We plan to use CBOR+SID w= ith YANG-Push in the near future
and may implement CoMI later on.=
I believe all documents are ready for publication.
Andy
=C2=A0
ending on

=C2=A0 =C2=A0 =C2=A0 =C2=A0 24:00 UTC on Tuesday, March 31, 2020.

(This includes some extra time for the IETF week and for cross-WG
coordination.)

This WGLC is copied to the netmod WG mailing list; please do have a look at these drafts as they are slated to become a part of the greater
YANG/NETCONF/RESTCONF family.=C2=A0 We intend the discussion to be on the CoRE mailing list, but if you find a fundamental issue with YANG or
RESTCONF, feel free to discuss that on netmod instead.

Please start a new email thread for each major issue that will need
discussion and make sure the subject line includes the draft name and
some sort of name for the issue.=C2=A0 (Minor issues such as typos can also=
be sent to the authors.)

If you read the draft and think it looks fine, please send a one line
email to the list or to the chairs letting us know that so we can get
a feel of how broad the review has been.

(To reviewers and authors:)=C2=A0 If you are aware of any patent claims tha= t
might apply to systems that implement these drafts, please review BCP 78 and BCP 79 and make any appropriate IPR declaration before the last-call ends. If you are not sure whether you need to make a declaration or not, please talk to the chairs and we will help.

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

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--0000000000003c3f5e05a2a0f156-- From nobody Mon Apr 6 09:18:35 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EA13A0C60 for ; Mon, 6 Apr 2020 09:18:14 -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_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnLoCDMuq3RO for ; Mon, 6 Apr 2020 09:18:12 -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 C63F93A0C5C for ; Mon, 6 Apr 2020 09:18:11 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id AE30A40146; Mon, 6 Apr 2020 18:18:09 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 1D96B79; Mon, 6 Apr 2020 18:18:09 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:2d54:7976:cdc9:1eab]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E8860367; Mon, 6 Apr 2020 18:18:08 +0200 (CEST) Received: (nullmailer pid 2699440 invoked by uid 1000); Mon, 06 Apr 2020 16:18:08 -0000 Date: Mon, 6 Apr 2020 18:18:08 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: John Mattsson Cc: "core@ietf.org" Message-ID: <20200406161808.GB2688660@hephaistos.amsuess.com> References: <5CD4BE47-4E21-4E00-8BE7-752917CBAF51@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1LKvkjL3sHcu1TtY" Content-Disposition: inline In-Reply-To: <5CD4BE47-4E21-4E00-8BE7-752917CBAF51@ericsson.com> Archived-At: Subject: Re: [core] Allowing non-HMAC based KDF in OSCORE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 16:18:15 -0000 --1LKvkjL3sHcu1TtY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello John, On Fri, Apr 03, 2020 at 11:03:54AM +0000, John Mattsson wrote: > As pointed out by Jim in the COSE virtual interim yesterday, OSCORE > restricts the type of KDF to HMAC-based HKDF algorithms. I do not know > (or remember) why the restriction is there. =66rom an implementer point of view, it would be much appreciated if an OSCORE library would only need to ask its backend COSE library things it can know (eg. whether an algorithm is a KDF algorithm) and not have to ship additional knowledge about algorithms. > I don't think there is any hurry to change this restriction but I > think it should be changed at some point. It makes sense for OSCORE to > allow any KDF specified in COSE. I would suggest that Group OSCORE > (which updates OSCORE) lifts this limitation also for RFC 8613. If we go that route (which sounds viable to me), could we have a "There are no technical reasons why this could not be extended to (non-group) OSCORE; updating that specification in a later document is being considered." in there? KR c --=20 I shouldn't have written all those tank programs. -- Kevin Flynn --1LKvkjL3sHcu1TtY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl6LVj0ACgkQOY0REtOk veH2sxAAvQYa1Wm6h3j098zlZzOzLDxGfiWoRWDpsHtfqhpppGz5L1KsRyLrp3Oe 0yX29NZoLdjykqf6Qu1akk0hAEKHsdch3SQv/TVa7Q3T/XCXNHNeOJ6sZQseMAgW 6YWd8ZsnBTW7twyBhmB/zVh+asPME4BqXt/fpVOvWFY+ZHDqtw/61/aU/HuRedU7 wEPBAoI/7W4mGPnzwqQiK4BVeEfam07ewfaoHLV3D6ggqiD8HeBYd1j68cziQvha wDBrMTgqqypizKYrBCHCiy0ubmtSKrOBCfh1wJX+nQP0w94unSVhyq24ROjlqjLU p4k7QNrDsR2RAOdqDha1xRz8zPREZ3dzZNV/mappWtVs22iMtA22+1bpFItPL0wc gO9LJ06twUp5pIBmKlhxpXjNPzqb8zjFj7DFQt48wvhMYigQWbqSdy3eHWOOaoKo VIm2wvfk6S+w9XwPlalvCv2nnWk53WbnKEa+CQPaFH7P066EoK3AHF/I6bP5o5G0 58rZ/n1/BtiLcajdo7pQmvjsBIEOSyz59DhMQTTyKmLNB6+dm4JrOO61B9//gpKf b59wuRlCWFkFifw+2UxK/2RbL3kvU/8A7n8ofPuLpXtYDxiWYAX8RfOh93S4xUM6 O2nGplUmWygUhos7bd/NbKBWFMGdKR30NQZQhO3F1T3VKB/l6ys= =TSzL -----END PGP SIGNATURE----- --1LKvkjL3sHcu1TtY-- From nobody Mon Apr 6 09:30:29 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2533A0486 for ; Mon, 6 Apr 2020 09:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_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 vBzubTX5t-Tc for ; Mon, 6 Apr 2020 09:30:10 -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 1CDA43A047F for ; Mon, 6 Apr 2020 09:30:10 -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 0883F40146; Mon, 6 Apr 2020 18:30:08 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 32DF379; Mon, 6 Apr 2020 18:30:07 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:2d54:7976:cdc9:1eab]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id F256E367; Mon, 6 Apr 2020 18:30:06 +0200 (CEST) Received: (nullmailer pid 2700067 invoked by uid 1000); Mon, 06 Apr 2020 16:30:06 -0000 Date: Mon, 6 Apr 2020 18:30:06 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad Cc: core@ietf.org Message-ID: <20200406163006.GC2688660@hephaistos.amsuess.com> References: <022401d60918$9a2d3f50$ce87bdf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tqI+Z3u+9OQ7kwn0" Content-Disposition: inline In-Reply-To: <022401d60918$9a2d3f50$ce87bdf0$@augustcellars.com> Archived-At: Subject: Re: [core] Questions dealing with Blockwise Transfer 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, 06 Apr 2020 16:30:12 -0000 --tqI+Z3u+9OQ7kwn0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim, On Thu, Apr 02, 2020 at 11:00:29AM -0700, Jim Schaad wrote: > 1. [...] might return some "large" size error resources. Good questions. > 2. The document does not explicitly give any way for a server to stop a > block transfer half way through. While it would make sense to an error > status is returned, I do not know if the block option is also supposed to= be > returned or not. Note that this would not necessarily interact well with > the idea of doing a blockwise return for an error status content. Section 2.3 item 1 (on descriptive usage) clearly relates the numand block size to the payload of that message. Thus, an error would only use Block2 in descriptive use if the error payload is being fragmented. (I know, that does not answer all the question.) KR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --tqI+Z3u+9OQ7kwn0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl6LWQsACgkQOY0REtOk veH76g//R90h3CHv3kmVL8jaq4Ov+l3bN+vL65if4CDf50/fZQtMqBkGBWWp5PZ+ UAlbx3+04utev6AAMEyNlkhTmZ6gQtBZa79lH5McMnCjtJdATvrqq1HeEZuypFxm VMvaF0cdghpOqm669TVk6beEl/gHYEIOGNgqoXgrtWDgfga7oQ990XsTf3kRPimR FL6DakLYWpFvdM8qaC+qZCthc3gWkoOtXjm7FapCa/k57wtKijTiUZibdIPkNAam 9SbAzqdqFOEo+BJGgaF0ktOF1Shk1Je9PXLG/TXYaCzMklDlN+8WGecGn8XTCk/0 Lk8CAgWIr+2IKSv72QR3zrKs4fwd45/5rSgczhf+J0gu9BSEVdYLQu1CeEfgpVQP 4i03ht3FZMpI9GoiP8vUAr8NzZSw+HQmCyDYjZFfY2IaLv+u2wHYuh+vHmBTDgpI 1tFLb5RfO/mcj5rZACM39cYkOnes3g3kuKLTrGKEMuizV1z/oLRZX0AsIJRLmLm1 tPWO88UoRHR+6uT48H2F7BUYRpR1V66XRF7iFAXoww7y+3xWjh7sdonKANWamxEY ImrQOdPviaaLaGLINeFUra5wsX9Q1EIeaagYopcZ1fwywG5lUw1jpdYztSJD4uw/ TQVj65czwsyu+dZ1GR82j+GjXbIOuFgwRhqzx4PO99773x4NRo8= =EgdA -----END PGP SIGNATURE----- --tqI+Z3u+9OQ7kwn0-- From nobody Mon Apr 6 10:32:49 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876D03A0D04; Mon, 6 Apr 2020 10:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAhIKVoLE9U7; Mon, 6 Apr 2020 10:32:26 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2074.outbound.protection.outlook.com [40.107.22.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 9B9763A0D0D; Mon, 6 Apr 2020 10:32:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gmFuHVkRWclijOQ/cIhV5kJJGGvLr0QDIDUK2jw6oWEtU2gfIdxQrYkJ2XNehGxbq6coBUj99Yl/CpeFARNzbtAfRn1Bdjdi7FvsyPQaW3+g4wQEtuKxI2+1FzrOgpvPIbmBptSBG0OSpVI/8EnGKeYyjbU5hucjDWqDGUNmot7WpIToGzwJ2YS7/EyLlldXhDjO5Dda8YeQxqIYrE9uSZy1KUdyysiB629ebLrOPM7sW+0LgPBAG9bDFStKc+AOr+qiJo+KQvdQ05ddYS2qY/N9QoqR9zR77iuuvlePXJCx/UbtDs0YfRlr8gPUbKL6y+AmjxWQ3oMb0RbRTRNN2Q== 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=7I9eIb0lmQS2fYoxVQ66abXtI9dbRHCV/3ZvRu/b+V4=; b=jLmb0WkgC/7dqTTl8dWk1aLfaeOFJo5dcS5GNT9TgZvquSh/YmKu0Jhj4Q/WSaeu1TEo7VVsY4TaUWLT0pruKfMB4pyHMY4WEA0yW/kJItcn8wvSijE4arHsHb3GN+9giscNSyyvlNd5HzjylmusLzCqO+eh0kVxvTBfmOg/PD8cNVMHKHP6H6KE0MZftn+lBp8qy0mM1yylTH8HsOYMvX+khjsh4CDmpCWiWKwdk/jsFQPHBHJXggdgJ9IE9AIgLhggN/4v0ZUC7Yn6YA3DOn/8oUD9j/WQ+CApd0GPNZW5wDHcYLQx9+0JIVyJMLgtORczIf3FU6NqChFQFnunLQ== 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=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7I9eIb0lmQS2fYoxVQ66abXtI9dbRHCV/3ZvRu/b+V4=; b=IEObxUp+e4w+5NgTTKTScfqY1MmjRwFfwLqdBR/TBfzvkh+78I5Adgs7PvVvImvI9cUr8ikbTMhAEXKApn7j5wA7AXWgl2BzfQBW1EmX4wb0NyQeBQYX4oh/54xn4vEMw70UPFZNyuFfqzEXCuJWgEhL7WPYzm4pJ/yJjQTEZw8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0528.EURP189.PROD.OUTLOOK.COM (10.165.196.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Mon, 6 Apr 2020 17:32:18 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2878.021; Mon, 6 Apr 2020 17:32:18 +0000 To: Jim Schaad , draft-ietf-core-oscore-groupcomm@ietf.org Cc: 'CoRE WG' References: <01c901d5fc9c$302115b0$90634110$@augustcellars.com> <065e01d6039b$41de9a10$c59bce30$@augustcellars.com> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Mon, 6 Apr 2020 19:32:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 In-Reply-To: <065e01d6039b$41de9a10$c59bce30$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="57m7GyKKYSYfA4v3Lrj4AOCnLEKZ6eZ3D" X-ClientProxiedBy: HE1PR07CA0025.eurprd07.prod.outlook.com (2603:10a6:7:66::11) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.6] (185.236.42.17) by HE1PR07CA0025.eurprd07.prod.outlook.com (2603:10a6:7:66::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.6 via Frontend Transport; Mon, 6 Apr 2020 17:32:17 +0000 X-Originating-IP: [185.236.42.17] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fa8ca5eb-adda-4b5b-b695-08d7da507478 X-MS-TrafficTypeDiagnostic: VI1P189MB0528: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-Forefront-PRVS: 0365C0E14B X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(39860400002)(136003)(376002)(346002)(396003)(8936002)(5660300002)(30864003)(8676002)(6486002)(86362001)(31686004)(81166006)(81156014)(966005)(26005)(478600001)(6666004)(16526019)(66574012)(66556008)(44832011)(66476007)(235185007)(66946007)(33964004)(2906002)(31696002)(52116002)(956004)(16576012)(2616005)(316002)(53546011)(21480400003)(36756003)(4326008)(186003); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: ri.se does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: b/5Ool7RrWiWT4tqNVUVg0GTNEZLnpgfQfFkWI6vo4sSdRJcPGmYVHKwpmW07mXzVNGZj06YUqQxCY3G4ZrMo0z+1i869lequN0RMo30XnCR9TlZPHaO1S53koHsS+Q9avW4W7oKlH+6u56QGgQ5jRSZPJBvbDakiAwq8YIybbbBs1JjS2zRiO1VgPwH4mUHBTecnte4Qqf3iqd7zGGV4Gzvr2S4dFVtjDovBDXChmbnJqmN9EzTctbfqK83/Vd/vPJkhUi/z7eeLg7w9s4eFzWHku3UtKWGoxs4fSm7JS6fXccfg9hoLMTxs2g4iZWuzEtfrro8cog8qIfZ6122rkDpH++er1xN5PnKqbTcHIbsefPJzPs4kX7h7NKY4XipzeSXkV/cVtyUIG0Ki6fOAXi1V9IW7NGR4C/BysdDLHaKaaK9dBNj3C3KmOWEzV32S6TypmIBCf/2nzCqqEWc/9BnKvQPsnCtmhwvqWvDoFLKXybeGq2FCvEYHvUrFhV19z7QU3WNMFtZu9VWUyMbaA== X-MS-Exchange-AntiSpam-MessageData: B4TvVU44BlW8po7+ep5dH9imyqDQEoukecuHlNMw7v3ZT5d9XjSKHnkfW1XFYixovb9SoqfnRdyIwub8g6gcw1YqUVIG9swe/Yuo8yMJubeXq6ylav+0XBBp2kw+bcFHoeIp/m7Wqo4ZRVzFuaA0Fw== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: fa8ca5eb-adda-4b5b-b695-08d7da507478 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 17:32:18.5050 (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: NT5dHpEmbcE+5MLDB5X9JOC/G8szOAXeFgVGBqIYqGNQ7krdy1Nzkw1uBtmktaGwxCgKmqPuKt9vvoBzF0KU/g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0528 Archived-At: Subject: Re: [core] Review of draft-ietf-core-oscore-groupcomm-07 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, 06 Apr 2020 17:32:34 -0000 --57m7GyKKYSYfA4v3Lrj4AOCnLEKZ6eZ3D Content-Type: multipart/mixed; boundary="CoNPsw7QwSTAwZoikyt7NaRpuOPk68SuV" --CoNPsw7QwSTAwZoikyt7NaRpuOPk68SuV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jim, Version -08 [1] submitted today addresses most of your comments. A few points are still open and will be raised at the upcoming meeting on Wednesday. Please, find some replies inline. Thanks again for your comments! Best, /Marco [1] https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-08 On 2020-03-26 19:20, Jim Schaad wrote: > > -----Original Message----- > From: Marco Tiloca =20 > Sent: Wednesday, March 25, 2020 11:47 AM > To: Jim Schaad ; draft-ietf-core-oscore-groupco= mm@ietf.org > Cc: 'CoRE WG' > Subject: Re: Review of draft-ietf-core-oscore-groupcomm-07 > > Hi Jim, > > Thank you for this review! > > Please, see inline some replies and requests for clarification. > > Best, > /Marco > > On 2020-03-17 21:39, Jim Schaad wrote: >> * Introduction - para 4 - I think you need to expand some text in this= =20 >> section to explain why it is that doing a pairwise response is still g= oing >> to be considered to be group communication. This assumes some intima= te >> details of how multicast works in CoRE that might not be generally kno= wn. > =3D=3D>MT > Yes, we can expand. A response is sent unicast either way. The differen= ce is that the pairwise-secure response remains confidential between the = originator server and the recipient client. > <=3D=3D > > [JLS] Yes, but in the case of block-wise, the following request might = also be sent unicast using the same context as well. This means that bot= h requests and responses are done using this. Thus you have taken multi-= cast into unicast. =3D=3D>MT Clarified in the current fourth and fifth paragraphs of Section 1. <=3D=3D > >> * Section 1.1. - Silent Server: Consider adding the following to the = >> definition "Given that for CoAP group communications, messages are=20 >> normally sent without requesting a confirmation the idea of a server=20 >> silently acting on a message is not unreasonable." > =3D=3D>MT > Good input, will do. > <=3D=3D =3D=3D>MT Done. <=3D=3D >> * Section 2.2 - next to last paragraph s/instead retrieve/retrieve/ >> >> * Section 2.2 - last para - this does not make any sense because a=20 >> server could do a non-reflection response and you would be unable to d= eal with it. >> I have not see any text to outlaw this behavior. > =3D=3D>MT > Ok, we'll just delete the paragraph. > <=3D=3D =3D=3D>MT Done. <=3D=3D >> * Section 2.3 - para #3 - s/from which/with which/ >> >> * Section 2.4 - para #3 - The implications of the paragraph are=20 >> horrendous in terms of performance of the system. It basically says=20 >> that you need to do some excess processing in order to deal with this = >> issue following a key roll-over. If the first message received cannot= =20 >> be validated by the signature then there is an issue of the question=20 >> was the message corrupted or was the id assigned to a new entity and=20 >> thus a new public key is required to be pulled down. > =3D=3D>MT > If we understand correctly, the reason leading to this is the Group Man= ager re-assigning a dismissed Sender ID, e.g. to a new group member. > As a consequence, the server will be able to retrieve an old Recipient = Context matching that Sender ID, but then failing the message verificatio= n as not considering the correct public key. Then the issue you mention c= omes up. > > If this is correct, it=E2=80=99s probably worth adding some text like: = i) the Group Manager should not recycle Sender IDs, especially in the sho= rt term; and ii) it=E2=80=99s up to application policies on the servers t= o check at the Group Manager that they have the correct public key for a = given Sender ID, after a number of consecutive failed verifications. > <=3D=3D > > [JLS] Yes that would be an appropriate set of text to alleviate the iss= ue. =3D=3D>MT Added the current fourth paragraph describing mitigation policies. <=3D=3D > >> * Section 3 - Have you actually done the testing to see if you can do = >> the mapping of EdDSA as suggested here? > =3D=3D>MT > We are working on it. The coordinate remapping seems to work for Ed2551= 9, and we are now proceeding with the shared secret calculation. > <=3D=3D > [JLS] I was never able to get to this, nor was I ever able to make myse= lf believe that it was going to work because of the difference in the way= that public keys re computed. It will be interesting to see if it does = work. > >> * Section 3 - are all of these pairwise keys to be tossed away when=20 >> new keys are issued for the group? > =3D=3D>MT > Yes, because new Sender/Recipient keys are derived from the new group k= eying material, and then used in the HKDF to derive the pairwise keys. > > Note that the same shared secret can be preserved across rekeyings. > Also, pairwise keys would not need to be recomputed right after a rekey= ing, but latest upon message reception, as their derivation is lightweigh= t. We will clarify these points. > <=3D=3D > [JLS] Not sure that I think that doing a pairwise key agreement is nece= ssarily lightweight or that it is necessarily a good idea to keep the com= puted shared secret in memory after it is needed. Might not be quite as = lightweight as you think. =3D=3D>MT Added text in Section 3.1 about discarding pairwise keys after a group rekeying and deriving a new ones. On the shared secret, new text has been added about the fact that it does not change across group rekeyings, while not explicitly saying that it can be stored rather than computed again. <=3D=3D > >> * Section 3 - clarity is needed on how PIV is going to work for this. = =20 >> I would assume that it amounts to a separate context but this is not=20 >> completely clear from the text. > =3D=3D>MT > Our idea was to have a single PIV per sender, used for all its outgoing= messages, regardless the exact mode to protect each of them. We will mak= e it clearer in the text. > > As a side consideration also to add, this PIV may jump forward more oft= en, hence replay checks may be invoked more often on the recipient side. = To better handle it, larger replay windows should be considered. > > Bottom line, this is due to the fact that not all recipients receive al= l messages from a given sender, i.e. the messages over multicast are addr= essed to the whole group, while the unicast messages (in signature or pai= rwise mode) are not. > <=3D=3D =3D=3D>MT Added a new Section 3.2 clarifying that a sender endpoint has a single Sequence Number space, to use for all its outgoing messages regardless of the mode used to protect them. <=3D=3D >> * Section 4.3 - s/and one structure/and second structure/ or=20 >> different structure >> >> * Section 7. - Para 2 - I have a problem with the second sentence. I = >> think that you need to make it clear who is supposed to be doing this = >> retransmission. It should not be the CoAP system, but it is instead=20 >> the application. That means that a new request could be sent rather=20 >> than a retransmission occurring. > =3D=3D>MT > Ok, we'll clarify. > <=3D=3D =3D=3D>MT We have clarified that retransmissions are handled by the application for group requests over multicast as Non-Confirmable. <=3D=3D > >> * Section 7.1 - Does not reflect the case where pairwise is used. Di= tto >> for other sections. - found it in section 8, but that does not seem to= =20 >> be referenced from section 9 which is "message processing". > =3D=3D>MT > In this section, we can clarify that the text refers to the Signature m= ode. Would it be ok? > > The pairwise mode is later described in Appendix G. > <=3D=3D > [JLS] Yes, that is a fine approach. =3D=3D>MT The beginning of Section 7 clarifies that its text refers to the signature mode. <=3D=3D > >> * Section 7.4.1 - Must send the group identifier on the first observe = >> following a rekey operation to all clients. ---- I am not sure that=20 >> the group may not be required at all times - We need to discuss why yo= u think >> this would not be true. Think of the case of two different observe >> relations from the client to the same server sent using the same pair = >> of ports on both devices but with different groups. > =3D=3D>MT > This comment seems to actually refer to Section 7.3.1, third paragraph.= > > Probably the best compromise here is saying that a server MAY include t= he Gid in many or all notifications after rekeying, e.g. if identifiers a= re reused in different groups. This would trade off the message overhead = with the chance of collision. Would it be ok? > <=3D=3D > [JLS] There are two cases: 1) after the rekey and 2) two security grou= ps on the same multicast address (or unicast addresses in the case of pai= r-wise) I still need to look at the second case as it may be dealt with = by message id. I am just not sure. > >> * Section 9 - I thought I understood how this is going to work and=20 >> after reading this I find that I am wrong. I am almost positive that = >> I dislike the compression for sending a request. > =3D=3D>MT > See reply below. Note that the part on optimized responses should be fi= ne, as identical in the pairwise mode of Appendix G. > <=3D=3D > >> * Section 9.1.1 - I believe that this is just wrong - I would have=20 >> thought that this is keep the tag and omit the countersignature. As=20 >> written you have messed up the AEAD and thus one level of security on = this. > =3D=3D>MT > Could you be more specific on the problem this creates? SIGMA-I and IKE= also consider a MAC not sent but included under a signature. > > Your original interpretation (keep the tag and omit the signature) is t= he case of requests in the pairwise mode of Appendix G. > <=3D=3D > [JLS] There are a couple of different issues that I have for this:=20 > 1. I now need a new mode for my AEAD algorithm where it will provide o= utput without validating that the MAC is correct. I do not know if this = is doable with any of my current crypto libraries. > 2. It permits for one to create a situation where the same encrypted v= alue could potentially be decrypted into two different plain texts by the= use of different keys or IV values. It requires a security analysis to = ensure that this is not possible, for example in the case where a sender = incorrectly derived the key and base IV. > >> * Section 10 para 1 - s/as further discussed/as discussed/ >> >> * Section 10.1 - should deal with the bilateral version and say that=20 >> it does not follow these rules. > =3D=3D>MT > We can surely add considerations about the pairwise mode of Appendix G.= > In particular, since the pairwise mode uses symmetric keys to protect m= essages, it does provide pairwise confidentiality and source authenticati= on without signatures. > <=3D=3D =3D=3D>MT Added a paragraph discussing how this changes when using the pairwise mod= e. <=3D=3D > >> * Section 10.4 s/ block-wire/block-wise/ >> >> * Section 10.7 has interesting block-wise implications that need to be= =20 >> explored. > =3D=3D>MT > Could you elaborate more on this point? > > Does this =E2=80=9Cjust=E2=80=9D mean that the attack has an even more = severe impact when involving the transfer of big bodies with blockwise? O= r is it about something more, such as mixing-up the blocks of two differe= nt but =E2=80=9Cakin=E2=80=9D > blockwise transfers to two different target servers? > > Should we even recommend against using the signature-mode for any unica= st request using block-wise, i.e. not only for non-safe methods such as P= UT, POST and PATCH/iPATCH? > <=3D=3D > > The first paragraph says that using group OSCORE is bad when done over = unicast, but if you do blockwise transfers and don't support the pairwise= situation then this is exactly what you are going to be doing. I don't = know if this means that the pairwise needs to be upgraded to a mandatory = to implement or if the NOT RECOMMENDED is too strong of a statement for t= his situation. The same problem occur with use of the ECHO option as the= response to the ECHO needs to be unicast not multicast (it only applies = to a single server) and thus falls into this same category. =3D=3D>MT Added the current fourth paragraph discussing how the attack affects block-wise transfers. <=3D=3D > > Jim > > >> >> > -- > Marco Tiloca > Ph.D., Senior Researcher > > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) > > Phone: +46 (0)70 60 46 501 > https://www.ri.se > > > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --CoNPsw7QwSTAwZoikyt7NaRpuOPk68SuV-- --57m7GyKKYSYfA4v3Lrj4AOCnLEKZ6eZ3D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl6LZ5kACgkQ7iZktA5Y 2kPBNAgAmhxmtOSlbM0O5QUDwT1XndjPNJAvCAH5BzBHQ7hAOnNRWu4iWomJ3zWe O7ZGQSir+qnuXAr3FVqoH3HJF4mulOglDgxwqjWX4wKj03A93XBmnxC6e1jAW53R bz9Xy/lOYjlzKacTFg13R6xUwIT+Yy1yZzgU0H/4+ExY3JvM+zitHh1cCwJkLjzt ki+7WUmz5CtE1Mv826eHEAxti3oAlk3A+T0Po7uJWRj/IGxSXauMDdPzJwZcsXua 3nhI+VweFvRcemhpcb6CKquTowpK7NdhcKDr05O2f5VlncOd2bx38hsHcdc0WL4h Kw+LMP5NJQfHyWZbWNd5IfUh+usd3A== =VcWt -----END PGP SIGNATURE----- --57m7GyKKYSYfA4v3Lrj4AOCnLEKZ6eZ3D-- From nobody Mon Apr 6 10:52:15 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1D63A0DA8; Mon, 6 Apr 2020 10:51:43 -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, MSGID_FROM_MTA_HEADER=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=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kblfYH_qU5DT; Mon, 6 Apr 2020 10:51:38 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70057.outbound.protection.outlook.com [40.107.7.57]) (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 EFDCB3A0D98; Mon, 6 Apr 2020 10:51:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kLaPal8bRdRJFKgILKdnPR3ynxz5N7tVEI+2BFTTn2s9Lskbut76WY0SwYMjNCm6UZNq0KKBFMjp8gkpflbhytQxgM4FjXQ3Ce0LG42qGdIKZ2kCvIHAQwtitRnsL27yj2jWMp1ZVqCbKaqcd3OWHx8eAwgpghQqKzAbdwUvy9TovV6Mfld8J+g42B2iihJJVXOsnyTSjcbL003t/MvmWGDwRw5aJfwlhAyk9fVHPLrw+3ReWz0fpSzDdX0ecHADMRjg/fRchnLx1UESIAQ0qRM1G31UFB1BqxNkCT4LttKOmNCHfNEAKGzx1R2YapiS1rvuvbKj41X+nGBHq2HKEQ== 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=1PjZJ0r9vZzpS+LRpIQzPxngYfhIvH8Su1LTNWwWiYs=; b=U2cMfaNfWnuJpzWS6jN88wMVshpNAKPE4FtscM1ObFAWv79qT+bXKC6E/DHsypBetakhUCam3LphDQXce9UPqklt7aGMcf9OcPrwqfMjOKWbq56FX4tYV1+GQUVtiiOk7xh4IwMgDKsYMU2vXoc6SiFddMn0gaukbufhtjJBl/XWOkJVbJuok21RrdznvwfkKWKLa9phS2L8dl4x+pG6AjNp6tfEBKT0kb+jQQoh+TkLOxjvwrBJXb3EUms2ec1vJ8pzvR9i0N7g+sBx68IO2CNuWxmcIPO46d4U4DUp8No7+nlGfDJ124QA9ypPTPPvWvGcOIRhr9F2g3H/KAxhjw== 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=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1PjZJ0r9vZzpS+LRpIQzPxngYfhIvH8Su1LTNWwWiYs=; b=e4O1d53O8hdih7S11v7EuijuCy47sqtHeljAJMQu7eLWNUd+ex8vntc/GzrN2mdS0UKqk6Q/39RHB4AZ3YcillTM6WzrBewM306+aBIeJxMn8UAjpSbRmSh1hntFTCa7QjRnAJiN16VbpIANqPLrAQNwUuGXgyyX6vLgxCUWVPs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0333.EURP189.PROD.OUTLOOK.COM (10.165.198.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19; Mon, 6 Apr 2020 17:51:28 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2878.021; Mon, 6 Apr 2020 17:51:28 +0000 To: =?UTF-8?Q?Christian_Ams=c3=bcss?= , draft-ietf-core-oscore-groupcomm@ietf.org Cc: core@ietf.org References: <20200327171524.GA1531909@hephaistos.amsuess.com> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Mon, 6 Apr 2020 19:51:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 In-Reply-To: <20200327171524.GA1531909@hephaistos.amsuess.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="in1IY9N9BnnoKGfyYTZoXrKudYtKK7s12" X-ClientProxiedBy: HE1PR09CA0089.eurprd09.prod.outlook.com (2603:10a6:7:3d::33) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.6] (185.236.42.17) by HE1PR09CA0089.eurprd09.prod.outlook.com (2603:10a6:7:3d::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Mon, 6 Apr 2020 17:51:27 +0000 X-Originating-IP: [185.236.42.17] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d81aa695-984a-45d9-3b18-08d7da532198 X-MS-TrafficTypeDiagnostic: VI1P189MB0333: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0365C0E14B X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(366004)(39860400002)(346002)(136003)(396003)(66556008)(4326008)(5660300002)(235185007)(81156014)(8936002)(66574012)(81166006)(478600001)(36756003)(16576012)(8676002)(31696002)(30864003)(66476007)(2616005)(956004)(26005)(966005)(44832011)(86362001)(52116002)(16526019)(186003)(66946007)(53546011)(2906002)(316002)(6666004)(6486002)(21480400003)(31686004); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: ri.se does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: C80SYl5NzJMVTofwKaYW4XN4uG83mR7b/8ogwGi9WIVWkmgOgJdXMWtu34wab/TPf8z23MnVZLpcYLBv0RHeu6OC2cvrEP61CjauVdXIy0h9U4z8dJHArcTdM6yBAl33jUUxRukRSEwU8tDQez5phlg3M2wP/j/nNtZSZ/Ezj/mc9cnxQG2zq73xMKtrs1jF2hLxPHpD/mWoYIV7bR9lHsjPr2Iook0IvDar/x9sLk/yZ1zwdQ5clWdf3rkuG8yIO2y2HNghLzGkRorvSKY4nI0YCeBsquY8uG3PJi1hU/9mVAFKsQ6ZSdbE8/OjV8KyaUlqFxE04YvHliHRGSAV8E3SEjRJPQn0opvlBWThIn4ol4CSh4LVlzPp2Ch4KZ7fYdyjYiTx09Uy8CRa6cJUJjQjnYlpFEJSi+23EIqBtizHuJ4ImHDJ6Y84aOHpwMXGOgQhCA1bucQ0Mp9QVPXHiXxLllnGbd+6PkctIQYfVinLvquw53rJEONMLjIsWKYpxHgJxB0zcEIp2Q1e+lNuXA== X-MS-Exchange-AntiSpam-MessageData: FepgB5O+p3y4why2P0MIhBmmT6ZSKFzKpwrUYI0ZYirJYQnJx0jdgvnzo1NMrkhiYmfVhO9cpGIx6idS0uALgRpieLDUfxXy+77tWJ5s0+zPDGuRhonx81vQI3/9mKBpq58TKiLJBXC+wHN1I90Sng== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: d81aa695-984a-45d9-3b18-08d7da532198 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 17:51:27.8938 (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: as3Fg2Klzn6UPmAzqjMKpbuGyqdguigmtt/HVMNcSLSurSD9nq2R3BJJCsBmBVWJNKR4KVDB7V+hj4V93nE4pg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0333 Archived-At: Subject: Re: [core] Review of draft-ietf-core-oscore-groupcomm-07 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, 06 Apr 2020 17:51:43 -0000 --in1IY9N9BnnoKGfyYTZoXrKudYtKK7s12 Content-Type: multipart/mixed; boundary="syNnZ35JZLiaohBYjpik2FWanjYWvtdwe" --syNnZ35JZLiaohBYjpik2FWanjYWvtdwe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Christian, Thank you very much for your review! We have addressed most of your comments in version -08 [1] submitted toda= y. Some points are still open and will be raised at the upcoming meeting on Wednesday. Please, find some replies inline. Best, /Marco [1] https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-08 On 2020-03-27 18:15, Christian Ams=FCss wrote: > Hello gropucomm authors, > > (I'll try to skip issues Jim already found) > > * Silent server: I don't see why the role as a client is described as > independent of being a silent server; doesn't the role as a client > automatically give it a sender context that that can be used in serve= r > role just as well? =3D=3D>MT We have expanded the definition of =93silent server=94 in Section 1.1. If the endpoint implements only the role of silent server, it does not have a sender context (at least in signature mode) and expects to process only incoming requests. That=92s explained later on, but we can anticipate it already here in Section 1.1. Instead, if the endpoint implements only the role of client, then it has a sender context and it is prepared to have multiple recipient contexts, but it expects to process only outgoing requests and incoming responses. <=3D=3D > > Would a proxy (say, one that serves a remote client accessing a local= > multicast group) that verifies the client's legitimacy based on its > signature as a group member classify as a "silent server", and if so,= > wouldn't "silent member" be more fitting? > > ("Bonus question": Can such a proxy be provisioned with the public ke= y > of the client but not the group key material?) =3D=3D>MT Good points. This is related to a comment from Jim [1] about the key management documents in ACE. The idea would be to have a =93proxy signature checker=94 as an entity which is not an actual member of the OSCORE group. That is, it needs to get the right permission to retrieve the public keys of group members from the Group Manager, but it does not need to be an actual group member and be able to retrieve the symmetric group keying material. While this is going to be defined in draft-ietf-ace-key-groupcomm and draft-ietf-ace-key-groupcomm-oscore , we have now added a new paragraph about this at the end of Section 2.3 of this document. [1] https://mailarchive.ietf.org/arch/msg/ace/6YCtkE93HPajYcWrPlpxYxr8GkE= / <=3D=3D > > * At some point in reading this, it would be comforting to be ensured > that however the keys are provisioned, I don't need to provision ever= y > member with every other member's keys. (Eg. in a bipartite setup of > clients and servers, clients only need recipient contexts of servers > and vice versa). The line that does this now is "from which messages > are received" -- is that visible enough? =3D=3D>MT Correct. Master Secret, Master Salt and ID Context are provisioned for the whole group. The symmetric Sender/Recipient keys are derived when needed. In Section 2, we have expanded the text for the bullet point about the recipient context. <=3D=3D > > * 2.5: OSCORE terminology on sequence numbers has so far not used > "wrapping" semantics, and only spoke of integers -- that those tend t= o > wrap is a programming language specific thing, and especially in the > typical 40-bit space is rarely the default. I could have sworn the > OSCORE document talks of sequence number "exhaustion", but it doesn't= ; > either way, "An endpoint can eventually exhaust its own ..." might be= > a better wording. (If wrapping needs to be mentioned, I think it > should rather be in "If an implementation's integers only support > wrapping addition, the implementation MUST detect a wrap and treat th= e > context as exhausted instead.") > > (Also in 10.11) =3D=3D>MT Thanks, we have rephrased Sections 2.5 and 10.11 to talk about exhaustion, with wrap-around as a specific case to handle as and be treated as exhaustion. <=3D=3D > > * 3.: I'd appreciate a reference to static-static diffie-hellman shared= > secrets. =3D=3D>MT We have added the following document as reference. Static-static Diffie-Hellman is discussed in its Section 6.3. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.p= df <=3D=3D > > * general (but in particular 4.2, and "That Sender ID is valid only > within that group, and is unique within the group"): This all works > under the assumption that kid and kid-context are used in a > hierarchical way of kid residing "under" the kid-context, and that th= e > GM may assign any kid to a given node because the GM is in control of= > the whole kid-context. This is not true if the client is also using > RFC8631 B.2 mode -- then, it needs to reserve some kid across all > kid-context. (It'd be tempting to partition those by whether a > multicast address is involved a request, but the Echo recovery happen= s > on unicast even when using group OSCORE). > > It might be that this requires some adaptation in the way B.2 is used= > in applications (eg. that they make their ID1 always start with some > agreed-on prefix that the group manager will not use). =3D=3D>MT Yes, we build on the hierarchical assumption where =91kid=92 is under =91kid-kontext=92. Now the Group Manager is the only entity in control of assignment and decommission of IDs, so group members cannot just negotiate new IDs with each other, but rather go back to the Group Manager if need be. We have clarified this by expanding the current third paragraph in Section 2.3. If we want to open to RFC8613 B.2 mode as an alternative, reservations and adaptations sound like indeed required. Then we have the problem of keep ensuring uniqueness of kid values in the same group. <=3D=3D > > * 4.3.2: Why does theo Signing AAD need to cover OSCORE_option?=20 > > Things in the option that could be manipulated are the flags > (pairwise selects a different key), kid and kid context (which select= > different keys) and partial IV changes the nonce -- of those, only th= e > Partial IV change would make the signature check succeed, and even > then, the AEAD will fail. > > If it's only about the Partial IV and actually necessary, a bstr that= > only encodes the PartialIV instead of OSCORE_option would make it > easier to obtain bounds for the size of the aad_array > serialization. =3D=3D>MT As you point out below, that started by considering what is now described in Section 10.6. A first proposal was to have the OSCORE option of class I altogether, but that was not ideal for implementors. We thought of including individual pieces of information from the OSCORE option as elements of the aad_array in Section 4.3.2, but that risked to complicate the description. All in all, and considering that the AAD does not go on the wire, we opted for including the whole OSCORE option in the aad_array. <=3D=3D > > *grml*, section 10.6 talks about that. I suppose that *does* require > that the AAD can be long enough to contain the longest possible OSCOR= E > option. =3D=3D>MT Right, we have added this as further note for implementation in Section 4.3.2. <=3D=3D > > * 5.: I have the impression this means to say that in pairwise mode, th= e > payload is as in RFC8613 and not as in the first bullet, but doesn't.= =3D=3D>MT Correct. In the first bullet point, we have clarified in which modes the signature is added. <=3D=3D > > * general (manifests in 5.1): It'd help understanding the structure if > there was a note around the ciphertext saying that this is a 28 byte > ciphertext created from a, say, 12 byte request and including a > 16 byte tag. =3D=3D>MT We have extended the text introducing the examples. <=3D=3D > > * 7.1.1 and later observation handling: Does letting observations run > through a re-keying open us up to the risk that the client could > receive the same KID again, start its sequence numbers anew, sends ou= t > a different observation on the same (KID, PIV) pair (but a different > key) and the responses get mixed up? > > (Maybe observations just need to terminate on rekeying, like they do > when your IP addresses change?) =3D=3D>MT Terminating observations across rekeying would be pretty inconvenient. In applications requiring backward/forward security, each (burst of) joining/leaving would trigger a rekeying, with consequent termination of all ongoing observations. The client and all the group members should actually maintain the same =91kid=92, as the Group Manager should not change them when rekeying the = group. However, the above is assuming that the Sender Sequence Numbers reset upon group rekeying. We never say it explicitly but the intention was to rather keep the Sender Sequence Numbers growing, which also helps observations to stay alive across group rekeyings. So this is also about clarifying if Sender Sequence Numbers should be either reset to 0 or not after a group rekeying. Both approaches have pros and cons. <=3D=3D > > * 7.2 (and 7.4): Is there any prescribed order between counter signatur= e > and AEAD verification? With the caveats of the below 9.1.1 comments, > can the client forego verifying the AEAD tag if it verifies the > signature first? =3D=3D>MT This was discussed for previous versions of the draft. The conclusion was to not mandate any particular order, so being flexible as long as both the signature and the tag are checked. <=3D=3D > > * 7.3: The same concerns as in 7.1.1 apply here where the different > security contexts are used in request and response. > > Especially, why is the SHOULD on taking a new partial IV not a MUST? > After all, the use of the original Partial IV is scoped over the Key > IDs, and using the requester Partial IV in the new security context > both for answering requests from this and from the old securty contex= t > (and thus, the old kid space) is inviting nonce reuse. > > My current impression is that in well-thought-through applications, > the late updates can work well enough even in constrained application= s > to not take the risks of crossing contexts between requests and > responses. =3D=3D>MT We have made it a MUST. <=3D=3D > > * 9.1.1: I had a lot of text here but found that Jim already said it > better. If found to be secure, this at least needs concrete guidance > of which stream cipher to use to replace which AEAD algorithm. > > * 10.5 or wherever that fits: The namespacing considerations we've > recently rolled in the OCF call might apply here as well. Unlike in > non-group OSCORE where the recipient is the authority of its recipien= t > IDs and can shard them as it pleases, in a group the group authority > (whoever allowed taking that group IP address) can shard the group ID= s > between different GMs that manage groups on the same address, if such= > a thing does at all make sense to deploy. > > (I placed this on "or wherever that fits" because while what's said i= n > 10.5 is true on the security side, I'd very much like things to be > designed that way that devices don't ever need to try multiple > decryptions. One practical reason is that decryption can often be don= e > in-place, but libraries don't promise to keep the old ciphertext > intact when decryption fails). =3D=3D>MT We have added the current third paragraph in Section 10.5 following your suggestions. We have also added related privacy considerations, in the current last paragraph of Section 10.15. <=3D=3D > > * Counter Signature Parameters Registry and following: Given how tightl= y > this is tied into the COSE registry, has it been considered to make > this an extension there? This would increase visibility of the > parameters registry to those who enter new counter signature > algorithms into COSE, and encourage them to describe the parameters > right away. =3D=3D>MT We plan to remove the IANA registries in Section 11.1 and 11.2, and rather point at the updated COSE registries at https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-07 <=3D=3D > > * The 'encoded as specified in the "Parameters" field' of 4.3.{1,2} and= > the parameters description of 11.2 miss some glue to me. I suppose > that the parameters field is a CDDL expression, which would be such > glue (ie. an EdDSA with kty=3D1 and crv=3D2 would be encoded as CBOR = `[1, > 2]`), but that is not explicit. =3D=3D>MT Correct, and to be revised when pointing directly at the updated COSE registries. <=3D=3D > > * 11.3: For the assignment of OSCORE Flag Bit 2: Is this only used for > group OSCORE, or can this be usd in other situations where both parti= es have > (or can have) static-static keys? =3D=3D>MT Good question. So far, we have thought of Group OSCORE only, we don't see a more general meaning. <=3D=3D > > If it is particular to group OSCORE, it might make sense to leave its= > meaning in non-group-OSCORE setups undefined. (A kid/kid-context > combination needs to be recognized as a group or non-group key with > either value, so the remaining value is free for non-group > applications). In that light, flipping the bit's value might be > worth considering, as "pair-wise mode" is the default for non-group > OSCORE. (AFAIR there was a "has counter-signature" bit in earlier > drafts. Why was that changed, just because "0" is the more natural > default value in group OSCORE?) =3D=3D>MT Flipping the value makes sense. So the bit can be 0 for symmetric-protected messages (in OSCORE; in Group OSCORE in pairwise mode), or 1 otherwise (in Group OSCORE signature mode). <=3D=3D > > * E.2: This is basically a trust (freshness) on first use -- but why is= > the first use discarded? An attacker can send in two consecutive > requests just as well as one, so the server could relay the first > request to the application just as well. =3D=3D>MT Right. We have changed it to not discard the first message. <=3D=3D > > * Appendix E in general: As I understand, sending a Partial IV in the > "Protecting the Response" step is as optional as in regular OSCORE: > you can do it, and need to under some circumstances, but for > efficiency you don't unless you need to. =3D=3D>MT Correct. <=3D=3D > > If that is the case, E.1 and E.2 should be explicit about that while > they may be good enough for the application's freshness requirements,= > they are not good enough for using the request's Partial IV, at least= > if the baseline synchronization state can ever get lost. =3D=3D>MT Correct, this is now explicitly discussed in both E.1 and E.2. <=3D=3D > > * E.3: That unicast repeated request=20 > > "otherwise, the request is silently discarded": Why? This could just > be due to a client that has taken its time, I'd have expected > "otherwise, a 4.01 (Unauthorized) including an Echo option is sent as= > above". =3D=3D>MT Right, we have updated the text to send a 4.01 response with an Echo opti= on. Since the request including the Echo option is unicast, this was an excessive adherence to the text in Section 7: "... it is RECOMMENDED that the recipient does not send back any error message. This prevents servers from replying with multiple error messages to a client sending a group request, so avoiding the risk of flooding and possibly congesting the group." <=3D=3D > > And does the server need a time interval here? I'd implement Echo as = a > random-per-bootup (or taken-from-own-sequence-numbers) source, and > don't see a cryptographic reason to concern myself with time there. > All that matters is that the new request is one the client sent after= > my server came up, so it can't have been responded to in an earlier > life. =3D=3D>MT Correct, we have updated the text for not caring about a time interval. <=3D=3D > > I disagree with the "all group members [need to] understand the > elective Echo option" approach; Echo is defined as elective, and > unknown Echo values can be ignored. Last but not least, two servers > could easily arrive at the same Echo value. Using pairwise security > contexts would be much more suitable for the re-request, and not rely= > on ignoring messages on mismatching Echo values, and should always be= > used with this mode; see discussion at > https://github.com/core-wg/oscore-groupcomm/issues/26. =3D=3D>MT We have removed that expectations from servers in the group, and stressed that using the pairwise mode would solve the problem altogether.= <=3D=3D > > * Appendix G: "Senders MUST NOT use [pairwise with] multiple > recipients": I was confused at first as to why this is not a "can > not", and only later realized this is to keep clients that want to > address a single server from just broadcasting a request with > pairwise encryption. This could be clearer. =3D=3D>MT We have clarified this point in the third paragraph. <=3D=3D > > * G.1: The mechanism for address discovery is an odd mixture of > vagueness and concreteness. Suggestion to replace the three last > paragraph and its bullets: "To make this information available, > servers MAY provide a resource to which a client can send a request > for a server identified by its sender ID, or a set thereof. Details o= f > such an interface are out of scope for this document." =3D=3D>MT Thanks, we have adopted your suggested text. Also, the =93set thereof=94 = may also be the empty set. This would point at all the servers, in case the client knows neither their addresses nor their =91kid=92 values. <=3D=3D > > * G, "Note that no changes are made to the AEAD nonce and AAD.": I'll > need to think this through again when implementing it. =3D=3D>MT Ok. <=3D=3D > > Over all, a thing I'm looking forward to implementing in aiocoap. > > Kind regards > Christian > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=E5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --syNnZ35JZLiaohBYjpik2FWanjYWvtdwe-- --in1IY9N9BnnoKGfyYTZoXrKudYtKK7s12 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl6LbBkACgkQ7iZktA5Y 2kPKqgf5ASooGF4eYjIFkD5OLHz49qqDCOmwYpayz22HVBShPDxDoaYESn12Ju54 Qradfyi3WypZVNwS6H6VJG8bcbTFDqAfV5/X/UAviTvFQZByTASz8BKlnA8fVp5Q 4oowzviD4+tOJnVRb7FsUEBXQjmCVZ2TjzuTF18ig1RLoVuqb9DbYNqyJZFoXk2V CqwCU+QVj1sbxOS4i1pVsc7fWnMmVSYkAb9ahlvgT8UEcV4w6c2UntcApTF9p4+k hoCk1yO6DAS4XsWb3mSI1rpVVSW5usLh16FMBs0x6t4CXyviTO89JrPZnPaXJkvm 914GBCEXsroYN+ICOH5CrOphIWXCMw== =amPb -----END PGP SIGNATURE----- --in1IY9N9BnnoKGfyYTZoXrKudYtKK7s12-- From nobody Mon Apr 6 13:02:07 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8221F3A0E37 for ; Mon, 6 Apr 2020 13:02:04 -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 mjdBeUCPAJSh for ; Mon, 6 Apr 2020 13:02:02 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 753993A0E47 for ; Mon, 6 Apr 2020 13:02:02 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id o1so1118248edv.1 for ; Mon, 06 Apr 2020 13:02:02 -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=7d1kdr0mw1wWHWKLMVwyNmGjEesPjLyBMnOFXCBCM2A=; b=stRarxaKcw8qGhSielOnZOIeMXeNNtJlNeKQ8kX0cDoklWWjs30HbqKtsD4mncqVSx 89/PELlHVoCh2tYz28NvWf2YAe93+oAyJqgETMwG48qNY0oTugKqpLulLNOIPYSGiieU JLq1fth9zRgSL/rYe+mOJDgvk0euF04UL2o0r/1yTiq/ZKCyMf56CKpmCgsQM6dFIDsR FmrDef+l96sHViM617To+MncKMtKW7cQHreJqv9CkAI7oALIugfMHUvK5SG+B4Ut8i8A XWI9zisGOuuTvnV0SnNooLT6kxMDdYAU92Ab3DQd/jpdlsEIESUexpaY1ASM6e7wxH2p G5MQ== 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=7d1kdr0mw1wWHWKLMVwyNmGjEesPjLyBMnOFXCBCM2A=; b=Hbc09E4ooXbWNerhmfaJdogzNapXRCerEj+jeT6goJ2RtYk/8CdehhQbDehrVpmg4+ 2XKxrb/rM0kpD/FA5vAg0H8icGTc1mBwO5zy1urEpnYn6NE84+2GmF33swoMtJx2+SDt 5qmg8/zH7FYObB5dCosS8dssbacLyGZ8WspNuMrKrVmY2TCWlVlTTwF/M3kYDIo1uudp WIo3Rev23ws8hm08H2rESoV/Lpd05FSLkZCxenu8yXwYZkHHmNb5dkYg5jmMd6UjHjv8 mj8T0+PdUnoEAlhlkg//eQXqUON8JFSRrqYMYgg82f6hm3z/NAv2UMqBbNIbyYKnR7DT wvAg== X-Gm-Message-State: AGi0PuZuKrRHHd65T5xkdLDDjercAkMIapKZNb40h4seplx+8fIjRPZ1 KmNqg7bfwRYdId5jyfuQkBjxbb96dAiroM73u/QjXGyz X-Google-Smtp-Source: APiQypIZcDBy8DpqKn3ksbtPcmUl/VT707gsTZV2v4HSkoaP/TBTUzjYUBHyQbVB4yxBdeyysuH5eBl+jbmNwrkpaf4= X-Received: by 2002:a17:906:7804:: with SMTP id u4mr1147990ejm.328.1586203320833; Mon, 06 Apr 2020 13:02:00 -0700 (PDT) MIME-Version: 1.0 References: <7B20E77F-CFF4-4735-A0C2-99121CD352D3@ericsson.com> <8012E8F3-F21D-455E-B888-24C996D9C509@ericsson.com> <99FAF8E8-D93B-4AAC-919D-BEC9F614ED28@tzi.org> In-Reply-To: From: Abhijan Bhattacharyya Date: Tue, 7 Apr 2020 01:31:49 +0530 Message-ID: To: Achim Kraus Cc: core Content-Type: multipart/alternative; boundary="0000000000007addda05a2a4bd9e" Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 06 Apr 2020 20:02:04 -0000 --0000000000007addda05a2a4bd9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Achim, I think we can put it this way: When we consider a purely Client/Server mode, there is this inherent assumption that usually the server will have the implicit responsibility to make itself available through a known accessible path. This does not hold as a general consideration when we want to do a P2P that should not depend only on a given assumption about the path to reach the peers. The peers may both be publicly addressable; one or both may be behind NAT/ Firewall; they may be in a home network where filtering rules are relaxed; they may be in an enterprise network with stricter rules (at times you may need the local infra admin to intervene to open specific ports -- let's keep that out of consideration here). So, any possible standardization effort should propose a mechanism that will allow the peers to access each other agnostic of the intermediate topology and the back haul. Thanks. On Mon, Apr 6, 2020 at 7:07 PM Achim Kraus wrote: > Hi Abhijan, > > in my experience it's not about IPv4 or IPv6 (and the feature assumed to > be included with both technologies). > > It's about the nature of the network you use for your peers to > communicate. CoAP over UDP (also over DTLS/UDP) works without the need > of additional parts, if your peers can exchange messages using UDP. > > So, is that network your peers are using fully under your control? As a > home-network maybe considered. So, you know, if your peers have static > or mainly static addresses. And there is nothing on the path between > your peers, which may block or modify your traffic? Then you have a very > good chance, that you don't need something additionally. > > But, if your peers can't reach each other without additional parts, e.g. > because both in "their home network" and so communicate over a path, > which uses a "public internet link", then you need more. > > Therefore, please try to describe first the network(s) and the > communication paths you plan to use for your peers. > > best regards > Achim > > Am 06.04.20 um 14:31 schrieb Abhijan Bhattacharyya: > > Hi Carsten, > > Considering the practical deployment possibilities, I think we are quit= e > > far from expecting a clean IPv6 path. My home broadband service provide= r > > still serves IPv4 only. :) > > Apart from that there may always be some firewall in place considering > > enterprise use cases and we would need to punch a hole. > > Thanks. > > > > On Mon, Apr 6, 2020 at 5:43 PM Carsten Bormann > > wrote: > > > > > > On 2020-04-06, at 13:52, Christer Holmberg > > > > wrote: > > > > > > I am not going to get involved in a discussion about that, > > because it is not CORE specific, but IPv6 is *NOT* going to remove > > the need for NATs :) > > > > Of course not, IPv6 is not removing IPv4=E2=80=A6 :-) > > > > (That=E2=80=99s why I talked about a =E2=80=9Cclean=E2=80=9D enviro= nment.) > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > > -- > > Regards, > > Abhijan Bhattacharyya, > > /Technologist by profession [IoT| Internet Protocols| 5G]/ > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --=20 Regards, Abhijan Bhattacharyya, *Technologist by profession [IoT| Internet Protocols| 5G]* --0000000000007addda05a2a4bd9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Achim,
I think we can put it this way:
Wh= en we consider a purely Client/Server mode, there is this inherent assumpti= on that usually the server will have the implicit responsibility to make it= self available through a known accessible path. This does not hold as a gen= eral consideration when we want to do a P2P that should not depend only on = a given assumption about the path to reach the peers.=C2=A0

<= /div>
The peers may both be publicly addressable; one or both may be be= hind NAT/ Firewall; they may be in a home network where filtering rules are= relaxed; they may be in an enterprise network with stricter rules (at time= s you may need the local infra admin to intervene to=C2=A0open specific por= ts -- let's keep that out of consideration here).=C2=A0So, any possible= standardization effort should propose a mechanism that will=C2=A0allow the= peers to access each other agnostic of the intermediate topology and the b= ack haul.


Thanks.=C2=A0 =C2=A0=C2= =A0

On Mon, Apr 6, 2020 at 7:07 PM Achim Kraus <achimkraus@gmx.net> wrote:
Hi Abhijan,

in my experience it's not about IPv4 or IPv6 (and the feature assumed t= o
be included with both technologies).

It's about the nature of the network you use for your peers to
communicate. CoAP over UDP (also over DTLS/UDP) works without the need
of additional parts, if your peers can exchange messages using UDP.

So, is that network your peers are using fully under your control? As a
home-network maybe considered. So, you know, if your peers have static
or mainly static addresses. And there is nothing on the path between
your peers, which may block or modify your traffic? Then you have a very good chance, that you don't need something additionally.

But, if your peers can't reach each other without additional parts, e.g= .
because both in "their home network" and so communicate over a pa= th,
which uses a "public internet link", then you need more.

Therefore, please try to describe first the network(s) and the
communication paths you plan to use for your peers.

best regards
Achim

Am 06.04.20 um 14:31 schrieb Abhijan Bhattacharyya:
> Hi Carsten,
> Considering the practical deployment possibilities, I think we are qui= te
> far from expecting a clean IPv6 path. My home broadband service provid= er
> still serves IPv4 only. :)
> Apart from that there may always be some firewall in place considering=
> enterprise use cases and we would need to punch a hole.
> Thanks.
>
> On Mon, Apr 6, 2020 at 5:43 PM Carsten Bormann <cabo@tzi.org
> <mailto:cabo@tzi.= org>> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0On 2020-04-06, at 13:52, Christer Holmberg
>=C2=A0 =C2=A0 =C2=A0<christer.holmberg@ericsson.com
>=C2=A0 =C2=A0 =C2=A0<mailto:christer.holmberg@ericsson.com>> wrot= e:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I am not going to get involved in a discussio= n about that,
>=C2=A0 =C2=A0 =C2=A0because it is not CORE specific, but IPv6 is *NOT* = going to remove
>=C2=A0 =C2=A0 =C2=A0the need for NATs :)
>
>=C2=A0 =C2=A0 =C2=A0Of course not, IPv6 is not removing IPv4=E2=80=A6 := -)
>
>=C2=A0 =C2=A0 =C2=A0(That=E2=80=99s why I talked about a =E2=80=9Cclean= =E2=80=9D environment.)
>
>=C2=A0 =C2=A0 =C2=A0Gr=C3=BC=C3=9Fe, Carsten
>
>
>
> --
> Regards,
> Abhijan Bhattacharyya,
> /Technologist by profession [IoT| Internet Protocols| 5G]/
>
> _______________________________________________
> core mailing list
> core@ietf.org > https://www.ietf.org/mailman/listinfo/core
>

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


--
Regards,
Abhijan Bhattacharyya,
Technolo= gist by profession [IoT| Internet Protocols| 5G]
--0000000000007addda05a2a4bd9e-- From nobody Mon Apr 6 13:03:46 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEE23A0EE6; Mon, 6 Apr 2020 13:03: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, 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 AF5tFn9vsCF5; Mon, 6 Apr 2020 13:03:38 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23A63A0E79; Mon, 6 Apr 2020 13:03:37 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 6 Apr 2020 13:03:29 -0700 From: Jim Schaad To: 'Marco Tiloca' , CC: 'CoRE WG' References: <01c901d5fc9c$302115b0$90634110$@augustcellars.com> <065e01d6039b$41de9a10$c59bce30$@augustcellars.com> In-Reply-To: Date: Mon, 6 Apr 2020 13:03:28 -0700 Message-ID: <041301d60c4e$71f03b80$55d0b280$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIDQ+RuWpZlVDWZeusmtLn6W5UIMwHt4X2kAl3WMZIBanFLcafkSEaQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Review of draft-ietf-core-oscore-groupcomm-07 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, 06 Apr 2020 20:03:45 -0000 -----Original Message----- From: Marco Tiloca =20 Sent: Monday, April 6, 2020 10:32 AM To: Jim Schaad ; = draft-ietf-core-oscore-groupcomm@ietf.org Cc: 'CoRE WG' Subject: Re: Review of draft-ietf-core-oscore-groupcomm-07 Hi Jim, Version -08 [1] submitted today addresses most of your comments. A few points are still open and will be raised at the upcoming meeting = on Wednesday. Please, find some replies inline. Thanks again for your comments! Best, /Marco [1] https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-08 On 2020-03-26 19:20, Jim Schaad wrote: > > -----Original Message----- > From: Marco Tiloca > Sent: Wednesday, March 25, 2020 11:47 AM > To: Jim Schaad ;=20 > draft-ietf-core-oscore-groupcomm@ietf.org > Cc: 'CoRE WG' > Subject: Re: Review of draft-ietf-core-oscore-groupcomm-07 > > Hi Jim, > > Thank you for this review! > > Please, see inline some replies and requests for clarification. > > Best, > /Marco > > On 2020-03-17 21:39, Jim Schaad wrote: >> * Introduction - para 4 - I think you need to expand some text in=20 >> this section to explain why it is that doing a pairwise response is = still going >> to be considered to be group communication. This assumes some = intimate >> details of how multicast works in CoRE that might not be generally = known. > =3D=3D>MT > Yes, we can expand. A response is sent unicast either way. The = difference is that the pairwise-secure response remains confidential = between the originator server and the recipient client. > <=3D=3D > > [JLS] Yes, but in the case of block-wise, the following request might = also be sent unicast using the same context as well. This means that = both requests and responses are done using this. Thus you have taken = multi-cast into unicast. =3D=3D>MT Clarified in the current fourth and fifth paragraphs of Section 1. <=3D=3D [JLS] Looks good > >> * Section 1.1. - Silent Server: Consider adding the following to the = >> definition "Given that for CoAP group communications, messages are=20 >> normally sent without requesting a confirmation the idea of a server=20 >> silently acting on a message is not unreasonable." > =3D=3D>MT > Good input, will do. > <=3D=3D =3D=3D>MT Done. <=3D=3D ]JLS] Looks good >> * Section 2.4 - para #3 - The implications of the paragraph are=20 >> horrendous in terms of performance of the system. It basically says=20 >> that you need to do some excess processing in order to deal with this = >> issue following a key roll-over. If the first message received=20 >> cannot be validated by the signature then there is an issue of the=20 >> question was the message corrupted or was the id assigned to a new=20 >> entity and thus a new public key is required to be pulled down. > =3D=3D>MT > If we understand correctly, the reason leading to this is the Group = Manager re-assigning a dismissed Sender ID, e.g. to a new group member. > As a consequence, the server will be able to retrieve an old Recipient = Context matching that Sender ID, but then failing the message = verification as not considering the correct public key. Then the issue = you mention comes up. > > If this is correct, it=E2=80=99s probably worth adding some text like: = i) the Group Manager should not recycle Sender IDs, especially in the = short term; and ii) it=E2=80=99s up to application policies on the = servers to check at the Group Manager that they have the correct public = key for a given Sender ID, after a number of consecutive failed = verifications. > <=3D=3D > > [JLS] Yes that would be an appropriate set of text to alleviate the = issue. =3D=3D>MT Added the current fourth paragraph describing mitigation policies. <=3D=3D [JLS] Looks good >> * Section 3 - are all of these pairwise keys to be tossed away when=20 >> new keys are issued for the group? > =3D=3D>MT > Yes, because new Sender/Recipient keys are derived from the new group = keying material, and then used in the HKDF to derive the pairwise keys. > > Note that the same shared secret can be preserved across rekeyings. > Also, pairwise keys would not need to be recomputed right after a = rekeying, but latest upon message reception, as their derivation is = lightweight. We will clarify these points. > <=3D=3D > [JLS] Not sure that I think that doing a pairwise key agreement is = necessarily lightweight or that it is necessarily a good idea to keep = the computed shared secret in memory after it is needed. Might not be = quite as lightweight as you think. =3D=3D>MT Added text in Section 3.1 about discarding pairwise keys after a group = rekeying and deriving a new ones. On the shared secret, new text has been added about the fact that it = does not change across group rekeyings, while not explicitly saying that = it can be stored rather than computed again. <=3D=3D [JLS] It should mostly be a new security consideration that keeping this = secret around long term is a potential issue where, if it is leaked, = then an attacker can do impersonation as long as they are in the group. = This may be an issue because the private key could be protected at a = significantly higher level than generic memory is. For example in a = TPM. > >> * Section 3 - clarity is needed on how PIV is going to work for this. = =20 >> I would assume that it amounts to a separate context but this is not=20 >> completely clear from the text. > =3D=3D>MT > Our idea was to have a single PIV per sender, used for all its = outgoing messages, regardless the exact mode to protect each of them. We = will make it clearer in the text. > > As a side consideration also to add, this PIV may jump forward more = often, hence replay checks may be invoked more often on the recipient = side. To better handle it, larger replay windows should be considered. > > Bottom line, this is due to the fact that not all recipients receive = all messages from a given sender, i.e. the messages over multicast are = addressed to the whole group, while the unicast messages (in signature = or pairwise mode) are not. > <=3D=3D =3D=3D>MT Added a new Section 3.2 clarifying that a sender endpoint has a single = Sequence Number space, to use for all its outgoing messages regardless = of the mode used to protect them. <=3D=3D [JLS] Looks to be all there >> * Section 7. - Para 2 - I have a problem with the second sentence. I = >> think that you need to make it clear who is supposed to be doing this = >> retransmission. It should not be the CoAP system, but it is instead=20 >> the application. That means that a new request could be sent rather=20 >> than a retransmission occurring. > =3D=3D>MT > Ok, we'll clarify. > <=3D=3D =3D=3D>MT We have clarified that retransmissions are handled by the application = for group requests over multicast as Non-Confirmable. <=3D=3D [JLS] Look good > >> * Section 7.1 - Does not reflect the case where pairwise is used. = Ditto >> for other sections. - found it in section 8, but that does not seem=20 >> to be referenced from section 9 which is "message processing". > =3D=3D>MT > In this section, we can clarify that the text refers to the Signature = mode. Would it be ok? > > The pairwise mode is later described in Appendix G. > <=3D=3D > [JLS] Yes, that is a fine approach. =3D=3D>MT The beginning of Section 7 clarifies that its text refers to the = signature mode. <=3D=3D [JLS] Look good > >> * Section 7.4.1 - Must send the group identifier on the first observe = >> following a rekey operation to all clients. ---- I am not sure that=20 >> the group may not be required at all times - We need to discuss why = you think >> this would not be true. Think of the case of two different observe >> relations from the client to the same server sent using the same pair = >> of ports on both devices but with different groups. > =3D=3D>MT > This comment seems to actually refer to Section 7.3.1, third = paragraph. > > Probably the best compromise here is saying that a server MAY include = the Gid in many or all notifications after rekeying, e.g. if identifiers = are reused in different groups. This would trade off the message = overhead with the chance of collision. Would it be ok? > <=3D=3D > [JLS] There are two cases: 1) after the rekey and 2) two security = groups on the same multicast address (or unicast addresses in the case = of pair-wise) I still need to look at the second case as it may be = dealt with by message id. I am just not sure. > >> * Section 9 - I thought I understood how this is going to work and=20 >> after reading this I find that I am wrong. I am almost positive that = >> I dislike the compression for sending a request. > =3D=3D>MT > See reply below. Note that the part on optimized responses should be = fine, as identical in the pairwise mode of Appendix G. > <=3D=3D > >> * Section 9.1.1 - I believe that this is just wrong - I would have=20 >> thought that this is keep the tag and omit the countersignature. As=20 >> written you have messed up the AEAD and thus one level of security on = this. > =3D=3D>MT > Could you be more specific on the problem this creates? SIGMA-I and = IKE also consider a MAC not sent but included under a signature. > > Your original interpretation (keep the tag and omit the signature) is = the case of requests in the pairwise mode of Appendix G. > <=3D=3D > [JLS] There are a couple of different issues that I have for this:=20 > 1. I now need a new mode for my AEAD algorithm where it will provide = output without validating that the MAC is correct. I do not know if = this is doable with any of my current crypto libraries. > 2. It permits for one to create a situation where the same encrypted = value could potentially be decrypted into two different plain texts by = the use of different keys or IV values. It requires a security analysis = to ensure that this is not possible, for example in the case where a = sender incorrectly derived the key and base IV. > >> * Section 10.1 - should deal with the bilateral version and say that=20 >> it does not follow these rules. > =3D=3D>MT > We can surely add considerations about the pairwise mode of Appendix = G. > In particular, since the pairwise mode uses symmetric keys to protect = messages, it does provide pairwise confidentiality and source = authentication without signatures. > <=3D=3D =3D=3D>MT Added a paragraph discussing how this changes when using the pairwise = mode. <=3D=3D [JLS] Looks fine. >> * Section 10.7 has interesting block-wise implications that need to=20 >> be explored. > =3D=3D>MT > Could you elaborate more on this point? > > Does this =E2=80=9Cjust=E2=80=9D mean that the attack has an even more = severe impact when involving the transfer of big bodies with blockwise? = Or is it about something more, such as mixing-up the blocks of two = different but =E2=80=9Cakin=E2=80=9D > blockwise transfers to two different target servers? > > Should we even recommend against using the signature-mode for any = unicast request using block-wise, i.e. not only for non-safe methods = such as PUT, POST and PATCH/iPATCH? > <=3D=3D > > The first paragraph says that using group OSCORE is bad when done over = unicast, but if you do blockwise transfers and don't support the = pairwise situation then this is exactly what you are going to be doing. = I don't know if this means that the pairwise needs to be upgraded to a = mandatory to implement or if the NOT RECOMMENDED is too strong of a = statement for this situation. The same problem occur with use of the = ECHO option as the response to the ECHO needs to be unicast not = multicast (it only applies to a single server) and thus falls into this = same category. =3D=3D>MT Added the current fourth paragraph discussing how the attack affects = block-wise transfers. <=3D=3D [JLS] I think this covers my issue. > > Jim > > >> >> > -- > Marco Tiloca > Ph.D., Senior Researcher > > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) > > Phone: +46 (0)70 60 46 501 > https://www.ri.se > > > -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se From nobody Mon Apr 6 13:48:36 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3D93A08E0 for ; Mon, 6 Apr 2020 13:48:33 -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, 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 (1024-bit key) header.d=taitradio.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 rijboe9NTkji for ; Mon, 6 Apr 2020 13:48:32 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 49F3A3A08B1 for ; Mon, 6 Apr 2020 13:48:32 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id a43so1231114edf.6 for ; Mon, 06 Apr 2020 13:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=taitradio.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6iaMRbLOQdCiDahEh58Do6qcKmaAKmHIN9lif2Cph/U=; b=Ki+4TqPvY7wtTr1z/FesQCGezQu4AtNFMs6VOL8G5tfUwSf8ZXY19cSczTNAAGvryu Tg5bD3WcHkRYGdnX6TgW9EsJcPnWOG4jeDtpGP2Prjw4lVmV91nWAFCMqK8HGH0oELf5 ZjDPvvYfCWxNDYmgYd64YEym6FXsZu4v4EGBc= 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=6iaMRbLOQdCiDahEh58Do6qcKmaAKmHIN9lif2Cph/U=; b=Kw3tdCoFqtLcub17dV1A7ASGxr+3AyrFLnO8xjws/U5POVyO3hgC9azyok59ZV95gH gAxsxxUg+CReAqLng302v4gEdvCjiEpRSydv0Z33CW72pMa9N8CRvFuxqOiLCtA7Cl/e SV2xFCSdV/UYzOVt3AunLTJH6oSUKBz5A93nxDkAsO01qsABWcL/mOpDT+x7euWm/5ay 4rb4DCdoyPa1pEjCAA7cFd2Fhxoa94I/n0AxDwhZ/8v9rLzZujzFFimONAAvEWGVZltd PVXtzQpazx92FCfLyi9S2iktWSKncAcljQL621STFljXwQXpfpkZMqhWkJHHrNzdx4s1 iy+w== X-Gm-Message-State: AGi0Puao46BPnAOilv8FjNXiJHwQynwwBH9N8r1LqvtxDuzXgvtCHN4S 6mTvNSPEXEdYYq5rrSjCmZlYJGv1Wlv5/RSmfX6gY9kfw7ByobU8hKUIUXp+t8LuXyagVacuv26 Qyfi1Dd8AeDj7qybX0A== X-Google-Smtp-Source: APiQypKZAympLPSdjOgpr3BfmSWeZPY594IbVpi8RmYm5qzWU50ScHBlTF2Yt82RyJBQHfLjnYc81cejt/sYEGdQdbA= X-Received: by 2002:a17:906:5a90:: with SMTP id l16mr1289414ejq.276.1586206110597; Mon, 06 Apr 2020 13:48:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John Carter Date: Tue, 7 Apr 2020 08:48:18 +1200 Message-ID: To: Abhijan Bhattacharyya Cc: core Content-Type: multipart/alternative; boundary="000000000000c3696905a2a563b5" Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 06 Apr 2020 20:48:35 -0000 --000000000000c3696905a2a563b5 Content-Type: text/plain; charset="UTF-8" While the standard is, unlike the http standard, agnostic as to who is the client and who is the server and the roles can switch.... in practical experience I'd advise caution. 1. If you are not careful you end up with a system that only works if and only if all nodes are up and working. The best thing about REST is it reduces coupling and dependencies between client and server. If you two way couple them, you have made the coupling a lot stronger. 2. If you are not careful, you can end up with update loops. ie. Node A updates an observable resource, in response to which Node B updates a derived observable resource, which Node.... updates a derived observable resource, which triggers an update on Node A and around we go. On Thu, Apr 2, 2020 at 12:31 AM Abhijan Bhattacharyya < abhijan.bhattacharyya@gmail.com> wrote: > Hi, > Is there any standardized mechanism to use CoAP for a P2P connection? > Thanks. > > -- > Regards, > Abhijan Bhattacharyya, > *Technologist by profession [IoT| Internet Protocols| 5G]* > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > -- John Carter Phone : (64)(3) 358 6639 Tait Electronics PO Box 1645 Christchurch New Zealand -- This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.taitradio.com/email_disclaimer --000000000000c3696905a2a563b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While the standard is, unlike the http standard, agno= stic as to who is the client and who is the server and the roles can switch= .... in practical experience I'd advise caution.

1. If you are not careful you end up with a system that only works if an= d only if all nodes are up and working. The best thing about REST is it red= uces coupling and dependencies between client and server. If you two way co= uple them, you have made the coupling a lot stronger.

2. If you are not careful, you can end up with update loops. ie. No= de A updates an observable resource, in response to which Node B updates a = derived observable resource, which Node.... updates a derived observable re= source, which triggers an update on Node A and around we go.

=

= On Thu, Apr 2, 2020 at 12:31 AM Abhijan Bhattacharyya <abhijan.bhattacharyya@gmail.com> w= rote:
Hi,
Is there any standardized mechanism to use CoAP for a P2P = connection?=C2=A0
Thanks.

--
=
Rega= rds,
Abhijan Bhattacharyya,
Technologist by pr= ofession [IoT| Internet Protocols| 5G]
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


--
John Carter
Phone : (64)(3) 358 6639Tait Electronics=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
PO Box 1645 Christchurch
New = Zealand


This Communication is Confidential. We only send and receive email on t= he
basis of the terms set out at www.taitradio.com/email_disclaimer
--000000000000c3696905a2a563b5-- From nobody Mon Apr 6 15:50:48 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E463A0C94 for ; Mon, 6 Apr 2020 15:50:47 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 uaq55bbP_Odt for ; Mon, 6 Apr 2020 15:50:45 -0700 (PDT) Received: from mail-io1-f71.google.com (mail-io1-f71.google.com [209.85.166.71]) (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 B18D43A0AD7 for ; Mon, 6 Apr 2020 15:50:45 -0700 (PDT) Received: by mail-io1-f71.google.com with SMTP id p4so1387589ioo.4 for ; Mon, 06 Apr 2020 15:50:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:references:in-reply-to :message-id:subject:from:to:cc; bh=L3EyG+70X0JYND9MYBTykh0hoESbDjbKEh/rxTKu660=; b=pPvz10YtfJkYdEpgFm497pd3me6kP5Xbr6KRUDIYqe+BQIbakNy2XrkpnQwDZ4xzDQ fxZd9rXOP28UiCCPErZXscvZVq7Cy75XXxd7/ch9JOK4B1O8l65Kl7cyO3NFGfGuCMbW eJiLmPYvNmCm2nyJTNZXVSFsQNUMM9DLdGxLL61SxJeSlorxWRulIdIReJTGkEf+cDK5 qBCt1mdAPu/M8ehcRHw7euiY1IZkoHJBKczGNgPXhPS+k7Pu0DFxQnBhz6fk/l4H30J2 yDSHj0xu9xGZEl3WaTc3UdkyovxQF41rdzlzAwjZ2bkgnfTlSQDm3drbzWeEqM8gv4J3 Rwfw== X-Gm-Message-State: AGi0Pub+6meKAGP1/85ITjnjtm6ySOOC4RVyafEAET2kVJIRJ2nh6Okv F8o5KUVRaoi35Yw7AU2/knShnrpg+t5vUYD+m7Mkkfc7h7LvdRGrPVc6E58wqRPqQVTKu7/x5bX URdIhjEtXYcFg7e0oC/gojaU= X-Google-Smtp-Source: APiQypLT1KXh9v94RYDzeTjHJvyqsw/tb2d7zkS6a/cKQgVf4X6iVLxiuQ5EjoXIa3y8kCLNTTn4izyD9s8OIksjqgLFo1rFyvewwA== X-Received: by 2002:a6b:4109:: with SMTP id n9mr21836438ioa.141.1586213444759; Mon, 06 Apr 2020 15:50:44 -0700 (PDT) MIME-Version: 1.0 Date: Tue, 7 Apr 2020 08:48:18 +1200 References: In-Reply-To: Message-ID: From: John Carter To: Abhijan Bhattacharyya Cc: core Content-Type: multipart/alternative; boundary="00000000000023f06d05a2a5639a" Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 06 Apr 2020 22:50:47 -0000 --00000000000023f06d05a2a5639a Content-Type: text/plain; charset="UTF-8" While the standard is, unlike the http standard, agnostic as to who is the client and who is the server and the roles can switch.... in practical experience I'd advise caution. 1. If you are not careful you end up with a system that only works if and only if all nodes are up and working. The best thing about REST is it reduces coupling and dependencies between client and server. If you two way couple them, you have made the coupling a lot stronger. 2. If you are not careful, you can end up with update loops. ie. Node A updates an observable resource, in response to which Node B updates a derived observable resource, which Node.... updates a derived observable resource, which triggers an update on Node A and around we go. On Thu, Apr 2, 2020 at 12:31 AM Abhijan Bhattacharyya < abhijan.bhattacharyya@gmail.com> wrote: > Hi, > Is there any standardized mechanism to use CoAP for a P2P connection? > Thanks. > > -- > Regards, > Abhijan Bhattacharyya, > *Technologist by profession [IoT| Internet Protocols| 5G]* > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > -- John Carter Phone : (64)(3) 358 6639 Tait Electronics PO Box 1645 Christchurch New Zealand -- This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.taitradio.com/email_disclaimer --00000000000023f06d05a2a5639a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While the standard is, unlike the http standard, agno= stic as to who is the client and who is the server and the roles can switch= .... in practical experience I'd advise caution.

1. If you are not careful you end up with a system that only works if an= d only if all nodes are up and working. The best thing about REST is it red= uces coupling and dependencies between client and server. If you two way co= uple them, you have made the coupling a lot stronger.

2. If you are not careful, you can end up with update loops. ie. No= de A updates an observable resource, in response to which Node B updates a = derived observable resource, which Node.... updates a derived observable re= source, which triggers an update on Node A and around we go.

=

= On Thu, Apr 2, 2020 at 12:31 AM Abhijan Bhattacharyya <abhijan.bhattacharyya@gmail.com> w= rote:
Hi,
Is there any standardized mechanism to use CoAP for a P2P = connection?=C2=A0
Thanks.

--
=
Rega= rds,
Abhijan Bhattacharyya,
Technologist by pr= ofession [IoT| Internet Protocols| 5G]
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


--
John Carter
Phone : (64)(3) 358 6639Tait Electronics=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
PO Box 1645 Christchurch
New = Zealand


This Communication is Confidential. We only send and receive email on t= he
basis of the terms set out at www.taitradio.com/email_disclaimer
--00000000000023f06d05a2a5639a-- From nobody Mon Apr 6 19:43:04 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0323A139B; Mon, 6 Apr 2020 19:43:03 -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 ziquWxqDUFAf; Mon, 6 Apr 2020 19:43:02 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A3B3A139A; Mon, 6 Apr 2020 19:43:01 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 6 Apr 2020 19:42:54 -0700 From: Jim Schaad To: CC: 'CoRE WG' Date: Mon, 6 Apr 2020 19:42:52 -0700 Message-ID: <043b01d60c86$3e1b8430$ba528c90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdYMWMU/Y2WOhYtxT1+Xupw5p6++hQ== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Review on draft-ietf-core-oscore-groupcomm--08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 02:43:03 -0000 * Section 3 - Is there supposed to be a signal that an endpoint does or does not support this? As part of the entity context? * In section 3.2 - the second paragraph is not completely correct. The only reason that the behavior of sequence numbers is going to change would be if the client and server send messages back and forth that they would not have normally wrapped with the group key. For the purpose of getting large content via blockwise this would not be the case. I don't believe that you are suggesting that these keys should be used for doing pair wise key establishment for things which would not be thought of as, in theory, part of a multicast application. * Section 10.4 - If client sends request in security context A, the server MUST NOT use reflection of the PIV if it is going t reply in security context B. Otherwise there is a chance that the same IV would be used twice in security context B. * Appendix A bullet #2 - This says that /.well-known/core cannot be part of two different application groups. That may be fine depending on how an application group is defined but it may not if one says that an application group member needs to do a search, inside of the application group, for resources from that resource. * Appendix E.1 - The second and third paragraphs seem to say the exactly opposite things. A very close reading shows that they don't, but it is hard on first read to detect that. * Appendix E.1 - I disagree with the recommendation of paragraph 3 in this section. The server would care about freshness only in the question of should it be processed and not in terms of how to process the response message. Using the reflected PIV seems to be perfectly reasonable if the server is willing to process the request. Given that responses almost never go via a multicast channel, a client would not see any responses from the server except to itself. The client has the ability to know when it sent the request and thus knows how long the response took and if it would consider it to be fresh enough. ** Same argument for E.2 * Appendix E.2 - This description omits one potential step that I would consider to be vital in this method. That is you receive the message, set the sequence number, DROP THE REQUEST, and then wait for new requests which have a higher sequence number. There is still the replay attack, but that also exists for E.1 as well. * Appendix E.3 - May want to add a note that there is no confusion about why the 4.01 is being returned because the message will be protected by the group security key so it is known that the crypto security is just fine. * Appendix E.3 - The idea of doing the echo sync process following a "large enough gap" in seen sequence numbers can potentially be problematic if you are also saying that a client may be doing a large number of unicast operations to a number of servers. This has the ability to consume that gap faster than one might think. This should be added here. Trade-offs between a sequence number gap and a time gap should probably be discussed. * Appendix E.3 - para 2 - The should be stored with the Echo Option value by the server and the Echo Option value should only be accepted if the same sender produced the message. An implication of this is that a roll over to a new key set means that all of the old Echo Option values would disappear, but you would still have the required freshness as use of the new crypto context means that there is a limit as to when it could have first been requested. Note that I think that this foils the section 10.7 attack as while an attacker can get the value, it does them no good because they cannot produce the required signature. *Appendix E.3 - The Echo option MUST NOT be sent in a multicast message because it makes no sense to any but one server. Jim From nobody Mon Apr 6 19:55:29 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11FE3A13D9 for ; Mon, 6 Apr 2020 19:55:27 -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 hawOBYvtyKcf for ; Mon, 6 Apr 2020 19:55:26 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085AC3A13D6 for ; Mon, 6 Apr 2020 19:55:25 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 6 Apr 2020 19:55:21 -0700 From: Jim Schaad To: 'John Mattsson' , References: <5CD4BE47-4E21-4E00-8BE7-752917CBAF51@ericsson.com> In-Reply-To: <5CD4BE47-4E21-4E00-8BE7-752917CBAF51@ericsson.com> Date: Mon, 6 Apr 2020 19:55:20 -0700 Message-ID: <043c01d60c87$fb334d90$f199e8b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQL8aJ5Y4j4+j1wW67pe+hm3VQlWd6YfmYaw Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Allowing non-HMAC based KDF in OSCORE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 02:55:28 -0000 -----Original Message----- From: core On Behalf Of John Mattsson Sent: Friday, April 3, 2020 4:04 AM To: core@ietf.org Subject: [core] Allowing non-HMAC based KDF in OSCORE Hi, As pointed out by Jim in the COSE virtual interim yesterday, OSCORE restricts the type of KDF to HMAC-based HKDF algorithms. I do not know (or remember) why the restriction is there. - There are no security reasons for the limitation (at least not if Master Secret is uniformly random), and it currently hinders OSCORE to be used with the COSE AES based KDFs. - The restriction is currently a practical problem. 6TiSCH people have stated that using AES and SHA-256 is not a problem at all. [JLS] I am not sure that I under stand where the immediate practical problem is. If SHA-256 is not a problem then HMAC-SHA-256 can be used as the PDF for HKDF. - however, the restriction may be more limiting in the future. COSE is currently discussing adding KMAC. For a node implementign SHAKE128, HMAC is overkill, and KMAC is a simpler and more lightweight alternative. HMAC was specifically design to mitigate the length extension attacks of early hash functions and is not needed for SHA-3. NIST lightweight crypto competition have many primitives that can be used for both AEAD and hashing, they will likely have lightweight KDF modes different from HMAC mode. I don't think there is any hurry to change this restriction but I think it should be changed at some point. It makes sense for OSCORE to allow any KDF specified in COSE. I would suggest that Group OSCORE (which updates OSCORE) lifts this limitation also for RFC 8613. Another possibility is to write a new draft, but it seems easier to just put it in Group OSCORE. [JLS] Right - as of today the legal set of values for this should be -10, -11, -12 and -13. Instead only the first two are legal because of the restriction to HMAC as the pdf. Jim Cheers, John _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Mon Apr 6 21:29:27 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BF43A1570 for ; Mon, 6 Apr 2020 21:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, 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 n0bsu3NRSgKw for ; Mon, 6 Apr 2020 21:29:23 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70051.outbound.protection.outlook.com [40.107.7.51]) (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 12B0E3A1550 for ; Mon, 6 Apr 2020 21:29:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JVBan+a8hww3tntNnv8dx23Z8JwV3btvCsdYnA+NJe8cg8LY8FVdeY3rved8tDNQ4ePYDiNx5AgF2B1IgUOwCW2wnWYOpaFLmZNQE1D1HO/USpOe9wzWmPLjB3KMdk7hCrTXx9gnEaUHoedC7YekgOB5dcdrHxyyKMXPBIj5CC8WFq2XeUXvT2km1RtJP+KDG9WRLSHm3SKiNEOIxRRh0rebTvVPEE6WO61zT2P+gqp171YSKH5Nz1ae03XC8zPVHF54qQEDxJ3AcJU/oqsCiCTt0FT0T7P4V8/B0UQosiuxqP+Rdab596fkFs+RO5CAq5ZVpD5bl6HLRkt5NEwBoQ== 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=ZfpFM2Z40l1y1u0vMCOrR+gzANiy6ZWnl7ESyT5u4fo=; b=ady5x2rt3F0pZL3cuMEcPfmqmOd3Wirez/ozz/JEvOkOjUdukMOgs3pUcAHKrh7u033H3jtbhBq0IFSIchLBoH+7krvGhzFImDxP6z+g1dwyxFGhbHmYKkSuX3qyxbJKuJ/HgKQbGQOMdGdBqRah2cxRz1h4/h4eWWc7vdDb8WCd+1+BiI7GURep8KHiS1XQRHXvL5qh3riePzwY9qA+I7i1HWl5KJAOPxKvAW3iyLpvKg9xxB/lNMsNZskfBhc20RQ8AQm/juWMsPoHgRptJx5zmbJTSvrkO0Bom7xOUarIXOPslTorfNWg9OXLLwRnHPryTIPmOjN7XRwIvfWf/g== 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=ZfpFM2Z40l1y1u0vMCOrR+gzANiy6ZWnl7ESyT5u4fo=; b=mv9nvpWe3G286o2OQ8lOWqEnINDY4HaSYX2eYx29a6kI90IZ2GX33kVospn+tToPLUHvKn+a4XLilc1Ld8bB3psL2bfkBpJoS9vbE6gkhCjhT5OHh4AyZO/iYRPCa84JfFrSEGGsnejylSBiV3oE0iMrK208X6qW0JP4bD/cfqo= Received: from AM6PR07MB4584.eurprd07.prod.outlook.com (20.177.37.216) by AM6PR07MB3848.eurprd07.prod.outlook.com (52.134.114.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.13; Tue, 7 Apr 2020 04:29:20 +0000 Received: from AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::928:dc19:896b:4b91]) by AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::928:dc19:896b:4b91%6]) with mapi id 15.20.2900.012; Tue, 7 Apr 2020 04:29:20 +0000 From: John Mattsson To: Jim Schaad , "core@ietf.org" Thread-Topic: [core] Allowing non-HMAC based KDF in OSCORE Thread-Index: AQHWCaeQBKQ/R/PrJ0CpFz210vCuHahs/KMAgAA7yoA= Date: Tue, 7 Apr 2020 04:29:19 +0000 Message-ID: <13AC1C7F-0D0A-479D-B8BD-EF95333C6CD6@ericsson.com> References: <5CD4BE47-4E21-4E00-8BE7-752917CBAF51@ericsson.com> <043c01d60c87$fb334d90$f199e8b0$@augustcellars.com> In-Reply-To: <043c01d60c87$fb334d90$f199e8b0$@augustcellars.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: db9e46b4-e852-49a9-1a88-08d7daac3dbd x-ms-traffictypediagnostic: AM6PR07MB3848: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB4584.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(396003)(346002)(366004)(5660300002)(66556008)(44832011)(2906002)(33656002)(110136005)(76116006)(66476007)(316002)(64756008)(91956017)(6486002)(2616005)(66446008)(71200400001)(66946007)(478600001)(8936002)(6512007)(81156014)(81166006)(8676002)(86362001)(4744005)(186003)(6506007)(36756003)(26005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0L5OuT+dbyANzNPeljPQNVWXQ0jRVack2RlOdPDfH38sSTMUU6rKWHd8CyGCeGbKWM0/6NnU53K5deKFUWWFyYM4Bm2fZdw87bIuF/k5mUA+AvwxUznPzOwFfLIWaPEffqrJF8KLbPSxfUJVqp5LfDFXp95wDhF2VxJrq+t8PgV2QgX8FVDDB6iWkwIfEfS6mrAiZkR2u4pT1aHg0CgPbBjMCF/eJU/moiYGmmnmj++Wb0OZzxj4B4UMJXx+398UtNRDdPFZ3TU6RPAg+O7oyhQJeDUhfQaVAqH+poYu19raavcf6tfQADx+Qb5+UU7q42GpzDKU/nHHfwQbxMKLbNYmVVhKKi9a8W/juej/wkcKIQVXJTtUeoQ0nGrGqK6ESqwPUjbYI37teYIdsP5++tbDhyOqhu20BRmLcHJ1CMFREDpHaUrSmVMhvWPxEGCP x-ms-exchange-antispam-messagedata: xjUIu+NwGrOWrRFLGusZbGAJY603LwnzalH9qh91g8nD2CwQMA2IqQil+UnoUnt3Pd4koGy7JUS/SuVWGqtceb5narI9IgwecqTVhA9kq2LGI7mjaoZlPMZTKal25w5eT93DhVTtP7GJRwGbQTbEMw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7DB374ED84ECC047A5145104BA190B0E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: db9e46b4-e852-49a9-1a88-08d7daac3dbd X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2020 04:29:20.0088 (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: W25VgveMejvMWB9L+49uY2nS58r4XcCVSkONifxdTK0D7O5J6zlZyuCLgMAIT1leutR3u5/L2YN/Xg/nbhyzC7JX7JHexH8IarWQgeEVGcM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB3848 Archived-At: Subject: Re: [core] Allowing non-HMAC based KDF in OSCORE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 04:29:27 -0000 LSBKaW0gU2NoYWFkIHdyb3RlOg0KDQogICAgLSBUaGVyZSBhcmUgbm8gc2VjdXJpdHkgcmVhc29u cyBmb3IgdGhlIGxpbWl0YXRpb24gKGF0IGxlYXN0IG5vdCBpZiBNYXN0ZXINCiAgICBTZWNyZXQg aXMgdW5pZm9ybWx5IHJhbmRvbSksIGFuZCBpdCBjdXJyZW50bHkgaGluZGVycyBPU0NPUkUgdG8g YmUgdXNlZCB3aXRoDQogICAgdGhlIENPU0UgQUVTIGJhc2VkIEtERnMuDQogICAgLSBUaGUgcmVz dHJpY3Rpb24gaXMgY3VycmVudGx5IGEgcHJhY3RpY2FsIHByb2JsZW0uIDZUaVNDSCBwZW9wbGUg aGF2ZQ0KICAgIHN0YXRlZCB0aGF0IHVzaW5nIEFFUyBhbmQgU0hBLTI1NiBpcyBub3QgYSBwcm9i bGVtIGF0IGFsbC4NCiAgICBbSkxTXSBJIGFtIG5vdCBzdXJlIHRoYXQgSSB1bmRlciBzdGFuZCB3 aGVyZSB0aGUgaW1tZWRpYXRlIHByYWN0aWNhbCBwcm9ibGVtDQogICAgaXMuICBJZiBTSEEtMjU2 IGlzIG5vdCBhIHByb2JsZW0gdGhlbiBITUFDLVNIQS0yNTYgY2FuIGJlIHVzZWQgYXMgdGhlIFBE Rg0KICAgIGZvciBIS0RGLg0KDQpbSlBNXSBTb3JyeSBteSBmYXVsdCwgSSBpbnRlbmRlZCB0byB3 cml0ZSB0byB3cml0ZSB0aGUgb3Bwb3NpdGU6ICJUaGUgcmVzdHJpY3Rpb24gaXMgY3VycmVudGx5 IE5PVCBhIHByYWN0aWNhbCBwcm9ibGVtIiwgYnV0IENocmlzdGlhbiBzZWVtcyB0byB0aGluayBp dCBpcyBpbmNvbnZlbmllbnQuDQoNCkpvaG4NCiANCg0K From nobody Mon Apr 6 21:33:17 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4BE3A1564 for ; Mon, 6 Apr 2020 21:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, 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 wQy1OiZyCKWG for ; Mon, 6 Apr 2020 21:33:15 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on0606.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::606]) (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 DFF883A1563 for ; Mon, 6 Apr 2020 21:33:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RWx2kgY3WGJUzY+YSwtBtJVMibZCqu0qSjODYBzuHCiYNldnp1BnZU/jYGlCj36zpHYt6Y2EPRAJGlJGCQ1xYGoe/er4cM7OJ6H/Imsg+aPPuW6J/Ub6BR8roaTSY13frVkyDSzbYHUMIi6l0fANHUiuGRdu5kGsO14vzke6Fv0/hIFUfgPVEaOy4oaNO357H0x3RNaDcUum1n5SJXFtpDwu1KI6H9x17opPrgF3yi4amXe2qPpxAV3pb/d80sHjXza0+Y+le+H7i8bCVu57dcR9OFir7nixqLs4y3ZIVqfh0j2vL3sPmVJ83k1yoxB7GpwLno/fArR+jGbdB/VBOw== 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=cpEm+n/qOBvo+ggxR34kzcje3ctmf05OIs3dSAGUj3Y=; b=Ob6AD80hfIrYYcNxcXMqer33YEHEHBDXudAFmOT+uSgkJtix/b3VdQcK1wwS185NGeVy/7fiYC2NyjGbAN4VkFQz8rOWtwmV4kka86XsNcDt0o9NP5tu4SMJ395h7bnsk0hFrMTJuX38KjRQ/XT8JtHQOlYfUTiI6dcIbPE40QahQFGRC6GdDMkwqbY7uh0AEE5Qsu/U+qsz0POXd4PZ55ZKGVWzIrmxLYeXg7Z5uW93iJZfqZB/UPpdR2BlsPwpLlzjz2dx4AOK5iDa7fNWQMLwxgmeeHRHfXtzCX9CoqRkAHqKAsLxDgYrNbiQYHModl4vcEE7z4x7xUv7t0Bb6Q== 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=cpEm+n/qOBvo+ggxR34kzcje3ctmf05OIs3dSAGUj3Y=; b=XWOxLlkrVWlXviMzcxEPQ1rBE30jDi9B04MlkRJvEnzLV57eaxCTRiCEg1UAj9Rvqgrbb8M6Eqjjlj5fpco9zIlb/AhmSgnZYSkOoxyDPfUGKkdRuttdnRr0y5sVCDvtjLBDimAiXbz9D/gKSrj7kBGIHvWSYBVr2LdDYkpsC7k= Received: from AM6PR07MB4584.eurprd07.prod.outlook.com (20.177.37.216) by AM6PR07MB3848.eurprd07.prod.outlook.com (52.134.114.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.13; Tue, 7 Apr 2020 04:33:12 +0000 Received: from AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::928:dc19:896b:4b91]) by AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::928:dc19:896b:4b91%6]) with mapi id 15.20.2900.012; Tue, 7 Apr 2020 04:33:12 +0000 From: John Mattsson To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= CC: "core@ietf.org" Thread-Topic: [core] Allowing non-HMAC based KDF in OSCORE Thread-Index: AQHWCaeQBKQ/R/PrJ0CpFz210vCuHahsSpsAgADu5oA= Date: Tue, 7 Apr 2020 04:33:12 +0000 Message-ID: <9F199D88-4F17-4B6D-B91B-73C904464906@ericsson.com> References: <5CD4BE47-4E21-4E00-8BE7-752917CBAF51@ericsson.com> <20200406161808.GB2688660@hephaistos.amsuess.com> In-Reply-To: <20200406161808.GB2688660@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 739dc34b-eea7-4427-da1d-08d7daacc83d x-ms-traffictypediagnostic: AM6PR07MB3848: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB4584.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(396003)(346002)(366004)(6916009)(5660300002)(66556008)(44832011)(2906002)(4326008)(33656002)(76116006)(66476007)(316002)(64756008)(91956017)(6486002)(2616005)(66446008)(71200400001)(66946007)(478600001)(8936002)(6512007)(81156014)(81166006)(8676002)(86362001)(53546011)(186003)(6506007)(36756003)(26005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3zELhohQhNePeR2F7HBM0iCm5JeEcGtBqEnRmHpRmonoscMlMJTVpO+siK0yz+xhTxQuB17k+HJG+fgyh5oAKUkWyFszKypT+0KmB6ebzxgZ7CLRR/Py0zV+vHH4mlEJIwxkTA1oLy9Gb6cEGde1WSrAlSMDKivV4YXuhH+czzUJmtJDoBzmBGGiK2bNukiG3VM4KabOC59WPSg2NPXK0RmxkB5wxF318brWEVtnbH24dk80+0uHqPmMf6FWYZgp/nqjdpPsxXqgNTMr4USeULYdm0CO8QoENmI00cYht8WEKgm5VcOytRsfrAK11GFKOh1FgOVAzYDqiSWo/Kd+8S6GJsFcAws5NJ3NBItA2xk/0RfSIMYFBaDgj4ZHALuoWU1V7lxIuzv2Sr3YoFU+x9u4JKxUm8ymoZBAvz6oz7RlLbSefBqlsSulMFzHq2NR x-ms-exchange-antispam-messagedata: 3zbwlm9hzmuhGwRXw354NC4CS0ubFL0jLA5KqIV1I+6XT8COKIQRYFcjzg+rQNGe1H8vELKMHH6EUL8ZRrBXtgrzMdjWtJWnTTqRsj3jhs0734GIPjNd2n5RsbJnIoVhbss8ysYLWk48bQyr1r9lnw== 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-Network-Message-Id: 739dc34b-eea7-4427-da1d-08d7daacc83d X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2020 04:33:12.4161 (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: VaJ7X+T0GHhCLUY4weTnIRbbszntswVairkg/y4lQG6j5+bcngaBzUfHdozC8Rfed7WQNYPO4qBz+u2exVGjIHwmE4LEu63SJ4SMDYN1uzM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB3848 Archived-At: Subject: Re: [core] Allowing non-HMAC based KDF in OSCORE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 04:33:16 -0000 Q2hyaXN0aWFuIEFtc8O8c3Mgd3JvdGU6DQoNCiAgICA+IEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMg YW55IGh1cnJ5IHRvIGNoYW5nZSB0aGlzIHJlc3RyaWN0aW9uIGJ1dCBJDQogICAgPiB0aGluayBp dCBzaG91bGQgYmUgY2hhbmdlZCBhdCBzb21lIHBvaW50LiBJdCBtYWtlcyBzZW5zZSBmb3IgT1ND T1JFIHRvDQogICAgPiBhbGxvdyBhbnkgS0RGIHNwZWNpZmllZCBpbiBDT1NFLiBJIHdvdWxkIHN1 Z2dlc3QgdGhhdCBHcm91cCBPU0NPUkUNCiAgICA+ICh3aGljaCB1cGRhdGVzIE9TQ09SRSkgbGlm dHMgdGhpcyBsaW1pdGF0aW9uIGFsc28gZm9yIFJGQyA4NjEzLg0KICAgIA0KICAgIElmIHdlIGdv IHRoYXQgcm91dGUgKHdoaWNoIHNvdW5kcyB2aWFibGUgdG8gbWUpLCBjb3VsZCB3ZSBoYXZlIGEg IlRoZXJlDQogICAgYXJlIG5vIHRlY2huaWNhbCByZWFzb25zIHdoeSB0aGlzIGNvdWxkIG5vdCBi ZSBleHRlbmRlZCB0byAobm9uLWdyb3VwKQ0KICAgIE9TQ09SRTsgdXBkYXRpbmcgdGhhdCBzcGVj aWZpY2F0aW9uIGluIGEgbGF0ZXIgZG9jdW1lbnQgaXMgYmVpbmcNCiAgICBjb25zaWRlcmVkLiIg aW4gdGhlcmU/DQoNCltKUE1dIEkgd2FzIG1vcmUgdGhpbmtpbmcgdGhhdCBHcm91cCBPU0NPUkUg ZG9jdW1lbnQgYWxyZWFkeSBub3cgd3JpdGVzIHRoYXQNCg0KICAgIFRoaXMgZG9jdW1lbnQgdXBk YXRlcyBSRkMgODYxMyBhcyBmb2xsb3dzOg0KICAgDQogICAgT0xEOiBUaGUgSEtERiBNVVNUIGJl IG9uZSBvZiB0aGUgSE1BQy1iYXNlZCBIS0RGIFtSRkM1ODY5XSBhbGdvcml0aG1zDQogICBkZWZp bmVkIGZvciBDT1NFIFtSRkM4MTUyXS4NCg0KICAgTkVXOiBUaGUgS0RGIE1VU1QgYmUgb25lIG9m IHRoZSBLREYgYWxnb3JpdGhtcyBkZWZpbmVkIGZvciBDT1NFIFtSRkM4MTUyXQ0KDQoNCkpvaG4N Cg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENocmlzdGlhbiBBbXPDvHNz IDxjaHJpc3RpYW5AYW1zdWVzcy5jb20+DQpEYXRlOiBNb25kYXksIDYgQXByaWwgMjAyMCBhdCAx ODoxOA0KVG86IEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPg0KQ2M6 ICJjb3JlQGlldGYub3JnIiA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0gQWxs b3dpbmcgbm9uLUhNQUMgYmFzZWQgS0RGIGluIE9TQ09SRQ0KDQogICAgSGVsbG8gSm9obiwNCiAg ICANCiAgICBPbiBGcmksIEFwciAwMywgMjAyMCBhdCAxMTowMzo1NEFNICswMDAwLCBKb2huIE1h dHRzc29uIHdyb3RlOg0KICAgID4gQXMgcG9pbnRlZCBvdXQgYnkgSmltIGluIHRoZSBDT1NFIHZp cnR1YWwgaW50ZXJpbSB5ZXN0ZXJkYXksIE9TQ09SRQ0KICAgID4gcmVzdHJpY3RzIHRoZSB0eXBl IG9mIEtERiB0byBITUFDLWJhc2VkIEhLREYgYWxnb3JpdGhtcy4gSSBkbyBub3Qga25vdw0KICAg ID4gKG9yIHJlbWVtYmVyKSB3aHkgdGhlIHJlc3RyaWN0aW9uIGlzIHRoZXJlLg0KICAgIA0KICAg IGZyb20gYW4gaW1wbGVtZW50ZXIgcG9pbnQgb2YgdmlldywgaXQgd291bGQgYmUgbXVjaCBhcHBy ZWNpYXRlZCBpZiBhbg0KICAgIE9TQ09SRSBsaWJyYXJ5IHdvdWxkIG9ubHkgbmVlZCB0byBhc2sg aXRzIGJhY2tlbmQgQ09TRSBsaWJyYXJ5IHRoaW5ncyBpdA0KICAgIGNhbiBrbm93IChlZy4gd2hl dGhlciBhbiBhbGdvcml0aG0gaXMgYSBLREYgYWxnb3JpdGhtKSBhbmQgbm90IGhhdmUgdG8NCiAg ICBzaGlwIGFkZGl0aW9uYWwga25vd2xlZGdlIGFib3V0IGFsZ29yaXRobXMuDQogICAgDQogICAg PiBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueSBodXJyeSB0byBjaGFuZ2UgdGhpcyByZXN0cmlj dGlvbiBidXQgSQ0KICAgID4gdGhpbmsgaXQgc2hvdWxkIGJlIGNoYW5nZWQgYXQgc29tZSBwb2lu dC4gSXQgbWFrZXMgc2Vuc2UgZm9yIE9TQ09SRSB0bw0KICAgID4gYWxsb3cgYW55IEtERiBzcGVj aWZpZWQgaW4gQ09TRS4gSSB3b3VsZCBzdWdnZXN0IHRoYXQgR3JvdXAgT1NDT1JFDQogICAgPiAo d2hpY2ggdXBkYXRlcyBPU0NPUkUpIGxpZnRzIHRoaXMgbGltaXRhdGlvbiBhbHNvIGZvciBSRkMg ODYxMy4NCiAgICANCiAgICBJZiB3ZSBnbyB0aGF0IHJvdXRlICh3aGljaCBzb3VuZHMgdmlhYmxl IHRvIG1lKSwgY291bGQgd2UgaGF2ZSBhICJUaGVyZQ0KICAgIGFyZSBubyB0ZWNobmljYWwgcmVh c29ucyB3aHkgdGhpcyBjb3VsZCBub3QgYmUgZXh0ZW5kZWQgdG8gKG5vbi1ncm91cCkNCiAgICBP U0NPUkU7IHVwZGF0aW5nIHRoYXQgc3BlY2lmaWNhdGlvbiBpbiBhIGxhdGVyIGRvY3VtZW50IGlz IGJlaW5nDQogICAgY29uc2lkZXJlZC4iIGluIHRoZXJlPw0KICAgIA0KICAgIEtSDQogICAgYw0K ICAgIA0KICAgIC0tIA0KICAgIEkgc2hvdWxkbid0IGhhdmUgd3JpdHRlbiBhbGwgdGhvc2UgdGFu ayBwcm9ncmFtcy4NCiAgICAgIC0tIEtldmluIEZseW5uDQogICAgDQoNCg== From nobody Mon Apr 6 23:22:45 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BA03A173B for ; Mon, 6 Apr 2020 23:22:38 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlWoTRX4fIJR for ; Mon, 6 Apr 2020 23:22:33 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 2B5CB3A173A for ; Mon, 6 Apr 2020 23:22:33 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id f20so541485wmh.3 for ; Mon, 06 Apr 2020 23:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tXe3/5SJohzwwOJ8f16rp8szi6HRnT2YhV6+MTvkyH4=; b=C40iZPO1Of9nHCOEcnH+zv9bmxOyDS0CxkH7w/6Xt+6nf7YsvxoiGukgVc4in8tk8P ZKhPbGqgjk5Fn7l46xWPw42Sb4HEWJwkSFM7VCCRprzZkyGuqe2gGzlGGVcZxS38K2oH 08LBg8auQNZJY712y/yCrVs6NgyKXTCxnZNzbcpKGIcq7smhPd+YePzplGd5vy0g10Ff a3Y1xgTv5/hSaN6L76+Ooxx2Vst5yZbtltZnHrRoEDf0rCRVswCp628O0x9K0OBoZmWT OB4cu5mPjw1lrDm2MvSPl4EieyaWKlUEQWq+utamnLnclY6PIuA4PQsDR5XW+VPjF1Rq 35eA== 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=tXe3/5SJohzwwOJ8f16rp8szi6HRnT2YhV6+MTvkyH4=; b=LAxaVi+XBwmR1d4rcWo67lptwyiUlPYunUZQ9iXWqbRjokinsr6LjZXr+QJc3dyWXr wKGzaQCIt4+usw5HL5Bo43WZA49I7RiwHH97kzES3oCaphTnIup7dUjEbAlBuPt43yEu DWbd6vVCtFx1wkrSVBGg7YYK9fck261TTk2oQQqrOkBQ7UeIxBPlIFzAj2UWscpK0Rqc jPdF/bsx6eQq9onu4+SyBfhxZzAmJACZoxR1eLhbNuxgeLKC5Llt6xa6lpVcgGQBuji/ mwAZuEfcTEggCbr3urZ01N+x3EaMPjLS3GT8SWu5SrvBhaxNeGDyL0tyEb3hmzyUj5fa dfEg== X-Gm-Message-State: AGi0PubtZUrnbVnO8ZjZItOLYb8Cx/E3jk16ERlYln0e3wK6ZL9CtA0C y6V//L49/CXdNb6bGanJ+ek0qbYe9AZawNOWIy51pQ== X-Google-Smtp-Source: APiQypJdlOVhfZh/4UmAaV00/bXIqOc+2RGD9rN1rjikQtAvyI4wxc3Mm3mww8Jwv2pBRQ5B99Id5NqIXPMlW7Ma2Ss= X-Received: by 2002:a1c:e242:: with SMTP id z63mr687626wmg.72.1586240551585; Mon, 06 Apr 2020 23:22:31 -0700 (PDT) MIME-Version: 1.0 References: <9AD3C4BB-7965-4776-84C4-6B5BFDCAA262@tzi.org> <15C8F1D1-B560-4D52-8D77-377C6B1C0518@tzi.org> In-Reply-To: From: Ivaylo Petrov Date: Tue, 7 Apr 2020 08:22:05 +0200 Message-ID: To: peter van der Stok Cc: Core , netmod@ietf.org Content-Type: multipart/alternative; boundary="0000000000009b130405a2ad6894" Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_CORECONF_drafts=3A?= =?utf-8?q?_draft-ietf-core-yang-cbor-12=2C_-sid-11=2C_-comi-09=2C_-yang-l?= =?utf-8?q?ibrary-01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 06:22:39 -0000 --0000000000009b130405a2ad6894 Content-Type: text/plain; charset="UTF-8" Hello Peter, Thank you for your reviews and your comments! It is true that currently we mandate each SID mega range to have 1000000 SIDs in 6.1 and the size in 6.2 is not strictly speaking necessary. I believe the idea of having this information is so that any software that is written today to work with this registry has all the necessary information inside the registry. If in the future we decide to change this limit to 500K or 5M this software can remain intact. If this is a big concern for you, do not hesitate to let us know and we will discuss further. Best regards, Ivaylo On Tue, Mar 31, 2020 at 2:16 PM Peter van der Stok wrote: > Dear all, > > I have reread draft-ietf-core-yang-sid. > I am quite happy that this document enters its final processing stage. > The document satisfies our wishes expressed earlier. > > One small point: > In section 6.2.2 the size seems superfluous as all ranges have the same > size. > > Greetings, > > Peter > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0000000000009b130405a2ad6894 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Peter,

T= hank you for your reviews and your comments!=C2=A0

=
It is true that currently we mandate each SID mega range to have 1= 000000 SIDs in 6.1 and the size in 6.2 is not strictly speaking necessary. = I believe the idea of having this information is so that any software that = is written today to work with this registry has all the necessary informati= on inside the registry. If in the future we decide to change this limit to = 500K or 5M this software can remain intact. If this is a big concern for yo= u, do not hesitate to let us know and we will discuss further.

Best regards,
Ivaylo
=


On Tue, Mar 31, 2020 at 2:16 PM Peter van d= er Stok <stokco= ns@bbhmail.nl> wrote:
Dear all,

I have reread draft-ietf-core-yang-sid.
I am quite happ= y that this document enters its final processing stage.
The document sat= isfies our wishes expressed earlier.

One small point:
In section = 6.2.2 the size seems superfluous as all ranges have the same size.

G= reetings,

Peter
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--0000000000009b130405a2ad6894-- From nobody Tue Apr 7 00:24:30 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BD73A1815 for ; Tue, 7 Apr 2020 00:24:28 -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 xt21qcXK61cd for ; Tue, 7 Apr 2020 00:24:26 -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 8F9D53A1811 for ; Tue, 7 Apr 2020 00:24:26 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48xJnJ4b7Szydy; Tue, 7 Apr 2020 09:24:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <9F199D88-4F17-4B6D-B91B-73C904464906@ericsson.com> Date: Tue, 7 Apr 2020 09:24:20 +0200 Cc: "core@ietf.org" X-Mao-Original-Outgoing-Id: 607936841.854139-442e81525fa46789d02768b091c67991 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5CD4BE47-4E21-4E00-8BE7-752917CBAF51@ericsson.com> <20200406161808.GB2688660@hephaistos.amsuess.com> <9F199D88-4F17-4B6D-B91B-73C904464906@ericsson.com> To: John Mattsson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] Allowing non-HMAC based KDF in OSCORE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 07:24:28 -0000 On 2020-04-07, at 06:33, John Mattsson = wrote: >=20 > NEW: The KDF MUST be one of the KDF algorithms defined for COSE = [RFC8152] (Maybe reference 8152bis-algs here.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 7 01:12:36 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6E33A18D1 for ; Tue, 7 Apr 2020 01:12:34 -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, FREEMAIL_FROM=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 4dqSsOWzOa2D for ; Tue, 7 Apr 2020 01:12:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7003A18CD for ; Tue, 7 Apr 2020 01:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586247144; bh=TQ0ZODj/NKyMRnjVKZ8iv4BKgubR7xnLiXQnbIf5ynQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=j8QO26rPdJQkuKZjzdL9+KlvGpZDATMOL92inhISpKBGkeEICCLiCOGBrwWtK9Ajk OLWLw5iGAH1lemvIL9RA+0G2y/1gbVA4t4Kj1426rVDUrM7jLvh5psEOZyL2F21+fm XBotnu6Jtfxy6szfL4/vphwPxGzqT4erDi9EG+lA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([88.65.144.250]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MVvL5-1jlKfC3lNl-00RtoY; Tue, 07 Apr 2020 10:12:24 +0200 To: Jim Schaad Cc: core@ietf.org References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> <02ec5628-3f7d-ff5d-620c-c0a90a4b89b0@gmx.net> <020701d60907$fb3ba720$f1b2f560$@augustcellars.com> <02c601d609e0$e0afcbf0$a20f63d0$@augustcellars.com> From: Achim Kraus Message-ID: <67d5ddf6-94dd-51af-0e43-10a078ecb5fc@gmx.net> Date: Tue, 7 Apr 2020 10:12:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <02c601d609e0$e0afcbf0$a20f63d0$@augustcellars.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:BMQ+yXBcgnDm4N5KMPOpT+/885PtqJS7Z0BxSHPOnVs9ZbWYuLf hnWw3bOwX3wr9YgQaXLkCrQgWD5r6PPWyTLSnQLxfP5MHjL3uIJN3TtgxkNnwTjZQhVhV+U /8xEO542klz8Bi4x6QuF2WHM5kBwbwz/azGoeIdUYQmuE4VuuZDmOG/z3I7bP6B+QVspOY+ 3LFZIgLNhzik2lbrtwqZA== X-UI-Out-Filterresults: notjunk:1;V03:K0:zJjhqNezY2o=:+dSWlsVbn69bZHCHIAMQhA +Alm3ImbVb6KtkAZxgVWIYYSRSFmpHFC5bEyOX3LTk3mq0T0l5XwjlRuOHuwsVAeQ8YEf/OVP dBgiqLC14Yz8mT4EvNKpGh1vYhhaJ1QQZ8F8qxAKfmgU3g0haMGbDaxWVv5rIKzHlQxNZNNdQ MQpAwrJKzeEgkaZwGUx/rf96EjKQKdX4okNGXLKIQwoLNSq8BsDPQqmxvWd+p1C9ENYlcr9Uo 0zRAdOlzqIyZ7AJ9kX+uVGYdhGcJ8YIoUBvJdXyhhpA8nshgKDExjLUmqKD8+av4+xMeKfpQg K2HLpCxWhd7d6cXyRjYXECqNWQmgVyZukgAPOswKBDSFMnuloeyfXBnecbMxU63tc8gMINqdx 0Mn21cfLei9/g6ojSCDj69bhOkx1KbkIotgTjzT6pgxWznP+15vr5g0IMZIqhLAcB8icSf3Ih TNxtwAxBvCFmYD0JsNsRjXa7HWYk9cB+ZU2hOUc3pe17q4knxqx6PHDxYtcl+MXUdQPT+ZIcF NQoJJbQ/QeYflyJJ8w/J2VaCBGz+RhFM5i2BTD5riIFVCZoPZWCqFZJhjjhyJqPW140Gl+1so UgwLkc8dN0sy8eGax3S6FVQFxv9RcsUbu/kT3qO81f9KoIRFv/VB6ns8+ZqAch9sdbfGhS8HS lDjuCmBHKpRDmlUNo9ODiJRXip+iyCMOr5maxSumLv1pcnxsyW2i7Fq69GaXRyXJpQ7xRyxmP ZbguUDV5nYR8HsT4KWd1n8wbD0FoYQJ7JpHfOL+rmQg3FI5FG2cNttwNTXKI8Xrr5yg45jTyI Go98uzmsp+HblGu5BZcFzZlYF6tQFf7ysXyE6Zom0LlMEeM8wzzwHI+czqdD8nrrLboITCt0x +Xdex4/ESLVSzHbC1/ycZGzIG6HakZ9dlo2RT+BcoA7M5D+bFO+pYsIOG+/Ndso3uQdX6QBWL nJZY+2QMU1u5ilzv77SksiXcLVtbFMuvsFt/DKmS0okKqU6ESE/MWdh9+y1AdleajbxBsgGJp 4ojBxlPWaG6glFH1swaLqVr6sl8ymrBKDsCFqAl+xdfmKLXsFnbXSoVuL5xD3YDfrQnJ9BJzX MVQlWoEqqmtZVC0eCUyYwiCcQyubAg9yr4A+e9pW/1vZmwZntB81FNynVeCBBlhZmGi2Qr6Bv btFyhgVsVFvgf3oBBhOmDXPZDs+muajXDkAECgAGKgsTndzT2kBwlgOr1f6XXhg2kHS8kO/TI rqAhG8J3OHdc6hMeG Archived-At: Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top 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, 07 Apr 2020 08:12:35 -0000 Hello Jim, > [JLS] I think it is a bad idea to use the port number as a means of distinguishing multicast and unicast message. If you do something like this completely internal to your own code, then it is an implementation detail but would not map to any type of text for an IETF document. Do you have an example, where a IETF specification uses multicast and unicast and differs in processing on that? Otherwise the point maybe, that other protocols, which also support multicast, process any request in the same way, regardless if it's received via the unicast or multicast address. > [JLS] If this is really true, and I am not sure that I believe that to be the case, then the JAVA library is completely broken and needs to get fixed. The fast look that I had at the JAVA library looks like you need to create a distinct socket for every pair that you are dealing with. I think that should give you all of the info that you need, but like I said, I have not done the JAVA programming itself. At least, it is easier to mix it up, than to do it proper. And "wrong" maybe not too obvious, because it requires precise mechanisms to detect that. And it may vary from OS to OS. For linux the multicast socket seems to require to be bound to the specific multicast address, for windows that doesn's work and seems to be not required. So, lets see, if only "my limited java multicast knowledge" is the gap, or other implementations will also struggle :-). best regards Achim Am 03.04.20 um 19:54 schrieb Jim Schaad: > > > -----Original Message----- > From: Esko Dijk > Sent: Friday, April 3, 2020 5:38 AM > To: Jim Schaad ; 'Achim Kraus' ; 'Thomas Fossati' ; 'Klaus Hartke' > Cc: core@ietf.org > Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Laye= r, page 67, top > > Hello Jim, > > Could you clarify your point further? > - what is a bad idea - having a dedicated port with dedicated for handli= ng multicast requests? Or the subsequent "internal routing" of the reques= t to the unicast server at a different port? Or both? > [JLS] I think it is a bad idea to use the port number as a means of dist= inguishing multicast and unicast message. If you do something like this= completely internal to your own code, then it is an implementation detail= but would not map to any type of text for an IETF document. > > - what is a "multicast channel" , do you mean an endpoint bound to a mul= ticast address ? > [JLS] I use the word channel because it maps from my code base in many w= ays. A "multicast channel" would map to an endpoint bound to a pair. An analogy for those of us who are really old would= be to consider UHF and VHF on your TV to be different multicast addresses= , but you still need to choose the channel number (port number) in order t= o get a flow of information that is usable. The analogy of course breaks d= own because you cannot send information back to the TV stations. > >> some resources may only want to be on a single multicast address even >> if the server is listening on multiple unicast addresses > > Sure, you can also have a dedicated server on say port :9999 that listen= s to multicast destination addresses only, because it is bound only to a m= ulticast address not a unicast address. This dedicated server can then han= dle resources that only are to be accessed via multicast. > But in this case, there's no "internal routing" needed to another server= inside the node because the resource is only hosted at say port :9999. > [JLS] You can have a dedicated server on say that= lists for multicast traffic. You always have the address and port as a p= air. > >> The IP address is different for a multicast vs a unicast message >> received at the server. This needs to be the distinction > > But the case the Achim indicated is that the server may not be able to d= etect whether a request came in via unicast of multicast. So this cannot b= e the distinction, e.g. in the following case: > 1) CoAP server at port 5683 is bound to unicast address U > 2) at same node, same CoAP server at port 5683 is bound to multicast add= ress M > [JLS] If this is really true, and I am not sure that I believe that to = be the case, then the JAVA library is completely broken and needs to get f= ixed. The fast look that I had at the JAVA library looks like you need = to create a distinct socket for every pair that you are de= aling with. I think that should give you all of the info that you need, b= ut like I said, I have not done the JAVA programming itself. > > Now in this case if a request comes in via multicast group M destined t= o port 5683, the server handling this cannot tell whether it was unicast o= r multicast. And if a unicast request comes in to destination address U an= d port 5683, the server cannot tell also whether that was unicast or multi= cast. > [JLS] What is the address that is associated with the port number? You = cannot have a bare port number you also must have an IP address. The IP a= ddress is how you distinguish unicast/multicast. > > [JLS] Jim > > By setting it up like this instead that problem is avoided: > 1) CoAP server at port 5683 is bound to unicast address U > 2) at same node, same CoAP server at port 9999 is bound to multicast add= ress M Then the server at port 5683 treats everything as unicast. (Because= it is not bound to a multicast address, it won't receive any multicast re= quests directly.) And the server at port 9999 treats everything as multica= st. (And this endpoint 9999 handles most requests by internally redirectin= g to server :5683, but only for those resources where multicast is allowed= . Some request for multicast-only resources it can handle itself directly.= ) > > So the above "workaround" seems handy for cases where a server at one sp= ecific UDP cannot itself determine the endpoint the request came in from (= could be either multicast like M or unicast like U). > > @Achim maybe you could comment if I've understood your use case properly= . To me the above seems more secure than trusting that a client will incl= ude a "This is multicast" CoAP Option in an honest way, which could easily= be misused. > > thanks > Esko > > -----Original Message----- > From: Jim Schaad > Sent: Thursday, April 2, 2020 18:02 > To: Esko Dijk ; 'Achim Kraus' ; 'Thomas Fossati' ; 'Klaus Hartke' > Cc: core@ietf.org > Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Laye= r, page 67, top > > Esko, > > That idea strikes me as a very bad idea. If you build your code on thi= s basis you will fall over the first time you come across a multicast chan= nel which uses the same port as the unicast server. The IP address is di= fferent for a multicast vs a unicast message received at the server. This= needs to be the distinction as well as the fact that some resources may o= nly want to be on a single multicast address even if the server is listeni= ng on multiple unicast addresses. > > Jim > > > -----Original Message----- > From: core On Behalf Of Esko Dijk > Sent: Thursday, April 2, 2020 1:23 AM > To: Achim Kraus ; Thomas Fossati ; Klaus Hartke > Cc: core@ietf.org > Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Laye= r, page 67, top > > Hello Achim, > > (see also my response to Jim) > Using the UDP port number to detect a multicast request vs a unicast req= uest sounds like a good use case. Just curious - I assume the security asp= ect requirements of RFC 7252 are taken care of in this use case? > > That is, a proper client sends its multicast requests always to port :99= 99 and the server treats these as multicast requests (e.g. only allow the = request for specific resources). > A malicious client may sends its multicast request to port :5683 to bypa= ss the above checks. I assume the server doesn't respond to this request, = because the multicast address is not bound to port 5683 but to say 9999 on= ly. > If the CoAP server at port 5683 cannot distinguish between unicast/multi= cast that would be a bad situation and the security requirements of RFC 72= 52 are not met. > > Esko > > -----Original Message----- > From: core On Behalf Of Achim Kraus > Sent: Wednesday, April 1, 2020 22:28 > To: Thomas Fossati ; Klaus Hartke > Cc: core@ietf.org > Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Laye= r, page 67, top > > Hi, > >>> +---------------+ +-----------------+ >>> | | request _|_ | >>> | | .---> / \ 224.0.1.187 | >>> | _|_ / \___/ --. :9999 | >>> | 192.168.0.1 / \ ---=C2=B4 | \ | >>> | :54321 \___/ <---. _|_ / rewrite | >>> | | \ / \ <-=C2=B4 | >>> | | `--- \___/ 192.168.0.100 | >>> | | response | :5683 | >>> +---------------+ +-----------------+ >>> Client Server > > Nice diagram. > >> Not sure why you would also want to rewrite the transport endpoint? > > I tried to follow the discussion. > The idea to change the port as well enables java (and I guess some more)= to differentiate between multicast and unicast requests. Jim also mention= ed, that it enables the use of multiple servers on the same host. > I have not enough experience with multicast in different environments to= see, if that may cause more trouble (e.g. firewall etc.). I would guess, = that some implementations will just offer that variant, at least as confi= gurable option (I would try do so for Californium). > So my favorite for now is just implement it and see, what the user's fee= dback will be. > > If that idea gets declined (may be by negative feedback of users), I sti= ll think, that there is a demand for other means to distinguish between mu= lticast and unicast requests. Maybe, either the usage of the uri-host opti= on or a new option will help. > > This maybe considered as "too pragmatically", but on the other side I al= so don't see the "great benefit" in insist not to change the port. > > best regards > Achim > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Tue Apr 7 02:12:55 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DB83A197D for ; Tue, 7 Apr 2020 02:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_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 6YAjkzm35aYU for ; Tue, 7 Apr 2020 02:12:51 -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 AABC33A197C for ; Tue, 7 Apr 2020 02:12:46 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id C6BDF40142; Tue, 7 Apr 2020 11:12:44 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id B99B014B; Tue, 7 Apr 2020 11:12:43 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:2d54:7976:cdc9:1eab]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 5411D381; Tue, 7 Apr 2020 11:12:43 +0200 (CEST) Received: (nullmailer pid 2749984 invoked by uid 1000); Tue, 07 Apr 2020 09:12:43 -0000 Date: Tue, 7 Apr 2020 11:12:43 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: John Mattsson Cc: "core@ietf.org" Message-ID: <20200407091243.GA2743407@hephaistos.amsuess.com> References: <5CD4BE47-4E21-4E00-8BE7-752917CBAF51@ericsson.com> <20200406161808.GB2688660@hephaistos.amsuess.com> <9F199D88-4F17-4B6D-B91B-73C904464906@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <9F199D88-4F17-4B6D-B91B-73C904464906@ericsson.com> Archived-At: Subject: Re: [core] Allowing non-HMAC based KDF in OSCORE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 09:12:53 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 07, 2020 at 04:33:12AM +0000, John Mattsson wrote: > [JPM] I was more thinking that Group OSCORE document already now writes t= hat >=20 > This document updates RFC 8613 as follows: > =20 > OLD: The HKDF MUST be one of the HMAC-based HKDF [RFC5869] algorithms > defined for COSE [RFC8152]. >=20 > NEW: The KDF MUST be one of the KDF algorithms defined for COSE [RFC81= 52] I was probably too hasty reading that; yes, that's even better to me. Thanks c --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl6MRAQACgkQOY0REtOk veH+IRAAmaaB7kXFOl71xQaEkl1dCjAhP4JgXBUQhDfbC29TzEoMYxj8sd4kiqPF p15JHU0s62XxI8jZsfIBhRB0V7HyyFn7sPTF+Sb3rER2wqV8uBcB7NZpEjkxxAR9 yD1aYcdH/PUR5xNsYnHaM91jrIW/S3pASUCNPLi0Ye79B4pIPkwtUzgAkhpxXGNi tpie01AwP1uMLc2hOLN1EJVEVu2TvU9vk/J2qXr71vrbEFmqnlfqV8e2GP85Wf+Q Uipxp3TLbuftEOIC4LDGp6wgKu2BN5j3pKt+rk0Z92aHQjSEs6yi/i4hX480AO8x c/3pSXWqiQUPzHVnSB7gk0Z3IDw1jruoRwkXaENSeMsXKEQaLsH+0YTRxmwW9zEL O6HDtDfoaIbVfjStJ6ZjX1VwRIbQlbm92UZ571Aa0Afi2UEAEoN4Sm6vk58Eih2o 8HjFThYcUQwTjsTm6r07CuyDxftA4t1GFAYL+ESMByn4rD6vNNsnF9B+lDU8oJZw SMWTZfzj06NLWx1IYBWXZFXUGbq9VjUWGa/CYr9nxx/9LfbnsY9nmod1LDjj91/X 7MulA/4C+txzWg7TxXTn3XRSh7i1dLCqwK5iyMd9gYRKE3rIS36ch/fMlJXImp0z EehpOXbeUny8n3fThMm+bp+Y5V1rpwoHYU2UaQaLjzREI4jmSGk= =qkcJ -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From nobody Tue Apr 7 04:11:34 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0383A0C69; Tue, 7 Apr 2020 04:11:33 -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, HTML_MESSAGE=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 DGeA9ogT11BZ; Tue, 7 Apr 2020 04:11:31 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788943A0C68; Tue, 7 Apr 2020 04:11:31 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfednr25.francetelecom.fr (ESMTP service) with ESMTPS id 48xPqP0d0tzCqvg; Tue, 7 Apr 2020 13:11:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586257889; bh=XLmWoNokFlCJkYyTt/BI5qtSXAUXqbizdfhpknnz+UE=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=xBRTYmU9OWPIqnhjXdQrSiiZSktRksPP/kxtJlI7C7AZGGtLj6k94JWmOMWGEXtpp P3QF522YIs9rotIxNngfqMt1JZPSGvWO1PnB/BSKTHlK1XaOPCAnFBN3gYjRhZlDIt x0tkcrjs/qwffKbfvNp4NFpZYnMHwwKSTdJkdDfNRUBvG9EzDUvnVYoSw+Kf/f4TmN Sik/u3/wSqUNTibwpXwhBmPTObvOb+sLVEFt04fW/e9YqRH8ctTGTpbbqDw91F4snr 5tuK4OJsiTM3kSF4Y70S90YTl9GNKkHA3ibG4AA/5xfIwftMR1tqI7Rr1zMCMfwOuX EHwntLQRTho7w== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr00.francetelecom.fr (ESMTP service) with ESMTPS id 48xPqP1KfPzDq7k; Tue, 7 Apr 2020 13:11:29 +0200 (CEST) From: To: "core@ietf.org" CC: "Jon Shallow (supjps-ietf@jpshallow.com)" , "dots@ietf.org" Thread-Topic: Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AdYMzUH7Od/A8MMEToW8zPzszV9XuQ== Date: Tue, 7 Apr 2020 11:11:28 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031490173@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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933031490173OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 11:11:33 -0000 --_000_787AE7BB302AE849A7480A190F8B933031490173OPEXCAUBMA2corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We are using Observe to receive notifications during attack events. These n= otifications are set as NON messages for reasons specific to DDoS condition= s. With DDoS telemetry information included (see draft-ietf-dots-telemetry), a= notification may not fit one single message. The use of BLOCK2 is not conv= enient during attack times. A full description of the issue is described he= re: https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4/ We are considering some mechanisms to solve this issue. One of them is to d= efine a new BLOCK option (similar to BLOCK2) that does not require the obse= rver to send a GET to receive the next fragment. The server will send all t= he fragments. The observer will follow a SACK-like approach to request retr= ansmission of missing fragments. Please let us know whether you think this is a generic issue that should be= solved at the CoAP or not. Suggestions are welcome. Thank you. Cheers, Jon & Med --_000_787AE7BB302AE849A7480A190F8B933031490173OPEXCAUBMA2corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

= We are using Observe to receive notifications during attack events. These n= otifications are set as NON messages for reasons specific to DDoS condition= s.

=  

= With DDoS telemetry information included (see draft-ietf-dots-telemetry), a= notification may not fit one single message. The use of BLOCK2 is not conv= enient during attack times. A full description of the issue is described here: https://mailarch= ive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4/

=  

= We are considering some mechanisms to solve this issue. One of them is to d= efine a new BLOCK option (similar to BLOCK2) that does not require the obse= rver to send a GET to receive the next fragment. The server will send all the fragments. The observer will follow a SACK-li= ke approach to request retransmission of missing fragments.

=  

= Please let us know whether you think this is a generic issue that should be= solved at the CoAP or not. Suggestions are welcome.

=  

= Thank you.

=  

= Cheers,

= Jon & Med

--_000_787AE7BB302AE849A7480A190F8B933031490173OPEXCAUBMA2corp_-- From nobody Tue Apr 7 05:32:41 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914B03A080E; Tue, 7 Apr 2020 05:32:39 -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_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdRaz_B_mbt1; Tue, 7 Apr 2020 05:32:37 -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 518873A0805; Tue, 7 Apr 2020 05:32:36 -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 C7AA540142; Tue, 7 Apr 2020 14:32:32 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0AA8814B; Tue, 7 Apr 2020 14:32:31 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:2d54:7976:cdc9:1eab]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id BD7E4381; Tue, 7 Apr 2020 14:32:30 +0200 (CEST) Received: (nullmailer pid 2762080 invoked by uid 1000); Tue, 07 Apr 2020 12:32:30 -0000 Date: Tue, 7 Apr 2020 14:32:30 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Jim Schaad , Thomas Fossati Cc: draft-fossati-core-coap-problem@ietf.org, core@ietf.org Message-ID: <20200407123230.GC2743407@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xgyAXRrhYN0wYx8y" Content-Disposition: inline In-Reply-To: <703EAB3E-A9CC-4260-8B52-6690BACFA62C@arm.com> <010b01d6076d$ab36bfd0$01a43f70$@augustcellars.com> Archived-At: Subject: Re: [core] Review of draft-fossati-core-coap-problem-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: Tue, 07 Apr 2020 12:32:40 -0000 --xgyAXRrhYN0wYx8y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Thomas and Jim, On Wed, Apr 01, 2020 at 10:36:10AM +0000, Thomas Fossati wrote: > > [JLS] Given that I would want to test the problem info being returned, > > getting unexpected errors with information is useful for me. This is > > the basic method that I have been using for my ACE server where a > > diagnostic string with the problem details is returned, but a stack > > trace is included in unexpected conditions (i.e. the code threw an > > exception). >=20 > I am certainly not opposed to that. Happy to call it "diagnostic"? Are these cases not independent cases anyway? If there is a known condition, its problem-detail is returned. On exceptions, there is no problem-detail but a stack-trace (without a content format). Of course, a framework might create an entry for (ns=3Dmy-framework, type=3D0, title=3D"Exception in resource handler", response-code=3D5.00, coapp-roblem-details-extension =3D [* stackframe]) But as I understand that use case, you don't need both simultaneously. KR c --=20 You don't use science to show that you're right, you use science to become right. -- Randall Munroe --xgyAXRrhYN0wYx8y Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl6MctsACgkQOY0REtOk veEvhA/9GmxtaZuRrlLl3RnJrG9Vq5td/6YCGM78KHTvWSaCzxB+L75TLgTNa/Qx KDtC5GsC5/7VsYLLUwSJq+Fhzyf7XFaqI76KwjwBETkJSK5hlm4aXMhge9PasEKW UgsHA64kqH71OElBhwh3BUXtrMaAKjbnu5FMjQE6IzoS9FHJCHoR+EmbRhfZHEtu AgKpcSpDkux7n7wLLuVJd8yCAvbm96e2jECIR/sScKQEF6RRgZugVcb8tCRTAFC5 MZObYWWcg9G2fpIU7lmw5FAk2C5/btWz2Etu+KWr+RFvwkIE+dDMpoVByqsPgOB2 sZq0cFhZB3WwRi8bzHqPibhEcED1jRy2gp+fl1UtV8CMKaRqkFX5jeghgwHkfQmI yyhh8DpqDbDpEwb7xIFviStwfcNhlaIcR18vRQoQeDkLIy8RXizvSupc3+OufhVR dXDnyEpm2yJLS9S7OVyeuU0NTl74fbCPRt8/tta4VxvjnsJhPmOK5ri7NdlEwnK9 J19erJZ6KeVWLXWM6ExpA35MqRtQ70fg5qOG1NkS4J3WSZPFLCErAHEyJCpc/GAe sC0Q8rBhFRRkyvyX7V1b5c8sKJfM0Sr9CRAlQrve9yp9aIqRO2BtTaG53ihniZVl WScH7QLF/Y7iW1bv4I5P8poFm+xqdu6JUCvse0E27GHi8F4jag8= =g/a9 -----END PGP SIGNATURE----- --xgyAXRrhYN0wYx8y-- From nobody Tue Apr 7 06:09:53 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D33B3A092A; Tue, 7 Apr 2020 06:09:51 -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_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlrVmfyFze7k; Tue, 7 Apr 2020 06:09:49 -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 4AA963A0928; Tue, 7 Apr 2020 06:09:48 -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 A7D8640142; Tue, 7 Apr 2020 15:09:46 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 43CC914B; Tue, 7 Apr 2020 15:09:45 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:2d54:7976:cdc9:1eab]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 08DBF381; Tue, 7 Apr 2020 15:09:45 +0200 (CEST) Received: (nullmailer pid 2764034 invoked by uid 1000); Tue, 07 Apr 2020 13:09:44 -0000 Date: Tue, 7 Apr 2020 15:09:44 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: mohamed.boucadair@orange.com Cc: "core@ietf.org" , "Jon Shallow (supjps-ietf@jpshallow.com)" , "dots@ietf.org" Message-ID: <20200407130944.GA2738832@hephaistos.amsuess.com> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 13:09:52 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jon, hello Med, I don't have full answers, but some data points (also pulling in the cited mail): > and a response (may need new code) that says status is too large to > fit into a packet or has been truncated). That an observation with blockwise would already do: If the observed resource changes to have its representation larger than the block size or MTU, it'd send the first block. > The observer will follow a SACK-like approach to request > retransmission of missing fragments. There was a draft around on non-traditional responses[1] some time ago that would provide building blocks from which a server could send follow-up blocks in an unsolicited fashion: The second block would be a message in the style of "This is a 2.05 Content response, which you would have received as a response had you requested block2 of /path". Those messages would not be ack'ed if they are NON, and the client can selectively request blocks it thinks it missed (but, in such a setup, would do that after a suitable timeout to not request something that is already in flight). That draft was not followed up on directly, but some of its ideas wound up in [2] where observe notifications are sent to a multicast group. In particular, the topic of which tokens would be usable for unsolicited responses to unicast addresses has not received the discussion it'd probably need. Kind regards Christian [1]: https://tools.ietf.org/html/draft-bormann-core-responses-00 [2]: https://tools.ietf.org/html/draft-tiloca-core-observe-multicast-notifi= cations-02 --=20 The detailed semantics of CoAP methods are "almost, but not entirely unlike" [HHGTTG] those of HTTP methods. [HHGTTG]: Adams, D., "The Hitchhiker's Guide to the Galaxy", October 1979. -- Shelby, et al., Internet-Draft Constrained Application Protocol (CoAP) --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl6Me5UACgkQOY0REtOk veF28Q/+NfJukV1iICMrEQwcnheVBfQcTTxr+AAlNhvtZAWwT2lNs7GceVV74CHq Xjd47f08uqPaxjHZuUD8/a8BWKum1QlfmWGzJRdXyB0oPjx5/dBtSYYS4mgpvzlu v6r883C/QWV7++WFzudxhT8fgcTMS+Pi9PbuksgdW8aqQjM3sIK0NcDqhqEOPtuE pMxgT1jLqLZrArMjJMo+EBLrEAT6b82Ctymd169NzSCelaFnIig5R4TSha8z/gOm r5fsQDRE1S5NCAbHycM3lgNvZxTVWKNqXgAJwYv+ezBuglPqy6F7qn3bzKaqsGpG UqZjj3maZy3FBeHu23YnGcbT9Qf6SER0nAtCyQuEH4dTB5GCkgv+bVD7kjbhmab2 8a/cEOoLQv8/gg4QlMxEXF8cgD075JjMj5oh2U4hpEbRG1yORk7XhCRa1cGePOp4 ZU0acZSrMABAm3siLVHK1otr0hYJc4ZfshNrog+QWzgDFJY1s+BgwAx8EX1DWqo8 qFqgLlUPdPTMe8RHZNe+2peL69uuv2fV4WaQ0pxZHJcIVW/Dx42kHbdFux3mfnOr 3i2P8KzTuvcZu12iSyT9G8HlKtRP5RRg9AhnRojRuLpOFcPDJE+9PvV5Qvflt0YI uARXIyaoT0bzAMO/LOeMZBS+a8w8REed0U65oVf7TUqGA+KiCBw= =zhM9 -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From nobody Tue Apr 7 06:17:15 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0323A094D for ; Tue, 7 Apr 2020 06:17:13 -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 em8MiiGWwVgr for ; Tue, 7 Apr 2020 06:17:12 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 A878E3A0949 for ; Tue, 7 Apr 2020 06:17:11 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id c7so4011787edl.2 for ; Tue, 07 Apr 2020 06:17:11 -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=aGJqQPX1VIS8qAFw6JyjZk+W7z+87cXwD2olSiuRn0g=; b=XK07AUrFdUpBQuEGM+xOoF0eWYYfKFHKQ4tEs+D6emiaLeHHFmS7iM4/vso/6e20II f85eM89ZyIbEtQFV+47fKWPrkZXlPpBp9B0T8fl0XNeJnzMLA5xlJD0L7DxfWnZoRyJq A27Sl6KPHeVyyuFTT7amXKifdIjq6yAUEGFpivGEZmJlb9gODPgl/XKjwiD0S0Zuxap7 4aXx375UQjy9cYdpWWob3USdiTD15IIIpgKmrZSwm4GInrYDAxq5Y0WHQxBVsmRivCgg bv/XpJmPK2Jp2kg+1iUp7Y+A6bm9E3PhVHdFsSFoQVZfehYhoRpiWgJDzpdCtcdUU82z FRgQ== 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=aGJqQPX1VIS8qAFw6JyjZk+W7z+87cXwD2olSiuRn0g=; b=aq06M3sSufG+25wAGDW2iD6hzOBvYX2noCacSqT3XEOCXkkr02rybpbHNmAMViOBip u1HB7/f13kZxQpfNRcAsgpeXh7yQqfltHwOS9GOORDAkExZNouutQf1OcnV2vWMSIvj9 EXIhfdtXeiYVefI4H8whP2IaB5KeZvwWLZAxaCRuHkFnHGOdSURHLU++llzlatSnXF61 pVkvctXJt3gYijpDdoCW7jlDghuATg3nTgxhMvrkFHjqVvzuLWP2LTv3gnp5H+3PNHVV itIzhDFias3CHbqDayQaALNl3Evy5nHLWxQ23YURFNzCcVPv9Wko/dWoSj+EHWgVTHZt gP6w== X-Gm-Message-State: AGi0PubsXRO427DQaVEsEImBzYSSw5tfAFpYtfBo0HFxx3f64Lv5QhPX 5sxvZ7VlVgI4uXpUXAu3tcn/4XhjZZMFnE95s6PoEQ== X-Google-Smtp-Source: APiQypIK4TGerzQ86Fd6EVtDSe6xJ060gM7Vics1OudkaDg70ibMv2ziYt/jER6Xg4diU0OPq44FDd+4xYOx/3OoFws= X-Received: by 2002:a17:906:d8d4:: with SMTP id re20mr2083413ejb.34.1586265430141; Tue, 07 Apr 2020 06:17:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Abhijan Bhattacharyya Date: Tue, 7 Apr 2020 18:46:58 +0530 Message-ID: To: John Carter Cc: core Content-Type: multipart/alternative; boundary="0000000000007bb02a05a2b33359" Archived-At: Subject: Re: [core] Using CoAP for P2P 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, 07 Apr 2020 13:17:14 -0000 --0000000000007bb02a05a2b33359 Content-Type: text/plain; charset="UTF-8" Yes, these are typical implementation considerations. Particularly if we consider the case in point number 2, any control system design must keep the stability of the system in mind. However, there will be many cases where the exchanges are not necessarily synchronous. A strictly synchronous model could probably be implemented with a typical client server relationship using POST request and response payload intelligently. P2P should be agnostic of any possible relationship between the resources. Thanks. On Tue, Apr 7, 2020 at 2:18 AM John Carter wrote: > While the standard is, unlike the http standard, agnostic as to who is the > client and who is the server and the roles can switch.... in practical > experience I'd advise caution. > > 1. If you are not careful you end up with a system that only works if and > only if all nodes are up and working. The best thing about REST is it > reduces coupling and dependencies between client and server. If you two way > couple them, you have made the coupling a lot stronger. > > 2. If you are not careful, you can end up with update loops. ie. Node A > updates an observable resource, in response to which Node B updates a > derived observable resource, which Node.... updates a derived observable > resource, which triggers an update on Node A and around we go. > > > On Thu, Apr 2, 2020 at 12:31 AM Abhijan Bhattacharyya < > abhijan.bhattacharyya@gmail.com> wrote: > >> Hi, >> Is there any standardized mechanism to use CoAP for a P2P connection? >> Thanks. >> >> -- >> Regards, >> Abhijan Bhattacharyya, >> *Technologist by profession [IoT| Internet Protocols| 5G]* >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > > > -- > John Carter > Phone : (64)(3) 358 6639 > Tait Electronics > PO Box 1645 Christchurch > New Zealand > > > ------------------------------ > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.taitradio.com/email_disclaimer > ------------------------------ > -- Regards, Abhijan Bhattacharyya, *Technologist by profession [IoT| Internet Protocols| 5G]* --0000000000007bb02a05a2b33359 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, these are typical implementation considerations.=C2= =A0
Particularly if we consider the case in point number 2, any control= system design must keep the stability of the system in mind. However, ther= e will be many cases where the exchanges are not necessarily synchronous. A= strictly synchronous model could probably be implemented with a typical cl= ient server relationship using POST request and response payload intelligen= tly. P2P should be agnostic of any possible relationship between the resour= ces.

Thanks.=C2=A0=C2=A0

On Tue, Apr 7, 2020 = at 2:18 AM John Carter <joh= n.carter@taitradio.com> wrote:
While the standard is, unlike t= he http standard, agnostic as to who is the client and who is the server an= d the roles can switch.... in practical experience I'd advise caution.<= /div>

1. If you are not careful you end up with a system= that only works if and only if all nodes are up and working. The best thin= g about REST is it reduces coupling and dependencies between client and ser= ver. If you two way couple them, you have made the coupling a lot stronger.=

2. If you are not careful, you can end up wit= h update loops. ie. Node A updates an observable resource, in response to w= hich Node B updates a derived observable resource, which Node.... updates a= derived observable resource, which triggers an update on Node A and around= we go.


On Thu, Apr 2, 2020 at 12:31 AM Abhijan Bhattacharyya= <a= bhijan.bhattacharyya@gmail.com> wrote:
Hi,
Is there any standar= dized mechanism to use CoAP for a P2P connection?=C2=A0
Thanks.

--
Regards,
Abhi= jan Bhattacharyya,
Technologist by profession [IoT| Internet Protocols| 5G= ]
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core


--
John Carter
Phone : (64)(3) 358 6639
Tait Electronics=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
PO Box 1645 Christchurch
New Zealand


This Communication is Confidential. We only send and receive email on t= he
basis of the terms set out at www.taitradio.com/email_disclaimer


--
Regards,
Abhijan Bhattacharyya= ,
= Technologist by profession [IoT| Internet Protocols| 5G]
--0000000000007bb02a05a2b33359-- From nobody Tue Apr 7 06:30:14 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FEF3A09C7 for ; Tue, 7 Apr 2020 06:30:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC7bwFbYhVh9 for ; Tue, 7 Apr 2020 06:30:06 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 C38183A09C8 for ; Tue, 7 Apr 2020 06:30:05 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id e26so1737438wmk.5 for ; Tue, 07 Apr 2020 06:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8ATMdTvYksTMevIuulVvnxv9zyxIHXOaOR4+1iaUrHA=; b=Wu9TjYqJIylMxTN3kbv4zxySFigFklVlNADHsddl3MmVlEpCxRunvvMc5WPQIhqsDh glRwzt8/Zzp9GYpTQv34/qCAX6CvUhx4YfdxK6NxSDRAV+g3uqEHYNRXJbVzBS8qoIAZ wXwlYMe6/V4dPI+sV/Y1DmvYXIGezcqJWhzFEE/aAFbmHQrXhb+sO9A/mZIV423LlzZK d4TkxQQjKK75se2vAODKbD1OkmAzKZCpbmo+3I6s6Ow+gXaNFNLnHrYufo7kOwhX4mZd 1/jCB40BHtXKCodiJn4jPa++imwpjr84wvCKQAOOSsGOktPtTYOTEAAr2kZKOVLTNHQ6 ek+Q== 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=8ATMdTvYksTMevIuulVvnxv9zyxIHXOaOR4+1iaUrHA=; b=J02scgBrjiCjTnmjN2CEtJ7u7Kql7GSl5tcI5PSK7fIM61r3r2E2R9OGIYLn9QBLvd fbDlbIbS/3Jgra6TdbbEo4/zyCSZAqAGeQD0LW2FWAsjBBbRVCtOV7CkU/2FoJXUS4A7 h9JUPCKBvIT0XYSwLVoD9J0EpNcPuCZFt69nYMdtDoxWx0ncqUFUaJvk1eeiiOgd2wUY gyceuE3HMJ7Yx5dhGdA/0tShV1gw1vqXalFNjhFCMl2GYJB3aMCRLwB0wbwYVnQB3Jl5 hLwf2A9Vxzma4sZAl4y/EYQhAHIDwvzoji1rQGqil8FvhbfUIh+7ni/cmENS4O5RZlLS B2DQ== X-Gm-Message-State: AGi0Pua3buzLGmdFQFXpD8o/a6GRKXekxbxv8CcO1l94BRxpLxvQL2FS vlvSA/qHdoZdZJDkmI+PYd5zOwnG9SopqPgpJjDMaHHy X-Google-Smtp-Source: APiQypJ6HPkBJ53UkpFbASJXprnR2PuOhyLv8Ffip4G3QVAwU+tZihoC9lNH+Msv+NlxrUDBRyScp2uR9hvDL/yB08c= X-Received: by 2002:a1c:32c7:: with SMTP id y190mr2545553wmy.13.1586266203831; Tue, 07 Apr 2020 06:30:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ivaylo Petrov Date: Tue, 7 Apr 2020 15:29:37 +0200 Message-ID: To: Esko Dijk Cc: "core@ietf.org WG" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000099510605a2b3615a" Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_CORECONF_drafts=3A?= =?utf-8?q?_draft-ietf-core-yang-cbor-12=2C_-sid-11=2C_-comi-09=2C_-yang-l?= =?utf-8?q?ibrary-01_/_-yang-cbor-12_review?= 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, 07 Apr 2020 13:30:10 -0000 --00000000000099510605a2b3615a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Esko, Thank you for your review and your comments! They truly help us improve this document. Please find my answers below (prefixed with [IP]). Note that the diff after handing your comments and those of Juergen Schoenwaelder can be found at [1]. Best regards, Ivaylo [1]: https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-yang-cbor&url2=3Dhttp= ://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.txt On Mon, Mar 30, 2020 at 2:24 PM Esko Dijk wrote: > Hello CoRE, > > I did a review of draft-ietf-core-yang-cbor-12 and some comments are > below. I do support the publication of this document but feel a few updat= es > of minor items are still needed! See the items below: > > Section 3: "This specification supports two type of CBOR keys" -> two > types of CBOR keys > [IP]: Fixed Section 3: This root CBOR map is provided only as a typical usage example > and is > not part of the present encoding rules. Only the value within this > CBOR map is compulsory. > -> Not fully clear to me, how can an example be compulsory? Other values > within the CBOR map could also be used, right? Also it wasn't fully clear > to me how the data structure would otherwise be encoded if not with a roo= t > CBOR map. Maybe good to give an example of how it would otherwise be > encoded if not with a root CBOR map! > [IP]: This stems from the separation between CoMI and YANG to CBOR - in CoMI we have complete examples with the complete encoding of elements that were requested, whereas here we provide only instructions how particular elements need to be encoded - regardless of the fact that they might be a part of a bigger payload or part of a protocol that handles the external wrapping. Where this causes issues is SID deltas for example - without the wrapping elements, it would not be clear how that would work. Please let us know if you could think of a better way to express this. > Section 3.1: Table 1 uses both uppercase and lowercase in the last column > for the CBOR encoding. Best practice is to use either uppercase or > lowercase for hexadecimal, but not mixed I think. > [IP]: Fixed > Section 4.5.2: "example-port: example-port-fault" : > -> space after ':' is to be removed. At least I think a space isn't > allowed there. > [IP]: Fixed > Section 3.3 / 4.5.1 "as follow" > -> as follows > [IP]: Fixed > Section 4.6: "data items tagged with one of the tag listed" > -> the tags listed > [IP]: Fixed Section 4.6: the "anyxml bar" definition should have "# SID 60000" comment, > like for the other YANG definitions that have a "# SID ....." comment . > [IP]: Fixed > Section 5.1: "YANG template encoded using SIDs are carried in " > -> YANG templates ... > [IP]: Changed request from Juergen Schoenwaelder made this look like: The yang-data extensions encoded using SIDs are carried in a CBOR map containing a single item pair. The key of this item is set to the SID assigned to the YANG template container, the value is set the CBOR encoding of this container as defined in {{container}}. > Section 5.2 similar sentence as 5.1 above > [IP]: Fixed similarly to the above one. > Section 6.6 example: > type union { > type int32; > type enumeration { > enum "unbounded"; > } > } > > unclear why "unbounded" is within quotes? The CBOR encoding of this > example encodes the word 'unbounded' without the quotes, which would look > like: > type enumeration { > enum unbounded; > } > An open question to me is whether RFC 7950 section 9.12.4 has the word > unbounded in quotes on purpose, or by mistake. None of the other examples > of enum statements use the quotes! Why would this example suddenly use th= e > quotes? In any case if quotes are used then per RFC 7950 definitions the > quotes must also be encoded as part of the yang-string. > [IP]: I believe that was copied indeed from RFC 7950 as it is. I could not find a reason why it should be with quotes, so I removed them as you suggested. > Section 6.6: Tag 44 use - in section 8.1, the table states that the tag > must mark a data item of type unsigned integer. Which is not the case her= e, > it marks a string. > [IP]: It should be a "text string" in Section 8.1. This has changed relatively recently and obviously we overlooked the values in the table. Fixed now > Section 6.7: similar to section 6.6, the tag 43 mentions data item "byte > string" in Section 8.1 while in section 6.7 it is followed by a text stri= ng. > Just to be clear: if a 'bits' type is encoded, it looks like the tag 43 i= s > only used if followed by a text string as in 43("under-repair critical") = ? > Or should a tag 43 also be used in case a CBOR byte string follows? > E.g. 43(h'06') instead of h'06' ? That doesn't seem to be the intention i= n > the current text. > [IP]: It should be a "text string" in Section 8.1. Fixed now. My reading of this is that the tag 43 can only be used inside unions. Section 8.1: could indicate here what the column 'Data Item' means. E.g. > make clear that the CBOR data item following the tag listed in the first > column cell must be of one of the CBOR data types listed in the second > column cell. > [IP]: This is the column title used in section 7.2 of RFC7049. If you believe that the sentence right before the table is not clear enough, please let us know how we could improve it. Best regards > Esko > > > IoTconsultancy.nl | Email/Skype: esko.dijk@iotconsultancy.nl > > > -----Original Message----- > From: core On Behalf Of Carsten Bormann > Sent: Monday, March 9, 2020 14:05 > To: core > Cc: netmod@ietf.org > Subject: [core] =F0=9F=94=94 WG Last Call of CORECONF drafts: > draft-ietf-core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01 > > It took us a long time to get the four CORECONF drafts in sync, > but now we are ready for WGLC. > > This starts a working group last call for > =E2=80=94 draft-ietf-core-yang-cbor-12 > =E2=80=94 draft-ietf-core-sid-11 > =E2=80=94 draft-ietf-core-comi-09 > =E2=80=94 draft-ietf-core-yang-library-01 > > ending on > > 24:00 UTC on Tuesday, March 31, 2020. > > (This includes some extra time for the IETF week and for cross-WG > coordination.) > > This WGLC is copied to the netmod WG mailing list; please do have a look > at these drafts as they are slated to become a part of the greater > YANG/NETCONF/RESTCONF family. We intend the discussion to be on the > CoRE mailing list, but if you find a fundamental issue with YANG or > RESTCONF, feel free to discuss that on netmod instead. > > Please start a new email thread for each major issue that will need > discussion and make sure the subject line includes the draft name and > some sort of name for the issue. (Minor issues such as typos can also > be sent to the authors.) > > If you read the draft and think it looks fine, please send a one line > email to the list or to the chairs letting us know that so we can get > a feel of how broad the review has been. > > (To reviewers and authors:) If you are aware of any patent claims that > might apply to systems that implement these drafts, please review BCP 78 > and BCP 79 and make any appropriate IPR declaration before the last-call > ends. If you are not sure whether you need to make a declaration or not, > please talk to the chairs and we will help. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --00000000000099510605a2b3615a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Esko,

Thank you for your= review and your=C2=A0comments! They truly help us improve this document. P= lease find my answers below (prefixed with [IP]). Note that the diff after = handing your comments and those of=C2=A0Juergen Schoenwaelder can be found at [1].=C2=A0=
=

Best regards,=
Ivaylo

<= /div>
= [1]:=C2=A0https://tools.ietf.org/rfcd= iff?url1=3Ddraft-ietf-core-yang-cbor&url2=3Dhttp://core-wg.github.io/ya= ng-cbor/draft-ietf-core-yang-cbor-latest.txt
=
On Mon, Mar 30, 2020 at 2:24 PM Esko Dijk <esko.dijk@iotco= nsultancy.nl> wrote:
Hello CoRE,

I did a review of draft-ietf-core-yang-cbor-12 and some comments are below.= I do support the publication of this document but feel a few updates of mi= nor items are still needed! See the items below:

Section 3: "This specification supports two ty= pe of CBOR keys" -> two types of CBOR keys
=C2= =A0
[IP]: Fixed=C2=A0

Section 3: T= his root CBOR map is provided only as a typical usage example and is
=C2=A0 =C2=A0not part of the present encoding rules.=C2=A0 Only the value w= ithin this CBOR map is compulsory.
-> Not fully clear to me, how can an example be compulsory? Other values= within the CBOR map could also be used, right? Also it wasn't fully cl= ear to me how the data structure would otherwise be encoded if not with a r= oot CBOR map. Maybe good to give an example of how it would otherwise be en= coded if not with a root CBOR map!
=C2=A0
[IP]: This stems from the s= eparation between CoMI and YANG to CBOR - in CoMI we have complete examples= with the complete encoding of elements that were requested, whereas here w= e provide only instructions how particular elements need to be encoded - re= gardless of the fact that they might be a part of a bigger payload or part = of a protocol that handles the external wrapping. Where this causes issues = is SID deltas for example - without the wrapping elements, it would not be = clear how that would work. Please let us know if you could think of a bette= r way to express this.
=C2=A0
Section 3.1: Table 1 uses both uppercase and lowercase in the last column f= or the CBOR encoding. Best practice is to use either uppercase or lowercase= for hexadecimal, but not mixed I think.

[IP]: Fixed
=C2=A0
Section 4.5.2: "example-port: example-port-fault" :
-> space after ':' is to be removed. At least I think a space is= n't allowed there.

[IP]: Fixed
=C2=A0
Section 3.3 / 4.5.1 "as follow"
-> as follows

[IP= ]: Fixed
=C2=A0
Section 4.6: "data items tagged with one of th= e tag listed"
-> the tags listed
=C2=A0
[IP]: Fixed=C2=A0

Section 4.6: the "anyxml bar" definition should have "# SID = 60000" comment, like for the other YANG definitions that have a "= # SID ....." comment .

[IP]: Fixed
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> Section 5.1: "YANG template encoded using SIDs are carried in " -> YANG templates ...

[IP]: Changed request from Juergen Schoenwaelder made this look like:<= /font>

The yang-data extensions encoded using SIDs are ca= rried in a CBOR map containing a single item pair. The key of this item is = set to the SID assigned to the YANG template container, the value is set th= e CBOR encoding of this container as defined in {{container}}.
=
=C2=A0
Section 5.2 similar sentence as 5.1 above

[IP]: Fixed similarly to the above one.
<= /div>
=C2=A0
Section 6.6 example:
=C2=A0 type union {
=C2=A0 =C2=A0 =C2=A0type int32;
=C2=A0 =C2=A0 =C2=A0type enumeration {
=C2=A0 =C2=A0 =C2=A0 =C2=A0enum "unbounded";
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}

unclear why "unbounded" is within quotes? The CBOR encoding of th= is example encodes the word 'unbounded' without the quotes, which w= ould look like:
=C2=A0 =C2=A0type enumeration {
=C2=A0 =C2=A0 =C2=A0 =C2=A0enum unbounded;
=C2=A0 =C2=A0 =C2=A0}
An open question to me is whether RFC 7950 section 9.12.4 has the word unbo= unded in quotes on purpose, or by mistake. None of the other examples of en= um statements use the quotes! Why would this example suddenly use the quote= s? In any case if quotes are used then per RFC 7950 definitions the quotes = must also be encoded as part of the yang-string.

<= /div>
[IP]:=C2=A0I believe that was copied indeed from RFC 7950 as it is. I could n= ot find a reason why it should be with quotes, so I removed them as you sug= gested.
=C2=A0
Section 6.6: Tag 44 use - in sec= tion 8.1, the table states that the tag must mark a data item of type unsig= ned integer. Which is not the case here, it marks a string.

[IP]: It should be a "text str= ing" in Section 8.1. This has changed relatively recently and obviousl= y we overlooked the values in the table. Fixed now
= =C2=A0
Section 6.7: similar to section 6.6, the tag 43 mentions data item "by= te string" in Section 8.1 while in section 6.7 it is followed by a tex= t string.
Just to be clear: if a 'bits' type is encoded, it looks like the ta= g 43 is only used if followed by a text string as in 43("under-repair = critical") ? Or should a tag 43 also be used in case a CBOR byte strin= g follows?
E.g. 43(h'06') instead of h'06' ? That doesn't seem to = be the intention in the current text.
=C2=A0
[IP]: It should be a "text string" in Section= 8.1. Fixed now. My reading of this is that the tag 43 can only be used ins= ide unions.

Section 8.1: could indicate here what the column 'Data Item' means.= E.g. make clear that the CBOR data item following the tag listed in the fi= rst column cell must be of one of the CBOR data types listed in the second = column cell.

[IP]: This i= s the column title used in section 7.2 of RFC7049. If you believe that the = sentence right before the table is not clear enough, please let us know how= we could improve it.

Best regards
Esko


IoTconsultancy.nl=C2=A0 |=C2=A0 Email/Skype: esko.dijk@iotconsultancy.nl


-----Original Message-----
From: core <c= ore-bounces@ietf.org> On Behalf Of Carsten Bormann
Sent: Monday, March 9, 2020 14:05
To: core <core@ietf.o= rg>
Cc: netmod@ietf.org
Subject: [core] =F0=9F=94=94 WG Last Call of CORECONF drafts: draft-ietf-co= re-yang-cbor-12, -sid-11, -comi-09, -yang-library-01

It took us a long time to get the four CORECONF drafts in sync,
but now we are ready for WGLC.

This starts a working group last call for
=E2=80=94 draft-ietf-core-yang-cbor-12
=E2=80=94 draft-ietf-core-sid-11
=E2=80=94 draft-ietf-core-comi-09
=E2=80=94 draft-ietf-core-yang-library-01

ending on

=C2=A0 =C2=A0 =C2=A0 =C2=A0 24:00 UTC on Tuesday, March 31, 2020.

(This includes some extra time for the IETF week and for cross-WG
coordination.)

This WGLC is copied to the netmod WG mailing list; please do have a look at these drafts as they are slated to become a part of the greater
YANG/NETCONF/RESTCONF family.=C2=A0 We intend the discussion to be on the CoRE mailing list, but if you find a fundamental issue with YANG or
RESTCONF, feel free to discuss that on netmod instead.

Please start a new email thread for each major issue that will need
discussion and make sure the subject line includes the draft name and
some sort of name for the issue.=C2=A0 (Minor issues such as typos can also=
be sent to the authors.)

If you read the draft and think it looks fine, please send a one line
email to the list or to the chairs letting us know that so we can get
a feel of how broad the review has been.

(To reviewers and authors:)=C2=A0 If you are aware of any patent claims tha= t
might apply to systems that implement these drafts, please review BCP 78 and BCP 79 and make any appropriate IPR declaration before the last-call ends. If you are not sure whether you need to make a declaration or not, please talk to the chairs and we will help.

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

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--00000000000099510605a2b3615a-- From nobody Tue Apr 7 06:36:53 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BB63A09EC for ; Tue, 7 Apr 2020 06:36:52 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or74oI39uymq for ; Tue, 7 Apr 2020 06:36:49 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 EC4E23A09F1 for ; Tue, 7 Apr 2020 06:36:05 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id r26so1872646wmh.0 for ; Tue, 07 Apr 2020 06:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=lbat/nid0XkgLgmugulQxduJIPCWodDW508b3fPW/2s=; b=FQ45laGivtYzV+cNdiJNCknxkD29eYT9uMjgfeg0bPsUvdLTTcnXehRuL1u3h8TX40 8cKoY/Dc83IdQ8PLaIXGdlAK0knoLTgZqpTH+nCgvOp4iIDE0dFpd66Er9yhdMJHRECG npyAM7E44Ap9+NodvpO9XPQ/nAn2mxk4bmc3ciSukteWUOebHbVkdF1XIM0ksJIrsosB 4kqElnGWwfdRHVKTwWBQWe/Z8KTqo+NMjQUOAPGqfQGVQeZLpMOkhUU24oNE9UIxCMgg wLJhxPdctyv7vaMLmTF5kHpV35RB4uF1tVhl1O4x9mkgy7GMhijaQFI37RznXtdCEw3I YVVg== 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; bh=lbat/nid0XkgLgmugulQxduJIPCWodDW508b3fPW/2s=; b=JnU8cpsYv5Y4sOEjvjDzdJ9AMzZ7Co2deWQviw1C9W/rc5Sd8dYGcYNHW/s/JFhAUY /EVqLl/9wZB92kYhMz3TOKGsIzOntjxe9tTD2mkG8RK+F9jH6bjpLX487ZgrDorZbXMr RYTxJ6VABJoXapcnJF2c/2IqgDvkSWnWvUdKG9HfHQQWq0wkL9eJSUhVIKlZAVxOQk4X tR1jnRqAblGbG2TGgYHvBW1Ge0QDbBkShNR03DzhoDKM2wo50wYuaZL25Me/HGfLaQh8 O4vpsm2uKUPxAAK6W7ZrF1pG9FnTHqUupDyVbQpgRr2jwM1LC4Jn/z6NUETGlHHwNHJF VZ6g== X-Gm-Message-State: AGi0PubNvUNSM7FTLYF2bnWBTpF5NKSd6L7IWR51blnYaRvRgF5CF1xp dA8LDREfm2rT2Ajz1HI00PJX4QUCG4bhf3EffBZ5z0qgUho= X-Google-Smtp-Source: APiQypJAaSiaXelAodFi2dtYcjUP2tOZU1YTOCZv8CGw+jmCX15iaFZ9HALeZmgxPK/mfbSHUU/eOkyS6sO7R5VqxcE= X-Received: by 2002:a1c:ab03:: with SMTP id u3mr2427013wme.86.1586266563938; Tue, 07 Apr 2020 06:36:03 -0700 (PDT) MIME-Version: 1.0 References: <20200331110237.zbo3zw74xlccur3w@anna.jacobs.jacobs-university.de> In-Reply-To: <20200331110237.zbo3zw74xlccur3w@anna.jacobs.jacobs-university.de> From: Ivaylo Petrov Date: Tue, 7 Apr 2020 15:35:37 +0200 Message-ID: To: Juergen Schoenwaelder , core , netmod@ietf.org Content-Type: multipart/alternative; boundary="00000000000010200b05a2b37726" Archived-At: Subject: Re: [core] js review of draft-ietf-core-yang-cbor-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: Tue, 07 Apr 2020 13:36:53 -0000 --00000000000010200b05a2b37726 Content-Type: text/plain; charset="UTF-8" Hello Juergen, Thank you for the detailed review and your comments! They truly help us improve this document. Please find my answers below (prefixed by [IP]). Note that the diff after handing your comments and those of Esko Dijk can be found at [1]. Best regards, Ivaylo [1]: https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-yang-cbor&url2=http://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.txt On Tue, Mar 31, 2020 at 1:03 PM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > here is my review of draft-ietf-core-yang-cbor-12. I have not checked > the examples in detail, I assume (hope?) the authors have used tools > to generate them or to validate them. > > - Nit: There is no need to capitalize Action in the abstract (and > elsewhere). > [IP]: Fixed - You should perhaps write 'yang-data extension' instead of 'yang data > template' since this is more concrete and less confusing. The use of > 'template' is a bit unfortunate in RFC 8040 since templates have > been used with different meanings elsewhere and I believe people > more commonly refer to the yang-data extension. I also checked > draft-ietf-netmod-yang-data-ext-05.txt and it does not use the word > "template" anymore. > > I see that you use 'YANG data template' later on in several places. > This is not strictly incorrect but I find it unfortunate. I would > prefer to talk specifically about the yang-data extensions. You > actually import both terms, I believe only one is needed (and I > prefer yang-data (extension) over YANG data template. > [IP]: Fixed following your advice. > - If this work gets approved, will other specifications like > draft-ietf-netmod-yang-data-ext-05.txt be expected to cover CBOR > encoding in addition to XML and JSON? This is more a procedural > question. > [IP]: From our discussions, I could say that that is desirable, but not something these drafts can enforce. (Also, for drafts that already are well-advanced, one would expect a companion draft on a later timeline instead of the original text-based (JSON/XML) draft.) > - Wording: > > A new set of encoding rules has been defined to allow the use of the > same data models in environments based on the JavaScript Object > Notation (JSON) Data Interchange Format [RFC8259]. This is > accomplished in the JSON Encoding of Data Modeled with YANG > specification [RFC7951]. > > What is "environments based on the JavaScript Object Notation (JSON) > Data Interchange Format". Perhaps do not even try to speculate about > reasons. What about this? > > An additional set of encoding rules has been defined based on the > JavaScript Object Notation (JSON) Data Interchange Format > [RFC8259]. > [IP]: Applied and added the reference to RFC7951 as that seems relevant. Now it reads: An additional set of encoding rules has been defined in {{RFC7951}} based on the JavaScript Object Notation (JSON) Data Interchange Format {{RFC8259}}. > - Is there a reason why SID terminology is not imported from the SID > specification? Is the reason to avoid a dependency? But then, can > this dependency really be avoided? I reviewed the SID document first > because I thought knowing what SIDs are is essential to understand > this document... > [IP]: This decision has been made before my personal involvement with this document. I will let the other authors correct me if I am mistaken, but my understanding is that while it is a good candidate, we did not necessarily want to mandate the use of the SID draft in order to use the yang-cbor draft. If the implementers want to have another way of deriving meaning for the SIDs, that is fine. I will have to verify if the interoperability in this case was a concern and how it was supposed to be handled. - I am not sure I would call a notification or a container a > collection. Note that RFC 7950 uses the phrase child node quite a > bit in definitions, so this may do the same without using the > (overloaded) word collection: > > o child: A schema node defined as a child node of a > container, a list, a case, a notification, an RPC input, an RPC > output, an action input, an action output. > > I searched the text and 'child' only shows up once and I am not > sure this deserves to define a term at all. > [IP]: I modified the definition as you suggested, but I believe we should keep it as it aims at avoiding confusion over choice and other schema nodes that do not add any additional payload/information during the encoding. They are not considered child nodes in the explicit definition as otherwise we would have had to provide rules for their encoding. - Is 'parent' the same as an 'interior node' defined in RFC 7950? If > so, why not use 'interior node'? Looking at the uses or parent, I am > not even convinced this term needs to be defined at all, the context > seems to be rather clear of what is meant. RFC 7950 does not define > 'parent' as term either but the meaning is clear in the contexts > where the word is being used. > [IP]: I reworded this definition as well, but similarly, a choice is not a parent node in this context. Relevant text: The container, list, case, notification, RPC input, RPC output, action input or action output node in which a schema node is defined. > - To summarize the last few comments, I propose to import 'item' and > 'SID' from the SID document, to not define 'child' and 'parent' > (following RFC 7950), and so the only term to defined here is > 'delta'. But see above concerning the relationship to the SID > document; it is not clear to me what the goals and intentions are in > terms of intended document dependencies. > [IP]: I believe that my previous points provide the relevant answers, but do not hesitate to let us know if you have more concerns about any of your remarks. > - schema trees vs data trees > > This document defines CBOR encoding rules for YANG schema trees and > their subtrees. > > You are not encoding schema trees, you are encoding data trees. See > also the JSON document, which says: > > This document defines JSON encoding for YANG data trees and their > subtrees. > > Why did you change this from data trees to schema trees? > [IP]: Fixed > - avoid 'collection'? > > s/A collection such as/A data node such as/ > [IP]: RPCs, action inputs/outputs and notifications are not included in the data node definition, therefore I changed it to 'nodes from the data tree', which seems to be precise enough. Please let us know how that works for you. Also do you think we should have a definition like `serializable node` in order to avoid listing all the different node types each time? - If I were to use CBOR with RESTCONF, can I request (e.g. via a > specific media-type) how I like the keys to be encoded? Or would > such a mechanism have to be specified elsewhere, i.e., we would need > another using CBOR with RESTCONF document that defines suitable > media types? > [IP]: Currently media types/content formats are defined in the CoMI draft, which seems the appropriate place for me. If RESTCONF is to be used with CBOR, I would expect that some specification should define the media type along with uses of SIDs if needed. - I do not understand this statement: > > Application payloads carrying a value serialized using the rules > defined by this specification (e.g. CoAP Content-Format) SHOULD > include the identifier (e.g. SID, namespace qualified name, > instance-identifier) of this value. > > What is "the identifier of this value"? I am not getting what > is being conveyed here. [IP]: I rewrote this as When schema node are serialized using the rules defined by this specification as part of an application payload, the payload SHOULD include information that would allow a stateless way to identify each node, such as the SID number associated with each node, SID delta from another SID in the application payload, the namespace qualified name or the instance-identifier. Please let us know if that is more clear. > - s/section Section 4/Section 4/ > [IP]: Fixed - SIDs other than [I-D.ietf-core-sid]? > > [...] If SIDs are to be used, the present specification is > used in conjunction with a specification defining this management. > One example for such a specification is [I-D.ietf-core-sid]. > > This seems to indicate that there can be other kinds of SIDs or SIDs > managed differently. Why is this? The SID I-D claims the entire > number space, so how would a different 'specification defining the > management of SIDs' ever work? Why not be specific that the usage of > SIDs depends on [I-D.ietf-core-sid]? See my earlier comments about > the unclear dependency relationship between this specification and > the SID specification. > [IP]: My understanding is that indeed there is the presumption that other implementations that map YANG item identifiers to unsigned numbers could exist in the future. If this is the case, I am not aware how one could interoperate (I would guess based on the content format), but I will let my coauthors comment on that. > - Avoid 'collections'? > > 4.2. The 'container' and other collections > > Collections such as containers, list instances, notification > > Rewrite to: > > 4.2. The 'container' and other interior data nodes > > Interior data nodes such as containers, list instances, notification > > There are more uses of collections following that likely can be > replaced with 'interior data nodes'. The phrase 'interior data node' > is used in RFC 7950 (although not formally defined). > [IP]: I mostly agree. It seems, however, that there are some nodes from data trees that are not qualified as data nodes that are still of interest to us here, so I used the term `nodes from data trees` instead of 'interior data nodes'. Now the title reads The 'container' and other nodes from the data tree and the first sentence just misses `Interior data nodes such as ` and starts listing the relevant nodes for which this section applies. > - Should > > 77 : { / event (SID 60200) / > > be > > 77 : { / example-port-fault (SID 60200) / > > Similarly > > 47(60200) : { / event (SID 60123) / > > be > > 47(60200) : { / example-port-fault (SID 60200) / > [IP]: Fixed > - Replace > > 5. Encoding of YANG data templates > > YANG data templates are data structures defined in YANG but not > intended to be implemented as part of a datastore. YANG data > templates are defined using the 'yang-data' extension as described by > [RFC8040]. > > YANG data templates MUST be encoded using the encoding rules of a > collection as defined in Section 4.2. > > with > > 5. Encoding of the 'yang-data' extension > > The yang-data extension [RFC8040] is used to define data structures > in YANG that are not intended to be implemented as part of a > datastore. > > The yang-data extension MUST be encoded using the encoding rules of > interior nodes as defined in Section 4.2. > > to avoid the use of 'templates' and 'collections'. In the following > text, there are a few more places where 'YANG template' should be > replaced by the 'yang-data extension'. > [IP]: Agreed, only interior nodes is replaced by for the nodes of the data trees as follows: The yang-data extension MUST be encoded using the encoding rules for the nodes of the data trees as defined in Section 4.2. - Unexpected ietf-comi module name showing up in an example > > "ietf-comi:error" : { > > The module prefix pops up out of the blue. You may want the put the > yang-data definition into an example module, give it an example > name, and then replace ietf-comi with that example name. Perhaps > even simplify the yang-data schema to just 1-2 leafs. > [IP]: I added extra text that should make this much easier to understand. While the relevant part could be communicated with a smaller example, I prefer to have a more complete example as long as it does not bloat the relevant part, which does not appear to be the case here. > - typo > > s/section defined the CBOR encoding/section defines the CBOR encoding/ > [IP]: Fixed > - Improve wording > > To avoid overlap of 'value' defined in different 'enumeration' > statements, 'enumeration' defined in a Leafs of type 'union' MUST be > encoded using a CBOR text string data item (major type 3) and MUST > contain one of the names assigned by 'enum' statements in YANG. > > This does not read well. Perhaps: > > Values of 'enumeration' types defined in a 'union' type MUST be > encoded using a CBOR text string data item (major type 3) and MUST > contain one of the names assigned by 'enum' statements in YANG. > > There is similar text on page 31 in the context of bits encoding > that will also benefit from a rewrite. > [IP]: Fixed > - Third example Bob vs Jack > > Should the third example use > > "/ietf-system:system/authentication/user[name='jack']" > > instead of > > "/ietf-system:system/authentication/user[name='bob']" > > to line up with the third example using SIDs? > [IP]: Fixed > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --00000000000010200b05a2b37726 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Juergen,<= /div>
=
Thank you for t= he detailed review and your=C2=A0comments!=C2=A0They truly help us improve this document= .=C2=A0Please find my answers below (prefixe= d by [IP]).=C2=A0Note that the diff after handing your comments and th= ose of=C2=A0E= sko Dijk can be found at [1].=C2=A0

Best=C2=A0regards,
Ivaylo

<= /div>
= [1]:=C2=A0https://tools.ietf= .org/rfcdiff?url1=3Ddraft-ietf-core-yang-cbor&url2=3Dhttp://core-wg.git= hub.io/yang-cbor/draft-ietf-core-yang-cbor-latest.txt
=
<= div dir=3D"ltr">
=
=
On Tue, Mar 31, 2020 at 1:03 PM Juergen Sch= oenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
=
Hi,

here is my review of draft-ietf-core-yang-cbor-12. I have not checked
the examples in detail, I assume (hope?) the authors have used tools
to generate them or to validate them.

- Nit: There is no need to capitalize Action in the abstract (and
=C2=A0 elsewhere).

[= IP]: Fixed

- You should perhaps write 'yang-data extension' instead of 'ya= ng data
=C2=A0 template' since this is more concrete and less confusing. The us= e of
=C2=A0 'template' is a bit unfortunate in RFC 8040 since templates = have
=C2=A0 been used with different meanings elsewhere and I believe people
=C2=A0 more commonly refer to the yang-data extension. I also checked
=C2=A0 draft-ietf-netmod-yang-data-ext-05.txt and it does not use the word<= br> =C2=A0 "template" anymore.

=C2=A0 I see that you use 'YANG data template' later on in several = places.
=C2=A0 This is not strictly incorrect but I find it unfortunate. I would =C2=A0 prefer to talk specifically about the yang-data extensions. You
=C2=A0 actually import both terms, I believe only one is needed (and I
=C2=A0 prefer yang-data (extension) over YANG data template.

[IP]: Fixed following your advice.=
=C2=A0
- If this work gets approved, will other specifications like
=C2=A0 draft-ietf-netmod-yang-data-ext-05.txt be expected to cover CBOR
=C2=A0 encoding in addition to XML and JSON? This is more a procedural
=C2=A0 question.

[IP= ]: From our discussions, I could say that that is desirable, but not someth= ing these drafts can enforce. =C2=A0(Also, for drafts that already are well= -advanced, one would expect a companion draft on a later timeline instead o= f the original text-based=C2=A0(JSON/XML) dra= ft.)=C2=A0
- Wording:

=C2=A0 =C2=A0 =C2=A0A new set of encoding rules has been defined to allow t= he use of the
=C2=A0 =C2=A0 =C2=A0same data models in environments based on the JavaScrip= t Object
=C2=A0 =C2=A0 =C2=A0Notation (JSON) Data Interchange Format [RFC8259].=C2= =A0 This is
=C2=A0 =C2=A0 =C2=A0accomplished in the JSON Encoding of Data Modeled with = YANG
=C2=A0 =C2=A0 =C2=A0specification [RFC7951].

=C2=A0 What is "environments based on the JavaScript Object Notation (= JSON)
=C2=A0 Data Interchange Format". Perhaps do not even try to speculate = about
=C2=A0 reasons. What about this?

=C2=A0 =C2=A0 =C2=A0An additional set of encoding rules has been defined ba= sed on the
=C2=A0 =C2=A0 =C2=A0JavaScript Object Notation (JSON) Data Interchange Form= at
=C2=A0 =C2=A0 =C2=A0[RFC8259].

[IP]: Applied and added the reference= to RFC7951 as that seems relevant. Now it reads:

=
An additional set of encoding rules has bee= n defined in {{RFC7951}} based on
the JavaScript Object Notation (JSON) = Data Interchange Format {{RFC8259}}.
=C2=A0
- Is there a reason why SID terminology is not imported from the SID
=C2=A0 specification? Is the reason to avoid a dependency? But then, can =C2=A0 this dependency really be avoided? I reviewed the SID document first=
=C2=A0 because I thought knowing what SIDs are is essential to understand =C2=A0 this document...
=C2=A0
[IP]: This decision has been made before my personal involv= ement with this document. I will let the other authors correct me if I am m= istaken, but my understanding is that while it is a good candidate, we did = not necessarily want to mandate the use of the SID draft in order to use th= e yang-cbor draft. If the implementers want to have another way of deriving= meaning for the SIDs, that is fine. I will have to verify if the interoper= ability in this case was a concern and how it was supposed to be handled.

- I am not sure I would call a notification or a container a
=C2=A0 collection. Note that RFC 7950 uses the phrase child node quite a =C2=A0 bit in definitions, so this may do the same without using the
=C2=A0 (overloaded) word collection:

=C2=A0 =C2=A0o=C2=A0 child: A schema node defined as a child node of a
=C2=A0 =C2=A0 =C2=A0 container, a list, a case, a notification, an RPC inpu= t, an RPC
=C2=A0 =C2=A0 =C2=A0 output, an action input, an action output.

=C2=A0 =C2=A0I searched the text and 'child' only shows up once and= I am not
=C2=A0 =C2=A0sure this deserves to define a term at all.

[IP]: I modified the definition as you= suggested, but I believe we should keep it as it aims at avoiding confusio= n over choice and other schema nodes that do not add any additional payload= /information during the encoding. They are not considered child nodes in th= e explicit definition as otherwise we would have had to provide rules for t= heir encoding.

- Is 'parent' the same as an 'interior node' defined in RFC= 7950? If
=C2=A0 so, why not use 'interior node'? Looking at the uses or pare= nt, I am
=C2=A0 not even convinced this term needs to be defined at all, the context=
=C2=A0 seems to be rather clear of what is meant. RFC 7950 does not define<= br> =C2=A0 'parent' as term either but the meaning is clear in the cont= exts
=C2=A0 where the word is being used.

[IP]: I reworded this definition a= s well, but similarly, a choice is not a parent node in this context. Relev= ant text:

The container, list, case, n= otification, RPC input, RPC output, action input or action output node in w= hich a schema node is defined.
= =C2=A0
- To summarize the last few comments, I propose to import 'item' an= d
=C2=A0 'SID' from the SID document, to not define 'child' a= nd 'parent'
=C2=A0 (following RFC 7950), and so the only term to defined here is
=C2=A0 'delta'. But see above concerning the relationship to the SI= D
=C2=A0 document; it is not clear to me what the goals and intentions are in=
=C2=A0 terms of intended document dependencies.

[IP]: I believe that=C2=A0my previous=C2=A0points provide the relevant ans= wers, but=C2=A0do not hesitate to let us know if yo= u have more concerns about any=C2=A0of your remarks.
=C2=A0
[IP]: Fixed
=C2=A0
- avoid 'collection'?

=C2=A0 s/A collection such as/A data node such as/<= br>

[IP]:=C2=A0RPCs= , action inputs/outputs and notifications are not included in the data node= definition, therefore I changed it to 'nodes from the data tree', = which seems to be precise enough.=C2=A0Please let us know how that w= orks for you. Also do you think we should have a definition like `serializa= ble node` in order to avoid listing all the different node types each time?=

- If I were to use CBOR with RESTCONF, can I request (e.g. via a
=C2=A0 specific media-type) how I like the keys to be encoded? Or would
=C2=A0 such a mechanism have to be specified elsewhere, i.e., we would need=
=C2=A0 another using CBOR with RESTCONF document that defines suitable
=C2=A0 media types?

[IP]:= =C2=A0=C2=A0Currentl= y media types/content formats are defined in the CoMI draft, which seems th= e appropriate place for me. If RESTCONF is to be used with CBOR, I would ex= pect that some specification should define the media type along with uses o= f SIDs if needed.

- I do not understand this statement:

=C2=A0 =C2=A0Application payloads carrying a value serialized using the rul= es
=C2=A0 =C2=A0defined by this specification (e.g.=C2=A0 CoAP Content-Format)= SHOULD
=C2=A0 =C2=A0include the identifier (e.g.=C2=A0 SID, namespace qualified na= me,
=C2=A0 =C2=A0instance-identifier) of this value.

=C2=A0 What is "the identifier of this value"? I am not getting w= hat
=C2=A0 is being conveyed here.

[IP]:=C2=A0I rewro= te this as

When sch= ema node are serialized using the rules defined by this specification as pa= rt of an application payload, the payload SHOULD include information that w= ould allow a stateless way to identify each node, such as the SID number as= sociated with=C2=A0each node, SID delta from anothe= r SID in the application payload, the namespace qualified name or the insta= nce-identifier.

Please let us know if that is more clear.
=C2=A0
- s/section Section 4/Section 4/

[IP]: Fixed

- SIDs other than [I-D.ietf-core-sid]?

=C2=A0 =C2=A0 =C2=A0[...] If SIDs are to be used, the present specification= is
=C2=A0 =C2=A0 =C2=A0used in conjunction with a specification defining this = management.
=C2=A0 =C2=A0 =C2=A0One example for such a specification is [I-D.ietf-core-= sid].

=C2=A0 This seems to indicate that there can be other kinds of SIDs or SIDs=
=C2=A0 managed differently. Why is this? The SID I-D claims the entire
=C2=A0 number space, so how would a different 'specification defining t= he
=C2=A0 management of SIDs' ever work? Why not be specific that the usag= e of
=C2=A0 SIDs depends on [I-D.ietf-core-sid]? See my earlier comments about =C2=A0 the unclear dependency relationship between this specification and =C2=A0 the SID specification.
=
[IP]: My understanding is that indeed there is the presumptio= n that other implementations that map YANG item identifiers to unsigned num= bers could exist in the future. If this is the case, I am not aware how one= could interoperate (I would guess based on the content format), but I will= let my coauthors comment on that.
=C2=A0
- Avoid 'collections'?

=C2=A0 =C2=A0 4.2.=C2=A0 The 'container' and other collections

=C2=A0 =C2=A0 Collections such as containers, list instances, notification<= br>
=C2=A0 Rewrite to:

=C2=A0 =C2=A0 4.2.=C2=A0 The 'container' an= d other interior data nodes

=C2=A0 =C2=A0 Interior data nodes such as container= s, list instances, notification

=C2=A0 There are more uses of collections following that likely can be
=C2=A0 replaced with 'interior data nodes'. The phrase 'interio= r data node'
=C2=A0 is used in RFC 7950 (although not formally defined).

[IP]= : I mostly agree. It seems, however, that there are some nodes from data tr= ees that are not qualified as data nodes that are still of interest to us h= ere, so I used the term `nodes from data trees` instead of 'interior da= ta nodes'. Now the title reads

The 'contai= ner' and other nodes from the data tree

and the first sentence=C2=A0just misses `Interior data nodes such as=C2=A0` and starts listing the relevant nodes= for which this section applies.
=C2=A0
- Should

=C2=A0 =C2=A0 =C2=A0 =C2=A077 : {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 / event (SID 60200) /

=C2=A0 be

=C2=A0 =C2=A0 =C2=A0 =C2=A077 : {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 / example-port-fault (SID 60200) /

=C2=A0 Similarly

=C2=A0 =C2=A0 =C2=A0 =C2=A047(60200) : {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0/ event (SID 60123) /

=C2=A0 be

=C2=A0 =C2=A0 =C2=A0 =C2=A047(60200) : {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0/ example-port-fault (SID 60200) /
=

[IP]: Fixed
=C2=A0
- Replace

=C2=A0 5.=C2=A0 Encoding of YANG data templates

=C2=A0 =C2=A0YANG data templates are data structures defined in YANG but no= t
=C2=A0 =C2=A0intended to be implemented as part of a datastore.=C2=A0 YANG = data
=C2=A0 =C2=A0templates are defined using the 'yang-data' extension = as described by
=C2=A0 =C2=A0[RFC8040].

=C2=A0 =C2=A0YANG data templates MUST be encoded using the encoding rules o= f a
=C2=A0 =C2=A0collection as defined in Section 4.2.

=C2=A0 with

=C2=A0 5.=C2=A0 Encoding of the 'yang-data' extension

=C2=A0 =C2=A0The yang-data extension [RFC8040] is u= sed to define data structures
=C2=A0 =C2=A0in YANG that are not intended to be implemented as part of a =C2=A0 =C2=A0datastore.

=C2=A0 =C2=A0The yang-data extension MUST be encoded using the encoding rul= es of
=C2=A0 =C2=A0interior nodes as defined in Section 4= .2.

=C2=A0 to avoid the use of 'templates' and 'collections'. I= n the following
=C2=A0 text, there are a few more places where 'YANG template' shou= ld be
=C2=A0 replaced by the 'yang-data extension'.
=
[IP]: Agreed, only=C2=A0inter= ior nodes is replaced by=C2=A0for the nodes of the data trees as follows:<= /div>

The yang-data extension MUST be encoded using the encoding rules for the n= odes of the data trees as defined in Section 4.2.=C2=A0
=

- Unexpected ietf-comi module name showing up in an example

=C2=A0 =C2=A0 =C2=A0"ietf-comi:error" : {

=C2=A0 The module prefix pops up out of the blue. You may want the put the<= br> =C2=A0 yang-data definition into an example module, give it an example
=C2=A0 name, and then replace ietf-comi with that example name. Perhaps
=C2=A0 even simplify the yang-data schema to just 1-2 leafs.
=C2=A0
[IP]: I added extra text that should make this much = easier to understand. While the relevant part could be communicated with a = smaller example, I prefer to have a more complete example as long as it doe= s not bloat the relevant part, which does not appear to be the case here.
=C2=A0
- typo

=C2=A0 s/section defined the CBOR encoding/section defines the CBOR encodin= g/

[IP]: Fixed
= =C2=A0
- Improve wording

=C2=A0 =C2=A0To avoid overlap of 'value' defined in different '= enumeration'
=C2=A0 =C2=A0statements, 'enumeration' defined in a Leafs of type &= #39;union' MUST be
=C2=A0 =C2=A0encoded using a CBOR text string data item (major type 3) and = MUST
=C2=A0 =C2=A0contain one of the names assigned by 'enum' statements= in YANG.

=C2=A0 This does not read well. Perhaps:

=C2=A0 =C2=A0Values of 'enumeration' types defined in a 'union&= #39; type MUST be
=C2=A0 =C2=A0encoded using a CBOR text string data item (major type 3) and = MUST
=C2=A0 =C2=A0contain one of the names assigned by 'enum' statements= in YANG.

=C2=A0 There is similar text on page 31 in the context of bits encoding
=C2=A0 that will also benefit from a rewrite.
<= font color=3D"#000000">
[IP]: Fixed=
=C2=A0
- Third example Bob vs Jack

=C2=A0 Should the third example use

=C2=A0 =C2=A0"/ietf-system:system/authentication/user[name=3D'jack= ']"

=C2=A0 instead of

=C2=A0 =C2=A0"/ietf-system:system/authentication/user[name=3D'bob&= #39;]"

=C2=A0 to line up with the third example using SIDs?
<= span class=3D"gmail_default" style=3D"font-family:verdana,sans-serif">
[IP]: F= ixed=C2=A0
=C2=A0
/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--00000000000010200b05a2b37726-- From nobody Tue Apr 7 08:18:55 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B33D3A0C42; Tue, 7 Apr 2020 08:18: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, 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 r-oAboI2pnJa; Tue, 7 Apr 2020 08:18:45 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2203A0C46; Tue, 7 Apr 2020 08:18:44 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 7 Apr 2020 08:18:38 -0700 From: Jim Schaad To: , CC: 'Jon Shallow' , References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Tue, 7 Apr 2020 08:18:36 -0700 Message-ID: <049201d60cef$d1299a50$737ccef0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0493_01D60CB5.24CB3780" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGFUV4cZbdAMYpJNEeLLEh4F2cKc6kPPIrA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 15:18:47 -0000 ------=_NextPart_000_0493_01D60CB5.24CB3780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I do not believe that there is anything today that says the observer is required to do a GET to receive the next fragment in the event that it does not care about what it says. The question that sprints to mind is how should the server/client decide that it does or does not want to retrieve the entire content? Jim From: core On Behalf Of mohamed.boucadair@orange.com Sent: Tuesday, April 7, 2020 4:11 AM To: core@ietf.org Cc: Jon Shallow (supjps-ietf@jpshallow.com) ; dots@ietf.org Subject: [core] Large asynchronous notifications under DDoS: New BLOCK Option? Hi all, We are using Observe to receive notifications during attack events. These notifications are set as NON messages for reasons specific to DDoS conditions. With DDoS telemetry information included (see draft-ietf-dots-telemetry), a notification may not fit one single message. The use of BLOCK2 is not convenient during attack times. A full description of the issue is described here: https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4/ We are considering some mechanisms to solve this issue. One of them is to define a new BLOCK option (similar to BLOCK2) that does not require the observer to send a GET to receive the next fragment. The server will send all the fragments. The observer will follow a SACK-like approach to request retransmission of missing fragments. Please let us know whether you think this is a generic issue that should be solved at the CoAP or not. Suggestions are welcome. Thank you. Cheers, Jon & Med ------=_NextPart_000_0493_01D60CB5.24CB3780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do not = believe that there is anything today that says the observer is required = to do a GET to receive the next fragment in the event that it does not = care about what it says.   The question that sprints to mind = is how should the server/client decide that it does or does not want to = retrieve the entire content?

 

Jim

 

 

From: core = <core-bounces@ietf.org> On Behalf Of = mohamed.boucadair@orange.com
Sent: Tuesday, April 7, 2020 = 4:11 AM
To: core@ietf.org
Cc: Jon Shallow = (supjps-ietf@jpshallow.com) <supjps-ietf@jpshallow.com>; = dots@ietf.org
Subject: [core] Large asynchronous notifications = under DDoS: New BLOCK Option?

 

Hi = all,

 

We are using = Observe to receive notifications during attack events. These = notifications are set as NON messages for reasons specific to DDoS = conditions.

 

With DDoS = telemetry information included (see draft-ietf-dots-telemetry), a = notification may not fit one single message. The use of BLOCK2 is not = convenient during attack times. A full description of the issue is = described here: https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBh= S_TZtsWeP4/

 

We are = considering some mechanisms to solve this issue. One of them is to = define a new BLOCK option (similar to BLOCK2) that does not require the = observer to send a GET to receive the next fragment. The server will = send all the fragments. The observer will follow a SACK-like approach to = request retransmission of missing fragments.

 

Please let us know whether you think = this is a generic issue that should be solved at the CoAP or not. = Suggestions are welcome.

 

Thank you. =

 

Cheers,

Jon & Med =

------=_NextPart_000_0493_01D60CB5.24CB3780-- From nobody Tue Apr 7 08:51:21 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B443A099F; Tue, 7 Apr 2020 08:51:19 -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, 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 lV0pOzc_tuI6; Tue, 7 Apr 2020 08:51:18 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38D53A09AA; Tue, 7 Apr 2020 08:51:17 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 48xX2C6T6tz1yKM; Tue, 7 Apr 2020 17:51:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586274675; bh=xY1JDBBkaKRZLlR50yODwE0Sh6ccvXciEcPDFPZ9Pho=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=q8BPTgytLdXbkHhlY5D2Vd85eO0DGhGbYYMdmFyPLXQRfzVepkfrj9zSTPF/LUIn4 I42koglugrUcpBiMkyCwZtP4luV8dhrL2yTMTuDqCQRTxH4oOEyC5OlLC6ke87ZHEC zREuHEiXk7l9WQVFWK0UJ1MvtsOtQY5NeuSNVdq3vHH/eBl1WjaAGY33dP0cyvUEqf 75kZNZq/vwwHmxVeLzS4eUTLJjcDEr1K8v3eu2pi8WPb8+W3Cjx9IhUyVCO+XwX0I0 ELeXBxsuSzR+EZXx8DnMPXVbWMNVn0K751b79IrTM+R/Ezmu86KVGe7dudxBtjY66s 6WKFJDtWGg0UQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 48xX2C6DbFzDq7f; Tue, 7 Apr 2020 17:51:15 +0200 (CEST) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= CC: "core@ietf.org" , "Jon Shallow (supjps-ietf@jpshallow.com)" , "dots@ietf.org" Thread-Topic: [core] Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AQHWDPRedOrOjDwtJU6xyqFOQUbPsA== Date: Tue, 7 Apr 2020 15:51:14 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303149075C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20200407130944.GA2738832@hephaistos.amsuess.com> In-Reply-To: <20200407130944.GA2738832@hephaistos.amsuess.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 15:51:19 -0000 Hi Christian, Thank you for sharing your thoughts.=20 I don't see where in the two drafts an observer can request a particular mi= ssing fragment.=20 Cheers, Med > -----Message d'origine----- > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] > Envoy=E9=A0: mardi 7 avril 2020 15:10 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: core@ietf.org; Jon Shallow (supjps-ietf@jpshallow.com); > dots@ietf.org > Objet=A0: Re: [core] Large asynchronous notifications under DDoS: New > BLOCK Option? >=20 > Hello Jon, hello Med, >=20 > I don't have full answers, but some data points (also pulling in the > cited mail): >=20 > > and a response (may need new code) that says status is too large to > > fit into a packet or has been truncated). >=20 > That an observation with blockwise would already do: If the observed > resource changes to have its representation larger than the block size > or MTU, it'd send the first block. >=20 > > The observer will follow a SACK-like approach to request > > retransmission of missing fragments. >=20 > There was a draft around on non-traditional responses[1] some time ago > that would provide building blocks from which a server could send > follow-up blocks in an unsolicited fashion: The second block would be > a message in the style of "This is a 2.05 Content response, which you > would have received as a response had you requested block2 of /path". >=20 > Those messages would not be ack'ed if they are NON, and the client can > selectively request blocks it thinks it missed (but, in such a setup, > would do that after a suitable timeout to not request something that > is already in flight). >=20 > That draft was not followed up on directly, but some of its ideas > wound up in [2] where observe notifications are sent to a multicast > group. In particular, the topic of which tokens would be usable for > unsolicited responses to unicast addresses has not received the > discussion it'd probably need. >=20 > Kind regards > Christian >=20 > [1]: https://tools.ietf.org/html/draft-bormann-core-responses-00 > [2]: https://tools.ietf.org/html/draft-tiloca-core-observe-multicast- > notifications-02 >=20 >=20 > -- > The detailed semantics of CoAP methods are "almost, but not entirely > unlike" [HHGTTG] those of HTTP methods. > [HHGTTG]: Adams, D., "The Hitchhiker's Guide to the Galaxy", October > 1979. > -- Shelby, et al., Internet-Draft Constrained Application Protocol > (CoAP) From nobody Tue Apr 7 09:48:55 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D23F3A0EAD; Tue, 7 Apr 2020 09:48:52 -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, HTML_MESSAGE=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 o_2UQ5pdboFX; Tue, 7 Apr 2020 09:48:50 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079F73A0EAA; Tue, 7 Apr 2020 09:48:50 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 48xYJc5S0Lz7tqZ; Tue, 7 Apr 2020 18:48:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586278128; bh=PFNUr/DLCWdsL/Urbz4cLj2KnwQxYJyt+osuaCuzje4=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=l9oVm/gviZKxWmAWKIChS+lh2m1AQjb0qs7NWCgSDoMscvIbr4RSQL2xmExJmq+ap u02XEpjvg60KtkJcUCBOnwbU/KWkbTmQZoXueJ0u+X2znQ2r6pYKduttW+SoboBpq7 uuj0Fb+x8zacyAxKRu0dzNyMl15ta5OCJVuGxBKylLFDihunLTDOjTFEMDaRkEd57o VKMWp/2uRgwqmoDTEOKpK3PWEnLckkq2ADG//CHGWOIhNk9kJnzyAOvCOtWIPorTXJ XRTCfyAVLPe+EqEgiZDRsnVb4Z1Xeh3E0IeoXSBX3Ge6VrK3XXNMGMLD0OSjEAOhW6 gqm/Wq0jq1New== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 48xYJc4GM2z1xpK; Tue, 7 Apr 2020 18:48:48 +0200 (CEST) From: To: Jim Schaad , "core@ietf.org" CC: 'Jon Shallow' , "dots@ietf.org" Thread-Topic: [core] Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AQHWDPxoTyAJ7vdgrkKV3NX2lQCcxw== Date: Tue, 7 Apr 2020 16:48:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303149082D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <049201d60cef$d1299a50$737ccef0$@augustcellars.com> In-Reply-To: <049201d60cef$d1299a50$737ccef0$@augustcellars.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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303149082DOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 16:48:52 -0000 --_000_787AE7BB302AE849A7480A190F8B93303149082DOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jim, That can be policy based at the client side + some signal to the server. For our DOTS application, clients indicate to servers that they are (not) w= illing to receive all the content (below an excerpt of our spec): DOTS clients that are interested to receive pre- or ongoing mitigation telemetry (pre-or-ongoing-mitigation) information from a DOTS server (Section 8.2) MUST set 'server-originated-telemetry' to 'true'. And In order to signal telemetry data in a mitigation efficacy update, it is RECOMMENDED that the DOTS client has already established a DOTS telemetry setup session with the server in 'idle' time. Clients can filter out data they are interested in (Uri-Query), e.g.,. Header: GET (Code=3D0.01) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=3D12332" Uri-Query: "target-alias=3Dhttps1" Observe: 0 If not filter is included, all the content has to be returned to the client= : Header: GET (Code=3D0.01) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "tm" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "tmid=3D123" Observe: 0 Figure 34: GET to Subscribe to Telemetry Asynchronous Notifications for a Specific 'tmid' What is missing for us is a "BLOCK2"-Like option to send all fragments with= out waiting for a GET + retrieval of missing fragments (if any). Cheers, Med De : Jim Schaad [mailto:ietf@augustcellars.com] Envoy=E9 : mardi 7 avril 2020 17:19 =C0 : BOUCADAIR Mohamed TGI/OLN; core@ietf.org Cc : 'Jon Shallow'; dots@ietf.org Objet : RE: [core] Large asynchronous notifications under DDoS: New BLOCK O= ption? I do not believe that there is anything today that says the observer is req= uired to do a GET to receive the next fragment in the event that it does no= t care about what it says. The question that sprints to mind is how shoul= d the server/client decide that it does or does not want to retrieve the en= tire content? Jim From: core On Behalf Of mohamed.boucadair@orange.co= m Sent: Tuesday, April 7, 2020 4:11 AM To: core@ietf.org Cc: Jon Shallow (supjps-ietf@jpshallow.com) ; do= ts@ietf.org Subject: [core] Large asynchronous notifications under DDoS: New BLOCK Opti= on? Hi all, We are using Observe to receive notifications during attack events. These n= otifications are set as NON messages for reasons specific to DDoS condition= s. With DDoS telemetry information included (see draft-ietf-dots-telemetry), a= notification may not fit one single message. The use of BLOCK2 is not conv= enient during attack times. A full description of the issue is described he= re: https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4/ We are considering some mechanisms to solve this issue. One of them is to d= efine a new BLOCK option (similar to BLOCK2) that does not require the obse= rver to send a GET to receive the next fragment. The server will send all t= he fragments. The observer will follow a SACK-like approach to request retr= ansmission of missing fragments. Please let us know whether you think this is a generic issue that should be= solved at the CoAP or not. Suggestions are welcome. Thank you. Cheers, Jon & Med --_000_787AE7BB302AE849A7480A190F8B93303149082DOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 

That can be policy based at the client side + some signal= to the server.

 

For our DOTS application, clients indicate to servers that th= ey are (not) willing to receive all the content (below an excerpt of our sp= ec):

 

   DOTS clients that are interested to receive p= re- or ongoing mitigation

   telemetry (pre-or-ongoing-mitigation) informa= tion from a DOTS server

   (Section 8.2) MUST set 'server-orig= inated-telemetry' to 'true'.

 

And

 

   In order to signal telemetry data in a mitigation efficac=
y update, it
   is RECOMMENDED that the DOTS client has already establish=
ed a DOTS
   telemetry setup session with the server in 'idle' time.

 

 

Clients can filter out data they are interested in (Uri-Query= ), e.g.,.

 

   Header: GET (Code=3D0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "mitigate"
   Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw"<=
/o:p>
   Uri-Path: "mid=3D12332"
   Uri-Query: "target-alias=3Dhttps1&=
quot;
   Observe: 0

 

If not filter is included, all the content has to be returned= to the client:

 

   Header: GET (Code=3D0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw"<=
/o:p>
   Uri-Path: "tmid=3D123"
   Observe: 0
 
    Figure 34: GET to Subscribe to Telemetry Asynchrono=
us Notifications
           &nbs=
p;            &=
nbsp;  for a Specific 'tmid'

 

What is missing for us is a “BLOCK2”-Like option = to send all fragments without waiting for a GET + retrieval of missing = fragments (if any).

 

Cheers,

Med

 

De : Jim Schaad [mailto:ietf@augustcellars.com]
Envoy=E9 : mardi 7 avril 2020 17:19
=C0 : BOUCADAIR Mohamed TGI/OLN; core@ietf.org
Cc : 'Jon Shallow'; dots@ietf.org
Objet : RE: [core] Large asynchronous notifications under DDoS:= New BLOCK Option?

 

I do not believe that there is anything today that s= ays the observer is required to do a GET to receive the next fragment in th= e event that it does not care about what it says.   The question = that sprints to mind is how should the server/client decide that it does or does not want to retrieve the entire content?<= /o:p>

 

Jim

 

 

From: core <core-bounces@ietf.org> O= n Behalf Of mohamed.boucadair@orange.com
Sent: Tuesday, April 7, 2020 4:11 AM
To: core@ietf.org
Cc: Jon Shallow (supjps-ietf@jpshallow.com) <supjps-ietf@jpshallo= w.com>; dots@ietf.org
Subject: [core] Large asynchronous notifications under DDoS: New BLO= CK Option?

 

Hi all,

 

= We are using Observe to receive notifications during attack events. These n= otifications are set as NON messages for reasons specific to DDoS condition= s.

=  

= With DDoS telemetry information included (see draft-ietf-dots-telemetry), a= notification may not fit one single message. The use of BLOCK2 is not conv= enient during attack times. A full description of the issue is described here: https://mailarch= ive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4/

=  

= We are considering some mechanisms to solve this issue. One of them is to d= efine a new BLOCK option (similar to BLOCK2) that does not require the obse= rver to send a GET to receive the next fragment. The server will send all the fragments. The observer will follow a SACK-li= ke approach to request retransmission of missing fragments.

=  

= Please let us know whether you think this is a generic issue that should be= solved at the CoAP or not. Suggestions are welcome.

=  

= Thank you.

=  

= Cheers,

= Jon & Med

--_000_787AE7BB302AE849A7480A190F8B93303149082DOPEXCAUBMA2corp_-- From nobody Tue Apr 7 09:50:18 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083043A0EC1; Tue, 7 Apr 2020 09:50:12 -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, FREEMAIL_FROM=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 ohPWqocywtQi; Tue, 7 Apr 2020 09:50:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1A23A0EBD; Tue, 7 Apr 2020 09:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586278203; bh=ILiRS55BpU55sdLJLxrv12R+4F2XOmjFKm8b0WuGy30=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=cSVbzKT/1/U2duaPQaZFKgrY2UV3uR90khbT88YgB2zhFU5D1tSUVpsnmw89o/a8l DciqxlP3TC15UONSMsvovC9dfiiJUHf8U2IRd7gNQylsOXkyTsLTISuzp9qeInevJt no3EBKzLhxWA4IS8aB4UDd44s44sD8lJammM49eI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([88.65.144.250]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MD9X9-1jUtpa1skj-0099n6; Tue, 07 Apr 2020 18:50:03 +0200 To: mohamed.boucadair@orange.com, "core@ietf.org" Cc: "Jon Shallow (supjps-ietf@jpshallow.com)" , "dots@ietf.org" References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Achim Kraus Message-ID: <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> Date: Tue, 7 Apr 2020 18:50:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:mPFjpV4HB6bc1Em4PJbRRTBjDTwakg/BFkx3yMW1Tb7ObxrRM/g HmTpNZzdIPeiBg08PJQZKkaUzFS1BGcEXxu1wRnZrSzzswwmYCs6KIjQxDD3ToIJE1yqZfq Vk732vhUmidCsMubMvdY9hU8UffYggX6zXKHppp+GvSgbXm/B7FKnYdb7g8Q3Sqsc/HnR94 HiHyjNROn8BmV3Iis5gGw== X-UI-Out-Filterresults: notjunk:1;V03:K0:zO8W3e4ORhY=:P0GBs1ZNtHBgbPxHDHFXIW 1ri3/7nfeqEgPFbmzGAwJUAcSgh7d4Eleqkhz1wBY8zs7vgVKCBTkxPwwCMMZnVM0xzP8k70a QUJu1SeDhCSysIgT/RUsG3asUFkMLV38Bobq7E7Ff7qznCLfvuEeYtdbivmxWKbqG6GR2UgPM 7KNsd0xa4gBi+8+V3aWMn5k47RadhrMGDeIQnXJfazn9fKp8jDml/VaCrbB1cHLvOqW51jviN 5yp8bwyudzA10C9ih/MysARe0Oa488X04zFkTn9AONK3VcqDqYOdLFpOjyVDR/kZ5uF+1mSA1 AfBKxhqYZ4N+NMvkDM0qMCuDR+kFRrAtrObr1HcnPGMFYV7mP4Bnppjl+zv9PSDn8M+gvQMrF zNohcEZYUb/snx15HnJm3HR0sR/VZ4J701vSwvcNPxyTkRQvrJGW3gAGWnvh8zN9fOx1dg5WA AthQDxc/sFCYJWdzNKgIxGNI/0Tt7OinBU4XahogVZlHqDC7elmQoAy3+qiTqu2GkSbWXz3Qt r24oXy51WtE9fl8lGjO4lmwGAC6aGm043k4gUGRQPf3IwbV600wKDVQDOmBK38YLFV4lDO79s TqEcqlevJOc1mFW0nJqEA/4xhVcXUZHK9YIfM/gFKdbmPTsxsRADXzfCacfKepHZoiV3BWQUK L2yjLh+u74tmiv598hVIcbVGMM6WbxLu82F8DwETZXAweXu3q/RvfXjFOa5SvSyFrjrsxnwqy BqITQz+jSCCvhDI1papz653ya20781w8aTE9yZXEC08CP8SKQLy1fjZ6VjvBOfCYIa5gqvm/4 3a6bUSrvrOJqH66vnEGCs+6w9t+gbug7jBOk1egIY4pEpNUhMOq8A8kyoUW/c6fMnMSf5Q+rO dX4cm4a+7trisIS9dKO3Mc0kwGJYKBY6WEDRwCWgGyI16BdlqXI2i5updMvVgkbKoF0jsixwO yreURufRCTotWLwzt3TTNQDspfC1l35dtjFZrzY8dkNjEZwXl7n28mFSbunAJZD7v6nlaCSbW 4/hLojUCGJkgNVM90L8WXO1HZELpIEgNq1fxdFo+okiP5ew+KBFbYXnvYurogchw/PsKVjrxm Rvk6J0YAabSJCXaxjbpbzN9evF39yQHIWK+x7TYWYUENW00+NJygIuWWjJUuyPGIExXVYh6OP GdkcByP1fsSNsL0L2Sjv7AwF5D5Dz87XHtQTOYG3NMjXIHIEyywFbOxAqyAmuzesNzL3GosT3 5rPgEBOfETYWktdys Archived-At: Subject: Re: [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 16:50:12 -0000 Hi Med, I think, not all assumption and requirements are clear to everyone. I guess, your mission is to send a couple of "block" messages, but without getting requested for the next-blocks, because the node is under attack and already receiving too much. Therefore the SACK will be used a little later as "cleanup"/"collect lefts". My first idea about that was, that sending the "block-flush" just creates the next attack. But, if you sure, that this doesn't happen, then such an approach may help in that special situation. I'm not sure, if you assume, that in the most cases all blocks will make it to the destination when sending them. That may also depend on the assumed number of blocks. If it's not assumed, that all block will be received, your payload should be encoded in a way, that you could decode the received blocks, even if some blocks are missing. If that number is not too large, maybe a "blockwise with NSTART-X" will also do it. Especially if DTLS is used, it may be possible to concat the "ACK/next blocks" into one package (with multiple records). AFAIK, that would require changes in implementations, which optimizes the deduplication base on a strict sequence of blocks, but the difference should be not too large. best regards Achim Am 07.04.20 um 13:11 schrieb mohamed.boucadair@orange.com: > Hi all, > > We are using Observe to receive notifications during attack events. > These notifications are set as NON messages for reasons specific to DDoS > conditions. > > With DDoS telemetry information included (see > draft-ietf-dots-telemetry), a notification may not fit one single > message. The use of BLOCK2 is not convenient during attack times. A full > description of the issue is described here: > https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4/ > > We are considering some mechanisms to solve this issue. One of them is > to define a new BLOCK option (similar to BLOCK2) that does not require > the observer to send a GET to receive the next fragment. The server will > send all the fragments. The observer will follow a SACK-like approach to > request retransmission of missing fragments. > > Please let us know whether you think this is a generic issue that should > be solved at the CoAP or not. Suggestions are welcome. > > Thank you. > > Cheers, > > Jon & Med > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Tue Apr 7 10:41:39 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8403A09D4; Tue, 7 Apr 2020 10:41:35 -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, 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 ugjAWRvEyuTn; Tue, 7 Apr 2020 10:41:33 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619B03A09C5; Tue, 7 Apr 2020 10:41:33 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 48xZTR44GRz8slB; Tue, 7 Apr 2020 19:41:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586281291; bh=NnTKUNempGvh7z/MhbD9tS/0qCskKu2X5UPkotvZgIs=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=eVz/KFEf+d5yBtYUdHD6YO7v7GeZCGd3D9iRFkQwmtxD4/JczoFhSaRPj9RbTLg6d uYOGLMFXC+YdeCx7hKGlEH8p3TKYb8xlG8v6EVTzIGZ/Of6i/5PT60IVyNOC8jMK7R 4sMkHQ4zKTpvDUS0zGtU/n7KLpcj2O9HMTx2/GrF4BHAx7QkxGrqt50tk33tmBJi8G hyLOvgV/8/r6+42ajV47bmplmmeZGJZcCMlwqhjLvJ7lDjbWW6Xwk7QLmvgo9ijljo +aoj8jsLbLn2WDRYs2UKB41DXnuSBqxQQ5OMofGBAYGazyev18ZNk2yeTY2XCsIz5P Q55Dj+CgaqYtQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 48xZTR2nvfzCqkn; Tue, 7 Apr 2020 19:41:31 +0200 (CEST) From: To: Achim Kraus , "core@ietf.org" CC: "Jon Shallow (supjps-ietf@jpshallow.com)" , "dots@ietf.org" Thread-Topic: [core] Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AQHWDQPFc2Cf8aWOkUeEiB2evm8ivQ== Date: Tue, 7 Apr 2020 17:41:30 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> In-Reply-To: <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 17:41:35 -0000 Hi Achim, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Achim Kraus [mailto:achimkraus@gmx.net] > Envoy=E9=A0: mardi 7 avril 2020 18:50 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; core@ietf.org > Cc=A0: Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org > Objet=A0: Re: [core] Large asynchronous notifications under DDoS: New > BLOCK Option? >=20 > Hi Med, >=20 > I think, not all assumption and requirements are clear to everyone. >=20 [Med] We are using CoAP for signaling DDoS attacks and for seeking help fro= m a DDoS mitigator. The mitigation signal itself is compact as we do have a= requirement that the signal channel survive under extreme DDoS conditions.= We do have a mechanism to maintain the signal alive, to detect when it is = lost and then to recover asap.=20 We are now designing an extension to the base signaling that allows to shar= e knowledge of attacks for better coordination and efficient mitigation. To= that aim, we need to signal DDoS telemetry data between our DOTS agents (C= oAP endpoints). =20 > I guess, your mission is to send a couple of "block" messages, but > without getting requested for the next-blocks, because the node is > under > attack and already receiving too much. Therefore the SACK will be used > a > little later as "cleanup"/"collect lefts". [Med] Yes. =20 >=20 > My first idea about that was, that sending the "block-flush" just > creates the next attack. But, if you sure, that this doesn't happen, > then such an approach may help in that special situation. [Med] Yes.=20 >=20 > I'm not sure, if you assume, that in the most cases all blocks will > make > it to the destination when sending them. That may also depend on the > assumed number of blocks. If it's not assumed, that all block will be > received, your payload should be encoded in a way, that you could > decode > the received blocks, even if some blocks are missing. [Med] This is will be nice to have. This might be managed at the applicatio= n (DOTS) level but there are some challenges as well (make sure that the cr= afted data will fit a single DTLS packet). >=20 > If that number is not too large, maybe a "blockwise with NSTART-X" > will > also do it. Especially if DTLS is used, it may be possible to concat > the > "ACK/next blocks" into one package (with multiple records). AFAIK, > that > would require changes in implementations, which optimizes the > deduplication base on a strict sequence of blocks, but the difference > should be not too large. >=20 > best regards > Achim >=20 >=20 > Am 07.04.20 um 13:11 schrieb mohamed.boucadair@orange.com: > > Hi all, > > > > We are using Observe to receive notifications during attack events. > > These notifications are set as NON messages for reasons specific to > DDoS > > conditions. > > > > With DDoS telemetry information included (see > > draft-ietf-dots-telemetry), a notification may not fit one single > > message. The use of BLOCK2 is not convenient during attack times. A > full > > description of the issue is described here: > > > https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4 > / > > > > We are considering some mechanisms to solve this issue. One of them > is > > to define a new BLOCK option (similar to BLOCK2) that does not > require > > the observer to send a GET to receive the next fragment. The server > will > > send all the fragments. The observer will follow a SACK-like > approach to > > request retransmission of missing fragments. > > > > Please let us know whether you think this is a generic issue that > should > > be solved at the CoAP or not. Suggestions are welcome. > > > > Thank you. > > > > Cheers, > > > > Jon & Med > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > From nobody Tue Apr 7 10:58:50 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCE53A1BD6; Tue, 7 Apr 2020 10:58:44 -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 OC99_BrR1nyk; Tue, 7 Apr 2020 10:58:42 -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 8AB6A3A0B1B; Tue, 7 Apr 2020 10:56:20 -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 1jLsSN-0006Sq-8N; Tue, 07 Apr 2020 18:56:15 +0100 From: "Jon Shallow" To: "'Achim Kraus'" , , , References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Tue, 7 Apr 2020 18:56:21 +0100 Message-ID: <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGFUV4cZbdAMYpJNEeLLEh4F2cKcwH1DnpQAK+no82o+kI84A== Content-Language: en-gb Archived-At: Subject: Re: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 17:58:49 -0000 Hi Achim, To add to Med's inline comments, the use case that we are trying to = solve is as follows. We are trying to send telemetry information from a server to a unicast client which has the potential to exceed the size of IP packet (possibly multiple times too large). The environment that this telemetry information is going to be = transmitted in will be where Distributed Denial of Service (DDoS) attacks are taking place and so there is a high chance that network pipes will be running = at or near capacity and hence there is likely to be high packet loss. It is likely that the direction of the telemetry data is the same as that of = the packet loss. This telemetry is an additional tool for passing information about how mitigations of these DDoS attacks are being effective so that decisions = can be taken as to how better to mitigate the DDoS situation. This is = making use of the DDoS Open Threat Signaling protocol (DOTS) described in = RFC8612 with other drafts for components of this protocol in the final stages of becoming RFCs ( https://tools.ietf.org/wg/dots/ ). While not desirable, it is acceptable if the client is unable to receive = the telemetry data (out of band mechanisms such as phone calls can be used = in slow time if needed for tuning against attacks) but we would like to maximize the possibility of the telemetry data getting through. Currently with other data and small amounts of telemetry, the GET = response or Observe data can safely be sent off from the server and the client = may or may not get it as we are using NON-confirmable. PUT (which has small amounts of data) and DELETE are also sent as NON-confirmable - and the client handles things if there is not seen a 2.XX etc. response to the PUT/DELETE. This issue is when the data is too large to fit into a single packet - = we currently use the CoAP BLOCK2 option which works fine under normal = traffic conditions, but relies on the client synchronously requesting the next = block of data. We currently are doing this as NON-confirmable so a loss of a block of data causes the transfer to stall with the need to do garbage collection at a later point in time ion the server. Using CONfirmable causes everything to slow right down with the lossy network and prevents = the next CON transmission for a long time as NSTART is 1. The data is CBOR based on YANG with the YANG parameters two-way mapped = into integers to give as much CBOR data reduction as possible, so cannot save = any space there. It is theoretically possible to reduce the amount of = telemetry data by only asking for subsets of information as Med has referred to in this email trail. It is possible to solve the issue using IP fragmentation and let the = client re-assemble everything, but this is not ideal in a lossy network and = there is no way to ask for a particular IP fragment to be re-transmitted. If there was a new CoAP option - let's call it NONBLOCK2, which the = server uses to send the all the data packets without waiting for the GET = request of the next block (only difference compared with BLOCK2). If the client = does not see all the blocks after a timeout, it can then request the missing blocks by using one or more of the NONBLOCK2 options in a new GET = request - or just wait until the next GET / Observe response. This may be a way = to move forward if we cannot solve the issue in another way. Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com > Sent: 07 April 2020 18:42 > To: Achim Kraus; core@ietf.org > Cc: Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org > Subject: Re: [Dots] [core] Large asynchronous notifications under = DDoS: > New BLOCK Option? >=20 > Hi Achim, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Achim Kraus [mailto:achimkraus@gmx.net] > > Envoy=E9=A0: mardi 7 avril 2020 18:50 > > =C0=A0: BOUCADAIR Mohamed TGI/OLN; core@ietf.org > > Cc=A0: Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org > > Objet=A0: Re: [core] Large asynchronous notifications under DDoS: = New > > BLOCK Option? > > > > Hi Med, > > > > I think, not all assumption and requirements are clear to everyone. > > >=20 > [Med] We are using CoAP for signaling DDoS attacks and for seeking = help > from a DDoS mitigator. The mitigation signal itself is compact as we = do have > a requirement that the signal channel survive under extreme DDoS > conditions. We do have a mechanism to maintain the signal alive, to = detect > when it is lost and then to recover asap. >=20 > We are now designing an extension to the base signaling that allows to > share knowledge of attacks for better coordination and efficient mitigation. > To that aim, we need to signal DDoS telemetry data between our DOTS > agents (CoAP endpoints). >=20 > > I guess, your mission is to send a couple of "block" messages, but > > without getting requested for the next-blocks, because the node is > > under > > attack and already receiving too much. Therefore the SACK will be = used > > a > > little later as "cleanup"/"collect lefts". >=20 > [Med] Yes. >=20 > > > > My first idea about that was, that sending the "block-flush" just > > creates the next attack. But, if you sure, that this doesn't happen, > > then such an approach may help in that special situation. >=20 > [Med] Yes. >=20 > > > > I'm not sure, if you assume, that in the most cases all blocks will > > make > > it to the destination when sending them. That may also depend on the > > assumed number of blocks. If it's not assumed, that all block will = be > > received, your payload should be encoded in a way, that you could > > decode > > the received blocks, even if some blocks are missing. >=20 > [Med] This is will be nice to have. This might be managed at the application > (DOTS) level but there are some challenges as well (make sure that the > crafted data will fit a single DTLS packet). >=20 > > > > If that number is not too large, maybe a "blockwise with NSTART-X" > > will > > also do it. Especially if DTLS is used, it may be possible to concat > > the > > "ACK/next blocks" into one package (with multiple records). AFAIK, > > that > > would require changes in implementations, which optimizes the > > deduplication base on a strict sequence of blocks, but the = difference > > should be not too large. > > > > best regards > > Achim > > > > > > Am 07.04.20 um 13:11 schrieb mohamed.boucadair@orange.com: > > > Hi all, > > > > > > We are using Observe to receive notifications during attack = events. > > > These notifications are set as NON messages for reasons specific = to > > DDoS > > > conditions. > > > > > > With DDoS telemetry information included (see > > > draft-ietf-dots-telemetry), a notification may not fit one single > > > message. The use of BLOCK2 is not convenient during attack times. = A > > full > > > description of the issue is described here: > > > > > > https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsW > eP4 > > / > > > > > > We are considering some mechanisms to solve this issue. One of = them > > is > > > to define a new BLOCK option (similar to BLOCK2) that does not > > require > > > the observer to send a GET to receive the next fragment. The = server > > will > > > send all the fragments. The observer will follow a SACK-like > > approach to > > > request retransmission of missing fragments. > > > > > > Please let us know whether you think this is a generic issue that > > should > > > be solved at the CoAP or not. Suggestions are welcome. > > > > > > Thank you. > > > > > > Cheers, > > > > > > Jon & Med > > > > > > > > > _______________________________________________ > > > core mailing list > > > core@ietf.org > > > https://www.ietf.org/mailman/listinfo/core > > > >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 7 12:04:39 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1433A0770; Tue, 7 Apr 2020 12:04:29 -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, FREEMAIL_FROM=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 cvtIhkSkEgaz; Tue, 7 Apr 2020 12:04:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1393A0EEE; Tue, 7 Apr 2020 12:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586286242; bh=GpXgLsGVG8ZrsqgNB4ishmasepQ84fcJoQLLfKPvv1c=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=WPEqGYii1y+cBhMTBxLo19dG7YlaGY6tReLoVTE2YLPrGt2t1HZZZP8PLx3/6G4P4 wUCHWr4NxLUsmloBTlq9A/HbslXUT352o+Emh1mmAG3LMrvQhkAzCRZ/rc/MPFdMKb Y2vbHvLSBcAVnsUy1xjfjPRBnNN2FzBwE14ZJIKY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([88.65.144.250]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M3DO3-1jIrFM2o9d-003gjp; Tue, 07 Apr 2020 21:04:01 +0200 To: Jon Shallow , mohamed.boucadair@orange.com, core@ietf.org, dots@ietf.org References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> From: Achim Kraus Message-ID: Date: Tue, 7 Apr 2020 21:04:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <019301d60d05$d87fcca0$897f65e0$@jpshallow.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:ReQsGiKjogqOLdcmututzFiDaI6m87yVxp4GLMLZ48fSJG85GKU yFHCwrBzAYjkR4VAdyK7SdrIYJQXxW7sLerNfeg3NM1BWsCmXr+AmaNai99xr10iOmg5j6E mu2B7mTTM1odU5gHnzw1/o6tFjXB5eFdquYutOr/bkeh71CplYTT/hezHhzjs3Lw18nkIgV 34wEig3KzBhuIT/TyCamA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Sh5UeQIoZwE=:///5Wlj0wKbtU1XgVnPAm5 5fzsIQUSEYwVX2fjjUKdHIhkV9gC7x8/ILngyteAMRGl+9eZU70+RTdQf93GOIIZB7yMZB4o3 wY6uc7hI5CaMcpJqwk21iF5zhIFIu+LxI17P5U5RhixVyPppjRt1bm+vgqmhCSONuEEc/QUDl 1HIX/9CNqkq9IjWK7nrnPP6t//I6HjdLANlmlWExUn6GVnc9fgFRFX9JRiNBCA1qpNnov0hLI 3A8aqzCicT3EcMw2kO00EBbH4AQ00iLM+h/DC7ZtDvABsVlJJ3OffKHrpuWd1+Ri5fluuUlbg MIh2Aa4bbakshQ8r7GY/OlWDAhKq5z5viDjHfd7T9uw1z6uqZjShvXZy7KQwhZpc+gdGBxdSx RbrTCOU3akU5wF/cTH3vd4Qtsx6A18m46kP2ztl/P3JD9SMpBk0rj6hKZRZoRKkMO6ufMADr5 AXqDR5WRGE4dN82VKrWilnAzUG/7RWfrLZdv+hOJmoUKxwI/pO3N0hIrx3oFtp4BiSwdlcIcD cqp0AvI/ztBVwEXwTsioZiIO5qzEFPamNvQFMRKfDaph3K+qYVdT9F3TSAsYgn2lWrPW7LD/j oRhWq4XKrSAww3ZXBpkmm3zkKQuzhsqOBltU/wOgp4BN6maskTDMvGdaQGnXUawAtxMLVi1wN bKyYXgwNGy/sgvPjqyocYbNrEQjV/B8HlOcSMAwycNB+MtvrfbIm4ExjHRn5jSXIzw4CZnxMN EHmZeRSTz/V1HigXbQuJtkZi9wT923YkhKbXTGMszQfehT+AIlVuOk+XFrusdll+cYWue0qO7 G1canXuIbZ++/lbVjCiuuYtuCTC0y1ZB7GjJrAzeRvK53v+7U87Nz9dUoUF70zXhz8rUQjREg wGI7OpOoBEIsdBNRTeQeJh+2fXfmiC0jofgYa68P+8tr12lVdhUKUwVM9cJ9NleIq86m5jC3L CvWFZXWZOfeE4D6YE7IjHJPm0qjfrvghUG6jDOz9vVJOwHZxkCOF5Awwri9av+vkcP0MM1yHF tn6otzpnYM3BdIcqBeOtmoi7FZwFuf9iVJAUtX3WhDiVclrTaHysxPF+bA2xCuNkedHzDnPeM 1W0cZPkpRMZSchcX+VVvAkcnHANuYwliCD/SrwUQpRswn/ohu/1gCapsCOAgs9Fx27FPl54zD Xis5ykVb6+L6JPM5sn4tXeRiKxQjk9G0RyiJLkvKKonOTw8fEj+vpq/WAIsUNv4s8rTxQt8Ds lJCQ2hnziteOfXG56 Archived-At: Subject: Re: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 19:04:30 -0000 Hi Jon, I'm still not sure, if such an approach would make sense: - if multiple blocks are required without gaps - the package loss is high =3D> that ends up in not receiving any "large payload" at all. FMPOV, the first thing to ensure is, that the "large payload" gets split into "application blocks", which could be processed even when other application blocks are missing. I would also not assume, that a "in between proxies" will be able to process blockwise resources with gaps. So I'm not sure, why observer/notify is used. If it should be used, (and a proxy will not work,) then you may consider to "misuse" the notifies and send your "application blocks" just in multiple notifies (each application block in one notify, without droping "old" notifies, because they are not old :-) ). In my opinion that would require less changes to existing implementations than introduce a "blockwise without next". In the end, it would be interesting, if such a improvement really pays off. Using some nodes with standard blockwise and others with the new one should show the benefit. It would be great, if you then report your numbers. best regards Achim Am 07.04.20 um 19:56 schrieb Jon Shallow: > Hi Achim, > > To add to Med's inline comments, the use case that we are trying to solv= e is > as follows. > > We are trying to send telemetry information from a server to a unicast > client which has the potential to exceed the size of IP packet (possibly > multiple times too large). > > The environment that this telemetry information is going to be transmitt= ed > in will be where Distributed Denial of Service (DDoS) attacks are taking > place and so there is a high chance that network pipes will be running a= t or > near capacity and hence there is likely to be high packet loss. It is > likely that the direction of the telemetry data is the same as that of t= he > packet loss. > > This telemetry is an additional tool for passing information about how > mitigations of these DDoS attacks are being effective so that decisions = can > be taken as to how better to mitigate the DDoS situation. This is makin= g > use of the DDoS Open Threat Signaling protocol (DOTS) described in RFC86= 12 > with other drafts for components of this protocol in the final stages of > becoming RFCs ( https://tools.ietf.org/wg/dots/ ). > > While not desirable, it is acceptable if the client is unable to receive= the > telemetry data (out of band mechanisms such as phone calls can be used i= n > slow time if needed for tuning against attacks) but we would like to > maximize the possibility of the telemetry data getting through. > > Currently with other data and small amounts of telemetry, the GET respon= se > or Observe data can safely be sent off from the server and the client ma= y or > may not get it as we are using NON-confirmable. PUT (which has small > amounts of data) and DELETE are also sent as NON-confirmable - and the > client handles things if there is not seen a 2.XX etc. response to the > PUT/DELETE. > > This issue is when the data is too large to fit into a single packet - w= e > currently use the CoAP BLOCK2 option which works fine under normal traff= ic > conditions, but relies on the client synchronously requesting the next b= lock > of data. We currently are doing this as NON-confirmable so a loss of a > block of data causes the transfer to stall with the need to do garbage > collection at a later point in time ion the server. Using CONfirmable > causes everything to slow right down with the lossy network and prevents= the > next CON transmission for a long time as NSTART is 1. > > The data is CBOR based on YANG with the YANG parameters two-way mapped i= nto > integers to give as much CBOR data reduction as possible, so cannot save= any > space there. It is theoretically possible to reduce the amount of telem= etry > data by only asking for subsets of information as Med has referred to in > this email trail. > > It is possible to solve the issue using IP fragmentation and let the cli= ent > re-assemble everything, but this is not ideal in a lossy network and the= re > is no way to ask for a particular IP fragment to be re-transmitted. > > If there was a new CoAP option - let's call it NONBLOCK2, which the serv= er > uses to send the all the data packets without waiting for the GET reques= t of > the next block (only difference compared with BLOCK2). If the client do= es > not see all the blocks after a timeout, it can then request the missing > blocks by using one or more of the NONBLOCK2 options in a new GET reques= t - > or just wait until the next GET / Observe response. This may be a way t= o > move forward if we cannot solve the issue in another way. > > Regards > > Jon > >> -----Original Message----- >> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com >> Sent: 07 April 2020 18:42 >> To: Achim Kraus; core@ietf.org >> Cc: Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org >> Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: >> New BLOCK Option? >> >> Hi Achim, >> >> Please see inline. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De=C2=A0: Achim Kraus [mailto:achimkraus@gmx.net] >>> Envoy=C3=A9=C2=A0: mardi 7 avril 2020 18:50 >>> =C3=80=C2=A0: BOUCADAIR Mohamed TGI/OLN; core@ietf.org >>> Cc=C2=A0: Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org >>> Objet=C2=A0: Re: [core] Large asynchronous notifications under DDoS: N= ew >>> BLOCK Option? >>> >>> Hi Med, >>> >>> I think, not all assumption and requirements are clear to everyone. >>> >> >> [Med] We are using CoAP for signaling DDoS attacks and for seeking help >> from a DDoS mitigator. The mitigation signal itself is compact as we do > have >> a requirement that the signal channel survive under extreme DDoS >> conditions. We do have a mechanism to maintain the signal alive, to det= ect >> when it is lost and then to recover asap. >> >> We are now designing an extension to the base signaling that allows to >> share knowledge of attacks for better coordination and efficient > mitigation. >> To that aim, we need to signal DDoS telemetry data between our DOTS >> agents (CoAP endpoints). >> >>> I guess, your mission is to send a couple of "block" messages, but >>> without getting requested for the next-blocks, because the node is >>> under >>> attack and already receiving too much. Therefore the SACK will be used >>> a >>> little later as "cleanup"/"collect lefts". >> >> [Med] Yes. >> >>> >>> My first idea about that was, that sending the "block-flush" just >>> creates the next attack. But, if you sure, that this doesn't happen, >>> then such an approach may help in that special situation. >> >> [Med] Yes. >> >>> >>> I'm not sure, if you assume, that in the most cases all blocks will >>> make >>> it to the destination when sending them. That may also depend on the >>> assumed number of blocks. If it's not assumed, that all block will be >>> received, your payload should be encoded in a way, that you could >>> decode >>> the received blocks, even if some blocks are missing. >> >> [Med] This is will be nice to have. This might be managed at the > application >> (DOTS) level but there are some challenges as well (make sure that the >> crafted data will fit a single DTLS packet). >> >>> >>> If that number is not too large, maybe a "blockwise with NSTART-X" >>> will >>> also do it. Especially if DTLS is used, it may be possible to concat >>> the >>> "ACK/next blocks" into one package (with multiple records). AFAIK, >>> that >>> would require changes in implementations, which optimizes the >>> deduplication base on a strict sequence of blocks, but the difference >>> should be not too large. >>> >>> best regards >>> Achim >>> >>> >>> Am 07.04.20 um 13:11 schrieb mohamed.boucadair@orange.com: >>>> Hi all, >>>> >>>> We are using Observe to receive notifications during attack events. >>>> These notifications are set as NON messages for reasons specific to >>> DDoS >>>> conditions. >>>> >>>> With DDoS telemetry information included (see >>>> draft-ietf-dots-telemetry), a notification may not fit one single >>>> message. The use of BLOCK2 is not convenient during attack times. A >>> full >>>> description of the issue is described here: >>>> >>> >> https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsW >> eP4 >>> / >>>> >>>> We are considering some mechanisms to solve this issue. One of them >>> is >>>> to define a new BLOCK option (similar to BLOCK2) that does not >>> require >>>> the observer to send a GET to receive the next fragment. The server >>> will >>>> send all the fragments. The observer will follow a SACK-like >>> approach to >>>> request retransmission of missing fragments. >>>> >>>> Please let us know whether you think this is a generic issue that >>> should >>>> be solved at the CoAP or not. Suggestions are welcome. >>>> >>>> Thank you. >>>> >>>> Cheers, >>>> >>>> Jon & Med >>>> >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > From nobody Tue Apr 7 12:48:07 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7813A098D; Tue, 7 Apr 2020 12:48: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, MSGID_FROM_MTA_HEADER=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=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBhxkC5DJJ3U; Tue, 7 Apr 2020 12:48:03 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on062e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::62e]) (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 C7D3A3A096E; Tue, 7 Apr 2020 12:48:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ORFcECd+mEv6fJu3dBbZiPXvv2vvPTYiovgKOewt/fVmtn/M4RZOVklAjHLg+77toeYukcQq/7L4weDNUT3t21wwe2vhW1xA5OW6u2ry1NWFQpmiiU67BnOs/jZjelItV/9WVnHr02hGMbbhC9fHF/zWaWdI4JPI4Or+Cc8wagDjCrIy4dN22HlJGQ2UaxCHi7NIecSVV7myaUeV0blZ97e9q7oN+g7l2gC9rPYnGEgqV/6RL2608UqdQpFfSrcv4fd6dHVXS9ADlq8Tzn78IMaAor1+VTNpdiZ1kS8AqZJElsLCA/Nt3CdkC0lpQCjxzrtqW+NXfMRmEW+BivvH6A== 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=tAIMTTc8MpftKPyNhnlzw6zNRbCAgtmJCi9R5wuc+Vo=; b=ID6pDRu/kusCyIvwmuNMawP0Y7i71OOXS6B5Rg5H440eedNcRqzdDXBL6JmrR3yY1ZxnU+nx68ofgTpp55y9RJ2QXD2kkbx2RXOHbe573Oe6ott4uirf+J9Es9AIq40sqEmBBNoTHHwIm0OoYITf9pgJ+Yp16bzcs9XZBPFnNmxtGlrp9qKO919aqiepDKuEW3NAl7xxemdbXJtICQilBmR3R8181Y5hIZj278x5dwlMYqDoX135MVn03YBSgAhwiCUJanb2mLFqUhZ8urFsPNqDrppSuS0IeGmjYlUbgKD40N8HjMD5CAG9FyEEmZ9ULi0LE0RSRbDzQHo8T0VBXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tAIMTTc8MpftKPyNhnlzw6zNRbCAgtmJCi9R5wuc+Vo=; b=NlMCcxlIMPkv5V01rY1D82KlGKUcXve7mwoYJE1h3IVTJVrY/dgVZoCL3fgVJtneYBPUCn5hHtBK8A5KXh44rEWBhNzSPcnT55HbAiww2R4jq3wsrDIlc5NOJPNYwN7/K3nzYDrIo2CyRvvaosheHlXPDS4W0zIuj56dWjJBVDc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (10.186.129.88) by AM0P190MB0770.EURP190.PROD.OUTLOOK.COM (10.186.130.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Tue, 7 Apr 2020 19:48:00 +0000 Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::382f:f91c:26b5:a440]) by AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::382f:f91c:26b5:a440%8]) with mapi id 15.20.2878.021; Tue, 7 Apr 2020 19:47:59 +0000 Date: Tue, 7 Apr 2020 21:47:58 +0200 From: Juergen Schoenwaelder To: Ivaylo Petrov Cc: core , netmod@ietf.org Message-ID: <20200407194758.luxnndxxsuixhzfo@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ivaylo Petrov , core , netmod@ietf.org References: <20200331110237.zbo3zw74xlccur3w@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: FR2P281CA0027.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::14) To AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:196::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (2001:638:709:5::7) by FR2P281CA0027.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16 via Frontend Transport; Tue, 7 Apr 2020 19:47:59 +0000 X-Originating-IP: [2001:638:709:5::7] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9ba87a87-4f01-4105-9326-08d7db2c936c X-MS-TrafficTypeDiagnostic: AM0P190MB0770: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 036614DD9C X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0707.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(39850400004)(136003)(376002)(396003)(366004)(346002)(6486002)(52116002)(66946007)(6496006)(66476007)(786003)(81156014)(66556008)(8676002)(2906002)(3450700001)(316002)(8936002)(3716004)(1076003)(81166006)(86362001)(186003)(478600001)(4326008)(6916009)(16526019)(5660300002); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: AnGCq2bgIVEMmvQmIUS3S90IDadL8izRVcq+cJg+vM7jSQw129NV8eF14sSperWrztJ0GM5ODyvrtJpYAyo9+jpHskixusO9sYq5XZg5D2qsru1HxKpsxXRJRHxzTUgEsXSZP5RzyXAoOmkVsbalMMNS80ZfNnbgf1ipVAfaQYRuqw/KYAJERqaum4F2NLoKV1loMl9bZGzgE2fF1UMWRZ8q5PPHsHdyAjMerFyKIyyyJWH+Rg9Jstkt5IjjFuqwW4NtMZxz611nr1/IkGGgFvVBweoJTATPG3lsy0SYQFg3m/JDXoVqAi047SvjaGSlI/hN3V/Phl6uMxGGwWDRBg/atLl1kJ88G53b5qiD5MQ8Gzqi7NMOwXlYr0F8jGlW0ypErca3H71+IiDIsLqzEbUZV5Qnaumwo6nWH5w59mxjQQADcE1k1812WnwImMzMjpfUCmIrjRkn1JIETvkLsrtGffRYlRYuHWRbs/RfqMMEPbdyhMhc6qZA7eLPRcPeyQmiOGpoxdCb8HQUTMQS5w== X-MS-Exchange-AntiSpam-MessageData: gm+kFDoNSwzlUPB5n8Pq3n1VWw28Nle0qw/W5AyBFXVOImb/LSwpKwYXvq8CtSWbLotvCJCuowKUI4/AjuIaj8EoXalnvZJQBphEnCIhBs4xQZvg6YIy0/DFVWFVOUvIuzEF7pU4tOMUaKEnRGpFe5P+29Zs8o1r4gSuz4DzqB8= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 9ba87a87-4f01-4105-9326-08d7db2c936c X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2020 19:47:59.6177 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: EmGtbNluDXub7tZM393mQovH6HHox9i9KkmdBfySFnCBvyuRLH2HSXpCcbbyn3KIfrUcfP4DzYZPz0HDzpK37ZvFw0Yq0ahoNu747Hzyj58= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0770 Archived-At: Subject: Re: [core] js review of draft-ietf-core-yang-cbor-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: Tue, 07 Apr 2020 19:48:06 -0000 Dear Ivaylo, thanks for your item-by-item response. I will cut things down to the few items I felt I still want to comment on (everything else I consider resolved). On Tue, Apr 07, 2020 at 03:35:37PM +0200, Ivaylo Petrov wrote: > > - Is there a reason why SID terminology is not imported from the SID > > specification? Is the reason to avoid a dependency? But then, can > > this dependency really be avoided? I reviewed the SID document first > > because I thought knowing what SIDs are is essential to understand > > this document... > > > > [IP]: This decision has been made before my personal involvement with this > document. I will let the other authors correct me if I am mistaken, but my > understanding is that while it is a good candidate, we did not necessarily > want to mandate the use of the SID draft in order to use the yang-cbor > draft. If the implementers want to have another way of deriving meaning for > the SIDs, that is fine. I will have to verify if the interoperability in > this case was a concern and how it was supposed to be handled. For me, the question is whether this ID defines SIDs and the other ID details how they are managed or this ID imports the definition of SIDs from the other document, which also details how they are managed. Right now, it seem something in between, i.e., it is not clear what the dependencies between these specifications is. > > - To summarize the last few comments, I propose to import 'item' and > > 'SID' from the SID document, to not define 'child' and 'parent' > > (following RFC 7950), and so the only term to defined here is > > 'delta'. But see above concerning the relationship to the SID > > document; it is not clear to me what the goals and intentions are in > > terms of intended document dependencies. > > > > [IP]: I believe that my previous points provide the relevant answers, but do > not hesitate to let us know if you have more concerns about any of your > remarks. Your solution kind of works for me. Note that here is one usage of 'collection' left in section 4.4. > - I do not understand this statement: > > > > Application payloads carrying a value serialized using the rules > > defined by this specification (e.g. CoAP Content-Format) SHOULD > > include the identifier (e.g. SID, namespace qualified name, > > instance-identifier) of this value. > > > > What is "the identifier of this value"? I am not getting what > > is being conveyed here. > > > [IP]: I rewrote this as > > When schema node are serialized using the rules defined by this > specification as part of an application payload, the payload SHOULD include > information that would allow a stateless way to identify each node, such as > the SID number associated with each node, SID delta from another SID in the > application payload, the namespace qualified name or the > instance-identifier. > > Please let us know if that is more clear. This is better, but I am still not sure what exactly this SHOULD is about. The SIDs in the payload are assumed to be unique and so are names and paths. So what is the requirement for an 'application payload' that uses this serialization format? (nit: first noun should be plural) > - SIDs other than [I-D.ietf-core-sid]? > > > > [...] If SIDs are to be used, the present specification is > > used in conjunction with a specification defining this management. > > One example for such a specification is [I-D.ietf-core-sid]. > > > > This seems to indicate that there can be other kinds of SIDs or SIDs > > managed differently. Why is this? The SID I-D claims the entire > > number space, so how would a different 'specification defining the > > management of SIDs' ever work? Why not be specific that the usage of > > SIDs depends on [I-D.ietf-core-sid]? See my earlier comments about > > the unclear dependency relationship between this specification and > > the SID specification. > > > > [IP]: My understanding is that indeed there is the presumption that other > implementations that map YANG item identifiers to unsigned numbers could > exist in the future. If this is the case, I am not aware how one could > interoperate (I would guess based on the content format), but I will let my > coauthors comment on that. Such a different mapping would most likely have to use separate SID allocations, i.e., a part of the number space may be managed differently but the resulting number is still a SID. (Of course, the whole idea sounds pretty scary in terms of interoperability.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 7 13:01:10 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116183A0A5D; Tue, 7 Apr 2020 13: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 rGlDRCejN5Ck; Tue, 7 Apr 2020 13:01:05 -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 DE2FB3A1051; Tue, 7 Apr 2020 13:01:04 -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 1jLuP8-0006XG-8E; Tue, 07 Apr 2020 21:01:02 +0100 From: "Jon Shallow" To: "'Achim Kraus'" , , , References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> In-Reply-To: Date: Tue, 7 Apr 2020 21:01:08 +0100 Message-ID: <01ad01d60d17$470b9a80$d522cf80$@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: AQGFUV4cZbdAMYpJNEeLLEh4F2cKcwH1DnpQAK+no80CR9JpmAF0lygWqNx+MCA= Content-Language: en-gb Archived-At: Subject: Re: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 20:01:08 -0000 Hi Achim, It is good to get this feedback. Please see inline Jon1> Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Achim Kraus > Sent: 07 April 2020 20:04 > To: Jon Shallow; mohamed.boucadair@orange.com; core@ietf.org; > dots@ietf.org > Subject: Re: [Dots] [core] Large asynchronous notifications under = DDoS: > New BLOCK Option? >=20 > Hi Jon, >=20 > I'm still not sure, if such an approach would make sense: > - if multiple blocks are required without gaps > - the package loss is high > =3D> that ends up in not receiving any "large payload" at all. Jon> The packet loss should be transitory in that if the DDoS Mitigation = is effective and reduces the rate of the DDoS Attack through the pipe = normal (certainly DOTS) service is resumed. DOTS needs to be able to = continue with limiting working with high packet loss as "PUT new = mitigation request" are still likely to get through. >=20 > FMPOV, the first thing to ensure is, that the "large payload" gets = split > into "application blocks", which could be processed even when other > application blocks are missing. Jon> We are also trying to do this as well, but it is not that = straightforward. >=20 > I would also not assume, that a "in between proxies" will be able to > process blockwise resources with gaps. Jon> In the DOTS case, we have the concept of DOTS gateways where the = DOTS CoAP server and DOTS CoAP client stacks are fully terminated making = things easier here. This is a good point though and needs to be worked = through. > So I'm not sure, why > observer/notify is used. If it should be used, (and a proxy will not > work,)=20 Jon> I don't quite follow why a proxy will not work unless you are = referring to blockwise resources with gaps. > then you may consider to "misuse" the notifies and send your > "application blocks" just in multiple notifies (each application block > in one notify, without droping "old" notifies, because they are not = old > :-) ). In my opinion that would require less changes to existing > implementations than introduce a "blockwise without next". Jon> It may make for less changes, but I was expecting the NONBLOCK2 = option to be handled within the application rather than at the CoAP = layer. In the DOTS case, server enhanced Telemetry information sending = has to be explicitly enabled by the client so existing implementations = will not get broken. >=20 > In the end, it would be interesting, if such a improvement really pays > off. Using some nodes with standard blockwise and others with the new > one should show the benefit. It would be great, if you then report = your > numbers. Jon> I will see what I can come up with here. A good suggestion. It = may take a while though as I have only partially got the DOTS telemetry = draft extensions coded. ~Jon >=20 > best regards > Achim >=20 > Am 07.04.20 um 19:56 schrieb Jon Shallow: > > Hi Achim, > > > > To add to Med's inline comments, the use case that we are trying to = solve > is > > as follows. > > > > We are trying to send telemetry information from a server to a = unicast > > client which has the potential to exceed the size of IP packet = (possibly > > multiple times too large). > > > > The environment that this telemetry information is going to be > transmitted > > in will be where Distributed Denial of Service (DDoS) attacks are = taking > > place and so there is a high chance that network pipes will be = running at or > > near capacity and hence there is likely to be high packet loss. It = is > > likely that the direction of the telemetry data is the same as that = of the > > packet loss. > > > > This telemetry is an additional tool for passing information about = how > > mitigations of these DDoS attacks are being effective so that = decisions can > > be taken as to how better to mitigate the DDoS situation. This is = making > > use of the DDoS Open Threat Signaling protocol (DOTS) described in > RFC8612 > > with other drafts for components of this protocol in the final = stages of > > becoming RFCs ( https://tools.ietf.org/wg/dots/ ). > > > > While not desirable, it is acceptable if the client is unable to = receive the > > telemetry data (out of band mechanisms such as phone calls can be = used > in > > slow time if needed for tuning against attacks) but we would like to > > maximize the possibility of the telemetry data getting through. > > > > Currently with other data and small amounts of telemetry, the GET > response > > or Observe data can safely be sent off from the server and the = client may > or > > may not get it as we are using NON-confirmable. PUT (which has = small > > amounts of data) and DELETE are also sent as NON-confirmable - and = the > > client handles things if there is not seen a 2.XX etc. response to = the > > PUT/DELETE. > > > > This issue is when the data is too large to fit into a single packet = - we > > currently use the CoAP BLOCK2 option which works fine under normal > traffic > > conditions, but relies on the client synchronously requesting the = next > block > > of data. We currently are doing this as NON-confirmable so a loss = of a > > block of data causes the transfer to stall with the need to do = garbage > > collection at a later point in time ion the server. Using = CONfirmable > > causes everything to slow right down with the lossy network and = prevents > the > > next CON transmission for a long time as NSTART is 1. > > > > The data is CBOR based on YANG with the YANG parameters two-way > mapped into > > integers to give as much CBOR data reduction as possible, so cannot = save > any > > space there. It is theoretically possible to reduce the amount of = telemetry > > data by only asking for subsets of information as Med has referred = to in > > this email trail. > > > > It is possible to solve the issue using IP fragmentation and let the = client > > re-assemble everything, but this is not ideal in a lossy network and = there > > is no way to ask for a particular IP fragment to be re-transmitted. > > > > If there was a new CoAP option - let's call it NONBLOCK2, which the = server > > uses to send the all the data packets without waiting for the GET = request > of > > the next block (only difference compared with BLOCK2). If the = client does > > not see all the blocks after a timeout, it can then request the = missing > > blocks by using one or more of the NONBLOCK2 options in a new GET > request - > > or just wait until the next GET / Observe response. This may be a = way to > > move forward if we cannot solve the issue in another way. > > > > Regards > > > > Jon > > > >> -----Original Message----- > >> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > >> Sent: 07 April 2020 18:42 > >> To: Achim Kraus; core@ietf.org > >> Cc: Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org > >> Subject: Re: [Dots] [core] Large asynchronous notifications under = DDoS: > >> New BLOCK Option? > >> > >> Hi Achim, > >> > >> Please see inline. > >> > >> Cheers, > >> Med > >> > >>> -----Message d'origine----- > >>> De : Achim Kraus [mailto:achimkraus@gmx.net] > >>> Envoy=C3=A9 : mardi 7 avril 2020 18:50 > >>> =C3=80 : BOUCADAIR Mohamed TGI/OLN; core@ietf.org > >>> Cc : Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org > >>> Objet : Re: [core] Large asynchronous notifications under DDoS: = New > >>> BLOCK Option? > >>> > >>> Hi Med, > >>> > >>> I think, not all assumption and requirements are clear to = everyone. > >>> > >> > >> [Med] We are using CoAP for signaling DDoS attacks and for seeking = help > >> from a DDoS mitigator. The mitigation signal itself is compact as = we do > > have > >> a requirement that the signal channel survive under extreme DDoS > >> conditions. We do have a mechanism to maintain the signal alive, to > detect > >> when it is lost and then to recover asap. > >> > >> We are now designing an extension to the base signaling that allows = to > >> share knowledge of attacks for better coordination and efficient > > mitigation. > >> To that aim, we need to signal DDoS telemetry data between our DOTS > >> agents (CoAP endpoints). > >> > >>> I guess, your mission is to send a couple of "block" messages, but > >>> without getting requested for the next-blocks, because the node is > >>> under > >>> attack and already receiving too much. Therefore the SACK will be = used > >>> a > >>> little later as "cleanup"/"collect lefts". > >> > >> [Med] Yes. > >> > >>> > >>> My first idea about that was, that sending the "block-flush" just > >>> creates the next attack. But, if you sure, that this doesn't = happen, > >>> then such an approach may help in that special situation. > >> > >> [Med] Yes. > >> > >>> > >>> I'm not sure, if you assume, that in the most cases all blocks = will > >>> make > >>> it to the destination when sending them. That may also depend on = the > >>> assumed number of blocks. If it's not assumed, that all block will = be > >>> received, your payload should be encoded in a way, that you could > >>> decode > >>> the received blocks, even if some blocks are missing. > >> > >> [Med] This is will be nice to have. This might be managed at the > > application > >> (DOTS) level but there are some challenges as well (make sure that = the > >> crafted data will fit a single DTLS packet). > >> > >>> > >>> If that number is not too large, maybe a "blockwise with NSTART-X" > >>> will > >>> also do it. Especially if DTLS is used, it may be possible to = concat > >>> the > >>> "ACK/next blocks" into one package (with multiple records). AFAIK, > >>> that > >>> would require changes in implementations, which optimizes the > >>> deduplication base on a strict sequence of blocks, but the = difference > >>> should be not too large. > >>> > >>> best regards > >>> Achim > >>> > >>> > >>> Am 07.04.20 um 13:11 schrieb mohamed.boucadair@orange.com: > >>>> Hi all, > >>>> > >>>> We are using Observe to receive notifications during attack = events. > >>>> These notifications are set as NON messages for reasons specific = to > >>> DDoS > >>>> conditions. > >>>> > >>>> With DDoS telemetry information included (see > >>>> draft-ietf-dots-telemetry), a notification may not fit one single > >>>> message. The use of BLOCK2 is not convenient during attack times. = A > >>> full > >>>> description of the issue is described here: > >>>> > >>> > >> > https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsW > >> eP4 > >>> / > >>>> > >>>> We are considering some mechanisms to solve this issue. One of = them > >>> is > >>>> to define a new BLOCK option (similar to BLOCK2) that does not > >>> require > >>>> the observer to send a GET to receive the next fragment. The = server > >>> will > >>>> send all the fragments. The observer will follow a SACK-like > >>> approach to > >>>> request retransmission of missing fragments. > >>>> > >>>> Please let us know whether you think this is a generic issue that > >>> should > >>>> be solved at the CoAP or not. Suggestions are welcome. > >>>> > >>>> Thank you. > >>>> > >>>> Cheers, > >>>> > >>>> Jon & Med > >>>> > >>>> > >>>> _______________________________________________ > >>>> core mailing list > >>>> core@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/core > >>>> > >> > >> _______________________________________________ > >> Dots mailing list > >> Dots@ietf.org > >> https://www.ietf.org/mailman/listinfo/dots > > >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 7 13:27:04 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9633A12A3; Tue, 7 Apr 2020 13: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, FREEMAIL_FROM=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 xdiyqLMEhSb1; Tue, 7 Apr 2020 13:26:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 B76D23A10D8; Tue, 7 Apr 2020 13:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586291192; bh=foLXtyc5U0FmFQMbdhDKJXKZLzxum8wuCIbBBA32raY=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=PHgQ4y3ugUHgwptbMRSuyoKKkGj6rFdufdP/tHyWT1IAYDyvPncAmk+mQqD8LSTQr PzSkmU8zMKfyLZqYDM3AC2vDjYN5PLqBmnzB/qamTdQvWwmPlDfFlxsAovhin2sC6S jtLGpMyPzZ1GhfCYfA//LB3wLbmkMMCq5gZdhE/M= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([88.65.144.250]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MmULx-1ivcOP12Ez-00iPXV; Tue, 07 Apr 2020 22:26:32 +0200 To: Jon Shallow , mohamed.boucadair@orange.com, core@ietf.org, dots@ietf.org References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <01ad01d60d17$470b9a80$d522cf80$@jpshallow.com> From: Achim Kraus Message-ID: <0955fc85-8d5a-f1c4-b618-f692b27ad9d3@gmx.net> Date: Tue, 7 Apr 2020 22:26:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <01ad01d60d17$470b9a80$d522cf80$@jpshallow.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:2LR+gFhIuGDPk3+BeJ/s3k6ORVCJWTz/XVqBbFceMC4Dhvvafey Vgd4w0sMbcvy2LaNCDjxcEYni1p6zzuHxONlQ+STPiuFX+TZZEJ+qFsqivHBlpXu9CQUF9n 91pye3EVdNsDKfSS0RrMmvuX/4+bHpCv/U7g82KhFVrGAYHi4zNp7iEnrLbeJKrpd7C9gXN dZttWQnAv3nVdYTcR6txg== X-UI-Out-Filterresults: notjunk:1;V03:K0:bujNJ5+2aWo=:hFeTR5zmW0kWg1zFQK/ov+ yxZQmS6lNaxQRwIct+UnfQnbIkD4psB0n9XeuvQxC7Xs+lvarryZ7039OCVYKkhBk3ErzPlbN 6oV++WpFvzqPKcTgNAfXsF9HkhJhoIM5iHh1cdPt6hcr7T7HDKSwDBYGMWXBPAQZD73zH2FVw C8UjXOV3br8ApO0nd0UssyfqO1l5Zw8sKakHMvrA+tSnZe/CnUChkgEC+bRjEuxAm6PylxmtJ wU1/O19GjhhxGSyeSp09+N+75EjM9tfYHK42DVXR0ivkq2RXEiBOSQ73ZEli09dQSjQGJaxFY hNAbD9cjc0O9goBdrPiENdJaibPxjJ64KBqadRL1yg2CEHy8ycSLSxASXINkYZz0pM5K/Ny1Y K47pMpqF5/91cla2MTvEeCPv+FbZLjwFvHgAcKlhHluwdzQXAzQcUQiIzY5FmVoP0NmOJu2w+ hbh7XWIJUptGwV0E2s0j8rC2ao/SHuEDUjUFltzxuwFZeocPOrAkmbSeHL1cS5lczm6VcOdJw 75Lyj3bnALYDXAjHvwGJ/3UReJzrrH0Eajl75DvEciMgKfss1wFcxFAcHYBbrM/dkT9d/62zA JF0chakMMbn1IQ1L8r6DcHH0Cz5Y7KbPprGhzBSfwVEgZvBbtiuXBE6PxwP8HllI8xh9q0kNP sh2ErgXpLL1R2rloA8if77HZPGh3CnpSsMfUEEv4ieB9HEcIDsmr1A6N1iXxUxhPtxwaVvbwb c9TC9LQVPc0Lo35I7FNKPgkCEVUapdzc/7K+uDu5yme8NEelUx7u+hz4/Z9GoxOQt8GPp/6YP m9CI7EUqeixJMUBjFG7+5dYbrZb80YpqlRriRHmUaO7RcF6/DQ0RLmHDsURdfE7pNKk8MVrIz o9zoPN6TfEKskAnz9hf7eHJI9OuhwkLRe6Q1B6EZoM9GvhmfNvXobtkJZ7dFpssE0QwfTK3wq CBNqHgSRkg5ZX1pSV59fcgylKCZ0vKfooYOTiSskoGCCq3sBBik1MLzoOm1tKzcWBJd9Y5Fwm FgABRt2svbZ35END2/lqXfaGBvXoFv1tQzLA6D2zvidvZTrCaTUF5f3ejoOKwLIGTcag9AzJc PtJ74AjmOWn3FNiRspxJJaK9vC4WjGq2aeA6hiwdFDzxkKoRUoEzlAX9qrjZDkS5qYmkDCYYl BxcRJnxZBJYRk2pHv1+sugBefNwOu3llRi/3jgEWFn2ZAGxZdg+BnEiqHJdPu7oVK9YgqKuZC IibOp29R8zly/ZIVX Archived-At: Subject: Re: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 20:26:57 -0000 Hi Jon, Jon> I don't quite follow why a proxy will not work unless you are referring to blockwise resources with gaps. Yes, the point is the blockwise with gaps. Jon> It may make for less changes, but I was expecting the NONBLOCK2 option to be handled within the application rather than at the CoAP layer. In the DOTS case, server enhanced Telemetry information sending has to be explicitly enabled by the client so existing implementations will not get broken. If it's not a modification of the coap-layer, which kind of messages are you plan to use? Multiple NON-responses (wouldn't that be notifies)? Or NON requests with "no-response"? best regards Achim Am 07.04.20 um 22:01 schrieb Jon Shallow: > Hi Achim, > > It is good to get this feedback. Please see inline Jon1> > > Regards > > Jon > >> -----Original Message----- >> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Achim Kraus >> Sent: 07 April 2020 20:04 >> To: Jon Shallow; mohamed.boucadair@orange.com; core@ietf.org; >> dots@ietf.org >> Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: >> New BLOCK Option? >> >> Hi Jon, >> >> I'm still not sure, if such an approach would make sense: >> - if multiple blocks are required without gaps >> - the package loss is high >> =3D> that ends up in not receiving any "large payload" at all. > > Jon> The packet loss should be transitory in that if the DDoS Mitigation= is effective and reduces the rate of the DDoS Attack through the pipe nor= mal (certainly DOTS) service is resumed. DOTS needs to be able to continu= e with limiting working with high packet loss as "PUT new mitigation reque= st" are still likely to get through. > >> >> FMPOV, the first thing to ensure is, that the "large payload" gets spli= t >> into "application blocks", which could be processed even when other >> application blocks are missing. > > Jon> We are also trying to do this as well, but it is not that straightf= orward. >> >> I would also not assume, that a "in between proxies" will be able to >> process blockwise resources with gaps. > > Jon> In the DOTS case, we have the concept of DOTS gateways where the DO= TS CoAP server and DOTS CoAP client stacks are fully terminated making thi= ngs easier here. This is a good point though and needs to be worked throu= gh. > >> So I'm not sure, why >> observer/notify is used. If it should be used, (and a proxy will not >> work,) > > Jon> I don't quite follow why a proxy will not work unless you are refer= ring to blockwise resources with gaps. > >> then you may consider to "misuse" the notifies and send your >> "application blocks" just in multiple notifies (each application block >> in one notify, without droping "old" notifies, because they are not old >> :-) ). In my opinion that would require less changes to existing >> implementations than introduce a "blockwise without next". > > Jon> It may make for less changes, but I was expecting the NONBLOCK2 opt= ion to be handled within the application rather than at the CoAP layer. I= n the DOTS case, server enhanced Telemetry information sending has to be e= xplicitly enabled by the client so existing implementations will not get b= roken. > >> >> In the end, it would be interesting, if such a improvement really pays >> off. Using some nodes with standard blockwise and others with the new >> one should show the benefit. It would be great, if you then report your >> numbers. > > Jon> I will see what I can come up with here. A good suggestion. It ma= y take a while though as I have only partially got the DOTS telemetry draf= t extensions coded. > ~Jon > >> >> best regards >> Achim >> >> Am 07.04.20 um 19:56 schrieb Jon Shallow: >>> Hi Achim, >>> >>> To add to Med's inline comments, the use case that we are trying to so= lve >> is >>> as follows. >>> >>> We are trying to send telemetry information from a server to a unicast >>> client which has the potential to exceed the size of IP packet (possib= ly >>> multiple times too large). >>> >>> The environment that this telemetry information is going to be >> transmitted >>> in will be where Distributed Denial of Service (DDoS) attacks are taki= ng >>> place and so there is a high chance that network pipes will be running= at or >>> near capacity and hence there is likely to be high packet loss. It is >>> likely that the direction of the telemetry data is the same as that of= the >>> packet loss. >>> >>> This telemetry is an additional tool for passing information about how >>> mitigations of these DDoS attacks are being effective so that decision= s can >>> be taken as to how better to mitigate the DDoS situation. This is mak= ing >>> use of the DDoS Open Threat Signaling protocol (DOTS) described in >> RFC8612 >>> with other drafts for components of this protocol in the final stages = of >>> becoming RFCs ( https://tools.ietf.org/wg/dots/ ). >>> >>> While not desirable, it is acceptable if the client is unable to recei= ve the >>> telemetry data (out of band mechanisms such as phone calls can be used >> in >>> slow time if needed for tuning against attacks) but we would like to >>> maximize the possibility of the telemetry data getting through. >>> >>> Currently with other data and small amounts of telemetry, the GET >> response >>> or Observe data can safely be sent off from the server and the client = may >> or >>> may not get it as we are using NON-confirmable. PUT (which has small >>> amounts of data) and DELETE are also sent as NON-confirmable - and the >>> client handles things if there is not seen a 2.XX etc. response to the >>> PUT/DELETE. >>> >>> This issue is when the data is too large to fit into a single packet -= we >>> currently use the CoAP BLOCK2 option which works fine under normal >> traffic >>> conditions, but relies on the client synchronously requesting the next >> block >>> of data. We currently are doing this as NON-confirmable so a loss of = a >>> block of data causes the transfer to stall with the need to do garbage >>> collection at a later point in time ion the server. Using CONfirmable >>> causes everything to slow right down with the lossy network and preven= ts >> the >>> next CON transmission for a long time as NSTART is 1. >>> >>> The data is CBOR based on YANG with the YANG parameters two-way >> mapped into >>> integers to give as much CBOR data reduction as possible, so cannot sa= ve >> any >>> space there. It is theoretically possible to reduce the amount of tel= emetry >>> data by only asking for subsets of information as Med has referred to = in >>> this email trail. >>> >>> It is possible to solve the issue using IP fragmentation and let the c= lient >>> re-assemble everything, but this is not ideal in a lossy network and t= here >>> is no way to ask for a particular IP fragment to be re-transmitted. >>> >>> If there was a new CoAP option - let's call it NONBLOCK2, which the se= rver >>> uses to send the all the data packets without waiting for the GET requ= est >> of >>> the next block (only difference compared with BLOCK2). If the client = does >>> not see all the blocks after a timeout, it can then request the missin= g >>> blocks by using one or more of the NONBLOCK2 options in a new GET >> request - >>> or just wait until the next GET / Observe response. This may be a way= to >>> move forward if we cannot solve the issue in another way. >>> >>> Regards >>> >>> Jon >>> >>>> -----Original Message----- >>>> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of >>> mohamed.boucadair@orange.com >>>> Sent: 07 April 2020 18:42 >>>> To: Achim Kraus; core@ietf.org >>>> Cc: Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org >>>> Subject: Re: [Dots] [core] Large asynchronous notifications under DDo= S: >>>> New BLOCK Option? >>>> >>>> Hi Achim, >>>> >>>> Please see inline. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Achim Kraus [mailto:achimkraus@gmx.net] >>>>> Envoy=C3=A9 : mardi 7 avril 2020 18:50 >>>>> =C3=80 : BOUCADAIR Mohamed TGI/OLN; core@ietf.org >>>>> Cc : Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org >>>>> Objet : Re: [core] Large asynchronous notifications under DDoS: New >>>>> BLOCK Option? >>>>> >>>>> Hi Med, >>>>> >>>>> I think, not all assumption and requirements are clear to everyone. >>>>> >>>> >>>> [Med] We are using CoAP for signaling DDoS attacks and for seeking he= lp >>>> from a DDoS mitigator. The mitigation signal itself is compact as we = do >>> have >>>> a requirement that the signal channel survive under extreme DDoS >>>> conditions. We do have a mechanism to maintain the signal alive, to >> detect >>>> when it is lost and then to recover asap. >>>> >>>> We are now designing an extension to the base signaling that allows t= o >>>> share knowledge of attacks for better coordination and efficient >>> mitigation. >>>> To that aim, we need to signal DDoS telemetry data between our DOTS >>>> agents (CoAP endpoints). >>>> >>>>> I guess, your mission is to send a couple of "block" messages, but >>>>> without getting requested for the next-blocks, because the node is >>>>> under >>>>> attack and already receiving too much. Therefore the SACK will be us= ed >>>>> a >>>>> little later as "cleanup"/"collect lefts". >>>> >>>> [Med] Yes. >>>> >>>>> >>>>> My first idea about that was, that sending the "block-flush" just >>>>> creates the next attack. But, if you sure, that this doesn't happen, >>>>> then such an approach may help in that special situation. >>>> >>>> [Med] Yes. >>>> >>>>> >>>>> I'm not sure, if you assume, that in the most cases all blocks will >>>>> make >>>>> it to the destination when sending them. That may also depend on the >>>>> assumed number of blocks. If it's not assumed, that all block will b= e >>>>> received, your payload should be encoded in a way, that you could >>>>> decode >>>>> the received blocks, even if some blocks are missing. >>>> >>>> [Med] This is will be nice to have. This might be managed at the >>> application >>>> (DOTS) level but there are some challenges as well (make sure that th= e >>>> crafted data will fit a single DTLS packet). >>>> >>>>> >>>>> If that number is not too large, maybe a "blockwise with NSTART-X" >>>>> will >>>>> also do it. Especially if DTLS is used, it may be possible to concat >>>>> the >>>>> "ACK/next blocks" into one package (with multiple records). AFAIK, >>>>> that >>>>> would require changes in implementations, which optimizes the >>>>> deduplication base on a strict sequence of blocks, but the differenc= e >>>>> should be not too large. >>>>> >>>>> best regards >>>>> Achim >>>>> >>>>> >>>>> Am 07.04.20 um 13:11 schrieb mohamed.boucadair@orange.com: >>>>>> Hi all, >>>>>> >>>>>> We are using Observe to receive notifications during attack events. >>>>>> These notifications are set as NON messages for reasons specific to >>>>> DDoS >>>>>> conditions. >>>>>> >>>>>> With DDoS telemetry information included (see >>>>>> draft-ietf-dots-telemetry), a notification may not fit one single >>>>>> message. The use of BLOCK2 is not convenient during attack times. A >>>>> full >>>>>> description of the issue is described here: >>>>>> >>>>> >>>> >> https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsW >>>> eP4 >>>>> / >>>>>> >>>>>> We are considering some mechanisms to solve this issue. One of them >>>>> is >>>>>> to define a new BLOCK option (similar to BLOCK2) that does not >>>>> require >>>>>> the observer to send a GET to receive the next fragment. The server >>>>> will >>>>>> send all the fragments. The observer will follow a SACK-like >>>>> approach to >>>>>> request retransmission of missing fragments. >>>>>> >>>>>> Please let us know whether you think this is a generic issue that >>>>> should >>>>>> be solved at the CoAP or not. Suggestions are welcome. >>>>>> >>>>>> Thank you. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Jon & Med >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> core mailing list >>>>>> core@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/core >>>>>> >>>> >>>> _______________________________________________ >>>> Dots mailing list >>>> Dots@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dots >>> >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > From nobody Tue Apr 7 13:27:08 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0173A115C; Tue, 7 Apr 2020 13:27:02 -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, 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=r9Ibp/Dq; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=r9Ibp/Dq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_K7xzQVZMoo; Tue, 7 Apr 2020 13:27:00 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20608.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::608]) (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 F0BBB3A112B; Tue, 7 Apr 2020 13:26:52 -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=sCoCo7yW2SE4EwbAakZsl2nNZC8AHni1SVdG5hXv1gQ=; b=r9Ibp/DqGGLw7DkX1HqXdAAeyw+xoDQwhsJeHr8xOu5Vf86hQHMYSb1NIkOo551lRWM6yLO/Y2pAmU8xZQt4kM3z11/YKVC9JWLj2LfBLMIf3qEiuAFPxZBWfmYR00sDY2n8LfflTLZcnDMnR3Q3Zk8Ls/fF3l9X48KE1ADWrPs= Received: from DB6PR0501CA0033.eurprd05.prod.outlook.com (2603:10a6:4:67::19) by DB7PR08MB3324.eurprd08.prod.outlook.com (2603:10a6:5:22::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Tue, 7 Apr 2020 20:26:50 +0000 Received: from DB5EUR03FT043.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:67:cafe::a4) by DB6PR0501CA0033.outlook.office365.com (2603:10a6:4:67::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20 via Frontend Transport; Tue, 7 Apr 2020 20:26:50 +0000 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=bestguesspass 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 DB5EUR03FT043.mail.protection.outlook.com (10.152.20.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Tue, 7 Apr 2020 20:26:49 +0000 Received: ("Tessian outbound 4b84da486446:v50"); Tue, 07 Apr 2020 20:26:49 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 7ea060a37ce5cd76 X-CR-MTA-TID: 64aa7808 Received: from ebf483565ea2.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6BB72EE4-3F5A-4AFA-9437-F55145D6FF72.1; Tue, 07 Apr 2020 20:26:44 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id ebf483565ea2.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 07 Apr 2020 20:26:44 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AYhh7iE/jGsMmE/X7uiSH0pom2pSUTUm8cC1klfzR88WY+5TScWilXtm3jBQKuA4cuk5WO47HnvIQNns/b0K3TYEzR4w231dO1QAGV92C3oj2GVucKExss1ZpWq8WGsvBZ6td9CoyzHCrW1+y3ZBd1g3vI/VYx2rCQGYIxJ57qlPcw2PYud777zOcKJgAwQHcgc3RheJUIL5ygybUvd9znfJqKH6m6SCI4QDGdGdTtHPhORWuXiZ2my8nnOn4/Ybxnzxn5iAoALvDWXyw9HJIkv2DEb15RkKDPoik8f3rdbKS+PaQx4D9HKw7sN1m1cy+3nQG9E6HRD7TVgb3Q2E3A== 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=sCoCo7yW2SE4EwbAakZsl2nNZC8AHni1SVdG5hXv1gQ=; b=TfLX0ORMgMoy+yExyYuNi7+j5HVCsciIVVJRo/6oplRnWhVR7+unbPg7y51J/aSzPSzHZmcMt4eXPXTKbkOboTuGF7+0uIfiOQ21VWKlj6XsrowwbSUKMpMyYHww4pxD4TbgUpuka4m0o/DrTqA71O1sBKl0Qdiedg/mucJyW5AiKbF0nDDFHYD/uWOAU5CduUjnfudABNHtRCKUsnD8qHM7TLTdhAro272OWWTNt07eBw3IOPOBRdzhbq/8DoODwx3EC0EmlW0FlMAaJHJ3NUe5fspEqzV35bibXaityfTxXmWoirgBSX48mEUO5FWrDjj2x2Ip5MHhS0z9TrW5Og== 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=sCoCo7yW2SE4EwbAakZsl2nNZC8AHni1SVdG5hXv1gQ=; b=r9Ibp/DqGGLw7DkX1HqXdAAeyw+xoDQwhsJeHr8xOu5Vf86hQHMYSb1NIkOo551lRWM6yLO/Y2pAmU8xZQt4kM3z11/YKVC9JWLj2LfBLMIf3qEiuAFPxZBWfmYR00sDY2n8LfflTLZcnDMnR3Q3Zk8Ls/fF3l9X48KE1ADWrPs= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB4660.eurprd08.prod.outlook.com (2603:10a6:20b:c1::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Tue, 7 Apr 2020 20:26:41 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f%7]) with mapi id 15.20.2878.022; Tue, 7 Apr 2020 20:26:40 +0000 From: Thomas Fossati To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , Jim Schaad CC: "draft-fossati-core-coap-problem@ietf.org" , "core@ietf.org" , Thomas Fossati Thread-Topic: [core] Review of draft-fossati-core-coap-problem-02 Thread-Index: AQHWDNieE/Li9vLsLUC6YCdEhPVEXKhuLMGA Date: Tue, 7 Apr 2020 20:26:40 +0000 Message-ID: <41D4AA49-192A-478C-9F26-06E1CE5D991E@arm.com> References: <703EAB3E-A9CC-4260-8B52-6690BACFA62C@arm.com> <010b01d6076d$ab36bfd0$01a43f70$@augustcellars.com> <20200407123230.GC2743407@hephaistos.amsuess.com> In-Reply-To: <20200407123230.GC2743407@hephaistos.amsuess.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [217.140.99.251] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: f7eea27f-6f94-4a9e-f6f1-08d7db320061 x-ms-traffictypediagnostic: AM6PR08MB4660:|AM6PR08MB4660:|DB7PR08MB3324: 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-forefront-prvs: 036614DD9C X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(366004)(346002)(396003)(136003)(376002)(8676002)(6506007)(64756008)(66556008)(478600001)(81166006)(8936002)(66446008)(6486002)(66476007)(91956017)(33656002)(4326008)(71200400001)(54906003)(66946007)(81156014)(53546011)(76116006)(86362001)(110136005)(316002)(36756003)(186003)(5660300002)(26005)(2906002)(6512007)(66574012)(2616005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 6KuFiN1cJvlUh8WeooAONEPBlkb3w1fiKwUpKhQDX/0sKWh6awxDE3qY/wsSVMRolo9xPD4VnMERN+CE0n61oWcGCisA0IxwmOHP+hxNsCrNgcZWXfHJ0YkzlZCUqItrcIBPQrh3t2GX9RZ/8OyPONkFKZ7NG0afzRPWwOaFDW8JSlE3LxnH3X2sfQ4RNu+btgNj+M3YRyLZl3PKsFFKJDNmFhPQefHsc85vDzpwHjPBa8KUfuR8whx2JLBAESUAP1g6F+3ZqD9B1b0iKBnZ4txYxscITppkZmkUGyqTvRG2+7JU8C1Fl1pK3I0RViPJ/M3Rdav6zgiNnaJQskU//X8gUfMhDjMMKQC8kGvEaWqzDpOuvn03NeftG1PmOhjDugMuF8JorGFyH/Fi8ysOv9m970QVRQ7MI0mQSkescXLoyK2iNb1qBtF14CICRio6 x-ms-exchange-antispam-messagedata: zgFXWqT7WAZepssmQSF9ndyEly9tXMokpJ3G1JbgEvhmM1eAHR6gE7IXWIz97063+XNs9QAc4qTyQiXvW15Rd7G6HzFwfa9nRn7nsxdrrHOtWFSIkF+bTgcip5FNll93EFeu48EcQNr21gjFnn0q2g== Content-Type: text/plain; charset="utf-8" Content-ID: <9687E23C00EF734D93ACC8C0FFF749B9@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4660 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT043.eop-EUR03.prod.protection.outlook.com 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; SFTY:; SFS:(10009020)(4636009)(396003)(376002)(39860400002)(136003)(346002)(46966005)(316002)(33656002)(5660300002)(36756003)(86362001)(110136005)(8936002)(70586007)(81166006)(54906003)(81156014)(70206006)(66574012)(26005)(8676002)(2906002)(4326008)(6506007)(6512007)(186003)(26826003)(53546011)(356004)(450100002)(47076004)(336012)(478600001)(6486002)(2616005)(82740400003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 82fb3d11-2985-4001-d3d4-08d7db31fb16 X-Forefront-PRVS: 036614DD9C X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: XhyhsI0zvBwt8ijdsmTnlDMFrH7XdyNq2gOP/JuD/todRjkmyzxzg8lfco0RFFiDVgJkdF0PZ3OYtTeHWbs8hsIBQhXd1slotEr4zmKYcL7UNiWFgCJSefHgtHROTH6KvpTcc6zU2bDhAi32Y+ZEZO0tB20GYZLTMIF44voC3ca9NyV6Is3EDauUmeDqlbSOjK6+XeW0Yi1TSGehGA68b65JL3ezKQDYt4xNn9Nkf9bireMwsmWvJt/vY80TZF+DtKZZ7ydYGFqUXP5tL640OG6s16sUaqjl9AWL6nA+TGMy1vLXJG/0FzB7a7q942ij7dbJlPODworIFwUtHs91IjcBTHXgjzxJp6JpVlMoOO31JDIUA46t3vR+ravtyXYJ3qGqJ5NCNGlBLkYHKap5CbGjX5eLyQzWk7FkkMoLH+Ok8AUg9yMiWsu1iUIpGGSYrmUE1NKDnBZTNOALWAc21eLuoWxuRVH/Zxt4T9zMX76pZARg+Jl5NlNu4tcAuJzfq7GJ/aNkc+OreAHmYeaP1g== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2020 20:26:49.7322 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f7eea27f-6f94-4a9e-f6f1-08d7db320061 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-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3324 Archived-At: Subject: Re: [core] Review of draft-fossati-core-coap-problem-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: Tue, 07 Apr 2020 20:27:07 -0000 SGkgQ2hyaXN0aWFuLA0KDQpPbiAwNy8wNC8yMDIwLCAxMzozMiwgIkNocmlzdGlhbiBBbXPDvHNz IiA8Y2hyaXN0aWFuQGFtc3Vlc3MuY29tPiB3cm90ZToNCj4gT24gV2VkLCBBcHIgMDEsIDIwMjAg YXQgMTA6MzY6MTBBTSArMDAwMCwgVGhvbWFzIEZvc3NhdGkgd3JvdGU6DQo+ID4gPiBbSkxTXSBH aXZlbiB0aGF0IEkgd291bGQgd2FudCB0byB0ZXN0IHRoZSBwcm9ibGVtIGluZm8gYmVpbmcNCj4g PiA+IHJldHVybmVkLCBnZXR0aW5nIHVuZXhwZWN0ZWQgZXJyb3JzIHdpdGggaW5mb3JtYXRpb24g aXMgdXNlZnVsIGZvcg0KPiA+ID4gbWUuICBUaGlzIGlzIHRoZSBiYXNpYyBtZXRob2QgdGhhdCBJ IGhhdmUgYmVlbiB1c2luZyBmb3IgbXkgQUNFDQo+ID4gPiBzZXJ2ZXIgd2hlcmUgYSBkaWFnbm9z dGljIHN0cmluZyB3aXRoIHRoZSBwcm9ibGVtIGRldGFpbHMgaXMNCj4gPiA+IHJldHVybmVkLCBi dXQgYSBzdGFjayB0cmFjZSBpcyBpbmNsdWRlZCBpbiB1bmV4cGVjdGVkIGNvbmRpdGlvbnMNCj4g PiA+IChpLmUuIHRoZSBjb2RlIHRocmV3IGFuIGV4Y2VwdGlvbikuDQo+ID4NCj4gPiBJIGFtIGNl cnRhaW5seSBub3Qgb3Bwb3NlZCB0byB0aGF0LiAgSGFwcHkgdG8gY2FsbCBpdCAiZGlhZ25vc3Rp YyI/DQo+DQo+IEFyZSB0aGVzZSBjYXNlcyBub3QgaW5kZXBlbmRlbnQgY2FzZXMgYW55d2F5Pw0K Pg0KPiBJZiB0aGVyZSBpcyBhIGtub3duIGNvbmRpdGlvbiwgaXRzIHByb2JsZW0tZGV0YWlsIGlz IHJldHVybmVkLiBPbg0KPiBleGNlcHRpb25zLCB0aGVyZSBpcyBubyBwcm9ibGVtLWRldGFpbCBi dXQgYSBzdGFjay10cmFjZSAod2l0aG91dCBhDQo+IGNvbnRlbnQgZm9ybWF0KS4NCj4gQnV0IGFz IEkgdW5kZXJzdGFuZCB0aGF0IHVzZSBjYXNlLCB5b3UgZG9uJ3QgbmVlZCBib3RoIHNpbXVsdGFu ZW91c2x5Lg0KDQpJdCBkb2Vzbid0IG5lY2Vzc2FyaWx5IGhhdmUgdG8gYmUgbXV0dWFsbHkgZXhj bHVzaXZlLg0KDQo+IE9mIGNvdXJzZSwgYSBmcmFtZXdvcmsgbWlnaHQgY3JlYXRlIGFuIGVudHJ5 IGZvciAobnM9bXktZnJhbWV3b3JrLA0KPiB0eXBlPTAsIHRpdGxlPSJFeGNlcHRpb24gaW4gcmVz b3VyY2UgaGFuZGxlciIsIHJlc3BvbnNlLWNvZGU9NS4wMCwNCj4gY29hcHAtcm9ibGVtLWRldGFp bHMtZXh0ZW5zaW9uID0gWyogc3RhY2tmcmFtZV0pDQoNClN1cmUsIGFuIGV4dGVuc2lvbiBjb3Vs ZCB3b3JrIGFzIHdlbGwuICBJbiBmYWN0LCBvbmUgdGhpbmcgSSdtIHRyeWluZyB0bw0KYXNzZXNz IGF0bSBpcyB3aGV0aGVyIHdlIGZlZWwgdGhlcmUgYXJlIGdvb2QgcmVhc29ucyB0byBzdWJzdW1l IHRoZQ0KZGlhZ25vc3RpYyBwYXlsb2FkIChvciBhdCBsZWFzdCBvbmUgc3BlY2lmaWMgdXNhZ2Ug cGF0dGVybiAtLSB0aGUgIkFQSQ0KZGV2ZWxvcGVyIidzKSB1bmRlciB0aGUgcHJvYmxlbSBzdHJ1 Y3R1cmUgb3IsIGFzIHlvdSBzdWdnZXN0LCB0aGlzDQpzaG91bGQgYmUgbGVmdCBhcyBhIGRlY2lz aW9uIHRvIGVhY2ggYW5kIGV2ZXJ5IEFQSS4NCg0KSVNUTSB0aGF0IGlmIHdlIHRha2UgSmltJ3Mg YXBwcm9hY2gsIHRoZXJlIGFyZSAoYXQgbGVhc3QpIHR3byBvcHRpb25zOg0KDQoxLiBpZiB0cmFj ZV9lbmFibGVkOiBleHRlbmQgdGhlICJkZXRhaWwiIHN0cmluZyB3aXRoIGRpYWdub3N0aWMgaW5m bzsNCjIuIGlmIHRyYWNlX2VuYWJsZWQ6IGFkZCBkaWFnbm9zdGljIGluZm8gdG8gYSBzZXBhcmF0 ZSBjaGFubmVsLg0KDQpGcm9tIGEgbG9nIGNvbnN1bWVyIHBvaW50IG9mIHZpZXcsIGEgbW9yZSBz dHJ1Y3R1cmVkIGFwcHJvYWNoIChpLmUuLCAyLikNCnNlZW1zIGVhc2llciB0byBpbmdlc3QgJiBw cm9jZXNzLiAgRnJvbSBhIHByb2R1Y2VyIHBlcnNwZWN0aXZlIHRoZSBjb3N0DQppcyB0aGUgc2Ft ZS4gIEZyb20gdGhlIHBvdiBvZiB0aGUgdHJhbnNwb3J0LCAyLiBpbmZsaWN0cyBhIHNsaWdodA0K aW5jcmVhc2UgaW4gYmFuZHdpZHRoIHRvIHN1cHBvcnQgdGhlIGV4dHJhIHN0cnVjdHVyaW5nIGJ1 dCBJJ2QgZXhwZWN0IGl0DQp0byBiZSBkd2FyZmVkIGJ5IHRoZSBkaWFnbm9zdGljIHBheWxvYWQu DQoNCkNoZWVycywgdGhhbmtzIQ0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBv ZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xv c2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBv c2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5r IHlvdS4NCg== From nobody Tue Apr 7 13:55:41 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA533A0FA8; Tue, 7 Apr 2020 13:55:36 -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 oPs3gM_ub51Y; Tue, 7 Apr 2020 13:55:33 -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 4940D3A1279; Tue, 7 Apr 2020 13:55:31 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48xfnF2CHHzyTQ; Tue, 7 Apr 2020 22:55:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <20200407194758.luxnndxxsuixhzfo@anna.jacobs.jacobs-university.de> Date: Tue, 7 Apr 2020 22:55:28 +0200 Cc: Ivaylo Petrov , NetMod WG , core X-Mao-Original-Outgoing-Id: 607985728.761826-987ad46b9786698c380faa14070a030a Content-Transfer-Encoding: quoted-printable Message-Id: <16670AE8-DE0D-4444-9F64-ED6C67654886@tzi.org> References: <20200331110237.zbo3zw74xlccur3w@anna.jacobs.jacobs-university.de> <20200407194758.luxnndxxsuixhzfo@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] js review of draft-ietf-core-yang-cbor-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: Tue, 07 Apr 2020 20:55:36 -0000 On 2020-04-07, at 21:47, Juergen Schoenwaelder = wrote: >=20 > For me, the question is whether this ID defines SIDs and the other ID > details how they are managed or this ID imports the definition of SIDs > from the other document, which also details how they are managed. > Right now, it seem something in between, i.e., it is not clear what > the dependencies between these specifications is. Thank you for that feedback. So I think we need to be a bit more radical/precise: -YANG-CBOR should explain that SIDs are 63-bit unsigned integers and how = the delta encoding in the CBOR map keys works. I.e., define the = concept, but not the number space management. -sid does the latter. The document that defines the media types (comi) gets to bind YANG-CBOR, = for these media types, to the specific SID concept defined in -sid. -YANG-CBOR can still refer to -sid as a preferred way to manage the = number space. But you can implement -YANG-CBOR without understanding -sid, so this is = not a normative reference. Any other document using -YANG-CBOR can refer to -sid as well (or, = exceptionally, to something specific for that usage). Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 7 14:19:06 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6E13A134C; Tue, 7 Apr 2020 14:19:04 -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 rQoX3QQ1bvE0; Tue, 7 Apr 2020 14:19:02 -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 614333A134A; Tue, 7 Apr 2020 14:19:00 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48xgJL5t8lzySC; Tue, 7 Apr 2020 23:18:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Tue, 7 Apr 2020 23:18:58 +0200 Cc: Jon Shallow , mohamed.boucadair@orange.com, core , dots@ietf.org X-Mao-Original-Outgoing-Id: 607987138.268279-c8b953ef6a0c78172142dc3c02ae1b1c Content-Transfer-Encoding: quoted-printable Message-Id: <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> To: Achim Kraus X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 21:19:05 -0000 Hi Achim, On 2020-04-07, at 21:04, Achim Kraus wrote: >=20 > FMPOV, the first thing to ensure is, that the "large payload" gets = split > into "application blocks", which could be processed even when other > application blocks are missing. Indeed, =E2=80=9Capplication layer framing=E2=80=9D comes to mind here; = that is always a good idea if it cannot be ensured that all messages = make it or if it is good to be able to process messages while still = waiting for others. .oOo. I=E2=80=99m trying to understand the very specific network environment = that we are targeting here. Are we assuming packets are way more likely to make it from the server = to the client than the other way around? That indeed would call for additional capabilities that base CoAP does = not have. We also may not really care about congestion control much in a situation = of massive (attacker-induced) congestion (although that might be = misdiagnosed, so some care is still required); which would be another = reason to maybe deviate from base CoAP. I don=E2=80=99t have a design in mind at the moment. It would need to = cater for the fact that sending the other response messages for the = request would be on the initiative of the server. So observe (with non-confirmable responses) is maybe a good model = indeed; what=E2=80=99s missing is some way to ask for gaps. I just resubmitted a draft that we have been discussing for a while in = T2TRG: The Series Transfer Pattern (STP) https://www.ietf.org/id/draft-bormann-t2trg-stp-02.html This has some discussion that may be relevant here, although it does not = address the specific DOTS problem. I think it would be great if = whatever we come up with to solve this problem would also be a step = forward on the larger class of applications needing the series transfer = pattern. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 7 14:47:46 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7E73A08E8; Tue, 7 Apr 2020 14:47:41 -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 inHpQufP9K3d; Tue, 7 Apr 2020 14:47:39 -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 88BAA3A08EA; Tue, 7 Apr 2020 14:47:39 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48xgxP72H4z103C; Tue, 7 Apr 2020 23:47:37 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Tue, 7 Apr 2020 23:47:37 +0200 Cc: Juergen Schoenwaelder , core , netmod@ietf.org X-Mao-Original-Outgoing-Id: 607988857.468165-4e4ed4fbdd2e49242546b03b071d8958 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200331110237.zbo3zw74xlccur3w@anna.jacobs.jacobs-university.de> To: Ivaylo Petrov X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] js review of draft-ietf-core-yang-cbor-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: Tue, 07 Apr 2020 21:47:42 -0000 On 2020-04-07, at 15:35, Ivaylo Petrov wrote: >=20 > - If this work gets approved, will other specifications like > draft-ietf-netmod-yang-data-ext-05.txt be expected to cover CBOR > encoding in addition to XML and JSON? This is more a procedural > question. >=20 > [IP]: =46rom our discussions, I could say that that is desirable, but = not something these drafts can enforce. (Also, for drafts that already = are well-advanced, one would expect a companion draft on a later = timeline instead of the original text-based (JSON/XML) draft.) Right. Are we creating any special hardship for = draft-ietf-netmod-yang-data-ext? Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 7 15:28:14 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEC43A003D; Tue, 7 Apr 2020 15:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_TONAME_EQ_TOLOCAL_SHORT=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6tYwyCzBWCS; Tue, 7 Apr 2020 15:28:10 -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 857943A0030; Tue, 7 Apr 2020 15:28:09 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48xhr63HHzzyT1; Wed, 8 Apr 2020 00:28:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> Date: Wed, 8 Apr 2020 00:28:05 +0200 X-Mao-Original-Outgoing-Id: 607991285.95842-e0f44b69f3e2bfa5dfa950f2c423a116 Content-Transfer-Encoding: quoted-printable Message-Id: References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> To: core , dots@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 07 Apr 2020 22:28:13 -0000 On 2020-04-07, at 23:18, Carsten Bormann wrote: >=20 > The Series Transfer Pattern (STP) > https://www.ietf.org/id/draft-bormann-t2trg-stp-02.html https://www.ietf.org/id/draft-bormann-t2trg-stp-03.html (forgot to process the figures.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 7 23:34:36 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4523A07A8; Tue, 7 Apr 2020 23:34:35 -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, MSGID_FROM_MTA_HEADER=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=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3rQ_m1ilnhN; Tue, 7 Apr 2020 23:34:33 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80075.outbound.protection.outlook.com [40.107.8.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1873D3A07A6; Tue, 7 Apr 2020 23:34:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IGvqUsQjwfjbzwJ9IsJVdnSht259cB2A9gcnqLVSmsEA62WflIzfw0X/XSsw/73kdjwZn3lb0ydvQXNN50MPVcnwX1CdYPCjYhTUg4XHAxSRuoqLgr3gLLlXfkMdzeWpxvJlHbzynvN/KJTGEy/R0TEH2MVpds6bwF9YLA43A2QX9p+PPvB8snr/JZSq8R8u1LgYmq/kVA/TgZz/w6UwKyjjRtc6yzJZGITUhflVvRh/iWLp6Hk7AnIoEmDXQeoQf7NJNDSmwXGPjFzu40Nbj86k9v6FmdGgaVIL63JMTHgelrIM6y9AKXzmZ3FzrkfLENQHNsfUxgBIApcm4MygpA== 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=/IK+ZBW9AsaO2hoCZUYiP0egipPL/RVjIFkWL0V7UHU=; b=oLtIRunvemqNURfyCAl8QGZZ2tRkGf/8E7zo2RhQ/kspShJvIxjd+uAN6Zkpf8C/oelej3ntkoLYytRYUdpCTFqHfFl5WxatpUgZVY/mOpBOdQ0gDLD1aa81fu+7x95oQxhIExtU8WuOvCmL5OcRgCkj+sC+2Lu2MGm19Xj+mcAMKEACnEfCgLiMJsmMtzTgr9h/rbdYWnyjOXmENpRngPXmPTAznznpbVv5kN/itFFcEUcxrcUhdU5Kf2RHBeEkRJxYkHKiVYg0p2+77BgCCei2WLfnruSYzGsIutYbKMvMIc5H7sCy4tqIY3rF/L/RUz/umwMtFmLR2ft9P6O9vQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/IK+ZBW9AsaO2hoCZUYiP0egipPL/RVjIFkWL0V7UHU=; b=pDdo9nH77nPUUUSe9SSYIUBO8M49AmCDx/MS4FEbUqwSx1hngy8dQF6R38MeVuEXPCpcwKvatsz1/0e9gd3L77X8az7D7AFycLyvbiMLpO8NM+vvyZGZYLLyaG+X8JadImMBMVUGLWJIHmcrrNZFAPf44bJRhXGqmngf5huNpi8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (10.186.129.88) by AM0P190MB0626.EURP190.PROD.OUTLOOK.COM (10.186.128.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Wed, 8 Apr 2020 06:34:29 +0000 Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::382f:f91c:26b5:a440]) by AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::382f:f91c:26b5:a440%8]) with mapi id 15.20.2878.021; Wed, 8 Apr 2020 06:34:29 +0000 Date: Wed, 8 Apr 2020 08:34:28 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: Ivaylo Petrov , core , netmod@ietf.org Message-ID: <20200408063428.xqpf47jgqnxtjtxe@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , Ivaylo Petrov , core , netmod@ietf.org References: <20200331110237.zbo3zw74xlccur3w@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AM6P195CA0044.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:87::21) To AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:196::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (2001:638:709:5::7) by AM6P195CA0044.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:87::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Wed, 8 Apr 2020 06:34:29 +0000 X-Originating-IP: [2001:638:709:5::7] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f4d00c53-f904-4a43-decd-08d7db86e40e X-MS-TrafficTypeDiagnostic: AM0P190MB0626: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 0367A50BB1 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0707.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(346002)(366004)(39840400004)(376002)(396003)(136003)(2906002)(16526019)(186003)(6496006)(54906003)(52116002)(6916009)(66476007)(66946007)(81156014)(81166007)(66556008)(5660300002)(8936002)(8676002)(53546011)(6486002)(478600001)(4326008)(1076003)(86362001)(3450700001)(316002)(786003); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MFEk+UGnJrbi4mJ/9K5+1+1aRzWy9CHTYT03eGMggkaXuXK8306LimHJorwbhosWWKx6gtrG7hqI9MpflzM/ew1PuHjyzTf4oF9ZCwtC5tqmZZQdAL5/bp+p6cELNvW6wu8rra6f+tWAXHpOiRMJpRErWm9oVn6D/PmkVmGPpE8niqxCTDdzQQreu0ByYBWbi/+BHsvI859BL7Os/91X2r66770lY0bOaAb0V7HlW4I8VcDMq5kj3f42/pe+tnGBS1brd2+UYn7g7Hf1G1huyMXl4rawErvyWFXcOiJKP14o6FZvktwcQfn4jpP9nbPo7+HhgElWdD1RHn9BnABUnOVAHivXE3Gb3Oorer3Coz0OdxtDJf5izprNCwEmfaa4pjCd9qs8qgtFsjbr8u6xITuWDEHmim6cg+YB/qkbcW/lU4UQ+SeiQfo6R7XaGEnPGo3kvelMULFedPzEbnx0kom0BW055LttVPt4vJgfKecn5VFUodtsWyXVLBpxr3dwVvpZpylURi3UwM7UxoNY2w== X-MS-Exchange-AntiSpam-MessageData: 71R11F0zU7NXtMWtApH1cNi0PWvUfmd9ZGx7B/a70feEWEtwjlQVDG8C24ifO1ntkbUQddwd3KOYWibFe7tRe1HBgvLRoBmKZiYHYzHWUHqQ0aosdPHZ+ymixQ+wiRpbaAhjoY3BYLGwo15YcrDrwt/udcs2O3p/r/peZ9EGE9A= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: f4d00c53-f904-4a43-decd-08d7db86e40e X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2020 06:34:29.5928 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: bhS5Q6WgWp0muhWTohXQmlsRnulRdYSkaGJlOBiCaYnz0LDe0H/0ZZyF/L9+onruxKIi5zMkdroW2L/iPpdCSJ26WZFmyMtSsj1UjhwXYAQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0626 Archived-At: Subject: Re: [core] js review of draft-ietf-core-yang-cbor-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, 08 Apr 2020 06:34:35 -0000 On Tue, Apr 07, 2020 at 11:47:37PM +0200, Carsten Bormann wrote: > On 2020-04-07, at 15:35, Ivaylo Petrov wrote: > > > > - If this work gets approved, will other specifications like > > draft-ietf-netmod-yang-data-ext-05.txt be expected to cover CBOR > > encoding in addition to XML and JSON? This is more a procedural > > question. > > > > [IP]: From our discussions, I could say that that is desirable, but not something these drafts can enforce. (Also, for drafts that already are well-advanced, one would expect a companion draft on a later timeline instead of the original text-based (JSON/XML) draft.) > > Right. Are we creating any special hardship for draft-ietf-netmod-yang-data-ext? > This is a procedural question (i.e., nothing the ID will regulate) and ideally the WGs involved come to some common understanding how we handle things in the future. One option is that NETMOD agrees to take care of CBOR as a third encoding in the future like it does take care of XML and JSON today. What I like to avoid is that YANG evolves and the various encodings start to work with different subsets of YANG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 7 23:57:51 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11EB3A08C4; Tue, 7 Apr 2020 23:57:46 -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, MSGID_FROM_MTA_HEADER=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=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajdnIa9YrSrn; Tue, 7 Apr 2020 23:57:42 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on060b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::60b]) (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 3256A3A08C3; Tue, 7 Apr 2020 23:57:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bHT5xHSURC/s6ozgLgTKltPQRhEzqEBJx4Px5vbAmlE3SG41K1wS+cmdVvo5ILHFMV+zDHHGjeNVdsFYxmmoAWj5wiPSoO3DnB34VSgbTrvGaWz3Zg9aXP2xM2ftk7ECMr/1tOTx6z1pG5Y2flpYOZY2QTZyZOqDx683oYKv3ZQv9FO0SqKYvjfL8iTaD+gVIpp9rbj/uZ5ah53zDTYOsYRfbX9i8jmpPS/ayATM/Rc4gRqTYy5v4Em2ttiRT4rgkJqLh+/NRYXPcY7dsMwc2vkpZgidj1MbIOOC/qkrXDmGMuWOgFPrZ9yWvB6Jd1ORbvf7vA1C2U2EtqlJO48BhA== 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=z8XgdfU2qK3ubILSWkubFh815/rz2RYBg6m472ZQdVo=; b=H7ds9R/vQe6Xia/DxkuT7dKly+QAH8C9sq7trWaZ1+Yb9IczBy2E1TOipU+eb9uCYwLSCvR5KvoWAmMxV9/1SNjSbQhK/cxY5N+URSg0sTwmwoa5xuhGJy3xuvnp4NY+HqBpUCufnwgStWFIaS7ho64Vc/IL54uArOIB9W2k7L4IYDUs+r+s01u4YyzNiv7CQ32LQRsxXg3AYi4XrFKpTv+WB2GKA8D94dTkVaPv24DCYZavgE3Pg0fIm5JTB0Vr0zXERji/vRFn1bwUrz/quEa1O4qKYcon3OAW5XwQgGidqDWGFS9DWJbQpR83xKJXk254vQe0WqwblHoBX+q0Zw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z8XgdfU2qK3ubILSWkubFh815/rz2RYBg6m472ZQdVo=; b=j/cMLTBu+b8pjA1/nTdwOpLBMlMj/pqHS4Kr/j0WWAxEm8cx1VHZhIcT2kUFO7px6hMjqkn0bfR3WjGqNpheDJzrtLkm/gLt9G9Rv3HlZDL6XuWHNDCysePhk948V8h/okfnE3wUeNaDVkxTWzRXMP3nC5YWoN8ClFrfy0c0eBY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (10.186.129.88) by AM0P190MB0722.EURP190.PROD.OUTLOOK.COM (10.186.129.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Wed, 8 Apr 2020 06:57:39 +0000 Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::382f:f91c:26b5:a440]) by AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::382f:f91c:26b5:a440%8]) with mapi id 15.20.2878.021; Wed, 8 Apr 2020 06:57:38 +0000 Date: Wed, 8 Apr 2020 08:57:38 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: Ivaylo Petrov , NetMod WG , core Message-ID: <20200408065738.l7jnht536vxzacse@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , Ivaylo Petrov , NetMod WG , core References: <20200331110237.zbo3zw74xlccur3w@anna.jacobs.jacobs-university.de> <20200407194758.luxnndxxsuixhzfo@anna.jacobs.jacobs-university.de> <16670AE8-DE0D-4444-9F64-ED6C67654886@tzi.org> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16670AE8-DE0D-4444-9F64-ED6C67654886@tzi.org> X-ClientProxiedBy: AM6P193CA0093.EURP193.PROD.OUTLOOK.COM (2603:10a6:209:88::34) To AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:196::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (2001:638:709:5::7) by AM6P193CA0093.EURP193.PROD.OUTLOOK.COM (2603:10a6:209:88::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19 via Frontend Transport; Wed, 8 Apr 2020 06:57:38 +0000 X-Originating-IP: [2001:638:709:5::7] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e3ed2f1f-2e99-4ef2-9c60-08d7db8a202b X-MS-TrafficTypeDiagnostic: AM0P190MB0722: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0367A50BB1 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0707.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(366004)(52116002)(8676002)(66946007)(186003)(53546011)(66556008)(1076003)(6486002)(66476007)(4326008)(6496006)(8936002)(86362001)(5660300002)(16526019)(54906003)(81156014)(498600001)(6916009)(3450700001)(2906002)(81166007); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Ictc9m4lNmHzh5J2GakvcazivFZp5Ts14GYEqxTMqdOpNSjgefdaaO7IDv0pCFV+Fxd2BHFL72CFGC2EJKYrQsJQdwR9/itN7HfEoyTYiKrsJT/3uWXi0f+Y0RDZyLX7tEReqBDp0XDsSqkUNFl08gkhbutykmsof8YE5ZWefEAA/W5bPASkWaBfX97Dz/Lg27J/BpIXWX1n9xlp5C7sbC8xrlqUhI7Rl45IZj57uzlxFfP0QSEXX2ws9+p4o3CFedPulO988NBt8I5laXuG1mn58/aZpu5GlZf9ixaEYGHTDVBFMi+tvPj3npKtqsbUgP56KvwBsd3Hvs4jIBQRYwiZ7b69WFHR1mixhH1QV65K21oiWM+qydgawszI7noKET8d7pR1TRC//Q4fxa6vqr+S+vNo7nmo6UkdHOBJAz5P0Jv9E0TTaE5wI9/CktwA8kKq6Lp4zod7Y7KkT4bX2kGERKKyN+eRAjRVyaXuN1CMyUqTQZOzoYShNTusxw6cnLNMCGxi4pBUlVATaYi7nQ== X-MS-Exchange-AntiSpam-MessageData: JT3kKuIbtpLtA7m4W4962BM+ylNZdateiWzZNtcRdnFAp5NWCdF2hN7+HM697gGQiFC0nRBS0qfHPF+BNKf50oSqAjydZs39SUJyOpIr9R69hP0HOFLhXmknadizYIPXwr1EjS+XfMcP5YXCbPYntX9HCPGW3qdnJWfBhkLP4pM= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: e3ed2f1f-2e99-4ef2-9c60-08d7db8a202b X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2020 06:57:38.9088 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ceZ8oovsTRuSqT1kWu9zF5JMgJSwNlj53RTdUe+ZYM1jr9t0iV2/R/wH2tZs4MSZFl3cSqa49V5oR8LNJOyY/0pshvMJhxqla/5cUudLYWY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0722 Archived-At: Subject: Re: [core] js review of draft-ietf-core-yang-cbor-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, 08 Apr 2020 06:57:47 -0000 On Tue, Apr 07, 2020 at 10:55:28PM +0200, Carsten Bormann wrote: > On 2020-04-07, at 21:47, Juergen Schoenwaelder wrote: > > > > For me, the question is whether this ID defines SIDs and the other ID > > details how they are managed or this ID imports the definition of SIDs > > from the other document, which also details how they are managed. > > Right now, it seem something in between, i.e., it is not clear what > > the dependencies between these specifications is. > > Thank you for that feedback. > > So I think we need to be a bit more radical/precise: > > -YANG-CBOR should explain that SIDs are 63-bit unsigned integers and how the delta encoding in the CBOR map keys works. I.e., define the concept, but not the number space management. > > -sid does the latter. > > The document that defines the media types (comi) gets to bind YANG-CBOR, for these media types, to the specific SID concept defined in -sid. > > -YANG-CBOR can still refer to -sid as a preferred way to manage the number space. > But you can implement -YANG-CBOR without understanding -sid, so this is not a normative reference. > Any other document using -YANG-CBOR can refer to -sid as well (or, exceptionally, to something specific for that usage). > This makes sense, but I prefer to have the media types defined in YANG-CBOR. If I use CBOR with RESTCONF, I love to depend on YANG-CBOR only and not in addition on COMI just for the media type definition. The serialization format is defined in YANG-CBOR, hence it makes sense to me to define the corresponding media-type(s) there as well. Note, I did not manage to review COMI due to a lack of time. So I am digging into the type definitions now. RESTCONF (RFC 8040) defines: application/yang-data+json application/yang-data+xml COMI defines: application/yang-data+cbor application/yang-identifiers+cbor application/yang-instances+cbor It seems that yang-data+cbor really is yang-data+cbor+sid and it seems there is no media type for yang-data+cbor+names (i.e., the CBOR encoding that uses names instead of SIDs as keys). The other two media types yang-identifiers+cbor and yang-instances+cbor seem to be COMI specific. Hence, me preference would be to define something like application/yang-data+cbor+sid application/yang-data+cbor+name in YANG-CBOR and to leave the other two application/yang-identifiers+cbor application/yang-instances+cbor for COMI. There is a certain interest to stream binary encoded YANG data and having a self-contained YANG-CBOR document would be desirable to minimize dependencies and maintenance headache down the road. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Apr 8 01:50:02 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82AB3A0E64; Wed, 8 Apr 2020 01:50:00 -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 VgAn3yh79xBT; Wed, 8 Apr 2020 01:49:57 -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 4F80B3A0E5F; Wed, 8 Apr 2020 01:49:56 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48xydb21kWz1069; Wed, 8 Apr 2020 10:49:55 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <20200408065738.l7jnht536vxzacse@anna.jacobs.jacobs-university.de> Date: Wed, 8 Apr 2020 10:49:53 +0200 Cc: Ivaylo Petrov , NetMod WG , core X-Mao-Original-Outgoing-Id: 608028593.513101-5d6b6b58aa325266491ef7540caa0229 Content-Transfer-Encoding: quoted-printable Message-Id: <0817C3C8-420A-4994-89D4-2CDA150F682B@tzi.org> References: <20200331110237.zbo3zw74xlccur3w@anna.jacobs.jacobs-university.de> <20200407194758.luxnndxxsuixhzfo@anna.jacobs.jacobs-university.de> <16670AE8-DE0D-4444-9F64-ED6C67654886@tzi.org> <20200408065738.l7jnht536vxzacse@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] js review of draft-ietf-core-yang-cbor-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, 08 Apr 2020 08:50:01 -0000 Hi J=C3=BCrgen, > On 2020-04-08, at 08:57, Juergen Schoenwaelder = wrote: >=20 > COMI defines: >=20 > application/yang-data+cbor > application/yang-identifiers+cbor > application/yang-instances+cbor >=20 > It seems that yang-data+cbor really is yang-data+cbor+sid (We couldn=E2=80=99t use that syntax for the media type name, as +sid is = not a structured syntax suffix, but I get the point.) One way to build a content-type from a media-type name is to add a = parameter: application/yang-data+cbor; id=3Dname application/yang-data+cbor; id=3Dsid (In the CoAP content-format those content types would just be two = different content-format numbers.) But we could also encode that parameter in the media type name. We would have to end the media type name with =E2=80=9C+cbor=E2=80=9D, = because that is the structured syntax suffix that applies. > and it seems > there is no media type for yang-data+cbor+names (i.e., the CBOR > encoding that uses names instead of SIDs as keys). The other two media > types yang-identifiers+cbor and yang-instances+cbor seem to be COMI > specific. Hence, me preference would be to define something like >=20 > application/yang-data+cbor+sid > application/yang-data+cbor+name >=20 > in YANG-CBOR That would put the normative reference to -sid back into YANG-CBOR. Yes, we could do that. Gr=C3=BC=C3=9Fe, Carsten PS.: The terminology for media types is a mess^W^W underdeveloped; see = the expired = https://tools.ietf.org/html/draft-bormann-core-media-content-type-format-0= 1.txt for more info. > and to leave the other two >=20 > application/yang-identifiers+cbor > application/yang-instances+cbor >=20 > for COMI. From nobody Wed Apr 8 02:03:12 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0A53A0EAE for ; Wed, 8 Apr 2020 02:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh4lvpLy1oin for ; Wed, 8 Apr 2020 02:03:02 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 CD7E23A0EB0 for ; Wed, 8 Apr 2020 02:02:58 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id i3so6300620ioo.13 for ; Wed, 08 Apr 2020 02:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4l/xq32iZQqe0Q4BOn4swSzdCcMV3ULa2hVKN8LAD5M=; b=vBiTes2AGBaNkBLdSfM1v831eplooO02SVvZxIAFpQfiGH+DP+ybRRVnZ8vNaimdwE PnPrSTVw6m8ctfRPzGfRqhrT+z9aR+eLjh5BwJ1VZJ46u5EGS8Ba3rr8ZCL3j0tuItZy U2KqRcy3s+9E7jTL9ekv17ibi3MtqwNSdw8UETapbHGDQ4diCyhsMK55yl12hQAWFYry 6b8iWEPIRya5kS/3IIiQU3heJJFpDtzf6XqAcfk4oiDXW6TxrLe7bCS9B9pNRYh48CjB nntnO0Je99SJwarQKfY98lR52u9yT9v9ZooExl9KJchj+aQt+jeClV49iiDuRAlKnTu2 nAXw== 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=4l/xq32iZQqe0Q4BOn4swSzdCcMV3ULa2hVKN8LAD5M=; b=G30SSBEkk3/1NFGmO9It9fMmoN/MrRtjQcAueaJ2gdoIL14WLDwxPNuzecrcX+z8qB yXFazRoOHF+dfkPM1+9LE8zPKMjwyWobhJZsYYV//8rf5HisYKt4gE5EsfHrO+FlWPMf 6Bin2YSWrx6yxCiYKyDy/jJ7yfMiDyL6jZhoG3Tr9QukamjGir2lUVTUAbjGxbuSIOjX jdRf2hWXg+fiT67NNSF3GLoK1Ag2MLZlBTiZx99Q6PkvQOzjAUZMqLVeR2jrx0LKTy7z yLrJ3H5S3JlpyZEjb48wFoOorFFq8J5JIaVI9koUdb/kntP2WE+oziummuvQuHbqxd+g olZw== X-Gm-Message-State: AGi0PuZ1ezWmA/a+LyfZuz3OGL8PYKFPOQpSuEjL5MgPNT+JQpwBacrG dN0JGncwwsM1elcguxrst8lGQn4lpAOVulhF7sMn4w== X-Google-Smtp-Source: APiQypJvyEmZVKsMaRLkyOjz8neXLeRXIUKm5ZCy2oU1EuT3v6mgE164q0+3NSEBGW2aiwzyp4tSA9iGzAuEN3LQNL8= X-Received: by 2002:a6b:c8d4:: with SMTP id y203mr6073842iof.111.1586336577510; Wed, 08 Apr 2020 02:02:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Pelov Date: Wed, 8 Apr 2020 11:02:18 +0200 Message-ID: To: Laurent Toutain Cc: "core@ietf.org WG" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000343d9f05a2c3c443" Archived-At: Subject: Re: [core] =?utf-8?q?=5Bnetmod=5D__=F0=9F=94=94_WG_Last_Call_of_CORE?= =?utf-8?q?CONF_drafts=3A_draft-ietf-core-yang-cbor-12=2C_-sid-11=2C_-comi?= =?utf-8?q?-09=2C_-yang-library-01_/_-sid-11_review?= 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, 08 Apr 2020 09:03:08 -0000 --000000000000343d9f05a2c3c443 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, I have no additions or remarks on the documents. They are and in my opinion have been ready for some time - waiting for reviews and input from other contributors / WGs. Now, I'm even more confident the documents are ready (once the final remarks are addressed of course). We've had interop tests several versions ago, and since then I have followed the development and the diffs of the documents. They are inline with what we have been discussing and have only improved the technology. Cheers, Alexander On Mon, Mar 30, 2020 at 2:26 PM Laurent Toutain < Laurent.Toutain@telecom-bretagne.eu> wrote: > Hi, > > I've uses these drafts, mainly -sid, -cbor, -comi, when I was defining th= e > SCHC Data Model to study the impact of CORECONF on the serialization. > For me, it is a mature work describing CORECONF. Documents are clear with > examples. I looked at the diff for the latest versions and I don't see > any significant changes, so for me, these documents are ready. > > Laurent > > On Mon, Mar 30, 2020 at 1:18 PM Esko Dijk > wrote: > >> Hello CoRE, >> >> I did a quick review of the -sid-11 draft; it looks ready for >> publication. Some minor issues found : >> >> Reference to RFC 7120 early allocation procedure: the allocation policie= s >> for the registries are all "Expert review". And the RFC 7120 early >> allocation procedure is defined, to do early allocations. However RFC 71= 20 >> mentions that this procedure only applies in case : >> (Section 2) >> a. The code points must be from a space designated as "RFC >> Required", "IETF Review", or "Standards Action". Additionally, >> requests for early assignment of code points from a >> "Specification Required" registry are allowed if the >> specification will be published as an RFC. >> So at first sight it looks like the procedure is not applicable, taken >> strictly. However IANA indicates ( >> https://www.iana.org/help/protocol-registration) that "Expert review" is >> part of "Specification Required" so it would apply still. But in RFC 812= 6 >> this is not mentioned in the same manner - so it could confuse some read= ers >> about whether it applies or not. Maybe some text could be added to state >> why RFC 7120 process does apply to the "Expert review" policy, even thou= gh >> "Expert review" is not listed under Section 2 point a. of RFC 7120. (No= te >> that early allocation by RFC 7120 only applies to "Expert review" >> allocations for draft documents that aim to become RFC.) >> >> Section 6.3.3: table column 1 is very narrow and it breaks the entry >> point integer number, which is confusing. Why not make this column wider= by >> one character? One of the last 2 columns can be made more narrow if need= ed. >> >> Section 3: "RESCONF" -> RESTCONF >> >> Section 3: CoRECONF -> CORECONF >> >> Section 3: "For example how this could be achieved, please refer to" >> -> For examples on how this could be achieved, please refer to >> >> Section 3: "For diagram of one" >> -> For a diagram of one ... >> >> Best regards >> >> Esko >> >> IoTconsultancy.nl | Email/Skype: esko.dijk@iotconsultancy.nl >> >> >> >> -----Original Message----- >> From: core On Behalf Of Carsten Bormann >> Sent: Monday, March 9, 2020 14:05 >> To: core >> Cc: netmod@ietf.org >> Subject: [core] =F0=9F=94=94 WG Last Call of CORECONF drafts: >> draft-ietf-core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01 >> >> It took us a long time to get the four CORECONF drafts in sync, >> but now we are ready for WGLC. >> >> This starts a working group last call for >> =E2=80=94 draft-ietf-core-yang-cbor-12 >> =E2=80=94 draft-ietf-core-sid-11 >> =E2=80=94 draft-ietf-core-comi-09 >> =E2=80=94 draft-ietf-core-yang-library-01 >> >> ending on >> >> 24:00 UTC on Tuesday, March 31, 2020. >> >> (This includes some extra time for the IETF week and for cross-WG >> coordination.) >> >> This WGLC is copied to the netmod WG mailing list; please do have a look >> at these drafts as they are slated to become a part of the greater >> YANG/NETCONF/RESTCONF family. We intend the discussion to be on the >> CoRE mailing list, but if you find a fundamental issue with YANG or >> RESTCONF, feel free to discuss that on netmod instead. >> >> Please start a new email thread for each major issue that will need >> discussion and make sure the subject line includes the draft name and >> some sort of name for the issue. (Minor issues such as typos can also >> be sent to the authors.) >> >> If you read the draft and think it looks fine, please send a one line >> email to the list or to the chairs letting us know that so we can get >> a feel of how broad the review has been. >> >> (To reviewers and authors:) If you are aware of any patent claims that >> might apply to systems that implement these drafts, please review BCP 78 >> and BCP 79 and make any appropriate IPR declaration before the last-call >> ends. If you are not sure whether you need to make a declaration or not, >> please talk to the chairs and we will help. >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > > > -- > Laurent Toutain > +--- VoIP (recommended) ---+----------- T=C3=A9l=C3=A9com Bretagne ------= -----+ > | Tel: +33 2 22 06 8156 | Tel: + 33 2 99 12 7026 | > Visit : > | Mob: +33 6 800 75 900 | | > | Fax: +33 2 22 06 8445 | Fax: +33 2 99 12 7030 | > http://class.touta.in > | Laurent@Touta.in | Laurent.Toutain@Telecom-Bretagne.eu | > +--------------------------+----------------------------------------+ > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000343d9f05a2c3c443 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

I have no additions or remark= s on the documents. They are and in my opinion have been ready for some tim= e - waiting for reviews and input from other=C2=A0contributors / WGs. Now, = I'm even more confident the documents=C2=A0are ready (once the final re= marks are addressed of course).

We've had inte= rop tests several versions ago, and since=C2=A0then I have followed the dev= elopment and the diffs of the documents. They are inline with what we have = been discussing and have only improved the technology.

=
Cheers,
Alexander


<= br>
On Mon,= Mar 30, 2020 at 2:26 PM Laurent Toutain <Laurent.Toutain@telecom-bretagne.eu> wrote:=
Hi,

I've uses these drafts, mainly -sid= , -cbor, -comi, when I was defining the SCHC Data Model to study the impact= of CORECONF on the serialization.
For me, it is a mature wo= rk describing CORECONF. Documents are clear with examples. I looked at the = diff for the latest versions and I don't see
any signifi= cant changes, so for me, these documents are ready.

Laurent

On Mon, Mar 30, 2020 at 1:18 PM Esko Dijk <esko.dijk@iotconsult= ancy.nl> wrote:
Hello CoRE,

I did a quick review of the -sid-11 draft; it looks ready for publication. = Some minor issues found :

Reference to RFC 7120 early allocation procedure: the allocation policies f= or the registries are all "Expert review". And the RFC 7120 early= allocation procedure is defined, to do early allocations. However RFC 7120= mentions that this procedure only applies in case :
=C2=A0 =C2=A0(Section 2)
=C2=A0 =C2=A0a. The code points must be from a space designated as "RF= C
=C2=A0 =C2=A0 =C2=A0 =C2=A0Required", "IETF Review", or &quo= t;Standards Action".=C2=A0 Additionally,
=C2=A0 =C2=A0 =C2=A0 =C2=A0requests for early assignment of code points fro= m a
=C2=A0 =C2=A0 =C2=A0 =C2=A0"Specification Required" registry are = allowed if the
=C2=A0 =C2=A0 =C2=A0 =C2=A0specification will be published as an RFC.
So at first sight it looks like the procedure is not applicable, taken stri= ctly. However IANA indicates (https://www.iana.org/he= lp/protocol-registration) that "Expert review" is part of &qu= ot;Specification Required" so it would apply still. But in RFC 8126 th= is is not mentioned in the same manner - so it could confuse some readers a= bout whether it applies or not. Maybe some text could be added to state why= RFC 7120 process does apply to the "Expert review" policy, even = though "Expert review" is not listed under Section 2 point a. of = RFC 7120.=C2=A0 (Note that early allocation by RFC 7120 only applies to &qu= ot;Expert review" allocations for draft documents that aim to become R= FC.)

Section 6.3.3: table column 1 is very narrow and it breaks the entry point = integer number, which is confusing. Why not make this column wider by one c= haracter? One of the last 2 columns can be made more narrow if needed.

Section 3: "RESCONF" -> RESTCONF

Section 3: CoRECONF -> CORECONF

Section 3: "For example how this could be achieved, please refer to&qu= ot;
-> For examples on how this could be achieved, please refer to

Section 3: "For diagram of one"
-> For a diagram of one ...

Best regards

Esko

IoTconsultancy.nl=C2=A0 |=C2=A0 Email/Skype: esko.dijk@iotconsultancy.nl



-----Original Message-----
From: core <c= ore-bounces@ietf.org> On Behalf Of Carsten Bormann
Sent: Monday, March 9, 2020 14:05
To: core <core@ietf.o= rg>
Cc: netmod@ietf.org
Subject: [core] =F0=9F=94=94 WG Last Call of CORECONF drafts: draft-ietf-co= re-yang-cbor-12, -sid-11, -comi-09, -yang-library-01

It took us a long time to get the four CORECONF drafts in sync,
but now we are ready for WGLC.

This starts a working group last call for
=E2=80=94 draft-ietf-core-yang-cbor-12
=E2=80=94 draft-ietf-core-sid-11
=E2=80=94 draft-ietf-core-comi-09
=E2=80=94 draft-ietf-core-yang-library-01

ending on

=C2=A0 =C2=A0 =C2=A0 =C2=A0 24:00 UTC on Tuesday, March 31, 2020.

(This includes some extra time for the IETF week and for cross-WG
coordination.)

This WGLC is copied to the netmod WG mailing list; please do have a look at these drafts as they are slated to become a part of the greater
YANG/NETCONF/RESTCONF family.=C2=A0 We intend the discussion to be on the CoRE mailing list, but if you find a fundamental issue with YANG or
RESTCONF, feel free to discuss that on netmod instead.

Please start a new email thread for each major issue that will need
discussion and make sure the subject line includes the draft name and
some sort of name for the issue.=C2=A0 (Minor issues such as typos can also=
be sent to the authors.)

If you read the draft and think it looks fine, please send a one line
email to the list or to the chairs letting us know that so we can get
a feel of how broad the review has been.

(To reviewers and authors:)=C2=A0 If you are aware of any patent claims tha= t
might apply to systems that implement these drafts, please review BCP 78 and BCP 79 and make any appropriate IPR declaration before the last-call ends. If you are not sure whether you need to make a declaration or not, please talk to the chairs and we will help.

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

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


--
Laurent Toutain=C2=A0
+--- VoIP (re= commended) ---+----------- T=C3=A9l=C3=A9com Bretagne -----------+
| Tel= : +33 2 22 06 8156 =C2=A0 =C2=A0| Tel: + 33 2 99 12 7026 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Visit :
| Mob: +33 6 800 75 900 =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|
| Fax: +33 2 22 06 84= 45 =C2=A0 =C2=A0| Fax: +33 2 99 12 7030 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0http://class.touta.in
| Laurent@Touta.in =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | Laurent.Toutain@Telecom-Bretagne.eu =C2=A0 =C2=A0|
+----= ----------------------+----------------------------------------+
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--000000000000343d9f05a2c3c443-- From nobody Wed Apr 8 02:06:23 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBCB3A0EB9; Wed, 8 Apr 2020 02:06:16 -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 ZYaU1dOXqC-y; Wed, 8 Apr 2020 02:06:14 -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 539923A0EB8; Wed, 8 Apr 2020 02:06:12 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id D859540147; Wed, 8 Apr 2020 11:06:10 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id D01E914B; Wed, 8 Apr 2020 11:06:06 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:2d54:7976:cdc9:1eab]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 91815381; Wed, 8 Apr 2020 11:06:06 +0200 (CEST) Received: (nullmailer pid 2853630 invoked by uid 1000); Wed, 08 Apr 2020 09:04:36 -0000 Date: Wed, 8 Apr 2020 11:04:36 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: mohamed.boucadair@orange.com Cc: "core@ietf.org" , "Jon Shallow (supjps-ietf@jpshallow.com)" , "dots@ietf.org" Message-ID: <20200408090436.GC2844485@hephaistos.amsuess.com> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20200407130944.GA2738832@hephaistos.amsuess.com> <787AE7BB302AE849A7480A190F8B93303149075C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zx4FCpZtqtKETZ7O" Content-Disposition: inline In-Reply-To: <787AE7BB302AE849A7480A190F8B93303149075C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [core] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 08 Apr 2020 09:06:16 -0000 --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Med, On Tue, Apr 07, 2020 at 03:51:14PM +0000, mohamed.boucadair@orange.com wrot= e: > I don't see where in the two drafts an observer can request a particular = missing fragment.=20 Observation combined with block-wise transfer generally has the observer request all the remaining blocks when an updates comes in, as illustrated in [1]. Those do not even necessarily need to be requested in sequence. If a mechanism gets added that allows the server to send additional blocks after a first request (and I'd appreciate that, maybe we can get that resurfaced in the upcoming meeting's AOB section), the client may miss some of them, but can still fall back to that original mechanism. Kind regards Christian [1]: https://tools.ietf.org/html/rfc7959#section-3.4 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --zx4FCpZtqtKETZ7O Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl6Nk6AACgkQOY0REtOk veHiWBAAmbZW/16cgSWLsDEKaIQeYDA9dnuoOLJQy/ushCTtHFNHU+bvWOKZ7wqy XSnTL7T7x/tR5AlZ/5bgrs3ZM2SoeAk1jdcrntLdeY+DB9EiyZ2e0T6x1wgm9UMU rgJab/Hoa2040t4OAn77Dtp4mtU39e9mscjARZjh/oXUhKjz39cFkmZQIU/zHraq RnnAXlUjqo8bPFbhcLHVsTFT4Efa8h4BPgNuCWyYfVy+/uZ9pjVPNI/V6XWnxptE RR/tl9dbZUpRScryjk6lEB7C/ZgpPdygCxgmFgh9XlG6dyitCAXnNr3mNV3Y8g1X zmmwql4Yu8WgACBn8su9SWplVaMKzNjQpRKqJ4/2IkfesQqRNwE6GEmrkOqvTwsY RmS8Aewwavd746JcqrgCYm/DJcbeno8PTCb6ZrQdP0GAkVXwfO3tQ6oREuIR5hEK 0dbrpxwxUgx43oOsABgZOCYfokQXQ3MaZLmzd5wzpzLYAeNsoSH9rjErtGPxHoiI gwjouRPNh3J8PxXCNju1G9xZ/JT9/BlLz17loi07TZ+2Ab72wDDr1+YQD1ZCkw3o zVvbcCOsGFfW6osOGRO/ZBDYYY9WKJrdqA5vrDEJ0vSi14m2TWTzLp1DbOtZ3sKI qK8qqOsk3nQrUvwFmC0Dm3qe4aawEtTzNt74iynlSP40mM9cz4A= =Mvla -----END PGP SIGNATURE----- --zx4FCpZtqtKETZ7O-- From nobody Wed Apr 8 02:56:21 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A223A0FE5; Wed, 8 Apr 2020 02:56:18 -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, 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 C67rlb0-Ugoo; Wed, 8 Apr 2020 02:56:17 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2EC3A0FE4; Wed, 8 Apr 2020 02:56:16 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 48y0663tZNz5vdm; Wed, 8 Apr 2020 11:56:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586339774; bh=iHbYQjpslX5s7pGcTMA04lnQcW5heQhj96FyHxcUN4o=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=o20XXuT1ChSeC3SS1oilAelf6cDJYFvsxRWVd2K5MNje2llffQZC12yvqNLl8sd9V VyUL0ikNizMXTLgn0695MnYWVQ+7UJLdHNSbOkPebOEkVvVe+4NKsUZg9RdTnp6SxQ iV2zPKhjtNtIykFrM6dIGfqXhONGsihG754LZpDIhuumVsWbbwQo1DfEfZNGBTgW8m Lr0MrR1aG6DXXByYcGsVj0rGerz5P687rlAIN941BqORQDF7JY6L01TrXTMM1XYO8y X3S0UcrRCDcfwwBdhHJ41TWzpuPUwhaX95uNBJB3C/E/El8y+eqHnO8qCz0DB4Odeh lvgvtIIT6tPsg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 48y0662nVxz8sZj; Wed, 8 Apr 2020 11:56:14 +0200 (CEST) From: To: Carsten Bormann CC: Jon Shallow , core , "dots@ietf.org" Thread-Topic: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AQHWDYvwpy/bxUigK0iz1rVnLiHoRg== Date: Wed, 8 Apr 2020 09:56:13 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> In-Reply-To: <566C58A5-0373-4D34-91F8-7B664423E373@tzi.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.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 08 Apr 2020 09:56:19 -0000 SGkgQ2Fyc3RlbiwNCg0KV2UgYXJlIGFsc28gY29uc2lkZXJpbmcgaG93IHRvIHNvbHZlIHRoZSBp c3N1ZSBhdCB0aGUgRE9UUyBsZXZlbC4gVGhlIGdvb2QgbmV3cyBpcyB0aGF0IHdlIGFyZSBub3Qg YmxpbmRseSBvdmVycmlkaW5nIHBpZWNlcyBvZiBkYXRhIHRoYXQgYXJlIHJlY2VpdmVkIGluIGRp c3RpbmN0IHJlc3BvbnNlcy4gV2UgaGF2ZSBzb21lIGNoZWNrcyB0byB1cGRhdGUgYW4gYWN0aXZl IHJlY29yZC4gQnV0IGFzIG1lbnRpb25lZCBieSBKb24sIHRoZXJlIGFyZSBzb21lIGNoYWxsZW5n ZXMgYXMgd2VsbC4gDQoNCldpdGggcmVnYXJkcyB0byB0aGUgbmV0d29yayBlbnZpcm9ubWVudCwg dGhlIGRpcmVjdGlvbiBvZiB0aGUgYXR0YWNrIGlzIHRoZSBzYW1lIGFzIHRoZSBvbmUgZnJvbSBz ZXJ2ZXJzIHRvIGNsaWVudHMuIFRoYXTigJlzIHNhaWQsIHRlbGVtZXRyeSBkYXRhIGNhbiBiZSBl eGNoYW5nZWQgaW4gYm90aCBkaXJlY3Rpb25zOg0KDQoqIGZyb20gY2xpZW50IHRvIHNlcnZlcnM6 IHVzaW5nIGEgZGVkaWNhdGVkIHRlbGVtZXRyeSBtZXNzYWdlIG9yIGluIGFuIGVmZmljYWN5IHVw ZGF0ZSBzaGFyZWQgd2l0aCB0aGUgc2VydmVyIHdoZW4gYSBtaXRpZ2F0aW9uIGlzIGFjdGl2ZS4g VGhpcyBpcyBkb25lIHVzaW5nIFBVVCBtZXNzYWdlcy4NCiogZnJvbSBzZXJ2ZXJzIHRvIGNsaWVu dHM6IHRlbGVtZXRyeSBkYXRhIGNhbiBiZSBzZW50IGluIGRlZGljYXRlZCBub3RpZmljYXRpb24g bWVzc2FnZXMgb3IgYXMgcGFydCBvZiB0aGUgbWl0aWdhdGlvbiBzdGF0dXMgdXBkYXRlLiBCb3Ro IHJlbHkgdXBvbiBHRVQrT2JzZXJ2ZS4gSGF2aW5nIGEgbWVjaGFuaXNtIHRvIGFzayBmb3IgZ2Fw cyB3b3VsZCB0aHVzIGJlIGhlbHBmdWwuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBDYXJzdGVuIEJvcm1hbm4gW21haWx0bzpjYWJvQHR6 aS5vcmddDQo+IEVudm95w6nCoDogbWFyZGkgNyBhdnJpbCAyMDIwIDIzOjE5DQo+IMOAwqA6IEFj aGltIEtyYXVzDQo+IENjwqA6IEpvbiBTaGFsbG93OyBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xO OyBjb3JlOyBkb3RzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBbY29yZV0gW0RvdHNdIExhcmdl IGFzeW5jaHJvbm91cyBub3RpZmljYXRpb25zIHVuZGVyIEREb1M6DQo+IE5ldyBCTE9DSyBPcHRp b24/DQo+IA0KPiBIaSBBY2hpbSwNCj4gDQo+IE9uIDIwMjAtMDQtMDcsIGF0IDIxOjA0LCBBY2hp bSBLcmF1cyA8YWNoaW1rcmF1c0BnbXgubmV0PiB3cm90ZToNCj4gPg0KPiA+IEZNUE9WLCB0aGUg Zmlyc3QgdGhpbmcgdG8gZW5zdXJlIGlzLCB0aGF0IHRoZSAibGFyZ2UgcGF5bG9hZCIgZ2V0cw0K PiBzcGxpdA0KPiA+IGludG8gImFwcGxpY2F0aW9uIGJsb2NrcyIsIHdoaWNoIGNvdWxkIGJlIHBy b2Nlc3NlZCBldmVuIHdoZW4gb3RoZXINCj4gPiBhcHBsaWNhdGlvbiBibG9ja3MgYXJlIG1pc3Np bmcuDQo+IA0KPiBJbmRlZWQsIOKAnGFwcGxpY2F0aW9uIGxheWVyIGZyYW1pbmfigJ0gY29tZXMg dG8gbWluZCBoZXJlOyB0aGF0IGlzIGFsd2F5cw0KPiBhIGdvb2QgaWRlYSBpZiBpdCBjYW5ub3Qg YmUgZW5zdXJlZCB0aGF0IGFsbCBtZXNzYWdlcyBtYWtlIGl0IG9yIGlmIGl0DQo+IGlzIGdvb2Qg dG8gYmUgYWJsZSB0byBwcm9jZXNzIG1lc3NhZ2VzIHdoaWxlIHN0aWxsIHdhaXRpbmcgZm9yIG90 aGVycy4NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgIC5vT28uDQo+IA0KPiBJ4oCZbSB0cnlp bmcgdG8gdW5kZXJzdGFuZCB0aGUgdmVyeSBzcGVjaWZpYyBuZXR3b3JrIGVudmlyb25tZW50IHRo YXQgd2UNCj4gYXJlIHRhcmdldGluZyBoZXJlLg0KPiBBcmUgd2UgYXNzdW1pbmcgcGFja2V0cyBh cmUgd2F5IG1vcmUgbGlrZWx5IHRvIG1ha2UgaXQgZnJvbSB0aGUgc2VydmVyDQo+IHRvIHRoZSBj bGllbnQgdGhhbiB0aGUgb3RoZXIgd2F5IGFyb3VuZD8NCj4gVGhhdCBpbmRlZWQgd291bGQgY2Fs bCBmb3IgYWRkaXRpb25hbCBjYXBhYmlsaXRpZXMgdGhhdCBiYXNlIENvQVAgZG9lcw0KPiBub3Qg aGF2ZS4NCj4gV2UgYWxzbyBtYXkgbm90IHJlYWxseSBjYXJlIGFib3V0IGNvbmdlc3Rpb24gY29u dHJvbCBtdWNoIGluIGENCj4gc2l0dWF0aW9uIG9mIG1hc3NpdmUgKGF0dGFja2VyLWluZHVjZWQp IGNvbmdlc3Rpb24gKGFsdGhvdWdoIHRoYXQNCj4gbWlnaHQgYmUgbWlzZGlhZ25vc2VkLCBzbyBz b21lIGNhcmUgaXMgc3RpbGwgcmVxdWlyZWQpOyB3aGljaCB3b3VsZCBiZQ0KPiBhbm90aGVyIHJl YXNvbiB0byBtYXliZSBkZXZpYXRlIGZyb20gYmFzZSBDb0FQLg0KPiANCj4gSSBkb27igJl0IGhh dmUgYSBkZXNpZ24gaW4gbWluZCBhdCB0aGUgbW9tZW50LiAgSXQgd291bGQgbmVlZCB0byBjYXRl cg0KPiBmb3IgdGhlIGZhY3QgdGhhdCBzZW5kaW5nIHRoZSBvdGhlciByZXNwb25zZSBtZXNzYWdl cyBmb3IgdGhlIHJlcXVlc3QNCj4gd291bGQgYmUgb24gdGhlIGluaXRpYXRpdmUgb2YgdGhlIHNl cnZlci4NCj4gU28gb2JzZXJ2ZSAod2l0aCBub24tY29uZmlybWFibGUgcmVzcG9uc2VzKSBpcyBt YXliZSBhIGdvb2QgbW9kZWwNCj4gaW5kZWVkOyB3aGF04oCZcyBtaXNzaW5nIGlzIHNvbWUgd2F5 IHRvIGFzayBmb3IgZ2Fwcy4NCj4gDQo+IEkganVzdCByZXN1Ym1pdHRlZCBhIGRyYWZ0IHRoYXQg d2UgaGF2ZSBiZWVuIGRpc2N1c3NpbmcgZm9yIGEgd2hpbGUgaW4NCj4gVDJUUkc6DQo+IFRoZSBT ZXJpZXMgVHJhbnNmZXIgUGF0dGVybiAoU1RQKQ0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9k cmFmdC1ib3JtYW5uLXQydHJnLXN0cC0wMi5odG1sDQo+IA0KPiBUaGlzIGhhcyBzb21lIGRpc2N1 c3Npb24gdGhhdCBtYXkgYmUgcmVsZXZhbnQgaGVyZSwgYWx0aG91Z2ggaXQgZG9lcw0KPiBub3Qg YWRkcmVzcyB0aGUgc3BlY2lmaWMgRE9UUyBwcm9ibGVtLiAgSSB0aGluayBpdCB3b3VsZCBiZSBn cmVhdCBpZg0KPiB3aGF0ZXZlciB3ZSBjb21lIHVwIHdpdGggdG8gc29sdmUgdGhpcyBwcm9ibGVt IHdvdWxkIGFsc28gYmUgYSBzdGVwDQo+IGZvcndhcmQgb24gdGhlIGxhcmdlciBjbGFzcyBvZiBh cHBsaWNhdGlvbnMgbmVlZGluZyB0aGUgc2VyaWVzDQo+IHRyYW5zZmVyIHBhdHRlcm4uDQo+IA0K PiBHcsO8w59lLCBDYXJzdGVuDQoNCg== From nobody Wed Apr 8 03:41:13 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0603A1003; Wed, 8 Apr 2020 03:41:11 -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 WgNf07dIqBSY; Wed, 8 Apr 2020 03:41:09 -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 9B0413A1232; Wed, 8 Apr 2020 03:41:08 -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 1jM88k-0007Cq-O9; Wed, 08 Apr 2020 11:41:02 +0100 From: "Jon Shallow" To: , , , References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <2a255f3b-6614-f950-4ecc-15f170087c9f@gmx.net> <787AE7BB302AE849A7480A190F8B933031490894@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d60d05$d87fcca0$897f65e0$@jpshallow.com> <566C58A5-0373-4D34-91F8-7B664423E373@tzi.org> <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933031491200@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Wed, 8 Apr 2020 11:41:08 +0100 Message-ID: <023101d60d92$3642ebb0$a2c8c310$@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: AQGFUV4cZbdAMYpJNEeLLEh4F2cKcwH1DnpQAK+no80CR9JpmAF0lygWAgQyebgB0OlAXai+yvJw Content-Language: en-gb Archived-At: Subject: Re: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option? 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, 08 Apr 2020 10:41:11 -0000 Hi All, Thanks for all your input so far. It has helped my thinking, but I = still do not have a clear answer yet as how to best do this for the DOTS = specific situation as well as more general use cases. Below is a more graphical way of trying to describe what is happening = and how it may be possible to overcome some of the limitations of using = BLOCK2 in a lossy traffic environment (caused by DDoS attacks). Regards Jon Primary packet loss is from Server to Client [Server is DDoS mitigating out in Internet, Client is on premise, DDoS = flood against client] GET followed by Observe response - all working - as we would do it = today. CLIENT SERVER | | +--------->| GET /path Token 0xf0 Observe 0 | | |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 0/1/1024 | | +--------->| GET /path Token 0xf0 Block2 1/0/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 1/1/1024 | | +--------->| GET /path Token 0xf0 Block2 2/0/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 2/1/1024 | | +--------->| GET /path Token 0xf0 Block2 3/0/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1234 Block2 3/0/1024 Observe triggered |<---------+ 2.05 Token 0xf0 Observe 1235 Block2 0/1/1024 | | +--------->| GET /path Token 0xf1 Block2 1/0/1024 | | |<---------+ 2.05 Token 0xf1 Observe 1235 Block2 1/1/1024 | | +--------->| GET /path Token 0xf1 Block2 2/0/1024 | | |<---------+ 2.05 Token 0xf1 Observe 1235 Block2 2/1/1024 | | +--------->| GET /path Token 0xf1 Block2 3/0/1024 | | |<---------+ 2.05 Token 0xf1 Observe 1235 Block2 3/0/1024 Confirmable ACK responses not displayed, nor Etag, Size2 or Maxage. Now with some packet loss. Observe triggered |<---------+ 2.05 Token 0xf0 Observe 1236 Block2 0/1/1024 | | +--------->| GET /path Token 0xf2 Block2 1/1/1024 | | | X<-----+ 2.05 Token 0xf2 Observe 1236 Block2 1/1/1024 | | Timeout Retry if Confirmable +--------->| GET /path Token 0xf2 Block2 1/1/1024 | | | X<-----+ 2.05 Token 0xf2 Observe 1236 Block2 1/1/1024 | | Retries continue - eventually timing out and possibly killing CoAP = session. Communications can be locked out for 90 seconds as CoAP NSTART is 1. [DOTS uses NON-Confirmable for protocol reliability, not traffic = reliability] If not using Confirmable, then the Client needs to time out at the = application layer and retry, but can only go forward 1 block at a time = (does not have to be in sequential order). Server may need to garbage collect on resource with Etag. What may help the situation (but client can decide when current = Etag/Maxage is no longer valid and stop continue requesting, and server = may still need to garbage collect) New CoAP Option NONBLOCK2 equivalent to BLOCK2, but does not rely on = client doing GET to get the next block synchronously. CLIENT SERVER | | +--------->| GET /path Token 0xf0 Observe 0 NonBlock2 = 0/0/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 0/1/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 1/1/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 2/1/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1234 NonBlock2 3/0/1024 Observe triggered |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 0/1/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 1/1/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 2/1/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1235 NonBlock2 3/0/1024 Observe triggered |<---------+ 2.05 Token 0xf0 Observe 1236 NonBlock2 0/1/1024 | | | X<-----+ 2.05 Token 0xf0 Observe 1236 NonBlock2 1/1/1024 | | | X<-----+ 2.05 Token 0xf0 Observe 1236 NonBlock2 2/1/1024 | | |<---------+ 2.05 Token 0xf0 Observe 1236 NonBlock2 3/0/1024 Client realises blocks are missing and asks for the missing ones in one = go +--------->| GET /path Token 0xf1 NonBlock2 1/0/1024 = NonBlock2 2/0/1024 | | | X<-----+ 2.05 Token 0xf1 Observe 1236 NonBlock2 1/1/1024 | | |<---------+ 2.05 Token 0xf1 Observe 1236 NonBlock2 2/1/1024 Get final missing block +--------->| GET /path Token 0xf2 NonBlock2 1/0/1024 | | |<---------+ 2.05 Token 0xf2 Observe 1236 NonBlock2 1/1/1024 Obviously the 3 second minimum for RTT calculations needs to be = maintained so that the Attack situation is not made worse. However, I = think it acceptable that all the NonBlock2s for a particular data set = are all sent as a stream. > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com > Sent: 08 April 2020 10:56 > To: Carsten Bormann > Cc: Jon Shallow; dots@ietf.org; core > Subject: Re: [Dots] [core] Large asynchronous notifications under = DDoS: > New BLOCK Option? >=20 > Hi Carsten, >=20 > We are also considering how to solve the issue at the DOTS level. The = good > news is that we are not blindly overriding pieces of data that are = received in > distinct responses. We have some checks to update an active record. = But as > mentioned by Jon, there are some challenges as well. >=20 > With regards to the network environment, the direction of the attack = is the > same as the one from servers to clients. That=E2=80=99s said, = telemetry data can be > exchanged in both directions: >=20 > * from client to servers: using a dedicated telemetry message or in an > efficacy update shared with the server when a mitigation is active. = This is > done using PUT messages. > * from servers to clients: telemetry data can be sent in dedicated > notification messages or as part of the mitigation status update. Both = rely > upon GET+Observe. Having a mechanism to ask for gaps would thus be > helpful. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : Carsten Bormann [mailto:cabo@tzi.org] > > Envoy=C3=A9 : mardi 7 avril 2020 23:19 > > =C3=80 : Achim Kraus > > Cc : Jon Shallow; BOUCADAIR Mohamed TGI/OLN; core; dots@ietf.org > > Objet : Re: [core] [Dots] Large asynchronous notifications under = DDoS: > > New BLOCK Option? > > > > Hi Achim, > > > > On 2020-04-07, at 21:04, Achim Kraus wrote: > > > > > > FMPOV, the first thing to ensure is, that the "large payload" gets > > split > > > into "application blocks", which could be processed even when = other > > > application blocks are missing. > > > > Indeed, =E2=80=9Capplication layer framing=E2=80=9D comes to mind = here; that is always > > a good idea if it cannot be ensured that all messages make it or if = it > > is good to be able to process messages while still waiting for = others. > > > > .oOo. > > > > I=E2=80=99m trying to understand the very specific network = environment that we > > are targeting here. > > Are we assuming packets are way more likely to make it from the = server > > to the client than the other way around? > > That indeed would call for additional capabilities that base CoAP = does > > not have. > > We also may not really care about congestion control much in a > > situation of massive (attacker-induced) congestion (although that > > might be misdiagnosed, so some care is still required); which would = be > > another reason to maybe deviate from base CoAP. > > > > I don=E2=80=99t have a design in mind at the moment. It would need = to cater > > for the fact that sending the other response messages for the = request > > would be on the initiative of the server. > > So observe (with non-confirmable responses) is maybe a good model > > indeed; what=E2=80=99s missing is some way to ask for gaps. > > > > I just resubmitted a draft that we have been discussing for a while = in > > T2TRG: > > The Series Transfer Pattern (STP) > > https://www.ietf.org/id/draft-bormann-t2trg-stp-02.html > > > > This has some discussion that may be relevant here, although it does > > not address the specific DOTS problem. I think it would be great if > > whatever we come up with to solve this problem would also be a step > > forward on the larger class of applications needing the series > > transfer pattern. > > > > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Apr 8 03:58:52 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8463A12E2; Wed, 8 Apr 2020 03:58:46 -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 E3fWG3BT1frD; Wed, 8 Apr 2020 03:58:44 -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 7D8A03A12E1; Wed, 8 Apr 2020 03:58:44 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48y1VB1vlkzyX1; Wed, 8 Apr 2020 12:58:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <0817C3C8-420A-4994-89D4-2CDA150F682B@tzi.org> Date: Wed, 8 Apr 2020 12:58:41 +0200 Cc: core , NetMod WG , Ivaylo Petrov X-Mao-Original-Outgoing-Id: 608036321.657564-eee273dc4db31bafc432d532efd82f13 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200331110237.zbo3zw74xlccur3w@anna.jacobs.jacobs-university.de> <20200407194758.luxnndxxsuixhzfo@anna.jacobs.jacobs-university.de> <16670AE8-DE0D-4444-9F64-ED6C67654886@tzi.org> <20200408065738.l7jnht536vxzacse@anna.jacobs.jacobs-university.de> <0817C3C8-420A-4994-89D4-2CDA150F682B@tzi.org> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] [netmod] js review of draft-ietf-core-yang-cbor-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, 08 Apr 2020 10:58:47 -0000 On 2020-04-08, at 10:49, Carsten Bormann wrote: >=20 > One way to build a content-type from a media-type name is to add a = parameter: >=20 > application/yang-data+cbor; id=3Dname > application/yang-data+cbor; id=3Dsid Ha. Let=E2=80=99s create a registry in yang-cbor for id=3D values (initially = filled with id=3Dname). -sid can then register id=3Dsid in that. Look, ma, no normative references! Gr=C3=BC=C3=9Fe, Carsten PS. If you wonder why I care about normative references: RFC 7252 got = stuck for a year in 2013 for an ill-advised normative reference. And = have a look at = https://www.rfc-editor.org/current_queue.php#draft-ietf-anima-grasp =E2=80= =94 140+ weeks of waiting for a (totally unneeded) normative = reference=E2=80=A6 From nobody Wed Apr 8 04:36:52 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D82C3A00E2 for ; Wed, 8 Apr 2020 04:36:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwW6PHJbrimA for ; Wed, 8 Apr 2020 04:36:43 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 7FEB13A0101 for ; Wed, 8 Apr 2020 04:36:43 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id h9so7413882wrc.8 for ; Wed, 08 Apr 2020 04:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9zrVQf14OfGg8juR/ZeATdZ3iQtbW/G4FtzcBiTqEss=; b=yAQVn8dsddYTrY1m9kb7m62O3dOa6v9ajkbhBZKkQJB8ZqdmCLS1reWZmBpNHU2Giz vVBsK8SOJ/meBWlc2dKZeO2IC1GRiSfd+ChRE5Kc79Aj9f0tugdE1VlKOvcXMQ1gevzR 4REKnc1Hxxky2dhZbZD3YCfxdoN7UAbHjbyVlXXRelmOO6KAz8iav8ZxH3wxtVVtgF6h +E6yy+/O1bosiVBCd4/+kPWMZECPed2ALkeuM/PHgE61s+90Uw8ATK1nDiDEe1yeztgJ CsJm0v51rS6xJbh/KGDXpypf4O08+bKR3u0ogIG9ymQfy5hPavVch7hDIVzvO/aDO9I/ rcdw== 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=9zrVQf14OfGg8juR/ZeATdZ3iQtbW/G4FtzcBiTqEss=; b=e9NJC2c6kSGJxrIFCffFzLSkTd0txBAxvmZoDCjQdq+bjRNZXmAH2wEwSO9PFyQkXJ GfTDpcPzZr241diQ5gQTZ92jsvbHyFEl8Xw0j5AECl/c5ahRVOrE3xeyEYZNwlUIiX8u m/HklimhsMEdic/VCs3AsP42mOrrDDAthALRx49FnPqo7a5Ky3dZWMML8K/trjCbVj0I HpR2+ZFbHH8b6zuiCCqOnG6SZ5MAAdlqIM6D33BQeVFXMpLM5ON0r4Yo+QK+4v6d/4bF c/u5p+L0MxbvQtPm3eydyeVK1rT1poRN0mJbiyxdpUaFWh3byUHwL822VpzaScVipyCX fsBA== X-Gm-Message-State: AGi0Pua7IzxzhuYARSa8achBb/F7jevuryHYXIXFrKfgQwMeGXe++EZO Sxe3kx2H6YTVr/xtMwLbihm8knfrnKrDw8M6WteAWQ== X-Google-Smtp-Source: APiQypKDV8wwKYhlTpyb3RYFgMQzcI4A793UDsdLIqKRdw1KeH5T28MjGbbGCaYSMRJuecqv0OfMmFjZ6TMsAxQ29RQ= X-Received: by 2002:a5d:6545:: with SMTP id z5mr6596729wrv.136.1586345801665; Wed, 08 Apr 2020 04:36:41 -0700 (PDT) MIME-Version: 1.0 References: <20200331110237.zbo3zw74xlccur3w@anna.jacobs.jacobs-university.de> <20200407194758.luxnndxxsuixhzfo@anna.jacobs.jacobs-university.de> <16670AE8-DE0D-4444-9F64-ED6C67654886@tzi.org> <20200408065738.l7jnht536vxzacse@anna.jacobs.jacobs-university.de> <0817C3C8-420A-4994-89D4-2CDA150F682B@tzi.org> In-Reply-To: From: Ivaylo Petrov Date: Wed, 8 Apr 2020 13:36:15 +0200 Message-ID: To: Carsten Bormann Cc: Juergen Schoenwaelder , core , NetMod WG Content-Type: multipart/alternative; boundary="000000000000ffe56f05a2c5e9e0" Archived-At: Subject: Re: [core] [netmod] js review of draft-ietf-core-yang-cbor-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, 08 Apr 2020 11:36:45 -0000 --000000000000ffe56f05a2c5e9e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I like this solution, but I am wondering if it will create a normative reference in the other direction (sid to yang-cbor) and would we be fine with that. Best regards, Ivaylo On Wed, Apr 8, 2020 at 12:58 PM Carsten Bormann wrote: > On 2020-04-08, at 10:49, Carsten Bormann wrote: > > > > One way to build a content-type from a media-type name is to add a > parameter: > > > > application/yang-data+cbor; id=3Dname > > application/yang-data+cbor; id=3Dsid > > Ha. > > Let=E2=80=99s create a registry in yang-cbor for id=3D values (initially = filled with > id=3Dname). > -sid can then register id=3Dsid in that. > > Look, ma, no normative references! > > Gr=C3=BC=C3=9Fe, Carsten > > PS. If you wonder why I care about normative references: RFC 7252 got > stuck for a year in 2013 for an ill-advised normative reference. And hav= e > a look at > https://www.rfc-editor.org/current_queue.php#draft-ietf-anima-grasp =E2= =80=94 > 140+ weeks of waiting for a (totally unneeded) normative reference=E2=80= =A6 > > --000000000000ffe56f05a2c5e9e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I like th= is solution, but I am wondering if it will create a normative reference in = the other direction (sid to yang-cbor) and would we be fine with that.

Best regards,
Ivaylo
<= div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature= ">


On Wed, Apr 8, 2020 at 12= :58 PM Carsten Bormann <cabo@tzi.org= > wrote:
On 2= 020-04-08, at 10:49, Carsten Bormann <cabo@tzi.org> wrote:
>
> One way to build a content-type from a media-type name is to add a par= ameter:
>
> application/yang-data+cbor; id=3Dname
> application/yang-data+cbor; id=3Dsid

Ha.

Let=E2=80=99s create a registry in yang-cbor for id=3D values (initially fi= lled with id=3Dname).
-sid can then register id=3Dsid in that.

Look, ma, no normative references!

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

PS. If you wonder why I care about normative references: RFC 7252 got stuck= for a year in 2013 for an ill-advised normative reference.=C2=A0 And have = a look at https://www.rfc-editor.= org/current_queue.php#draft-ietf-anima-grasp =E2=80=94 140+ weeks of wa= iting for a (totally unneeded) normative reference=E2=80=A6

--000000000000ffe56f05a2c5e9e0-- From nobody Wed Apr 8 04:50:38 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7551A3A041A; Wed, 8 Apr 2020 04:50:34 -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, MSGID_FROM_MTA_HEADER=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=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 014KZW_Wgz7E; Wed, 8 Apr 2020 04:50:32 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2059.outbound.protection.outlook.com [40.107.21.59]) (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 8812B3A0542; Wed, 8 Apr 2020 04:50:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DWVK0exhM5y8j05V1IX7DxI/H3DpYh8/uYOWAhLK8+TCvxgqg9EFMesDwcGtiejoFtPJkZcXo9QawVd6yWih2l/bIxRXCZV8ep/Z0pVbTBqbwQHcPdIkujiqgxV+aVWhO9mNvKootVPnCxh6URPZmSoEAC2Mxr9BlPFn4GaFGbFPNg8kV77sfoqnkHMLENCdyUf2o8ekpGhhnx5EmqRUjVgaJctVdcIh9ZPr2JLOUiTDlK9KK9OS6DN80RAMMG3Tul5lrcrbVeixHxzKm8fCCn/iGx+37rTbfSZ0pFGFRmCShnqD7yx+9z1Tsvdj/OPM0tzkldL7A6s5dXiZN6cCGA== 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=2yPslVyVtgamLNXA+ARc6B9IWXN1V75mGX+nFPonWHc=; b=ONIDI1SOXHdNfo2140qGzejapsiqfATgC5AHvLc6oDZ/QV/jYItB3lSlf2ynpV5DNPaYMMZznVG4j2/rCmBYDM4A8Rl7gQFhf3SXEgWh6VUzyDRXCBd0i8xcyoyYp5u7TBfUq3zliOqRbn5AHJ5RJUnIvbzBPDADcyTDhsRMJm+jaRAbazUwFDdgNrk99FVrPat2xl3h7usifa7al7nJDjIliT3JzUMSO24cADNrWgVkkbh2yHjWfZe47owI/OCmHzMh48gdQ7LKRBUgjLNjXhVXDKYeg01l1l6kyPDBi/+Ehz58pzPxC+cAHKmJXSc5msJL72BAigcJ7ByH6DBmJw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2yPslVyVtgamLNXA+ARc6B9IWXN1V75mGX+nFPonWHc=; b=i/21jXb/tmcWxSa2y1u1lOrvEjgbJvv4iPdXPomlvAoGOOpaiDwtLRNCofsFrDzObz5AjocSj2Xv7ym1jlAtFFLqf89oSdUUQ3tBF1yBBPOWGQFomuJJVxjG4/XGUXucqpsqbi6GK1oQBG3rNg5gk5BmyAvHsr5sHLh6xg1n9nQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (10.186.129.88) by AM0P190MB0676.EURP190.PROD.OUTLOOK.COM (10.186.128.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Wed, 8 Apr 2020 11:50:30 +0000 Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::382f:f91c:26b5:a440]) by AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::382f:f91c:26b5:a440%8]) with mapi id 15.20.2878.021; Wed, 8 Apr 2020 11:50:30 +0000 Date: Wed, 8 Apr 2020 13:50:29 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: core , NetMod WG , Ivaylo Petrov Message-ID: <20200408115029.sfcm2p4gebai3y74@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , core , NetMod WG , Ivaylo Petrov References: <20200331110237.zbo3zw74xlccur3w@anna.jacobs.jacobs-university.de> <20200407194758.luxnndxxsuixhzfo@anna.jacobs.jacobs-university.de> <16670AE8-DE0D-4444-9F64-ED6C67654886@tzi.org> <20200408065738.l7jnht536vxzacse@anna.jacobs.jacobs-university.de> <0817C3C8-420A-4994-89D4-2CDA150F682B@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AM5PR0201CA0023.eurprd02.prod.outlook.com (2603:10a6:203:3d::33) To AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:196::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (2001:638:709:5::7) by AM5PR0201CA0023.eurprd02.prod.outlook.com (2603:10a6:203:3d::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Wed, 8 Apr 2020 11:50:29 +0000 X-Originating-IP: [2001:638:709:5::7] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 503d984d-4445-4c1a-d9bc-08d7dbb3095c X-MS-TrafficTypeDiagnostic: AM0P190MB0676: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6430; X-Forefront-PRVS: 0367A50BB1 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0707.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(366004)(396003)(346002)(376002)(136003)(39850400004)(6486002)(86362001)(53546011)(52116002)(66946007)(5660300002)(66556008)(66476007)(6496006)(2906002)(186003)(54906003)(4326008)(6916009)(8676002)(81166007)(81156014)(8936002)(1076003)(16526019)(3450700001)(316002)(786003)(478600001); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vpsrfBv557VYN3PHQQzMfTmDI+z9rL6FF8KMGD7X51tF647w109ZHgK8Z08WTGZtsXvxkRKmMl8hFjrn+huvgq5hZ2bFhByqnge01ZpyJGsZihfhvJhremhlCSkXAy78xqA+Wq8PWPg1Z08Pl5bLKYt4cym1LD3scfdxnWOQ7zHdDG/xiW0ir5GoJJHUTntou6bVOXbG4eJgzq6sMoTzYE+ihd7yzAheV7PZD8ZhxHv26AnJv6sU5+7QFRCbGMKB3jeDbniagevz3aOszbwnPZFRGhb/RLe9RdTtc03rp1LfXQOpb6xfD81G6bP4OwWYe1PxVPWpvFfE8pJGdNau13iwYQGijd9KgXUiISPgl+YV/nsBwirdX5R+9Ie5n8BtJV0I/SpVJBEQvrfvKeGT7R5rIOE1kMw35JkPCM8GKSPd9NY9abQqij3c7v8sw86X6YxbCC7ussQ3N3g5Q9zeIUs/NvdAZvKuTcGOA4zI2RkIAGmMo7fX47wCKPW10hx0pLbrk9CJvuzviMZ4Y1+zkg== X-MS-Exchange-AntiSpam-MessageData: R2AxU8YhxxkLPmPWxSadw+PZpDcEFwRtmpSLtulDPMYUND7pMRsIyRl76ZOvuTcwPNHcrad1hFAhy6FoRBkTheHAMMz04Oby0z9b62G7xEOpHsX7i3HDTGJFZLsSp1RO3/XAHhoBsNyh9i25vse1S8Xg6j3YrB5PrIOvG3mJEc8= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 503d984d-4445-4c1a-d9bc-08d7dbb3095c X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2020 11:50:30.0347 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: sCESM1B4YkLnIsVKcsRLI+mInHihiMDqMSDrj0oQ7mF8ZHPZWaJLQfEvRs1iJvRhCquXvMP534Jjm0IkQlx5alZvYLeK38hW15xmQBxGZhI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0676 Archived-At: Subject: Re: [core] [netmod] js review of draft-ietf-core-yang-cbor-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, 08 Apr 2020 11:50:35 -0000 On Wed, Apr 08, 2020 at 12:58:41PM +0200, Carsten Bormann wrote: > On 2020-04-08, at 10:49, Carsten Bormann wrote: > > > > One way to build a content-type from a media-type name is to add a parameter: > > > > application/yang-data+cbor; id=name > > application/yang-data+cbor; id=sid > > Ha. > > Let’s create a registry in yang-cbor for id= values (initially filled with id=name). > -sid can then register id=sid in that. He? yang-cbor defines how to use sids as ids so I see no reason to not also register the id=sid in yang-cbor. I thought we settled on yang-cbor defines what sids are and the sid id details how they are assigned and how the number space is managed. This way, yang-cbor is the base document and the sid document has a normative reference to yang-cbor and comi has a normative reference to yang-cbor. Is there a reason that speaks against this? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Apr 8 04:56:00 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2353A0769; Wed, 8 Apr 2020 04:55:53 -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 6liFV9wzN73Z; Wed, 8 Apr 2020 04:55:51 -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 6E30D3A076E; Wed, 8 Apr 2020 04:55:50 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 48y2m42g7nz10Gw; Wed, 8 Apr 2020 13:55:48 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <20200408115029.sfcm2p4gebai3y74@anna.jacobs.jacobs-university.de> Date: Wed, 8 Apr 2020 13:55:47 +0200 Cc: core , NetMod WG , Ivaylo Petrov X-Mao-Original-Outgoing-Id: 608039747.7926379-e359bd8fff38faa4d778885139f6e312 Content-Transfer-Encoding: quoted-printable Message-Id: <0CBA1A2B-E7D0-4A9E-92C0-13F87974F971@tzi.org> References: <20200331110237.zbo3zw74xlccur3w@anna.jacobs.jacobs-university.de> <20200407194758.luxnndxxsuixhzfo@anna.jacobs.jacobs-university.de> <16670AE8-DE0D-4444-9F64-ED6C67654886@tzi.org> <20200408065738.l7jnht536vxzacse@anna.jacobs.jacobs-university.de> <0817C3C8-420A-4994-89D4-2CDA150F682B@tzi.org> <20200408115029.sfcm2p4gebai3y74@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] [netmod] js review of draft-ietf-core-yang-cbor-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, 08 Apr 2020 11:55:54 -0000 >> Ha. >>=20 >> Let=E2=80=99s create a registry in yang-cbor for id=3D values = (initially filled with id=3Dname). >> -sid can then register id=3Dsid in that. >=20 > He? yang-cbor defines how to use sids as ids so I see no reason to not > also register the id=3Dsid in yang-cbor. I thought we settled on > yang-cbor defines what sids are and the sid id details how they are > assigned and how the number space is managed. This way, yang-cbor is > the base document and the sid document has a normative reference to > yang-cbor and comi has a normative reference to yang-cbor. Is there > a reason that speaks against this? Hi, The media type could simply say =E2=80=9Cuses the concept of SIDs=E2=80=9D= or it could say =E2=80=9Cuses SIDs as allocated in -sid=E2=80=9D. I=E2=80=99m not sure the media type needs to say anything at all about = this, but if it does, for completeness I think it would need to do the = latter (so we can have other media types that get their SIDs elsewhere). That would mean a normative reference from yang-cbor to -sid. The registry trick turns that around. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 8 05:07:36 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915103A0803 for ; Wed, 8 Apr 2020 05:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXL366rwmrKL for ; Wed, 8 Apr 2020 05:07:27 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 E844B3A080F for ; Wed, 8 Apr 2020 05:07:26 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id z7so4881844wmk.1 for ; Wed, 08 Apr 2020 05:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ubyz84biSrkTHonihLNtGJxzih6focFYjnRCj+00tDo=; b=dYMTI8emdj9rGILjRm/76QESc6DnYWes8FGfTFlF1SLQN1r8Bbs4gHOimc8PA0qfqw sZBEPMt5eQH1ShllqDrAjzu7Ax1GxAbIy4oIgvqvS2yUHIk61zROhzoHhoSRYrNoqLMD Ppsy1/y9z9Rn6whk7MRYxACwdKrU6+fm9pz41lJmSKJ0ZdzoiQ0PpHUBoWmwQIVwiXxn xLGDsNL8laGl5vrkX8ubLrXpcjAbsZi33rF6QJreH481zykwMCSvPwAzp5z7ffcq1Wlx zNM9udiAeLIi4fCUBZqLHySkH3HXe2hPUlX19JjGmwbCb6S1Zm5WQhpMmjSaurtFeTbx ShSg== 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=ubyz84biSrkTHonihLNtGJxzih6focFYjnRCj+00tDo=; b=U4hZLlKfIHbGFgXOiiZ1XmJe6wwwW3hwdLU+0iqp8VW/c4lPPaNke39y61aKoUZsL1 EpLVU50C3b870PN9g2BbfFB+KPu/naEVUw8AdTj+xAebHDBWUSj2NiCFQd1+EzZpImv5 zUXGw2RGT5FMCXX9IypcyC7P2O8EmeqZne+aKXFOd92a33ksnvlPme2jg07rwRcHNHB8 Qqvyky0LVPPe9qjCXswJ/TCKTrpUFQe6JVhrqPg07xH9z+Xhr0Bbs/10NcUwabHroWKR 7iQMb8OKE28ptaLm8Vp3WQvKo2nVBx/B6wMHHnyWruYxyukT91QOZjyRnqPuK9Yhr190 EayA== X-Gm-Message-State: AGi0PuaF9EyvJEB0majhdib+6RvXj8iM1uZNYjOiB23H9U/z0As6aDSk c6wBZ3opX0cfMY1QGtBGW/Fg9yoAIrlAZs+ql6GgAQ== X-Google-Smtp-Source: APiQypIL/8bUdY/YEF5bOZG6qmV6MA6+EWwiT5/xaqSLmarN71upmD7lztN6B6EKY8PqkYnLGuGcONHa1dKe3bZoJPI= X-Received: by 2002:a1c:5502:: with SMTP id j2mr4405367wmb.93.1586347645337; Wed, 08 Apr 2020 05:07:25 -0700 (PDT) MIME-Version: 1.0 References: <9AD3C4BB-7965-4776-84C4-6B5BFDCAA262@tzi.org> <15C8F1D1-B560-4D52-8D77-377C6B1C0518@tzi.org> In-Reply-To: From: Ivaylo Petrov Date: Wed, 8 Apr 2020 14:06:59 +0200 Message-ID: To: tom petch Cc: core , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e4168605a2c65739" Archived-At: Subject: Re: [core] =?utf-8?q?=5Bnetmod=5D_=F0=9F=94=94_admin_WG_Last_Call_of?= =?utf-8?q?_CORECONF_drafts=3A_draft-ietf-core-yang-yang-library-01?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 12:07:33 -0000 --000000000000e4168605a2c65739 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Tom, Thank you for your review and your comments! They were indeed very helpful. I will try to spend some more time making sure we follow the recommendations from RFC8407, but for now please find my answers below (prefixed with [IP]). Note that the diff after handing your comments can be found at [1] for the txt file diff and [2] for the raw Markdown diff. Best regards, Ivaylo [1]: https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-yang-library&url2=3Dh= ttp://core-wg.github.io/yang-cbor/draft-ietf-core-yang-library-latest.txt [2]: https://github.com/core-wg/yang-cbor/commit/2aa29f2468c827fd4b58cad6a5decba= 795d9c767 On Mon, Mar 30, 2020 at 12:11 PM tom petch wrote: > There is quite a lot wrong with the admin of the YANG-library I-D when > compared with RFC8407 IMHO > > Security considerations does not conform to boiler plate > [IP]: Adding the following text in the beginning of the security considerations will make it follow the same structure as RFC7895. Would that be acceptable for you? The YANG module defined in this memo is designed to be accessed via CORECON= F {{-comi}}, NETCONF {{RFC6241}} or RESTCONF {{RFC8040}}. Depending on the used protocol, the security considerations of some or all of those will apply. > IANA considerations does not register name space > [IP]: I added such registration. Please let me know if it looks fine. The relevant text is: ## YANG Namespace Registration This document registers the following XML namespace URN in the "IETF XML Registry", following the format defined in {{RFC3688}}: URI: please assign urn:ietf:params:xml:ns:yang:ietf-constrained-yang-librar= y Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. > RFC 6991 is imported and so MUST be a Normative reference > [IP]: Fixed > ietf-sid-file is imported and so MUST be a Normative not Informative > reference for the I-D > [IP]: Fixed reference ietf-core-sid would be better as RFC YYYY with an RFC Editor note > asking them to replace YYYY with the number assigned to 'YANG Schema ... > [IP]: Fixed > Organization Netconf WG seems an odd choice and contradicts contact detai= ls > [IP]: Changed to CoRE WG > Contact does not normally specify WG Chairs > > [IP]: I removed the chairs and left only the group and the editors. Is that what you had in mind? more than one revision clause > [IP]: Fixed > CORECONF not an abbreviation I recognise > [IP]: We have received other comments related to this. We will discuss them during the meeting today and try to clarify this. > I will look some more as and when these are addressed (or I see IETF Last > Call:-) > > Tom Petch > ________________________________________ > From: netmod on behalf of Carsten Bormann < > cabo@tzi.org> > Sent: 09 March 2020 13:04 > To: core > Cc: netmod@ietf.org > Subject: [netmod] =F0=9F=94=94 WG Last Call of CORECONF drafts: > draft-ietf-core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01 > > It took us a long time to get the four CORECONF drafts in sync, > but now we are ready for WGLC. > > This starts a working group last call for > =E2=80=94 draft-ietf-core-yang-cbor-12 > =E2=80=94 draft-ietf-core-sid-11 > =E2=80=94 draft-ietf-core-comi-09 > =E2=80=94 draft-ietf-core-yang-library-01 > > ending on > > 24:00 UTC on Tuesday, March 31, 2020. > > (This includes some extra time for the IETF week and for cross-WG > coordination.) > > This WGLC is copied to the netmod WG mailing list; please do have a look > at these drafts as they are slated to become a part of the greater > YANG/NETCONF/RESTCONF family. We intend the discussion to be on the > CoRE mailing list, but if you find a fundamental issue with YANG or > RESTCONF, feel free to discuss that on netmod instead. > > Please start a new email thread for each major issue that will need > discussion and make sure the subject line includes the draft name and > some sort of name for the issue. (Minor issues such as typos can also > be sent to the authors.) > > If you read the draft and think it looks fine, please send a one line > email to the list or to the chairs letting us know that so we can get > a feel of how broad the review has been. > > (To reviewers and authors:) If you are aware of any patent claims that > might apply to systems that implement these drafts, please review BCP 78 > and BCP 79 and make any appropriate IPR declaration before the last-call > ends. If you are not sure whether you need to make a declaration or not, > please talk to the chairs and we will help. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000000000000e4168605a2c65739 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Tom,
<= div class=3D"gmail_default" style=3D"color:rgb(34,34,34)">
Thank you for your review and your=C2=A0com= ments! They were indeed very helpful. I will try to spend some more time ma= king sure we follow the recommendations from RFC8407, but for now please=C2= =A0find my answers below (prefixed with [IP]= ). Note that the diff after handing your comments=C2=A0can be found at [1] for the txt= file diff and [2] for the raw Markdown diff.=C2=A0

= Best regards,
Ivaylo

[1]:=C2=A0https://tools.ietf.org/rfcdiff?u= rl1=3Ddraft-ietf-core-yang-library&url2=3Dhttp://core-wg.github.io/yang= -cbor/draft-ietf-core-yang-library-latest.txt
[2]:=C2=A0https://github.com/core-wg/yang-cbor/commit/2aa29f2468c827fd4b58cad6a5de= cba795d9c767


On Mon, Mar 30, 2020 at 12:11 PM t= om petch <ietfc@btconnect.com<= span style=3D"font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">&= gt; wrote:
There is quite a lot wrong with the admi= n of the YANG-library I-D when compared with RFC8407 IMHO

Security considerations does not conform to boiler plate

[IP]: Adding= =C2=A0the following text in=C2=A0the beginning of the security consideratio= ns will make it follow the same structure as RFC7895. Would that be accepta= ble for you?

The YANG module defined in this memo is designed t= o be accessed via CORECONF
{{-co= mi}}, NETCONF {{RFC6241}} or RESTCONF {{RFC8040}}. Depending on the used
protocol, the security considerati= ons of some or all of those will apply.
=C2=A0
IANA considerations does not register name space

<= /div>[IP]: I added such registration. Please let me= know if it looks fine. The relevant text is:

## YANG Namespace Registration

This document registers the following XML namespace URN in the "= IETF XML
Registry", following the form= at defined in {{RFC3688}}:

URI: please assign urn:ietf:params:xml:ns:yang:ietf-co= nstrained-yang-library

Registrant Contact: The IESG.

XML: N/A, the requested URI is an = XML namespace.
=C2=A0
RFC 6991=C2=A0 is imported and so MUST b= e a Normative reference

[IP]: Fixed
=C2=A0
ietf-sid-file is imported and so MUST be a Normative=C2=A0 not Informative = reference for the I-D

[IP]: Fixed

reference ietf-core-sid would be better as RFC YYYY with an RFC Editor note= asking them to replace YYYY with the number assigned to 'YANG Schema .= ..

[IP]: Fixed
= =C2=A0
Organization Netconf WG seems an odd choice and contradicts contact details=
=C2=A0
[IP]: Changed to = CoRE WG
=C2=A0
Contact does not normally specify WG Chairs


[IP]: I removed the= chairs and left only the group and the editors. Is that what you had in mind?

more than one revision clause
=C2=A0
[IP]: Fixed
=C2=A0
CORECONF not an abbreviation I recognise

[IP]: We have received other comments related to this.= We will discuss them during the meeting today and try to clarify this.=C2=A0
I will look some more as and when these are addressed (or I see IETF Last C= all:-)

Tom Petch
________________________________________
From: netmod <netmod-bounces@ietf.org> on behalf of Carsten Bormann <cabo@tzi.org>
Sent: 09 March 2020 13:04
To: core
Cc: netmod@ietf.org
Subject: [netmod] =F0=9F=94=94 WG Last Call of CORECONF drafts: draft-ietf-= core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01

It took us a long time to get the four CORECONF drafts in sync,
but now we are ready for WGLC.

This starts a working group last call for
=E2=80=94 draft-ietf-core-yang-cbor-12
=E2=80=94 draft-ietf-core-sid-11
=E2=80=94 draft-ietf-core-comi-09
=E2=80=94 draft-ietf-core-yang-library-01

ending on

=C2=A0 =C2=A0 =C2=A0 =C2=A0 24:00 UTC on Tuesday, March 31, 2020.

(This includes some extra time for the IETF week and for cross-WG
coordination.)

This WGLC is copied to the netmod WG mailing list; please do have a look at these drafts as they are slated to become a part of the greater
YANG/NETCONF/RESTCONF family.=C2=A0 We intend the discussion to be on the CoRE mailing list, but if you find a fundamental issue with YANG or
RESTCONF, feel free to discuss that on netmod instead.

Please start a new email thread for each major issue that will need
discussion and make sure the subject line includes the draft name and
some sort of name for the issue.=C2=A0 (Minor issues such as typos can also=
be sent to the authors.)

If you read the draft and think it looks fine, please send a one line
email to the list or to the chairs letting us know that so we can get
a feel of how broad the review has been.

(To reviewers and authors:)=C2=A0 If you are aware of any patent claims tha= t
might apply to systems that implement these drafts, please review BCP 78 and BCP 79 and make any appropriate IPR declaration before the last-call ends. If you are not sure whether you need to make a declaration or not, please talk to the chairs and we will help.

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

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--000000000000e4168605a2c65739-- From nobody Wed Apr 8 05:34:47 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610373A0964 for ; Wed, 8 Apr 2020 05:34:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=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=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVIzImeHDwa0 for ; Wed, 8 Apr 2020 05:34:43 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70084.outbound.protection.outlook.com [40.107.7.84]) (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 137083A095E for ; Wed, 8 Apr 2020 05:34:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dhbtnaU+NzyGkcq/G9oRoysTTeNtPMGBuscxcxsKZzBNbe/1YiudMB/SNy1FDGNR2x+4xO1P15dqJv5BVY8HTJc76S9IjGjLJgRsaLx6+WXQ43FmmAQZrwj0Q+6C6WhnWIUCIqdwj5fbOu5PkgZW6+/KZ33tPvgyCA0MRaCdcEekTei4fFx+u8nsaU+cdDsHP81u8WdwcIZEbNT9oaosN7HPUQwVFMeUKfUdEfmJMzUTdWiWAQ6G+azOCghnNQDJjt4vdGXpoIL8BviNM/1jfCvdkCHHFiDg17ZXGQVSgQMkkXxCCfJbYyZ9ymmPLmathpK9NOZ5falBcVE5XPEiCg== 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=Otgj9sDWpFhpVahjVdSYQS38G6kLY8dNa5y58v8aZxo=; b=Eu7od9tZqmIuFc4Wn/IuoXq7dbCSjkur4X/A+5VGUkbL4FGLE1fZ8JjVaDdjFOuqfeVqUDU9dN/0JKw9Gyx/DiXqsW4KA2bF2f7czcOTRI7HW9EBJrDPWdhcwEWfBqUYGJ9NO6f1Ndy1QcD2+ziNJi4p0n0MJp+u3zEUryS2y6zbE0+FHPVdCz2/nj6fN9XRR8Tym39q9xl2fAjtsS4QsTnrFJuvh+DFORboCdBswO5JEI+ihrCZUe+I9s4RTRwaXZwCaQN4oySBpVRzcDaayeGmnBLSuM0+eBfhukFJtImG9O7Vk+Kpq7pBfwJCimkWDWWVnVMhsO2eJxS+nA73TQ== 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=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Otgj9sDWpFhpVahjVdSYQS38G6kLY8dNa5y58v8aZxo=; b=AS0sE60VAHoXHs13EVcaCXuLu6HhX724QOsPsi3eNS9QlGfB9/6XpVYl9f8hPQ0VWen6RpXZ//wwuiLC/jUZ74wKu/FZOPs5fU1E3TapFKYkpkyWA5U62z50OR1WRpWCPxfb4l7CCAR/MIE1xHcfmDdi4QVVISuxcM2NwmJ8JbY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0590.EURP189.PROD.OUTLOOK.COM (10.165.197.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19; Wed, 8 Apr 2020 12:34:38 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2878.021; Wed, 8 Apr 2020 12:34:38 +0000 To: core@ietf.org References: <789d189c-619c-7f06-0f0a-fc68b2262a51@ri.se> <4e258729-37d1-46fd-9907-a43354af50d5@www.fastmail.com> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <7101c64f-9ba6-fe38-0bdc-48062556e849@ri.se> Date: Wed, 8 Apr 2020 14:34:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 In-Reply-To: <4e258729-37d1-46fd-9907-a43354af50d5@www.fastmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xUMAglWIjQX3ZQg1apF4Ci0vJROQrqnqF" X-ClientProxiedBy: HE1P190CA0003.EURP190.PROD.OUTLOOK.COM (2603:10a6:3:bc::13) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.5] (185.76.9.97) by HE1P190CA0003.EURP190.PROD.OUTLOOK.COM (2603:10a6:3:bc::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Wed, 8 Apr 2020 12:34:37 +0000 X-Originating-IP: [185.76.9.97] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9820f98c-f3f3-4493-a08c-08d7dbb933c6 X-MS-TrafficTypeDiagnostic: VI1P189MB0590: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-Forefront-PRVS: 0367A50BB1 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(366004)(396003)(39860400002)(136003)(376002)(36756003)(5660300002)(956004)(16799955002)(31686004)(66476007)(66556008)(86362001)(66946007)(31696002)(2906002)(52116002)(33964004)(316002)(81166007)(478600001)(16576012)(53546011)(6486002)(44832011)(2616005)(8936002)(81156014)(8676002)(235185007)(26005)(966005)(186003)(16526019)(21480400003)(66574012)(6916009)(6666004); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: ri.se does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 31KyqV2B/pyq9w3oVbbSoJzX4zXtDZ6bAaGf2wJvLA0A3u8npk5OR0gY1fdk9i3+5SWAqx2BwcDK1uakD2pctyPPHAqLaNASLY6EhAehzk5cHLqnCsLsJdb/Hc7RmEWoQJmKAdHbY2QShhEnuWhYnHQ1UsjNki8Ylob/KQUHYv7HpA6sHL9teDLhLPk0Z4Htq6lrxw/BqLu2JrEt7w751MN2CH4y4/C+Xpn26L17GzU5EfuK16VzQEEyTj754oF8ExicfvPntj93jw/c32mDF96k1v1EeJLUWIuvkR+WYOQkrQdaj7dVt9jE+FfL6XMZJ3+UXn/pfA+g0e7OMl1cse3IyDr91X3obRu/jHVpx4xYIjUsiolwUVxXH2Ow0wvhGjaeCpui72ZSeL21/bTvLmqspGKQKUnCgCHlHbyXuZf3ruoMnG4tDTHNFaXICLboCDULV2bx6o248bRuAsEqhPWQHFSKkw/pu5JvOKO+nxHnPrQKFMvTspzcfP1JXh67JdhvJoogoKDRIQTLSCFgog== X-MS-Exchange-AntiSpam-MessageData: 8J5vQ/kIFkbCybmyLlV5JQoFzXvyqXe31YCF7T83127X7DKLCH9zKjhH/ZhDRavZUeZPXhshGp/MObDP9yQoVgSaAWVvOHpTs0Td+wG51Ld0QmWQKCrlVBu4aU479iCSGGdRo8eM3vUk00AO2VRxhw== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 9820f98c-f3f3-4493-a08c-08d7dbb933c6 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2020 12:34:38.3220 (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: 4WvvTVyM0PsxhkQsMopNKiv0f0nSkUW7QRLaogXPy7kRDxCVenmHeapDg4Nsu9o3pqrWKIIM+X8XukTK6jwfBw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0590 Archived-At: Subject: Re: [core] Upcoming CoRE Virtual Meetings 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, 08 Apr 2020 12:34:46 -0000 --xUMAglWIjQX3ZQg1apF4Ci0vJROQrqnqF Content-Type: multipart/mixed; boundary="98jFtzPoVQmwje1jh4sGRwkCoacIfQ6Sq" --98jFtzPoVQmwje1jh4sGRwkCoacIfQ6Sq Content-Type: multipart/alternative; boundary="------------44C4996819D6C79F1E263571" Content-Language: en-US This is a multi-part message in MIME format. --------------44C4996819D6C79F1E263571 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all, Just a reminder that we will start our CoRE virtual session in less than 30 minutes, i.e. at 13:00 UTC. Please, see below for related information and links. Talk to you soon, Marco and Jaime Meeting entry: https://datatracker.ietf.org/meeting/interim-2020-core-01/session/core Agenda: https://datatracker.ietf.org/doc/agenda-interim-2020-core-01-core-01/ Etherpad: https://etherpad.ietf.org/p/notes-ietf-107-core?useMonospaceFont=3Dtrue Jabber: xmpp:core@jabber.ietf.org?join =C2=A0=C2=A0 For the virtual microphone queue, you may want to say "help = q" Join by Webex =C2=A0=C2=A0 URL: https://ietf.webex.com/ietf/j.php?MTID=3Dm355f196a763aa1549467110e081b5b7= 6 =C2=A0=C2=A0 Meeting number (access code): 616 017 942 =C2=A0=C2=A0 Meeting password: constrained Join by Phone =C2=A0=C2=A0 1-650-479-3208 Call-in number (US/Canada) =C2=A0=C2=A0 1-877-668-4493 Call-in toll free number (US/Canada) =C2=A0=C2=A0 Access code: 616 017 942 =C2=A0=C2=A0 Toll-free calling restrictions: =C2=A0=C2=A0 https://www.webex.com/pdf/tollfree_restrictions.pdf On 2020-04-06 13:10, Jaime Jim=C3=A9nez wrote: > Dear core, > > in order to run the CoRE Virtual meetings smoothly we'd like to send a > reminder of the following: > > - Those who are going to be presenting slides on Wednesday the 8th. > Please send us the slides already *today*=C2=A0at the latest.=C2=A0 You= can use > pptx or pdf format. We will upload them > to=C2=A0https://github.com/core-wg/wg-materials/tree/master/ietf107=C2=A0= =2E > > - We will be using Webex for the virtual meetings, however the queue > management will be done over jabber. If you haven't already, please > set up a jabber account (https://ietf.org/how/meetings/jabber/=C2=A0) a= nd > join the group=C2=A0core@jabber.ietf.org > =C2=A0group. If you cannot, you can still = use > the webex chat during the meeting and we'll add you manually to the > queue. We will explain about this during the meeting too. > > Ciao! > --=C2=A0 > Jaime Jim=C3=A9nez > > > > On Tue, Mar 31, 2020, at 12:01 AM, Marco Tiloca wrote: >> Hello CoRE, >> >> The two virtual meetings replacing IETF 107 are confirmed for the >> intended days and times, as summarized below. >> >> [Meeting 1] >> Date and time: 8th of April 2020, 13:00-15:00 UTC [1] >> Webex link: >> https://ietf.webex.com/webappng/sites/ietf/meeting/info/12f03cd44d7d40= 79b925586135df03ee >> >> [Meeting 2] >> Date and time: 16th of April 2020, 13:00-14:30 UTC [2] >> Webex link: >> https://ietf.webex.com/webappng/sites/ietf/meeting/info/1ccf8929f40d4f= f2a6ff4a6b46521a12 >> >> Like in regular IETF meetings, we plan to also use Jabber. In particul= ar >> also for the virtual microphone queue, you may want to say =E2=80=9Che= lp q=E2=80=9D in >> xmpp:core@jabber.ietf.org?join >> >> >> The planned agenda for both meetings is available at: >> >> https://github.com/core-wg/wg-materials/blob/master/ietf107/core-107-a= genda.md >> >> Please, provide the chairs with the intended objectives for your >> pertaining time slot and the name of the intended discussion >> leader/presenter, if they are not included already. >> >> Finally, please send your slides to the chairs: >> >> - By the 6th of April for the first meeting. >> - By the 14th of April for the second meeting. >> >> Consolidated slides will be also made available at: >> https://github.com/core-wg/wg-materials/tree/master/ietf107 >> >> Best, >> Marco and Jaime >> >> >> [1] >> https://www.timeanddate.com/worldclock/meetingdetails.html?year=3D2020= &month=3D4&day=3D8&hour=3D13&min=3D0&sec=3D0&p1=3D239&p2=3D179 >> >> [2] >> https://www.timeanddate.com/worldclock/meetingdetails.html?year=3D2020= &month=3D4&day=3D16&hour=3D13&min=3D0&sec=3D0&p1=3D239&p2=3D179 >> >> --=C2=A0 >> Marco Tiloca >> Ph.D., Senior Researcher >> >> RISE Research Institutes of Sweden >> Division ICT >> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 >> SE-164 40 Kista (Sweden) >> >> Phone: +46 (0)70 60 46 501 >> https://www.ri.se >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> >> *Attachments:* >> >> * signature.asc >> > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --------------44C4996819D6C79F1E263571 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all,

Just a reminder that we will start our CoRE virtual session in less than 30 minutes, i.e. at 13:00 UTC.

Please, see below for related information and links.

Talk to you soon,
Marco and Jaime


Meeting entry:
https://datatracker.ietf.org/me= eting/interim-2020-core-01/session/core

Agenda: https://datatracker.ietf.org= /doc/agenda-interim-2020-core-01-core-01/

Etherpad: https://etherpad.ietf.org/= p/notes-ietf-107-core?useMonospaceFont=3Dtrue

Jabber: xmpp:core@jabber.ietf.org?join
=C2=A0=C2=A0 For the virtual microphone queue, you may want to say "h= elp q"

Join by Webex
=C2=A0=C2=A0 URL: https://ietf.webex.com/= ietf/j.php?MTID=3Dm355f196a763aa1549467110e081b5b76
=C2=A0=C2=A0 Meeting number (access code): 616 017 942
=C2=A0=C2=A0 Meeting password: constrained

Join by Phone
=C2=A0=C2=A0 1-650-479-3208 Call-in number (US/Canada)
=C2=A0=C2=A0 1-877-668-4493 Call-in toll free number (US/Canada)
=C2=A0=C2=A0 Access code: 616 017 942
=C2=A0=C2=A0 Toll-free calling restrictions:
=C2=A0=C2=A0 https://www.webex.com/pdf/tollfre= e_restrictions.pdf


On 2020-04-06 13:10, Jaime Jim=C3=A9ne= z wrote:
=

Hello All,

 

I participate in the OMA LwM2M specification develop= ment group. I had included additional attributes in our Core Specification = to guide the UE on measurement reporting.

 

Please consider the issue https://github.com/core-wg/dynlink/issues/18 for inclusion in any updat= e to the Dynlink draft.

 

Please let me know if I should attend a meeting to j= ustify my request, and I will provide any additional required information.<= o:p>

 

Thank you for your consideration,

Alan Soloway

 

--_000_CY4PR02MB2501A8028621422DBED96796E3DD0CY4PR02MB2501namp_-- From nobody Mon Apr 13 15:23:40 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431753A1F6F for ; Mon, 13 Apr 2020 15:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si4w-H8RTB9Q for ; Mon, 13 Apr 2020 15:23:35 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AB473A1F6E for ; Mon, 13 Apr 2020 15:23:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8559B3818F; Mon, 13 Apr 2020 18:21:46 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E2ACEE0A; Mon, 13 Apr 2020 18:23:26 -0400 (EDT) From: Michael Richardson To: Ivaylo Petrov cc: core In-Reply-To: References: <26233.1585585343@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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] comments on CORECONF drafts in WGLC 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, 13 Apr 2020 22:23:39 -0000 --=-=-= Content-Type: text/plain Ivaylo Petrov wrote: >> The security considerations, and authorization for this system is >> underspecified. This was ultimately was killed SNMPv2, and led to a >> multi-decade long failure of SNMPv3. >> I suspect that this part will have a difficult time with security ADs. >> > [IP]: I tried to improve this section to some extent. Please let me know if > you have other ideas. Text contribution is always welcomed as well. It's better. > [IP]: I added an informational link to ACE, which for me seems as one of > the ways authorization can be handled in COMI. Is this what you have in > mind? I didn't really understand it the addition. > [IP]: I would imagine so. > I disagree with the Security Considerations, that knowing the list of >> modules helps the attacker to the extent that it is important to provide >> specific read controls on it. Attackers already have a copy of the ROM ;-) >> I would say that the entire COMI interface needs authorized read access, >> and >> this module no more than any other module. >> > [IP]: I believe the idea here is that the attacker doesn't necessarily know > which ROM the device is using. Having an easy way to discover that and from > there all the possible vulnerabilities of that device is what we want to > avoid. Otherwise I agree that the entire CoMI interface needs authorized > read access. I believe that the attacker will know exactly what the system under attack is, and likely knows the ROM version, and probably has a copy of that ROM too. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6U5l4ACgkQgItw+93Q 3WVR4Af/VLN1pt5qzGXofHLixtcmbPS9e229KuE/wuLVkUCy7OQhTPBBtjjkY1Wr 0WVE7jsCUa4eVYbT3LGWIA40p12SuJJ6EQvFVi8bQNZqzDTKl2rYXxLGTxyTtPKE Cx4KGI5aLdHcSnxXt31tLcXI4ZuiaUut0PGJX1Ggi630KgBuPNk0xYU6P/0kMGlh CVV2VgxBfEpCm2edDpgEw5lS0ePuwz8A1xRVXBkqux22v1rahMtnuV+IgHFxZoQl v7hZdmuhZSmUIH+Ne+ElUJyJgIpz4kfZV7IByyXesWUmKZs3n31Cg+UppLeLkh/T d/JzT+PaRvzWs8cg2/28Q9We+tbQtQ== =xBxx -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 13 23:20:50 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFCA3A0D85 for ; Mon, 13 Apr 2020 23:20:48 -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, 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=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Mxcf9-bbCeQ for ; Mon, 13 Apr 2020 23:20:46 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 869873A0D84 for ; Mon, 13 Apr 2020 23:20:46 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id u13so12444512wrp.3 for ; Mon, 13 Apr 2020 23:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rC6lzck/p/0rm/YeSmhXegL/32Cj5/GyiwXa37Dfr20=; b=NlxlNIPfPyd/qwAj4Trjodb277e8ew7aIwK6Fl6enxJkzr/8GLQxwhhiH4nI84evl9 g9GsfW0PhNHGmaog55NTR79DIA2mqbAI4ldgo96MLBDasqAIMBc9XtllX5uPAy65S5nY W7ozIU7YtN0xBgNEFBsqxFT38qaCDFbd7dzyLDw3wPY1ty+6fhYTGDjdrD1GHDRFr47q U6KOBANKFgs36xlT4q+WCES7QnbUZwIbiuLpyseppTkxJZosq1CZoOrPpRnlInSg14gY cwPLj57o6n2Kw/c8NwgQTHIJz/sRf3QeydzTcBZ1SsqG99MnJ9uTaW4q4WzhMxwp3FEb Y34g== 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=rC6lzck/p/0rm/YeSmhXegL/32Cj5/GyiwXa37Dfr20=; b=r0xehlQCwACCj9wswypinhspPat9DgOUDKQ238MF57P/98WjX1zZFHixMqpTQRu2R2 ztB9oIeEg2rnbWURFNZgrMopkOnFilueWU5adr7KN9VHqCWpPk2fLrm6HTJwej0ptPJM ekE4fRQ8a9abiHdb/nkUojGEbHdnRZHDKxUinOOFRqauPbSO6L7erOOxLJag7kz/XyEz Yn0G5RrvhaU/bVmhlh84GdqvPtJI19ktSFov0omLz4SEs2spLH5TTUj5Xk3Q1rr1g9pB 6EUxqx6llr/NV5Vv0UQ9HAYjaKBb1jKaylNwCVaYA95uOtk6wHHkIxrdshWYgoVG/o/d 56Ng== X-Gm-Message-State: AGi0Pubmy/ewSPyby24epZ8y9DS5RBjhX9eteZ1+iNicj6dI1vmsG8cO Uf18IXPR97+q+/OWBs49e13GOBuEi2Mn5bDssQ39rV59 X-Google-Smtp-Source: APiQypIokcZO8pggQJfPCCy//Axyskjm91rZb+Re9PdgtUY6fxzbqd97L09w7WP24lJOWejFdwJuPpf2hsuNFexEDlM= X-Received: by 2002:a5d:500b:: with SMTP id e11mr13559110wrt.272.1586845244387; Mon, 13 Apr 2020 23:20:44 -0700 (PDT) MIME-Version: 1.0 References: <26233.1585585343@localhost> <30150.1586816606@localhost> In-Reply-To: <30150.1586816606@localhost> From: Ivaylo Petrov Date: Tue, 14 Apr 2020 08:20:16 +0200 Message-ID: To: Michael Richardson Cc: core Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] comments on CORECONF drafts in WGLC 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, 14 Apr 2020 06:20:49 -0000 Hello Michael, Thank you for the new comments! Please find my answers below. On Tue, Apr 14, 2020 at 12:23 AM Michael Richardson wrote: > > > Ivaylo Petrov wrote: > >> The security considerations, and authorization for this system is > >> underspecified. This was ultimately was killed SNMPv2, and led to a > >> multi-decade long failure of SNMPv3. > >> I suspect that this part will have a difficult time with security ADs. > >> > > > [IP]: I tried to improve this section to some extent. Please let me know if > > you have other ideas. Text contribution is always welcomed as well. > > It's better. > > > [IP]: I added an informational link to ACE, which for me seems as one of > > the ways authorization can be handled in COMI. Is this what you have in > > mind? > > I didn't really understand it the addition. [IP]: Apologies, I forgot to include the relevant text. Here it is: For secure network management, it is important to restrict access to configuration variables only to authorized parties. CoMI re-uses the security mechanisms already available to CoAP, this includes DTLS [RFC6347] and OSCORE [RFC8613] for protected access to resources, as well as suitable authentication and authorization mechanisms, for example those defined in ACE OAuth [I-D.ietf-ace-oauth-authz]. Or maybe you find the new text difficult/impossible to understand? > > > [IP]: I would imagine so. > > > I disagree with the Security Considerations, that knowing the list of > >> modules helps the attacker to the extent that it is important to provide > >> specific read controls on it. Attackers already have a copy of the ROM ;-) > >> I would say that the entire COMI interface needs authorized read access, > >> and > >> this module no more than any other module. > >> > > > [IP]: I believe the idea here is that the attacker doesn't necessarily know > > which ROM the device is using. Having an easy way to discover that and from > > there all the possible vulnerabilities of that device is what we want to > > avoid. Otherwise I agree that the entire CoMI interface needs authorized > > read access. > > I believe that the attacker will know exactly what the system under attack > is, and likely knows the ROM version, and probably has a copy of that ROM too. [IP]: In the security considerations the assumption was made that the attacker does not know what the ROM version is. If the attacker already knows that and therefore likely has a copy of it, then having read access to the yang-library interface will not give him leverage, unless the vulnerability is inside that very component. So without our assumption, the yang-library interface should be protected similarly to any other CORECONF interface. With our assumption, on the other hand, it needs more protection than some other interfaces as, for example, knowing the time on the system gives leverage to the attacker, but does not give him a concrete list of exploits, which identification of the ROM version might give. Considering those two different cases, we have focused the discussion on the more severe danger. Let us know if you think this would be rephrased to include those two cases and discussions about their significance. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > -- Best regards, Ivaylo From nobody Tue Apr 14 06:28:53 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81A53A0E7A for ; Tue, 14 Apr 2020 06:28: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, 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 4LKdHNqOYLqt for ; Tue, 14 Apr 2020 06:28:50 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF533A0E76 for ; Tue, 14 Apr 2020 06:28:49 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 491mXc3hJVz2y19 for ; Tue, 14 Apr 2020 15:28:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1586870928; bh=lQ2BJcxdGTBcOAm9njYv5Vw+ZzOLv7YmNTMcW2sR8oM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=BVJfF+LFY3FJgESui1JC2IT5dEo2G8EUvg6KCcmyEdZUvx70adOIWNa7EhjXR3ZvQ JTJ8MRz5JTo8lCgP1Lemxdy/OLZjA2tBxF1a6gkSrTDzA4DUbuj2PTCnwOh8Ool5PL zV5KJ2CbEtwlRT3nb2u3FLitj/D0YtSVRcoSR8f3AEK9AywDvFduvqiBO4qTNgehX+ 2iEBhkvrnHvmIJfuJNJILGhlK1huCPsng/qcD5z7NNk+NRzJvX3EwMkPow4XDAqs3/ kBXmPUooKJ407irq+kahw7rVyAC0Q3hW1cirlw6D7pQkrD6pQ5mxjrelqO4BsRTjGv 43jjLfol+F8gA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 491mXc2jT3z5vNb for ; Tue, 14 Apr 2020 15:28:48 +0200 (CEST) From: To: "core@ietf.org" Thread-Topic: New Version Notification for draft-bosh-core-new-block-00.txt Thread-Index: AQHWEl/W/Kx+LjW+NESAgd3Y+ur5Tah4m1qQ Date: Tue, 14 Apr 2020 13:28:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031494DF4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158687058384.18108.18222984813247786930@ietfa.amsl.com> In-Reply-To: <158687058384.18108.18222984813247786930@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: [core] TR: New Version Notification for draft-bosh-core-new-block-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: Tue, 14 Apr 2020 13:28:52 -0000 SGkgYWxsLCANCg0KVGhlIGRyYWZ0IGlzIGFib3V0IHRoZSBuZXcgQmxvY2sgb3B0aW9ucyB3ZSBk aXNjdXNzZWQgb24gdGhlIGxpc3QuDQoNClBsZWFzZSByZXZpZXcgYW5kIHNoYXJlIHlvdXIgY29t bWVudHMuIA0KDQpUaGFuayB5b3UuIA0KDQpDaGVlcnMsDQpKb24gJiBNZWQNCg0KLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KRW52b3nDqcKgOiBtYXJkaSAxNCBhdnJpbCAy MDIwIDE1OjIzDQrDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOOyBKb24gU2hhbGxvdw0K T2JqZXTCoDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1ib3NoLWNvcmUtbmV3 LWJsb2NrLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ib3NoLWNvcmUt bmV3LWJsb2NrLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNb2hh bWVkIEJvdWNhZGFpciBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1l OgkJZHJhZnQtYm9zaC1jb3JlLW5ldy1ibG9jaw0KUmV2aXNpb246CTAwDQpUaXRsZToJCU5ldyBD b25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkgQmxvY2stV2lzZSBUcmFuc2Zl ciBPcHRpb25zDQpEb2N1bWVudCBkYXRlOgkyMDIwLTA0LTE0DQpHcm91cDoJCUluZGl2aWR1YWwg U3VibWlzc2lvbg0KUGFnZXM6CQkxOA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ib3NoLWNvcmUtbmV3LWJsb2NrLTAwLnR4dA0KU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvc2gt Y29yZS1uZXctYmxvY2svDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJvc2gtY29yZS1uZXctYmxvY2stMDANCkh0bWxpemVkOiAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWJvc2gtY29yZS1uZXctYmxvY2sN Cg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIG5ldyBDb25zdHJhaW5l ZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkNCiAgIEJsb2NrLVdpc2UgdHJhbnNmZXIgb3B0 aW9uczogQmxvY2szIGFuZCBCbG9jazQgb3B0aW9ucy4gIFRoZXNlDQogICBvcHRpb25zIGFyZSBz aW1pbGFyIHRvIHRoZSBDb0FQIEJsb2NrMSBhbmQgQmxvY2syIG9wdGlvbnMsIGJ1dCBlbmFibGUN CiAgIGZhc3RlciB0cmFuc21pc3Npb25zIG9mIGJpZyBibG9ja3Mgb2YgZGF0YSB3aXRoIGxlc3Mg cGFja2V0DQogICBpbnRlcmNoYW5nZXMgYXMgd2VsbCBhcyBzdXBwb3J0aW5nIGZhc3RlciByZWNv dmVyeSBzaG91bGQgYW55IG9mIHRoZQ0KICAgQmxvY2tzIGdldCBsb3N0IGluIHRyYW5zbWlzc2lv bi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24N CnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K From nobody Wed Apr 15 06:26:42 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A534C3A0775 for ; Wed, 15 Apr 2020 06:26:40 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uylvtixddccF for ; Wed, 15 Apr 2020 06:26:38 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 0F3013A0771 for ; Wed, 15 Apr 2020 06:26:37 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id k11so18534197wrp.5 for ; Wed, 15 Apr 2020 06:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5pfOh5WRVG5cE2Hgza4tjMuROUF7B3sQvt8bZYwTC7Y=; b=a/lwtAny65C99IHt+tFRczaXg+SBGcek2EG/THqCU3FBOw2uWlZiitwpTzSkQpRggm Nx402BXtnKUDIMdAtYMRUTy3KG/oEHR+DDBvDbTcaB0gcxsFeIjpk5Ne7l1aVqizXNC0 Pbi/UEm5zggihWMvkvbocGs3ev7QfrkSj3MOAV04lU6d5iEajullfEVz9j54q0l/3BT+ w73c9YGvCIdJLH9QojQwMlXVMBcfOD/MLlU/pbqNjjAnKBUqLX5Uk+hVorjmWrhbGcri dwZH7imP8gXW5Q3lFawzYLcC8Q+Kcefpkj9Vt2SF3EipAzRFUtkuG2qbdzKpmlMUX7ug OL1w== 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=5pfOh5WRVG5cE2Hgza4tjMuROUF7B3sQvt8bZYwTC7Y=; b=f2eoFPmnY0gv1wWd8wa+UEREz9rfVh3jZd+LNfvIU1BCkeJc/5ePizxLVXvXW0CjvQ bjkNe+VY2zev5MBeZ0y1eKXElA523PfiTtOiBEUA7R+QGYgf2RQQBGHqSCymuMD3Pzk+ gbey+XbjV1F2Cqhf71bjtmpfozXgv4A7NE2UZFDtXtWwmaSdXlrI0H03bUaLwcKJhr0V UVhf4QsQVjqiSCm5v5J21n2zNqkosYPz50mFYUJlip7cHFRXtR+dK8rq9F/FZE4ZJLwj xO7h9iZRWNRz68nJL+fGJFjm27zQsQucXhd/gP3bhruQZtIrFiKDWManNUk1BxveXQqV SoWA== X-Gm-Message-State: AGi0PuYIOB3zLaX3rCNRlRyZ+asiUpRc25p3xD4YECHbQEcUUFZJ20zE 9p90mycSWKorwX9YS2bwpWWJTjFekuEjN72QKv5Y52Nu9aU= X-Google-Smtp-Source: APiQypLHC6ba6gLgM0fihkAa9uUTg+LkvVkqvgbcgoZTqzWx54cQQaTiYu+xGIEgMKEyG0LExvw/ObWE0PKvYodebLE= X-Received: by 2002:adf:e681:: with SMTP id r1mr7640265wrm.213.1586957196264; Wed, 15 Apr 2020 06:26:36 -0700 (PDT) MIME-Version: 1.0 References: <9AD3C4BB-7965-4776-84C4-6B5BFDCAA262@tzi.org> <15C8F1D1-B560-4D52-8D77-377C6B1C0518@tzi.org> In-Reply-To: From: Ivaylo Petrov Date: Wed, 15 Apr 2020 15:26:10 +0200 Message-ID: To: tom petch Cc: core , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f520e605a354433e" Archived-At: Subject: Re: [core] =?utf-8?q?=5Bnetmod=5D_=F0=9F=94=94_admin_WG_Last_Call_of?= =?utf-8?q?_CORECONF_drafts=3A_draft-ietf-core-sid-11?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 13:26:41 -0000 --000000000000f520e605a354433e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Tom, Thank you for your review and your comments! They truly help us improve this document. Please find my answers below (prefixed with [IP]). Note that the diff after handing your comments and those of Esko Dijk and Juergen Schoenwaelder can be found at [1]. Best regards, Ivaylo [1]: https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-sid&url2=3Dhttp://cor= e-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.txt On Mon, Mar 30, 2020 at 1:16 PM tom petch wrote: > Some YANG admin for core-sid > > import must have a reference clause > [IP]: Fixed. such reference must be Normative References for the I-D > [IP]: Fixed. no RFC Editor note to update the date (I know, they will fix that :-) > [IP]: Fixed. contact lacks e-mail of WG > [IP]: Fixed. > IANA Considerations fails to register namespace > [IP]: Fixed. IANA Considerations does not specify a Group name; a well-chosen group name > makes a registry easy to find. Many if not most of the existing Group > names are not well-chosen. Please choose with care. e.g. is this for > constrained devices or for all; is it specific to YANG and will there be > other uses? .... > [IP]: That is a very good point. I am not sure how it is supposed to work - IANA will ask us about the group name when they create the registries or there is some text that we can write to request this. I will follow with a question to the working group with a few options for possible group names. Tom Petch > ________________________________________ > From: netmod on behalf of Carsten Bormann < > cabo@tzi.org> > Sent: 09 March 2020 13:04 > To: core > Cc: netmod@ietf.org > Subject: [netmod] =F0=9F=94=94 WG Last Call of CORECONF drafts: > draft-ietf-core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01 > > It took us a long time to get the four CORECONF drafts in sync, > but now we are ready for WGLC. > > This starts a working group last call for > =E2=80=94 draft-ietf-core-yang-cbor-12 > =E2=80=94 draft-ietf-core-sid-11 > =E2=80=94 draft-ietf-core-comi-09 > =E2=80=94 draft-ietf-core-yang-library-01 > > ending on > > 24:00 UTC on Tuesday, March 31, 2020. > > (This includes some extra time for the IETF week and for cross-WG > coordination.) > > This WGLC is copied to the netmod WG mailing list; please do have a look > at these drafts as they are slated to become a part of the greater > YANG/NETCONF/RESTCONF family. We intend the discussion to be on the > CoRE mailing list, but if you find a fundamental issue with YANG or > RESTCONF, feel free to discuss that on netmod instead. > > Please start a new email thread for each major issue that will need > discussion and make sure the subject line includes the draft name and > some sort of name for the issue. (Minor issues such as typos can also > be sent to the authors.) > > If you read the draft and think it looks fine, please send a one line > email to the list or to the chairs letting us know that so we can get > a feel of how broad the review has been. > > (To reviewers and authors:) If you are aware of any patent claims that > might apply to systems that implement these drafts, please review BCP 78 > and BCP 79 and make any appropriate IPR declaration before the last-call > ends. If you are not sure whether you need to make a declaration or not, > please talk to the chairs and we will help. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000000000000f520e605a354433e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Tom,
Thank you for your review and your comments! They truly help us improve th= is document. Please find my answers below (prefixed with [IP]). Note that t= he diff after handing your comments and those of Esko Dijk and Juergen Scho= enwaelder can be found at [1].

Best regards,
Ivaylo

[1]: <= a href=3D"https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-sid&url= 2=3Dhttp://core-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.txt">http= s://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-sid&url2=3Dhttp://cor= e-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.txt

O= n Mon, Mar 30, 2020 at 1:16 PM tom petch <ietfc@btconnect.com> wrote:
Some YANG admin for core-sid<= br>
import must have a reference clause

[IP]: Fixed.

such reference must be Normative References for the I-D

[IP]: Fixed.

no RFC Editor note to update the date (I know, they will fix that :-)
=C2=A0
[IP]: Fixed.

contact lacks e-mail of WG

[IP]: Fixed.
=C2= =A0
IANA Considerati= ons fails to register namespace

[IP]: Fixed.

IANA Considerations does not specify a Group name; a well-chosen group name= makes a registry easy to find.=C2=A0 Many if not most of the existing Grou= p names are not well-chosen.=C2=A0 Please choose with care. e.g. is this fo= r constrained devices or for all; is it specific to YANG and will there be = other uses? ....

[IP]: That is a very good point. I am not sure how it is suppo= sed to work - IANA will ask us about the group name when they create the re= gistries or there is some text that we can write to request this. I will fo= llow with a question to the working group with a few options for possible g= roup names.

Tom Petch
________________________________________
From: netmod <netmod-bounces@ietf.org> on behalf of Carsten Bormann <cabo@tzi.org>
Sent: 09 March 2020 13:04
To: core
Cc: netmod@ietf.org
Subject: [netmod] =F0=9F=94=94 WG Last Call of CORECONF drafts: draft-ietf-= core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01

It took us a long time to get the four CORECONF drafts in sync,
but now we are ready for WGLC.

This starts a working group last call for
=E2=80=94 draft-ietf-core-yang-cbor-12
=E2=80=94 draft-ietf-core-sid-11
=E2=80=94 draft-ietf-core-comi-09
=E2=80=94 draft-ietf-core-yang-library-01

ending on

=C2=A0 =C2=A0 =C2=A0 =C2=A0 24:00 UTC on Tuesday, March 31, 2020.

(This includes some extra time for the IETF week and for cross-WG
coordination.)

This WGLC is copied to the netmod WG mailing list; please do have a look at these drafts as they are slated to become a part of the greater
YANG/NETCONF/RESTCONF family.=C2=A0 We intend the discussion to be on the CoRE mailing list, but if you find a fundamental issue with YANG or
RESTCONF, feel free to discuss that on netmod instead.

Please start a new email thread for each major issue that will need
discussion and make sure the subject line includes the draft name and
some sort of name for the issue.=C2=A0 (Minor issues such as typos can also=
be sent to the authors.)

If you read the draft and think it looks fine, please send a one line
email to the list or to the chairs letting us know that so we can get
a feel of how broad the review has been.

(To reviewers and authors:)=C2=A0 If you are aware of any patent claims tha= t
might apply to systems that implement these drafts, please review BCP 78 and BCP 79 and make any appropriate IPR declaration before the last-call ends. If you are not sure whether you need to make a declaration or not, please talk to the chairs and we will help.

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

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--000000000000f520e605a354433e-- From nobody Wed Apr 15 06:27:27 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1553A0779 for ; Wed, 15 Apr 2020 06:27:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsTX9fSih61I for ; Wed, 15 Apr 2020 06:27:21 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 DC55B3A0776 for ; Wed, 15 Apr 2020 06:27:20 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id g12so11213173wmh.3 for ; Wed, 15 Apr 2020 06:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NGifetFEu1I2LN0x9KachFFADb01ehQEoX/dHXucKjI=; b=Tc0EJW2WyU4/sNRyNyO0plsUtNN/3S/xK2duk90C00jX3XRry7O48PiSeKg4gylUWp Egz4X8He9f18JelT6tGD/+Of8o+QNxdPhCs0fgI6U0wnbnALtrYTlSe1ktj/aQ+/n1M/ I5BDyeuPWKYm1JFmEEhj0f2M+NFPK83UEJkiV1UGk2lcOWpSHVQXmDsDiucRIhN7UJr5 UzD3FWsPRYImGmBxZx0L0iD/eBZliho5moUd7v2SlJqPm/ByG+3fU0CSwLlsx/0tM1Pf 1rZEYEFKXQiC12jm638/in0g5SdB4FSE1C6kjpk7lQ8emN61ygm6Ma/ic9CchQVGXMPj UWFg== 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=NGifetFEu1I2LN0x9KachFFADb01ehQEoX/dHXucKjI=; b=NVvnRGFIfOlhOZ6zLsWTVJVZVAoWbkEyuffkC/73aSMwmoX0I5oXRUQASdMpltckvp xpisHFqP99x7CEmNuZzwvxG9WnskM21Hfa1qhXyRSvTdsow72Q8FYGuT8czqpBOIO5Nz FB7l5a3Drr7WHc5B/ThPmIQGnaGWsfrAVX4HuqHrGgR9QfWil3O9T3cLIaUsh8ZisHIX jAa7a3vz4Zi3eGwW26OozD420RRpa+B0g8bFyohd19mUVVszi2HjBnX2Z80PqXl+mn13 YX0W0ALTaqXo/FBIuVc3AU12a98kMw5DSI3K87zGt1QWT2lxR8+qhGgwnfRfafVpAb0k nvtg== X-Gm-Message-State: AGi0PuYWjhtJbHWJ7gPdOOHvBmTuLFHq/bNrjfJwQe02dG+zbZBJKow0 cf41/bU05kcVWVxhYew9Z/D/0JL+RbFQWJfUP5uGWw== X-Google-Smtp-Source: APiQypJUs8LJ6NENJbr6+CkySim+rGHg9zP9hw+gA5mk91OuYWJp//G2igjQMuLap4Syg7mRhFGoH8XEzJLU1toAZHc= X-Received: by 2002:a1c:32c7:: with SMTP id y190mr5547617wmy.13.1586957239192; Wed, 15 Apr 2020 06:27:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ivaylo Petrov Date: Wed, 15 Apr 2020 15:26:52 +0200 Message-ID: To: Esko Dijk Cc: "core@ietf.org WG" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008424ed05a3544640" Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_CORECONF_drafts=3A?= =?utf-8?q?_draft-ietf-core-yang-cbor-12=2C_-sid-11=2C_-comi-09=2C_-yang-l?= =?utf-8?q?ibrary-01_/_-sid-11_review?= 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, 15 Apr 2020 13:27:25 -0000 --0000000000008424ed05a3544640 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Esko, Thank you for your review and your comments! They do help us improve this document. Please find my answers below (prefixed with [IP]). Note that the diff after handing your comments and those of Juergen Schoenwaelder can be found at [1]. Best regards, Ivaylo [1]: https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-sid&url2=3Dhttp://cor= e-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.txt On Mon, Mar 30, 2020 at 1:17 PM Esko Dijk wrote: > Hello CoRE, > > I did a quick review of the -sid-11 draft; it looks ready for publication= . > Some minor issues found : > > Reference to RFC 7120 early allocation procedure: the allocation policies > for the registries are all "Expert review". And the RFC 7120 early > allocation procedure is defined, to do early allocations. However RFC 712= 0 > mentions that this procedure only applies in case : > (Section 2) > a. The code points must be from a space designated as "RFC > Required", "IETF Review", or "Standards Action". Additionally, > requests for early assignment of code points from a > "Specification Required" registry are allowed if the > specification will be published as an RFC. > So at first sight it looks like the procedure is not applicable, taken > strictly. However IANA indicates ( > https://www.iana.org/help/protocol-registration) that "Expert review" is > part of "Specification Required" so it would apply still. But in RFC 8126 > this is not mentioned in the same manner - so it could confuse some reade= rs > about whether it applies or not. Maybe some text could be added to state > why RFC 7120 process does apply to the "Expert review" policy, even thoug= h > "Expert review" is not listed under Section 2 point a. of RFC 7120. (Not= e > that early allocation by RFC 7120 only applies to "Expert review" > allocations for draft documents that aim to become RFC.) > [IP]: We are in the process of reformulating this. Section 6.3.3: table column 1 is very narrow and it breaks the entry point > integer number, which is confusing. Why not make this column wider by one > character? One of the last 2 columns can be made more narrow if needed. > [IP]: Fixed. Section 3: "RESCONF" -> RESTCONF > [IP]: Fixed. > Section 3: CoRECONF -> CORECONF > [IP]: Fixed. Section 3: "For example how this could be achieved, please refer to" > -> For examples on how this could be achieved, please refer to > [IP]: Fixed. Section 3: "For diagram of one" > -> For a diagram of one ... > [IP]: Fixed. Best regards > > Esko > > IoTconsultancy.nl | Email/Skype: esko.dijk@iotconsultancy.nl > > > > -----Original Message----- > From: core On Behalf Of Carsten Bormann > Sent: Monday, March 9, 2020 14:05 > To: core > Cc: netmod@ietf.org > Subject: [core] =F0=9F=94=94 WG Last Call of CORECONF drafts: > draft-ietf-core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01 > > It took us a long time to get the four CORECONF drafts in sync, > but now we are ready for WGLC. > > This starts a working group last call for > =E2=80=94 draft-ietf-core-yang-cbor-12 > =E2=80=94 draft-ietf-core-sid-11 > =E2=80=94 draft-ietf-core-comi-09 > =E2=80=94 draft-ietf-core-yang-library-01 > > ending on > > 24:00 UTC on Tuesday, March 31, 2020. > > (This includes some extra time for the IETF week and for cross-WG > coordination.) > > This WGLC is copied to the netmod WG mailing list; please do have a look > at these drafts as they are slated to become a part of the greater > YANG/NETCONF/RESTCONF family. We intend the discussion to be on the > CoRE mailing list, but if you find a fundamental issue with YANG or > RESTCONF, feel free to discuss that on netmod instead. > > Please start a new email thread for each major issue that will need > discussion and make sure the subject line includes the draft name and > some sort of name for the issue. (Minor issues such as typos can also > be sent to the authors.) > > If you read the draft and think it looks fine, please send a one line > email to the list or to the chairs letting us know that so we can get > a feel of how broad the review has been. > > (To reviewers and authors:) If you are aware of any patent claims that > might apply to systems that implement these drafts, please review BCP 78 > and BCP 79 and make any appropriate IPR declaration before the last-call > ends. If you are not sure whether you need to make a declaration or not, > please talk to the chairs and we will help. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0000000000008424ed05a3544640 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Esko,

Th= ank you for your review and your=C2=A0comments! They do help us improve thi= s document. Please find my answers below (prefixed with [IP]). Note that th= e diff after handing your comments and those of=C2=A0Juergen Schoenwaelder can be found = at [1].=C2=A0=

Best regards,
<= font color=3D"#000000">Ivaylo

[1]: https://tools.ietf.org/rfcdiff?= url1=3Ddraft-ietf-core-sid&url2=3Dhttp://core-wg.github.io/yang-cbor/dr= aft-ietf-core-sid-latest.txt


On = Mon, Mar 30, 2020 at 1:17 PM Esko Dijk <esko.dijk@iotconsultancy.nl> wrote:=
Hello CoRE,

I did a quick review of the -sid-11 draft; it looks ready for publication. = Some minor issues found :

Reference to RFC 7120 early allocation procedure: the allocation policies f= or the registries are all "Expert review". And the RFC 7120 early= allocation procedure is defined, to do early allocations. However RFC 7120= mentions that this procedure only applies in case :
=C2=A0 =C2=A0(Section 2)
=C2=A0 =C2=A0a. The code points must be from a space designated as "RF= C
=C2=A0 =C2=A0 =C2=A0 =C2=A0Required", "IETF Review", or &quo= t;Standards Action".=C2=A0 Additionally,
=C2=A0 =C2=A0 =C2=A0 =C2=A0requests for early assignment of code points fro= m a
=C2=A0 =C2=A0 =C2=A0 =C2=A0"Specification Required" registry are = allowed if the
=C2=A0 =C2=A0 =C2=A0 =C2=A0specification will be published as an RFC.
So at first sight it looks like the procedure is not applicable, taken stri= ctly. However IANA indicates (https://www.iana.org/he= lp/protocol-registration) that "Expert review" is part of &qu= ot;Specification Required" so it would apply still. But in RFC 8126 th= is is not mentioned in the same manner - so it could confuse some readers a= bout whether it applies or not. Maybe some text could be added to state why= RFC 7120 process does apply to the "Expert review" policy, even = though "Expert review" is not listed under Section 2 point a. of = RFC 7120.=C2=A0 (Note that early allocation by RFC 7120 only applies to &qu= ot;Expert review" allocations for draft documents that aim to become R= FC.)

[IP]: We are in= the process of reformulating this.

Section 6.3.3: table column 1 is very narrow and it breaks the entry point = integer number, which is confusing. Why not make this column wider by one c= haracter? One of the last 2 columns can be made more narrow if needed.
<= /blockquote>

[IP]: Fixed.

Section 3: "RESCONF" -> RESTCONF

[IP]: Fixed.
=C2=A0
Section 3: CoRECONF -> CORECONF

[IP]: Fixed.

Section 3: "For example how this could be achieved, please refer to&qu= ot;
-> For examples on how this could be achieved, please refer to

[IP]: Fixed.

Section 3: "For diagram of one"
-> For a diagram of one ...

[IP]: Fixed.

Best regards

Esko

IoTconsultancy.nl=C2=A0 |=C2=A0 Email/Skype: esko.dijk@iotconsultancy.nl



-----Original Message-----
From: core <c= ore-bounces@ietf.org> On Behalf Of Carsten Bormann
Sent: Monday, March 9, 2020 14:05
To: core <core@ietf.o= rg>
Cc: netmod@ietf.org
Subject: [core] =F0=9F=94=94 WG Last Call of CORECONF drafts: draft-ietf-co= re-yang-cbor-12, -sid-11, -comi-09, -yang-library-01

It took us a long time to get the four CORECONF drafts in sync,
but now we are ready for WGLC.

This starts a working group last call for
=E2=80=94 draft-ietf-core-yang-cbor-12
=E2=80=94 draft-ietf-core-sid-11
=E2=80=94 draft-ietf-core-comi-09
=E2=80=94 draft-ietf-core-yang-library-01

ending on

=C2=A0 =C2=A0 =C2=A0 =C2=A0 24:00 UTC on Tuesday, March 31, 2020.

(This includes some extra time for the IETF week and for cross-WG
coordination.)

This WGLC is copied to the netmod WG mailing list; please do have a look at these drafts as they are slated to become a part of the greater
YANG/NETCONF/RESTCONF family.=C2=A0 We intend the discussion to be on the CoRE mailing list, but if you find a fundamental issue with YANG or
RESTCONF, feel free to discuss that on netmod instead.

Please start a new email thread for each major issue that will need
discussion and make sure the subject line includes the draft name and
some sort of name for the issue.=C2=A0 (Minor issues such as typos can also=
be sent to the authors.)

If you read the draft and think it looks fine, please send a one line
email to the list or to the chairs letting us know that so we can get
a feel of how broad the review has been.

(To reviewers and authors:)=C2=A0 If you are aware of any patent claims tha= t
might apply to systems that implement these drafts, please review BCP 78 and BCP 79 and make any appropriate IPR declaration before the last-call ends. If you are not sure whether you need to make a declaration or not, please talk to the chairs and we will help.

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

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--0000000000008424ed05a3544640-- From nobody Wed Apr 15 06:28:02 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE25A3A082A for ; Wed, 15 Apr 2020 06:27:54 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSrjJnk4HnBk for ; Wed, 15 Apr 2020 06:27:52 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 9C4033A0833 for ; Wed, 15 Apr 2020 06:27:49 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id b11so7777660wrs.6 for ; Wed, 15 Apr 2020 06:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=MPsGZp5jkhumT8uMvLA60Hq3iygUFDHYDVfalIc/G1M=; b=b/nkBFHjBtUGCTwtQPGUNiC3AqeaiLhcbeP+O6tm+DXxmSFpOR/1vGsqGZzN3VVIP7 mfWj8V82aRJnv2fT13dGPV85GtLje3vQ4hL/iM6P3h8ltH69y43dE/Fey0AcARipjp4U bhbuxoIKRtPABavCFUGO+5UiaWZtCiZwINC4VEybor1ND6zYuFcRheaJsBdbo4yBo5X5 s49Z40pZdXVQww+hkfNQYsn+V6NnYDZTdfiZ0jesXmr+fIjb9Iu52MrFFVY+l/FAEmY3 uXV38QLa2mwpJ+cV2v0BEx5BExeJyKr/fnZ8XmKyBgUA6dWhInWfxol7gCcgCYBeiiPU Kt2Q== 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; bh=MPsGZp5jkhumT8uMvLA60Hq3iygUFDHYDVfalIc/G1M=; b=i4aAB6XKwAp+9AR0pF14r6g3P2PkY2ZSXF2iQr3wtO/bB5ucT4CvLFiK+ytn8G17Sk IlpCCDMv/oHsny0HtokhLBxB+e/Ru/yPuaWgF//cZPpOKerPvWQZEVFM34lmj8XUNdZr PpF33/nzE7PlUjPrYb7irQoEfI4xyoTh5bk5T6Ct1+COL7zjVpzxCxD1TNd+bw33PU3x h+iGq8mgIWo8gGsUeVoH18NunloGw2NsG6rhF8b5q1eg/J/jekEltDrfTsBZD7pirZL6 5vtyV5eCMszHYPvutfqrf+2m0xuxEabZEQw+/4iVfLV1Vmj+yWbkYpaFmHY9Np0qfcDK hWBw== X-Gm-Message-State: AGi0PubtYVskVtLGQPeJfoBa03FN8VQnGy7KIhp1PQ1nHLulKAoF4ukI PIe7TgOWP2qFuW1Z+5ObeMp5mu8WK53pUvsa99sdNHPb X-Google-Smtp-Source: APiQypLbwlQH1/dAvHyIgldnMKLTXMwInP49WJ1CY75GDYuF1krgUmGfydI7XDBe8cI1E+2jnqIBFj6SiNCzlW0GB8U= X-Received: by 2002:adf:e681:: with SMTP id r1mr7645390wrm.213.1586957267803; Wed, 15 Apr 2020 06:27:47 -0700 (PDT) MIME-Version: 1.0 References: <20200330213129.m2azrbeaxrtgivfc@anna.jacobs.jacobs-university.de> In-Reply-To: <20200330213129.m2azrbeaxrtgivfc@anna.jacobs.jacobs-university.de> From: Ivaylo Petrov Date: Wed, 15 Apr 2020 15:27:21 +0200 Message-ID: To: Juergen Schoenwaelder , core , NetMod WG Content-Type: multipart/alternative; boundary="00000000000038b8e805a354486b" Archived-At: Subject: Re: [core] js review of draft-ietf-core-sid-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, 15 Apr 2020 13:27:57 -0000 --00000000000038b8e805a354486b Content-Type: text/plain; charset="UTF-8" Hello Juergen, Thank you for your review and your comments! They really help us improve this document. Please find my answers below (prefixed with [IP]). Note that the diff after handing your comments and those of Esko Dijk and Tom Petch can be found at [1]. Best regards, Ivaylo [1]: https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-sid&url2=http://core-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.txt On Mon, Mar 30, 2020 at 11:32 PM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > I have reviewed draft-ietf-core-sid-12. I will try to review yang-cbor > tomorrow as well. (I am probably more interested in CBOR encoding for > RESTCONF than the usage of CoAP itself, hence my priority on these two > IDs under last call.) > > - Avoid the use of the word 'template', which is not a well defined > term and may be used with varying interpretations. > > o data nodes (Note: including those parts of a YANG template as > defined by the 'yang-data' extension.) > > It is not clear to me what is meant with "those parts of a YANG > template as defined by the 'yang-data' extension." I think this > could benefit from a rewording. > [IP]: Reworded. - The ID seems to assume that semantics of yang items never change. > This is true so far but NETMOD has chartered work that might change > this property. So what happens if the semantics of a YANG item > changes? > > SIDs are assigned permanently, items introduced by a new revision of > a YANG module are added to the list of SIDs already assigned. > > If a YANG module changes in a non-backwards compatible way, I assume > a new sid range must be allocated? Strictly speaking, this question > does not have to be answered today but it very likely needs an > answer in the future... > [IP]: We will not be able to clearly answer this before there is more information how the YANG items semantics can change. For now it looks like assigning new range would be a good solution, but maybe there will be some other solutions that will be even more optimal. What looks logical is that at least every semantic of an item should have a separate SID. - The definition of 'path' is not very precise, i.e., it does not > spell out how module namespaces work, only by example.. I do not > know whether a definition can be imported from somewhere. > [IP]: I tried to improve it. Please let me know if now it is clear enough. - s/RESCONF/RESTCONF/ > [IP]: Fixed. - Is it CoRECONF or CORECONF? And I find the term CORECONF confusing. > We have two protocols called NETCONF and RESTCONF and now we add > another protocol called CoMI and we call CoMI together with YANG > CBOR and SIDs CORECONF? > > 1) NETCONF + YANG + XML serialization + path naming -> ? > 2) RESTCONF + YANG + XML|JSON serialization + path naming -> ? > 3) CoMI + YANG + CBOR serialization + SID naming -> CORECONF > > We do not have a term for 1) and 2) and then we have a term for 3) > which, however, looks more like the protocol names used in 1) and > 2). This comment is not specific to this ID, but the asymmetry > showed up while reading the SID document, I had to look at other IDs > to understand how things are named. And the SID document says > > YANG is a language designed to model data accessed using one of the > compatible protocols (e.g. NETCONF [RFC6241], RESCONF [RFC8040] and > CoRECONF [I-D.ietf-core-comi]). > > Then I read the CoMI abstract. It first says CoMI is "a CoAP > Management Interface", it then says "The complete solution composed > of CoMI, [I-D.ietf-core-yang-cbor] and [I-D.ietf-core-sid] is called > CORECONF." and finally it states that "CORECONF extends the set of > YANG based protocols, NETCONF and RESTCONF, with the capability to > manage constrained devices and networks.". So I am confused, is > CORECONF a protocol as stated in this document? Or is CoMI a > protocol? (What is then the difference between a "Management > Interface" and a management protocol?) I am not sure whether I get > to review comi, hence I mention my confusion here as I hit it while > reviewing the sid document. > [IP]: Currently this is indeed somewhat confusing. The proposed change from Michael Richardson was to at least have CORECONF in the title of the CoMI document. I am wondering if that might still leave some of the confusion. For me the simple solution is in this document to refer to CoMI, not CORECONF and let CoMI draft define what CORECONF actually is. Unless you think this will still not resolve the issue, this is going to be my way forward. - This description makes little sense to me: > > typedef sid-file-version-identifier { > type uint64; > description > "Optional attribute that gives information about the .sid file > version."; > } > > This is a type definition. Why does the description talk about an > optional attribute? The type should not state whether something > using the type is optional or not. (And I would prefer to avoid > 'attribute', better use YANG defined terms or just describe that > this type represents a version number for a SID file.) > [IP]: I believe now it should be more clear. - sid range - was it not said before that it is 63 bits? Is the idea > that sids with the highest bit set are legal but undefined or > reserved? Or should there be a range restriction? > > typedef sid { > type uint64; > description > "YANG Schema Item iDentifier"; > reference > "[I-D.ietf-core-sid] YANG Schema Item iDentifier (SID)"; > } > [IP]: I set the range accordingly. - schema-node-path > > "Identifies a schema-node path string for use in the > SID registry. This string format follows the rules > for an instance-identifier, as defined in RFC 7959, > except that no predicates are allowed. > > RFC 7959 seems to be a typo, I assume you mean RFC 7951 > [IP]: Yes, thank you for spotting this! s/Identifies a schema-node path string/A schema-node path" > > It is a bit confusing to define a schema-node path by way of > reference to an instance identifier. I understand that you borrow > the namespace encoding from the way JSON encode instance identifiers > but this type really represents what RFC 7950 calls an absolute > schema node identifier, no? Is the term schema-node path actually > needed or is it the same as absolute schema node identifier? Or is > the difference between the two how namespaces are represented? > [IP]: I might have misunderstood something, but my understanding is that the prefix related to a module could be changed during an import, whereas here we really want to use the module name as a more stable identifier. The difference between absolute schema node identifier and schema-node path is that we mandate the use of module name and not prefix as defined in RFC 7950. - dependency-revision > > list dependency-revision { > key "module-name"; > > description > "Information about the revision of each YANG module that the > module in > 'module-name' includes used during the .sid file generation."; > > The sentence can probably be rewritten to make it clearer. > > Are the SIDs assigned to a module dependent on the modules listed > in the 'dependency-revision'? (Is this a good name for the list?) > Why is it necessary to know which revisions were used to resolve > imports without revision? > [IP]: I reformulated it to Information about the used revision during the .sid file generation of each YANG module that the module in 'module-name' imported. The idea is that if this information is not available later on and different versions of the modules are used, slightly different results might be produced due to augmented items for example. - Please avoid wrapped entry point numbers in the table in 6.3.3. > [IP]: Fixed. - The handling of early allocations sounds complex, I have some doubts > this process will work in practice... > [IP]: We are working on reformulating it in a more precise manner. - Incomplete sentence: > > RFC7120] also says > > Or is the following paragraph a quote? In that case, add a colon. > > - There are likely more normative references, e.g., RFC 6991 and RFC > 8040. > [IP]: Fixed. - Why does the example in appendix A not have / need > dependency-revisions? > [IP]: Added now. - I have not run any tools to validate things. I just read the I-D. > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --00000000000038b8e805a354486b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello J= uergen,

Thank you for your review and your c= omments! They really help us improve this document. Please find my answers = below (prefixed with [IP]). Note that the diff after handing your comments = and those of Esko Dijk and Tom Petch can be found at [1].

Best regar= ds,
Ivaylo

[1]: = https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-sid&am= p;url2=3Dhttp://core-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.txt<= /a>

Hi,

I have reviewed draft-ietf-core-sid-12. I will try to review yang-cbor
tomorrow as well. (I am probably more interested in CBOR encoding for
RESTCONF than the usage of CoAP itself, hence my priority on these two
IDs under last call.)

- Avoid the use of the word 'template', which is not a well defined=
=C2=A0 term and may be used with varying interpretations.

=C2=A0 =C2=A0o=C2=A0 data nodes (Note: including those parts of a YANG temp= late as
=C2=A0 =C2=A0 =C2=A0 defined by the 'yang-data' extension.)

=C2=A0 It is not clear to me what is meant with "those parts of a YANG=
=C2=A0 template as defined by the 'yang-data' extension." I th= ink this
=C2=A0 could benefit from a rewording.

[IP]: Reworded.

- The ID seems to assume that semantics of yang items never change.
=C2=A0 This is true so far but NETMOD has chartered work that might change<= br> =C2=A0 this property. So what happens if the semantics of a YANG item
=C2=A0 changes?

=C2=A0 =C2=A0SIDs are assigned permanently, items introduced by a new revis= ion of
=C2=A0 =C2=A0a YANG module are added to the list of SIDs already assigned.<= br>
=C2=A0 If a YANG module changes in a non-backwards compatible way, I assume=
=C2=A0 a new sid range must be allocated? Strictly speaking, this question<= br> =C2=A0 does not have to be answered today but it very likely needs an
=C2=A0 answer in the future...

[IP]:= =C2=A0We will not be able to clearly answer this before there is mor= e information how the YANG items semantics can change. For now it looks lik= e assigning new range would be a good solution, but maybe there will be som= e other solutions that will be even more optimal. What looks logical is tha= t at least every semantic of an item should have a separate SID.

- The definition of 'path' is not very precise, i.e., it does not =C2=A0 spell out how module namespaces work, only by example.. I do not
=C2=A0 know whether a definition can be imported from somewhere.

[IP]: = I tried to improve it. Please let me know if now it is clear enough.
- s/RESCONF/RESTCONF/

[IP]: Fixed.

- Is it CoRECONF or CORECONF? And I find the term CORECONF confusing.
=C2=A0 We have two protocols called NETCONF and RESTCONF and now we add
=C2=A0 another protocol called CoMI and we call CoMI together with YANG
=C2=A0 CBOR and SIDs CORECONF?

=C2=A0 1) NETCONF=C2=A0 + YANG + XML=C2=A0 =C2=A0 =C2=A0 serialization + pa= th naming -> ?
=C2=A0 2) RESTCONF + YANG + XML|JSON serialization + path naming -> ? =C2=A0 3) CoMI=C2=A0 =C2=A0 =C2=A0+ YANG + CBOR=C2=A0 =C2=A0 =C2=A0serializ= ation + SID naming=C2=A0 -> CORECONF

=C2=A0 We do not have a term for 1) and 2) and then we have a term for 3) =C2=A0 which, however, looks more like the protocol names used in 1) and =C2=A0 2). This comment is not specific to this ID, but the asymmetry
=C2=A0 showed up while reading the SID document, I had to look at other IDs=
=C2=A0 to understand how things are named. And the SID document says

=C2=A0 =C2=A0YANG is a language designed to model data accessed using one o= f the
=C2=A0 =C2=A0compatible protocols (e.g.=C2=A0 NETCONF [RFC6241], RESCONF [R= FC8040] and
=C2=A0 =C2=A0CoRECONF [I-D.ietf-core-comi]).

=C2=A0 Then I read the CoMI abstract. It first says CoMI is "a CoAP =C2=A0 Management Interface", it then says "The complete solution= composed
=C2=A0 of CoMI, [I-D.ietf-core-yang-cbor] and [I-D.ietf-core-sid] is called=
=C2=A0 CORECONF." and finally it states that "CORECONF extends th= e set of
=C2=A0 YANG based protocols, NETCONF and RESTCONF, with the capability to =C2=A0 manage constrained devices and networks.". So I am confused, is=
=C2=A0 CORECONF a protocol as stated in this document? Or is CoMI a
=C2=A0 protocol? (What is then the difference between a "Management =C2=A0 Interface" and a management protocol?) I am not sure whether I = get
=C2=A0 to review comi, hence I mention my confusion here as I hit it while<= br> =C2=A0 reviewing the sid document.

[IP]: Currently this is indeed somewhat confusing. The propo= sed change from Michael Richardson was to at least have CORECONF in the tit= le of the CoMI document. I am wondering if that might still leave some of t= he confusion. For me the simple solution is in this document to refer to Co= MI, not CORECONF and let CoMI draft define what CORECONF actually is. Unles= s you think this will still not resolve the issue, this is going to be my w= ay forward.

- This description makes little sense to me:

=C2=A0 typedef sid-file-version-identifier {
=C2=A0 =C2=A0 type uint64;
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "Optional attribute that gives information about = the .sid file
=C2=A0 =C2=A0 =C2=A0 =C2=A0version.";
=C2=A0 }

=C2=A0 This is a type definition. Why does the description talk about an =C2=A0 optional attribute? The type should not state whether something
=C2=A0 using the type is optional or not. (And I would prefer to avoid
=C2=A0 'attribute', better use YANG defined terms or just describe = that
=C2=A0 this type represents a version number for a SID file.)

[IP]: I believe now it shoul= d be more clear.

- sid range - was it not said before that it is 63 bits? Is the idea
=C2=A0 that sids with the highest bit set are legal but undefined or
=C2=A0 reserved?=C2=A0 Or should there be a range restriction?

=C2=A0 typedef sid {
=C2=A0 =C2=A0 type uint64;
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "YANG Schema Item iDentifier";
=C2=A0 =C2=A0 reference
=C2=A0 =C2=A0 =C2=A0 "[I-D.ietf-core-sid] YANG Schema Item iDentifier = (SID)";
=C2=A0 }

[IP]: I set= the range accordingly.

- schema-node-path

=C2=A0 =C2=A0 =C2=A0 "Identifies a schema-node path string for use in = the
=C2=A0 =C2=A0 =C2=A0 =C2=A0SID registry. This string format follows the rul= es
=C2=A0 =C2=A0 =C2=A0 =C2=A0for an instance-identifier, as defined in RFC 79= 59,
=C2=A0 =C2=A0 =C2=A0 =C2=A0except that no predicates are allowed.

=C2=A0 RFC 7959 seems to be a typo, I assume you mean RFC 7951

[IP]: Yes, thank you for spotting this!

=C2=A0 s/Identifies a schema-node path string/A schema-node path"

=C2=A0 It is a bit confusing to define a schema-node path by way of
=C2=A0 reference to an instance identifier. I understand that you borrow =C2=A0 the namespace encoding from the way JSON encode instance identifiers=
=C2=A0 but this type really represents what RFC 7950 calls an absolute
=C2=A0 schema node identifier, no? Is the term schema-node path actually =C2=A0 needed or is it the same as absolute schema node identifier? Or is =C2=A0 the difference between the two how namespaces are represented?

[IP]: I might have misund= erstood something, but my understanding is that the prefix related to a mod= ule could be changed during an import, whereas here we really want to use t= he module name as a more stable identifier. The difference between absolute= schema node identifier and schema-node path is that we mandate the use of = module name and not prefix as defined in RFC 7950.

- dependency-revision

=C2=A0 =C2=A0 =C2=A0 =C2=A0 list dependency-revision {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 key "module-name";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Information about the revision of = each YANG module that the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 module in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'module-name' includes used duri= ng the .sid file generation.";

=C2=A0 =C2=A0The sentence can probably be rewritten to make it clearer.

=C2=A0 =C2=A0Are the SIDs assigned to a module dependent on the modules lis= ted
=C2=A0 =C2=A0in the 'dependency-revision'? (Is this a good name for= the list?)
=C2=A0 =C2=A0Why is it necessary to know which revisions were used to resol= ve
=C2=A0 =C2=A0imports without revision?
=C2=A0
[IP]: I reformulated it to

Information about the used revision during the .sid file generation
of each YANG module that the module in 'module-name' impo= rted.

The idea is that if this information is not av= ailable later on and different versions of the modules are used, slightly d= ifferent results might be produced due to augmented=C2=A0<= /span>items=C2=A0for example.

- Please avoid wrapped entry point numbers in the table in 6.3.3.

[IP]: Fixed.

- The handling of early allocations sounds complex, I have some doubts
=C2=A0 this process will work in practice...

[IP]: We are working on reformulating it in a more= precise manner.

=
- Incomplete sentence:

=C2=A0 RFC7120] also says

=C2=A0 Or is the following paragraph a quote? In that case, add a colon.
- There are likely more normative references, e.g., RFC 6991 and RFC
=C2=A0 8040.

[IP]: Fixed.
=
- Why does the example in appendix A not have / need
=C2=A0 dependency-revisions?

[IP]: Added now.

- I have not run any tools to validate things. I just read the I-D.=C2=A0

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--00000000000038b8e805a354486b-- From nobody Wed Apr 15 09:21:41 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78863A0A8F; Wed, 15 Apr 2020 09:21:01 -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, MSGID_FROM_MTA_HEADER=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=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CqzYoN0-m_a; Wed, 15 Apr 2020 09:20:59 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2064.outbound.protection.outlook.com [40.107.22.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274783A0A3A; Wed, 15 Apr 2020 09:20:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xp5gHw52R1w+aE1P+vXHlSTwkeVSkip1WhZmRa4ky8OQb/k8cDA2EYxW39JOFTB0VWbd2mazKori4yRkOZ1TyInsVTFKzDB8UGA136wwj+XP4VqhewRuhXsqpkxY5IpvBpIjf14/8/60FiMN0efyfEpoDJmaQW6zoSLYyzskvCCmsxfIET7ZtvQ67RtjWOb2vUq9/3B+UR8q2XxiC/ppVv7CIgH95v88TQj1i7CEjPfSvhPEvhRUugYo/2MFriglfTWdq1m41CnKJmNFk8rhgXgH40yb1cd5QM+N1R/mnD9BJUT7kHqmE2ebS4TFa231vMSYDw2bJvDCDN0/xdT4xg== 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=HQysCgPSbG8FnpVNa+p+Z0FTFHPaO4kx7Dz1BsWcooY=; b=N356Ok9m/1msrKuJvvX4/sM6NL7zUlLSvorXozXiK4f9yvy6bSKGzvvqnHm4ZlZQea82XS1NV4hXUCl+MbrmhJsRx4WdsP7Y7Omf/8u4xCimRXhFHDUbo/12qwuKGbnybAf7H82++WNgxiWUAsGq6S4jgd5USvcXxbBjN8BRx4n66qw4Cgnk48TrV2VDUgBsjFwLmmtOBO2xxiJ+CzwwvXel+ZNgbZIw6wL82UjD7YPnOhVy9IKORRl1J7qD8s2NHZWIaFEE9wniUk7l38wYBQV2bzr3pu6LPH1czIh7VtozxMD4oG6wpg2JHiWQedzEeMgXM3p09birtU7juG+u5A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HQysCgPSbG8FnpVNa+p+Z0FTFHPaO4kx7Dz1BsWcooY=; b=nXG1sJkCxbOwAnfNVGliE8aN8jg5jeSoPo7fofwJGBNdqR3GjvCOJfzd1rtMoudU6UQ8WaqCzADokkl6qzeW3h0apVPnk5NaP+2qgOdU0L/62Wj2/GZutJHgNHJJqB1qIJ8pvS+OEg2v2EhfS8h+YBmYIRSLfl3EgX9/hmY3UzI= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:196::24) by AM0P190MB0626.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:193::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.24; Wed, 15 Apr 2020 16:20:56 +0000 Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::dc34:2067:88d1:c483]) by AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::dc34:2067:88d1:c483%5]) with mapi id 15.20.2921.024; Wed, 15 Apr 2020 16:20:55 +0000 Date: Wed, 15 Apr 2020 18:20:54 +0200 From: Juergen Schoenwaelder To: Ivaylo Petrov Cc: core , NetMod WG Message-ID: <20200415162054.s4bjcrienqvrytfz@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ivaylo Petrov , core , NetMod WG References: <20200330213129.m2azrbeaxrtgivfc@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AM0P190CA0004.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:190::14) To AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:196::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (2001:638:709:5::7) by AM0P190CA0004.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:190::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25 via Frontend Transport; Wed, 15 Apr 2020 16:20:55 +0000 X-Originating-IP: [2001:638:709:5::7] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2a14954d-cab0-419e-a63b-08d7e158f96a X-MS-TrafficTypeDiagnostic: AM0P190MB0626: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0374433C81 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0707.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(136003)(376002)(39850400004)(396003)(366004)(346002)(8936002)(66476007)(52116002)(1076003)(2906002)(8676002)(5660300002)(66946007)(6916009)(3450700001)(6496006)(81156014)(66556008)(86362001)(54906003)(6486002)(478600001)(186003)(4326008)(786003)(316002)(16526019)(83080400001); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: gOSlABOvkpHT96L3QSk9mu89pi8pBfOLoP3cqioQzwM35zECqLh0QgUZnuh9cRutXQMKswA7/9ri6t0yT4gfqr8xCxgGnNp8ppEZegZYa3nA7my2y++gRs4IS0i4jYgEkKnpcu/39ncZn+BUTcKITWX0FpEhV9Or+v+80wBslRBrwvI7eeyshr2VN1yf6UgZzv3zfGX+/ltWtjBFclsEGUm61Jd/Bw5zYdpCC+E8LH59acFYRtKFh4YskMrYYdM75qQHRBep3xTL38/8Hhg1zJBuR5HzADHCfRE79s1lAO3rfs+BFAPCmn0PlzSdwhoV6v1hKqEJXOVbTaJVAbo6RUxJEk9EUI5R2TXg5y5JfZzcdob3owlV+N/vvkGwq6QH9ch5NfV7YaeqPeEWF5OQHyqvfPY9ml/oOIYXHAulmHTtnUv21SxqSIGGRBBHv7XuE8rgidZ7JnJ92bPL8MCXWc9h+O+t0DIjMm/D52g+AANp34M/F3mu+mH9HYhMqRnko9IunPgtEXLcc0nnQr9S/w== X-MS-Exchange-AntiSpam-MessageData: y8cX+aTi3Go/cYcpb/ITPFt9d9kc731DI7+SX1ELPlx8KhwcEIq/Gd/z3aD5lkFZxG3scGnnoZw9MM4gwmJTAWrLLiilVToaxz541e6PJw/bOHZdM/U05vqfRiQoRBBWEV1N56sGY5CMaJ/kX5QYIXiIMmdpUnAiu+9vg9AFcnk= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 2a14954d-cab0-419e-a63b-08d7e158f96a X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Apr 2020 16:20:55.7945 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: nH+JDmzwUOsfnz2amhNGeCR3EYcb8sBfEFLUHeCNvLx+MwmRSqZGIvFnSGgm9NN0VqBnSxuS1v4qf0Ch74Ys5W8TWPQc8SGdAGR0WKirO1c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0626 Archived-At: Subject: Re: [core] js review of draft-ietf-core-sid-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, 15 Apr 2020 16:21:02 -0000 On Wed, Apr 15, 2020 at 03:27:21PM +0200, Ivaylo Petrov wrote: > - The ID seems to assume that semantics of yang items never change. > > This is true so far but NETMOD has chartered work that might change > > this property. So what happens if the semantics of a YANG item > > changes? > > > > SIDs are assigned permanently, items introduced by a new revision of > > a YANG module are added to the list of SIDs already assigned. > > > > If a YANG module changes in a non-backwards compatible way, I assume > > a new sid range must be allocated? Strictly speaking, this question > > does not have to be answered today but it very likely needs an > > answer in the future... > > > > [IP]: We will not be able to clearly answer this before there is more > information how the YANG items semantics can change. For now it looks like > assigning new range would be a good solution, but maybe there will be some > other solutions that will be even more optimal. What looks logical is that > at least every semantic of an item should have a separate SID. Yes and this will impact the SID document since SIDs are going to be specific to a (module, path, version) triple. > - Is it CoRECONF or CORECONF? And I find the term CORECONF confusing. > > We have two protocols called NETCONF and RESTCONF and now we add > > another protocol called CoMI and we call CoMI together with YANG > > CBOR and SIDs CORECONF? > > > > 1) NETCONF + YANG + XML serialization + path naming -> ? > > 2) RESTCONF + YANG + XML|JSON serialization + path naming -> ? > > 3) CoMI + YANG + CBOR serialization + SID naming -> CORECONF > > > > We do not have a term for 1) and 2) and then we have a term for 3) > > which, however, looks more like the protocol names used in 1) and > > 2). This comment is not specific to this ID, but the asymmetry > > showed up while reading the SID document, I had to look at other IDs > > to understand how things are named. And the SID document says > > > > YANG is a language designed to model data accessed using one of the > > compatible protocols (e.g. NETCONF [RFC6241], RESCONF [RFC8040] and > > CoRECONF [I-D.ietf-core-comi]). > > > > Then I read the CoMI abstract. It first says CoMI is "a CoAP > > Management Interface", it then says "The complete solution composed > > of CoMI, [I-D.ietf-core-yang-cbor] and [I-D.ietf-core-sid] is called > > CORECONF." and finally it states that "CORECONF extends the set of > > YANG based protocols, NETCONF and RESTCONF, with the capability to > > manage constrained devices and networks.". So I am confused, is > > CORECONF a protocol as stated in this document? Or is CoMI a > > protocol? (What is then the difference between a "Management > > Interface" and a management protocol?) I am not sure whether I get > > to review comi, hence I mention my confusion here as I hit it while > > reviewing the sid document. > > > > [IP]: Currently this is indeed somewhat confusing. The proposed change from > Michael Richardson was to at least have CORECONF in the title of the CoMI > document. I am wondering if that might still leave some of the confusion. > For me the simple solution is in this document to refer to CoMI, not > CORECONF and let CoMI draft define what CORECONF actually is. Unless you > think this will still not resolve the issue, this is going to be my way > forward. Avoiding CORECONF in this document helps to limit the problem. If CoMI is the name of the protocol, I would hope we do not need CORECONF at all. But then CORECONF is all over the place in draft-ietf-core-comi-09.txt, it actually looks like the protocol is called CORECONF and not CoMI. I really believe this terminology confusion needs to be resolved in the WG so the WG actually knows and agrees on the name of the technology they standardize. > - This description makes little sense to me: > > > > typedef sid-file-version-identifier { > > type uint64; > > description > > "Optional attribute that gives information about the .sid file > > version."; > > } > > > > This is a type definition. Why does the description talk about an > > optional attribute? The type should not state whether something > > using the type is optional or not. (And I would prefer to avoid > > 'attribute', better use YANG defined terms or just describe that > > this type represents a version number for a SID file.) > > > > [IP]: I believe now it should be more clear. Yes. I wonder though, is this a simple linear counter? Or can it be anything as long as newer > older is satisfied? Or is this just a tag that needs to match and it does not imply any order semantics? > s/Identifies a schema-node path string/A schema-node path" > > > > It is a bit confusing to define a schema-node path by way of > > reference to an instance identifier. I understand that you borrow > > the namespace encoding from the way JSON encode instance identifiers > > but this type really represents what RFC 7950 calls an absolute > > schema node identifier, no? Is the term schema-node path actually > > needed or is it the same as absolute schema node identifier? Or is > > the difference between the two how namespaces are represented? > > > > [IP]: I might have misunderstood something, but my understanding is that > the prefix related to a module could be changed during an import, whereas > here we really want to use the module name as a more stable identifier. The > difference between absolute schema node identifier and schema-node path is > that we mandate the use of module name and not prefix as defined in RFC > 7950. Well, what you model here is an absolute schema node path, except that prefixes are replaced by module names. Note that refering to instance-identifier as defined in RFC 7951 has the problem, the RFC 7951 definition of an instance-identifier also includes prefixes instead of module names. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Apr 16 03:35:31 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E925F3A13F6 for ; Thu, 16 Apr 2020 03:35:29 -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 dTGIZNXI8Auk for ; Thu, 16 Apr 2020 03:35:28 -0700 (PDT) Received: from forward5-smtp.messagingengine.com (forward5-smtp.messagingengine.com [66.111.4.239]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395CC3A13F5 for ; Thu, 16 Apr 2020 03:35:26 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailforward.nyi.internal (Postfix) with ESMTP id B7AD819405CB; Thu, 16 Apr 2020 06:35:25 -0400 (EDT) Received: from imap3 ([10.202.2.53]) by compute7.internal (MEProxy); Thu, 16 Apr 2020 06:35:25 -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=Q/MANyNrbGJGVSpNcHePhS3NyATBfI218I/Ri6faI XI=; b=Meou/9skKftpvpob/rNn+uTrT45pbeP4l/KotFiwGEKZkBG6IaUG+9X3C QgiuSSMs2ZN0SUq9ljhavzYuGo6k8pavkIii3s9N2xYQgFjZuPZSOp5A33u9/Zma V+j4921x4mWy/3ueEuNx70gs5/vyHc2sHeZzv6Aq6nh1gYrvq3dB/Fx39pbcMTvo ZioFgylCUk8udH9VWgs5ydY7x4JqEy+C7mshUZ4T1Aw/bM3Qh49ftoHfqrNu/RHl XScaYUCFfzUJxjJ1ZQMZptFaf4SLBpXfXbjQsZyxzxI1bSNWI9pITPE+rBdHxdOa GzHZdBH1+0wMDdyy6RKpC+LD6gMeQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfeehgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomheplfgrihhm vggplfhimhornhgviicuoehjrghimhgvsehikhhirdhfiheqnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjhgrihhmvgesihhkihdrfhhi X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3C0894E009F; Thu, 16 Apr 2020 06:35:24 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1131-g3221b37-fmstable-20200415v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <481f9820-bcea-af6a-d5c4-d713be24d43d@isode.com> Date: Thu, 16 Apr 2020 13:35:04 +0300 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: "Alexey Melnikov" , "core@ietf.org" Cc: "Barry Leiba" , =?UTF-8?Q?Christian_Ams=C3=BCss?= , "Marco Tiloca" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] AD review of draft-ietf-core-resource-directory-23 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, 16 Apr 2020 10:35:30 -0000 Dear all, sorry for the delay on this discussion. We have had a parallel thread an= d now I realise the discussion was not on the list nor with the ADs on i= t.=20 Christian can correct me but the current situation is that the two outst= anding issues can be solved: > > =C2=A0=C2=A0 This section describes how the registering endpoint can= maintain the > > =C2=A0=C2=A0 registrations that it created.=C2=A0 The registering en= dpoint can be the > > =C2=A0=C2=A0 registrant-ep or the CT.=C2=A0 An endpoint SHOULD NOT u= se this interface > > > > Why SHOULD NOT (instead of MUST NOT) and how is this enforced? There was a previous reply from Christian on this, which makes me (and I= suppose others) to lean towards keeping the SHOULD NOT. "This is more expressing the intention than anything enforcable. Frankly= , it is a bit imprecise: The goal is to discourage any agents enumerating registrations from the endpoint lookup and trying to enhance them. Endpoints switching addresses (thus technically becoming different endpoints) and updating their registration is encouraged. There are some cases in the middle we probably don't want to rule out but caution against, invoking "SHOULD"'s "know what you're doing" which we may not want to rule out (but have not discussed). In the end, enforcement is up to the security policy -- if an agent knows a registration URI and has the authorization to act on it, that will succeed." > > > > =C2=A0=C2=A0 for registrations that it did not create.=C2=A0 The reg= istrations are > > =C2=A0=C2=A0 resources of the RD.=20 > =C2=A0[snip] > > At the end of section 9.3: > > =C2=A0=C2=A0 It is expected that the registry will receive between 5= and 50=20 > > registrations in total over the next years. > > > > This will not age well! Maybe remove this text from the document and= =20 > > add it to the spherding write-up? Christian will remove the paragraph and I'll update the writeup. Thanks! -- Jaime From nobody Thu Apr 16 05:13:45 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9B93A1599 for ; Thu, 16 Apr 2020 05:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIk9EKqUvfu9 for ; Thu, 16 Apr 2020 05:13:42 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id E3D7E3A1598 for ; Thu, 16 Apr 2020 05:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1587039220; d=isode.com; s=june2016; i=@isode.com; bh=MtTFh8VYtTyTe+2DVg7AwfsWap+hhp6Bl6T2DYsQ+9w=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=tQG8d0XjdCfZS0NffJLw/yglukSEN1bieo8zDv2p/r4S6bqZG4NaYWUVGBmljY829z41SJ grUvdxkzJpLa+wIn+0sd5P2HE9hNedeLkzX/JQDp6KMYxBa7cBY7xh7Rt5SAsS1LUUJ4ud 8W+S873/m6Sv53h5XwFdlpN+S207LaI=; Received: from [172.27.254.130] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 16 Apr 2020 13:13:40 +0100 To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org" Cc: Barry Leiba , =?UTF-8?Q?Christian_Ams=c3=bcss?= , Marco Tiloca References: <481f9820-bcea-af6a-d5c4-d713be24d43d@isode.com> From: Alexey Melnikov Message-ID: Date: Thu, 16 Apr 2020 13:13:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [core] AD review of draft-ietf-core-resource-directory-23 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, 16 Apr 2020 12:13:43 -0000 Hi Jaime, On 16/04/2020 11:35, Jaime Jim=C3=A9nez wrote: > Dear all, > > sorry for the delay on this discussion. We have had a parallel thread and = now I realise the discussion was not on the list nor with the ADs on it. Yes, that didn't help ;-). > Christian can correct me but the current situation is that the two outstan= ding issues can be solved: > >>> =C2=A0=C2=A0 This section describes how the registering endpoint can ma= intain the >>> =C2=A0=C2=A0 registrations that it created.=C2=A0 The registering endpo= int can be the >>> =C2=A0=C2=A0 registrant-ep or the CT.=C2=A0 An endpoint SHOULD NOT use = this interface >>> >>> Why SHOULD NOT (instead of MUST NOT) and how is this enforced? > There was a previous reply from Christian on this, which makes me (and I s= uppose others) to lean towards keeping the SHOULD NOT. > > "This is more expressing the intention than anything enforcable. Frankly, > it is a bit imprecise: The goal is to discourage any agents enumerating > registrations from the endpoint lookup and trying to enhance them. > Endpoints switching addresses (thus technically becoming different > endpoints) and updating their registration is encouraged. > > There are some cases in the middle we probably don't want to rule out > but caution against, invoking "SHOULD"'s "know what you're doing" which > we may not want to rule out (but have not discussed). > > In the end, enforcement is up to the security policy -- if an agent > knows a registration URI and has the authorization to act on it, that > will succeed." Two comments on this: 1) If this is not supposed to be enforcable, then the document shouldn't=20 use RFC 2119 language in this sentence, I think lowercase "should" would=20 be much better. 2) This is related to my question (I believe I've asked it earlier)=20 about how security policy is going to be implemented in relationship to=20 resource directory. What are the current or expected mechanism? The=20 document is silent about that and this causes me concerns. >>> =C2=A0=C2=A0 for registrations that it did not create.=C2=A0 The regist= rations are >>> =C2=A0=C2=A0 resources of the RD. >> =C2=A0[snip] >>> At the end of section 9.3: >>> =C2=A0=C2=A0 It is expected that the registry will receive between 5 an= d 50 >>> registrations in total over the next years. >>> >>> This will not age well! Maybe remove this text from the document and >>> add it to the spherding write-up? > Christian will remove the paragraph and I'll update the writeup. Great. Best Regards, Alexey From nobody Thu Apr 16 05:40:08 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0913A15F8 for ; Thu, 16 Apr 2020 05:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF7_OJvppCHb for ; Thu, 16 Apr 2020 05:40:00 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30055.outbound.protection.outlook.com [40.107.3.55]) (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 0A3B83A15F6 for ; Thu, 16 Apr 2020 05:39:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SxELxfyaeso0Yt3acPe0DVBsQ1lFnkiH1pNE92cYTTgEvhBQn3GZk1Iqf++pofn9lg78JLuwsGJCjGejyFopKb1Kaj878vTlpj5lQU6OHp0f5IQV3tXTpO4f0+9lLiutojp+uZbb10+A+YUSO5vq9jQOhCZQg092Rr/j6/d31Hwapd+kOx9T493bbzMxlW2CVX0v6X7FxAom6eRbFq9bKd/rt9n3bgrcxz9OyoYLr2NEj9R3dvSWDIHC/W+qGG5OM7OX1yCqyopmavAzeMBMLj150UToB8vaPkq+WU6yaSoN5VE9ztKPZpqsCWCN+6P4M/qmUwQdmN0T4Xdr2RWO6g== 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=SSonB1hNcze4GAAkuE8q9OpSjFGM27ICceHFgBllr24=; b=m93+iZiB4FVyoAWaZR3YoK4Qpb5BkpYnLq4LYlRomPnILvj7P/6pWsaEzKZX2p7ZVcZsK4spc1BNzFu9OCs+h0RaIZKwsqkeEEuG3GAVcP79FjkBt3ftBesu6bIQIfWj+SFxwIFGF4RpOxnnawo3D0hSJSojg9IVjxX20L9xfk7ZleOChYUWTyHjFOk8bIybEJvZHtx9EwlI0r2cmkelyJhqm9rDqd5W8H8zRY6dQpSOmXQ8DyESQeGiC8p+eEh3I5yMuYq3sYOInEpyxgnkmvqo8od4psICF6Jlpcl3Zq9ipkvtKkZsJbgH8Z53n6QKgcUizxqJfYf99cyCOsd7Xg== 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=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SSonB1hNcze4GAAkuE8q9OpSjFGM27ICceHFgBllr24=; b=p2xCGnlKem4QKDkux5iXBCT8rCsGbaE1bT56KwxlVRcbuSXrgV2mnEw9OgVjDiW2iRxTcf4jmw/wiDC7wLaK+iCcR2rGwMojyir9DSS2aqvR90SguS1jqMhOwFpCDYqZyihNbVZ1rtqskNQpqWlVgB3gI2fA86Tb4h30p1oBjIs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0349.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:30::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Thu, 16 Apr 2020 12:39:57 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2900.028; Thu, 16 Apr 2020 12:39:56 +0000 From: Marco Tiloca To: core@ietf.org References: <789d189c-619c-7f06-0f0a-fc68b2262a51@ri.se> <4e258729-37d1-46fd-9907-a43354af50d5@www.fastmail.com> <7101c64f-9ba6-fe38-0bdc-48062556e849@ri.se> Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Thu, 16 Apr 2020 14:39:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: <7101c64f-9ba6-fe38-0bdc-48062556e849@ri.se> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hTeO9Yyf9MDoskyEz0mVTkxuuKv6OoJo6" X-ClientProxiedBy: HE1PR0202CA0033.eurprd02.prod.outlook.com (2603:10a6:3:e4::19) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.13] (185.236.42.101) by HE1PR0202CA0033.eurprd02.prod.outlook.com (2603:10a6:3:e4::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25 via Frontend Transport; Thu, 16 Apr 2020 12:39:56 +0000 X-Originating-IP: [185.236.42.101] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 286767ed-2db4-4b8a-c522-08d7e20344ea X-MS-TrafficTypeDiagnostic: VI1P189MB0349: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-Forefront-PRVS: 0375972289 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(366004)(346002)(396003)(21480400003)(53546011)(33964004)(16799955002)(6486002)(44832011)(52116002)(66574012)(2616005)(81156014)(31686004)(8676002)(956004)(8936002)(36756003)(478600001)(86362001)(6916009)(66476007)(966005)(66556008)(2906002)(66946007)(6666004)(16576012)(316002)(5660300002)(235185007)(26005)(16526019)(186003)(31696002); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: ri.se does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /ko1QXyhqoOF9ih0BYZxuG9gpIrdfqXIvB7dac1zOyiTzYTqTkQ+Mo32AK4XRpP2ig9z66v6dl3o9jNj1T4kR5cLDfAVvWaZ2TViSi2IEWF54K8na2opwz0eDIv+mn7/uy468o/0vxrL9wApla7roL011owZQ+OWNNQQ4nU+006VK1fHJe8jHiQoswRzkludoYRa2sz6bc6U7x1W9nqn3Jy57kmTrMlu9lHaGoSFKvDHXzkAEqagk2qC1xF63zjimnV98SCPZSvww2zAAW5MM/QhoVjWYGf/28/DiLwTLOSoJUSMmAvXPUHiomwmcex/csHsIs0TrbZlRfRygobrXLPrdbj3csT3ELHrhz9v2v6t0hFWPWUnCJxFbcfy54PVRLXBfaDAp6aizRKJc+BQUXRLvJS8MqaUEefQLCJv2jd6/zBJin4ekWEJtDWBnJHDZSZyDx3X0gHOTcYfKVHpTMJPytnmLyy57laVR+hWeci5znqrbd4Fjcyo0dYePP7xMxxUpsea4VKXx6XKGEo1Gg== X-MS-Exchange-AntiSpam-MessageData: 4wivQKYsW1YsdRnnDkMVytmQguzoIyGuz7C6IVTnFHTcKx9IZoTNd6eNa+Al0SkzlmJ5F7i/l6QJgIoEEtlrboEi0y8pBpbXbt4Z4+QGpytX4O9aa+o69x5f9z/7tTx9SF08w3bnzZ1O2W7AjASJrw== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 286767ed-2db4-4b8a-c522-08d7e20344ea X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2020 12:39:56.7888 (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: stZhHzFhuhrlaSw/8C4efTVxq9F3GXGi245VfT6B4gA5PdBMJ8RghEbYd29iYVtu24cNyQUydtzh/2NuMI3xcA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0349 Archived-At: Subject: Re: [core] Upcoming CoRE Virtual Meetings 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, 16 Apr 2020 12:40:07 -0000 --hTeO9Yyf9MDoskyEz0mVTkxuuKv6OoJo6 Content-Type: multipart/mixed; boundary="pVxSsEk7AKizTCdBFHiMWPWgtJXqJZS21" --pVxSsEk7AKizTCdBFHiMWPWgtJXqJZS21 Content-Type: multipart/alternative; boundary="------------70FA2271B82650279AC20975" Content-Language: en-US This is a multi-part message in MIME format. --------------70FA2271B82650279AC20975 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all, Just a reminder that we will start our second CoRE virtual session in less than 30 minutes, i.e. at 13:00 UTC. Please, see below for related information and links. Talk to you soon, Marco and Jaime Meeting entry: https://datatracker.ietf.org/meeting/interim-2020-core-02/session/core Agenda: https://datatracker.ietf.org/doc/agenda-interim-2020-core-02-core-01/ Etherpad: https://etherpad.ietf.org/p/notes-ietf-107-core?useMonospaceFont=3Dtrue Jabber: xmpp:core@jabber.ietf.org?join =C2=A0=C2=A0 For the virtual microphone queue, you may want to say "help = q" Join by Webex =C2=A0=C2=A0 URL: https://ietf.webex.com/ietf/j.php?MTID=3Dm5191b3eadadd36af2b5cbc2599bb317= 5 =C2=A0=C2=A0 Meeting number (access code): 613 591 591 =C2=A0=C2=A0 Meeting password: constrained Join by Phone =C2=A0=C2=A0 1-650-479-3208 Call-in number (US/Canada) =C2=A0=C2=A0 1-877-668-4493 Call-in toll free number (US/Canada) =C2=A0=C2=A0 Access code: 613 591 591 =C2=A0=C2=A0 Toll-free calling restrictions: =C2=A0=C2=A0 https://www.webex.com/pdf/tollfree_restrictions.pdf > > > On 2020-04-06 13:10, Jaime Jim=C3=A9nez wrote: >> Dear core, >> >> in order to run the CoRE Virtual meetings smoothly we'd like to send >> a reminder of the following: >> >> - Those who are going to be presenting slides on Wednesday the 8th. >> Please send us the slides already *today*=C2=A0at the latest.=C2=A0 Yo= u can use >> pptx or pdf format. We will upload them >> to=C2=A0https://github.com/core-wg/wg-materials/tree/master/ietf107=C2= =A0. >> >> - We will be using Webex for the virtual meetings, however the queue >> management will be done over jabber. If you haven't already, please >> set up a jabber account (https://ietf.org/how/meetings/jabber/=C2=A0) = and >> join the group=C2=A0core@jabber.ietf.org >> =C2=A0group. If you cannot, you can still= use >> the webex chat during the meeting and we'll add you manually to the >> queue. We will explain about this during the meeting too. >> >> Ciao! >> --=C2=A0 >> Jaime Jim=C3=A9nez >> >> >> >> On Tue, Mar 31, 2020, at 12:01 AM, Marco Tiloca wrote: >>> Hello CoRE, >>> >>> The two virtual meetings replacing IETF 107 are confirmed for the >>> intended days and times, as summarized below. >>> >>> [Meeting 1] >>> Date and time: 8th of April 2020, 13:00-15:00 UTC [1] >>> Webex link: >>> https://ietf.webex.com/webappng/sites/ietf/meeting/info/12f03cd44d7d4= 079b925586135df03ee >>> >>> [Meeting 2] >>> Date and time: 16th of April 2020, 13:00-14:30 UTC [2] >>> Webex link: >>> https://ietf.webex.com/webappng/sites/ietf/meeting/info/1ccf8929f40d4= ff2a6ff4a6b46521a12 >>> >>> Like in regular IETF meetings, we plan to also use Jabber. In particu= lar >>> also for the virtual microphone queue, you may want to say =E2=80=9Ch= elp q=E2=80=9D in >>> xmpp:core@jabber.ietf.org?join >>> >>> >>> The planned agenda for both meetings is available at: >>> >>> https://github.com/core-wg/wg-materials/blob/master/ietf107/core-107-= agenda.md >>> >>> Please, provide the chairs with the intended objectives for your >>> pertaining time slot and the name of the intended discussion >>> leader/presenter, if they are not included already. >>> >>> Finally, please send your slides to the chairs: >>> >>> - By the 6th of April for the first meeting. >>> - By the 14th of April for the second meeting. >>> >>> Consolidated slides will be also made available at: >>> https://github.com/core-wg/wg-materials/tree/master/ietf107 >>> >>> Best, >>> Marco and Jaime >>> >>> >>> [1] >>> https://www.timeanddate.com/worldclock/meetingdetails.html?year=3D202= 0&month=3D4&day=3D8&hour=3D13&min=3D0&sec=3D0&p1=3D239&p2=3D179 >>> >>> [2] >>> https://www.timeanddate.com/worldclock/meetingdetails.html?year=3D202= 0&month=3D4&day=3D16&hour=3D13&min=3D0&sec=3D0&p1=3D239&p2=3D179 >>> >>> --=C2=A0 >>> Marco Tiloca >>> Ph.D., Senior Researcher >>> >>> RISE Research Institutes of Sweden >>> Division ICT >>> Isafjordsgatan 22 / Kistag=C3=A5ngen 16 >>> SE-164 40 Kista (Sweden) >>> >>> Phone: +46 (0)70 60 46 501 >>> https://www.ri.se >>> >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> >>> *Attachments:* >>> >>> * signature.asc >>> >> > > --=20 > Marco Tiloca > Ph.D., Senior Researcher > > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) > > Phone: +46 (0)70 60 46 501 > https://www.ri.se --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --------------70FA2271B82650279AC20975 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all,

Just a reminder that we will start our second CoRE virtual session in less than 30 minutes, i.e. at 13:00 UTC.

Please, see below for related information and links.

Talk to you soon,
Marco and Jaime


Meeting entry:
https://datatracker.ietf.org/me= eting/interim-2020-core-02/session/core

Agenda: https://datatracker.ietf.org= /doc/agenda-interim-2020-core-02-core-01/

Etherpad: https://etherpad.ietf.org/= p/notes-ietf-107-core?useMonospaceFont=3Dtrue

Jabber: xmpp:core@jabber.ietf.org?join
=C2=A0=C2=A0 For the virtual microphone queue, you may want to say "h= elp q"

Join by Webex
=C2=A0=C2=A0 URL: https://ietf.webex.com/= ietf/j.php?MTID=3Dm5191b3eadadd36af2b5cbc2599bb3175
=C2=A0=C2=A0 Meeting number (access code): 613 591 591
=C2=A0=C2=A0 Meeting password: constrained

Join by Phone
=C2=A0=C2=A0 1-650-479-3208 Call-in number (US/Canada)
=C2=A0=C2=A0 1-877-668-4493 Call-in toll free number (US/Canada)
=C2=A0=C2=A0 Access code: 613 591 591
=C2=A0=C2=A0 Toll-free calling restrictions:
=C2=A0=C2=A0 https://www.webex.com/pdf/tollfre= e_restrictions.pdf



On 2020-04-06 13:10, Jaime Jim=C3=A9= nez wrote:

I had a slightly different proposal to what Klaus = presented at the last interim in terms of doing href compression.  = It is based on the fact that URIs have a relatively fixed pattern and = keeps the CBOR coding directly rather than moving to some type of binary = encoding.

 

The standard pattern for a URI is = scheme://hostname/path/path/…  Using this for compression = purposes by removing all of the tagging which keeps to the same pattern = you would compress coap://example.com/foo/abc…xyz = to

 

[ = “coap”, “example.com”, “foo”, = “abc…xyz”]

1    = 1          = 1          = 1          = 2     =3D 6 bytes of padding

 

This is the same = amount of padding as his binary compression method.  There is a = slight loss over his method when you want to do port numbers, queries or = fragments as they would need to have a integer tag inserted so you = get

 

[ = “coap”, “example.com”, “foo”, = “bar”, Query, “a=3Db”, “c=3Dd”, = Fragment, “gohere”]

1    = 1          = 1           = 1      1     = 1       1     = 1       = 1        = 1        =3D 10 = bytes

 

In the binary encoding this would only require 9 = bytes

 

Moving to an IP address adds no additional padding as = the difference between a text string, a byte string of length either 4 = or 8 can easily be detected.  Relative URIs are encoded using = similar tagging so you end up with

 

[ Absolute, “foo”, = “bar” ]

1   = 1          = 1      1   =3D  4 = byte

 

[ Relative, = 2, “foo”, “bar” ]

1   1        = 1   1     = 1        =3D 5 = bytes

 

Using the binary mode these would be 4 bytes and =  4 bytes respectively (I think as no examples are in the = slides)

 

I believe that the advantage of this proposal is that = there is no new encoder/decoder needed as this is pure CBOR.  The = compressed outputs are of similar lengths as the binary version and = processing them I believe will result in near identical code = sizes.  The code to do absolute and relative processing as well as = generating CBOR options is going to be very similar.

 

Jim

 

------=_NextPart_000_00BB_01D61898.100B25F0-- From nobody Wed Apr 22 12:23:11 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1513A0B6C; Wed, 22 Apr 2020 12:22:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-core-stateless@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , cabo@tzi.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <158758337327.19237.10369808433001369188@ietfa.amsl.com> Date: Wed, 22 Apr 2020 12:22:53 -0700 Archived-At: Subject: [core] Warren Kumari's No Objection on draft-ietf-core-stateless-06: (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, 22 Apr 2020 19:22:54 -0000 Warren Kumari has entered the following ballot position for draft-ietf-core-stateless-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-stateless/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this, it was a pleasant and easy read (especially as I am not a COAP person). 1: I'd believe that the Abstract needs to say *how* "This document updates RFCs 7252 and 8323." (A simple copy and paste from the start of Section 2 would satisfy this) 2: This is not actionable, but I really really enjoyed the "look ma, no state!" bit in Figure 2. Thank you for keeping documents interesting and fun to read... From nobody Wed Apr 22 22:14:20 2020 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCC83A140D; Wed, 22 Apr 2020 22:14:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-core-stateless@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , cabo@tzi.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <158761884340.24804.11461411197672215884@ietfa.amsl.com> Date: Wed, 22 Apr 2020 22:14:03 -0700 Archived-At: Subject: [core] Erik Kline's Discuss on draft-ietf-core-stateless-06: (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, 23 Apr 2020 05:14:04 -0000 Erik Kline has entered the following ballot position for draft-ietf-core-stateless-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-stateless/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [[ discuss ]] [ section 2.2.2 ] * I agree with Ben's point about MTU. Some text about the implications seems warranted. Even just a link to 7252#4.6 might be fine (and maybe a skull-and-crossbones emoji [☠️] if they can be included now ;-) * 60 minutes for address changes? Out of curiosity, upon what was this based? I lack a good deal of context, but this kind of feels like the kind of constant that will get baked into code and come to govern some behaviour that later might need updating. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ nits ]] [ section 4 ] * s/along the/along with the/? From nobody Thu Apr 23 12:15:14 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6129D3A123D for ; Thu, 23 Apr 2020 12:15:11 -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 R-CnsKeRH_bj for ; Thu, 23 Apr 2020 12:15:09 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 4E2D53A123A for ; Thu, 23 Apr 2020 12:15:09 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id i5so6995436uaq.1 for ; Thu, 23 Apr 2020 12:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=noEzJ14hvaJV+Y+FZE/Wjcd834NsIlJjk3cS/LZkrBQ=; b=KGSVMLBD8Uq48cDzqD3Gc9nCvZcStiNuB4w4JIbPeG4m9oqbSRUNCp80iaD6TRjJjB r0LTY1NtWK+zvytGAjH5CEp+q3GefB0ynKV/9Y9V8O0Qnh/5sZdsCAb8oCzqnLg/7sTN MlLwjFNKdb/ZJ26QJ5D4kJREimS5su5Bd8iyUFlrpq81lCkUH+z/FEhQ+alrcWulNlMg C+uKhn5nTUKpSzh9u1tKbK7cMweSntITkM41HLFtlh14WPoYI4mV4XZJ7nPdis3VnLSE 3Wje78wu2d87TG+reK9XQK/fncm5gHlwssCDveaMgSwpbXQi2fX9JUTknT8N0C7lStFt 6q1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=noEzJ14hvaJV+Y+FZE/Wjcd834NsIlJjk3cS/LZkrBQ=; b=qMPqp1vST0yyfCkeQaVWLxqiSuza0h5P3I0GPTiT7BQHVZ/L5j8fmqTObztvX+XYSN lgiAAbdjyo7BQY+R+uhsRE1NjBpvxdVPn/iB1lyIKqYphRLWeEWHj29s5V+axyzR6Fzi Rk5Emm+mo26XWbNRTXZSiMm3Ilk9xPgI6nJ6L5mgUR2Rfb/i3l8zbvStyUAt3rAn+DTO YY+R0kx8ZZLtvT0oztZSxqa9JLtmx8f5NalkxSJKhag2QVZ1bYeZTnggaUgIbdxOxBho wVjViIViCwOL7n1hcmAhZNjF7+8xGfBl1srYOe2I2EopSCUOvl0eq9p5WiRqthtozGR3 1tJQ== X-Gm-Message-State: AGi0PuZRYhfIed2nJYJNK9MBWm2JI3KFzVjVmJ82DQWz+QFXT0BTx2zx /KEq0FL7eQxCxyi4jOmRdkpz+ux980ztN6nOTzEnFofqDXs= X-Google-Smtp-Source: APiQypJbq/ziDSO2YginPznsHEi6lHc9ElnzdE/S0LN64GdZHgl/COEzVeQkBzipyqaRZ394daUEdS+E8mXWfXkEicg= X-Received: by 2002:a67:ffcf:: with SMTP id w15mr4789165vsq.213.1587669307750; Thu, 23 Apr 2020 12:15:07 -0700 (PDT) MIME-Version: 1.0 From: Jonathan Beri Date: Thu, 23 Apr 2020 12:14:32 -0700 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary="0000000000001bfc8d05a3fa119a" Archived-At: Subject: [core] API specification via OpenAPI & AsyncAPI 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, 23 Apr 2020 19:15:12 -0000 --0000000000001bfc8d05a3fa119a Content-Type: text/plain; charset="UTF-8" OpenAPI (openapis.org) is a popular API specification format under the Linux Foundation. Use cases for an API definition documents include interactive documentation, code generation for documentation, clients, and servers and automation of test cases. Recently I learned about AsyncAPI ( asyncapi.com), which is a sibling spec for asynchronous, event-driven APIs. I believe it would provide an improved developer experience for the reasons listed above to have an API specification format for CoAP and groupcomm. It should be feasible to adopt OpenAPI for the request-response features of CoAP and AsyncAPI for the group comms. There's some interest in the AsyncAPI community to see CoAP support, which I'd be interested in facilitating. Thoughts? There may be some overlap between the Link Format and Resource Directory specs, but I believe those can be mitigated - or even supported via code generation. Are there any other related efforts that should be considered? If not, there's a lot of value around the community and ecosystem of OpenAPI and now AsyncAPI. -- Jonathan Beri linkedin.com/in/jonathanberi --0000000000001bfc8d05a3fa119a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OpenAPI (= openapis.org) is a popular API specification format under the Linux Fou= ndation.=C2=A0Use cases for an API definition documents include interactive= documentation, code generation for documentation, clients, and servers and= automation of test cases. Recently I learned about AsyncAPI (asyncapi.com), which is a sibling spec for asynchron= ous, event-driven APIs.

I = believe it would provide an improved developer experience for the reasons l= isted above to have an API specification format for CoAP and groupcomm. It = should be feasible to adopt OpenAPI for the request-response features of Co= AP and AsyncAPI for the group comms. There's some interest=C2=A0in the AsyncAPI comm= unity to see CoAP support, which I'd be interested in facilitating.

Thoughts? There may be some overlap betwe= en the Link Format and Resource Directory specs, but I believe those can be= mitigated - or even supported via code generation. Are there any other rel= ated efforts that should be considered? If not, there's a lot of value = around the community and ecosystem of OpenAPI and now AsyncAPI.

--
Jonathan Beri<= div>linkedin.com/in/jonathanberi
--0000000000001bfc8d05a3fa119a-- From nobody Thu Apr 23 13:57:07 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A843A0860; Thu, 23 Apr 2020 13:56:55 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=Dsoios27; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ENf1PyKh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cib7QTBrUl0f; Thu, 23 Apr 2020 13:56:53 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6063A085E; Thu, 23 Apr 2020 13:56:52 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 98EC95C0874; Thu, 23 Apr 2020 16:56:51 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 23 Apr 2020 16:56:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=bDTNQH29SWSgalNEeVtMC6W mDCIY6T/s1PY/ll/zX5s=; b=Dsoios27SLA8Ddo6zdToFKKmAaLfeAfDAaT6yIW fuJPB4kzl16Gh17H7bn+Bf3A0ZogM2qxYbm9QA4bqRa/9Ks2pVWZ09uHYT4VqkRf KDz5oF5bwiuDKVL/zY4cibGxZw5QPHdZsLJMQVNp2dcZP7LbmhKNtsOJ/NhSpeXN stGL/Jqd8MJdNRCBsN6wdlaggqTjyUm3b6Hbdojop0XaHjFKbWm27s/OGRk99hqu wMeg0HegBh+Pp50NUINT1MIbuNwpC0lDBN0yA76GMEktKzuka+7o4HicUpWTY/MO raPaGXKmBiMwo37tkQpbmOi+YX9uxjL2gXG2OeD+WZBt8/w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=bDTNQH 29SWSgalNEeVtMC6WmDCIY6T/s1PY/ll/zX5s=; b=ENf1PyKhpW4sMkmHUmp6dX iBmCbjPWFjSbu4bZw2fbpPT+uu7m2YwFjuX8zMlnygX6wpSaqBJTJKNpQu/BapUp 2SRthqyQBGU9Yn2QBGkw1UVb/yx+D6difXrYfEE5BS01qVZlIFCXCwybTIUB8UQ6 S3C2PzTK8ZjOu2yJBw+r9GnhbI2GiSt2Y3Wd+o5biq8gA3//7BDNDqXJVEhvb6JF 6IyML6r6yFV4Q4yQ7VceUGBrsMrSbBB5CUDo8H2z2LwRdWD+bOtB52E8sNP40TVJ 74+GEv6JzOaMtkbpDICTACC38dONgzJu7KH63ItuXDidwYlwsD7rPcAf7TsmEtEA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeelgdduvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdejkeenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestghooh hpvghrfidrihhn X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.78]) by mail.messagingengine.com (Postfix) with ESMTPA id 7680B3280064; Thu, 23 Apr 2020 16:56:50 -0400 (EDT) From: Alissa Cooper Message-Id: <899B1D87-E497-4344-8A1C-2E6B65B2F6E1@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_A9A023AA-AEC9-4AF3-A770-A63B61E8E1A3" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) Date: Thu, 23 Apr 2020 16:56:50 -0400 In-Reply-To: Cc: Klaus Hartke , "gen-art@ietf.org" , "draft-ietf-core-stateless.all@ietf.org" , "core@ietf.org" , "last-call@ietf.org" To: Dan Romascanu , Klaus Hartke References: <158573098630.30833.17715509721846547699@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [core] [Gen-art] Genart last call review of draft-ietf-core-stateless-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 20:56:56 -0000 --Apple-Mail=_A9A023AA-AEC9-4AF3-A770-A63B61E8E1A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dan, thanks for your reviews. Klaus, thanks for your responses. I = entered a No Objection ballot. Alissa > On Apr 12, 2020, at 6:11 AM, Dan Romascanu wrote: >=20 > Looks good to me. Thanks for addressing these points.=20 >=20 > Regards, >=20 > Dan >=20 >=20 > On Sun, Apr 12, 2020 at 12:31 PM Klaus Hartke > wrote: > Dan Romascanu wrote: > >> > 1. It would be useful to include some considerations whether the = authors > >> > consider useful / possible / allowed that the mechanism (extended = token > >> > lengths) presented in this document can be used for other = purposed than > >> > the by-design the use case (avoiding per-request state). > >> > >> The last paragraph in Section 1 says: > >> > >> While the use case (avoiding per-request state) and the = mechanism > >> (extended token lengths) presented in this document are closely > >> related, both can be used independently of each other: Some > >> implementations may be able to fit their state in just 8 bytes; = some > >> implementations may have other use cases for extended token = lengths. > >> > >> Does that solve your issue? > > > > Actually this is exactly the paragraph that triggered my concern. = Does 'using independently' mean that you encourage or do not care = implementations in the future dealing with other use cases? If the = answer is yes, maybe the current text is fine. If the answer is 'rather = not' than a discussion would be welcome. >=20 > The paragraph is intended to give permission that extended token > lengths may be used for other purposes than avoiding per-request > state. Of course, these will need security considerations etc., but > those are out of this document's scope. >=20 > >> > > The use of encryption, integrity protection, and replay = protection of > >> > serialized state is recommended in general, unless a careful = analysis > >> > of any potential attacks to security and privacy is performed. = AES- > >> > CCM with a 64 bit tag is recommended, combined with a sequence = number > >> > and a replay window. Where encryption is not needed, = HMAC-SHA-256, > >> > combined with a sequence number and a replay window, may be = used. > >> > > >> > A few issues with this paragraph. Why are not 'recommended' and = 'may' > >> > capitalized? The formulation 'is recommended in general' seems = odd, and > >> > the rest of the sentence does not clarify. What does 'a careful = analysis of any > >> > potential attacks' mean? Who is supposed to perform this analysis = and who > >> > can ensure it is 'careful enough' at any given point in time for = any potential > >> > attacks? > >> > >> AFAIK, the Security Considerations section is supposed to discuss = security-related issues that users need to be aware of, but not make = normative statements. So all the normative requirements are in Section = 3.1. (Where 'users' in this case are implementations and specifications = that decide to make use of this implementation strategy in clients.) > >> > >> Overall, it's a bit difficult to make normative requirements here, = because these are usually about the interoperability e.g. of a client = and a server. But in this case, the client only needs to interoperate = with itself (it needs to accept a token that it created itself) and the = only real requirement is that "client implementations MUST NOT be = vulnerable to maliciously crafted tokens". The meaning of "vulnerable" = and "malicious" here depends a lot on the = application/deployment-specific context; the document can really just = highlight some potential issues that users should take into = consideration. > >> > >> I'm open to concrete suggestions for text improvements, though.. > > > > I believe that I understood the point that you are making. If I am = to suggest text improvements, I would: > > > > - s/recommended in general/recommended/ > > - clarify, maybe in this very words that "the requirement is that = client implementations must not be vulnerable to maliciously crafted = tokens" >=20 > I've made these two changes in the Security Considerations section and > also tried to improve clarity in section 3.1. I will submit a -06 > shortly. >=20 > Thanks! >=20 > Klaus > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_A9A023AA-AEC9-4AF3-A770-A63B61E8E1A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dan, = thanks for your reviews. Klaus, thanks for your responses. I entered a = No Objection ballot.

Alissa


On Apr = 12, 2020, at 6:11 AM, Dan Romascanu <dromasca@gmail.com> = wrote:

Looks good to me. Thanks for = addressing these points.

Regards,

Dan


On Sun, Apr 12, 2020 at 12:31 PM Klaus = Hartke <hartke@projectcool.de> wrote:
Dan Romascanu wrote:
>> > 1. It would be useful to include some considerations = whether the authors
>> > consider useful / possible / allowed that the mechanism = (extended token
>> > lengths) presented in this document can be used for other = purposed than
>> > the by-design the use case (avoiding per-request = state).
>>
>> The last paragraph in Section 1 says:
>>
>>    While the use case (avoiding per-request state) = and the mechanism
>>    (extended token lengths) presented in this = document are closely
>>    related, both can be used independently of each = other: Some
>>    implementations may be able to fit their state in = just 8 bytes; some
>>    implementations may have other use cases for = extended token lengths.
>>
>> Does that solve your issue?
>
> Actually this is exactly the paragraph that triggered my concern. = Does 'using independently' mean that you encourage or do not care = implementations in the future dealing with other use cases? If the = answer is yes, maybe the current text is fine. If the answer is 'rather = not' than a discussion would be welcome.

The paragraph is intended to give permission that extended token
lengths may be used for other purposes than avoiding per-request
state. Of course, these will need security considerations etc., but
those are out of this document's scope.

>> > > The use of encryption, integrity protection, and = replay protection of
>> >    serialized state is recommended in general, = unless a careful analysis
>> >    of any potential attacks to security and = privacy is performed.  AES-
>> >    CCM with a 64 bit tag is recommended, = combined with a sequence number
>> >    and a replay window.  Where encryption = is not needed, HMAC-SHA-256,
>> >    combined with a sequence number and a replay = window, may be used.
>> >
>> > A few issues with this paragraph. Why are not = 'recommended' and 'may'
>> > capitalized? The formulation 'is recommended in general' = seems odd, and
>> > the rest of the sentence does not clarify. What does 'a = careful analysis of any
>> > potential attacks' mean? Who is supposed to perform this = analysis and who
>> > can ensure it is 'careful enough' at any given point in = time for any potential
>> > attacks?
>>
>> AFAIK, the Security Considerations section is supposed to = discuss security-related issues that users need to be aware of, but not = make normative statements. So all the normative requirements are in = Section 3.1. (Where 'users' in this case are implementations and = specifications that decide to make use of this implementation strategy = in clients.)
>>
>> Overall, it's a bit difficult to make normative requirements = here, because these are usually about the interoperability e.g. of a = client and a server. But in this case, the client only needs to = interoperate with itself (it needs to accept a token that it created = itself) and the only real requirement is that "client implementations = MUST NOT be vulnerable to maliciously crafted tokens". The meaning of = "vulnerable" and "malicious" here depends a lot on the = application/deployment-specific context; the document can really just = highlight some potential issues that users should take into = consideration.
>>
>> I'm open to concrete suggestions for text improvements, = though..
>
> I believe that I understood the point that you are making. If I am = to suggest text improvements, I would:
>
> - s/recommended in general/recommended/
> - clarify, maybe in this very words that "the requirement is that = client implementations must not be vulnerable to maliciously crafted = tokens"

I've made these two changes in the Security Considerations section = and
also tried to improve clarity in section 3.1. I will submit a -06
shortly.

Thanks!

Klaus
_______________________________________________
Gen-art = mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_A9A023AA-AEC9-4AF3-A770-A63B61E8E1A3-- From nobody Thu Apr 23 16:08:42 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F423A0906 for ; Thu, 23 Apr 2020 16:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKOtBBv8sCvF for ; Thu, 23 Apr 2020 16:08:39 -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 83D693A08EA for ; Thu, 23 Apr 2020 16:08:38 -0700 (PDT) Received: from [192.168.217.119] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 497XzQ26LXzyf5; Fri, 24 Apr 2020 01:08:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Fri, 24 Apr 2020 01:08:35 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 609376114.5539629-4ae6f657f43b7ee220b63bdfb730abe8 Content-Transfer-Encoding: quoted-printable Message-Id: <064FEA36-EF58-4DBA-9B36-F853DC6B72BA@tzi.org> References: To: Jonathan Beri X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] API specification via OpenAPI & AsyncAPI 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, 23 Apr 2020 23:08:41 -0000 Hi Jonathan, questions like this are being actively discussed in the T2TRG under the = name of "WISHI" (Work on IoT Semantic/Hypermedia Interoperability, = http://wishi.space). We'll have the next WISHI web conference today (er, tomorrow US time): = Gr=C3=BC=C3=9Fe, Carsten > On 2020-04-23, at 21:14, Jonathan Beri wrote: >=20 > OpenAPI (openapis.org) is a popular API specification format under the = Linux Foundation. Use cases for an API definition documents include = interactive documentation, code generation for documentation, clients, = and servers and automation of test cases. Recently I learned about = AsyncAPI (asyncapi.com), which is a sibling spec for asynchronous, = event-driven APIs. >=20 > I believe it would provide an improved developer experience for the = reasons listed above to have an API specification format for CoAP and = groupcomm. It should be feasible to adopt OpenAPI for the = request-response features of CoAP and AsyncAPI for the group comms. = There's some interest in the AsyncAPI community to see CoAP support, = which I'd be interested in facilitating. >=20 > Thoughts? There may be some overlap between the Link Format and = Resource Directory specs, but I believe those can be mitigated - or even = supported via code generation. Are there any other related efforts that = should be considered? If not, there's a lot of value around the = community and ecosystem of OpenAPI and now AsyncAPI. >=20 > --=20 > Jonathan Beri > linkedin.com/in/jonathanberi > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Apr 23 17:42:41 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919613A0BE6 for ; Thu, 23 Apr 2020 17:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 onHVoVxmrZs0 for ; Thu, 23 Apr 2020 17:42:37 -0700 (PDT) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 6D03C3A0BE4 for ; Thu, 23 Apr 2020 17:42:26 -0700 (PDT) Received: by mail-vk1-xa2a.google.com with SMTP id n128so2309171vke.5 for ; Thu, 23 Apr 2020 17:42:26 -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=ZrVaogipBO9pWFnXGu6RGGENYisvz4efSYF1/Jypl1M=; b=aQn/W2Bdwfros9wX7WJzxM4n5xDtGKjFk1d+P7GvqJ8newk8zwow0i/nqn3y3HH4Yc uy6Bi+Jeom7pEcdXvj/PRQStfs7RQnewMAV9PoBbFEiyRYIR3KXANAzgOdj5QqRrRi9N P2dHzUclAis6DuP7ULcAwP0EKc5I9A7oVzyZQwYk1pUjVyVzTLJVD0QCu0Z0QXqLYkp6 7i7cIMetv3d+BFOJRuS6S1CZfTkmHPQ4DhjXOHRG7/on4Ie791aa1ZlFvGkvWBnMvLB4 i102jhms5kBkzgPjIiPXWs8msN2HwD98vy8mOgSic8VXy8zk0+/wfFjP9RrxyniuaWDN X1HA== 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=ZrVaogipBO9pWFnXGu6RGGENYisvz4efSYF1/Jypl1M=; b=QKXru+qCeITNI3EiKfbI6vbrWpnptD/XaaZqGmlrfmuQXYVIkD7SX9VMZy8zWdBgT5 yoSLUWWhj5mqRMLp8Uuf4kA0or9w6505qPfPT9x9cXF6jpc++otZwfa2wPXjILLSIxuT nxnEVWRiBf8wCOiobLjNMRsdy1YT+OYD6dt3stG0m5TGRAmJfAEEfhtZhFW0kb5m3FUS GzI4ZCq3Oxwj6CfayGIGTy1wg9xs+TdAOmebHpmIMSS4zuZFNlJNM9vOGvaUbSGqkcLs QbJWf/+Q6NypWsxYpHM2SWvHaL2nZ9I9ke8w5CYmastZga8ykU7xAGr49mEDu1mjm65I hUfA== X-Gm-Message-State: AGi0PuYuPncSImJd0vrxCUlbuefDgsfEGeRsXIM3UJC7hzdHZD+OLnmF Xx9XIX0djIxjTN/0QhfESgJwCHByYKoy94UDMVJRb1di X-Google-Smtp-Source: APiQypKbSYghqO5rsVx0Ue+UHvpd9rM8QJLK1GpKLuYlgHddqHXZdk2qOghDvJ23Yz4J+IamXo/hyHQsche6UMLazbM= X-Received: by 2002:a1f:2f91:: with SMTP id v139mr5981576vkv.22.1587688945238; Thu, 23 Apr 2020 17:42:25 -0700 (PDT) MIME-Version: 1.0 References: <064FEA36-EF58-4DBA-9B36-F853DC6B72BA@tzi.org> In-Reply-To: <064FEA36-EF58-4DBA-9B36-F853DC6B72BA@tzi.org> From: Jonathan Beri Date: Thu, 23 Apr 2020 17:41:48 -0700 Message-ID: To: Carsten Bormann Cc: core@ietf.org Content-Type: multipart/alternative; boundary="00000000000098477805a3fea3ab" Archived-At: Subject: Re: [core] API specification via OpenAPI & AsyncAPI 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, 24 Apr 2020 00:42:40 -0000 --00000000000098477805a3fea3ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Carsten, I plan to attend! Given the short notice I doubt I'll be able to add to the agenda (or have slides in time,) but I hope to connect with the RG. On Thu, Apr 23, 2020 at 4:08 PM Carsten Bormann wrote: > Hi Jonathan, > > questions like this are being actively discussed in the T2TRG under the > name of "WISHI" (Work on IoT Semantic/Hypermedia Interoperability, > http://wishi.space). > We'll have the next WISHI web conference today (er, tomorrow US time): > > > Gr=C3=BC=C3=9Fe, Carsten > > > > On 2020-04-23, at 21:14, Jonathan Beri wrote: > > > > OpenAPI (openapis.org) is a popular API specification format under the > Linux Foundation. Use cases for an API definition documents include > interactive documentation, code generation for documentation, clients, an= d > servers and automation of test cases. Recently I learned about AsyncAPI ( > asyncapi.com), which is a sibling spec for asynchronous, event-driven > APIs. > > > > I believe it would provide an improved developer experience for the > reasons listed above to have an API specification format for CoAP and > groupcomm. It should be feasible to adopt OpenAPI for the request-respons= e > features of CoAP and AsyncAPI for the group comms. There's some interest = in > the AsyncAPI community to see CoAP support, which I'd be interested in > facilitating. > > > > Thoughts? There may be some overlap between the Link Format and Resourc= e > Directory specs, but I believe those can be mitigated - or even supported > via code generation. Are there any other related efforts that should be > considered? If not, there's a lot of value around the community and > ecosystem of OpenAPI and now AsyncAPI. > > > > -- > > Jonathan Beri > > linkedin.com/in/jonathanberi > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > --=20 Jonathan Beri linkedin.com/in/jonathanberi --00000000000098477805a3fea3ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Carsten, I plan to attend! Given the short notice I= doubt I'll be able to add to the agenda (or have slides in time,) but = I hope to connect with the RG.

On Thu, Apr 23, 2020 at 4:08 PM Carsten Borma= nn <cabo@tzi.org> wrote:
Hi Jonathan,

questions like this are being actively discussed in the T2TRG under the nam= e of "WISHI" (Work on IoT Semantic/Hypermedia Interoperability, <= a href=3D"http://wishi.space" rel=3D"noreferrer" target=3D"_blank">http://w= ishi.space).
We'll have the next WISHI web conference today (er, tomorrow US time):<= br> <https://mailarchive.ietf.= org/arch/msg/t2trg/FC63LiID6CoXYYwdCRpOfIhTO58>

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


> On 2020-04-23, at 21:14, Jonathan Beri <jmberi@gmail.com> wrote:
>
> OpenAPI (openapis.org) is a popular API specification format under the L= inux Foundation. Use cases for an API definition documents include interact= ive documentation, code generation for documentation, clients, and servers = and automation of test cases. Recently I learned about AsyncAPI (asyncapi.com= ), which is a sibling spec for asynchronous, event-driven APIs.
>
> I believe it would provide an improved developer experience for the re= asons listed above to have an API specification format for CoAP and groupco= mm. It should be feasible to adopt OpenAPI for the request-response feature= s of CoAP and AsyncAPI for the group comms. There's some interest in th= e AsyncAPI community to see CoAP support, which I'd be interested in fa= cilitating.
>
> Thoughts? There may be some overlap between the Link Format and Resour= ce Directory specs, but I believe those can be mitigated - or even supporte= d via code generation. Are there any other related efforts that should be c= onsidered? If not, there's a lot of value around the community and ecos= ystem of OpenAPI and now AsyncAPI.
>
> --
> Jonathan Beri
> linkedin.com/in/jonathanberi
> _______________________________________________
> core mailing list
> core@ietf.org > https://www.ietf.org/mailman/listinfo/core



--
--00000000000098477805a3fea3ab-- From nobody Fri Apr 24 02:09:45 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941833A1086 for ; Fri, 24 Apr 2020 02:09:44 -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 azfLBlFZNao2 for ; Fri, 24 Apr 2020 02:09:43 -0700 (PDT) Received: from wforward4-smtp.messagingengine.com (wforward4-smtp.messagingengine.com [64.147.123.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24473A108C for ; Fri, 24 Apr 2020 02:09:42 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailforward.west.internal (Postfix) with ESMTP id 1A3DEE92 for ; Fri, 24 Apr 2020 05:09:42 -0400 (EDT) Received: from imap3 ([10.202.2.53]) by compute7.internal (MEProxy); Fri, 24 Apr 2020 05:09:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=gmfbFmyBL2faOufcF4QqEnOzMHzuG vwNl3SJSEi6sfA=; b=onrlRiZ4agUPavf8kFjZg2z69TIQFcwYz6JP6m/oiAj3x Ypc6Od4+PyCoq9CRn0ZDKC+z2XyBh4K81zfqqo3lVbeJcfewZrcnuw3uJogPW3uV aqHbwei9LbA6Ix6lvgcyHnfiytSTlqQGej8fTrIcIQAP4lLhvCO0KCnXRvdj6UTI 6Sqw473ss/bOX34QyXRqoL3P0aT1gCS4bINoNyUKpZFXtA1zN0O9jTCo/FLN0F6d jLpq0ExihnYqyzo+U7LDH7JbVjmSuC8WUcPmnHf6evLpcbSCuUVzta5IkHSP7PML OXHb0cETL5qzvOoxVXm30EzGq8MM+TaeIo3vt9foA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrhedugdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre erjeenucfhrhhomheplfgrihhmvggplfhimhornhgviicuoehjrghimhgvsehikhhirdhf iheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjhgrihhmvgesihhk ihdrfhhi X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3218D4E009F; Fri, 24 Apr 2020 05:09:41 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: Date: Fri, 24 Apr 2020 12:09:21 +0300 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: core@ietf.org Content-Type: text/plain Archived-At: Subject: [core] Summary of CoRE WG - IETF107 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, 24 Apr 2020 09:09:45 -0000 Dear CoRE WG, Marco and I have prepared a summary of the two CoRE Virtual Meetings we had the past weeks. You can find the summary and the slides both on github [1] and on the datatracker [2]. We have few actionable items we will start with shortly. So expect emails related to upcoming virtual interims (29th April) and working group adoptions. [1] https://github.com/core-wg/wg-materials/tree/master/ietf107 [2] https://datatracker.ietf.org/wg/core/meetings/ Thank you! -- Marco and Jaime From nobody Fri Apr 24 02:22:05 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA1D3A10B8 for ; Fri, 24 Apr 2020 02:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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, 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 5rDRXJ_NY6Ry for ; Fri, 24 Apr 2020 02:21:59 -0700 (PDT) Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) (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 163693A10C3 for ; Fri, 24 Apr 2020 02:21:35 -0700 (PDT) Received: by mail-ot1-f49.google.com with SMTP id g14so11224639otg.10 for ; Fri, 24 Apr 2020 02:21:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0wo0c30odiUogLcTSCr5Ds1iICp6LNTccrEycnRTaQY=; b=tZCBQT34LjEHHVDnPYkl0Rq3nJJ2+NOVAnfSOOq4lyhK4P0HrMUjHoaoSbhzmS4Ohi +iNbYb3qudCL3NZmOIicUx3ARvl3UKfaFsYXfDYQRuT3P2/Q8TdJlckfkharyLiUzrih peHhRHZ3Bo427dIse9yv7YHlclGRliNzO5NuD4+gasZtLLZQW5erTQbeJAbScglNnhic OzaIkI3H03VFjOKvXtD5Hh2D2Ah384YLOCvy2qnU1wHdqmPImbgco9fyOnHlD2bY2N8I Om+xN47b6FVfY9jPsX08/x9XsMY4SOZrJDs3eLkFKcddOWjpqmzYuy88WaQO0x4DSdi4 SngQ== X-Gm-Message-State: AGi0PuZF2OWjntx0FfwJDNOsuShCCFc9Fajojb4dPt4f9V/T7la3jlG/ oGLpm/+6Tc1oFFTeBQndkhetOMjeo0r90UqGZeSraoh2X1g= X-Google-Smtp-Source: APiQypLQpHzS5hhPAo1QGYccaU4J2q2tLszbbWYCdSOekQ/0+AsZLrQTSnmyrRoLjxNviX9rc4bQAku6fyiObYplGYI= X-Received: by 2002:aca:ad87:: with SMTP id w129mr5980890oie.173.1587720094942; Fri, 24 Apr 2020 02:21:34 -0700 (PDT) MIME-Version: 1.0 From: Emmanuel Baccelli Date: Fri, 24 Apr 2020 11:21:24 +0200 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary="000000000000430a2e05a405e4a2" Archived-At: Subject: [core] RIOT Summit 2020: Call for Contributions 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, 24 Apr 2020 09:22:02 -0000 --000000000000430a2e05a405e4a2 Content-Type: text/plain; charset="UTF-8" Dear all, the below call for contributions might be of interest for you, as RIOT bundles an open source implementation of CoAP, and an OSCORE implementation on the way. In particular, CoRE-related talks, tutorials, or demos are very welcome -- *both online and onsite* -- on Sept. 14-15. Looking forward to your proposals! Cheers, Emmanuel (Apologies for potential cross-posting) ************************************************************************ CALL FOR CONTRIBUTIONS RIOT Summit 2020 September 14-15, 2020 Participation options: online & on-site (f2f meeting to be confirmed, at Station F, Paris, France) https://summit.riot-os.org ************************************************************************ RIOT is an open source operating system for microcontroller-based IoT devices. Initially developed by folks from academia, the RIOT community now consists of companies, makers, and hobbyist, distributed all around the world. The RIOT community gathers yearly at the RIOT Summit, which brings together RIOTers, beginners, and experts, as well as people interested in the IoT in general and decision makers who plan to deploy RIOT in the future. The event combines plenary talks, hands-on tutorials, and demos. Every year since 2016, the RIOT Summit was successful in providing a forum to connect. We aim to continue this tradition in 2020, with some changes catering for online participation. We will try our very best to create the special RIOT Summit atmosphere online, as well as onsite (f2f to be confirmed, at French Tech Central in Station F, Paris, France). The organizers of the RIOT Summit call for contributions that relate to RIOT and the Internet of Things. If you want to present a talk, a tutorial, or a demo (whether online or onsite!) please consider the Call for Contributions: * https://summit.riot-os.org/2020/call-for-contributions Best regards, the organizers, on behalf of the RIOT community --000000000000430a2e05a405e4a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

<= /span>
the below call for contributions might be of interes= t for you, as RIOT bundles an open source implementation of CoAP, and an OS= CORE implementation on the way.

In particular, CoRE-related talks, tutorials, or demos are very= welcome -- both online and onsite -- on Sept. 14-15. Looking forwar= d to your proposals!

Cheers,

Emmanuel


(Apologies for potential cross-posting)

**************************= **********************************************

CALL FOR CONTRIBUTION= S

RIOT Summit 2020

September 14-15, 2020

Participation= options: online & on-site
(f2f meeting to be confirmed, at Station = F, Paris, France)

https://summit.riot-os.org

******************************= ******************************************

RIOT is an open source op= erating system for microcontroller-based IoT
devices. Initially d= eveloped by folks from academia, the RIOT community
now consists = of companies, makers, and hobbyist, distributed
all around the world.
The RIOT community gathers yearly at the RIOT Summit, which br= ings
together RIOTers, beginners, and experts, as well as people i= nterested
in the IoT in general and decision makers who plan to deploy R= IOT in the
future. The event combines plenary talks, hands-on tutorials,= and demos.

Every year since 2016, the RIOT Summit was succes= sful in providing
a forum to connect. We aim to continue this tradition = in 2020,
with some changes catering for online participation. We will t= ry
our very best to create the special RIOT Summit atmosphere online,as well as onsite (f2f to be confirmed, at French Tech Central in
Stat= ion F, Paris, France).

The organizers of the RIOT Summit call = for contributions that relate to
RIOT and the Internet of Things. If you= want to present a talk, a
tutorial, or a demo (whether online or onsite= !) please consider the Call
for Contributions:

=C2=A0 * https://summit.riot-os.org/2020/call-for-contributions


Be= st regards,
the organizers, on behalf of the RIOT community
=
--000000000000430a2e05a405e4a2-- From nobody Fri Apr 24 04:37:37 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86123A0952 for ; Fri, 24 Apr 2020 04:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_KAM_HTML_FONT_INVALID=0.01, 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 DEMG88xk6YCe for ; Fri, 24 Apr 2020 04:37:33 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 78C003A0947 for ; Fri, 24 Apr 2020 04:37:33 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id j20so6955626edj.0 for ; Fri, 24 Apr 2020 04:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=6rRxbWSlaHeZFjuFH3NKBoPXfWSuEngJTgsfLUwcuJk=; b=L0ETnVFpThzLUQKUjudvncaTh1Ja6Wgm09OJL5oF+cwi7Ur1lb86nHbE65gwnWU9U4 MhkX/e83spdw8YPiyhRtee+eMy2n0WM+ciYRwLQXJnYuQTLFzMXnpEA7OJdHGuxeYSug MZ9uLbFHGX3/Co3AnIL3ydiOYaW9mrhAuR/Id/+6qoa/C/blbPb1mJ9RgqmxJ5V7POkD deNomBkk5O/6sW/EVtjPAOQeApULVPoh6vg9/BD4pSug+N4TcRRXNEveY+P1Nhf7+ZsE 26r3gWjMPkIgvpf8PxXre20++GQPeaXcYy+47MLe4TH6cj6W5EoHmo7xd8rmG6IM/TTN Zpcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6rRxbWSlaHeZFjuFH3NKBoPXfWSuEngJTgsfLUwcuJk=; b=lnCqZC9AfGalz/Der4VvVYc+5PVUNtwysZNcNwGvhrMKEWD8xocg1sKDnUTh3Xs3yz fZNieVF/7NaLgMIlK3YAeYC9SWA84ffMupyBlHFdRth/s67sALkUYXEx/VqrStjtE3je +4l1AA1bHWCN27AQnA2cEg+Ukn9pgGF7MgJFIazorrYPMl004GwaZ8kUEF8Rt74MTk5W lhmDxqs4VHLVxXeoR/cm1l8UYH1nC6SKF+KB94TtxfIPkkuodW06b8qol2P6CB+NAWpR aUcPxFNgIJH9aer32exAUCuN13UboVelr7p+rKv515wyMIJOWx+fyCt3jbklDok3g5ic sO9g== X-Gm-Message-State: AGi0PuYbJct0+06fja4RAoDNs1gJY7W1A06VH86ZVpfq5KKBM+grhJIy LY/T9ixeQbagv7S+YQK7cliOQE9sIUjwcOOKVWkBX3oRCHk= X-Google-Smtp-Source: APiQypI8SRviVHzTJhRLUpSN6oeTBZY3WRpnoeGtmtH9Ttd6zcJYm3sHDQBb3VcR7Q8uetqmlJV8jaezV6BItxhqBAE= X-Received: by 2002:a05:6402:3136:: with SMTP id dd22mr6613584edb.165.1587728251544; Fri, 24 Apr 2020 04:37:31 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Joel_H=C3=B6glund?= Date: Fri, 24 Apr 2020 13:37:20 +0200 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary="0000000000006eeeaf05a407caab" Archived-At: Subject: Re: [core] [Ace] draft-raza-ace-cbor-certificates-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 11:37:36 -0000 --0000000000006eeeaf05a407caab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi! First a meta comment: I=E2=80=99m now answering to both the ACE and the COR= E mailing list. If the working group chairs have recommendations on where to keep the continued discussion I=E2=80=99m eager to hear. Thank you for your review! Some answers to the questions are inline below. > When you sign CBOR, usually it is wrapped in a bstr. This is important > to be able to use typical CBOR encoders/decoders. This doesn=E2=80=99t se= em > to be the case here, at least I don=E2=80=99t see it in the text near the= end of > section 3. Since this bstr wrapping has become the expected norm we agree this is a good suggestion for an improvement with low overhead, which we will add for the next version. > Was any consideration given to using the COSE algorithm registry rather > than defining a new one? Yes, it is still work in progress to determine if the COSE algorithm registry can accommodate the algorithms deemed useful for inclusion. > But of most interest to me is whether the COSE was considered as the > signing format for native CBOR certs. If COSE is used, then this looks > almost identical to CWT and may be a native CBOR cert is a variant of > a CWT? =E2=80=A6 =E2=80=A6 Our starting point has been to stay close to the original X.509 format while minimizing size. A COSE encoding would re-add some format overhead (close to 10% for the provided example certificate). But if a COSE encoding would help making the format accepted and used, it can definitely be further discussed. Once again, thank you for your comments! and Best Regards Joel H=C3=B6glund *Fr=C3=A5n:* Ace f=C3=B6r Laurence Lundblade < lgl@island-resort.com> *Skickat:* den 22 april 2020 17:23 *Till:* Ace Wg *=C3=84mne:* [Ace] draft-raza-ace-cbor-certificates-04.txt I have a few comments / questions about draft-raza-ace-cbor-certificates-04.txt section 6 on native CBOR certs When you sign CBOR, usually it is wrapped in a bstr. This is important to be able to use typical CBOR encoders/decoders. This doesn=E2=80=99t seem to= be the case here, at least I don=E2=80=99t see it in the text near the end of sect= ion 3.. Was any consideration given to using the COSE algorithm registry rather than defining a new one? But of most interest to me is whether the COSE was considered as the signing format for native CBOR certs. If COSE is used, then this looks almost identical to CWT and may be a native CBOR cert is a variant of a CWT? One advantage of this would be reuse of some of the CWT (and EAT) code. Some of the fields in the CBOR cert might overlap with CWT claims. That might be a good thing. LL _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --0000000000006eeeaf05a407caab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi!


First a meta comm= ent: I=E2=80=99m now answering to both the ACE and the CORE mailing list. I= f the working group chairs have recommendations on where to keep the contin= ued discussion I=E2=80=99m eager to hear.


Thank you for your review! Some answers to th= e questions are inline below.


> When you sign CBOR, usually it is wrapped in a bstr.= This is important

> to be able to use typical CBOR encoders/decoders. This doesn=E2=80= =99t seem

> t= o be the case here, at least I don=E2=80=99t see it in the text near the en= d of

> sectio= n 3.


Since t= his bstr wrapping has become the expected norm we agree this is a good sugg= estion for an improvement with low overhead, which we will add for the next= version.


&g= t; Was any consideration given to using the COSE algorithm registry rather<= /span>

> than defini= ng a new one?


Yes, it is still work in progress to determine if the COSE algorithm regi= stry can accommodate the algorithms deemed useful for inclusion.

=

> But of most inter= est to me is whether the COSE was considered as the

> signing format for native CBOR c= erts. If COSE is used, then this looks

> almost identical to CWT and may be a native CBO= R cert is a variant of

> a CWT? =E2=80=A6 =E2=80=A6=C2=A0


Our starting point has been to stay close = to the original X.509 format while minimizing size. A COSE encoding would r= e-add some format overhead (close to 10% for the provided example certifica= te). But if a COSE encoding would help making the format accepted and used,= it can definitely be further discussed.


Once again, thank you for your comments!


and

Best Regards

Joel H=C3=B6glund=


Fr=C3=A5n:=C2=A0Ace <ace-bounces@ietf.org> f=C3=B6r Laurence Lundblade &l= t;lgl@island-resort.com>Skickat:=C2=A0den 22 april 2020 17:23
Till:=C2=A0Ace Wg &= lt;ace@ietf.org>
=C3=84mne:=C2=A0[Ace] draft-raza-ace-cbor-certificates-04.txt
=C2=A0
I have a few comments / questions about draft-raza-ace-cb= or-certificates-04.txt section 6 on native CBOR certs

When you sign = CBOR, usually it is wrapped in a bstr. This is important to be able to use = typical CBOR encoders/decoders. This doesn=E2=80=99t seem to be the case he= re, at least I don=E2=80=99t see it in the text near the end of section 3..=

Was any consideration given to using the COSE algorithm registry ra= ther than defining a new one?

But of most interest to me is whether = the COSE was considered as the signing format for native CBOR certs. If COS= E is used, then this looks almost identical to CWT and may be a native CBOR= cert is a variant of a CWT? One advantage of this would be reuse of some o= f the CWT (and EAT) code. Some of the fields in the CBOR cert might overlap= with CWT claims. That might be a good thing.

LL




= _______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace<= br>

=
--0000000000006eeeaf05a407caab-- From nobody Mon Apr 27 09:16:59 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4883A0E79 for ; Mon, 27 Apr 2020 09:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.919 X-Spam-Level: X-Spam-Status: No, score=-2.919 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.82, 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 72mm9CR5YzVJ for ; Mon, 27 Apr 2020 09:16:54 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130054.outbound.protection.outlook.com [40.107.13.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0651B3A0E75 for ; Mon, 27 Apr 2020 09:16:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m/3sbldrBaDOG9ThVNaLwkGeE/Oh6vIQAcI7lLf6reo6yassA3zi438tIgN4chHqCY7I7MsRVIlDfIbHPwfpCqBQYVXehqQkJyxN6dnpWVYIcXca5egX7y8nqzshH1XQdO4jwwwHg5+m93PfVo1kIWxSEJ4BzOS0JVmxHOXaEoM3R3bUqja3hLyRBOD46XmVQw+O9jxWJl+fLiPynnYCCTYPBJVXMinup2xahd+hnbaOMaGvyi1kB6XOi2JlMRNRBWHRlw8H+mwVkxltTPQvNUUNLTnjLmmxA14dzFgOIDmHNLT+MtKX90kNjSx+8P4U1RyYZOi5JAq9V/nZ3BmTrQ== 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=RSNWj2yZUO7/Tnfo2SmfHNWVmnA8AqnMUJ1Oe6dcLOA=; b=BadVRpNzxiBlU1rewK2QOCA0KMkGZJNTkwI3Zuzp6MtvbY1KSX+Lv7HWwW2gnYW9QTOMXqRTqDa0TtIDwWYlO5K9Bj1j0jVxm7NQ5KjXVuzGI7+IiYKJ5RgRw/emZZCjI1YxjWCnMM/UIXJmSyLJWpD0UAhmBRBfDz8x9Q8v9wOz9c/CKTUPm0hXeZoxSo0CBAxFJr+Yezuimjg9t71tVSsjX7WxHHVX8sY6mM7zxHB3syOgBW8byMkZgzQ1THge13vSbVCxitIeEC0Z2oImGo5KJLKDEzfMAcJxFcHoZmc1G1YB9Lc51m2Z3sIyUiAnyVYBu+0mkyiEPg8okVmQNw== 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=RSNWj2yZUO7/Tnfo2SmfHNWVmnA8AqnMUJ1Oe6dcLOA=; b=K0XDAJWwfOfl9JJQOtfXGvtR6+b6AEaoct1nn4vJLNPNKGS7PBh+I6TlBVrbWD3VhkGxnCSgHGtRr1KurUbnTsGkBmysCrPpZ+IBjQUYH3KxFfFMyWVZnWH0/v6K5cODCFwEEJPhQCpg7P3Ngk/8pQv4LWWFreB8iv+gqW19tD4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0287.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:2f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Mon, 27 Apr 2020 16:16:51 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2937.020; Mon, 27 Apr 2020 16:16:51 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: <8117e490-7893-c221-2ce6-e331131356c7@ri.se> Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Mon, 27 Apr 2020 18:16:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: <8117e490-7893-c221-2ce6-e331131356c7@ri.se> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zgpFZrJoFqpWfLgZhQkMvKNni9BbdAz5U" X-ClientProxiedBy: HE1PR07CA0005.eurprd07.prod.outlook.com (2603:10a6:7:67::15) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.16] (95.174.66.180) 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.2958.7 via Frontend Transport; Mon, 27 Apr 2020 16:16:50 +0000 X-Originating-IP: [95.174.66.180] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2727f2e1-c309-4e5b-af9e-08d7eac664aa X-MS-TrafficTypeDiagnostic: VI1P189MB0287: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 0386B406AA X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(366004)(136003)(346002)(39860400002)(5660300002)(66476007)(66556008)(6486002)(316002)(16576012)(66946007)(2906002)(966005)(66574012)(956004)(44832011)(478600001)(2616005)(33964004)(81156014)(31696002)(86362001)(16526019)(6916009)(52116002)(53546011)(235185007)(8676002)(21480400003)(186003)(6666004)(26005)(8936002)(36756003)(31686004); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: ri.se does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dNh4+x5kIppvotu+JvCisfmBgyc2oiA3Xld59dSd8cTEP73Oun4QguHHmbiZdOD9Q3JzGwb90xLwztPkInrW7Z4ciKfRUcxlXNuJhixFP4bqc4wM57Ef3xcsIQ3ECiyznNnb/kxHndoI2dZA2DzdUnqFu1qj2IL5q043F4JYd0nNP3YnvCWIUAbXl0OKjLPwUVw4N7dk1AOKpGeKo8sb0cg9qBSu9kXsgQh/nDjvTsWBoAHmlkt+1u4JfLmN57UxD8TxD3+6GxmPzLaalfG682O/2WMIqYs+TATUsxtlC7ym+tB6RZIDSCCKPG8aZtu5w8DlcsHKX7xt3sybNi5lxmQgphW1Zdx0IXE90n7h7lO/uTtQ8iym3dhm1WbhpVnJ37rsavvJDn35jCmYnkZjlU2RPnioydr0zl6ItE1pi57nUI7mnyjofFbtt68PiMFVAlrXCt3rS19FIKFtMVJAo92cr6MdEZDOazgi/DajTvbNm4wGEXIiroXqL+KqlJoRlE4/IrVg5kozAVLHmI2qjw== X-MS-Exchange-AntiSpam-MessageData: SbcW/fppYSvpxXMgztxTSfNyo5mtpeH+gveklvpR+KU7SCIES2QBaYx/jljfPrBUm52sFdkvlJtyGy6AjgETtk+Jq36NvvaBE5tu/zpZqt2e4mG7lPuk28tVV9Q+ELmq4iZx8Bhs+Y5y4Vc3vXfWgk6WN2KSI/xOcyLhET7X6LnbcrqW7VuwICq1HEpPSZIVFw3XPlrFfSflSXio9uyEE7HQrMsOFcmULFlcrXWOb4epjIuQAr/XfpGc5aykykmesPzd9YBxaIG2JXQfCsRg5RSYYQNBe5KRODsaNTPvJeWlNsDCMU/90gesATahWSR6R0l30+Yusvhe70a22UEnoiwkaxAqSUMvkerUUCD9wuWfTlqizRNsn5jfWuwXQ8nWdwUnmI2d4P4CR3p4aqr5prHCeXUcJd2Zef0b2NBdpN3UJQbSSGlMb95Gkt5rkXLYA7j7572IYAaFWHOXjUHe8gbwErAFTfXYxfcAanG5kj05AaB52n+XCzgu1FK4k78VSHHl6cJZa2DUWy6PBuEMOs3Ukfnd2K5KiYgcjquFG6UgCfyGzGNRADcWpfgyN/Wcy80eTE+PZ9gYdyleXhj+GC/jpVJdHu3I4yMxkQylFvTmTAx2qHK5H+FfYd5ec4CbTfUYYqqpE3lIRUZtxnKtnoRZUpU2p42o1y5rt54mePEVGKeDZ1ByfRLaoCbhdTIk4lKOXQHzjYC17jp2lxzgNUCwc5Q54ORaLr76/4/6E6qaQX1NviqYgs0xr+vKKtDC4IRQfB898GVyvmgVBwKO3RAO5HjbafT+hC/Imsa8mS4= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 2727f2e1-c309-4e5b-af9e-08d7eac664aa X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2020 16:16:51.1725 (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: jmNlOnletVYeHhIN3YqRcNEwDMC27O2WatgGc7DffR5Jwj25Fo3HkzqqQCLcorZeVM/knzovJgzs/sRIcprtRQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0287 Archived-At: Subject: Re: [core] WGLC on draft-ietf-core-dev-urn 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, 27 Apr 2020 16:16:57 -0000 --zgpFZrJoFqpWfLgZhQkMvKNni9BbdAz5U Content-Type: multipart/mixed; boundary="1Uv1NRksUTGsCSQqPfa0POgsuNBab9Ef5" --1Uv1NRksUTGsCSQqPfa0POgsuNBab9Ef5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, The WGLC on this draft is now concluded. We have received some comments from Jim [1], Thomas [2] and Carsten [3] --- Thank you! Authors are encouraged to address these comments in the draft and submit an updated version. Best, /Marco [1] https://mailarchive.ietf.org/arch/msg/core/rwXv9jEBTjUtZ0P51U1rhHOMyK= Q/ [2] https://mailarchive.ietf.org/arch/msg/core/KNVKMw2Yj5kyvbG9b3zrYMP-HR= I/ [3] https://mailarchive.ietf.org/arch/msg/core/dsX18XoFBzFwpHf13hBp4FS1kY= g/ On 2020-04-09 20:08, Marco Tiloca wrote: > Dear all, > > As anticipated during the latest CoRE virtual meeting, this mail starts= > a Working Group last call on: > > https://tools.ietf.org/html/draft-ietf-core-dev-urn-04 > > The document is in good shape, with no pending issues. This latest > version especially improved the syntax, examples and IANA rules. > > This WGLC will end on Friday, 24th of April. > > Best, > /Marco > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --1Uv1NRksUTGsCSQqPfa0POgsuNBab9Ef5-- --zgpFZrJoFqpWfLgZhQkMvKNni9BbdAz5U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl6nBWsACgkQ7iZktA5Y 2kPLuQf/RuhpOEKwIwnBOUX2FJWg4FXLAd+V7tYVe9jDYFFY+0IjWFnFdbdC9DrY N9fnITfJa03GbM1Yc8BRWr88FO2MU0BMjuHX61Vi9LHa6uLzeNV6KWOVlxapJpNr L5e6c5PYApbGe2detab+vJE2K1EhNlmeDmZ4OyL1bpTviEzrYXi85q8xVXIkZKgV JADLIOt7ojOLoeYy5nYkyMrVRG4oAxBijK57jvFDA30p1IEr2+MTzFg5d+VIvsdj /m/PeiudigxlB9bdBFLIcz3IVn1twph/k1FzgVU/9RGFfwqtC6rAwQ+YpJKdHNm9 t6Fa7IONcGmwrhmA/OVy0R11gubinQ== =MMBI -----END PGP SIGNATURE----- --zgpFZrJoFqpWfLgZhQkMvKNni9BbdAz5U-- From nobody Mon Apr 27 09:28:27 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789513A0E86 for ; Mon, 27 Apr 2020 09:28:25 -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, 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 bWz2tRVb6yZs for ; Mon, 27 Apr 2020 09:28:22 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70075.outbound.protection.outlook.com [40.107.7.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4EB63A0E91 for ; Mon, 27 Apr 2020 09:28:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W9zwWJDCajM/en5T5DBi21QtAfcLJ+MQQ3a+we0//vhsc46d5L9DpFq+6ZN4QX3WdDLRD2JEW7DxCYXfO8hUt59aDqKiBNABbm5FLaQLKsRsGGK1/9p8c1KT+jy4g1bTl0sRNBev0hRlaoZUfcKS2HHjW8FW2xJ9u6smwwIM9FLLLOdJJcC7EA704Np01gjVSjjvWlGcGvG2lwkgsIofLfx1jeNShx0FQrA9L7RI+kRcpXKnfCZhmEMJnTFFBjZ8HyFUPNIWN98R9EEW5GkCwheTFpFOrk2zNjw7Jq9oFD8Jsd5VKELuqwrH9IEKNGx5j2JIWMw54qTeJ14fUOYzMw== 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=g2MyfamqT+qRW6n6SYBtIYj3SOJCKzFd8xgCR6UR3qU=; b=Prtzq+TXB51kFbPI2VGkKWs8FCu/rLfivbEERWQBk/MdTSNKHTblgHpX1pICdL5eXFdWMt8VU1g1nFkxz7FLEjF2DqFdqkujboJRewr9E3hefzqKXPA3BEKPs1zWsYpAdZD6ZEKNMZtgyHvAKuSAXQqdGSywDb4PY1dfI51IHW8I9nTadv0lDU7tBS0H+bNnQ3lUqcPxmMANI4m3x2tYevP0LzeK7njD3HkUJZkayEKwMq5Y4IJqY8BUibiw06opaEX/Xv0fcLybTgR1eK8yxUCg5de19r3rQQHUvVVx7gRgeXkAYdLjOsOzBNWG1O75mFMxb+FOftfDfQRnUJZHpg== 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=g2MyfamqT+qRW6n6SYBtIYj3SOJCKzFd8xgCR6UR3qU=; b=VYDIsSOeEqo9umPEfepbtKyZNq2anTUuQTGAFYJJIiGeYq4oYgBzffKxyEnpZoRUOhwt4fLwM7zAmYEPXASnllyCjGb3YMNz7Qn49vzQSTyt0uDXBAPPnQdl/bVYU7pokuM7m3f7AyFBVvAV6D7KFgze9NaTtAedO6XGB32AsOc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0303.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:33::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Mon, 27 Apr 2020 16:28:14 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2937.020; Mon, 27 Apr 2020 16:28:14 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <2084d7f6-d3ca-4ba5-480f-de58fa632d63@ri.se> Date: Mon, 27 Apr 2020 18:28:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Xp4yGFLerm9C7GiPnYEEk7egaYHT6uhgD" X-ClientProxiedBy: HE1PR0301CA0006.eurprd03.prod.outlook.com (2603:10a6:3:76::16) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.16] (95.174.66.180) by HE1PR0301CA0006.eurprd03.prod.outlook.com (2603:10a6:3:76::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Mon, 27 Apr 2020 16:28:13 +0000 X-Originating-IP: [95.174.66.180] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f6c624cf-d0b2-4170-3fc0-08d7eac7fbbc X-MS-TrafficTypeDiagnostic: VI1P189MB0303: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-Forefront-PRVS: 0386B406AA X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(396003)(39860400002)(136003)(366004)(478600001)(5660300002)(235185007)(36756003)(966005)(316002)(8676002)(26005)(16576012)(21480400003)(81156014)(52116002)(6916009)(6666004)(956004)(8936002)(31686004)(66556008)(2616005)(66946007)(2906002)(66476007)(86362001)(16526019)(186003)(6486002)(31696002)(33964004)(44832011); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: ri.se does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: A8kQQDJ5BgqapgyLydYwE9PmJlPyCrbKg41YGY1al+0t7guZ2XhM3+tDwxYPiMzZWuIblbnFBnRyM6CPdSzkVJLyWRpvWOROw4dlS23TFBtlXIK3tjiBURM7bFkCVdwqUzEr3UCJ+I1tynSTDTxA97N64hwMbHillzSP16Fj9JFWo0A6PrWdhqAUdBiPEtK7hRECMi7QcI5e67g3eTsgCntupGHLvohCi0fKy3BQdmG2ZFx2Ah0p6UPYNqcYGklhCWhtRyigR8WB8iylluZ5At4LMDkDeAQ92Ie5odpgwjvkTz21UiBq9hT+XRzmQMopwlrBtNM/vN0fomz9qsylYigC2WYcFl1KvUlP/PW8WEzt7khyecjTIzKlcYV1R8a5o2LuqUjeDT2W+iC85EPx4jhonoEdg+2q5yOxGVLnzXqdKqCc9OiU5htIVn6zVbYAqNZ478O75o0kmmXXqruFUEisdBw36YGymGchqXapqOZvmZtUdWLz184NwWyZW2hhiLpKV7HDPK5Hvpct76c7FA== X-MS-Exchange-AntiSpam-MessageData: 2Z5hXznbOAr0uW4x1wTWyyj3/8TKxpeAtiJvVwR9/yk8wHnt+K7c2KQXnLOokNO0e4HtftGfJpZgZd6FOhwlZJ0mau5FzMi3YffuV2N85IoYkCqmX3HQHj66u4RMr3JNjX2MKET3gHI9ospg6y2DUOKh8iE/EtqjYCP0+rzpfyQQUt7tR7nz+rWg7xhQCfmU2MYDn2CCUTGjW8lNpGrsFo89m2KkyPUC2mGOI4HJWR1+U7AoTdF4YyohNAcpOuhclQNW8Jjrony1bGxfQZXBz7vAgV5VCtswXr/+pk8fWklDpW0lvdTfnUpEnN9s/D7i6ZTTqvVX49qtkQM1jQEyaQ1Soxi62YlMu1vwiswcWAsjfngBbQBjEN5NWvRB6xdJY9/oPX3lxjwKNDPR5DIamt71yiom6QsYV6JDi3jUVyNgrGYxl6rZ1NCjPFxjbiaWRXdL5HAotrad/Udc65iUQCeOzxyXjWNjmutg3XtVc3Z7ewsUQDmx2Pv72GjxWVyfJYYJBgJgeQEDVRaZrx8xq9l6o16laQAaivf13u5qrl5MU03JX6sBHl7JJfmx89EzSPLw0TgONU01RtHoNScH8n0UzaLNnDLEXYvOdoYjjvSK8aYMf1cA22QjEQZfv4Qrew9/YWtFBOB7Sw9idSs5TaGM3a1NZKT+z7yrqWZNztAzx1UcHD9OFJoX10bHXT0PhFo1WdI53WAQrMoXfDyyabEl7vKQ6FlazGgS2OrouV2Vi7SVG0E9bdyKL1jcAP2F94FFQ4pz6DfjVX2vn7j4kO6Fv3MCmGpudbDcJ6LTgpc= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: f6c624cf-d0b2-4170-3fc0-08d7eac7fbbc X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2020 16:28:14.5290 (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: AqBVraA+/Mj1J2+RV+erwl5zacJ3IXhcwIgx+hqCdpCeXq+1jvImlESd0AToNMw8CNFYXsAWXiGBEINq8MaYjg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0303 Archived-At: Subject: [core] CoRE Working Group adoption call for draft-bormann-core-senml-versions-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 16:28:26 -0000 --Xp4yGFLerm9C7GiPnYEEk7egaYHT6uhgD Content-Type: multipart/mixed; boundary="uSv6VJSDcIlwD0fFfJkgkJUTa88SEDQqM" --uSv6VJSDcIlwD0fFfJkgkJUTa88SEDQqM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear CoRE WG, Considering the interest shown during the April virtual meeting, this mail starts a call for adoption on: https://tools.ietf.org/html/draft-bormann-core-senml-versions-01 Please, reply to the mailing list with your comments, including but not limited to whether or not you support adoption. This WG adoption call will end on Tuesday, 12th of May. Best, /Marco --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --uSv6VJSDcIlwD0fFfJkgkJUTa88SEDQqM-- --Xp4yGFLerm9C7GiPnYEEk7egaYHT6uhgD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl6nCBUACgkQ7iZktA5Y 2kNxegf/VQTJ26J5M96GkIX25NXi3N5jFxeTHB7D0fzCSmdqy4sYZERlK2iktM6D yLY65nO2w4KJVYOiAqucG/ukMq8J7udVeVWKSf5Cd5uxZBetJMX+IE7AA7shfCPV t31WWlKBzLVfVrvSxoWjowouVRgIT6XHVkuVaxuz0xzGbFl5Kynzu2EpZGcEN3eK hvzHHAOWyUgBM/TwAqN89qDegILWU1+JMM61awa5tjaVT+tmYSneMJJj9LIp2cmz //nj8Pi1h7frA5Ep1NkVdglSpOjyU21Owk7tXe5x4G+8b7naWFhvH4JeVOYBPBNg HYaV9ACESbFxfLdsyN2Fvv903x8mbA== =7vnd -----END PGP SIGNATURE----- --Xp4yGFLerm9C7GiPnYEEk7egaYHT6uhgD-- From nobody Mon Apr 27 09:34:04 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92FF3A0EEE for ; Mon, 27 Apr 2020 09:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.919 X-Spam-Level: X-Spam-Status: No, score=-2.919 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.82, 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 HuABbSFWVXjC for ; Mon, 27 Apr 2020 09:33:59 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130050.outbound.protection.outlook.com [40.107.13.50]) (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 602ED3A0EEA for ; Mon, 27 Apr 2020 09:33:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dY/QF8klK3eCk2FCnWUr1xI77eZnT7scxzEqMuE9KabHO/5KeaSFWC/x+yNr+aUYnfExvlZ5MZi8wdru2I9OO3HWo/TG2J0oO7r2mKGeh6WF+7bdg/PpzXudLRR9mmLl76fHBQHhN91RnjgzLSjiXR2PSo0XfA1kLQ5pKgj9WM0/BSNGyKL2Vj3v+rv/O8PSD6OeKM7Y2idLfITaW1Kf4UioHaMzL2j1DZBGuLCnP2Ty6j2/nnS1F2rVFcMndJWhNLk6z4HUEni7YaYzTgha8uZipJT6O3YLZ5qgcyBQS8DC1jNOqwBN3esqDNdQrGyU5bwAahvys+E8vx8wHkOe7Q== 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=UUR+Fyd3tgm8HiyoOksSJHif9ylw60Dbv+x/YereS8E=; b=Vw9ldd2N0isIqLNGtCVzT8dj3shcMNv25XMR54mRnFGZ4ShDswqKJarqj1IawHGVGMYTsEurP68LmssIj4tvDl/m6mLwfkclugr+qyIKvc23PoKQr02TPzbDgPI9Colvn/sbl+NIGeYGK1i9p66gx9s63gPzX71Ln0Xay7OMqbv6AF18Ysh/6Ji4fEKq2Mgtd1/zxI27tnSq62E8fBdD1akkmdjd7e0KDeuu3e9WvE9AaiDorRHTBfev5X5SsS2WVd5egDLm561Mf/jZkrGMJEaLRVYmBKU3gCdoQUqmH3RVIXyfAZ1fhrhEJh0vozyli/gSZwZNAr+D2tlsUydxyw== 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=UUR+Fyd3tgm8HiyoOksSJHif9ylw60Dbv+x/YereS8E=; b=ip4hmGqGmqAyfMZSUt3xFf5bIcjkPC2aX7zkDqHdsVeB2MohNCOQ9qKiZrFDoClX7N1kcAQQHIg5102KhtEL4xQwh5V9O1SYhENBLK6KYaIlxENsIQ9WK81+9q0+JWy+sO2OAk/Sf1Eh7UwYzaX1wx6x2cX9JuurJgyWGEqQybg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0431.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Mon, 27 Apr 2020 16:33:57 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2937.020; Mon, 27 Apr 2020 16:33:57 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Mon, 27 Apr 2020 18:33:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gpvaFchwcCOWMZndbXnZkHIxIZgmmYEJi" X-ClientProxiedBy: HE1PR05CA0212.eurprd05.prod.outlook.com (2603:10a6:3:fa::12) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.16] (95.174.66.180) by HE1PR05CA0212.eurprd05.prod.outlook.com (2603:10a6:3:fa::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Mon, 27 Apr 2020 16:33:56 +0000 X-Originating-IP: [95.174.66.180] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7b01f96a-5c50-4277-d384-08d7eac8c811 X-MS-TrafficTypeDiagnostic: VI1P189MB0431: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-Forefront-PRVS: 0386B406AA X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(366004)(376002)(346002)(39860400002)(44832011)(2616005)(8676002)(6916009)(5660300002)(478600001)(966005)(16526019)(956004)(235185007)(6486002)(36756003)(31686004)(21480400003)(86362001)(6666004)(26005)(186003)(81156014)(8936002)(316002)(31696002)(66476007)(33964004)(66556008)(52116002)(66946007)(16576012)(2906002); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: ri.se does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: f34eZZbvmhe5iB0l1o33P0UApcd2m7L918kRTgpF/K9FZ+8JVw4ENJprjEESv6Y2ji2E3StTYdjwpk+fFgm863IOEtJatuMhMZJqcn+QDrfRVUHqxgVcBWpTKJpjHoPE1e53nCt9F9161aqzbN18d92eeAlcYL59QonwG+A6zpR6p/JiQNKuCzQxZsho3sYfg+orvMxxEqItjpuqgysnTQfcsKYaEE89L9fOzt72TsgU0y/d4QTQs3J14Za+JMK1/FpcsbtSyXfuQsqmKqaX5/mHILflYJBpGck0ihAi1/7U1tdfsEBvGSgnH6bpYZF5fUhDu3MITi9D8Kl3miABRhcQHfysiEdbxGB5+ObhxCsmGVbk0iwJE3LIfvVnxX0tzI4SFYTSsF/zYG2u4qDr/DrC+390hGXS81czySq2gsdpsQxM9T00yb/BAXhgHEuUXDZ5wfTNYmhgBdbNakhQATCHiz72rvCrodC0LWzU8QuhdE+r3c+6CYhuP7/cdrJnosy9EXIKQVp+tUSS+2gPxA== X-MS-Exchange-AntiSpam-MessageData: Rol9ChVU3l8THotsYV5APfx8tdTpJTlLGRu9h/kZTWDYFwiwVseirq9fz4kLycq23sDtvsyF9k/LgmemhGCrXzu88HlFUt1M45WydsYjLgZDzdoEDRzW1VIioveuF3sNFCnRSwDb669YTg40eCIyIOKxNAvSHNJFW3ZTpECONyF2YoOwR36abrDdNuDLfUxm/It43JsoDDduatHVoywzkIhppdn8u2Gm3s8Pm91iT895rAJx19iXFLcSCmnCGOBQkeIPm/XNwaSYvOwjlck2EWeJSGNOIMmHus9Ty3fi8ZPF3/erR/W+FPidhbZCZZs9G7IdlxoxhXcMq4XVvs5j3z7y7apy5nPqErdws4EFUAH95H1HQxe6d+xVupHQMtxuKLv3fubNUW1WaYJ6tLQtiPFwufxnlKvO44pVgxia6gopmuzNR8LT3XAc0dogn+BwldZM5llvEq+h57iUDD8WW33/IOx/bSdWXJNgCSvo6Hnrp6hQX3c2lMS1KUGmD9BdXbI/fexrhK5R2pn4XsKUHtT32pHP2ZvK2LJdoOxEcAqWQtkqJlVh2CsYudVtgR8c6FMJylB7YDckLe+VAmNcvtHbKC71OZpNfDVdMzLd+qX26hOIUs0UWNxsAICV0xsMavQy3XdO1NH1TtyP5RbiuWFx/7uTm+uA5Vm9f4o3nSJs2O+buXQ8EqrENkFw/aFp431ZxV/QWxEBJgjO75Tn8jYfL1YcQFyMkD7m1O37yVCEm6U0yHmTto385RMkTYNn0Y0IMri2RAOWCC4PX4lFGjuLNzUimNPCLWUxaHzASFk= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 7b01f96a-5c50-4277-d384-08d7eac8c811 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2020 16:33:56.8953 (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: l7nJK2JWPj8yAmk0ukym5AxDtHosE7MNqIT5CiGKU6OIbrZp6u0O6xvpz7EjgrVXCtppvsfWeVGEgEbO4CGPgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0431 Archived-At: Subject: [core] CoRE Working Group adoption call for draft-fossati-core-coap-problem-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: Mon, 27 Apr 2020 16:34:02 -0000 --gpvaFchwcCOWMZndbXnZkHIxIZgmmYEJi Content-Type: multipart/mixed; boundary="RibKFZhW42JqFeBDqeo6gRJ7M74vkFIw2" --RibKFZhW42JqFeBDqeo6gRJ7M74vkFIw2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear CoRE WG, Considering the interest shown during the April virtual meeting, this mail starts a call for adoption on: https://tools.ietf.org/html/draft-fossati-core-coap-problem-02 Please, reply to the mailing list with your comments, including but not limited to whether or not you support adoption. This WG adoption call will end on Tuesday, 12th of May. Best, /Marco --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --RibKFZhW42JqFeBDqeo6gRJ7M74vkFIw2-- --gpvaFchwcCOWMZndbXnZkHIxIZgmmYEJi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl6nCW0ACgkQ7iZktA5Y 2kNBTAf8DfLS20IgUcGM9UM/q4QiuGE+yhRyOGSLwNztbFpv4W7dSc3vJCI5iEQX 8IAa1/FJkYV8ni8U/dt1uZmo+l94kwp9kLz0pipQOvLW0og/MCXRJheoUaHCRRCQ sS7kXmpONgj1l2MMZ/2xeljkosImfoU5Cyla8Bf7bNN/waFfDJ3f28tQm1SgVNmW UV+Uw5YKi2kZyX0jgMViZ7EQvgGcASuF70HGr2Ehy6vSQWkItxJNzZEV5kxc0N32 +3FFn16Q46ZGzvXjhuL7PMd8hKy4Tx0Cd3q75yJrXcJqhCLW9ho3zIJmzl0IRfDa Va0G2QmZLuFllwbhL1Wt2uOmX5clyw== =v+fF -----END PGP SIGNATURE----- --gpvaFchwcCOWMZndbXnZkHIxIZgmmYEJi-- From nobody Mon Apr 27 09:46:08 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3694B3A10E6 for ; Mon, 27 Apr 2020 09:45:59 -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=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYxpvxxHVYc4 for ; Mon, 27 Apr 2020 09:45:57 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id C74743A10B5 for ; Mon, 27 Apr 2020 09:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1588005956; d=isode.com; s=june2016; i=@isode.com; bh=XITXTqBGUFHQDvZEJxhhBuKGB2zWCNNDXQgix/5JYUw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Xe1NF6fPBFwDgV6yZf8c9C3EZlhzyX9NFBkkju6JSS0AG5Y2vJB68bED6u5LswRjkBH5yo iKJqXol1j8oMdzdKlTeuBA7/PQgMPJtBV6X8XO48Zqno4ywJjsisRok9cf+O8a7niAoroE R9BAn+Za91PZOe3kX7C7dhRxeMSbcAc=; Received: from [172.27.255.19] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 27 Apr 2020 17:45:55 +0100 To: Marco Tiloca , "core@ietf.org WG (core@ietf.org)" References: <2084d7f6-d3ca-4ba5-480f-de58fa632d63@ri.se> From: Alexey Melnikov Message-ID: Date: Mon, 27 Apr 2020 17:45:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: <2084d7f6-d3ca-4ba5-480f-de58fa632d63@ri.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [core] CoRE Working Group adoption call for draft-bormann-core-senml-versions-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 16:46:06 -0000 Hi, On 27/04/2020 17:28, Marco Tiloca wrote: > Dear CoRE WG, > > Considering the interest shown during the April virtual meeting, this > mail starts a call for adoption on: > > https://tools.ietf.org/html/draft-bormann-core-senml-versions-01 > > Please, reply to the mailing list with your comments, including but not > limited to whether or not you support adoption. > > This WG adoption call will end on Tuesday, 12th of May. I just had a quick read of the draft and I support adoption of this document by the CORE WG. Best Regards, Alexey From nobody Mon Apr 27 10:03:56 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAA63A110F for ; Mon, 27 Apr 2020 10:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.82, 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=x1eW45s0; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=x1eW45s0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQt7xBplv5oj for ; Mon, 27 Apr 2020 10:03:51 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20088.outbound.protection.outlook.com [40.107.2.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E2D3A1130 for ; Mon, 27 Apr 2020 10:03:50 -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=sPideA2cV4FZireLigK+R6pi9Q54/Z5WufRAJR6mAcM=; b=x1eW45s0rqXah4VLAZo2bQDKO1eue+scBM+/uz29sVHt/JF2B0rjn9xyKb3lV+mDBR4+o+ZU89wpz1itoBBYmxH54mkIapN6KVrMFpxpQYKLLs5Og+GPt8XUu8NV9Q1w3xRO50hh9gWQ88Zem9QPjYBwKYQP1Uw91MeC3eHDAjE= Received: from DB8PR06CA0059.eurprd06.prod.outlook.com (2603:10a6:10:120::33) by AM4PR08MB2657.eurprd08.prod.outlook.com (2603:10a6:205:b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Mon, 27 Apr 2020 17:03:48 +0000 Received: from DB5EUR03FT056.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:120:cafe::12) by DB8PR06CA0059.outlook.office365.com (2603:10a6:10:120::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Mon, 27 Apr 2020 17:03:48 +0000 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=bestguesspass 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 DB5EUR03FT056.mail.protection.outlook.com (10.152.21.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Mon, 27 Apr 2020 17:03:48 +0000 Received: ("Tessian outbound fb9de21a7e90:v54"); Mon, 27 Apr 2020 17:03:48 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: d551d60b4c752d24 X-CR-MTA-TID: 64aa7808 Received: from b3d9da4826d4.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 590B53BC-CC03-479D-AC83-1D07AEF46979.1; Mon, 27 Apr 2020 17:03:42 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b3d9da4826d4.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 27 Apr 2020 17:03:42 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hARVtI3twmqsE1VOdrqZLyYVfspMfCeTBYgAyW6iXWAWpLOLSfaDHuUSofYC/EKq+uQEmxdgYYjY8yF1/JxANZDoxfEPjyQx3CFcFSWdC1qyWDd165xcmb9iyw5MyS3s/oNplm9+39PN+CxDgp212bVv10E8mER4EJDMJD2YBajSaQW0BMaaCbhiTehJ/2qXyfe5LZPS8YeprqAhXLdCNmYGjLJX0tA4EHvXxHkdk8WmrZ5esva9INrHJL7NVcSyvEECP6QkytX460ir7oEui17VMTJN7gfeEZwq2xrf22lkKfAmcJHJeCGk6FzmmJtasYUfc159Kc79g8AZ1PdQdg== 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=sPideA2cV4FZireLigK+R6pi9Q54/Z5WufRAJR6mAcM=; b=F9aUjpg3oJUZ8zSwrQLodaS18zJflhGfdOLC6P0BXxppuK+Jv+EpYIhEdfOn1nTovb2aih6g/ZB+lR2ZKuRDh7x905GlZRN7JU9UpS2HQJ51dJ5I1J1+HXABMrvTMkubRd3sWSNA3fIeMiif3vtjZlNOzf7GFlborz6RWVAWL1O8TE8GKOmHJzJM2ZH4Vo8EAiTaiZiunMdj1ws6yMGXq+TIO8az/52OkXqyK9Jl817nHz9PBjid7M6i1OPDW/A8Ay2pd4e1bVL0bccjd603GMs5JgrC3HLBLZfClceWazbcvdtAbK5PfR9Xqrki0+qmMBLHIZJiJXIfmklL927EnQ== 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=sPideA2cV4FZireLigK+R6pi9Q54/Z5WufRAJR6mAcM=; b=x1eW45s0rqXah4VLAZo2bQDKO1eue+scBM+/uz29sVHt/JF2B0rjn9xyKb3lV+mDBR4+o+ZU89wpz1itoBBYmxH54mkIapN6KVrMFpxpQYKLLs5Og+GPt8XUu8NV9Q1w3xRO50hh9gWQ88Zem9QPjYBwKYQP1Uw91MeC3eHDAjE= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB4965.eurprd08.prod.outlook.com (2603:10a6:20b:e5::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Mon, 27 Apr 2020 17:03:41 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d%6]) with mapi id 15.20.2937.023; Mon, 27 Apr 2020 17:03:41 +0000 From: Thomas Fossati To: Marco Tiloca , "core@ietf.org WG (core@ietf.org)" Thread-Topic: [core] CoRE Working Group adoption call for draft-bormann-core-senml-versions-01 Thread-Index: AQHWHLDmfHwVMvWLvUGIdd2nslhSIaiNQvoA Date: Mon, 27 Apr 2020 17:03:41 +0000 Message-ID: <5B455CF6-C8D9-4CC2-AECF-F3F3F11D42BC@arm.com> References: <2084d7f6-d3ca-4ba5-480f-de58fa632d63@ri.se> In-Reply-To: <2084d7f6-d3ca-4ba5-480f-de58fa632d63@ri.se> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 0fe54b49-6295-4cdd-07de-08d7eaccf3c9 x-ms-traffictypediagnostic: AM6PR08MB4965:|AM6PR08MB4965:|AM4PR08MB2657: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:6790;OLM:9508; x-forefront-prvs: 0386B406AA X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(396003)(376002)(136003)(346002)(6486002)(2616005)(8676002)(6512007)(71200400001)(33656002)(26005)(4326008)(8936002)(81156014)(36756003)(4744005)(2906002)(91956017)(76116006)(5660300002)(110136005)(66946007)(86362001)(478600001)(66556008)(53546011)(66446008)(66476007)(316002)(966005)(186003)(6506007)(64756008); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: AugqXdV8rKPQyW7KaEUEb/co/Zi9vCnWVwEZT1LdthGACt86lNStMTLiGLwB2qY4EEr2wKhlcGU5YRZqRqjxJT8lhWVodXhHLFtr/SuDa3h6oKY7opP5S1rl/XNt7R6iSzQor8+dXTRWg3D6vFzo5zZaG2oJzj+z0MIv2lcvttJxfNf+d6RkCX/jRLd5UngAW8k2zzqMUZbwhO046TWiPp/SDRzKIfdCeZdEuibjemM1lMF/ds/ghNzViYVR26xtL3MZORKs6tFZQmCQuqwkLdzX5Ty7R2tobPYlPvntcM9QSv0d5dnSGEW2Mpts9wegr4wvSabCp5Xv2yXU/zrVSAHRK+bw9k20YO6bI0U1neWHxYg/IiCjYr1b8LJkFgwKnvyLB6zLlPy21tXLS5vUKyYO0+Qms/mJKv7kLT4V10xq3wpqJVhTc7JbW+4PJ+YGlPezda547970Zqjap5a8qzzU6PF6UQDQEG15rsPOSupv2xJQI7yquEVO2m/MIzfNR5KHPo7npBGKfp7JOKrfpw== x-ms-exchange-antispam-messagedata: NgvA0CvdXXN6blLDQo45ofDb9tGdSjPEYa6uu7Y4c2xCjayQ+H1NzgwZCqv5U1/IXgSa5t/UR4ZgP5P/7lULDSWJQ5b+92VwiANTAY0cEuWrhXE3R8ZZx5vYlIg2Kx9MPREdHn+DGG7trnsWNT4TGfLx+kn24W41uiJOkwy6p+bRBPddDXZGkM7ep6wBDsAJc2mlw4NshvVw9FjdEqEKf0zFy5VTbkf9v07Tu/iF0tijWRyipPKKKOj1XU5uhLMHM1xScErNx6ju0vClDH4xJD44olnPUNV+prNFJ8Vm4t8oUv+KEIS4U4pv2vJS5DVKDZLJoaV9I+nUIW1Ml+3aG+ZoiSRljtB+VmXdFE17LQ/zR4m9y8KrcSN5Rnx5A7ZxGCxAatCc+5XwmNQQEFikd/PXCzXeJwnEgdCtkulA8Mi/y5tbNTSb9fCAgcuV0AlzTS8++nMdH5YrPOyN1VJ4OScDctsPSg+he0qPUacVq19XksERUTEtrAsPbpq9JvnYNIdLeK/SgzIDV8zVkAslptpSZeFQdDdUR04T2ezJkkA0KxyXhkAZaLkmBlcVO+bOKvJQHfk4UCX3Hv2JAvUCDSUFtt6bkfnPNN887LO1VOs0MI8JW0uXwA7fLeN+OzMLeJG/lqljspDspPJVdcqPJilTKQYKKfDQtTKM1IsuetmJ9s5+5X2BWM6TfK/1LTJ0MkJe/QSuCKCHkm5l56LGaZAwHK2MDXhGEK+0ZilDsVWQK/BXu7ll4CTxVVxKCYHD8Ol74JDOFCW9t5/tCcQ7Vh3S274Gpdjmskx1d0uJJzo= Content-Type: text/plain; charset="utf-8" Content-ID: <3C5FB628E8A7EE488C9A5C717930BE68@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4965 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT056.eop-EUR03.prod.protection.outlook.com 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; SFTY:; SFS:(4636009)(396003)(346002)(376002)(39860400002)(136003)(46966005)(356005)(82740400003)(33656002)(186003)(26005)(36756003)(2616005)(53546011)(82310400002)(2906002)(6506007)(336012)(86362001)(81166007)(478600001)(6512007)(966005)(4326008)(4744005)(5660300002)(8676002)(70586007)(47076004)(81156014)(316002)(70206006)(8936002)(110136005)(6486002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: f9d27f2d-8786-408b-fd22-08d7eaccefa7 X-Forefront-PRVS: 0386B406AA X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: qoc5G9nfYCeenCo2dIGqFDnsQ6H4vQh6SylE/uW4+UpfsW4k2Re2ltQFQGPG0K0jOgl1DfA8KDYHLkN5uD4i8671uvGWm2lABMLDzqw0y84kQv6kpy+awhqokQdbGkpshVfFZ46vEn2GosLI952EAqIcMW6h1/7Dmbyqh59/bNPDpxMTlfWritaBjyKG34C3+AeTvOvl4C5bQKM2Qb4rtR1+iZoM1elS+VWP/bFAmGSuoe9iHAWkY6nzcxSzcD9UVKabEMrDqm1alvXBY6/mRqH2W91E0HaHfFX1j/Y+Fpm7Ud4J/FfUKVQj+7BejnWpvbUagRMRu5DKZEIME2QpPSUdwIjgd62tHVtD2ZKssz+ebM2y0wKj+gSGRYtN1Fbf8xY1uQv05Xtx4Hxe2wB2Ar8e8bzqOOKJuVtnzhwC2/sf6QV6bdkiqMa4nepwzBOYDkevXmxSHazTN91a+kuBeGUkzx14/o+pqlzvYuKI9+vzR/+BEMTy3u5asBcebLc5cLm3lNG3e7T3rA/XrtVzLKFqfgj7t6hxiQnFMZ/ereYXFBlX4IPO/92HrxfrPwkexA7o1TD2DjTnOCeIh12vuA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2020 17:03:48.0420 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0fe54b49-6295-4cdd-07de-08d7eaccf3c9 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-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR08MB2657 Archived-At: Subject: Re: [core] CoRE Working Group adoption call for draft-bormann-core-senml-versions-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 17:03:55 -0000 T24gMjcvMDQvMjAyMCwgMTc6MjgsICJNYXJjbyBUaWxvY2EiIDxtYXJjby50aWxvY2FAcmkuc2U+ IHdyb3RlOg0KPiBDb25zaWRlcmluZyB0aGUgaW50ZXJlc3Qgc2hvd24gZHVyaW5nIHRoZSBBcHJp bCB2aXJ0dWFsIG1lZXRpbmcsIHRoaXMNCj4gbWFpbCBzdGFydHMgYSBjYWxsIGZvciBhZG9wdGlv biBvbjoNCj4NCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvcm1hbm4tY29y ZS1zZW5tbC12ZXJzaW9ucy0wMQ0KPg0KPiBQbGVhc2UsIHJlcGx5IHRvIHRoZSBtYWlsaW5nIGxp c3Qgd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNsdWRpbmcgYnV0IG5vdA0KPiBsaW1pdGVkIHRvIHdo ZXRoZXIgb3Igbm90IHlvdSBzdXBwb3J0IGFkb3B0aW9uLg0KPg0KPiBUaGlzIFdHIGFkb3B0aW9u IGNhbGwgd2lsbCBlbmQgb24gVHVlc2RheSwgMTJ0aCBvZiBNYXkuDQoNCkkgc3VwcG9ydCBhZG9w dGlvbi4NCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxl Z2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMg dG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3Ig Y29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Mon Apr 27 13:11:56 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6F53A1BCD for ; Mon, 27 Apr 2020 13:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, 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 nKAM2J1E88Ng for ; Mon, 27 Apr 2020 13:11:53 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20056.outbound.protection.outlook.com [40.107.2.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 571313A1BCB for ; Mon, 27 Apr 2020 13:11:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LfVgvsIS0KvEFkBGXLzH+UIFaAp0qAbtJHO0wNz/QiXp4///5x394wQYBvOGDz0Hw8XN3GCbCwEchz87Z4aOPi9ET4/cjU4XCxmY47T4L4T5pcgR3RKmfz0x14x+hIuGl5fS/RuEbcOof4cCxrZisu3fsf7VSJucsMRwTjGc8HN0gf3ahqNNyZAp9B4c1GjHoaqw/FUTxiRQ0uRHToOJUAu7zXLGR3MCsAhO/sIGuy5Nq21STyFrNY/ao/sR8uxLJK3kuyZfUAAM/GkspRfBCuoj4mm14rYPH0RKGVhzOydDLIc7ihbmTGkiAXtdfqNsF7QpMIhLuZy7Sul2HjWg6Q== 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=StV2wN1Q8DhDB1Ru1F2jAnxJRGVfN5MYn0hil48Ect8=; b=CjG26yhj6iE8/Gl6yTOLfigo8oEsbuseOb0EfjUpGDTp1bSecLnKcsh5FYkL1H2LM0vNDxSN8z1zKtd5g4vvcRjg/pvbmoQG2SD2J0zR4wojO8O3HBsTwKjttbHc4SRf6LY8jMiiPKJFip4m0ve3e7GqHvKUeU3pAigW/4V4PqtUyXVfU+bW0g+oMAmIorrdzJdGeuWH/4N30nQ5ltAiIR2beI8c2AjRAGnKaNnEdEwHnrWBCsxcUPMEAkKI1SXSBuwP+ZoLdom4D6y9HD9nixpOZjzKwWpXXWtROFfSaPlTS2a3ENRlzp/ZAunLtCDRcEAUrzFahxEyz1a91NGIXQ== 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=StV2wN1Q8DhDB1Ru1F2jAnxJRGVfN5MYn0hil48Ect8=; b=WIBqw8ao77dpWUgBINTQdIPcCgv/n1wRWyJl5E5YoB3ijw/NX6OEFluOxUhR4w0FFrN+N45BPXgfrJoUypcXQL9G/yOpTNmenn1maeIPguQ9yeSF+SAobocmTROQsfabiltBxX+4XDCLf5SAxPauhkKQAbtzluS+f6g4K1L6Uy8= Received: from HE1PR07MB3226.eurprd07.prod.outlook.com (2603:10a6:7:33::20) by HE1PR07MB3163.eurprd07.prod.outlook.com (2603:10a6:7:34::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.7; Mon, 27 Apr 2020 20:11:49 +0000 Received: from HE1PR07MB3226.eurprd07.prod.outlook.com ([fe80::61a8:cb1d:fa94:efc3]) by HE1PR07MB3226.eurprd07.prod.outlook.com ([fe80::61a8:cb1d:fa94:efc3%7]) with mapi id 15.20.2958.010; Mon, 27 Apr 2020 20:11:49 +0000 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Marco Tiloca CC: "core@ietf.org WG (core@ietf.org)" Thread-Topic: [core] CoRE Working Group adoption call for draft-bormann-core-senml-versions-01 Thread-Index: AQHWHLDonSvqdyYVgUuXC0fhvxwrxqiNMjiAgAA0kIA= Date: Mon, 27 Apr 2020 20:11:49 +0000 Message-ID: <4D7A269B-B2A7-464D-8486-C828D97675CC@ericsson.com> References: <5B455CF6-C8D9-4CC2-AECF-F3F3F11D42BC@arm.com> In-Reply-To: <5B455CF6-C8D9-4CC2-AECF-F3F3F11D42BC@arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ari.keranen@ericsson.com; x-originating-ip: [2001:14bb:190:116e:2484:109f:2ac6:3766] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8004bba5-c2c4-4811-8cb5-08d7eae7384c x-ms-traffictypediagnostic: HE1PR07MB3163: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3226.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(376002)(396003)(366004)(136003)(6486002)(4326008)(76116006)(36756003)(8676002)(66446008)(64756008)(86362001)(2616005)(4744005)(66556008)(81156014)(85202003)(8936002)(6512007)(186003)(5660300002)(71200400001)(66476007)(33656002)(6506007)(478600001)(2906002)(99936003)(85182001)(316002)(66946007)(966005)(66616009)(6916009); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tBej6/odgUjuUrvsKjiLHfX9lS1s/E+1dAd91YMA4zVcWbxDt8CwTEd83JvHnMefi65igmWr2oNBUBzb/nTuJ8S5O2h3FO6BXIkYtd2LV3GOQ7iHs0eHJIFPKpRpZ7BEqfZq0ZLwBPwUR7zo0T1N+JIu9RYSWYYawlNl3ZxNH6Q0XWs1OySVl5Qy9np6xgRoHZ5EqNsg+pWpuoeeEdOCKWC11z+ZzB2ZgPpbpTO/1bZ0yqaUrn8gWnAnbsQ1W0cAnNz/0wF6PBJmg5f2Y9WXdo6X/zt8ifqvMZ/mODN+1KThxi45AdijuvOQ2PDdX3/e/jaKuO+5BGjTtipMRvl7mGBG9tDImcczLgrJPL5YwqnF2Oqpwciy8FZCTTVMyIqC3b6NE9hj0Uyr56lEk9EliKpthg8MoPvLJxaPtlJRpybUiazFF3OPizt1KmG5ZdnjoCaaY7bWx0GeB03oXfAvRyf3olzR/YQCSOZmkMZaIlz+Xy9r1K1gE9e3eQjpQ6JqYNyWQ6kn76/W+Q6WnlLVSw== x-ms-exchange-antispam-messagedata: 8Vn0L56RkvqrC6h5t3pJdOzLT1s/7vmaq2TthO/VgKB0btIfwowOkTgxo+Eo2XUeSBZNz5WIZs7iGpqGpPKIkbrR5BwsKB2PyiP3Ym4RCunuuZ98chuwUnv7crtHQSecCQfrMuk5/yHF6JIj2kb7KGyCuzL2KvZbirPzV+Z6HDq1BynZ+mWnoez/BiresbB5XfckbQURMRBqnsyoAmH1X0Fr1JcWvqa5rkPbNkjuyoSaW5zjtFM9l8r0kEuxa2hr0mWRF8HwiS/seme6aGNkOHaA5jvIF5aVHXrFkLWah2gDwEeQe4l5FW+nvZsplwnbP1e9kbH/giHkkdZfTPbLPH6ZWYVE0Qr6Pulii84kC97QiLpJO3GRzEIfB80oiNhYAf8CLu5LlTUm9G8BsMaz0WotuMeDVxcpcJtNsquPWIhdYqVic3mkZf9W6U4U2M8CcSl6cny/KQ0h0aGfIvs6pv0majFc0h7jCw6NlReFhVbGEnEBJ0H2yFre9VMwfqm6mX9MxBfYqdFseF06jFOvJmBvk/eiKv08NNDyXXnzxpZxdiKJiaI2umSni3RBchkp6n8syPMlVLZu2BwTjNsAlr15iATk1NdvCUbsSBy2HxPbfBIflt2QO+i5Qzf3BpULJB9eIFG3O47TMVEtnR2yshO9QBNB3u5LgNNW+f2qsW9hD9XQQcF4ofvQDtbsjsGB9+H0p5KbLbNfMyhk5NIb+afNJMZmg+3qQz7gyhkKTBiPJRIwWUpNtvcwKUXlOBDxHEPKyooLRmJuYGgewJ3Ky+sGOTdwD6WOwyv3piAa9zQmozlh9lRJRiPyeG95O9dtL18C5lqRoti1ECZwUGjIeHgNSKavgfrH5s96kyZIr5g= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; boundary=Apple-Mail-946513B1-5219-4962-A45A-3CC57DD2E98E; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8004bba5-c2c4-4811-8cb5-08d7eae7384c X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 20:11:49.7681 (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: ze47jDFwFGAwk12PVopcvKrEBIWEetAB5COp34EiNy/vVa+VNO9NGazw6gJWRdEbWXrJf4Iw40P6LyGy5eXQMRCSW9a1i7AKRhFothi+EXw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3163 Archived-At: Subject: Re: [core] CoRE Working Group adoption call for draft-bormann-core-senml-versions-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 20:11:56 -0000 --Apple-Mail-946513B1-5219-4962-A45A-3CC57DD2E98E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 DQoNCj4gT24gMjcuIEFwciAyMDIwLCBhdCAyMC4wNCwgVGhvbWFzIEZvc3NhdGkgPFRob21hcy5G b3NzYXRpQGFybS5jb20+IHdyb3RlOg0KPiANCj4g77u/T24gMjcvMDQvMjAyMCwgMTc6MjgsICJN YXJjbyBUaWxvY2EiIDxtYXJjby50aWxvY2FAcmkuc2U+IHdyb3RlOg0KPj4gQ29uc2lkZXJpbmcg dGhlIGludGVyZXN0IHNob3duIGR1cmluZyB0aGUgQXByaWwgdmlydHVhbCBtZWV0aW5nLCB0aGlz DQo+PiBtYWlsIHN0YXJ0cyBhIGNhbGwgZm9yIGFkb3B0aW9uIG9uOg0KPj4gDQo+PiBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm9ybWFubi1jb3JlLXNlbm1sLXZlcnNpb25zLTAx DQo+PiANCj4+IFBsZWFzZSwgcmVwbHkgdG8gdGhlIG1haWxpbmcgbGlzdCB3aXRoIHlvdXIgY29t bWVudHMsIGluY2x1ZGluZyBidXQgbm90DQo+PiBsaW1pdGVkIHRvIHdoZXRoZXIgb3Igbm90IHlv dSBzdXBwb3J0IGFkb3B0aW9uLg0KPj4gDQo+PiBUaGlzIFdHIGFkb3B0aW9uIGNhbGwgd2lsbCBl bmQgb24gVHVlc2RheSwgMTJ0aCBvZiBNYXkuDQo+IA0KPiBJIHN1cHBvcnQgYWRvcHRpb24uDQoN CisxDQoNCkNoZWVycywNCkFyaSA= --Apple-Mail-946513B1-5219-4962-A45A-3CC57DD2E98E Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDMAw ggX2MIID3qADAgECAhA3E3FzLlznzicd63Rv9v4YMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMDQxNDEzNDRaFw0yMDEyMDQxNDEzNDNaMGUxETAPBgNVBAoMCEVyaWNzc29u MRUwEwYDVQQDDAxBcmkgS2Vyw6RuZW4xJzAlBgkqhkiG9w0BCQEWGGFyaS5rZXJhbmVuQGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWFyaWtlcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AIUlV66I5z1/qGYdhiIGfyvv8aaZexDetFCPlauUh5ugtp7Pf7ynpPRIK1FeWaoKs+IJ3E9R/9wT APFzjzjXpjyHHoBUdp8ZBuL/kt60cUTHTD4AScJGUHEgy70/Uf2YEj3JJjrTBbFnqDcXWTFF1n2Y edmhZDBdzZQJ18tlIjJmxgAJB1clI0nEg1gBnhl8mVdQp+ar6GjvxXfRuA1+uOpxa3y4zUpzF+ha LmaC4a5AbOsROtr7Uad8/pCzulAvAmPXvEJ/3JusafQfiqxNv1J/fT6W7sS8dBjF6vv3LgeAnYj5 /imtl9BOurFol0aIic+AjptfNoVf2pDhgYxn808CAwEAAaOCAb4wggG6MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCMGA1UdEQQcMBqBGGFyaS5rZXJhbmVuQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYB BQUHAwIwHQYDVR0OBBYEFNHQXDyNP/SSyF6+EMLvo07phb3FMB8GA1UdIwQYMBaAFBx7GZ6XnHas ID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAVVggYWTwdz5B iMeBRYLop6Jo3Ji9YmfonCRFiyfw8he+efYc59IwzU9eIBRFSiWf87eqcZZJjcwWjHuju3MvzWsp 1qHnirszOtcNrUflFBoY7N3r19tG+z2bE/bjjZPituSIgCoX28IgLZLpIcnYg7niWXnwR3xGiphs EPO3mR3p7f+XLtdy+1qU/rAjZoW36mZuYk1lV6nIt9GfhuH1/yIQd5pxTDj54j3TOLv/KrEKwCFQ YLkho6zrOicpJk7DkjYGNLwmaDTRxuehMQHKDW+fXi1xi7/eScV0YnELjxXGuE3HojEkLB8Offfa /5TICfBN2HTASXJ0YsbpnAxPTyjExmKzl3mudQz6x5wP6THhM0sltX8wHVQEhU5w0uyLfT9yqWVY KTq+9GI02S9kzD+u1AWtftbWK2CQIGUAE43faZGrCchkT+fnYz5b1Ppyf5H45r/psmsA9J63iFCz nilKlo9M47fQPEsqpFWvDfE4jdobqSmQXp/aK7cvYoAEhcj5vOqR/bPNum7wWegQZdDsfy35vZl8 +vtRrKAk/6bmUfaiazqQoGq+DF1OL7sQlb1HbMmkJblrrBf8Csh6wdEVFey6vegBSIwtOnmcAFN9 2NlKp24f8rJxM17M9pWNG6OsmCGhxyo4k1BHn69nXXQfSN7QdqLpGfhQfpJL3LgwggbCMIIEqqAD AgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29u ZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1 MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3Q3cY VVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldkUgUg MKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZYzwN v/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKHMgZq QvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6kmH/ KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup5dpX bxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS3b6O Moc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOq QFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3Nw LnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1 c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYB Af8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9y ZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0 cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQc exmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkq hkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bO ULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9jWQk MrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/ajdbiR sehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzICfsSr Z4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZcdAOZ oviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBdLoo4 gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTomgCF z/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJzqgb 8ToH7WLoOzmPRCmPlpAxggLNMIICyQIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmlj c3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQNxNxcy5c584nHet0 b/b+GDANBglghkgBZQMEAgEFAKCCAUMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMjAwNDI3MjAxMTQ5WjAvBgkqhkiG9w0BCQQxIgQgzzIs9SUdwNgQkKcyerW0i/z/ n4hD0Va1B406OlXUEsQwagYJKwYBBAGCNxAEMV0wWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEDcTcXMuXOfO Jx3rdG/2/hgwbAYLKoZIhvcNAQkQAgsxXaBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmlj c3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQNxNxcy5c584nHet0 b/b+GDANBgkqhkiG9w0BAQEFAASCAQB62e9nFAxMKo/whz/STRH1r39jkBajcyTsG8t7lNC14MqK iT3l6vu3r0kFrmZf89BYdkmF3KuhOCpwFZ8aeaKaOCWT0fQ4UzXJPdYYXhmGOocpyLm6PxnRdUlr 2e8SZGLCe34CXI0MtC22bTnd287V8h6QkBP903O+WfB6RBD9gCU6nTmFjtiYAZf/U97Hz5x7S/Vd 7eKjwI3VLNhaPZZimfqtW81I15wkfZRyVADYAcyhoR4YLZlCXvxlYf+jpU+qH6GkpFZBgQGbf5p+ 35MO133D+buZqMCD1/LXbwndqgjZuBrjedhODDCuqp7q6B5Jl/Vm0mDnlGIf8O3c4WBIAAAAAAAA --Apple-Mail-946513B1-5219-4962-A45A-3CC57DD2E98E-- From nobody Mon Apr 27 14:00:29 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348433A0982 for ; Mon, 27 Apr 2020 14:00:27 -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 ykFR6mAZj8DR for ; Mon, 27 Apr 2020 14:00:25 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A8A3A097F for ; Mon, 27 Apr 2020 14:00:24 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 27 Apr 2020 14:00:18 -0700 From: Jim Schaad To: 'Marco Tiloca' , References: In-Reply-To: Date: Mon, 27 Apr 2020 14:00:15 -0700 Message-ID: <014001d61cd6$db6bc320$92434960$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJN7A0KOJSAzHkjr6vk7aHQNyUKlaed1YHg Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] CoRE Working Group adoption call for draft-fossati-core-coap-problem-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: Mon, 27 Apr 2020 21:00:28 -0000 I support adoption and have already provided several sets of comments on = the document. Jim -----Original Message----- From: core On Behalf Of Marco Tiloca Sent: Monday, April 27, 2020 9:34 AM To: core@ietf.org WG (core@ietf.org) Subject: [core] CoRE Working Group adoption call for = draft-fossati-core-coap-problem-02 Dear CoRE WG, Considering the interest shown during the April virtual meeting, this = mail starts a call for adoption on: https://tools.ietf.org/html/draft-fossati-core-coap-problem-02 Please, reply to the mailing list with your comments, including but not = limited to whether or not you support adoption. This WG adoption call will end on Tuesday, 12th of May. Best, /Marco -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se From nobody Tue Apr 28 02:24:10 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FA33A1196 for ; Tue, 28 Apr 2020 02:24:07 -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 B_dTDw-EcVqi for ; Tue, 28 Apr 2020 02:24:06 -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-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027CD3A1195 for ; Tue, 28 Apr 2020 02:24:05 -0700 (PDT) Received: from mail-qt1-f173.google.com ([209.85.160.173]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1jTMTB-0008UA-3m; Tue, 28 Apr 2020 11:24:01 +0200 Received: by mail-qt1-f173.google.com with SMTP id k12so16734523qtm.4 for ; Tue, 28 Apr 2020 02:24:01 -0700 (PDT) X-Gm-Message-State: AGi0PuYsMZRxXjvMlEe7jCSE9GMIY7z2Gt6OOzG6RzibX8typFUgOO1d LWoMYXTFQxkktqPtyoXk4N+AKfmb33Ha0CusaKQ= X-Google-Smtp-Source: APiQypKPIUjWEt6tU57lTzWiui8VrgNfCiEwsp2yVbDOcWGSIjj80CIjWKKiWHhJju7YMfKXnpFu1b434L7Wz23fwhI= X-Received: by 2002:ac8:7b27:: with SMTP id l7mr27959165qtu.283.1588065840032; Tue, 28 Apr 2020 02:24:00 -0700 (PDT) MIME-Version: 1.0 References: <014001d61cd6$db6bc320$92434960$@augustcellars.com> In-Reply-To: <014001d61cd6$db6bc320$92434960$@augustcellars.com> From: Klaus Hartke Date: Tue, 28 Apr 2020 11:23:32 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Jim Schaad Cc: Marco Tiloca , "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1588065846; fda1e2cd; X-HE-SMSGID: 1jTMTB-0008UA-3m Archived-At: Subject: Re: [core] CoRE Working Group adoption call for draft-fossati-core-coap-problem-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: Tue, 28 Apr 2020 09:24:08 -0000 Jim Schaad wrote: > I support adoption and have already provided several sets of comments on the document. +1 Klaus From nobody Tue Apr 28 02:45:21 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4403A11CD; Tue, 28 Apr 2020 02:45:14 -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 MwP5Is1_xkmF; Tue, 28 Apr 2020 02:45:12 -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-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7CF3A11C8; Tue, 28 Apr 2020 02:45:11 -0700 (PDT) Received: from mail-qk1-f170.google.com ([209.85.222.170]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1jTMnc-00069i-Ro; Tue, 28 Apr 2020 11:45:08 +0200 Received: by mail-qk1-f170.google.com with SMTP id g74so21052790qke.13; Tue, 28 Apr 2020 02:45:08 -0700 (PDT) X-Gm-Message-State: AGi0PuaBdHmNkxKW9U/LoRUa6EX5uW9SqPaeleEQ61W6nxoHrMbagwgJ cilMT1QVJU58RX56J2WgKaAIy5GO7FjdDJYGwgQ= X-Google-Smtp-Source: APiQypLH1B+12XMRAD2LR76oVMOzRbhbuviq2BNf/LUdnicbRAqypQaCqs+JxDGwlKmoFfqclopJfQwUEtIMg7/Aha8= X-Received: by 2002:a05:620a:166d:: with SMTP id d13mr24619547qko.448.1588067107775; Tue, 28 Apr 2020 02:45:07 -0700 (PDT) MIME-Version: 1.0 References: <158758337327.19237.10369808433001369188@ietfa.amsl.com> In-Reply-To: <158758337327.19237.10369808433001369188@ietfa.amsl.com> From: Klaus Hartke Date: Tue, 28 Apr 2020 11:44:44 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Warren Kumari Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-stateless@ietf.org, "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1588067112; 6b9c256b; X-HE-SMSGID: 1jTMnc-00069i-Ro Archived-At: Subject: Re: [core] Warren Kumari's No Objection on draft-ietf-core-stateless-06: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 09:45:15 -0000 Warren Kumari wrote: > Thank you for this, it was a pleasant and easy read (especially as I am not a > COAP person). Thanks a lot for your review! > 1: I'd believe that the Abstract needs to say *how* "This document updates RFCs > 7252 and 8323." (A simple copy and paste from the start of Section 2 would > satisfy this) Done. > 2: This is not actionable, but I really really enjoyed the "look ma, no state!" > bit in Figure 2. ;-) Klaus From nobody Tue Apr 28 03:11:46 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6256F3A127D; Tue, 28 Apr 2020 03:11:44 -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 HwljBmBD8mki; Tue, 28 Apr 2020 03:11:42 -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-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0E153A127A; Tue, 28 Apr 2020 03:11:41 -0700 (PDT) Received: from mail-qt1-f172.google.com ([209.85.160.172]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1jTNDG-00008P-B0; Tue, 28 Apr 2020 12:11:38 +0200 Received: by mail-qt1-f172.google.com with SMTP id i68so16792475qtb.5; Tue, 28 Apr 2020 03:11:38 -0700 (PDT) X-Gm-Message-State: AGi0PuZfEsIGL9tpMr9Z/XTQaI0aqEmK69XUSIf9oZX+Pp5mXgLcaq1I lryBxRaWZzG7gKpz6dA478lqg6D6vLSxqDy6un0= X-Google-Smtp-Source: APiQypJprwQHXxzuvqTm5/KcAp4+UrdJS1wbLDYXgLVzmKrgIoChOo7ej0HfOVmd/nLLrnrcDoP1csXScjichm1s7LU= X-Received: by 2002:ac8:358c:: with SMTP id k12mr28463340qtb.38.1588068697134; Tue, 28 Apr 2020 03:11:37 -0700 (PDT) MIME-Version: 1.0 References: <158761884340.24804.11461411197672215884@ietfa.amsl.com> In-Reply-To: <158761884340.24804.11461411197672215884@ietfa.amsl.com> From: Klaus Hartke Date: Tue, 28 Apr 2020 12:11:14 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Erik Kline Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-stateless@ietf.org, "core@ietf.org WG" , Carsten Bormann Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1588068702; ea5def25; X-HE-SMSGID: 1jTNDG-00008P-B0 Archived-At: Subject: Re: [core] Erik Kline's Discuss on draft-ietf-core-stateless-06: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 10:11:45 -0000 Erik Kline wrote: > * I agree with Ben's point about MTU. Some text about the implications s= eems > warranted. Even just a link to 7252#4.6 might be fine (and maybe a > skull-and-crossbones emoji [=E2=98=A0=EF=B8=8F] if they can be included= now ;-) I've added the following paragraph: In CoAP over UDP, it is often beneficial to keep CoAP messages small enough to avoid IP fragmentation. The maximum practical token length may therefore also be influenced by the Path MTU. See Section 4.6 of RFC 7252 for details. > * 60 minutes for address changes? Out of curiosity, upon what was this b= ased? > I lack a good deal of context, but this kind of feels like the kind of > constant that will get baked into code and come to govern some behaviou= r > that later might need updating. This was based on the desire to specify something more specific than "must take address changes into account". I have to admit that I'm not exactly sure how to express this in the best way. The specific value of 60 minutes was suggested by Carsten. Maybe he can chime in? > * s/along the/along with the/? Yes. Fixed. Thank you very much! Klaus From nobody Tue Apr 28 05:49:59 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5C43A14A5 for ; Tue, 28 Apr 2020 05:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.919 X-Spam-Level: X-Spam-Status: No, score=-2.919 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.82, 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 C2pi5HSmup_c for ; Tue, 28 Apr 2020 05:49:55 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80081.outbound.protection.outlook.com [40.107.8.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F473A14A1 for ; Tue, 28 Apr 2020 05:49:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AEx9u8JUe/Z4FO8tckNowddHx2RssiYPhCfKnBtL+1D0qN0lLLZ1zjJ80AaPOBPLVy1aWmXhCqfZ4OP1QkCRkyq5mUJwIsU+MqqEBZ7iKpLu3FUJ8auarMDOdxFcjMnyIuWHjLU44VWvGiog1XjMnvNR0hQ9uaOUdoaXTgfyH+jgQy1mO3TkRpuHCbB9Z2+z+gbdFRAa746yuYiag554Z2/lgtVLvm/EG8g9yaHPFZUXWhT7pv1DuH9Kgb99K9bCgSjSQan6WSIFADiWPw/QMTHiMJj2ioihozBJ7ooQD9oJklbRtA9rjCAHW6ZCD9ZF5DXquuHLIS7omblshZ6IsQ== 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=i6qZVGeOGJ3ckD22TZjaJ7Sj+HrzIK4GCksuBxIeXBw=; b=PnlcAr7gS13i8lkOKFwbIf7CD1FkOJaumGsllR1myiYK1Fnr75R+XXWodFBmjjbCL4yvnL6EFdQ6oV+hAHM00Eb9V8ptMn9chIo2B9J/TiARo/6GZcdRcs78OQx/io0/Nmcl3E2sfL0RGPcCkCFUQUh+8Bqj+CHdx1polGmC9zTS+sa9nL8SgsvJqhJhK9vAqRuXADb3e1bq02akwBFlATZHaaRtnf4z26ijIYR5CH/W7bay3TVD8RYy4OekmCOt3U7HL5XGNtSuWGAVes+tPL8xGqWZrEEhkiL2ZezaoIO+bLWDST0C63WUaQ5f5Tj+miw2DATn8rthwpjUr/YjQw== 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=i6qZVGeOGJ3ckD22TZjaJ7Sj+HrzIK4GCksuBxIeXBw=; b=I9bk0uXJHU6gYopTQQjZjxm1vECZtAcwEie1TRAlKG+BSBa+y29vMz/b5JY7MwcLpj4J3tDqRkO4Y1/e+ZZaE26sjw8TAb4Z9YIfmh5u2xGydpZKyBqG3lUnC0bTB0rmJOhHRaM1UWVwLmAqZKVwe+XK1fWC/pPxh5D4Xupx6/0= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0430.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:36::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Tue, 28 Apr 2020 12:49:52 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::5db5:cc81:e984:7c27%7]) with mapi id 15.20.2937.023; Tue, 28 Apr 2020 12:49:51 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <9333f146-9542-81e1-3386-0eb52188ed44@ri.se> Date: Tue, 28 Apr 2020 14:49:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ccLNSBJyCV5CHban42jxUAt9J5UaLzy9s" X-ClientProxiedBy: AM6PR10CA0022.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:89::35) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.10] (2.58.46.228) by AM6PR10CA0022.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:89::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Tue, 28 Apr 2020 12:49:51 +0000 X-Originating-IP: [2.58.46.228] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 95882cbb-f9b1-4a11-5be3-08d7eb72a46d X-MS-TrafficTypeDiagnostic: VI1P189MB0430: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5516; X-Forefront-PRVS: 0387D64A71 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(376002)(346002)(396003)(366004)(66946007)(66556008)(66476007)(33964004)(316002)(16799955002)(52116002)(6916009)(8936002)(16576012)(26005)(81156014)(478600001)(966005)(8676002)(2906002)(6666004)(66574012)(36756003)(31696002)(6486002)(31686004)(2616005)(956004)(235185007)(5660300002)(16526019)(186003)(86362001)(44832011)(21480400003); DIR:OUT; SFP:1101; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: n5WBBuS4yOJMYNnre7DK+ef3woF/5FXJkYaT/h2c4ay8R5AH8vHLBSabvmv7D/BJkEPS5qwRJmDmdfz82ucxqyflUNHlRn3dkhq4mNyn5S+5ajxwjUa9vD3A4fZptTu8o/XqnyZbOfqt0A+UCvZMcVDpVeltjTblynJLME8F5fijcAIpEynhOO3xTXEEGltpIMxRvyy6KhAAehWFpOdM/NRCCNhZmEMKFmtYssNQC3iBUPTglFnAfarKvkqsPUNqodun6A2LqGAi7KchOhZ9d2tlNPESc1/NhUgju6cCEHER+Y8zDF0pziXL3mn3t15wefWeAi1zf+yoDCKh05pm74gVKkzvqaBdkaJI1dGvMHueoR+vCfommbvJVr54IbxQSuS4Hzc95cScf9ZNim9WF5h8ScrwtPYktAdPwcZMsVC8BS1iWiLjgZlsedm7Xo+a2DkHGybhRQHM1TSzArks/BpPQ54zybInxx0F8MPbKYRUbBXqLTfefTjPDu2ZGFm6b4zqrsT5d3JI7sxaohNPpw== X-MS-Exchange-AntiSpam-MessageData: 0/JSxX5k2qsf/dHnwDpT0fJmt8hXJNodYPgn5SEyEGH++Nz5hZ0weOK06gHcfTAwCD6kI1+ISaAbBigv4hLZNjuqSDaaETG98X3HI65g2LTA41jyjevSXCWLWDUFUb4R2kqV06RN8IuIqDO82SwVh4CLf6961Stp24rsj3ZQWcu8RgJ2/y0kAOH4nPbxyalvZWPSooR6UWe3/gV48Rt6178tZ8Bfdp+pD0MLX++p87s7YyNRQf7gsqKRnvyGL0jJaENxDx/lo4SFZT2WvWFIqwN8aU1UjoPIyUT6c1VnR2o0Ux45W5CtpB811h+L41xA6KlWShxuBN8bNWIZfkCHDx0OCpYMt8RA02V2y1DFfeMyBYSG+8lzFyjXOoYEg7kfkrTQDzgiBsAK5idVSCAwFEw6bY6NB9vH8RFWx0oDOHtOgA/QUbwq6Xn7pVnq+s1T/4PuopEmfjsCTTqvfQcxqxmEvbCACjud3flpxDBMcW37A0CGLt4JqhCH56ymkGH7GQUMqcg1BDGZ5S3iM+1BJ7ZmTlcM+Gq0Tiu9KC8rKA+v6bbqwSwF5HwxreW2BBE1AAsCs7dH84ay+jAOTSKZpk5N6KYH7PT4HUOgh5Wf083aS0V3X5pwgFM4LK8Mebf+v49WtuLtfBGKE+2+wH3G9e/ZHVQO9CZkcExQe4BKYLIVep2vYi/PwllrPLUUCfG+U4YsdApzdjZ4dLKt4L8G54IYPCiCDeGrzcIhF80sOqQAvULJo3d3Y13IWbcd63v5PibePPtVC5F8MBrIUxoJ5NhxM+9Ta2QDFgrtBq31N8Q= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 95882cbb-f9b1-4a11-5be3-08d7eb72a46d X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2020 12:49:51.5782 (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: U8JfirL55Ja45ima5EXwUlaqCh2JzfZc8QkWCaRQPXPutZ8V7/iUVIaY5gJqC4I+p1XtVHqMBB1mSbM76rXvlg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0430 Archived-At: Subject: [core] CoRE virtual interim 29-04-2020 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, 28 Apr 2020 12:49:59 -0000 --ccLNSBJyCV5CHban42jxUAt9J5UaLzy9s Content-Type: multipart/mixed; boundary="wO1dbpu2rqUEC3Qy41VQvjDpKfayA8ktv" --wO1dbpu2rqUEC3Qy41VQvjDpKfayA8ktv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a kind reminder that tomorrow (Wednesday) we will have our bi-weekly CoRE virtual interim, at 14:00 UTC. Please, find below the information to join. During the meeting, we'll cover the following topics: 1) SenML, both the -versions and -ct documents. 2) Usage of CDDL in specifications, thinking also of those using CoRAL. Best, Marco and Jaime =3D=3D=3D Meeting Information =3D=3D=3D Meeting entry: https://datatracker.ietf.org/meeting/interim-2020-core-03/session/core Webex link: https://ietf.webex.com/ietf/j.php?MTID=3Dmaf73502a66b35ef0f7478a46ea5bff7= 3 Meeting number: 616 038 576 Password: constrained Host key: 536630 More ways to join Join by video system Dial 616038576@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) 1-877-668-4493 Call-in toll free number (US/Canada) Access code: 616 038 576 --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --wO1dbpu2rqUEC3Qy41VQvjDpKfayA8ktv-- --ccLNSBJyCV5CHban42jxUAt9J5UaLzy9s Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl6oJm4ACgkQ7iZktA5Y 2kNNswf9G01XK2FtC2nOfCjXilbcCRF0XHUIbuK38wZ3In5DA4wOPiHl2WPW8lgK 4DhgWx/8UDy37CPpwG41g+W39sWdwCVHhUjGKKr4dPvRycpYCPeg4fr0RCd8aWl+ emLkTueZ3vXfrOsoNExfffPFGWh++EFHcreLuDmiIEq/zp1Bqk5IhKfl+Dlu0wuE r7CDqV08jZ7Eajv1FmBkhMDLayLQC9Idr7tqNTbpSSy4Zmoszu1DxjWsOW9e8u5N c2EKdIDZXqgHLpIAOqZRVI6nsgOgdfrhewZy9gOCEPDMWXJSfBo8Zidt47qF4q/g oXa3uMOgMFpn7LJOdbeu2wPSUDLHbQ== =7NhS -----END PGP SIGNATURE----- --ccLNSBJyCV5CHban42jxUAt9J5UaLzy9s-- From nobody Tue Apr 28 10:26:54 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B20B3A0AA0 for ; Tue, 28 Apr 2020 10:26: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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVo7_OZt811Y for ; Tue, 28 Apr 2020 10:26:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E67DB3A0A9E for ; Tue, 28 Apr 2020 10:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588094808; bh=Uz4J4DcwMgGZg4KNGiZhgl0yys4jMInweSMLHrhnSHU=; h=X-UI-Sender-Class:To:From:Subject:Date; b=HlFKVoeRGw2rBxkoxFId4CULUrUnpKdUaOxxXJJMlg7YO97KoWNDtG7RzjwrB7hUn 2KRiUpnUwDbo9Fd5iFDCKcQbvIMYeHQGIX2ndhqQQyjD22uaVKiuDi+t1O30bPT1aS WzRaS7/QHgfMr3LykW8+n0hXo/8METIAmdpX13us= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([94.216.230.90]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MQMyf-1jphgP27Pt-00MJBD for ; Tue, 28 Apr 2020 19:26:48 +0200 To: "core@ietf.org" From: Achim Kraus Message-ID: Date: Tue, 28 Apr 2020 19:26:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:yHfTXIL1FVdV96+WIiumHls74Ux5eXsVpdUUZk2uwzdTtbNZw8H 0PvXpdMo+9Eon53LIYz1xprD37zcebYS/7hLAgJurEoDvfG8ahY7EvGQdkDevEk1IL9fUOi ObgJ6KyKlnN1Uj5R2QJGjVKfrqmYS+/3TIwyBok/e0wtGe/j6shSxuDW+eBOvf9clf4NmRA Y/oy/+m1734/itzx7x2JA== X-UI-Out-Filterresults: notjunk:1;V03:K0:8HqQBZF8Fzo=:p9j54vSmechxHEvZZkFq2t 3NG28aY4Vj485eQsvbQcA7wxZ3jE/URU1u9MxYEJMJHmbiBqMH5VczT8ASkCQV7jLzgbhmQl6 ity9OGVwLfYmBji8A4GLp8Gbl8Wx6DHrv1NHlS1WPfpIRP5pzQ1lDQ+fzfRY2QsWNc5pssMXs iz8kDWWgoDZNwiVFlUBu8OAiqzWgEQHrVZIFHIBakopeq4vBTtY8pJ3+QXpfB1XojqEGK+azY OsO9SnhQMmotAFd1ewpeMNuQ5rpcoX2OsZf+pLqmW8l2UE2YELfQV0zsYYptUo+zDp54zvPuy lL8fzyxx596dw0KKUpUHvMFD9QYq3NlSMOnHgTkLGE5yU1MzX5wLGrQdOhlq/XcWB8O7Sx1Tz cPB+FS6Ax95HFGyq4zuERSm+BO2LWpoHk6sNHf8KNlhKPFBNcl1736sVVTylSG2oUZcLFpCrn YHtsmT09o7aPFbT/ReI5BBPjUQvlCKuBk1FP2KsUmPwR0NkK8u0gUIZTgSu7n6HSFzpjfH7xv hLSLKiYIHq44tga1s+S8OsfEa8G1r5xpvfOmEHElErWhZrqUqGwbRDQyZ2SZrGjATCyk1pNog btw8xU0hpjhNPlE4Vk3s2PMloeQDye5sVS4lg+Vxti+A6+4avs3f8fitghp3hJQ8lb82glPHn HhUTkHQxRQECbK8uhWHJjDLURbfSiziPr0mi36+NNnLIycZfkdT/knEs6vSi/0yVOvxTULgoJ GNPYG0O7G+wR5SCfQXLENjOo5cCaIZfbwTmy+UwBD2StZP0A3Mlsey4UZ5arZ+4yfqaSeSDc9 iqbATUUqVPnAV6GmyvOn2ueswNqE40KYXF7/zLDL5G8ioCzkHweTN8ZPq7Yfuq+FgwaOwOcHw PeatQrvYOItmfCONPQ9bkrLy/NoBuE6B8fdUuUGDVlDcMwDGEXmk595avYm7Vm6RClHe+/3EC 1uSpch7kFcwRZ4bu9ngUjzlkzFhJ5PzUQN2zjRjApDI5R/gukmr8B7YoBzCYWpOPz4+iIPsyi IcbCRISKupcXeiK444NN12M1gj0rxIDeJEPGlO9AhaZToxTonV6aynfJqc4AicTxShRWemJcY GaDVBxB19U1Bbv90rK/7iihRhRSSSxVJB00Fd4mRcxCFCcP+j2FqgJq7AH9ERGSotCxGgZOiB 9EI8rCUbA9OLJCo9Sp7vsE3HRCKcsGn5nWR8ZZtwzOAhsTVoFMPrFRstVvN9cMYem/5I3nNyb fOfeDSyjXpkVFPG2I Archived-At: Subject: [core] RFC7252 - 5.10.7. Location-Path and Location-Query 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, 28 Apr 2020 17:26:54 -0000 Hi List, RFC 7252 - 5.10.7. Location-Path and Location-Query defines: "A combination of these options is included in a 2.01 (Created) response." and "If a response with one or more Location-Path and/or Location-Query Options passes through a cache that interprets these options and the implied URI identifies one or more currently stored responses, those entries MUST be marked as not fresh." Does this imply, that the location MUST NOT be used with other response codes? Or COULD the location be used with other response codes? Does the instruction to mark the entries as not fresh in the cache apply then? best regards Achim Kraus From nobody Tue Apr 28 12:27:14 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F613A0AC7 for ; Tue, 28 Apr 2020 12:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=x6X6+mkf; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=x6X6+mkf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEohqstwfmBo for ; Tue, 28 Apr 2020 12:27:04 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80071.outbound.protection.outlook.com [40.107.8.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42AA3A0AAA for ; Tue, 28 Apr 2020 12:27:03 -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=O4w8NGtM6a+tEPQgpJpf8E7g5NUzwqXvvufewk6+89U=; b=x6X6+mkfLXtMS1jemJW6oLzsZG27rjgoYTaHcTpWs2+a6+WuJhOEQ17xoMiVh/vh+l5ofHlzQ94qx4kU6Ol/I64VE9oNJliTnJ/V8pXimIgFCGbGMTvjxuw+lkKWlq1ekIeAL3YsXHXCsAdGDosy3mwhKDiwtw65byYff9jUsdI= Received: from DB6P195CA0008.EURP195.PROD.OUTLOOK.COM (2603:10a6:4:cb::18) by VI1PR08MB3374.eurprd08.prod.outlook.com (2603:10a6:803:82::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Tue, 28 Apr 2020 19:27:00 +0000 Received: from DB5EUR03FT056.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:cb:cafe::c4) by DB6P195CA0008.outlook.office365.com (2603:10a6:4:cb::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Tue, 28 Apr 2020 19:27:00 +0000 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=bestguesspass 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 DB5EUR03FT056.mail.protection.outlook.com (10.152.21.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Tue, 28 Apr 2020 19:27:00 +0000 Received: ("Tessian outbound ff098c684b24:v54"); Tue, 28 Apr 2020 19:27:00 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: dc81ce861449ac90 X-CR-MTA-TID: 64aa7808 Received: from 45025fa3f490.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 930D66AC-B044-4D94-8EB8-7D2425B7DC66.1; Tue, 28 Apr 2020 19:26:55 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 45025fa3f490.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 28 Apr 2020 19:26:54 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kmsOcrLdQTC9L6rsAwRQYki8Cu6METa8IoaFszF0OAFm17ixDzM1gQhKfDcoQyU/E+nSTqfTKYn0j4/OAleeAhzuxVONOvTafUzZAEKswY/luxR2x2sm8ZbJuzx3mxGT4Vu8nNt/0IsLo8AFbgCUO5yQ0xENwpJgP3QXRhz3Mfjxlg2ywqqzQICI1KVg5AY9iWJsBXTycSg8Sx/cBl3ZTF75ueAx5d88g59PaIE3luzBKHOFZALUjN8nQeOwfztB9hjM+00hiNR93rAO0CXzv3UkD7r8dRj9nTPSd7dTjd/1D+OVmVf1X1vMBuuSu3cUtD6tPdhKE/g6rc8YbVwn+g== 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=O4w8NGtM6a+tEPQgpJpf8E7g5NUzwqXvvufewk6+89U=; b=Pri3dzHpYRcLjTgITOVQz8X1Z20RANL3me46Yu6ChR82yQfyE2ipKWN8OHGfcfNjLhpnxIDTYsPA1fSelcu10Osavd4CNeivAMlA96lOXKjTTwAU2qvIMgp6/KYOgP/21gaIPlbv77o3EV8zkNyiWI7cUeqHIWzT8dCEs76IKjFwTrH1Hes7Qx2u+TIEYI22pUJofF8QlDWjf0eeYNBrkg8+HREunQPL5E5qRS0Gp+Y9RAAooVRWsot9lKLgpg9bYEZxSv9O9yBKPu04cBwHD5kWSqiohq9kbq6yzqJ4gp/7qjkyzBZ7SEjkeoKbqzjTNJd8w6Cs3JeEyxtvHPzoZQ== 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=O4w8NGtM6a+tEPQgpJpf8E7g5NUzwqXvvufewk6+89U=; b=x6X6+mkfLXtMS1jemJW6oLzsZG27rjgoYTaHcTpWs2+a6+WuJhOEQ17xoMiVh/vh+l5ofHlzQ94qx4kU6Ol/I64VE9oNJliTnJ/V8pXimIgFCGbGMTvjxuw+lkKWlq1ekIeAL3YsXHXCsAdGDosy3mwhKDiwtw65byYff9jUsdI= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB4503.eurprd08.prod.outlook.com (2603:10a6:20b:72::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Tue, 28 Apr 2020 19:26:53 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d%6]) with mapi id 15.20.2937.023; Tue, 28 Apr 2020 19:26:53 +0000 From: Thomas Fossati To: Achim Kraus , "core@ietf.org" Thread-Topic: [core] RFC7252 - 5.10.7. Location-Path and Location-Query Thread-Index: AQHWHYI73fMC0YThK0ilvERHKTb586iO+68A Date: Tue, 28 Apr 2020 19:26:53 +0000 Message-ID: <01D7B079-85FD-41F1-A42C-3840961C4BF5@arm.com> 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.36.20041300 Authentication-Results-Original: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: a3b790db-07b5-477e-e7e1-08d7ebaa1fc9 x-ms-traffictypediagnostic: AM6PR08MB4503:|AM6PR08MB4503:|VI1PR08MB3374: 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-forefront-prvs: 0387D64A71 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(346002)(376002)(136003)(39860400002)(36756003)(316002)(26005)(76116006)(186003)(2906002)(66446008)(64756008)(110136005)(71200400001)(66476007)(66946007)(5660300002)(66556008)(86362001)(4326008)(6512007)(8936002)(91956017)(2616005)(6486002)(478600001)(8676002)(6506007)(33656002)(53546011); DIR:OUT; SFP:1101; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 6rubQxt0HbuM82Nph9mNlV2VRzS+9eGMX+5/QLpZD2wq19mj/g2z6O4QT9Ru1VajeYQSwV5PV1ooUbIIoYSecW5gPyRZX/idOE7tjkzzQqeYGXfdcy+r9VA0kVFtHKYSFTn95HHzRjpBP49mPFCJwXfF/Lftp1g5ezbsIS8KbOak20AoyGlFvyGlkrLWL2O1wxoz0pxIF/jVIMsiKiAdMZqi7kkOMMs0bUQbAlfBbY0t8PWe7PdlpR7gAwhFzPvNVAiAsr2Xz18Z71cJ0KNTQU9a93v17qHoYuJK+wQenRmUkd+z5tZr05aQnziIoh6+r0FXfKQestFtADGPmy/DHySb0Jv+FY3EhFt7NojIFEaL5K5SG/VvvJ81ZRizhhHlN6+iRAuHamTiwAuXycAyXvb8t0vN12pKxLab6PI+vPNZT1R1YD37V5R3ApnMzkHl x-ms-exchange-antispam-messagedata: uFk9JwIz1rNhjZq2xuMt7hfRAXjjbRX02BsgKFr4KyEFicBlMs5F3ihuHk1DQgQa4PWFnXjdEda4pUaASHlI7V/KRZiHdd/ONRkcgpoHz1qhVkcscj0Jiih31sEsys+mmYoZaEKlqw2fckYDw5ahCp2aCqEWgvrJgnzYLh55zB01MpgO1lNogMZ4hNg7mTrfH4hoPR8/iZiGqH+dcVfVYF435PUwm+E0rR5xbHTtY8R0mzD1VKRrCNUgJrp9raxk+TXHVqJQ+mAEuvhZ/94D8yZuNqFCR7/rW5BOnSw3DmemxSNF4J3m3lP/ZBmQ5pKb58emAJd+KHxRCbvKljIgtA8cMd2Zhvl/TFBmiBwwqr4GJLl8kHb5zLqH0EQ01TsicUAjKT5g+25sMYUh6+Abt1zXX8ZW+GkMZZGlYfHnZ82pJMqOU0Z2aBRLH8m3q/UP0x6QnP6+2O/BCOg6GWRRoCS0bgHSz7pacrxZEKGe6pxXQqcour+7nohXizbe4xdgyb86FqobnesvDj/H3O3PkdBznL5EB+MuREUycUwLYzxU5ZauvKpayO+iBBsVQUBdvZC0Jl1UPYYKZsXVgWRsS3p7c2HH8nsHQEw2yZE4ZiagywgwFlqCZNhoyBG9RRiH5gDU2W8InHeRhydhkYlKQ6F7GPlhgMKjtyplVpGrqyPI5tDKp/xFVZgn9sfNI9UAp/5US8xV9vDgUOffv40PLjVQBIreNRKM0Ke94+IljSmFQoALzlztiug75IK21GoWK3QoqzUglUO35xZwGjBkOQlvFs7jMK2jgxQfQBZSgO4= Content-Type: text/plain; charset="utf-8" Content-ID: <5066B35332B84E46AA160E2D7E295939@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4503 Original-Authentication-Results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT056.eop-EUR03.prod.protection.outlook.com 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; SFTY:; SFS:(4636009)(346002)(376002)(39860400002)(136003)(396003)(46966005)(5660300002)(8936002)(36756003)(478600001)(70586007)(8676002)(2616005)(86362001)(70206006)(2906002)(4326008)(110136005)(81166007)(6506007)(6486002)(26005)(316002)(82310400002)(6512007)(336012)(82740400003)(186003)(53546011)(33656002)(47076004)(356005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: dee7972d-212d-410b-7576-08d7ebaa1b53 X-Forefront-PRVS: 0387D64A71 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +5e11f0rhghbU3Co7nRvoibaA2lFtzaUKgYHBOvy0lWEIqwWRYibg1//ptYe3TUJmPnsRSIqRa/RK4WWUsW6SHbS4AloQmRv4KeR0I/W3Pn02o0fUGFVJAojcRRSI4pJXHz7ypdsDJuyin32gqysA6qNeXrspdVTbKWASf3yuwQ0MKX+AE/f5n5XGEaCFMTIpz0seA/c3ChLdEj5fRZbVW3peMP3MEFFFJ5rorbqh9YcmuHDJP2lwUFeK/iZyEc8d60R2LC1oUTrNO6hMFEAsx2laoyjgCy7RiMwYCUwKjQ3jk5/HQ/LhYLnv7qczGNjUWW6ozFG6PGlbY50uAnOZmD5UN2edwlXnXOx4Rqz6T1h8oIrH6CHK4qq+3PijI9Tg2/lNzaJ6vRb2QjFgO7hj6J/Gt6nfj99MNEIN5ARkjPl03KdybUVmeAhe4omBsMmrtJTh71o93Os1WdNtiNAjgDfc1LzdJOUIgGGq35tVlkdzpBBZGqrzRaXElCZAQ7n6CarhIEVY4fJK+jvDUpKUA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2020 19:27:00.6238 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a3b790db-07b5-477e-e7e1-08d7ebaa1fc9 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-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3374 Archived-At: Subject: Re: [core] RFC7252 - 5.10.7. Location-Path and Location-Query 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, 28 Apr 2020 19:27:13 -0000 SGkgQWNoaW0sDQoNCk9uIDI4LzA0LzIwMjAsIDE4OjI3LCAiQWNoaW0gS3JhdXMiIDxhY2hpbWty YXVzQGdteC5uZXQ+IHdyb3RlOg0KPiBSRkMgNzI1MiAtIDUuMTAuNy4gIExvY2F0aW9uLVBhdGgg YW5kIExvY2F0aW9uLVF1ZXJ5IGRlZmluZXM6DQo+DQo+ICJBIGNvbWJpbmF0aW9uIG9mIHRoZXNl IG9wdGlvbnMgaXMgaW5jbHVkZWQgaW4gYSAyLjAxIChDcmVhdGVkKQ0KPiByZXNwb25zZS4iDQo+ DQo+IGFuZA0KPg0KPiAiSWYgYSByZXNwb25zZSB3aXRoIG9uZSBvciBtb3JlIExvY2F0aW9uLVBh dGggYW5kL29yIExvY2F0aW9uLVF1ZXJ5DQo+IE9wdGlvbnMgcGFzc2VzIHRocm91Z2ggYSBjYWNo ZSB0aGF0IGludGVycHJldHMgdGhlc2Ugb3B0aW9ucyBhbmQgdGhlDQo+IGltcGxpZWQgVVJJIGlk ZW50aWZpZXMgb25lIG9yIG1vcmUgY3VycmVudGx5IHN0b3JlZCByZXNwb25zZXMsIHRob3NlDQo+ IGVudHJpZXMgTVVTVCBiZSBtYXJrZWQgYXMgbm90IGZyZXNoLiINCj4NCj4gRG9lcyB0aGlzIGlt cGx5LCB0aGF0IHRoZSBsb2NhdGlvbiBNVVNUIE5PVCBiZSB1c2VkIHdpdGggb3RoZXIgcmVzcG9u c2UNCj4gY29kZXM/DQoNClRvIG1lIGl0IG1lYW5zIHRoZSBzZW1hbnRpYyBvZiBsb2NhdGlvbi0q LCBpbmNsdWRpbmcgaXRzIGltcGFjdCBvbg0KY2FjaGVzLCBpcyBvbmx5IGRlZmluZWQgZm9yIDIu MDEuDQoNCj4gT3IgQ09VTEQgdGhlIGxvY2F0aW9uIGJlIHVzZWQgd2l0aCBvdGhlciByZXNwb25z ZSBjb2Rlcz8NCg0KU3VyZSwgYnV0IG9uZSB3b3VsZCBoYXZlIHRvIHNwZWNpZnkgc29tZXdoZXJl IHdoYXQgdGhhdCBtZWFucy4NCg0KPiBEb2VzIHRoZSBpbnN0cnVjdGlvbiB0byBtYXJrIHRoZSBl bnRyaWVzIGFzIG5vdCBmcmVzaCBpbiB0aGUgY2FjaGUNCj4gYXBwbHkgdGhlbj8NCg0KSXQgZGVw ZW5kcyBvbiB3aGF0IHNlbWFudGljIG9uZSBhdHRhY2hlcyB0byB0aGlzIG5ldyBjb21iaW5hdGlv biBvZg0KcmVxdWVzdCBtZXRob2QsIHJlc3BvbnNlIGNvZGUgYW5kIGxvY2F0aW9uLSogb3B0aW9u cy4gIEZvciBleGFtcGxlLA0Kc2hvdWxkIHdlIGRlZmluZSB0aGlzIGZvciByZWRpcmVjdGlvbnMg KHNpbWlsYXIgdG8gSFRUUCAzeHgpIEkgZG9uJ3QNCnRoaW5rIGl0IHdvdWxkIGJlIHRoZSBjYXNl Lg0KDQpjaGVlcnMhDQotLQ0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhp cyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNv IGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRo ZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBv ciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3Uu DQo= From nobody Tue Apr 28 12:53:25 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54393A0B39 for ; Tue, 28 Apr 2020 12:53:23 -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 Dv3iRc9zUsde for ; Tue, 28 Apr 2020 12:53:21 -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 377FA3A0B31 for ; Tue, 28 Apr 2020 12:53:21 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (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 49BXPq2LKMzyft; Tue, 28 Apr 2020 21:53:19 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <01D7B079-85FD-41F1-A42C-3840961C4BF5@arm.com> Date: Tue, 28 Apr 2020 21:53:19 +0200 Cc: Achim Kraus , "core@ietf.org" X-Mao-Original-Outgoing-Id: 609796398.903134-27a79057b48e87979489da22fb02c695 Content-Transfer-Encoding: quoted-printable Message-Id: <413E8478-5D7A-472B-8DF0-F07DF091D94D@tzi.org> References: <01D7B079-85FD-41F1-A42C-3840961C4BF5@arm.com> To: Thomas Fossati X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [core] RFC7252 - 5.10.7. Location-Path and Location-Query 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, 28 Apr 2020 19:53:24 -0000 > On 2020-04-28, at 21:26, Thomas Fossati = wrote: >=20 > Hi Achim, >=20 > On 28/04/2020, 18:27, "Achim Kraus" wrote: >> RFC 7252 - 5.10.7. Location-Path and Location-Query defines: >>=20 >> "A combination of these options is included in a 2.01 (Created) >> response." >>=20 >> and >>=20 >> "If a response with one or more Location-Path and/or Location-Query >> Options passes through a cache that interprets these options and the >> implied URI identifies one or more currently stored responses, those >> entries MUST be marked as not fresh." >>=20 >> Does this imply, that the location MUST NOT be used with other = response >> codes? >=20 > To me it means the semantic of location-*, including its impact on > caches, is only defined for 2.01. Agree. Specifically, 2.01 means that the location pointed to is new, so = that is what makes the cache invalidation useful; other uses might point = to other kinds of locations. >> Or COULD the location be used with other response codes? >=20 > Sure, but one would have to specify somewhere what that means. Yes. >> Does the instruction to mark the entries as not fresh in the cache >> apply then? >=20 > It depends on what semantic one attaches to this new combination of > request method, response code and location-* options. For example, > should we define this for redirections (similar to HTTP 3xx) I don't > think it would be the case. I hope that particular example never happens, but I agree with the = principle. Gr=C3=BC=C3=9Fe, Carsten PS.: > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential=20 I don't think so. From nobody Wed Apr 29 04:11:45 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB373A0C8B; Wed, 29 Apr 2020 04:11: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 MpU4DWUVA0FF; Wed, 29 Apr 2020 04:11:32 -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-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A183A0C88; Wed, 29 Apr 2020 04:11:31 -0700 (PDT) Received: from mail-qt1-f175.google.com ([209.85.160.175]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1jTkch-0001Xj-FW; Wed, 29 Apr 2020 13:11:27 +0200 Received: by mail-qt1-f175.google.com with SMTP id t20so1394243qtq.13; Wed, 29 Apr 2020 04:11:27 -0700 (PDT) X-Gm-Message-State: AGi0PuZj6nojj0mCDbhIRWSPcOH8eErnMVUaZFxOjpwReZv4qLTGAORJ jYO00d20rF81/AO4pAzB4tCKDALC+vlRpaxeSZ8= X-Google-Smtp-Source: APiQypLQ+5IQvJ6qlQHa73XyZIIqNl0LdUz/lGQvF0qI3VB3HDOjb2HGAFTVUNe0sN/fX6CNXl5j9SSA9jjjRpnIOlU= X-Received: by 2002:ac8:358c:: with SMTP id k12mr34309844qtb.38.1588158686104; Wed, 29 Apr 2020 04:11:26 -0700 (PDT) MIME-Version: 1.0 References: <158741679923.20291.1071401061463555301@ietfa.amsl.com> In-Reply-To: <158741679923.20291.1071401061463555301@ietfa.amsl.com> From: Klaus Hartke Date: Wed, 29 Apr 2020 13:11:04 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Benjamin Kaduk Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-stateless@ietf.org, "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1588158692; 32b131e4; X-HE-SMSGID: 1jTkch-0001Xj-FW Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-stateless-06: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 11:11:35 -0000 Hi Ben, here's the next batch. Please see inline below. Best regards, Klaus Benjamin Kaduk wrote: > Section 3.1 > > o A client SHOULD integrity protect the state information serialized > in a token, unless processing a response does not modify state or > cause any other significant side effects. > > If the intent is that the "does not modify state" clause is the only case > when one would disregard the need for integrity protection, "MUST [...] > unless" seems more appropriate. (I would prefer unconditional MUST and am > not sure I understand the cases where there is a need to skip integrity > protection.) The intent here is that a client must do integrity protection, but there may exist valid reasons in particular circumstances to ignore this requirement. In this case, the full implications must be understood and carefully weighed. All of the circumstances that come to my mind here are those where a modified token doesn't actually hurt. For example, if a client sends a request to some server at regular intervals, it might only be interested in whether the response has an error or success code and not even deserialise the token. What's the best way to capture this? > o Even when the serialized state is integrity protected, an attacker > may still replay a response, making the client believe it sent the > same request twice. For this reason, the client SHOULD implement > > (Basically the same comments about "SHOULD".) See above. This section is about protecting the serialized state, but of course the requests and responses need to be protected as a whole as well (e.g., using DTLS or OSCORE). In some circumstances, receiving a replayed token might not hurt if the client can verify that the response is coming from the right server. > cause other any significant side effects. For replay protection, > integrity protection is REQUIRED. > > I'm not entirely sure if the normative keyword is needed for effect, here; > it's simply a fact that replay protection is impossible in the absence of > integrity protection, isn't it? Right. The intention here was to turn the "SHOULD integrity protect the state information" from above into a "MUST". But I can lowercase the "REQUIRED" or remove the sentence. > o If processing a response without keeping request state is > sensitive to the time elapsed since sending the request, then the > serialized state SHOULD include freshness information (e.g., a > timestamp). > > Continuing the theme, this seems like a conditional MUST (not SHOULD). > Actually, all the rest of the SHOULDs in this section do. See above. > This particular one should also note that the response processing needs to > actually check the timestamp and reject ones that are insufficiently fresh. I've made the following change (ignoring the SHOULD/MUST discussion): OLD: If processing a response without keeping request state is sensitive to the time elapsed since sending the request, then the serialized state SHOULD include freshness information (e.g., a timestamp). NEW: If processing a response without keeping request state is sensitive to the time elapsed since sending the request, then the client SHOULD include freshness information (e.g., a timestamp) in the serialized state and reject any response where the freshness information is insufficiently fresh. > Also, integrity protection is again required for this to work. Right. I think I'll remove the sentence "For replay protection, integrity protection is REQUIRED." from above so that I don't have to repeat it for every item. I think it's quite obvious. > Section 5.2 > > The use of encryption, integrity protection, and replay protection of > serialized state is recommended, unless a careful analysis of any > potential attacks to security and privacy is performed. [...] > > I suggest an alternative wording: > > % It is generally expected that the use of encryption, integrity protection, > % and replay protection for serialized state is appropriate. However, a > % careful analysis of any potential attacks to the security and privacy > % properties of the system might reveal that there are cases where such > % cryptographic protections do not add value in a specific case. Sounds good. Thanks! From nobody Thu Apr 30 05:12:58 2020 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E873A0404 for ; Thu, 30 Apr 2020 05:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.82, 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 6TYRmAWQZW4E for ; Thu, 30 Apr 2020 05:12:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B9083A03FE for ; Thu, 30 Apr 2020 05:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588248761; bh=U8qsuDzwgbwyUaf8uUqSpVJmhMKXad2mfA5ebYZ2C7E=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=GuZ3AWxCQLkf4kguTjoZGViv8Ap4T7Qz/JCv/qmo2PaAdcVDkV7JfTiwcWbqO4zBA j8m45bZPyYftSXZY4BKuATMDP+iION4mDmrV6IdXGu3JA7OTFd43JOIvVBZy3UVBE9 e3wm8O3C2wV2mkAl3zKChlR0LMKPMHx+i1JVjWwo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([178.10.31.29]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M9Wyy-1jZeMW3Kiq-005Znb; Thu, 30 Apr 2020 14:12:40 +0200 To: Carsten Bormann , Thomas Fossati Cc: "core@ietf.org" References: <01D7B079-85FD-41F1-A42C-3840961C4BF5@arm.com> <413E8478-5D7A-472B-8DF0-F07DF091D94D@tzi.org> From: Achim Kraus Message-ID: Date: Thu, 30 Apr 2020 14:12:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <413E8478-5D7A-472B-8DF0-F07DF091D94D@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:YnlkOmMXR5hIgYNq7pK7AskUCWn5GXAO0nDCvJwn6NwJ3fPYgv5 nuIyUgl9qCrqkD/FANXHD+XmBbYxMuOvSOjEBGuGgJRg1+C74gMvqf12/Ml09FmQm+J2Ktn Ighek6+r6dNMq3ITIqBI0npj7PExZ5skUmiPK1GXklJX+RKIQr4+0dwdsWPtSYMSKtDTT3I VFr8aF9bA5Bqoj2bgKZUg== X-UI-Out-Filterresults: notjunk:1;V03:K0:gndoTwsnGH0=:IQd2BdVm0Ls3ZdAc3/qQvZ fsB8F/QAL5wib/V/RqzlOJWhm0AWcN+wl0lOsRposRok4BAlZE59gmuGELAJheZv3C1Iw1NWy NygabQYKJG4WmYCeIbNuIhgX2grC3tHRcK8RenMu894f+p0WKNZ4RVMPOV3kAs0sPHnGPc9yG tVufz1CDt3wagPW4CcQ0oQfUytiuYN5XPQJ9+4/eVfaC82TkswiNEwa9xnvJdmQ1dR08ucLS8 hwgClL06ZbZeFYnMnSkquXNzF3UAkfMnQJASGNRLs3+t3O2wmNok1XHaOWXcpNF8vo3gOdvXU TkdFK1X7gYKsBRh0jD0LFumy+rX9Z1ry+JsYtezP1aMUhmaEuCQJHc4Kj7Zu59QVLa3cMqOrR cgDxX07Zymz8z04HKp/ok8Cc/HVyXTmQrgkEe+5UwqG52y/ktAdhK/VUDLKSQ+8B/uA0WADdk ZUrgla36IkP+faY80fpj3Tz83DlddYpbvaJlxjfzfGC2dP616Bpb8ntC6bmUGVAFVrlHlCcef inyykiWBUKsG6qJRXMDmjMo3t3btdg6np98m/UlPx6R7EHt2hMsBnGQbAePuMxSW6lskDr9rM KZap7ujuCuVC9ye1oONwuwoUKadS/nmDH8ol9KsuWxjQo/kAiReJLb+Q94H4NU4suqUQanedB 05F+BLc6Rjaht3nD4uON1Ke3LoTLL4AOTftZA592rQowfqIdIqyjCOFmMGLAg2bQVcyDyoJC/ LcPnr/VIismFfcP9oWo5Ire643OdpE40zlRAIm79MW+Z6H+55GAU5XM9YejrMUQSisAYW0O/R 8xdI8+2+vfXvDzG+oou5TfP/vaOULiKMPgjcyGqSs4xsPaDJnTGes5uyuJTUFLTyHtRBHrKEf xzVPNOg60KpFc87kt4aFz3WOJngj+7dg+uo923ROw7vLIlf7yZzHGGb8UGASkFFXWBDpZP+c3 RGM6IN4omMW8OgSyDZ73yTxUG6JAU2icvlGfRckJ7A7tIdLBIg3Rx8UXHz+uKBYcBOQjQDnfo JIkTVvt7emUwZ9l+/h3jDAdgn7E/Vg98nHCn3ILEHihFCNbjqaW2cCcZmlYFTVhedYNY27h99 6OS3R2J9gEnlDDEs4znF2j50GS8cwfjvVbyqC93Lkx3tBUtXQPAc1m81S29aK5sU+ctPzEMAY TquBl8bnXpSgxurKP01ls8mHoe2IxIFxVqolOgU+y1A4UYW040RjvFv2QfcVv9+F3X74SrGbL HrM520gbFRl+8NM9s Archived-At: Subject: Re: [core] RFC7252 - 5.10.7. Location-Path and Location-Query 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, 30 Apr 2020 12:12:57 -0000 Hi Thomas, Hi Carsten, thanks for your answers! best regards Achim Am 28.04.20 um 21:53 schrieb Carsten Bormann: > >> On 2020-04-28, at 21:26, Thomas Fossati wrote: >> >> Hi Achim, >> >> On 28/04/2020, 18:27, "Achim Kraus" wrote: >>> RFC 7252 - 5.10.7. Location-Path and Location-Query defines: >>> >>> "A combination of these options is included in a 2.01 (Created) >>> response." >>> >>> and >>> >>> "If a response with one or more Location-Path and/or Location-Query >>> Options passes through a cache that interprets these options and the >>> implied URI identifies one or more currently stored responses, those >>> entries MUST be marked as not fresh." >>> >>> Does this imply, that the location MUST NOT be used with other respons= e >>> codes? >> >> To me it means the semantic of location-*, including its impact on >> caches, is only defined for 2.01. > > Agree. Specifically, 2.01 means that the location pointed to is new, so= that is what makes the cache invalidation useful; other uses might point = to other kinds of locations. > >>> Or COULD the location be used with other response codes? >> >> Sure, but one would have to specify somewhere what that means. > > Yes. > >>> Does the instruction to mark the entries as not fresh in the cache >>> apply then? >> >> It depends on what semantic one attaches to this new combination of >> request method, response code and location-* options. For example, >> should we define this for redirections (similar to HTTP 3xx) I don't >> think it would be the case. > > I hope that particular example never happens, but I agree with the princ= iple. > > Gr=C3=BC=C3=9Fe, Carsten > > PS.: > >> IMPORTANT NOTICE: The contents of this email and any attachments are co= nfidential > > I don't think so. > >