From nobody Wed Dec 1 07:59:54 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690D63A08CB for ; Wed, 1 Dec 2021 07:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIU9TfL5Podr for ; Wed, 1 Dec 2021 07:59:45 -0800 (PST) Received: from wforward1-smtp.messagingengine.com (wforward1-smtp.messagingengine.com [64.147.123.30]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3F633A08B4 for ; Wed, 1 Dec 2021 07:59:44 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailforward.west.internal (Postfix) with ESMTP id DBCC91AC0201 for ; Wed, 1 Dec 2021 10:59:42 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute6.internal (MEProxy); Wed, 01 Dec 2021 10:59:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=kq7lGFVMqtJKRGdTP14wLV6f+EVdt8ubZbfaQ/n82 Ho=; b=gAXj6enXQ9bA1DIOlQM7wXVHp24XubpvgLg8oDTZoCWqw2uRmS3otPsy1 c7BwH6c2PkDtC2bTkdiOcLzB6herDS8WU0eBFp9Fdb0YeJaYCujHWCtArn2lzy3o 7Xe/jisydmzm5XMEu9lif3113Lyndf8Uku+g1ameweUkl3N4Zg7+w9kdQYhFs9II xyOsZ/ZhAQAYNiVFmEA88PdJagyM8Qqn8CqfqFqNwb3b6sSDTceNg8dD920fdytr l8KMszcM2ckAuRMuMPcybyVc1mx03CyzD99ilMZtYJD2FZVnpdAC5hq7KWdVNN+N VtWKZiOG2JblpX19hCTlV2+m5c40w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrieefgdekvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpeflrghimhgvpgflihhmrohnvgiiuceojhgrihhmvgesihhk ihdrfhhiqeenucggtffrrghtthgvrhhnpeejffehfefgfeduieekjeetieefgeefkeefhf elhfeigfeuuedttdevteehjeetueenucffohhmrghinhepihgvthhfrdhorhhgpdhgihht hhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehjrghimhgvsehikhhirdhfih X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9A01324A0074; Wed, 1 Dec 2021 10:59:41 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4458-g51a91c06b2-fm-20211130.004-g51a91c06 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 01 Dec 2021 17:59:21 +0200 From: =?UTF-8?Q?Jaime_Jim=C3=A9nez?= To: core@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-os?= =?utf-8?q?core-groupcomm?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 15:59:50 -0000 Dear all, the deadline for this WGLC is today. Given that we have not received eno= ugh reviews and that the Christmas period is arriving soon, we will have= to extend the deadline for this.=20 Marco and I propose 6 more weeks of extension until 2022-01-11 Tuesday, = to give more ample time for thorough reviews. Ciao! --=20 Jaime Jim=C3=A9nez On Tue, Nov 9, 2021, at 8:59 PM, Jaime Jim=C3=A9nez wrote: > Dear CoRE, > > as we discussed yesterday, the authors of=20 > draft-ietf-core-oscore-groupcomm think their draft is ready for a 2nd=20 > WGLC. The current version of the draft (v13) is not expecting any=20 > updates so you can start your planned reviews. > > https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm= -13 > > In addition to the email list discussion reviewers could consider=20 > opening new issues on the Github repo of the draft as courtesy to the=20 > authors. > > https://github.com/core-wg/oscore-groupcomm > > As we have the IETF ongoing and the document needs time to be digested= ,=20 > we place the end of the call on the 1st of December with a possibility=20 > of extension depending on the number of reviews. > >>From the minutes I take that CA, RH, ED and TF would give it thorough = look. Thank you already for that, much appreciated!! > > Ciao! > --=20 > Jaime Jim=C3=A9nez > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Dec 1 10:06:46 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782063A0867 for ; Wed, 1 Dec 2021 10:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKhr0MS98tLK for ; Wed, 1 Dec 2021 10:06:39 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60117.outbound.protection.outlook.com [40.107.6.117]) (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 330473A081B for ; Wed, 1 Dec 2021 10:06:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RS1xPerE5sv5/MzK/ut29hf2kaxzXxq6hBifumAuIu4+eVjAwtbvDuTMt+GcPanLQPRA/Ez3SWSC5HVQWAV+ZlYwRz5mg2gEZiDm+x2xMg9OfqS5SYLUQhgpcVEzN06CDdQaMWp/IvCtQGxm0m07wSPNGW9tnxFyVlYvi7Q9rOwKy3k6RbhZhtdu+1fFh+c251dF1+u6O69Uy2k3Y1vhvywnhR8E0EwX1vhHQdHgkQmKwB4xbYFJQqOJqb5Q7EIBqpAC/2aO/M+qv7FjdOrxFOKQ4rrtawSiDV+RS30ZfECuCqCv+0WxGGR6+hM3jjaBkDna1s/cypvv/VwzlP+5Ug== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Y6SeJukfs1drRqrVY4i1l1O13IkyFtJGEtyjRh1c6s4=; b=CqLR33Tl6an9Qn7FHY61QBfHi6YwUP2ARdgWmKnEhiVcpDtg4iL2ycZ38gZ75KTdDKMxrf1oeuwDnoTUqL6g5UN0Vt/xZt1gqFlYf0s554jdmtPwIexAbk5A0VOf1Z2ZDC3QZr6Bihx0LO8UoMIc7O+9k2OeQQP+S/TQt21NLaMbu6xobnTiT6Se3eNm9PZ39Qfgel6BAjmnz3339XDHMQ8JfYWg17N3jXAtvoRbZiTgeXsw5Q1Xn7Y0kzZJjgjhMVxDOHwA04oq6Ku1fl+AKxLEEuz9vJeHVL9uoszSZ6JdUvKjIfoJbDrZhyDs4kbsnklvjFMySNmCs6pT9B4wOA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y6SeJukfs1drRqrVY4i1l1O13IkyFtJGEtyjRh1c6s4=; b=kz/sV4jf4tz3OuiAIzKqlWH1NCuWbK8hM6RQs+Iz7ukwN2uFS9vEnJZGFa/StWtlIvizj6eXXPEcXoV4vNOTdRm3hH3v2RTmR+jf/YyJsZRocf7JbgvWUuN0OYYuhvWb+R4xUEYLQq63MbTgCNvDoVklroAPyJ9cIsVwrVqaCNY= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM4P190MB0067.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:61::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.23; Wed, 1 Dec 2021 18:06:35 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::c41d:c9d6:d8c7:65c8]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::c41d:c9d6:d8c7:65c8%8]) with mapi id 15.20.4734.024; Wed, 1 Dec 2021 18:06:35 +0000 From: Esko Dijk To: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core@ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHIExhc3QgQ2FsbCBvZiBkcmFmdC1pZXRmLWNvcmUt?= =?utf-8?Q?oscore-groupcomm?= Thread-Index: AQHX5syENDEgPmpTY0OwNAm2NOr/Dawd7hJw Date: Wed, 1 Dec 2021 18:06:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=iotconsultancy.nl; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4423b808-c707-4129-46ea-08d9b4f5504d x-ms-traffictypediagnostic: AM4P190MB0067: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sfuW5pclunmEc7pmm5mCgoXXyvNZ3FsjCiiaJQ9tC9SBj2gPIO4GWhsGRF6KHZObvy2WwMBJKFjh7zFrDuq+bZVcRne9+PTLgCRdLriQGGw/u7XlHnthtkxQUERMAM4yCWfmeN5OIj36MiaBcuSLrKEjX4qAONPzVu0AExokajpVQrYy4l0xC6PVXrbtI0m2DSVPyZKVnyCD2yu4r7GzTyZDxe3ttxSf1lDiFiGFf2G2mxLPWRixaBWs4om6F/VP+sSVOqolwyN7HFdGftHk1S80sKvKVB2o6a4+pY7bm7wZYLkIkKS7x6r4lRF9KmiXjirzVXEi+XKHa3I5/vOti8a5dDa2NNq90Ntufa30IQwkLB/8rBzaMrIhmYK3B62EoGASvwqAd4o9VdxvClfrcjx7X9jNA3yaB4xC8dJMo+KJsVze63yle7CCaKgkX/bagzi6zum3hSXCaF8++Jdcc0LjyRWKiEy5MiNC8PiCNY64glhSAA4V1GYgPc14f/ksT8S35qicfuYlQTKgHjr/zfNADXAzBQRve54htRCHrlD885HFNlQoBwarxJazstk/qxud5UUBfz5n3kCZpX2fzLLAK8lg08Kgum8PUwU1LzI7pH9IA0nekTGMHYhRK9Jy3LEb2ApPSJ65Ed2mQ7wj+JPrhp7DwS0N2jH5xvOi38OPV1gdRIHPZAjF/OLOKzLQHXqElzyHAKR6gFNT69SDeAZK7UkClhLiRgfjhn+y9k6mx08m+hdRP3bayshT1K/EYoLiCqxA0vlmnXscJvY1lWKKgaUD+1RmI/gRcJTY1o8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(376002)(39830400003)(136003)(366004)(396003)(316002)(83380400001)(7696005)(2906002)(110136005)(508600001)(122000001)(38100700002)(966005)(64756008)(76116006)(6506007)(38070700005)(52536014)(8936002)(33656002)(86362001)(26005)(66476007)(66946007)(55016003)(53546011)(5660300002)(186003)(9686003)(66556008)(44832011)(66446008)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dktueDRQQVVXOFVKTDBTZlllRnM2TkRKRVlBWHBwNVFpeGl2OHRKUE5GUWRx?= =?utf-8?B?aW1MNUR2MUR6cE5nSkNMenB2UjhxeHV5MThnZzFPSm9qR2owMEcwZzdneHFi?= =?utf-8?B?S3RWaFh3K1ZjUHBDbnFzSmk4T0owRTcvOERuL3ZtUUI0WHNyZkxaakY1Nkl3?= =?utf-8?B?bFd4NG5HWVBFNXVYVjYxUXRmTkE4N1BzNk9jL0pmNGVhSFhDbStxSzlaUk1r?= =?utf-8?B?d0syc2liRXpGblhJQ2ZuT29tUThiYW1pQXNOY00wTU82TzBIZHpxemNXZHk0?= =?utf-8?B?U0Vxc2t4eGFsTll0N1ZzWTJUR2svUDFTMmVUUXU1YUlnRWFrN3dRR1gyRnFF?= =?utf-8?B?aUhES254dE51NGI3L25RbVFZcng5YThHZDRJcUhNbks4clQ1ZkhLWW9NNDhU?= =?utf-8?B?WXE0ck9HaDdaVlBsbmkvS1BQZDRKdlNnbnl2YlFkMlQvNFJNd3luZ08rL0V4?= =?utf-8?B?ODk2TFB0SzVqeWQvNFFMVmw5ejU3RStMYVUyL01VOG4vVS9PM1NEWjFWNmdJ?= =?utf-8?B?NGg4M1ZCK1pIWFUrWjlOUDJKOGZ5ZFRJWmZHQ3R3c3hmL3RwZTFSWHVzUGVY?= =?utf-8?B?K2RTYmJqK3I4SVpsQjFsdC84Z2lreXE5SXR1U3l0bFJ5cUpjRlB6c3AwZWFx?= =?utf-8?B?aEw4Q3JmNitWRFNBU05zZFk5cGdOOFdITFFBRE1NMFpDN2dnTGh1QWRaU2Nt?= =?utf-8?B?clRHYlM4QmM4WlI3V1VFd1NYc3ROZTZDRVVGNHp6N2ZoQ2RRRyt4NDc3VlRR?= =?utf-8?B?ZkZrWWlqY29SZFZHbzNHSXphSHFnUWVSMzkzSjJocHpOWHJSblFQbFJMbVp2?= =?utf-8?B?VnYxOE5CNHNoZHRBWVpKejdSUDdOckttQ3lidHZwWG1yWGREVlJYeHgxWnNR?= =?utf-8?B?SXlsWHpUZGxJS3JvdEhMbWhsRmQxQzZsYzROOEN3RWtTdGhwQXoyUTVSRXp3?= =?utf-8?B?UCtDdlY5YmZKL0gzQnVCWTlZZjZpeHN3djlySkFSYXYrbm5UTWZ2ZGc5R1RL?= =?utf-8?B?bHFtYmNNVk9IRmhQbDJzck9CSzYwdUd3dkJkNGUwbHZFR3UyWHoxNzN5dmh0?= =?utf-8?B?WUlRcXc3dlVuQmNaaXBkd0lxMk5QYjUvTGRuSk1COFBobnpnb3J1dVMzb2pp?= =?utf-8?B?c1l1ZHZyWUZla2d2N3NPVFB6NGYvTlpBbUlJdC9ZMUgzWU5Ca29nUkcwMjcv?= =?utf-8?B?aVdKSTJTbmZwN21SZ2tRQWdpSkFzbHpqd0JKNDJzUHRIQTR1RGVDNWh5K3dh?= =?utf-8?B?aWFCNHBxYXd6QWpFRStxZi9lOCswWjhQb1ZEOFBGeGNWeFhsZGF3N2lVRFJl?= =?utf-8?B?S3A4RFl6dmhKTnBjcERrUnh1b2NXNHVwL1ltTGtnRE9PZUU2NnBuTHJUVkxr?= =?utf-8?B?TGxqZHpsRmh4cmVvSGxnOHlzYmtYUStNYzRjSlYxazJzVXRKaURlZ2V2SFI1?= =?utf-8?B?TEk0RElpZDJTcWFtdTFWSFU1SEF3c3RBT1lkUExkMTdxMHcwWDdBVmlibVVx?= =?utf-8?B?VE1mazYwV2sxMVlwQm1mN3JSdHAwNm0rK3duejhXdG1SQnlJaXJmYVJ1MkdF?= =?utf-8?B?Yzd5Yk5rVEFubnBKWHRteUU1a2hJYjh1djg4VTVPYVRuTUJONnVUV1NURTNK?= =?utf-8?B?TU9od2JzcS93b0t2RUVIcVhiajJhMzZ0MEFhVmpQZUVER1pqOGR3dkFkbGw0?= =?utf-8?B?Z0JKR3VQQTlKRVUrNG1rRlM4VnpoelRrNFNNUThTMmd5RnJ0cUwxZVZISnFu?= =?utf-8?B?MVNhNnlWbHVuRlNPY24yVy8vSWhOUHp6L3NNVjVOaDdaTG9ER3B1c0R1SDZi?= =?utf-8?B?U1AydGppWUY2MGZ2ckF0cHNxYnprU3lhVFBMdTMxUXVYUjdBbEZNVGVOMytS?= =?utf-8?B?cEpzWkkzY1Eza3BveTlvaXI5L21haytyUU44Nk1BUVZnaDZ6MDhpbVJFeFov?= =?utf-8?B?NHdrUDRJTDNSR2FZamtxYWo3c3M2cm5NN211YnVFWk1QbnhuS0ZENDlmb1ND?= =?utf-8?B?dzA4T1BPUStXMlNseXFMdVAxWWtJVUE4NUJNbkxjWHBwQ1c1S010NGRiK3NT?= =?utf-8?B?SnVkL1ZydFViWVNLV29xOWVDN0paNVRLWENTa09jbm1NTVRVd1RRU0Z4aHlG?= =?utf-8?B?Q2ZEVHBzTUNHMzhLdE1Sb3JJNldWQ2NQV2VVMm9LZDVVdXZXdU1tZXNLYlZm?= =?utf-8?B?ZHhnRjNUTzBWZjJ1V1A3ZHFzaDNnZG5Gd3N3SG9vM0JIaE14clJXWWVLbTJZ?= =?utf-8?B?aitrQk4vTXpXejNyK0VZTmxGcEVnPT0=?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 4423b808-c707-4129-46ea-08d9b4f5504d X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2021 18:06:35.5679 (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: o+Bz6tDZKbSWT0NYjKfKyZjV4K2831Z/sMhIb3Qrx/EgrjScO5zMaGolm8EUkGMk11yUPCWK2Xh51IGb5mCjPLw00ZNDUM+MeXDSY2/F9IE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0067 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-os?= =?utf-8?q?core-groupcomm?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 18:06:45 -0000 SGkgSmFpbWUsDQoNCk15IHJldmlldyB3YXMgaW4gcHJvZ3Jlc3MgYnV0IEkgZGlkbid0IHJlYWxp emUgdGhpcyBkZWFkbGluZSBkYXRlLiBXaGV0aGVyIHNpeCBtb3JlIHdlZWtzIGlzIGFtcGxlIHdl IHN0aWxsIGhhdmUgdG8gc2VlIGFzIGl0IGlzIDk4IHBhZ2VzLCBzb21lIG9mIHdoaWNoIGRlbnNl bHkgcGFja2VkIHdpdGggY3J5cHRvLXNwZWFrICA7LSkNCkkgY2FuIHNlbmQgYSBmaXJzdCBlbWFp bCB3aGVuIEkgJ20gaGFsZndheSB0aHJvdWdoLg0KDQpyZWdhcmRzDQpFc2tvDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjb3JlIDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IE9u IEJlaGFsZiBPZiBKYWltZSBKaW3DqW5leg0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxLCAy MDIxIDE2OjU5DQpUbzogY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSDwn5SUIFdH IExhc3QgQ2FsbCBvZiBkcmFmdC1pZXRmLWNvcmUtb3Njb3JlLWdyb3VwY29tbQ0KDQpEZWFyIGFs bCwNCg0KdGhlIGRlYWRsaW5lIGZvciB0aGlzIFdHTEMgaXMgdG9kYXkuIEdpdmVuIHRoYXQgd2Ug aGF2ZSBub3QgcmVjZWl2ZWQgZW5vdWdoIHJldmlld3MgYW5kIHRoYXQgdGhlIENocmlzdG1hcyBw ZXJpb2QgaXMgYXJyaXZpbmcgc29vbiwgd2Ugd2lsbCBoYXZlIHRvIGV4dGVuZCB0aGUgZGVhZGxp bmUgZm9yIHRoaXMuIA0KDQpNYXJjbyBhbmQgSSBwcm9wb3NlIDYgbW9yZSB3ZWVrcyBvZiBleHRl bnNpb24gdW50aWwgMjAyMi0wMS0xMSBUdWVzZGF5LCB0byBnaXZlIG1vcmUgYW1wbGUgdGltZSBm b3IgdGhvcm91Z2ggcmV2aWV3cy4NCg0KQ2lhbyENCi0tIA0KSmFpbWUgSmltw6luZXoNCg0KT24g VHVlLCBOb3YgOSwgMjAyMSwgYXQgODo1OSBQTSwgSmFpbWUgSmltw6luZXogd3JvdGU6DQo+IERl YXIgQ29SRSwNCj4NCj4gYXMgd2UgZGlzY3Vzc2VkIHllc3RlcmRheSwgdGhlIGF1dGhvcnMgb2Yg DQo+IGRyYWZ0LWlldGYtY29yZS1vc2NvcmUtZ3JvdXBjb21tIHRoaW5rIHRoZWlyIGRyYWZ0IGlz IHJlYWR5IGZvciBhIDJuZCANCj4gV0dMQy4gVGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZHJh ZnQgKHYxMykgaXMgbm90IGV4cGVjdGluZyBhbnkgDQo+IHVwZGF0ZXMgc28geW91IGNhbiBzdGFy dCB5b3VyIHBsYW5uZWQgcmV2aWV3cy4NCj4NCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLWNvcmUtb3Njb3JlLWdyb3VwY29tbS0xMw0KPg0KPiBJbiBh ZGRpdGlvbiB0byB0aGUgZW1haWwgbGlzdCBkaXNjdXNzaW9uIHJldmlld2VycyBjb3VsZCBjb25z aWRlciANCj4gb3BlbmluZyBuZXcgaXNzdWVzIG9uIHRoZSBHaXRodWIgcmVwbyBvZiB0aGUgZHJh ZnQgYXMgY291cnRlc3kgdG8gdGhlIA0KPiBhdXRob3JzLg0KPg0KPiBodHRwczovL2dpdGh1Yi5j b20vY29yZS13Zy9vc2NvcmUtZ3JvdXBjb21tDQo+DQo+IEFzIHdlIGhhdmUgdGhlIElFVEYgb25n b2luZyBhbmQgdGhlIGRvY3VtZW50IG5lZWRzIHRpbWUgdG8gYmUgZGlnZXN0ZWQsIA0KPiB3ZSBw bGFjZSB0aGUgZW5kIG9mIHRoZSBjYWxsIG9uIHRoZSAxc3Qgb2YgRGVjZW1iZXIgd2l0aCBhIHBv c3NpYmlsaXR5IA0KPiBvZiBleHRlbnNpb24gZGVwZW5kaW5nIG9uIHRoZSBudW1iZXIgb2YgcmV2 aWV3cy4NCj4NCj4+RnJvbSB0aGUgbWludXRlcyBJIHRha2UgdGhhdCBDQSwgUkgsIEVEIGFuZCBU RiB3b3VsZCBnaXZlIGl0IHRob3JvdWdoIGxvb2suIFRoYW5rIHlvdSBhbHJlYWR5IGZvciB0aGF0 LCBtdWNoIGFwcHJlY2lhdGVkISENCj4NCj4gQ2lhbyENCj4gLS0gDQo+IEphaW1lIEppbcOpbmV6 DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo= From nobody Thu Dec 2 05:48:29 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638113A1100 for ; Thu, 2 Dec 2021 05:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 5CigU2boZpLH for ; Thu, 2 Dec 2021 05:48:22 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00072.outbound.protection.outlook.com [40.107.0.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF353A10FB for ; Thu, 2 Dec 2021 05:48:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AwIxxzQLifwg9BznnrE/+Q9fSnszQoHH89ZgLG//xRKyRWHeePSFnaiKLbmdpxvlniL9zp4flhMphtKXTmulEEovKcAXNjrhIRE+QodMpkAFuXJ5af5m44DbKya166F8irgWCiSoZZ8dWcwLVJR27UMmQSAWl6VYDJicm/NL+37ZVvR019q58OvnXan+HQbLv8EFi04Vpkirq5FTvVsragtr1gKojcool3a23O02+MPnz0FMg/CQfu/DL1umSwxyDPxOr9QykuHUdeFb/O7w4hkeLeG67Y+lSUWWOILQ9lWmPCCYE1CiVit7PAeRlNmmw8F19ZBicpR5uGHpJ9g+nA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NjMLXUiJhbMzmnISAKzpX+X4KZOa/cD48PhC2hRjvEc=; b=IOzx2LhkO65oADef6FJOz/D1CQqbVf7SIEoD2BSx324buXCXJVntkozW98HUmNN7mo+UbvMLTvY480SZK+ZqNIYxXDd+uTA006Vr3/xezzJmiwbJyZUektO71TP5Dubrce49nNXs75tIQvVakvd7VnSSiw9cjNeqWfCwbyI0ZbnOH2zts2Vy+Y5ksA8aAuS7FPdkWqpx2F/ell0MUwkD6cF2pN6iuNb9UtNFg7Z1l07o7heVZBHKIOoU7pWLMLfwDR8JCX6LLDw7DLATP6x8eL+G/LaRSXbhdwM1Vtxv1RvQai6RV9OARdmdkakKI6IJwvJbZrqxC1UAJKDgZvzERQ== 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=NjMLXUiJhbMzmnISAKzpX+X4KZOa/cD48PhC2hRjvEc=; b=REPhxCx1jY092Y1bx/TSbnvponDJqdoU7IdY+M8QhboHF5VSr2XleJEMWenvGRqHrU8pVOopt4PChIj7lLAMVylroHB8HvnfYWDVRFDLLo5D4yZEVpmWIG9ncieRnGCb6VR7woXkCTVfl7RPBgGJACsiH9rhd4+kCTg6JLtZTMo= Received: from AM9P189MB1571.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:30d::9) by AM8P189MB1250.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:24f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.24; Thu, 2 Dec 2021 13:48:16 +0000 Received: from AM9P189MB1571.EURP189.PROD.OUTLOOK.COM ([fe80::e510:c6c2:e086:60f1]) by AM9P189MB1571.EURP189.PROD.OUTLOOK.COM ([fe80::e510:c6c2:e086:60f1%9]) with mapi id 15.20.4734.028; Thu, 2 Dec 2021 13:48:16 +0000 From: =?utf-8?B?UmlrYXJkIEjDtmdsdW5k?= To: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core@ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHIExhc3QgQ2FsbCBvZiBkcmFmdC1pZXRmLWNvcmUt?= =?utf-8?Q?oscore-groupcomm?= Thread-Index: AQHX5sy5SM8wLy1RbkWdTBWR2KKP+qwfODld Date: Thu, 2 Dec 2021 13:48:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 7ffedc0c-6789-5e60-e75b-6cf414084ec4 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c24f5ce0-fd7f-4b17-4d66-08d9b59a644f x-ms-traffictypediagnostic: AM8P189MB1250: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xnZxQy24yvawaid9A1746784CLVZizRM44Kd8D3A+WIpFxwRXo45YKmCGtK0Oi6D1iIh8eZJS4Y9d1ZgujVFuccu1zFFNB4Fa5tdv6DXCVMWrMIeFOHTZR8+tk9z3DYyntADKojFpJS9bv05zSl1a3Jw35nYiH8xgReNVyBvpwSHCyVW1LNPAS7ZSslvP+WGlC6Qjee8UybDHxM5GeeVy7WC1+c2/8AhzdbVvNMpWGH1m45+1pzhliouZlfczFMkHNzX/kvH+tMiZzC63DOJLxzL0ZI3FJDTdtkwD8R+3fSVmPlXWQIpkuyC81wRwvTnptN3qpCYe7kSXEDm2m0uGVVEbsktHlTlI3PV8h+QJkio9Oa2n/137qOQrAJMtwICp77B6q3u+W97TVGqkbRqaEAwkjGG0xP1qHZC9gWUF3ls5SlNLu55lrmHtHb4lYEQkWL5ZBTZ33OdHJo1phEEjO1MjBxIVKip+51nUNyZ3Gr51YLQ2brlbSYhy96DBByGxupD+46r9d643T+Nq4zxeqYaWC02EJRm3+yltDcR9QwihVY9YY/WrNDx0+UZxutxUueI85vk+cS5ZjtUqFONSl37WofnnLnEaoeYQ2l0ZqTXF5YNKx6STMeRzylJOed2pgS/J4iK0177FefskrUPQjsrfPoj3iuJQk+NvYq3qtz/rQILLwz4xRf5bf/PjDgsCp9pFPt82q4Yc9Bvjds6GyShfrFFXw4FIkyTSByP2YWxlm6yZAO/KN3ujzjV3G6tRoyQ5fpRbqfZhkvTIurgMCA57jHosP4lzCWQcBDGq9M= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9P189MB1571.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(38070700005)(52536014)(85202003)(19627405001)(83380400001)(508600001)(110136005)(966005)(26005)(91956017)(166002)(71200400001)(7696005)(66574015)(33656002)(76116006)(45080400002)(5660300002)(316002)(186003)(38100700002)(64756008)(66476007)(122000001)(53546011)(85182001)(66556008)(66446008)(86362001)(8936002)(2906002)(6506007)(9686003)(66946007)(55016003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?emt1SGpPekc0R1h1OW95VmI1TW9CWFdoblh5TDM0dEdlZHdOakZLZGJ0Y3dY?= =?utf-8?B?RzcwQkZLbFh6Ri9veDZJTGpLejh6S3VBbU1yb0R6K1ZpMFI3Q2hETVRyTVNw?= =?utf-8?B?Sm9MV3hJQkRyUU0xUkowUG43TzJnTzA5RjdrWHVicWNuMTNzRUVXY1VGSy95?= =?utf-8?B?MzRFMUQwOHJwaVJ2anRSYXVKUUgvTE84eEVpUTFaVnIxRk8yd0JtSThmRVdq?= =?utf-8?B?V0ZEWDVlK3ZtV3V4NmNDd09mSW9DaEJlZTlNL2xNeHpUL2NZbklqdHNnWTJX?= =?utf-8?B?VHBhcFBWYWZnL0lhY2ZhZXM1SVZnd2JLaWR0Y1NCSG02QlpEMmJrMmtnZkZ2?= =?utf-8?B?VjV3Ymg5M0dqWm54M3cyVUxoOVorcjJaMXFjOC9YcDZITWFGZXgvVklIM1px?= =?utf-8?B?cm90RERRRzAxYUxsajlPSmRTZ3BwQk9xajdCWEVJdjJhY2VmTG95aVVwYUxm?= =?utf-8?B?WGtTQWlOVWJ0UlR5dWhieFl2ckRlS25SREVld3lZRFpkcEdTa0VveDNscGhm?= =?utf-8?B?ZkJrV1E2Z2t5NytJcHpsWnI4WFJ5QkNZNnR5Rm8yVFlReFpLdW1FSXYvVFB4?= =?utf-8?B?NFVXT3FHbWh5ZlBwS3B0UnRGRzQrNGZvaUlMbHpMS0ZXZjE1NXNDRnVnYTdm?= =?utf-8?B?RzNoaVNhYVlsd0JJU1ZRb1dSWDRCWWxpRVA0UG1sd0I3cE5tb0RiWEVFaTlz?= =?utf-8?B?bmU3cE1PakRobm1xK3luc2pVR2RINVNIOFN6NTJ2aWI5RXJBanFLVXFQemRs?= =?utf-8?B?UlFGc3JScnVUNUQ1cGErYlNiVEpuQVVPVHMwSWhaY3ZsZU8yeWsxS0pxRlJq?= =?utf-8?B?OEFnYUtVWlNIUTFwdlY3bWRKRjNWQ3RUemdkVnpOdm4vTUVLUVlUamJYQVZV?= =?utf-8?B?RnlST3lWVVFPSTM3bTFDc1h5YkI4RWxmSi9WYnE5bVdmQTV1YVFKemNkaG1q?= =?utf-8?B?bi9GWFAycXRCbDNRYmhLTGRCaGFxK0h3bkJ0NUFQSThhUVlMZm5aL0JhOE5J?= =?utf-8?B?TXNsZHJaSnF1VVViV2xOTUs3ejhDRE5vcDJseE40LzZSZG91TzhkdmU3SHJj?= =?utf-8?B?UTkybTFjV1NDWk96bDMxTVhsTTl0UGZkT3pacVJneXkrNzJwSDlBTFlWdi9G?= =?utf-8?B?WVJ4cmE2TXN4NzZ3SlFxQ3kxdTlCSmtNQS9EdWxIdUpMbzFTdnYyTkpZZjlQ?= =?utf-8?B?QTMxMUJSc1ZxUEp5NktjSUxRNGRZTGg2aUhHNlBFUzFPMUZoKzloMXRUU1R0?= =?utf-8?B?ZW9wWmluemNCZmphNno1VFhhak5vWFBkNDBDMzN4QnY4VG9QL1lUeWk3eVlo?= =?utf-8?B?eEkzQ3A1N2E2RUcxOGdZYkREZ1pYK3A2OE1zcThZRlo2ZWV5dkMwZyt0Vy9Y?= =?utf-8?B?Q0JIV3dBaS82N2hGdzd5ZlRaeWpYK0wrY0VYUFU0cmpueEtlcURGbDMwVzdB?= =?utf-8?B?c3A3QTJxek5ZcGV5UTFWVUVFTnBKRnhKNVVIRU1qMmp3NjhLS2JyYWtPN3dN?= =?utf-8?B?RTBwSlFkWjJLLzc2MVlIcVluRkJCK3hVVjBBWE9WR0RLMVJNR0poSGZHNk9p?= =?utf-8?B?VjZpc052WUg5cVRaN2tkd2dpMWtiaytmaytQT1NLTEVORk02SXJhS3JaYXJ3?= =?utf-8?B?cFFSNVp4eWpHcGp1bmtMdkV3TE1NczVmVFdnMThXdkV4ZU5DSnp5N3d1MWQ5?= =?utf-8?B?WkJlbURrb2FZRWE0MUNmOGZFQnA3WGJlYkVJQkFubzl2L2hwQmxUNFA5QkEw?= =?utf-8?B?RFFxZzJaeWdYM3I3a1l1SVU2RHhWTG9CczIvTnF3Y2ExMW5PU09OclM3SVRI?= =?utf-8?B?MHFGMlhWenNxMlU5YWd5dForOVBIY1UzWFlGazV0U3U2TitxNUxYZVlmdFQ2?= =?utf-8?B?eUVBMFF6a1ZVMzBoOTNWV2NRZmFNNW5QMVZLajMrYll4V3hTRktMd0kyb25Z?= =?utf-8?B?K1lMaVJUaSt0Ulh6MU9ucTEvQi8rcitpSDlsSUJWSk1iMk1aV0dPSDI3WFhq?= =?utf-8?B?MnRFSEQ5YklVSFYwaFk2TFp4SkxKb0ovWGFwOTFnNmRYR1VKMW8rQ1ZlQStz?= =?utf-8?B?dGpUa2g0R0t6VVhWWEEvQmpKeEZsbUpiam53Y250WGlkelBsMnl3SGx6T3ZB?= =?utf-8?B?RzFlaUtickNHRzJGKzJEcUptU2UzVndoNUV6VXpmVURPaEk2b3g1aGFPOVVG?= =?utf-8?B?Nnc9PQ==?= Content-Type: multipart/alternative; boundary="_000_AM9P189MB157177D63C0767ECF866962B83699AM9P189MB1571EURP_" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM9P189MB1571.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: c24f5ce0-fd7f-4b17-4d66-08d9b59a644f X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2021 13:48:16.1229 (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: b6uFynINpQ5J265ycGaXcY7i0EEyI4wy4/9DVPCxqrJM3qQIPhY6QcDY/Dmldvy2VXqKtwrx5bFtzUsJqDOkvA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P189MB1250 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Last_Call_of_draft-ietf-core-os?= =?utf-8?q?core-groupcomm?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 13:48:28 -0000 --_000_AM9P189MB157177D63C0767ECF866962B83699AM9P189MB1571EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8uDQoNClRoYW5rIHlvdSBmb3IgdGhlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBleHRlbnNp b24uDQoNCkkgYW0gYWxzbyB3b3JraW5nIG9uIGEgcmV2aWV3IHdoaWNoIEkgd2lsbCBiZSBzZW5k aW5nIGluIGJlZm9yZSB0aGUgbmV3IGRlYWRsaW5lLg0KDQpCZXN0DQpSaWthcmQgSMO2Z2x1bmQN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBjb3JlIDxjb3JlLWJvdW5j ZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBKYWltZSBKaW3DqW5leiA8amFpbWVAaWtpLmZpPg0K U2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxLCAyMDIxIDE2OjU5DQpUbzogY29yZUBpZXRmLm9y ZyA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0g8J+UlCBXRyBMYXN0IENhbGwg b2YgZHJhZnQtaWV0Zi1jb3JlLW9zY29yZS1ncm91cGNvbW0NCg0KRGVhciBhbGwsDQoNCnRoZSBk ZWFkbGluZSBmb3IgdGhpcyBXR0xDIGlzIHRvZGF5LiBHaXZlbiB0aGF0IHdlIGhhdmUgbm90IHJl Y2VpdmVkIGVub3VnaCByZXZpZXdzIGFuZCB0aGF0IHRoZSBDaHJpc3RtYXMgcGVyaW9kIGlzIGFy cml2aW5nIHNvb24sIHdlIHdpbGwgaGF2ZSB0byBleHRlbmQgdGhlIGRlYWRsaW5lIGZvciB0aGlz Lg0KDQpNYXJjbyBhbmQgSSBwcm9wb3NlIDYgbW9yZSB3ZWVrcyBvZiBleHRlbnNpb24gdW50aWwg MjAyMi0wMS0xMSBUdWVzZGF5LCB0byBnaXZlIG1vcmUgYW1wbGUgdGltZSBmb3IgdGhvcm91Z2gg cmV2aWV3cy4NCg0KQ2lhbyENCi0tDQpKYWltZSBKaW3DqW5leg0KDQpPbiBUdWUsIE5vdiA5LCAy MDIxLCBhdCA4OjU5IFBNLCBKYWltZSBKaW3DqW5leiB3cm90ZToNCj4gRGVhciBDb1JFLA0KPg0K PiBhcyB3ZSBkaXNjdXNzZWQgeWVzdGVyZGF5LCB0aGUgYXV0aG9ycyBvZg0KPiBkcmFmdC1pZXRm LWNvcmUtb3Njb3JlLWdyb3VwY29tbSB0aGluayB0aGVpciBkcmFmdCBpcyByZWFkeSBmb3IgYSAy bmQNCj4gV0dMQy4gVGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgKHYxMykgaXMgbm90 IGV4cGVjdGluZyBhbnkNCj4gdXBkYXRlcyBzbyB5b3UgY2FuIHN0YXJ0IHlvdXIgcGxhbm5lZCBy ZXZpZXdzLg0KPg0KPiBodHRwczovL2V1cjA1LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwl MkZkcmFmdC1pZXRmLWNvcmUtb3Njb3JlLWdyb3VwY29tbS0xMyZhbXA7ZGF0YT0wNCU3QzAxJTdD cmlrYXJkLmhvZ2x1bmQlNDByaS5zZSU3Q2M1MTQ2ZGIwMzIyMDRmYWYxMjVkMDhkOWI0ZTNhNjc2 JTdDNWE5ODA5Y2YwYmNiNDEzYTgzOGEwOWVjYzQwY2M5ZTglN0MwJTdDMCU3QzYzNzczOTcxMjk4 ODM3NTIxOSU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJ am9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0 YT02QjdkRWJKOGw0JTJCdmMlMkJ4ck1CaUZ4TjZHUmY3bEFvaTVGVVpCSTY4Y2ROUSUzRCZhbXA7 cmVzZXJ2ZWQ9MA0KPg0KPiBJbiBhZGRpdGlvbiB0byB0aGUgZW1haWwgbGlzdCBkaXNjdXNzaW9u IHJldmlld2VycyBjb3VsZCBjb25zaWRlcg0KPiBvcGVuaW5nIG5ldyBpc3N1ZXMgb24gdGhlIEdp dGh1YiByZXBvIG9mIHRoZSBkcmFmdCBhcyBjb3VydGVzeSB0byB0aGUNCj4gYXV0aG9ycy4NCj4N Cj4gaHR0cHM6Ly9ldXIwNS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRmNvcmUtd2clMkZvc2NvcmUtZ3JvdXBjb21tJmFtcDtk YXRhPTA0JTdDMDElN0NyaWthcmQuaG9nbHVuZCU0MHJpLnNlJTdDYzUxNDZkYjAzMjIwNGZhZjEy NWQwOGQ5YjRlM2E2NzYlN0M1YTk4MDljZjBiY2I0MTNhODM4YTA5ZWNjNDBjYzllOCU3QzAlN0Mw JTdDNjM3NzM5NzEyOTg4Mzc1MjE5JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0 d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3 QzMwMDAmYW1wO3NkYXRhPVdGWHREcGlRMVJSaVcxaFAxSmVVeDAlMkY0JTJGNWkxVUtPaWE5Wk5U NU5kSW5zJTNEJmFtcDtyZXNlcnZlZD0wDQo+DQo+IEFzIHdlIGhhdmUgdGhlIElFVEYgb25nb2lu ZyBhbmQgdGhlIGRvY3VtZW50IG5lZWRzIHRpbWUgdG8gYmUgZGlnZXN0ZWQsDQo+IHdlIHBsYWNl IHRoZSBlbmQgb2YgdGhlIGNhbGwgb24gdGhlIDFzdCBvZiBEZWNlbWJlciB3aXRoIGEgcG9zc2li aWxpdHkNCj4gb2YgZXh0ZW5zaW9uIGRlcGVuZGluZyBvbiB0aGUgbnVtYmVyIG9mIHJldmlld3Mu DQo+DQo+PkZyb20gdGhlIG1pbnV0ZXMgSSB0YWtlIHRoYXQgQ0EsIFJILCBFRCBhbmQgVEYgd291 bGQgZ2l2ZSBpdCB0aG9yb3VnaCBsb29rLiBUaGFuayB5b3UgYWxyZWFkeSBmb3IgdGhhdCwgbXVj aCBhcHByZWNpYXRlZCEhDQo+DQo+IENpYW8hDQo+IC0tDQo+IEphaW1lIEppbcOpbmV6DQo+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUg bWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly9ldXIwNS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJG bWFpbG1hbiUyRmxpc3RpbmZvJTJGY29yZSZhbXA7ZGF0YT0wNCU3QzAxJTdDcmlrYXJkLmhvZ2x1 bmQlNDByaS5zZSU3Q2M1MTQ2ZGIwMzIyMDRmYWYxMjVkMDhkOWI0ZTNhNjc2JTdDNWE5ODA5Y2Yw YmNiNDEzYTgzOGEwOWVjYzQwY2M5ZTglN0MwJTdDMCU3QzYzNzczOTcxMjk4ODM3NTIxOSU3Q1Vu a25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlM Q0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT1PNGJrJTJGZGho bDZpZFdoWERrcXhXTlV5R09VZ1VwNGZxVmtlVTBoWWtDREUlM0QmYW1wO3Jlc2VydmVkPTANCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFp bGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL2V1cjA1LnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZjb3JlJmFtcDtkYXRhPTA0JTdDMDElN0NyaWthcmQuaG9nbHVuZCU0MHJp LnNlJTdDYzUxNDZkYjAzMjIwNGZhZjEyNWQwOGQ5YjRlM2E2NzYlN0M1YTk4MDljZjBiY2I0MTNh ODM4YTA5ZWNjNDBjYzllOCU3QzAlN0MwJTdDNjM3NzM5NzEyOTg4Mzc1MjE5JTdDVW5rbm93biU3 Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2 SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO3NkYXRhPU80YmslMkZkaGhsNmlkV2hY RGtxeFdOVXlHT1VnVXA0ZnFWa2VVMGhZa0NERSUzRCZhbXA7cmVzZXJ2ZWQ9MA0K --_000_AM9P189MB157177D63C0767ECF866962B83699AM9P189MB1571EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNv bG9yOiByZ2IoMCwgMCwgMCk7Ij4NCkhlbGxvLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJw dDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQpUaGFuayB5b3UgZm9yIHRoZSBpbmZvcm1h dGlvbiBhYm91dCB0aGUgZXh0ZW5zaW9uLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsg Y29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx MnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQpJIGFtIGFsc28gd29ya2luZyBvbiBhIHJldmll dyB3aGljaCBJIHdpbGwgYmUgc2VuZGluZyBpbiBiZWZvcmUgdGhlIG5ldyBkZWFkbGluZS48L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0K QmVzdDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsi Pg0KUmlrYXJkIEjDtmdsdW5kPC9kaXY+DQo8ZGl2IGlkPSJhcHBlbmRvbnNlbmQiPjwvZGl2Pg0K PGhyIHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazt3aWR0aDo5OCUiIHRhYmluZGV4PSItMSI+ DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+PGZvbnQgZmFjZT0iQ2FsaWJyaSwg c2Fucy1zZXJpZiIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0IiBjb2xvcj0iIzAwMDAwMCI+PGI+RnJv bTo8L2I+IGNvcmUgJmx0O2NvcmUtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEph aW1lIEppbcOpbmV6ICZsdDtqYWltZUBpa2kuZmkmZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgRGVjZW1iZXIgMSwgMjAyMSAxNjo1OTxicj4NCjxiPlRvOjwvYj4gY29yZUBpZXRmLm9y ZyAmbHQ7Y29yZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtjb3JlXSDw n5SUIFdHIExhc3QgQ2FsbCBvZiBkcmFmdC1pZXRmLWNvcmUtb3Njb3JlLWdyb3VwY29tbTwvZm9u dD4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IkJvZHlGcmFnbWVudCI+ PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+DQo8ZGl2IGNsYXNz PSJQbGFpblRleHQiPkRlYXIgYWxsLDxicj4NCjxicj4NCnRoZSBkZWFkbGluZSBmb3IgdGhpcyBX R0xDIGlzIHRvZGF5LiBHaXZlbiB0aGF0IHdlIGhhdmUgbm90IHJlY2VpdmVkIGVub3VnaCByZXZp ZXdzIGFuZCB0aGF0IHRoZSBDaHJpc3RtYXMgcGVyaW9kIGlzIGFycml2aW5nIHNvb24sIHdlIHdp bGwgaGF2ZSB0byBleHRlbmQgdGhlIGRlYWRsaW5lIGZvciB0aGlzLg0KPGJyPg0KPGJyPg0KTWFy Y28gYW5kIEkgcHJvcG9zZSA2IG1vcmUgd2Vla3Mgb2YgZXh0ZW5zaW9uIHVudGlsIDIwMjItMDEt MTEgVHVlc2RheSwgdG8gZ2l2ZSBtb3JlIGFtcGxlIHRpbWUgZm9yIHRob3JvdWdoIHJldmlld3Mu PGJyPg0KPGJyPg0KQ2lhbyE8YnI+DQotLSA8YnI+DQpKYWltZSBKaW3DqW5lejxicj4NCjxicj4N Ck9uIFR1ZSwgTm92IDksIDIwMjEsIGF0IDg6NTkgUE0sIEphaW1lIEppbcOpbmV6IHdyb3RlOjxi cj4NCiZndDsgRGVhciBDb1JFLDxicj4NCiZndDs8YnI+DQomZ3Q7IGFzIHdlIGRpc2N1c3NlZCB5 ZXN0ZXJkYXksIHRoZSBhdXRob3JzIG9mIDxicj4NCiZndDsgZHJhZnQtaWV0Zi1jb3JlLW9zY29y ZS1ncm91cGNvbW0gdGhpbmsgdGhlaXIgZHJhZnQgaXMgcmVhZHkgZm9yIGEgMm5kIDxicj4NCiZn dDsgV0dMQy4gVGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgKHYxMykgaXMgbm90IGV4 cGVjdGluZyBhbnkgPGJyPg0KJmd0OyB1cGRhdGVzIHNvIHlvdSBjYW4gc3RhcnQgeW91ciBwbGFu bmVkIHJldmlld3MuPGJyPg0KJmd0Ozxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9ldXIwNS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRy YWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1jb3JlLW9zY29yZS1ncm91 cGNvbW0tMTMmYW1wO2FtcDtkYXRhPTA0JTdDMDElN0NyaWthcmQuaG9nbHVuZCU0MHJpLnNlJTdD YzUxNDZkYjAzMjIwNGZhZjEyNWQwOGQ5YjRlM2E2NzYlN0M1YTk4MDljZjBiY2I0MTNhODM4YTA5 ZWNjNDBjYzllOCU3QzAlN0MwJTdDNjM3NzM5NzEyOTg4Mzc1MjE5JTdDVW5rbm93biU3Q1RXRnBi R1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFX d2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO2FtcDtzZGF0YT02QjdkRWJKOGw0JTJCdmMlMkJ4 ck1CaUZ4TjZHUmY3bEFvaTVGVVpCSTY4Y2ROUSUzRCZhbXA7YW1wO3Jlc2VydmVkPTAiPg0KaHR0 cHM6Ly9ldXIwNS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZodG1sJTJGZHJhZnQtaWV0Zi1jb3Jl LW9zY29yZS1ncm91cGNvbW0tMTMmYW1wO2FtcDtkYXRhPTA0JTdDMDElN0NyaWthcmQuaG9nbHVu ZCU0MHJpLnNlJTdDYzUxNDZkYjAzMjIwNGZhZjEyNWQwOGQ5YjRlM2E2NzYlN0M1YTk4MDljZjBi Y2I0MTNhODM4YTA5ZWNjNDBjYzllOCU3QzAlN0MwJTdDNjM3NzM5NzEyOTg4Mzc1MjE5JTdDVW5r bm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxD SkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO2FtcDtzZGF0YT02QjdkRWJK OGw0JTJCdmMlMkJ4ck1CaUZ4TjZHUmY3bEFvaTVGVVpCSTY4Y2ROUSUzRCZhbXA7YW1wO3Jlc2Vy dmVkPTA8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgSW4gYWRkaXRpb24gdG8gdGhlIGVtYWlsIGxp c3QgZGlzY3Vzc2lvbiByZXZpZXdlcnMgY291bGQgY29uc2lkZXIgPGJyPg0KJmd0OyBvcGVuaW5n IG5ldyBpc3N1ZXMgb24gdGhlIEdpdGh1YiByZXBvIG9mIHRoZSBkcmFmdCBhcyBjb3VydGVzeSB0 byB0aGUgPGJyPg0KJmd0OyBhdXRob3JzLjxicj4NCiZndDs8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vZXVyMDUuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyRmdpdGh1Yi5jb20lMkZjb3JlLXdnJTJGb3Njb3JlLWdyb3VwY29tbSZhbXA7YW1wO2Rh dGE9MDQlN0MwMSU3Q3Jpa2FyZC5ob2dsdW5kJTQwcmkuc2UlN0NjNTE0NmRiMDMyMjA0ZmFmMTI1 ZDA4ZDliNGUzYTY3NiU3QzVhOTgwOWNmMGJjYjQxM2E4MzhhMDllY2M0MGNjOWU4JTdDMCU3QzAl N0M2Mzc3Mzk3MTI5ODgzNzUyMTklN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3 TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdD MzAwMCZhbXA7YW1wO3NkYXRhPVdGWHREcGlRMVJSaVcxaFAxSmVVeDAlMkY0JTJGNWkxVUtPaWE5 Wk5UNU5kSW5zJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MCI+DQpodHRwczovL2V1cjA1LnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJG Y29yZS13ZyUyRm9zY29yZS1ncm91cGNvbW0mYW1wO2FtcDtkYXRhPTA0JTdDMDElN0NyaWthcmQu aG9nbHVuZCU0MHJpLnNlJTdDYzUxNDZkYjAzMjIwNGZhZjEyNWQwOGQ5YjRlM2E2NzYlN0M1YTk4 MDljZjBiY2I0MTNhODM4YTA5ZWNjNDBjYzllOCU3QzAlN0MwJTdDNjM3NzM5NzEyOTg4Mzc1MjE5 JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1 TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO2FtcDtzZGF0YT1X Rlh0RHBpUTFSUmlXMWhQMUplVXgwJTJGNCUyRjVpMVVLT2lhOVpOVDVOZElucyUzRCZhbXA7YW1w O3Jlc2VydmVkPTA8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgQXMgd2UgaGF2ZSB0aGUgSUVURiBv bmdvaW5nIGFuZCB0aGUgZG9jdW1lbnQgbmVlZHMgdGltZSB0byBiZSBkaWdlc3RlZCwgPGJyPg0K Jmd0OyB3ZSBwbGFjZSB0aGUgZW5kIG9mIHRoZSBjYWxsIG9uIHRoZSAxc3Qgb2YgRGVjZW1iZXIg d2l0aCBhIHBvc3NpYmlsaXR5IDxicj4NCiZndDsgb2YgZXh0ZW5zaW9uIGRlcGVuZGluZyBvbiB0 aGUgbnVtYmVyIG9mIHJldmlld3MuPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7RnJvbSB0aGUgbWlu dXRlcyBJIHRha2UgdGhhdCBDQSwgUkgsIEVEIGFuZCBURiB3b3VsZCBnaXZlIGl0IHRob3JvdWdo IGxvb2suIFRoYW5rIHlvdSBhbHJlYWR5IGZvciB0aGF0LCBtdWNoIGFwcHJlY2lhdGVkISE8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBDaWFvITxicj4NCiZndDsgLS0gPGJyPg0KJmd0OyBKYWltZSBKaW3D qW5lejxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyBjb3JlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgY29y ZUBpZXRmLm9yZzxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9ldXIwNS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFp bG1hbiUyRmxpc3RpbmZvJTJGY29yZSZhbXA7YW1wO2RhdGE9MDQlN0MwMSU3Q3Jpa2FyZC5ob2ds dW5kJTQwcmkuc2UlN0NjNTE0NmRiMDMyMjA0ZmFmMTI1ZDA4ZDliNGUzYTY3NiU3QzVhOTgwOWNm MGJjYjQxM2E4MzhhMDllY2M0MGNjOWU4JTdDMCU3QzAlN0M2Mzc3Mzk3MTI5ODgzNzUyMTklN0NV bmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklp TENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7YW1wO3NkYXRhPU80Ymsl MkZkaGhsNmlkV2hYRGtxeFdOVXlHT1VnVXA0ZnFWa2VVMGhZa0NERSUzRCZhbXA7YW1wO3Jlc2Vy dmVkPTAiPg0KaHR0cHM6Ly9ldXIwNS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGY29y ZSZhbXA7YW1wO2RhdGE9MDQlN0MwMSU3Q3Jpa2FyZC5ob2dsdW5kJTQwcmkuc2UlN0NjNTE0NmRi MDMyMjA0ZmFmMTI1ZDA4ZDliNGUzYTY3NiU3QzVhOTgwOWNmMGJjYjQxM2E4MzhhMDllY2M0MGNj OWU4JTdDMCU3QzAlN0M2Mzc3Mzk3MTI5ODgzNzUyMTklN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4 ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhW Q0k2TW4wJTNEJTdDMzAwMCZhbXA7YW1wO3NkYXRhPU80YmslMkZkaGhsNmlkV2hYRGtxeFdOVXlH T1VnVXA0ZnFWa2VVMGhZa0NERSUzRCZhbXA7YW1wO3Jlc2VydmVkPTA8L2E+PGJyPg0KPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpjb3Jl IG1haWxpbmcgbGlzdDxicj4NCmNvcmVAaWV0Zi5vcmc8YnI+DQo8YSBocmVmPSJodHRwczovL2V1 cjA1LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3 d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZjb3JlJmFtcDthbXA7ZGF0YT0wNCU3 QzAxJTdDcmlrYXJkLmhvZ2x1bmQlNDByaS5zZSU3Q2M1MTQ2ZGIwMzIyMDRmYWYxMjVkMDhkOWI0 ZTNhNjc2JTdDNWE5ODA5Y2YwYmNiNDEzYTgzOGEwOWVjYzQwY2M5ZTglN0MwJTdDMCU3QzYzNzcz OTcxMjk4ODM3NTIxOSU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURB aUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFt cDthbXA7c2RhdGE9TzRiayUyRmRoaGw2aWRXaFhEa3F4V05VeUdPVWdVcDRmcVZrZVUwaFlrQ0RF JTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly9ldXIwNS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUy Rmxpc3RpbmZvJTJGY29yZSZhbXA7YW1wO2RhdGE9MDQlN0MwMSU3Q3Jpa2FyZC5ob2dsdW5kJTQw cmkuc2UlN0NjNTE0NmRiMDMyMjA0ZmFmMTI1ZDA4ZDliNGUzYTY3NiU3QzVhOTgwOWNmMGJjYjQx M2E4MzhhMDllY2M0MGNjOWU4JTdDMCU3QzAlN0M2Mzc3Mzk3MTI5ODgzNzUyMTklN0NVbmtub3du JTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRp STZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7YW1wO3NkYXRhPU80YmslMkZkaGhs NmlkV2hYRGtxeFdOVXlHT1VnVXA0ZnFWa2VVMGhZa0NERSUzRCZhbXA7YW1wO3Jlc2VydmVkPTA8 L2E+PGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM9P189MB157177D63C0767ECF866962B83699AM9P189MB1571EURP_-- From nobody Sun Dec 5 09:55:07 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8D03A0542 for ; Sun, 5 Dec 2021 09:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Fpj1u9mZY-da for ; Sun, 5 Dec 2021 09:54:59 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 8F4243A053E for ; Sun, 5 Dec 2021 09:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1638726895; bh=o33zpC6PX3EYZFvMfiIoJKC+Hy4wXJFu5lv4w74nmoM=; h=X-UI-Sender-Class:To:From:Subject:Date; b=Nzzdqd7nBk34ofskFXRYW6aEhgxO/1bZLFceXIGegBEx/EyTyHaoANytGx0RcER0W z4Q1qPxZnaBmBYCvPNNH9LKtmATpQNQDNoHN35dDVUY9Br7xGbxpvR2INJOTZy3Wml RaODDUOLaU8a4W7CZ7x3Ait5LLviEK2Isy2OZdsA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.10] ([5.146.193.130]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M2f5T-1mrRjd1TF1-004COR for ; Sun, 05 Dec 2021 18:49:50 +0100 To: "core@ietf.org" From: Achim Kraus Message-ID: Date: Sun, 5 Dec 2021 18:49:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.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:VK5p6Ki11K+K3yvuSaJ5iasoej7GGnHQl40Cnijzca0GrHih/1f hvbmmxNk1f3xGd/X7fvdQ5+I8FJkECIeBMH8tMKlW1CAnMVQBoY+b2xh9uTVDHNOcqvQO4R qlLRxyO6Kn3CTWtnKLiLuORLhKnNo3U+9PJH1IvgrvojGeWIIi8Wx9ZZChcmAd6Iu06Rv4d PEl4/+8SAb9nx0IqgXF7w== X-UI-Out-Filterresults: notjunk:1;V03:K0:/y0vkD+ed+A=:g0/JBxq7CqDegp701hvJ3e JmptI/cKEmsHLav6XM+XgYgiI9zL0WnYpISgIpQ136NYHSvn2J8HbhUkug600YpVBpg1/eFCF kh+bO0HI9H/R2Pj1R0aqx7cKpyqgI9owygCVOlPIDAuenU78uw8yaARgbA8stWnWRJjkk4Ifv Z3Pf/rqxHR8WNrPFx8H5hRLn0HwTXAq9W4gSg8MCrnZGt8KWMDLRm9ZKiTlMdwGW4j6lFbCGh qXKq8rYa3IxzRUEgKLz06Dsdoguq/dPXuOt+dp46MTIl9jRMwHXF4K4u+B20R5CjTTua6TtyJ 2cRMwaxHS1WQbqAqH46V2r5//tiS7/WX2Ljf6+frCVhj/RNG88PBEh0z7JX3tDhfmiQGKBgop aB7eL6mKnE5a3SXYlfJoD8WoU0jX6JLlnv9nwBqBuYDJyzPvsWMBWzfsNSqU5kqTMzim6yPhc vW5QRa+rtFQYOsJoNI7re+NOhOIZfEYTpusDODGKuFF5F2g5js3iJTMTQo6rwG5TmNA7KTU4B vjm9k7YL9abx5aUvOYId/axetrSwiVrIG+Hfp0a7C0u5XtXx7Iex+A02IM6RHxXLTFlkl0KlQ 28hDM2EvQL+MOGYz1Wh8E2Ti0Pp0aQXEzIVcPrJNy8vnqHAq9zG6d07UgRzP+oXPlFy/OJnt0 I0MlB32+1j+kZZAhCS+jIlg47a/iNQGWlht8cwPsLEl8mLfmD5xTsftw272KvNraPjsWqiFjs NBfMar8EyTVu4J7zze1ox+vjuv2D9nX4TqtrJlZT+fLscE7Qg7lq3NpJiNDnTmV4OSFcln7C2 cRc7LWd5K3xKGFQvIigeJW/ShCXyvLw9PGq2jRgLVqG//VaftFQMqXy1qFV5i2ZN1QR1jPiFL H6ZNjxnyVv7ALwfNnpfXxkJgBBcux2ceCIZQwckfXYvm6VySlpjy/CpzjEYNBZtxkNnKi9G/S q1MtPS+i/zFrzlU1xoKSVgS3wHTXuW0gCMomRwjlP25O9T9ULnkisDIBpfm0J3Olt61dBgyOJ 01KtGkNwR2DN7TX3piFt/srHBKFig8L2OY8JyJWtAbG2vzUuY5ZGocZosMYVBoJ9xnmV7ER1C xZSm/+P0w34IuM= Archived-At: Subject: [core] RFC7252 discover - RFC6690 / special characters X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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 Dec 2021 17:55:05 -0000 Dear list, I stumbled over a detail in the coap-discover, and I'm not sure, if my interpretation is the right one: How are special characters in the resource path handled, e.g. "[". My interpretation of RFC6690, https://datatracker.ietf.org/doc/html/rfc6690#section-2.2 is to report such a resource in the discover response as relative URI with: "" (The "[" is encoded as "%5B".) Is that the intended behavior? I couldn't find an example in RFC6690, which covers that case. best regards Achim Kraus From nobody Mon Dec 6 01:57:59 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED64A3A09DC for ; Mon, 6 Dec 2021 01:57:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163878467695.8193.10446613608643327743@ietfa.amsl.com> Date: Mon, 06 Dec 2021 01:57:56 -0800 From: IETF Secretariat Archived-At: Subject: [core] Milestones changed for core WG 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 Dec 2021 09:57:58 -0000 Changed milestone "Media Types for Sensor Measurement Lists (SenML) submitted to IESG for PS", resolved as "Done". Changed milestone "CBOR Encoding of Data Modeled with YANG submitted to IESG for PS", resolved as "Done". Changed milestone "Object Security for Constrained RESTful Environments (OSCORE)", resolved as "Done". Changed milestone "CoRE Resource Directory submitted to IESG for PS", resolved as "Done". Changed milestone "Management over CoAP submitted to IESG for PS", set due date to June 2022 from January 2018. URL: https://datatracker.ietf.org/wg/core/about/ From nobody Mon Dec 6 02:12:15 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B0F3A09C7 for ; Mon, 6 Dec 2021 02:12:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163878553397.471.4490809012604183437@ietfa.amsl.com> Date: Mon, 06 Dec 2021 02:12:13 -0800 From: IETF Secretariat Archived-At: Subject: [core] Milestones changed for core WG 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 Dec 2021 10:12:14 -0000 Changed milestone "Constrained Resource Identifiers submitted to IESG for PS", set state to active from review, accepting new milestone. Changed milestone "Group communication for CoAP bis submitted to IESG for PS", set state to active from review, accepting new milestone. Changed milestone "Secure group communication for CoAP submitted to IESG for PS", set state to active from review, accepting new milestone. Changed milestone "Conditional Attributes for Constrained RESTful Environments submitted to IESG for PS", set state to active from review, accepting new milestone. Changed milestone "Constrained RESTful Application Language (CoRAL) submitted to IESG for PS", set state to active from review, accepting new milestone. Changed milestone "Dynamic Resource Linking for Constrained RESTful Environments submitted to IESG for PS", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/core/about/ From nobody Mon Dec 6 08:50:30 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C983A0C01; Mon, 6 Dec 2021 08:50:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163880942920.4273.1562988200408400026@ietfa.amsl.com> Date: Mon, 06 Dec 2021 08:50:29 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-oscore-key-update-00.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 Dec 2021 16:50:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Key Update for OSCORE (KUDOS) Authors : Rikard Höglund Marco Tiloca Filename : draft-ietf-core-oscore-key-update-00.txt Pages : 25 Date : 2021-12-06 Abstract: Object Security for Constrained RESTful Environments (OSCORE) uses AEAD algorithms to ensure confidentiality and integrity of exchanged messages. Due to known issues allowing forgery attacks against AEAD algorithms, limits should be followed on the number of times a specific key is used for encryption or decryption. This document defines how two OSCORE peers must follow these limits and what steps they must take to preserve the security of their communications. Therefore, this document updates RFC8613. Furthermore, this document specifies Key Update for OSCORE (KUDOS), a lightweight procedure that two peers can use to update their keying material and establish a new OSCORE Security Context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-oscore-key-update/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-oscore-key-update-00.html Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Dec 6 13:57:21 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44693A0827 for ; Mon, 6 Dec 2021 13:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNCKkPThrHyM for ; Mon, 6 Dec 2021 13:57:14 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60074.outbound.protection.outlook.com [40.107.6.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 99C2F3A0823 for ; Mon, 6 Dec 2021 13:57:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KnhooCqC25LFr8im3PWDH+neXMr7PANtin7Rqw6qQypN1lxXvKQ6aMETiruTmAyt6YSUGrC6WnihW5fwRDTfaGv2hdko0xxNbuydPE/FJvHhKjIDArwi5GI6FmGrh7Cm3rfy1bN8NG+fi95K1aHOWtPPsgQEexQAmTtcgYKsygm/8uItB8ZuoaOP+r6elWMNhN8oMpXu8shA6cDh/OM0xqOrs3EKKAGwsiAPp44aCrchrbNR9bgjZ2vVmAi6KTKNk7iMN0hFX54QpAgZSE38Og/jZSSswIT1f/HNuKnyJK7X30NyO0pLIAMyrvO3NDv/kLtKSM6exy7DXyGBb0TiMg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2nQ/yxvXnsgLW3IfV/0VfNzlD1yy8X3kIgIxCRdGiQg=; b=fkbJu/PgkXxfgseVVE5qM73utl2bzP9jxG2uqM17euHRbRVAJ5OdH/o2P3Fe8qcHeGx9A0N9KIEnRs/U8Xi748pE3/9p6JlKP6AG5KN6utgOlxQo4FQIzLgDe61eVpOOBIbpHkMU40or0daazV2sJlU3WvtLXfYPtPfuy+MEM0vH1w8ciuOPwhnNHRTkK5GJwVK246L7ZTB9V9YBG/vg6VTFdOW7rM5Rl7uf7a7rc1hVJH3XaFPcSFHgWBSDwUzq0qC7bw7XOMl6Q5zssGcISOct4QEZ10TOsrTUHG4HEfev5rJHWulEL/zcBqEPZyU+w9r1FsQxpo0RW7Qnn5KOeg== 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=2nQ/yxvXnsgLW3IfV/0VfNzlD1yy8X3kIgIxCRdGiQg=; b=bGzHgaYSpwvePb8fU9xOkbLcoWIhOt28txOyO6bMECmkXUBsgxSURclw+pvDSK9477M0RbhcEte58tTwQ5k2QflPVQrRmqQt20/VEaB3r5pt5PkWpfb17ARs+C7LWGzp4T3cKPZH7xg1YPYK4M1rxbF7kxE5c1UtGeFrTDBc0+s= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P189MB0405.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:3d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.11; Mon, 6 Dec 2021 21:57:10 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::20b1:5d0e:9de4:7ca1]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::20b1:5d0e:9de4:7ca1%5]) with mapi id 15.20.4755.021; Mon, 6 Dec 2021 21:57:10 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: <0f2d9934-3b72-9032-e783-8ee7755272f1@ri.se> Date: Mon, 6 Dec 2021 22:57:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dkGAkdwcHcjhAeKwxoM0iiLPlmphKVito" X-ClientProxiedBy: GV3P280CA0062.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:a::18) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 Received: from [10.8.0.2] (185.236.42.107) by GV3P280CA0062.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.16 via Frontend Transport; Mon, 6 Dec 2021 21:57:10 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ed813434-a2b3-46d0-9000-08d9b9035a7f X-MS-TrafficTypeDiagnostic: DB6P189MB0405:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:3044; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 7lWf4tAQoptLk8ERoh8ay5cDGBb4M0C8SReVZ0jNO4EMWgzQskhMXHk7zUL6OJ456Xrz/Y7GDjiPDYhnti//jarJv2Bseq3yw0hmYvR1TSIESMJEvFMY7AgONz/3qIxEDrQrNPB30leySC7yt+osnhicAMSPdP2yJio6ocDMEQfVhFnaLaxK9GigpabsRjeNwoSd5AUm8zspWysfhC/GKM7N8VkVVw/CpXVWYfvil/DN7ChMHUHtn6vpY2eUfDf/ZVICnjy/bZyAhy3ppScwu0XSIlaGQYfCr1f98rdfon1T7T/Cf9KDM4updtLQi6qXTdF4DlBOQ19WykMs+X5SRVWzk8F4TcZrbrGG3kIB2OE426R9+fHWd77m24NcljAhydC+h4vCwb2e25WpUyGTspaXIrVf3vDO10U3r9CETJP+oFkHQemgUt6x5wk96j96ouN0B9DfwvRIwIoAIuFrCxQKrtQWladVXAAZDew9UY8I9yHSZbS2xExoZNuIjNuK+/uw9NhckDxnKKI0yjJa+ijd/+xc5Bkgx8/eSCZ47eVyXsX8b5xnMJVttNmqOsn8CpYx8VGwv+v2B+Ewp3zNfV4b8oRD9HzUNbhNavHVsRF0J4oiSiuSbk5SUeQAuqFgqFgAPrw8K9elMMPCAI75/PUlM0Ii3zK20m847E0w2UBFtU3jWmenkwxRvNa8XpsWejTjVRITcGOly8G5v6ngai0vZ+2XyML9G40gHNE/K9ZjKSXATDVK0sW71S2ZdkjsNPgWhs/W7gb9pVbTChi7pkudYEyiD0ZOn6uyKiJWbY//xl8iYmHSaMGFCb34vqAJ X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(38100700002)(31696002)(16576012)(316002)(31686004)(6486002)(508600001)(21480400003)(966005)(66574015)(235185007)(8936002)(66476007)(66556008)(66946007)(956004)(44832011)(2616005)(26005)(2906002)(33964004)(186003)(86362001)(83380400001)(36756003)(8676002)(6916009)(5660300002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WjhqQWNyakxLNUY4L3MweWU5ODhldE9xb3FnSTVsbUd2L0FXQUwvdjNxRmRK?= =?utf-8?B?eGoxdmdjMXF5ZmdKMVFIVElkdnJyZTVFdm1qdGg3cERVbmZMeGhMdmpTd3ps?= =?utf-8?B?alNWbGpubXNKbERSM3VSODd1K0wwamY1MUlyMUcvMUl1QVV3WnU5VG9wdjYw?= =?utf-8?B?OW5PREV2Qi95SFlHdnlTV2N2b2lzc0VCQzJ3c3liQVF1VURId0xWZHBITEFi?= =?utf-8?B?WTFJZzFHRE5XSUs0a3Z4ZWFQbWxYVUhQR3VvUlZGS1dac0xmOTVkcEN4QzE3?= =?utf-8?B?amYzaEN3TnJoRFh6VG4weEFWZndrTE5zZE9STHBxOUZqRUErdEJ5T3NuUy9N?= =?utf-8?B?UXRRNUtHbXNJQjBvdGdHK3BaM3EwaVQ1OFFTc1VWR2NDSGZxZlh1UnRkUElC?= =?utf-8?B?eFNRZmxTdzhaWkhhOVpxZ0dTRnlpZEo4UnA0U2FscXk5OGV3clpkVEM4TGg0?= =?utf-8?B?L2hrR1lON3JDNTVkeGc3VnNGZ3d6UXRaYy8vWTMrUUpQcXpKSjU3K0xpWXF4?= =?utf-8?B?a0NCWW5jREFqcDlMeWsxSFh4SVVqOUFtSThIVjFKUmQwTVpPNnVyUnQyQitH?= =?utf-8?B?OFdIR1U1Q2taMTh1SHZGZis3ZjJtaEsxM3BRRFlGYUdJaDBmamxtMmJ3QnlU?= =?utf-8?B?WXBNS3hnYm1OR0RGOVg0enlENDJHRGY4ZlpsTk9JTXNUdVNHOEJaSzlzMGtU?= =?utf-8?B?UFhNNkRmczJBQ1BCR0tWU3BrUmJ4U2pzVXFkUXR4RDc4QzVGTlg3TWpZckNx?= =?utf-8?B?QVlYanRGeVhqVTUvd0llOUlSckU1eDlFZGtKdEIvZmZKWnpZZCsxM2xSc05K?= =?utf-8?B?cklxTG9XQ1lBWkViZm82aG5uZG9rdXlZcFBRRnF4Wnc2OFV2d3prdVFiQk45?= =?utf-8?B?NnBEMkJaWC9WL2VsdEt0dDllQ0hZbkZTb0d0V3R5ZWJvZU0yak5MTmtISE5N?= =?utf-8?B?UTMvQUFJekMzYk0rd0FDWmtrUEswNjgvdVU3R3VYRlVReXhNVklnM21RNUdJ?= =?utf-8?B?U1I0M1BaUGtyWTlUaE5QeHhRYlhKSVY3YVZRb0lkMjBxSFF5ZTlUWC94YmRw?= =?utf-8?B?TXpialVVcDFBQS9lU2l1Y3h0VFNNWkFSZ1hpS1Y1dHFYZlpDYThacWxHQStE?= =?utf-8?B?dXJSbm9ES2xKellMY2g5VjZtMHdidXIvaXF6R05kdkRqLy9hSVZocUFrbmI1?= =?utf-8?B?S3N0a2xCUEVBZkdQTDZWQXhjL0hUNTBBSVF5QW13ZzJTSmRRblJHNlJqVVdZ?= =?utf-8?B?LzRLQnpZODlkU0VydDZ2UkwvdHZROFhjeWpHY0JIRnhJa0NpSzExcThtb2Zj?= =?utf-8?B?Vk1EZllFTUpoOHgrUTU0S3QyeXRDbmNGeUNBT21tOUFIb3NIaTZ1dWdROUds?= =?utf-8?B?V0hseW9nOEFKK2RkRHRmc05mUTNkZGxTMGRmZmduNmloQlR0QkNaaU1ydHNx?= =?utf-8?B?N0g1RFNUMHFTNDMwTGFZZDA1RTU0UGpYNkZKZE1UZjU3TnJDeUhoQ0lGSWVE?= =?utf-8?B?RFJVdW9pbllHdHlnbzBQZld3ZE02eGhieEg1TVRBeXREaFR5ZVBhVFFtdHlX?= =?utf-8?B?YmxCSVhwVDVjOEZua0NuZ3ZvZE1PTDllSG5rWGdkUmxOMHRkT3Arbkc1YU9D?= =?utf-8?B?Tno1L29Ia09HNVhxZzlrVTJrRlBjSGo3OTFXbGROR0hGN2hrRlZKejJPMDdq?= =?utf-8?B?N1ZwRnRYYUswRDA5OExwU1g4YnFlMmNGRXViQURwR1NPZVJkY0VxaGRMUTdu?= =?utf-8?B?cWpzQXdZaFFnVGgwUUNlRjVYWXoyN3E0dTM2ZnA5L28yU1locGR4TFZET3Q4?= =?utf-8?B?UmRXdGQya2tNdGk5Qi81VU85NWFBV2VNL3FMZit3VkF6WG9iNGk3MGljOUxY?= =?utf-8?B?UHhLTTVuRFdnd3FUTDJUeGZEN0l2ZHVJeDdteDY5NXAwS0FuWWFISGVxV0wz?= =?utf-8?B?eGRDWHRZQVFOdHduOGl4VUQvMUsxMFdpUlAzQXRjT044aUxJbkNEZlZHcFFO?= =?utf-8?B?dmJnWVhxTGpDdGttL2lROWJyWDhSMitwdXNZK1dFYUE0czVvbUdXYmhsWjlk?= =?utf-8?B?Q0RndnBLM1dITnA5dklwRzZPT0dZNW55TWRzdEpieDcxOUtHZmdYM1RhVSti?= =?utf-8?B?YmRISmtsVlViT0Q2S3EyN3ZZM3Y5cTQwUDdPeHRjNmNOampPYitoOGdUQmhI?= =?utf-8?Q?mkmrVxnHgUKcty+2jnPebXw=3D?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: ed813434-a2b3-46d0-9000-08d9b9035a7f X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Dec 2021 21:57:10.5391 (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: ROxwmMPYiLqGCev2tnVXu16QusDvUNgspxXjGIJtgzxHOTn7IZbw+F9XaAmnUiVLVVRBii3zCDiwceMM4fgoAQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0405 Archived-At: Subject: [core] CoRE WG Virtual Interim 2021-12-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2021 21:57:20 -0000 --dkGAkdwcHcjhAeKwxoM0iiLPlmphKVito Content-Type: multipart/mixed; boundary="0DO5uusSKDoGCdJGktr47732eYZ2yznD2"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <0f2d9934-3b72-9032-e783-8ee7755272f1@ri.se> Subject: [core] CoRE WG Virtual Interim 2021-12-08 --0DO5uusSKDoGCdJGktr47732eYZ2yznD2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that we will have a virtual interim meeting on=20 Wednesday, December 8th at 15:00 UTC. The agenda is available at [1]. The meeting will be on Meetecho [2] and minutes will be taken at [3]. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/interim-2021-core-14/session/cor= e [2]=20 https://meetings.conf.meetecho.com/interim/?short=3Dd0d8d377-c8f9-46ef-87= 08-1f13d069af9f [3] https://notes.ietf.org/notes-ietf-interim-2021-core-14-core --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --0DO5uusSKDoGCdJGktr47732eYZ2yznD2-- --dkGAkdwcHcjhAeKwxoM0iiLPlmphKVito Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmGuhzQFAwAAAAAACgkQ7iZktA5Y2kPz EQf+IAt/x7XBOF7KCfpW8Xzhig8MmLl5IuruD4eysadNo4f8GXJ3HaMQiL36Ml7JF2Zj7moDudbh NxNLs+GLeOUw4gw14HLBgYlbZB6NSVGoS80E7w+5fGOYXXuzdxH9H/gpvewntQiTolq9r5ZB48mD XoXZbB94uD9oOGWmZpuCRTX60WsVPSa2UBMd2dRPZ98ihd3IW2qdRSc3xEqjFP2yRIo0V1MZemsV srGpYmVQV/9QxQr5mrFyrsMMdL+U9+mtk8SIo1ffnPZ+KpEgU0wAQA4BVtjZLC4Rrn6w8nrMIWnG AjJhI7WOMo8bzpXVnwqNj8+koyK3CeNXZd0tTYVLzg== =Txq7 -----END PGP SIGNATURE----- --dkGAkdwcHcjhAeKwxoM0iiLPlmphKVito-- From nobody Wed Dec 8 07:04:28 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7073A09D2 for ; Wed, 8 Dec 2021 07:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-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=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 yupLWuAWVFv7 for ; Wed, 8 Dec 2021 07:03:58 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60053.outbound.protection.outlook.com [40.107.6.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701203A09D0 for ; Wed, 8 Dec 2021 07:03:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KKqx/G+Zr5DYuggqQNsUt9G7bh8Q/tRXY0kk1uMCS3E3hWc7ieyq7AHuabrABi9iNpBKSLAuIsq5sjFx1NhjTQWCUiX7nDHZ6cxVGfxie9vLhQoiwpyXkPfNoJ4bn/pd1CWaziy01msBLYDw+Xdom/k5KpX88KUdsJY4f9Cuxvn2kkCvIY0Iv+xhEMXmjXIh70IgFqCJsRv+ERK3FA/F26kpk8taXy7WiwJwE9TsoHx61tQDymhCBJewr/1rV7IML55sNN49oFDiaYdS8P/q9UDSeD17W53sgUvQQ0kmEEHcABn8t/I9q2RnEPzvDUPjVz5qsB01fz0eRRYjRkRstA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=p+MLVzLVzhqYPmHrUq65zrlKB2/TnsXizz6GMQN1fck=; b=Mj87G2LzXE6nMH38rArBCYdD42uioRrd+JuZm5hpPprqHAML1RvzNUheisw1YnA5wwVORr1vpCmZiiz/QwVTtAJoeI/Gp+Bhge0KEzDAfyM2labqAGu8khTw1k9YaTM7d10LFYImUxOExyqYXixSFYany5i6MNuKbxLjquFpha3NF72vBWa+k484trutTsQRrJku1oomwjvINSQ+9KuDQTq78H+bcQpAupJF4qewarWNCSmBHVAQiW4k+d0JBSKqWoxaN1Qxwqiq4eVA8PE3r04NqxAItS3CTJZZP6dT1GXWSJ6+3WT0pmIg28RvAznymTXThWlugcHWkLmXwozmBw== 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=p+MLVzLVzhqYPmHrUq65zrlKB2/TnsXizz6GMQN1fck=; b=K7CK4SpIWmQ6jvem0CZClkeASafgZtxGJ1Ew9r4/7kGbsC49iqMTWFTm/l7T9n+Z5rOdR16tn/BcvtIDivNgWZVuNcym9Ul6yiyZCfAvLojo0YI0c0ep4kMOysZPrqGBu+jOEG5smoCHZQZiNAFkqzw4Kbc10rWF9q/SRXDRsD4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P189MB0374.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:3a::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.11; Wed, 8 Dec 2021 15:03:46 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::20b1:5d0e:9de4:7ca1]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::20b1:5d0e:9de4:7ca1%5]) with mapi id 15.20.4755.022; Wed, 8 Dec 2021 15:03:46 +0000 To: Marco Tiloca , "core@ietf.org WG (core@ietf.org)" References: <0f2d9934-3b72-9032-e783-8ee7755272f1@ri.se> From: Marco Tiloca Message-ID: <96f442b0-cf39-31a1-c526-e4dae3c91f60@ri.se> Date: Wed, 8 Dec 2021 16:03:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: <0f2d9934-3b72-9032-e783-8ee7755272f1@ri.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="C5U1XXgLv1E9Dnm9U0WPrATuYu3uCdekB" X-ClientProxiedBy: MN2PR15CA0053.namprd15.prod.outlook.com (2603:10b6:208:237::22) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 Received: from [192.168.0.65] (92.34.13.218) by MN2PR15CA0053.namprd15.prod.outlook.com (2603:10b6:208:237::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.20 via Frontend Transport; Wed, 8 Dec 2021 15:03:45 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: aabcb257-1a25-4d73-07b7-08d9ba5beecb X-MS-TrafficTypeDiagnostic: DB6P189MB0374:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2399; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: iP+BtVyA9aw3hYRZnfCJuCSSBS9TZHCwVOsQteC7ZIPygx7AFeTvw/AoxFPeOhgemrgHmx96B31Q9fw9u8N7jIcys0vDl5KaoX/Zg1eTDPLoLxo+5Su1WC56mVNdo6TwASIprNhRCy5WGJeFLgQU95vgEuwHzHaPVsUNAh8+3oZrcrDev5U5g73b171MaH9CBjq2vMOpUd6QGxk5IZ8BR/Jha54+zP8NSwyRjTJkdrFkioFUl6/6N9Lel4zNauJVyg8YcwGlRer7bQG8X0LEgY9CGZS84enPWlA2Wo8mJu+Sc58Bop4HP6SAbQbkg7K782rJGzQeFSZ40bBUWPqyK7dPOz1OM3nCtJ+b2rwOYmGI0d/K7s2opY7bIvQcK9gm9cukAmMyJzrVz4hocYTFQB8of5NPZDVLGIgmL5YHIHVTcxlhJQOcOMyuPBWEAPPMm6ETfswV8rsTLpA6nomCRH33pHXGX3l8rRZ0MRBfZY8CL6XViH+bSL+iiskwVRHQzCq7lekB9PpLwld0ScFyz6UO0lZSODDgArU3PDCPH1PSswcfoveABjq0NqPn5CHcj+tcKbWucLhlz92FcQm9+Ur3MI4gzBh1hsvWblPnWuTH042pcrNV9WA9ZqxFHI3yr32gvoR286jJeNwL6tPfHjIW8cc6B2U5umPOiERxhYE3QMYGxtYWw/g8YfFbGpE5bBdlCr633bm7pu+pk9pOoG8X7djVbqO4TBGOegv+gjP93FKwDKVCJfSbC6EUPL0kTfS+STppoo0Vc/Ai4E4gDaAMe9BlQAa1S5AaPl5I6tIEh/YB104dYWhMhdFgMHGG X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(26005)(66946007)(235185007)(8936002)(66574015)(2616005)(316002)(8676002)(83380400001)(110136005)(956004)(16576012)(66556008)(66476007)(2906002)(44832011)(166002)(966005)(53546011)(6486002)(508600001)(6666004)(33964004)(186003)(5660300002)(21480400003)(36756003)(38100700002)(31696002)(16799955002)(86362001)(31686004)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QWRpZmNRbVJPaUo3dWNrcHkycGJIWGJ0RjJodzhBSWhPOER2Slk1Y0krRld6?= =?utf-8?B?SFpZNnhKbEhTRFlibEt1Um9HMjNTSHB0SG9IYVlUeGVpVWJZMm9nSGF1OGlC?= =?utf-8?B?R2E1allYZnJLN0hjelNiaGpCOFpwaExRK2lUNXdqZGRVTHg3b2hHWUxWRXRz?= =?utf-8?B?MzdWNGk0YnR6ZDVmbW1uWDNjSmJyczdsbGJsSEJ5YmZ4am1oQWV0TTVCRlNr?= =?utf-8?B?enQvZHQvekRXYi93WUNnWHZIZzJudUhTaGl3Wi93dWRKN29BQmVqcUZIWFNR?= =?utf-8?B?MDFuemVFTDFDVXBkWjVqT0hPaXBxMk56M1phTFNCRjR0YmVQM2xpRjVtbDNZ?= =?utf-8?B?cGhSSmdBbVVQNVdjbWVoeTl2ZS9HT0lFNnEwQS9UcWFQRGdNeHMzSWdEaTZq?= =?utf-8?B?ejRyZFVMUUIvZlFHbXhIYXVWU01SNHB1NGgzMEZGWERQNVNzcmxPU0luUm1U?= =?utf-8?B?K3p2amU4eGExMXh0djR2NHQyc2VTS3BhcEs0WDh4cVYyenN6MHJVY1Qxb1lG?= =?utf-8?B?cXJnR0Q2Q01LQzEzbkxlTjFQbWxUMnNtM3NzTWNQWCtENS8zMmdOZVpLbWs5?= =?utf-8?B?Y0VZUTFFZmlsVFEyZ0doajZRMnBtdmh6QzRmZzNTSGpnbDhhQmpMWGdzT0Rz?= =?utf-8?B?Slo4TVpPUGl4VTY0YXpQVWMrSHFPZ0gyUzJiQ0V0Z2VSdHd4OGFyTGRTdGt1?= =?utf-8?B?T1pIeUlWLzB5OE5IZHNFR0ZqRmN1UjRUd3NBWkFPV0JDZzlpdFRKd1dyUU1K?= =?utf-8?B?RHMvVUFhSVl5V3BlRzlpc014TmFsK0FwQWV5dFBPVHVSWWxVOHdJQmxBR29S?= =?utf-8?B?NkZZbmI2Yy9Udk92N2JJNHQ5K1VSMmZ6MmRkTjdvTVJBWVZ6UVQxTlRXa3dk?= =?utf-8?B?aDVTN3RPd2VDSVd3NXpPMzE5aTdUTmdIWHZQbkUyNE9tWHF2MEN5amVrUjlU?= =?utf-8?B?Rmh0NG9YTDRjbGtGTTFnQThvMmJRTU81YzE4cW01ZEZQVFJmcjdrLzlWTWhI?= =?utf-8?B?di9JQi9kYjA0MXQrTlYzL3Avck45YkxrbzdEdTViVXhxd05jSEJHWkdSRS9o?= =?utf-8?B?OTN4c2dLYXFXbGpBOXlNZVYwcVhZcnljZDBjNGd1NVBCUTVHMTFMck1HTTZi?= =?utf-8?B?cTJuL3dXazFDL2tIMmE1enhhRkg2cTJDRmpkS0dVdDU2SFVGQUtIWE5DcFlh?= =?utf-8?B?WHNBeUhxd1crclpzN0xqQ0RVRXhXck1IUGhha3pZUmdYWVVUSzd3L05HQmg0?= =?utf-8?B?djZFKzZjQ0I5ckVpRmxUaVNPalFrTWlDMzJKQS8rT2hnUldpSmlJS0lpbWEr?= =?utf-8?B?QzB4bm4rei9YZVRTZlo1UDByLytKMVgrbExuRFdLSUdtMkZkTndRMXdqSGQv?= =?utf-8?B?WVBRenJubWJCaXZxclpvTlJPK0VQaXRQMkk1VzVyWHRBN0tYSVR0dUxBZytJ?= =?utf-8?B?VThYNnZ2dXZ1dUVDMjBTZnNZMGhWQ0RQT01nQXBRSy9JV1ZrOWdEc1M4VVBl?= =?utf-8?B?Q0Noald3TEVwVnI2VmtIUkdIeHE3SjhlU2kyektFZmd6WUd2NTZWdmxxKy83?= =?utf-8?B?bG5CUzQ4UmE1Z01UYzdYNGdHM0hoc3I3a2RiTHU4WFV2VW1WVFVzNFNlWkl5?= =?utf-8?B?QnAvNmNxUSswNGh5b1VqaFBsdVFNRkl3dWJWcVQxOXB5RklpVlAwVTByQUJT?= =?utf-8?B?VjR3TDgybk5sVE5hMmtaSFdyYWZNejhoczhNcFJZMkJTc2JqVk96VVNKR3NG?= =?utf-8?B?WW1zZDFxb3I2Rk1vR3dZdnpJYWxGTk5xTytKckRjMklDQzI4akdnSU5jVmJa?= =?utf-8?B?TCttUkxJRno0bXk0clJYTmhJZ0V2TVljUld6VlBRcEtKTEpyYWFYMTI4S0ZR?= =?utf-8?B?NW9ybzV0K3pGMW9GcHd3bXlUODRDbTcyeFNNUm9SVFZxbmY3K3hHZlhBbXI1?= =?utf-8?B?d1RKZmVUeXprc0ZaOWs3ak9HeWtaVmpQdGNha3Y0Z1NaNHFEQWcydDhQcG9t?= =?utf-8?B?dk1oRDBPVTFXT1lCQ2gwMGViZUQ1VytHMk45ZE9DMzIxSGN2RmVaZFlSS0h4?= =?utf-8?B?RWk5bWhaSm5uUDNWQmxuc2U3bEhYSVF4eTF4YVlTUzhVeUd1dUtVclhEUmVQ?= =?utf-8?B?YkVUTWlwQWg4ZHFqMGlQL1BrNmsrV2FkOXpwN3FPdGtIWmdkZWZxaDN3YXhu?= =?utf-8?Q?gB/+sbCnQGTzZL3JuruX1Jc=3D?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: aabcb257-1a25-4d73-07b7-08d9ba5beecb X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Dec 2021 15:03:46.2440 (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: OJsx/cDukvBtxQ610D75DYqijqjvFEha6xA62OG4xn88ZLZT/qzkC54SXm+2g2aerOmWXJrC3mqKk5m+TapalA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0374 Archived-At: Subject: Re: [core] CoRE WG Virtual Interim 2021-12-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: Wed, 08 Dec 2021 15:04:04 -0000 --C5U1XXgLv1E9Dnm9U0WPrATuYu3uCdekB Content-Type: multipart/mixed; boundary="hOF3YVTdRhjAEG8Ggd5r2RJ341arIT58M"; protected-headers="v1" From: Marco Tiloca To: Marco Tiloca , "core@ietf.org WG (core@ietf.org)" Message-ID: <96f442b0-cf39-31a1-c526-e4dae3c91f60@ri.se> Subject: Re: [core] CoRE WG Virtual Interim 2021-12-08 References: <0f2d9934-3b72-9032-e783-8ee7755272f1@ri.se> In-Reply-To: <0f2d9934-3b72-9032-e783-8ee7755272f1@ri.se> --hOF3YVTdRhjAEG8Ggd5r2RJ341arIT58M Content-Type: multipart/alternative; boundary="------------B279BCA348601A0146B4716D" Content-Language: en-US This is a multi-part message in MIME format. --------------B279BCA348601A0146B4716D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Dear all, Many are having issues joining Meetecho. Please, join on Webex at [1]. Password: "constrained". Best, /Marco [1] https://ietf.webex.com/ietf/j.php?MTID=3Dmdd42b7c13deac94af584c4f5a7b= f0ffa On 2021-12-06 22:57, Marco Tiloca wrote: > Dear all, > > Just a reminder that we will have a virtual interim meeting on=20 > Wednesday, December 8th at 15:00 UTC. The agenda is available at [1]. > > The meeting will be on Meetecho [2] and minutes will be taken at [3]. > > Best, > Marco and Jaime > > > [1]=20 > https://datatracker.ietf.org/meeting/interim-2021-core-14/session/core > > [2]=20 > https://meetings.conf.meetecho.com/interim/?short=3Dd0d8d377-c8f9-46ef-= 8708-1f13d069af9f > > [3] https://notes.ietf.org/notes-ietf-interim-2021-core-14-core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --------------B279BCA348601A0146B4716D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all,

Many are having issues joining Meetecho.

Please, join on Webex at [1]. Password: "constrained".

Best,
/Marco

[1] https://ietf.webex.com/= ietf/j.php?MTID=3Dmdd42b7c13deac94af584c4f5a7bf0ffa

On 2021-12-06 22:57, Marco Tiloca wrote:
Dear all,

Just a reminder that we will have a virtual interim meeting on Wednesday, December 8th at 15:00 UTC. The agenda is available at [1].

The meeting will be on Meetecho [2] and minutes will be taken at [3].

Best,
Marco and Jaime


[1] https://datatracker.iet= f.org/meeting/interim-2021-core-14/session/core

[2] https://mee= tings.conf.meetecho.com/interim/?short=3Dd0d8d377-c8f9-46ef-8708-1f13d069= af9f

[3] https://notes.ietf.org/notes-iet= f-interim-2021-core-14-core 


____________________________=
___________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core


--=20
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www=
=2Eri.se

Phone: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)
--------------B279BCA348601A0146B4716D-- --hOF3YVTdRhjAEG8Ggd5r2RJ341arIT58M-- --C5U1XXgLv1E9Dnm9U0WPrATuYu3uCdekB Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmGwyUwFAwAAAAAACgkQ7iZktA5Y2kP2 IQgAtKztL3TIS59AGX8anR+REGg1rTu7zjUSLIouV+Z/JxYgCGOL/bwHhyZXmw9RbJPh6uG2TJjF YjnagcL92/Uh9SdHgyETfzdDwllJAT2Oi9zFLWK4nrVJHNP3Z536qY6BeECGuVeMkdAQRrVBQmxU kVdt20qfK+RU3bh1PV5Ebt9ffNOLanuuwmoZDPzMVy2/6DQZXUptZnNHYLdg+qLb8uBybtMkecQr 0FjrKvng5VZPtoL5CVoBRFxMb/ORVewE2UmFBs9ir5n4rvSUqSVfxSZ3aFFRs5Ev5vsJv6F9Bfia TJ5e+igf3USdwLS4nrGfLlu2OsTqgV9vZqH2vYqs5g== =mIqY -----END PGP SIGNATURE----- --C5U1XXgLv1E9Dnm9U0WPrATuYu3uCdekB-- From nobody Wed Dec 8 11:57:12 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 519613A09FA; Wed, 8 Dec 2021 11:57:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-core-sid@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann , jaime@iki.fi, jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <163899343030.12184.8844189837449825001@ietfa.amsl.com> Date: Wed, 08 Dec 2021 11:57:10 -0800 Archived-At: Subject: [core] Benjamin Kaduk's No Objection on draft-ietf-core-sid-18: (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, 08 Dec 2021 19:57:11 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-core-sid-18: 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/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for (largely) addressing my previous Discuss points! Following up on what was previously my discuss point (3), I still see MUST-level guidance to the expert in §7.5.2 to ensure that YANG items are assigned the same SIDs as in any other ".sid" file that has allocated SIDs for the YANG module in question. It seems prudent to qualify that on the YANG items having the same semantics as the already allocated SIDs and/or refer to the discussion in Appendix B from this location. Section 7.4.3 For a YANG module approved for publication as an RFC, a ".sid" file SHOULD be included in the Internet-Draft as a source code block. This ".sid" file is to be extracted by IANA/the expert reviewer and put into the YANG SID Registry (Section 7.5) along with the YANG module. The ".sid" file MUST NOT be published as part of the RFC: the IANA Registry is authoritative and a link is to be inserted in the RFC. Following up the "SHOULD be included in the I-D" with "is to be extracted and put into the YANG SID registry" leaves some ambiguity about what happens if the SHOULD is ignored (i.e., the ".sid" file is not in the draft). I think the intent is that something is created and still goes into the YANG SID registry, but that might be worth clarifying. I'm also a bit ambivalent about using "MUST NOT" for "don't include the ".sid" file in the RFC" -- it's generally the right thing to do, but who's it supposed to be binding on? With no enforcement mechanism, it might be easy to overlook, and what's the remedy if that happens? It also precludes any exceptional circumstance where we do feel a need to put the file contents in the RFC. Appendix A The ruby one-liner provided to extract JSON from Figure 3 is really evocative of the things people like to complain about perl code for. I don't really know any Ruby, but have to ask if the quoting+escaping is up to best practices for secure coding, and whether "\n" is going to properly match line endings on all OSes. [the following is retained from my previous ballot position] Section 7.4.2 In case a SID range is required before publishing the RFC due to implementations needing stable SID values, early allocation as defined in [BCP100] can be employed. As specified in Section 4.6 of [RFC8126], RFCs and by extension documents that are expected to become an RFC fulfill the requirement for "Specification Required" stated in Section 2 of [BCP100], which allows for the early allocation process to be employed. While the first bit of this is all true, the registry here doesn't use the "Specification Required" policy for any range, and early allocations are available for the "RFC Required" range. So we should probably tweak or remove the second sentence. [ed. the response to my previous ballot position pointed to PR 103 but I am failing to find a change that addressed this comment] From nobody Thu Dec 9 01:10:46 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B923A080B; Thu, 9 Dec 2021 01:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKuPKGmF6W1I; Thu, 9 Dec 2021 01:10:41 -0800 (PST) Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (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 C34EF3A080A; Thu, 9 Dec 2021 01:10:35 -0800 (PST) Received: from poseidon-mailhub.amsuess.com ([IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 1B99AR8H073265 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Dec 2021 10:10:27 +0100 (CET) (envelope-from christian@amsuess.com) X-Authentication-Warning: smtp.akis.at: Host [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd] claimed to be poseidon-mailhub.amsuess.com Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id DADCBD0; Thu, 9 Dec 2021 10:10:26 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:87f6:b42b:66ba:8c7f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A747978; Thu, 9 Dec 2021 10:10:26 +0100 (CET) Received: (nullmailer pid 660218 invoked by uid 1000); Thu, 09 Dec 2021 09:10:21 -0000 Date: Thu, 9 Dec 2021 10:10:21 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-ietf-core-oscore-key-update@ietf.org, core@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j+NifjOMXJucFIqk" Content-Disposition: inline Archived-At: Subject: [core] KUDOS and observations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 09 Dec 2021 09:10:45 -0000 --j+NifjOMXJucFIqk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Rikard, kept thinking about observation persistence after yesterdays's interim, hoping this gets us forward: There can be situations in which client and server disagree on whether an observation is still active. (There can be in theory, for a client can always send deregistrations and rely on the server to cancel all observations on the same resource (identified by roughly the cache key), but I think that's brittle both because it means clients can never stop an observation quickly). When the server starts using a security context, it needs to be sure whether to keep the observations on or not; if they are left on, it might immediately produce notifications referring to the previous context's sequence numbers. (If the server tried to track observations and cancel them when receiving that same sequence number again, that'd be pointless because the cryptographically matching responses would already be on the air). So it's up to the client to ensure non-reuse of still-acceptable sequence numbers (be it by longjumping or by skipping). The "p=EF=B8=A6" bit you described (it's not in the editors' copy, right?) = would probably go into the "x" field (limiting id_detail from 256 bytes to still unrealistic 128). Maybe we could take another bit off there that says "I'm making sure that my observations are good, you can keep sending me notifications of older observations even on the new key material". Servers that don't see this bit would stop any observations still on (any of) the old key(s). Whether the client then does longjumping, skipping or something else (maybe "I always use the first N sequence numbers for the semantically same requests so it's OK if they get reused", or "I have some long-running observations which I establish with my first N sequence numbers, and then longump only to N+1") is then up to the client. BR c PS: With this we *would* have a bit in the OSCORE optiojn that needs protecting. Possibly, "x || id-detail" could go into the key derivation rather than just id-detail. PPS: It may help to state clearly that servers may just stop all observations on rekeying if they don't expect them to be useful, this would allow constrained servers that don't need it to not do it. Then, even though observations are not guaranteed by transports to be kept alive anyway, another flag "I am indeed persisting observations" could be helpful, which a server that ignores the first bit just never sets. "Read as any, write as 0" should be a safe thing to do for any implementation. --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --j+NifjOMXJucFIqk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmGxx/kACgkQOY0REtOk veFE8Q/7B4OIPf9BfbzKElZW6Y9emYYsuEF6aZ6tixLpmSOtNWvIDeCay+UA5fU+ EOvE3kMdOLAMkfiVSn31sLeYw0FzOfHvOq9vrpsR64PQ/zmEwquauq32iXad51zN xLUEZDBySsmhRQraU5eRCCLYDtOWfyZDrnvPheQhRHXdwzYuxmi38R80WndQ1zJq RnZkRp5nIz5rx6+gYiwK+U2smiJugr2z6gVmoyyXgoVEbgiSnlN6tz0i1mJAfUS7 KCnZ0lnOwsG7d8S560Z8i7hrfz5UeXWbHlcJc+SNNUGrkf6RhqpqkowJC7GsmVta Km9tEnQMIaLcaXL1U3f9plTfIbL4GfGLiMafJ09K+STto79qPJoYOokY+tjvfR1A CjbemAPtqOY1kw3J6uA1q3627ZI2FR7nYJTtME9oPtxGfW8EyCxwn9cwW/qNQ9CO GJ9y2TN9lCqPhBaKtF7ljFMyAZBtOd/WFzfjcdBNMoW9btz1CB7TZWF1whLb6coq yEaT7baU6IctiSLxcycqwJLgxU0+ulJQFzOliR9ic3XVkoCRn8fXdmde/KC22obO WIGJ8E4CzKFrDAwsBZZRrGMHoTQUG4mKtfoZyv5IIOb15bln63FSOkSzy/lwpxg4 C7YWZ8q+AIkq1vPuSTeqNiMkLq7zA0PayDUqyfOiVFvECFemB5o= =5kN4 -----END PGP SIGNATURE----- --j+NifjOMXJucFIqk-- From nobody Sun Dec 19 19:43:26 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 180E03A0D75; Sun, 19 Dec 2021 19:43:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <163997180399.21184.16962217246463776502@ietfa.amsl.com> Date: Sun, 19 Dec 2021 19:43:24 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-yang-cbor-18.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, 20 Dec 2021 03:43:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : CBOR Encoding of Data Modeled with YANG Authors : Michel Veillette Ivaylo Petrov Alexander Pelov Carsten Bormann Michael Richardson Filename : draft-ietf-core-yang-cbor-18.txt Pages : 50 Date : 2021-12-19 Abstract: Based on the Concise Binary Object Representation (CBOR, RFC 8949), this document defines encoding rules for representing configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications, defined using YANG (RFC 7950). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-yang-cbor-18.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-yang-cbor-18 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sun Dec 19 19:50:49 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BBE3A0D8B; Sun, 19 Dec 2021 19:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZCyBFGMLYGCi; Sun, 19 Dec 2021 19:50:42 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8FD13A0D81; Sun, 19 Dec 2021 19:50:41 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JHQbf5kqKzDCcB; Mon, 20 Dec 2021 04:50:38 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <162635612227.22030.13513408024494659570@ietfa.amsl.com> Date: Mon, 20 Dec 2021 04:50:38 +0100 Cc: The IESG , draft-ietf-core-yang-cbor@ietf.org, core-chairs@ietf.org, core@ietf.org, Marco Tiloca X-Mao-Original-Outgoing-Id: 661665038.354174-bb976e0a70802e7def18f2194fcf7e37 Content-Transfer-Encoding: quoted-printable Message-Id: <096F7FFB-21FA-49A9-BFA3-FA6A5A6B4ECD@tzi.org> References: <162635612227.22030.13513408024494659570@ietfa.amsl.com> To: Robert Wilton X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Robert Wilton's Discuss on draft-ietf-core-yang-cbor-16: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2021 03:50:47 -0000 Hi Rob, here is finally the response to your feedback, based on yang-cbor-18: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-yang-cbor-17.txt https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-yang-cbor-18.txt > On 2021-07-15, at 15:35, Robert Wilton via Datatracker = wrote: >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks for this document, it is good work, and I think that there = specification > is almost there, but that the text could be tightened up in a few = places. >=20 > 1. The document should be clearer on its use of terminology around = schema > nodes. Mostly the encoding related to YANG data nodes, not YANG = schema nodes.=20 > I've provided more information in the comments section. Right. Neither schema node nor data node are the term we need most. We have introduced the term =E2=80=9Crepresentation node=E2=80=9D for = instances of schema nodes that turn up in representations. > 2. As also raised by Ben, this document should probably cover the YANG = data > structure extension in RFC 8791. This could potentially be done in = addition to > rc:yang-data, but perhaps better in its place. For the internal usage of YANG in the two drafts: We changed the ietf-sid-files module to use sx:structure. https://github.com/core-wg/yang-cbor/pull/116 This is about the documents=E2=80=99s *use* of rc:yang=E2=80=94data = migrating to sx:structure. As far as showing sx:structure examples with encoding from YANG-CBOR: We have introduced sx:structure as another representation node, = equivalent with container. This should cover all aspects of representing sx:structure. We do not plan to remove the support for rc:yang-data. > 3. Did the WG consider supporting encoding YANG metadata (RFC 7952)?=20= > Presumably this would be expected to be covered as future work? The design team did; we did not discuss this on the WG list. Supporting RFC 7952 metadata is a non-trivial effort, and we wouldn=E2=80=99= t want that as a late addition to the present document. We do plan to set up another document that defines the CBOR = representation of metadata, but not to include this in the present = document (or round of documents). > 4. How does the CBOR encoding of SIDs apply to YANG features? This = draft > references features and the SID draft allows SIDs for them, but I = don't > understand how they are used in the encoding (since features don't = appear in > the instance data, they are only at the schema level). YANG features can occur in the data of a YANG module, e.g., yang-library = (RFC 8525). Using a SID instead of an identifier for a feature allows a = compact representation. > 5. I also support Ben's second discuss point. I think that as = written, this > draft needs a normative reference to the SID draft. I don=E2=80=99t necessarily agree, but this is an easy change without = negative consequences. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 1. Abstract: > This document defines encoding rules for serializing configuration > data, state data, RPC input and RPC output, action input, action > output, notifications and the yang-data extension defined within YANG > modules using the Concise Binary Object Representation (CBOR, RFC > 8949). >=20 > When I read the abstract, it raises the question about what is left = out.=20 > Hence, I am wondering whether it wouldn't be better to just describe = it as > encoding YANG data tree instance data. However, I see that the = description > effectively mirrors the abstract for the YANG JSON encoding (RFC = 7951), so it > is at least consistent. We discussed this and do want to stay consistent with RFC 7951. > 2. I find this document (along with the SID draft), somewhat confusing = in that > it references YANG schema nodes, but in most cases, it probably only = cares > about the subset of YAND schema nodes that represent itemsthat are = present in > data tree instantiation. RFC 7950 calls such 'schema nodes' as 'data = nodes'.=20 > For example, 'choice', 'case', 'input' and 'output' exist as nodes in = the YANG > schema tree, but are not data nodes and don't appear as instantiated = data nodes. The representation may also include information about schema nodes for = action, rpc, input, output, and notification. We introduced a new term, = representation node, for this subset of schema nodes (see above). > Where this causes problems are in the definitions of: 'child' - (e.g., = 'case' > cannot be a child of a 'container' only a child of a 'choice', and = equivalently > for the definition of 'parent'. This definitions are not heavily used = and > could perhaps be removed? We removed the definition of =E2=80=9Cchild=E2=80=9D, as it was used in = only one place and that could easily be substituted by =E2=80=9Cschema = node defined within=E2=80=9D. We left the term =E2=80=9Cparent=E2=80=9D, as this is used seven times, = and clarified it to mean The schema node of the closest enclosing = representation node. > Hence my suggestion to clarify the text are: > - potentially import and use data node rather than schema node. Note = that > data node, as defined in RFC 7950, is a subset of schema nodes, so you = still > need the text saying an instance of a data node. =20 We do import data node and already used it occasionally in -16. By the way, in the whole of YANG, I can only find RFC 7952 that ever = talks about an =E2=80=9Cinstance of a data node=E2=80=9D, so I=E2=80=99m = a bit reluctant to use that terminology throughout =E2=80=94 any problem = with using =E2=80=9Cdata tree node=E2=80=9D? > Arguably, the RFC 7950 > definition of a data node is somewhat confusing. - please check = everywhere > where 'schema node' or 'data node' turns up in the text to ensure that = you are > referencing instances of that schema node rather than the schema node = itself.=20 > E.g., the second paragraph in section 3 states 'where each child = schema node > is encoded ...', but this should be an instance of child schema node. = - ensure > that if you are referring to the parent or child of a 'schema node' = that the > logic skip out the schema nodes that don't get encoded in the data = tree.=20 > E.g., when calculating SIDs. This was covered by introducing the term =E2=80=9Crepresentation node=E2=80= =9D discussed above; please see updated introduction to Section 3. > 3. I think that some of the references to submodules are not quite = right.=20 > Basically, the CBOR encoding should not need to concern itself about = submodules > at all, since logically, it works with the module schema (which = logically > incorporates the submodules). E.g., perhaps you could mention this in = the > introduction, referencing section 4.2.1 (4th paragraph in particular) = of RFC > 7950? >=20 > Hence: > In section 2: > * item: A schema node, an identity, a module, a submodule, or a > feature defined using the YANG modeling language. >=20 > I think that this should exclude submodule (and possibly feature as = well). Submodule is mostly gone from -18, except for paragraphs such as: >> Note that any structuring of modules into submodules is transparent = to YANG-CBOR: >> SIDs are not allocated for the names of submodules, and any >> items within a submodule are effectively allocated SIDs as part of >> processing the module that includes them. > In section 3.2: > YANG modules, submodules, and features >=20 > I don't think that you want submodules in this list (and perhaps not = features > either). Indeed, we removed all instances of =E2=80=9Csubmodule=E2=80=9D in lists = of nodes. (See also reply to =E2=80=9Cfeatures=E2=80=9D above.) > And in: > 6.13.1. SIDs as instance-identifier >=20 > SIDs uniquely identify a schema node. In the case of a = single > instance schema node, i.e., a schema node defined at the root = of a > YANG module or submodule or schema nodes defined within a = container, > the SID is sufficient to identify this instance. >=20 > I would remove "or submodule" from this text. Effectively, the text = about > modules already covers this. (See above.) > 4. Please check the text that describes how lists are encoded. = Section 4.2 > seems to suggest that they are encoded as a CBOR Map, section 4.4 = states that > they are encoded as an array. I presume that the answer is that they = encode > the list is an array, and each list entry is a Map. We now consistently use =E2=80=9Clist entry=E2=80=9D (Section 7.8 of RFC = 7950) for representation nodes that form a list. > 5. > Values of 'bits' types defined in a 'union' type MUST be encoded > using a CBOR text string data item (major type 3) and MUST contain a > space-separated sequence of names of 'bits' that are set >=20 > It might be helpful to have a quick sentence to justify why this is = done. We added references to the section 6.12 in 6.6 and 6.7. We added some explanation in 6.12. Fully explaining the unfortunate idiosyncrasy is a bit beyond the scope = of this specification, though. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 20 01:40:34 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B80B3A0788 for ; Mon, 20 Dec 2021 01:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 O5HQdba-c52U for ; Mon, 20 Dec 2021 01:40:24 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE62B3A078D for ; Mon, 20 Dec 2021 01:40:22 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JHZM641gVzDCm8; Mon, 20 Dec 2021 10:40:18 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Mon, 20 Dec 2021 10:40:18 +0100 Cc: "t2trg@irtf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 661686018.002265-b39d317f38754abfc304e79ad978ac26 Content-Transfer-Encoding: quoted-printable Message-Id: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> References: To: "Apple Inc." X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] Quick Doodle T2TRG security topics (Re: [T2TRG] New topic for T2TRG?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 20 Dec 2021 09:40:30 -0000 I assume most people are mostly in holiday mode already. We did want to have a chat this year about setting up a T2TRG activity = around research issues in securing IoT (tentatively called = =E2=80=9Cseccore=E2=80=9D), similar to WISHI, but probably with a = different core group of people attending. Some background for that in G=C3=B6ran's mail cited below. I have put up 9 potential meeting slots this week: https://doodle.com/poll/7e76k335hd6d28k3 If you are interested, please choose slots you can still make. I plan to close this COB US today, so please click quickly. This week=E2=80=99s meeting is mostly for planning and, first and = foremost, discussing the scope we want to communicate. The actual first meeting of a seccore activity would probably then be in = 2022W2, but that is one of the things we want to discuss this week. That link was https://doodle.com/poll/7e76k335hd6d28k3 ... Gr=C3=BC=C3=9Fe, Carsten > On 2021-11-29, at 17:15, G=C3=B6ran Selander = wrote: >=20 > Dear T2TRG, > =20 > As reported from the CoRE applications side meeting below, there seems = to be an interest in progressing topics in the area of security for = constrained RESTful environments, and a proposal to host that work in = T2TRG. > =20 > * What? > =20 > CoAP can be used in various settings beyond simple REST. How do we = adapt existing security requirements and solutions to these new modes of = operation? Some work of this kind is already in progress in the IETF but = some issues go beyond the individual IETF WGs, or could benefit from = additional contributions from a wider audience, reviews and information = sharing. > Examples include: > - Rekeying with PFS vs. stateless operations [2] > - Firmware updates using group communication > - Efficient and secure tunnelling of CoAP in CoAP > - Notifications surviving rekeying > - Progressing pub-sub with CoAP > =20 > =20 > =20 > * Why? > =20 > To progress applications of CoAP in different security settings which = "touch standardization in the IETF" [1] but are not necessarily in scope = of a single working group like CoRE, ACE, SUIT, COSE, LAKE, etc. > =20 > =20 > * How? > =20 > Through a "sister" of WISHI: A recurring meeting series under the = T2TRG umbrella about topics on security for constrained RESTful = environments. Working name: seccore (which apparently may mean "dryness" = in some Italian context; not intended as a characterization of the = content :-) Frequency and topics open for discussion. > =20 > =20 > * Comments? > =20 > What do people think? > =20 > Should we try to have a first meeting before the upcoming holiday = season? > =20 > =20 > G=C3=B6ran > =20 > [1] Thing-to-Thing (t2trg) - (ietf.org) > [2] [core] KUDOS, PFS and operations considerations (ietf.org) > =20 > =20 > =20 > From: core on behalf of Christian Ams=C3=BCss = > Date: Tuesday, 16 November 2021 at 15:57 > To: core@ietf.org > Subject: Re: [core] CoRE applications side meetings (pubsub / = dynlink)? >=20 > Hello, >=20 > On Tue, Nov 09, 2021 at 05:17:39PM +0100, Christian Ams=C3=BCss wrote: > > based on the feedback that arrived, a small group will meet tomorrow > > (Thursday) 10:00 UTC in the hackathon area to look through some > > applications (pubsub, problem-details), possibly doing examples or = check > > out how things align with current CoRAL. >=20 > the small group was not all that small and very lively -- thanks > everyone for participating! >=20 > I've attached the minutes here in case the pad we used[1] goes away. >=20 > While we figure out how to best make more of the CoRE ecosystem = publicly > visible at coap.technology, we can already start collecting material = at > the wiki[2]. >=20 > Best regards > Christian >=20 > [1]: https://notes.ietf.org/GaM_PWd2TnmY0DrTe6DdQA?view > [2]: = https://protect2.fireeye.com/v1/url?k=3Df4bbca08-ab20f04d-f4bb8a93-867b36d= 1634c-1b783ca428431080&q=3D1&e=3Da3621d21-f226-4875-acd7-faaf5c694f88&u=3D= https%3A%2F%2Fgithub.com%2Fcore-wg%2Fwiki%2Fwiki >=20 > --=20 > To use raw power is to make yourself infinitely vulnerable to greater = powers. > -- Bene Gesserit axiom From nobody Mon Dec 20 06:54:59 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5643A0E4F for ; Mon, 20 Dec 2021 06:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5L-hFRdjj5o for ; Mon, 20 Dec 2021 06:54:32 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2838C3A0E4D for ; Mon, 20 Dec 2021 06:54:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 29967395C5; Mon, 20 Dec 2021 09:58:59 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Aig8RFFuwsVx; Mon, 20 Dec 2021 09:58:56 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C8E20395C4; Mon, 20 Dec 2021 09:58:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1640012336; bh=G63QeZHdBT8zrz36rWLU2m7NBZnqu5F7OUguEwUuEc4=; h=From:To:Subject:In-Reply-To:References:Date:From; b=Xxc9wesnC3+6qHWqcSgmpLhZIToFJLHVM6X3khncXNGrjXX8xDe5BQSe4lWJd7ZUL 7Tr/cFo4lX4M09A81DunxuWoIjWOWA0Yk6BdW3mVfMP5HgnZv3FcPyn+nL5SezxxNG iJu7XS5potmfiyh7njP38J1ely2r4HAenGhoBfXuPic0JZRJyIdN+yDEeM2j1OkAix yNghaefTNCOIVWwm8fvH3eb0TZktgcP1YnHcUr8feFHU4jCYo7phBKK7O0Zl6eWzLk zLjI7eOFy9yTEWTq8Ef7jue+/czsCmEyZkslDnrJgAqPOViEHMxp4YojY0sHX6kX6N wWIgoPueyCMaQ== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4E62898E; Mon, 20 Dec 2021 09:54:27 -0500 (EST) From: Michael Richardson To: Carsten Bormann , goran.selander@ericsson.com, "t2trg\@irtf.org" , "core\@ietf.org" In-Reply-To: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> References: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] Quick Doodle T2TRG security topics (Re: [T2TRG] New topic for T2TRG?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 20 Dec 2021 14:54:37 -0000 Carsten Bormann wrote: > I assume most people are mostly in holiday mode already. a bit. > I have put up 9 potential meeting slots this week: > https://doodle.com/poll/7e76k335hd6d28k3 I have mutable plans Tuesday, but I could be persuaded to change them. > This week=E2=80=99s meeting is mostly for planning and, first and for= emost, > discussing the scope we want to communicate. > The actual first meeting of a seccore activity would probably then be > in 2022W2, but that is one of the things we want to discuss this week. Understood. >> CoAP can be used in various settings beyond simple REST. How do we >>adapt existing security requirements and solutions to these new modes= of >>operation? Some work of this kind is already in progress in the IETF = but >>some issues go beyond the individual IETF WGs, or could benefit from >>additional contributions from a wider audience, reviews and informati= on >>sharing. >> Examples include: >> - Rekeying with PFS vs. stateless operations [2] >> - Firmware updates using group communication >> - Efficient and secure tunnelling of CoAP in CoAP >> - Notifications surviving rekeying >> - Progressing pub-sub with CoAP I guess this is really CoAP focused around OSCORE :-) I'm not saying this is a problem, but it certainly explains "seccore" as a = name. If we produced a few roadmaps (or a less interestingly, a roadmap with a few options), which explained some specific choices, I think that would be useful. I think that two or three Informational RFCs would be appropriate. I prefer multiple RFCs rather than one RFC with three sections in order to make procurement clearer. -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Mon Dec 20 07:54:11 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99063A0F16 for ; Mon, 20 Dec 2021 07:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiU2eTbNVdHJ for ; Mon, 20 Dec 2021 07:54:02 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp2059.outbound.protection.outlook.com [104.47.2.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 6DE1C3A0D9A for ; Mon, 20 Dec 2021 07:54:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mHAy4HgvVLt8+YAepRwY1hkDejrAkal70CB3Nza8AeRg6zF5aYREbUaKpjj6KpvNTuBmq7B+4IM6Uv2OFeA81VDxzbDRDqDHUl7VPfuJn6LIjbamYDFc4nwNoq/y54tEN+k2Wsn6b2DeFlOYijfc20xTaVEBdHcc1LHFAoA3c1aoElKlctm2hVI3RdasX6/A0AcL1jm1mJqMnZCb26xM3vxk1yCxbt5VMAOA2StMy+Ims+R8kFILYiTfRtcWSLatrXLgnSEm7F3TNhcEPYOgEaKP2ex0lRjHQ2oGuyUHDWF7uz5K+K3W5GPdJ/TIA8oeJYHnN4brCvg8fnvruX2Uyw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3mtdXnuZtbR9BOWEm5792IUKGeaIlMWTYPvQCICz+u8=; b=l59gxpd/z5FmFW5jMlxnsLKSO67YsninEO/rPlk5PUYmtcifktPuJd5YTJDdkQasvqiP369r08tjWtr6pVZLup/qWuWGcNbYI+2zsDAkRNxWj512cxJV4Br1+eQS2pdfxHnmxY8bKu60K3OnSJRXOshTFLtnxJvkb32GUYBHIjz86iwJ/qie6VT9Uk/xmp9xZkxqt5P7bTlZVPCbkeuLOMwRvViMv2NUI97mHRCBgMHtzOeEUShk5XO1s2tgWaBh3kV6B7Cpgf8bfayLlZLSVHLhTApAQBgaWSxELhHuxkZ8bFxCz2527tLMN7tWZzGE8wLEJjG58WOw4lgZ6uKGhA== 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=3mtdXnuZtbR9BOWEm5792IUKGeaIlMWTYPvQCICz+u8=; b=skRymqW272eTrV9bPwILrVCSPdNy+lPAsdEGYDpyZ8vKpZVsDRdqFK9Hrkc2sGtxTLw24DCDysXkcW7YRCOhP+1lkyU2v/QtsGD5KD8lOqYMI3KO9p11ZlitswoiOKLtywt9AqomWIgH8oC7YwJ5azcX+GJltPUvXu58QsGv4jI= Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com (2603:10a6:200:45::6) by VI1PR07MB3296.eurprd07.prod.outlook.com (2603:10a6:802:23::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4823.14; Mon, 20 Dec 2021 15:53:58 +0000 Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b]) by AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b%4]) with mapi id 15.20.4823.014; Mon, 20 Dec 2021 15:53:58 +0000 From: =?Windows-1252?Q?G=F6ran_Selander?= To: Michael Richardson , Carsten Bormann , "t2trg@irtf.org" , "core@ietf.org" Thread-Topic: [core] Quick Doodle T2TRG security topics (Re: [T2TRG] New topic for T2TRG?) Thread-Index: AQHX9YWfUbDLzPibKEGO3FVg10ZGi6w7d+yAgAAJzuA= Date: Mon, 20 Dec 2021 15:53:58 +0000 Message-ID: References: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> <25576.1640012067@localhost> In-Reply-To: <25576.1640012067@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7c46c160-e0cf-495e-cf81-08d9c3d0ef56 x-ms-traffictypediagnostic: VI1PR07MB3296:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yTDMOGzKZSpVzKSRXrVqnWpLSduIgJinXNBSkf18IpIHxDxRyh2j5ftf/DzZbb5P6kgnKXyrop+7Tkh3QtDNrCSlbLDUKuoXS931Gp554BwETlqb7jDr+2tZ7XqL0PcZO8FEOqPlg2aIfpu+gGpMlqkbGABr6dUL8ghqbUDmjfB4KKhC94gQy+jsbIeCrgncvd5b+Wvs/qZ4Fb0pOwK3KqFf1xa5DgNjKIbrPRB5MxotWMwrW0O9LIFFZ9n13FGjGSDO+V15B/+ddJM0Lizpss+qqWmeCS8VQHgadIwMds5IsXmvMSqR7ZtQxCg0zscMYwf3J5CsWY+/NxnOW8Me8amdeli4Z9vfesH++3ClnJ+L4FJvUoGtscXDb9BOBldDGX26dSoxfx3K0VVX5d59WKlje0wqesu/BH9nkBpi2BtaydB40gslPAC2aTriL+QEE9X+S7nn2Gc+WjaZR4OcZqMwvKkA/7+xzB0EBYCugifNr9iM18rpSB6cuzZC2J9IWsR35TZXtdgPdQGpepX/mIukOSYih+1Bazpy8we22gvaWMLn+pXA+3uZnJ6C/xYwjhfkkQtxkSUN0EffiKSEprRbvvPPQ+53CLurRMVbgUt8wQUBzSTnUq2L7AZbejX3SgXaK84uzxZHDdaGqSuT1qV8kc+B5ZCbKKsdN1LeWaLHubmE0jjOdz37lNA5doVCfKLiA84LyeSr3H3b/z74iqG6IDlJW6N4ohKZOWKOrfQwhrq5aKlOvdSndGbl4hMvGbC1kOtgFbfk6TkXlJD4919394w4tgPfrkK71vf+1R6UzIP7nMH5/PT/iCxtObeu65d+o8i2PSS0eTinAzmp+A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM4PR0701MB2195.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(7696005)(6506007)(38070700005)(64756008)(71200400001)(66556008)(86362001)(66476007)(66446008)(52536014)(66946007)(76116006)(91956017)(8936002)(83380400001)(316002)(110136005)(66574015)(55016003)(8676002)(966005)(508600001)(9686003)(166002)(38100700002)(122000001)(26005)(186003)(82960400001)(33656002)(15650500001)(2906002)(5660300002)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?U7wdF0bhtrWfV6G63rvHrukouqX41uuOV3RLkmswSJmOtRwzdQ+7xH1Q?= =?Windows-1252?Q?n0kK0yYT697c05q83GbbgCdYVFydn3CT+8J1winFp6hRLW3HCm1GU96C?= =?Windows-1252?Q?B3bpAUeCXcQSFseWtpdjffh6295FWoZmSpXJmzZSfpJ7An0TbansMteo?= =?Windows-1252?Q?XTPhf9U3AdVHKtzd4j5v+XfwAZSXVbMYqweMyOnwI2rq+j+Ttxnm26ok?= =?Windows-1252?Q?uCBP7zj668EX3HXtDyaEgY4lEbxlBMGUd+6sfdHdWeB3bYiyWc9T84pi?= =?Windows-1252?Q?h60Dm4Xqma2/Z6sA6QMjfKShalsX3Czj0aSXHaobbDnW87BGAtIndj9G?= =?Windows-1252?Q?/ITjXUgsVrrSye7kN/sEQ2CAIcW4ok5QYuxE1do06srQ/LKhlg3AVnaV?= =?Windows-1252?Q?T6PmxsFaNfdCf/DbOTPje6sFGIc5naI+7ZnV41m9rUwhkZxwvovwKbfp?= =?Windows-1252?Q?Y8Q18j0XuMWyxJkW7klki4OSITXCvnXejAf9CYRB/v+4hzqx8edp6WNO?= =?Windows-1252?Q?dyHDrod+gGx6O6y9AnTQKyrGJ7ABlJJOBD4quuGM50nKgp6YHRVyMh5C?= =?Windows-1252?Q?2HnuMUJykVrM+q0VzReyo32R2Q3Es2EcfcZm50AjsYRbzXhte0F03Z6j?= =?Windows-1252?Q?u83VtCiyjTZdyZv6nbFHOmrpvOPSCEwmPeRB3tYYK0hjWw5KR47joytZ?= =?Windows-1252?Q?Mpdr3NBSXkFNGYdtdFgJ9E6ROjPUafDSnt3QFmfCtYlq9UA1fBFsclZu?= =?Windows-1252?Q?Xz7WYkP+4obydVUKoN6Qx24QQx2qHxJe6Lgldz9N9VsBaqojDBNhQP24?= =?Windows-1252?Q?bOtw9M8H1cGc5C2NjFcWK4scVcBfoyZstf/gJ0z8i5hg32UMX1QPpc55?= =?Windows-1252?Q?YadGdTn28fXpu8SCV2/le4UbzUhe10P7Gxp66fmnRIHWS48obUD8CRrx?= =?Windows-1252?Q?LVMpc8DjOUnW+CBjuBas4CmzHfmWIyjH2QmFOLOSztRUtKpL2ZS9NYKp?= =?Windows-1252?Q?PyicJqh/9s6YfhKh2wuqKY+2gfLe0zhQW7dXlBx764T2gsYzhFczuMl1?= =?Windows-1252?Q?umDZ7d115gRv2kesSMm9k2naZYCX0CjQWCagQqLfo/0LyPSIuc7QirGt?= =?Windows-1252?Q?bvMTJIlRuFyWb6p+1Ae/EceduAt9x01depbvw6BDrEqDAsKLxcrLD+D7?= =?Windows-1252?Q?3BSr73TWbou4Cij8/e5ypipT6C7f2AOeJW6EEuRcZLzD0cN5PXA85Mal?= =?Windows-1252?Q?q3TyO36y0N4+SMWl+69etK/fLZqsHkRBxrD0uu9yjDJ0uWxXnlVwHXue?= =?Windows-1252?Q?8Ts2uQX7EW9/c/5jZs/hkp7wwUfFQ0pmYLlKbPDRiju/EFQOdQglA+SH?= =?Windows-1252?Q?SYfKS/YqhVB0/caSimoZ1m3cciEvd0p+UcTminHt6cRhCxY7LYAFcAwF?= =?Windows-1252?Q?mZqmKeoVT5BzbA0SmrCrWQz1HREnsAKP7uaEZThd4UvnMF5PlRx9N92I?= =?Windows-1252?Q?HvKmM5C8UOmOk+A6z+a5LQadxL1S570pbxHDon8bku/KjB/tFc8ADV8j?= =?Windows-1252?Q?PhK0ELxzSsXF22Dvnpvm+BYWVEF1HBvGOi6j85PbT8k1j65MqLGse56R?= =?Windows-1252?Q?C7bbSJA2aJnKar2rhl0FrkjjWS8kR+rXyGO47Vxcqklb5HJlN09Ya3v6?= =?Windows-1252?Q?KTSeo3W8xPs8OtDT2OWbohwMeXJe6Qs5ktbsCV2MMtyOjdwDkQ6O/nwL?= =?Windows-1252?Q?jHpBjW4bFuj/K4y9oPp+WUe8u+djZ0hhbX6wKbNwH0V3PbXf/dCsEsW8?= =?Windows-1252?Q?QyiZ0uwH8i8/EJVmFNQnnvL99D8=3D?= Content-Type: multipart/alternative; boundary="_000_AM4PR0701MB2195A52DA79B1E88364BCAD7F47B9AM4PR0701MB2195_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM4PR0701MB2195.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7c46c160-e0cf-495e-cf81-08d9c3d0ef56 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2021 15:53:58.5068 (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: zySsvTu6CBMgxOOcjXdiG1OTr//gRAVyQY5zwkLLdU52zbgKxQpVo+3snIPbPkR6bDhxgbgdawZw4p5lef7gPAIOH0OB9jmrH8ZetWWaT4Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3296 Archived-At: Subject: Re: [core] Quick Doodle T2TRG security topics (Re: [T2TRG] New topic for T2TRG?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 20 Dec 2021 15:54:08 -0000 --_000_AM4PR0701MB2195A52DA79B1E88364BCAD7F47B9AM4PR0701MB2195_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Michael Richardson Carsten Bormann wrote: > I assume most people are mostly in holiday mode already. a bit. > I have put up 9 potential meeting slots this week: > https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-313273af-45= 4445555731-7e45b11ea3df9a0f&q=3D1&e=3Dd35fe755-7487-44c5-97d7-2f7f0d483c98&= u=3Dhttps%3A%2F%2Fdoodle.com%2Fpoll%2F7e76k335hd6d28k3 I have mutable plans Tuesday, but I could be persuaded to change them. > This week=92s meeting is mostly for planning and, first and foremost, > discussing the scope we want to communicate. > The actual first meeting of a seccore activity would probably then be > in 2022W2, but that is one of the things we want to discuss this week= . Understood. >> CoAP can be used in various settings beyond simple REST. How do we >>adapt existing security requirements and solutions to these new modes= of >>operation? Some work of this kind is already in progress in the IETF = but >>some issues go beyond the individual IETF WGs, or could benefit from >>additional contributions from a wider audience, reviews and informati= on >>sharing. >> Examples include: >> - Rekeying with PFS vs. stateless operations [2] >> - Firmware updates using group communication >> - Efficient and secure tunnelling of CoAP in CoAP >> - Notifications surviving rekeying >> - Progressing pub-sub with CoAP I guess this is really CoAP focused around OSCORE :-) I'm not saying this is a problem, but it certainly explains "seccore" as a = name. [GS] The scope is for discussion but the proposal is security in settings m= aking use of CoAP, and to start with the problem rather than specific solut= ions. "seccore" is some sort of abbreviation of "security in constrained RE= STful environments". If we produced a few roadmaps (or a less interestingly, a roadmap with a fe= w options), which explained some specific choices, I think that would be useful. I think that two or three Informational RFCs would be appropriate. I prefer multiple RFCs rather than one RFC with three sections in order to make procurement clearer. [GS] Maybe someone else thought about roadmaps, I was more thinking about c= oncrete problem statements. If the outcome is a T2TRG draft or a new IETF W= G draft (or neither) may depend on the problem. G=F6ran --_000_AM4PR0701MB2195A52DA79B1E88364BCAD7F47B9AM4PR0701MB2195_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

 

 

From: Michael Richardson = <mcr@sandelman.ca>

Carsten Bormann <cabo@tzi.org> wrote:
    > I assume most people are mostly in holiday mode alr= eady.

a bit.

    > I have put up 9 potential meeting slots this week:<= br>     > https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-313273af-45444555= 5731-7e45b11ea3df9a0f&q=3D1&e=3Dd35fe755-7487-44c5-97d7-2f7f0d483c9= 8&u=3Dhttps%3A%2F%2Fdoodle.com%2Fpoll%2F7e76k335hd6d28k3

I have mutable plans Tuesday, but I could be persuaded to change them.

    > This week=92s meeting is mostly for planning and, f= irst and foremost,
    > discussing the scope we want to communicate.
    > The actual first meeting of a seccore activity woul= d probably then be
    > in 2022W2, but that is one of the things we want to= discuss this week.

Understood.

    >> CoAP can be used in various settings beyond sim= ple REST. How do we
    >>adapt existing security requirements and solutio= ns to these new modes of
    >>operation? Some work of this kind is already in = progress in the IETF but
    >>some issues go beyond the individual IETF WGs, o= r could benefit from
    >>additional contributions from a wider audience, = reviews and information
    >>sharing.
    >> Examples include:
    >> - Rekeying with PFS vs. stateless operations [2= ]
    >> - Firmware updates using group communication     >> - Efficient and secure tunnelling of CoAP in Co= AP
    >> - Notifications surviving rekeying
    >> - Progressing pub-sub with CoAP

I guess this is really CoAP focused around OSCORE :-)
I'm not saying this is a problem, but it certainly explains "seccore&q= uot; as a name.

[GS] The scope is for discussion but the proposa= l is security in settings making use of CoAP, and to start with the problem= rather than specific solutions. "seccore" is some sort of abbreviation of "security in constrained RESTful envi= ronments".

If we produced a few roadmaps (or a less interestingly, a roadmap with a fe= w
options), which explained some specific choices, I think that would be
useful.
I think that two or three Informational RFCs would be appropriate.
I prefer multiple RFCs rather than one RFC with three sections in order to<= br> make procurement clearer.

[GS] Maybe someone else thought about roadmaps, = I was more thinking about concrete problem statements. If the outcome is a = T2TRG draft or a new IETF WG draft (or neither) may depend on the problem.

G=F6ran

 

--_000_AM4PR0701MB2195A52DA79B1E88364BCAD7F47B9AM4PR0701MB2195_-- From nobody Mon Dec 20 08:29:45 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04443A1067 for ; Mon, 20 Dec 2021 08:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 nz1ZS5eDrRIC for ; Mon, 20 Dec 2021 08:29:40 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D666C3A1066 for ; Mon, 20 Dec 2021 08:29:39 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1mzLXZ-0006Le-Vy for core@ietf.org; Mon, 20 Dec 2021 16:29:34 +0000 From: To: Date: Mon, 20 Dec 2021 16:29:40 -0000 Message-ID: <269201d7f5be$c94dcef0$5be96cd0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2693_01D7F5BE.C94EB950" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Adf1vshJNGc75PGbQqaRUljVR+kGug== Content-Language: en-gb Archived-At: Subject: [core] draft-ietf-core-echo-request-tag -14 and Block2 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 20 Dec 2021 16:29:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_2693_01D7F5BE.C94EB950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, I have run into an issue where multiple CoAP requests (not needing Block1) to the same resource trigger potentially different responses that require the use of Block2. If the responses overlap, then there is confusion as to how to pull back the correct response to match the request. For example (grossly simplifying things) POST /api//read payload = { 'offset': 0, 'count': 1200 } POST /api//read payload = { 'offset': 2000, 'count': 1300 } Or FETCH /api//read payload = { 'offset': 0, 'count': 1200 } FETCH /api//read payload = { 'offset': 2000, 'count': 1300 } RFC7959 2.4 rightly states The Block2 Option provides no way for a single endpoint to perform multiple concurrently proceeding block-wise response payload transfer (e.g., GET) operations to the same resource. This is rarely a requirement, but as a workaround, a client may vary the cache key (e.g., by using one of several URIs accessing resources with the same semantics, or by varying a proxy-safe elective option). Which then brings in the possible use of Request-Tag option in the request as a proxy-safe elective option. However. draft-ietf-core-echo-request-tag -14 3.2 states The Request-Tag option is only used in requests that carry the Block1 option, and in Block2 requests following these. Which implies that the examples above need to contain the Block1 option in the first instance if there is any suspicion that Block2 is needed in the response. Then draft-ietf-core-echo-request-tag -14 3.4 states Note that Request-Tag options can be present in request messages that carry no Block option (for example, because a Request-Tag unaware proxy reassembled them), and MUST be ignored in those. Apart from being hard to parse (what does "those" refer to?), this tells me that Servers MUST ignore requests that have no Block option - so, I cannot just add the Request-tag option to a request on the off-chance there may be a Block2 needed response. Is there a good reason for this MUST? If it is too late for the draft to be updated, the only easy way forward that I can see is to add in an unneeded Block1 to the request, or to add in a Block2 option to the request so the Request-Tag can be used even if the response fits into a single payload. I have raised this as Issue #77 https://github.com/core-wg/echo-request-tag/issues/77 . Regards Jon ------=_NextPart_000_2693_01D7F5BE.C94EB950 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = there,

 

I have run into an issue where multiple CoAP requests = (not needing Block1) to the same resource trigger potentially different = responses that require the use of Block2. If the responses overlap, then = there is confusion as to how to pull back the correct response to match = the request.  For example (grossly simplifying = things)

POST = /api/<service>/read   payload =3D { 'offset': 0, = 'count': 1200 }

POST /api/<service>/read   =
payload =3D { 'offset': 2000, 'count': 1300 =
}
Or

FETCH = /api/<service>/read   payload =3D { 'offset': 0, = 'count': 1200 }

FETCH =
/api/<service>/read   payload =3D { 'offset': 2000, =
'count': 1300 }
 <=
/o:p>

RFC7959 2.4 rightly = states

   The Block2 Option = provides no way for a single endpoint to perform

   multiple concurrently proceeding = block-wise response payload transfer

   (e.g., GET) operations to the same = resource.  This is rarely a

   requirement, but as a workaround, a = client may vary the cache key

   (e.g., by using one of several URIs = accessing resources with the same

   semantics, or by varying a proxy-safe = elective option).

 

Which then = brings in the possible use of Request-Tag option in the request as a = proxy-safe elective option. However.

draft-ietf-core-echo-request-tag -14 3.2 = states

   The Request-Tag = option is only used in requests that

   carry the Block1 option, and in Block2 = requests following these.

 

Which = implies that the examples above need to contain the Block1 option in the = first instance if there is any suspicion that Block2 is needed in the = response.

 

Then draft-ietf-core-echo-request-tag -14 3.4 = states

   Note that = Request-Tag options can be present in request messages = that

   carry no Block = option (for example, because a Request-Tag unaware

   proxy reassembled them), and MUST be = ignored in those.

 

Apart from = being hard to parse (what does “those” refer to?), this = tells me that Servers MUST ignore requests that have no Block option = – so, I cannot just add the Request-tag option to a request on the = off-chance there may be a Block2 needed response.

 

Is there a = good reason for this MUST?

 

If it is too = late for the draft to be updated, the only easy way forward that I can = see is to add in an unneeded Block1 to the request, or to add in a = Block2 option to the request so the Request-Tag can be used even if the = response fits into a single payload.

 

I have = raised this as Issue #77 https://gi= thub.com/core-wg/echo-request-tag/issues/77 .

 

Regards

 

Jon

------=_NextPart_000_2693_01D7F5BE.C94EB950-- From nobody Mon Dec 20 09:23:02 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA193A110A for ; Mon, 20 Dec 2021 09:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOl1N53ADOID for ; Mon, 20 Dec 2021 09:22:54 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54CE93A1100 for ; Mon, 20 Dec 2021 09:22:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 505A93917B; Mon, 20 Dec 2021 12:27:21 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xfw92if81Lga; Mon, 20 Dec 2021 12:27:20 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2577339033; Mon, 20 Dec 2021 12:27:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1640021240; bh=jvQU7h66SqEO8LHiaiURIYU5CrE/rCUETn74h1qAUUE=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=hPD0UPpuOH2zksSPYEh5e3JFh/EoX+BZkV9/nb+6vpLeZVvR7RQ0ZrsH7jg1EUI2O f6vz4SaJgWhI4lqUnpwQqPEXuH6xsPTWA+Ke8sVCuGCI09byukAp3xOQegGr6ER4iU s8mtcYNFwUe1boWbc4u6Z/Xx6Vd5BZ2k5XLuqIJJxyiR+XDcZmXcIYIXADMuGhbAHN 2uP3ApTMOKuoDRFtf/rvrNS2UNa/QvSK98WFfT8hK/XiUDR78E8EmQETPpl002poO+ GQ/70zwGxXG5IvsS5UotMZ5CWY/smLUX4XqZXjD4C80zfTgQ80ZP6Ikqe0hIpQPX91 YQHaDUZY+Z1Wg== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4068A1A25; Mon, 20 Dec 2021 12:22:50 -0500 (EST) From: Michael Richardson To: =?us-ascii?Q?=3D=3FWindows-1252=3FQ=3FG=3DF6ran=5FSelander=3F=3D?= cc: Carsten Bormann , "t2trg\@irtf.org" , "core\@ietf.org" In-Reply-To: References: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> <25576.1640012067@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] Quick Doodle T2TRG security topics (Re: [T2TRG] New topic for T2TRG?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 20 Dec 2021 17:23:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable G=C3=B6ran Selander wrote: GS> Maybe someone else thought about roadmaps, I was more thinking about GS> concrete problem statements. If the outcome is a T2TRG draft or a n= ew GS> IETF WG draft (or neither) may depend on the problem. I think of a document that says: When you have condition1,condition2,condition3, then a solution like: RFCXXXX suite 1, with RFCYYYY section 4, and use of RFCZZZZ ... would make sense. So, I think that the first part of the document is definitely a problem statement, or perhaps more correctly called an applicability statement. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmHAu+kACgkQgItw+93Q 3WXdtQgAqS88iOXvWd/Lhvg7txlTb7o1/TdoAdA+m7E/OgZ/i33J1M/CXI2q5wIx NriUCL+S4EPlmxPszH1FQbDEZRAY24toUnwmWfh9rI7bl0PRtn7lySL+Vs7V2Zai gNU5kKDKQhzoMxn8YjLT/AxPz7fe2Nd8dZHBUgBRE8s+1zU5SP8OZRGgFsb6yGGX esFsecUhOhBCYCbCDBnW8rrOiilPLMV0Bf7DRtFUinyVSUN5J0qyO9fIr0kPW+O4 JqydvODfd76z2ncfTwHQyf8rcjqhqo4TKHb2FMjQgpQfSnkQY8mIjBnZfRUGZ+R2 bUtCswgkhhj7Iraw1sw387H49nONMg== =7aba -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 20 09:39:35 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976AB3A1120 for ; Mon, 20 Dec 2021 09:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Akh_x0BzpK_J for ; Mon, 20 Dec 2021 09:39:27 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265E43A1123 for ; Mon, 20 Dec 2021 09:39:22 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JHmzq4XSVzDCvC; Mon, 20 Dec 2021 18:39:19 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <269201d7f5be$c94dcef0$5be96cd0$@jpshallow.com> Date: Mon, 20 Dec 2021 18:39:19 +0100 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 661714759.151062-4c721ab288ae8f7f815c0d3d8f9fc8f4 Content-Transfer-Encoding: quoted-printable Message-Id: <8E42CD49-27E0-4537-9E09-19469EDCADB7@tzi.org> References: <269201d7f5be$c94dcef0$5be96cd0$@jpshallow.com> To: supjps-ietf@jpshallow.com X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] draft-ietf-core-echo-request-tag -14 and Block2 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 20 Dec 2021 17:39:33 -0000 Hi Jon, thank you for bringing this up. > On 2021-12-20, at 17:29, supjps-ietf@jpshallow.com wrote: >=20 > Hi there, > =20 > I have run into an issue where multiple CoAP requests (not needing = Block1) to the same resource trigger potentially different responses = that require the use of Block2. If the responses overlap, then there is = confusion as to how to pull back the correct response to match the = request. For example (grossly simplifying things) > POST /api//read payload =3D { 'offset': 0, 'count': 1200 } > POST /api//read payload =3D { 'offset': 2000, 'count': 1300 = } > Or > FETCH /api//read payload =3D { 'offset': 0, 'count': 1200 } > FETCH /api//read payload =3D { 'offset': 2000, 'count': = 1300 } > =20 > RFC7959 2.4 rightly states > The Block2 Option provides no way for a single endpoint to perform > multiple concurrently proceeding block-wise response payload = transfer > (e.g., GET) operations to the same resource. This is rarely a > requirement, but as a workaround, a client may vary the cache key > (e.g., by using one of several URIs accessing resources with the = same > semantics, or by varying a proxy-safe elective option). =E2=80=A6 and note that Request-Tag says: 3.2.1. Request-Tag Option Format The Request-Tag option is not critical, is safe to forward, repeatable, and part of the cache key, see Figure 4, which extends Table 4 of [RFC7252]). (No idea why =E2=80=9Celective=E2=80=9D is spelled =E2=80=9Cnot = critical=E2=80=9D, but the point is that the option can be used to = distinguish multiple ongoing sequences of requests, as is spelled out at = the end of 3.2: In essence, it is an implementation of the "proxy-safe elective option" used just to "vary the cache key" as suggested in [RFC7959] Section 2.4. ) > Which then brings in the possible use of Request-Tag option in the = request as a proxy-safe elective option. However. > draft-ietf-core-echo-request-tag -14 3.2 states > The Request-Tag option is only used in requests that > carry the Block1 option, and in Block2 requests following these. This is indeed weird, in particular since 3.2.1 then has the correct = sentence: The Request-Tag option is only used in the request messages of block- wise operations. =20 > Which implies that the examples above need to contain the Block1 = option in the first instance if there is any suspicion that Block2 is = needed in the response. > =20 > Then draft-ietf-core-echo-request-tag -14 3.4 states > Note that Request-Tag options can be present in request messages = that > carry no Block option (for example, because a Request-Tag unaware > proxy reassembled them), and MUST be ignored in those. > =20 > Apart from being hard to parse (what does =E2=80=9Cthose=E2=80=9D = refer to?), =E2=80=9CThose=E2=80=9D =3D =E2=80=9Crequest messages that carry no = Block Option=E2=80=9D. > this tells me that Servers MUST ignore requests that have no Block = option No, that is definitely not what it says =E2=80=94 it says the *option* = is ignored in non-Block requests, not the entire request, and the = context makes clear that what is meant is that the recipient MUST NOT = throw an error just because the option is there. The wording =E2=80=9CMUST be ignored=E2=80=9D is unfortunate, because = they are still part of the cache key. > =E2=80=93 so, I cannot just add the Request-tag option to a request on = the off-chance there may be a Block2 needed response. You can (at least that is the intent). The =E2=80=9CChanges=E2=80=9D have this snippet: - Lift ban on Request-Tag options without Block1 (as they can legitimately be generated by an unaware proxy) =E2=80=A6which is confusing to me, but also see = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-echo-request-tag-09.tx= t =20 > Is there a good reason for this MUST? Your different reading demonstrates that we need to align the phrasing = better with the intent. This can be done in AUTH48, if the AD agrees. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 20 09:46:25 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF1A3A00AF for ; Mon, 20 Dec 2021 09:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYDEJr0sgF0F for ; Mon, 20 Dec 2021 09:46:11 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6FB3A003F for ; Mon, 20 Dec 2021 09:46:11 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JHn7g6176zDCjR; Mon, 20 Dec 2021 18:46:07 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <2420.1640020970@localhost> Date: Mon, 20 Dec 2021 18:46:07 +0100 Cc: "Apple Inc." , "t2trg@irtf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 661715167.295393-5278db39456b6b14e94aaea077ddd9f5 Content-Transfer-Encoding: quoted-printable Message-Id: References: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> <25576.1640012067@localhost> <2420.1640020970@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Quick Doodle T2TRG security topics (Re: [T2TRG] New topic for T2TRG?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 20 Dec 2021 17:46:17 -0000 On 2021-12-20, at 18:22, Michael Richardson = wrote: >=20 > applicability statement. That word is taken (Section 3.2 of RFC 2026), so please don=E2=80=99t = use it unless you actually do mean this (rather unsuccessful) form of = specification. https://datatracker.ietf.org/doc/html/rfc2026#section-3.2 Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 20 09:58:45 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33903A03F7 for ; Mon, 20 Dec 2021 09:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZy-X6I4zjJd for ; Mon, 20 Dec 2021 09:58:22 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECFF3A03F3 for ; Mon, 20 Dec 2021 09:58:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 351523954C; Mon, 20 Dec 2021 13:02:49 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pX6SVaKXpo6Y; Mon, 20 Dec 2021 13:02:47 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C683C3953B; Mon, 20 Dec 2021 13:02:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1640023367; bh=erBC2O8pf0gMgwa3VHIlLr8YrvgYK9qKf+++UPohdJA=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=uQZ+aRdyiczsCdztvHmoGZoyO7bIgqOR61fUzh08G3e/cj59fXO3OHzpbQd2D1xVm efurqLelY8cLYOMtlHKl++4A7aG6B4bxWaYwzTA+iME0RjZFq93unO6jA8/4aQMeT4 MUtAH0nq2EExEriKMuSf38/WzP1KzZWcCl8uGAlh/hN7thtQUd2yjgM9iqc184lmqW VMwCPnjCkd+4j6SnS/FFwNV6AHmZIdwzmAx1KPegTbrpipxHiy4VP7WPoPjBo4QTMc Ukj9MgNf0eSx+lImu9fMaimeBmlfrMC01JG5yRiYMiCZTfTXcG/veMBjoDDBrClsyE rXlViPv/SjAqQ== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CA4EA1A25; Mon, 20 Dec 2021 12:58:17 -0500 (EST) From: Michael Richardson To: Carsten Bormann cc: "Apple Inc." , "t2trg\@irtf.org" , "core\@ietf.org" In-Reply-To: References: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> <25576.1640012067@localhost> <2420.1640020970@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] Quick Doodle T2TRG security topics (Re: [T2TRG] New topic for T2TRG?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 20 Dec 2021 17:58:29 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >> >> applicability statement. > That word is taken (Section 3.2 of RFC 2026), so please don=E2=80=99t= use it > unless you actually do mean this (rather unsuccessful) form of > specification. > https://datatracker.ietf.org/doc/html/rfc2026#section-3.2 I think that I really do mean this word in exactly the context given. I agree that they have often been unused or ill-applied, but also often do work. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmHAxDkACgkQgItw+93Q 3WXLXQgAtzAkReEDGU0xYZYUaQeQ7nCn9Bh84CF7hUasbmYwTgnKxg7hm7DvqS0C SpzTu4kNvMOzCQ0C+61/d0Kv39fbgT9ktUQOPL/CpQS46Y3d01H53FYYsji3fMd/ 4hyvgKia74+JrENBB9XBEAOBCF7EhTVFlQ+RLO5jrt571HhWZhK9Y36YWnNhBhBv Tue1j7KJdH5KHQ5DHTiyvSRum45uHFr405MYY1U38DvyYrsVMevcpAgGSdsKks6d al2NDaTYb8T8FM3ecKDBvJzvtyCtQQIBGZ+PV+4JHg77wGMNPob8tK+xKMZCy1B8 2SMaHg51vD87Ss0XOhkc1gtw9+nHAQ== =yVgD -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 20 10:01:50 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22F93A03EA for ; Mon, 20 Dec 2021 10:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 Wh_OiZn5rVAz for ; Mon, 20 Dec 2021 10:01:38 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB5C3A0406 for ; Mon, 20 Dec 2021 10:01:38 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JHnTW1HdDzDCnl; Mon, 20 Dec 2021 19:01:35 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <13383.1640023097@localhost> Date: Mon, 20 Dec 2021 19:01:34 +0100 Cc: "Apple Inc." , "t2trg@irtf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 661716094.208497-efc730248854ded5eb62fa74b938489c Content-Transfer-Encoding: quoted-printable Message-Id: <2F90658A-DD84-47CA-A431-E4F49AA3D3E0@tzi.org> References: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> <25576.1640012067@localhost> <2420.1640020970@localhost> <13383.1640023097@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] [T2TRG] Quick Doodle T2TRG security topics (Re: New topic for T2TRG?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 20 Dec 2021 18:01:44 -0000 > On 2021-12-20, at 18:58, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Carsten Bormann wrote: >>>=20 >>> applicability statement. >=20 >> That word is taken (Section 3.2 of RFC 2026), so please don=E2=80=99t = use it >> unless you actually do mean this (rather unsuccessful) form of >> specification. >=20 >> https://datatracker.ietf.org/doc/html/rfc2026#section-3.2 >=20 > I think that I really do mean this word in exactly the context given. > I agree that they have often been unused or ill-applied, but also = often do > work. As an informational document, sure. In the RFC 2026 sense, hmm. Note that the activity discussed in this thread is really trying to = organize an activity of the T2TRG, and RGs don=E2=80=99t do standards, = so any RFC 2026 ASs would need to be done elsewhere. But research = identifying good (and not so good) combinations does make a lot of sense = here. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 20 11:22:35 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE16D3A090D for ; Mon, 20 Dec 2021 11:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRD3M05SPp5x for ; Mon, 20 Dec 2021 11:22:29 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CC6F3A0902 for ; Mon, 20 Dec 2021 11:22:28 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1mzOEo-0006RK-9c; Mon, 20 Dec 2021 19:22:22 +0000 From: "Jon Shallow" To: "'Carsten Bormann'" Cc: References: <269201d7f5be$c94dcef0$5be96cd0$@jpshallow.com> <8E42CD49-27E0-4537-9E09-19469EDCADB7@tzi.org> In-Reply-To: <8E42CD49-27E0-4537-9E09-19469EDCADB7@tzi.org> Date: Mon, 20 Dec 2021 19:22:28 -0000 Message-ID: <297301d7f5d6$ed3a33e0$c7ae9ba0$@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: AQF8QA3GNdD894KceuIedjWXFRhXNAJ65wRwrN9VGGA= Content-Language: en-gb Archived-At: Subject: Re: [core] draft-ietf-core-echo-request-tag -14 and Block2 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 20 Dec 2021 19:22:34 -0000 Hi Carsten, Thanks for this. I will go ahead using the Request-Tag in the request = in the potential case there is a response requiring Block2. Regards Jon > -----Original Message----- > From: Carsten Bormann [mailto: cabo@tzi.org] > Sent: 20 December 2021 17:39 > To: jon@jpshallow.com > Cc: core@ietf.org > Subject: Re: [core] draft-ietf-core-echo-request-tag -14 and Block2 >=20 > Hi Jon, >=20 > thank you for bringing this up. >=20 ..... >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Dec 21 02:26:29 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED583A0A51 for ; Tue, 21 Dec 2021 02:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 046C2RYVjIsF for ; Tue, 21 Dec 2021 02:26:24 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B76C3A0987 for ; Tue, 21 Dec 2021 02:26:23 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JJCKh3PgmzDCbd; Tue, 21 Dec 2021 11:26:16 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> Date: Tue, 21 Dec 2021 11:26:16 +0100 Cc: "t2trg@irtf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 661775175.9623179-111053cb990f5f00baff6a0342f91e8e Content-Transfer-Encoding: quoted-printable Message-Id: <8CDC234A-7F52-4571-8CCA-0D5F59A84DB6@tzi.org> References: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> To: "Apple Inc." X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Quick Doodle T2TRG security topics (Re: [T2TRG] New topic for T2TRG?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 21 Dec 2021 10:26:28 -0000 > I have put up 9 potential meeting slots this week: > https://doodle.com/poll/7e76k335hd6d28k3 The doodle was in favor of 1600Z today (1100 EST, 1700 CET, 1800 EET). Webex info: Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dmd00b3797e6b5d123cd2689f53b076f11= =20 Meeting number: 2428 335 7567 Password:=20 constrained I hope to have an agenda prepared in a few hours. As I said, this is going to be an informal chat in preparation of the = real work. Talk to you then! Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Dec 21 07:24:19 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299253A0E25 for ; Tue, 21 Dec 2021 07:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ymNwK5RzRp1t for ; Tue, 21 Dec 2021 07:24:13 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8E73A0DA0 for ; Tue, 21 Dec 2021 07:24:12 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JJKxQ2pvKzDCdN; Tue, 21 Dec 2021 16:24:10 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <8CDC234A-7F52-4571-8CCA-0D5F59A84DB6@tzi.org> Date: Tue, 21 Dec 2021 16:24:09 +0100 Cc: "t2trg@irtf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 661793049.72253-7758a03e8981921177d8d94cc182f8fa Content-Transfer-Encoding: quoted-printable Message-Id: <5B94533C-55C8-4DD8-BB57-29E96880A951@tzi.org> References: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> <8CDC234A-7F52-4571-8CCA-0D5F59A84DB6@tzi.org> To: "Apple Inc." X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Quick Doodle T2TRG security topics (Re: [T2TRG] New topic for T2TRG?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 21 Dec 2021 15:24:18 -0000 Some initial slides at http://tzi.de/~cabo/t2trg-chat-2021-12-21.pdf We will collect notes at https://notes.ietf.org/notes-t2trg-chat-2021-12-21 See you in 35 minutes=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten > On 2021-12-21, at 11:26, Carsten Bormann wrote: >=20 >> I have put up 9 potential meeting slots this week: >> https://doodle.com/poll/7e76k335hd6d28k3 >=20 > The doodle was in favor of 1600Z today (1100 EST, 1700 CET, 1800 EET). >=20 > Webex info: >=20 > Meeting link: > = https://ietf.webex.com/ietf/j.php?MTID=3Dmd00b3797e6b5d123cd2689f53b076f11= =20 > Meeting number: > 2428 335 7567 > Password:=20 > constrained >=20 > I hope to have an agenda prepared in a few hours. > As I said, this is going to be an informal chat in preparation of the = real work. > Talk to you then! >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Tue Dec 21 09:17:55 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A82B3A1188 for ; Tue, 21 Dec 2021 09:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 il4ZxmbFlRIY for ; Tue, 21 Dec 2021 09:17:35 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7133A1182 for ; Tue, 21 Dec 2021 09:17:34 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JJNSC1G19zDCfW; Tue, 21 Dec 2021 18:17:31 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <5B94533C-55C8-4DD8-BB57-29E96880A951@tzi.org> Date: Tue, 21 Dec 2021 18:17:30 +0100 Cc: "t2trg@irtf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 661799850.743416-796ecd4460ffc5a9b1d48c2680462ea9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> <8CDC234A-7F52-4571-8CCA-0D5F59A84DB6@tzi.org> <5B94533C-55C8-4DD8-BB57-29E96880A951@tzi.org> To: "Apple Inc." X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Quick Doodle T2TRG security topics (Re: [T2TRG] New topic for T2TRG?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 21 Dec 2021 17:17:40 -0000 So we had the first hour of discussion, and it was interesting to see = how many areas of potential work we could actually make out beyond what = I had prepared. See notes referenced below. We decided we would spend some time individually, grouping the = activities listed (and our favorite additions) into =E2=80=94 short term (do now) =E2=80=94 mid term (examine and turn into one or more short-term items = during year 2022) =E2=80=94 long term (same, but really with a longer outlook and some = =E2=80=9Cfreezer=E2=80=9D semantics for now). So we=E2=80=99ll try to have a few short emails (=E2=80=9Cdocuments=E2=80=9D= ) out with this by Monday, 2022-01-10, and meet again 2022-01-11 at = 1600Z again to merge and make this more concrete. An actual work meeting, with prepared discussion points = (=E2=80=9Cpresentations=E2=80=9D, but really mostly for discussion), = would then be next. Gr=C3=BC=C3=9Fe, Carsten > On 2021-12-21, at 16:24, Carsten Bormann wrote: >=20 > Some initial slides at >=20 > http://tzi.de/~cabo/t2trg-chat-2021-12-21.pdf >=20 > We will collect notes at >=20 > https://notes.ietf.org/notes-t2trg-chat-2021-12-21 >=20 > See you in 35 minutes=E2=80=A6 >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On 2021-12-21, at 11:26, Carsten Bormann wrote: >>=20 >>> I have put up 9 potential meeting slots this week: >>> https://doodle.com/poll/7e76k335hd6d28k3 >>=20 >> The doodle was in favor of 1600Z today (1100 EST, 1700 CET, 1800 = EET). >>=20 >> Webex info: >>=20 >> Meeting link: >> = https://ietf.webex.com/ietf/j.php?MTID=3Dmd00b3797e6b5d123cd2689f53b076f11= =20 >> Meeting number: >> 2428 335 7567 >> Password:=20 >> constrained >>=20 >> I hope to have an agenda prepared in a few hours. >> As I said, this is going to be an informal chat in preparation of the = real work. >> Talk to you then! >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Dec 23 08:42:30 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3A83A05F8 for ; Thu, 23 Dec 2021 08:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, 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 9u6dFFDzRv9i for ; Thu, 23 Dec 2021 08:42:23 -0800 (PST) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 5C9043A0602 for ; Thu, 23 Dec 2021 08:42:23 -0800 (PST) Received: by mail-qv1-xf2b.google.com with SMTP id kk22so5730360qvb.0 for ; Thu, 23 Dec 2021 08:42:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=Je0OcDX3L0qOKY8WLzJnNRPuqrojnlRNlDGOGp6nT6Q=; b=CYEsnwuYuTpwD13G8y/4V+NLde7WK49JzxcxsGnmbpShW/ucwUYiGfb+ldj2IOe0xx aV1i2kxAAA/+aln9Z9el91TsgQ1TKP8uFzaBhMUn1tFha0/t4Sd//JZtBnqBj1rh/7pP 4PP8r/EG/ZLJW1GYe9K1ug+Cq84fgnaXNurl1Z5lIIRTt94CLFyqdeeDfCWuFHJTs7Jr zfIZ7yVPU2wQ5+PrcCYqCcn5HtuJr4ILO50PwARygQBBn3dLDFUu6pJ45C1kXvIcGxYL T9Q0sgYr4d4W/xrP4qbwZGPwou5g3c+d349BsGPNjk9Wiai2pPjTWdJGUYHziAPV1KYw HXNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Je0OcDX3L0qOKY8WLzJnNRPuqrojnlRNlDGOGp6nT6Q=; b=ojTGUUq7vv4j9UCtMNo4vmKR4cnKDy/YMUWtfA5/zGDvQ0lIxv07BwZg0eXybDWFPI 1zfWqC9NLPeFr8utCby17UfRu3lw7OmvS2M/vyAnAegU+7MhJew3ikxZn6UfBOXDZcnn vEqhtloncy4H7Dre0hht/qiiGzq5rA9ngQzLc7JYdtWrjsHEbPNDFpO9xP5yzZ8or6C5 RZS7kY7JgTk9g/TercDHOLJSCKrGarpsMR6kvEjPoibt99W2dwQ//MHAVHvLrFOmJBE+ U117+9O7wa9AZeCS8+/uaqYDBYwRFJH4B2HgVtZ88qbGnMtF/yhnkfOO36YMtOQy7ZbY Makg== X-Gm-Message-State: AOAM531BjWZMKIg/Tsj0tpi1jIKqy6E3toJMgfi/EhoH0/DXAxL9PgVM yws6lVGjK0HnFzmfDZr1thfY6Fo+Npw= X-Google-Smtp-Source: ABdhPJwpa64WyXZZ4ZM1+CaF8/zxTUlzelnAkX5gyMj6bBLqUhrzC1XpyB9QS3roxEmIanEEBCAonA== X-Received: by 2002:a05:6214:1c4b:: with SMTP id if11mr2342378qvb.9.1640277741913; Thu, 23 Dec 2021 08:42:21 -0800 (PST) Received: from ?IPV6:2607:fea8:8a0:1397:2c78:a3f0:bd90:64f8? ([2607:fea8:8a0:1397:2c78:a3f0:bd90:64f8]) by smtp.gmail.com with ESMTPSA id bi6sm4732446qkb.29.2021.12.23.08.42.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Dec 2021 08:42:21 -0800 (PST) Message-ID: <80a44d0d-767b-46dd-8e26-2f032dc653a5@gmail.com> Date: Thu, 23 Dec 2021 11:42:18 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: Carsten Bormann , "Apple Inc." Cc: "t2trg@irtf.org" , "core@ietf.org" , Mohit Sethi References: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> <8CDC234A-7F52-4571-8CCA-0D5F59A84DB6@tzi.org> <5B94533C-55C8-4DD8-BB57-29E96880A951@tzi.org> From: Rene Struik In-Reply-To: <5B94533C-55C8-4DD8-BB57-29E96880A951@tzi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] [T2TRG] Quick Doodle T2TRG security topics (Re: New topic for T2TRG?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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 Dec 2021 16:42:29 -0000 [resending prior offline communication, but now to the list] Hi Carsten: I dialed-into this chat (but had to log-off, due to schedule conflict 11.30am EST). During the call, you mentioned that EAP-NOOB seems un-implementable (or, one of your students thought so). If you could articulate what is good and what is bad (in terms of feature set, user experience, etc.), that would be good to know, as would be whether you think this can be remedied or whether one can improve the protocol with a minor tweak. In other words, what is missing and what would you ideally like to see here? Best regards, Rene On 2021-12-21 10:24 a.m., Carsten Bormann wrote: > Some initial slides at > > http://tzi.de/~cabo/t2trg-chat-2021-12-21.pdf > > We will collect notes at > > https://notes.ietf.org/notes-t2trg-chat-2021-12-21 > > See you in 35 minutes… > > Grüße, Carsten > > >> On 2021-12-21, at 11:26, Carsten Bormann wrote: >> >>> I have put up 9 potential meeting slots this week: >>> https://doodle.com/poll/7e76k335hd6d28k3 >> The doodle was in favor of 1600Z today (1100 EST, 1700 CET, 1800 EET). >> >> Webex info: >> >> Meeting link: >> https://ietf.webex.com/ietf/j.php?MTID=md00b3797e6b5d123cd2689f53b076f11 >> Meeting number: >> 2428 335 7567 >> Password: >> constrained >> >> I hope to have an agenda prepared in a few hours. >> As I said, this is going to be an informal chat in preparation of the real work. >> Talk to you then! >> >> Grüße, Carsten >> > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 From nobody Thu Dec 23 09:39:06 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6803A3A059F for ; Thu, 23 Dec 2021 09:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=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 36pjEqy_bz5L for ; Thu, 23 Dec 2021 09:38:55 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1273A083C for ; Thu, 23 Dec 2021 09:38:42 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JKcqZ4XdRzDCbT; Thu, 23 Dec 2021 18:38:34 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <80a44d0d-767b-46dd-8e26-2f032dc653a5@gmail.com> Date: Thu, 23 Dec 2021 18:38:34 +0100 Cc: "Apple Inc." , "t2trg@irtf.org" , "core@ietf.org" , Mohit Sethi X-Mao-Original-Outgoing-Id: 661973914.105266-11d998cfeef504c7448d55c73ef47200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> <8CDC234A-7F52-4571-8CCA-0D5F59A84DB6@tzi.org> <5B94533C-55C8-4DD8-BB57-29E96880A951@tzi.org> <80a44d0d-767b-46dd-8e26-2f032dc653a5@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] [T2TRG] Quick Doodle T2TRG security topics (Re: New topic for T2TRG?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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 Dec 2021 17:39:01 -0000 Hi Rene, > During the call, you mentioned that EAP-NOOB seems un-implementable = (or, one of your students thought so). If you could articulate what is = good and what is bad (in terms of feature set, user experience, etc.), = that would be good to know, as would be whether you think this can be = remedied or whether one can improve the protocol with a minor tweak. I haven=E2=80=99t really looked at the protocol, only briefly at the = implementability of the signing inputs after a student alerted me to = issues he had. Re the protocol, I=E2=80=99ve heard rumors that a simpler protocol could = be invented that solves the same set of problems, but I know nothing = about that. Re the implementability: I sent some notes to Mohit; I=E2=80=99m sure = the student will also write up something but it is a quiet time here in = Germany right now. I think that the RG would benefit from an analysis of NOOB, both with = respect to technical details such as signing inputs, and with respect to = players, trust relationships, outcomes, etc., and how the protocol = addresses these. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Dec 23 10:38:33 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CFB3A08AD for ; Thu, 23 Dec 2021 10:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sId4oRsYZBhX for ; Thu, 23 Dec 2021 10:38:10 -0800 (PST) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 B015D3A08AB for ; Thu, 23 Dec 2021 10:38:10 -0800 (PST) Received: by mail-qv1-xf31.google.com with SMTP id o10so5944321qvc.5 for ; Thu, 23 Dec 2021 10:38:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:cc :references:from:subject:in-reply-to:content-transfer-encoding; bh=o/9G5kTGoZQHFVi/N0yXeFWsJSTsyM5GbhudsKR1Dss=; b=fAbDISkr95AoB0t4sr7PONnRhG2HJfk4Fg62LxoJTeDkNVPBYP2bWV11aFchyyokv6 IwZ1bdgHzRKFLNZw6vMKIptaeim2VMT3tl/ZNojA+1F5AU7zEpVQ4DcxLZCTHqElHwGg dHmSydPMwlz/lxZelf01wIGkbff5EO4qKQLThH2bhn9w9DOsGl0tj2aBRQ84yK5GskB3 Gd0DOD+0qgxWOqTlbglm+u6G9Ug5NJFaBaNnbXctlkA8zKxv3bybKyAtC2pQnlE9m5kl UgMvaKLkj49pG1tpqpSp3nMgBqhjhIB+//TMLX0QQ0grgkY+KK+MUVa5d7farmwMRzh4 /bTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=o/9G5kTGoZQHFVi/N0yXeFWsJSTsyM5GbhudsKR1Dss=; b=PCwB/ztF5R9FTNKeDt0dbdOZWDeQoXM7snMhfMwIWwzJiy7I1vGXtPt9+1nyZwijjX sB6NBk2LDprua3bV0q4zD0xFpp+TYy2KYcnQb37A8drnoVG7dNWAnVULe24TZHRT5Huw udMDO6y97XWGpbGNOctPM98xBmysFWlONle0MXSKodpBCvOgtYtXug7kHvilQKFRgxHs AEdK7Nc/gny+ogXoSDJei8iVfi7KK57jf2Bg/RzqWhleEYI0EXXFJdXqEuNCHq9tkQWS iwZpTn7tApYQ6dmwqoJG8Twv6ubyVch6Z6Jn+CgIPtPD1CsmBRyN3mQaLmDtjzx5fREG cx/A== X-Gm-Message-State: AOAM533kKV9+ynjj+MksfxC4PdFGKUnb+eqKlDRZSVQPx4ZpD7fl41uE pXBplBeO1J/5gbibntgB4qM= X-Google-Smtp-Source: ABdhPJzmX91yMFJo9xmql/nHZOV70/8K2tQUYq2p9S1vtapbYp6dXSWTCZ9k1w34J08QB8gCQ5IUmQ== X-Received: by 2002:a05:6214:1d03:: with SMTP id e3mr2723122qvd.77.1640284687928; Thu, 23 Dec 2021 10:38:07 -0800 (PST) Received: from ?IPV6:2607:fea8:8a0:1397:fc5f:12b:d173:619a? ([2607:fea8:8a0:1397:fc5f:12b:d173:619a]) by smtp.gmail.com with ESMTPSA id w10sm5469528qkp.121.2021.12.23.10.38.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Dec 2021 10:38:07 -0800 (PST) Message-ID: <616d64f3-ae50-3eb7-e6be-ca00f364fb82@gmail.com> Date: Thu, 23 Dec 2021 13:38:04 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: Carsten Bormann Cc: "Apple Inc." , "t2trg@irtf.org" , "core@ietf.org" , Mohit Sethi References: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> <8CDC234A-7F52-4571-8CCA-0D5F59A84DB6@tzi.org> <5B94533C-55C8-4DD8-BB57-29E96880A951@tzi.org> <80a44d0d-767b-46dd-8e26-2f032dc653a5@gmail.com> From: Rene Struik In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] [T2TRG] Quick Doodle T2TRG security topics (Re: New topic for T2TRG?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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 Dec 2021 18:38:15 -0000 Hi Carsten: Thanks. If there is a brief problem statement on what problem is solved, both stated and in real life, I am happy to reflect on this: I have done quite a bit of protocol analysis, including fixes, but this starts with a clear description about what one wishes to achieve (at least, on the crypto level with existing protocol soup distractions removed for the moment). A good use of yet another cooped-up time window or simply next to the Christmas tree. {if not completely clear/complete yet, please let me know offline -- I can fill in part of the blanks if not that many}. Best regards, Rene On 2021-12-23 12:38 p.m., Carsten Bormann wrote: > Hi Rene, > >> During the call, you mentioned that EAP-NOOB seems un-implementable (or, one of your students thought so). If you could articulate what is good and what is bad (in terms of feature set, user experience, etc.), that would be good to know, as would be whether you think this can be remedied or whether one can improve the protocol with a minor tweak. > I haven’t really looked at the protocol, only briefly at the implementability of the signing inputs after a student alerted me to issues he had. > > Re the protocol, I’ve heard rumors that a simpler protocol could be invented that solves the same set of problems, but I know nothing about that. > > Re the implementability: I sent some notes to Mohit; I’m sure the student will also write up something but it is a quiet time here in Germany right now. > > I think that the RG would benefit from an analysis of NOOB, both with respect to technical details such as signing inputs, and with respect to players, trust relationships, outcomes, etc., and how the protocol addresses these. > > Grüße, Carsten > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 From nobody Mon Dec 27 10:09:01 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E543A0E46 for ; Mon, 27 Dec 2021 10:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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=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 fTtzhxZfIR8u for ; Mon, 27 Dec 2021 10:08:49 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 767633A0E42 for ; Mon, 27 Dec 2021 10:08:49 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id x4so9353345ljc.6 for ; Mon, 27 Dec 2021 10:08:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=peOYVawycjslUmVrEA/OmZnYV9+au2q0y16yC02S1sY=; b=cDbdCoB5HXFRUjRhz/bcC91/gHF0P0S5XoQAoA81AMrj2p9e9b+z7gQ0YAxAn5Y4K6 0DgSWS9YojbJmcHkVrjcRqwYAm4/kkE5N5DP4X4G/QxvrXY2RxAGIky2gKe+/xKXgRql 5Z2VazQRvE/L/AxkuIvpWpGZ/Ey/ckmeoZM5GjaMpAWs4win2ElDKwn/uPIzLmTQ7mEt WmYvs614nAaW4Z9bEbkgSVJb2rwFLeg/BDq0ERgBiJuIWc1OBcyZwDSTjkmSXqDd1FRg l6QKNwCXrHx8WDTxh9hsV8IooX5X50qGSWdCbtNU+Ucq7kIisNwjPk70MLGdSc/9LSBG 85jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=peOYVawycjslUmVrEA/OmZnYV9+au2q0y16yC02S1sY=; b=ZLe58jEI4Aoyk0SoJaTKOSZ5MH/IsEE3DXaoeIxeJcww1XCyayojlkwkk5Oju7+cUJ 2p0TeG1ACYfLrzy6JREOCmyzBsIeJywFzpmodjeoaWtcxXtdnyAX6jm8UXUbRUmHa8IJ ax1z95i8tOBe7VwGT9+U4mVDSQyS6aSX1TTZefCKmUHfhSjGxzPAOLux4hgPCnkl/yrv wZ5LVB9f27pqrJ5D1KizB63r3GBmYdt1aK2tGMxOPiwOhJ7d5d1pDiGMGt4gCTQn1sp/ XqeQ1ztP6bUZgDi70BNiFRzgkdGX5t+3vaRdmK9ED9iBQws8k8F4bfxVWpKNqD1hpi9d jt0g== X-Gm-Message-State: AOAM531pfRywGBmpPY6pAhWztfNEQUozbKl/04GWyGP3TGjLKGo+fqJJ 8vf/T68LwXRpuYPddxPY+4cWpMyXavKw1JQhrBQ= X-Google-Smtp-Source: ABdhPJwWi7s3GIMBskaBQZIBv9DCBIZb5eZ9UnaLFOuiHfq4kzSMo5Xhe0XlA3YdVN3omznnkDFybDnl7l3+IEEMmwo= X-Received: by 2002:a2e:8813:: with SMTP id x19mr14748738ljh.2.1640628526262; Mon, 27 Dec 2021 10:08:46 -0800 (PST) MIME-Version: 1.0 References: <97ED3090-7BBA-4ED8-B50B-26C5AC863EB5@tzi.org> <8CDC234A-7F52-4571-8CCA-0D5F59A84DB6@tzi.org> <5B94533C-55C8-4DD8-BB57-29E96880A951@tzi.org> <80a44d0d-767b-46dd-8e26-2f032dc653a5@gmail.com> In-Reply-To: Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Mon, 27 Dec 2021 12:08:34 -0600 Message-ID: To: Carsten Bormann Cc: Rene Struik , Mohit Sethi , "Apple Inc." , "t2trg@irtf.org" , "core@ietf.org" Content-Type: multipart/alternative; boundary="000000000000842c1405d4249800" Archived-At: Subject: Re: [core] [T2TRG] Quick Doodle T2TRG security topics (Re: New topic for T2TRG?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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 Dec 2021 18:08:55 -0000 --000000000000842c1405d4249800 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 23, 2021 at 11:39 AM Carsten Bormann wrote: > Hi Rene, > > > During the call, you mentioned that EAP-NOOB seems un-implementable (or= , > one of your students thought so). If you could articulate what is good an= d > what is bad (in terms of feature set, user experience, etc.), that would = be > good to know, as would be whether you think this can be remedied or wheth= er > one can improve the protocol with a minor tweak. > > I haven=E2=80=99t really looked at the protocol, only briefly at the > implementability of the signing inputs after a student alerted me to issu= es > he had. > > Re the protocol, I=E2=80=99ve heard rumors that a simpler protocol could = be > invented that solves the same set of problems, but I know nothing about > that. > > > Re the implementability: I sent some notes to Mohit; I=E2=80=99m sure the= student > will also write up something but it is a quiet time here in Germany right > now. > > Which part is the problem? EAP part with 802.15.4 interface or NOOB out-of-band channel with blinking LED, its encoding on an Android smartphone? I think in the implementation as reported they have used specific software like Contiki-NG, hardware like Zolertia Firefly motes and the board and if you don't use them or have a different version, etc. the assumptions may not hold true. I think that the RG would benefit from an analysis of NOOB, both with > respect to technical details such as signing inputs, and with respect to > players, trust relationships, outcomes, etc., and how the protocol > addresses these. > > +1 Behcet > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg > --000000000000842c1405d4249800 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 23, 2021 at 11:39 AM Cars= ten Bormann <cabo@tzi.org> wrote:=
Hi Rene,

> During the call, you mentioned that EAP-NOOB seems un-implementable (o= r, one of your students thought so). If you could articulate what is good a= nd what is bad (in terms of feature set, user experience, etc.), that would= be good to know, as would be whether you think this can be remedied or whe= ther one can improve the protocol with a minor tweak.

I haven=E2=80=99t really looked at the protocol, only briefly at the implem= entability of the signing inputs after a student alerted me to issues he ha= d.

Re the protocol, I=E2=80=99ve heard rumors that a simpler protocol could be= invented that solves the same set of problems, but I know nothing about th= at.


=C2=A0
Re the implementability: I sent some notes to Mohit; I=E2=80=99m sure the s= tudent will also write up something but it is a quiet time here in Germany = right now.


Which part is the problem? EAP part wi= th 802.15.4 interface or NOOB out-of-band channel with blinking LED, its en= coding on an Android smartphone?
I =C2=A0think in the implementat= ion as reported they have used specific software like Contiki-NG, hardware = like Zolertia Firefly motes and the board and if you don't use them or = have a different version, etc. the assumptions may not hold true.


I think that the RG would benefit from an analysis of NOOB, both with respe= ct to technical details such as signing inputs, and with respect to players= , trust relationships, outcomes, etc., and how the protocol addresses these= .


+1

Behcet
=C2=A0
Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
T2TRG mailing list
T2TRG@irtf.org
https://www.irtf.org/mailman/listinfo/t2trg
--000000000000842c1405d4249800--