From nobody Sun Dec 1 18:25:38 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3689412011F for ; Sun, 1 Dec 2019 18:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 85BuY-qicvvB for ; Sun, 1 Dec 2019 18:25:35 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 C9AA7120052 for ; Sun, 1 Dec 2019 18:25:34 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id y5so13962105lfy.7 for ; Sun, 01 Dec 2019 18:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2BBvEM4+YLtUu3VUnpu1rJCnCdWmeHBoSPjDyO8VTFY=; b=H9hOp5mt7bVZhYj9GD8cwRjMGagCt3PFOS1eBtQmuj1mypdz+SYM2AgtBAKmJzr7tf +CO71Vz4uhS70RwipyEELzSGyE0izEtVO1mbra233m9Ua6cFDf8ybNpqNG35gJjcTBaj 7o86JyLSKU+SAZqGl+ItuZO7KTQHCIWxkngUpE3U7K/AmHNKw723JJXVXY99t4v61ihf av6YDK/E3tFXi8qv39Ig9ypGiUmjrgzzKYJPl8I81D/ARveNx6fwSihiwJL/57JKN5cK OJZyWRdkUzTD8mrQJNCQszvL+IIWIvu48FbGWPHWWNS/ak9ZvHt5vGuvlaVHbzlnZk2O gnLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2BBvEM4+YLtUu3VUnpu1rJCnCdWmeHBoSPjDyO8VTFY=; b=KxR/P5EDfdgHFMXwnxQ7z5zFgC5TuTdyalnGKZTTyZnOjCeAWa5tkZiJcGM+wd2/CO dvbJJUWvkKYLBNMHsj7GHpkXsNIdbFt4wfTzvyhxmC5xDzTSap6DhTkRYIcXlRSUH1Ha UxSGjbSqFLziN4m2ozq24WHDqgkMBiTwskdMXnqFOsqUaYbhrZ6KP6Q2Ug9fgHOA46yY vk6SxhbUPbUwX9XqbYTXdGBpOozEUiSqaHMBgBdc3P+6k7sY3KGG3hH6IEjuO64OhJex yn4EFLihrg/Be8prhUErJmE1X8UasrZWH9UkXOJD3yj6/H/Q8r+k04QZfN5RGs5W4Eoy MP/g== X-Gm-Message-State: APjAAAU0cmAvzx8DOYixTmNXDrWYl1xH0qk51fiS0tH/cZlp3PG8GrXM ivZR623lTCs1dMf3exruzPQl5C03EoUrNDN3hT6d X-Google-Smtp-Source: APXvYqyVwdpiaZWBFKcZ1SYynhTTB+Wjp2IzsBCK9CkBbYLDcu4l8cxW3qr8RXt5RIofelvRRqG9R3O/6G3Bu6dT1b8= X-Received: by 2002:ac2:5a1a:: with SMTP id q26mr1243708lfn.33.1575253532552; Sun, 01 Dec 2019 18:25:32 -0800 (PST) MIME-Version: 1.0 From: James Nguyen Date: Sun, 1 Dec 2019 21:25:20 -0500 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary="0000000000003d335b0598af4b9e" Archived-At: Subject: [core] IETF 106 Meeting Notes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 02:25:36 -0000 --0000000000003d335b0598af4b9e Content-Type: text/plain; charset="UTF-8" Hello WG, Are the IETF 106 meeting notes available for viewing? -- James Nguyen Email: james.huy.nguyen@gmail.com --0000000000003d335b0598af4b9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello WG,

Are the IETF 106 meeting note= s available for viewing?=C2=A0

--
Ja= mes Nguyen
Email: james.huy.nguyen@gmail.com
--0000000000003d335b0598af4b9e-- From nobody Mon Dec 2 01:16:54 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A58120048 for ; Mon, 2 Dec 2019 01:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeqQu-3vru5N for ; Mon, 2 Dec 2019 01:16:50 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10080.outbound.protection.outlook.com [40.107.1.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DA3120044 for ; Mon, 2 Dec 2019 01:16:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YmZkX733CmkTkhdo2lrB02yzKY6VgOf8QtA8e2lNesikgXplC/o7BRxaEJhM/kPWfEAz9cTL/5DHgrHGbMpzN8dwJM2elvVS/ac4ZivPU2FoBf4s83Ph5lDl+X+UTUatuKSekLgS1bPIrNO4W1V1PL00q/2jY6v2hpHkTK6fMklJwnnsxUHGhoQDFb43QRoE7FPda1oXhcPOTb5fbxxfDUz5yXRw6wDUOkQEVjjaymPzg+39gdx5m+4O6dYAgAaKRV+BnCq0tBIrJNE95dcc/Cf1/vnfR26fozY2Wba3Qo5FLLY9PlQcJVWbTNYHCi/Wn/cl5PUh13jlRdYpQsSAuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9Dg7uJjc8BVQwur7XNZNv2mLlN2yzdRCmlDYohdZWko=; b=Ivb0wS6GkHTg8aMc+vOc8MuBslLWKqbuln50NX3I34qR69f2SlZ9I3FubxPAOAghkNO+mS5Nb53rcQY603kHTjNqWQYB+rH07rntfonSaIfFuEbrc2AwufoMB2KmI5kH+9vWb5EnRI0TRgnYhWlnneMiLGRWLiLA48Hs+jQloB+v9bFzjLvVqSLFuiP5mBQvdbINznmlEMa5s8jRJHNyoMSmNMR1ZLgdl9lIaLekM9IH/EfRreZvq/CFw4tYXu6lX6nxzR+KMVg9rNJbJzd6lOX78JZhys6Affks+d3/pA3C7vIS2Lo2QzqjAtOqtliZo+3sn2qDGZ/7BFkM0KWeww== 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=9Dg7uJjc8BVQwur7XNZNv2mLlN2yzdRCmlDYohdZWko=; b=GpIm+ve81JtReum1LAb8gLxraNtTQbOXVV1x2CAHQnDTl3a46OE0j3dFu8Zga9kFFxUla9o2IW1Rwgg7STEXO0jhAa2PKsDqxpVo4PAO+SuJv3jHQpvCksot8IPtlBScBeolaC4HqBVMALafGmf87uhSHVDF5y8gcKM0OVk9xJI= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3467.eurprd07.prod.outlook.com (10.170.241.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.4; Mon, 2 Dec 2019 09:16:37 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::2ca9:414:cc01:9706]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::2ca9:414:cc01:9706%4]) with mapi id 15.20.2516.003; Mon, 2 Dec 2019 09:16:37 +0000 From: Christer Holmberg To: Carsten Bormann CC: "core@ietf.org" Thread-Topic: [core] Retransmission of non-confirmable response message upon receiving request message retranmission? Thread-Index: AQHVppE/OetFI+DdS0KoPWGUqntDGKeiDkmAgASofwA= Date: Mon, 2 Dec 2019 09:16:37 +0000 Message-ID: <15497B4D-33BA-4DE9-A352-417F6393E4D2@ericsson.com> References: <41889A1F-ACC3-458B-B57F-503A55D1D2A3@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0bc6e998-71fa-410e-8c28-08d7770855a0 x-ms-traffictypediagnostic: HE1PR07MB3467: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(366004)(346002)(39860400002)(136003)(199004)(189003)(3846002)(2906002)(76116006)(66556008)(66946007)(44832011)(305945005)(7736002)(66446008)(91956017)(58126008)(186003)(26005)(2616005)(86362001)(316002)(11346002)(446003)(64756008)(6916009)(66476007)(36756003)(102836004)(71190400001)(15650500001)(71200400001)(81166006)(81156014)(5660300002)(6506007)(14454004)(8936002)(76176011)(478600001)(256004)(66066001)(8676002)(99286004)(14444005)(25786009)(6436002)(4326008)(229853002)(6512007)(6486002)(33656002)(6116002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3467; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: h4axwOU6UDl287BhAs5UIag8VQtf0RkzM9v3NVWJU18EqLTq5vI44vyL28TpNBicEhHzm2AsDaFm1iZnJs22H3WzIZaP/+e6SPLeFt3/HIrze0j4LzpLiqdAXhfZr2a7LYfeEw6G6s1MgnPSX47AQCt+QcVGAySRlDCwHvL0SIdAEqVg68Nch9XvG8Dv3UsHZENWJumiqZeeOfV7PS5MqaWOQu7pVd+EPDEZknUJskg3Y5DQ3mRyH6ylqN8xjqDjkOfr3iT9pJfF+NNiTZjW32BYH6ieiph87vu9HxCMbCUVKwedGCk68thxBZqLHdwJ9WpIDUCmI5RLM2WwkguI4EoLGhwxWiHuk2zJvjJvS7E9a3ljT/ILMgY0OKW9Yt65Uh9frxZapE1qJmgjzIJrvGzAsFAcBp4xNragNFaY9C222EXjkO2crdROEys2wfIX x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0bc6e998-71fa-410e-8c28-08d7770855a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2019 09:16:37.5403 (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: izf+QyhjmioS3vH5/3TClmtbjw6N85CQmHXs9nicy+sU4MiV4PmaezMel/KYWTQy60eeHp2S5Fe8Hlk++YDX4R1wpr5glKDKdMQVgqHMVv8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3467 Archived-At: Subject: Re: [core] Retransmission of non-confirmable response message upon receiving request message retranmission? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 09:16:52 -0000 SGksDQoNCiAgICA+PiBBc3N1bWUgYSBDb0FQIHNlcnZlciByZWNlaXZlcyBhIGNvbmZpcm1hYmxl IHJlcXVlc3QgbWVzc2FnZS4NCiAgICA+PiAgDQogICAgPj4gQWNjb3JkaW5nIHRvIFNlY3Rpb24g NC41LiBvZiBSRkMgNzI1MiwgdGhlIHNlcnZlciBTSE9VTEQgcmV0cmFuc21pdCB0aGUgYXNzb2Np YXRlZCBBQ0sgd2hlbmV2ZXIgaXQgcmVjZWl2ZXMgYSByZXRyYW5zbWlzc2lvbiBvZiB0aGUgcmVx dWVzdCBtZXNzYWdlLiBTbyBmYXIsIHNvIGdvb2QuDQogICAgPj4gIA0KICAgID4+IFRoZW4sIGFz c3VtZSB0aGF0IHRoZSBzZXZlciBzZW5kcyBhIG5vbi1jb25maXJtYWJsZSByZXNwb25zZSBtZXNz YWdlIHRvIHRoZSByZXF1ZXN0LiBBRkFJSywgdGhhdCBpcyBhbGxvd2VkLg0KICAgID4NCiAgICA+ IEFsbG93ZWQsIHllcywgYnV0IGFsc28gYSByYXRoZXIgdW51c3VhbCBjYXNlOiBUaGUgY2xpZW50 IHRvb2sgY2FyZSB0byBzZW5kIGEgY29uZmlybWFibGUgcmVxdWVzdCwgYW5kIHRoZSBzZXJ2ZXIg b25seSBhbnN3ZXJzIHVucmVsaWFibHkuICANCiAgICA+IFRoaXMgY29tYmluYXRpb24gbWFrZXMg dGhlIG1vc3Qgc2Vuc2UgZm9yIGFuIG9ic2VydmUtR0VULCB3aGVyZSB0aGUgc2VydmVyIGlzIHNl bmRpbmcgcGVyaW9kaWMgbm90aWZpY2F0aW9ucywgc28gdGhlIGxvc3Mgb2YgYSBzaW5nbGUgb25l IGlzIG5vdCByZWFsbHkgYSBiaWcgcHJvYmxlbS4NCg0KICAgIFdoZXRoZXIgaXQgaXMgYSBwcm9i bGVtIG9yIG5vdCBJIGd1ZXNzIGRlcGVuZHMgb24gdGhlIHVzZS1jYXNlLCBidXQgSSBhc3N1bWUg b25lIHdvdWxkIHVzZSBjb25maXJtYWJsZSByZXNwb25zZXMgaXQgaXMgY3JpdGljYWwgdG8gcmVj ZWl2ZSBlYWNoIG5vdGlmaWNhdGlvbi4NCg0KICAgIFExOg0KICAgICAgDQogICAgPj4gUGVyaGFw cyBJIGhhdmUgbWlzc2VkIGl0LCBJIGNhbuKAmXQgZmluZCBhbnkgdGV4dCBzYXlpbmcgdGhhdCB0 aGUgc2VydmVyIHdvdWxkIHJldHJhbnNtaXQgdGhlIHJlc3BvbnNlIG1lc3NhZ2UgaWYgaXQgcmVj ZWl2ZXMgYSByZXRyYW5zbWlzc2lvbiBvZiB0aGUgcmVxdWVzdC4gDQogICAgPg0KICAgID4gTm8s IGl0IHdvbuKAmXQuICBUaGUgY2xpZW50IHdpbGwgcmV0cmFuc21pdCBvbmx5IHVwIHRvIHJlY2Vp dmluZyBhbiBBQ0suDQoNCiAgICBDb3JyZWN0LCBzbyBpbiBub3JtYWwgc2l0dWF0aW9ucyB0aGUg c2VydmVyIHNob3VsZCBub3QgcmVjZWl2ZSByZXRyYW5zbWl0cyBvZiB0aGUgcmVxdWVzdCBvbmNl IGl0IHNlbmRzIHRoZSByZXNwb25zZS4gQnV0LCBpdCBjb3VsZCBoYXBwZW4gaWYgYSByZXF1ZXN0 IHJldHJhbnNtaXQgaGFzIGdvdCAic3R1Y2tlZCIgaW4gdGhlIG5ldHdvcmsgc29tZXdoZXJlLg0K DQogICAgPiBTaW5jZSB5b3VyIHNjZW5hcmlvIGFzc3VtZXMgbm9uLWNvbmZpcm1hYmxlIHJlc3Bv bnNlcywgdGhpcyBpbXBsaWVzIGEgc2VwYXJhdGUgcmVzcG9uc2UsIHNvIHRoZSBBQ0sgd2lsbCBi ZSBlbXB0eS4gIFRoZSBzZXJ2ZXIgY2FuIHRoZW4gc2VuZCwgYXQgbGVpc3VyZSwgDQogICAgPiBp dHMgcmVzcG9uc2U7IG5vIGZ1cnRoZXIgcmV0cmFubWlzc2lvbnMgd2lsbCB0YWtlIHBsYWNlLg0K DQogICAgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIGlmIHRoYXQgaXMgZXhwbGljaXRseSB3cml0 dGVuIGluIHRoZSBSRkMsIGJlY2F1c2UgaW4gbWFueSBvdGhlciBwcm90b2NvbHMgcmVjZWl2aW5n IGEgcmV0cmFuc21pdCBvZiBhIHJlcXVlc3QgKndpbGwqIHRyaWdnZXIgYSByZXRyYW5zbWl0IG9m IHRoZSByZXNwb25zZS4NCg0KICAgID4gKEEgd2VpcmQgY2FzZSBpcyB3aGVyZSBhbGwgQUNLcyBn ZXQgbG9zdCBhbmQgZmluYWxseSB0aGUgcmVzcG9uc2UgaW5kaWNhdGVzIHRvIHRoZSBjbGllbnQg dGhhdCB0aGUgcmVxdWVzdCBtdXN0IGhhdmUgYXJyaXZlZCwgc3RvcHBpbmcgcmV0cmFuc21pc3Np b24g4oCUIHNlZSBwZW51bHRpbWF0ZQ0KICAgID4gcGFyYWdyYXBoIG9mIDQuMi4gIFN0aWxsLCB0 aGUgbWVzc2FnZS1pZCBvZiBhbGwgcmV0cmFuc21pc3Npb25zIGlzIHRoZSBzYW1lLCBzbyBubyBh ZGRpdGlvbmFsIHJlc3BvbnNlIHdpbGwgYmUgZ2VuZXJhdGVkLikNCg0KICAgIElmIHRoZSBBQ0sg ZG9lcyBnZXQgbG9zdCwgYW5kIHRoZSBjbGllbnQgcmVjZWl2ZXMgdGhlIHJlc3BvbnNlLCB3aWxs IGl0IHN0b3AgcmV0cmFuc21pdHRpbmcgdGhlIHJlcXVlc3Q/DQoNCiAgICA+PiBTZWN0aW9uIDQu MyBkb2VzIHNheSB0aGF0IGEgc2VydmVyIG1heSBjaG9vc2UgdG8gdHJhbnNtaXQgbXVsdGlwbGUg Y29waWVzIG9mIGEgbm9uLWNvbmZpcm1hYmxlIG1lc3NhZ2UsIGJ1dCB0aGVyZSBpcyBubyB0ZXh0 IHNheWluZyB0aGF0DQogICAgPj4gc3VjaCB0cmFuc21pdHMgd291bGQgYmUgdHJpZ2dlcmVkIGJ5 IGEgcmV0cmFuc21pc3Npb24gb2YgdGhlIHJlcXVlc3QuDQogICAgPg0KICAgID4gVGhhdCBpcyBp bmRlZWQgbm90IGludGVuZGVkLiAgUmV0cmFuc21pc3Npb25zIGhhcHBlbiBhdCB0aGUgbWVzc2Fn ZSBsYXllci4gIFJlcXVlc3QvcmVzcG9uc2UgaXMgYSBsYXllciBhYm92ZSBhbmQgaXMgbm90IGNv bmNlcm5lZCB3aXRoIHJldHJhbnNtaXNzaW9ucy4NCg0KICAgIERldGVjdGluZyBvZiBhIHJlcXVl c3QgcmV0cmFuc21pdCBhbHNvIGhhcHBlbnMgYXQgdGhlIG1lc3NhZ2UgbGF5ZXIuDQoNCiAgICA+ PiBTZWN0aW9uIDQuNS4gZG9lcyBzYXk6DQogICAgPj4gIA0KICAgID4+ICAgICAg4oCcQSBzZXJ2 ZXIgbWlnaHQgcmVsYXggdGhlIHJlcXVpcmVtZW50IHRvIGFuc3dlciBhbGwgcmV0cmFuc21pc3Np b25zDQogICAgPj4gICAgICAgb2YgYW4gaWRlbXBvdGVudCByZXF1ZXN0IHdpdGggdGhlIHNhbWUg cmVzcG9uc2UgKFNlY3Rpb24gNC4yKSzigJ0NCiAgICA+DQogICAgPiBOb3cgeW91IGFyZSBiYWNr IHRvIHBpZ2d5YmFja2VkIHJlc3BvbnNlcy4NCg0KICAgIFRoYXQgaXMgbm90IG1lbnRpb25lZCBh bnl3aGVyZS4NCg0KICAgIEFuZCwgbm93IEkgYW0gYWxzbyBiYWNrIGF0IGFub3RoZXIgaXNzdWUg SSBoYWQ6IHNlbmRpbmcgcmV0cmFuc21pdHMgdGhhdCBhcmUgbm90IGlkZW50aWNhbCwgaGF2aW5n IG5vIGNsdWUgd2hldGhlciB0aGUgcmVtb3RlIHBlZXIgaXMgZ29pbmcgdG8gZGV0ZWN0IGl0Li4u DQogICAgIA0KICAgID4+IFdoZXJlIGRvZXMgU2VjdGlvbiA0LjIgdGFsayBhYm91dCBhbnN3ZXJp bmcgcmV0cmFuc21pc3Npb25zIG9mIGFuIGlkZW1wb3RlbnQgcmVxdWVzdCAob3IgYW55IHJlcXVl c3QsIGZvciB0aGF0IG1hdHRlcikgd2l0aCB0aGUgc2FtZSByZXNwb25zZT8NCiAgICA+DQogICAg Pkdvb2QgcXVlc3Rpb24uICBJbnRlcmVzdGluZy4NCiAgICAgDQogICAgIC0tLQ0KICAgICAgDQog ICAgUTI6DQogICAgICANCiAgICA+PiBSZWxhdGVkIHRvIFExLCBTZWN0aW9uIDQuNSBzYXlzOg0K ICAgID4+ICANCiAgICA+PiAgICAgICDigJ1Gb3IgZXhhbXBsZSwgYW4gaW1wbGVtZW50YXRpb24g bWlnaHQgd2FudCB0byBwcm9jZXNzIGR1cGxpY2F0ZQ0KICAgID4+ICAgICAgIHRyYW5zbWlzc2lv bnMgb2YgYSBHRVQsIFBVVCwgb3IgREVMRVRFIHJlcXVlc3QgYXMgc2VwYXJhdGUNCiAgICA+PiAg ICAgICByZXF1ZXN0cyBpZiB0aGUgZWZmb3J0IGluY3VycmVkIGJ5IGR1cGxpY2F0ZSBwcm9jZXNz aW5nIGlzIGxlc3MNCiAgICA+PiAgICAgICBleHBlbnNpdmUgdGhhbiBrZWVwaW5nIHRyYWNrIG9m IHByZXZpb3VzIHJlc3BvbnNlcyB3b3VsZCBiZS7igJ0NCiAgICA+PiAgDQogICAgPj4gIA0KICAg ID4+IE1heWJlIEkgbWlzdW5kZXJzdGFuZCB0aGlzIOKAnHByb2Nlc3MgYXMgc2VwYXJhdGUgcmVx dWVzdHPigJ0gdGhpbmcsIGJ1dDoNCiAgICA+PiAgDQogICAgPj4gRmlyc3QsIGl0IG1lYW5zIHRo YXQgZWFjaCByZXNwb25zZSBjb3VsZCBiZSBkaWZmZXJlbnQgZnJvbSB0aGUgcHJldmlvdXMgb25l LCBhbmQgdGhlIHNlbmRlciBvZiB0aGUgcmVxdWVzdCB3b3VsZCBoYXZlIHRvIHByb2Nlc3MgZWFj aCBvZiB0aGVtLg0KICAgID4NCiAgICA+IFRoZSBzZW5kZXIgaXMgbm90IHN1cHBvc2VkIHRvIHJl dHJhbnNtaXQgYSByZXF1ZXN0IGlmIGl0IGFscmVhZHkgcmVjZWl2ZWQgYSByZXNwb25zZS4NCiAg ICA+IE9mIGNvdXJzZSwgdGhlIHJldHJhbnNtaXNzaW9uIGFuZCB0aGUgcmVzcG9uc2UgbWlnaHQg Y3Jvc3M7IGluIHRoaXMgY2FzZSB0aGUgc3VwZXJmbHVvdXMgcmVzcG9uc2UgaXMgbm90IHVzZWQu DQoNCkJ1dCwgaWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgaW4gdGhpcyBjYXNlIHRoZSBzZXJ2 ZXIgZG9lcyBub3Qga25vdyB3aGV0aGVyIGEgcmVxdWVzdCBpcyBhIHJldHJhbnNtaXQgb3Igbm90 Lg0KICAgICANCiAgICA+PiBTZWNvbmQsIGRvZXMgdGhpcyBtZWFuIHRoYXQsIGlmIHRoZSByZXNw b25zZXMgYXJlIGNvbmZpcm1hYmxlLCB0aGUgc2VydmVyIHNob3VsZCBleHBlY3QgYW4gQUNLIGZv ciBlYWNoIHJlc3BvbnNlPyDigJxQcm9jZXNzIGFzIHNlcGFyYXRlIHJlcXVlc3Rz4oCdIG1ha2Vz IGl0IHNvdW5kIGxpa2UgdGhhdC4NCiAgICA+DQogICAgPklmIHRoZSByZXNwb25zZSBpcyBzZW50 IGFzIGEgY29uZmlybWFibGUgbWVzc2FnZSwgdGhlIHNlcnZlciBleHBlY3RzIGFuIEFDSyBmb3Ig aXQuICBJdCByZXRyYW5zbWl0cyB1bnRpbCBpdCBnZXRzIG9uZS4NCiAgICA+SWYgdGhlIHJlc3Bv bnNlIGlzIGluIGFuIEFDSywgaXQgaXMgbm90IGNvbmZpcm1hYmxlOyB0aGlzIGlzIHJlYWxseSB0 aGUgdXNlZnVsIGNhc2UgZm9yIOKAnHByb2Nlc3MgYXMgc2VwYXJhdGUgcmVxdWVzdHPigJ0uDQoN CkkgYW0gcmVmZXJyaW5nIHRvIHRoZSBzZXJ2ZXIuIElmIHRoZSBzZXJ2ZXIgcHJvY2Vzc2VzIGVh Y2ggcmV0cmFuc21pdCBhcyBhIHNlcGFyYXRlIHJlcXVlc3QsIGluIHRoZW9yeSBpdCBtaWdodCBt ZWFuIHRoYXQgZWFjaCBBQ0sgd2lsbCBiZSBkaWZmZXJlbnQgKHNpbmNlIHRoZSBzZXJ2ZXIgZG9l cyBub3Qga2VlcCB0cmFjayBvZiB0aGUgQUNLIHRyaWdnZXJlZCBieSB0aGUgcHJldmlvdXMgcmVx dWVzdCByZXRyYW5zbWl0KS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCiAgICANCiAgICANCg0K From nobody Mon Dec 2 01:58:12 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31F412004C for ; Mon, 2 Dec 2019 01:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=wL1oTDnA; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=VAYXTNM3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taFJaM9UHWQP for ; Mon, 2 Dec 2019 01:58:07 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0625.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::625]) (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 C623D120041 for ; Mon, 2 Dec 2019 01:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gvojItOdJw7vfDiodfcKxK45zmuN1rUZlRaKO9DiV7Q=; b=wL1oTDnA2VX5JfnJdjg5Di1c+7epNYw3ez3G1o8tl/OFxGKBnvEEif1wSDoVQKk+tXqOJYMxEJgIztOoYsJvSqdQNRY2+u5QKcvUkC3s6NSKibq5YstYDZf6caORPMp6wjy8d3ehU2Kc49rbChIo5tlsAKnjQL9R1rQi4dExOTY= Received: from AM6PR08CA0023.eurprd08.prod.outlook.com (2603:10a6:20b:b2::35) by VE1PR08MB4958.eurprd08.prod.outlook.com (2603:10a6:803:108::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.20; Mon, 2 Dec 2019 09:58:03 +0000 Received: from AM5EUR03FT013.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::202) by AM6PR08CA0023.outlook.office365.com (2603:10a6:20b:b2::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.18 via Frontend Transport; Mon, 2 Dec 2019 09:58:03 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT013.mail.protection.outlook.com (10.152.16.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.18 via Frontend Transport; Mon, 2 Dec 2019 09:58:02 +0000 Received: ("Tessian outbound 15590139dbb5:v37"); Mon, 02 Dec 2019 09:58:02 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 569a5d17df0a3aa5 X-CR-MTA-TID: 64aa7808 Received: from ebe6b5f25062.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 86FA0E4A-804A-4599-A77A-93419B4725F1.1; Mon, 02 Dec 2019 09:57:56 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id ebe6b5f25062.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 02 Dec 2019 09:57:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d4n70uVD6GQgnNviV+tOyF1pIEIlsQqPyDOxjyp+wlq3PI7hGKgneVth2g6sLo4ZiHOnIwcnPZxnU4TQcWPbExFvs28R4FIT1ylztyMOh1c6Bankuu1Q4EAsmAAkOa2hwOxZ/mALmFtg56RXBMYSm5TBZwAV4ZxqadlhQ8wfbjHYocTnpIq6F7PlQUbyvcgm1pItEMccA1c/kNWojwevPv34z+3FdxMrwV6oeFyUE9L0nhjkPInY15TGvZVQzJ9lIKbmCfJ+oOsllG+zTsYM3pW9NqpC9XtSx+X/azS3ehEVTB6K95YKKUJY/KMBOlTnyu6gWJWVm6EDiR/M9bqljg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VLQ4Po80lRCwM6RZ7dn1x8i2CtZXPrTbFWpavJHzkJg=; b=Zv90X03ndNKNQo+7szzLtlJ26vz+wGmxPK65i9lV2E8sUsc4PhikQ/n6XVDh8s1EBD0ay+uBMeYbliA7P9l8qE8HwtNNADWOW9h4cuG2Mm7o1Tk6GCvVabi2T5iJNoekQ17Pf5DDJuCBpMQPSIo6A9lT4fIOp4n2I9K3Ja7+86XuqpZTJHYXHrVH5X2YrtDg5GC/ZE+uxkRL7vz8VqFs6vQ4tyHiwu9KR/1KDa5PNPF5SWToacKBk8Myqnwns6nzlZxZ0gmdjOZ2SV3RXhKfLkiZxi/ClXhrrpte7I6HmwrdO/v1qrSRTy9uWlqYgpB2zqV8QP6YqEw+cdc10UQ+tg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VLQ4Po80lRCwM6RZ7dn1x8i2CtZXPrTbFWpavJHzkJg=; b=VAYXTNM36r9XxrQRACL+yJR4Lf+ECHwJuUmhnOQ7ImZ1ggu/QiSZ1fPX0AtWnNM76bq0INAJsfiWl/xQr4v434fhNBfnvROltIbZSDZHTDK8eYlBKhRZuHNjQMXG2Qv4qH1cB2piYQ5oQCakF/5Nf92z7B7r0lMyoPPKcDPKTW0= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (20.179.18.151) by AM6PR08MB3575.eurprd08.prod.outlook.com (20.177.114.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.18; Mon, 2 Dec 2019 09:57:55 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::e8f5:4b6f:34b7:47a4]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::e8f5:4b6f:34b7:47a4%7]) with mapi id 15.20.2495.014; Mon, 2 Dec 2019 09:57:55 +0000 From: Thomas Fossati To: James Nguyen , "core@ietf.org" Thread-Topic: [core] IETF 106 Meeting Notes Thread-Index: AQHVqLfNUNixCf9qJkKrHGr3oEov3KemnH4A Date: Mon, 2 Dec 2019 09:57:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [217.140.106.54] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 72804e0f-1adf-44c9-9d86-08d7770e1f05 X-MS-TrafficTypeDiagnostic: AM6PR08MB3575:|AM6PR08MB3575:|VE1PR08MB4958: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:3513;OLM:3513; x-forefront-prvs: 0239D46DB6 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(396003)(39860400002)(366004)(346002)(189003)(199004)(36756003)(53546011)(6306002)(76176011)(86362001)(66556008)(66476007)(64756008)(25786009)(66446008)(76116006)(66946007)(4744005)(6436002)(99286004)(7736002)(2501003)(6246003)(91956017)(316002)(4326008)(305945005)(6116002)(66066001)(3846002)(256004)(33656002)(2906002)(6512007)(5660300002)(186003)(229853002)(14454004)(8936002)(102836004)(6506007)(26005)(81166006)(966005)(71200400001)(446003)(11346002)(2616005)(6486002)(58126008)(110136005)(81156014)(71190400001)(8676002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3575; H:AM6PR08MB4231.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: ryd0ymNX9j+lkFMw7oQPbRcdlUzyM5Hvp//rKu4a/NxWWTiJR9mxqb5JohOwt5jQE+qzwyeRfq3N9Rd63lMxBEPzDPXAuFXpcdlr3A1/V3ANwA3k94RnUVRlgLoAvQ9WVjuU1xhQ6+fC+SHkuuXFgU2OwCJtAGDQTssEJVyWf3clM5A62Q2+eEbqoQlhFuDowGiK+xn66I2E35EDxmzDw2atCN7rYgw9bvsA5BOj0SmTAsghvCnlu20/T1LdL6zLpmZxPVZPpf3W0lkgk3eLREIZ+I9MYTGtYO4TvDwf2fhitX+yPxsYUQipx6Kt23kKSmbjzQK6xvHlnWFySCV/yB4A7b6boJVrL2bPgDGb2bWyeYL/OHujpwK0Rkw8cCDEiex9s7QI6GXL3l/sIJAyEYiIxvWs+LrsSjtnhpdV3XHbEYaDAVOEuMUzxkldOOMf/fn3bKdG9opm9M/4mBh2LmzRrLrjy5+uZkz5iazpuTw= Content-Type: text/plain; charset="utf-8" Content-ID: <5D605800E015284D857CB5CFD5A439EF@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3575 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT013.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(346002)(376002)(396003)(199004)(189003)(40434004)(966005)(4744005)(316002)(110136005)(58126008)(229853002)(33656002)(14454004)(8676002)(81166006)(8936002)(81156014)(356004)(26826003)(99286004)(66066001)(25786009)(6486002)(6246003)(36906005)(106002)(4326008)(5024004)(14444005)(478600001)(47776003)(6306002)(446003)(436003)(102836004)(6506007)(53546011)(186003)(26005)(336012)(86362001)(2616005)(11346002)(70206006)(76176011)(6512007)(50466002)(22756006)(23676004)(2486003)(2906002)(3846002)(6116002)(305945005)(5660300002)(2501003)(7736002)(36756003)(70586007)(76130400001); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR08MB4958; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: 1b6ff2b6-9b4c-41b3-9e89-08d7770e1a60 X-Forefront-PRVS: 0239D46DB6 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 6doIOpFF7aB6ZDJS5jf0w/A4rAjr/Dki57ft+YYBVQFS11q3KYs3Ztv3P467lZO273EkbQE0lj3yBdQyy+3C5wgS+QXzwxtkI3TsfjMJLGBhzZrnOzhEhPbe//KBmuPARfH0MYnEA00hrpq8puLB/UwRb9s7/rfdT5S91auvud7fTum7AYnQUJa1pT4fKOppNl8TYAac1xtQpBnToVmMex2yxcErpiCJ1yCQ9zQnKg9tCzhx2trmlQ9o6awTqqfaNqhwRiGzSMLk3HvDvMtrRSE0cPIzfRxG0cgxESfTXEG4140nquw13NiD6HoL17wTTUKnUgm8Mn1FcE7pJC/TX8yo6S2Y4pXQdVa+c9MGPIUGYOiCpPgk5yOtz1QyqMiOXEFkqDmm1QrsRRMQA2TBKiFsz9a2tGas7wcYeLDsK8kdGwqoDRWb83qRzdCc9mydc/vfqwKCdhSdyuBZ8/q+3C+rJOTkyukW5i/unbO39P0= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2019 09:58:02.9303 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 72804e0f-1adf-44c9-9d86-08d7770e1f05 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB4958 Archived-At: Subject: Re: [core] IETF 106 Meeting Notes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 09:58:11 -0000 SGkgSmFtZXMsDQoNCk9uIDAyLzEyLzIwMTksIDAyOjI1IEphbWVzIE5ndXllbiB3cm90ZToNCj4g QXJlIHRoZSBJRVRGIDEwNiBtZWV0aW5nIG5vdGVzIGF2YWlsYWJsZSBmb3Igdmlld2luZz8NCg0K VGhlIG9mZmljaWFsIG1lZXRpbmcgbWF0ZXJpYWxzIFsxXSBhcmUgbm90IG91dCB5ZXQsIGJ1dCB5 b3UgY2FuDQp0YWtlIGEgbG9vayBhdCBbMl0gdG8gZ2V0IGFuIGlkZWEuDQoNCihCb3RoIHNlc3Np b25zIGFyZSBhbHNvIGF2YWlsYWJsZSBvbiBZVCAtLSBzZWFyY2ggZm9yICJpZXRmIDEwNiBjb3Jl Ii4pDQoNCkNoZWVycw0KDQpbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5n LzEwNi9tYXRlcmlhbHMNClsyXSBodHRwczovL2V0aGVycGFkLmlldGYub3JnL3Avbm90ZXMtaWV0 Zi0xMDYtY29yZQ0KDQoNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMg ZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBi ZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUg Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Ig c3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Mon Dec 2 07:58:12 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E202120882 for ; Mon, 2 Dec 2019 07:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 4X3lXKYDr-OM for ; Mon, 2 Dec 2019 07:58:06 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00047.outbound.protection.outlook.com [40.107.0.47]) (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 84CD112088C for ; Mon, 2 Dec 2019 07:58:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MQAd3/S02e5p3eJikO1G2zGYKWN0TgbmgOXj2/dl8DmUUnaHBmZEqrfhiln7v64tc501LRjLmGElQtw6yWInUVfOHQlfjHwXDD6h6RYI4XldsM5jtKROGYJ1IQKkiQIgIWd15boGWwlDHzbkn7h1CtyW0ME/QVWSzkR6A1smFG1KzL6ySa2uBZcOTwXv+JBde5zP9OLUg8MtRMxUjsTVBF+tYxYYdb0y2JN7YzibluclOZSkhrr27aysB45nWlrdP1Vmo1v4aizGevLfUqNRLnsVrGfmqe9CTuRjJRW/5+eKtWJpiTE+dipwLFub90s/z1QfPx9P0bKiT9ZrlS0lNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hmGN1ZDVqPiKfFW9brj4wtnBO1mEybb8qMwLfDFNW3w=; b=Y2vOc3WzFg0QWZU8/Dvbte06ac4eZYiqmaTVefkqLb4yHlRgGsI72HYLoW8KtBS5A6LdfcVWeYqDDH5/O7y4j3GmusPNUtUXUZz5rqRhx2n6qeOkELZOqDJS8WZ7wT9lEgASpOuyPeDMMKEnvMcBkFAGgLyJ0RX+TcJ2kcR0RCjOBrY2jDGy8YK7Xxo+Gz/FkG1h0bMX1biKgqTyd0t31nLy0sK9Cn7w/63hPR15qdM6n9W4/q6P9PI0YCaatJvUrzvMHQm1EHiJCqgUZQ1g4enKxHtem6HipIvt4w2h765YT7NDHGGO2s2aRXpZS/e5zui3ZqGNrdH3U8nuV3ArtQ== 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=hmGN1ZDVqPiKfFW9brj4wtnBO1mEybb8qMwLfDFNW3w=; b=Fv4cJ7qQjLMvPQY1+LWaCE0ZEIsB6wDvLJkecLhAB8Gu1rfZj+4ugBoHUJSW0vKDlSMby9wJwXLxVXOLe3m+7B07E3SqIhVHK3FF1e4m/8aHeUvHodlZz8qFEhvde0vH4HAT188+7zARDjL+9WAHwJ4Dpr/TlJtipQf3qBr/YiI= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3436.eurprd07.prod.outlook.com (10.170.242.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.6; Mon, 2 Dec 2019 15:58:04 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::2ca9:414:cc01:9706]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::2ca9:414:cc01:9706%4]) with mapi id 15.20.2516.003; Mon, 2 Dec 2019 15:58:04 +0000 From: Christer Holmberg To: "Kraus Achim (INST/ECS4)" CC: "core@ietf.org" , Carsten Bormann Thread-Topic: [core] Retransmission of non-confirmable response message upon receiving request message retranmission? Thread-Index: AQHVppE/OetFI+DdS0KoPWGUqntDGKeiDkmAgAADTICABRVdgA== Date: Mon, 2 Dec 2019 15:58:03 +0000 Message-ID: <96A29F25-2555-4542-875A-F1B8194CC254@ericsson.com> References: <41889A1F-ACC3-458B-B57F-503A55D1D2A3@ericsson.com> <09a7f0f318dc4f45a3cdd7791b28ecdd@bosch-si.com> In-Reply-To: <09a7f0f318dc4f45a3cdd7791b28ecdd@bosch-si.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 262ed02f-e100-4df9-cd36-08d777406a4e x-ms-traffictypediagnostic: HE1PR07MB3436: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(136003)(396003)(366004)(39860400002)(199004)(189003)(5660300002)(8676002)(58126008)(316002)(54906003)(446003)(99286004)(14444005)(6436002)(2906002)(15650500001)(66066001)(2616005)(11346002)(229853002)(256004)(6486002)(44832011)(36756003)(86362001)(8936002)(71200400001)(81156014)(478600001)(81166006)(33656002)(66574012)(966005)(71190400001)(305945005)(91956017)(7736002)(76176011)(66476007)(6246003)(64756008)(3846002)(76116006)(25786009)(66556008)(4326008)(66946007)(6116002)(102836004)(26005)(14454004)(53546011)(6506007)(6306002)(66446008)(6512007)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3436; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LKIP6Sf+kfcXc/+Fxci7Q2WGtVrZQL+h/uN8GVaAZpxrVaUwMMv0sAtQx17Q1bvoNTlsk4xredB1p1yfQGHUUYpaNRKlVI+z/QyAaXNOM36+3rxZo9dD4hfjTEZTTcc2yKHtrvz/gdtIj1kFu6CH4H9HkAnI2tpkEQ61itE46aIDh1EwaUMhpXFRMZVUuBY/RERKQ9h7Q3qr0RicK4YA3022ekKfFpIkChQ+PXWop6/jJ8hO4tgYZSbrQzoR7C0gDvggOqvrpaGQOuTV0mu16Ao7pSKlNYm+ahH1n+j3q+AnNwGlUxRpXmoCLX0bWjEhFO82hRAoK9YQMU9+hK24EPaPpbLfcBBqXWUzDeZbEHWeip6JMGn0LcMDGDMLyMjeMMZLZd5wmM0mdux13RNXa2ilndL1FH9V6yN0dFH3fkkomFNlt4Vv+gExrgivOCXa9tjC+SUEU+y63QEDFIW8Ke7zLuJeRc4qkZ8thwDBMtg= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <101DCC9A008EAB4ABB1A5800833F56D7@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 262ed02f-e100-4df9-cd36-08d777406a4e X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2019 15:58:04.0146 (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: gZHJ9IVK+pJdyKf/7NxyZAPPVMtSEp27VgVJNE3odJlbY8hJuUmQd2TXfUZsdw1dxxbOEoVSHV5lBvl7gF1+ZAqObW4xRivHmhui1MjgcOY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3436 Archived-At: Subject: Re: [core] Retransmission of non-confirmable response message upon receiving request message retranmission? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 15:58:10 -0000 SGkgS3JhdXMsDQogICAgDQo+ICAgIFNlY3Rpb24gNCBpcyBhYm91dCB0cmFuc21pc3Npb24gKENP TiwgTk9OLEFDSyBhbmQgUlNUKSwgYW5kIG9ubHkgc2xpZ2h0IHJlZmVyIHRvIHNlY3Rpb24gNSAo cmVxdWVzdC9yZXNwb25zZSkuIEZvciB0aGF0IEZNUE9WIGl0IHNlZW1zIHRvIGJlIGNsZWFyLCB0 aGF0IA0KPiAgICBpZiBhIHJldHJhbnNtaXNzaW9uIGlzIGRldGVjdGVkLCB0aGUgcmVjZWl2ZXIg c2hvdWxkIGRvIGl0cyBiZXN0IHRoZSBzZW5kIGJhY2sgdGhlIHNhbWUgYW5zd2VyLCBpbiB5b3Vy IGNhc2UgdGhlIGVtcHR5IEFDSy4gDQo+DQo+ICAgIEluIG15IGludGVycHJldGF0aW9uIG9mIFNl Y3Rpb24gNC41IHRoZSBpbnRlbnRpb24gaXMsIHRoYXQgdGhlIHJldHJhbnNtaXNzaW9uIHNob3Vs ZCBiZSBoYW5kbGVkIGJlc3Qgb24gdGhlIHRyYW5zbWlzc2lvbiBsYXllciBhbmQgc2hvdWxkIG5v dCBiZSB2aXNpYmxlL2ZvcndhcmRlZA0KPiAgICB0byB0aGUgcmVxdWVzdC9yZXNwb25zZSBsYXll ci4gVGhhdCBtYXliZSByZWxheGVkLCBpZiB0aGUgb3V0Y29tZSBpcyB0aGUgc2FtZSBvciBzaG93 cyBvbmx5IGFjY2VwdGFibGUgZGlmZmVyZW5jZS4gR2VuZXJhbGx5LCB0aGUgbWVzc2FnZXMgKGZs aWdodCkgb2YgdGhlIG9yaWdpbmFsDQo+ICAgIGFuc3dlciBhcmUgaW50ZW5kZWQgdG8gYmUgcmV0 cmFuc21pdHRlZC4NCg0KSG93IGRvZXMgdGhlIHN0YWNrIGtub3cgaWYgdGhlIG91dGNvbWUgd2ls bCBiZSB0aGUgc2FtZT8gDQoNCkFuZCwgd2hhdCBpcyB0aGUgZGVmaW5pdGlvbiBvZiAiYWNjZXB0 YWJsZSBkaWZmZXJlbmNlIj8NCg0KPiAgICBTZWN0aW9uIDUgaXMgdGhlbiBhYm91dCB0aGUgcmVx dWVzdC9yZXNwb25zZSA1LjIuMiwgcGFnZSAzNCAodG9wKSwgIklmIGEgcmV0cmFuc21pdHRlZCBy ZXF1ZXN0IGlzIHJlY2VpdmVkIChwZXJoYXBzIGJlY2F1c2UgdGhlIG9yaWdpbmFsDQo+ICAgIEFj a25vd2xlZGdlbWVudCB3YXMgZGVsYXllZCksIGFub3RoZXIgRW1wdHkgQWNrbm93bGVkZ2VtZW50 IGlzIHNlbnQsIGFuZCBhbnkgcmVzcG9uc2UgTVVTVCBiZSBzZW50IGFzIGEgc2VwYXJhdGUgcmVz cG9uc2UuIg0KPiAgICBUaGF0IHNlZW0gdG8gcG9pbnQgdG8gdGhlIHNhbWUgaW50ZW50aW9uOiBy ZXRyYW5zbWl0IHRoZSBvcmlnaW5hbCBtZXNzYWdlcyAoZmxpZ2h0KSBhcyBhbnN3ZXIuDQogIA0K SSBhbSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5ICJvcmlnaW5hbCBtZXNzYWdlIGFzIGFuc3dl ciIuIEFyZSB5b3UgcmVmZXJyaW5nIHRvIGFuIEFDSywgb3IgdG8gYSByZXNwb25zZSBtZXNzYWdl Pw0KICAgIA0KPiAgICBRMS4gIlBlcmhhcHMgSSBoYXZlIG1pc3NlZCBpdCIgPT4gSSB0aGluayBw YWdlIDM0IHRvcCBzcGVjaWZpZXMgdGhhdC4NCiAgDQpXaGVyZT8NCg0KSSBjYW4gb25seSBmaW5k IHRleHQgc2F5aW5nIHRoYXQgYW5vdGhlciBBQ0sgaXMgc2VudCBpcyBhIHJlcXVlc3QgcmV0cmFu c21pdCBpcyByZWNlaXZlZC4NCiAgIA0KPiAgICBRMjogVGhhdCdzIHRoZSByZXNwb25zaWJpbGl0 eSBvZiB0aGUgYXBwbGljYXRpb24gdG8gY2hvb3NlIHRoZSByaWdodCB0cmFkZW9mZiBiZXR3ZWVu IHJlc291cmNlcyBjb25zdW1wdGlvbiBhbmQgY29tcGx5aW5nIHRvIHRoZSBleHBlY3RhdGlvbnMu DQo+ICAgIElmIHRoZSBkaWZmZXJlbmNlIGlzIGxhcmdlciwgeW91ciBhcHBsaWNhdGlvbiBtdXN0 IGJlIGRlc2lnbmVkIGZvciB0aGF0LiANCiAgDQpUaGUgaXNzdWUgaXMgdGhhdCB0aGUgcmVzcG9u c2VzIG1heSBub3QgYmUgaWRlbnRpY2FsLCBhcyB0aGUgc2VydmVyIGRvZXMgbm90IGtlZXAgdHJh Y2sgb2YgcHJldmlvdXNseSBzZW50IHJlc3BvbnNlcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0KDQogICAgDQogICAgLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KICAgIFZv bjogY29yZSA8Y29yZS1ib3VuY2VzQGlldGYub3JnPiBJbSBBdWZ0cmFnIHZvbiBDYXJzdGVuIEJv cm1hbm4NCiAgICBHZXNlbmRldDogRnJlaXRhZywgMjkuIE5vdmVtYmVyIDIwMTkgMTM6MDgNCiAg ICBBbjogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnPTQwZXJpY3Nzb24uY29t QGRtYXJjLmlldGYub3JnPg0KICAgIENjOiBjb3JlQGlldGYub3JnDQogICAgQmV0cmVmZjogUmU6 IFtjb3JlXSBSZXRyYW5zbWlzc2lvbiBvZiBub24tY29uZmlybWFibGUgcmVzcG9uc2UgbWVzc2Fn ZSB1cG9uIHJlY2VpdmluZyByZXF1ZXN0IG1lc3NhZ2UgcmV0cmFubWlzc2lvbj8NCiAgICANCiAg ICBIaSBDaHJpc3RlciwNCiAgICANCiAgICA+IE9uIE5vdiAyOSwgMjAxOSwgYXQgMDk6NDQsIENo cmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZz00MGVyaWNzc29uLmNvbUBkbWFyYy5p ZXRmLm9yZz4gd3JvdGU6DQogICAgPiANCiAgICA+IEhpLA0KICAgID4gIA0KICAgID4gQSBjb3Vw bGUgb2YgcXVlc3Rpb25zIGZvciBjbGFyaWZpY2F0aW9uLg0KICAgID4gIA0KICAgID4gIA0KICAg ID4gQXNzdW1lIGEgQ29BUCBzZXJ2ZXIgcmVjZWl2ZXMgYSBjb25maXJtYWJsZSByZXF1ZXN0IG1l c3NhZ2UuDQogICAgPiAgDQogICAgPiBBY2NvcmRpbmcgdG8gU2VjdGlvbiA0LjUuIG9mIFJGQyA3 MjUyLCB0aGUgc2VydmVyIFNIT1VMRCByZXRyYW5zbWl0IHRoZSBhc3NvY2lhdGVkIEFDSyB3aGVu ZXZlciBpdCByZWNlaXZlcyBhIHJldHJhbnNtaXNzaW9uIG9mIHRoZSByZXF1ZXN0IG1lc3NhZ2Uu IFNvIGZhciwgc28gZ29vZC4NCiAgICA+ICANCiAgICA+IFRoZW4sIGFzc3VtZSB0aGF0IHRoZSBz ZXZlciBzZW5kcyBhIG5vbi1jb25maXJtYWJsZSByZXNwb25zZSBtZXNzYWdlIHRvIHRoZSByZXF1 ZXN0LiBBRkFJSywgdGhhdCBpcyBhbGxvd2VkLg0KICAgIA0KICAgIEFsbG93ZWQsIHllcywgYnV0 IGFsc28gYSByYXRoZXIgdW51c3VhbCBjYXNlOiBUaGUgY2xpZW50IHRvb2sgY2FyZSB0byBzZW5k IGEgY29uZmlybWFibGUgcmVxdWVzdCwgYW5kIHRoZSBzZXJ2ZXIgb25seSBhbnN3ZXJzIHVucmVs aWFibHkuICBUaGlzIGNvbWJpbmF0aW9uIG1ha2VzIHRoZSBtb3N0IHNlbnNlIGZvciBhbiBvYnNl cnZlLUdFVCwgd2hlcmUgdGhlIHNlcnZlciBpcyBzZW5kaW5nIHBlcmlvZGljIG5vdGlmaWNhdGlv bnMsIHNvIHRoZSBsb3NzIG9mIGEgc2luZ2xlIG9uZSBpcyBub3QgcmVhbGx5IGEgYmlnIHByb2Js ZW0uDQogICAgDQogICAgDQogICAgPiAtLS0NCiAgICA+ICANCiAgICA+IFExOg0KICAgID4gIA0K ICAgID4gUGVyaGFwcyBJIGhhdmUgbWlzc2VkIGl0LCBJIGNhbuKAmXQgZmluZCBhbnkgdGV4dCBz YXlpbmcgdGhhdCB0aGUgc2VydmVyIHdvdWxkIHJldHJhbnNtaXQgdGhlIHJlc3BvbnNlIG1lc3Nh Z2UgaWYgaXQgcmVjZWl2ZXMgYSByZXRyYW5zbWlzc2lvbiBvZiB0aGUgcmVxdWVzdC4gDQogICAg DQogICAgTm8sIGl0IHdvbuKAmXQuICBUaGUgY2xpZW50IHdpbGwgcmV0cmFuc21pdCBvbmx5IHVw IHRvIHJlY2VpdmluZyBhbiBBQ0suDQogICAgU2luY2UgeW91ciBzY2VuYXJpbyBhc3N1bWVzIG5v bi1jb25maXJtYWJsZSByZXNwb25zZXMsIHRoaXMgaW1wbGllcyBhIHNlcGFyYXRlIHJlc3BvbnNl LCBzbyB0aGUgQUNLIHdpbGwgYmUgZW1wdHkuICBUaGUgc2VydmVyIGNhbiB0aGVuIHNlbmQsIGF0 IGxlaXN1cmUsIGl0cyByZXNwb25zZTsgbm8gZnVydGhlciByZXRyYW5taXNzaW9ucyB3aWxsIHRh a2UgcGxhY2UuDQogICAgDQogICAgKEEgd2VpcmQgY2FzZSBpcyB3aGVyZSBhbGwgQUNLcyBnZXQg bG9zdCBhbmQgZmluYWxseSB0aGUgcmVzcG9uc2UgaW5kaWNhdGVzIHRvIHRoZSBjbGllbnQgdGhh dCB0aGUgcmVxdWVzdCBtdXN0IGhhdmUgYXJyaXZlZCwgc3RvcHBpbmcgcmV0cmFuc21pc3Npb24g 4oCUIHNlZSBwZW51bHRpbWF0ZSBwYXJhZ3JhcGggb2YgNC4yLiAgU3RpbGwsIHRoZSBtZXNzYWdl LWlkIG9mIGFsbCByZXRyYW5zbWlzc2lvbnMgaXMgdGhlIHNhbWUsIHNvIG5vIGFkZGl0aW9uYWwg cmVzcG9uc2Ugd2lsbCBiZSBnZW5lcmF0ZWQuKQ0KICAgIA0KICAgID4gU2VjdGlvbiA0LjMgZG9l cyBzYXkgdGhhdCBhIHNlcnZlciBtYXkgY2hvb3NlIHRvIHRyYW5zbWl0IG11bHRpcGxlIGNvcGll cyBvZiBhIG5vbi1jb25maXJtYWJsZSBtZXNzYWdlLCBidXQgdGhlcmUgaXMgbm8gdGV4dCBzYXlp bmcgdGhhdCBzdWNoIHRyYW5zbWl0cyB3b3VsZCBiZSB0cmlnZ2VyZWQgYnkgYSByZXRyYW5zbWlz c2lvbiBvZiB0aGUgcmVxdWVzdC4NCiAgICANCiAgICBUaGF0IGlzIGluZGVlZCBub3QgaW50ZW5k ZWQuICBSZXRyYW5zbWlzc2lvbnMgaGFwcGVuIGF0IHRoZSBtZXNzYWdlIGxheWVyLiAgUmVxdWVz dC9yZXNwb25zZSBpcyBhIGxheWVyIGFib3ZlIGFuZCBpcyBub3QgY29uY2VybmVkIHdpdGggcmV0 cmFuc21pc3Npb25zLg0KICAgICANCiAgICA+IFNlY3Rpb24gNC41LiBkb2VzIHNheToNCiAgICA+ ICANCiAgICA+ICAgICAg4oCcQSBzZXJ2ZXIgbWlnaHQgcmVsYXggdGhlIHJlcXVpcmVtZW50IHRv IGFuc3dlciBhbGwgcmV0cmFuc21pc3Npb25zDQogICAgPiAgICAgICBvZiBhbiBpZGVtcG90ZW50 IHJlcXVlc3Qgd2l0aCB0aGUgc2FtZSByZXNwb25zZSAoU2VjdGlvbiA0LjIpLOKAnQ0KICAgIA0K ICAgIE5vdyB5b3UgYXJlIGJhY2sgdG8gcGlnZ3liYWNrZWQgcmVzcG9uc2VzLg0KICAgICANCiAg ICA+IFdoZXJlIGRvZXMgU2VjdGlvbiA0LjIgdGFsayBhYm91dCBhbnN3ZXJpbmcgcmV0cmFuc21p c3Npb25zIG9mIGFuIGlkZW1wb3RlbnQgcmVxdWVzdCAob3IgYW55IHJlcXVlc3QsIGZvciB0aGF0 IG1hdHRlcikgd2l0aCB0aGUgc2FtZSByZXNwb25zZT8NCiAgICANCiAgICBHb29kIHF1ZXN0aW9u LiAgSW50ZXJlc3RpbmcuDQogICAgIA0KICAgID4gLS0tDQogICAgPiAgDQogICAgPiBRMjoNCiAg ICA+ICANCiAgICA+IFJlbGF0ZWQgdG8gUTEsIFNlY3Rpb24gNC41IHNheXM6DQogICAgPiAgDQog ICAgPiAgICAgICDigJ1Gb3IgZXhhbXBsZSwgYW4gaW1wbGVtZW50YXRpb24gbWlnaHQgd2FudCB0 byBwcm9jZXNzIGR1cGxpY2F0ZQ0KICAgID4gICAgICAgdHJhbnNtaXNzaW9ucyBvZiBhIEdFVCwg UFVULCBvciBERUxFVEUgcmVxdWVzdCBhcyBzZXBhcmF0ZQ0KICAgID4gICAgICAgcmVxdWVzdHMg aWYgdGhlIGVmZm9ydCBpbmN1cnJlZCBieSBkdXBsaWNhdGUgcHJvY2Vzc2luZyBpcyBsZXNzDQog ICAgPiAgICAgICBleHBlbnNpdmUgdGhhbiBrZWVwaW5nIHRyYWNrIG9mIHByZXZpb3VzIHJlc3Bv bnNlcyB3b3VsZCBiZS7igJ0NCiAgICA+ICANCiAgICA+ICANCiAgICA+IE1heWJlIEkgbWlzdW5k ZXJzdGFuZCB0aGlzIOKAnHByb2Nlc3MgYXMgc2VwYXJhdGUgcmVxdWVzdHPigJ0gdGhpbmcsIGJ1 dDoNCiAgICA+ICANCiAgICA+IEZpcnN0LCBpdCBtZWFucyB0aGF0IGVhY2ggcmVzcG9uc2UgY291 bGQgYmUgZGlmZmVyZW50IGZyb20gdGhlIHByZXZpb3VzIG9uZSwgYW5kIHRoZSBzZW5kZXIgb2Yg dGhlIHJlcXVlc3Qgd291bGQgaGF2ZSB0byBwcm9jZXNzIGVhY2ggb2YgdGhlbS4NCiAgICANCiAg ICBUaGUgc2VuZGVyIGlzIG5vdCBzdXBwb3NlZCB0byByZXRyYW5zbWl0IGEgcmVxdWVzdCBpZiBp dCBhbHJlYWR5IHJlY2VpdmVkIGEgcmVzcG9uc2UuDQogICAgT2YgY291cnNlLCB0aGUgcmV0cmFu c21pc3Npb24gYW5kIHRoZSByZXNwb25zZSBtaWdodCBjcm9zczsgaW4gdGhpcyBjYXNlIHRoZSBz dXBlcmZsdW91cyByZXNwb25zZSBpcyBub3QgdXNlZC4NCiAgICAgDQogICAgPiBTZWNvbmQsIGRv ZXMgdGhpcyBtZWFuIHRoYXQsIGlmIHRoZSByZXNwb25zZXMgYXJlIGNvbmZpcm1hYmxlLCB0aGUg c2VydmVyIHNob3VsZCBleHBlY3QgYW4gQUNLIGZvciBlYWNoIHJlc3BvbnNlPyDigJxQcm9jZXNz IGFzIHNlcGFyYXRlIHJlcXVlc3Rz4oCdIG1ha2VzIGl0IHNvdW5kIGxpa2UgdGhhdC4NCiAgICAN CiAgICBJZiB0aGUgcmVzcG9uc2UgaXMgc2VudCBhcyBhIGNvbmZpcm1hYmxlIG1lc3NhZ2UsIHRo ZSBzZXJ2ZXIgZXhwZWN0cyBhbiBBQ0sgZm9yIGl0LiAgSXQgcmV0cmFuc21pdHMgdW50aWwgaXQg Z2V0cyBvbmUuDQogICAgSWYgdGhlIHJlc3BvbnNlIGlzIGluIGFuIEFDSywgaXQgaXMgbm90IGNv bmZpcm1hYmxlOyB0aGlzIGlzIHJlYWxseSB0aGUgdXNlZnVsIGNhc2UgZm9yIOKAnHByb2Nlc3Mg YXMgc2VwYXJhdGUgcmVxdWVzdHPigJ0uDQogICAgDQogICAgR3LDvMOfZSwgQ2Fyc3Rlbg0KICAg IA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog ICAgY29yZSBtYWlsaW5nIGxpc3QNCiAgICBjb3JlQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQogICAgDQoNCg== From nobody Mon Dec 2 11:16:50 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81D5120018 for ; Mon, 2 Dec 2019 11:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.073, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrZUv05NhpSy for ; Mon, 2 Dec 2019 11:16:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2841D120045 for ; Mon, 2 Dec 2019 11:16:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575314199; bh=BE6kN80iDgq65o70sg/e8YuCrIYjN4fi3dikIZSs0vM=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Z0BIKlKK42AcIiU3fwRlK9rFXs878p6hQXkSp/E2ZDIC9sOxxk4T0455DH82JFbe9 gqmwkuC9/PV6Tv+kiI2p0bRd+R/JsH5EkBIMHtpIuxigoozuiKp4VTo6BkBy1NqvWw p6MT6Ff3zH2LqHyNIy5g/GPlAlzilfGQzFckevbY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([178.2.219.226]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MGz1V-1iXiBo1nEJ-00E7N7; Mon, 02 Dec 2019 20:16:39 +0100 To: Christer Holmberg Cc: "core@ietf.org" References: <41889A1F-ACC3-458B-B57F-503A55D1D2A3@ericsson.com> <09a7f0f318dc4f45a3cdd7791b28ecdd@bosch-si.com> <96A29F25-2555-4542-875A-F1B8194CC254@ericsson.com> From: Achim Kraus Message-ID: Date: Mon, 2 Dec 2019 20:16:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <96A29F25-2555-4542-875A-F1B8194CC254@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Lqcj9YuQ7LGrtfTGZu8KRLo3w+eDViW5v2FpfEEplmQAHolWHIT LdIqotrf52RsBGqh8P1BNQwmaww+h6Y7v98J8LqUZpCJF/r6uvWCe6sIl8TiCT2rU/26WKg vzs23gpsy9JpK9gLfTwep5JGvTrncJHWzNKIZeRB/9+NX2ZqHLoiIeUN2gyo8Lo2sO2obmD 9qWA48Ld40x3kNLA2NKaw== X-UI-Out-Filterresults: notjunk:1;V03:K0:1iWaeo9Dyrg=:3XOgvOsTyin3+ixArVnb5w urashTo0dA7NGbUBXKg+z3L1xjYnpduQWj0Png+g+l/8AqXup9yZNCmuMDz5kIoZk6EiyRG2u dTUhesRqqQN8weIlUwHImrAxwD3fJd6Xbso0dM6UQvlWHJrOrh9HpV1eKIM0iw/rx8yklkeJI +kuD2AN/afzKQvLIfTk1WMGlol4QghRdr2gj7ok5A/N39kLOYJGLAPWY7Ixz8f8cwpVzN2Twg b6nppJ1sAcjmRQAB5QwS0YTE0CSG7dTPJrJrd+TSovyVFBvjr0KRzUcAxM93s9TjwZt+nPqUq Onr8oZjfgbsty+hz74qTFw/bJG/NjiloG3X0i2p1vgGkShCjr9aKoJVXLur/aDiJBvU8BRdQN mLo/Ot7/wJrqhBJRgzRG9aa6n1DUYzPnanVqbWUzbQACP0l5YpnacWj9LbM8WDGPIyIFeTPJ/ 86rZbD4Uls24Gpck8DVrxuXEeEila8i9AFwCAeIWbaoMxByRscZrmrF5vlCWw6sacr950XJVu eGrd+lHtwiM/jbE7B2GiyobiZAaBCO5vYCNq3yII6OcHBkHILlPxUpMaA5j/Li+QG0q0XUHh/ wrgUPpNTMQFNByReXqHKrgQC7wX8II3R/8iBbBzQKKG1/d0oMe+iQMJ+ow65lA9RAsNXkmyPZ ILRog1RsHWuEyW7YxfALoN7HdP+7TiTpzUlc28iHiQ9zYQ8z3JKqEryWFAd/ED/JGu/Ip2d5A ZUWLzVh8Emqu170Ayld7yI3DWAA7TkE1Y5RNl8Uw3Sq/PBI6XJjlGpK7AdEOZSNCXncuDznxP 2oxBHIJ3PW27KtMeU/44lKZhE/RtJnNH2AqtVoxq+57OqwAtHkHfFGCeW08CwUsyz0nd9H323 4d4swM7lUp5vvgjArHlTOoTTVmgQx5Zy/StTU0outrxvO8jHguWULAgLOkjasI5MUb/nVLwLQ mIRcay68usJ1VbMiOjeWhD8ol2Kc3bY+nFSljNSmSxtXsco98nxnxJdfEil5gnwbwq8o14sDE Sz7pImU8CfZOoc6krZtyT/Rvo0Gnd8+dKAS84owqB++SQ6mbGBPCbIqkqcqGz9VpGci65RH4K vyygnxJ1v5YFBa8q26uq4RKEKvKZ5C3KOFdgFLPvvIaZP5nWrxAm65IYJWhKKGyFxf2OTfFKx p7t6GWe1HMvZb7fSabaVWduLZpLb23mDjOFTLJjYEvq9lcRGhFxDRoP3mfvKq+eE3yYDrUXJk U/M6j/G3One/QBxPfF3lQ1FVhZ3SB78o/75PUx/5syFtyh7n9DV6ey5+kLvg= Archived-At: Subject: Re: [core] Retransmission of non-confirmable response message upon receiving request message retranmission? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 19:16:50 -0000 Hi Christer, >> Section 4 is about transmission (CON, NON,ACK and RST), and only slight refer to section 5 (request/response). For that FMPOV it seems to be clear, that >> if a retransmission is detected, the receiver should do its best the send back the same answer, in your case the empty ACK. >> >> In my interpretation of Section 4.5 the intention is, that the retransmission should be handled best on the transmission layer and should not be visible/forwarded >> to the request/response layer. That maybe relaxed, if the outcome is the same or shows only acceptable difference. Generally, the messages (flight) of the original >> answer are intended to be retransmitted. > > How does the stack know if the outcome will be the same? Your sequence: 1 - CON request 2 - ACK 3 - NON response With that, the outcome is: the request (may) have been answered once with the response 4 - CON request (re transmission) 5 - ACK (re transmission) 6 - NON response (re transmission) With that re transmitted flight, the outcome is: the request (may) have been also answered once with the response. (At least, it's possible to implement the response re receive in that way.= ) The difference not re transmitting the response, is that the may would get less probable. Or do I misunderstand your question? > > And, what is the definition of "acceptable difference"? > That depends on your application. That is a cascade of relaxing the consideration for peers, which are not able to operate as preferred. Best 1 - use storage to re transmit the message from Next 2 - call the application layer to get the same message for re transmission. Next 3 - call the application layer to get the similar message for re transmission. The point is, that the selected implementation depends on the available resources. If it's only "Best - 1", then all peers would require to have enough storage. Relaxing that, makes it possible to operate on smaller devices with less footprint. >> Section 5 is then about the request/response 5.2.2, page 34 (top), "If a retransmitted request is received (perhaps because the origin= al >> Acknowledgement was delayed), another Empty Acknowledgement is sent, and any response MUST be sent as a separate response." >> That seem to point to the same intention: retransmit the original messages (flight) as answer. > > I am not sure what you mean by "original message as answer". Are you referring to an ACK, or to a response message? > >> Q1. "Perhaps I have missed it" =3D> I think page 34 top specifies that. > > Where? > > I can only find text saying that another ACK is sent is a request retransmit is received. That was my wrong interpretation of "If a retransmitted request is received (perhaps because the original Acknowledgement was delayed), another Empty Acknowledgement is sent, and any response MUST be sent as a separate response." Carsten, the author, already explained his intention, which is obviously the right on :-). > >> Q2: That's the responsibility of the application to choose the right tradeoff between resources consumption and complying to the expectations. >> If the difference is larger, your application must be designed for that. > > The issue is that the responses may not be identical, as the server does not keep track of previously sent responses. > I don't get that. My feeling your implementing a stack, which interacts with the application layer. The specification sometimes relax the requirements for the stack and push them to the application layer. With that, the stack is not longer responsible, it's the application layer. And there is sure no general answer to the questions, what will be, if that application layer doesn't comply to the expectations. I would think, that it's up to the application layer implementors to chose the right, fitting into the resources and works for their use-case. Best regards Achim Am 02.12.19 um 16:58 schrieb Christer Holmberg: > Hi Kraus, > >> Section 4 is about transmission (CON, NON,ACK and RST), and only sl= ight refer to section 5 (request/response). For that FMPOV it seems to be = clear, that >> if a retransmission is detected, the receiver should do its best th= e send back the same answer, in your case the empty ACK. >> >> In my interpretation of Section 4.5 the intention is, that the retr= ansmission should be handled best on the transmission layer and should not= be visible/forwarded >> to the request/response layer. That maybe relaxed, if the outcome i= s the same or shows only acceptable difference. Generally, the messages (f= light) of the original >> answer are intended to be retransmitted. > > How does the stack know if the outcome will be the same? > > And, what is the definition of "acceptable difference"? > >> Section 5 is then about the request/response 5.2.2, page 34 (top), = "If a retransmitted request is received (perhaps because the original >> Acknowledgement was delayed), another Empty Acknowledgement is sent= , and any response MUST be sent as a separate response." >> That seem to point to the same intention: retransmit the original m= essages (flight) as answer. > > I am not sure what you mean by "original message as answer". Are you ref= erring to an ACK, or to a response message? > >> Q1. "Perhaps I have missed it" =3D> I think page 34 top specifies t= hat. > > Where? > > I can only find text saying that another ACK is sent is a request retran= smit is received. > >> Q2: That's the responsibility of the application to choose the righ= t tradeoff between resources consumption and complying to the expectations= . >> If the difference is larger, your application must be designed for = that. > > The issue is that the responses may not be identical, as the server does= not keep track of previously sent responses. > > Regards, > > Christer > > > > -----Urspr=C3=BCngliche Nachricht----- > Von: core Im Auftrag von Carsten Bormann > Gesendet: Freitag, 29. November 2019 13:08 > An: Christer Holmberg > Cc: core@ietf.org > Betreff: Re: [core] Retransmission of non-confirmable response mess= age upon receiving request message retranmission? > > Hi Christer, > > > On Nov 29, 2019, at 09:44, Christer Holmberg wrote: > > > > Hi, > > > > A couple of questions for clarification. > > > > > > Assume a CoAP server receives a confirmable request message. > > > > According to Section 4.5. of RFC 7252, the server SHOULD retransm= it the associated ACK whenever it receives a retransmission of the request= message. So far, so good. > > > > Then, assume that the sever sends a non-confirmable response mess= age to the request. AFAIK, that is allowed. > > Allowed, yes, but also a rather unusual case: The client took care = to send a confirmable request, and the server only answers unreliably. Th= is combination makes the most sense for an observe-GET, where the server i= s sending periodic notifications, so the loss of a single one is not reall= y a big problem. > > > > --- > > > > Q1: > > > > Perhaps I have missed it, I can=E2=80=99t find any text saying th= at the server would retransmit the response message if it receives a retra= nsmission of the request. > > No, it won=E2=80=99t. The client will retransmit only up to receiv= ing an ACK. > Since your scenario assumes non-confirmable responses, this implies= a separate response, so the ACK will be empty. The server can then send,= at leisure, its response; no further retranmissions will take place. > > (A weird case is where all ACKs get lost and finally the response i= ndicates to the client that the request must have arrived, stopping retran= smission =E2=80=94 see penultimate paragraph of 4.2. Still, the message-i= d of all retransmissions is the same, so no additional response will be ge= nerated.) > > > Section 4.3 does say that a server may choose to transmit multipl= e copies of a non-confirmable message, but there is no text saying that su= ch transmits would be triggered by a retransmission of the request. > > That is indeed not intended. Retransmissions happen at the message= layer. Request/response is a layer above and is not concerned with retra= nsmissions. > > > Section 4.5. does say: > > > > =E2=80=9CA server might relax the requirement to answer all = retransmissions > > of an idempotent request with the same response (Section 4.= 2),=E2=80=9D > > Now you are back to piggybacked responses. > > > Where does Section 4.2 talk about answering retransmissions of an= idempotent request (or any request, for that matter) with the same respon= se? > > Good question. Interesting. > > > --- > > > > Q2: > > > > Related to Q1, Section 4.5 says: > > > > =E2=80=9DFor example, an implementation might want to proce= ss duplicate > > transmissions of a GET, PUT, or DELETE request as separate > > requests if the effort incurred by duplicate processing is = less > > expensive than keeping track of previous responses would be= .=E2=80=9D > > > > > > Maybe I misunderstand this =E2=80=9Cprocess as separate requests= =E2=80=9D thing, but: > > > > First, it means that each response could be different from the pr= evious one, and the sender of the request would have to process each of th= em. > > The sender is not supposed to retransmit a request if it already re= ceived a response. > Of course, the retransmission and the response might cross; in this= case the superfluous response is not used. > > > Second, does this mean that, if the responses are confirmable, th= e server should expect an ACK for each response? =E2=80=9CProcess as separ= ate requests=E2=80=9D makes it sound like that. > > If the response is sent as a confirmable message, the server expect= s an ACK for it. It retransmits until it gets one. > If the response is in an ACK, it is not confirmable; this is really= the useful case for =E2=80=9Cprocess as separate requests=E2=80=9D. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Mon Dec 2 11:53:16 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B67B120046 for ; Mon, 2 Dec 2019 11:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpPTKvyYRkLg for ; Mon, 2 Dec 2019 11:53:12 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE1F120018 for ; Mon, 2 Dec 2019 11:53:11 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Mon, 02 Dec 2019 21:53:06 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=OGfCjqT2D3qVkMLmC rcE3iqKGQ8HogIn2GGF1PMF0R8=; b=ixV/iPVarcXcnGMTc/ier45pxmzNY1MmL 5862an0sOngIb2ZvYNa5oU4cijqAM0FS0e0i9ZEYdRYj18c7yfFFI+TSKzTgyPjm i5WwS26rZLlQU4CKo4QRTxAUFV4HNwxRP54diDp9uzFbJhwvKLolNohVSF/A2lSD c56zB1dcPM= Received: from dx6-cs-02.pc.helsinki.fi (dx6-cs-02.pc.helsinki.fi [193.167.160.58]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Mon, 02 Dec 2019 21:53:06 +0200 id 00000000005A0040.000000005DE56BA2.00002976 Date: Mon, 2 Dec 2019 21:53:06 +0200 (EET) From: Markku Kojo X-X-Sender: kojo@dx6-cs-02.pc.helsinki.fi To: Christer Holmberg cc: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" , "core@ietf.org" In-Reply-To: Message-ID: References: <9917155C-DBA2-43F7-B14C-3B778B27E96F@ericsson.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Archived-At: Subject: Re: [core] Comments and questions on draft-jarvinen-core-fasor-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 19:53:15 -0000 Hi Christer, Apologies for the late reply. Thanks a lot for your feedback. As usual, certainly there is room for improvement with a draft in its "infancy". We'll take action items on your comments and try to address them in the next rev. Please see inline. On Wed, 20 Nov 2019, Christer Holmberg wrote: > Hi Markku, > > >> Q1: > >> > >> Section 4.4. says: > >> > >> "The Retransmission Count Option is used to distinguish whether an > >> Acknowledgement message arrives for the original transmission or one > >> of the retransmissions of a Confirmable message." > >> > >> - I assume this is achieved by, once it has been confirmed that the > >> receiver supports the option, incrementing the counter value in each > >> retransmitted message. However, I cannot find that described anywhere. > >> The text only says that the value of the original transmission is zero. > > > > Right, but the text says it just with a bit different phrasing. In the > > second but last para of Sec 4.4: > > > > "Retransmissions, if any, carry the ordinal number of the > > retransmission." > > I think you should be more specific, and say something like: "the > client MUST increment the number by one in each retransmission", > A or something like that... Right. We would need to be more specific. What you suggest is possibly more accurate but I'd hesitate using MUST for increment by one because it's all up to the client to decide how to distinguish between the retransmissions. Only the first message to an endpoint is an interoparatibility issue on the wire, others after that are not. I'm saying this even though we have orginally proposed using this quite obvious option of "increment by one" but with a second thought the client should be able to decide how to do it, I think. It might even be desireable in some cases not to expose to the network whether a reguest is retransmission or not? We'd be happy to hear opinions on this. On the other hand, if the wg thinks it would be useful for a receiver (server) to know whether a request is a retransmission or not that would make it different. We'd be happy to hear opinions on this as well. We'll try to find text that's more clear and possibly give the "increment by one" approach as one example of how to implement it. > >> Q2: > >> > >> Section 4.4. says: > >> > >> "However, the Retransmission Count Option cannot be used with an Empty > >> Acknowledgement (or Reset) message because the CoAP protocol > >> specification [RFC7252] does not allow adding options to an Empty > >> message. Therefore, Retransmission Count Option is useful only for > >> the common case of Piggybacked Response." > >> > >> - This means that the count option cannot be used when the receiver is > >> a proxy, since a proxy will typically send an empty acknowledgement when > >> it receives a message. > > > > Yes, that's what it means and that's why it's an optional enhancement. > > Unfortunately, CoAP didn't include such a feature in its base spec. > > And I believe the reason for this was that the base spec. didn't include > > any kind of RTT measurements for the RTO timer, so it would have been > > unnecessary. This could have been achieved by stealing 2-3 bits from the > > Message ID, for example. Alternatively, it could still be possible to > > introduce a new type of message, an Empty Message with options, I > > believe. This would allow support for delivering options in an empty ack. > > Such an empty ack message would be needed also for other purpuses, for > > example, if at some point support for ECN is seen useful for CoAP (over > > UDP). Otherwise, there seems not to be any other way to provide the > > necessary feedback. > > I don't argue against the reasons you give, but I think it would be > good to explicitly point out the limitations when the receiver is a > proxy. Agreed. However, we'd like to postpone further discussion about limitations until we know what actually is possible. That is, if this gets adopted and the wg thinks it might be a good idea to have such a new type of message (Empty Message with options), then the draft does not need to discuss any limitations at all for this part. Otherwise, the draft probably should discuss, unless we find some other less restrictive way. After all, this is not yet even draft-ietf-core-...-00 ;) > >> Q3: > >> > >> Section 4.4 says: > >> > >> "The original transmission of a request is indicated with the number > >> 0, except when sending the first request to a new destination > >> endpoint. The first original transmission of the request to a new > >> endpoint carries the number 255 (0xFF) and is interpreted the same as > >> an original transmission carrying the number 0." > >> > >> - What is meant by "new" endpoint? Does the sender have to remember the > >> endpoints it has previously communicated with? If so, for how long? > > > > Endpoint means how it is defined in the base spec (RFC 7252): > > Just to clarify, I am not asking for the definition of "endpoint", but the definition of "new". > > > Just like a CoCoA sender, a FASOR sender needs to maintain an RTO timer > > per endpoint, i.e., it needs to remember the endpoints. For how long, is > > not specified. > > Since you say "new", you need to give guidance on what it means. You are right. It is similar to the concept of "new connection", e.g., with TCP, that is five-tuple. We need to figure out an accurate way to phrase it, maybe simply just like how it is is specified in the CoCoA draft. > >However, from the option usage point of view it would be > >just ok to forget about an endpoint at any point and consider it as a new > > endpoint next time the sender communicates with it. This would just mean > >that when sending to the same endpoint next time we cannot leverage the > >empty option value optimization of CoAP (i.e., need to include the > >special value 255 (0xFF) in the option and confirm again that the > >receiver supports the option). Forgeting about the RTO timer (and > >corresponding RTT estimate would be possible too (just like in RFC > >6298), but is not advisable as it would affect the accuracy of the RTT > >estimation. > > In that case, I think you should describe it that way. Instead of > talking about a "new" endpoint, you should talk about an endpoint that > does not exist in the sender's memory of known remote endpoints, or > something like that... Right. This obviously needs some clarifying text. > >> Q4: > >> Section 4.5 describes how, as an alternative solution, the Token can be > >> used to exchange count information. > >> > >> - How would that work? Would you use different Token values in each > >> retransmission? Again, I am not sure whether CoAP explicitly forbids > >> that, but I assume that is not the intention. > > > >Yes, it should work just fine. It is all up to the client to decide how it > >generates the token values. Servers just echo it back without > >modification. > > My issue is not about how the sender generates the token value, but > that the sender would use a different token value in each > retransmission. > I would really like to hear from the CoAP experts whether that is > allowed or not... Fine. The authors base this on what is written in RFC 7252 and some hallway discussions with "the experts" but as the authors do not consider themselves as "CoAP experts" we would appreciate any advice from the wg. Once again: many thanks for your input! Best regards, /Markku From nobody Mon Dec 2 13:26:02 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C868012004D for ; Mon, 2 Dec 2019 13:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQ9wlXznbdSS for ; Mon, 2 Dec 2019 13:25:59 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 B6135120018 for ; Mon, 2 Dec 2019 13:25:58 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id 21so1243751ljr.0 for ; Mon, 02 Dec 2019 13:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N4RmINMzTzbeWaTM6G5Di1YS2I5SIFepfrMWk48OCU4=; b=Au29XqJ2E38eUGhrbsZl72+PG8m4fuCeILXamd/kAhQ3xEM7QoOi2iF4hp9ZPWL2J4 t45hcdJ99cplsGLydux2AoNFup3LflBd6kEST6kslbvPwFfXxM8gSSfhERostdiFZt5c 3hwjwFf81WHJ4znlBjkqdvmrKVxsQ6CD/lWJ/7BeTY4TVK9P1hm9LK9XgKcDA4nDKaHT zmRUr/YchSuZT/BXUuF9CJEE+CcpvZRF2U+KUOTdFzLBdum5OMn+W27hTCzsjwDAXMr2 S6KsvUc+GX59DIvjCTaRPiJ+pjZ1a7rpknRfPY6ZOaQ3EXlflZPCK0DJreBRxsfKXASj +dlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N4RmINMzTzbeWaTM6G5Di1YS2I5SIFepfrMWk48OCU4=; b=I8EH0yOhBucq3bvrLtqlDtuW7vKVsWm1bO/OACuJG39J+pouWZS8Siiv0KE6UHup5O NBJizyX83UIzWuycyklhEY5c6Bn7IAGXcHM4UQfpwz8GDpocTYtIO2tx4giAkSUUOGvw uX5yHzGm0JhkO4etaYw35J3I+BhBiDiCGBKS1wLez2deY++AHLME/1e9tUeUh0tVyl9d txE6/1GENA6d0xpep5FANWTSyNrA5FQHB5gIX/OuKpUdmM+nJJgDQ4l+nzkr4g2f8Imz wfczzJ4AkAyXZxzuBXpMKiVyUdbTdg2C3hXw2nLzKQ2aEBxHnkcpXTF0T28Xng1OmAaj PiYg== X-Gm-Message-State: APjAAAX2cpQj9+gcxk8XSTdh8nQ9qXuFfA+VXPgWBc8CspnrInPuvlbx fPPh8Fcj5mbbOwGNrjvl8ZaOUVZpFfEVa4G0aA== X-Google-Smtp-Source: APXvYqxrzJa9IpcD6xVboueTg98DLT/blrZX0dqowDqVc1s8lLx/AvXQjheKzCIzBR+s78ELlf5i673upX9wk1W9XYs= X-Received: by 2002:a2e:298d:: with SMTP id p13mr513966ljp.143.1575321956791; Mon, 02 Dec 2019 13:25:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: James Nguyen Date: Mon, 2 Dec 2019 13:25:45 -0800 Message-ID: To: Thomas Fossati Cc: "core@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a43b040598bf3955" Archived-At: Subject: Re: [core] IETF 106 Meeting Notes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 21:26:01 -0000 --000000000000a43b040598bf3955 Content-Type: text/plain; charset="UTF-8" Thanks, Thomas. James On Mon, Dec 2, 2019 at 1:58 AM Thomas Fossati wrote: > Hi James, > > On 02/12/2019, 02:25 James Nguyen wrote: > > Are the IETF 106 meeting notes available for viewing? > > The official meeting materials [1] are not out yet, but you can > take a look at [2] to get an idea. > > (Both sessions are also available on YT -- search for "ietf 106 core".) > > Cheers > > [1] https://datatracker.ietf.org/meeting/106/materials > [2] https://etherpad.ietf.org/p/notes-ietf-106-core > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > -- James Nguyen Email: james.huy.nguyen@gmail.com --000000000000a43b040598bf3955 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Thomas.

James

On Mon, Dec 2, 2019 at 1:58 AM Thomas Fossat= i <Thomas.Fossati@arm.com&= gt; wrote:
Hi James,

On 02/12/2019, 02:25 James Nguyen wrote:
> Are the IETF 106 meeting notes available for viewing?

The official meeting materials [1] are not out yet, but you can
take a look at [2] to get an idea.

(Both sessions are also available on YT -- search for "ietf 106 core&q= uot;.)

Cheers

[1] https://datatracker.ietf.org/meeting/106/mater= ials
[2] https://etherpad.ietf.org/p/notes-ietf-106-core



IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you.
--
James Nguyen
Email: james.huy.nguyen@gmail.com
--000000000000a43b040598bf3955-- From nobody Tue Dec 3 05:12:14 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509A812004F for ; Tue, 3 Dec 2019 05:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgUFxdw-sVHV for ; Tue, 3 Dec 2019 05:12:11 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0609.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::609]) (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 64B3212002E for ; Tue, 3 Dec 2019 05:12:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JiI8pcezn4ZKxnkvpbNIeKpifCFjJnhd+N8BTGDPZ7HhiWu/logypflxODRvda6pGsoQ8+r2f1JyVeIEb/69RLdEp9H+g6FyxuQgmylUQbUuJtJ82rhv2iyNMzygpzIY3SnruvHP22v8ZKLFwNhgTym5XMeoQ2VjOexKtFToHHWj+9NsXgUKu9A+7Ext2H3j5LGDbCC7yZ9GYfR6gO/N37rEnW9+IW6kQjfCK59Yv+ljiuqKTNppuJOUFER9lw4YMv1muK8o/5R0OJJykF+O6HBt9Ac0UUFKS/dRXCwsMO1WDEAdf4PnahHDTiuv5OH8RPaa1gaw8izLZ0f4ncPDFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o7gQoRt2wjikNM4kQmffyqMAkPixVCa7RjwG1ickcoQ=; b=NKCoyIGjOAjJu1hkRkJghQNv3K39gP0U76t7y78/F6suGjj0aUa0/kxGxXIEQawVUAVugMP9AKE+2Aoo/a2+sajglgdX5Uigdxbials31Nkzgo5sWr0FeP52+LKPQW3IYL6x7OOK8NP7nPLiW3G/B2eOoaN4lusj5Rw/5uMihONmqPuon2P/q65hK+r2O8KBOG8E5+gLLSI4I86N/pDdqfIA2ck3XatYzZT3A2ZCVAIypKaMW6AsTwWKBc0Qr+INUo3u1NGORfj7WtZ9fT9LkkccKNpAowpWfKkUGTtdTT1amEzMmu0yYg0pEvqWiCGnM0jRvcFi+v0hhRMYJ9Z7yQ== 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=o7gQoRt2wjikNM4kQmffyqMAkPixVCa7RjwG1ickcoQ=; b=YTSljJUzXxQlc+EB5toak4DSCENvswOwH5Cvc95Kzim4HU3XgmYwSgfGlLi4iTITzE2RwWtXKbFpFE8VyLk5OJPkEojCVNeTVSTUrSlA6EbrvUxM2wkmqeSM12R9Y6zN1p9VYSnD9Tp3vZqB64mI01ZyeJng5onZZetAiDKGcNs= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3404.eurprd07.prod.outlook.com (10.170.242.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.4; Tue, 3 Dec 2019 13:12:06 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::2ca9:414:cc01:9706]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::2ca9:414:cc01:9706%4]) with mapi id 15.20.2516.003; Tue, 3 Dec 2019 13:12:06 +0000 From: Christer Holmberg To: Markku Kojo CC: =?utf-8?B?SWxwbyBKw6RydmluZW4=?= , "core@ietf.org" Thread-Topic: [core] Comments and questions on draft-jarvinen-core-fasor-02 Thread-Index: AQHVn2BECFPCnrAr20yH8up3HLf2tKeTp94AgAEryoCAEoHRAIABQ9GA Date: Tue, 3 Dec 2019 13:12:06 +0000 Message-ID: <36EF701E-9688-4DC8-9686-6495F9AF4074@ericsson.com> References: <9917155C-DBA2-43F7-B14C-3B778B27E96F@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f938b7fb-6998-4e92-e210-08d777f265a3 x-ms-traffictypediagnostic: HE1PR07MB3404: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(39860400002)(376002)(366004)(396003)(189003)(199004)(26005)(36756003)(33656002)(8676002)(6246003)(81166006)(81156014)(58126008)(25786009)(478600001)(316002)(256004)(14454004)(54906003)(14444005)(102836004)(71200400001)(6506007)(186003)(446003)(71190400001)(99286004)(4326008)(2616005)(8936002)(11346002)(6486002)(44832011)(76176011)(5660300002)(2906002)(6512007)(76116006)(6436002)(66476007)(66556008)(3846002)(6116002)(66946007)(66446008)(86362001)(229853002)(91956017)(64756008)(7736002)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3404; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 69d3FA3+JfODD+hzNckphH/8ZxwtRlO2+PmaH93afmhNohzLxudqNwA04RPzUYWng+7ZBU6TbKJOgCVsQJVkA8H1D+iIfSu4+lxNp9Tdicel4Qs1yEMvPVrhxoUbr2m3ntcXVextUeh/tlReUPlaHILs5rQCzMYAvEbtn3YZNGTrJX5NiYT6bT28gThEC8b/3ONFOn0fbLZymznOSzSs9huMtpXfvyrMyabjj8Qz5pZd8C1TDNTsyTHxTH/Kn1kn3o1bl7Leselh0hFgP9P0RjGI+IGZCA0XSGzkWDBxzOVl55ePPR4ekImwwUQYMolqENplWZ1y/8Iw4/xB7GEqRvh8R18sEHhoA/wzb2WEgZcel3Z1OfCPBlqCL2YReIolsEq6UPyFE4ko/fYM7dhQRH7tocYrEn3MmRleWfOVnBcJkGg2yocXHwEDaEDqC70H x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0D13EB23197B0645828B6494ACAE0511@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f938b7fb-6998-4e92-e210-08d777f265a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2019 13:12:06.5195 (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: ZnDN9wI4/JfJsqt4VJIwHpLw1nEBB6QhrnR9r4/BrRHClR9cAE8Lb9hKs8xBEK1iLBqkccbyyyjyQ/q7f+tRg5bZLPQNdHVwv/fjKQVgv3Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3404 Archived-At: Subject: Re: [core] Comments and questions on draft-jarvinen-core-fasor-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 13:12:13 -0000 SGksDQoNCiAgICBRMToNCiAgICA+Pj4+DQogICAgPj4+PiBTZWN0aW9uIDQuNC4gc2F5czoNCiAg ICA+Pj4+DQogICAgPj4+PiAgICJUaGUgUmV0cmFuc21pc3Npb24gQ291bnQgT3B0aW9uIGlzIHVz ZWQgdG8gZGlzdGluZ3Vpc2ggd2hldGhlciBhbg0KICAgID4+Pj4gICBBY2tub3dsZWRnZW1lbnQg bWVzc2FnZSBhcnJpdmVzIGZvciB0aGUgb3JpZ2luYWwgdHJhbnNtaXNzaW9uIG9yIG9uZQ0KICAg ID4+Pj4gICBvZiB0aGUgcmV0cmFuc21pc3Npb25zIG9mIGEgQ29uZmlybWFibGUgbWVzc2FnZS4i DQogICAgPj4+Pg0KICAgID4+Pj4gLSBJIGFzc3VtZSB0aGlzIGlzIGFjaGlldmVkIGJ5LCBvbmNl IGl0IGhhcyBiZWVuIGNvbmZpcm1lZCB0aGF0IHRoZQ0KICAgID4+Pj4gcmVjZWl2ZXIgc3VwcG9y dHMgdGhlIG9wdGlvbiwgaW5jcmVtZW50aW5nIHRoZSBjb3VudGVyIHZhbHVlIGluIGVhY2gNCiAg ICA+Pj4+IHJldHJhbnNtaXR0ZWQgbWVzc2FnZS4gSG93ZXZlciwgSSBjYW5ub3QgZmluZCB0aGF0 IGRlc2NyaWJlZCBhbnl3aGVyZS4NCiAgICA+Pj4+IFRoZSB0ZXh0IG9ubHkgc2F5cyB0aGF0IHRo ZSB2YWx1ZSBvZiB0aGUgb3JpZ2luYWwgdHJhbnNtaXNzaW9uIGlzIHplcm8uDQogICAgPj4+DQog ICAgPj4+IFJpZ2h0LCBidXQgdGhlIHRleHQgc2F5cyBpdCBqdXN0IHdpdGggYSBiaXQgZGlmZmVy ZW50IHBocmFzaW5nLiBJbiB0aGUNCiAgICA+Pj4gc2Vjb25kIGJ1dCBsYXN0IHBhcmEgb2YgU2Vj IDQuNDoNCiAgICA+Pj4NCiAgICA+Pj4gICJSZXRyYW5zbWlzc2lvbnMsIGlmIGFueSwgY2Fycnkg dGhlIG9yZGluYWwgbnVtYmVyIG9mIHRoZQ0KICAgID4+PiAgIHJldHJhbnNtaXNzaW9uLiINCiAg ICA+Pg0KICAgID4+IEkgdGhpbmsgeW91IHNob3VsZCBiZSBtb3JlIHNwZWNpZmljLCBhbmQgc2F5 IHNvbWV0aGluZyBsaWtlOiAidGhlDQogICAgPj4gY2xpZW50IE1VU1QgaW5jcmVtZW50IHRoZSBu dW1iZXIgYnkgb25lIGluIGVhY2ggcmV0cmFuc21pc3Npb24iLA0KICAgID4+IEEgb3Igc29tZXRo aW5nIGxpa2UgdGhhdC4uLg0KICAgID4NCiAgICA+ICBSaWdodC4gV2Ugd291bGQgbmVlZCB0byBi ZSBtb3JlIHNwZWNpZmljLg0KICAgID4NCiAgICA+IFdoYXQgeW91IHN1Z2dlc3QgaXMgcG9zc2li bHkgbW9yZSBhY2N1cmF0ZSBidXQgSSdkIGhlc2l0YXRlIHVzaW5nIE1VU1QgDQogICAgPiBmb3Ig aW5jcmVtZW50IGJ5IG9uZSBiZWNhdXNlIGl0J3MgYWxsIHVwIHRvIHRoZSBjbGllbnQgdG8gZGVj aWRlIGhvdyB0byANCiAgICA+IGRpc3Rpbmd1aXNoIGJldHdlZW4gdGhlIHJldHJhbnNtaXNzaW9u cy4gT25seSB0aGUgZmlyc3QgbWVzc2FnZSB0byBhbiANCiAgICA+IGVuZHBvaW50IGlzIGFuIGlu dGVyb3BhcmF0aWJpbGl0eSBpc3N1ZSBvbiB0aGUgd2lyZSwgb3RoZXJzIGFmdGVyIHRoYXQgDQog ICAgPiBhcmUgbm90Lg0KICAgID4gSSdtIHNheWluZyB0aGlzIGV2ZW4gdGhvdWdoIHdlIGhhdmUg b3JnaW5hbGx5IHByb3Bvc2VkIHVzaW5nIHRoaXMgcXVpdGUgDQogICAgPiBvYnZpb3VzIG9wdGlv biBvZiAiaW5jcmVtZW50IGJ5IG9uZSIgYnV0IHdpdGggYSBzZWNvbmQgdGhvdWdodCB0aGUgY2xp ZW50IA0KICAgID4gc2hvdWxkIGJlIGFibGUgdG8gZGVjaWRlIGhvdyB0byBkbyBpdCwgSSB0aGlu ay4gSXQgbWlnaHQgZXZlbiBiZSANCiAgICA+IGRlc2lyZWFibGUgaW4gc29tZSBjYXNlcyBub3Qg dG8gZXhwb3NlIHRvIHRoZSBuZXR3b3JrIHdoZXRoZXIgYSByZWd1ZXN0IA0KICAgID4gaXMgcmV0 cmFuc21pc3Npb24gb3Igbm90PyBXZSdkIGJlIGhhcHB5IHRvIGhlYXIgb3BpbmlvbnMgb24gdGhp cy4NCiAgICA+DQogICAgPiBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgdGhlIHdnIHRoaW5rcyBpdCB3 b3VsZCBiZSB1c2VmdWwgZm9yIGEgcmVjZWl2ZXIgDQogICAgPiAoc2VydmVyKSB0byBrbm93IHdo ZXRoZXIgYSByZXF1ZXN0IGlzIGEgcmV0cmFuc21pc3Npb24gb3Igbm90IHRoYXQgd291bGQgDQog ICAgPiBtYWtlIGl0IGRpZmZlcmVudC4gV2UnZCBiZSBoYXBweSB0byBoZWFyIG9waW5pb25zIG9u IHRoaXMgYXMgd2VsbC4NCiAgICANCk5vdCBzdXJlIEkgdW5kZXJzdGFuZC4gVGhlIE1lc3NhZ2Ug SUQgd2lsbCBleHBvc2UgdGhhdCB0aGUgbWVzc2FnZSBpcyBhIHJldHJhbnNtaXNzaW9uLg0KDQog ICAgPiBXZSdsbCB0cnkgdG8gZmluZCB0ZXh0IHRoYXQncyBtb3JlIGNsZWFyIGFuZCBwb3NzaWJs eSBnaXZlIHRoZSAiaW5jcmVtZW50IA0KICAgID4gYnkgb25lIiBhcHByb2FjaCBhcyBvbmUgZXhh bXBsZSBvZiBob3cgdG8gaW1wbGVtZW50IGl0Lg0KDQpUaGUgYWR2YW50YWdlIG9mIE1VU1QtaW5j cmVtZW50LWJ5LW9uZSBpcyB0aGF0IGl0IGFsc28gZW5hYmxlcyBvbmUgdG8gZGV0ZWN0IGxvc3Qg bWVzc2FnZXMuDQoNCi0tLQ0KDQogICAgUTI6DQogICAgDQogICAgPj4+PiBTZWN0aW9uIDQuNC4g c2F5czoNCiAgICA+Pj4+DQogICAgPj4+PiAgICJIb3dldmVyLCB0aGUgUmV0cmFuc21pc3Npb24g Q291bnQgT3B0aW9uIGNhbm5vdCBiZSB1c2VkIHdpdGggYW4gRW1wdHkNCiAgICA+Pj4+ICAgQWNr bm93bGVkZ2VtZW50IChvciBSZXNldCkgbWVzc2FnZSBiZWNhdXNlIHRoZSBDb0FQIHByb3RvY29s DQogICAgPj4+PiAgIHNwZWNpZmljYXRpb24gW1JGQzcyNTJdIGRvZXMgbm90IGFsbG93IGFkZGlu ZyBvcHRpb25zIHRvIGFuIEVtcHR5DQogICAgPj4+PiAgIG1lc3NhZ2UuICBUaGVyZWZvcmUsIFJl dHJhbnNtaXNzaW9uIENvdW50IE9wdGlvbiBpcyB1c2VmdWwgb25seSBmb3INCiAgICA+Pj4+ICAg dGhlIGNvbW1vbiBjYXNlIG9mIFBpZ2d5YmFja2VkIFJlc3BvbnNlLiINCiAgICA+Pj4+DQogICAg Pj4+PiAtIFRoaXMgbWVhbnMgdGhhdCB0aGUgY291bnQgb3B0aW9uIGNhbm5vdCBiZSB1c2VkIHdo ZW4gdGhlIHJlY2VpdmVyIGlzDQogICAgPj4+PiBhIHByb3h5LCBzaW5jZSBhIHByb3h5IHdpbGwg dHlwaWNhbGx5IHNlbmQgYW4gZW1wdHkgYWNrbm93bGVkZ2VtZW50IHdoZW4NCiAgICA+Pj4+IGl0 IHJlY2VpdmVzIGEgbWVzc2FnZS4NCiAgICA+Pj4NCiAgICA+Pj4gWWVzLCB0aGF0J3Mgd2hhdCBp dCBtZWFucyBhbmQgdGhhdCdzIHdoeSBpdCdzIGFuIG9wdGlvbmFsIGVuaGFuY2VtZW50Lg0KICAg ID4+PiBVbmZvcnR1bmF0ZWx5LCBDb0FQIGRpZG4ndCBpbmNsdWRlIHN1Y2ggYSBmZWF0dXJlIGlu IGl0cyBiYXNlIHNwZWMuDQogICAgPj4+IEFuZCBJIGJlbGlldmUgdGhlIHJlYXNvbiBmb3IgdGhp cyB3YXMgdGhhdCB0aGUgYmFzZSBzcGVjLiBkaWRuJ3QgaW5jbHVkZQ0KICAgID4+PiBhbnkga2lu ZCBvZiBSVFQgbWVhc3VyZW1lbnRzIGZvciB0aGUgUlRPIHRpbWVyLCBzbyBpdCB3b3VsZCBoYXZl IGJlZW4NCiAgICA+Pj4gdW5uZWNlc3NhcnkuIFRoaXMgY291bGQgaGF2ZSBiZWVuIGFjaGlldmVk IGJ5IHN0ZWFsaW5nIDItMyBiaXRzIGZyb20gdGhlDQogICAgPj4+IE1lc3NhZ2UgSUQsIGZvciBl eGFtcGxlLiBBbHRlcm5hdGl2ZWx5LCBpdCBjb3VsZCBzdGlsbCBiZSBwb3NzaWJsZSB0bw0KICAg ID4+PiBpbnRyb2R1Y2UgYSBuZXcgdHlwZSBvZiBtZXNzYWdlLCBhbiBFbXB0eSBNZXNzYWdlIHdp dGggb3B0aW9ucywgSQ0KICAgID4+PiBiZWxpZXZlLiBUaGlzIHdvdWxkIGFsbG93IHN1cHBvcnQg Zm9yIGRlbGl2ZXJpbmcgb3B0aW9ucyBpbiBhbiBlbXB0eSBhY2suDQogICAgPj4+IFN1Y2ggYW4g ZW1wdHkgYWNrIG1lc3NhZ2Ugd291bGQgYmUgbmVlZGVkIGFsc28gZm9yIG90aGVyIHB1cnB1c2Vz LCBmb3INCiAgICA+Pj4gZXhhbXBsZSwgaWYgYXQgc29tZSBwb2ludCBzdXBwb3J0IGZvciBFQ04g aXMgc2VlbiB1c2VmdWwgZm9yIENvQVAgKG92ZXINCiAgICA+Pj4gVURQKS4gT3RoZXJ3aXNlLCB0 aGVyZSBzZWVtcyBub3QgdG8gYmUgYW55IG90aGVyIHdheSB0byBwcm92aWRlIHRoZQ0KICAgID4+ PiBuZWNlc3NhcnkgZmVlZGJhY2suDQogICAgPj4NCiAgICA+PiBJIGRvbid0IGFyZ3VlIGFnYWlu c3QgdGhlIHJlYXNvbnMgeW91IGdpdmUsIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIA0KICAgID4+ IGdvb2QgdG8gZXhwbGljaXRseSBwb2ludCBvdXQgdGhlIGxpbWl0YXRpb25zIHdoZW4gdGhlIHJl Y2VpdmVyIGlzIGEgDQogICAgPj4gcHJveHkuDQogICAgPg0KICAgID4gQWdyZWVkLiBIb3dldmVy LCB3ZSdkIGxpa2UgdG8gcG9zdHBvbmUgZnVydGhlciBkaXNjdXNzaW9uIGFib3V0IA0KICAgID4g bGltaXRhdGlvbnMgdW50aWwgd2Uga25vdyB3aGF0IGFjdHVhbGx5IGlzIHBvc3NpYmxlLiBUaGF0 IGlzLCBpZiB0aGlzIA0KICAgID4gZ2V0cyBhZG9wdGVkIGFuZCB0aGUgd2cgdGhpbmtzIGl0IG1p Z2h0IGJlIGEgZ29vZCBpZGVhIHRvIGhhdmUgc3VjaCBhIG5ldyANCiAgICA+IHR5cGUgb2YgbWVz c2FnZSAoRW1wdHkgTWVzc2FnZSB3aXRoIG9wdGlvbnMpLCB0aGVuIHRoZSBkcmFmdCBkb2VzIG5v dCANCiAgICA+IG5lZWQgdG8gZGlzY3VzcyBhbnkgbGltaXRhdGlvbnMgYXQgYWxsIGZvciB0aGlz IHBhcnQuIE90aGVyd2lzZSwgdGhlIA0KICAgID4gZHJhZnQgcHJvYmFibHkgc2hvdWxkIGRpc2N1 c3MsIHVubGVzcyB3ZSBmaW5kIHNvbWUgb3RoZXIgbGVzcyByZXN0cmljdGl2ZSANCiAgICA+IHdh eS4NCg0KSSB0aGluayB5b3Ugc2hvdWxkIGRvY3VtZW50IHRoZSBsaW1pdGF0aW9uLCBhcyBpdCBy ZXByZXNlbnRzIHRoZSBjdXJyZW50IHN0YXRlLiAgVGhlbiwgaWYgd2UgZGVmaW5lIGEgbmV3IG1l c3NhZ2UgKGUuZy4sIEVtcHR5IE1lc3NhZ2Ugd2l0aCBvcHRpb25zKSB3ZSBzaW1wbHkgcmVtb3Zl IHRoZSBsaW1pdGF0aW9uIHRleHQuDQoNCiAgID4gQWZ0ZXIgYWxsLCB0aGlzIGlzIG5vdCB5ZXQg ZXZlbiBkcmFmdC1pZXRmLWNvcmUtLi4uLTAwICA7KQ0KDQpTdXJlLCBidXQgd2hlbiBwcm9wb3Np bmcgYSBuZXcgd29yayBJIHRoaW5rIGl0IGlzIGdvb2QgdG8gZG9jdW1lbnQgdGhlIGlzc3VlcyBh bmQgbGltaXRhdGlvbnMgdGhhdCBhcmUga25vd24gYXQgdGhhdCBtb21lbnQuIFRoZSBXRyB3aWxs IHRoZW4gZGVjaWRlIGhvdy9pZiB0byBhZGRyZXNzIHRoZW0uDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQogICAgDQoNCg== From nobody Fri Dec 6 04:45:25 2019 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 8CC481200F4; Fri, 6 Dec 2019 04:45:18 -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: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <157563631841.20931.16572517984526523779@ietfa.amsl.com> Date: Fri, 06 Dec 2019 04:45:18 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-stateless-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 12:45:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) Author : Klaus Hartke Filename : draft-ietf-core-stateless-04.txt Pages : 15 Date : 2019-12-06 Abstract: This document provides considerations for alleviating CoAP clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths. This document updates RFCs 7252 and 8323. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-stateless/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-stateless-04 https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-stateless-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 6 04:51:25 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFDF1200FF for ; Fri, 6 Dec 2019 04:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 yR7XzzAhCV5e for ; Fri, 6 Dec 2019 04:51:21 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00070.outbound.protection.outlook.com [40.107.0.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BF0212001E for ; Fri, 6 Dec 2019 04:51:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oJnj3n6bJAkDhr9wrjc0aaSOCOSb8BcliwvTYd/vKuBEpDHI36VGGTS6pbnuK87HQfbeYD4qtHCDtCMLJ5ZfZCBg8RA6gETaih0mJpfoXd0GNLETVrDYWGx2pVlQDHoVOhHzbJENzRNgQVV+OPA+jiEdHzK7hxLUywOUCLP5kfTbLIaMAFG+zcnhJ4/31tE/vTHXQlPvowqXrmlJ+L2uZ+IrK+atNraOBJ1gzDWYUWytf8IqkdFRFfehRJfzVYsSZ1Qqb25bTLeKRV/UgR+VTtZ9qEYiuECf8fURCWKgmBdYG3ABMj1ZCjQPQRXdj2ICaUCxTOpmstWBfniDaGyadw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WsC5f5iAD7uS4PAPTa4vAJhSO7NAHdGt8Jqo7ZJipm0=; b=dnx7V3m18t+wpU2UbkoWsUVc31SnnQEXvkOgIp1CAEIu3OucOP1VZpaYFZsxERd5FHEjUxsp1LwsgyaSLLJi4dxmP7GE+/0I0a4H1hPV8dNLJIeFGr3I2dIkQSOX9T5y4A4gyQWRo9LEjOIg0duZlADQ3VFPciiVx/hQTyWgygXrDbX9dkErZfCT7WqFXY3rFo6F9z1uZLMZfpEbJYa4GgpF9cmj7aH8vzspju7QL2uLCV8o55dbQT3IH+AnIZWFAKlzEmj8PiebEMM1hhQzftNOGwR890Rrjl/d0qZIZaFi3w1bO/eiTfPGCwDMHHXWFbMX8F1lTeFF0PRuvCLYIA== 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=WsC5f5iAD7uS4PAPTa4vAJhSO7NAHdGt8Jqo7ZJipm0=; b=pOVnQXUuyN8HTWfvpDC3wbWVnMvEn660SiljyacuoucQ/6vvlKMmU8hXC7dbGirWJ5t0WZEgXP2KJfAto6pxZERhIR1C+aF1ltS0CxzPIWypJoFWV6ZJSLnocpDaiRDd0ubbjaNH/OGHP5+Nkve0unfgmrdmWGpel/am7xlAjPY= Received: from VI1PR07MB3293.eurprd07.prod.outlook.com (10.170.238.158) by VI1PR07MB3455.eurprd07.prod.outlook.com (10.175.244.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.9; Fri, 6 Dec 2019 12:51:16 +0000 Received: from VI1PR07MB3293.eurprd07.prod.outlook.com ([fe80::b187:1c48:761:9f49]) by VI1PR07MB3293.eurprd07.prod.outlook.com ([fe80::b187:1c48:761:9f49%4]) with mapi id 15.20.2538.005; Fri, 6 Dec 2019 12:51:16 +0000 From: Klaus Hartke To: "core@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-stateless-04.txt Thread-Index: AQHVrDM1cy801KATdEqIlFiyLqgjWKetDxLw Date: Fri, 6 Dec 2019 12:51:15 +0000 Message-ID: References: <157563631841.20931.16572517984526523779@ietfa.amsl.com> In-Reply-To: <157563631841.20931.16572517984526523779@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=klaus.hartke@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 487a004e-4855-4bde-7ca3-08d77a4afb6d x-ms-traffictypediagnostic: VI1PR07MB3455: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0243E5FD68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(366004)(346002)(396003)(376002)(199004)(189003)(13464003)(229853002)(305945005)(99286004)(8936002)(81166006)(8676002)(1730700003)(6916009)(81156014)(76116006)(64756008)(66446008)(26005)(186003)(2906002)(102836004)(76176011)(7696005)(53546011)(6506007)(86362001)(478600001)(71200400001)(71190400001)(52536014)(966005)(66556008)(55016002)(5640700003)(66476007)(66946007)(33656002)(316002)(66616009)(9686003)(44832011)(66574012)(74316002)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3455; H:VI1PR07MB3293.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AxE86deCyGa5MwoLb6KDhBB4HegKuJnwCGhAzvSq3DUSMFzwUXMrs6PF8lVCG+oDMFPZ+1S/T2yZ9MIR145jtERahFLDQq4SRL6+4Y/dGrXB8pOx1zz8ySPA1FtzAkkmEHE4d29dg2fdZIx16CBgPLHSKZmIk2WPbId1a0wpjGk7zJTNdUrnocPZoN0oa4TfY0slap0tgkAjd8EMjusR2VjF/ynaazd0rqCPyoFAld9rSZyVmz2RjFPMCP1ZDVLm8VrjJOexaQNOmeRe2ellCgT6/qrD+PFSuFuJ6H7jiMIemZO6BNShbtTsvW+rXQ2tfm9qb2ftxheHmKongC51MZMMsstERD2gZsUV4vOrc9Q+lbzNnaXd7y50oHchkQ5w2yGLc/sd4jNP7OAue3cG/eMn8msLSksoPchq6GMnj+K5uNBSiDiz4TGnOuByOJ8Bdq08bUgVCOATlxnBaenERyf2cMGCDJ1MDpG4HOdNfNQpVsH4N06PUbqFfoj4f5Sp8gcqAAtCsdTx0/XzZizG1/h2qzdoHu4Yi1WtIuZov5Q= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0010_01D5AC3C.39D4CBC0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 487a004e-4855-4bde-7ca3-08d77a4afb6d X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2019 12:51:15.9400 (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: svw8VyiszDxuxqWAOb11FSptA/M7Z+gjSOksOay8YsQfIk+817/fT3RIaT+lPWrirOv8xbLmPYAS8OxUdtcJaA7b/MBr/LGYC92Z0BEPrIA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3455 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-stateless-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 12:51:23 -0000 ------=_NextPart_000_0010_01D5AC3C.39D4CBC0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit This revision addresses all remaining WGLC feedback. Klaus > -----Original Message----- > From: core On Behalf Of internet-drafts@ietf.org > Sent: Friday, December 6, 2019 1:45 PM > To: i-d-announce@ietf.org > Cc: core@ietf.org > Subject: [core] I-D Action: draft-ietf-core-stateless-04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Constrained RESTful Environments WG of the > IETF. > > Title : Extended Tokens and Stateless Clients in the > Constrained > Application Protocol (CoAP) > Author : Klaus Hartke > Filename : draft-ietf-core-stateless-04.txt > Pages : 15 > Date : 2019-12-06 > > Abstract: > This document provides considerations for alleviating CoAP clients > and intermediaries of keeping per-request state. To facilitate this, > this document additionally introduces a new, optional CoAP protocol > extension for extended token lengths. > > This document updates RFCs 7252 and 8323. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-stateless/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-core-stateless-04 > https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-core-stateless-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ ------=_NextPart_000_0010_01D5AC3C.39D4CBC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVZjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF9zCCA9+gAwIBAgIP AWOls3xSSP0QOxRgidAlMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0xODA1Mjgw NzQzMTBaFw0yMTA1MjgwNzQzMTBaMGYxETAPBgNVBAoMCEVyaWNzc29uMRUwEwYDVQQDDAxLbGF1 cyBIYXJ0a2UxEDAOBgNVBAUTB2VoYXJrbGExKDAmBgkqhkiG9w0BCQEWGWtsYXVzLmhhcnRrZUBl cmljc3Nvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCDio+ih5PYz7S6Kd5Z 0+ZSHH8kBUbafoWY84G8FFX0Kc3WSR7IVtqk83AVZTtaQCI2HfpA8SGglPolFVJVIXGWCQ+r7PB2 7Cdi21DpMybMqSKTyNUQBRlEJ6P8Yw/2NibI5V71JgRAvCmYYV469azp0Vfe7IDCZ7aYy82RDoKF KPvzdbS/ITaDkBvJNs2XuTQ/sA25E89DmuDlTXMcn4bI9pREIUYR8B68DALCE2T5EUw5iKt/wing MAwiL6b0WmX/KGcrC0MIU5/Roz/n/JRaw86TbH355Zzuo0bC2IDcV9fMuxKP2FYYrrwc3xADU8me iFLzbCx6hCj7G5T/EtbFAgMBAAGjggG/MIIBuzAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj 2y2mUzAdBgNVHQ4EFgQUGkbqBNsUkr3X5JiraFGVxglHlyMwDgYDVR0PAQH/BAQDAgWgMFUGA1Ud IAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMCQGA1UdEQQdMBuBGWtsYXVzLmhhcnRrZUBlcmljc3Nv bi5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYzLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwgYIG CCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBI BggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQAEFazqt3IoPffSKVXdh9vWt2u8pFzk PKlloydyvKOdKHsfJmXxLPBqNqLbQil8nuNhbYWUBVMXFdoymFFvndSTgGhB29TqWl7v3vRFgjhy cUE7qd3trmee7hjBIG8C8wKEvP1JqEu0Blg9OmLv6/nIVY5UZEVZyY22Jmn4fFBHDWS7BuyQg9zj HtQBrLpos71G3G5kd8PRPus/SxdFTMmgQi84NfmeTLG6f7YqfNSD6ss6bvSgw79TmCEXBhzdJCHh xqxE94Giq8W1m3JkH43m6wP7bBuVuNstiizERMlooNIJHk+C2MiwZCA28o8oxPdb29M2CYldzhp2 YPuHPMI0GDF/Uz6QqZ+GwAzyWKxhfI1BdQpyUY7yDQTUaPZZLrYbswXStyHiANRNW/ELol2MW38I VyeObWYgc2l7awJQNjYyJ82zJSAmWMyZkMZ6zmdbv7eAKnFLQbcvVRVe002YmxCUMFBCqz1VE7A/ 8ISDvlFZaHpRCMGB2VCmg2HdnsniFTb3lKWNcIgJa4VbpOfbGAikJxfLfKJ+k9Jf121503JCyEwI 9y7ug0x3336llwbPEQD89omt6PSsFgdGlbLvLvjFmKc1j8P2w9pCarqsM2Ug7V4g8HTFpaETHAcS F9s4z0+vvhUlEx3pwuz2hTLBJ/8OFx6qtxlzbbaB57biTjCCBsIwggSqoAMCAQICEFO4foPhnJko k7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMM FlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUxMDI3MTIxNjQ2WjBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDs8t8AALhQ8qe7 2FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meisbhkqUXkL7fFzoe4iIZCh /VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdDdxhVW4Leo0awEhfLf98M vWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmd vkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7 zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP 1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3s p0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25a EvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUU kBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCC AbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFz b25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVy YS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1 c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1 c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7GZ6XnHasID3Y3OOR auPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBCwUAA4IC AQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5QtaZiObNHCZ7mmSNM Vek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj0uKvdASzYL4KMaB7 m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQysshUcqRdUbkS13HT CIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNM MbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7 DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPN mJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKa kDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i 0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+W kDGCAv8wggL7AgEBMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BY6WzfFJI/RA7FGCJ0CUwCQYFKw4DAhoF AKCCAXowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMjA2MTI1 MTE0WjAjBgkqhkiG9w0BCQQxFgQUPpbE1pTl8HAMyhjnBxeuDaZHr4MwQwYJKoZIhvcNAQkPMTYw NDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowaQYJ KwYBBAGCNxAEMVwwWjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCDwFjpbN8Ukj9EDsUYInQJTBrBgsqhkiG9w0B CRACCzFcoFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmlj c3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BY6WzfFJI/RA7FGCJ0CUwDQYJKoZIhvcNAQEBBQAE ggEAEwQiXjI8EIXEmEgagV7hNFYMrUici8HlVvcl37RX/JxBkhKMhCSWEaAdlj5OUaL3dvEER8J+ n3efKh6XlMK4Du0tImvPMo26jikFj9E4v5z2SAIc0c2J6m3IHf9vN9JKJQ2H3nbvVCTeQo+3xLOM 0QrPL/cd6fP2zGG44AWY5hGMOMAxs5FxS4Y+8Gq2L5h+TaB6jVfisLAW5WzTTniYHlWP83u8GCCe G81JGSsIIjXNrWtpCqnEizKFRdg+rGbKJ0W626xVMcCWcbnoYrVPHnvziXIH4gvh7G64pyrangNB T8WRs6h/D9+ZgWQETFg95rULtkTjiCAR3DsAwAbRkQAAAAAAAA== ------=_NextPart_000_0010_01D5AC3C.39D4CBC0-- From nobody Fri Dec 6 07:38:22 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08F21200C5; Fri, 6 Dec 2019 07:38:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ozx0X6bzpDER; Fri, 6 Dec 2019 07:38:18 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2EB12081C; Fri, 6 Dec 2019 07:38:18 -0800 (PST) Received: from mail-qv1-f51.google.com ([209.85.219.51]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1idFgM-0007M5-Od; Fri, 06 Dec 2019 16:38:14 +0100 Received: by mail-qv1-f51.google.com with SMTP id q19so37763qvy.9; Fri, 06 Dec 2019 07:38:14 -0800 (PST) X-Gm-Message-State: APjAAAVeELS91qrh4g7kyXPT0n7zebdJd5oA5KtfA+E1eGY3RLwXSsYv Lfokz2h94MAHegRSfQyeQIyDf7d96i2+27iObyA= X-Google-Smtp-Source: APXvYqyEb7/wKcS0LcrjSwpqGTgHaRduj4Ao9/oc0QBJT/P6XhPuEOUgp/LqIOMeSz759uv6LCHo/VfXjztM4aBE6ZM= X-Received: by 2002:a05:6214:14ad:: with SMTP id bo13mr1467384qvb.22.1575646693547; Fri, 06 Dec 2019 07:38:13 -0800 (PST) MIME-Version: 1.0 References: <048701d5a189$2177f9c0$6467ed40$@augustcellars.com> In-Reply-To: <048701d5a189$2177f9c0$6467ed40$@augustcellars.com> From: Klaus Hartke Date: Fri, 6 Dec 2019 16:37:37 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Jim Schaad Cc: draft-hartke-t2trg-coral-reef@ietf.org, "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1575646698; 60db8347; X-HE-SMSGID: 1idFgM-0007M5-Od Archived-At: Subject: Re: [core] Comments on draft-hartke-t2trg-coral-reef-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 15:38:21 -0000 Hi Jim, thanks a lot for your comments! > * I am having a problem with you saying that you are defining a new > well-known resource. "/.well-known/core" has already been defined. It > would be better to say you are expanding the capabilities I think. This is mostly due to the fact that I haven't looked much yet into how RFC 6690 and -coral-reef would coexist on the the same well-known path, so at the moment -coral-reef is just assuming that it's alone in the universe (see also the disclaimer in [1]). Of course, this cannot stay like that if we want to work towards a WG adoption. Then we should figure out whether -coral-reef should take over the resource entirely (possibly with a section describing the "legacy" format (with an opportunity to "fix" that)) or whether -coral-reef should be presented as an extension to RFC 6690 or something else. > * In the first example in the document (page 4), I believe that you should > be able to return "ct TBD3" as part of the "/sensors" resource. This may > or may not be covered by this document so I am not sure if you think it > would be allowable or not. Specifically, I believe that any place you can > currently use application/link-format you should be able to use REEF Not sure. Not every resource that has a Link Format representation behaves like . But in this case (the example was stolen from [2]) I think the intention was that functions like a kind of "mini" resource directory for additional resources on the server. So it would indeed make sense here to use -coral-reef for that too. I wonder if/how we should signal to a client that not just happens to have a representation in format TBD3 but also implements the -coral-reef interface. > * At the end of section 2.1, second to last paragraph - The last clause in > the last sentence has a problem with matching the pronoun back to the > correct subject. On first read I matched one back to schema not to the > details. I think that use of a semicolon would fix this problem. OLD: The example contains links to three resources of interest on the server: , , and . For , a content format hint ("ct") and a title ("title") are provided as resource metadata. For both and , a resource type ("rt") and an interface description ("if") are provided. Additionally, two links are provided with further detail on : one to a schema describing this resource ("describedby") and one to an substitute ("alternate"). NEW: The example contains links to three resources of interest on the server: , , and . For , a content format hint ("ct") and a title ("title") are provided as resource metadata. For both and , a resource type ("rt"), and an interface description ("if") are provided. Additionally, two links are provided that provide further details on : a link to a schema describing this resource ("describedby") and a link to a substitute ("alternate"). Does that fix it for you? Otherwise I'd need a bit of help since I'm not a native speaker :) > * In section 2.2, the registration interface is currently missing the query > parameters. The big ones would be ep (endpoint name) and d (domain), you > should not need base because that can be represented in the CoRAL document. > About the time I got to section 5.2 on the second pass, I realized that you > did not deal with endpoint registration and queries at all. This is a > needed feature. This is a feature that I don't understand. What does it do and why is it needed? > * There should however be a statement that the link for an rd-item when > registering MUST NOT only be a path comment. I assume you mean you do not want relative references. But, if I want to register a resource that has the same authority (IP address/DNS name and port) as the resource directory, why should I not be able to register that using a relative reference? > * I think there should be a statement that only the first base directive can > include schema + authority information. This is because you are only > supposed to register resources for one entity at a time. -coral-reef currently doesn't make this restriction/assumption. If you have, for example, a commissioning tool that registers the resources of lots of servers in a resource directory and wants to register all of them as a single unit, then I don't see why shouldn't be allowed to do so (given proper authorizations). > * Section 3 - I am not sure you want to use the word "identifier" in the > description of title. That is not normally how I think of a title. I > would probably also use "title" rather than "label" in both paragraphs. > > * Section 3 - you need to give me something to better distinguish between > #type and #ct as they both seem to say the same thing to me. > > * Section 3 - you need to say something about how to deal with #ct for > multiple values. I am not sure about #if Section 3 currently sources its list of items from different places, such as [3] and [4], and hasn't seen much work yet. For example, the word "identifier" was just copied from [4]. Let's go through the list sometime (maybe in a CoRE virtual interim?) and decide what to keep, how to name it (I'm not a big fan of the acronyms), and how to describe it. > * Section 3 - I think that you should have all of the tags in this section. > For example rd-item and rd-unit. rd-item and rd-unit are not resource metadata vocabulary, so I wouldn't add them to this section. But, yes, having a combined list of all the vocabulary used in the document somewhere would be nice. Maybe as an appendix? > * General - I know that this is supposed to be what is going to happen, an > ?rt= query option is going to be the same as reef#rt, but I don't think > there is anyplace in this document that makes that statement. Section 4.2.2 [5] currently says: On success, the server returns a 2.05 (Content) response with a representation of the list of resources (see Section 4.1.1), but containing only the subset of links that has resource metadata of type with the specified text value. Klaus [1] https://tools.ietf.org/html/draft-hartke-t2trg-coral-reef-03#section-1 [2] https://tools.ietf.org/html/rfc6690#section-5 [3] https://tools.ietf.org/html/rfc6690#section-3 [4] https://tools.ietf.org/html/rfc8288#section-3.4.1 [5] https://tools.ietf.org/html/draft-hartke-t2trg-coral-reef-03#section-4.2.2 From nobody Fri Dec 6 10:12:00 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BCE120059; Fri, 6 Dec 2019 10:11:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 GLQXhcN4RHRa; Fri, 6 Dec 2019 10:11:54 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B72F12006D; Fri, 6 Dec 2019 10:11:54 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 6 Dec 2019 10:11:48 -0800 From: Jim Schaad To: 'Klaus Hartke' CC: , References: <048701d5a189$2177f9c0$6467ed40$@augustcellars.com> In-Reply-To: Date: Fri, 6 Dec 2019 10:11:46 -0800 Message-ID: <034601d5ac60$a1ea9180$e5bfb480$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGbDY5eketAF6ADVAxOVPdt9lkeRwFtBPbwqBc4xMA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] Comments on draft-hartke-t2trg-coral-reef-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 18:11:59 -0000 -----Original Message----- From: Klaus Hartke =20 Sent: Friday, December 6, 2019 7:38 AM To: Jim Schaad Cc: draft-hartke-t2trg-coral-reef@ietf.org; core@ietf.org WG = Subject: Re: [core] Comments on draft-hartke-t2trg-coral-reef-03 Hi Jim, thanks a lot for your comments! > * I am having a problem with you saying that you are defining a new=20 > well-known resource. "/.well-known/core" has already been defined. =20 > It would be better to say you are expanding the capabilities I think. This is mostly due to the fact that I haven't looked much yet into how = RFC 6690 and -coral-reef would coexist on the the same well-known path, = so at the moment -coral-reef is just assuming that it's alone in the = universe (see also the disclaimer in [1]). Of course, this cannot stay = like that if we want to work towards a WG adoption. Then we should = figure out whether -coral-reef should take over the resource entirely = (possibly with a section describing the "legacy" format (with an = opportunity to "fix" that)) or whether -coral-reef should be presented = as an extension to RFC 6690 or something else. > * In the first example in the document (page 4), I believe that you = should > be able to return "ct TBD3" as part of the "/sensors" resource. This = may > or may not be covered by this document so I am not sure if you think=20 > it would be allowable or not. Specifically, I believe that any place=20 > you can currently use application/link-format you should be able to=20 > use REEF Not sure. Not every resource that has a Link Format representation = behaves like . But in this case (the example was = stolen from [2]) I think the intention was that functions = like a kind of "mini" resource directory for additional resources on the = server. So it would indeed make sense here to use -coral-reef for that = too. I wonder if/how we should signal to a client that not = just happens to have a representation in format TBD3 but also implements = the -coral-reef interface. [JLS] I don't know that I have dealt with anything that did link-format = that was not a directory type thing. Yes it would only make sense for = those things which are directory like. > * At the end of section 2.1, second to last paragraph - The last=20 > clause in the last sentence has a problem with matching the pronoun=20 > back to the correct subject. On first read I matched one back to=20 > schema not to the details. I think that use of a semicolon would fix = this problem. OLD: The example contains links to three resources of interest on the server: , , and . For , a content format hint ("ct") and a title ("title") are provided as resource metadata. For both and , a resource type ("rt") and an interface description ("if") are provided. Additionally, two links are provided with further detail on : one to a schema describing this resource ("describedby") and one to an substitute ("alternate"). NEW: The example contains links to three resources of interest on the server: , , and . For , a content format hint ("ct") and a title ("title") are provided as resource metadata. For both and , a resource type ("rt"), and an interface description ("if") are provided. Additionally, two links are provided that provide further details on : a link to a schema describing this resource ("describedby") and a link to a substitute ("alternate"). Does that fix it for you? Otherwise I'd need a bit of help since I'm not = a native speaker :) [JLS] Looks like you have the same for both OLD and NEW, however this = fixes the issue. > * In section 2.2, the registration interface is currently missing the=20 > query parameters. The big ones would be ep (endpoint name) and d=20 > (domain), you should not need base because that can be represented in = the CoRAL document. > About the time I got to section 5.2 on the second pass, I realized=20 > that you did not deal with endpoint registration and queries at all. =20 > This is a needed feature. This is a feature that I don't understand. What does it do and why is it = needed? [JLS] Endpoint and Domain provide a way to give a "name" to an endpoint = and to associate that name to the entry in the RD. For a third party, = among other things this means that you only need to find the name of the = endpoint to get and update the entry in the resource directory. You do = not need to both remember and share the location path to other entities. = If you think that this is not clear in the RD document, this should be = raised as an issue to get better text there. > * There should however be a statement that the link for an rd-item=20 > when registering MUST NOT only be a path comment. I assume you mean you do not want relative references. But, if I want to = register a resource that has the same authority (IP address/DNS name and = port) as the resource directory, why should I not be able to register = that using a relative reference? [JLS] Yes I meant component not comment. In theory there is no reason = why you should no be able to do so. In practice it is going almost = always be an indication that there is an error in the registration. The = only entity this should be true for is the RD itself. > * I think there should be a statement that only the first base=20 > directive can include schema + authority information. This is because = > you are only supposed to register resources for one entity at a time. -coral-reef currently doesn't make this restriction/assumption. If you = have, for example, a commissioning tool that registers the resources of = lots of servers in a resource directory and wants to register all of = them as a single unit, then I don't see why shouldn't be allowed to do = so (given proper authorizations). [JLS] Well - you are going to have a hard time returning the = location-path to each of those different servers that you just = registered into the RD. > * Section 3 - I am not sure you want to use the word "identifier" in = the > description of title. That is not normally how I think of a title. = I > would probably also use "title" rather than "label" in both = paragraphs. > > * Section 3 - you need to give me something to better distinguish=20 > between #type and #ct as they both seem to say the same thing to me. > > * Section 3 - you need to say something about how to deal with #ct for = > multiple values. I am not sure about #if Section 3 currently sources its list of items from different places, = such as [3] and [4], and hasn't seen much work yet. For example, the = word "identifier" was just copied from [4]. Let's go through the list = sometime (maybe in a CoRE virtual interim?) and decide what to keep, how = to name it (I'm not a big fan of the acronyms), and how to describe it. [JLS] Sounds reasonable. > * Section 3 - I think that you should have all of the tags in this = section. > For example rd-item and rd-unit. rd-item and rd-unit are not resource metadata vocabulary, so I wouldn't = add them to this section. But, yes, having a combined list of all the = vocabulary used in the document somewhere would be nice. Maybe as an = appendix? [JLS] You may not thinking of them as resource metadata vocabulary, but = they are vocabulary for -reef. As such they need to have a description = someplace that is easy to find and having all of the vocabulary in a = single location is very useful. Titling the section "Reef = Vocabulary" and then having subsections would also be a way to address = you grouping issue. > * General - I know that this is supposed to be what is going to=20 > happen, an ?rt=3D query option is going to be the same as reef#rt, but = I=20 > don't think there is anyplace in this document that makes that = statement. Section 4.2.2 [5] currently says: On success, the server returns a 2.05 (Content) response with a representation of the list of resources (see Section 4.1.1), but containing only the subset of links that has resource metadata of type with the specified text value. [JLS] That does not answer my question. Do rt and = map to the same information, and if so = where is this stated so that I don't get confused about other things = that have similar looking names. This is going to be really an issue if = you start getting rid of abbreviations and go to = instead because the strings no = longer match. Given that the RD needs to support arbitrary strings in = the link format, knowing if the list is closed or open ended in some = manner helps. =20 ** Jim Klaus [1] = https://tools.ietf.org/html/draft-hartke-t2trg-coral-reef-03#section-1 [2] https://tools.ietf.org/html/rfc6690#section-5 [3] https://tools.ietf.org/html/rfc6690#section-3 [4] https://tools.ietf.org/html/rfc8288#section-3.4.1 [5] = https://tools.ietf.org/html/draft-hartke-t2trg-coral-reef-03#section-4.2.= 2 From nobody Sat Dec 7 03:19:12 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560F71200F1; Sat, 7 Dec 2019 03:19:11 -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_DNSWL_NONE=-0.0001, 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 ugsiNotCv0Go; Sat, 7 Dec 2019 03:19:08 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A8B120106; Sat, 7 Dec 2019 03:19:08 -0800 (PST) Received: from mail-qk1-f178.google.com ([209.85.222.178]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1idY75-0002pp-KK; Sat, 07 Dec 2019 12:19:03 +0100 Received: by mail-qk1-f178.google.com with SMTP id k6so8856008qki.5; Sat, 07 Dec 2019 03:19:03 -0800 (PST) X-Gm-Message-State: APjAAAXf3wmg1uAQEwD4vPlyqHmGANBXSEaewCMHufNtAxbly9EgKfg7 NTVNHThqVFzcjkGdfvA3uYpdqgXRrQG+RYUf1Gk= X-Google-Smtp-Source: APXvYqzsMxc3D+2DMYBYfDpWG0RFRQPDylPByk6gYje6z2K4hO4+NiTzs3Cizz4HX/+JigQIh09r7OfPaec80prBPY8= X-Received: by 2002:a05:620a:6db:: with SMTP id 27mr4276605qky.453.1575717542309; Sat, 07 Dec 2019 03:19:02 -0800 (PST) MIME-Version: 1.0 References: <048701d5a189$2177f9c0$6467ed40$@augustcellars.com> <034601d5ac60$a1ea9180$e5bfb480$@augustcellars.com> In-Reply-To: <034601d5ac60$a1ea9180$e5bfb480$@augustcellars.com> From: Klaus Hartke Date: Sat, 7 Dec 2019 12:18:26 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Jim Schaad Cc: draft-hartke-t2trg-coral-reef@ietf.org, "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1575717548; 464c51bb; X-HE-SMSGID: 1idY75-0002pp-KK Archived-At: Subject: Re: [core] Comments on draft-hartke-t2trg-coral-reef-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2019 11:19:11 -0000 Jim Schaad wrote: > [JLS] Endpoint and Domain provide a way to give a "name" to an endpoint a= nd to associate that name to the entry in the RD. For a third party, among= other things this means that you only need to find the name of the endpoin= t to get and update the entry in the resource directory. You do not need t= o both remember and share the location path to other entities. There are two sides: the lookup interface and the registration interface. On the lookup interface side, if you want to get all the registered resources associated with one CoAP endpoint, I guess the authority (IP address/DNS name and port) is the natural endpoint identifier. On the registration interface side, you have the registration units in -reef. If you want clients to give these units a name, then you immediately run into namespace coordination problems. So I think the best solution here is to let the server decide the name of a registration unit. That indeed means you have to pass the server-generated name around if want other parties to make modifications, but the same applies to a client-generated name, no? > [JLS] Yes I meant component not comment. In theory there is no reason wh= y you should no be able to do so. In practice it is going almost always be= an indication that there is an error in the registration. The only entity= this should be true for is the RD itself. That seems like an issue of how you want to set up policies for your resource directory, but not an interoperability issue. >> If you have, for example, a commissioning tool that registers the resour= ces of lots of servers in a resource directory and wants to register all of= them as a single unit, then I don't see why shouldn't be allowed to do so = (given proper authorizations). > > [JLS] Well - you are going to have a hard time returning the location-pat= h to each of those different servers that you just registered into the RD. On the lookup interface side, if multiple resources on different servers match the query, then you'll need to return URIs to all those different servers. On the registration interface side, if a commissioning tool registers many resources on different servers at once, then this single unit has only a single location in -reef. Maybe this is part of the endpoint/domain thing that I don't understand... >> Section 4.2.2 [5] currently says: >> >> On success, the server returns a 2.05 (Content) response with a >> representation of the list of resources (see Section 4.1.1), but >> containing only the subset of links that has resource metadata of >> type with the specified text value. > > [JLS] That does not answer my question. Do rt and map to the same information, and if so where is this stated so tha= t I don't get confused about other things that have similar looking names. = This is going to be really an issue if you start getting rid of abbreviati= ons and go to instead because the= strings no longer match. Given that the RD needs to support arbitrary str= ings in the link format, knowing if the list is closed or open ended in som= e manner helps. There are four different namespaces here: The names of attributes that RFC 6690 allows you to put in a Link, the name of query parameters that RFC 6690 allows you to use for filtering, the name of query parameters that -reef allows you to use for filtering, and the resource metadata vocabulary in -reef. * The list of attributes that RFC 6690 allows you to put in a Link is basically open ended. There are a few attributes defined in RFC 6690 ("rel", "anchor", "rev", "hreflang", "media", "title", "title*", "type", "rt", "if", "sz") but any number of additional attributes can be defined as long as the name conforms to the `parmname` rule and is not "href". [1] * The list of query parameters that RFC 6690 allows you to use is the same as the list of attributes with the addition of "href" [2]. * The list of query parameters that -reef allows you to use currently includes only "rt" [3] and "if" [4]. These map to and , respectively [3][4]. The idea is that you can query by any other metadata by using FETCH [5] instead of using GET with query parameter. * The list of resource metadata vocabulary supported by -reef is open ended. (The vocabulary "includes but is not limited to" the items in section 3.) Now there are those attributes defined in RFC 6690 and a bunch of others that have been defined in a number of different places. When we create the vocabulary for -reef, it would be nice if we had an equivalent to each of them. But I think (and that was the conclusion of a discussion with Christian a while ago) that we'll probably don't want to do a mechanical mapping but rather a semantic one. For example, have readable names instead of acronyms, do not use decimal strings for integers, do not use whitespace-separated strings for lists, etc. So the list of items in that mapping can only closed: If you convert from Link Format to CoRAL, you really need to understand each of the attributes you're converting. Our conclusion was that this is a viable way forward even if new attributes get defined in the future; those would just need to define their mapping to existing or new CoRAL vocabulary. You can then easily query by them using FETCH. For queries using GET with query parameter, I guess we can choose if we want to have a fixed list or rather a mechanism for discovering an open ended list of query parameter names that are supported by a server. Klaus [1] https://tools.ietf.org/html/rfc6690#section-2 [2] https://tools.ietf.org/html/rfc6690#section-4.1 [3] https://tools.ietf.org/html/draft-hartke-t2trg-coral-reef-03#section-5.= 3.2 [4] https://tools.ietf.org/html/draft-hartke-t2trg-coral-reef-03#section-5.= 3.3 [5] https://tools.ietf.org/html/draft-hartke-t2trg-coral-reef-03#section-5.= 3.4 From nobody Sat Dec 7 21:03:08 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB4312003E for ; Sat, 7 Dec 2019 21:03:07 -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_DNSWL_NONE=-0.0001, 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 gXlfS3haSg3l for ; Sat, 7 Dec 2019 21:03:05 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D96A120033 for ; Sat, 7 Dec 2019 21:03:05 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 7 Dec 2019 21:02:59 -0800 From: Jim Schaad To: 'Klaus Hartke' , 'Carsten Bormann' CC: Date: Sat, 7 Dec 2019 21:02:58 -0800 Message-ID: <039101d5ad84$c3d656b0$4b830410$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdWtWgTMrYSayXktTNaOYW0MrHp1WQ== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] What do coap URIs mean X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 08 Dec 2019 05:03:08 -0000 I have been playing with the HREF and CoRAL documents and ended up with a question that I have no idea what the answer is. coap://host.example/a/b/c This URI represents a resource on the server that you can send a set of verbs to. Given that I represent resources in my implementation as a tree, this is an easy thing to describe and find. coap://host.example/a//b/c This URI is a bit strange, but again I can build this tree and be happy with receiving a verb addressed to that path. It is also something that appears to be totally legal based on the URI -> CoAP options algorithm. coap://host.example/a/b/c/ I don't know what this URI represents. Is this supposed to go to the same location as the first example above, or is it supposed to go to a resource with an empty name under c in my tree? Jim From nobody Sat Dec 7 21:22:40 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C03212003F for ; Sat, 7 Dec 2019 21:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAf_98NuWopE for ; Sat, 7 Dec 2019 21:22:38 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3696120033 for ; Sat, 7 Dec 2019 21:22:37 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id t2so12328189wrr.1 for ; Sat, 07 Dec 2019 21:22:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lXcgTNVE4IGte3fu12754M3+AZC0NTWotznElPmMpJc=; b=u965d0l10CZI3oO60kFx/sNcEGDeoe7Q1RA4zZxj7Bp2+dSrzV2qXp3JBeRz20gk/V EtApDMuejc9oUH+jluJXfLcK0SXMYwXkZBMGCsssNseIQnaDZuA9f+H11aHgBOodYowT gUvHnEuBLGDmSb0zmlDGwukolbzQ5KbCWMZU+GrzFvLiVKNav6dMm+385apF/3+AbxAa JLxuTX9M1f9z/UtKnXYZXzCkhx9Y6wcIgQ69EroN2BF2b/r95Xr1QsCHX6aRqa6nw2JS Rh9T/0k0Fd8WuKTN4hmUXAyHyq8uMEVvJjw4YWhcU7KjUL51++PhVnvXevPvfmQxjT4U 374w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lXcgTNVE4IGte3fu12754M3+AZC0NTWotznElPmMpJc=; b=UKI1AG8cJB7/iPMg6ZD4J3CJkymtk+ulhRPX3it8OJJrYKPeg2WA+VJO1TT21HEHPX Xo11ltn1S+f8IXrHn5tuT0UABzPhshvCEJgZfML+4Ct8nAh8upU46FB53UOOL5K8r3ii rcsc5AiKfLyrw2gPqdenjY2Dcgi0GPDToXAB7T05xvZGbN3aacg95duoHYrU25xzOR9o Yh+dt1RqIrekt9msbzezcCo+pHL3nB0X0Oijj+1Tz3ERCHv8+ubr2fBBwqa4R3jnNLHW P+bke5NmsQoD35qStqMwL8PtzAFNYW1/qwVB6pnTteAunJjaGLPNds7cLQrB2OHcnkEa K4/w== X-Gm-Message-State: APjAAAU1jLhP1LozsSETl5bMkcRLtGsL9bICDRRQz2Bc/7b0fv7HBTtW gzHJC7MgqcJakDgeh9pnQS8= X-Google-Smtp-Source: APXvYqzCrTWwKsrnPrWTivfVk5LP5r+ZjrkdN8g3+fHS6y09I+tqqlT6jrup8gGPe3nNDHXYpBlARg== X-Received: by 2002:adf:f1d0:: with SMTP id z16mr23196655wro.209.1575782556367; Sat, 07 Dec 2019 21:22:36 -0800 (PST) Received: from [192.168.217.116] (p548DC893.dip0.t-ipconnect.de. [84.141.200.147]) by smtp.gmail.com with ESMTPSA id x10sm22176859wrp.58.2019.12.07.21.22.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Dec 2019 21:22:35 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <039101d5ad84$c3d656b0$4b830410$@augustcellars.com> Date: Sun, 8 Dec 2019 06:22:33 +0100 Cc: Klaus Hartke , core@ietf.org X-Mao-Original-Outgoing-Id: 597475260.4179929-cf846cf739a4a09dbc39687e555144a5 Content-Transfer-Encoding: quoted-printable Message-Id: <705B42F8-5078-4F9E-931E-9ED20729106C@gmail.com> References: <039101d5ad84$c3d656b0$4b830410$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] What do coap URIs mean X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 08 Dec 2019 05:22:39 -0000 Hi Jim, On Dec 8, 2019, at 06:02, Jim Schaad wrote: >=20 > I have been playing with the HREF and CoRAL documents and ended up = with a > question that I have no idea what the answer is. >=20 > coap://host.example/a/b/c >=20 > This URI represents a resource on the server that you can send a set = of > verbs to. Given that I represent resources in my implementation as a = tree, > this is an easy thing to describe and find. >=20 > coap://host.example/a//b/c >=20 > This URI is a bit strange, but again I can build this tree and be = happy with > receiving a verb addressed to that path. It is also something that = appears > to be totally legal based on the URI -> CoAP options algorithm. >=20 > coap://host.example/a/b/c/ >=20 > I don't know what this URI represents. Is this supposed to go to the = same > location as the first example above, No. > or is it supposed to go to a resource > with an empty name under c in my tree? This. Many HTTP Web servers handle the fact that (1) and (3) are different by = redirecting to the one that is intended. =20 There is one little problem lurking here in that coap://host.example and=20 coap://host.example/ are supposed to be the same thing (see also 6.2.3 and 6.2.4 of 3986 for = more of this). Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 9 09:17:26 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A1A120052 for ; Mon, 9 Dec 2019 09:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 nHCOCs_HyPuS for ; Mon, 9 Dec 2019 09:17:22 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38DDD120047 for ; Mon, 9 Dec 2019 09:17:22 -0800 (PST) Received: from [192.168.217.116] (p548DC893.dip0.t-ipconnect.de [84.141.200.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47Wqcw3wGWz16Bh; Mon, 9 Dec 2019 18:17:20 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 9 Dec 2019 18:17:20 +0100 X-Mao-Original-Outgoing-Id: 597604635.700677-6b1ecbbd52f7e6dd4db08fd80d8cbf05 Content-Transfer-Encoding: quoted-printable Message-Id: <2D679FD0-F95F-488E-BCC4-0B90693FDA3A@tzi.org> References: To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_CoRE_Working_Group_Adoption_call_f?= =?utf-8?q?or_draft-jarvinen-core-fasor-02?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 17:17:25 -0000 I know we are entering the slow season, so this is a gentle reminder: > On Nov 19, 2019, at 09:03, Carsten Bormann wrote: >=20 > This message starts a three-week working group adoption call. > (Two weeks because the WG call partially overlaps an IETF and the US = Thanksgiving week.) >=20 > If you have read the draft and support adopting it, please say so. > If you see a problem with adopting it as a WG document, please tell = us. So far, nobody indicated their support for this adoption on this mailing = list outside the author team. Is really nobody else in the CoRE WG interested in this? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 9 12:34:35 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB83A12029C for ; Mon, 9 Dec 2019 12:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 6R7PgG560GSU for ; Mon, 9 Dec 2019 12:34:31 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987F0120236 for ; Mon, 9 Dec 2019 12:34:31 -0800 (PST) Received: from [192.168.217.116] (p548DC893.dip0.t-ipconnect.de [84.141.200.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47Ww0P6ccgz161X; Mon, 9 Dec 2019 21:34:29 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 9 Dec 2019 21:34:29 +0100 X-Mao-Original-Outgoing-Id: 597616467.379476-1f3ca5a01adab1022a2e48d03fdf9a13 Content-Transfer-Encoding: quoted-printable Message-Id: <4C059F03-BB42-498D-9B75-A08BEA274416@tzi.org> References: <481f9820-bcea-af6a-d5c4-d713be24d43d@isode.com> <20191119125733.GA8007@hephaistos.amsuess.com> To: "core@ietf.org" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] DNS-SD service types for CoRE-RD (Re: AD review of draft-ietf-core-resource-directory-23) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 20:34:34 -0000 On Nov 20, 2019, at 03:03, Alexey Melnikov = wrote: >=20 >>> I think the following reference is Normative the way it is used in = the >>> document: >>>=20 >>> [I-D.ietf-core-rd-dns-sd] Stok, P., Koster, M., and C. Amsuess, = "CoRE >>> Resource Directory: DNS-SD mapping", draft-ietf-core-rd-dns-sd-05 = (work in >>> progress), July 2019. >>=20 >> Oh please not. >>=20 >> I suppose this is due to "The use of DNS facilities is described in >> [rd-dns-sd]" being listed as a recommended way, or are there more >> aspects to it? >>=20 >> The DNS-SD component has been holding RD back quite a bit, so if it's = that >> recommendation, I assume the group might want to reconsider = recommending >> that mechanism for discovering the RD. >=20 > The WG started to discuss whether this is truly normative. I am = awaiting conclusion of this discussion. The outcome in discussion in the Friday meeting was that the = resource-directory specification should simply define the small number = of DNS-SD service types that are needed for resource directory = discovery. =20 We said details were to be taken to the list, which I want to initiate = now. In the meeting, I gave the three examples _core-rd._udp, = _core-rd-tls._udp, and _core-rd._tcp =E2=80=94 noting that while core-rd = is a proper RD service type, core-rd-tls isn=E2=80=99t. To cover the = six transports we have for CoAP today (coap, coaps, coap+tcp, coaps+tcp, = coap+ws, coaps+ws), we would need four service types on top of _tcp and = could use two of them over _udp? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Dec 9 14:42:16 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761E4120113 for ; Mon, 9 Dec 2019 14:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 CxHnHD84hgeD for ; Mon, 9 Dec 2019 14:42:12 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C94C120086 for ; Mon, 9 Dec 2019 14:42:12 -0800 (PST) Received: from client-0059.vpn.uni-bremen.de (client-0059.vpn.uni-bremen.de [134.102.107.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47Wyqk2trzz161X; Mon, 9 Dec 2019 23:42:10 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 597624127.479866-bbb6148add716f3655faee5b3d96b9da Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 9 Dec 2019 23:42:09 +0100 Message-Id: To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [core] CoRE @ IETF106: Summary and Minutes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2019 22:42:15 -0000 We have uploaded draft minutes for the two CoRE meetings at IETF106: https://datatracker.ietf.org/meeting/106/materials/minutes-106-core As usual, this starts with a summary of what happened (with fewer = technical details), followed by more detailed minutes as collected in = Etherpad. Please send fixes and updates to core-chairs@ietf.org or to the mailing = list, preferably within the next 7 days or at least before you dive into = the holidays. For easier viewing and commenting, the summary part is replicated below. Gr=C3=BC=C3=9Fe, Carsten # CoRE WG - Summary IETF106 (Constrained RESTful Environments WG, Draft Minutes 0.1) The core WG held two meetings at IETF 106 in Singapore, both of which = are summarized in these minutes. Videos: : Wednesday (2019-11-20, 2 h): : Friday (2019-11-22, 1.5 h): Slides: = Raw minutes: Thanks to the note takers Niklas and Ivaylo! ## Working Group Document Status In RFC-Editor=E2=80=99s Queue: * draft-ietf-core-multipart-ct-04 In IESG processing: * draft-ietf-core-hop-limit-07: Alexey explained that the "Approved-announcement to be sent::Point Raised - writeup needed" status is due to the open question why this cannot be mapped to HTTP. Carsten proposed defining a generic HTTP header field for "tunneling" CoAP options, outside this document. (With that, the draft has since transitioned to the RFC-Editor's Queue on 2019-11-26.) * draft-ietf-core-resource-directory-23: In AD Evaluation, substatus "Revised I-D Needed". As was further discussed in the Friday meeting, the main open point is the question whether the reference to the much less well-advanced RD-DNS-SD draft needs to be normative. The outcome of the discussion was that the resource-directory draft should simply define the small number of DNS-SD service types that are needed for resource directory discovery, with details to be taken to the list. * draft-ietf-core-senml-more-units-03: Status "Waiting for Writeup". Some need for clarification that the secondary registry SHOULD be implemented but the derived units still SHOULD NOT be used, and for the designated expert instructions. Concerns had been raised about opening up the second registry for derived units, making it harder for a SenML application to find out whether a unit encountered was actually of interest to it. Discussion in the first session resulted in the tentative proposal to mark secondary units with an asterisk (as in "*km/h", as opposed to unmarked "m/s"). Further discussion in the second session made clear that while this makes the use of secondary units stand out, it does not really improve the situation of SenML applications that want to quickly discard measurements for units they do not care about, unless they track the contents of the two registries, which would make the asterisks redundant. There also was some feedback the asterisks would make the adoption of the SenML units registry by other SDOs more difficult. The in-room consensus not to go for the asterisks, but to include more explanatory text about implementation strategies, needs to confirmed on the mailing list. Also, it was brought up that proactively registering remaining SI-based units in table 1 now might improve the stability of that table further on; this should be done in an independent effort (exercising the registry). * draft-ietf-core-senml-etch-05: IESG Evaluation::Revised I-D Needed. Latest changes are on github, a few comments still to be addressed. In particular, there may be a need to select for units. Also, a decision needs to be made what happens if the selector in a patch record matches multiple records (proposal: error); need to double check idempotency, too. In Post-WGLC processing: * draft-ietf-core-stateless-03: Authors to update draft from WGLC input. (Done as of 2019-12-06 in draft-ietf-core-stateless-04.) * draft-ietf-core-echo-request-tag-08: Update made the deadline, now needs write-up from shepherd. Almost at WGLC: * draft-ietf-core-dev-urn-03: (expired), an ABNF problem needs to be fixed and the draft resubmitted before it can go directly into WG last-call. In WG adoption call: * draft-bormann-core-corr-clar-00: WG adoption call finished with only one item of feedback; in-room consensus was good before that; what should we do now? * draft-jarvinen-core-fasor-02: (adoption call runs until 2019-12-03) ## CoRECONF cluster * draft-ietf-core-yang-cbor-11, draft-ietf-core-yang-library-00, draft-ietf-core-comi-08, draft-ietf-core-sid-07: Now ready for WGLC, to be sent to CoRE as well as netconf/netmod (with the discussion to happen on CoRE). (One comment on the numeric range of SIDs still to be taken care of.) ## Group communication cluster * draft-ietf-core-oscore-groupcomm-06: Ongoing. Moving to COSE-bis registries, discussing countersignature algorithms, details on key rollover. After this round, might be ready for WGLC; previous reviewers please vouch for that. Might need 7390bis (below) as a normative reference. * draft-tiloca-core-oscore-discovery-04: Reviewer volunteers are asked to provide reviews now. Also: The usual discussion of needing a registry for link target attributes (which is now possible according to the updated RFC 8288) ensued; Klaus might have a draft soon. * draft-tiloca-core-observe-multicast-notifications-01: New work first presented in Montreal; was revised with a simpler approach, which is could be summarized as the server redirecting a client to a multicast group by supplying a phantom request for that; this allows the server to choose a group and a token. In-room support, but probably needs more work, e.g., in congestion control. Need more reviewers now to make progress on this as a WG. * draft-dijk-core-groupcomm-bis-02: intended normative successor of (and obsoleting) RFC 7390 (dropping the experimental RESTful protocol that has not been picked up), with some initial reviews already addressed. In-room consensus to adopt as a WG document; to be confirmed on the mailing list. Then, before WGLC, we should ascertain implementation support for the whole breadth of the draft. ## SenML cluster (See also documents in IESG, above.) * draft-ietf-core-senml-data-ct-01: updated with feedback from IETF105, still grappling with potential conflicts between "ct" and "ct_". * draft-keranen-core-senml-base-prefix-00 (ipr #3662): need to look closer at use cases and find out how this is not a practical problem in LWM2M usage so far. This draft could be combined with Hannes' draft; more analysis is needed. ## CoRE Applications Klaus led the group through a review of results from Tuesday's side meeting. As a result, the following new draft was published already: * draft-fossati-core-coap-problem-00: The draft uses custom CBOR, but the information could also be mapped to CoRAL. More discussion needed. With respect code point management (numeric identifiers), we might want to learn from the CoRECONF SID approach for other code point spaces, too. Also, some more thinking is needed about error responses that encode application results; some of this has been added in RFC 8132 (FETCH/PATCH): 4.09 ("conflict", i.e., application would reach unwanted state), 4.22 (unprocessable entity); do we want to add more? * draft-ietf-core-coral-01, draft-ietf-core-href-01: small update was needed so far. * draft-ietf-core-coap-pubsub-09: Proposal for update was discussed in Montreal; feature parity with existing -09 not yet reached. draft-hartke-t2trg-coral-pubsub-00 explores how CoRAL might be used for enabling publish/subscribe-style communication over CoAP. Various other T2TRG drafts make use of CoRAL, e.g., draft-hartke-t2trg-coral-reef-03 and draft-hartke-t2trg-data-hub-05, and should be considered in this context. It also turns out that draft-tiloca-ace-oscore-gm-admin-01 is very similar in structure to pubsub. Carsten presented a proposed timeline for completing CoRAL: stable at IETF107, implemented and validated at IETF108, WGLC mid-2020. Klaus agreed that a lot of validation has already happened. Also, a question came up whether there should be a JSON serialization of CoRAL (there are two proposals for that now =E2=80=94 do we need both?). ## Flextime Francesca brought up the integration of EDHOC (draft-selander-lake-edhoc-00) and OSCORE (RFC 8613) =E2=80=94 can the = third EDHOC message (maybe 20 bytes) be integrated with the first OSCORE message? Two proposals have been made (by Mali=C5=A1a and Jim); this = needs discussion. Francesca brought up a third approach, where both the EDHOC and the OSCORE messages are included in the payload. Christian pointed out that this would be combining two different REST requests, and Carsten suggested thinking about piggybacking in a more general sense. Carsten promised to come up with a schedule for virtual interim WG meetings that is a bit lighter than the two-week cadence we had before IETF106. From nobody Mon Dec 9 17:08:30 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919D41200C7 for ; Mon, 9 Dec 2019 17:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50BVG39cFVl2 for ; Mon, 9 Dec 2019 17:08:26 -0800 (PST) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (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 7C9EC12006E for ; Mon, 9 Dec 2019 17:08:26 -0800 (PST) Received: by mail-vk1-xa2b.google.com with SMTP id u123so5080002vkb.9 for ; Mon, 09 Dec 2019 17:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=1C6/s2MMox5lL8fcfZeVbwIMvJm6cBTlTn5aJ0fVrdA=; b=Nmr0rqMbIj03rT0qh3DHwqpnCnAjjDSpDciUWOWQJIqrxcn9PwDvb+0ufqaIIXYt6D 7Z2aOrQvihzAOCHy997/UQYFk8A4wBo7eFkIFk34dycBz037gb8Tp2fOnYCbO3ED3sc7 VDrf9yYBzR9VzBkGGsxZZPp1+pIKaOmsCrD8ZPUNaacPB9l12jhVOxypLKyrRBVLNWTk GctT1KO0N0Vkvwb0yu6WvZupBcSpWtRRNj24lPKjNIST7i2NawqtfqVPTQ/jSHTWXs7l dP1HgKnmUK/u14F8/AFsplOohnkimf62+asC07eBJEgBR8Z4mrDhDWagawNrfu1uD2Fy Oc1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=1C6/s2MMox5lL8fcfZeVbwIMvJm6cBTlTn5aJ0fVrdA=; b=cTAMRmkph6i1ewRoFqo8xZ2FWvtanFJYZD/HZ2quNwKfgGMnpbaIPbCaflsk4XzXhM x4Y1jKuOEhoHb36xYJD3dzt88slZ/ieKz6b88JUeLzlAWr8n7f6fYp7cccikOXjO2nB0 dPJ7PKAD+6zfvg+n6VCWhwTFwGhvEHLhC80JNJ2utchAnOFnAWKgh2XslbXvOPJht2M/ KfcxuSakIaUBQvSYFQQRHUjGnb8vn1NlMyz3VXhZsSRcYVcvfJ7TzUFTBQReefp+Cz9q Cgz9EZeKRBXWFr7DwHRXOO6/ZVudAo6nXh0XKWjsvTpbCTmbTyHoth7lVhDSJc4h94X7 XiTQ== X-Gm-Message-State: APjAAAWtqoaiNqJQutlqNBlJO746s4h3nZriXTTfURn99maC/A3Qfo/t 4pREhXSNEynbj/xT07YxE0ZSCLCbknFPHgM9xrzB6+c6 X-Google-Smtp-Source: APXvYqzDcNVWArQy3Hnyv+sA1fQVE+aV+9WRn/3mwj2wYm1XuHE1Kc6m0Q19VqBtY/SgHntj6pAoqAKiii4jkJBybvE= X-Received: by 2002:a1f:ec41:: with SMTP id k62mr27424939vkh.87.1575940104831; Mon, 09 Dec 2019 17:08:24 -0800 (PST) MIME-Version: 1.0 References: <2D679FD0-F95F-488E-BCC4-0B90693FDA3A@tzi.org> In-Reply-To: <2D679FD0-F95F-488E-BCC4-0B90693FDA3A@tzi.org> From: Zhen Cao Date: Tue, 10 Dec 2019 09:08:13 +0800 Message-ID: To: Carsten Bormann , "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_CoRE_Working_Group_Adoption_call_f?= =?utf-8?q?or_draft-jarvinen-core-fasor-02?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 01:08:29 -0000 hi Carsten, I think it is necessary and reasonable to take into account the opinions that had already been expressed on the f2f meeting, as recorded in the minutes. This is the Montreal meeting minutes when this draft was asked for adoption. https://tools.ietf.org/wg/core/minutes?item=3Dminutes-105-core-0= 1.html Regards, Zhen On Tue, Dec 10, 2019 at 1:17 AM Carsten Bormann wrote: > > I know we are entering the slow season, so this is a gentle reminder: > > > On Nov 19, 2019, at 09:03, Carsten Bormann wrote: > > > > This message starts a three-week working group adoption call. > > (Two weeks because the WG call partially overlaps an IETF and the US Th= anksgiving week.) > > > > If you have read the draft and support adopting it, please say so. > > If you see a problem with adopting it as a WG document, please tell us. > > So far, nobody indicated their support for this adoption on this mailing = list outside the author team. > Is really nobody else in the CoRE WG interested in this? > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Dec 9 22:48:06 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EF3120091 for ; Mon, 9 Dec 2019 22:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olIlkvScFMNx for ; Mon, 9 Dec 2019 22:48:03 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 6C63C120020 for ; Mon, 9 Dec 2019 22:48:03 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id z12so15132762iln.11 for ; Mon, 09 Dec 2019 22:48:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aWxsJq2Dlb262jhymMD5goxdnjcy4ZRV1MVIRWnNPiA=; b=Amn9IuItJKO+wAgqat4axdzAHmcHeYfN7APD8KIFCXH83/sc385C5HOd3UiY4j6KOU Zde+lY2eT6gKH37uluH35v+b60w8QuxNEg8z95OeWPUMUPY0o1Rb/c8iYX/Ebh3YuZTl /pnDUJnjMng552yrOvCZn9TQ+R2Ye/M+eyv1y7ZIIyILX9rV+zBWsK7ezZGC8S9KtduJ xY/XxlRKKW2+DooxL3aPUWxZLYdjRgeVzz9opcF1Lko+AUa2o6viPhqjDkG4e8H+IQ1f WhUZpTsr7/7WpoFUORFeICbhN8dwKpq7dzzzjBYfiM6dXW6lpqmpQ/aVG7dn4YjHurG8 f2Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aWxsJq2Dlb262jhymMD5goxdnjcy4ZRV1MVIRWnNPiA=; b=BSxkiUUSA2Qe0rhzh4GsakUe5Suzo8tBwp7o+IPZctD7uzFXdKaKd9j6cOROWtQjXG IZNZTMhpRLtJVh25GkVavPVEvkPVGsqZNBdkIUDIMKam0mt8hhOzMxXfE33ToR9+P6T4 ycD3LfNmiJJ8u5MsovvrWugm0F8cY1rEP2v8hk+VsphBdNynCT3Qhdt0wswwmzPcJIpu 8smWOTH579QcMOu1GSWEwY+HYbuobFUuFs9255RgIyuLEA0wuczJv+67I70kelaz178z GB9l9vwQVArv8qY93sZ6cfpm6ZFk+0cmg3qKecJ6Eo16bt4Zk8q9tY0wRmge6v3YCczB NTHw== X-Gm-Message-State: APjAAAVMw+TagFHDx/U3oW/ftJ1b3fCSAekHCBimQdsW/k78YyafYQgv jGJgOopfjniTxb0/qDVy/4qtNabBp5ebxKeOtk8= X-Google-Smtp-Source: APXvYqzqqxA7fO2BdmEJ7jaaf4xtwnKtwu/OyRmxR4LE4shzRnjCYIAHzLWzy1tpUk9+vp1CFM6XfVenGqtO3XeyeeA= X-Received: by 2002:a92:83c4:: with SMTP id p65mr31025211ilk.95.1575960482815; Mon, 09 Dec 2019 22:48:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Hui Deng Date: Tue, 10 Dec 2019 14:47:50 +0800 Message-ID: To: Carsten Bormann Cc: "core@ietf.org WG" Content-Type: multipart/alternative; boundary="000000000000c22639059953e4c3" Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_CoRE_Working_Group_Adoption_call_f?= =?utf-8?q?or_draft-jarvinen-core-fasor-02?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 06:48:05 -0000 --000000000000c22639059953e4c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi there, I think it is important that we have a few options of congestion control algorithm for CoAP likewise what tcp does, and FASOR is a good candidate. I am in favor of working on this using this draft as the basis. (I thought this was clear enough after Montreal , so I did not voice out earlier) DENG Hui On Tue, Nov 19, 2019 at 4:03 PM Carsten Bormann wrote: > In Montreal, we said we were going to issue an adoption call for > draft-jarvinen-core-fasor-02 right away. We didn=E2=80=99t, and the chai= rs need to > apologize. > > (Working group adoption of this was delayed for a while, during which > people could judge the impact of the updated IPR declaration. This waiti= ng > time was completed by Montreal.) > > This message starts a three-week working group adoption call. > (Two weeks because the WG call partially overlaps an IETF and the US > Thanksgiving week.) > > If you have read the draft and support adopting it, please say so. > If you see a problem with adopting it as a WG document, please tell us. > Note that according to IETF procedures the mere presence of IPR claims on > the document is by itself not a sufficient reason to reject a document th= at > would otherwise go forward; however, if you have considered the terms of > the IPR declaration and see a problem with agreeing on a spec encumbered > with those terms, please do tell us. (In Montreal, by the sense of the > room, that seemed not to be the case.) > > Please remember that WG adoption does not mean that we already have > consensus on all the details, just that this is the right working documen= t > to address the issue (and that we should address the issue in the first > place); you are encouraged to mention any issues that you already know. > > Please respond to core@ietf.org, or exceptionally to core-chairs@ietf.org > (for off-list comments). > > This formal WG adoption call runs until the end of December 3rd. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000000000000c22639059953e4c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,=C2=A0

I think = it is important that we have a few options of congestion control algorithm = for CoAP likewise what tcp does, and FASOR is a good candidate.=C2=A0 I am = in favor of working on this using this draft as the basis.=C2=A0=C2=A0=C2= =A0 (I thought this was clear enough after Montreal , so I did not voice ou= t earlier)

DENG Hui

<= /span>

On Tue, Nov 19, 2019 at 4:03 PM Carsten Bormann <cabo@tzi.org> wrote:
In Montreal, we said we were going to issue an adoption call for dra= ft-jarvinen-core-fasor-02 right away.=C2=A0 We didn=E2=80=99t, and the chai= rs need to apologize.

(Working group adoption of this was delayed for a while, during which peopl= e could judge the impact of the updated IPR declaration.=C2=A0 This waiting= time was completed by Montreal.)

This message starts a three-week working group adoption call.
(Two weeks because the WG call partially overlaps an IETF and the US Thanks= giving week.)

If you have read the draft and support adopting it, please say so.
If you see a problem with adopting it as a WG document, please tell us.
Note that according to IETF procedures the mere presence of IPR claims on t= he document is by itself not a sufficient reason to reject a document that = would otherwise go forward; however, if you have considered the terms of th= e IPR declaration and see a problem with agreeing on a spec encumbered with= those terms, please do tell us.=C2=A0 (In Montreal, by the sense of the ro= om, that seemed not to be the case.)

Please remember that WG adoption does not mean that we already have consens= us on all the details, just that this is the right working document to addr= ess the issue (and that we should address the issue in the first place); yo= u are encouraged to mention any issues that you already know.

Please respond to core@i= etf.org, or exceptionally to core-chairs@ietf.org (for off-list comments).

This formal WG adoption call runs until the end of December 3rd.

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

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--000000000000c22639059953e4c3-- From nobody Tue Dec 10 13:16:37 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92141120147 for ; Tue, 10 Dec 2019 13:16:36 -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_DNSWL_NONE=-0.0001, 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 h73Yslu8JJPX for ; Tue, 10 Dec 2019 13:16:35 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF81A120121 for ; Tue, 10 Dec 2019 13:16:34 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 10 Dec 2019 13:16:29 -0800 From: Jim Schaad To: Date: Tue, 10 Dec 2019 13:16:28 -0800 Message-ID: <049901d5af9f$17bc87b0$47359710$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdWvkguD1AGjrOCBQhetxYfEo40mtQ== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Change the default path option in the href document X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2019 21:16:36 -0000 I would like to change the default path option value in the href document. It is currently PathOption.Relative and I would like to make it PathOption.Append. Relative is the right answer if the primary schema is going to be http. If you do a GET on the resource and get back #status open #menu -> #order -> This makes complete sense. In http, CoffeePot is a directory and the files main.html, menu.html and order.html are all children of that directory. This means that a substitution of "menu.html" for "main.html" is what is expected to happen. For CoAP, you can do something similar and have the structure /CoffeePot /coffee /menu /order In this case doing a relative resolution of the target will give the correct answer. In CoAP there is not the ability to do a redirect, however for the coffee pot, if that is all it does then one can put all of the resources at the root and things are fine. However, most of the applications that I have been seeing are using a tree structure so that one would have the structure /CoffeePot /menu /order /queue Doing the GET on the resource /CoffeePot then needs to return a CoRAL document that looks like #status open #menu -> #order -> When using CIRI, this can be simplified slightly to [ PathType, Append-Path, Path, "menu"]. If append-path because the default value for PathType, then this becomes [Path, "menu"] which is going to be the shortest possible encoding. In that case if you want the same semantics as http, you would need to encode it as [PathType, RelativePath, Path, "menu"]. I think that the major criteria that needs to go into making this change is if the default model for CoAP devices is to be flat like http or hierarchical as I believe it normally is based on the small set of things that I have looked at. Jim From nobody Fri Dec 13 02:12:24 2019 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 908C3120832; Fri, 13 Dec 2019 02:12:23 -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: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <157623194344.12991.3439063055593403036@ietfa.amsl.com> Date: Fri, 13 Dec 2019 02:12:23 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-dev-urn-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2019 10:12:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Uniform Resource Names for Device Identifiers Authors : Jari Arkko Cullen Jennings Zach Shelby Filename : draft-ietf-core-dev-urn-04.txt Pages : 17 Date : 2019-12-13 Abstract: This memo describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage, or equipment inventories. A URN-based representation can be easily passed along in any application that needs the information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-dev-urn-04 https://datatracker.ietf.org/doc/html/draft-ietf-core-dev-urn-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dev-urn-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 13 07:56:46 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8363120180 for ; Fri, 13 Dec 2019 07:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sczZdo_KsGt8 for ; Fri, 13 Dec 2019 07:56:25 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 68FD5120018 for ; Fri, 13 Dec 2019 07:56:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B0D0066019D for ; Fri, 13 Dec 2019 17:56:24 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wjdhbd-o1h39 for ; Fri, 13 Dec 2019 17:56:23 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 46A926600BD for ; Fri, 13 Dec 2019 17:56:23 +0200 (EET) From: Jari Arkko Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 13 Dec 2019 17:56:22 +0200 References: <157623194373.12991.16585649050189639189.idtracker@ietfa.amsl.com> To: core In-Reply-To: <157623194373.12991.16585649050189639189.idtracker@ietfa.amsl.com> Message-Id: <556FCEF7-4120-4079-AF5D-447F21B11414@piuha.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [core] FW: New Version Notification for draft-ietf-core-dev-urn-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2019 15:56:29 -0000 After a long silent period, we=E2=80=99ve updated this draft in = preparation for the document to move forward. We=E2=80=99ve been tracking comments and usage of the draft in the = meanwhile, and I=E2=80=99ve also re-implemented this version in order to = convince myself that the syntax is complete and correct. The main changes: * Syntax fine-tuning for better extensibility and some corrections * Example corrections and additional examples * IANA rules slightly relaxed Jari > On 13 Dec 2019, at 12.12, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-ietf-core-dev-urn-04.txt > has been successfully submitted by Jari Arkko and posted to the > IETF repository. >=20 > Name: draft-ietf-core-dev-urn > Revision: 04 > Title: Uniform Resource Names for Device Identifiers > Document date: 2019-12-13 > Group: core > Pages: 17 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-core-dev-urn-04.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/ > Htmlized: https://tools.ietf.org/html/draft-ietf-core-dev-urn-04 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-core-dev-urn > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-dev-urn-04 >=20 > Abstract: > This memo describes a new Uniform Resource Name (URN) namespace for > hardware device identifiers. A general representation of device > identity can be useful in many applications, such as in sensor data > streams and storage, or equipment inventories. A URN-based > representation can be easily passed along in any application that > needs the information. From nobody Fri Dec 13 10:27:40 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF7912011C for ; Fri, 13 Dec 2019 10:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilOr2bB96Yz4 for ; Fri, 13 Dec 2019 10:27:36 -0800 (PST) Received: from smtp71.ord1c.emailsrvr.com (smtp71.ord1c.emailsrvr.com [108.166.43.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8F1120013 for ; Fri, 13 Dec 2019 10:27:36 -0800 (PST) X-Auth-ID: fluffy@iii.ca Received: by smtp17.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 8A22D600E1; Fri, 13 Dec 2019 13:27:35 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (d75-159-246-1.abhsia.telus.net [75.159.246.1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 13 Dec 2019 13:27:35 -0500 From: Cullen Jennings Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C4F442A0-E3C6-48C9-AC51-F35B04BBA130" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 13 Dec 2019 11:27:34 -0700 In-Reply-To: To: core References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [core] CoRE @ IETF106: Summary and Minutes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2019 18:27:38 -0000 --Apple-Mail=_C4F442A0-E3C6-48C9-AC51-F35B04BBA130 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 9, 2019, at 3:42 PM, Carsten Bormann wrote: >=20 >=20 > Concerns had been raised about opening up the second registry for > derived units, making it harder for a SenML application to find out > whether a unit encountered was actually of interest to it. > Discussion in the first session resulted in the tentative proposal > to mark secondary units with an asterisk (as in "*km/h", as opposed > to unmarked "m/s"). Further discussion in the second session made > clear that while this makes the use of secondary units stand out, it > does not really improve the situation of SenML applications that > want to quickly discard measurements for units they do not care > about, unless they track the contents of the two registries, which > would make the asterisks redundant. I disagree that the asterisk does not improve the situation > There also was some feedback > the asterisks would make the adoption of the SenML units registry by > other SDOs more difficult. The in-room consensus not to go for the > asterisks, but to include more explanatory text about implementation > strategies, needs to confirmed on the mailing list. =20 I strongly object to this. RFC 8428 has a strong assertion that the = units=20 For a given type of measurement, there will only be one unit type defined. So for length, meters are defined and other lengths such as mile, foot, light year are not allowed. For most cases, the SI unit is preferred. There is running code that is based on that assumption that has been in = production for many years. You can=E2=80=99t break that assumption = without some backwards compatibility consideration that help theses = deployed applications mitigate the breakage this causes. The ideas that millions of edge aggregation devices, many on far side of = slow links, would query the IANA web server to track the units and = decide how to process data seems like a very bad design. I would expect = the IESG to reject anything that lead to cases like = https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse = --Apple-Mail=_C4F442A0-E3C6-48C9-AC51-F35B04BBA130 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Dec 9, 2019, at 3:42 PM, Carsten Bormann <cabo@tzi.org> = wrote:


 Concerns had been raised = about opening up the second registry for
 derived units, making it harder for a SenML application = to find out
 whether = a unit encountered was actually of interest to it.
 Discussion in the first = session resulted in the tentative proposal
 to mark secondary units with an asterisk (as in = "*km/h", as opposed
 to unmarked "m/s").  Further discussion in the = second session made
 clear that while this makes the use of secondary units = stand out, it
 does = not really improve the situation of SenML applications that
 want to quickly discard = measurements for units they do not care
 about, unless they track the contents of the two = registries, which
 would make the asterisks redundant. =

I disagree that the = asterisk does not improve the situation

 There also was some = feedback
 the = asterisks would make the adoption of the SenML units registry = by
 other = SDOs more difficult.  The in-room consensus not to go for = the
 asterisks, but to include more explanatory text about = implementation
 strategies, needs to confirmed on the mailing list. =  

I strongly object to this.  RFC 8428 has a strong = assertion that the units 

        For a =
given type of measurement, there will only be one unit
        type defined.  So for length, meters are defined and other
        lengths such as mile, foot, light year are not allowed.  For
        most cases, the SI unit is preferred.
There is running code that is based on that assumption =
that has been in production for many years. You can=E2=80=99t break that =
assumption without some backwards compatibility consideration that help =
theses deployed applications mitigate the breakage this =
causes.
The ideas that millions of edge =
aggregation devices, many on far side of slow links, would query the =
IANA web server to track the units and decide how to process data seems =
like a very bad design. I would expect the IESG to reject anything that =
lead to cases like https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse

= --Apple-Mail=_C4F442A0-E3C6-48C9-AC51-F35B04BBA130-- From nobody Tue Dec 17 08:05:11 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C001209E5 for ; Tue, 17 Dec 2019 08:05:09 -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_DNSWL_NONE=-0.0001, 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 NxYN8fkJpLD7 for ; Tue, 17 Dec 2019 08:05:07 -0800 (PST) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1591F1209E7 for ; Tue, 17 Dec 2019 08:05:07 -0800 (PST) Received: from mail-qk1-f174.google.com ([209.85.222.174]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1ihFLN-0000kR-0l; Tue, 17 Dec 2019 17:05:05 +0100 Received: by mail-qk1-f174.google.com with SMTP id z14so8659738qkg.9 for ; Tue, 17 Dec 2019 08:05:04 -0800 (PST) X-Gm-Message-State: APjAAAV5QRgdw3a5QbQahIKNce3JeF8wdQm4gVPmAt7I4+fjVs1zgdHB 6+qgXJtW8oKn6fjb982ibjE216G2IEhbuvqfnfY= X-Google-Smtp-Source: APXvYqwLzaAwJFXbYeyzsvZvWgc5/ueKKcQFLKGGbOA3FQjSZdUezCvz76rt2cWuwPXPVuQFdtedghlQgdnLw34YZ58= X-Received: by 2002:ae9:ec0a:: with SMTP id h10mr5309495qkg.303.1576598703912; Tue, 17 Dec 2019 08:05:03 -0800 (PST) MIME-Version: 1.0 References: <049901d5af9f$17bc87b0$47359710$@augustcellars.com> In-Reply-To: <049901d5af9f$17bc87b0$47359710$@augustcellars.com> From: Klaus Hartke Date: Tue, 17 Dec 2019 17:04:28 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Jim Schaad Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1576598707; 8e2e7b99; X-HE-SMSGID: 1ihFLN-0000kR-0l Archived-At: Subject: Re: [core] Change the default path option in the href document X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 16:05:09 -0000 Hi Jim! > I would like to change the default path option value in the href document. > It is currently PathOption.Relative and I would like to make it > PathOption.Append. > [...] > When using CIRI, this can be simplified slightly to [ PathType, Append-Path, > Path, "menu"]. If append-path because the default value for PathType, then > this becomes [Path, "menu"] which is going to be the shortest possible > encoding. I had a similar hunch, but resisted the temptation to just make that change without further confirmation. But now that we have a small number of real CoRAL-based applications specified (like draft-hartke-t2trg-coral-pubsub-00 and the upcoming draft-tiloca-ace-oscore-gm-admin-01), maybe we could start building the collection of real-world CoRAL documents and use your implementation to benchmark changes to the encoding like this? Klaus From nobody Wed Dec 18 03:29:19 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EBA120903 for ; Wed, 18 Dec 2019 03:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssC_rSL_e15E for ; Wed, 18 Dec 2019 03:29:15 -0800 (PST) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 50424120059 for ; Wed, 18 Dec 2019 03:29:15 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id xBIBTCwg045890; Wed, 18 Dec 2019 12:29:12 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 951F81D53C1; Wed, 18 Dec 2019 12:29:11 +0100 (CET) Received: from 83.37.3.185 by webmail.entel.upc.edu with HTTP; Wed, 18 Dec 2019 12:29:12 +0100 Message-ID: In-Reply-To: <2D679FD0-F95F-488E-BCC4-0B90693FDA3A@tzi.org> References: <2D679FD0-F95F-488E-BCC4-0B90693FDA3A@tzi.org> Date: Wed, 18 Dec 2019 12:29:12 +0100 From: "Carles Gomez Montenegro" To: "Carsten Bormann" Cc: "core@ietf.org WG" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.3 at violet X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Wed, 18 Dec 2019 12:29:13 +0100 (CET) Archived-At: Subject: Re: [core] =?iso-8859-1?Q?=F0=9F=94=94_CoRE_Working_Group_Adoption_call_for_draft-ja?=rvinen-core-fasor-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 11:29:17 -0000 Dear all, Sorry for the late message! I support the adoption of draft-jarvinen-core-fasor-02. Based on our previous experience with CoCoA, in my opinion, the document will benefit from evaluation under a range of scenarios and conditions in terms of (but not limited to): - Network topologies (e.g. mesh, tree, single-hop, etc.). - Technologies (especially with different RTT characteristics). - Technology settings (e.g. acknowledged vs unacknowledged). - Traffic loads. - BER/PER. Cheers, Carles > I know we are entering the slow season, so this is a gentle reminder: > >> On Nov 19, 2019, at 09:03, Carsten Bormann wrote: >> >> This message starts a three-week working group adoption call. >> (Two weeks because the WG call partially overlaps an IETF and the US >> Thanksgiving week.) >> >> If you have read the draft and support adopting it, please say so. >> If you see a problem with adopting it as a WG document, please tell us. > > So far, nobody indicated their support for this adoption on this mailing > list outside the author team. > Is really nobody else in the CoRE WG interested in this? > > Grüße, Carsten From nobody Tue Dec 24 15:50:52 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D9D120098 for ; Tue, 24 Dec 2019 15:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxaWYRZCSgsc for ; Tue, 24 Dec 2019 15:50:49 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAC4120059 for ; Tue, 24 Dec 2019 15:50:48 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2FEB73897D; Tue, 24 Dec 2019 18:50:38 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 03EF6146B; Tue, 24 Dec 2019 18:50:47 -0500 (EST) From: Michael Richardson To: core@ietf.org, Michel Veillette In-Reply-To: References: <29380.1565102380@localhost> <7505.1565633977@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [core] progressing ietf-core-yang-cbor and ietf-core-sid X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 24 Dec 2019 23:50:51 -0000 --=-=-= Content-Type: text/plain {trying to clear out my inbox} Michel Veillette laments: > The file "ietf-constrained-voucher@2019-08-01.yang" is constructed with > an "import ietf-voucher" and a "uses v:voucher-artifact-grouping". For > this reason, part of the "yang-data voucher-constrained-artifact" is > defined in "ietf-voucher" with SIDs assigned within the scope of this > module. > This example raises an interesting point. "ietf-voucher" have been > defined without considering a possible constrained implementation and > have no SID list or .sid file included in RFC 8366. SIDs has been > assigned after the fact, as allowed by > https://tools.ietf.org/html/draft-ietf-core-sid-07#section-3. If we > include a SID list or .sid file for > "ietf-constrained-voucher@2019-08-01.yang", part of the SIDs will be in > a RFC, the rest won't. To avoid such situation, we should rely entirely > on an IANA registry for all .sid files defined by RFCs. I am still uncertain how this is going to work. I have not seen any progress on: 1) https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ 2) https://datatracker.ietf.org/doc/draft-ietf-core-sid/ At IETF105, it seemed that the documents were unstuck, and would progress to WGLC soon. Is there something holding this up other than author time? I think that allocations were made for ietf-anima-constrained-voucher, but I guess that was in the github version only. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4CpFYACgkQgItw+93Q 3WWtJAgAmcNAhQMgqWsu6tSMY/kNVwuCQGkY6o+3BoESQyZlQKJWSD2bY+Mgqye7 U48Az9UXw+TvJICToxuQdw/7YzwRSgXV+MleNS9l54EO6FV1K/3BMBkuTyfLG3C6 swCPYVfV5EZuKX+Ryg1PBhnTYqZB8e+Imc1pqigeeN4iT+axgpcsDg+otEXTBt3k 4uotvgAyf0TbR/2FjoE28g7qnhq/lZXdWApcX2TN4o91dizBFlKiLAX2vGbTgzDl U59FF5gjyiq4cIF196yuJysJUKcTBFEpKCFEp3mJVIf/QNfJyPy0Dxyp11QppoOK tbJT64qjRuoNYWrTazBhQ9nw8lsKcg== =6aCh -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 27 12:04:12 2019 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 A942B12006F; Fri, 27 Dec 2019 12:04:03 -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: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <157747704360.30057.14437678603138327755@ietfa.amsl.com> Date: Fri, 27 Dec 2019 12:04:03 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-etch-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 20:04:04 -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 : FETCH & PATCH with Sensor Measurement Lists (SenML) Authors : Ari Keranen Mojan Mohajer Filename : draft-ietf-core-senml-etch-06.txt Pages : 11 Date : 2019-12-27 Abstract: The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or configuration parameters. The CoAP FETCH, PATCH, and iPATCH methods enable accessing and updating parts of a resource or multiple resources with one request. This document defines new media types for the CoAP FETCH, PATCH, and iPATCH methods for resources represented with the SenML data model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-etch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-senml-etch-06 https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-etch-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-etch-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 27 12:11:50 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFE212010E for ; Fri, 27 Dec 2019 12:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ZjxBDV8PhreV for ; Fri, 27 Dec 2019 12:11:46 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50059.outbound.protection.outlook.com [40.107.5.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 9B20D12006F for ; Fri, 27 Dec 2019 12:11:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UZiPaeBBw/NQ5YUAMV6YAvLN0/InE14fcWPpjWyHjx9lFjiP/y/GBtPXkCcSEVWscu2fWheFCbg9+I9nNrQYGRGfJtFmc+nzpeER0JKsG0R2t0UIwG2H+jP/XOyyht4ekS0dfPlRU5BO7uebZE8XeKodv0ZUj+5abjm327BREp6bD/2Pq14Xgj8rbZ+Q4n7eXhQXXV+zrWsljWDbDmXEaw0ykgZaWkM2DGstSk3kFZ5TKKTvg8N/eNTxQ2Ko4k4aEpLfWUjpc6w/kAVlzcu6zpEfBFbQAR1/yZgbf/fGxcCIaoTpoR33l27cbBiieiIVcxQg3Y+7xC5o1ODfQE/AFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vYLyeHsACaIxCPIL1CmmGlhJnY1HaboFKhYF6mZa8Bo=; b=NtnHewj0cWzQM7t4VCfuUewmB3TPXfakTXdYX8IrBZQzCkZ+cRlgKMk7Wcq7hzTpVGsm8AUlmoVGYg5h6ir31YCfXLhtu1z9RLCa6qkFVtwgsz32rZ9sxI4UYpiU3xhW8cJ/hryOxfzCEqq/jbb26ooH/zKbGhzKm7dPmz2dto5f++z29qTp6kW+/t8Qbk+hgtX74qjDjtGFHLiEOfn/FmJ7zMHkqSYqkJ7AEs/NUHmd1BYLqqcyJml35LtiHjDpabw0d3Lu3GBjNTcwgW+Lg71HVpuILQzQbHWpigg5+jgGga6sA0eMY/4UnzUEGEy1RNsOdX4WH2Oz7GD2OKVebA== 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=vYLyeHsACaIxCPIL1CmmGlhJnY1HaboFKhYF6mZa8Bo=; b=IgXAf9myphSMrdvYG8kqULnEhElaJwmYMSZdAFLvtrRyv7fi1Cz6sQh34CgqdyX4syQDTQgo82NGjLq8sGu2DnnIwIdWteSntjgxfmR5PQupgj2JD8ljYFFl46HoGozZk04Koshk2lAoSn2ci/yeCWAP281pZc69RgHFaFtOozc= Received: from HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) by HE1PR07MB3386.eurprd07.prod.outlook.com (10.170.247.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.7; Fri, 27 Dec 2019 20:11:42 +0000 Received: from HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::dc2b:f9d6:17f5:58dc]) by HE1PR07MB4236.eurprd07.prod.outlook.com ([fe80::dc2b:f9d6:17f5:58dc%5]) with mapi id 15.20.2602.006; Fri, 27 Dec 2019 20:11:42 +0000 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: "core@ietf.org" , Warren Kumari , Barry Leiba , Alissa Cooper , Roman Danyliw , Adam Roach , Benjamin Kaduk , "Eric Vyncke (evyncke)" Thread-Topic: [core] I-D Action: draft-ietf-core-senml-etch-06.txt Thread-Index: AQHVvPDdPawmB9a+PU238J0FPeBSE6fOaCWA Date: Fri, 27 Dec 2019 20:11:42 +0000 Message-ID: References: <157747704360.30057.14437678603138327755@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ari.keranen@ericsson.com; x-originating-ip: [91.156.90.170] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0d08b3d9-3f4c-4613-5f2b-08d78b08fdb2 x-ms-traffictypediagnostic: HE1PR07MB3386: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(346002)(136003)(396003)(366004)(199004)(189003)(85202003)(26005)(85182001)(966005)(2906002)(36756003)(8936002)(110136005)(6506007)(33656002)(71200400001)(4001150100001)(186003)(8676002)(81156014)(86362001)(478600001)(316002)(81166006)(76116006)(6486002)(2616005)(66556008)(66946007)(66446008)(64756008)(6512007)(5660300002)(66574012)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3386; H:HE1PR07MB4236.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oQqHGspILCSXbTBtA2xzuZM7okNxHolwl+xiSxx7gi6RR4cSuIaLD6y3TfyH80azntbnwWamBAbbECOodNhiUwLLqsch5drIvKPI7bbyMhlMBzdmmfipy1WCKlKz70Fehsjead6LBAXDlQXEzEd5mp98t8YZMEhKDcaiLvwPNY3XFw4Qswc5EZGo+ty80V1O9b/VI3a/qvjZIdUV/2Lkf4Trmm76OD0rkTniGTfDQOIPMXOS9xUWVuVBSV9NCWEJf8C4uw21Q6bph9kjSam3w50CvkcoDS7Y0YUack+Igeo9jQc41RSxOO/3Paob808vtfq6TGHihQIdvnaQ85O/PaCU16iA6+RCg6PH79w2Hn1CSPm1rxb8jXYg0l3ri9OPLWrD/jm1c4mzgadzMayMmtJDlOX7ZmgjpybH9wQKpOnqGgiB5LlB15JYnFukVGL+666HeOh94qxNhoVTKU0g3lIUdDHd8XK3rvJTbttiE+8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <79663BDC94BCD8438B1B9F34B4FB1728@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0d08b3d9-3f4c-4613-5f2b-08d78b08fdb2 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2019 20:11:42.7599 (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: liHfRhU/7oq8nJ6wVwWw2tGvePYgUO2nh9WHFkEPU2JTO4b3T45dKmdjWeP8Njb8R986SmiHvOQ+TvvH1n0jnug8Z7B5h9jGLNfJ0poXYnA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3386 Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-senml-etch-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 20:11:48 -0000 SGksDQoNClRoaXMgdXBkYXRlIGFkZHJlc3NlcyB0aGUgSUVTRyByZXZpZXcgY29tbWVudHMgZnJv bSBXYXJyZW4sIEJhcnJ5LCBBbGlzc2EsIEVyaWMsIGFuZCBSb21hbiwgYW5kIHRoZSBnZW4tYXJ0 LCBJb1QgZGlyZWN0b3JhdGUsIGFuIG9wcyBkaXJlY3RvcmF0ZSByZXZpZXcgY29tbWVudHMuDQoN ClRoZSBkaXNjdXNzIGZyb20gQWRhbSBhbmQgY291cGxlIG9mIGNvbW1lbnRzIGZyb20gQmVuIHN0 aWxsIG5lZWQgdG8gYmUgYWRkcmVzc2VkIGluIGEgbmV3IHJldmlzaW9uLCBidXQgd2Ugd2FudGVk IHRvIGdldCB0aGlzIHZlcnNpb24gb3V0IG5vdyBzbyB0aGF0IHRoZSBvdGhlciBBRHMgY2FuIGNo ZWNrIHRoYXQgdGhlaXIgY29tbWVudHMgYXJlIGFkZHJlc3NlZCBhbmQgdGhlIGdyb3VwIGNhbiBy ZXZpZXcgYWxsIHRoZSBjaGFuZ2VzIHNvIGZhciBpbiBjb250ZXh0Lg0KDQpTdW1tYXJ5IG9mIHVw ZGF0ZXM6DQoqIFJlLXdyb3RlIEZyYWdtZW50IElEIHNlY3Rpb247IGFkZGVkIGV4YW1wbGVzDQoq IENsYXJpZmllZDogRmV0Y2ggbmVlZHMgYXQgbGVhc3Qgb25lIFJlY29yZCBhbmQgTmFtZSANCiog Q2xhcmlmaWVkOiBQYXRjaCBSZWNvcmRzIE1VU1QgY29udGFpbiBWYWx1ZSBvciBTdW0gDQoqIENs YXJpZmllZDogQ29BUCBwcm92aWRlcyB0aGUgc2VjdXJpdHkgZm9yIEZFVENIL1BBVENIDQoqIENs YXJpZmllZDogaVBBVENIIGFuZCBQQVRDSCBhcmUgZXF1aXZhbGVudCBoZXJlDQoqIFJldHVybiBl bXB0eSBQYWNrIHdoZW4gbm8gbWF0Y2hlcyB0byBGRVRDSA0KKiBJQU5BIHJlZ2lzdHJhdGlvbiBj bGFyaWZpY2F0aW9ucw0KKiBBZGRlZCBzZWxlY3RpbmcgcmVjb3JkcyBieSB1bml0DQoqIEVkaXRv cmlhbCBmaXhlcw0KDQoNCkNoZWVycywNCkFyaQ0KDQo+IE9uIDI3LiBEZWMgMjAxOSwgYXQgMjIu MDQsICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+ IHdyb3RlOg0KPiANCj4gDQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29uc3RyYWluZWQgUkVTVGZ1bCBFbnZpcm9ubWVudHMgV0cg b2YgdGhlIElFVEYuDQo+IA0KPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogRkVUQ0ggJiBQQVRD SCB3aXRoIFNlbnNvciBNZWFzdXJlbWVudCBMaXN0cyAoU2VuTUwpDQo+ICAgICAgICBBdXRob3Jz ICAgICAgICAgOiBBcmkgS2VyYW5lbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgTW9qYW4g TW9oYWplcg0KPiAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWNvcmUtc2VubWwtZXRj aC0wNi50eHQNCj4gICAgUGFnZXMgICAgICAgICAgIDogMTENCj4gICAgRGF0ZSAgICAgICAgICAg IDogMjAxOS0xMi0yNw0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgVGhlIFNlbnNvciBNZWFzdXJlbWVu dCBMaXN0cyAoU2VuTUwpIG1lZGlhIHR5cGUgYW5kIGRhdGEgbW9kZWwgY2FuIGJlDQo+ICAgdXNl ZCB0byBzZW5kIGNvbGxlY3Rpb25zIG9mIHJlc291cmNlcywgc3VjaCBhcyBiYXRjaGVzIG9mIHNl bnNvciBkYXRhDQo+ICAgb3IgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzLiAgVGhlIENvQVAgRkVU Q0gsIFBBVENILCBhbmQgaVBBVENIDQo+ICAgbWV0aG9kcyBlbmFibGUgYWNjZXNzaW5nIGFuZCB1 cGRhdGluZyBwYXJ0cyBvZiBhIHJlc291cmNlIG9yIG11bHRpcGxlDQo+ICAgcmVzb3VyY2VzIHdp dGggb25lIHJlcXVlc3QuICBUaGlzIGRvY3VtZW50IGRlZmluZXMgbmV3IG1lZGlhIHR5cGVzDQo+ ICAgZm9yIHRoZSBDb0FQIEZFVENILCBQQVRDSCwgYW5kIGlQQVRDSCBtZXRob2RzIGZvciByZXNv dXJjZXMNCj4gICByZXByZXNlbnRlZCB3aXRoIHRoZSBTZW5NTCBkYXRhIG1vZGVsLg0KPiANCj4g DQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvcmUtc2VubWwt ZXRjaC8NCj4gDQo+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBh dDoNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1zZW5tbC1l dGNoLTA2DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0 Zi1jb3JlLXNlbm1sLWV0Y2gtMDYNCj4gDQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtY29yZS1zZW5tbC1ldGNoLTA2DQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWls YWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gY29yZSBtYWlsaW5nIGxpc3QNCj4gY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0K From nobody Mon Dec 30 02:08:13 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29157120142 for ; Mon, 30 Dec 2019 02:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.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 m8QxVqLaqiqj for ; Mon, 30 Dec 2019 02:08:10 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29026120133 for ; Mon, 30 Dec 2019 02:08:09 -0800 (PST) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id 4F3F8181D3043; Mon, 30 Dec 2019 10:08:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=UDhynS5sfh9P8vk4h8 603mQqGP0tcHU2JUnwJhwCeYY=; b=nalxf//KxFaxMGwSdyyhrBjeJQ3gQta+7R eYzTfijNN3gosdG7AOJHgirl5/RQzmESKo6vcf8xdx6TT/HwQ5aNAuciw6m/R0RY Avxkw8XpKHKe/CQQ80w3V1+ygLB+9psk4svCFM7BCspRJ3IAr37AIl/H+nTwXheG JmjfAXHjE= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::::::, RULES_HIT:41:72:152:355:379:582:599:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1534:1541:1568:1575:1588:1589:1592:1594:1711:1714:1730:1777:1792:2068:2069:2198:2199:2525:2553:2566:2682:2685:2734:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3865:3866:3867:3868:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:5007:6117:6261:6657:6659:7464:7903:8603:9025:10004:10215:10400:10848:11232:11658:11914:12043:12109:12895:13139:14093:14096:14181:14721:21080:21324:21433:21451:21627:30006:30054:30090, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:0, DNSBL:none, Custom_rules:0:0:0, LFtime:1, LUA_SUMMARY:none X-HE-Tag: crush35_46fcd8a3d7e0b X-Filterd-Recvd-Size: 3545 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf14.hostedemail.com (Postfix) with ESMTPA; Mon, 30 Dec 2019 10:08:07 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_7c378f41ad32c38e5eeed344515c978c" Date: Mon, 30 Dec 2019 11:08:07 +0100 From: Peter van der Stok To: Michael Richardson Cc: core@ietf.org, Michel Veillette , a@ackl.io, ivaylo@ackl.io, consultancy Reply-To: consultancy@vanderstok.org In-Reply-To: <18990.1577231446@localhost> References: <29380.1565102380@localhost> <7505.1565633977@localhost> <18990.1577231446@localhost> User-Agent: Roundcube Webmail/1.4-rc2 Message-ID: <0bfb0f10f1a5001a588047a79d6db792@bbhmail.nl> X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy X-Originating-IP: [83.201.120.57] Archived-At: Subject: Re: [core] progressing ietf-core-yang-cbor and ietf-core-sid X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 30 Dec 2019 10:08:12 -0000 --=_7c378f41ad32c38e5eeed344515c978c Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed > I have not seen any progress on: > 1) https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ > 2) https://datatracker.ietf.org/doc/draft-ietf-core-sid/ > > At IETF105, it seemed that the documents were unstuck, and would progress > to WGLC soon. Is there something holding this up other than author time? > > I also want to express my concern about the VERY slow progress of these documents. > It is quite possible and understandable that the authors are occupied with too many other tasks. > > An additional author may be the answer to unstick the progress. > > Greetings, > > Peter --=_7c378f41ad32c38e5eeed344515c978c Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
=
I have not seen any progress on:
  1) https://datatracker.ietf.org/doc/draft-ietf-core= -yang-cbor/
  2) ht= tps://datatracker.ietf.org/doc/draft-ietf-core-sid/

At IETF1= 05, it seemed that the documents were unstuck, and would progress
to W= GLC soon.  Is there something holding this up other than author time?<= br />


= I also want to express my concern about the VERY slow progress of these doc= uments.
It is quite possible and understandable that the authors are o= ccupied with too many other tasks.

An additional author may be t= he answer to unstick the progress.

Greetings,

Peter
--=_7c378f41ad32c38e5eeed344515c978c-- From nobody Mon Dec 30 03:07:35 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481761200A1 for ; Mon, 30 Dec 2019 03:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DukVo4+1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kJZbjqFF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WRGt4sL57wi for ; Mon, 30 Dec 2019 03:07:31 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F22E12002F for ; Mon, 30 Dec 2019 03:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4586; q=dns/txt; s=iport; t=1577704051; x=1578913651; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Mfo9Ge54gat7epwEV8SDbjgYgnSSfAfW2FjvCYhqrPE=; b=DukVo4+1DZDhZZeMf9ZZ8u9F1MRNu4Kv+T7Mg5uLlg5bjrlJ8E2K79GI RAH3XMdCi6h6ku7qmWRi/Sx/svZAml4tJaBTW/EpmsHbc9YnQfv5TG/kg kBLoga52w+XaZKZdGINldSqMYSEG4oIPQt4PeuQ0537VUvGLWm5Xb96kE U=; IronPort-PHdr: =?us-ascii?q?9a23=3AOqrDSB0IZOdy7/wIsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQBFPqKvXpYgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAQCF2Qle/4cNJK1lDg0BAQEBAQE?= =?us-ascii?q?BBQEBAREBAQMDAQEBgXyBVCQsBWxYIAQLKoQIg0YDinuCX5gJglIDVAkBAQE?= =?us-ascii?q?MAQEYCwoCAQGEQAIXgVIkOBMCAw0BAQQBAQECAQUEbYULBiYMhV4BAQEBAgE?= =?us-ascii?q?BARAREQwBASwLAQ8CAQgYAgImAgICJQsVEAIEAQ0FIoMAAYJGAw4gAQ6fZgK?= =?us-ascii?q?BOIhhdYEygn4BAQWBCQEvAg5BgnsYggwJgQ4ojBkagUE/gREnIIJMPoJkAQE?= =?us-ascii?q?CAQEYgQFGF4J5MoIskD2Fe4k9jyIKgjSHM45mG4JGdocFkBaOUoFGhwySBAI?= =?us-ascii?q?EAgQFAg4BAQWBaSKBWHAVGiEqAYJBCUcYDYMfiXODc4UUhQQEATZ0gSiNUII?= =?us-ascii?q?yAQE?= X-IronPort-AV: E=Sophos;i="5.69,374,1571702400"; d="scan'208";a="460086302" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Dec 2019 11:07:29 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id xBUB7To2005457 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 Dec 2019 11:07:29 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 30 Dec 2019 05:07:28 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 30 Dec 2019 06:07:27 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 30 Dec 2019 06:07:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j8a2CJ6gRnW/E4Xy381ueLR6H28sTPCS5qFzsRbpIKJ5sbwYpGYymZh05ecg5h/bZMXLMzgdMSfc/1W3XBcsXdP4XjTlAPwE4ziyKcfXcdd7ub4E+w4s6nlVbB3RlqcPFD96YohKUs1IruMpTBboi9b2sxXKOyhyKDRVwSgs2tAjVRb5+wEKBkE28jgaSdHLlg2/gLnFk8idcuM5g6lCioUp0kOPLrJEHlqqSsxFmntchMPR+Kcr4aV5HVZVE6EnM08vttqDASdT7uuxlUBqqfq/lAHA6iVGblaLWhwaaEpzVBg1YqRdbGSB6KRQKv2xDy/rv+fds9MyiFlha8/2Dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mfo9Ge54gat7epwEV8SDbjgYgnSSfAfW2FjvCYhqrPE=; b=Fh+c9jBc1mM1KklFxFZ0fwJKyjvmkog7SLaVp9qOjy1bxZ9QF1isD4LLD2p3nTOzg4OKEovp29/bYVlEUD3QpVV1KAffF4evPQYI6ESPKopVj7XFC7w8CEqBzEO90OQmIzpdxQxLNhtJe8hQF3offLsURW5vZUrC5cYLR63kPsn9EJj5aCTyrtWzJgFI6XLyyiIavTzLvmJFaxBY/J7da3qnupJYdboY6YX3xZY2RUFkfpn72yu+VbaQ4y4DBXJ07ZaPhRWXjvRePHPxhrXK9I3YXCtPSUn8iPqJ5uHbCNg4OytVCgs74qXsDfmlfpsZPlBQXO1vT/VNefPwFkzQCA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mfo9Ge54gat7epwEV8SDbjgYgnSSfAfW2FjvCYhqrPE=; b=kJZbjqFF30qldL1NQIy3NAuX78CVqupKhCvmN6EU01Z3/QkWTWhJELzkOr8oqxpsBP5cp6ekZ+lJZ6+xzUfWJcZfH/Y89nUsHN1Ci9lUh4Vrv4XjmfZYcXPaN+rLqHbWkROUYwPdLxRsT7z8P6zEtgrByKNueItCfQcpXpdggVE= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (10.175.88.141) by DM5PR11MB1641.namprd11.prod.outlook.com (10.172.37.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.12; Mon, 30 Dec 2019 11:07:27 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::f8ba:7d8d:391d:4302]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::f8ba:7d8d:391d:4302%12]) with mapi id 15.20.2581.007; Mon, 30 Dec 2019 11:07:26 +0000 From: "Eric Vyncke (evyncke)" To: =?utf-8?B?QXJpIEtlcsOkbmVu?= , "core@ietf.org" , Warren Kumari , Barry Leiba , Alissa Cooper , Roman Danyliw , Adam Roach , Benjamin Kaduk CC: "ietf@kovatsch.net" Thread-Topic: [core] I-D Action: draft-ietf-core-senml-etch-06.txt Thread-Index: AQHVvPDdPawmB9a+PU238J0FPeBSE6fOaCWAgAQxXoA= Date: Mon, 30 Dec 2019 11:07:26 +0000 Message-ID: References: <157747704360.30057.14437678603138327755@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:2031:aed9:363:f568] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: afc4d468-7ef7-4f3d-3f80-08d78d187447 x-ms-traffictypediagnostic: DM5PR11MB1641: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0267E514F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(136003)(366004)(39860400002)(189003)(199004)(8676002)(186003)(8936002)(71200400001)(33656002)(4326008)(2906002)(4001150100001)(36756003)(91956017)(76116006)(6506007)(86362001)(81166006)(66446008)(81156014)(66476007)(2616005)(66946007)(64756008)(66556008)(66574012)(5660300002)(478600001)(966005)(6486002)(110136005)(316002)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1641; H:DM5PR11MB1753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CC39Ysz4Fjw7YX4Bq1VxpNhiLrqO/jGLbuf2BcujxQsqTrt3V/d5uVw/DNzTCu33Y5YFvI51mXho6bZhY91IBAADnIS2oofxsuOnypyTwwMdgAc9sWUvmTwF+bSkQUd5/CV2wMhDYCjyxxvEimobeleGgIm5AELIKNpU1bXcru7yLbLx0sdNXDWvNUOUL4/ec33nCtJoHMj2I6fipkPkQorZEHYnls0JiCt0SqrTImg5a5Z/r8sbRA5mjM0nIoNvvhvkemvlIt4LMkH0S8zHpqTf2dD8GK7x9rKRCJW0nZl4rukledeqR10WE5Vq/L09bkFlH6kLuvx2W5W0nhsKHwzstZrkgeflZhOP5dO4+k2SoN6iah0QIlhKUKtF0E16lBh6z2GTSwE31nQdYNAHG0YAdECMVkBpDJONeIAkUF6IEIp0Nk5WmFh8TcJp5UyyJfFI7EgNIEh9sn7Htx2TRFtAk2NH0UwOn4LMlWL1ILA= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: afc4d468-7ef7-4f3d-3f80-08d78d187447 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Dec 2019 11:07:26.4253 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: P3khoRpsW6XJjWVG5vqmzwpXHEyHROQP9sxwodxSfAQ4Cy7GWWnooyYidsEDDs/QLShP1mT4tPYsd41LQ5wAeA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1641 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-senml-etch-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2019 11:07:33 -0000 VGhhbmsgeW91IEFyaSBmb3IgYWRkcmVzc2luZyB0aGUgY29tbWVudHMgaW4gTWF0dGhpYXMnIElv VC1kaXJlY3RvcmF0ZSByZXZpZXcgYXMgd2VsbCBmb3IgcmVwbHlpbmcgdG8gaGltIG9uIHRoZSBt YWlsaW5nIGxpc3Qgb24gaGlzIG90aGVyIGNvbW1lbnRzLg0KDQpUaGFuayB5b3UgYWdhaW4gTWF0 dGhpYXMgOy0pDQoNCkkgd2lzaCB5b3UgYSB3b25kZXJmdWwgMjAyMCAhDQoNCi3DqXJpYw0KDQoN Cu+7v09uIDI3LzEyLzIwMTksIDIxOjEyLCAiQXJpIEtlcsOkbmVuIiA8YXJpLmtlcmFuZW5AZXJp Y3Nzb24uY29tPiB3cm90ZToNCg0KICAgIEhpLA0KICAgIA0KICAgIFRoaXMgdXBkYXRlIGFkZHJl c3NlcyB0aGUgSUVTRyByZXZpZXcgY29tbWVudHMgZnJvbSBXYXJyZW4sIEJhcnJ5LCBBbGlzc2Es IEVyaWMsIGFuZCBSb21hbiwgYW5kIHRoZSBnZW4tYXJ0LCBJb1QgZGlyZWN0b3JhdGUsIGFuIG9w cyBkaXJlY3RvcmF0ZSByZXZpZXcgY29tbWVudHMuDQogICAgDQogICAgVGhlIGRpc2N1c3MgZnJv bSBBZGFtIGFuZCBjb3VwbGUgb2YgY29tbWVudHMgZnJvbSBCZW4gc3RpbGwgbmVlZCB0byBiZSBh ZGRyZXNzZWQgaW4gYSBuZXcgcmV2aXNpb24sIGJ1dCB3ZSB3YW50ZWQgdG8gZ2V0IHRoaXMgdmVy c2lvbiBvdXQgbm93IHNvIHRoYXQgdGhlIG90aGVyIEFEcyBjYW4gY2hlY2sgdGhhdCB0aGVpciBj b21tZW50cyBhcmUgYWRkcmVzc2VkIGFuZCB0aGUgZ3JvdXAgY2FuIHJldmlldyBhbGwgdGhlIGNo YW5nZXMgc28gZmFyIGluIGNvbnRleHQuDQogICAgDQogICAgU3VtbWFyeSBvZiB1cGRhdGVzOg0K ICAgICogUmUtd3JvdGUgRnJhZ21lbnQgSUQgc2VjdGlvbjsgYWRkZWQgZXhhbXBsZXMNCiAgICAq IENsYXJpZmllZDogRmV0Y2ggbmVlZHMgYXQgbGVhc3Qgb25lIFJlY29yZCBhbmQgTmFtZSANCiAg ICAqIENsYXJpZmllZDogUGF0Y2ggUmVjb3JkcyBNVVNUIGNvbnRhaW4gVmFsdWUgb3IgU3VtIA0K ICAgICogQ2xhcmlmaWVkOiBDb0FQIHByb3ZpZGVzIHRoZSBzZWN1cml0eSBmb3IgRkVUQ0gvUEFU Q0gNCiAgICAqIENsYXJpZmllZDogaVBBVENIIGFuZCBQQVRDSCBhcmUgZXF1aXZhbGVudCBoZXJl DQogICAgKiBSZXR1cm4gZW1wdHkgUGFjayB3aGVuIG5vIG1hdGNoZXMgdG8gRkVUQ0gNCiAgICAq IElBTkEgcmVnaXN0cmF0aW9uIGNsYXJpZmljYXRpb25zDQogICAgKiBBZGRlZCBzZWxlY3Rpbmcg cmVjb3JkcyBieSB1bml0DQogICAgKiBFZGl0b3JpYWwgZml4ZXMNCiAgICANCiAgICANCiAgICBD aGVlcnMsDQogICAgQXJpDQogICAgDQogICAgPiBPbiAyNy4gRGVjIDIwMTksIGF0IDIyLjA0LCAi aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90 ZToNCiAgICA+IA0KICAgID4gDQogICAgPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogICAgPiBU aGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb25zdHJhaW5lZCBSRVNUZnVsIEVudmly b25tZW50cyBXRyBvZiB0aGUgSUVURi4NCiAgICA+IA0KICAgID4gICAgICAgIFRpdGxlICAgICAg ICAgICA6IEZFVENIICYgUEFUQ0ggd2l0aCBTZW5zb3IgTWVhc3VyZW1lbnQgTGlzdHMgKFNlbk1M KQ0KICAgID4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IEFyaSBLZXJhbmVuDQogICAgPiAgICAg ICAgICAgICAgICAgICAgICAgICAgTW9qYW4gTW9oYWplcg0KICAgID4gICAgRmlsZW5hbWUgICAg ICAgIDogZHJhZnQtaWV0Zi1jb3JlLXNlbm1sLWV0Y2gtMDYudHh0DQogICAgPiAgICBQYWdlcyAg ICAgICAgICAgOiAxMQ0KICAgID4gICAgRGF0ZSAgICAgICAgICAgIDogMjAxOS0xMi0yNw0KICAg ID4gDQogICAgPiBBYnN0cmFjdDoNCiAgICA+ICAgVGhlIFNlbnNvciBNZWFzdXJlbWVudCBMaXN0 cyAoU2VuTUwpIG1lZGlhIHR5cGUgYW5kIGRhdGEgbW9kZWwgY2FuIGJlDQogICAgPiAgIHVzZWQg dG8gc2VuZCBjb2xsZWN0aW9ucyBvZiByZXNvdXJjZXMsIHN1Y2ggYXMgYmF0Y2hlcyBvZiBzZW5z b3IgZGF0YQ0KICAgID4gICBvciBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMuICBUaGUgQ29BUCBG RVRDSCwgUEFUQ0gsIGFuZCBpUEFUQ0gNCiAgICA+ICAgbWV0aG9kcyBlbmFibGUgYWNjZXNzaW5n IGFuZCB1cGRhdGluZyBwYXJ0cyBvZiBhIHJlc291cmNlIG9yIG11bHRpcGxlDQogICAgPiAgIHJl c291cmNlcyB3aXRoIG9uZSByZXF1ZXN0LiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIG5ldyBtZWRp YSB0eXBlcw0KICAgID4gICBmb3IgdGhlIENvQVAgRkVUQ0gsIFBBVENILCBhbmQgaVBBVENIIG1l dGhvZHMgZm9yIHJlc291cmNlcw0KICAgID4gICByZXByZXNlbnRlZCB3aXRoIHRoZSBTZW5NTCBk YXRhIG1vZGVsLg0KICAgID4gDQogICAgPiANCiAgICA+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0 YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLXNlbm1sLWV0Y2gvDQogICAgPiANCiAgICA+IFRo ZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAgICA+IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtc2VubWwtZXRjaC0wNg0KICAg ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWNvcmUt c2VubWwtZXRjaC0wNg0KICAgID4gDQogICAgPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVy c2lvbiBpcyBhdmFpbGFibGUgYXQ6DQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1jb3JlLXNlbm1sLWV0Y2gtMDYNCiAgICA+IA0KICAgID4gDQogICAg PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAgPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgID4gDQogICAgPiBJ bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQog ICAgPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KICAgID4gDQogICAgPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gY29y ZSBtYWlsaW5nIGxpc3QNCiAgICA+IGNvcmVAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KICAgIA0KICAgIA0KDQo= From nobody Mon Dec 30 11:46:53 2019 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC005120B53 for ; Mon, 30 Dec 2019 11:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 RIiS5NqZ55Hj for ; Mon, 30 Dec 2019 11:46:49 -0800 (PST) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 1611C120020 for ; Mon, 30 Dec 2019 11:46:49 -0800 (PST) Received: by mail-vs1-xe36.google.com with SMTP id b79so21530171vsd.9 for ; Mon, 30 Dec 2019 11:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UZ/lwTK4pLq/2tjw19kOxuMxkElR3oYgPcmSmYLv4BI=; b=aOLwTnpGzHJyRSXCP2hMoiwR9Sc8y/j7PE7A1iEdbH68wTFNHc9HzhHNY4PH6a0AnF oIYmLhr7L8yIP9O4NmhUYawP4AGShi+SpnUcBtMmxk1GgdbtPzPCgm9ctCYtSAsNKk4s K+ThGFMzwTe79V1Vqhd+E7xnha3SmuKBhQ7SaxBpX/NeYoIUdZbQv/gftW7fXwSFQwpt 0GvwVnFyIri5yuJ9Z9AzQG+XL3Xu/FEdNeZlX18GjPwmVLBmLPup3Tg4EIXCoevMHIDs jJx9eaKgjbV+cq9AaRMBrzHjdhu9pbNUPQfKkk14BVbEQKwWpPN5Z8e3hUKaYGR9fgLc 8x9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UZ/lwTK4pLq/2tjw19kOxuMxkElR3oYgPcmSmYLv4BI=; b=GLTANSB7ZZas4UjeYAOou1BtnoTdB/Z2VxFLnXEq/UF23RPLrKUE00DwCNXJWza73Z k1IFn1uYBvOz/Z6bSho2SCrxr9xST0GywmOrIlwn9hkUCYU3SsK6jirvViM7MpYp/DoU OaQjscDb/GeUJSK1gC0xZ3cjyIAsEKW/SMOpjuDy9aff6Eu+QjRPhtjQTVjWc16uBL9E +4wkf5xdnziTxqMVdnwZsiNwm8B+ITk2J89f3xlSxZd93aYTk94wDSZdGSt6t7R2Y9I/ L35+C807eBblm1GRXC5ex1b+XiplJSKasJ/Lw8ZJ0NJM2XChcc9OzEqARlzP34VAC367 vvNw== X-Gm-Message-State: APjAAAVoGF3g2S7BaRnnYqknGPlHND1BNpC1jsPjPb0T5mbMB8f45qDk IefUg8LlpnifPK9YUTCZ/fNH6b9kB2d4hLCHNrRVBTK7 X-Google-Smtp-Source: APXvYqzW4McvEhd2TfeNk4Scorfc9+mue9Pj74+Ibxpdv5+NUNUOXRI3/4GQ3ev1ubR+G1GQIpzQK0Nm3l9uWsk/AVY= X-Received: by 2002:a05:6102:402:: with SMTP id d2mr32837836vsq.146.1577735207790; Mon, 30 Dec 2019 11:46:47 -0800 (PST) MIME-Version: 1.0 From: Pascal Urien Date: Mon, 30 Dec 2019 20:46:35 +0100 Message-ID: To: core Content-Type: multipart/alternative; boundary="0000000000009c2c2f059af11a55" Archived-At: Subject: [core] bMAC test program for Arduino Nano X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: 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, 30 Dec 2019 19:46:51 -0000 --0000000000009c2c2f059af11a55 Content-Type: text/plain; charset="UTF-8" The bijective MAC Time Stamped (bMAC_TS algorithm see https://tools.ietf.org/html/draft-urien-core-bmac-05) aims at detecting malicious (corrupted) software in constrained environments. It works with two pillars, memory space is finite and computing time is stable. Memory space is hashed according to a pseudo random order. The computing time is measured in order to defeat code decompression algorithms. I have written a test software for arduino nano (33KB space memory for FLASH + SRAM+EEPROM) Computing time is about 27s (# 1m/byte), roughly speaking the computing time follows a normal distribution, the entropy is about 10bits (3 standard deviation) The code is here: https://github.com/purien/bMAC Comments welcome .. Pascal --0000000000009c2c2f059af11a55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The bijective MAC Time Stamped (bMAC_TS algorithm see= =C2=A0http= s://tools.ietf.org/html/draft-urien-core-bmac-05) aims at detecting mal= icious (corrupted) software in constrained environments.

It works with two pillars, memory space is finite and computing time= is stable.

Memory=C2=A0space is hashed according = to a pseudo random order. The computing time is measured in order to defeat= code decompression algorithms.

I have written a t= est software for arduino nano (33KB space memory for FLASH=C2=A0+ SRAM+EEPR= OM)

Computing time is about 27s (# 1m/byte), rough= ly speaking the computing time follows a normal distribution, the entropy i= s about 10bits (3 standard deviation)


Comments welcome ..

<= div>Pascal
--0000000000009c2c2f059af11a55--