From nobody Mon Oct 2 05:02:03 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E381345D2 for ; Mon, 2 Oct 2017 05:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywIfyv7zeRQE for ; Mon, 2 Oct 2017 05:01:56 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5A61344D1 for ; Mon, 2 Oct 2017 05:01:55 -0700 (PDT) X-AuditID: c1b4fb3a-491789c000003fec-45-59d22ab18f30 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9F.4D.16364.1BA22D95; Mon, 2 Oct 2017 14:01:54 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.75) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 2 Oct 2017 14:01:53 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YJCppIl1FzZpbsmSODr8ynazii6zIYbvOZAlO3Y6EA0=; b=MxjQFp/CePzQBqu1Q8uk3j7KJOXONY2mgcdV6oBf3LT6mEQuheVKnLkltJ6amcixAeAcobvcDx0KQvyItSofyBDKfHiLCcln8DyaK3dOUkn/DbM90gVAoGhchSIb/QNkrk3X7ldJT5pJJFVJXCufHhe5EI1iaoZ5FtaxY0d/BBU= Received: from DB5PR07MB1256.eurprd07.prod.outlook.com (10.164.41.146) by DB5PR07MB1256.eurprd07.prod.outlook.com (10.164.41.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Mon, 2 Oct 2017 12:01:51 +0000 Received: from DB5PR07MB1256.eurprd07.prod.outlook.com ([fe80::54e6:3c90:b26a:fd23]) by DB5PR07MB1256.eurprd07.prod.outlook.com ([fe80::54e6:3c90:b26a:fd23%13]) with mapi id 15.20.0077.018; Mon, 2 Oct 2017 12:01:51 +0000 From: John Mattsson To: "core@ietf.org" Thread-Topic: New Version Notification for draft-mattsson-core-security-overhead-01.txt Thread-Index: AQHTOiRYxzS1lp6oJ0SvxfAIw5BkjaLN2q8AgAKdggA= Date: Mon, 2 Oct 2017 12:01:50 +0000 Message-ID: <8C3A71BF-1FCA-4313-BA26-984796728D96@ericsson.com> References: <150680058398.3361.14187607597491361256.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-originating-ip: [192.176.1.81] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB1256; 6:LC7fcjHckGOuTzvjcvp3n7cMG27xgW2tnVZH9R+8az96p//1zWa1lA24G3awQ03IOVm2k9tlG57QxyNB6MZy//QPEztRN+3HX00EG2SrmAB2weCk3mSMcV8AnvNQlM1VBi7G39WDABB1aHO6svc8BgeswLhky0A45BWJyLl4Dx9E1glimMpiIchkF4BrkN7dKgSnlz1tlqaOQhbL7oQLDG1kpFZ3kiFOnzA1NNW8UGPddkXtMdmiqU0+E/3rcWf5cPAM3K8EKHYQCAlq/5Sqa4ReG4hPvYH1TV83Zpey1sUHUzEhidTZFXPBwiy6KORHsDo55/TqHcnYL8MKQQ9nrw==; 5:KWwoQqO1e/NvS/2ANVwV7SCp/TNvrqo8biiV8Mp27NK8FNCtlADzEXWu2iXzq3mp9BUz/gRznm1BKoSGO7QDB7yGX/vG5fYBvnRPpW0bMjRmefBgviApogULCR1yYWfBODF9cqSIbOQK2qK50hGRUVOhmNtFFDtg/CQAa9sF1Uo=; 24:fbGjWRrVCQoEqbXwLkBPmgSxNifBJ0cLeObxMkggzCm3Rv53IE5FN0cNrPHroZoFOPM/XGvauSD4YosqilFP5cRuPuqx23NzRhNgJgUlEr8=; 7:/W/efW2+OVjwvAOevCOvBiv4cVRO0VQmXCsBbNxjFjue3tiyrhRKGPUel5FZ/7y2hIfWcusV0enoe0HyMhFjL4VmYurai9/qbd1MCD1v8Vw5drzlWKo0XGUkSA/b/z8vAUicbEptVzA+CdMRVe5rSdt74cXTatGBWTj8QcaaA6hzsfzOe0ADr2dnQlhFdcBYARbraFBNUa55vZUe45yA3UfNEtw+NKkKkCaN2dB80Hc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1be93d08-828e-48b9-da52-08d5098d5dc9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DB5PR07MB1256; x-ms-traffictypediagnostic: DB5PR07MB1256: authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB1256; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB1256; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(377424004)(189002)(199003)(24454002)(101416001)(58126008)(2501003)(316002)(68736007)(2906002)(5250100002)(5660300001)(97736004)(3280700002)(50986999)(83506001)(2950100002)(76176999)(3660700001)(83716003)(15650500001)(54356999)(66066001)(6916009)(6486002)(7736002)(6116002)(36756003)(8936002)(81156014)(1730700003)(189998001)(81166006)(106356001)(33656002)(53936002)(3846002)(86362001)(105586002)(102836003)(2351001)(305945005)(25786009)(230783001)(8676002)(2900100001)(229853002)(478600001)(6436002)(5640700003)(6506006)(6246003)(53546010)(6306002)(6512007)(82746002)(99286003)(14454004)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR07MB1256; H:DB5PR07MB1256.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:3; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2017 12:01:50.9935 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1256 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHObt3291ocDKnz3wBW/nBSdO2SBMx+yaYIQXhsrehNxV1yr0q arhEs3TL0lLS1cxComniMksTtbnU4Up8y0IiUJNERAkRyhcqr9egb7/n+f/P/3nO4VCER6nQ h0oz5NCMQZ+hFEnJ+oTO2EPtqgld6GitMLxvuY2IRjFNTeuCeHROGplMZ6Tl0UxI1GVp6mJr cPYtRf5obzNRjLrAhCgK8BEob0s3ISnlgQcQvJ50CPjChcBl3iC4gsSVBPTWbQp5pUYAUxvN Ir6YQ9DwpZ80IQklwqFg7SkWceyJD8DLD0uI4304Adyfa0m+r4ObA1wsxxGwsNW54yfxQaiw Lwi4nWT4OIzYjXx+KYKtj1Yh55HgaLC5Pgk4RtgLfrqf7zCBvaFkzbbjAYyhqWeU4FkOi99+ C7lMOVbDzT9FfDsAhupsJM/+MPHIjLhZgC1iMK9Xi3lBDa+qlxHPcfDuhlvEmxoQzM2vCnhB BWPjdjG/0AUoK7u/u8RJuNP9ZDcoHewjW7uH3wth6M0Myb+8H1S2UFVIbfnvDpZthcBB0NYd wmMMWG2+vGM/1JhnxRzL8F4Yrp8nG5GwGclZmmUzUzQaNc2kJbFslkFtoHPa0fbX6O/YjOhC /QsnnAhTSLlHFi6b0HkI9XlsQaYTAUUoPWWGoO2WLFlfUEgzWZeY3AyadSJfilR6y6L7xhI8 cIo+h06n6Wya+acKKIlPMYqf/l55+6HWFHi9YlDDvHg8bg0cV8ReMzOTZ+5qE8PYmacORal1 XaVdGuw41jhER1KBVwuHXVqdOtnXSU1vvn3gaNS4A446BPeq4n6dby2XzRZd8ZvKS0wyqi9a vOTsD8+G1OBnp8NEayuSFrPx60qJIvdUVK81N9941n/VR0myqfrDKoJh9X8Bv+r1FxYDAAA= Archived-At: Subject: Re: [core] New Version Notification for draft-mattsson-core-security-overhead-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 12:02:02 -0000 TWlub3IgdXBkYXRlIHRvIGFsaWduIHdpdGggZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0 eS0wNS4gVGhlIGVuY3J5cHRpb24gb2YgQ29kZSBhZGRzIGEgYnl0ZSBvdmVyaGVhZCwgYnV0IGFs c28gYWxsb3dzIHRoZSBjb21wcmVzc2VkIGNvZGUgaGVhZGVyIHRvIGJlIGV2ZW4gc21hbGxlci4g VGhlIG92ZXJoZWFkIHdpdGggc2VxdWVuY2UgbnVtYmVyID0g4oCYMDXigJkgYXJlOiANCiAgICAN Ck9TQ09SRSBSZXF1ZXN0IChTSUQgPSAwKSAgICAgIDEyIGJ5dGVzIG92ZXJoZWFkDQpPU0NPUkUg UmVxdWVzdCAoU0lEID0gMS0yNTUpICAxMyBieXRlcyBvdmVyaGVhZA0KT1NDT1JFIFJlc3BvbnNl ICAgICAgICAgICAgICAgMTAgYnl0ZXMgb3ZlcmhlYWQNCiAgICANCihub3QgcGxhbm5pbmcgdG8g dXBkYXRlIHRoaXMgYW55bW9yZSwgYnV0IG1pZ2h0IGRvIHNvIGlmIGFueSBvZiB0aGUgc2VjdXJp dHkgcHJvdG9jb2xzIGdldCBjaGFuZ2VkKS4NCiAgICANCi9Kb2huDQogICAgDQogICAgT24gMjAx Ny0wOS0zMCwgMjE6NDMsICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+IHdyb3RlOg0KICAgIA0KICAgICAgICANCiAgICAgICAgQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LW1hdHRzc29uLWNvcmUtc2VjdXJpdHktb3ZlcmhlYWQtMDEudHh0DQog ICAgICAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSm9obiBNYXR0c3NvbiBh bmQgcG9zdGVkIHRvIHRoZQ0KICAgICAgICBJRVRGIHJlcG9zaXRvcnkuDQogICAgICAgIA0KICAg ICAgICBOYW1lOgkJZHJhZnQtbWF0dHNzb24tY29yZS1zZWN1cml0eS1vdmVyaGVhZA0KICAgICAg ICBSZXZpc2lvbjoJMDENCiAgICAgICAgVGl0bGU6CQlNZXNzYWdlIFNpemUgT3ZlcmhlYWQgb2Yg Q29BUCBTZWN1cml0eSBQcm90b2NvbHMNCiAgICAgICAgRG9jdW1lbnQgZGF0ZToJMjAxNy0wOS0z MA0KICAgICAgICBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KICAgICAgICBQYWdlczoJ CTEzDQogICAgICAgIFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtbWF0dHNzb24tY29yZS1zZWN1cml0eS1vdmVyaGVhZC0wMS50eHQNCiAg ICAgICAgU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LW1hdHRzc29uLWNvcmUtc2VjdXJpdHktb3ZlcmhlYWQvDQogICAgICAgIEh0bWxpemVkOiAg ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWF0dHNzb24tY29yZS1zZWN1 cml0eS1vdmVyaGVhZC0wMQ0KICAgICAgICBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tYXR0c3Nvbi1jb3JlLXNlY3VyaXR5LW92ZXJo ZWFkLTAxDQogICAgICAgIERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtbWF0dHNzb24tY29yZS1zZWN1cml0eS1vdmVyaGVhZC0wMQ0KICAgICAg ICANCiAgICAgICAgQWJzdHJhY3Q6DQogICAgICAgICAgIFRoaXMgZG9jdW1lbnQgYW5hbHl6ZXMg YW5kIGNvbXBhcmVzIHBlci1wYWNrZXQgbWVzc2FnZSBzaXplIG92ZXJoZWFkcw0KICAgICAgICAg ICB3aGVuIHVzaW5nIGRpZmZlcmVudCBzZWN1cml0eSBwcm90b2NvbHMgdG8gc2VjdXJlIENvQVAu ICBUaGUgYW5hbHl6ZWQNCiAgICAgICAgICAgc2VjdXJpdHkgcHJvdG9jb2xzIGFyZSBEVExTIDEu MiwgRFRMUyAxLjMsIFRMUyAxLjIsIFRMUyAxLjMsIGFuZA0KICAgICAgICAgICBPU0NPUkUuICBE VExTIGFuZCBUTFMgYXJlIGFuYWx5emVkIHdpdGggYW5kIHdpdGhvdXQgY29tcHJlc3Npb24uDQog ICAgICAgICAgIERUTFMgYXJlIGFuYWx5emVkIHdpdGggdHdvIGRpZmZlcmVudCBhbHRlcm5hdGl2 ZXMgZm9yIGhlYWRlcg0KICAgICAgICAgICBjb21wcmVzc2lvbi4NCiAgICAgICAgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uDQogICAgICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgICAgIA0KICAgICAg ICBUaGUgSUVURiBTZWNyZXRhcmlhdA0KICAgICAgICANCiAgICAgICAgDQogICAgDQogICAgDQog ICAgDQoNCg== From nobody Wed Oct 4 01:00:38 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C178213306A for ; Wed, 4 Oct 2017 01:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 nxOaLTqu14oL for ; Wed, 4 Oct 2017 01:00:32 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54B7132D18 for ; Wed, 4 Oct 2017 01:00:31 -0700 (PDT) X-AuditID: c1b4fb3a-0adff70000003fec-29-59d4951d2e42 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 65.29.16364.D1594D95; Wed, 4 Oct 2017 10:00:30 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.166]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Wed, 4 Oct 2017 10:00:29 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG (core@ietf.org)" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHIENhbGwgZm9yIEFkb3B0aW9uIG9uIGRyYWZ0LWFt?= =?utf-8?Q?suess-core-repeat-request-tag-00?= Thread-Index: AQHTPObYOROpZqxttkGRksmfL6kiqg== Date: Wed, 4 Oct 2017 08:00:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/signed; boundary="Apple-Mail=_272E881A-77AD-4951-9919-21AD505BF5FE"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUyM2J7iK7c1CuRBv8/cFscmXKX1WLf2/XM DkweS5b8ZPKYtigzgCmKyyYlNSezLLVI3y6BK2PS3CvsBZtdKxa/mcvawNjp2MXIySEhYCIx +eVdpi5GLg4hgSOMEtOProRyFjNKtO+ezA5SxSbgLPHpWSOYLSJgJrFl11dWEJtZQEniwLUt zCANwgINjBK/n+5iA3FEBFoZJZqWXGOF6NCTWDRxAlA3BweLgIrEuiOyIGFeAXuJ3s7VbCA2 o4CYxPdTa5gghopL3HoynwniPBGJhxdPs0HYohIvH/9jhbAVJT6+2scIUT+FUeLxvCqImYIS J2c+YZnAKDQLyahZSMpmISmDiCdJvJm/lxXC1pZYtvA1M4StKbG/ezkLpriGROe3iVD1phKv j35khLCtJWb8OsgGYStKTOl+yL6AkXsVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmAkHtzy 22oH48HnjocYBTgYlXh43duvRAqxJpYVV+YeYlQBmvNow+oLjFIsefl5qUoivN9agdK8KYmV ValF+fFFpTmpxYcYpTlYlMR5HfZdiBASSE8sSc1OTS1ILYLJMnFwSjUwVkfz9cavuREnf/5N aE5tTLl4hUeY4sT7Oke+lSmnT794pDo3KGSKyfJfZ9YkXHlnfsNub5fb92VZaryhcrWr0vI5 30ukJrCyztWZfGW1PduszyoFTIXSF0LvnHo7VUl3hVCzu4vCvA8sQpX57ZO1gz4L7c/7kCcj uvDRzm9nFDeZXsqVaZRXYinOSDTUYi4qTgQAtRaeLcwCAAA= Archived-At: Subject: [core] =?utf-8?q?__=F0=9F=94=94_WG_Call_for_Adoption_on_draft-ams?= =?utf-8?q?uess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 04 Oct 2017 08:00:35 -0000 --Apple-Mail=_272E881A-77AD-4951-9919-21AD505BF5FE Content-Type: multipart/alternative; boundary="Apple-Mail=_913F0620-7085-42A3-960E-E8C01785B38E" --Apple-Mail=_913F0620-7085-42A3-960E-E8C01785B38E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear CoRE WG, during last IETF the following draft was presented: https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00 = =20= The draft mitigates known issues with the freshness of a CoAP request as = well as fragmentation of the CoAP message body.=20 There was strong room consensus or adoption so this is just to confirm = it. Please reply to the list with your comments, including although not = limited to whether or not you support adoption. Non-authors are = especially encouraged to comment. Target for the end of the WGA call is 16th October.=20 Ciao, - - Jaime Jim=C3=A9nez --Apple-Mail=_913F0620-7085-42A3-960E-E8C01785B38E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear CoRE WG,

during last IETF the following draft was presented:
https://tools.ietf.org/html/draft-amsuess-core-repeat-request-t= ag-00 

The draft mitigates known issues with the freshness of a CoAP = request as well as fragmentation of the CoAP message = body. 
There was strong room consensus or = adoption so this is just to confirm it. Please reply to the list with = your comments, including although not limited to whether or = not you support adoption. Non-authors are especially encouraged to = comment.

Target = for the end of the WGA call is 16th October. 

Ciao,
- - Jaime Jim=C3=A9nez

= --Apple-Mail=_913F0620-7085-42A3-960E-E8C01785B38E-- --Apple-Mail=_272E881A-77AD-4951-9919-21AD505BF5FE Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMrTCCBe8w ggPXoAMCAQICEGjDnK4TEsyfW0+Qr43kvSowDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjA5MTMy MzExWhcNMTcxMjA5MTMyMzEwWjBpMREwDwYDVQQKDAhFcmljc3NvbjEXMBUGA1UEAwwOSmFpbWUg Smltw6luZXoxKTAnBgkqhkiG9w0BCQEWGmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tMRAwDgYD VQQFEwdlamFqaW1uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz9DiTCOChb1bYXyr VSnjxfVxZ+NGqajFezGGSWAWycgkTkiVdHu7Ek89luoUCU9D8KukeSlzeIFu+TdcANzelWOUqm53 Dh64KfoutxkI1g1FOk8+o45tjBFqw7xknXyEUhZ9/XLqaXuRdw7sCvO91Z05R37hwGhscO7M0fgv lRtWBxaqbC/Ikvjo+PPqt5zpx+GFaqsJ0+4ZQWjrb6I+8e8EAxCpLqB9HmCAztI+zog/tzaSDQdd gQVjLDAndvnKRziQvOrYc5kvJHkXzLcWITDYmi5pZrgNRBJL2poiwSopQPlF5bGjaRYu2WBytXe2 SDEj1viuqpae1vxy7+AdUwIDAQABo4IBwDCCAbwwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUH AQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUF BzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwJQYDVR0RBB4wHIEaamFpbWUuamltZW5lekBlcmljc3Nvbi5jb20wVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud DgQWBBQ58oLpEh/5VlA3MqHd3ggGy2cPpzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9L NzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBABcJc9IVKYtDtvxGDcoFbAFvNeiH +bRaEu1d9BWRhjtb8ZAU586LmsSwblH+2rbFRtisroKUwq7tZyjQtCrL7Rma0yM74p5PNZ7sGfmz yNZT33hfTZEDo7bjKdaUg0ELBzQvttjIIr7tBVf9cpdOAyOkGn3oqGEomPizRDiKrXBD3V8oMibX nQDb90hg8TJmLb9mqyaRnu1ztxV2585qJUXXPAt1v6qUy23V+tmOE7JzMxrQwa5UupoS/muaQSsR 7Evde7pXBg8jERM7o4VZJIA7LI55ogyb37O7W2zhITXzbHgjQzLoS6MonjIPegCv3pLgdLx0zXhp SUT19qg2LmX1sXTxLJBSJp5eev+x8B7H14taM8FpsAVGLccstjPuxOabdmNNaEvfSBL7GPtQ5Sil DTMdbxhtuFPlP+1p4tPC6A/85YQozqTKCgk28emo8UupTt28DZgfP5b7xpBbnrsA/2aRYpmV2Ay8 BOd8g4O+ZP0WZD9/vPddUDBYPpJiSulKe6uj15vsiiBY4D272VS0dMpwXOvmkKKS/ZAmarywk0hy bl2mb+GW456+N8CESWD4JIHABoXxVAaa0GdGEyL1lSEmw7jOU2h5UAhlhHqPudpSoaLJgqateP2C hWYGv/DwkR9bVpuO8k1ohfjJA4n0qgxfOkWU23sZgo6495KjMIIGtjCCBJ6gAwIBAgIRAKAMy8yb mZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNV BAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXs MmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHf Ozlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FA cLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenI UwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP 5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA1 41dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6Mqe aTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYB BQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20w SwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxp YXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYB BAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNv bmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9 kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg 36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiX g5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ 6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5 tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6 n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHr ZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApIC AQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEwMDQwODAwMzJaMCMGCSqGSIb3DQEJBDEWBBS/ idDGP7c88TO3sj9nu35biMGejTBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhBow5yuExLMn1tPkK+N5L0q MF8GCyqGSIb3DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjANBgkqhkiG9w0BAQEFAASC AQAFTKqCeBKCvUPPe4bQ9E/w5B4g45EqDFRvb/J1y7Y0IabgNlOsN5DH9r2Fncoo5Rk71PCPqaom bV2w3DGzJhu2pS1taRZhjakOHOvsyy1H4kJw9RfiolaRgmXqVyf0zYz7CzWflWQQnghgfuyfhOFJ jqhq9A7rqpZFHhldKR9MJV2v5U17jfqQNO5CYlqe5s48yP2L+o/2nbO7e03dq0Gqk4u5T5eKWxlp Cn87y6+arrNf8PNIaBw7xKchCpn0yVyz9uwZcahLXMVTk/tHRUXgHwp35p/urGvpF9xVCzbRbgFn gRVSlFTaK5NFkSB0rMEA7vpt9AQnZ2ciqCEUmromAAAAAAAA --Apple-Mail=_272E881A-77AD-4951-9919-21AD505BF5FE-- From nobody Wed Oct 4 04:11:27 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7FD132198 for ; Wed, 4 Oct 2017 04:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 2C9DWtcn61uB for ; Wed, 4 Oct 2017 04:11:23 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2DD4124239 for ; Wed, 4 Oct 2017 04:11:22 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id 7AFA0221C87 for ; Wed, 4 Oct 2017 11:11:20 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Wed, 4 Oct 2017 13:11:20 +0200 To: References: From: Ludwig Seitz Message-ID: <930b2a6e-0eb9-99e6-af6e-940cb1da0ef2@ri.se> Date: Wed, 4 Oct 2017 13:11:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=M+w9E24s c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=02M-m0pO-4AA:10 a=48vgC7mUAAAA:8 a=5-64Y8D9rw9jbaMjNJIA:9 a=xin3Aj6DxTAk85zV:21 a=eJfsZPjV7jP9Cpad:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 04 Oct 2017 11:11:26 -0000 On 2017-10-04 10:00, Jaime Jiménez wrote: > Dear CoRE WG, > > during last IETF the following draft was presented: > https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00 > > The draft mitigates known issues with the freshness of a CoAP request as > well as fragmentation of the CoAP message body. > There was strong room consensus or adoption so this is just to confirm > it. Please reply to the list with your comments, including although > not limited to whether or not you support adoption. Non-authors are > especially encouraged to comment. > > Target for the end of the WGA call is 16th October. > > Ciao, > - - Jaime Jiménez > > I support adoption of this draft. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Wed Oct 4 07:50:55 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8121B132C2A for ; Wed, 4 Oct 2017 07:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 0pNIMLbSdrnQ for ; Wed, 4 Oct 2017 07:50:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5805F1321DF for ; Wed, 4 Oct 2017 07:50:52 -0700 (PDT) Received: from [192.168.91.203] ([31.168.171.66]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MVN0w-1do5tH1V0A-00YhAg; Wed, 04 Oct 2017 16:50:49 +0200 To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org WG (core@ietf.org)" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <1a9f165d-6994-a92f-3e93-faabf9c690ba@gmx.net> Date: Wed, 4 Oct 2017 16:50:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:OKkoSnVEpJXpYkmYm3NbWel6goPpOO6jgMVQBw1bHnH+wF9BEuT CxmgFv09aIfkL5gDWFfC0hdQuSg09LR+sUgqeH7sJap3VPH21DZm1+QG7sHOLkljBIrV66n cZis+0018Ybfu/NLGzv4yR0wZCfqifZUsChoZr+CYiwFLD4Y6buq2xOpu6CZ8CKME0sQw4F Nfq2zSXcZTOIcwjpA0VHg== X-UI-Out-Filterresults: notjunk:1;V01:K0:MIU8zR+10Uw=:N6CiojTzg4DM6h3qtZU3lJ 7VSyfjZNk4YKt+5GmPRqkGFVuUWQRcewCtoXi1YchvUhTwCSgGyrhmol5EgZ4TRymjCagF2U7 lYerkVr/zQDZAg72RzBHdtM2NhIHLGRJ4D6vgG66irKGw/PmVUTHjz4G+GVp8TaU6RE793XfL CtJOF7R0xabAOTbB8ZLBlhErjB5uom+RasY4Dalh2eHjCfPBbIxa593U7MEs7IYALFXIdoW/J 0EaRN7URD66CtRBxhbjg+8+NefRPm5AWbICDXApjk+DWGJnyuCE0301SONfFfMgZZQ4ZN+Kiv UIA113tfbfC7fYoNT9oh8eNk9Gy+feJaM2/YO+ln/umPTLUL4IJf0Apj2gA1JuVcbcjQIZyBD qzPntjsJgXyagnr/OxxxOUybTNJtC5tuE3DDMntgVWJ4wxGSWa7oSUVQ/Ml07r5nv8q2tGPE/ CYBjgfr0zUVAXACmNVvQEVWvIgXXF2lf2JzOO/vAquPPFrie2UX6TM2bFSIrQjuDFUaBBAyNf 7+4Rwu3wQMdaVIw9A/zBnmAL0ax/jZq6whitJXfw7BbYETcyCTOWrYSWVjx0HCxsmRe6Cgi6F 85GUlo3BFYn3YNfUGSj3mqbf2PrCaUOdZXbPgUj5BB848V/nqsJXk5G5w6kN78WkKQ9vNNwCI Gh1JdO68wC4slClHzs8p9L/Wv19axjgLEXLg+wN4fk6fXD4YEqkIp2we1Nps150heOEe/3fxF hZBJH8rCF3Y2XjFqPIh29j2zc0lN1wKu/8WMGnyYNuu3uxTtXAiihgLEbdhedO/anEeTdGZMl 0nxwb/pBPkmMg3TZ6PRlkQayQ9onUjEs5YTRuV/VUD2eUYh8As= Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 04 Oct 2017 14:50:54 -0000 Two comments: IMHO the presented problems are not worthwhile to solve. Additionally, I would prefer if the CORE working group finishes already chartered items rather than always adding new stuff. On 10/04/2017 10:00 AM, Jaime Jiménez wrote: > Dear CoRE WG, > > during last IETF the following draft was presented: > https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00  > > The draft mitigates known issues with the freshness of a CoAP request as > well as fragmentation of the CoAP message body.  > There was strong room consensus or adoption so this is just to confirm > it. Please reply to the list with your comments, including although > not limited to whether or not you support adoption. Non-authors are > especially encouraged to comment. > > Target for the end of the WGA call is 16th October.  > > Ciao, > - - Jaime Jiménez > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Thu Oct 5 00:35:45 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E742813301B for ; Thu, 5 Oct 2017 00:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 39Z0s9_4E3kr for ; Thu, 5 Oct 2017 00:35:42 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 23BAC13247A for ; Thu, 5 Oct 2017 00:35:41 -0700 (PDT) X-AuditID: c1b4fb25-a5fff700000060a2-58-59d5e0cc329a Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 68.BB.24738.CC0E5D95; Thu, 5 Oct 2017 09:35:40 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.166]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Thu, 5 Oct 2017 09:35:39 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core@ietf.org WG (core@ietf.org)" Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHIENhbGwgZm9yIEFkb3B0aW9uIG9uIGRyYWZ0LWFt?= =?utf-8?Q?suess-core-repeat-request-tag-00?= Thread-Index: AQHTPSAxaWuW9otw3kSS8ugFnBWbrqLU3tMA Date: Thu, 5 Oct 2017 07:35:39 +0000 Message-ID: References: <1a9f165d-6994-a92f-3e93-faabf9c690ba@gmx.net> In-Reply-To: <1a9f165d-6994-a92f-3e93-faabf9c690ba@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <3A9A7928305FC146889AF61241C44469@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7n+6ZB1cjDf48FLTY93Y9s8XSnfdY HZg8Fm/az+axZMlPpgCmKC6blNSczLLUIn27BK6MA3d3shU8Eqr4NvcNewPjEqEuRg4OCQET icmHK7oYuTiEBI4wSjxe8J8NwlnMKNHSco69i5GTg03AReJBwyMmkISIwApGiZ7be8AcYYEW RolHr3tYIDKtjBJNS66xgrSICBhJLL7xmg3EZhFQkdi/ejUjiM0rYCGxYsJJZhBbSKBAoufB ExYQm1PAWqLtcDNYL6OAmMT3U2uYQGxmAXGJW0/mg9kSAgISS/acZ4awRSVePv4HVi8qoCex t6edDSKuJLH28HYWkN+YBTQl1u/ShxhjLXH/8ydWCFtRYkr3Q3aIcwQlTs58wjKBUWwWkm2z ELpnIemehaR7FpLuBYysqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECI+vglt+qOxgvv3E8 xCjAwajEw8t05GqkEGtiWXFl7iFGCQ5mJRHelzeAQrwpiZVVqUX58UWlOanFhxilOViUxHkd 912IEBJITyxJzU5NLUgtgskycXBKNTAq/9rL9njxHS3WDVZ5mQskfqn1cT+7XDrntfwCvTqH qT9S1vBfexnKE2Tyf8cO15S2hfwHPp7uXrcwcd39OSzuF3wmOJxyXXBnwRal1ntCb462na+O DtrUOG2W0qXPjXoyBjN5Vv5PFVR7Vs2utCX0iffsvVpvVRoe3zixO2PLy9DAJGldnSUXlViK MxINtZiLihMBrw7tFKgCAAA= Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 07:35:44 -0000 SGkgSGFubmVzLA0KDQpUaGlzIGRyYWZ0IGNvbnRhaW5zIHR3byBzZWN1cml0eSB1cGRhdGVzIHRv IENvQVAsIHNvIHRoaXMgaXMg4oCcZml4aW5nDQpzdHVmZiIgcmF0aGVyIHRoYW4gImFkZGluZyBu ZXcgc3R1ZmYiLiBKdXN0IGFzIGFuIGV4YW1wbGUsIHBlb3BsZQ0KZGVwbG95aW5nIENvQVAgKHdp dGggZS5nLiBEVExTKSBpbiBhY3R1YXRvciBhcHBsaWNhdGlvbnMgbWF5IGJlIHVuYXdhcmUNCnRo YXQgdGhleSBhcmUgdnVsbmVyYWJsZSB0byByZXF1ZXN0IGRlbGF5IGF0dGFja3M6DQoNCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0c3Nvbi1jb3JlLWNvYXAtYWN0dWF0b3Jz LTAyI3NlY3Rpb24tMg0KLjINCg0KV2h5IGlzbuKAmXQgdGhpcyB3b3J0aHdoaWxlIHRvIHNvbHZl Pw0KDQoNCkfDtnJhbg0KDQoNCg0KT24gMjAxNy0xMC0wNCAxNjo1MCwgImNvcmUgb24gYmVoYWxm IG9mIEhhbm5lcyBUc2Nob2ZlbmlnIg0KPGNvcmUtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2YgaGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4gd3JvdGU6DQoNCj5Ud28gY29tbWVudHM6DQo+ DQo+SU1ITyB0aGUgcHJlc2VudGVkIHByb2JsZW1zIGFyZSBub3Qgd29ydGh3aGlsZSB0byBzb2x2 ZS4gQWRkaXRpb25hbGx5LCBJDQo+d291bGQgcHJlZmVyIGlmIHRoZSBDT1JFIHdvcmtpbmcgZ3Jv dXAgZmluaXNoZXMgYWxyZWFkeSBjaGFydGVyZWQgaXRlbXMNCj5yYXRoZXIgdGhhbiBhbHdheXMg YWRkaW5nIG5ldyBzdHVmZi4NCj4NCj4NCj4NCj5PbiAxMC8wNC8yMDE3IDEwOjAwIEFNLCBKYWlt ZSBKaW3DqW5leiB3cm90ZToNCj4+IERlYXIgQ29SRSBXRywNCj4+IA0KPj4gZHVyaW5nIGxhc3Qg SUVURiB0aGUgZm9sbG93aW5nIGRyYWZ0IHdhcyBwcmVzZW50ZWQ6DQo+PiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYW1zdWVzcy1jb3JlLXJlcGVhdC1yZXF1ZXN0LXRhZy0wMA0K Pj4gDQo+PiBUaGUgZHJhZnQgbWl0aWdhdGVzIGtub3duIGlzc3VlcyB3aXRoIHRoZSBmcmVzaG5l c3Mgb2YgYSBDb0FQIHJlcXVlc3QgYXMNCj4+IHdlbGwgYXMgZnJhZ21lbnRhdGlvbiBvZiB0aGUg Q29BUCBtZXNzYWdlIGJvZHkuDQo+PiBUaGVyZSB3YXMgc3Ryb25nIHJvb20gY29uc2Vuc3VzIG9y IGFkb3B0aW9uIHNvIHRoaXMgaXMganVzdCB0byBjb25maXJtDQo+PiBpdC4gUGxlYXNlIHJlcGx5 IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50cywgaW5jbHVkaW5nIGFsdGhvdWdoDQo+PiBu b3QgbGltaXRlZCB0byB3aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4gTm9uLWF1 dGhvcnMgYXJlDQo+PiBlc3BlY2lhbGx5IGVuY291cmFnZWQgdG8gY29tbWVudC4NCj4+IA0KPj4g VGFyZ2V0IGZvciB0aGUgZW5kIG9mIHRoZSBXR0EgY2FsbCBpcyAxNnRoIE9jdG9iZXIuDQo+PiAN Cj4+IENpYW8sDQo+PiAtIC0gSmFpbWUgSmltw6luZXoNCj4+IA0KPj4gDQo+PiANCj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBjb3JlIG1haWxp bmcgbGlzdA0KPj4gY29yZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jb3JlDQo+PiANCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPmNvcmUgbWFpbGluZyBsaXN0DQo+Y29yZUBpZXRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQo= From nobody Thu Oct 5 04:50:34 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7830A1342D3 for ; Thu, 5 Oct 2017 04:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLoLW5WHfWEZ for ; Thu, 5 Oct 2017 04:50:30 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07981342C5 for ; Thu, 5 Oct 2017 04:50:29 -0700 (PDT) X-AuditID: c1b4fb3a-0adff70000003fec-2e-59d61c83edd9 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B4.86.16364.38C16D95; Thu, 5 Oct 2017 13:50:28 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 5 Oct 2017 13:50:27 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4ZMDF6G2oaq/IiQofEz3FbBCmikNtMtULPKqxGexQR8=; b=OR3M0zZ0ItfoqiU4OUmy+VjOh+m99yEkRsrtYaT/tuzEg6mN9/3aaBIKtmacXoUyfPkJJV5ch9k6o0b6TNT0ACKNfzoHlTzB8zIfoLuRLMgwcPLJTPBIJxtYFMxHOucmGVLXQ+0z/kpMqFyVc14W7pfh9W7zvi/jSuDTnYqmcFM= Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com (10.168.129.17) by HE1PR0701MB2537.eurprd07.prod.outlook.com (10.168.129.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 5 Oct 2017 11:50:26 +0000 Received: from HE1PR0701MB2539.eurprd07.prod.outlook.com ([fe80::456e:eb29:8077:6178]) by HE1PR0701MB2539.eurprd07.prod.outlook.com ([fe80::456e:eb29:8077:6178%17]) with mapi id 15.20.0077.018; Thu, 5 Oct 2017 11:50:26 +0000 From: Francesca Palombini To: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core@ietf.org WG (core@ietf.org)" Thread-Topic: =?utf-8?B?W2NvcmVdICAg8J+UlCBXRyBDYWxsIGZvciBBZG9wdGlvbiBvbiBkcmFmdC1h?= =?utf-8?Q?msuess-core-repeat-request-tag-00?= Thread-Index: AQHTPObYOROpZqxttkGRksmfL6kiqqLVJhfg Date: Thu, 5 Oct 2017 11:50:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2537; 6:2FE4a3LbN84sKusjy1F7H4NuUZ6TiN5lpePwnnUujh3lZiS5dn3dhMf/rl5q9vlzIBYeOUzJCVPEDspzu3tuHwRfb1mZJSw2E3d8+ICzibXSVg6nfgSEJAQG8q7PGv5yc0jGXOQci/Nys6qnVb3G5Tg8TWkhPEY5GIq3XIniQFURteCM/xA8mrRk7bYUCRAeF1nmtfJqUaWkXvDzQ0KjZfOzTIPa1FWYO4P20ZBRNVrZkQi2G8nGAHqT1PfjP/2VDwulJVp4vlc72xpW3ShN0Iu2agmekr1Dm9w41tu/TAUGVPRUOyF8L/W31scCbj1mU0YgpRQCqp8Ww708AItLGg==; 5:Sg3l7dTA97gn3xrHKTWzUnTEXcaO7CgRPHX3hQqsjN6KVlM0rQD+7qzA+l9JhkJ/vCDDwi+r4OMS7S7rGG7PbPhtj/O3Ew4AZDpoLBIsw73GdCDl8phAn312VfuAGjYxDYzl5tDPzmB70PVJjpyD6A==; 24:xy1I8/GQ+NmlA/ch6fV5chBdtVaRlHMyGUcl8VrY+fNBKXO5ZagvYrxuyISPQFPTbMbkThWnRsbU4C3e55sdv2+4YuBbclqqbbxfwKtKqqg=; 7:6JPGqULgF2C6nu5r+uk07di+lAGA/IEDiyWCNMJcEIx94yNdPt6B89KD5TQNJpeNK9RQ801IMgH2CE2iVQa0eoQUVtO9DzDaIfQu6HJycvRwo3ujBiuRn1wlf7KyT6H38l8HMSETqMR4FAPubK62gCZ3JmYntvUlgjrYxYkrB7i9hsU6aWkurLOaWfL/M7i4teISORqE1CYmmGRHNPH0lIQiQ6O7kcL6oqg3BriFnMs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c9953fe7-a01d-4b56-ea63-08d50be74503 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR0701MB2537; x-ms-traffictypediagnostic: HE1PR0701MB2537: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB2537; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB2537; x-forefront-prvs: 04519BA941 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(199003)(189002)(5250100002)(6436002)(81166006)(9686003)(229853002)(230783001)(101416001)(8936002)(97736004)(81156014)(55016002)(6306002)(229383001)(68736007)(6506006)(105586002)(7736002)(2906002)(236005)(53936002)(189998001)(106356001)(2900100001)(6246003)(54896002)(53546010)(99286003)(478600001)(74316002)(316002)(54356999)(3280700002)(102836003)(606006)(66066001)(966005)(33656002)(790700001)(50986999)(3846002)(7696004)(2950100002)(76176999)(5660300001)(19609705001)(14454004)(110136005)(86362001)(25786009)(6116002)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2537; H:HE1PR0701MB2539.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB25397D1C4000D067DA0F403D98700HE1PR0701MB2539_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2017 11:50:26.4934 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2537 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUyM2K7im6LzLVIg5332Sz2vV3P7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujI+X7jIVnLGpeHdmHXsD4werLkZODgkBE4kbx7azdTFycQgJ HGGUuPFyGjuEc5xR4tzVBjCHRaCXWWL/991QmRlMEq+mXmSFcJ4xSrQu2sIIMoxNwEbiwsP3 rCC2iEC5xPztE8HiwgKtjBKz/5SANIgItDFK/N0F0s0B5BhJXJtcBFLDIqAi8XD5f2YQm1cg QaLj0CwwW0jAXuLgkq1MIDangIPE03WL2UFsRgFZiS+Nq8FqmAXEJW49mc8E8ZCAxJI955kh bFGJl4//sULUJ0tcud3HDhFXkHjV3cAGYctKXJrfzQhym4RAB7tEQ/MSqISexNaJbxkhbF+J tvN9rBBFCxglNjddhirSkVj6/jjUNm+JV9OfQTXkS/zbdokNouE8q0T39wVgH0sIyEg8/8cL UfOBVeLN9JgJjNqzkDwBYedLrL91jm0WODAEJU7OfMIyC6ibWUBTYv0ufYgSRYkp3Q/ZIWwN idY5c9mRxRcwsq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECEw2B7f8ttrBePC54yFGAQ5G JR7e1j9XI4VYE8uKK3MPMUpwMCuJ8F4SvRYpxJuSWFmVWpQfX1Sak1p8iFGag0VJnNdh34UI IYH0xJLU7NTUgtQimCwTB6dUA6OT3zTLhJa0yEOMv2d8+B2fdyM4+oF8lKSzTPbPrz2b2Ods O3fk6yK9+qdW5+x1bV+1tvMnbWW2Tp9+6dQxNaab5VaJ/6cLftM4c/RMpu7CK02eVhNslD59 eb4kYE2jrm94b9WerAV50T0bA8XcXBwTI9MdfLbLX11kd4bX7tYP/mZdPQ3ZPUosxRmJhlrM RcWJAJnCr1wyAwAA Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 11:50:31 -0000 --_000_HE1PR0701MB25397D1C4000D067DA0F403D98700HE1PR0701MB2539_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgZXhwcmVzc2VkIGF0IHRoZSBJRVRGOTkgbWVldGluZywgSSBzdXBwb3J0IFdHIGFkb3B0aW9u IG9mIHRoaXMgZHJhZnQuDQoNClRoYW5rcywNCkZyYW5jZXNjYQ0KDQoNCkZyb206IGNvcmUgW21h aWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKYWltZSBKaW3DqW5leg0K U2VudDogZGVuIDQgb2t0b2JlciAyMDE3IDEwOjAwDQpUbzogY29yZUBpZXRmLm9yZyBXRyAoY29y ZUBpZXRmLm9yZykgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbY29yZV0g8J+UlCBXRyBDYWxs IGZvciBBZG9wdGlvbiBvbiBkcmFmdC1hbXN1ZXNzLWNvcmUtcmVwZWF0LXJlcXVlc3QtdGFnLTAw DQoNCkRlYXIgQ29SRSBXRywNCg0KZHVyaW5nIGxhc3QgSUVURiB0aGUgZm9sbG93aW5nIGRyYWZ0 IHdhcyBwcmVzZW50ZWQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYW1zdWVz cy1jb3JlLXJlcGVhdC1yZXF1ZXN0LXRhZy0wMA0KDQpUaGUgZHJhZnQgbWl0aWdhdGVzIGtub3du IGlzc3VlcyB3aXRoIHRoZSBmcmVzaG5lc3Mgb2YgYSBDb0FQIHJlcXVlc3QgYXMgd2VsbCBhcyBm cmFnbWVudGF0aW9uIG9mIHRoZSBDb0FQIG1lc3NhZ2UgYm9keS4NClRoZXJlIHdhcyBzdHJvbmcg cm9vbSBjb25zZW5zdXMgb3IgYWRvcHRpb24gc28gdGhpcyBpcyBqdXN0IHRvIGNvbmZpcm0gaXQu IFBsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMsIGluY2x1ZGluZyBh bHRob3VnaCBub3QgbGltaXRlZCB0byB3aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlv bi4gTm9uLWF1dGhvcnMgYXJlIGVzcGVjaWFsbHkgZW5jb3VyYWdlZCB0byBjb21tZW50Lg0KDQpU YXJnZXQgZm9yIHRoZSBlbmQgb2YgdGhlIFdHQSBjYWxsIGlzIDE2dGggT2N0b2Jlci4NCg0KQ2lh bywNCi0gLSBKYWltZSBKaW3DqW5leg0KDQo= --_000_HE1PR0701MB25397D1C4000D067DA0F403D98700HE1PR0701MB2539_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgU3ltYm9sIjsNCglwYW5v c2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJT ZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9z ZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGV4cHJlc3NlZCBhdCB0aGUgSUVURjk5IG1lZXRp bmcsIEkgc3VwcG9ydCBXRyBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3MsPGJyPg0KRnJhbmNlc2NhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4g Y29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+ SmFpbWUgSmltw6luZXo8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDQgb2t0b2JlciAyMDE3IDEwOjAw PGJyPg0KPGI+VG86PC9iPiBjb3JlQGlldGYub3JnIFdHIChjb3JlQGlldGYub3JnKSAmbHQ7Y29y ZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2NvcmVdIDxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj4mIzEyODI3Njs8L3Nw YW4+IFdHIENhbGwgZm9yIEFkb3B0aW9uIG9uIGRyYWZ0LWFtc3Vlc3MtY29yZS1yZXBlYXQtcmVx dWVzdC10YWctMDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIg Q29SRSBXRyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmR1 cmluZyBsYXN0IElFVEYgdGhlIGZvbGxvd2luZyBkcmFmdCB3YXMgcHJlc2VudGVkOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFtc3Vlc3MtY29yZS1yZXBlYXQtcmVxdWVz dC10YWctMDAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hbXN1ZXNzLWNvcmUt cmVwZWF0LXJlcXVlc3QtdGFnLTAwPC9hPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZHJhZnQgbWl0aWdhdGVzIGtub3duIGlz c3VlcyB3aXRoIHRoZSBmcmVzaG5lc3Mgb2YgYSBDb0FQIHJlcXVlc3QgYXMgd2VsbCBhcyBmcmFn bWVudGF0aW9uIG9mIHRoZSBDb0FQIG1lc3NhZ2UgYm9keS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIHdhcyBzdHJvbmcgcm9v bSBjb25zZW5zdXMgb3IgYWRvcHRpb24gc28gdGhpcyBpcyBqdXN0IHRvIGNvbmZpcm0gaXQuIFBs ZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMsIGluY2x1ZGluZyBhbHRo b3VnaCBub3QmbmJzcDtsaW1pdGVkIHRvIHdoZXRoZXImbmJzcDtvciBub3QgeW91IHN1cHBvcnQg YWRvcHRpb24uIE5vbi1hdXRob3JzIGFyZSBlc3BlY2lhbGx5Jm5ic3A7ZW5jb3VyYWdlZCB0byBj b21tZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UYXJnZXQgZm9yIHRoZSBlbmQgb2YgdGhlIFdHQSBjYWxsIGlzIDE2dGggT2N0b2Jlci4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q2lhbyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LSAtIEphaW1lIEppbcOpbmV6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_HE1PR0701MB25397D1C4000D067DA0F403D98700HE1PR0701MB2539_-- From nobody Fri Oct 6 05:46:40 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6B713208E; Fri, 6 Oct 2017 05:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 ZWjGVEpxNVTt; Fri, 6 Oct 2017 05:46:32 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15CA1342E0; Fri, 6 Oct 2017 05:46:31 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3BD8A47727; Fri, 6 Oct 2017 14:46:29 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 74AAE57; Fri, 6 Oct 2017 14:46:28 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.130]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 3936119; Fri, 6 Oct 2017 14:46:28 +0200 (CEST) Received: (nullmailer pid 18068 invoked by uid 1000); Fri, 06 Oct 2017 12:46:27 -0000 Date: Fri, 6 Oct 2017 14:46:27 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-nottingham-rfc5988bis@ietf.org, "core@ietf.org WG (core@ietf.org)" Message-ID: <20171006124626.d6463wglfpagqhsu@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sy6niz3k5ri4ozre" Content-Disposition: inline User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: [core] RFC5988bis vs RFC6690: interpretation of anchors X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 12:46:38 -0000 --sy6niz3k5ri4ozre Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Mark, hello CoRE WG, reviewing the current 5988bis draft in the course of work on draft-ietf-core-resource-directory, it seems to me that the update is fixing a previously ambiguous behavior to be different to how 6690 has disambiguated it -- the question is: Whether the target IRI is resolved relative to the link context IRI or the document context IRI. * 5988 prescribes that the relative target references are resolved per 3986 (not applying base IRIs from the message's content, which I read as data inside the response body like an HTML base-href). This leaves it unclear whether the "Context" of the link (defined in the next paragraph) also serves as the context as the term is used in 3986 section 5. * 6690 section 2.1 explains that the context is just another word for Base URI ("context URI of a link (also called the base URI in RFC39)"), and that the anchor sets such a context. This implies that if an anchor is set, the target reference is resolved relative to the resolved anchor. * 5988bis does not change the relevant wording, but the algorithm in Appendix B clearly resolves target before resolving context, so both the target_string and the context_string are resolved relative to the document URI. None of documents has examples where the it actually matters whether or not target_string is relative to context_string or to the document base URI. Was the decision to clarify the behavior this way made in awareness of RFC6690 building on the original document interpreting otherwise? If not, could you consider the alternative behavior? Or are there other applications or documents that are already set on the new one? If this stays as it is in the latest 5988bis, will the text in RFC6690 be considered erroneous, or will application/link-format diverge from link headers? In resource-directory, we *will* need to give examples of what a link looks like when served from a different URI, and to give guidance as to how a directory should parse the links -- so what can we assume? Thanks Christian --=20 There's always a bigger fish. -- Qui-Gon Jinn --sy6niz3k5ri4ozre Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlnXexwACgkQOY0REtOk veHwXQ/+PVFC/zQg6VIpxEd8r7MGVnA8EPyr0UvVcxz0uEi1kVSnfz4zDHq27ep2 iZlD3w9CXw38h3kzD/fTitvQ0E79qnDkPIIIJ8F00THSvReLBPizIxCvPGjtAw9B 8tVEk7rnRuFaCeFK+3F4NAmTAlFxsk/8PVTcaowWZPLIev7i++QlWZDUQUkh0atI neE9SpnXKJbxE15IIAzmPRE0PV6TNwCFaNL0+MBUdsLtFZeteUYJ87b3sV+nGjdm p3z73mWpML4ewWLBIA+RGbdDvQP9kXUPMndGYrmqTPKdz6UCCp8UdJv+ZEEJlLxX rrh9sO7fNtMzSd4Mo0nXzdY3KudrJtIAfqOjceELbI0XzsBcdTkaxiNYI120Ij9n tEojANM8hMC1n1KvKxrKnZr7nSEe3evOOfeS+fIT9j7Jfc4oQMTdgWa/SaiYssJU nLs5Vfp7IqzuE8CZdb3dHeoNOTu1Tbyz3uMlu/ylon5t/J1sWdMT73jtprljnSl/ OSZWtxARyRdH5+GOPqonLdX4vx680a767gtHZtbLn/y1SBKiuJGpIZBCmLoWbnxi hXbmCPxLoECgNfKkBWHT+8nSCKTMFPk5ThV6bs2XV7XTWjWPKnxg2fe7VvpfKDGU PpRhz0q5dlvyTFiFzHDIBi7ckwOWURlAhPZL1AQNPi7QmKJRAj4= =vX8l -----END PGP SIGNATURE----- --sy6niz3k5ri4ozre-- From nobody Fri Oct 6 06:31:19 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A6A1342C5 for ; Fri, 6 Oct 2017 06:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 EFRf06aXTxkL for ; Fri, 6 Oct 2017 06:31:16 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF861331BA for ; Fri, 6 Oct 2017 06:31:16 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0FE0347727 for ; Fri, 6 Oct 2017 15:31:11 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 645FA57 for ; Fri, 6 Oct 2017 15:31:10 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.130]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2E68219 for ; Fri, 6 Oct 2017 15:31:10 +0200 (CEST) Received: (nullmailer pid 20657 invoked by uid 1000); Fri, 06 Oct 2017 13:31:09 -0000 Date: Fri, 6 Oct 2017 15:31:09 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "core@ietf.org WG (core@ietf.org)" Message-ID: <20171006133108.epl4drcou6diiyd7@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5hydjggwhl4r6qw5" Content-Disposition: inline User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: [core] RFC6690: target and link attributes (and dynlink applications) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 13:31:17 -0000 --5hydjggwhl4r6qw5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE WG, reviewing the current dynlink draft for an application, its use of link attributes struck me as odd as (from reading RFC5988) I interpreted link attributes to be always attributes of the target and not properties of the link, so ;rel=3D"boundto";anchor=3D"/a/observing";bind=3D"ob= s", ;rel=3D"boundto";anchor=3D"/a/polling";bind=3D"poll" is semantically equivalent to ;rel=3D"boundto";anchor=3D"/a/observing";bind=3D"ob= s";bind=3D"poll", ;rel=3D"boundto";anchor=3D"/a/polling" because target attributes are not tied to the link but only to the target. In RFC6690, I found the explicit mention that an attribute "[describes] the link or its target", so unless an attribute is known to be a target attribute (which, by 5988, all seem to be), it can not be freely moved between links. Is this a deliberate deviation from 5988? Can dynlink (and resource-directory, whose implementations can be tempted to do the above transformation) rely on this staying around? If this is something we actively want to have, IMO we should ask to have it included in 5988bis; otherwise I think we should not rely on it. I'm a bit worried that having a feature like this creates divergence between two seemingly compatible formats and impedes code sharing between a link-header and link-format implementations. Please let me know what you think of the situation Christian --=20 Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -- Terry Pratchett (attributed) --5hydjggwhl4r6qw5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlnXhZMACgkQOY0REtOk veEjcA//eG23nS56+A2Avxdf8L0gI441pltYPjrbeUTbbcPk/cjUZK+z2Gn6oa7W c6uLmDqGYie4MBjVbIQd/Luu4blpnvW2BEn8f2t10Ulr0Ftt+BA/NAwivyMqmIHv 6mGtuKE/JFPTuiyflj+vAQP5yHtzEqzcFpz/zwkVMRYrz95UNcHbv9u1M4OjlPNM sLm1gPYqvfNhyxoHJWfRHzwB5G3Qwak7L0Q9Gm4lUY6sz8oqOtmmotaOWRqQXWzo keo7+1DPiO/QhcsGezDQVgSGwQ9A+oZFbHEC3f4QmsPzKoMdQAFNq6HDkNgDtLxL 1Sif1Z+4TU/TsZPCU4LixO4vEbQWicm5ufVCSLA+oC/6y1AsUjAvKFg2Vpju/bi2 uovmA/BEgKJj3QitvPTYZKfCmTTr/HmdRWwqXIHFfX0TWkUowRCFYIqmMRbfNtwf yfqJH7yERrC0TyinDqWNkp+ElfO5vg6MXF1ZPCDRn+jda87KpFIUX2lf4TgjaYZy u7SWAdTAyyj8WgBZxrrFReGTktNPxuiGaiS6hGMe/+QhVl4XCXQinUoz/uSavahN nfcmIjkdrEa4WL7jLyzzVZMTmQO/oM8XATJgkOTjXi5iRvWZNo3ak9izMwwFWm/S Uw9huYC/NwpWD0x4Ny0pN5vWuOGeYwvR9WqtHx4eWjcR426M8oo= =K/vo -----END PGP SIGNATURE----- --5hydjggwhl4r6qw5-- From nobody Fri Oct 6 11:48:06 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B31134C37 for ; Fri, 6 Oct 2017 11:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 xKeQG8K1bxEM for ; Fri, 6 Oct 2017 11:48:02 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2F1134C1F for ; Fri, 6 Oct 2017 11:48:01 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id 762F4223C34; Fri, 6 Oct 2017 18:47:59 +0000 (UTC) Received: from [192.168.0.64] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Fri, 6 Oct 2017 20:47:59 +0200 To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org WG (core@ietf.org)" References: From: Marco Tiloca Message-ID: <1abea2a6-ca03-0806-93a0-0517e2498052@ri.se> Date: Fri, 6 Oct 2017 20:47:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dikc74J7886IoqERfblbFh7LMIpI9K6rE" X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=KqQ94SeN c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=02M-m0pO-4AA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=xPT6tdSuAAAA:8 a=0zhQ4xgkvBBr4oHzwhgA:9 a=vRhEawdkhMaTFiAf:21 a=GcsXO-NJvzQso4TF:21 a=QEXdDO2ut3YA:10 a=0FD05c-RAAAA:8 a=MehzG-DCschUXUABMjQA:9 a=oFcjmmqVu9sKdrE_:21 a=3stLvTaqQrGWgdYG:21 a=ME5k141DJ5K6Lnfh:21 a=_W_S_7VecoQA:10 a=55NgRPijT7-RHO1HkhEA:9 a=ONNS8QRKHyMA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=80PJfYVSYmV_jLpvUEnt:22 a=l1rpMCqCXRGZwUSuRcM3:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 18:48:05 -0000 --dikc74J7886IoqERfblbFh7LMIpI9K6rE Content-Type: multipart/mixed; boundary="VR2UxcUqKBMx5nspjfsuCDPoCOVFTokeb"; protected-headers="v1" From: Marco Tiloca To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org WG (core@ietf.org)" Message-ID: <1abea2a6-ca03-0806-93a0-0517e2498052@ri.se> Subject: =?UTF-8?Q?Re:_[core]_=f0=9f=94=94_WG_Call_for_Adoption_on_draft-ams?= =?UTF-8?Q?uess-core-repeat-request-tag-00?= References: In-Reply-To: --VR2UxcUqKBMx5nspjfsuCDPoCOVFTokeb Content-Type: multipart/alternative; boundary="------------D5BF050D4074CE7333ED4E02" Content-Language: en-US This is a multi-part message in MIME format. --------------D5BF050D4074CE7333ED4E02 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I support WG adoption of this draft. Best, /Marco On 2017-10-04 10:00, Jaime Jim=C3=A9nez wrote: > Dear CoRE WG, > > during last IETF the following draft was presented: > https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00=C2= =A0 > > The draft mitigates known issues with the freshness of a CoAP request > as well as fragmentation of the CoAP message body.=C2=A0 > There was strong room consensus or adoption so this is just to confirm > it. Please reply to the list with your comments, including although > not=C2=A0limited to whether=C2=A0or not you support adoption. Non-autho= rs are > especially=C2=A0encouraged to comment. > > Target for the end of the WGA call is 16th October.=C2=A0 > > Ciao, > - - Jaime Jim=C3=A9nez > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Marco Tiloca, PhD Research Institutes of Sweden RISE ICT/SICS Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.sics.se https://www.sics.se/~marco/ The RISE institutes Innventia, SP and Swedish ICT have merged in order to become a stronger research and innovation partner for businesses and society. SICS Swedish ICT AB, has now changed name to RISE SICS AB. --------------D5BF050D4074CE7333ED4E02 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I support WG adoption of this draft.

Best,
/Marco

On 2017-10-04 10:00, Jaime Jim=C3=A9ne= z wrote:
Dear CoRE WG,

during last IETF the following draft was presented:=
https://tools.ietf.org/html= /draft-amsuess-core-repeat-request-tag-00=C2=A0

The draft mitigates known issues with the freshness= of a CoAP request as well as fragmentation of the CoAP message body.=C2=A0
There was strong room consensus or adoption so this= is just to confirm it. Please reply to the list with your comments, including although not=C2=A0limited to whether=C2=A0or = not you support adoption. Non-authors are especially=C2=A0encouraged to comment.

Target for the end of the WGA call is 16th October.= =C2=A0

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



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


--=20
Marco Tiloca, PhD
Research Institutes of Sweden
RISE ICT/SICS
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)
Phone: +46 (0)70 60 46 501
https://w=
ww.sics.se
h=
ttps://www.sics.se/~marco/

The RISE institutes Innventia, SP and Swedish ICT
have merged in order to become a stronger research
and innovation partner for businesses and society.

SICS Swedish ICT AB, has now changed name to RISE SICS AB.
--------------D5BF050D4074CE7333ED4E02-- --VR2UxcUqKBMx5nspjfsuCDPoCOVFTokeb-- --dikc74J7886IoqERfblbFh7LMIpI9K6rE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ18/eAAoJEO4mZLQOWNpDNfsH/3I3RnEnqtmfxpr3H8qZ+Y7x ck1WClDO7bSVx3K+Xd5UmcnLEYEsLtEhQiJakW+rvU8Sr8+C10r9iSqmYIc1TPGJ MQfbaUgrerTOWN18645+QzDLvhjUWxGYzFUeoBUKHOYkMm/FeTtGxffRc+OtgfK2 mCy0VfwzguhDdndyFQskL+PWU5ub8dzgQhUN1NVKxUpARnWTNxRRSOVR/anLxY57 vTAY8zdWdSgCbONGO9p3dxPrDZlHZAjsBd31WGnWAASChuPuFN1punXrptjbplcH g9aksyGAhGOr5VtJ0IO4/BeAPyG0dmKJlpC3NPmHMH+63XifoCITT2iQ2XrEQQE= =jLyI -----END PGP SIGNATURE----- --dikc74J7886IoqERfblbFh7LMIpI9K6rE-- From nobody Mon Oct 9 11:28:51 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45926133338; Mon, 9 Oct 2017 11:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=BswV6Xmj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QPwMyM/8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYJv-M3h1WUA; Mon, 9 Oct 2017 11:28:46 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A170134534; Mon, 9 Oct 2017 11:28:46 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C37CF20E46; Mon, 9 Oct 2017 14:28:45 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 09 Oct 2017 14:28:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=FqvXcC4YrYeL2M6LrV /r6J9O+uoJct8IIr1clP2WlQU=; b=BswV6XmjFO4ukVyY7lpQUkwws6R6rUzDHq BDOPZOmhBpuXwaqFGo23FIcc2fkreNLjAp8G5ga40R6D74yeQrSA98M3E2RH9VQ+ 9gYkwQ5F0S6do2kM5GwDRAostOnVtheJfvnlOPIEbnjoXqtB2epypBn9XYUgnIje CiQ/W4XCAARdXiz5uc3ZCPy3CuERuPvWYikLnl0qOE3gbWjgqXd5II8LEe79ga1S EOxk81p2RvvgqzPcp09hmnzs6wK0jNArnjNroJI7KXZOdYNE7k/KCc/d1YSDUnSQ TWI+Wc+bx1yNOA+6wMb8UPVcQqnLNnsKbj8x5jfw0J/n+tgPlZuw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=FqvXcC4YrYeL2M6LrV/r6J9O+uoJct8IIr1clP2WlQU=; b=QPwMyM/8 geVtO0sKKKUTPRdjnQdALnHdMwAVPmWzhkNCkV7D+A3gWW0DcetR3GZJ531EFgXl PPU/qd9/QNJH2SpvvvpOEXVByti+iawpTUYl6xJZ8sSGdGFQfJ/FfEyEDcSukj8o +m1QzFk2UZAcGjrERobxAB9ufTBtCah3kMjo/0nkcu90HaTD0TvOqq8Z8Gjbm9pF tqW/sqe++NSdE3V8nernizKbsDIhaiIkgoLYv5y68lAhh6ozM8bMlZ/IzCUFlpZt hKK76SrVTVHk/f0PZwZggY/51vTI7V0hZ8dRtUr8e/3S1ZXS3+tzP+EZ1XQwtw0n j+xLYLu2TicdHg== X-ME-Sender: X-Sasl-enc: M4e7yFZVi2ytogkJhiGIuXKOR50J1mjb6IiZcW+D+5cB 1507573725 Received: from [10.100.20.97] (unknown [8.18.217.202]) by mail.messagingengine.com (Postfix) with ESMTPA id 438D3248B1; Mon, 9 Oct 2017 14:28:45 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Mark Nottingham In-Reply-To: <20171006124626.d6463wglfpagqhsu@hephaistos.amsuess.com> Date: Mon, 9 Oct 2017 11:28:44 -0700 Cc: draft-nottingham-rfc5988bis@ietf.org, "core@ietf.org WG (core@ietf.org)" Content-Transfer-Encoding: quoted-printable Message-Id: <5D407B1A-2400-4086-AE73-FD56B0C03E6F@mnot.net> References: <20171006124626.d6463wglfpagqhsu@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [core] RFC5988bis vs RFC6690: interpretation of anchors X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 18:28:49 -0000 Hi Christian et al, > On 6 Oct 2017, at 5:46 am, Christian Ams=C3=BCss = wrote: >=20 > Hello Mark, hello CoRE WG, >=20 > reviewing the current 5988bis draft in the course of work on > draft-ietf-core-resource-directory, it seems to me that the update is > fixing a previously ambiguous behavior to be different to how 6690 has > disambiguated it -- the question is: >=20 > Whether the target IRI is resolved relative to the link context IRI or > the document context IRI. >=20 > * 5988 prescribes that the relative target references are resolved per > 3986 (not applying base IRIs from the message's content, which I read > as data inside the response body like an HTML base-href). >=20 > This leaves it unclear whether the "Context" of the link (defined in > the next paragraph) also serves as the context as the term is used in > 3986 section 5. That's not ambiguous at all. 3986 only uses "context" casually; the = formal term is defined as "base uri" in 5.1. When introducing what links are, 5988 says: """ A link can be viewed as a statement of the form "{context IRI} has a = {relation type} resource at {target IRI}, which has {target = attributes}". """ How does this countenance that reading? > * 6690 section 2.1 explains that the context is just another word for > Base URI ("context URI of a link (also called the base URI in > RFC39)"), and that the anchor sets such a context. This implies that > if an anchor is set, the target reference is resolved relative to the > resolved anchor. That's diverging from 5988.=20 > * 5988bis does not change the relevant wording, but the algorithm in > Appendix B clearly resolves target before resolving context, so both > the target_string and the context_string are resolved relative to the > document URI. >=20 > None of documents has examples where the it actually matters whether = or > not target_string is relative to context_string or to the document > base URI. >=20 >=20 > Was the decision to clarify the behavior this way made in awareness of > RFC6690 building on the original document interpreting otherwise? No. > If not, could you consider the alternative behavior? No; doing so would break Web linking pretty fundamentally. > Or are there other > applications or documents that are already set on the new one? It's not new. AFAIK, 6690 is the only ones that interpreted it this way. > If this stays as it is in the latest 5988bis, will the text in RFC6690 > be considered erroneous, or will application/link-format diverge from > link headers? I think that's up to you. > In resource-directory, we *will* need to give examples of what a link > looks like when served from a different URI, and to give guidance as = to > how a directory should parse the links -- so what can we assume? I'm not sure what you're looking for here. Cheers, >=20 > Thanks > Christian >=20 > --=20 > There's always a bigger fish. > -- Qui-Gon Jinn -- Mark Nottingham https://www.mnot.net/ From nobody Tue Oct 10 12:20:57 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0267F1346B4 for ; Tue, 10 Oct 2017 12:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 NiSMdVXJ81yM for ; Tue, 10 Oct 2017 12:20:53 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964A5134292 for ; Tue, 10 Oct 2017 12:20:52 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id A04ED477B8 for ; Tue, 10 Oct 2017 21:20:50 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 9610C39 for ; Tue, 10 Oct 2017 21:20:49 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.130]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9891B19 for ; Tue, 10 Oct 2017 21:20:43 +0200 (CEST) Received: (nullmailer pid 31994 invoked by uid 1000); Tue, 10 Oct 2017 19:20:41 -0000 Date: Tue, 10 Oct 2017 21:20:41 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "core@ietf.org WG (core@ietf.org)" Message-ID: <20171010192040.qeanayarc5ziyd2v@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rylgoj5eennwzbpq" Content-Disposition: inline User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: [core] Use of rel=hosts (LWM2M?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 19:20:55 -0000 --rylgoj5eennwzbpq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE mailing list, the semantics of rel=3D"hosts" came up in recent RD planning discussions (around the topic of "how are statements from .well-known/core correctly represented in the RD?"). What is the relation type used for, and are any particular semantics applied to it, especially in LWM2M which was mentioned as one application area? The description in RFC6690 doesn't say too much, and rumor has it it is used to determine which host to contact for reaching the resource. Could someone elaborate on any application it has, or give me a pointer to where such applications are described further? Thanks Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --rylgoj5eennwzbpq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlndHYgACgkQOY0REtOk veE0wQ//R30q9+2V0tQQgNlBh8CAVtoIwNWdH466nj9OCwZBTOnuM8ublLGv7rwl aQIaq8qfbws3oBpWsdboo2YrGPXpwEZ6eUe5mf94Tbj3mzZqUnxS//1NTiwKYR3V 2wSsWmO9SHDK5ym6zMGusix8UqF9EXpS6DF2GPO1rP+DLuTDOnH+avGEUei4q5rl UbtcTPEEBmVI5ejMn/jIa20Se1PATJYdxdXRjk4yMhNK6Do6I2BqHUNeb6i+RW1M Yi3KvLIN5RaAcgunTARONT/8jwwhqZwfog6O+X42ZkBdG4dM96RdYxUp+CknvERM DFQ4Fcz8pE4eN0nDR8buUQigCCuibZRQR9AoLn7j6nlgd51yaTsNLay4oybgK+P8 3uzNiqGYh1vUs/iTnyVrr+Tk9G+xbTD9pDYSxhxje0y6kj1+MBT47lJHf63TwwVq Kkvps2gHuOK3VqJmbrCtnxGJi3+D/+3Tvjavsl31Wgf5ktCgJ6q9fgWZKqYg3Q30 fJZNF9jJee4Xzi1RxG5FWKQbdC6OAv0ViHcnVbdAkEi3pAKttvvrEq0PgoDv1EYw zvhbsT2raDl38i5l17zpE7AYfJi/jgw8AKEYCLKH2zDO2rXttVvUj0VUS37M20rw aT1CB0kfc7k5ICHdthicvEpKUYPSh2dmJzAyWOjdkasoBAXKZE8= =enVq -----END PGP SIGNATURE----- --rylgoj5eennwzbpq-- From nobody Tue Oct 10 12:52:52 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BBA132D96 for ; Tue, 10 Oct 2017 12:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOLbrpEU2pGk for ; Tue, 10 Oct 2017 12:52:46 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AFBC126D0C for ; Tue, 10 Oct 2017 12:50:36 -0700 (PDT) Received: from mail-lf0-f44.google.com ([209.85.215.44]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1e20Xx-0003MO-Sh; Tue, 10 Oct 2017 21:50:33 +0200 Received: by mail-lf0-f44.google.com with SMTP id d10so30007742lfg.11 for ; Tue, 10 Oct 2017 12:50:33 -0700 (PDT) X-Gm-Message-State: AMCzsaWRF3YskUVFMSnRCncUERNeNxNlkI79B51gwWk741FbTFua3W8w pE23v89qzjK3UrfPk78h5IoK0ImAhCUN9hADU78= X-Google-Smtp-Source: AOwi7QBZXUEQTR2iONEbj9wo77FBrN0teaxNMW85tW3EuXKyBxbLw1sgZ65Yntxg9Ogb3DJFc3SvHvjOf36YT5AmKzE= X-Received: by 10.25.83.78 with SMTP id h75mr4075503lfb.134.1507665033345; Tue, 10 Oct 2017 12:50:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.79.3 with HTTP; Tue, 10 Oct 2017 12:49:52 -0700 (PDT) In-Reply-To: <20171010192040.qeanayarc5ziyd2v@hephaistos.amsuess.com> References: <20171010192040.qeanayarc5ziyd2v@hephaistos.amsuess.com> From: Klaus Hartke Date: Tue, 10 Oct 2017 21:49:52 +0200 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: "core@ietf.org WG (core@ietf.org)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1507665036; e6f1d64e; X-HE-SMSGID: 1e20Xx-0003MO-Sh Archived-At: Subject: Re: [core] Use of rel=hosts (LWM2M?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 19:52:48 -0000 Christian Ams=C3=BCss wrote: > the semantics of rel=3D"hosts" came up in recent RD planning discussions > (around the topic of "how are statements from .well-known/core correctly > represented in the RD?"). > > What is the relation type used for, and are any particular semantics > applied to it, especially in LWM2M which was mentioned as one > application area? > > The description in RFC6690 doesn't say too much, and rumor has it it is > used to determine which host to contact for reaching the resource. Could > someone elaborate on any application it has, or give me a pointer to > where such applications are described further? Originally, RFC6690 was only for the /.well-known/core resource. A /.well-known/core resource of a server consists of links to the resources hosted by the server: the server "hosts" the link targets. In practice, the "hosts" relation type is basically a "I'm told I must use link relation types; let's put some random string in the 'rel' field to make people happy and then completely ignore it". I guess a resource directory is more like a repository of URLs (with some resource metadata) rather than of links, since there isn't really a relationship between the RD and the resources other than that the RD stores their URLs. Klaus From nobody Tue Oct 10 23:07:11 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2337A13303A; Tue, 10 Oct 2017 23:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 ZQgQtuZCUo6A; Tue, 10 Oct 2017 23:07:07 -0700 (PDT) Received: from mail4.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 89E70132D4B; Tue, 10 Oct 2017 23:07:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1507702025; h=from:subject:to:date:message-id; bh=jqrgyKH+Beq0ojucCPg7p1Eg/EyPT7eh+doQZ2bV4XM=; b=YtnIEign0WVPNMElYqrRfCRA1BM1R0cYlyG2KXDA11tv+6Vnmvku8KYeiEEIm3EzFPy3kuv3COA CtGW1tcw8jHScgWUE+yZx1L7ZY84uqQf+OBI00qITrprhRqm//PCDsKI9Ag/hA18WJQ3bJ50tjDzb K5IoJy5QkoJGe66+Msuv4fBJPcYCmz1BjChwlJUKkZzxzrWLLPIhReklhxhvxktkd6mIFxnLi95CA CRP0Zsi2KVGANCG1PVeLkNNBjQ4R13eYCZs3Oh0Ihwg/bLzqVP3MXKT67Nqin8cS6ixB/pTITbheT UPzsUYgv63m81L1o0oXIcem1dHVBjdU1C78A== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 10 Oct 2017 23:07:05 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 10 Oct 2017 23:06:10 -0700 From: Jim Schaad To: CC: Date: Tue, 10 Oct 2017 23:06:58 -0700 Message-ID: <011901d34257$27b8d950$772a8bf0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdNCDxflBrT2UulyTbeReHGbxp5RNg== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [core] Review draft-ietf-core-object-security-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Oct 2017 06:07:09 -0000 This update had a few things that came in out of left field and maybe a couple of them should have stayed there. 0. Document structure - define a short name to be used as the header of each page. 1. Introduction: I am not sure what is meant by a "non-empty message". This cannot refer to the payload being empty, so I am unclear what is meant here. 2. Section 2 - I dislike the fact that you are moving the byte of flags from the body to the option. I want the flags next to the data that I am either assembling or dis-assembling and not in a totally different location. If you think that the option is going to have more than one value, then it should either have its own flags or a defined structure. Please move it back unless you have a REALLY good case and are willing to prove it. 3. Section 3.1 - I do not understand why you are making the Send ID an integer rather than a byte string. There are a couple of issues with this. First it is thought of as a byte string everywhere that it is currently passed around - in COSE and in ACE. Secondly, it decreases the number of ids that are possible as h'01' and h'0001' are distinct while 1 and 1 are not. 4. Section 3.1- I am not sure that the word 'interchange' in the last paragraph is what you want to use. This does not read as proper English when I read it. "Endpoints can operator in either or both roles as client and server and use the same security context for those roles." 5. Section 3.2.1 - In the structure info - you have id as a bstr, but it was defined as an integer previously. You need to harmonize this. Additionally, it should be "alg : int / tstr," to match the definition of an algorithm identifier in COSE. Also section 5.3 6. Section 3.3 - s/1, For AES/1, for AES/ 7. Section 3.3 - you have a requirement in the last sentence about the length of sender IDs. How should this be enforced given that IDs are integers, does this imply a restriction on the range of integers to be used? 8. Section 4.3 - I am not sure that this section should start "Most CoAP header fields..." Looking at the table, it appears to be about 50-50 and the assumption is new fields will probably be internal. I think 'some' may be better. 9. Section 5 - I would like to have the Partial IV have a length of 1 in the event that the partial iv is zero. Ditto kid 10. Section 5 - The rule of the SHALL NOT for Partial IV worries me for group messaging. It may cause problems you don't want. There are no real problems, except for optimization, to using the reflected Partial IV value. Please rethink this. Ditto kid 11. Section 5.1 - Does this mean that the Partial IV is limited to 2^(5*8) different values? If you exceed this is a new context required or do you wrap or something else? 12. Section 5.1 - what is the purpose of putting the ID of the PIV generator in the nonce value? Please put in text that will justify this. Given that the keys are different, is there any need for this? 13. Section 5.1 - Please use a different symbol in the figure than +, this could be read as addition rather than xor. 14. Section 5.3 - You need a rule for options for dealing with a repeated option. 15. Section 6.1 - s/request's ID/requestor's ID/ 16. Section 7.4 step 8 - It would appear that if there is an inner option which is present on the outer message but not present on the inner message, then it would not be removed. Is that what is desired? 17. Section 8.3 - is there a specific error to return here, or is just the "can't find a kid" error? Please document. From nobody Wed Oct 11 09:48:08 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7783A13300C for ; Wed, 11 Oct 2017 09:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 hfRtAQz5U8HH for ; Wed, 11 Oct 2017 09:48:05 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 363131342D6 for ; Wed, 11 Oct 2017 09:48:05 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 8F0B147819; Wed, 11 Oct 2017 18:48:03 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 7C3C436; Wed, 11 Oct 2017 18:48:01 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0413619; Wed, 11 Oct 2017 18:48:00 +0200 (CEST) Received: (nullmailer pid 16066 invoked by uid 1000); Wed, 11 Oct 2017 16:48:00 -0000 Date: Wed, 11 Oct 2017 18:48:00 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "core@ietf.org WG (core@ietf.org)" , Mark Nottingham Message-ID: <20171011164758.73n7ytnniqzyaft2@hephaistos.amsuess.com> References: <20171006124626.d6463wglfpagqhsu@hephaistos.amsuess.com> <5D407B1A-2400-4086-AE73-FD56B0C03E6F@mnot.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rbu7ccrj3ufnvflp" Content-Disposition: inline In-Reply-To: <5D407B1A-2400-4086-AE73-FD56B0C03E6F@mnot.net> User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [core] RFC5988bis vs RFC6690: interpretation of anchors X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 11 Oct 2017 16:48:07 -0000 --rbu7ccrj3ufnvflp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Mark, thanks for your fast and unambiguous response. On Mon, Oct 09, 2017 at 11:28:44AM -0700, Mark Nottingham wrote: > That's not ambiguous at all. 3986 only uses "context" casually; the > formal term is defined as "base uri" in 5.1. >=20 > When introducing what links are, 5988 says: >=20 > """ > A link can be viewed as a statement of the form "{context IRI} has a > {relation type} resource at {target IRI}, which has {target > attributes}". > """ >=20 > How does this countenance that reading? That sentence doesn't; it's the informal use of context that did, when read without keeping normative and non-normative language apart stictly. At any rate, with the algorithm in 5988bis the intention is fixed, and we'll need to think of how to resolve the resulting discrepancies with 6690 and its users. So, hello working group, > > * 6690 section 2.1 explains that [...] if an anchor is set, the > > target reference is resolved relative to the resolved anchor. >=20 > That's diverging from 5988.=20 So how do we go about this? If CoRE insists on sticking with the divergence it's fine with me, but I assume it doesn't. And if so, we'd need to state that explicitly in resource-directory, and I'd prefer not to only start this discussion when it goes through late review stages. Otherwise, given that we can't change that in an erratum, the next logical step would be a 6690bis document that makes a clear cut and changes the link semantics to the 5988 ones. The published documents that reference 6690, from my brief survey, do not really touch on the semantics of links; the one affected most deeply is RFC7089, and given it is used in an HTTP context together with Link headers, I consider it unlikely that applications actually implement the diverging behavior of 6690 for link-format bodies. The document does give special rules for the links' interpretation, though, which use Context as a formal term. > > In resource-directory, we *will* need to give examples of what a link > > looks like when served from a different URI, and to give guidance as to > > how a directory should parse the links -- so what can we assume? >=20 > I'm not sure what you're looking for here. Guidance from the working group as to which direction this will take, and how this topic can come to a conclusion without holding up resource-directory for cycles. Thanks Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --rbu7ccrj3ufnvflp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlneSzoACgkQOY0REtOk veGm9RAAsw2Tj6ZosGSn4w9L+QI1yja0/T/WvcT+skKDE6AgxkOGusklJX93xhop ORGaCOy+XwNOJ51F0Ln+iPV7B/FUHLHo59tPnKqMLiHes5Lv/DBTldwanQ24xa3O MK6jmF8z+nnIKp6x92PLp+x69Uu5dhcIXIok2WmgSbvFaiurYzdvbZpkUmNpHZOU CNAJSPo1VhhlyIJY297P1Tzi3HrPhdRcswmMGV8B4H9zCpgPw8ESjlYFwUnFgIF7 Hqb/WXpP9jCwl9uAv57R6XGSFSRfxs0qE6FzV2pF+fF9nb4+NCspQ3T0ZfAbzKUX 4SP3G9ErkA4u4r/HTV/YD2Rq9zF0Yxu4gAzK+fCstV75L1/fgEmkPbMHTxd3ugEC iVbP/0L6jhIqrkuXawRuLj5KpWVV6MTCthHwI0+bAfyP0OthwHxurllL3Bpz+cyz 3tJK29Mq0b0s82FPDmPpWedzUCu0svsaw9IZkWMrPfO/6IRDEP9pmyiJAsbe/fE0 Tsh5wa2Ssi8r4xt6cvVju++2iWHpaApqX3MZhoKHduziixu7yh3X77eGRjCNVuUn CCBMgiPrhF/ASAm7gLLY3YeRT+8pBedI7e3NuyLSK1D6k5EYLWhLgcnYsHJz33vF HH0/3brhCv2bISu3sLEkPNmyhH3Nmg8AccZfFY1NezGgRMiG64U= =zApv -----END PGP SIGNATURE----- --rbu7ccrj3ufnvflp-- From nobody Wed Oct 11 19:24:05 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C6A1342FE for ; Wed, 11 Oct 2017 19:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=augustcellars.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 6A8GKube_1fh for ; Wed, 11 Oct 2017 19:23:58 -0700 (PDT) Received: from mail4.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 F37001342F2 for ; Wed, 11 Oct 2017 19:23:57 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1507775033; h=from:subject:to:date:message-id; bh=LIuMR6lNBUc/md9y24D7nyRco7kr8lX5324QLcobM0Q=; b=bKkTKTE2b9w9EQpjUHAY/eEn1VgL6FZZ23UbAWM85KWT11v2+7szff71gTSyX5tLZHuvDV/nQoI lgANP3kd0eA+w3SCo596hgWnUTEVj/U/Na5cerqNK9EnhMeqfA5gsSQiMWO9b8VpROV7p4H144jUg HTDV/2h6ENkc1tuEF5qg1cDLcYHqdNCAVJicGCFqoon211qdTDz3WgWQRkk2GL+KrMOaG9Sqm6eFm dwDmuOQAVRs5MRZB7/tesaTeiviUYOL44E6MfoeO6gzBssElz3+G3IlqQOuTgtpOuFMEr19cxBN1f yfaTT5ng7HotM7eLzgq60A6X5Yygs1Kfijhw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 11 Oct 2017 19:23:52 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 11 Oct 2017 19:22:59 -0700 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= , References: <20171006124626.d6463wglfpagqhsu@hephaistos.amsuess.com> <5D407B1A-2400-4086-AE73-FD56B0C03E6F@mnot.net> <20171011164758.73n7ytnniqzyaft2@hephaistos.amsuess.com> In-Reply-To: <20171011164758.73n7ytnniqzyaft2@hephaistos.amsuess.com> Date: Wed, 11 Oct 2017 19:23:49 -0700 Message-ID: <001901d34301$255a9cc0$700fd640$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJqvtJx5n5fSnZHmxh6hPcWZngw0gExiG1eAcnIHZuhmKjAUA== X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [core] RFC5988bis vs RFC6690: interpretation of anchors X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 02:24:04 -0000 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Christian = Ams=FCss > Sent: Wednesday, October 11, 2017 9:48 AM > To: core@ietf.org WG (core@ietf.org) ; Mark Nottingham > > Subject: Re: [core] RFC5988bis vs RFC6690: interpretation of anchors >=20 > Hello Mark, >=20 > thanks for your fast and unambiguous response. >=20 > On Mon, Oct 09, 2017 at 11:28:44AM -0700, Mark Nottingham wrote: > > That's not ambiguous at all. 3986 only uses "context" casually; the > > formal term is defined as "base uri" in 5.1. > > > > When introducing what links are, 5988 says: > > > > """ > > A link can be viewed as a statement of the form "{context IRI} has a > > {relation type} resource at {target IRI}, which has {target > > attributes}". > > """ > > > > How does this countenance that reading? >=20 > That sentence doesn't; it's the informal use of context that did, when read > without keeping normative and non-normative language apart stictly. >=20 > At any rate, with the algorithm in 5988bis the intention is fixed, and we'll > need to think of how to resolve the resulting discrepancies with > 6690 and its users. >=20 > So, hello working group, >=20 > > > * 6690 section 2.1 explains that [...] if an anchor is set, the > > > target reference is resolved relative to the resolved anchor. > > > > That's diverging from 5988. >=20 > So how do we go about this? >=20 > If CoRE insists on sticking with the divergence it's fine with me, but = I assume > it doesn't. And if so, we'd need to state that explicitly in resource-directory, > and I'd prefer not to only start this discussion when it goes through = late > review stages. >=20 > Otherwise, given that we can't change that in an erratum, the next = logical > step would be a 6690bis document that makes a clear cut and changes = the > link semantics to the 5988 ones. Given the proposed definition of the "at" parameter, I think we should = kill the current usage of anchor and figure out exactly how we want to use = "at" and "con" to do this instead. For that purpose, I think that we need to = do an update of RFC 6690 to correct this algorithm and provide one using = one or both of the other parameters. It is not clear to me that 'at' and 'con' = are both needed so that should be discussed as well. Another thing that is part of this which I have not yet fund, is the question of what the context should be when things are pulled from the /.well-known/core location. The context according to the defined = algorithm would include that path and I do not believe that is what anybody things should be happening. Jim >=20 > The published documents that reference 6690, from my brief survey, do = not > really touch on the semantics of links; the one affected most deeply = is > RFC7089, and given it is used in an HTTP context together with Link headers, I > consider it unlikely that applications actually implement the = diverging > behavior of 6690 for link-format bodies. The document does give = special > rules for the links' interpretation, though, which use Context as a = formal > term. >=20 > > > In resource-directory, we *will* need to give examples of what a > > > link looks like when served from a different URI, and to give > > > guidance as to how a directory should parse the links -- so what = can we > assume? > > > > I'm not sure what you're looking for here. >=20 > Guidance from the working group as to which direction this will take, = and > how this topic can come to a conclusion without holding up resource- > directory for cycles. >=20 > Thanks > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Thu Oct 12 00:28:47 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70943133052 for ; Thu, 12 Oct 2017 00:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 20QoueYMz-7Z for ; Thu, 12 Oct 2017 00:28:44 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6714B132F3F for ; Thu, 12 Oct 2017 00:28:44 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 4676A47877; Thu, 12 Oct 2017 09:28:42 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 2DCE936; Thu, 12 Oct 2017 09:28:39 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id DEEED3A; Thu, 12 Oct 2017 09:28:38 +0200 (CEST) Received: (nullmailer pid 2128 invoked by uid 1000); Thu, 12 Oct 2017 07:28:38 -0000 Date: Thu, 12 Oct 2017 09:28:38 +0200 From: 'Christian =?iso-8859-1?Q?Ams=FCss'?= To: Jim Schaad Cc: core@ietf.org Message-ID: <20171012072837.rflwdgivs5qnse7g@hephaistos.amsuess.com> References: <20171006124626.d6463wglfpagqhsu@hephaistos.amsuess.com> <5D407B1A-2400-4086-AE73-FD56B0C03E6F@mnot.net> <20171011164758.73n7ytnniqzyaft2@hephaistos.amsuess.com> <001901d34301$255a9cc0$700fd640$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j4w2q4nlshskodpy" Content-Disposition: inline In-Reply-To: <001901d34301$255a9cc0$700fd640$@augustcellars.com> User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [core] RFC5988bis vs RFC6690: interpretation of anchors X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 07:28:46 -0000 --j4w2q4nlshskodpy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jim, On Wed, Oct 11, 2017 at 07:23:49PM -0700, Jim Schaad wrote: > Given the proposed definition of the "at" parameter, I think we should ki= ll > the current usage of anchor and figure out exactly how we want to use "at" > and "con" to do this instead. I was thinking more along the lines of a minimal patch (given that con=3D, as of now, is a purely RD internal attribute without any effect on link-format parsing or interpretation, short of under-the-rug corner cases we try to avoid). Of course, using con=3D/at=3D (from my last talk with protocol-negotiation authors, I think that we can have con=3D everywhere in the output) to explicitly set a base URI at the metadata level would have its merits. But I don't quite see how this can be done in a compatible way, and how not every link-format request then means that .well-known/core has to be available in parsed form too to see whether there's a con in the metadata. (Or would a `<>;rel=3Dself;con=3D"x"` have the same effect as an HTML , inline setting the Base URI?) I would like that, and be happy to discuss it, (for example because it could save quite some message size in RD resource lookups), but am conflicted because anything that's not a re-publication with fixes applied has the potential for holding up RD even further. > Another thing that is part of this which I have not yet fund, is the > question of what the context should be when things are pulled from the > /.well-known/core location. The context according to the defined algorit= hm > would include that path and I do not believe that is what anybody things > should be happening. Yes, that's the second ting a 6690bis should solve. I think that it's practically not so pressing because the ambiguity is easy to work around by all links in .w-k/c starting with at least a slash (which they usually do) and because the hosts relation is not used too much, but still we should have an answer to that. Thanks for your response Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --j4w2q4nlshskodpy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlnfGaIACgkQOY0REtOk veEfQA/9H9DnoOFmGVQW8U35U547DRUdaTQZnsJaXbTRXSiNd8Qld76PhH969d6V vQQz3gCbGqOp9eTJO/XtLDMbTSwE6RMYvEVyiJ392XgWerCT4z8sHBL9jPsCW6w6 F82oiob0CTjCgSEYCC24ufM3MkRSLIeGPxI9A69+Rr5ecV/PSY+o1k6Qpy9CHNN6 BEaACdBFRmKpd9rNrNYzAY8z7Y6nOXeYbHuOSR38YWT5aJwIecn/J/ggdGxLYpdJ 59Q8Vt4bI6rqWIdV8oD7FpJH+ICazavBj3RdcziCNl4FBpOTyNIEPFAL0/nMxige mggUhWjE/+swWw4qJz0MI8QBD1zDMJpj8+gzlaHsIR+O7GTtiHbdRlBt6iJUKDoh riocxZ/eX1Zm+W0F6hVqClGEbAm/QMdqlu4hIARSxYwpeEUXV/D5Yp/QbXwZlKDe 29safmxroh2e2GOjihs+0CNXNjrIijowAAErgBRmpgkitpRIBZBW6eELNgazi3jg qFsKj/LAtuPCbZBSkPObU6qYu60jOEfmcrqHpDTwu1BQPr0eLSyI9BEAq7jkWAl6 VnxZ0Krya/sWCGu0OhFcD7M7Tpa0UZKgzoHBcuK0dZsUP9AP3npPP9HrOObN7OYK tihNFv/c7e/scyml84FNakusvhbQDgDSU1krWDqevGFlwiU5dlE= =oNXq -----END PGP SIGNATURE----- --j4w2q4nlshskodpy-- From nobody Thu Oct 12 04:36:03 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1921013301F; Thu, 12 Oct 2017 04:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ErWz1HVyE5i4; Thu, 12 Oct 2017 04:35:58 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5AE132C2A; Thu, 12 Oct 2017 04:35:58 -0700 (PDT) X-AuditID: c1b4fb3a-dffff70000006897-43-59df539cfdf0 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 07.FE.26775.C935FD95; Thu, 12 Oct 2017 13:35:56 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.166]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Thu, 12 Oct 2017 13:35:55 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "draft-ietf-core-object-security@ietf.org" CC: "core@ietf.org" Thread-Topic: Review draft-ietf-core-object-security-05 Thread-Index: AdNCDxflBrT2UulyTbeReHGbxp5RNgBPzWSA Date: Thu, 12 Oct 2017 11:35:55 +0000 Message-ID: References: <011901d34257$27b8d950$772a8bf0$@augustcellars.com> In-Reply-To: <011901d34257$27b8d950$772a8bf0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-ID: <2CAA375CE3DC294FAF04DEDB263B2A0A@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2J7oO6c4PuRBh3NShb73q5ntpj27wyL xerp39kcmD02zpnO5rFkyU+mAKYoLpuU1JzMstQifbsErozL2x+yFfwIqVh04gNbA+ODoC5G Tg4JAROJ6Q9+s3YxcnEICRxhlNj08yYThLOEUeL2yotsIFVsAi4SDxoegSVEBJoYJR7P7WMG STALKEscn32YFcQWFjCT2DR5LwuILSJgLvGxoZsVwjaSmPL3E9AgDg4WAVWJY2eVQMK8AhYS L541gs0XErCX+H7tNiOIzSngINGx9wjYGEYBMYnvp9YwQawSl7j1ZD4TxNUCEkv2nGeGsEUl Xj7+B7ZKVEBPYm9POxtEXFHi46t9jCBrmQU0Jdbv0ocYYy1xbs4GqJGKElO6H7JDnCMocXLm E5YJjOKzkGybhdA9C0n3LCTds5B0L2BkXcUoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGHcH t/y22sF48LnjIUYBDkYlHl53yfuRQqyJZcWVuYcYJTiYlUR4DSyBQrwpiZVVqUX58UWlOanF hxilOViUxHkd9l2IEBJITyxJzU5NLUgtgskycXBKNTBO1WDSMIj9ylXx+Wz5jbMnhHn7dRSX By7c3M64QnzbH/7FjxjXfn24TVyUyefK/lDrg+4vNuz16dhw1eytw5Fiy+nr7zclS9TtvPvg cvAchvdy697amqfFXWX4ubEqoYL1ysp7haxJG6y3zhEKVZ8ttOHC00tHBJL7Njl+OPIsQOTC dxvvfSe3KbEUZyQaajEXFScCAIrCiE63AgAA Archived-At: Subject: Re: [core] Review draft-ietf-core-object-security-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 11:36:01 -0000 SGkgSmltLA0KDQpNYW55IHRoYW5rcyBmb3IgdGhlIHJldmlldy4NCg0KQXMgbWVudGlvbmVkIGlu IHRoZSBhbm5vdW5jZW1lbnQgdGhpcyB2ZXJzaW9uIGNvbXBpbGVzIGFsbCB0aGUgcHJvcG9zZWQN CmZpbmFsIGNoYW5nZXMsIGFuZCwgYWRtaXR0ZWRseSwgdGhlIHJhdGlvbmFsZSBmb3IgYWxsIHBy b3Bvc2FscyBoYXMgbm90DQpiZWVuIGRpc2N1c3NlZCBpbiBkZXRhaWwgc28gaXQgaXMgZ29vZCB0 aGF0IHdlIGNhbiBkbyB0aGF0IG9uIHRoZSBtYWlsaW5nDQpsaXN0IG5vdy4gDQoNCg0KQW5zd2Vy cyBpbmxpbmUgYW5kIGEgY291cGxlIG9mIHF1ZXN0aW9ucyBiYWNrLiBTb21lIG9mIHRoZSBjb21t ZW50cyBhcmUNCmFscmVhZHkgYWRkcmVzc2VkIGluIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdn L29zY29hcA0KDQoNCk9uIDIwMTctMTAtMTEgMDg6MDYsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1 c3RjZWxsYXJzLmNvbT4gd3JvdGU6DQoNCj5UaGlzIHVwZGF0ZSBoYWQgYSBmZXcgdGhpbmdzIHRo YXQgY2FtZSBpbiBvdXQgb2YgbGVmdCBmaWVsZCBhbmQgbWF5YmUgYQ0KPmNvdXBsZSBvZiB0aGVt IHNob3VsZCBoYXZlIHN0YXllZCB0aGVyZS4NCj4NCj4wLiAgRG9jdW1lbnQgc3RydWN0dXJlIC0g ZGVmaW5lIGEgc2hvcnQgbmFtZSB0byBiZSB1c2VkIGFzIHRoZSBoZWFkZXIgb2YNCj5lYWNoIHBh Z2UuDQoNCkRvbmUuDQoNCj4NCj4xLiAgSW50cm9kdWN0aW9uOiAgSSBhbSBub3Qgc3VyZSB3aGF0 IGlzIG1lYW50IGJ5IGEgIm5vbi1lbXB0eSBtZXNzYWdlIi4NCj5UaGlzIGNhbm5vdCByZWZlciB0 byB0aGUgcGF5bG9hZCBiZWluZyBlbXB0eSwgc28gSSBhbSB1bmNsZWFyIHdoYXQgaXMNCj5tZWFu dA0KPmhlcmUuDQoNCiJFbXB0eSBNZXNzYWdl4oCdIGlzIGFjdHVhbGx5IGRlZmluZWQgaW4gUkZD NzI1Mi4gSSBjYXBpdGFsaXNlZCDigJxFbXB0eeKAnSBmb3INCmNsYXJpdHkuDQoNCj4NCj4yLiAg U2VjdGlvbiAyIC0gSSBkaXNsaWtlIHRoZSBmYWN0IHRoYXQgeW91IGFyZSBtb3ZpbmcgdGhlIGJ5 dGUgb2YgZmxhZ3MNCj5mcm9tIHRoZSBib2R5IHRvIHRoZSBvcHRpb24uICBJIHdhbnQgdGhlIGZs YWdzIG5leHQgdG8gdGhlIGRhdGEgdGhhdCBJIGFtDQo+ZWl0aGVyIGFzc2VtYmxpbmcgb3IgZGlz LWFzc2VtYmxpbmcgYW5kIG5vdCBpbiBhIHRvdGFsbHkgZGlmZmVyZW50DQo+bG9jYXRpb24uDQo+ SWYgeW91IHRoaW5rIHRoYXQgdGhlIG9wdGlvbiBpcyBnb2luZyB0byBoYXZlIG1vcmUgdGhhbiBv bmUgdmFsdWUsIHRoZW4gaXQNCj5zaG91bGQgZWl0aGVyIGhhdmUgaXRzIG93biBmbGFncyBvciBh IGRlZmluZWQgc3RydWN0dXJlLiBQbGVhc2UgbW92ZSBpdA0KPmJhY2sNCj51bmxlc3MgeW91IGhh dmUgYSBSRUFMTFkgZ29vZCBjYXNlIGFuZCBhcmUgd2lsbGluZyB0byBwcm92ZSBpdC4NCg0KWWVz LCB0aGlzIHdhcyBvbmUgdGhpbmcgdGhhdCB3YXNu4oCZdCBkaXNjdXNzZWQuIEhlcmUgaXMgdGhl IHJlYXNvbjoNCg0KVGhlIGVuY3J5cHRpb24gb2YgQ29kZSBsZWFkIHRvIHRoZSBzaW1wbGlmaWNh dGlvbiB0aGF0IHRoZSBjb21wcmVzc2VkIENPU0UNCm9iamVjdCBpcyBub3cgYWx3YXlzIHRyYW5z cG9ydGVkIGluIHRoZSBDb0FQIHBheWxvYWQgb2YgdGhlIE9TQ09SRQ0KbWVzc2FnZS4gSGVuY2Ug dGhlIE9iamVjdC1TZWN1cml0eSBvcHRpb24gd291bGQgaGF2ZSBtZXJlbHkgYmVjb21lIGFuDQpp bmRpY2F0b3Igb2Ygd2hldGhlciB0aGlzIHdhcyBhbiBPU0NPUkUgbWVzc2FnZSBvciBub3QuIEJ1 dCBDb0FQIG9wdGlvbnMNCmhhcyBhIGJ1aWx0LWluIGxlbmd0aCB2YWx1ZSwgYW5kIHBhcnQgb2Yg dGhlIGNvbXByZXNzZWQgQ09TRSBPYmplY3QgYWxzbw0KY29udGFpbnMgbGVuZ3RoIHZhbHVlcyBv ZiB0aGUgY29udGV4dCBwYXJhbWV0ZXJzLCBzbyB3ZSBjb3VsZCBzYXZlIGFub3RoZXINCmJ5dGUg YnkgcmVtb3Zpbmcgb25lIGxlbmd0aCBpbmRpY2F0b3IgZnJvbSB0aGUgY29tcHJlc3NlZCBDT1NF IC0gdGhhdCBvZg0KdGhlIGtpZCAtIGFuZCBwbGFjaW5nIHRoZSBraWQgaW4gdGhlIG9wdGlvbi4g SW5zdGVhZCBvZiBqdXN0IG1vdmluZyB0aGUNCmtpZCwgd2UgbW92ZWQgdGhlIGtpZCBhbmQgZXZl cnl0aGluZyBiZWZvcmUgdGhlIGtpZCAtIGkuZS4gYWxzbyB0aGUgZmxhZw0KYnl0ZSAtIGludG8g dGhlIG9wdGlvbiwgc28gdGhlIGNvbXByZXNzZWQgQ09TRSBiZWNhbWUgYSBjb25jYXRlbmF0aW9u IG9mDQpvcHRpb24gYW5kIHBheWxvYWQuDQoNCklmIHBlb3BsZSB0aGlua3MgdGhpcyB1bmR1bHkg Y29tcGxpY2F0ZXMgcHJvY2Vzc2luZyB3ZSByZXZlcnQgYmFjay4NCkFub3RoZXIgYWx0ZXJuYXRp dmUgaXMgdG8ga2VlcCB0aGUga2lkIGluIHRoZSBvcHRpb24gYW5kIGhhdmUgZXZlcnl0aGluZw0K ZXhjZXB0IHRoZSBraWQgaW4gdGhlIHBheWxvYWQuIFRoYXQgd2F5IHRoZSBmbGFnIGJ5dGUgY29t ZXMgZmlyc3QgaW4gdGhlDQpwYXlsb2FkLCBidXQgeW91IHN0aWxsIG5lZWQgdG8gbG9vayBpbiB0 aGUgb3B0aW9uIHRvIGdldCB0aGUga2lkLg0KDQpXaGF0IGlzIHRoZSBwcmVmZXJlbmNlPw0KDQph LiBDaGFuZ2UgYmFjayB0byBjb21wcmVzc2VkIENPU0UgaW4gcGF5bG9hZA0KYi4gSGF2ZSBqdXN0 IHRoZSBraWQgaW4gdGhlIG9wdGlvbg0KYy4gS2VlcCBpdCBhcyBjdXJyZW50bHkgc3BlY2lmaWVk IHdpdGggdGhlIGNvbXByZXNzZWQgQ09TRSBvYmplY3QgZXF1YWwgdG8NCnRoZSBjb25jYXRlbmF0 aW9uIG9mIG9wdGlvbiBhbmQgcGF5bG9hZA0KDQoNCj4NCj4zLiAgU2VjdGlvbiAzLjEgLSBJIGRv IG5vdCB1bmRlcnN0YW5kIHdoeSB5b3UgYXJlIG1ha2luZyB0aGUgU2VuZCBJRCBhbg0KPmludGVn ZXIgcmF0aGVyIHRoYW4gYSBieXRlIHN0cmluZy4gIFRoZXJlIGFyZSBhIGNvdXBsZSBvZiBpc3N1 ZXMgd2l0aA0KPnRoaXMuDQo+Rmlyc3QgaXQgaXMgdGhvdWdodCBvZiBhcyBhIGJ5dGUgc3RyaW5n IGV2ZXJ5d2hlcmUgdGhhdCBpdCBpcyBjdXJyZW50bHkNCj5wYXNzZWQgYXJvdW5kIC0gaW4gQ09T RSBhbmQgaW4gQUNFLiAgU2Vjb25kbHksIGl0IGRlY3JlYXNlcyB0aGUgbnVtYmVyIG9mDQo+aWRz IHRoYXQgYXJlIHBvc3NpYmxlIGFzIGgnMDEnIGFuZCBoJzAwMDEnIGFyZSBkaXN0aW5jdCB3aGls ZSAxIGFuZCAxIGFyZQ0KPm5vdC4gDQoNCkluIG9yZGVyIHRvIGVhc2lseSB2ZXJpZnkgdW5pcXVl bmVzcyBvZiAoa2V5LCBub25jZSkgcGFpcnMgaW4gdGhlIGN1cnJlbnQNCnNldHVwIHdpdGggYSBj b21tb24gSVYgYW5kIHRoZSByZXVzZSBvZiBub25jZSBpbiByZXNwb25zZXMgKGFsc28gaW4gdGhl DQpncm91cCBjb21tdW5pY2F0aW9uIHNldHRpbmcpIHRoZSBTZW5kZXIgSUQgaXMgbm93IGluY2x1 ZGVkIGluIHRoZSBub25jZQ0KZ2VuZXJhdGlvbi4gV2l0aCB0aGlzIGNvbnN0cnVjdGlvbiwgYWxs IG5vbmNlcyBjb21pbmcgZnJvbSBhIHBhcnRpY3VsYXINCnNlbmRlciBoYXMgYSBjZXJ0YWluIHBy ZWZpeCwgd2hpY2ggd2lsbCBub3QgY29pbmNpZGUgd2l0aCBhIG5vbmNlDQpnZW5lcmF0ZWQgYnkg YW5vdGhlciBzZW5kZXIuDQoNClRoZSB0d28gYnl0ZSBzdHJpbmdzIHlvdSBtZW50aW9uIGFyZSBk aXN0aW5jdCwgYnV0IHdvdWxkIGFsc28gbmVlZCB0byBiZQ0KbWFwcGVkIHRvIGRpc3RpbmN0IGJ5 dGUgc3RyaW5ncyBvZiBmaXhlZCBsZW5ndGggaW4gb3JkZXIgdG8gZG8gdGhlIFhPUg0Kd2l0aCB0 aGUgY29tbW9uIElWLiBXaXRoIFNlbmRlciBJRCBiZWluZyBhbiBpbnRlZ2VyIHRoZSB1bmlxdWVu ZXNzDQpwcm9wZXJ0eSBpcyBlYXNpZXIgdG8gZXN0YWJsaXNoLiBTdGlsbCB0aGUgU0lEIGlzIGNv bnZlcnRlZCBpbnRvIGEgQ0JPUg0KYnl0ZSBzdHJpbmcgd2hlbiB1c2VkLiBJIGFkZGVkIHRleHQg b24gdGhhdC4NCg0KDQo+DQo+NC4gU2VjdGlvbiAzLjEtIEkgYW0gbm90IHN1cmUgdGhhdCB0aGUg d29yZCAnaW50ZXJjaGFuZ2UnIGluIHRoZSBsYXN0DQo+cGFyYWdyYXBoIGlzIHdoYXQgeW91IHdh bnQgdG8gdXNlLiAgVGhpcyBkb2VzIG5vdCByZWFkIGFzIHByb3BlciBFbmdsaXNoDQo+d2hlbiBJ IHJlYWQgaXQuICAiRW5kcG9pbnRzIGNhbiBvcGVyYXRvciBpbiBlaXRoZXIgb3IgYm90aCByb2xl cyBhcyBjbGllbnQNCj5hbmQgc2VydmVyIGFuZCB1c2UgdGhlIHNhbWUgc2VjdXJpdHkgY29udGV4 dCBmb3IgdGhvc2Ugcm9sZXMuIg0KDQpEb25lDQoNCg0KPg0KPjUuIFNlY3Rpb24gMy4yLjEgLSBJ biB0aGUgc3RydWN0dXJlIGluZm8gLSB5b3UgaGF2ZSBpZCBhcyBhIGJzdHIsIGJ1dCBpdA0KPndh cw0KPmRlZmluZWQgYXMgYW4gaW50ZWdlciBwcmV2aW91c2x5LiAgWW91IG5lZWQgdG8gaGFybW9u aXplIHRoaXMuDQo+QWRkaXRpb25hbGx5LCBpdCBzaG91bGQgYmUgImFsZyA6IGludCAvIHRzdHIs IiB0byBtYXRjaCB0aGUgZGVmaW5pdGlvbiBvZg0KPmFuDQo+YWxnb3JpdGhtIGlkZW50aWZpZXIg aW4gQ09TRS4gICBBbHNvIHNlY3Rpb24gNS4zDQoNCkRvbmUNCg0KPg0KPjYuIFNlY3Rpb24gMy4z IC0gcy8xLCBGb3IgQUVTLzEsIGZvciBBRVMvDQoNCkRvbmUNCg0KPg0KPjcuICBTZWN0aW9uIDMu MyAtIHlvdSBoYXZlIGEgcmVxdWlyZW1lbnQgaW4gdGhlIGxhc3Qgc2VudGVuY2UgYWJvdXQgdGhl DQo+bGVuZ3RoIG9mIHNlbmRlciBJRHMuICBIb3cgc2hvdWxkIHRoaXMgYmUgZW5mb3JjZWQgZ2l2 ZW4gdGhhdCBJRHMgYXJlDQo+aW50ZWdlcnMsIGRvZXMgdGhpcyBpbXBseSBhIHJlc3RyaWN0aW9u IG9uIHRoZSByYW5nZSBvZiBpbnRlZ2VycyB0byBiZQ0KPnVzZWQ/DQoNClllcywgdGhlIGludGVu dCBpcyB0aGF0IHJhbmRvbSBTZW5kZXIgSURzIE1VU1QgYmUgZ2VuZXJhdGVkIGluIGEgbGFyZ2UN CnJhbmdlIG9mIGludGVnZXJzLiBJIG1hZGUgYW4gdXBkYXRlIHRvIGNsYXJpZnkgdGhhdC4NCg0K Pg0KPjguICBTZWN0aW9uIDQuMyAtIEkgYW0gbm90IHN1cmUgdGhhdCB0aGlzIHNlY3Rpb24gc2hv dWxkIHN0YXJ0ICJNb3N0IENvQVANCj5oZWFkZXIgZmllbGRzLi4uIiAgTG9va2luZyBhdCB0aGUg dGFibGUsIGl0IGFwcGVhcnMgdG8gYmUgYWJvdXQgNTAtNTAgYW5kDQo+dGhlIGFzc3VtcHRpb24g aXMgbmV3IGZpZWxkcyB3aWxsIHByb2JhYmx5IGJlIGludGVybmFsLiAgSSB0aGluayAnc29tZScN Cj5tYXkNCj5iZSBiZXR0ZXIuDQoNCkFjdHVhbGx5LCB0aGUgaGVhZGVyIGZpZWxkcyBhcmUgbm90 IHRoZSBvcHRpb25zIGJ1dCB0aGUgNCBieXRlcyBoZWFkZXINCmluY2x1ZGluZyB0aGluZ3MgbGlr ZSBUeXBlLCBDb2RlLCBNZXNzYWdlIElEIGV0Yy4gU28gSSBiZWxpZXZlIHRoYXQgdGhlDQpzdGF0 ZW1lbnQgaXMgdHJ1ZS4gSSBhZGRlZCB0ZXh0IG9uIHRoYXQuDQoNCg0KPg0KPjkuICBTZWN0aW9u IDUgLSBJIHdvdWxkIGxpa2UgdG8gaGF2ZSB0aGUgUGFydGlhbCBJViBoYXZlIGEgbGVuZ3RoIG9m IDEgaW4NCj50aGUgZXZlbnQgdGhhdCB0aGUgcGFydGlhbCBpdiBpcyB6ZXJvLiAgIERpdHRvIGtp ZA0KDQpUaGUgaW50ZW50IGhlcmUgaXMgdG8gc2F2ZSB0aGVzZSBieXRlcywgaXMgdGhlcmUgYW4g aXNzdWU/DQoNCg0KPg0KPjEwLiAgU2VjdGlvbiA1IC0gVGhlIHJ1bGUgb2YgdGhlIFNIQUxMIE5P VCBmb3IgUGFydGlhbCBJViB3b3JyaWVzIG1lIGZvcg0KPmdyb3VwIG1lc3NhZ2luZy4gIEl0IG1h eSBjYXVzZSBwcm9ibGVtcyB5b3UgZG9uJ3Qgd2FudC4gIFRoZXJlIGFyZSBubyByZWFsDQo+cHJv YmxlbXMsIGV4Y2VwdCBmb3Igb3B0aW1pemF0aW9uLCB0byB1c2luZyB0aGUgcmVmbGVjdGVkIFBh cnRpYWwgSVYNCj52YWx1ZS4NCj5QbGVhc2UgcmV0aGluayB0aGlzLiAgRGl0dG8ga2lkDQoNCkZv ciBncm91cCBjb21tdW5pY2F0aW9uLCB0aGUgY3VycmVudCBjb25zdHJ1Y3Rpb24gbmV2ZXIgcmVx dWlyZXMgYSBQYXJ0aWFsDQpJViBpbiB0aGUgcmVzcG9uc2UuIChUaGF0IGRyYWZ0IG5lZWRzIHRv IGJlIHVwZGF0ZWQuKSBCdXQga2lkIGlzIG5lZWRlZCBpbg0KdGhlIHJlc3BvbnNlLiANCg0KSW4g cHJldmlvdXMgdmVyc2lvbnMgb2YgdGhlIHR3byBkcmFmdHMsIHdlIGhhdmUgaGFkIG5vcm1hdGl2 ZSB0ZXh0IGluIHRoZQ0KT1NDT0FQIGRyYWZ0IHdoaWNoIHdhcyBjb250cmFkaWN0ZWQgaW4gdGhl IGNhc2Ugb2YgZ3JvdXAgT1NDT0FQLCBidXQgbWF5YmUNCml0IGlzIGJldHRlciB0byByZWxheCB0 aGUgT1NDT0FQIHNwZWNpZmljYXRpb24/DQoNCkkgbWFkZSB0aGUgZm9sbG93aW5nIGNoYW5nZSBv biBHaXRodWI6DQoNCi0ga2VlcCDigJxQYXJ0aWFsIElWIFNIQUxMIE5PVCBiZSBwcmVzZW50IGlu IHJlc3BvbnNlc+KAnQ0KLSByZXBsYWNlIGtpZCAiU0hBTEwgTk9UIGJlIHByZXNlbnQgaW4gcmVz cG9uc2Vz4oCdIHRvIOKAnE1BWSBiZSBvbWl0dGVkIGluDQpyZXNwb25zZXMiDQoNCg0KDQo+MTEu ICBTZWN0aW9uIDUuMSAtIERvZXMgdGhpcyBtZWFuIHRoYXQgdGhlIFBhcnRpYWwgSVYgaXMgbGlt aXRlZCB0bw0KPjJeKDUqOCkNCj5kaWZmZXJlbnQgdmFsdWVzPyANCg0KWWVzLg0KDQo+SWYgeW91 IGV4Y2VlZCB0aGlzIGlzIGEgbmV3IGNvbnRleHQgcmVxdWlyZWQgb3IgZG8geW91DQo+d3JhcCBv ciBzb21ldGhpbmcgZWxzZT8NCg0KTmV3IGNvbnRleHQuIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBzdGF0ZSB0aGUgbWF4aW11bSBzZXF1ZW5jZQ0KbnVtYmVyLCBJIGFkZGVkIHRleHQgYWJv dXQgbmV3IGNvbnRleHQuDQoNCg0KPg0KPjEyLiBTZWN0aW9uIDUuMSAtIHdoYXQgaXMgdGhlIHB1 cnBvc2Ugb2YgcHV0dGluZyB0aGUgSUQgb2YgdGhlIFBJVg0KPmdlbmVyYXRvcg0KPmluIHRoZSBu b25jZSB2YWx1ZT8gIFBsZWFzZSBwdXQgaW4gdGV4dCB0aGF0IHdpbGwganVzdGlmeSB0aGlzLiAg IEdpdmVuDQo+dGhhdA0KPnRoZSBrZXlzIGFyZSBkaWZmZXJlbnQsIGlzIHRoZXJlIGFueSBuZWVk IGZvciB0aGlzPw0KDQpBcyBkaXNjdXNzZWQgYWJvdmUsIHRoaXMgbWFrZXMgaXQgZWFzeSB0byB2 ZXJpZnkgdGhlIChrZXksIG5vbmNlKQ0KdW5pcXVlbmVzcy4NCg0KDQo+DQo+MTMuIFNlY3Rpb24g NS4xIC0gUGxlYXNlIHVzZSBhIGRpZmZlcmVudCBzeW1ib2wgaW4gdGhlIGZpZ3VyZSB0aGFuICss IHRoaXMNCj5jb3VsZCBiZSByZWFkIGFzIGFkZGl0aW9uIHJhdGhlciB0aGFuIHhvci4NCg0KRG9u ZQ0KDQo+DQo+MTQuICBTZWN0aW9uIDUuMyAtIFlvdSBuZWVkIGEgcnVsZSBmb3Igb3B0aW9ucyBm b3IgZGVhbGluZyB3aXRoIGEgcmVwZWF0ZWQNCj5vcHRpb24uDQoNCg0KV2h5IGlzIHJlcGVhdGVk IENsYXNzIEkgb3B0aW9ucyBhbiBpc3N1ZT8NCg0KDQo+DQo+MTUuICBTZWN0aW9uIDYuMSAtIHMv cmVxdWVzdCdzIElEL3JlcXVlc3RvcidzIElELw0KDQpEb25lIA0KDQo+DQo+MTYuIFNlY3Rpb24g Ny40IHN0ZXAgOCAtIEl0IHdvdWxkIGFwcGVhciB0aGF0IGlmIHRoZXJlIGlzIGFuIGlubmVyIG9w dGlvbg0KPndoaWNoIGlzIHByZXNlbnQgb24gdGhlIG91dGVyIG1lc3NhZ2UgYnV0IG5vdCBwcmVz ZW50IG9uIHRoZSBpbm5lcg0KPm1lc3NhZ2UsDQo+dGhlbiBpdCB3b3VsZCBub3QgYmUgcmVtb3Zl ZC4gIElzIHRoYXQgd2hhdCBpcyBkZXNpcmVkPw0KDQoNCkl0IHdvdWxkIGFscmVhZHkgYmUgcmVt b3ZlZCBpbiBzdGVwIDI6DQoNCuKAnDIuIERpc2NhcmQgdGhlIG1lc3NhZ2UgQ29kZSBhbmQgYWxs IG5vbi1zcGVjaWFsIENsYXNzIEUgb3B0aW9ucyBmcm9tIHRoZQ0KbWVzc2FnZS4iDQoNCg0KDQo+ DQo+MTcuICBTZWN0aW9uIDguMyAtIGlzIHRoZXJlIGEgc3BlY2lmaWMgZXJyb3IgdG8gcmV0dXJu IGhlcmUsIG9yIGlzIGp1c3QNCj50aGUNCj4iY2FuJ3QgZmluZCBhIGtpZCIgZXJyb3I/ICBQbGVh c2UgZG9jdW1lbnQuDQoNCkkgYWRkZWQgYSByZWZlcmVuY2UgdG8gdGhlIHByb2Nlc3Npbmcgc3Rl cHMgb2YgdmVyaWZ5aW5nIHRoZSByZXF1ZXN0IHdoaWNoDQpzaG91bGQgY2FwdHVyZSBhbGwgY2Fz ZXMuDQoNCg0KDQpHw7ZyYW4NCg0K From nobody Thu Oct 12 09:50:14 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B2A13454B for ; Thu, 12 Oct 2017 09:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 nP7PFremMsge for ; Thu, 12 Oct 2017 09:50:10 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1968C13454E for ; Thu, 12 Oct 2017 09:50:06 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 64217479B2 for ; Thu, 12 Oct 2017 18:50:05 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id D3C3136 for ; Thu, 12 Oct 2017 18:50:04 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8EE7419 for ; Thu, 12 Oct 2017 18:50:04 +0200 (CEST) Received: (nullmailer pid 12996 invoked by uid 1000); Thu, 12 Oct 2017 16:50:03 -0000 Date: Thu, 12 Oct 2017 18:50:03 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "core@ietf.org WG (core@ietf.org)" Message-ID: <20171012165003.ui35b2bdcsypa42p@hephaistos.amsuess.com> References: <20171006124626.d6463wglfpagqhsu@hephaistos.amsuess.com> <5D407B1A-2400-4086-AE73-FD56B0C03E6F@mnot.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="phs3agmmlgiue4tn" Content-Disposition: inline In-Reply-To: <5D407B1A-2400-4086-AE73-FD56B0C03E6F@mnot.net> User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [core] RFC5988bis vs RFC6690: interpretation of anchors X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 16:50:13 -0000 --phs3agmmlgiue4tn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Working Group, On Mon, Oct 09, 2017 at 11:28:44AM -0700, Mark Nottingham wrote: > That's diverging from 5988.=20 =66rom the last resource-directory meeting, the takeaway is that RFC6690 link-format serialization already does some other things differently than Link-Headers, and that having the target resolve relative to the anchor is a practical thing to do in the context of standalone documents. The next version of resource-directory will be more explicit about how relative references are resolved into URIs, and possibly lining out the differences to Link headers in preparation for a more explicit 6690bis, without any urgency for such a document. I'm not convinced personally that it's the best way to go about it, but I see that it makes some things easier (so I'd hapily participating in any further discussion ensuing from this). Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --phs3agmmlgiue4tn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlnfnTgACgkQOY0REtOk veHJnw/+KnI0qfGFbHDh7NuH/rTFdrL3zACZPI6+MjxzpRLNwBJWxv0yu+aIR0Zx Vd2Fcyc/WqERU2xniLfR2lscSEP2a7xKLcUMXblPoP5sbfnDSwwVW5OzyWEJUENA 4EVRYxVb5gF3ktK4GfMyX5sOrVseByDbtiWwPE4hvYckvkl0d8j0ZIHRymrjtIIe 599R0LzfBnSJnliZOTaxiG9qN9ZDDgr+F0So+g3pPvdYPZCAaXCzkYghLxdjWhnY Y+dUsTpHxbaoUQU6e1YsowxS9PbVi59n+ggbb7im6ZdEWqZZj83PgLL/wjhqzNjK LIK78eRQsf5qdB3xMzYrE8rHm2NsPSyJMUxofjafLSHJlNP79G8LsDUt/xEuLdB3 AopJHMyEDyu4fjqvDtQDQ2EveNzYTxBfgelKyrFwcsPiesnAaEFQ9bESCQSSB9Dc MDfxwvHF099zq6MJs30hdP9Cs0gwd4k6qbpNBEMhLv1hvpAIbhrRZdhO7M0bHO88 t5pTgXy7mrDGelayQI9lWY/M0EcrWhum13EUS5I7cRa1mztiCsiTgTcM6lTQvsX3 qjyWxzt+88b33B6HmqKM+iwFdQ6POt/+sD8LRjWzS/13Wum1YdhWXU+8bnKHFwp6 0FXbS8lfCzQMO6x93zmmbKxjXL+uAPDm5G9QKdO8hq1U9kXH0tw= =KA+d -----END PGP SIGNATURE----- --phs3agmmlgiue4tn-- From nobody Thu Oct 12 10:32:53 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796D6133224 for ; Thu, 12 Oct 2017 10:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=augustcellars.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 Wl7IUReeEKcQ for ; Thu, 12 Oct 2017 10:32:50 -0700 (PDT) Received: from mail4.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 D758C132F8F for ; Thu, 12 Oct 2017 10:32:50 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1507829569; h=from:subject:to:date:message-id; bh=5CRvxWUzFJbSrfOu36kY6t/d28GUX33QakOmcv2MKlo=; b=VmsCcOIyNR+w371GnCFgefbbYD7yaIcIijtpxxCCbz6yBCKB8udc9q1jPQjNSLAVl7/765FDIfn PZJNbH2ydYgcR+rt9ratt3MES42f7DlJCrov5AWstJgtqXQVVn+EY1jfu7a9JtK7pvQjHACqKJ4PB uDTebDSYVao/lMfXyyPxOpgYea1CWCG9p5+YglDlqBSIjZS9bn+Bk6nLwCUz8c0Mcy7gmyo16ZIQT dbB8kLNXNrOII+Yb+0w+C8k8jUj/jv4cFjkus1lePWH/7998YusJSOMGU0KYAy1uS6SOTRrQA4uCr GraEHiqY1wyTSbjcS3lKqRxWe8AS3sGcxyXw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 12 Oct 2017 10:32:48 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 12 Oct 2017 10:31:53 -0700 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= CC: References: <20171006124626.d6463wglfpagqhsu@hephaistos.amsuess.com> <5D407B1A-2400-4086-AE73-FD56B0C03E6F@mnot.net> <20171011164758.73n7ytnniqzyaft2@hephaistos.amsuess.com> <001901d34301$255a9cc0$700fd640$@augustcellars.com> <20171012072837.rflwdgivs5qnse7g@hephaistos.amsuess.com> In-Reply-To: <20171012072837.rflwdgivs5qnse7g@hephaistos.amsuess.com> Date: Thu, 12 Oct 2017 10:32:43 -0700 Message-ID: <007d01d34380$1dce98b0$596bca10$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJqvtJx5n5fSnZHmxh6hPcWZngw0gExiG1eAcnIHZsCW1rWfAHOrvitoXhXPOA= X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [core] RFC5988bis vs RFC6690: interpretation of anchors X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 17:32:52 -0000 Greetings Christian, > -----Original Message----- > From: 'Christian Ams=FCss' [mailto:c.amsuess@energyharvesting.at] > Sent: Thursday, October 12, 2017 12:29 AM > To: Jim Schaad > Cc: core@ietf.org > Subject: Re: [core] RFC5988bis vs RFC6690: interpretation of anchors >=20 > Hello Jim, >=20 > On Wed, Oct 11, 2017 at 07:23:49PM -0700, Jim Schaad wrote: > > Given the proposed definition of the "at" parameter, I think we = should > > kill the current usage of anchor and figure out exactly how we want = to use > "at" > > and "con" to do this instead. >=20 > I was thinking more along the lines of a minimal patch (given that = con=3D, as of > now, is a purely RD internal attribute without any effect on = link-format > parsing or interpretation, short of under-the-rug corner cases we try = to > avoid). >=20 > Of course, using con=3D/at=3D (from my last talk with = protocol-negotiation > authors, I think that we can have con=3D everywhere in the output) to explicitly > set a base URI at the metadata level would have its merits. > But I don't quite see how this can be done in a compatible way, and = how not > every link-format request then means that .well-known/core has to be > available in parsed form too to see whether there's a con in the = metadata. > (Or would a `<>;rel=3Dself;con=3D"x"` have the same effect as an HTML = href=3D"x">, inline setting the Base URI?) My problem with this approach is that, given what I understand how "at" = to be defined, it should just replace "con" completely. Therefore starting = to use con and then making it go away seems to me to be a bad idea. Even = if we just define the use of "at" with one item and then allow or it later to become two items seems to me to be a better approach. Jim >=20 > I would like that, and be happy to discuss it, (for example because it could > save quite some message size in RD resource lookups), but am = conflicted > because anything that's not a re-publication with fixes applied has = the > potential for holding up RD even further. >=20 > > Another thing that is part of this which I have not yet fund, is the > > question of what the context should be when things are pulled from = the > > /.well-known/core location. The context according to the defined > > algorithm would include that path and I do not believe that is what > > anybody things should be happening. >=20 > Yes, that's the second ting a 6690bis should solve. I think that it's practically > not so pressing because the ambiguity is easy to work around by all = links in > .w-k/c starting with at least a slash (which they usually do) and = because the > hosts relation is not used too much, but still we should have an = answer to > that. >=20 > Thanks for your response > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Thu Oct 12 11:08:04 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E13134224; Thu, 12 Oct 2017 11:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=augustcellars.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 oYt3EHa9tfsN; Thu, 12 Oct 2017 11:08:00 -0700 (PDT) Received: from mail4.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 5DAE1133187; Thu, 12 Oct 2017 11:08:00 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1507831677; h=from:subject:to:date:message-id; bh=9sWF6uKSAxiGYKhVbzUcG5IfxEGHC2LgEquTjWE8mP0=; b=YfyLChO8rIW1d+3hSp/mbHCC5oiNkdbzk6Rss2/oYVZ1m6Leeh54uF6SNoZR8SLSdEvVIwvqSdj ax8IL29u1mvRuTOuPBqbgTWAsAP3+ann5jfY8rPFet90m4HPDEcYFK+UoGGNmXT8Z3SU7v31fsjN9 gV6A7z7r9ABC+KRMgK8bE0H+tbmy85FP5LxSecAxeuy9B15fP0rEYbQyunBIrxCkqk17EGAZ5F/sh bGBqyrLFYp6tmc7dnLjqlXG4lRAQJJIwcieDfDZjNznlKXehhCAMNnVq3I9gYYJ6WOX4XIOBJRqTf 7LVpcjPfpTXLlAEzb1TYpxT8w5iyMgWz1sKw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 12 Oct 2017 11:07:57 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 12 Oct 2017 11:07:00 -0700 From: Jim Schaad To: =?utf-8?Q?'G=C3=B6ran_Selander'?= , CC: References: <011901d34257$27b8d950$772a8bf0$@augustcellars.com> In-Reply-To: Date: Thu, 12 Oct 2017 11:07:50 -0700 Message-ID: <008501d34385$060c5820$12250860$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQL1P0kokeO6eLldy2El08GhLgI49gItREfioIsYMHA= X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [core] Review draft-ietf-core-object-security-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 18:08:03 -0000 See inline - I have trimmed some items. > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Thursday, October 12, 2017 4:36 AM > To: Jim Schaad ; draft-ietf-core-object- > security@ietf.org > Cc: core@ietf.org > Subject: Re: Review draft-ietf-core-object-security-05 >=20 > Hi Jim, >=20 > Many thanks for the review. >=20 > As mentioned in the announcement this version compiles all the = proposed > final changes, and, admittedly, the rationale for all proposals has = not been > discussed in detail so it is good that we can do that on the mailing = list now. >=20 >=20 > Answers inline and a couple of questions back. Some of the comments = are > already addressed in https://github.com/core-wg/oscoap >=20 >=20 > On 2017-10-11 08:06, "Jim Schaad" wrote: >=20 > >This update had a few things that came in out of left field and maybe = a > >couple of them should have stayed there. > > > > > >1. Introduction: I am not sure what is meant by a "non-empty = message". > >This cannot refer to the payload being empty, so I am unclear what is > >meant here. >=20 > "Empty Message=E2=80=9D is actually defined in RFC7252. I capitalised = =E2=80=9CEmpty=E2=80=9D for > clarity. >=20 Consider a reference given that it is important people get this part = right. > > > >2. Section 2 - I dislike the fact that you are moving the byte of > >flags from the body to the option. I want the flags next to the data > >that I am either assembling or dis-assembling and not in a totally > >different location. > >If you think that the option is going to have more than one value, = then > >it should either have its own flags or a defined structure. Please = move > >it back unless you have a REALLY good case and are willing to prove = it. >=20 > Yes, this was one thing that wasn=E2=80=99t discussed. Here is the = reason: >=20 > The encryption of Code lead to the simplification that the compressed = COSE > object is now always transported in the CoAP payload of the OSCORE > message. Hence the Object-Security option would have merely become an > indicator of whether this was an OSCORE message or not. But CoAP = options > has a built-in length value, and part of the compressed COSE Object = also > contains length values of the context parameters, so we could save = another > byte by removing one length indicator from the compressed COSE - that = of > the kid - and placing the kid in the option. Instead of just moving = the kid, we > moved the kid and everything before the kid - i.e. also the flag byte = - into the > option, so the compressed COSE became a concatenation of option and > payload. >=20 > If people thinks this unduly complicates processing we revert back. > Another alternative is to keep the kid in the option and have = everything > except the kid in the payload. That way the flag byte comes first in = the > payload, but you still need to look in the option to get the kid. >=20 > What is the preference? >=20 > a. Change back to compressed COSE in payload b. Have just the kid in = the > option c. Keep it as currently specified with the compressed COSE = object > equal to the concatenation of option and payload C does not really make any sense to me.=20 B is fine - and you could remove the bit flag for kid from the bit = array. It might be "useful" to move all of the key identification code to the = option, but that would mean that you would no longer save the byte. = However keys could then be located before decoding the rest of the = message. This means that you would have both kid and context in the = option. The problem is trying to figure out how to get the kid to have = an implicit length and the context being optional. I don=E2=80=99t see = a way to do this w/o adding a byte however. >=20 >=20 > > > >3. Section 3.1 - I do not understand why you are making the Send ID = an > >integer rather than a byte string. There are a couple of issues with > >this. > >First it is thought of as a byte string everywhere that it is = currently > >passed around - in COSE and in ACE. Secondly, it decreases the = number > >of ids that are possible as h'01' and h'0001' are distinct while 1 = and > >1 are not. >=20 > In order to easily verify uniqueness of (key, nonce) pairs in the = current setup > with a common IV and the reuse of nonce in responses (also in the = group > communication setting) the Sender ID is now included in the nonce > generation. With this construction, all nonces coming from a = particular sender > has a certain prefix, which will not coincide with a nonce generated = by > another sender. Uniqueness could easily be tested after left padding with zeros if that = is really something that needs to be done. >=20 > The two byte strings you mention are distinct, but would also need to = be > mapped to distinct byte strings of fixed length in order to do the XOR = with > the common IV. With Sender ID being an integer the uniqueness property = is > easier to establish. Still the SID is converted into a CBOR byte = string when > used. I added text on that. For this document that is not a strict requirement that I can see. = Given that the keys are going to be distinct, the fact that the same IVs = are being used is not a problem. The only issue would be if both the = sender and the recipient had the same identifier after padding has been = added. In that case one could not easily distinguish between reflection = and non-reflection cases based on the IV by itself. However that should = not be a problem as we don't distinguish those cases using the IV today. = The kid is used and those would be distinct. If this is a real restriction, it could be added as an additional = restriction for the group document and ignored here. > >7. Section 3.3 - you have a requirement in the last sentence about = the > >length of sender IDs. How should this be enforced given that IDs are > >integers, does this imply a restriction on the range of integers to = be > >used? >=20 > Yes, the intent is that random Sender IDs MUST be generated in a large = range > of integers. I made an update to clarify that. >=20 > > > >8. Section 4.3 - I am not sure that this section should start "Most > >CoAP header fields..." Looking at the table, it appears to be about > >50-50 and the assumption is new fields will probably be internal. I = think > 'some' > >may > >be better. >=20 > Actually, the header fields are not the options but the 4 bytes header > including things like Type, Code, Message ID etc. So I believe that = the > statement is true. I added text on that. Yeah, you are right - I was thinking options. >=20 >=20 > > > >9. Section 5 - I would like to have the Partial IV have a length of = 1 in > >the event that the partial iv is zero. Ditto kid >=20 > The intent here is to save these bytes, is there an issue? Saving one byte in this case does not seem to be that useful. For the IV = it would only apply to a single message. Having a value for consistency = is probably more helpful. >=20 >=20 > > > >10. Section 5 - The rule of the SHALL NOT for Partial IV worries me > >for group messaging. It may cause problems you don't want. There = are > >no real problems, except for optimization, to using the reflected > >Partial IV value. > >Please rethink this. Ditto kid >=20 > For group communication, the current construction never requires a = Partial > IV in the response. (That draft needs to be updated.) But kid is = needed in the > response. Is that true if there were an observe in the group communication? >=20 > In previous versions of the two drafts, we have had normative text in = the > OSCOAP draft which was contradicted in the case of group OSCOAP, but > maybe it is better to relax the OSCOAP specification? >=20 > I made the following change on Github: >=20 > - keep =E2=80=9CPartial IV SHALL NOT be present in responses=E2=80=9D > - replace kid "SHALL NOT be present in responses=E2=80=9D to = =E2=80=9CMAY be omitted in > responses" >=20 >=20 >=20 > >11. Section 5.1 - Does this mean that the Partial IV is limited to > >2^(5*8) > >different values? >=20 > Yes. >=20 > >If you exceed this is a new context required or do you wrap or > >something else? >=20 > New context. The security considerations state the maximum sequence > number, I added text about new context. Just so we are clear, this may be a smaller number that is imposed by = the algorithm. >=20 >=20 > > > >12. Section 5.1 - what is the purpose of putting the ID of the PIV > >generator > >in the nonce value? Please put in text that will justify this. = Given > >that > >the keys are different, is there any need for this? >=20 > As discussed above, this makes it easy to verify the (key, nonce) = uniqueness. >=20 >=20 >=20 > > > >14. Section 5.3 - You need a rule for options for dealing with a > >repeated option. >=20 >=20 > Why is repeated Class I options an issue? Order of the options is not uniquely defined at present. One will = always order the option number in increasing order due to the delta = encoding, however if you have foo=3Ddelta;foo=3Dbar and they are = re-ordered by an intermediary then validation would fail. > >16. Section 7.4 step 8 - It would appear that if there is an inner > >option which is present on the outer message but not present on the > >inner message, then it would not be removed. Is that what is = desired? >=20 >=20 > It would already be removed in step 2: >=20 > =E2=80=9C2. Discard the message Code and all non-special Class E = options from the > message." It would be easier to understand if these rules are combined. Jim >=20 >=20 >=20 > G=C3=B6ran From nobody Fri Oct 13 07:19:44 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77AB12426E; Fri, 13 Oct 2017 07:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2ybDNvuED_d3; Fri, 13 Oct 2017 07:19:39 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 379D1120720; Fri, 13 Oct 2017 07:19:39 -0700 (PDT) X-AuditID: c1b4fb30-2ddc39c000001b7f-65-59e0cb799e57 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 07.40.07039.97BC0E95; Fri, 13 Oct 2017 16:19:37 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.166]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Fri, 13 Oct 2017 16:18:59 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "draft-ietf-core-object-security@ietf.org" CC: "core@ietf.org" Thread-Topic: Review draft-ietf-core-object-security-05 Thread-Index: AdNCDxflBrT2UulyTbeReHGbxp5RNgBPzWSAAAl8vQAALn0dgA== Date: Fri, 13 Oct 2017 14:18:59 +0000 Message-ID: References: <011901d34257$27b8d950$772a8bf0$@augustcellars.com> <008501d34385$060c5820$12250860$@augustcellars.com> In-Reply-To: <008501d34385$060c5820$12250860$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <4D9B0BADFEC56A4D9756185603E8FDAE@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7im7l6QeRBj23pSz2vV3PbDHt3xkW i9XTv7M5MHtsnDOdzWPJkp9MAUxRXDYpqTmZZalF+nYJXBnPLmxjKljSy1hxc+F3tgbGK52M XYycHBICJhJH3u1k62Lk4hASOMIo8ejNFnYIZwmjxOWNE8Cq2ARcJB40PGICSYgINDFKPJ7b xwySYBZQljg++zAriC0sYCaxafJeFhBbRMBc4mNDNyuE7SRx9OwKoHoODhYBVYmJD3RBwrwC FhKf5jxhhFt2oGEdWC+ngIPE9YdT2UBsRgExie+n1jBB7BKXuPVkPhPE2QISS/acZ4awRSVe Pv4HtktUQE9ib087G0RcSWLR7c9MIHuZBTQl1u/ShxhjLTHl7gNGCFtRYkr3Q3aIewQlTs58 wjKBUXwWkm2zELpnIemehaR7FpLuBYysqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjECo+/g lt8GOxhfPnc8xCjAwajEw/vg5INIIdbEsuLK3EOMEhzMSiK8iQeAQrwpiZVVqUX58UWlOanF hxilOViUxHkd912IEBJITyxJzU5NLUgtgskycXBKNTCG7D6pqh6rN/9Ob0jRoe3BfPl7zu/0 nHEl8pzn0clbnRnO3bi94o3V7V2lLytDm/JZ7l87m1voy+d098jTcNalh17UhsRbhOh1Hf2j GPrlMXfP3joDgzU/ZvG8lHV6c+x41YQE3WZbedbIKwtLNB2SvzcLXhP7krY9eJPQPpstoher o8MsTgsrsRRnJBpqMRcVJwIAlJHEzroCAAA= Archived-At: Subject: Re: [core] Review draft-ietf-core-object-security-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 14:19:43 -0000 SGkgSmltLA0KDQpPbiAyMDE3LTEwLTEyIDIwOjA3LCAiSmltIFNjaGFhZCIgPGlldGZAYXVndXN0 Y2VsbGFycy5jb20+IHdyb3RlOg0KDQo+U2VlIGlubGluZSAtIEkgaGF2ZSB0cmltbWVkIHNvbWUg aXRlbXMuDQo+DQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogR8O2 cmFuIFNlbGFuZGVyIFttYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tXQ0KPj4gU2Vu dDogVGh1cnNkYXksIE9jdG9iZXIgMTIsIDIwMTcgNDozNiBBTQ0KPj4gVG86IEppbSBTY2hhYWQg PGlldGZAYXVndXN0Y2VsbGFycy5jb20+OyBkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LQ0KPj4gc2Vj dXJpdHlAaWV0Zi5vcmcNCj4+IENjOiBjb3JlQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogUmV2 aWV3IGRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHktMDUNCj4+IA0KPj4gSGkgSmltLA0K Pj4gDQo+PiBNYW55IHRoYW5rcyBmb3IgdGhlIHJldmlldy4NCj4+IA0KPj4gQXMgbWVudGlvbmVk IGluIHRoZSBhbm5vdW5jZW1lbnQgdGhpcyB2ZXJzaW9uIGNvbXBpbGVzIGFsbCB0aGUgcHJvcG9z ZWQNCj4+IGZpbmFsIGNoYW5nZXMsIGFuZCwgYWRtaXR0ZWRseSwgdGhlIHJhdGlvbmFsZSBmb3Ig YWxsIHByb3Bvc2FscyBoYXMgbm90DQo+PmJlZW4NCj4+IGRpc2N1c3NlZCBpbiBkZXRhaWwgc28g aXQgaXMgZ29vZCB0aGF0IHdlIGNhbiBkbyB0aGF0IG9uIHRoZSBtYWlsaW5nDQo+Pmxpc3Qgbm93 Lg0KPj4gDQo+PiANCj4+IEFuc3dlcnMgaW5saW5lIGFuZCBhIGNvdXBsZSBvZiBxdWVzdGlvbnMg YmFjay4gU29tZSBvZiB0aGUgY29tbWVudHMgYXJlDQo+PiBhbHJlYWR5IGFkZHJlc3NlZCBpbiBo dHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9vc2NvYXANCj4+IA0KPj4gDQo+PiBPbiAyMDE3LTEw LTExIDA4OjA2LCAiSmltIFNjaGFhZCIgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdyb3RlOg0K Pj4gDQo+PiA+VGhpcyB1cGRhdGUgaGFkIGEgZmV3IHRoaW5ncyB0aGF0IGNhbWUgaW4gb3V0IG9m IGxlZnQgZmllbGQgYW5kIG1heWJlIGENCj4+ID5jb3VwbGUgb2YgdGhlbSBzaG91bGQgaGF2ZSBz dGF5ZWQgdGhlcmUuDQo+PiA+DQo+DQo+DQo+PiA+DQo+PiA+MS4gIEludHJvZHVjdGlvbjogIEkg YW0gbm90IHN1cmUgd2hhdCBpcyBtZWFudCBieSBhICJub24tZW1wdHkNCj4+bWVzc2FnZSIuDQo+ PiA+VGhpcyBjYW5ub3QgcmVmZXIgdG8gdGhlIHBheWxvYWQgYmVpbmcgZW1wdHksIHNvIEkgYW0g dW5jbGVhciB3aGF0IGlzDQo+PiA+bWVhbnQgaGVyZS4NCj4+IA0KPj4gIkVtcHR5IE1lc3NhZ2Xi gJ0gaXMgYWN0dWFsbHkgZGVmaW5lZCBpbiBSRkM3MjUyLiBJIGNhcGl0YWxpc2VkIOKAnEVtcHR5 4oCdDQo+PmZvcg0KPj4gY2xhcml0eS4NCj4+IA0KPg0KPkNvbnNpZGVyIGEgcmVmZXJlbmNlIGdp dmVuIHRoYXQgaXQgaXMgaW1wb3J0YW50IHBlb3BsZSBnZXQgdGhpcyBwYXJ0DQo+cmlnaHQuDQoN CkJvdGggdGhlIHByZXZpb3VzIGFuZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIHJlZmVyZW5jZSBS RkMgNzI1MiwgYnV0IEkndmUNCmFkZGVkIGEgcmVmZXJlbmNlIGluIHRoaXMgc2VudGVuY2UgYWxz by4NCg0KPg0KPj4gPg0KPj4gPjIuICBTZWN0aW9uIDIgLSBJIGRpc2xpa2UgdGhlIGZhY3QgdGhh dCB5b3UgYXJlIG1vdmluZyB0aGUgYnl0ZSBvZg0KPj4gPmZsYWdzIGZyb20gdGhlIGJvZHkgdG8g dGhlIG9wdGlvbi4gIEkgd2FudCB0aGUgZmxhZ3MgbmV4dCB0byB0aGUgZGF0YQ0KPj4gPnRoYXQg SSBhbSBlaXRoZXIgYXNzZW1ibGluZyBvciBkaXMtYXNzZW1ibGluZyBhbmQgbm90IGluIGEgdG90 YWxseQ0KPj4gPmRpZmZlcmVudCBsb2NhdGlvbi4NCj4+ID5JZiB5b3UgdGhpbmsgdGhhdCB0aGUg b3B0aW9uIGlzIGdvaW5nIHRvIGhhdmUgbW9yZSB0aGFuIG9uZSB2YWx1ZSwgdGhlbg0KPj4gPml0 IHNob3VsZCBlaXRoZXIgaGF2ZSBpdHMgb3duIGZsYWdzIG9yIGEgZGVmaW5lZCBzdHJ1Y3R1cmUu IFBsZWFzZSBtb3ZlDQo+PiA+aXQgYmFjayB1bmxlc3MgeW91IGhhdmUgYSBSRUFMTFkgZ29vZCBj YXNlIGFuZCBhcmUgd2lsbGluZyB0byBwcm92ZSBpdC4NCj4+IA0KPj4gWWVzLCB0aGlzIHdhcyBv bmUgdGhpbmcgdGhhdCB3YXNu4oCZdCBkaXNjdXNzZWQuIEhlcmUgaXMgdGhlIHJlYXNvbjoNCj4+ IA0KPj4gVGhlIGVuY3J5cHRpb24gb2YgQ29kZSBsZWFkIHRvIHRoZSBzaW1wbGlmaWNhdGlvbiB0 aGF0IHRoZSBjb21wcmVzc2VkDQo+PkNPU0UNCj4+IG9iamVjdCBpcyBub3cgYWx3YXlzIHRyYW5z cG9ydGVkIGluIHRoZSBDb0FQIHBheWxvYWQgb2YgdGhlIE9TQ09SRQ0KPj4gbWVzc2FnZS4gSGVu Y2UgdGhlIE9iamVjdC1TZWN1cml0eSBvcHRpb24gd291bGQgaGF2ZSBtZXJlbHkgYmVjb21lIGFu DQo+PiBpbmRpY2F0b3Igb2Ygd2hldGhlciB0aGlzIHdhcyBhbiBPU0NPUkUgbWVzc2FnZSBvciBu b3QuIEJ1dCBDb0FQIG9wdGlvbnMNCj4+IGhhcyBhIGJ1aWx0LWluIGxlbmd0aCB2YWx1ZSwgYW5k IHBhcnQgb2YgdGhlIGNvbXByZXNzZWQgQ09TRSBPYmplY3QgYWxzbw0KPj4gY29udGFpbnMgbGVu Z3RoIHZhbHVlcyBvZiB0aGUgY29udGV4dCBwYXJhbWV0ZXJzLCBzbyB3ZSBjb3VsZCBzYXZlDQo+ PmFub3RoZXINCj4+IGJ5dGUgYnkgcmVtb3Zpbmcgb25lIGxlbmd0aCBpbmRpY2F0b3IgZnJvbSB0 aGUgY29tcHJlc3NlZCBDT1NFIC0gdGhhdCBvZg0KPj4gdGhlIGtpZCAtIGFuZCBwbGFjaW5nIHRo ZSBraWQgaW4gdGhlIG9wdGlvbi4gSW5zdGVhZCBvZiBqdXN0IG1vdmluZyB0aGUNCj4+a2lkLCB3 ZQ0KPj4gbW92ZWQgdGhlIGtpZCBhbmQgZXZlcnl0aGluZyBiZWZvcmUgdGhlIGtpZCAtIGkuZS4g YWxzbyB0aGUgZmxhZyBieXRlIC0NCj4+aW50byB0aGUNCj4+IG9wdGlvbiwgc28gdGhlIGNvbXBy ZXNzZWQgQ09TRSBiZWNhbWUgYSBjb25jYXRlbmF0aW9uIG9mIG9wdGlvbiBhbmQNCj4+IHBheWxv YWQuDQo+PiANCj4+IElmIHBlb3BsZSB0aGlua3MgdGhpcyB1bmR1bHkgY29tcGxpY2F0ZXMgcHJv Y2Vzc2luZyB3ZSByZXZlcnQgYmFjay4NCj4+IEFub3RoZXIgYWx0ZXJuYXRpdmUgaXMgdG8ga2Vl cCB0aGUga2lkIGluIHRoZSBvcHRpb24gYW5kIGhhdmUgZXZlcnl0aGluZw0KPj4gZXhjZXB0IHRo ZSBraWQgaW4gdGhlIHBheWxvYWQuIFRoYXQgd2F5IHRoZSBmbGFnIGJ5dGUgY29tZXMgZmlyc3Qg aW4gdGhlDQo+PiBwYXlsb2FkLCBidXQgeW91IHN0aWxsIG5lZWQgdG8gbG9vayBpbiB0aGUgb3B0 aW9uIHRvIGdldCB0aGUga2lkLg0KPj4gDQo+PiBXaGF0IGlzIHRoZSBwcmVmZXJlbmNlPw0KPj4g DQo+PiBhLiBDaGFuZ2UgYmFjayB0byBjb21wcmVzc2VkIENPU0UgaW4gcGF5bG9hZCBiLiBIYXZl IGp1c3QgdGhlIGtpZCBpbiB0aGUNCj4+IG9wdGlvbiBjLiBLZWVwIGl0IGFzIGN1cnJlbnRseSBz cGVjaWZpZWQgd2l0aCB0aGUgY29tcHJlc3NlZCBDT1NFIG9iamVjdA0KPj4gZXF1YWwgdG8gdGhl IGNvbmNhdGVuYXRpb24gb2Ygb3B0aW9uIGFuZCBwYXlsb2FkDQo+DQo+QyBkb2VzIG5vdCByZWFs bHkgbWFrZSBhbnkgc2Vuc2UgdG8gbWUuDQo+QiBpcyBmaW5lIC0gYW5kIHlvdSBjb3VsZCByZW1v dmUgdGhlIGJpdCBmbGFnIGZvciBraWQgZnJvbSB0aGUgYml0IGFycmF5Lg0KPg0KPkl0IG1pZ2h0 IGJlICJ1c2VmdWwiIHRvIG1vdmUgYWxsIG9mIHRoZSBrZXkgaWRlbnRpZmljYXRpb24gY29kZSB0 byB0aGUNCj5vcHRpb24sIGJ1dCB0aGF0IHdvdWxkIG1lYW4gdGhhdCB5b3Ugd291bGQgbm8gbG9u Z2VyIHNhdmUgdGhlIGJ5dGUuDQo+SG93ZXZlciBrZXlzIGNvdWxkIHRoZW4gYmUgbG9jYXRlZCBi ZWZvcmUgZGVjb2RpbmcgdGhlIHJlc3Qgb2YgdGhlDQo+bWVzc2FnZS4gIFRoaXMgbWVhbnMgdGhh dCB5b3Ugd291bGQgaGF2ZSBib3RoIGtpZCBhbmQgY29udGV4dCBpbiB0aGUNCj5vcHRpb24uICBU aGUgcHJvYmxlbSBpcyB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cgdG8gZ2V0IHRoZSBraWQgdG8g aGF2ZQ0KPmFuIGltcGxpY2l0IGxlbmd0aCBhbmQgdGhlIGNvbnRleHQgYmVpbmcgb3B0aW9uYWwu ICBJIGRvbuKAmXQgc2VlIGEgd2F5IHRvDQo+ZG8gdGhpcyB3L28gYWRkaW5nIGEgYnl0ZSBob3dl dmVyLg0KDQpJIG9wZW5lZCBhbiBpc3N1ZSBhYm91dCBjaGFuZ2luZyB0byBvcHRpb24gQjoNCg0K aHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvb3Njb2FwL2lzc3Vlcy8xNzkNCg0KPg0KPj4gDQo+ PiANCj4+ID4NCj4+ID4zLiAgU2VjdGlvbiAzLjEgLSBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoeSB5 b3UgYXJlIG1ha2luZyB0aGUgU2VuZCBJRCBhbg0KPj4gPmludGVnZXIgcmF0aGVyIHRoYW4gYSBi eXRlIHN0cmluZy4gIFRoZXJlIGFyZSBhIGNvdXBsZSBvZiBpc3N1ZXMgd2l0aA0KPj4gPnRoaXMu DQo+PiA+Rmlyc3QgaXQgaXMgdGhvdWdodCBvZiBhcyBhIGJ5dGUgc3RyaW5nIGV2ZXJ5d2hlcmUg dGhhdCBpdCBpcyBjdXJyZW50bHkNCj4+ID5wYXNzZWQgYXJvdW5kIC0gaW4gQ09TRSBhbmQgaW4g QUNFLiAgU2Vjb25kbHksIGl0IGRlY3JlYXNlcyB0aGUgbnVtYmVyDQo+PiA+b2YgaWRzIHRoYXQg YXJlIHBvc3NpYmxlIGFzIGgnMDEnIGFuZCBoJzAwMDEnIGFyZSBkaXN0aW5jdCB3aGlsZSAxIGFu ZA0KPj4gPjEgYXJlIG5vdC4NCj4+IA0KPj4gSW4gb3JkZXIgdG8gZWFzaWx5IHZlcmlmeSB1bmlx dWVuZXNzIG9mIChrZXksIG5vbmNlKSBwYWlycyBpbiB0aGUNCj4+Y3VycmVudCBzZXR1cA0KPj4g d2l0aCBhIGNvbW1vbiBJViBhbmQgdGhlIHJldXNlIG9mIG5vbmNlIGluIHJlc3BvbnNlcyAoYWxz byBpbiB0aGUgZ3JvdXANCj4+IGNvbW11bmljYXRpb24gc2V0dGluZykgdGhlIFNlbmRlciBJRCBp cyBub3cgaW5jbHVkZWQgaW4gdGhlIG5vbmNlDQo+PiBnZW5lcmF0aW9uLiBXaXRoIHRoaXMgY29u c3RydWN0aW9uLCBhbGwgbm9uY2VzIGNvbWluZyBmcm9tIGEgcGFydGljdWxhcg0KPj5zZW5kZXIN Cj4+IGhhcyBhIGNlcnRhaW4gcHJlZml4LCB3aGljaCB3aWxsIG5vdCBjb2luY2lkZSB3aXRoIGEg bm9uY2UgZ2VuZXJhdGVkIGJ5DQo+PiBhbm90aGVyIHNlbmRlci4NCj4NCj5VbmlxdWVuZXNzIGNv dWxkIGVhc2lseSBiZSB0ZXN0ZWQgYWZ0ZXIgbGVmdCBwYWRkaW5nIHdpdGggemVyb3MgaWYgdGhh dA0KPmlzIHJlYWxseSBzb21ldGhpbmcgdGhhdCBuZWVkcyB0byBiZSBkb25lLg0KDQpJIGRvbuKA mXQgdW5kZXJzdGFuZCBob3cgdW5pcXVlbmVzcyBjYW4gYmUgdGVzdGVkIGFmdGVyIGxlZnQgcGFk ZGluZyB3aXRoDQp6ZXJvZXMgLSB3b3VsZCBub3QgdGhhdCBvbiB0aGUgY29udHJhcnkgcmVtb3Zl IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlbT8NCg0KPg0KPj4gDQo+PiBUaGUgdHdvIGJ5dGUg c3RyaW5ncyB5b3UgbWVudGlvbiBhcmUgZGlzdGluY3QsIGJ1dCB3b3VsZCBhbHNvIG5lZWQgdG8g YmUNCj4+IG1hcHBlZCB0byBkaXN0aW5jdCBieXRlIHN0cmluZ3Mgb2YgZml4ZWQgbGVuZ3RoIGlu IG9yZGVyIHRvIGRvIHRoZSBYT1INCj4+d2l0aA0KPj4gdGhlIGNvbW1vbiBJVi4gV2l0aCBTZW5k ZXIgSUQgYmVpbmcgYW4gaW50ZWdlciB0aGUgdW5pcXVlbmVzcyBwcm9wZXJ0eQ0KPj5pcw0KPj4g ZWFzaWVyIHRvIGVzdGFibGlzaC4gU3RpbGwgdGhlIFNJRCBpcyBjb252ZXJ0ZWQgaW50byBhIENC T1IgYnl0ZSBzdHJpbmcNCj4+d2hlbg0KPj4gdXNlZC4gSSBhZGRlZCB0ZXh0IG9uIHRoYXQuDQo+ DQo+Rm9yIHRoaXMgZG9jdW1lbnQgdGhhdCBpcyBub3QgYSBzdHJpY3QgcmVxdWlyZW1lbnQgdGhh dCBJIGNhbiBzZWUuICBHaXZlbg0KPnRoYXQgdGhlIGtleXMgYXJlIGdvaW5nIHRvIGJlIGRpc3Rp bmN0LCB0aGUgZmFjdCB0aGF0IHRoZSBzYW1lIElWcyBhcmUNCj5iZWluZyB1c2VkIGlzIG5vdCBh IHByb2JsZW0uICBUaGUgb25seSBpc3N1ZSB3b3VsZCBiZSBpZiBib3RoIHRoZSBzZW5kZXINCj5h bmQgdGhlIHJlY2lwaWVudCBoYWQgdGhlIHNhbWUgaWRlbnRpZmllciBhZnRlciBwYWRkaW5nIGhh cyBiZWVuIGFkZGVkLg0KPkluIHRoYXQgY2FzZSBvbmUgY291bGQgbm90IGVhc2lseSBkaXN0aW5n dWlzaCBiZXR3ZWVuIHJlZmxlY3Rpb24gYW5kDQo+bm9uLXJlZmxlY3Rpb24gY2FzZXMgYmFzZWQg b24gdGhlIElWIGJ5IGl0c2VsZi4gIEhvd2V2ZXIgdGhhdCBzaG91bGQgbm90DQo+YmUgYSBwcm9i bGVtIGFzIHdlIGRvbid0IGRpc3Rpbmd1aXNoIHRob3NlIGNhc2VzIHVzaW5nIHRoZSBJViB0b2Rh eS4gIFRoZQ0KPmtpZCBpcyB1c2VkIGFuZCB0aG9zZSB3b3VsZCBiZSBkaXN0aW5jdC4NCj4NCj5J ZiB0aGlzIGlzIGEgcmVhbCByZXN0cmljdGlvbiwgaXQgY291bGQgYmUgYWRkZWQgYXMgYW4gYWRk aXRpb25hbA0KPnJlc3RyaWN0aW9uIGZvciB0aGUgZ3JvdXAgZG9jdW1lbnQgYW5kIGlnbm9yZWQg aGVyZS4NCj4NCg0KTGV04oCZcyBnbyBvdmVyIHRoZSBkaWZmZXJlbnQgY2FzZXMuIEVhY2ggZW5k cG9pbnQgaGFzIGEgdW5pcXVlIGtleSBmb3INCnNlbmRpbmcuIFRoZSBrZXkgaXMgdXNlZA0KDQox LiB0byBwcm90ZWN0IGEgcmVxdWVzdCAoaW4gdGhlIHJvbGUgb2YgY2xpZW50KQ0KMi4gdG8gcHJv dGVjdCBhbiBvcmRpbmFyeSByZXNwb25zZSAoaW4gdGhlIHJvbGUgb2YgdGhlIHNlcnZlcikNCjMu IHRvIHByb3RlY3QgYSBub3RpZmljYXRpb24gKGluIHRoZSByb2xlIG9mIHRoZSBzZXJ2ZXIsIGlu IHRoZSBjYXNlIG9mDQpPYnNlcnZlKQ0KDQpJbiBjYXNlIDEgYW5kIDMsIHRoZSBlbmRwb2ludCBp cyBpbiBjb250cm9sIG9mIHRoZSBQYXJ0aWFsIElWIHVzZWQgaW4gdGhlDQpub25jZS4gQnV0IGlu IGNhc2UgMiBpdCBpcyBub3QsIHNpbmNlIHRoZSBzYW1lIG5vbmNlIGlzIHVzZWQgYXMgaW4gdGhl DQpyZXF1ZXN0IGl0IGlzIHJlc3BvbmRpbmcgdG8uIFNvIGV2ZW4gaW4gdGhlIGNhc2Ugb2YgbmVp dGhlciBncm91cA0KY29tbXVuaWNhdGlvbiBub3Igb2JzZXJ2ZSwgd2UgbmVlZCB0byBlbnN1cmUg dGhhdCB0aGUgbm9uY2UgdXNlZCBpbiB0aGUNCnJlcXVlc3QgaXMgZGlzdGluY3QgZnJvbSB0aGUg bm9uY2UgdXNlZCBpbiBhIHJlc3BvbnNlLiBJbiAtMDQgdGhlIGZpcnN0DQpiaXQgb2YgdGhlIG5v bmNlIHdhcyB1c2VkIHRvIHBhcnRpdGlvbiB0aGUgSVYtc3BhY2UuIEluIC0wNSB0aGUgc2VuZGVy IElEDQppcyBpbmNsdWRlZCBpbiB0aGUgbm9uY2UgZ2VuZXJhdGlvbiBzdWNoIHRoYXQgbm9uY2Vz IGdlbmVyYXRlZCBieQ0KZGlmZmVyZW50IHNlbmRlcnMgYmVjb21lIGRpZmZlcmVudCBieSBjb25z dHJ1Y3Rpb24sIGFuZCB0aGVuIGl0DQphdXRvbWF0aWNhbGx5IGFwcGxpZXMgdG8gZ3JvdXBzLg0K DQpPbmUgd2F5IHRvIGdlbmVyYXRlIGEgZ3JvdXAgaXMgdG8gc3RhcnQgd2l0aCB0d28gZW5kcG9p bnRzIGFuZCB0aGVuIGFkZA0KbW9yZSBlbmRwb2ludHMgYXMgeW91IGdvLiBJbiB0aGF0IGNhc2Ug dGhlcmUgaXMgYW4gYWR2YW50YWdlIGlmIHRoZSBzYW1lDQpoYW5kbGluZyBvZiBzZWN1cml0eSBj b250ZXh0IGFwcGxpZXMgdG8gcG9pbnQtdG8tcG9pbnQgYXMgZ3JvdXBzLg0KDQo+DQo+PiA+Ny4g IFNlY3Rpb24gMy4zIC0geW91IGhhdmUgYSByZXF1aXJlbWVudCBpbiB0aGUgbGFzdCBzZW50ZW5j ZSBhYm91dCB0aGUNCj4+ID5sZW5ndGggb2Ygc2VuZGVyIElEcy4gIEhvdyBzaG91bGQgdGhpcyBi ZSBlbmZvcmNlZCBnaXZlbiB0aGF0IElEcyBhcmUNCj4+ID5pbnRlZ2VycywgZG9lcyB0aGlzIGlt cGx5IGEgcmVzdHJpY3Rpb24gb24gdGhlIHJhbmdlIG9mIGludGVnZXJzIHRvIGJlDQo+PiA+dXNl ZD8NCj4+IA0KPj4gWWVzLCB0aGUgaW50ZW50IGlzIHRoYXQgcmFuZG9tIFNlbmRlciBJRHMgTVVT VCBiZSBnZW5lcmF0ZWQgaW4gYSBsYXJnZQ0KPj5yYW5nZQ0KPj4gb2YgaW50ZWdlcnMuIEkgbWFk ZSBhbiB1cGRhdGUgdG8gY2xhcmlmeSB0aGF0Lg0KPj4gDQo+PiA+DQo+PiA+OC4gIFNlY3Rpb24g NC4zIC0gSSBhbSBub3Qgc3VyZSB0aGF0IHRoaXMgc2VjdGlvbiBzaG91bGQgc3RhcnQgIk1vc3QN Cj4+ID5Db0FQIGhlYWRlciBmaWVsZHMuLi4iICBMb29raW5nIGF0IHRoZSB0YWJsZSwgaXQgYXBw ZWFycyB0byBiZSBhYm91dA0KPj4gPjUwLTUwIGFuZCB0aGUgYXNzdW1wdGlvbiBpcyBuZXcgZmll bGRzIHdpbGwgcHJvYmFibHkgYmUgaW50ZXJuYWwuICBJDQo+PnRoaW5rDQo+PiAnc29tZScNCj4+ ID5tYXkNCj4+ID5iZSBiZXR0ZXIuDQo+PiANCj4+IEFjdHVhbGx5LCB0aGUgaGVhZGVyIGZpZWxk cyBhcmUgbm90IHRoZSBvcHRpb25zIGJ1dCB0aGUgNCBieXRlcyBoZWFkZXINCj4+IGluY2x1ZGlu ZyB0aGluZ3MgbGlrZSBUeXBlLCBDb2RlLCBNZXNzYWdlIElEIGV0Yy4gU28gSSBiZWxpZXZlIHRo YXQgdGhlDQo+PiBzdGF0ZW1lbnQgaXMgdHJ1ZS4gSSBhZGRlZCB0ZXh0IG9uIHRoYXQuDQo+DQo+ WWVhaCwgeW91IGFyZSByaWdodCAtIEkgd2FzIHRoaW5raW5nIG9wdGlvbnMuDQo+DQo+PiANCj4+ IA0KPj4gPg0KPj4gPjkuICBTZWN0aW9uIDUgLSBJIHdvdWxkIGxpa2UgdG8gaGF2ZSB0aGUgUGFy dGlhbCBJViBoYXZlIGEgbGVuZ3RoIG9mIDENCj4+aW4NCj4+ID50aGUgZXZlbnQgdGhhdCB0aGUg cGFydGlhbCBpdiBpcyB6ZXJvLiAgIERpdHRvIGtpZA0KPj4gDQo+PiBUaGUgaW50ZW50IGhlcmUg aXMgdG8gc2F2ZSB0aGVzZSBieXRlcywgaXMgdGhlcmUgYW4gaXNzdWU/DQo+DQo+U2F2aW5nIG9u ZSBieXRlIGluIHRoaXMgY2FzZSBkb2VzIG5vdCBzZWVtIHRvIGJlIHRoYXQgdXNlZnVsLg0KPkZv ciB0aGUgSVYgaXQgd291bGQgb25seSBhcHBseSB0byBhIHNpbmdsZSBtZXNzYWdlLiBIYXZpbmcg YSB2YWx1ZSBmb3INCj5jb25zaXN0ZW5jeSBpcyBwcm9iYWJseSBtb3JlIGhlbHBmdWwuDQoNCkkg d291bGQgYWdyZWUgZm9yIHRoZSBQYXJ0aWFsIElWIHNpbmNlIHRoaXMgaXMgYSBzaW5nbGUgbWVz c2FnZSBpbiBhDQpwb3RlbnRpYWxseSBsb25nIGV4Y2hhbmdlIG9mIG1lc3NhZ2VzLiBIb3dldmVy LCBmb3IgdGhlIGtpZCwgd2hlcmUgdGhlDQpjbGllbnQgd291bGQgdHlwaWNhbGx5IHVzZSBraWQ9 MCB0aGlzIHdvdWxkIGJlIGV2ZXJ5IG1lc3NhZ2Ugc2VudC4gV2l0aA0KaXNzdWUgIzE3OSwga2lk IHdvdWxkIGFueXdheSBiZSB0cmVhdGVkIGRpZmZlcmVudGx5LCBzbyBpdCBzaG91bGQgbm90DQpt YXR0ZXIgaWYgdGhlc2UgdHdvIHBhcmFtZXRlcnMgYXJlIGhhbmRsZWQgZGlmZmVyZW50bHkuIFdv dWxkIHlvdSBiZSBPSw0Kd2l0aCBvbmx5IGFwcGx5aW5nIHRoaXMgdG8gdGhlIFBhcnRpYWwgSVY/ DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL29zY29hcC9pc3N1ZXMvMTgwDQoNCiAgICAg IA0KPg0KPj4gDQo+PiANCj4+ID4NCj4+ID4xMC4gIFNlY3Rpb24gNSAtIFRoZSBydWxlIG9mIHRo ZSBTSEFMTCBOT1QgZm9yIFBhcnRpYWwgSVYgd29ycmllcyBtZQ0KPj4gPmZvciBncm91cCBtZXNz YWdpbmcuICBJdCBtYXkgY2F1c2UgcHJvYmxlbXMgeW91IGRvbid0IHdhbnQuICBUaGVyZSBhcmUN Cj4+ID5ubyByZWFsIHByb2JsZW1zLCBleGNlcHQgZm9yIG9wdGltaXphdGlvbiwgdG8gdXNpbmcg dGhlIHJlZmxlY3RlZA0KPj4gPlBhcnRpYWwgSVYgdmFsdWUuDQo+PiA+UGxlYXNlIHJldGhpbmsg dGhpcy4gIERpdHRvIGtpZA0KPj4gDQo+PiBGb3IgZ3JvdXAgY29tbXVuaWNhdGlvbiwgdGhlIGN1 cnJlbnQgY29uc3RydWN0aW9uIG5ldmVyIHJlcXVpcmVzIGENCj4+UGFydGlhbA0KPj4gSVYgaW4g dGhlIHJlc3BvbnNlLiAoVGhhdCBkcmFmdCBuZWVkcyB0byBiZSB1cGRhdGVkLikgQnV0IGtpZCBp cyBuZWVkZWQNCj4+aW4gdGhlDQo+PiByZXNwb25zZS4NCj4NCj5JcyB0aGF0IHRydWUgaWYgdGhl cmUgd2VyZSBhbiBvYnNlcnZlIGluIHRoZSBncm91cCBjb21tdW5pY2F0aW9uPw0KDQpBY2NvcmRp bmcgdG8gUkZDNzM5MCBDb0FQIE9ic2VydmUgZG9lcyBub3Qgc3VwcG9ydCBhIGdyb3VwIGNvbW11 bmljYXRpb24NCm1vZGUsIHNvIHdlIGRpZG7igJl0IGhhdmUgdGhhdCBhcyBwYXJ0IG9mIHRoZSBk ZXNpZ24gZ29hbHMuDQoNCj4NCj4+IA0KPj4gSW4gcHJldmlvdXMgdmVyc2lvbnMgb2YgdGhlIHR3 byBkcmFmdHMsIHdlIGhhdmUgaGFkIG5vcm1hdGl2ZSB0ZXh0IGluDQo+PnRoZQ0KPj4gT1NDT0FQ IGRyYWZ0IHdoaWNoIHdhcyBjb250cmFkaWN0ZWQgaW4gdGhlIGNhc2Ugb2YgZ3JvdXAgT1NDT0FQ LCBidXQNCj4+IG1heWJlIGl0IGlzIGJldHRlciB0byByZWxheCB0aGUgT1NDT0FQIHNwZWNpZmlj YXRpb24/DQo+PiANCj4+IEkgbWFkZSB0aGUgZm9sbG93aW5nIGNoYW5nZSBvbiBHaXRodWI6DQo+ PiANCj4+IC0ga2VlcCDigJxQYXJ0aWFsIElWIFNIQUxMIE5PVCBiZSBwcmVzZW50IGluIHJlc3Bv bnNlc+KAnQ0KPj4gLSByZXBsYWNlIGtpZCAiU0hBTEwgTk9UIGJlIHByZXNlbnQgaW4gcmVzcG9u c2Vz4oCdIHRvIOKAnE1BWSBiZSBvbWl0dGVkIGluDQo+PiByZXNwb25zZXMiDQo+PiANCj4+IA0K Pj4gDQo+PiA+MTEuICBTZWN0aW9uIDUuMSAtIERvZXMgdGhpcyBtZWFuIHRoYXQgdGhlIFBhcnRp YWwgSVYgaXMgbGltaXRlZCB0bw0KPj4gPjJeKDUqOCkNCj4+ID5kaWZmZXJlbnQgdmFsdWVzPw0K Pj4gDQo+PiBZZXMuDQo+PiANCj4+ID5JZiB5b3UgZXhjZWVkIHRoaXMgaXMgYSBuZXcgY29udGV4 dCByZXF1aXJlZCBvciBkbyB5b3Ugd3JhcCBvcg0KPj4gPnNvbWV0aGluZyBlbHNlPw0KPj4gDQo+ PiBOZXcgY29udGV4dC4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHN0YXRlIHRoZSBtYXhp bXVtIHNlcXVlbmNlDQo+PiBudW1iZXIsIEkgYWRkZWQgdGV4dCBhYm91dCBuZXcgY29udGV4dC4N Cj4NCj5KdXN0IHNvIHdlIGFyZSBjbGVhciwgdGhpcyBtYXkgYmUgYSBzbWFsbGVyIG51bWJlciB0 aGF0IGlzIGltcG9zZWQgYnkgdGhlDQo+YWxnb3JpdGhtLg0KDQpSaWdodC4gU2VjdXJpdHkgY29u c2lkZXJhdGlvbiByZWFkczoNCg0KIlRoZSBtYXhpbXVtIHNlbmRlciBzZXF1ZW5jZSBudW1iZXIg aXMgZGVwZW5kZW50IG9uIHRoZSBBRUFEIGFsZ29yaXRobS4NClRoZSBtYXhpbXVtIHNlbmRlciBz ZXF1ZW5jZSBudW1iZXIgU0hBTEwgYmUgMl40MCAtIDEsIG9yIGFueSBhbGdvcml0aG0NCnNwZWNp ZmljIGxvd2VyIGxpbWl0LCBhZnRlciB3aGljaCBhIG5ldyBzZWN1cml0eSBjb250ZXh0IG11c3Qg YmUNCmdlbmVyYXRlZC4gVGhlIGNvbXByZXNzaW9uIG1lY2hhbmlzbSBhc3N1bWVzIHRoYXQgdGhl IFBhcnRpYWwgSVYgaXMgNDANCmJpdHMgb3IgbGVzcy4iDQoNCg0KRG8geW91IG1pc3MgYW55dGhp bmcgdGhlcmU/DQoNCj4NCj4+IA0KPj4gDQo+PiA+DQo+PiA+MTIuIFNlY3Rpb24gNS4xIC0gd2hh dCBpcyB0aGUgcHVycG9zZSBvZiBwdXR0aW5nIHRoZSBJRCBvZiB0aGUgUElWDQo+PiA+Z2VuZXJh dG9yDQo+PiA+aW4gdGhlIG5vbmNlIHZhbHVlPyAgUGxlYXNlIHB1dCBpbiB0ZXh0IHRoYXQgd2ls bCBqdXN0aWZ5IHRoaXMuICAgR2l2ZW4NCj4+ID50aGF0DQo+PiA+dGhlIGtleXMgYXJlIGRpZmZl cmVudCwgaXMgdGhlcmUgYW55IG5lZWQgZm9yIHRoaXM/DQo+PiANCj4+IEFzIGRpc2N1c3NlZCBh Ym92ZSwgdGhpcyBtYWtlcyBpdCBlYXN5IHRvIHZlcmlmeSB0aGUgKGtleSwgbm9uY2UpDQo+PnVu aXF1ZW5lc3MuDQo+PiANCj4+IA0KPj4gDQo+PiA+DQo+PiA+MTQuICBTZWN0aW9uIDUuMyAtIFlv dSBuZWVkIGEgcnVsZSBmb3Igb3B0aW9ucyBmb3IgZGVhbGluZyB3aXRoIGENCj4+ID5yZXBlYXRl ZCBvcHRpb24uDQo+PiANCj4+IA0KPj4gV2h5IGlzIHJlcGVhdGVkIENsYXNzIEkgb3B0aW9ucyBh biBpc3N1ZT8NCj4NCj5PcmRlciBvZiB0aGUgb3B0aW9ucyBpcyBub3QgdW5pcXVlbHkgZGVmaW5l ZCBhdCBwcmVzZW50LiAgT25lIHdpbGwgYWx3YXlzDQo+b3JkZXIgdGhlIG9wdGlvbiBudW1iZXIg aW4gaW5jcmVhc2luZyBvcmRlciBkdWUgdG8gdGhlIGRlbHRhIGVuY29kaW5nLA0KPmhvd2V2ZXIg aWYgeW91IGhhdmUgZm9vPWRlbHRhO2Zvbz1iYXIgYW5kIHRoZXkgYXJlIHJlLW9yZGVyZWQgYnkg YW4NCj5pbnRlcm1lZGlhcnkgdGhlbiB2YWxpZGF0aW9uIHdvdWxkIGZhaWwuDQoNCllvdSBhcmUg cmlnaHQsIHRoYXQgaXMgaW5kZWVkIHNwZWNpZmljYWxseSBmb3IgY2xhc3MgSSBvcHRpb25zLCBJ IG9wZW5lZA0KYW4gaXNzdWU6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL29zY29hcC9p c3N1ZXMvMTgxDQoNClNpbmNlIHRoZXJlIGFyZSBubyBvcHRpb25zIG9mIHRoaXMga2luZCB5ZXQs IEkgYW0gdGVtcHRlZCB0byBsZWF2ZSB0aGlzIGFzDQphIHJlcXVpcmVtZW50IGZvciB0aG9zZSBp bnRyb2R1Y2luZyB0aGUgbmV3IHJlcGVhdGFibGUgQ2xhc3MgSSBvcHRpb24gdG8NCmFsc28gZGVm aW5lIGFuIG9yZGVyaW5nIG9mIHRoZSBvcHRpb24gdmFsdWVzLg0KDQo+DQo+PiA+MTYuIFNlY3Rp b24gNy40IHN0ZXAgOCAtIEl0IHdvdWxkIGFwcGVhciB0aGF0IGlmIHRoZXJlIGlzIGFuIGlubmVy DQo+PiA+b3B0aW9uIHdoaWNoIGlzIHByZXNlbnQgb24gdGhlIG91dGVyIG1lc3NhZ2UgYnV0IG5v dCBwcmVzZW50IG9uIHRoZQ0KPj4gPmlubmVyIG1lc3NhZ2UsIHRoZW4gaXQgd291bGQgbm90IGJl IHJlbW92ZWQuICBJcyB0aGF0IHdoYXQgaXMgZGVzaXJlZD8NCj4+IA0KPj4gDQo+PiBJdCB3b3Vs ZCBhbHJlYWR5IGJlIHJlbW92ZWQgaW4gc3RlcCAyOg0KPj4gDQo+PiDigJwyLiBEaXNjYXJkIHRo ZSBtZXNzYWdlIENvZGUgYW5kIGFsbCBub24tc3BlY2lhbCBDbGFzcyBFIG9wdGlvbnMgZnJvbQ0K Pj50aGUNCj4+IG1lc3NhZ2UuIg0KPg0KPkl0IHdvdWxkIGJlIGVhc2llciB0byB1bmRlcnN0YW5k IGlmIHRoZXNlIHJ1bGVzIGFyZSBjb21iaW5lZC4NCg0KV2UgY291bGQgbW92ZSBzdGVwIDIgdG8g YSBuZXcgc3RlcCA3LiBUaGF0LCBob3dldmVyLCB3b3VsZCBwb3RlbnRpYWxseQ0KbWFrZSBpdCBt b3JlIGRpZmZpY3VsdCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHByZS1leGlzdGluZyBvdXRlciBv cHRpb25zDQphbmQgZGVjcnlwdGVkIG9wdGlvbnMgKGluIHN0ZXAgMiB0aGVyZSBleGlzdHMgb25s eSBvdXRlciBvcHRpb25zIHNpbmNlIHRoZQ0KZGVjcnlwdGlvbiBvcGVyYXRpb24gaGFzIG5vdCB5 ZXQgYmVlbiBwZXJmb3JtZWQpLiBBbHRlcm5hdGl2ZWx5IHdlIGNvdWxkDQppbnRyb2R1Y2Ugc29t ZSB0ZXh0IGV4cGxhaW5pbmcgb3IgcmVmZXJlbmNpbmcgYmV0d2VlbiB0aGVzZSBkaWZmZXJlbnQN Cm9wZXJhdGlvbnMuIFdoYXQgaXMgcHJlZmVycmVkPw0KDQoNCkfDtnJhbg0KDQo= From nobody Fri Oct 13 08:59:44 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346DE1331E3 for ; Fri, 13 Oct 2017 08:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 PD4knhb8d8yy for ; Fri, 13 Oct 2017 08:59:41 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C3971331B0 for ; Fri, 13 Oct 2017 08:59:40 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 312B9479D9; Fri, 13 Oct 2017 17:59:38 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 7A16D36; Fri, 13 Oct 2017 17:59:37 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 4B9EA19; Fri, 13 Oct 2017 17:59:37 +0200 (CEST) Received: (nullmailer pid 5050 invoked by uid 1000); Fri, 13 Oct 2017 15:59:36 -0000 Date: Fri, 13 Oct 2017 17:59:35 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Klaus Hartke Cc: "core@ietf.org WG (core@ietf.org)" Message-ID: <20171013155935.oczzm2s4w3hxvhes@hephaistos.amsuess.com> References: <20171010192040.qeanayarc5ziyd2v@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fhkjdnj7mocvh6dv" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [core] Use of rel=hosts (LWM2M?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 15:59:43 -0000 --fhkjdnj7mocvh6dv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Klaus and WG, On Tue, Oct 10, 2017 at 09:49:52PM +0200, Klaus Hartke wrote: > Originally, RFC6690 was only for the /.well-known/core resource. A > /.well-known/core resource of a server consists of links to the > resources hosted by the server: the server "hosts" the link targets. >=20 > In practice, the "hosts" relation type is basically a "I'm told I must > use link relation types; let's put some random string in the 'rel' > field to make people happy and then completely ignore it". Thanks for your reply, this sounds quite plausible to me. One perspective I've recently started to take is that 'hosts' allows applications to group resources of a device together even though URIs are opaque to it -- but that goes well together with yours. Another different use of 'hosts' I've heard of happens in some versions of (or plans for) OCF, where the target should be interpreted relative to the anchor if (and only if) rel=3Dhosts. This is a use case of which I think it contradicts the resolution rules of RFC6690 (and would be better served by protocol-negotiation) -- but if this is interpretation is more widespread (or deployed anywyhere), we should probably work out together how this fits with the rest of the link-format model. Is it? > I guess a resource directory is more like a repository of URLs (with > some resource metadata) rather than of links, since there isn't really > a relationship between the RD and the resources other than that the RD > stores their URLs. We're trying to store the link in its full semantics in the RD, not only the targets (so eg. ;anchor=3D"/temp"; rel=3D"describedby" can be understood by a client to the RD). From the document's current (and probably also WGLC) state, this means that the hosts relationship is carried over as a ;if=3D"core.s"; anchor=3D"coap://the-endpoint", still keeping the implied hosts relationship. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --fhkjdnj7mocvh6dv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlng4rsACgkQOY0REtOk veEunw/+PKwaa6RSJh8Wxm31BKLGOV1izs7GRhPQ+3HXjI1gyKVRRIAmL15lfU2d icaJp9j7dtgxcKZ7j9QJwp6q1vZs8fBjc7l0yaINPitaDn4Ml08/Dwv30kPJKhBD VB04wVu3w4bgB1NoLz/upqNwTiRqYqOKoW5DjMJ/VRUzhL2QPfxLLKdCJzHHYs14 +GqbnxdX7fd8p7DdJkXV6ehTVAgW35Vz8StIfaPrg2DBUWjvwOYlBiBvHbzInDEn 3DDqfu0pgPnVn7owL168/J0Z2+rlPo0gHTQwMNjYCnlbSuF9qS+/iMVypIHRYyBn ncExpfi4GXz3LovDh5N0iaNDbqNwRwuezCV/El/GMpm9TvAlf/Py5UeiSyn7P/XV P6kG8qtFUZAXZ5iXdyyNUHk+rmk2T3QVkVfd/zuORUIjxhP8BsY8DO7uMcOk2au3 kSEal+EsgnE5lspVzFtDbYRUEmr5aNPjBcq7Quf3uMJkiOhHqwlHlh1Xo2zZ/m97 iF047fLPF8jpU2j4yNvSPWCWRKNUHz7okFsX1a5zIsgeQvlzB05f8dqtMXEnQXwa +f9fPV5TscITcyqsXwf27EBYtVA0UJ0ce1TUFNP9/thCtdQUnhx3Xjc0HavCvPnL /PzKLHN0/uTFtbpaFX12tjUtBzQP/5Ek5M+t2hCq519i8AohaJI= =saSx -----END PGP SIGNATURE----- --fhkjdnj7mocvh6dv-- From nobody Fri Oct 13 09:31:41 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32F51331D9 for ; Fri, 13 Oct 2017 09:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 pmnFiIPShZuR for ; Fri, 13 Oct 2017 09:31:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0AB13243A for ; Fri, 13 Oct 2017 09:31:37 -0700 (PDT) Received: from [192.168.91.203] ([80.92.116.99]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LzpWx-1d8RwD3aIV-0150Z2 for ; Fri, 13 Oct 2017 18:31:34 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Fri, 13 Oct 2017 18:31:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:XKVlUf/2dPmhYFvUoqyKrhUE5Qe8mGVZ+Vb0vOIGgnXea9MVXt7 Oyj+nf+CKuH/0uPD+PFGcspsgAJK/ygBvlLvDBS+RqDXAlv7fUeI++rsf7Olu0lPRhC1ylf 28xlxJ/pSZL0JJAYuOwjGj11JD6owiaXSHT21jGac+532TjqvCTpyfWluVKoU6Gxl5Bq0Hl lCpF9bdirCbSNvTvbl8MA== X-UI-Out-Filterresults: notjunk:1;V01:K0:QBk+V1Tpobk=:0DfjeUs7jepNg3cVrsn+sg oK761TW698JrlBQKLlLRrTKGaE95mHjpXyqm5zXeJt/gu4i4QIz1QvJdWwgVNXzZLNseODYUq 1xRWxfTndw18fWm6r4FGtcXywuFxmst8ecZlRjP1uMRyWWIb3GMddn9cCd1l74nEp9SHdKW3a MT/LJNPKX3zpYVXBgEHoJQIbKavWUQIiMa5IXdBNBp4eqERrfrEZlVviVMiVTPg6NoPYrnIYW hVrWjkD5mdUA4KOn5VMAY1zDB9f03mp4ZPuRKfhOhNRuqeaayY05gZKgAOsfoGwSqZdlGdiah bdSXz96dr6O7Q4SV3nRW+xtQW9Kq69TMm6KO4DtXc7kL65Cod7lVxe4NTDkpwipeAPz9AlgAy fqAohTvhiSWbeeID4V/KG6jaeanyWWdDTVtAModojKDufzb8lX1H6jQAYMuVFaFyyXl49leYq d50L533l5wJl5Fd6BccOl3arq9QYRMyNtDtQxmiFyYuK3N5CN8QScA7yyjBSjDoT3Hnc8Wc04 M0GxqP20UE5N9sg9ndOYgojSzwLYqSi2evgFs5+gxNe8a9gxHgeUSupbtZ2scfU627H9vjeVK O08K+2x04sSOkkaV/hUmfaGvMgo0Q0Z9t62OevyesX9YB4Y8RXgTlw9ij/IpYQlkD7MMnDmbq Z8gjgdbcuuQGuXF62tYj+JQpMXmTCZh3COOS1p0HwJ8mcvlbUm9ZUAxOYrJw/c9sNCkPfm1jG tDxgwymNmONZo8oFyxjihSSajzR7LNSeJ4JTN62nT7kHCqzBOTj4HMQgO4Wty/m0FdrzJFPsJ ujX9zxhlkwJ4Sc73/7eD9jjdnaucRL+uB3CmNRH/+Ph+8+Uzs8= Archived-At: Subject: [core] New intro to CoAP over TCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 16:31:40 -0000 After a discussion with Jaime I wrote a new introduction for the CoAP over TCP draft. Below is the new text. What do you think? ----- 1. Introduction The Constrained Application Protocol (CoAP) [RFC7252] was designed for Internet of Things (IoT) deployments, assuming that UDP [RFC0768] and DTLS [RFC6347] over UDP can be used unimpeded. The use of CoAP over UDP is focused on simplicity, has a low code footprint, and a small over-the-wire message size. The primary reason for introducing CoAP over TCP [RFC0793] and TLS [RFC5246] is that some networks drop UDP packets. Complete blocking of UDP happens in between about 2% and 4% of terrestrial access networks, according to [EK2016]. UDP impairment is especially concentrated in enterprise networks and networks in geographic regions with otherwise challenged connectivity. Some networks also rate-limit UDP traffic, as reported in [BK2015] and deployment investigations related to the standardization of QUIC revealed numbers around 0.3 % [SW2016]. The introduction of CoAP over TCP also leads to some side effects, namely o Where NATs are present along the communication path, CoAP over TCP leads to different NAT traversal behavior than CoAP over UDP. NATs often calculate expiration timers based on the transport layer protocol being used by application protocols. Many NATs maintain TCP-based NAT bindings for longer periods based on the assumption that a transport layer protocol, such as TCP, offers additional information about the session life cycle. UDP, on the other hand, does not provide such information to a NAT and timeouts tend to be much shorter [HomeGateway]. According to [HomeGateway] the mean between TCP and UDP NAT binding timeouts is 386 minutes (TCP) and 160 seconds (UDP). Shorter timeout values require keepalive messages to be sent more frequently. Hence, the use of CoAP over TCP requires less frequent transmission of keep- alive messages. o TCP utilizes more sophisticated congestion and flow control mechanisms, which is useful for the transfer of larger payloads. In the context of IoT deployments such transfers could be firmware updates. There is, however, ongoing work to add advanced congestion control to CoAP as well, see [I-D.ietf-core-cocoa]. Note that the use of CoAP over UDP (and CoAP over DTLS over UDP) is still the recommended transport for use constrained node networks, particularly when used in concert with blockwise transfer. CoAP over TCP is applicable for those cases where the networking infrastructure leaves no other choice. The use of CoAP over TCP leads to a larger code size, more roundtrips, increased RAM requirements and larger packet sizes. Developers implementing CoAP over TCP are encouraged to read [I-D.gomez-lwig-tcp-constrained-node-networks] for guidance on low-footprint TCP implementations for IoT devices. Emerging standards such as Lightweight Machine to Machine [LWM2M] currently use CoAP over UDP as a transport and require support for CoAP over TCP to address the issues above and to protect investments in existing CoAP implementations and deployments. Although HTTP/2 could also potentially address the need for enterprise firewall traversal, there would be additional costs and delays introduced by such a transition from CoAP to HTTP/2. Currently, there are also fewer HTTP/2 implementations available for constrained devices in comparison to CoAP. Since CoAP also support group communication using IP layer multicast and unreliable communication IoT devices would have to support HTTP/2 in addition to CoAP. Furthermore, CoAP may be integrated into a Web environment where the front-end uses CoAP over UDP from IoT devices to a cloud infrastructure and then CoAP over TCP between the back-end services. A TCP-to-UDP gateway can be used at the cloud boundary to communicate with the UDP-based IoT device. Finally, CoAP applications running inside a web browser without access to connectivity other than HTTP and the WebSocket protocol [RFC6455] may cross-proxy their CoAP requests via HTTP to a HTTP-to- CoAP cross-proxy or transport them via the the WebSocket protocol, which provides two-way communication between a WebSocket client and a WebSocket server after upgrading an HTTP/1.1 [RFC7230] connection. To address the above-mentioned deployment requirements, this document defines how to transport CoAP over TCP, CoAP over TLS, and CoAP over WebSockets. For these cases, the reliability offered by the transport protocol subsumes the reliability functions of the message layer used for CoAP over UDP. (Note that both for a reliable transport and the CoAP over UDP message layer, the reliability offered is per transport hop: where proxies -- see Sections 5.7 and 10 of [RFC7252] -- are involved, that layer's reliability function does not extend end-to-end.) Figure 1 illustrates the layering: +--------------------------------+ | Application | +--------------------------------+ +--------------------------------+ | Requests/Responses/Signaling | CoAP (RFC 7252) / This Document |--------------------------------| | Message Framing | This Document +--------------------------------+ | Reliable Transport | +--------------------------------+ Figure 1: Layering of CoAP over Reliable Transports This document specifies how to access resources using CoAP requests and responses over the TCP, TLS and WebSocket protocols. This allows connectivity-limited applications to obtain end-to-end CoAP connectivity either by communicating CoAP directly with a CoAP server accessible over a TCP, TLS or WebSocket connection or via a CoAP intermediary that proxies CoAP requests and responses between different transports, such as between WebSockets and UDP. Appendix A updates the "Observing Resources in the Constrained Application Protocol" [RFC7641] specification for use with CoAP over reliable transports. [RFC7641] is an extension to the CoAP protocol that enables CoAP clients to "observe" a resource on a CoAP server. (The CoAP client retrieves a representation of a resource and registers to be notified by the CoAP server when the representation is updated.) ----- The pull request is here: https://github.com/core-wg/coap-tcp-tls/pull/187 From nobody Fri Oct 13 09:52:37 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF7913243A for ; Fri, 13 Oct 2017 09:52:36 -0700 (PDT) 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] 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 5HBaJ20FE0Qx for ; Fri, 13 Oct 2017 09:52:33 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 ECDBE132076 for ; Fri, 13 Oct 2017 09:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9DGqRab029065; Fri, 13 Oct 2017 18:52:28 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yDDKR5vp4zDM5Q; Fri, 13 Oct 2017 18:52:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Fri, 13 Oct 2017 18:52:26 +0200 Cc: "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 529606346.74276-f78764fe8892d5797c24dffc79d86794 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] New intro to CoAP over TCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 16:52:36 -0000 > On Oct 13, 2017, at 18:31, Hannes Tschofenig = wrote: >=20 > After a discussion with Jaime I wrote a new introduction for the CoAP > over TCP draft. Below is the new text. What do you think? Nice. A few comments: >=20 > ----- >=20 > 1. Introduction >=20 > The Constrained Application Protocol (CoAP) [RFC7252] was designed > for Internet of Things (IoT) deployments, assuming that UDP = [RFC0768] > and DTLS [RFC6347] over UDP can be used unimpeded. The use of CoAP > over UDP is focused on simplicity, has a low code footprint, and a > small over-the-wire message size. >=20 > The primary reason for introducing CoAP over TCP [RFC0793] and TLS > [RFC5246] is that some networks drop s/drop/do not forward/ (I=E2=80=99m not aware of a network that never drops UDP packets, so all = networks drop UDP packets.) > UDP packets. Complete blocking > of UDP happens in between about 2% and 4% of terrestrial access > networks, according to [EK2016]. UDP impairment is especially > concentrated in enterprise networks and networks in geographic > regions with otherwise challenged connectivity. Some networks also > rate-limit UDP traffic, as reported in [BK2015] and deployment > investigations related to the standardization of QUIC revealed > numbers around 0.3 % [SW2016]. >=20 > The introduction of CoAP over TCP also leads to some side effects, > namely These are not exactly side effects =E2=80=94 besides complete = suppression of UDP, low NAT binding life times are the main reason for = CoAP over TCP. I=E2=80=99d say that these are effects that may be = desirable. >=20 > o Where NATs are present along the communication path, CoAP over = TCP > leads to different NAT traversal behavior than CoAP over UDP. > NATs often calculate expiration timers based on the transport > layer protocol being used by application protocols. Many NATs > maintain TCP-based NAT bindings for longer periods based on the > assumption that a transport layer protocol, such as TCP, offers > additional information about the session life cycle. UDP, on the > other hand, does not provide such information to a NAT and > timeouts tend to be much shorter [HomeGateway]. According to > [HomeGateway] the mean between TCP and UDP NAT binding timeouts = is s/mean between/mean for/ > 386 minutes (TCP) and 160 seconds (UDP). Shorter timeout values > require keepalive messages to be sent more frequently. Hence, = the > use of CoAP over TCP requires less frequent transmission of keep- > alive messages. >=20 > o TCP utilizes more sophisticated congestion and flow control > mechanisms, =E2=80=A6 than the default mechanisms provided by CoAP. > which is useful for the transfer of larger payloads. > In the context of IoT deployments such transfers could be = firmware > updates. =20 Unlikely as a reason to deploy CoAP over TCP =E2=80=94 if UDP is too = slow for those, you really have problems... > There is, however, ongoing work to add advanced > congestion control to CoAP as well, see [I-D.ietf-core-cocoa]. Right. > Note that the use of CoAP over UDP (and CoAP over DTLS over UDP) is > still the recommended transport for use constrained node networks, > particularly when used in concert with blockwise transfer. CoAP = over > TCP is applicable for those cases where the networking = infrastructure > leaves no other choice. The use of CoAP over TCP leads to a larger > code size, more roundtrips, increased RAM requirements and larger > packet sizes. Developers implementing CoAP over TCP are encouraged > to read [I-D.gomez-lwig-tcp-constrained-node-networks] for guidance > on low-footprint TCP implementations for IoT devices. >=20 > Emerging standards such as Lightweight Machine to Machine [LWM2M] Hmm, it=E2=80=99s maybe not that emerging any more after half a decade? > currently use CoAP over UDP as a transport and require support for > CoAP over TCP to address the issues above and to protect investments > in existing CoAP implementations and deployments. That reads like they need to do a wholesale switch to CoAP over TCP; = I=E2=80=99m not aware of that. (Some deployments may.) > Although HTTP/2 could also potentially address the need for > enterprise firewall traversal, there would be additional costs and > delays introduced by such a transition from CoAP to HTTP/2. >=20 > Currently, there are also fewer HTTP/2 implementations available for > constrained devices in comparison to CoAP. Since CoAP also support > group communication using IP layer multicast and unreliable > communication IoT devices would have to support HTTP/2 in addition = to > CoAP. >=20 > Furthermore, CoAP may be integrated into a Web environment where the > front-end uses CoAP over UDP from IoT devices to a cloud > infrastructure and then CoAP over TCP between the back-end services. > A TCP-to-UDP gateway can be used at the cloud boundary to = communicate > with the UDP-based IoT device. >=20 > Finally, CoAP applications running inside a web browser without > access to connectivity other than HTTP and the WebSocket protocol > [RFC6455] may cross-proxy their CoAP requests via HTTP to a HTTP-to- > CoAP cross-proxy or transport them via the the WebSocket protocol, > which provides two-way communication between a WebSocket client and = a > WebSocket server after upgrading an HTTP/1.1 [RFC7230] connection. (The advantage of using WebSockets over H2 here is that all CoAP = functions stay available, including Observe.) > To address the above-mentioned deployment requirements, this = document > defines how to transport CoAP over TCP, CoAP over TLS, and CoAP over > WebSockets. For these cases, the reliability offered by the > transport protocol subsumes the reliability functions of the message > layer used for CoAP over UDP. (Note that both for a reliable > transport and the CoAP over UDP message layer, the reliability > offered is per transport hop: where proxies -- see Sections 5.7 and > 10 of [RFC7252] -- are involved, that layer's reliability function > does not extend end-to-end.) Figure 1 illustrates the layering: >=20 > +--------------------------------+ > | Application | > +--------------------------------+ > +--------------------------------+ > | Requests/Responses/Signaling | CoAP (RFC 7252) / This = Document > |--------------------------------| > | Message Framing | This Document > +--------------------------------+ > | Reliable Transport | > +--------------------------------+ >=20 > Figure 1: Layering of CoAP over Reliable Transports >=20 > This document specifies how to access resources using CoAP requests > and responses over the TCP, TLS and WebSocket protocols. This = allows > connectivity-limited applications to obtain end-to-end CoAP > connectivity either by communicating CoAP directly with a CoAP = server > accessible over a TCP, TLS or WebSocket connection or via a CoAP > intermediary that proxies CoAP requests and responses between > different transports, such as between WebSockets and UDP. >=20 > Appendix A updates the "Observing Resources in the Constrained > Application Protocol" [RFC7641] specification for use with CoAP over > reliable transports. [RFC7641] is an extension to the CoAP protocol > that enables CoAP clients to "observe" a resource on a CoAP server. > (The CoAP client retrieves a representation of a resource and > registers to be notified by the CoAP server when the representation > is updated.) >=20 > ----- >=20 >=20 > The pull request is here: > https://github.com/core-wg/coap-tcp-tls/pull/187 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From nobody Fri Oct 13 10:04:45 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66485133226 for ; Fri, 13 Oct 2017 10:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_SORBS_SPAM=0.5, SPF_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxKRLFevm5lO for ; Fri, 13 Oct 2017 10:04:41 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E0113243A for ; Fri, 13 Oct 2017 10:04:41 -0700 (PDT) Received: from mail-lf0-f47.google.com ([209.85.215.47]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1e33O2-0001RM-VV; Fri, 13 Oct 2017 19:04:39 +0200 Received: by mail-lf0-f47.google.com with SMTP id k40so10330460lfi.4 for ; Fri, 13 Oct 2017 10:04:38 -0700 (PDT) X-Gm-Message-State: AMCzsaXgoSJ20lVOp+fDh2PClpL9fSGEzUORq/cfUdFyMDj39xdU+tot tqbpUKaEBZYsH8XKzVQyHeQ0AZq1hRSd2ZBN1oc= X-Google-Smtp-Source: ABhQp+TS7EE+A//baSfzhaChfd9yptJEuH2toKcMGTWJmQZ6kgG4DJpD3p4alh8EVHr81EU4RHMfw6bDgjYttovq+Y0= X-Received: by 10.25.21.101 with SMTP id l98mr731785lfi.180.1507914278489; Fri, 13 Oct 2017 10:04:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.79.3 with HTTP; Fri, 13 Oct 2017 10:03:58 -0700 (PDT) In-Reply-To: <20171013155935.oczzm2s4w3hxvhes@hephaistos.amsuess.com> References: <20171010192040.qeanayarc5ziyd2v@hephaistos.amsuess.com> <20171013155935.oczzm2s4w3hxvhes@hephaistos.amsuess.com> From: Klaus Hartke Date: Fri, 13 Oct 2017 19:03:58 +0200 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: "core@ietf.org WG (core@ietf.org)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1507914281; 889b598d; X-HE-SMSGID: 1e33O2-0001RM-VV Archived-At: Subject: Re: [core] Use of rel=hosts (LWM2M?) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 17:04:43 -0000 Christian Ams=C3=BCss wrote: >> I guess a resource directory is more like a repository of URLs (with >> some resource metadata) rather than of links, since there isn't really >> a relationship between the RD and the resources other than that the RD >> stores their URLs. > > We're trying to store the link in its full semantics in the RD, not only > the targets (so eg. ;anchor=3D"/temp"; > rel=3D"describedby" can be understood by a client to the RD). From the > document's current (and probably also WGLC) state, this means that the > hosts relationship is carried over as a ;if=3D"core.s"; > anchor=3D"coap://the-endpoint", still keeping the implied hosts > relationship. I grouped those "describedby" links into "resource metadata". For example, if you store something like this representation (taken from RFC6690) ;ct=3D40;title=3D"Sensor Index", ;rt=3D"temperature-c";if=3D"sensor", ;rt=3D"light-lux";if=3D"sensor", ;anchor=3D"/sensors/temp" ;rel=3D"describedby", ;anchor=3D"/sensors/temp";rel=3D"alternate" in a resource directory, then the RD essentially stores these URLs together with this resource metadata * ct=3D40 * title=3D"Sensor Index" * rt=3D"temperature-c" * if=3D"sensor" * link rel=3D"describedby" href=3D"http://www.example.com/sensors/t1= 23" * link rel=3D"alternate" href=3D"coap://example.com/t" * rt=3D"light-lux" * if=3D"sensor" It would make a lot of sense to make the target URLs of the inner links relative to the outer URLs. And to be able to specify a base URL for the top-level URLs. Something like this: #base { ct "40" title "Sensor Index" } { rt "temperature-c" if "sensor" describedby alternate } { rt "light-lux" if "sensor" } Klaus From nobody Fri Oct 13 10:39:14 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459631332E1 for ; Fri, 13 Oct 2017 10:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 b3ZiOZwnWa_b for ; Fri, 13 Oct 2017 10:39:06 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 34F871332CA for ; Fri, 13 Oct 2017 10:39:05 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id j58so9871537qtj.0 for ; Fri, 13 Oct 2017 10:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5XwPnLb42FsRHGOWPvL1s2QhN9m+xx9GqaG9B3JK/n4=; b=DdUrZ2CGVpM0Xf2WeQ+vVU6JNBGEwPSD8fIRrYj+Kmv4CfkzwD45ss5IxmF5X/1NTi yiYMK0rgi4Zhngfqvv8X+AKXcTvg8cjasyzBPJMPGvBJM0DeQk++a/XB5kzs8t+h58gi +lUwmBXJvhTcaW+fTdhk2knli12dRtM13KJ11722SbgOQ89JENrzMgEOcr0kzOQ4IJ/b dIpgr3tPuicnsmM75P11pOJQeaJnuJFLJp/R5lDG/iwuSO0MJg9HakINqSRFkrqGyVHv wUUy0+rgpX1lAa69znsfABENG8QrSDEIvAJXLvzjCh7lzNGpoowsKx6n0V9HHfjirNQe Hj4w== 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=5XwPnLb42FsRHGOWPvL1s2QhN9m+xx9GqaG9B3JK/n4=; b=OfraHLOJ+ScD64bKj8Hpim2BmD89uDfAtzrjt+hHiSDz2OgDfHsPYXILVDGb5oiRfa IQI8FyuUXT03oVB0qa3zjnE51ZQIuH4CdOO42qm5km4N/bkbpBuOxROU9sg/b3bTVX0A QikXh6vp8Ngac2gMEp1KAfKZayxdjpR4+cDbwZKcLpgWFVtpC1YtAOkEBSPMNzAxOa5u Z7DNLWfnDlxR2kkXOrpkmVUsYYEhuCgn2EtXkyO6YYvRv4nLC+XnZpuLPszgpfJZLwVQ q9O4lbP9l113qMw1LTTuZRcoB9vyGQ/iX4dLAkHPVDMxv1yEU8fsF5dQpJ0x9apaPQjm gJAA== X-Gm-Message-State: AMCzsaX+yv6TbxUTmi0R0gkXWCfb9yIBzQ0CTU2pX80r1kH40e+oyvtF 3iRJqUGZy6ZDb96AZUh5HxrWuliXWNLjvKOZOpzPXw== X-Google-Smtp-Source: AOwi7QBk8DqWEwcBl90mU4mol/AsQz2aWt5CWaqQc1mYYNGokCZX/BU4tEI7pyjRFiDy/VgYXAGClt4ryaS4C30pMlA= X-Received: by 10.37.104.76 with SMTP id d73mr1475143ybc.9.1507916344842; Fri, 13 Oct 2017 10:39:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Simon Lemay Date: Fri, 13 Oct 2017 17:38:54 +0000 Message-ID: To: Hannes Tschofenig Cc: "core@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c14fcee15e10f055b712261" Archived-At: Subject: Re: [core] New intro to CoAP over TCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 17:39:12 -0000 --94eb2c14fcee15e10f055b712261 Content-Type: text/plain; charset="UTF-8" I like it, comment inline On Fri, Oct 13, 2017 at 9:31 AM Hannes Tschofenig wrote: > After a discussion with Jaime I wrote a new introduction for the CoAP > over TCP draft. Below is the new text. What do you think? > > ----- > > 1. Introduction > > The Constrained Application Protocol (CoAP) [RFC7252] was designed > for Internet of Things (IoT) deployments, assuming that UDP [RFC0768] > and DTLS [RFC6347] over UDP can be used unimpeded. The use of CoAP > over UDP is focused on simplicity, has a low code footprint, and a > small over-the-wire message size. > > The primary reason for introducing CoAP over TCP [RFC0793] and TLS > [RFC5246] is that some networks drop UDP packets. Complete blocking > of UDP happens in between about 2% and 4% of terrestrial access > networks, according to [EK2016]. UDP impairment is especially > concentrated in enterprise networks and networks in geographic > regions with otherwise challenged connectivity. Some networks also > rate-limit UDP traffic, as reported in [BK2015] and deployment > investigations related to the standardization of QUIC revealed > numbers around 0.3 % [SW2016]. > > The introduction of CoAP over TCP also leads to some side effects, > namely > > o Where NATs are present along the communication path, CoAP over TCP > leads to different NAT traversal behavior than CoAP over UDP. > NATs often calculate expiration timers based on the transport > layer protocol being used by application protocols. Many NATs > maintain TCP-based NAT bindings for longer periods based on the > assumption that a transport layer protocol, such as TCP, offers > additional information about the session life cycle. UDP, on the > life cycle --> lifecycle other hand, does not provide such information to a NAT and > timeouts tend to be much shorter [HomeGateway]. According to > [HomeGateway] the mean between TCP and UDP NAT binding timeouts is > 386 minutes (TCP) and 160 seconds (UDP). Shorter timeout values > require keepalive messages to be sent more frequently. Hence, the > use of CoAP over TCP requires less frequent transmission of keep- > alive messages. > > o TCP utilizes more sophisticated congestion and flow control > mechanisms, which is useful for the transfer of larger payloads. > In the context of IoT deployments such transfers could be firmware > coma after deployments updates. There is, however, ongoing work to add advanced > congestion control to CoAP as well, see [I-D.ietf-core-cocoa]. > > Note that the use of CoAP over UDP (and CoAP over DTLS over UDP) is > still the recommended transport for use constrained node networks, > particularly when used in concert with blockwise transfer. CoAP over > TCP is applicable for those cases where the networking infrastructure > leaves no other choice. The use of CoAP over TCP leads to a larger > code size, more roundtrips, increased RAM requirements and larger > packet sizes. Developers implementing CoAP over TCP are encouraged > to read [I-D.gomez-lwig-tcp-constrained-node-networks] for guidance > on low-footprint TCP implementations for IoT devices. > > Emerging standards such as Lightweight Machine to Machine [LWM2M] > currently use CoAP over UDP as a transport and require support for > CoAP over TCP to address the issues above and to protect investments > in existing CoAP implementations and deployments. > > Although HTTP/2 could also potentially address the need for > enterprise firewall traversal, there would be additional costs and > delays introduced by such a transition from CoAP to HTTP/2. > > Currently, there are also fewer HTTP/2 implementations available for > constrained devices in comparison to CoAP. Since CoAP also support > group communication using IP layer multicast and unreliable > communication IoT devices would have to support HTTP/2 in addition to > CoAP. > > Furthermore, CoAP may be integrated into a Web environment where the > front-end uses CoAP over UDP from IoT devices to a cloud > infrastructure and then CoAP over TCP between the back-end services. > A TCP-to-UDP gateway can be used at the cloud boundary to communicate > with the UDP-based IoT device. > > Finally, CoAP applications running inside a web browser without > access to connectivity other than HTTP and the WebSocket protocol > [RFC6455] may cross-proxy their CoAP requests via HTTP to a HTTP-to- > CoAP cross-proxy or transport them via the the WebSocket protocol, > which provides two-way communication between a WebSocket client and a > WebSocket server after upgrading an HTTP/1.1 [RFC7230] connection. > this may be a bit heavy (long sentence), a possible rewording: Finally, CoAP applications running inside a web browser may be without access to connectivity other than HTTP. In this case, the WebSocket protocol [RFC6455] may be used to either cross-proxy their CoAP requests via HTTP to an HTTP-to-CoAP cross-proxy or transport them via the WebSocket protocol. This would, in turn, provide two-way communication between a WebSocket client and a WebSocket server after upgrading an HTTP/1.1 [RFC7230] connection. > To address the above-mentioned deployment requirements, this document > defines how to transport CoAP over TCP, CoAP over TLS, and CoAP over > WebSockets. For these cases, the reliability offered by the > transport protocol subsumes the reliability functions of the message > layer used for CoAP over UDP. (Note that both for a reliable > transport and the CoAP over UDP message layer, the reliability > offered is per transport hop: where proxies -- see Sections 5.7 and > 10 of [RFC7252] -- are involved, that layer's reliability function > does not extend end-to-end.) Figure 1 illustrates the layering: > > +--------------------------------+ > | Application | > +--------------------------------+ > +--------------------------------+ > | Requests/Responses/Signaling | CoAP (RFC 7252) / This Document > |--------------------------------| > | Message Framing | This Document > +--------------------------------+ > | Reliable Transport | > +--------------------------------+ > > Figure 1: Layering of CoAP over Reliable Transports > > This document specifies how to access resources using CoAP requests > and responses over the TCP, TLS and WebSocket protocols. This allows > connectivity-limited applications to obtain end-to-end CoAP > connectivity either by communicating CoAP directly with a CoAP server > accessible over a TCP, TLS or WebSocket connection or via a CoAP > intermediary that proxies CoAP requests and responses between > different transports, such as between WebSockets and UDP. > > Appendix A updates the "Observing Resources in the Constrained > Application Protocol" [RFC7641] specification for use with CoAP over > reliable transports. [RFC7641] is an extension to the CoAP protocol > that enables CoAP clients to "observe" a resource on a CoAP server. > (The CoAP client retrieves a representation of a resource and > registers to be notified by the CoAP server when the representation > is updated.) > > ----- > > > The pull request is here: > https://github.com/core-wg/coap-tcp-tls/pull/187 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --94eb2c14fcee15e10f055b712261 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I like it, comment inline

On Fri, Oct 13, 2017 at 9:31 AM Hannes Tschofenig <hannes.tschofenig@gmx.net>= ; wrote:
After a discussion with Ja= ime I wrote a new introduction for the CoAP
over TCP draft. Below is the new text. What do you think?

-----

1.=C2=A0 Introduction

=C2=A0 =C2=A0The Constrained Application Protocol (CoAP) [RFC7252] was desi= gned
=C2=A0 =C2=A0for Internet of Things (IoT) deployments, assuming that UDP [R= FC0768]
=C2=A0 =C2=A0and DTLS [RFC6347] over UDP can be used unimpeded.=C2=A0 The u= se of CoAP
=C2=A0 =C2=A0over UDP is focused on simplicity, has a low code footprint, a= nd a
=C2=A0 =C2=A0small over-the-wire message size.

=C2=A0 =C2=A0The primary reason for introducing CoAP over TCP [RFC0793] and= TLS
=C2=A0 =C2=A0[RFC5246] is that some networks drop UDP packets.=C2=A0 Comple= te blocking
=C2=A0 =C2=A0of UDP happens in between about 2% and 4% of terrestrial acces= s
=C2=A0 =C2=A0networks, according to [EK2016].=C2=A0 UDP impairment is espec= ially
=C2=A0 =C2=A0concentrated in enterprise networks and networks in geographic=
=C2=A0 =C2=A0regions with otherwise challenged connectivity.=C2=A0 Some net= works also
=C2=A0 =C2=A0rate-limit UDP traffic, as reported in [BK2015] and deployment=
=C2=A0 =C2=A0investigations related to the standardization of QUIC revealed=
=C2=A0 =C2=A0numbers around 0.3 % [SW2016].

=C2=A0 =C2=A0The introduction of CoAP over TCP also leads to some side effe= cts,
=C2=A0 =C2=A0namely

=C2=A0 =C2=A0o=C2=A0 Where NATs are present along the communication path, C= oAP over TCP
=C2=A0 =C2=A0 =C2=A0 leads to different NAT traversal behavior than CoAP ov= er UDP.
=C2=A0 =C2=A0 =C2=A0 NATs often calculate expiration timers based on the tr= ansport
=C2=A0 =C2=A0 =C2=A0 layer protocol being used by application protocols.=C2= =A0 Many NATs
=C2=A0 =C2=A0 =C2=A0 maintain TCP-based NAT bindings for longer periods bas= ed on the
=C2=A0 =C2=A0 =C2=A0 assumption that a transport layer protocol, such as TC= P, offers
=C2=A0 =C2=A0 =C2=A0 additional information about the session life cycle.= =C2=A0 UDP, on the
=C2=A0
life cycle --> = lifecycle=C2=A0

=C2=A0 =C2=A0 =C2=A0 other hand, does not provide such information to a NAT= and
=C2=A0 =C2=A0 =C2=A0 timeouts tend to be much shorter [HomeGateway].=C2=A0 = According to
=C2=A0 =C2=A0 =C2=A0 [HomeGateway] the mean between TCP and UDP NAT binding= timeouts is
=C2=A0 =C2=A0 =C2=A0 386 minutes (TCP) and 160 seconds (UDP).=C2=A0 Shorter= timeout values
=C2=A0 =C2=A0 =C2=A0 require keepalive messages to be sent more frequently.= =C2=A0 Hence, the
=C2=A0 =C2=A0 =C2=A0 use of CoAP over TCP requires less frequent transmissi= on of keep-
=C2=A0 =C2=A0 =C2=A0 alive messages.

=C2=A0 =C2=A0o=C2=A0 TCP utilizes more sophisticated congestion and flow co= ntrol
=C2=A0 =C2=A0 =C2=A0 mechanisms, which is useful for the transfer of larger= payloads.
=C2=A0 =C2=A0 =C2=A0 In the context of IoT deployments such transfers could= be firmware
=C2=A0
coma after deployments= =C2=A0

=C2=A0 =C2=A0 =C2=A0 updates.=C2=A0 There is, however, ongoing work to add = advanced
=C2=A0 =C2=A0 =C2=A0 congestion control to CoAP as well, see [I-D.ietf-core= -cocoa].

=C2=A0 =C2=A0Note that the use of CoAP over UDP (and CoAP over DTLS over UD= P) is
=C2=A0 =C2=A0still the recommended transport for use constrained node netwo= rks,
=C2=A0 =C2=A0particularly when used in concert with blockwise transfer.=C2= =A0 CoAP over
=C2=A0 =C2=A0TCP is applicable for those cases where the networking infrast= ructure
=C2=A0 =C2=A0leaves no other choice.=C2=A0 The use of CoAP over TCP leads t= o a larger
=C2=A0 =C2=A0code size, more roundtrips, increased RAM requirements and lar= ger
=C2=A0 =C2=A0packet sizes.=C2=A0 Developers implementing CoAP over TCP are = encouraged
=C2=A0 =C2=A0to read [I-D.gomez-lwig-tcp-constrained-node-networks] for gui= dance
=C2=A0 =C2=A0on low-footprint TCP implementations for IoT devices.

=C2=A0 =C2=A0Emerging standards such as Lightweight Machine to Machine [LWM= 2M]
=C2=A0 =C2=A0currently use CoAP over UDP as a transport and require support= for
=C2=A0 =C2=A0CoAP over TCP to address the issues above and to protect inves= tments
=C2=A0 =C2=A0in existing CoAP implementations and deployments.

=C2=A0 =C2=A0Although HTTP/2 could also potentially address the need for =C2=A0 =C2=A0enterprise firewall traversal, there would be additional costs= and
=C2=A0 =C2=A0delays introduced by such a transition from CoAP to HTTP/2.
=C2=A0 =C2=A0Currently, there are also fewer HTTP/2 implementations availab= le for
=C2=A0 =C2=A0constrained devices in comparison to CoAP.=C2=A0 Since CoAP al= so support
=C2=A0 =C2=A0group communication using IP layer multicast and unreliable =C2=A0 =C2=A0communication IoT devices would have to support HTTP/2 in addi= tion to
=C2=A0 =C2=A0CoAP.

=C2=A0 =C2=A0Furthermore, CoAP may be integrated into a Web environment whe= re the
=C2=A0 =C2=A0front-end uses CoAP over UDP from IoT devices to a cloud
=C2=A0 =C2=A0infrastructure and then CoAP over TCP between the back-end ser= vices.
=C2=A0 =C2=A0A TCP-to-UDP gateway can be used at the cloud boundary to comm= unicate
=C2=A0 =C2=A0with the UDP-based IoT device.

=C2=A0 =C2=A0Finally, CoAP applications running inside a web browser withou= t
=C2=A0 =C2=A0access to connectivity other than HTTP and the WebSocket proto= col
=C2=A0 =C2=A0[RFC6455] may cross-proxy their CoAP requests via HTTP to a HT= TP-to-
=C2=A0 =C2=A0CoAP cross-proxy or transport them via the the WebSocket proto= col,
=C2=A0 =C2=A0which provides two-way communication between a WebSocket clien= t and a
=C2=A0 =C2=A0WebSocket server after upgrading an HTTP/1.1 [RFC7230] connect= ion.

this may be a bit heavy (long sent= ence), a possible rewording:

=C2=A0Finally, CoAP a= pplications running inside a web browser may be without access to connectiv= ity other than HTTP.=C2=A0 In this case,=C2=A0 the WebSocket protocol [RFC6= 455] may be used to either cross-proxy their CoAP requests via HTTP to an H= TTP-to-CoAP cross-proxy or transport them via the WebSocket protocol. This = would, in turn, provide two-way communication between a WebSocket client an= d a WebSocket server after upgrading an HTTP/1.1 [RFC7230] connection.
<= /div>


=C2=A0 =C2=A0To address the above-mentioned deployment requirements, this d= ocument
=C2=A0 =C2=A0defines how to transport CoAP over TCP, CoAP over TLS, and CoA= P over
=C2=A0 =C2=A0WebSockets.=C2=A0 For these cases, the reliability offered by = the
=C2=A0 =C2=A0transport protocol subsumes the reliability functions of the m= essage
=C2=A0 =C2=A0layer used for CoAP over UDP.=C2=A0 (Note that both for a reli= able
=C2=A0 =C2=A0transport and the CoAP over UDP message layer, the reliability=
=C2=A0 =C2=A0offered is per transport hop: where proxies -- see Sections 5.= 7 and
=C2=A0 =C2=A010 of [RFC7252] -- are involved, that layer's reliability = function
=C2=A0 =C2=A0does not extend end-to-end.)=C2=A0 Figure 1 illustrates the la= yering:

=C2=A0 =C2=A0 =C2=A0+--------------------------------+
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Application=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0+--------------------------------+
=C2=A0 =C2=A0 =C2=A0+--------------------------------+
=C2=A0 =C2=A0 =C2=A0|=C2=A0 Requests/Responses/Signaling=C2=A0 |=C2=A0 CoAP= (RFC 7252) / This Document
=C2=A0 =C2=A0 =C2=A0|--------------------------------|
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 Message Framing=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 This Document
=C2=A0 =C2=A0 =C2=A0+--------------------------------+
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 Reliable Transport=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0+--------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 1: Layering of CoAP over R= eliable Transports

=C2=A0 =C2=A0This document specifies how to access resources using CoAP req= uests
=C2=A0 =C2=A0and responses over the TCP, TLS and WebSocket protocols.=C2=A0= This allows
=C2=A0 =C2=A0connectivity-limited applications to obtain end-to-end CoAP =C2=A0 =C2=A0connectivity either by communicating CoAP directly with a CoAP= server
=C2=A0 =C2=A0accessible over a TCP, TLS or WebSocket connection or via a Co= AP
=C2=A0 =C2=A0intermediary that proxies CoAP requests and responses between<= br> =C2=A0 =C2=A0different transports, such as between WebSockets and UDP.

=C2=A0 =C2=A0Appendix A updates the "Observing Resources in the Constr= ained
=C2=A0 =C2=A0Application Protocol" [RFC7641] specification for use wit= h CoAP over
=C2=A0 =C2=A0reliable transports.=C2=A0 [RFC7641] is an extension to the Co= AP protocol
=C2=A0 =C2=A0that enables CoAP clients to "observe" a resource on= a CoAP server.
=C2=A0 =C2=A0(The CoAP client retrieves a representation of a resource and<= br> =C2=A0 =C2=A0registers to be notified by the CoAP server when the represent= ation
=C2=A0 =C2=A0is updated.)

-----


The pull request is here:
https://github.com/core-wg/coap-tcp-tls/pull/187=

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--94eb2c14fcee15e10f055b712261-- From nobody Fri Oct 13 10:39:39 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63B2133221; Fri, 13 Oct 2017 10:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 CVW-KO_xhSpI; Fri, 13 Oct 2017 10:39:35 -0700 (PDT) Received: from mail4.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 29FC7133341; Fri, 13 Oct 2017 10:39:34 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1507916369; h=from:subject:to:date:message-id; bh=RzLp7yMT/X4hTicD3obDy6SEM2rOjXc845AgAHdJRpc=; b=agABOBG6NZh9f3L1mwS8U6To/POxqYYO2LoizXlJxQWM19YDuxd6TRGzyMHJApnTw1GaR2GawlH K8HvSTW67kOEQPe6YlfvoJlkWHQWgBq3TUR+0R2p+Csz+2HxqfNCuufc+qN9vwHMOG7SjJRHg0xd2 q/13Evl49m1BaQmgd1rS1Qx9hQInL6m1O2j3YbrfOr4jsynXSMoyUDu7u+xUctoG1UgIo+jLuQOdr oCMikubZLVTs9xMjbtxppMnKAdKFB3raHcM7nJtBUjXLVANtfYgj4JKllMNB/r8l5AAQpsiuZn9LU oa58WXklxqk4Bc+CKOqaf/SzZ/kQ1PV4R74Q== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 13 Oct 2017 10:39:29 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 13 Oct 2017 10:38:35 -0700 From: Jim Schaad To: =?utf-8?Q?'G=C3=B6ran_Selander'?= , CC: References: <011901d34257$27b8d950$772a8bf0$@augustcellars.com> <008501d34385$060c5820$12250860$@augustcellars.com> In-Reply-To: Date: Fri, 13 Oct 2017 10:39:24 -0700 Message-ID: <011c01d3444a$37525e50$a5f71af0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQL1P0kokeO6eLldy2El08GhLgI49gItREfiAkH+0xIB8hPF3qBq/Kjw X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [core] Review draft-ietf-core-object-security-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 17:39:39 -0000 > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Friday, October 13, 2017 7:19 AM > To: Jim Schaad ; draft-ietf-core-object- > security@ietf.org > Cc: core@ietf.org > Subject: Re: Review draft-ietf-core-object-security-05 >=20 > Hi Jim, >=20 > On 2017-10-12 20:07, "Jim Schaad" wrote: >=20 > >See inline - I have trimmed some items. > > > > > >> -----Original Message----- > >> From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > >> Sent: Thursday, October 12, 2017 4:36 AM > >> To: Jim Schaad ; draft-ietf-core-object- > >> security@ietf.org > >> Cc: core@ietf.org > >> Subject: Re: Review draft-ietf-core-object-security-05 > >> > >> Hi Jim, > >> > >> Many thanks for the review. > >> > >> As mentioned in the announcement this version compiles all the > >>proposed final changes, and, admittedly, the rationale for all > >>proposals has not been discussed in detail so it is good that we = can > >>do that on the mailing list now. > >> > >> > >> Answers inline and a couple of questions back. Some of the comments > >> are already addressed in https://github.com/core-wg/oscoap > >> > >> > >> On 2017-10-11 08:06, "Jim Schaad" wrote: > >> > >> >This update had a few things that came in out of left field and > >> >maybe a couple of them should have stayed there. > >> > > > > > > >> >3. Section 3.1 - I do not understand why you are making the Send = ID > >> >an integer rather than a byte string. There are a couple of = issues > >> >with this. > >> >First it is thought of as a byte string everywhere that it is > >> >currently passed around - in COSE and in ACE. Secondly, it > >> >decreases the number of ids that are possible as h'01' and h'0001' > >> >are distinct while 1 and > >> >1 are not. > >> > >> In order to easily verify uniqueness of (key, nonce) pairs in the > >>current setup with a common IV and the reuse of nonce in responses > >>(also in the group communication setting) the Sender ID is now > >>included in the nonce generation. With this construction, all = nonces > >>coming from a particular sender has a certain prefix, which will = not > >>coincide with a nonce generated by another sender. > > > >Uniqueness could easily be tested after left padding with zeros if = that > >is really something that needs to be done. >=20 > I don=E2=80=99t understand how uniqueness can be tested after left = padding with > zeroes - would not that on the contrary remove the difference between > them? I was giving an example of how you could test for uniqueness using a = byte array rather than an integer. I thought that was what you were = looking at here. >=20 > > > >> > >> The two byte strings you mention are distinct, but would also need = to > >>be mapped to distinct byte strings of fixed length in order to do = the > >>XOR with the common IV. With Sender ID being an integer the > >>uniqueness property is easier to establish. Still the SID is > >>converted into a CBOR byte string when used. I added text on that. > > > >For this document that is not a strict requirement that I can see. > >Given that the keys are going to be distinct, the fact that the same > >IVs are being used is not a problem. The only issue would be if both > >the sender and the recipient had the same identifier after padding = has > been added. > >In that case one could not easily distinguish between reflection and > >non-reflection cases based on the IV by itself. However that should > >not be a problem as we don't distinguish those cases using the IV > >today. The kid is used and those would be distinct. > > > >If this is a real restriction, it could be added as an additional > >restriction for the group document and ignored here. > > >=20 > Let=E2=80=99s go over the different cases. Each endpoint has a unique = key for > sending. The key is used >=20 > 1. to protect a request (in the role of client) 2. to protect an = ordinary > response (in the role of the server) 3. to protect a notification (in = the role of > the server, in the case of > Observe) >=20 > In case 1 and 3, the endpoint is in control of the Partial IV used in = the nonce. > But in case 2 it is not, since the same nonce is used as in the = request it is > responding to. So even in the case of neither group communication nor > observe, we need to ensure that the nonce used in the request is = distinct > from the nonce used in a response. In -04 the first bit of the nonce = was used > to partition the IV-space. In -05 the sender ID is included in the = nonce > generation such that nonces generated by different senders become > different by construction, and then it automatically applies to = groups. >=20 > One way to generate a group is to start with two endpoints and then = add > more endpoints as you go. In that case there is an advantage if the = same > handling of security context applies to point-to-point as groups. But in that case you understand in advance that you are going to create = a group and can apply any restrictions from the start. Another way to = create a group is to merge two groups together and re-key, that would = not necessarily work because you might have assigned the same id in both = cases. If the two groups used different length ids then it would be = possible.=20 There are lots of ways to create groups that are going to have problems = with how IDs are assigned unless there is an intent that a group is = going to be created from the start. =20 A different way to do the same thing in terms of building things would = be XX YYYY ZZ Where XX is the length of kid YYY is the kid padded (either right or left) with a constant and ZZ is = the partial IV. One could play games and assign a padding value on a per recipient basis = which could be used for all sorts of separation of spaces. I lost one = byte at the front from the length of ID, but I got a lot more kid values = from just using an integer value for shorter kids. > >> >9. Section 5 - I would like to have the Partial IV have a length = of > >> >1 > >>in > >> >the event that the partial iv is zero. Ditto kid > >> > >> The intent here is to save these bytes, is there an issue? > > > >Saving one byte in this case does not seem to be that useful. > >For the IV it would only apply to a single message. Having a value = for > >consistency is probably more helpful. >=20 > I would agree for the Partial IV since this is a single message in a = potentially > long exchange of messages. However, for the kid, where the client = would > typically use kid=3D0 this would be every message sent. With issue = #179, kid > would anyway be treated differently, so it should not matter if these = two > parameters are handled differently. Would you be OK with only applying = this > to the Partial IV? >=20 > https://github.com/core-wg/oscoap/issues/180 If you omit the flag for existence, then you would need to have the byte = for existence in the option. Having the flag not with the value is not = something that I would prefer. > >> >10. Section 5 - The rule of the SHALL NOT for Partial IV worries = me > >> >for group messaging. It may cause problems you don't want. There > >> >are no real problems, except for optimization, to using the > >> >reflected Partial IV value. > >> >Please rethink this. Ditto kid > >> > >> For group communication, the current construction never requires a > >>Partial IV in the response. (That draft needs to be updated.) But = kid > >>is needed in the response. > > > >Is that true if there were an observe in the group communication? >=20 > According to RFC7390 CoAP Observe does not support a group > communication mode, so we didn=E2=80=99t have that as part of the = design goals. I would design with this in mind given the different ways that this = might come about. I think that an observe type think in group = communications might end up coming into existence. I would do a = defensive design myself. > >> In previous versions of the two drafts, we have had normative text = in > >>the OSCOAP draft which was contradicted in the case of group = OSCOAP, > >>but maybe it is better to relax the OSCOAP specification? > >> > >> I made the following change on Github: > >> > >> - keep =E2=80=9CPartial IV SHALL NOT be present in = responses=E2=80=9D > >> - replace kid "SHALL NOT be present in responses=E2=80=9D to = =E2=80=9CMAY be omitted > >> in responses" > >> > >> > >> > >> >11. Section 5.1 - Does this mean that the Partial IV is limited = to > >> >2^(5*8) > >> >different values? > >> > >> Yes. > >> > >> >If you exceed this is a new context required or do you wrap or > >> >something else? > >> > >> New context. The security considerations state the maximum sequence > >> number, I added text about new context. > > > >Just so we are clear, this may be a smaller number that is imposed by > >the algorithm. >=20 > Right. Security consideration reads: >=20 > "The maximum sender sequence number is dependent on the AEAD > algorithm. > The maximum sender sequence number SHALL be 2^40 - 1, or any algorithm > specific lower limit, after which a new security context must be = generated. > The compression mechanism assumes that the Partial IV is 40 bits or = less." It is not the compression mechanism that is assuming this, it is the = method for building nonces that is assuming this. >=20 >=20 > Do you miss anything there? >=20 > > > >> > >> > >> > > >> >12. Section 5.1 - what is the purpose of putting the ID of the PIV > >> >generator > >> >in the nonce value? Please put in text that will justify this. = Given > >> >that > >> >the keys are different, is there any need for this? > >> > >> As discussed above, this makes it easy to verify the (key, nonce) > >>uniqueness. > >> > >> > >> > >> > > >> >14. Section 5.3 - You need a rule for options for dealing with a > >> >repeated option. > >> > >> > >> Why is repeated Class I options an issue? > > > >Order of the options is not uniquely defined at present. One will > >always order the option number in increasing order due to the delta > >encoding, however if you have foo=3Ddelta;foo=3Dbar and they are = re-ordered > >by an intermediary then validation would fail. >=20 > You are right, that is indeed specifically for class I options, I = opened an issue: >=20 > https://github.com/core-wg/oscoap/issues/181 >=20 > Since there are no options of this kind yet, I am tempted to leave = this as a > requirement for those introducing the new repeatable Class I option to = also > define an ordering of the option values. Right, and each one could define a different mechanism. This is not = what I want to here. Jim >=20 > > > >> >16. Section 7.4 step 8 - It would appear that if there is an inner > >> >option which is present on the outer message but not present on = the > >> >inner message, then it would not be removed. Is that what is = desired? > >> > >> > >> It would already be removed in step 2: > >> > >> =E2=80=9C2. Discard the message Code and all non-special Class E = options from > >>the message." > > > >It would be easier to understand if these rules are combined. >=20 > We could move step 2 to a new step 7. That, however, would potentially > make it more difficult to distinguish between pre-existing outer = options and > decrypted options (in step 2 there exists only outer options since the > decryption operation has not yet been performed). Alternatively we = could > introduce some text explaining or referencing between these different > operations. What is preferred? >=20 >=20 > G=C3=B6ran From nobody Sat Oct 14 02:25:10 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BCC13235C; Sat, 14 Oct 2017 02:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Ujvxbpq98_Ci; Sat, 14 Oct 2017 02:25:06 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 F377E133049; Sat, 14 Oct 2017 02:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9E9Ox8h004393; Sat, 14 Oct 2017 11:24:59 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yDfLg0x85zDMBr; Sat, 14 Oct 2017 11:24:59 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 529665898.341332-7b72f59c77b8f11dd7ec6cdf17e94c6b Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 14 Oct 2017 11:24:58 +0200 Message-Id: <6241D667-C2A1-41EF-83CB-D264BF9DFD3F@tzi.org> To: ace , "core@ietf.org WG" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF100: DRAFT AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 14 Oct 2017 09:25:08 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF100. Remember that there is still quite some potential for changes. The CBOR/SUIT conflict needs to be fixed. Also, maybe CORE and 6TISCH are going to swap so we have more time between the two CORE meetings. All times are SGT (UTC+0800). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, November 10, 2017 -- Joint meeting of OCF and T2TRG @ OCF meeting venue SATURDAY/SUNDAY -- Hackathon (including various interops) MONDAY, November 13, 2017 0930-1200 Morning Session I Collyer ART dispatch Dispatch WG - 0930-1100 Joint = with ARTAREA Collyer ART httpbis Hypertext Transfer Protocol WG - = 1100-1200 Olivia INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Sophia OPS anima Autonomic Networking Integrated Model = and Approach WG 1330-1530 Afternoon Session I Olivia ART *** core Constrained RESTful Environments WG Padang OPS v6ops IPv6 Operations WG 1550-1720 Afternoon Session II Bras Basah ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Collyer INT homenet Home Networking WG Padang IRTF maprg Measurement and Analysis for Protocols Canning SEC *** suit Software Updates for Internet of Things = WG 1740-1840 Afternoon Session III Padang SEC tls Transport Layer Security WG Canning TSV tsvwg Transport Area Working Group WG TUESDAY, November 14, 2017 0930-1200 Morning Session I Collyer SEC *** ace Authentication and Authorization for = Constrained Environments WG Sophia TSV taps Transport Services WG 1330-1530 Afternoon Session I Olivia ART *** core Constrained RESTful Environments WG Canning OPS v6ops IPv6 Operations WG Bras Basah SEC tokbind Token Binding WG Padang TSV quic QUIC WG 1550-1750 Afternoon Session II Padang IRTF*** t2trg Thing-to-Thing Olivia RTG bier Bit Indexed Explicit Replication WG Sophia SEC oauth Web Authorization Protocol WG WEDNESDAY, November 15, 2017 0930-1200 Morning Session I Sophia INT dnssd Extensions for Scalable DNS Service = Discovery WG Collyer INT ipwave IP Wireless Access in Vehicular = Environments WG - 0930-1030 Collyer INT *** lwig Light-Weight Implementation Guidance WG = - 1100-1200 Bras Basah IRTF icnrg Information-Centric Networking Canning TSV quic QUIC WG 1330-1500 Afternoon Session I Bras Basah ART uta Using TLS in Applications WG Collyer SEC *** teep A Protocol for Dynamic Trusted Execution = Environment Enablement BOF Orchard TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1650 Afternoon Session II Collyer INT intarea Internet Area Working Group WG Orchard SEC oauth Web Authorization Protocol WG THURSDAY, November 16, 2017 0930-1200 Morning Session I Collyer INT 6man IPv6 Maintenance WG Padang IRTF irtfopen IRTF Open Meeting Sophia RTG detnet Deterministic Networking WG Canning SEC tls Transport Layer Security WG 1330-1530 Afternoon Session I Sophia INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Collyer IRTF panrg Path Aware Networking Proposed RG Padang SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Sophia INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Canning RTG rtgarea Routing Area Open Meeting 1810-1910 Afternoon Session III Orchard SEC curdle CURves, Deprecating and a Little more = Encryption WG Padang TSV tsvarea Transport Area Open Meeting FRIDAY, November 17, 2017 0930-1130 Morning Session I Canning ART httpbis Hypertext Transfer Protocol WG Orchard RTG babel Babel routing protocol WG Collyer TSV tsvwg Transport Area Working Group WG 1150-1320 Afternoon Session I Olivia SEC acme Automated Certificate Management = Environment WG From nobody Sat Oct 14 02:56:50 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A89C1323B4; Sat, 14 Oct 2017 02:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 r2FHkt4ggfUC; Sat, 14 Oct 2017 02:56:27 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 0E5EE13307F; Sat, 14 Oct 2017 02:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9E9uJYD028675; Sat, 14 Oct 2017 11:56:19 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yDg2q2lbCzDMC7; Sat, 14 Oct 2017 11:56:19 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <6241D667-C2A1-41EF-83CB-D264BF9DFD3F@tzi.org> Date: Sat, 14 Oct 2017 11:56:18 +0200 X-Mao-Original-Outgoing-Id: 529667778.821235-c9d7eaa3be613be80ad8719f41133613 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6241D667-C2A1-41EF-83CB-D264BF9DFD3F@tzi.org> To: ace , "core@ietf.org WG" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [core] FIXED: Constrained Node/Network Cluster @ IETF100: DRAFT AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 14 Oct 2017 09:56:36 -0000 (Sorry for the resend; the previous version missed out on all meetings in the room "VIP A", and I didn't see those conflicts either.) Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF100. Remember that there is still quite some potential for changes. The CBOR/SUIT conflict needs to be fixed. Also, maybe CORE and 6TISCH are going to swap so we have more time between the two CORE meetings. ROLL vs. TEEP is a bit unfortunate, as is DINRG vs. LPWAN vs. DISPATCH. All times are SGT (UTC+0800). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten MONDAY, November 13, 2017 0930-1200 Morning Session I Collyer ART dispatch Dispatch WG - 0930-1100 Joint = with ARTAREA Collyer ART httpbis Hypertext Transfer Protocol WG - = 1100-1200 Olivia INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG VIP A IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Sophia OPS anima Autonomic Networking Integrated Model = and Approach WG 1330-1530 Afternoon Session I Olivia ART *** core Constrained RESTful Environments WG Padang OPS v6ops IPv6 Operations WG 1550-1720 Afternoon Session II Bras Basah ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Collyer INT homenet Home Networking WG Padang IRTF maprg Measurement and Analysis for Protocols Canning SEC *** suit Software Updates for Internet of Things = WG 1740-1840 Afternoon Session III Padang SEC tls Transport Layer Security WG Canning TSV tsvwg Transport Area Working Group WG TUESDAY, November 14, 2017 0930-1200 Morning Session I Collyer SEC *** ace Authentication and Authorization for = Constrained Environments WG Sophia TSV taps Transport Services WG 1330-1530 Afternoon Session I Olivia ART *** core Constrained RESTful Environments WG Canning OPS v6ops IPv6 Operations WG Bras Basah SEC tokbind Token Binding WG Padang TSV quic QUIC WG 1550-1750 Afternoon Session II Padang IRTF*** t2trg Thing-to-Thing Olivia RTG bier Bit Indexed Explicit Replication WG Sophia SEC oauth Web Authorization Protocol WG WEDNESDAY, November 15, 2017 0930-1200 Morning Session I Sophia INT dnssd Extensions for Scalable DNS Service = Discovery WG Collyer INT ipwave IP Wireless Access in Vehicular = Environments WG - 0930-1030 Collyer INT *** lwig Light-Weight Implementation Guidance WG = - 1100-1200 Bras Basah IRTF icnrg Information-Centric Networking Canning TSV quic QUIC WG 1330-1500 Afternoon Session I Bras Basah ART uta Using TLS in Applications WG VIP A RTG *** roll Routing Over Low power and Lossy = networks WG Collyer SEC *** teep A Protocol for Dynamic Trusted Execution = Environment Enablement BOF Orchard TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1650 Afternoon Session II Collyer INT intarea Internet Area Working Group WG VIP A IRTF cfrg Crypto Forum Orchard SEC oauth Web Authorization Protocol WG THURSDAY, November 16, 2017 0930-1200 Morning Session I Collyer INT 6man IPv6 Maintenance WG Padang IRTF irtfopen IRTF Open Meeting Sophia RTG detnet Deterministic Networking WG Canning SEC tls Transport Layer Security WG 1330-1530 Afternoon Session I Sophia INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Collyer IRTF panrg Path Aware Networking Proposed RG Padang SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II VIP A ART ice Interactive Connectivity Establishment = WG - 1550-1650 Sophia INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Canning RTG rtgarea Routing Area Open Meeting 1810-1910 Afternoon Session III Orchard SEC curdle CURves, Deprecating and a Little more = Encryption WG Padang TSV tsvarea Transport Area Open Meeting FRIDAY, November 17, 2017 0930-1130 Morning Session I Canning ART httpbis Hypertext Transfer Protocol WG Orchard RTG babel Babel routing protocol WG Collyer TSV tsvwg Transport Area Working Group WG 1150-1320 Afternoon Session I Olivia SEC acme Automated Certificate Management = Environment WG From nobody Mon Oct 16 01:31:20 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C057F13448C for ; Mon, 16 Oct 2017 01:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 l7-MeTqf8dYv for ; Mon, 16 Oct 2017 01:31:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9AD113448B for ; Mon, 16 Oct 2017 01:31:15 -0700 (PDT) Received: from [192.168.91.203] ([80.92.116.99]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LedVG-1dSAcY3eoQ-00qQlq; Mon, 16 Oct 2017 10:31:13 +0200 To: Simon Lemay Cc: "core@ietf.org WG" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Mon, 16 Oct 2017 10:31:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:bqosnMA4NGxqZhTawWYSj8mVAej8rnXbUv1mxg6+IypLoct8XSN fcGVX6AJWFFuXH00yBvfC4UqgNrxp87WvY7nj+NWYIUkNqPtEMr5cRtAPP0Vr/BFlMv/3cn V4aZKFTmk1v9r9FMfsrFwFEwF1DcR6xqQqrgUgp04eqURjoIZA3TuqIWmS37Wyr23LVSb9C SQ3544MW+Rd7iSsCGM9eg== X-UI-Out-Filterresults: notjunk:1;V01:K0:IaXmvMY1dj0=:Ef4rAIjWNZwoFbzjRb3SQn +zbbn16HIOXPux/h84MdM/tOK3KO27GEv0r7cCvBtLqnxebUKm7QX2phLChJmK2lFGibVoRm9 E2IInE42xeyDtMqSo6JMdosCWK2v77z0mqMJmtBTqHabzOpihinSHT3KsRrQRXP4j1LmL9Mia 1GhmwIOjvJZomIlAQTtFs3rn4exD43zdRhgBVHe71vaRgvaGwELjzOa9BoTGUZIY29g+qv4QZ 1J8Npo0JoC8YnqSxTUGRjOxzDM6V3xyaY17rrDP8v3oBXlXpjfu1J1EupHt90RHT0UC9Eq2od ey3Xc4oavDE4u7MVELelkFOsvvdg4R8+6QNaTJXJQmc5brgXJxFMAf/cxHQbrh+lT6yIS2VSJ u+7Kvgvw0qUWRSor3Ow7canTJRHHMvkpj8HCF4sElj94RLatfrXqjEyXgc2yQ4snYg/ESXMfl NcOMjAdeMjtQTP0YQmURWo8pF6gB8vUYi7ppRF/xmGQtba8QtkEmFfWvzEjBLZsOnZOSmXVsl cryFEwj1wuYZrmv+pXhwEzU8n5UPAKFgCtHYzktZ8QMH7bKm1lZUDz2HFUYVcauY5fiUTZsrd 3Qzl4iQlYWAZdO7ue+2KPEmWZhz9/rnYcs0orCPHAfhhdrEeCcRV9ZN272xP0mQxbhZx0FnXj 79itA0Y4zrAu/DhktPmSMnU0OsxraWUVoI+2mAaWtqQjb+vLSaj8klBb13UpPHwc15BZQ+Y0i F9iDkmKr2vrUtDWc1zJa+2A3+cnTVmX6v4S3M1Qvjme6XL3mYc6oRj6TScILFj6lqIoe9O1d/ UJWJ98EywSWNiYaprQ53r1Go/K16DkNUJ3RSFQbzkz523jWrzY= Archived-At: Subject: Re: [core] New intro to CoAP over TCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 16 Oct 2017 08:31:19 -0000 Thanks, Simon. I fixed all the issues you raised. On 10/13/2017 07:38 PM, Simon Lemay wrote: > I like it, comment inline > > On Fri, Oct 13, 2017 at 9:31 AM Hannes Tschofenig > > wrote: > > After a discussion with Jaime I wrote a new introduction for the CoAP > over TCP draft. Below is the new text. What do you think? > > ----- > > 1.  Introduction > >    The Constrained Application Protocol (CoAP) [RFC7252] was designed >    for Internet of Things (IoT) deployments, assuming that UDP [RFC0768] >    and DTLS [RFC6347] over UDP can be used unimpeded.  The use of CoAP >    over UDP is focused on simplicity, has a low code footprint, and a >    small over-the-wire message size. > >    The primary reason for introducing CoAP over TCP [RFC0793] and TLS >    [RFC5246] is that some networks drop UDP packets.  Complete blocking >    of UDP happens in between about 2% and 4% of terrestrial access >    networks, according to [EK2016].  UDP impairment is especially >    concentrated in enterprise networks and networks in geographic >    regions with otherwise challenged connectivity.  Some networks also >    rate-limit UDP traffic, as reported in [BK2015] and deployment >    investigations related to the standardization of QUIC revealed >    numbers around 0.3 % [SW2016]. > >    The introduction of CoAP over TCP also leads to some side effects, >    namely > >    o  Where NATs are present along the communication path, CoAP over TCP >       leads to different NAT traversal behavior than CoAP over UDP. >       NATs often calculate expiration timers based on the transport >       layer protocol being used by application protocols.  Many NATs >       maintain TCP-based NAT bindings for longer periods based on the >       assumption that a transport layer protocol, such as TCP, offers >       additional information about the session life cycle.  UDP, on the > >   > life cycle --> lifecycle  > >       other hand, does not provide such information to a NAT and >       timeouts tend to be much shorter [HomeGateway].  According to >       [HomeGateway] the mean between TCP and UDP NAT binding timeouts is >       386 minutes (TCP) and 160 seconds (UDP).  Shorter timeout values >       require keepalive messages to be sent more frequently.  Hence, the >       use of CoAP over TCP requires less frequent transmission of keep- >       alive messages. > >    o  TCP utilizes more sophisticated congestion and flow control >       mechanisms, which is useful for the transfer of larger payloads. >       In the context of IoT deployments such transfers could be firmware > >   > coma after deployments  > >       updates.  There is, however, ongoing work to add advanced >       congestion control to CoAP as well, see [I-D.ietf-core-cocoa]. > >    Note that the use of CoAP over UDP (and CoAP over DTLS over UDP) is >    still the recommended transport for use constrained node networks, >    particularly when used in concert with blockwise transfer.  CoAP over >    TCP is applicable for those cases where the networking infrastructure >    leaves no other choice.  The use of CoAP over TCP leads to a larger >    code size, more roundtrips, increased RAM requirements and larger >    packet sizes.  Developers implementing CoAP over TCP are encouraged >    to read [I-D.gomez-lwig-tcp-constrained-node-networks] for guidance >    on low-footprint TCP implementations for IoT devices. > >    Emerging standards such as Lightweight Machine to Machine [LWM2M] >    currently use CoAP over UDP as a transport and require support for >    CoAP over TCP to address the issues above and to protect investments >    in existing CoAP implementations and deployments. > >    Although HTTP/2 could also potentially address the need for >    enterprise firewall traversal, there would be additional costs and >    delays introduced by such a transition from CoAP to HTTP/2. > >    Currently, there are also fewer HTTP/2 implementations available for >    constrained devices in comparison to CoAP.  Since CoAP also support >    group communication using IP layer multicast and unreliable >    communication IoT devices would have to support HTTP/2 in addition to >    CoAP. > >    Furthermore, CoAP may be integrated into a Web environment where the >    front-end uses CoAP over UDP from IoT devices to a cloud >    infrastructure and then CoAP over TCP between the back-end services. >    A TCP-to-UDP gateway can be used at the cloud boundary to communicate >    with the UDP-based IoT device. > >    Finally, CoAP applications running inside a web browser without >    access to connectivity other than HTTP and the WebSocket protocol >    [RFC6455] may cross-proxy their CoAP requests via HTTP to a HTTP-to- >    CoAP cross-proxy or transport them via the the WebSocket protocol, >    which provides two-way communication between a WebSocket client and a >    WebSocket server after upgrading an HTTP/1.1 [RFC7230] connection. > > > this may be a bit heavy (long sentence), a possible rewording: > >  Finally, CoAP applications running inside a web browser may be without > access to connectivity other than HTTP.  In this case,  the WebSocket > protocol [RFC6455] may be used to either cross-proxy their CoAP requests > via HTTP to an HTTP-to-CoAP cross-proxy or transport them via the > WebSocket protocol. This would, in turn, provide two-way communication > between a WebSocket client and a WebSocket server after upgrading an > HTTP/1.1 [RFC7230] connection. > > >    To address the above-mentioned deployment requirements, this document >    defines how to transport CoAP over TCP, CoAP over TLS, and CoAP over >    WebSockets.  For these cases, the reliability offered by the >    transport protocol subsumes the reliability functions of the message >    layer used for CoAP over UDP.  (Note that both for a reliable >    transport and the CoAP over UDP message layer, the reliability >    offered is per transport hop: where proxies -- see Sections 5.7 and >    10 of [RFC7252] -- are involved, that layer's reliability function >    does not extend end-to-end.)  Figure 1 illustrates the layering: > >      +--------------------------------+ >      |          Application           | >      +--------------------------------+ >      +--------------------------------+ >      |  Requests/Responses/Signaling  |  CoAP (RFC 7252) / This Document >      |--------------------------------| >      |        Message Framing         |  This Document >      +--------------------------------+ >      |      Reliable Transport        | >      +--------------------------------+ > >             Figure 1: Layering of CoAP over Reliable Transports > >    This document specifies how to access resources using CoAP requests >    and responses over the TCP, TLS and WebSocket protocols.  This allows >    connectivity-limited applications to obtain end-to-end CoAP >    connectivity either by communicating CoAP directly with a CoAP server >    accessible over a TCP, TLS or WebSocket connection or via a CoAP >    intermediary that proxies CoAP requests and responses between >    different transports, such as between WebSockets and UDP. > >    Appendix A updates the "Observing Resources in the Constrained >    Application Protocol" [RFC7641] specification for use with CoAP over >    reliable transports.  [RFC7641] is an extension to the CoAP protocol >    that enables CoAP clients to "observe" a resource on a CoAP server. >    (The CoAP client retrieves a representation of a resource and >    registers to be notified by the CoAP server when the representation >    is updated.) > > ----- > > > The pull request is here: > https://github.com/core-wg/coap-tcp-tls/pull/187 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Mon Oct 16 04:25:36 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEA3132143; Mon, 16 Oct 2017 04:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01OdORrpWkjp; Mon, 16 Oct 2017 04:25:33 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 501F21270AB; Mon, 16 Oct 2017 04:25:32 -0700 (PDT) X-AuditID: c1b4fb2d-bf5ff7000000268d-af-59e4972ae241 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F3.2F.09869.A2794E95; Mon, 16 Oct 2017 13:25:30 +0200 (CEST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 16 Oct 2017 13:25:30 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oE31sThtXIk/7t6vSFZBuwqRlSgxWaMTnrWGTL5GL/g=; b=ct+meiNGjC3ShCSdDnvGGCcQtaaVU1wykPg1zvzHA4IO5d+IE7/wEDDCIDUWCfmwIELt+PUetnErXefm1IdHlzrEBqfsfyCOpiyONcVAsx4moZJv0b0bgWMoCKQ+GLNmXB+xH/Zd4ClNq4yr5ZJtVfrM3n2rxy5jzp4EAU3EYyM= Received: from HE1PR07MB1529.eurprd07.prod.outlook.com (10.169.122.151) by HE1PR07MB1531.eurprd07.prod.outlook.com (10.169.122.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Mon, 16 Oct 2017 11:25:28 +0000 Received: from HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::11af:c0a0:4d0d:d5f1]) by HE1PR07MB1529.eurprd07.prod.outlook.com ([fe80::11af:c0a0:4d0d:d5f1%13]) with mapi id 15.20.0077.019; Mon, 16 Oct 2017 11:25:28 +0000 From: Francesca Palombini To: Jim Schaad , "draft-ietf-core-object-security@ietf.org" CC: "core@ietf.org" Thread-Topic: Review draft-ietf-core-object-security-05 Thread-Index: AdNCDxflBrT2UulyTbeReHGbxp5RNgBPzWSAAA2toAAAKkyGgAAG/90AAImYPFA= Date: Mon, 16 Oct 2017 11:25:27 +0000 Message-ID: References: <011901d34257$27b8d950$772a8bf0$@augustcellars.com> <008501d34385$060c5820$12250860$@augustcellars.com> <011c01d3444a$37525e50$a5f71af0$@augustcellars.com> In-Reply-To: <011c01d3444a$37525e50$a5f71af0$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1531; 6:9Vq/bhtYGy1aNrHekheHoswgaLgj81/MdzVfDwxdDScP1ifaeFtIjQVVFaHfA7hxl2mxP5+KhnQENNZaKLvU/oWPi6366Pkn9IFxyliWt8i9b9OUWb1h8wfEynTiYeN1Kaaj8+rEsDeeIUW1CJR5+zofaZyLrAk3CZJOcjJBeBLq648IDeE5QqIm6MHBUHhkLpgrcm4UoLftyY5OwtdrVQ+Gz2V0IRLWenUg4WHM0VmSgHWtCjKbo1+MB1sO2Th+am0yxVOfJx4dzpcpd2bQscmZVhDSZAxbeGYxmR7xglclc6eBP7m9yu9QU0G3ca5L3Lymsno43C8tPpeFifZP3g==; 5:L9Ty73UOwbDrjxRjxJTWq1voX5HoFoD926SkOdSG07Xe4aWlMruVbQ7BPTVPCdR+pAy1OjV/boOdLuqjaZEWpPgPGF75dzQHCMsUxlo4xaZHuGIPHlCHuFGCC7KcLonMM8jFoBjgsuQWECbFfUPseY0Ay7r3Lce5NQFKUOrUKqY=; 24:WlRRTnq4AqllsMHtfJUo+xopZVzWYrum1CM1hpFc99eL1+NeOozZyiDhPtJDdkNRPxfXGp78Rqgg0IpTJ+nklvbtPqnGSnsR/HGilcIaw3Y=; 7:IK08TyHyMLdix/nPizmfVyVzqpTl0+ujt8fGuCWcSPNaj9UgqgF8b4ZOXx4TL8a4N/GBU/L+EKk41IUZqOh8uug09R72CwyFIRQCChGZIwdtio3rAK9esfTluRW0dL9A3VG/d+eYwLBEXImRNR9PrRHSuSytKj32jWDyOTq7K6yXvFASSf2E88WDanlBoSK6S1vxJYzYF3jKAiv7ONZwanaTA1GX9jUy8LbIot8fsAw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 19edeb86-3def-4ad7-b496-08d514889a6b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603219)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR07MB1531; x-ms-traffictypediagnostic: HE1PR07MB1531: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-exchange-antispam-report-test: UriScan:(37575265505322)(190756311086443)(158342451672863)(166708455590820)(192374486261705)(162968082949237)(788757137089)(211936372134217); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(920507026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB1531; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB1531; x-forefront-prvs: 0462918D61 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(39860400002)(346002)(53754006)(52584002)(377454003)(51914003)(377424004)(51444003)(13464003)(189002)(24454002)(199003)(5660300001)(6436002)(101416001)(81166006)(81156014)(316002)(105586002)(106356001)(6116002)(102836003)(3846002)(8936002)(93886005)(2906002)(50986999)(189998001)(55016002)(8676002)(6306002)(9686003)(99286003)(3660700001)(2900100001)(25786009)(76176999)(3280700002)(7696004)(15650500001)(86362001)(54356999)(110136005)(53936002)(68736007)(2501003)(74316002)(966005)(53546010)(5250100002)(229853002)(6506006)(33656002)(4326008)(66066001)(7736002)(97736004)(4001150100001)(34040400001)(478600001)(305945005)(2950100002)(6246003)(230783001)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1531; H:HE1PR07MB1529.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2017 11:25:27.9932 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1531 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0iTURjGOd9lfhsuTqb5MhVyEeRiMytqxQiNICMyoyDtQk39UFOn7FNJ QVr+UbnZUpDmZmUXEWyheU3MC03x2sU0RNJa4sTmJQuHkaHk9i3ov9/7Pu953uccDkP63aUl TKomm9Vq1OlSgYgyx70MkstMjvjdzsEwZediHam8t/6GUlpNvwSRZHT9fZMguqrqNxFLnBep ktj01FxWG374iijlx8KlrHE9ujbbpUM6VHIL6ZGQAbwPmheKSD0SMX64B4GppIvii34E1rdO 2l1Q+A4JzskR75iJgGX7ig9fTCN43tIgcJsJsAqGp5Y8R/xxIYLpB0bSLZB4O/RVdNNu3oL3 w83aDsLN/vgA/NQZaJ5jYKx+yGNE4R3g6ur19MX4IhhmzIjfVkSAbnLEE12II2F8yB1DyCAc Aq4bVu+yQPjkqCT462Goan9P8hwAzul1mudtMGfQCXgOgZFKg2cBYIsPzFcMewUFNJcuet/p JLTdbiX4oYcIHO/WvE4yqDbO0HyKRPg4YfThh2oRPB346nVKg+UaM8ULYzTMjY56hWD4vmAT lCC55b/oFsRscBjUtYXz7VAoM0z5WDzPsRkGzA7qEaKeoQCO5biM5D17Faw2NZHjMjUKDZvd gDa+yeumP/JWZJ2PsiHMIKmvuFHviPej1blcXoYNAUNK/cWKwo2WOEmdl89qMy9rc9JZzoaC GEoaKI7sHI7zw8nqbDaNZbNY7T+VYIQSHbruKs05s6uzhSs2Nk7AgD23zxTck3CI7T2WaEkq yD9o3/oh9MgmmUg1Y6p+4VvMyGPPLjkHXTUxF748sa9LwozG1lNldNPM6ePdnYrKMONsrG21 oD7G+i1G9aojAa8oK8eqRY9VRZ9Dz12Ncpjby7WDRklE/wmLcufq0bXyEinFpagjZKSWU/8F bEUIsCIDAAA= Archived-At: Subject: Re: [core] Review draft-ietf-core-object-security-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 16 Oct 2017 11:25:36 -0000 SGkgYWxsLA0KDQpXZSBhcmUgcGxhbm5pbmcgdG8gZGlzY3VzcyBKaW0ncyBjb21tZW50cyAoYW5k IHRoZSBsYXRlc3QgT1NDT0FQIHVwZGF0ZXMpIGluIGEgaGFuZ291dCBjYWxsIHRvZGF5ICgxNjow MCBDRVNUKS4NClNvcnJ5IGZvciB0aGUgc2hvcnQgbm90aWNlLiBXZWxjb21lIHRvIGpvaW4gaWYg eW91IGFyZSBpbnRlcmVzdGVkLg0KDQpUaW1lOiBodHRwczovL3d3dy53b3JsZHRpbWVidWRkeS5j b20vP3FtPTEmbGlkPTEwMCwyNjczNzMwLDgmaD0yNjczNzMwJmRhdGU9MjAxNy0xMC0xNiZzbG49 MTYtMTcgDQpIYW5nb3V0IGxpbms6IGh0dHBzOi8vaGFuZ291dHMuZ29vZ2xlLmNvbS9jYWxsLzJ6 dDRleXcyMnJkdTNuZWQ0eWE3MmFyaWZtZSANCg0KRnJhbmNlc2NhDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmltIFNjaGFhZCBbbWFpbHRvOmlldGZAYXVndXN0Y2Vs bGFycy5jb21dDQo+IFNlbnQ6IGRlbiAxMyBva3RvYmVyIDIwMTcgMTk6MzkNCj4gVG86IEfDtnJh biBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPjsgZHJhZnQtaWV0Zi1jb3Jl LW9iamVjdC0NCj4gc2VjdXJpdHlAaWV0Zi5vcmcNCj4gQ2M6IGNvcmVAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUkU6IFJldmlldyBkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LTA1DQo+IA0K PiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBHw7ZyYW4g U2VsYW5kZXIgW21haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb21dDQo+ID4gU2VudDog RnJpZGF5LCBPY3RvYmVyIDEzLCAyMDE3IDc6MTkgQU0NCj4gPiBUbzogSmltIFNjaGFhZCA8aWV0 ZkBhdWd1c3RjZWxsYXJzLmNvbT47IGRyYWZ0LWlldGYtY29yZS1vYmplY3QtDQo+ID4gc2VjdXJp dHlAaWV0Zi5vcmcNCj4gPiBDYzogY29yZUBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBSZXZp ZXcgZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS0wNQ0KPiA+DQo+ID4gSGkgSmltLA0K PiA+DQo+ID4gT24gMjAxNy0xMC0xMiAyMDowNywgIkppbSBTY2hhYWQiIDxpZXRmQGF1Z3VzdGNl bGxhcnMuY29tPiB3cm90ZToNCj4gPg0KPiA+ID5TZWUgaW5saW5lIC0gSSBoYXZlIHRyaW1tZWQg c29tZSBpdGVtcy4NCj4gPiA+DQo+ID4gPg0KPiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4gPj4gRnJvbTogR8O2cmFuIFNlbGFuZGVyIFttYWlsdG86Z29yYW4uc2VsYW5kZXJA ZXJpY3Nzb24uY29tXQ0KPiA+ID4+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDEyLCAyMDE3IDQ6 MzYgQU0NCj4gPiA+PiBUbzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47IGRy YWZ0LWlldGYtY29yZS1vYmplY3QtDQo+ID4gPj4gc2VjdXJpdHlAaWV0Zi5vcmcNCj4gPiA+PiBD YzogY29yZUBpZXRmLm9yZw0KPiA+ID4+IFN1YmplY3Q6IFJlOiBSZXZpZXcgZHJhZnQtaWV0Zi1j b3JlLW9iamVjdC1zZWN1cml0eS0wNQ0KPiA+ID4+DQo+ID4gPj4gSGkgSmltLA0KPiA+ID4+DQo+ ID4gPj4gTWFueSB0aGFua3MgZm9yIHRoZSByZXZpZXcuDQo+ID4gPj4NCj4gPiA+PiBBcyBtZW50 aW9uZWQgaW4gdGhlIGFubm91bmNlbWVudCB0aGlzIHZlcnNpb24gY29tcGlsZXMgYWxsIHRoZQ0K PiA+ID4+cHJvcG9zZWQgIGZpbmFsIGNoYW5nZXMsIGFuZCwgYWRtaXR0ZWRseSwgdGhlIHJhdGlv bmFsZSBmb3IgYWxsDQo+ID4gPj5wcm9wb3NhbHMgaGFzIG5vdCBiZWVuICBkaXNjdXNzZWQgaW4g ZGV0YWlsIHNvIGl0IGlzIGdvb2QgdGhhdCB3ZQ0KPiA+ID4+Y2FuIGRvIHRoYXQgb24gdGhlIG1h aWxpbmcgbGlzdCBub3cuDQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IEFuc3dlcnMgaW5saW5lIGFu ZCBhIGNvdXBsZSBvZiBxdWVzdGlvbnMgYmFjay4gU29tZSBvZiB0aGUgY29tbWVudHMNCj4gPiA+ PiBhcmUgYWxyZWFkeSBhZGRyZXNzZWQgaW4gaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvb3Nj b2FwDQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IE9uIDIwMTctMTAtMTEgMDg6MDYsICJKaW0gU2No YWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4gd3JvdGU6DQo+ID4gPj4NCj4gPiA+PiA+VGhp cyB1cGRhdGUgaGFkIGEgZmV3IHRoaW5ncyB0aGF0IGNhbWUgaW4gb3V0IG9mIGxlZnQgZmllbGQg YW5kDQo+ID4gPj4gPm1heWJlIGEgY291cGxlIG9mIHRoZW0gc2hvdWxkIGhhdmUgc3RheWVkIHRo ZXJlLg0KPiA+ID4+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4+ID4zLiAgU2VjdGlvbiAzLjEgLSBJ IGRvIG5vdCB1bmRlcnN0YW5kIHdoeSB5b3UgYXJlIG1ha2luZyB0aGUgU2VuZA0KPiA+ID4+ID5J RCBhbiBpbnRlZ2VyIHJhdGhlciB0aGFuIGEgYnl0ZSBzdHJpbmcuICBUaGVyZSBhcmUgYSBjb3Vw bGUgb2YNCj4gPiA+PiA+aXNzdWVzIHdpdGggdGhpcy4NCj4gPiA+PiA+Rmlyc3QgaXQgaXMgdGhv dWdodCBvZiBhcyBhIGJ5dGUgc3RyaW5nIGV2ZXJ5d2hlcmUgdGhhdCBpdCBpcw0KPiA+ID4+ID5j dXJyZW50bHkgcGFzc2VkIGFyb3VuZCAtIGluIENPU0UgYW5kIGluIEFDRS4gIFNlY29uZGx5LCBp dA0KPiA+ID4+ID5kZWNyZWFzZXMgdGhlIG51bWJlciBvZiBpZHMgdGhhdCBhcmUgcG9zc2libGUg YXMgaCcwMScgYW5kIGgnMDAwMScNCj4gPiA+PiA+YXJlIGRpc3RpbmN0IHdoaWxlIDEgYW5kDQo+ ID4gPj4gPjEgYXJlIG5vdC4NCj4gPiA+Pg0KPiA+ID4+IEluIG9yZGVyIHRvIGVhc2lseSB2ZXJp ZnkgdW5pcXVlbmVzcyBvZiAoa2V5LCBub25jZSkgcGFpcnMgaW4gdGhlDQo+ID4gPj5jdXJyZW50 IHNldHVwICB3aXRoIGEgY29tbW9uIElWIGFuZCB0aGUgcmV1c2Ugb2Ygbm9uY2UgaW4gcmVzcG9u c2VzDQo+ID4gPj4oYWxzbyBpbiB0aGUgZ3JvdXAgIGNvbW11bmljYXRpb24gc2V0dGluZykgdGhl IFNlbmRlciBJRCBpcyBub3cNCj4gPiA+PmluY2x1ZGVkIGluIHRoZSBub25jZSAgZ2VuZXJhdGlv bi4gV2l0aCB0aGlzIGNvbnN0cnVjdGlvbiwgYWxsDQo+ID4gPj5ub25jZXMgY29taW5nIGZyb20g YSBwYXJ0aWN1bGFyIHNlbmRlciAgaGFzIGEgY2VydGFpbiBwcmVmaXgsIHdoaWNoDQo+ID4gPj53 aWxsIG5vdCBjb2luY2lkZSB3aXRoIGEgbm9uY2UgZ2VuZXJhdGVkIGJ5ICBhbm90aGVyIHNlbmRl ci4NCj4gPiA+DQo+ID4gPlVuaXF1ZW5lc3MgY291bGQgZWFzaWx5IGJlIHRlc3RlZCBhZnRlciBs ZWZ0IHBhZGRpbmcgd2l0aCB6ZXJvcyBpZg0KPiA+ID50aGF0IGlzIHJlYWxseSBzb21ldGhpbmcg dGhhdCBuZWVkcyB0byBiZSBkb25lLg0KPiA+DQo+ID4gSSBkb27igJl0IHVuZGVyc3RhbmQgaG93 IHVuaXF1ZW5lc3MgY2FuIGJlIHRlc3RlZCBhZnRlciBsZWZ0IHBhZGRpbmcNCj4gPiB3aXRoIHpl cm9lcyAtIHdvdWxkIG5vdCB0aGF0IG9uIHRoZSBjb250cmFyeSByZW1vdmUgdGhlIGRpZmZlcmVu Y2UNCj4gPiBiZXR3ZWVuIHRoZW0/DQo+IA0KPiBJIHdhcyBnaXZpbmcgYW4gZXhhbXBsZSBvZiBo b3cgeW91IGNvdWxkIHRlc3QgZm9yIHVuaXF1ZW5lc3MgdXNpbmcgYSBieXRlDQo+IGFycmF5IHJh dGhlciB0aGFuIGFuIGludGVnZXIuICBJIHRob3VnaHQgdGhhdCB3YXMgd2hhdCB5b3Ugd2VyZSBs b29raW5nIGF0DQo+IGhlcmUuDQo+IA0KPiA+DQo+ID4gPg0KPiA+ID4+DQo+ID4gPj4gVGhlIHR3 byBieXRlIHN0cmluZ3MgeW91IG1lbnRpb24gYXJlIGRpc3RpbmN0LCBidXQgd291bGQgYWxzbyBu ZWVkDQo+ID4gPj50byBiZSAgbWFwcGVkIHRvIGRpc3RpbmN0IGJ5dGUgc3RyaW5ncyBvZiBmaXhl ZCBsZW5ndGggaW4gb3JkZXIgdG8NCj4gPiA+PmRvIHRoZSBYT1Igd2l0aCAgdGhlIGNvbW1vbiBJ Vi4gV2l0aCBTZW5kZXIgSUQgYmVpbmcgYW4gaW50ZWdlciB0aGUNCj4gPiA+PnVuaXF1ZW5lc3Mg cHJvcGVydHkgaXMgIGVhc2llciB0byBlc3RhYmxpc2guIFN0aWxsIHRoZSBTSUQgaXMNCj4gPiA+ PmNvbnZlcnRlZCBpbnRvIGEgQ0JPUiBieXRlIHN0cmluZyB3aGVuICB1c2VkLiBJIGFkZGVkIHRl eHQgb24gdGhhdC4NCj4gPiA+DQo+ID4gPkZvciB0aGlzIGRvY3VtZW50IHRoYXQgaXMgbm90IGEg c3RyaWN0IHJlcXVpcmVtZW50IHRoYXQgSSBjYW4gc2VlLg0KPiA+ID5HaXZlbiB0aGF0IHRoZSBr ZXlzIGFyZSBnb2luZyB0byBiZSBkaXN0aW5jdCwgdGhlIGZhY3QgdGhhdCB0aGUgc2FtZQ0KPiA+ ID5JVnMgYXJlIGJlaW5nIHVzZWQgaXMgbm90IGEgcHJvYmxlbS4gIFRoZSBvbmx5IGlzc3VlIHdv dWxkIGJlIGlmIGJvdGgNCj4gPiA+dGhlIHNlbmRlciBhbmQgdGhlIHJlY2lwaWVudCBoYWQgdGhl IHNhbWUgaWRlbnRpZmllciBhZnRlciBwYWRkaW5nDQo+ID4gPmhhcw0KPiA+IGJlZW4gYWRkZWQu DQo+ID4gPkluIHRoYXQgY2FzZSBvbmUgY291bGQgbm90IGVhc2lseSBkaXN0aW5ndWlzaCBiZXR3 ZWVuIHJlZmxlY3Rpb24gYW5kDQo+ID4gPm5vbi1yZWZsZWN0aW9uIGNhc2VzIGJhc2VkIG9uIHRo ZSBJViBieSBpdHNlbGYuICBIb3dldmVyIHRoYXQgc2hvdWxkDQo+ID4gPm5vdCBiZSBhIHByb2Js ZW0gYXMgd2UgZG9uJ3QgZGlzdGluZ3Vpc2ggdGhvc2UgY2FzZXMgdXNpbmcgdGhlIElWDQo+ID4g PnRvZGF5LiAgVGhlIGtpZCBpcyB1c2VkIGFuZCB0aG9zZSB3b3VsZCBiZSBkaXN0aW5jdC4NCj4g PiA+DQo+ID4gPklmIHRoaXMgaXMgYSByZWFsIHJlc3RyaWN0aW9uLCBpdCBjb3VsZCBiZSBhZGRl ZCBhcyBhbiBhZGRpdGlvbmFsDQo+ID4gPnJlc3RyaWN0aW9uIGZvciB0aGUgZ3JvdXAgZG9jdW1l bnQgYW5kIGlnbm9yZWQgaGVyZS4NCj4gPiA+DQo+ID4NCj4gPiBMZXTigJlzIGdvIG92ZXIgdGhl IGRpZmZlcmVudCBjYXNlcy4gRWFjaCBlbmRwb2ludCBoYXMgYSB1bmlxdWUga2V5IGZvcg0KPiA+ IHNlbmRpbmcuIFRoZSBrZXkgaXMgdXNlZA0KPiA+DQo+ID4gMS4gdG8gcHJvdGVjdCBhIHJlcXVl c3QgKGluIHRoZSByb2xlIG9mIGNsaWVudCkgMi4gdG8gcHJvdGVjdCBhbg0KPiA+IG9yZGluYXJ5 IHJlc3BvbnNlIChpbiB0aGUgcm9sZSBvZiB0aGUgc2VydmVyKSAzLiB0byBwcm90ZWN0IGENCj4g PiBub3RpZmljYXRpb24gKGluIHRoZSByb2xlIG9mIHRoZSBzZXJ2ZXIsIGluIHRoZSBjYXNlIG9m DQo+ID4gT2JzZXJ2ZSkNCj4gPg0KPiA+IEluIGNhc2UgMSBhbmQgMywgdGhlIGVuZHBvaW50IGlz IGluIGNvbnRyb2wgb2YgdGhlIFBhcnRpYWwgSVYgdXNlZCBpbiB0aGUNCj4gbm9uY2UuDQo+ID4g QnV0IGluIGNhc2UgMiBpdCBpcyBub3QsIHNpbmNlIHRoZSBzYW1lIG5vbmNlIGlzIHVzZWQgYXMg aW4gdGhlDQo+ID4gcmVxdWVzdCBpdCBpcyByZXNwb25kaW5nIHRvLiBTbyBldmVuIGluIHRoZSBj YXNlIG9mIG5laXRoZXIgZ3JvdXANCj4gPiBjb21tdW5pY2F0aW9uIG5vciBvYnNlcnZlLCB3ZSBu ZWVkIHRvIGVuc3VyZSB0aGF0IHRoZSBub25jZSB1c2VkIGluDQo+ID4gdGhlIHJlcXVlc3QgaXMg ZGlzdGluY3QgZnJvbSB0aGUgbm9uY2UgdXNlZCBpbiBhIHJlc3BvbnNlLiBJbiAtMDQgdGhlDQo+ ID4gZmlyc3QgYml0IG9mIHRoZSBub25jZSB3YXMgdXNlZCB0byBwYXJ0aXRpb24gdGhlIElWLXNw YWNlLiBJbiAtMDUgdGhlDQo+ID4gc2VuZGVyIElEIGlzIGluY2x1ZGVkIGluIHRoZSBub25jZSBn ZW5lcmF0aW9uIHN1Y2ggdGhhdCBub25jZXMNCj4gPiBnZW5lcmF0ZWQgYnkgZGlmZmVyZW50IHNl bmRlcnMgYmVjb21lIGRpZmZlcmVudCBieSBjb25zdHJ1Y3Rpb24sIGFuZCB0aGVuDQo+IGl0IGF1 dG9tYXRpY2FsbHkgYXBwbGllcyB0byBncm91cHMuDQo+ID4NCj4gPiBPbmUgd2F5IHRvIGdlbmVy YXRlIGEgZ3JvdXAgaXMgdG8gc3RhcnQgd2l0aCB0d28gZW5kcG9pbnRzIGFuZCB0aGVuDQo+ID4g YWRkIG1vcmUgZW5kcG9pbnRzIGFzIHlvdSBnby4gSW4gdGhhdCBjYXNlIHRoZXJlIGlzIGFuIGFk dmFudGFnZSBpZg0KPiA+IHRoZSBzYW1lIGhhbmRsaW5nIG9mIHNlY3VyaXR5IGNvbnRleHQgYXBw bGllcyB0byBwb2ludC10by1wb2ludCBhcyBncm91cHMuDQo+IA0KPiBCdXQgaW4gdGhhdCBjYXNl IHlvdSB1bmRlcnN0YW5kIGluIGFkdmFuY2UgdGhhdCB5b3UgYXJlIGdvaW5nIHRvIGNyZWF0ZSBh DQo+IGdyb3VwIGFuZCBjYW4gYXBwbHkgYW55IHJlc3RyaWN0aW9ucyBmcm9tIHRoZSBzdGFydC4g IEFub3RoZXIgd2F5IHRvIGNyZWF0ZSBhDQo+IGdyb3VwIGlzIHRvIG1lcmdlIHR3byBncm91cHMg dG9nZXRoZXIgYW5kIHJlLWtleSwgdGhhdCB3b3VsZCBub3QgbmVjZXNzYXJpbHkNCj4gd29yayBi ZWNhdXNlIHlvdSBtaWdodCBoYXZlIGFzc2lnbmVkIHRoZSBzYW1lIGlkIGluIGJvdGggY2FzZXMu ICBJZiB0aGUgdHdvDQo+IGdyb3VwcyB1c2VkIGRpZmZlcmVudCBsZW5ndGggaWRzIHRoZW4gaXQg d291bGQgYmUgcG9zc2libGUuDQo+IA0KPiBUaGVyZSBhcmUgbG90cyBvZiB3YXlzIHRvIGNyZWF0 ZSBncm91cHMgdGhhdCBhcmUgZ29pbmcgdG8gaGF2ZSBwcm9ibGVtcyB3aXRoDQo+IGhvdyBJRHMg YXJlIGFzc2lnbmVkIHVubGVzcyB0aGVyZSBpcyBhbiBpbnRlbnQgdGhhdCBhIGdyb3VwIGlzIGdv aW5nIHRvIGJlDQo+IGNyZWF0ZWQgZnJvbSB0aGUgc3RhcnQuDQo+IA0KPiBBIGRpZmZlcmVudCB3 YXkgdG8gZG8gdGhlIHNhbWUgdGhpbmcgaW4gdGVybXMgb2YgYnVpbGRpbmcgdGhpbmdzIHdvdWxk IGJlDQo+IA0KPiBYWCBZWVlZIFpaDQo+IA0KPiBXaGVyZSBYWCBpcyB0aGUgbGVuZ3RoIG9mIGtp ZA0KPiBZWVkgaXMgdGhlIGtpZCBwYWRkZWQgKGVpdGhlciByaWdodCBvciBsZWZ0KSB3aXRoIGEg Y29uc3RhbnQgYW5kIFpaIGlzIHRoZSBwYXJ0aWFsDQo+IElWLg0KPiANCj4gT25lIGNvdWxkIHBs YXkgZ2FtZXMgYW5kIGFzc2lnbiBhIHBhZGRpbmcgdmFsdWUgb24gYSBwZXIgcmVjaXBpZW50IGJh c2lzDQo+IHdoaWNoIGNvdWxkIGJlIHVzZWQgZm9yIGFsbCBzb3J0cyBvZiBzZXBhcmF0aW9uIG9m IHNwYWNlcy4gICAgSSBsb3N0IG9uZSBieXRlIGF0DQo+IHRoZSBmcm9udCBmcm9tIHRoZSBsZW5n dGggb2YgSUQsIGJ1dCBJIGdvdCBhIGxvdCBtb3JlIGtpZCB2YWx1ZXMgZnJvbSBqdXN0IHVzaW5n DQo+IGFuIGludGVnZXIgdmFsdWUgZm9yIHNob3J0ZXIga2lkcy4NCj4gDQo+IA0KPiA+ID4+ID45 LiAgU2VjdGlvbiA1IC0gSSB3b3VsZCBsaWtlIHRvIGhhdmUgdGhlIFBhcnRpYWwgSVYgaGF2ZSBh IGxlbmd0aA0KPiA+ID4+ID5vZg0KPiA+ID4+ID4xDQo+ID4gPj5pbg0KPiA+ID4+ID50aGUgZXZl bnQgdGhhdCB0aGUgcGFydGlhbCBpdiBpcyB6ZXJvLiAgIERpdHRvIGtpZA0KPiA+ID4+DQo+ID4g Pj4gVGhlIGludGVudCBoZXJlIGlzIHRvIHNhdmUgdGhlc2UgYnl0ZXMsIGlzIHRoZXJlIGFuIGlz c3VlPw0KPiA+ID4NCj4gPiA+U2F2aW5nIG9uZSBieXRlIGluIHRoaXMgY2FzZSBkb2VzIG5vdCBz ZWVtIHRvIGJlIHRoYXQgdXNlZnVsLg0KPiA+ID5Gb3IgdGhlIElWIGl0IHdvdWxkIG9ubHkgYXBw bHkgdG8gYSBzaW5nbGUgbWVzc2FnZS4gSGF2aW5nIGEgdmFsdWUNCj4gPiA+Zm9yIGNvbnNpc3Rl bmN5IGlzIHByb2JhYmx5IG1vcmUgaGVscGZ1bC4NCj4gPg0KPiA+IEkgd291bGQgYWdyZWUgZm9y IHRoZSBQYXJ0aWFsIElWIHNpbmNlIHRoaXMgaXMgYSBzaW5nbGUgbWVzc2FnZSBpbiBhDQo+ID4g cG90ZW50aWFsbHkgbG9uZyBleGNoYW5nZSBvZiBtZXNzYWdlcy4gSG93ZXZlciwgZm9yIHRoZSBr aWQsIHdoZXJlIHRoZQ0KPiA+IGNsaWVudCB3b3VsZCB0eXBpY2FsbHkgdXNlIGtpZD0wIHRoaXMg d291bGQgYmUgZXZlcnkgbWVzc2FnZSBzZW50Lg0KPiA+IFdpdGggaXNzdWUgIzE3OSwga2lkIHdv dWxkIGFueXdheSBiZSB0cmVhdGVkIGRpZmZlcmVudGx5LCBzbyBpdCBzaG91bGQNCj4gPiBub3Qg bWF0dGVyIGlmIHRoZXNlIHR3byBwYXJhbWV0ZXJzIGFyZSBoYW5kbGVkIGRpZmZlcmVudGx5LiBX b3VsZCB5b3UNCj4gPiBiZSBPSyB3aXRoIG9ubHkgYXBwbHlpbmcgdGhpcyB0byB0aGUgUGFydGlh bCBJVj8NCj4gPg0KPiA+IGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL29zY29hcC9pc3N1ZXMv MTgwDQo+IA0KPiBJZiB5b3Ugb21pdCB0aGUgZmxhZyBmb3IgZXhpc3RlbmNlLCB0aGVuIHlvdSB3 b3VsZCBuZWVkIHRvIGhhdmUgdGhlIGJ5dGUgZm9yDQo+IGV4aXN0ZW5jZSBpbiB0aGUgb3B0aW9u LiAgSGF2aW5nIHRoZSBmbGFnIG5vdCB3aXRoIHRoZSB2YWx1ZSBpcyBub3Qgc29tZXRoaW5nDQo+ IHRoYXQgSSB3b3VsZCBwcmVmZXIuDQo+IA0KPiA+ID4+ID4xMC4gIFNlY3Rpb24gNSAtIFRoZSBy dWxlIG9mIHRoZSBTSEFMTCBOT1QgZm9yIFBhcnRpYWwgSVYgd29ycmllcw0KPiA+ID4+ID5tZSBm b3IgZ3JvdXAgbWVzc2FnaW5nLiAgSXQgbWF5IGNhdXNlIHByb2JsZW1zIHlvdSBkb24ndCB3YW50 Lg0KPiA+ID4+ID5UaGVyZSBhcmUgbm8gcmVhbCBwcm9ibGVtcywgZXhjZXB0IGZvciBvcHRpbWl6 YXRpb24sIHRvIHVzaW5nIHRoZQ0KPiA+ID4+ID5yZWZsZWN0ZWQgUGFydGlhbCBJViB2YWx1ZS4N Cj4gPiA+PiA+UGxlYXNlIHJldGhpbmsgdGhpcy4gIERpdHRvIGtpZA0KPiA+ID4+DQo+ID4gPj4g Rm9yIGdyb3VwIGNvbW11bmljYXRpb24sIHRoZSBjdXJyZW50IGNvbnN0cnVjdGlvbiBuZXZlciBy ZXF1aXJlcyBhDQo+ID4gPj5QYXJ0aWFsICBJViBpbiB0aGUgcmVzcG9uc2UuIChUaGF0IGRyYWZ0 IG5lZWRzIHRvIGJlIHVwZGF0ZWQuKSBCdXQNCj4gPiA+PmtpZCBpcyBuZWVkZWQgaW4gdGhlICBy ZXNwb25zZS4NCj4gPiA+DQo+ID4gPklzIHRoYXQgdHJ1ZSBpZiB0aGVyZSB3ZXJlIGFuIG9ic2Vy dmUgaW4gdGhlIGdyb3VwIGNvbW11bmljYXRpb24/DQo+ID4NCj4gPiBBY2NvcmRpbmcgdG8gUkZD NzM5MCBDb0FQIE9ic2VydmUgZG9lcyBub3Qgc3VwcG9ydCBhIGdyb3VwDQo+ID4gY29tbXVuaWNh dGlvbiBtb2RlLCBzbyB3ZSBkaWRu4oCZdCBoYXZlIHRoYXQgYXMgcGFydCBvZiB0aGUgZGVzaWdu IGdvYWxzLg0KPiANCj4gSSB3b3VsZCBkZXNpZ24gd2l0aCB0aGlzIGluIG1pbmQgZ2l2ZW4gdGhl IGRpZmZlcmVudCB3YXlzIHRoYXQgdGhpcyBtaWdodCBjb21lDQo+IGFib3V0LiAgSSB0aGluayB0 aGF0IGFuIG9ic2VydmUgdHlwZSB0aGluayBpbiBncm91cCBjb21tdW5pY2F0aW9ucyBtaWdodCBl bmQNCj4gdXAgY29taW5nIGludG8gZXhpc3RlbmNlLiAgSSB3b3VsZCBkbyBhIGRlZmVuc2l2ZSBk ZXNpZ24gbXlzZWxmLg0KPiANCj4gPiA+PiBJbiBwcmV2aW91cyB2ZXJzaW9ucyBvZiB0aGUgdHdv IGRyYWZ0cywgd2UgaGF2ZSBoYWQgbm9ybWF0aXZlIHRleHQNCj4gPiA+PmluIHRoZSAgT1NDT0FQ IGRyYWZ0IHdoaWNoIHdhcyBjb250cmFkaWN0ZWQgaW4gdGhlIGNhc2Ugb2YgZ3JvdXANCj4gPiA+ Pk9TQ09BUCwgYnV0ICBtYXliZSBpdCBpcyBiZXR0ZXIgdG8gcmVsYXggdGhlIE9TQ09BUCBzcGVj aWZpY2F0aW9uPw0KPiA+ID4+DQo+ID4gPj4gSSBtYWRlIHRoZSBmb2xsb3dpbmcgY2hhbmdlIG9u IEdpdGh1YjoNCj4gPiA+Pg0KPiA+ID4+IC0ga2VlcCDigJxQYXJ0aWFsIElWIFNIQUxMIE5PVCBi ZSBwcmVzZW50IGluIHJlc3BvbnNlc+KAnQ0KPiA+ID4+IC0gcmVwbGFjZSBraWQgIlNIQUxMIE5P VCBiZSBwcmVzZW50IGluIHJlc3BvbnNlc+KAnSB0byDigJxNQVkgYmUNCj4gPiA+PiBvbWl0dGVk IGluIHJlc3BvbnNlcyINCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+PiA+MTEuICBTZWN0 aW9uIDUuMSAtIERvZXMgdGhpcyBtZWFuIHRoYXQgdGhlIFBhcnRpYWwgSVYgaXMgbGltaXRlZA0K PiA+ID4+ID50bw0KPiA+ID4+ID4yXig1KjgpDQo+ID4gPj4gPmRpZmZlcmVudCB2YWx1ZXM/DQo+ ID4gPj4NCj4gPiA+PiBZZXMuDQo+ID4gPj4NCj4gPiA+PiA+SWYgeW91IGV4Y2VlZCB0aGlzIGlz IGEgbmV3IGNvbnRleHQgcmVxdWlyZWQgb3IgZG8geW91IHdyYXAgb3INCj4gPiA+PiA+c29tZXRo aW5nIGVsc2U/DQo+ID4gPj4NCj4gPiA+PiBOZXcgY29udGV4dC4gVGhlIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIHN0YXRlIHRoZSBtYXhpbXVtIHNlcXVlbmNlDQo+ID4gPj4gbnVtYmVyLCBJIGFk ZGVkIHRleHQgYWJvdXQgbmV3IGNvbnRleHQuDQo+ID4gPg0KPiA+ID5KdXN0IHNvIHdlIGFyZSBj bGVhciwgdGhpcyBtYXkgYmUgYSBzbWFsbGVyIG51bWJlciB0aGF0IGlzIGltcG9zZWQgYnkNCj4g PiA+dGhlIGFsZ29yaXRobS4NCj4gPg0KPiA+IFJpZ2h0LiBTZWN1cml0eSBjb25zaWRlcmF0aW9u IHJlYWRzOg0KPiA+DQo+ID4gIlRoZSBtYXhpbXVtIHNlbmRlciBzZXF1ZW5jZSBudW1iZXIgaXMg ZGVwZW5kZW50IG9uIHRoZSBBRUFEDQo+ID4gYWxnb3JpdGhtLg0KPiA+IFRoZSBtYXhpbXVtIHNl bmRlciBzZXF1ZW5jZSBudW1iZXIgU0hBTEwgYmUgMl40MCAtIDEsIG9yIGFueQ0KPiBhbGdvcml0 aG0NCj4gPiBzcGVjaWZpYyBsb3dlciBsaW1pdCwgYWZ0ZXIgd2hpY2ggYSBuZXcgc2VjdXJpdHkg Y29udGV4dCBtdXN0IGJlIGdlbmVyYXRlZC4NCj4gPiBUaGUgY29tcHJlc3Npb24gbWVjaGFuaXNt IGFzc3VtZXMgdGhhdCB0aGUgUGFydGlhbCBJViBpcyA0MCBiaXRzIG9yIGxlc3MuIg0KPiANCj4g SXQgaXMgbm90IHRoZSBjb21wcmVzc2lvbiBtZWNoYW5pc20gdGhhdCBpcyBhc3N1bWluZyB0aGlz LCBpdCBpcyB0aGUgbWV0aG9kDQo+IGZvciBidWlsZGluZyBub25jZXMgdGhhdCBpcyBhc3N1bWlu ZyB0aGlzLg0KPiANCj4gPg0KPiA+DQo+ID4gRG8geW91IG1pc3MgYW55dGhpbmcgdGhlcmU/DQo+ ID4NCj4gPiA+DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+ID4NCj4gPiA+PiA+MTIuIFNlY3Rpb24g NS4xIC0gd2hhdCBpcyB0aGUgcHVycG9zZSBvZiBwdXR0aW5nIHRoZSBJRCBvZiB0aGUgUElWDQo+ ID4gPj4gPmdlbmVyYXRvcg0KPiA+ID4+ID5pbiB0aGUgbm9uY2UgdmFsdWU/ICBQbGVhc2UgcHV0 IGluIHRleHQgdGhhdCB3aWxsIGp1c3RpZnkgdGhpcy4gICBHaXZlbg0KPiA+ID4+ID50aGF0DQo+ ID4gPj4gPnRoZSBrZXlzIGFyZSBkaWZmZXJlbnQsIGlzIHRoZXJlIGFueSBuZWVkIGZvciB0aGlz Pw0KPiA+ID4+DQo+ID4gPj4gQXMgZGlzY3Vzc2VkIGFib3ZlLCB0aGlzIG1ha2VzIGl0IGVhc3kg dG8gdmVyaWZ5IHRoZSAoa2V5LCBub25jZSkNCj4gPiA+PnVuaXF1ZW5lc3MuDQo+ID4gPj4NCj4g PiA+Pg0KPiA+ID4+DQo+ID4gPj4gPg0KPiA+ID4+ID4xNC4gIFNlY3Rpb24gNS4zIC0gWW91IG5l ZWQgYSBydWxlIGZvciBvcHRpb25zIGZvciBkZWFsaW5nIHdpdGggYQ0KPiA+ID4+ID5yZXBlYXRl ZCBvcHRpb24uDQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IFdoeSBpcyByZXBlYXRlZCBDbGFzcyBJ IG9wdGlvbnMgYW4gaXNzdWU/DQo+ID4gPg0KPiA+ID5PcmRlciBvZiB0aGUgb3B0aW9ucyBpcyBu b3QgdW5pcXVlbHkgZGVmaW5lZCBhdCBwcmVzZW50LiAgT25lIHdpbGwNCj4gPiA+YWx3YXlzIG9y ZGVyIHRoZSBvcHRpb24gbnVtYmVyIGluIGluY3JlYXNpbmcgb3JkZXIgZHVlIHRvIHRoZSBkZWx0 YQ0KPiA+ID5lbmNvZGluZywgaG93ZXZlciBpZiB5b3UgaGF2ZSBmb289ZGVsdGE7Zm9vPWJhciBh bmQgdGhleSBhcmUNCj4gPiA+cmUtb3JkZXJlZCBieSBhbiBpbnRlcm1lZGlhcnkgdGhlbiB2YWxp ZGF0aW9uIHdvdWxkIGZhaWwuDQo+ID4NCj4gPiBZb3UgYXJlIHJpZ2h0LCB0aGF0IGlzIGluZGVl ZCBzcGVjaWZpY2FsbHkgZm9yIGNsYXNzIEkgb3B0aW9ucywgSSBvcGVuZWQgYW4NCj4gaXNzdWU6 DQo+ID4NCj4gPiBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9vc2NvYXAvaXNzdWVzLzE4MQ0K PiA+DQo+ID4gU2luY2UgdGhlcmUgYXJlIG5vIG9wdGlvbnMgb2YgdGhpcyBraW5kIHlldCwgSSBh bSB0ZW1wdGVkIHRvIGxlYXZlDQo+ID4gdGhpcyBhcyBhIHJlcXVpcmVtZW50IGZvciB0aG9zZSBp bnRyb2R1Y2luZyB0aGUgbmV3IHJlcGVhdGFibGUgQ2xhc3MgSQ0KPiA+IG9wdGlvbiB0byBhbHNv IGRlZmluZSBhbiBvcmRlcmluZyBvZiB0aGUgb3B0aW9uIHZhbHVlcy4NCj4gDQo+IFJpZ2h0LCBh bmQgZWFjaCBvbmUgY291bGQgZGVmaW5lIGEgZGlmZmVyZW50IG1lY2hhbmlzbS4gIFRoaXMgaXMg bm90IHdoYXQgSQ0KPiB3YW50IHRvIGhlcmUuDQo+IA0KPiANCj4gSmltDQo+IA0KPiA+DQo+ID4g Pg0KPiA+ID4+ID4xNi4gU2VjdGlvbiA3LjQgc3RlcCA4IC0gSXQgd291bGQgYXBwZWFyIHRoYXQg aWYgdGhlcmUgaXMgYW4gaW5uZXINCj4gPiA+PiA+b3B0aW9uIHdoaWNoIGlzIHByZXNlbnQgb24g dGhlIG91dGVyIG1lc3NhZ2UgYnV0IG5vdCBwcmVzZW50IG9uDQo+ID4gPj4gPnRoZSBpbm5lciBt ZXNzYWdlLCB0aGVuIGl0IHdvdWxkIG5vdCBiZSByZW1vdmVkLiAgSXMgdGhhdCB3aGF0IGlzDQo+ IGRlc2lyZWQ/DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IEl0IHdvdWxkIGFscmVhZHkgYmUgcmVt b3ZlZCBpbiBzdGVwIDI6DQo+ID4gPj4NCj4gPiA+PiDigJwyLiBEaXNjYXJkIHRoZSBtZXNzYWdl IENvZGUgYW5kIGFsbCBub24tc3BlY2lhbCBDbGFzcyBFIG9wdGlvbnMNCj4gPiA+PmZyb20gdGhl ICBtZXNzYWdlLiINCj4gPiA+DQo+ID4gPkl0IHdvdWxkIGJlIGVhc2llciB0byB1bmRlcnN0YW5k IGlmIHRoZXNlIHJ1bGVzIGFyZSBjb21iaW5lZC4NCj4gPg0KPiA+IFdlIGNvdWxkIG1vdmUgc3Rl cCAyIHRvIGEgbmV3IHN0ZXAgNy4gVGhhdCwgaG93ZXZlciwgd291bGQgcG90ZW50aWFsbHkNCj4g PiBtYWtlIGl0IG1vcmUgZGlmZmljdWx0IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gcHJlLWV4aXN0 aW5nIG91dGVyDQo+ID4gb3B0aW9ucyBhbmQgZGVjcnlwdGVkIG9wdGlvbnMgKGluIHN0ZXAgMiB0 aGVyZSBleGlzdHMgb25seSBvdXRlcg0KPiA+IG9wdGlvbnMgc2luY2UgdGhlIGRlY3J5cHRpb24g b3BlcmF0aW9uIGhhcyBub3QgeWV0IGJlZW4gcGVyZm9ybWVkKS4NCj4gPiBBbHRlcm5hdGl2ZWx5 IHdlIGNvdWxkIGludHJvZHVjZSBzb21lIHRleHQgZXhwbGFpbmluZyBvciByZWZlcmVuY2luZw0K PiA+IGJldHdlZW4gdGhlc2UgZGlmZmVyZW50IG9wZXJhdGlvbnMuIFdoYXQgaXMgcHJlZmVycmVk Pw0KPiA+DQo+ID4NCj4gPiBHw7ZyYW4NCj4gDQoNCg== From nobody Wed Oct 18 10:52:31 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF801331D2 for ; Wed, 18 Oct 2017 10:52:29 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 ferjMLetOttN for ; Wed, 18 Oct 2017 10:52:27 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 DB5E6133054 for ; Wed, 18 Oct 2017 10:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9IHqN1B012686 for ; Wed, 18 Oct 2017 19:52:23 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yHKQH1MbrzDXJk; Wed, 18 Oct 2017 19:52:23 +0200 (CEST) From: Carsten Bormann Content-Type: multipart/alternative; boundary="Apple-Mail=_FA34F8B4-30F4-47C8-90DE-4225477A2696" X-Mao-Original-Outgoing-Id: 530041940.695031-c7a44ab83e986a996115a7fee0c7cd1d Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 18 Oct 2017 19:52:20 +0200 Message-Id: <5AA63060-E209-4A5A-A992-DD42F6CBCE4D@tzi.org> References: <150834335544.12474.3820514225890782960@ietfa.amsl.com> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [core] YANG-Push-CoAP problem statement X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 17:52:30 -0000 --Apple-Mail=_FA34F8B4-30F4-47C8-90DE-4225477A2696 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There is a new I-D with a problem statement and a rough solution outline = for a gap that would need to be closed to make COMI applicable to an = additional set of applications.=20 It is not a particularly long draft. Some review from CoRE experts = might help us find the best way forward =E2=80=94 this is not a lot of = new protocol work for CoRE, but of course we want to make sure the tools = we already provide for this are used in the best possible way. Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: = draft-birkholz-yang-push-coap-problemstatement-00.txt > Date: October 18, 2017 at 18:15:55 GMT+2 > To: > > Reply-To: internet-drafts@ietf.org > Archived-At: = > >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : YANG Push Operations for CoMI > Authors : Henk Birkholz > Tianran Zhou > Xufeng Liu > Eric Voit > Filename : = draft-birkholz-yang-push-coap-problemstatement-00.txt > Pages : 11 > Date : 2017-10-18 >=20 > Abstract: > This document provides a problem statement, derives an initial gap > analysis and illustrates a first set of solution approaches in = regard > to augmenting YANG data stores based on the CoAP Management = Interface > with YANG Push capabilities. A binary transfer mechanism for YANG > Subscribed Notifications addresses both the requirements of > constrained-node networks and the need for semantic interoperability > via self-descriptiveness of the corresponding data in motion. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-birkholz-yang-push-coap-problemstat= ement/ = >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-birkholz-yang-push-coap-problemstatement= -00 > = https://datatracker.ietf.org/doc/html/draft-birkholz-yang-push-coap-proble= mstatement-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 --Apple-Mail=_FA34F8B4-30F4-47C8-90DE-4225477A2696 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 There is a new I-D with a problem statement and a rough = solution outline for a gap that would need to be closed to make COMI = applicable to an additional set of applications. 

It is not a particularly long draft. =  Some review from CoRE experts might help us find the best way = forward =E2=80=94 this is not a lot of new protocol work for CoRE, but = of course we want to make sure the tools we already provide for this are = used in the best possible way.

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


Begin forwarded = message:

From: = internet-drafts@ietf.org
Subject: = I-D Action: = draft-birkholz-yang-push-coap-problemstatement-00.txt
Date: = October 18, 2017 at 18:15:55 = GMT+2
To: = <i-d-announce@ietf.org>
Reply-To: = internet-drafts@ietf.org
Archived-At: = <https://mailarchive.ietf.org/arch/msg/i-d-announce/nli8rUCRmvXO= zeHlW0h7LPFghE0>


A New Internet-Draft is = available from the on-line Internet-Drafts directories.


=        Title =           : YANG Push = Operations for CoMI
=        Authors =         : Henk Birkholz
=             &n= bsp;           &nbs= p;Tianran Zhou
=             &n= bsp;           &nbs= p;Xufeng Liu
=             &n= bsp;           &nbs= p;Eric Voit
Filename =        : = draft-birkholz-yang-push-coap-problemstatement-00.txt
Pages =           : 11
= Date =            : = 2017-10-18

Abstract:
=   This document provides a problem statement, derives an = initial gap
  analysis and illustrates a first = set of solution approaches in regard
  to = augmenting YANG data stores based on the CoAP Management Interface
  with YANG Push capabilities.  A binary = transfer mechanism for YANG
  Subscribed = Notifications addresses both the requirements of
=   constrained-node networks and the need for semantic = interoperability
  via self-descriptiveness of = the corresponding data in motion.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-birkholz-yang-push-coap-= problemstatement/

There are also = htmlized versions available at:
https://tools.ietf.org/html/draft-birkholz-yang-push-coap-probl= emstatement-00
https://datatracker.ietf.org/doc/html/draft-birkholz-yang-push-= coap-problemstatement-00


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


= --Apple-Mail=_FA34F8B4-30F4-47C8-90DE-4225477A2696-- From nobody Wed Oct 18 11:31:17 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CB9132C2A for ; Wed, 18 Oct 2017 11:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUqVLB-b482a for ; Wed, 18 Oct 2017 11:31:14 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5892B13431E for ; Wed, 18 Oct 2017 11:31:13 -0700 (PDT) Received: from mail-lf0-f42.google.com ([209.85.215.42]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1e4t7W-00045a-AD; Wed, 18 Oct 2017 20:31:10 +0200 Received: by mail-lf0-f42.google.com with SMTP id l23so6872384lfk.10 for ; Wed, 18 Oct 2017 11:31:10 -0700 (PDT) X-Gm-Message-State: AMCzsaV1VJvL1khcq7amBB1+inExjeg6SJ9NpfILqlKGnc14BhL0s03l reDJJNZEgiG0RjKPHWcqeMulsCVdxzWhMsFTRRk= X-Google-Smtp-Source: ABhQp+RGPCDrfezS5T/w6K32weH5QPcys8MS7mk8/rxW2A3QHtwTU+sxOrgBnrSzawhq5jZOA7juhJxYPVeASRWmupY= X-Received: by 10.25.21.101 with SMTP id l98mr5620201lfi.180.1508351469808; Wed, 18 Oct 2017 11:31:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.79.3 with HTTP; Wed, 18 Oct 2017 11:30:29 -0700 (PDT) In-Reply-To: <5AA63060-E209-4A5A-A992-DD42F6CBCE4D@tzi.org> References: <150834335544.12474.3820514225890782960@ietfa.amsl.com> <5AA63060-E209-4A5A-A992-DD42F6CBCE4D@tzi.org> From: Klaus Hartke Date: Wed, 18 Oct 2017 20:30:29 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1508351474; 5411d344; X-HE-SMSGID: 1e4t7W-00045a-AD Archived-At: Subject: Re: [core] YANG-Push-CoAP problem statement X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 18:31:16 -0000 This is what I call a great problem statement. Thank you! I have checked the outlined approaches and all of them seem viable to me. I actually started writing a draft on "configured subscriptions" a long time ago but never published it because it's really short: "A server (or proxy in the role of a server) MAY send unsolicited notifications to a client (or proxy in the role of a client) if the client's interest in receiving notifications for a resource has been registered with the server using some out-of-band mechanism (such as manual configuration or a discovery process)." (This probably needs another sentence about clients that permanently don't respond or reject all notifications...) Klaus On 18 October 2017 at 19:52, Carsten Bormann wrote: > There is a new I-D with a problem statement and a rough solution outline = for > a gap that would need to be closed to make COMI applicable to an addition= al > set of applications. > > It is not a particularly long draft. Some review from CoRE experts might > help us find the best way forward =E2=80=94 this is not a lot of new prot= ocol work > for CoRE, but of course we want to make sure the tools we already provide > for this are used in the best possible way. > > Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Oct 20 17:28:58 2017 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 325B313451F; Fri, 20 Oct 2017 17:24:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: core@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854546420.20809.2195652657036314367.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:24 -0700 Archived-At: Subject: [core] core - Requested sessions have been scheduled for IETF 100 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:24 -0000 Dear Carsten Bormann, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. core Session 1 (2:00:00) Monday, Afternoon Session I 1330-1530 Room Name: Sophia size: 200 --------------------------------------------- core Session 2 (2:00:00) Tuesday, Afternoon Session I 1330-1530 Room Name: Bras Basah size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Carsten Bormann Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: cbor httpbis artarea t2trg ace lpwan 6lo roll teep fud Second Priority: dnssd saag irtfopen 6tisch netconf netmod sacm dinrg Third Priority: lwig detnet quic v6ops opsarea cfrg icnrg People who must be present: Carsten Bormann Alexey Melnikov Jaime Jimenez Resources Requested: Special Requests: Please also avoid any IoT related BOFs that might come up. *Preferred* pairing: Tue/Thu or other space between; Friday is also no problem. --------------------------------------------------------- From nobody Sat Oct 21 00:25:17 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8B4126BF3; Sat, 21 Oct 2017 00:25:05 -0700 (PDT) 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] 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 AZhVVvaNtwQx; Sat, 21 Oct 2017 00:25:02 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 65BD5132C32; Sat, 21 Oct 2017 00:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9L7Ov0j002362; Sat, 21 Oct 2017 09:24:57 +0200 (CEST) Received: from [192.168.44.182] (vpn27.hotsplots.net [185.46.137.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yJvLp5pDyzDWYW; Sat, 21 Oct 2017 09:24:50 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 530263478.505612-13ffd0836dba12edc5c52d7ceea636c1 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 21 Oct 2017 09:24:38 +0200 Message-Id: <1B709418-2990-4B00-9D7E-32AAA5637C7F@tzi.org> To: ace , "core@ietf.org WG" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF100: FINAL AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 21 Oct 2017 07:25:05 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF100. Remember that "FINAL" means this will be the basis for printed agenda sheets, there is still some potential for changes after that. The CBOR/SUIT conflict has been fixed, but now there is overlap between 6TISCH and SUIT. ROLL vs. TEEP is a bit unfortunate, as is DINRG vs. LPWAN vs. DISPATCH. All times are SGT (UTC+0800). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, November 10, 2017 -- Joint meeting of OCF and T2TRG @ OCF meeting venue SATURDAY/SUNDAY -- Hackathon (including various interops) MONDAY, November 13, 2017 0930-1200 Morning Session I Collyer ART dispatch Dispatch WG - 0930-1100 Joint = with ARTAREA Collyer ART httpbis Hypertext Transfer Protocol WG - = 1100-1200 Olivia INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG VIP A IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Sophia OPS anima Autonomic Networking Integrated Model = and Approach WG 1330-1530 Afternoon Session I Sophia ART *** core Constrained RESTful Environments WG Padang OPS v6ops IPv6 Operations WG 1550-1720 Afternoon Session II Bras Basah INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Collyer INT homenet Home Networking WG Padang IRTF maprg Measurement and Analysis for Protocols Canning SEC *** suit Software Updates for Internet of Things = BOF 1740-1840 Afternoon Session III Sophia INT ipwave IP Wireless Access in Vehicular = Environments WG - 0930-1030 Padang SEC tls Transport Layer Security WG Canning TSV tsvwg Transport Area Working Group WG TUESDAY, November 14, 2017 0930-1200 Morning Session I Collyer SEC *** ace Authentication and Authorization for = Constrained Environments WG Olivia TSV taps Transport Services WG 1330-1530 Afternoon Session I Bras Basah ART *** core Constrained RESTful Environments WG Canning INT 6man IPv6 Maintenance WG VIP A SEC tokbind Token Binding WG Padang TSV quic QUIC WG 1550-1750 Afternoon Session II Padang IRTF*** t2trg Thing-to-Thing Olivia RTG bier Bit Indexed Explicit Replication WG Sophia SEC oauth Web Authorization Protocol WG WEDNESDAY, November 15, 2017 0930-1200 Morning Session I Canning INT dnssd Extensions for Scalable DNS Service = Discovery WG Olivia INT *** lwig Light-Weight Implementation Guidance WG = - 1100-1200 VIP A IRTF icnrg Information-Centric Networking Collyer TSV quic QUIC WG 1330-1500 Afternoon Session I Bras Basah ART uta Using TLS in Applications WG VIP A RTG *** roll Routing Over Low power and Lossy = networks WG Collyer SEC *** teep Trusted Execution Environment = Provisioning BOF Orchard TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1650 Afternoon Session II Collyer INT intarea Internet Area Working Group WG VIP A IRTF cfrg Crypto Forum Orchard SEC oauth Web Authorization Protocol WG THURSDAY, November 16, 2017 0930-1200 Morning Session I Padang IRTF irtfopen IRTF Open Meeting Collyer OPS v6ops IPv6 Operations WG Sophia RTG detnet Deterministic Networking WG Canning SEC tls Transport Layer Security WG 1330-1530 Afternoon Session I Sophia INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Collyer IRTF panrg Path Aware Networking Proposed RG Padang SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Olivia ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG VIP A ART ice Interactive Connectivity Establishment = WG - 1550-1650 Canning RTG rtgarea Routing Area Open Meeting Sophia SEC acme Automated Certificate Management = Environment WG 1810-1910 Afternoon Session III VIP A SEC curdle CURves, Deprecating and a Little more = Encryption WG Padang TSV tsvarea Transport Area Open Meeting FRIDAY, November 17, 2017 0930-1130 Morning Session I Canning ART httpbis Hypertext Transfer Protocol WG VIP A RTG babel Babel routing protocol WG Collyer TSV tsvwg Transport Area Working Group WG From nobody Mon Oct 23 06:34:31 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA97138BCD for ; Mon, 23 Oct 2017 06:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 16xLIV7vB8lZ for ; Mon, 23 Oct 2017 06:34:28 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C91138AED for ; Mon, 23 Oct 2017 06:34:27 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id 8E024222980 for ; Mon, 23 Oct 2017 13:34:25 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Mon, 23 Oct 2017 15:34:25 +0200 To: core From: Ludwig Seitz Message-ID: <63a3524b-27d5-7ba9-0ae4-7943423d947e@ri.se> Date: Mon, 23 Oct 2017 15:34:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=KqQ94SeN c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=02M-m0pO-4AA:10 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=VzzZoDx1fYG3ivHQKv8A:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: [core] Question about RD from ACE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Oct 2017 13:34:30 -0000 Hello CoRE, an interesting question has come up in ACE, for which we would need feed-back from people familiar with the Resource Directory work. In our draft we suggest that a client that whishes to access a resource at a server can look up the authorization server in charge of that server in a resource directory [1]. Jim Schaad has made me aware that this is not as easy as it sounds [2], and I feel I would need feed-back as to: 1.) Is it a good idea at all to put such information somewhere in the RD? 2.) Where in the RD would one put such information? What would such a resource type look like? Regards, Ludwig Seitz [1] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1 [2] https://github.com/ace-wg/ace-oauth/issues/120 -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon Oct 23 06:41:25 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E842C138999 for ; Mon, 23 Oct 2017 06:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3] 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 CWS0iI4Lm6LH for ; Mon, 23 Oct 2017 06:41:23 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 01B8C13899A for ; Mon, 23 Oct 2017 06:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9NDfKwl024806; Mon, 23 Oct 2017 15:41:20 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yLHcH6lhKzDX53; Mon, 23 Oct 2017 15:41:19 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <63a3524b-27d5-7ba9-0ae4-7943423d947e@ri.se> Date: Mon, 23 Oct 2017 15:41:18 +0200 Cc: core X-Mao-Original-Outgoing-Id: 530458877.945187-6d228c4616d098b24d26a953773147de Content-Transfer-Encoding: quoted-printable Message-Id: References: <63a3524b-27d5-7ba9-0ae4-7943423d947e@ri.se> To: Ludwig Seitz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Question about RD from ACE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 23 Oct 2017 13:41:25 -0000 On Oct 23, 2017, at 15:34, Ludwig Seitz wrote: >=20 > Hello CoRE, >=20 > an interesting question has come up in ACE, for which we would need = feed-back from people familiar with the Resource Directory work. >=20 > In our draft we suggest that a client that whishes to access a = resource at a server can look up the authorization server in charge of = that server in a resource directory [1]. That appears to be the wrong way around. A client that finds a resource in a resource directory might find link = relations or target attributes there that will also find the = authorization manager for that server. > Jim Schaad has made me aware that this is not as easy as it sounds = [2], and I feel I would need feed-back as to: >=20 > 1.) Is it a good idea at all to put such information somewhere in the = RD? Yes. We haven=E2=80=99t really discussed how the authorization of the = disclosure of such information would work in an RD, but that should be a = relatively small step with ACE available. > 2.) Where in the RD would one put such information? What would such a = resource type look like? Say, = ;rel=3Dauthorization-managed-by;anchor=3D= =E2=80=9C/s/temp=E2=80=9D;ace-profile=3D=E2=80=9Coscore" (Add target attributes to get more useful profile information in there; = the above surely doesn=E2=80=99t cut it.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Oct 24 23:53:29 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E925113AB3E for ; Tue, 24 Oct 2017 23:53:28 -0700 (PDT) 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] 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 qjs63ysDo4lI for ; Tue, 24 Oct 2017 23:53:28 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 A24DD13A344 for ; Tue, 24 Oct 2017 23:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9P6rNA6008497; Wed, 25 Oct 2017 08:53:23 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yMLSg5M22zDXZP; Wed, 25 Oct 2017 08:53:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <1a9f165d-6994-a92f-3e93-faabf9c690ba@gmx.net> Date: Wed, 25 Oct 2017 08:53:23 +0200 Cc: =?utf-8?Q?Jaime_Jim=C3=A9nez?= , "core@ietf.org WG (core@ietf.org)" X-Mao-Original-Outgoing-Id: 530607203.125244-ddb736898dc4c3490f1e18c9135eb350 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1a9f165d-6994-a92f-3e93-faabf9c690ba@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Oct 2017 06:53:29 -0000 Hi Hannes, On Oct 4, 2017, at 16:50, Hannes Tschofenig = wrote: >=20 > Two comments: >=20 > IMHO the presented problems are not worthwhile to solve. I=E2=80=99m not sure I understand. The problem pointed out is a = security problem in certain applications. Are you saying we shouldn=E2=80=99t invest time in these applications? Or are you saying this should instead be solved within the application = (which is perfectly possible, but not something we can expect developers = to always get right)? > Additionally, I > would prefer if the CORE working group finishes already chartered = items > rather than always adding new stuff. I think we can agree on this, but addressing a security problem does = have a special importance. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Oct 25 00:49:46 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE55A13A5A3 for ; Wed, 25 Oct 2017 00:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 D5YaCi5V9Z_Y for ; Wed, 25 Oct 2017 00:49:43 -0700 (PDT) Received: from bne.vrt.com.au (bne-eth.vrt.com.au [103.225.70.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69AF4138467 for ; Wed, 25 Oct 2017 00:49:42 -0700 (PDT) Received: from bne.vrt.com.au (localhost [127.0.0.1]) by bne.vrt.com.au (Postfix) with ESMTP id EEA7580308937 for ; Wed, 25 Oct 2017 17:49:38 +1000 (AEST) Received: by bne.vrt.com.au (Postfix, from userid 8) id D8D80807AB5BC; Wed, 25 Oct 2017 17:49:38 +1000 (AEST) Received: from bneprdmail (unknown [10.87.160.28]) by bne.vrt.com.au (Postfix) with ESMTP id 32BA680308937 for ; Wed, 25 Oct 2017 17:49:34 +1000 (AEST) Received: from [10.87.130.82] (unknown [10.87.130.82]) by bneprdmail (Postfix) with ESMTPSA id 5D8EC52F25 for ; Wed, 25 Oct 2017 17:49:34 +1000 (AEST) To: "core@ietf.org WG (core@ietf.org)" From: Stuart Longland Openpgp: id=B8AA34BA25C794168FAEF315A02404BC58650CF9; url=https://stuartl.longlandclan.id.au/key.asc Organization: VRT Systems Message-ID: <48729a59-f5e8-e20a-f1cb-7a0bb64b1d8d@vrt.com.au> Date: Wed, 25 Oct 2017 17:49:33 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Archived-At: Subject: [core] Simple registration and URI length restrictions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Oct 2017 07:49:45 -0000 Hi all, I'm in the process of writing a proof-of-concept implementation of the CoRE resource discovery server for the purpose of allowing devices on a Thread/6LoWPAN network to "log in". Reading the spec, and taking into account the limitations of the devices we're using (built around TI's CC2538 and running the OpenThread firmware stack), I figured the Simple publishing mechanism would be the easiest to implement as I already have the /.well-known/core endpoint working on the devices (it just coughs up static output). For simplicity's sake, I was going to use the EUI64 of the device as the endpoint name. The problem seems to be the size of the URI this generates, the spec says¹: > 5.3.2. Simple publishing to Resource Directory Server > > An endpoint that wants to make itself discoverable occasionally sends > a POST request to the "/.well-known/core" URI of any candidate > directory server that it finds. The body of the POST request is > empty, which triggers the resource directory server to perform GET > requests at the requesting server's default discovery URI to obtain > the link-format payload to register. > > The endpoint MUST include the endpoint name and MAY include the > registration parameters d, lt, and et, in the POST request as per > Section 5.3. > > The following example shows an endpoint using simple publishing, by > simply sending an empty POST to a resource directory. > > Req:(to RD server from [ff02::1]) > POST coap://rd.example.com/.well-known/core?lt=6000;ep=node1 I'm testing this with the OpenThread CLI, and I've discovered that it limits URIs to 32 characters. This means my endpoint name gets chopped off. This is the outgoing request: >> coap post fdde:ad00:beef:0:52c2:9f9e:6e6d:ade1 .well-known/core?ep=11f47b5800124b00<=300 > Sending coap request: Done and my server (implemented with node-coap) sees this: > [2017-10-25T07:27:50.017Z] INFO: WideSkyCoAPGateway/coap/10134 on vk4msl-ws: Begin request (method=POST, uri=/.well-known/core?ep=11f47b58001) > source: { > "address": "fdde:ad00:beef::ff:fe00:ec00", > "family": "IPv6", > "port": 5683, > "size": 39 > } I can change this in OpenThread of course, I've identified where the changes would need to go, however the other examples use the much shorter `/rd` endpoint, which avoids some of these problems. I was wondering whether it was actually intended that `/.well-known/core` be used or whether this was overlooked? Regards, -- _ ___ Stuart Longland - Systems Engineer \ /|_) | T: +61 7 3535 9619 \/ | \ | 38b Douglas Street F: +61 7 3535 9699 SYSTEMS Milton QLD 4064 http://www.vrt.com.au 1. https://tools.ietf.org/html/draft-ietf-core-resource-directory-11#section-5 From nobody Wed Oct 25 01:53:02 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D4B13AF23 for ; Wed, 25 Oct 2017 01:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lightingaad.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQx1xGIBp2k9 for ; Wed, 25 Oct 2017 01:52:56 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20051.outbound.protection.outlook.com [40.107.2.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB0C13ADBD for ; Wed, 25 Oct 2017 01:52:55 -0700 (PDT) Received: from VI1P121CA0001.EURP121.PROD.OUTLOOK.COM (2a01:111:e400:e2b2::15) by VI1P121MB0015.EURP121.PROD.OUTLOOK.COM (2a01:111:e400:e2b2::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Wed, 25 Oct 2017 08:52:53 +0000 Received: from AM5EUR02FT005.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::201) by VI1P121CA0001.outlook.office365.com (2a01:111:e400:e2b2::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4 via Frontend Transport; Wed, 25 Oct 2017 08:52:53 +0000 Authentication-Results: spf=neutral (sender IP is 13.80.155.198) smtp.mailfrom=philips.com; vrt.com.au; dkim=fail (signature did not verify) header.d=lightingaad.onmicrosoft.com;vrt.com.au; dmarc=fail action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 13.80.155.198 is neither permitted nor denied by domain of philips.com) Received: from EDGE-VM-002.westeurope.cloudapp.azure.com (13.80.155.198) by AM5EUR02FT005.mail.protection.outlook.com (10.152.8.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.156.4 via Frontend Transport; Wed, 25 Oct 2017 08:52:52 +0000 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (94.245.120.88) by autodiscover.lighting.com (192.168.0.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1034.26; Wed, 25 Oct 2017 08:52:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightingaad.onmicrosoft.com; s=selector1-lighting-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ykjh+/DDtcXVmXQaS0eUpj6BJOJcxWtPkBeBB0507fQ=; b=1TrOxO1WJH4E4j0UvOYrnPvB+eiSythVCk1Vp5b1h8AdnnLEmi10TrnSWfmtV3Twub5vvB6pdX6ry7aKZGY9/nLGe7is1F5IV9pddnvWUDHTMLotqt3ihZ8DauVnkj7RoOOjvvqtW7V5MFshs5h0Lrhxp1JoG4UE3yCemxgZ4Dc= Received: from HE1P121MB0042.EURP121.PROD.OUTLOOK.COM (129.75.191.149) by HE1P121MB0041.EURP121.PROD.OUTLOOK.COM (129.75.191.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 25 Oct 2017 08:52:34 +0000 Received: from HE1P121MB0042.EURP121.PROD.OUTLOOK.COM ([129.75.191.149]) by HE1P121MB0042.EURP121.PROD.OUTLOOK.COM ([129.75.191.149]) with mapi id 15.20.0077.023; Wed, 25 Oct 2017 08:52:34 +0000 From: Esko Dijk To: Stuart Longland , "core@ietf.org WG (core@ietf.org)" Thread-Topic: [core] Simple registration and URI length restrictions Thread-Index: AQHTTWXYRvrbsvtunUm746jMyX4i4qL0Onww Date: Wed, 25 Oct 2017 08:52:34 +0000 Message-ID: References: <48729a59-f5e8-e20a-f1cb-7a0bb64b1d8d@vrt.com.au> In-Reply-To: <48729a59-f5e8-e20a-f1cb-7a0bb64b1d8d@vrt.com.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@lighting.com; x-originating-ip: [80.255.245.238] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1; HE1P121MB0041; 6:Tn5++geq4D8eS+zvEQ02mxIrqWRJTtLo8PCYR/1erT+2K0pSRRKxlikZ+7ZjuaJ5WS9rlyDoVhk/eGf5x6WBJsh8PyZpmTYT3MOQsNL7wr5DGMWqeoYvs7Nnj+SqweK3UBbjqemBuXp/yED+pcTrJvmejTQqH+ccR4kk4hS+054iC8754mLsRi+RM0m+fMF5wQ4NGu74ErACTQHgaqu6gz1wTPV9ZjZhsm17nTpSpPmihyz2ZObazTjeN8jbDWihHbTC6S66L+frVlK5ta8w7MmVrfnmtI40bmq9XN3rvO2Z0iG6RWQ//mjWcPd+zy0vNujFkEzty4lZnm2NJWR4eg==; 5:HFgAsFNFWVwAB/Fu8vQdBL92+mRbEWCmTtmvC74E2/3/aaMAC5jZYW+a3nQAi2yu515rpqySh7pyzUBMHfFoYIchYRxzq08amosjsqcf6WJ9lge+O6ZWe9su3GVdBw6L08f9sheWbFirEpY2yUEliQ==; 24:HeLztIGgK03mY4lRuENwlMWEe8RSDnefCdGIPkz1OwEZaE0xd3FDG8ukk6sLrsE9FwE3m6cYyVbw/7YA+9O1x3OFtfE6nC/UDA+HWc6DumY=; 7:ycif3rfBieOHEbvvQQWHcf+ToHslDma62QNoeN6T2ZW32SCPBHQX2d4+1S0WOH0wwQxgWz+2gHlrSxQD2ZtzDgihH1C6lWzeql0gyuUa79ulBuZqJUkVb0C0g6hmDy8ZvVC4tQia7Mo+EOv4NIYUxaJWfXcQsMMSwil08sx0837hUWttYl65SvmsvcU9XDxCwP6EFSOzzkKap/yiV+s53KHohgsR3fQpmOU1T53dNVo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; X-MS-Office365-Filtering-Correlation-Id: fb1c8ded-d24d-4fdb-ef7d-08d51b85c731 X-Microsoft-Antispam-Untrusted: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:HE1P121MB0041; X-MS-TrafficTypeDiagnostic: HE1P121MB0041:|VI1P121MB0015: x-exchange-antispam-report-test: UriScan:(158342451672863)(150554046322364)(46150409022019); UriScan:(158342451672863)(150554046322364)(46150409022019); X-Microsoft-Antispam-PRVS: x-exchange-antispam-report-cfa-test: =?utf-8?B?QkNMOjA7UENMOjA7UlVMRUlEOigxMDAwMDA3MDAxMDEpKDEwMDEwNTAwMDA5?= =?utf-8?B?NSkoMTAwMDAwNzAxMTAxKSgxMDAxMDUzMDAwOTUpKDEwMDAwMDcwMjEwMSko?= =?utf-8?B?MTAwMTA1MTAwMDk1KSg2MDQwNDUwKSgyNDAxMDQ3KSg4MTIxNTAxMDQ2KSg1?= =?utf-8?B?MDA1MDA2KSgzMjMxMDIwKSgxMDIwMTUwMTA0NikoOTMwMDYwOTUpKDkzMDAx?= =?utf-8?B?MDk1KSgxMDAwMDA3MDMxMDEpKDEwMDEwNTQwMDA5NSkoMzAwMjAwMSkoNjA0?= =?utf-8?B?MTI0OCkoMjAxNjExMjM1NTgxMDApKDIwMTYxMTIzNTU1MDI1KSgyMDE2MTEy?= =?utf-8?B?MzU2MjAyNSkoMjAxNzAzMTMxNDIzMDc1KSgyMDE3MDIyODE1MjgwNzUpKDIw?= =?utf-8?B?MTcwMzA2MTQyMTA3NSkoMjAxNzAzMDYxNDA2MTUzKSgyMDE2MTEyMzU2NDAy?= =?utf-8?B?NSkoMjAxNjExMjM1NjAwMjUpKDYwNzIxNDgpKDIwMTcwODA3MTc0MjAxMSko?= =?utf-8?B?MTAwMDAwNzA0MTAxKSgxMDAxMDUyMDAwOTUpKDEwMDAwMDcwNTEwMSkoMTAw?= =?utf-8?B?MTA1NTAwMDk1KTtTUlZSOkhFMVAxMjFNQjAwNDE7QkNMOjA7UENMOjA7UlVM?= =?utf-8?B?RUlEOigxMDAwMDA4MDAxMDEpKDEwMDExMDAwMDA5NSkoMTAwMDAwODAxMTAx?= =?utf-8?B?KSgxMDAxMTAzMDAwOTUpKDEwMDAwMDgwMjEwMSkoMTAwMTEwMTAwMDk1KSgx?= =?utf-8?B?MDAwMDA4MDMxMDEpKDEwMDExMDQwMDA5NSkoMTAwMDAwODA0MTAxKSgxMDAx?= =?utf-8?B?MTAyMDAwOTUpKDEwMDAwMDgwNTEwMSkoMTAwMTEwNTAwMDk1KTtTUlZSOkhF?= =?utf-8?B?MVAxMjFNQjAwNDE7QkNMOjA7UENMOjA7UlVMRUlEOigxMDAwMDA3MDAxMDEp?= =?utf-8?B?KDEwMDEwNTAwMDA5NSkoMTAwMDAwNzAxMTAxKSgxMDAxMDUzMDAwOTUpKDEw?= =?utf-8?B?MDAwMDcwMjEwMSkoMTAwMTA1MTAwMDk1KSg2MDk1MTM1KSgyNDAxMDQ3KSg4?= =?utf-8?B?MTIxNTAxMDQ2KSg1MDA1MDA2KSg5MzAwNjA5NSkoOTMwMDMwOTUpKDEwMDAw?= =?utf-8?B?MDcwMzEwMSkoMTAwMTA1NDAwMDk1KSgzMDAyMDAxKSgxMDIwMTUwMTA0Niko?= =?utf-8?B?MzIzMTAyMCkoNjA1NTAyNikoNjA5NjAzNSkoMjAxNjExMjM1NTYwMjUpKDIw?= =?utf-8?B?MTYxMTIzNTY1MDI1KSgyMDE2MTEyMzU2MTAyNSkoMjAxNzAzMTMxNDMwMDc1?= =?utf-8?B?KSgyMDE3MDMxMzE0MzMwNzUpKDIwMTcwMzEzMTQ0ODA3NSkoMjAxNzAzMTYx?= =?utf-8?B?MjU5MTUwKSgyMDE3MDMxNTEwNDIxNTMpKDIwMTYxMTIzNTU5MTAwKSgyMDE2?= =?utf-8?B?MTEyMzU2MzAyNSkoMjAxNzA4MDcxNzQyMDExKSgxMDAwMDA3MDQxMDEpKDEw?= =?utf-8?B?MDEwNTIwMDA5NSkoMTAwMDAwNzA1MTAxKSgxMDAxMDU1MDAwOTUpO1NSVlI6?= =?utf-8?B?VkkxUDEyMU1CMDAxNTtCQ0w6MDtQQ0w6MDtSVUxFSUQ6KDEwMDAwMDgwMDEw?= =?utf-8?B?MSkoMTAwMTEwMDAwMDk1KSgxMDAwMDA4MDExMDEpKDEwMDExMDMwMDA5NSko?= =?utf-8?B?MTAwMDAwODAyMTAxKSgxMDAxMTAxMDAwOTUpKDEwMDAwMDgwMzEwMSkoMTAw?= =?utf-8?B?MTEwNDAwMDk1KSg0MDAwMDYpKDEwMDAwMDgwNDEwMSkoMTAwMTEwMjAwMDk1?= =?utf-8?B?KSgxMDAwMDA4MDUxMDEpKDEwMDExMDUwMDA5NSk7U1JWUjpWSTFQMTIxTUIw?= =?utf-8?Q?015;?= x-forefront-prvs: 0471B73328 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(199003)(189002)(13464003)(53754006)(85714005)(288314003)(68736007)(102836003)(189998001)(5660300001)(50986999)(53936002)(76176999)(3846002)(86362001)(2950100002)(53546010)(54356999)(105586002)(33656002)(101416001)(6246003)(66066001)(53386004)(316002)(7696004)(106356001)(25786009)(110136005)(229853002)(305945005)(97736004)(7736002)(3280700002)(8936002)(478600001)(9686003)(6116002)(6306002)(3660700001)(2906002)(8676002)(966005)(81156014)(81166006)(74316002)(6436002)(6506006)(55016002)(2900100001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1P121MB0041; H:HE1P121MB0042.EURP121.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: lighting.com does not designate permitted sender hosts) SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P121MB0041 X-EOPAttributedMessage: 0 X-Matching-Connectors: 131533951731050885; (); (fd2a86c0-868a-4d63-2575-08d435642d86) X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR02FT005.eop-EUR02.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:13.80.155.198; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(336005)(376002)(346002)(39380400002)(39860400002)(2980300002)(85714005)(13464003)(199003)(53754006)(288314003)(189002)(8936002)(81156014)(498600001)(53936002)(956001)(966005)(5660300001)(9686003)(6306002)(25786009)(55016002)(76176999)(50986999)(54356999)(6116002)(2900100001)(3846002)(2950100002)(102836003)(53386004)(189998001)(2906002)(229853002)(53546010)(23676002)(68736007)(33656002)(22756006)(7696004)(97736004)(66066001)(356003)(47776003)(74316002)(305945005)(7736002)(50466002)(81166006)(8676002)(6506006)(105586002)(106466001)(110136005)(6246003)(86362001)(316002)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P121MB0015; H:EDGE-VM-002.westeurope.cloudapp.azure.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM5EUR02FT005; 1:JaJ3Qw6+ZYycU17w4uScBwylnav/29qHas51t9fG9KPndXPyj/e8V6+37pkJeKn1zUGywDcgne7/xK1JZzxQyNCWTk0/9PPGyNh6GwZxw7veHWiwBb7af3l60XTxWz4W X-DkimResult-Test: Failed X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(3002016)(4534020)(4628075)(201703131517081)(2017052603199); SRVR:VI1P121MB0015; X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0015; 3:DuZ+1E/MZ/abYTuVxjxuN5pX6A9hURzCcjHdUoF1dwHJOXytPfDZlRAlEdcqvl5Ei1S+6pO9urArq0A/05oO5ydfOKl/BJPzw80txChvAcuNQb5+CufeAZzmoOoMk8Tkkf6uHlcH+HbiTI0ePyWPgjjMnwWlFr+Vi6Q+PsvAnW3hcYBr/7VJoJiiYJwv0kDiFJINXzT96VzqTDFt+CmqYZqxeDo1qF7Eow17Pm4x3QB1/nPD8TeVdEwBzBGsoRtZIcRWyoDP8l2gh9+Mr6aF04IDm+xlY9ZsxYkZS56Vp/WrPBEl7R8ePatGR4f9TrgZVE79H0VoIg32rorl9kakCDJRljFpewNHZvuumuwlTN8=; 25:Ij4pWsSQBRqUK2ODmTvhuAhJJZW0LlPWSCMl2SytGzUBcmcXrvJulYw0DSWR5VL5EV1XLUZY8M7iJREusqcg/pEjlcNcgcQvjPGuU7jY+ddigUOb5rrzq+54m1M8ppWHLgUFNmlL3yG3caVokitN7mcwpvXqHMe85lkMKGiPoVlZKAg1QSNxhltEzPkhcUGRbj4EKv9wxljUxfxCjsfjFpQRbYovKauzM5pREb0LaJ1VtIPuZLg5tBr0gUFjICO0iMorRZeMQfHHXYEtp2UlHz9zl0na3EJb5nuXRnd01hbFB2+UH29Bb/h6hePQjdVtoiFMOZXLJ62gjmzr5kEOKQ== X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0015; 31:Z/nzGHH5bHQco6tn2STqdvybsOEHKKABmR2i9lMuX1inbEnjfeNIq4JjIu2PkJTT7CyE33Smj1D2ssRj3ScmDmKg7n7DnzAOkw0+q66IXTWKS2YkjZ/udd2dHNlxqO6Gbrqk67Lr8dvmIgN1eSf8CraQCnEYC6xcygSJHXgjJi+hDMQGDybUiMEG8J5qoY6qjLOBYDDyanOQ4YQ2BM3VukZXjWk9QDWKsXqBIaCHDSM=; 4:tbg0YYCvZ1bzPg0bjz8npDLebj9yFBe99ngcywIh0HoZYIgjVFaBiCIGKbbJ922pwz7ab3AFMEqu21CRytHPPkEyrHojnYjybnL8OBiLltUzExN+aNAEhjpfgcB4sDCmdBVMt+aPVxhsLcoTltITSyW/j3EKLhb2q12VdJxwpfv3CC+S0D8PeWLF3tmAIucYLyd+mpJiLUIAAM2mJpoXj6LLBU/uLiTIoI3yQkn89AvponL4M1GJGNJWy6TskJD7lvAzjbblFR/0/WTxKbsKYbxZ1KpZ4ccy2muUYXcPEOSTITJVYgt/e0VFhDmNKZe0HomBwZ/2fGsfjuk7UIEONJF32pss6WBVHkIojbDulhW/uA5kNejdWe6/msTRxlZb X-Forefront-PRVS: 0471B73328 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQMTIxTUIwMDE1OzIzOkFnNUJ3WktFallESzA0OG1pdEZ5Snp4NE5K?= =?utf-8?B?K2xsTUlrWmRkaXMwMFpkSCt3Qlc5blVmU2JzbGh2UjVHdWpsMk5hY2ZvWDZp?= =?utf-8?B?VmNUaFVBaDUvTGZZMGlSOWtrM25rNElPOHp3ZUdML0I0OUhLbmk0cDBwektv?= =?utf-8?B?Z09Jd3lGdzVFVWN2cHlCTXM0dVlMOU9PbEs2OHBlSi84SmMvbEJ1ejFRMllQ?= =?utf-8?B?ZFZ3SUpONjVuNjF0cE9xbGxKUEwybHpQOVF5bk5qUWpBTy9Ra1Ztb1E1Ykxx?= =?utf-8?B?MWprRVRIZ1JpTmxGLzE4cDJZa3F1UFJvN1QzNU5QMXY0TXlRRUx0dWNDS3da?= =?utf-8?B?YVpJY04vRnRMRXA5L0IwTUpkelowUXVDeVQ3eEVETTFaR1RHd0JtOUcwSkhm?= =?utf-8?B?ZWpjY3Ywa3MzckVSb2NORnJvekRSYVVTcnVQa3pPai9WUnpGc2pFdy9FOUFU?= =?utf-8?B?MzZhME1kSmJTUGJ5UWl2aEhqcVJSRTBSRUQ4N1NrM3oySXVrK0I1TVFGZitY?= =?utf-8?B?bkt6Z2ZWRW9TT04vOWhsMlgwYnpFcjYzOU12bng3azFzbERkTGZVUEZzNkp4?= =?utf-8?B?ZE5lWnF0cEdqbkc4bEhvZDFLUU1abjFjUElXVWVRQXRteStQYy9VMHR0ZU03?= =?utf-8?B?d0N0Z25XQno2cENtT3ZvdTloWUtpRzk2elJqL1QvMldKVy9makJhenk1ajVw?= =?utf-8?B?Uk9jbHovUzdCQXUvTVcveFNwdXBra2pTVHk4Yi94U1hIckNMd3Mwb2wyQisx?= =?utf-8?B?OHV2dldObnBOTENEd0xGeFFMNXZueTNhNXcvTWRYekNBQWYyY01nTERRemhU?= =?utf-8?B?eGRMYmp2MzNPcEVNOUdJb09PdVQvUG1ERkZnN3dsMG9qOXduZ2N1ai9XQi9T?= =?utf-8?B?czNYd0ZWVXZDaStGQ0NnT0EvaExVOTdNM0pMKzBtV1d6REJLeitRT1lnVXdY?= =?utf-8?B?c2hWUHJSUmhwcVEva0VtLzRuc1pPbk4zaGd5bEZDa0RKL3dqdWVIWUdjV2dj?= =?utf-8?B?Nkc0bDVjaDJjaklVUTUrRHVTNmx5ejdmYU1nL2VjOFVFQUhpMTdQd2JPcUd5?= =?utf-8?B?Q3hxamdhNVVEUUlBWnA5VU9TR2dXM3NLSmVjdmN2NjBjZHVJMHphV3l6YUNs?= =?utf-8?B?YnZ3b1FXTG1LaWo0WjlPV0MzajErc0gwQmJSaU5vZ3VZYzd5K0E3SGVpMmdR?= =?utf-8?B?WElPUWhWSHJMNmZWdzFKcVdJL2VXcDRtanM1bC9HNkpIaVBrM3VLNE0xZFI3?= =?utf-8?B?cmpSV0tldGZpd1gyQkV2VVZuT01jTk12bzU1TmU1aDJQSTFiOERZNmNCSzIw?= =?utf-8?B?VTdLVm1FNC9vT0ZHOThuOThHTU5BcGdUblMrQjFhV1RjV2NKK2tHTGp5dmFw?= =?utf-8?B?RFNXZ2luRDU1QUNDMlBDc29YWHVxaTk3M2gveWhBdzlzWjk4dTBsY3V2U2NX?= =?utf-8?B?MjdTQ3llenZJaTB5UDE0OEdTLzRmbXIxV0hrLzRrMEY2WStrSHhYckNJbnBI?= =?utf-8?B?Wjh5ZnJ2SUFxemlYbHlZYzdmeDZjWDFsVGhJelJnUFROWGhXcG9mbzVKSFdG?= =?utf-8?B?cWNwUDQ1QUFZbDRibmxCR1FmdjhnUzl0ZGhtb214Uk1VaFF1aDJFbGhGYmpN?= =?utf-8?B?UFZmb0EvZFBHZVZiRUJ0Mzk3WGsyV2pYMWxubTgwaWpEVGd3M0dBWmhuV1Iv?= =?utf-8?B?bE1VSUN6VFFmdnVCV1FNd0Q1NWNZZklzcTd6L3FZQ1R3RTlkR2o2MGNPck5s?= =?utf-8?B?OW53eCs4SHdFUnlTS3h0OUpUbGFLRWJhb0ZOVGk2aEM0QkJBOVh6U29ocU1i?= =?utf-8?B?TU9UOXFmdmlBaUpsWCtqVG9zS1hyWWs5THorQ3pyWjlhcXlMamZjMGYrZjA1?= =?utf-8?Q?YeDwnhZ/ZB0=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1P121MB0015; 6:+MBT3oarW75HTdoWezvdJZairpvqsQzmS15/NkV04i2XacZuK2ze9l3oVIeAbH87MGOxcftgJUbCLlIVPL6jYc6eYWdEFu2YiY3Vbqag2hfwn0YfcFuFfWUxaFcampYX3Dyil5E7iuqXzkzGZshz/PrjazrjAS1eTtNEQszY165xOMnt1BF5sgray7/VisnZH7KV+C9RtRxkEgloVX9yfpNrdZ1ZomkyYjjmLBPM6RApMod8bHOSlPu0BSgXxYLImaQYp5DJetnv7nqF93hivyZlVizWnm+kE2iwWHvrs/rAy/eFR+cO3PuzboK8/gAyR4ympK0xAx/dpp2mJmtxFg==; 5:IpW7BWeVS/bAVQTdqXfWbOpxn0W9PGvvpwhUla7AyDSJzVgftsbfPG+7KbKadZpRDuNSr0cUgKPAeQyrYWi967YJsMpnBd7ZNCdmwLatmabTbf8n7Iz/1N7cki/xFS/kl27cJ044dkkzxzt+1cR81A==; 24:Jv9EwCjtJeiq1CMRdFZesvtwunMYS8Ps8oT/i2koBexUr9MM9u8Jbz9VOLJ/keA2f7P0RqSRS1eAwUtExF2BIil6K+o92VJHWh8nKpqQg6Q=; 7:Oz8FFdrStusE85Pb8IIe63d5MtDVdw6bwSbIqHJ4p0Xdw7wZrZjx/C6GPyw1IGxZ5mpiY6bQMgJwn5prR2dvnzBue724tPSNv+CZoRfmhlzhy7mLjb8OqAvGoKHZ3zshkszthHutHC30fls8RfNh9GJoutHrtxU0wFTi3//TiivZ79i3JguD7UrlVeg20zGpCUL4OnIBTxFtqMEGofz0zxZa5+9mgPhSq/7RCw6avd8= X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2017 08:52:52.8707 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fb1c8ded-d24d-4fdb-ef7d-08d51b85c731 X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[13.80.155.198]; Helo=[EDGE-VM-002.westeurope.cloudapp.azure.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P121MB0015 Archived-At: Subject: Re: [core] Simple registration and URI length restrictions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Oct 2017 08:53:00 -0000 SGVsbG8gU3R1YXJ0LA0KDQpJbiBnZW5lcmFsIHRoZSBwcm9ibGVtIGluIE9wZW5UaHJlYWQgQ0xJ IGNvZGUgc2hvdWxkIGJlIGZpeGVkIGFueWhvdywgYmVjYXVzZSB5b3UgY2FuIG5ldmVyIGtub3cg YXQgd2hpY2ggVVJJIHBlb3BsZSB3aWxsIGhvc3QgdGhlaXIgUkQuIEl0IG1heSBiZSB2ZXJ5IGxv bmchIEVzcGVjaWFsbHkgd2hlbiBPcGVuVGhyZWFkIGNvZGUgZW5kcyB1cCBpbnRvIHByb2R1Y3Rz IGl0IG5lZWRzIHRvIGJlIHJpZ2h0Lg0KDQpTdGlsbCBhIGdvb2QgcXVlc3Rpb24gSSB0aGluaywg YmVjYXVzZSB0aGUgY3VycmVudCBkcmFmdCBzdGF0ZXMgdGhhdCBhbiBlbmRwb2ludCBmaXJzdCBk aXNjb3ZlcnMgUkQocykgYW5kIHRoZW4gcHVibGlzaGVzIGl0c2VsZiAodXNpbmcgdGhlIFNlY3Rp b24gNS4zLjIgUE9TVCBhcHByb2FjaCkgdG8gb25lIG9yIG1vcmUgc2VsZWN0ZWQgUkQocykuIFNp bmNlIHRoZSBlbmRwb2ludCBhbHJlYWR5IGRpZCB0aGUgZGlzY292ZXJ5LCBpdCBrbm93cyB0aGUg cmVzb3VyY2UgYXQgd2hpY2ggdGhlIFJEIHNlcnZpY2UgcmVzaWRlcyAoZS5nLiAvcmQpLiBTbyB3 aHkgZG9lc24ndCBpdCB1c2UgdGhhdCByZXNvdXJjZSAvcmQgdG8gcHVibGlzaCBpdHNlbGY/IFRo YXQncyB0aGUgUkQgd2hlcmUgdGhlIGRldmljZSB3YW50cyB0byByZWdpc3Rlci4NCg0KT25lIHZh bGlkIHJlYXNvbiB0byBzdGlsbCB1c2UgLy53ZWxsLWtub3duL2NvcmUgaXMgdGhlIGZhY3QgdGhh dCBzb21ldGltZXMgb25seSB0aGUgSVB2NiBhZGRyZXNzLCBvciBhbiBJUHY2IGhvc3RuYW1lLCBv ZiB0aGUgUkQgY2FuIGJlIGRpc3RyaWJ1dGVkIGluIGEgbmV0d29yayB1c2luZyBzcGVjaWZpYyBt ZWFucy4gRS5nLiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLXJl c291cmNlLWRpcmVjdG9yeS0xMSNzZWN0aW9uLTkuMiBzdGF0ZXMgaG93IGFuIE5EIG9wdGlvbiBj YW4gZG8gdGhpcy4gSW4gc29tZSBkZXBsb3ltZW50cyBpdCBtYXkgYmUgYSB3ZWxsLWtub3duIGFu eWNhc3QgSVAgYWRkcmVzcyBwb2ludGluZyB0byB0aGUgbmVhcmVzdCBSRC4gSW4gdGhlc2UgY2Fz ZXMgdGhlIGNsaWVudCBkb2Vzbid0IGtub3cgKHlldCkgdGhlIHNwZWNpZmljIHJlc291cmNlIHRv IGNvbnRhY3QgdGhlIFJELCBzbyB1c2luZyBhIHdlbGwta25vd24gcmVzb3VyY2UgaGVscHMgdG8g b3ZlcmNvbWUgdGhpcyBpc3N1ZS4gICBPZiBjb3Vyc2UgdGhlIGVuZHBvaW50IGNvdWxkIGluIHBy aW5jaXBsZSB1bmljYXN0IGRpc2NvdmVyIHRoZSBSRCByZXNvdXJjZSBhdCBjb2FwOi8vW1JELUlQ djYtYWRkcmVzc10vLndlbGwta25vd24vY29yZT9ydD1jb3JlLnJkICwgYnV0IHRoYXQgd291bGQg YWRkIG1vcmUgY29tcGxleGl0eSB0byB0aGUgZW5kcG9pbnQgYW5kIG1vcmUgZGF0YSB0cmFmZmlj LiAgSSBhc3N1bWUgdGhpcyAia2VlcCB0aGUgZW5kcG9pbnQgc2ltcGxlIiB3YXMgdGhlIHJlYXNv biB0byB1c2UgYSB3ZWxsLWtub3duIFVSSS4NCg0KKiogTm90ZSBmb3IgUkQgZWRpdG9ycw0KSSBh c3N1bWUgbXVsdGljYXN0IFBPU1RpbmcgdG8gbXVsdGlwbGUgUkRzIGlzIG5vdCBzdXBwb3J0ZWQg ZXZlbiB0aG91Z2ggU2VjdGlvbiA1LjMuMiB1c2VzIGEgbXVsdGljYXN0IGFkZHJlc3MgW2ZmMDI6 OjFdIGluIHRoZSBleGFtcGxlLiAoVGhpcyBzZWVtcyB3cm9uZyBoZXJlPykuDQpBbHNvIGluIHRo ZSBjdXJyZW50IGRyYWZ0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gU2ltcGxlIFJlZ2lzdHJhdGlv biA1LjMuMSBhbmQgU2ltcGxlIFB1Ymxpc2hpbmcgNS4zLjIgaXMgbm90IGNsZWFyLiAoVGhleSBh cHBlYXIgZGlmZmVyZW50IG1lY2hhbmlzbXMsIGJ1dCB3aGVuIGxvb2tpbmcgY2xvc2VyIHRoZXkg YXBwZWFyIHRoZSBzYW1lIG1lY2hhbmlzbS4uLikgUkQtMDggZm9yIGV4YW1wbGUgbWFrZXMgbW9y ZSBjbGVhciB0aGF0IHRoZXNlIGFyZSBvbmUgYW5kIHRoZSBzYW1lIHByb2Nlc3MuIExldCdzIGdp dmUgdGhlc2UgdHdvIG9uZSBuYW1lIHRoZW4/DQoNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBTdHVhcnQgTG9uZ2xhbmQNClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAyNSwgMjAx NyAwOTo1MA0KVG86IGNvcmVAaWV0Zi5vcmcgV0cgKGNvcmVAaWV0Zi5vcmcpIDxjb3JlQGlldGYu b3JnPg0KU3ViamVjdDogW2NvcmVdIFNpbXBsZSByZWdpc3RyYXRpb24gYW5kIFVSSSBsZW5ndGgg cmVzdHJpY3Rpb25zDQoNCkhpIGFsbCwNCg0KSSdtIGluIHRoZSBwcm9jZXNzIG9mIHdyaXRpbmcg YSBwcm9vZi1vZi1jb25jZXB0IGltcGxlbWVudGF0aW9uIG9mIHRoZSBDb1JFIHJlc291cmNlIGRp c2NvdmVyeSBzZXJ2ZXIgZm9yIHRoZSBwdXJwb3NlIG9mIGFsbG93aW5nIGRldmljZXMgb24gYSBU aHJlYWQvNkxvV1BBTiBuZXR3b3JrIHRvICJsb2cgaW4iLg0KDQpSZWFkaW5nIHRoZSBzcGVjLCBh bmQgdGFraW5nIGludG8gYWNjb3VudCB0aGUgbGltaXRhdGlvbnMgb2YgdGhlIGRldmljZXMgd2Un cmUgdXNpbmcgKGJ1aWx0IGFyb3VuZCBUSSdzIENDMjUzOCBhbmQgcnVubmluZyB0aGUgT3BlblRo cmVhZCBmaXJtd2FyZSBzdGFjayksIEkgZmlndXJlZCB0aGUgU2ltcGxlIHB1Ymxpc2hpbmcgbWVj aGFuaXNtIHdvdWxkIGJlIHRoZSBlYXNpZXN0IHRvIGltcGxlbWVudCBhcyBJIGFscmVhZHkgaGF2 ZSB0aGUgLy53ZWxsLWtub3duL2NvcmUgZW5kcG9pbnQgd29ya2luZyBvbiB0aGUgZGV2aWNlcyAo aXQganVzdCBjb3VnaHMgdXAgc3RhdGljIG91dHB1dCkuDQoNCkZvciBzaW1wbGljaXR5J3Mgc2Fr ZSwgSSB3YXMgZ29pbmcgdG8gdXNlIHRoZSBFVUk2NCBvZiB0aGUgZGV2aWNlIGFzIHRoZSBlbmRw b2ludCBuYW1lLg0KDQpUaGUgcHJvYmxlbSBzZWVtcyB0byBiZSB0aGUgc2l6ZSBvZiB0aGUgVVJJ IHRoaXMgZ2VuZXJhdGVzLCB0aGUgc3BlYyBzYXlzwrk6DQo+IDUuMy4yLiAgU2ltcGxlIHB1Ymxp c2hpbmcgdG8gUmVzb3VyY2UgRGlyZWN0b3J5IFNlcnZlcg0KPg0KPiAgICBBbiBlbmRwb2ludCB0 aGF0IHdhbnRzIHRvIG1ha2UgaXRzZWxmIGRpc2NvdmVyYWJsZSBvY2Nhc2lvbmFsbHkgc2VuZHMN Cj4gICAgYSBQT1NUIHJlcXVlc3QgdG8gdGhlICIvLndlbGwta25vd24vY29yZSIgVVJJIG9mIGFu eSBjYW5kaWRhdGUNCj4gICAgZGlyZWN0b3J5IHNlcnZlciB0aGF0IGl0IGZpbmRzLiAgVGhlIGJv ZHkgb2YgdGhlIFBPU1QgcmVxdWVzdCBpcw0KPiAgICBlbXB0eSwgd2hpY2ggdHJpZ2dlcnMgdGhl IHJlc291cmNlIGRpcmVjdG9yeSBzZXJ2ZXIgdG8gcGVyZm9ybSBHRVQNCj4gICAgcmVxdWVzdHMg YXQgdGhlIHJlcXVlc3Rpbmcgc2VydmVyJ3MgZGVmYXVsdCBkaXNjb3ZlcnkgVVJJIHRvIG9idGFp bg0KPiAgICB0aGUgbGluay1mb3JtYXQgcGF5bG9hZCB0byByZWdpc3Rlci4NCj4NCj4gICAgVGhl IGVuZHBvaW50IE1VU1QgaW5jbHVkZSB0aGUgZW5kcG9pbnQgbmFtZSBhbmQgTUFZIGluY2x1ZGUg dGhlDQo+ICAgIHJlZ2lzdHJhdGlvbiBwYXJhbWV0ZXJzIGQsIGx0LCBhbmQgZXQsIGluIHRoZSBQ T1NUIHJlcXVlc3QgYXMgcGVyDQo+ICAgIFNlY3Rpb24gNS4zLg0KPg0KPiAgICBUaGUgZm9sbG93 aW5nIGV4YW1wbGUgc2hvd3MgYW4gZW5kcG9pbnQgdXNpbmcgc2ltcGxlIHB1Ymxpc2hpbmcsIGJ5 DQo+ICAgIHNpbXBseSBzZW5kaW5nIGFuIGVtcHR5IFBPU1QgdG8gYSByZXNvdXJjZSBkaXJlY3Rv cnkuDQo+DQo+ICAgIFJlcToodG8gUkQgc2VydmVyIGZyb20gW2ZmMDI6OjFdKQ0KPiAgICBQT1NU IGNvYXA6Ly9yZC5leGFtcGxlLmNvbS8ud2VsbC1rbm93bi9jb3JlP2x0PTYwMDA7ZXA9bm9kZTEN Cg0KSSdtIHRlc3RpbmcgdGhpcyB3aXRoIHRoZSBPcGVuVGhyZWFkIENMSSwgYW5kIEkndmUgZGlz Y292ZXJlZCB0aGF0IGl0IGxpbWl0cyBVUklzIHRvIDMyIGNoYXJhY3RlcnMuICBUaGlzIG1lYW5z IG15IGVuZHBvaW50IG5hbWUgZ2V0cyBjaG9wcGVkIG9mZi4gIFRoaXMgaXMgdGhlIG91dGdvaW5n IHJlcXVlc3Q6DQoNCj4+IGNvYXAgcG9zdCBmZGRlOmFkMDA6YmVlZjowOjUyYzI6OWY5ZTo2ZTZk OmFkZTENCj4+IC53ZWxsLWtub3duL2NvcmU/ZXA9MTFmNDdiNTgwMDEyNGIwMCZsdD0zMDANCj4g U2VuZGluZyBjb2FwIHJlcXVlc3Q6IERvbmUNCg0KYW5kIG15IHNlcnZlciAoaW1wbGVtZW50ZWQg d2l0aCBub2RlLWNvYXApIHNlZXMgdGhpczoNCj4gWzIwMTctMTAtMjVUMDc6Mjc6NTAuMDE3Wl0g IElORk86IFdpZGVTa3lDb0FQR2F0ZXdheS9jb2FwLzEwMTM0IG9uIHZrNG1zbC13czogQmVnaW4g cmVxdWVzdCAobWV0aG9kPVBPU1QsIHVyaT0vLndlbGwta25vd24vY29yZT9lcD0xMWY0N2I1ODAw MSkNCj4gICAgIHNvdXJjZTogew0KPiAgICAgICAiYWRkcmVzcyI6ICJmZGRlOmFkMDA6YmVlZjo6 ZmY6ZmUwMDplYzAwIiwNCj4gICAgICAgImZhbWlseSI6ICJJUHY2IiwNCj4gICAgICAgInBvcnQi OiA1NjgzLA0KPiAgICAgICAic2l6ZSI6IDM5DQo+ICAgICB9DQoNCkkgY2FuIGNoYW5nZSB0aGlz IGluIE9wZW5UaHJlYWQgb2YgY291cnNlLCBJJ3ZlIGlkZW50aWZpZWQgd2hlcmUgdGhlIGNoYW5n ZXMgd291bGQgbmVlZCB0byBnbywgaG93ZXZlciB0aGUgb3RoZXIgZXhhbXBsZXMgdXNlIHRoZSBt dWNoIHNob3J0ZXIgYC9yZGAgZW5kcG9pbnQsIHdoaWNoIGF2b2lkcyBzb21lIG9mIHRoZXNlIHBy b2JsZW1zLiAgSSB3YXMgd29uZGVyaW5nIHdoZXRoZXIgaXQgd2FzIGFjdHVhbGx5IGludGVuZGVk IHRoYXQgYC8ud2VsbC1rbm93bi9jb3JlYCBiZSB1c2VkIG9yIHdoZXRoZXIgdGhpcyB3YXMgb3Zl cmxvb2tlZD8NCg0KUmVnYXJkcywNCi0tDQogICAgIF8gX19fICAgICAgICAgICAgIFN0dWFydCBM b25nbGFuZCAtIFN5c3RlbXMgRW5naW5lZXINClwgIC98XykgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgIFQ6ICs2MSA3IDM1MzUgOTYxOQ0KIFwvIHwgXCB8ICAgICAzOGIgRG91Z2xhcyBTdHJl ZXQgICAgRjogKzYxIDcgMzUzNSA5Njk5DQogICBTWVNURU1TICAgIE1pbHRvbiBRTEQgNDA2NCAg ICAgICBodHRwOi8vd3d3LnZydC5jb20uYXUNCg0KMS4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWNvcmUtcmVzb3VyY2UtZGlyZWN0b3J5LTExI3NlY3Rpb24tNQ0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWls aW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY29yZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGVtYWlsIG1heSBiZSBjb25maWRlbnRpYWwgYW5kL29y IGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwg Zm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgZW1haWwg aXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJl dHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgZW1haWwu DQo= From nobody Wed Oct 25 02:30:51 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC509139950 for ; Wed, 25 Oct 2017 02:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Vbj6nslWxIRE for ; Wed, 25 Oct 2017 02:30:48 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C2A139680 for ; Wed, 25 Oct 2017 02:30:48 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 2317B482A2; Wed, 25 Oct 2017 11:30:46 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0FB1E2A; Wed, 25 Oct 2017 11:30:44 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id D8E0557; Wed, 25 Oct 2017 11:30:43 +0200 (CEST) Received: (nullmailer pid 26692 invoked by uid 1000); Wed, 25 Oct 2017 09:30:43 -0000 Date: Wed, 25 Oct 2017 11:30:43 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Stuart Longland Cc: "core@ietf.org WG (core@ietf.org)" Message-ID: <20171025093042.tkgx5justvcnxtl3@hephaistos.amsuess.com> References: <48729a59-f5e8-e20a-f1cb-7a0bb64b1d8d@vrt.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pbl32gicsop2nokd" Content-Disposition: inline In-Reply-To: <48729a59-f5e8-e20a-f1cb-7a0bb64b1d8d@vrt.com.au> User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [core] Simple registration and URI length restrictions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Oct 2017 09:30:51 -0000 --pbl32gicsop2nokd Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Stuart, On Wed, Oct 25, 2017 at 05:49:33PM +1000, Stuart Longland wrote: > I can change this in OpenThread of course, I've identified where the > changes would need to go, however the other examples use the much > shorter `/rd` endpoint, which avoids some of these problems. I was > wondering whether it was actually intended that `/.well-known/core` be > used or whether this was overlooked? The short `/rd` is only an example and needs to be discovered using the discovery steps unless Simple Registration is performed. It is up to the resource directory to pick its own path, which may be as short as `/rd` or even longer than `.well-known/core`. Registration without the URI discovery steps (ie. Simple Registraition, which sounds very suitable for the use case you decribe) can only happen to a .well-known URI, or it would enforce a particular path design on the server. I recommend to increase the limit of the URI length; as long as you statically know the ep name length and use Simple Registration, you can be sure that even a short (but longer than 32 bytes) length it sufficient, as opposed to URI discovery where you'd need to be prepared to process much longer URIs. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --pbl32gicsop2nokd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlnwWcAACgkQOY0REtOk veEt2Q//QvvkfNHr0ML6/hOXwJ9IkgelO9na3ORlAOZC8pFoLCxOTvITP7xHMT1i pHMfYtcXMjM8HyqdqOr8MivOY7JYFa3O3CWj/w+8s5DhYqvypaICD6TPEAXh+7tV qzjEEhNbEcvGhYcHhKbl9valp81Yff8hfBkYwDuAjgSXYeI5Ck5uiGCYBEX+y2EQ cZwKUAyQnLn5uwsVerEAFfJJXNXO5FfqcnQQgMrDDVtZj4uYOH5PXTMxLv6VjEfJ w26jDvZ38573TXDRoenkReqJr/7a8E4VkYzKAiho7yJkYUKXqXYm/AJeKVZD2xty g5b6xdjTM9ubd6+PtknP3lXIzkvAMhms1kHX+UVk02jRcrGZRm/tISwOJIEGSb45 6P/df2jHcU8QHIhOzGf5BAm3RoJBn52FvxEy0xpAAnp45VQ2BkQWSbJRY72nDfqA VJnLXUlxMAm3NYwLzm9eH7dOoR3DqJF6BQseqtksdFuAACRl7L1JOmXWaLtpwHcQ IVOGYPEX4c/SwcOI/bJpWNNDL5eUUEDyZLG8V24BbzAeeCRQjt97S62FbcN20uwo 1Iv/J4aUobvSORxH76dmiqruBF+9eISwypy/tzvNC7oALHuF2oFrFlQRC7FNOSSX tC4ay6fmFYbtCGCaCobn58T8dwcVjTcxzUBljDkxT1nRF1A0RjA= =IjXt -----END PGP SIGNATURE----- --pbl32gicsop2nokd-- From nobody Wed Oct 25 06:22:36 2017 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 02667137C2E; Wed, 25 Oct 2017 06:22:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150893775396.4719.13813603602545221804@ietfa.amsl.com> Date: Wed, 25 Oct 2017 06:22:34 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-object-security-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 13:22:34 -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 : Object Security for Constrained RESTful Environments (OSCORE) Authors : Göran Selander John Mattsson Francesca Palombini Ludwig Seitz Filename : draft-ietf-core-object-security-06.txt Pages : 45 Date : 2017-10-25 Abstract: This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end encryption, integrity and replay protection, as well as a secure message binding. OSCORE is designed for constrained nodes and networks and can be used over any layer and across intermediaries, and also with HTTP. OSCORE may be used to protect group communications as is specified in a separate draft. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-object-security-06 https://datatracker.ietf.org/doc/html/draft-ietf-core-object-security-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-object-security-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 Wed Oct 25 12:52:42 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BC3139095; Wed, 25 Oct 2017 12:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Qva2aN0f_4Fa; Wed, 25 Oct 2017 12:52:39 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 95512138AEE; Wed, 25 Oct 2017 12:52:38 -0700 (PDT) X-AuditID: c1b4fb2d-bf5ff7000000268d-ac-59f0eb84baa0 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 16.10.09869.48BE0F95; Wed, 25 Oct 2017 21:52:36 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; Wed, 25 Oct 2017 21:52:35 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core CC: "draft-ietf-core-senml@ietf.org" Thread-Topic: SenML unit registry policy update Thread-Index: AQHTTcrNzhyxXu8yeEmEx4uZqfGivQ== Date: Wed, 25 Oct 2017 19:52:35 +0000 Message-ID: <7ECB01B5-6750-438C-9053-35C1AE2CFBB2@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <71172BF255683E46B238EA8BBEF6839E@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2K7vW7L6w+RBi+OC1jse7ue2eLnuyXM DkweS5b8ZApgjOKySUnNySxLLdK3S+DKeHPyLHvBL+aKI5efsjcw9jN3MXJySAiYSJw5e5Gl i5GLQ0jgCKPEr9ZHjBDOYkaJCxefsoNUsQnYS0xe85ERxBYRkJDo/LofLM4s4Crxe+1NsLiw gJbEhlf/mSFq9CWmXLnE1sXIAWTrSZxdyAsSZhFQleieshisnBdo5LtFl1lBbEYBMYnvp9Yw QYwUl7j1ZD4TxHECEkv2nIc6VFTi5eN/rBC2ksTaw9tZIOr1JG5MncIGYVtL3JnxBSquLbFs 4WtmiF2CEidnPmGZwCgyC8mKWUjaZyFpn4WkfRaS9gWMrKsYRYtTi4tz042M9VKLMpOLi/Pz 9PJSSzYxAqPj4JbfujsYV792PMQowMGoxMNr8PJDpBBrYllxZe4hRgkOZiUR3lmvgEK8KYmV ValF+fFFpTmpxYcYpTlYlMR5HfZdiBASSE8sSc1OTS1ILYLJMnFwSjUwht5grlo5963uakmG qw7VK48FSRR9UGru0TjR9l8iliflmumuudKZ3zUC5dnn9K57Y3ciKdfzxqV7YpVZ+zfNSrZe M51plyif4pv5gZwrLP8cqrkuyS51NczlzQlBjmWf3lhVbr954lb1oX3XDi978bd9OZO44CpH cfuP/Uy/KhQvHMg/sUj+kBJLcUaioRZzUXEiAHh2zoeKAgAA Archived-At: Subject: [core] SenML unit registry policy update X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Oct 2017 19:52:41 -0000 Hi all, At the IETF 99 CoRE session we discussed whether the unit registry should h= ave "IESG approval" in addition to the "Expert review" policy. There seemed= to be more support for just "Expert review" to avoid confusion with what i= s the right path but it was concluded that we should bring this to the list= too. Here's a PR that fixes this: https://github.com/core-wg/senml-spec/pull/80/files If there's no objections, we'll merge that for the next version. Cheers, Ari From nobody Wed Oct 25 13:04:25 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8ABE138F9C for ; Wed, 25 Oct 2017 13:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=augustcellars.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 gAMnJ5N22tE4 for ; Wed, 25 Oct 2017 13:04:20 -0700 (PDT) Received: from mail4.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 836CE1386A2 for ; Wed, 25 Oct 2017 13:04:20 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_018A_01D34D91.C28996F0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1508961802; h=from:subject:to:date:message-id; bh=dpA6oC9EBTMcqLSfbECE0Hwq2Bl2PhwVBNDVA/gvUyQ=; b=aBd0osqnShriWe0EcxMnQBJhZlHzme1Fbz6ANh4yACYpjfZxArshQFxy/UJrVHj54P//QThjjZH TNbRfl0WCBdG1jl7NEhg/7zLESkW8/Sdcha0A32Q73oIuGrpsKkF/ao9uWhwBecNFU/ffTz6BNbxi L8i1/7WWduy97yiLHkexcY2Xv/BuZXKZJgN2727okFJnpYX6Pedf/bB3nN5LhM0XAn63cNFkpz0MS iDfuf9rbw3k7jGZcH1g3jNhi/+2MniQ6YcBXakqz3DO+04hvgO5K4aGHJJu0SgJmqXj0pREm6CbMg 6Chd5F9rmbBEwlnomI1maHwmA6L5nHOXi2Xw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 25 Oct 2017 13:03:22 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 25 Oct 2017 13:03:18 -0700 From: Jim Schaad To: =?utf-8?Q?'Jaime_Jim=C3=A9nez'?= , References: In-Reply-To: Date: Wed, 25 Oct 2017 13:04:12 -0700 Message-ID: <018901d34dcc$6ee5fdf0$4cb1f9d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIaJGwH9kzXlzkJW35TDUFXFE4YcaJnT7hw X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 25 Oct 2017 20:04:23 -0000 ------=_NextPart_000_018A_01D34D91.C28996F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I should have relied at the time, but better late than never. =20 I believe that the request field absolute must be adopted. I am = agnostic about the repeat field although I do see the usefulness of = having it =20 Jim =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Jaime = Jim=C3=A9nez Sent: Wednesday, October 4, 2017 1:00 AM To: core@ietf.org WG (core@ietf.org) Subject: [core] =F0=9F=94=94 WG Call for Adoption on = draft-amsuess-core-repeat-request-tag-00 =20 Dear CoRE WG, =20 during last IETF the following draft was presented: https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00=20 =20 The draft mitigates known issues with the freshness of a CoAP request as = well as fragmentation of the CoAP message body.=20 There was strong room consensus or adoption so this is just to confirm = it. Please reply to the list with your comments, including although not = limited to whether or not you support adoption. Non-authors are = especially encouraged to comment. =20 Target for the end of the WGA call is 16th October.=20 =20 Ciao, - - Jaime Jim=C3=A9nez =20 ------=_NextPart_000_018A_01D34D91.C28996F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I should = have relied at the time, but better late than never.

 

I believe = that the request field absolute must be adopted.=C2=A0 I am agnostic = about the repeat field although I do see the usefulness of having = it

 

Jim

 

From: core = [mailto:core-bounces@ietf.org] On Behalf Of Jaime = Jim=C3=A9nez
Sent: Wednesday, October 4, 2017 1:00 = AM
To: core@ietf.org WG (core@ietf.org) = <core@ietf.org>
Subject: [core] 🔔 WG = Call for Adoption on = draft-amsuess-core-repeat-request-tag-00

 

Dear CoRE = WG,

 

during last IETF the following draft was = presented:

 

The draft mitigates known issues with the freshness of = a CoAP request as well as fragmentation of the CoAP message = body. 

There was = strong room consensus or adoption so this is just to confirm it. Please = reply to the list with your comments, including although = not limited to whether or not you support adoption. = Non-authors are especially encouraged to = comment.

 

Target for the end of the WGA call is 16th = October. 

 

Ciao,

- - Jaime = Jim=C3=A9nez

 

------=_NextPart_000_018A_01D34D91.C28996F0-- From nobody Wed Oct 25 23:47:51 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AE613A441 for ; Wed, 25 Oct 2017 23:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kzY_i9Er74Ub for ; Wed, 25 Oct 2017 23:47:48 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC63138FA0 for ; Wed, 25 Oct 2017 23:47:48 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 8BF4A482B0; Thu, 26 Oct 2017 08:47:45 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id BFF092A; Thu, 26 Oct 2017 08:47:43 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.130]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 7156057; Thu, 26 Oct 2017 08:47:43 +0200 (CEST) Received: (nullmailer pid 6417 invoked by uid 1000); Thu, 26 Oct 2017 06:47:42 -0000 Date: Thu, 26 Oct 2017 08:47:42 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Esko Dijk Cc: "core@ietf.org WG (core@ietf.org)" Message-ID: <20171026064741.t2q5rlzfrvvv7a7y@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oz53dgaezmbyftzw" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [core] Simple registration and URI length restrictions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 06:47:50 -0000 --oz53dgaezmbyftzw Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Esko, On Wed, Oct 25, 2017 at 08:52:34AM +0000, Esko Dijk wrote: > I assume multicast POSTing to multiple RDs is not supported even > though Section 5.3.2 uses a multicast address [ff02::1] in the > example. (This seems wrong here?). The multicast address was used erroneously in that example; the upcoming next draft version fixes that. > Also in the current draft the difference between Simple Registration > 5.3.1 and Simple Publishing 5.3.2 is not clear. (They appear different > mechanisms, but when looking closer they appear the same mechanism...) > RD-08 for example makes more clear that these are one and the same > process. Let's give these two one name then? Only one mechanism is meant. Good point, thanks, taken up on the issue tracker[1]. Best regards Christian [1]: https://github.com/core-wg/resource-directory/issues/75 --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --oz53dgaezmbyftzw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlnxhQoACgkQOY0REtOk veHy+xAAyRn4p2wTnL0EqnR72J8AH2beizeP9DW1oPtEvaw1kv2h/BUYyrTRV019 g+Akkck1KKYy1r/9uv2aO9DYfbD7jCU7sVydwfYX7PrL1UOC/IyjbJTRTjlv7bE0 tAehEpFOv9UKnjf2kO0e98ZwNXTNfV68ccFbrxReC4zQxXhobhK/w6FMmDdtVJoz OFP2rLkVgLtoK0x65NoqEm3db7cyBFvTfnFkELALhkznyzH5DRyWI16lMwmD4lIr RP/JbDLlqtpVOoCBf42J6p6ZVNC5aUVo9sdxLQwPoCVAsI8Kha+6gOl5A564H69s 8OwJBEFUTsBaFhpbO5bh70R5beKbj1Gc/NIxCJ3jBVprl35tRFsrmTId6rKqXNPr acPB875LRxxnbgZAdxRSqYdleiHsvf6frcmtMHV2b/HjTfAxlPoLCBwvopz9E/86 wIQq7hhE0/OzAWtbJy1710blXWrc38FfCi83k4F8EkilyaguFVVVWFYhImlg8OE8 8SbRfBAQeuaPoRb+nTTGb4+sBrDxX6Y+H44MXIY8xr5ihhNuyT07oKW5SdcUeZ8G nBfKkU4B9J1RIiWYJfY51ptCa9P901qlHa2L52JkJ7ryYyNoSgz9kpvD4luplco7 XiU4qYzspshllzebKdxi5fi/09H1m5cmGqnnPaCz6YNO+yUzUqg= =E8lT -----END PGP SIGNATURE----- --oz53dgaezmbyftzw-- From nobody Thu Oct 26 00:22:27 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C9913A441 for ; Thu, 26 Oct 2017 00:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 WkJEQOJX_KDY for ; Thu, 26 Oct 2017 00:22:23 -0700 (PDT) Received: from bne.vrt.com.au (bne-eth.vrt.com.au [103.225.70.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4224313915C for ; Thu, 26 Oct 2017 00:22:23 -0700 (PDT) Received: from bne.vrt.com.au (localhost [127.0.0.1]) by bne.vrt.com.au (Postfix) with ESMTP id 6EB7C8030893D; Thu, 26 Oct 2017 17:22:21 +1000 (AEST) Received: by bne.vrt.com.au (Postfix, from userid 8) id 5A9CE8085C77D; Thu, 26 Oct 2017 17:22:21 +1000 (AEST) Received: from bneprdmail (unknown [10.87.160.28]) by bne.vrt.com.au (Postfix) with ESMTP id 6F1838030893D; Thu, 26 Oct 2017 17:22:10 +1000 (AEST) Received: from [10.87.130.82] (unknown [10.87.130.82]) by bneprdmail (Postfix) with ESMTPSA id 9438752F25; Thu, 26 Oct 2017 17:22:10 +1000 (AEST) To: Esko Dijk , "core@ietf.org WG (core@ietf.org)" References: <48729a59-f5e8-e20a-f1cb-7a0bb64b1d8d@vrt.com.au> From: Stuart Longland Openpgp: id=B8AA34BA25C794168FAEF315A02404BC58650CF9; url=https://stuartl.longlandclan.id.au/key.asc Organization: VRT Systems Message-ID: <72045bd2-f3e9-015d-4ee5-37cdc0b40700@vrt.com.au> Date: Thu, 26 Oct 2017 17:22:08 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Archived-At: Subject: Re: [core] Simple registration and URI length restrictions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 07:22:26 -0000 On 25/10/17 18:52, Esko Dijk wrote: > In general the problem in OpenThread CLI code should be fixed anyhow, > because you can never know at which URI people will host their RD. It > may be very long! Especially when OpenThread code ends up into > products it needs to be right. This is true, especially if it's actually implemented as a HTTP service on the other side of a proxy. (I'd hope not, but you never know.) I have in fact, amended OpenThread to cope with this: https://github.com/vrtsystems/openthread/commit/fd8b6fd2460f2abbbf2318f17d3848742ff15009 I'll raise it with them on their mailing list and see about making this configurable in the sources (I'm thinking a #define). Thankfully it doesn't appear to be a limitation of the underlying CoAP client. > Still a good question I think, because the current draft states that > an endpoint first discovers RD(s) and then publishes itself (using > the Section 5.3.2 POST approach) to one or more selected RD(s). Since > the endpoint already did the discovery, it knows the resource at > which the RD service resides (e.g. /rd). So why doesn't it use that > resource /rd to publish itself? That's the RD where the device wants > to register. Well, that's why I wondered if there was an omission here. I could see good reasons for using `.well-known/core`, but it also made me wonder if a suitable half-way compromise could be used. Arguably there's nothing stopping me from breaking out my function that replies to `.well-known/core` with the list of endpoints and calling that to generate the `POST` payload when registering if I'm going to do it the long way. :-) > One valid reason to still use /.well-known/core is the fact that > sometimes only the IPv6 address, or an IPv6 hostname, of the RD can > be distributed in a network using specific means. E.g. > https://tools.ietf.org/html/draft-ietf-core-resource-directory-11#section-9.2 > states how an ND option can do this. In some deployments it may be a > well-known anycast IP address pointing to the nearest RD. In these > cases the client doesn't know (yet) the specific resource to contact > the RD, so using a well-known resource helps to overcome this issue. So if a device doesn't know a target address, I'm guessing the anycast IP address is the intended mechanism by which to perform service publication? > ** Note for RD editors I assume multicast POSTing to multiple RDs is > not supported even though Section 5.3.2 uses a multicast address > [ff02::1] in the example. (This seems wrong here?). Also in the > current draft the difference between Simple Registration 5.3.1 and > Simple Publishing 5.3.2 is not clear. (They appear different > mechanisms, but when looking closer they appear the same > mechanism...) RD-08 for example makes more clear that these are one > and the same process. Let's give these two one name then? Is it particularly harmful to do a POST to a multicast address? Presumably the other nodes not set up as RD could just ignore the POST. I was planning to have the nodes POST to coap://[ff05::fd]/.well-known/core… at the moment I'm just unicasting it as I'm finding `node-coap` a little reluctant to join multicast IPv6 groups. The intricacies of multicast programming is something I'm still just getting my head around, and in the IPv6 context in particular; while I've been experimenting with it privately at home, this has largely been unicast communications. I'll have a look at using anycast addresses, see if that offers a viable solution too. I don't want to hard-code addresses if I can avoid it. :-) Many thanks. Regards, -- _ ___ Stuart Longland - Systems Engineer \ /|_) | T: +61 7 3535 9619 \/ | \ | 38b Douglas Street F: +61 7 3535 9699 SYSTEMS Milton QLD 4064 http://www.vrt.com.au From nobody Thu Oct 26 00:26:28 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B296F13A902 for ; Thu, 26 Oct 2017 00:26:27 -0700 (PDT) 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] 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 gJU1wuJPFxhf for ; Thu, 26 Oct 2017 00:26:24 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 02C3813A441 for ; Thu, 26 Oct 2017 00:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9Q7QKTP013217; Thu, 26 Oct 2017 09:26:20 +0200 (CEST) Received: from client-0191.vpn.uni-bremen.de (client-0191.vpn.uni-bremen.de [134.102.107.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yMz8D5GcQzDWMw; Thu, 26 Oct 2017 09:26:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <72045bd2-f3e9-015d-4ee5-37cdc0b40700@vrt.com.au> Date: Thu, 26 Oct 2017 09:26:20 +0200 Cc: Esko Dijk , "core@ietf.org WG (core@ietf.org)" X-Mao-Original-Outgoing-Id: 530695580.009739-62a6672b011cf6f51b1c155b3ef066f8 Content-Transfer-Encoding: quoted-printable Message-Id: References: <48729a59-f5e8-e20a-f1cb-7a0bb64b1d8d@vrt.com.au> <72045bd2-f3e9-015d-4ee5-37cdc0b40700@vrt.com.au> To: Stuart Longland X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Simple registration and URI length restrictions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 07:26:28 -0000 On Oct 26, 2017, at 09:22, Stuart Longland wrote: >=20 > So if a device doesn't know a target address, I'm guessing the anycast > IP address is the intended mechanism by which to perform service > publication? We have recently cleaned up the section "Finding a Resource = Directory=E2=80=9D. = https://core-wg.github.io/resource-directory/draft-ietf-core-resource-dire= ctory.html#rfc.section.4 Please let us know whether that works for you. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 26 00:58:40 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1766613AB34 for ; Thu, 26 Oct 2017 00:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 IAe-RahnLVoB for ; Thu, 26 Oct 2017 00:58:23 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC6F139689 for ; Thu, 26 Oct 2017 00:58:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.43,434,1503352800"; d="scan'208,217";a="297969304" Received: from unknown (HELO [89.188.33.198]) ([89.188.33.198]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2017 09:58:20 +0200 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A8452FDB-29D0-4A99-A967-94383A074E5F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 26 Oct 2017 09:58:21 +0200 In-Reply-To: <018901d34dcc$6ee5fdf0$4cb1f9d0$@augustcellars.com> Cc: =?utf-8?Q?Jaime_Jim=C3=A9nez?= , core@ietf.org To: Jim Schaad References: <018901d34dcc$6ee5fdf0$4cb1f9d0$@augustcellars.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 07:58:26 -0000 --Apple-Mail=_A8452FDB-29D0-4A99-A967-94383A074E5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My take on this is that the Repeat option seems quite useful for replay = mitigation in the case where OSCORE server reboots. Thus, I support the = adoption. Mali=C5=A1a > On 25 Oct 2017, at 22:04, Jim Schaad wrote: >=20 > I should have relied at the time, but better late than never. > =20 > I believe that the request field absolute must be adopted. I am = agnostic about the repeat field although I do see the usefulness of = having it > =20 > Jim > =20 > From: core [mailto:core-bounces@ietf.org] On Behalf Of Jaime Jim=C3=A9ne= z > Sent: Wednesday, October 4, 2017 1:00 AM > To: core@ietf.org WG (core@ietf.org) > Subject: [core] =F0=9F=94=94 WG Call for Adoption on = draft-amsuess-core-repeat-request-tag-00 > =20 > Dear CoRE WG, > =20 > during last IETF the following draft was presented: > https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00 = =20= > =20 > The draft mitigates known issues with the freshness of a CoAP request = as well as fragmentation of the CoAP message body.=20 > There was strong room consensus or adoption so this is just to confirm = it. Please reply to the list with your comments, including although not = limited to whether or not you support adoption. Non-authors are = especially encouraged to comment. > =20 > Target for the end of the WGA call is 16th October.=20 > =20 > Ciao, > - - Jaime Jim=C3=A9nez > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_A8452FDB-29D0-4A99-A967-94383A074E5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My take on this is that the Repeat option seems quite useful = for replay mitigation in the case where OSCORE server reboots. Thus, I = support the adoption.

Mali=C5=A1a

On = 25 Oct 2017, at 22:04, Jim Schaad <ietf@augustcellars.com> wrote:

I should have relied at the time, but better late than = never.
 
I believe that the request field absolute must be = adopted.  I am agnostic about the repeat field although I do see = the usefulness of having it
 
Jim
 
From: core [mailto:core-bounces@ietf.org] On Behalf = Of Jaime = Jim=C3=A9nez
Sent: Wednesday, October 4, 2017 = 1:00 AM
To: core@ietf.org WG (core@ietf.org) <core@ietf.org>
Subject: [core] =F0=9F=94=94 WG Call for Adoption on = draft-amsuess-core-repeat-request-tag-00
 
Dear CoRE WG,
 
during last IETF the following draft was presented:
 
The draft mitigates known issues with the freshness of a CoAP = request as well as fragmentation of the CoAP message body. 
There was strong room consensus or adoption so this is just = to confirm it. Please reply to the list with your comments, including = although not limited to whether or not you support adoption. = Non-authors are especially encouraged to comment.
 
Target for the end of the WGA call is = 16th October. 
 
Ciao,
- - Jaime Jim=C3=A9nez
 
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_A8452FDB-29D0-4A99-A967-94383A074E5F-- From nobody Thu Oct 26 03:57:49 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AD313F555 for ; Thu, 26 Oct 2017 03:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 Pq8Ss37a-RvD for ; Thu, 26 Oct 2017 03:57:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 5A1631387BC for ; Thu, 26 Oct 2017 03:57:46 -0700 (PDT) Received: from [192.168.91.204] ([80.92.116.6]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MbJTE-1drEvj3IP6-00IieZ; Thu, 26 Oct 2017 12:57:35 +0200 To: Carsten Bormann Cc: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org WG (core@ietf.org)" References: <1a9f165d-6994-a92f-3e93-faabf9c690ba@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <26860663-b0c3-981a-5b91-34645786968b@gmx.net> Date: Thu, 26 Oct 2017 12:57:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:xK+SoIuS7CUj4MpLtHwI39wzbbKMNw/rihNVgLS3o1YRgPCOUuP 9LZiSFP/QiGl0H2RQgs0M0fDvB3KoxY+F9EITo+PPt2EIKQIUMqkZ4qhqTmU64Yd6hXXA/5 2f1M+cNsjx5RmEDB+F19xwB69CIJhMQNjrjFzQIdurpXwY5WFPjteFGcRF6COZjmsgNPTiZ s/GKz+Jx36dvBwRJ585nQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:5WoOD/4qQsw=:3D/7ZDlJozVvAg5CltKIKz /SrR7fjLVO07Z11iN1Mi57T4k/hSoEJO47cx/4cPmOzc8OcKA/u4YFEib7LoxrALvGYl95mrJ Z6CYW5FTCLnbp0m2xCQdKqoVaVybrwqmhsR0g6mbfsZVTdzsoYEFmENdnwuVVpqm0XJDnaB4b UncxbDtLPaK1wyNBAsJB20OqAqzc8eB1ANDTMJZ7Oy0q9OnyO7rMmmCtNJJy62cpCv6YKCu4k z3LCGslywIWsnDKq2nSRP5xAz5AXBAdygJsJIjoiZeUGkPt3rNS+lX5XNlSy25JNGmULwWdsd qvmhYkYSm50F60Dnxd8mgwTu4nzRm1VLDEE83cSt/4tx2IUivW3WiJ1yecGlcdqcOIxZh0jL7 wfaOZ1MxMJxHGA+DSFQ4LN1kiBC5i8V3qqehuOmbZo6g04obB026Gv7GaviYPO4xLndp6FpwQ Vgnqx5aZkJJggXDGDTcJnQH4fsnDLbRElmEs8PjigZCaTEjREm5qXidyK8JWvjmrKMASpH4B8 6kGHu16tjX5A+whnGDf7U/JMtpvZmoxe95xMngowVAQPJs7wp70SgEOanN7JLL4NUrFp7z/fR 0wsiwQJHTaV8CMoi/A8HfdpHjqGCMepxDx+B5KrlgQborWjmDqc0XbwXchxPtAvXydFeMl3bR xDq602AkAlaclDKR2xU3kxocB/jTt/DS/V1G/hPURO1uJHLXUc9bOz5fVNw525dpgLT+1MtRk IRgft5Rlgm3lqKOzumsXQhRpbEqKjdlFaxzZ7X5nSoOWTGcbqapvl/GuKi6cWQahumRLJP7yy KYr6gWE9Uu3Ye9Ea6cs0bz0CF7IIPX8UVRroMov20EDVaog17c= Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 10:57:48 -0000 Hi Carsten, I fail to understand the reasoning. You want end-to-end security but then you put a proxy in the middle. Architecturally not a great idea since you don't have to do that. Now the proxy is there. You seem to trust the proxy to process and relay your messages. Probably the proxy does much in order to justify the existence. But then the proxy you previously trusted becomes evil and mounts attacks against your communication. Then, you add this extension. However, you nicely trust the proxy not to do all sorts of other things. For example, it could just drop your messages. It could also delay your messages (which would have pretty nasty effects in an industrial IoT environment where timing matters). Then, you also expose lots of meta-data to this proxy as well (leading to privacy violations). That's seems just fine (and maybe be covered as part of a later draft). For this reason I believe the story is constructed. If you believe the feature is essential for OSCOAP, as it sounds from your second response, then why is this not part of OSCOAP (which is also still work in progress)? Ciao Hannes On 10/25/2017 08:53 AM, Carsten Bormann wrote: > Hi Hannes, > > On Oct 4, 2017, at 16:50, Hannes Tschofenig wrote: >> >> Two comments: >> >> IMHO the presented problems are not worthwhile to solve. > > I’m not sure I understand. The problem pointed out is a security problem in certain applications. > Are you saying we shouldn’t invest time in these applications? > Or are you saying this should instead be solved within the application (which is perfectly possible, but not something we can expect developers to always get right)? > >> Additionally, I >> would prefer if the CORE working group finishes already chartered items >> rather than always adding new stuff. > > I think we can agree on this, but addressing a security problem does have a special importance. > > Grüße, Carsten > From nobody Thu Oct 26 04:24:30 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4AF13F564 for ; Thu, 26 Oct 2017 04:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hyker-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIL0R6kl5U-j for ; Thu, 26 Oct 2017 04:24:27 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 65F6413B2BB for ; Thu, 26 Oct 2017 04:24:27 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id h34so2189147uaa.6 for ; Thu, 26 Oct 2017 04:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hyker-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SdSd2+w+uaVtsMFbB4modNH71aadhDAqsQsJWPhlXLk=; b=nl/mbK9+cjmKTen241TQ9RLg8C1NyxqlBkOelWkoQ23X3PkhMhdkdVod1hAra0brWK B4G3IUogJvevyuTRr+JPc7jTL7KYEK6DgrkaOB5P6ew6Y/xdlr1m+yRr+hHaDNbtq6f8 hmD7D3WFvyyjWfCCRlevzchqtE8Wa/i3Z5PhrrEcFK4A/7UTwS5fSuG/FWAT0zlessZ1 gmICKDdUWWZcsQXsnrkJ49/Le5kyO8B7MO+OAlsqqFLV+rgAH9CfxyDJGqJGJHRYd3nV PJBc0eDvtvDzlKMxhfHNi0xg44ZaK8BwAxq2ATMPxSv3cY4ka22zFm2DKOIL/7qvXSRe A4uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SdSd2+w+uaVtsMFbB4modNH71aadhDAqsQsJWPhlXLk=; b=qYVZEqOzr/y7ttknyeHP7kNOgrEzQr0GMEGn8uGkb8MIrtii5/+WfUmN/TuLawEV82 D9xk3YxgJREgbIC9FSHdE4vIcZ9aVQSgGuJ2ONKprBojEADO0fmDXlSdPawNz+BiwOqa A52j56v/aQoDjCdtp6OKBoT6TU1ML5WtV6EUQDqZmpWB7NsmnLuYfz+Rs+ECYNqOY3aW xReOVG4ryw4T52bIdv0L/swfEGb6EWm3Sr/hohFVdaaeZz4wV5gDh+aZWc1jNi61GuDN 3Vs0mbdhL9fTUL+k+WoN3QLH4NjMmaUJrZZShBGm8lw/tzy8x3dnqmNk219K+lG3wRJc WMXg== X-Gm-Message-State: AMCzsaXGhLxK3RCy25Fv8uOf6FknDM7158aIgpRoRDmOtFM8DIAGvtgq LbsfkESVS/0VB0JQRBhzw0/oE4+9Et+RLRLgHcb1plXZ X-Google-Smtp-Source: ABhQp+SrOaliNtgxBvm4w5bNhwRO7PUzdOVDjA4Ufdy+2wedIddBRvp3sdnwod52HUJVGLzExrE63Qb/jxZZLB2W6Ug= X-Received: by 10.176.81.253 with SMTP id h58mr3827202uaa.201.1509017066391; Thu, 26 Oct 2017 04:24:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.32.69 with HTTP; Thu, 26 Oct 2017 04:24:26 -0700 (PDT) In-Reply-To: <26860663-b0c3-981a-5b91-34645786968b@gmx.net> References: <1a9f165d-6994-a92f-3e93-faabf9c690ba@gmx.net> <26860663-b0c3-981a-5b91-34645786968b@gmx.net> From: Joakim Brorsson Date: Thu, 26 Oct 2017 13:24:26 +0200 Message-ID: To: Hannes Tschofenig Cc: Carsten Bormann , "core@ietf.org WG (core@ietf.org)" Content-Type: multipart/alternative; boundary="94eb2c19243633dea3055c716a46" Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 11:24:29 -0000 --94eb2c19243633dea3055c716a46 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Hannes. The situation is in my opinion much more nuanced. Trust is not all or nothing. We might want to trust a proxy with availability, in order to obtain asynchronicity. But we can not trust the proxy with actual plaintext data, since the data owner and the infrastructure owner might not be the same person. Without separating the concepts of confidentiality, integrity and availability, we become very limited in how we can design secure systems. Regards Joakim 2017-10-26 12:57 GMT+02:00 Hannes Tschofenig : > Hi Carsten, > > I fail to understand the reasoning. > > You want end-to-end security but then you put a proxy in the middle. > Architecturally not a great idea since you don't have to do that. > > Now the proxy is there. You seem to trust the proxy to process and relay > your messages. Probably the proxy does much in order to justify the > existence. > > But then the proxy you previously trusted becomes evil and mounts > attacks against your communication. > > Then, you add this extension. > > However, you nicely trust the proxy not to do all sorts of other things. > For example, it could just drop your messages. It could also delay your > messages (which would have pretty nasty effects in an industrial IoT > environment where timing matters). Then, you also expose lots of > meta-data to this proxy as well (leading to privacy violations). That's > seems just fine (and maybe be covered as part of a later draft). > > For this reason I believe the story is constructed. > > If you believe the feature is essential for OSCOAP, as it sounds from > your second response, then why is this not part of OSCOAP (which is also > still work in progress)? > > Ciao > Hannes > > On 10/25/2017 08:53 AM, Carsten Bormann wrote: > > Hi Hannes, > > > > On Oct 4, 2017, at 16:50, Hannes Tschofenig > wrote: > >> > >> Two comments: > >> > >> IMHO the presented problems are not worthwhile to solve. > > > > I=E2=80=99m not sure I understand. The problem pointed out is a securi= ty > problem in certain applications. > > Are you saying we shouldn=E2=80=99t invest time in these applications? > > Or are you saying this should instead be solved within the application > (which is perfectly possible, but not something we can expect developers = to > always get right)? > > > >> Additionally, I > >> would prefer if the CORE working group finishes already chartered item= s > >> rather than always adding new stuff. > > > > I think we can agree on this, but addressing a security problem does > have a special importance. > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --94eb2c19243633dea3055c716a46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hell= o Hannes.
The situ= ation is in my opinion much more nuanced. Trust is not all or nothing.=C2= =A0

We might want to trust a proxy with availabili= ty, in order to obtain asynchronicity. But we can not trust the proxy with = actual plaintext data, since the data owner and the infrastructure owner mi= ght not be the same person.

Without separating the= concepts of confidentiality, integrity and availability, we become very li= mited in how we can design secure systems.

Regards=
Joakim

2017-10-26 12:57 GMT+02:00 Hannes Tschofenig <ha= nnes.tschofenig@gmx.net>:
H= i Carsten,

I fail to understand the reasoning.

You want end-to-end security but then you put a proxy in the middle.
Architecturally not a great idea since you don't have to do that.

Now the proxy is there. You seem to trust the proxy to process and relay your messages. Probably the proxy does much in order to justify the
existence.

But then the proxy you previously trusted becomes evil and mounts
attacks against your communication.

Then, you add this extension.

However, you nicely trust the proxy not to do all sorts of other things. For example, it could just drop your messages. It could also delay your
messages (which would have pretty nasty effects in an industrial IoT
environment where timing matters). Then, you also expose lots of
meta-data to this proxy as well (leading to privacy violations). That's=
seems just fine (and maybe be covered as part of a later draft).

For this reason I believe the story is constructed.

If you believe the feature is essential for OSCOAP, as it sounds from
your second response, then why is this not part of OSCOAP (which is also still work in progress)?

Ciao
Hannes

On 10/25/2017 08:53 AM, Carsten Bormann wrote:
> Hi Hannes,
>
> On Oct 4, 2017, at 16:50, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>
>> Two comments:
>>
>> IMHO the presented problems are not worthwhile to solve.
>
> I=E2=80=99m not sure I understand.=C2=A0 The problem pointed out is a = security problem in certain applications.
> Are you saying we shouldn=E2=80=99t invest time in these applications?=
> Or are you saying this should instead be solved within the application= (which is perfectly possible, but not something we can expect developers t= o always get right)?
>
>> Additionally, I
>> would prefer if the CORE working group finishes already chartered = items
>> rather than always adding new stuff.
>
> I think we can agree on this, but addressing a security problem does h= ave a special importance.
>
> Gr=C3=BC=C3=9Fe, Carsten
>

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

--94eb2c19243633dea3055c716a46-- From nobody Thu Oct 26 04:42:09 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066ED13AF23 for ; Thu, 26 Oct 2017 04:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 5bTCXcrNmQLo for ; Thu, 26 Oct 2017 04:42:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2B213F563 for ; Thu, 26 Oct 2017 04:42:05 -0700 (PDT) Received: from [192.168.91.204] ([80.92.116.6]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M6vSj-1dD8Ba1mo1-00wpSH; Thu, 26 Oct 2017 13:41:55 +0200 To: Joakim Brorsson Cc: Carsten Bormann , "core@ietf.org WG (core@ietf.org)" References: <1a9f165d-6994-a92f-3e93-faabf9c690ba@gmx.net> <26860663-b0c3-981a-5b91-34645786968b@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Thu, 26 Oct 2017 13:41:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:a+5sj9TFlDu+T/ApQDMB9EET+LkicHmmlCWKcGfChlJDwOPuzxg /6m5udujqCWJ+mfwAwo8Wu3ocBRvfUfiTVvPGXL/AeZlc9QLh6cZ5XjvARo1LrITCF5dN6c LrJ82N4V0FkgcKPzwb9q0G+yO8pcKaRl4Bslw1TOLzqDfy5fDWpInILN3ofiJ4XjW6B9tCH p1qVb2CygMmk5ahUbjGxw== X-UI-Out-Filterresults: notjunk:1;V01:K0:wsi4XVZ7egs=:YmwptqBmrOtprlLifkuKmh Y9HB0UL2tGOpLqIximrZjJcE/dIgEPHNZTGdQ/iDnVqqhpMRsaed+5Xd53A0wbnQaL+sUq/xX adFebPh3ztdxTyJSBESOvfLxnfX+UtagegSAWVQXw9ioLL5jfxFAgfkQngJutrGsaZcVveBCG ps8MaalU2vUMvf+njKCSeoGiSnsgBSXBERCelM/6aWTVbGfOvtBq7eHbHX6ASbUOtEOHFBoeP 1uyzjV8zRtLUfOudTutRidyddZIe3fC/JfX7C8H6UKb1q9hDrLE1oEqRMWDP6sSO/T9hHUWMV sOf2efY4oU8AXRmVnbOVdtOHq0pH2HuoWJjVxEM1G5aUgwo2FKm6IDC8pticffHbJ2vRTJuJs AXZ0lRiWDXcvGbx3h2lkIL3vpRlouyulW8JnLsBpH3awIkSQZ8aYanNThlFN8jwAxhE1QPUGW orQazVaWaUl//aOAPgZdUosdePaHWDip4y0dhT5Qz5OCaccpw9O28ZkFAtIH7BNw6gQl/2dRE Uv361cKEKTCJHqyUktEaQ9oa0KmhlJ0k8a9y4FHOoA1OyPd5jt54wr/qvBapaFThzNSj99vMF f+Nu/mPpjM6j7rrncbA8Oo5fboxb6ExEKDCWR0oAzWyy527yoyCqCiHZw/vabMWKAXU8Pl83t FK9tA7riDwOKpkXDTY/1ENZladQp25nAoLiB69lLVMDzITkOSUDK/Vbjk+cm+ctMmRm/bktpe rA+xKtDPO9B9xBeI5bJVVMZy42aAOpTZ3HXXY8e3YotDGKE9DuhpyYyGwYQnDy0ERx82TcQaL bi2unoWSIYGkSuK945fscrepN6haBICLWRb5wE76IJRFPHLjEM= Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 11:42:08 -0000 Hi Joakim, I fully understand that trust is not black and white. When I read a document I have to figure out whether this is something we at ARM also encounter in our deployments. I am also happy to learn when other companies encounter deployment challenges and share them (including solutions) with the rest of the community. Here, it appears, that the requirements just fall out of the blue sky. If you, Carsten, Jim, and Malisa have IoT deployments that need this then you should say "yes, we need this for our deployment". This is the purpose of the call for adoption. Ciao Hannes On 10/26/2017 01:24 PM, Joakim Brorsson wrote: > Hello Hannes. > > The situation is in my opinion much more nuanced. Trust is not all or > nothing.  > > We might want to trust a proxy with availability, in order to obtain > asynchronicity. But we can not trust the proxy with actual plaintext > data, since the data owner and the infrastructure owner might not be the > same person. > > Without separating the concepts of confidentiality, integrity and > availability, we become very limited in how we can design secure systems. > > Regards > Joakim > > 2017-10-26 12:57 GMT+02:00 Hannes Tschofenig >: > > Hi Carsten, > > I fail to understand the reasoning. > > You want end-to-end security but then you put a proxy in the middle. > Architecturally not a great idea since you don't have to do that. > > Now the proxy is there. You seem to trust the proxy to process and relay > your messages. Probably the proxy does much in order to justify the > existence. > > But then the proxy you previously trusted becomes evil and mounts > attacks against your communication. > > Then, you add this extension. > > However, you nicely trust the proxy not to do all sorts of other things. > For example, it could just drop your messages. It could also delay your > messages (which would have pretty nasty effects in an industrial IoT > environment where timing matters). Then, you also expose lots of > meta-data to this proxy as well (leading to privacy violations). That's > seems just fine (and maybe be covered as part of a later draft). > > For this reason I believe the story is constructed. > > If you believe the feature is essential for OSCOAP, as it sounds from > your second response, then why is this not part of OSCOAP (which is also > still work in progress)? > > Ciao > Hannes > > On 10/25/2017 08:53 AM, Carsten Bormann wrote: > > Hi Hannes, > > > > On Oct 4, 2017, at 16:50, Hannes Tschofenig > > wrote: > >> > >> Two comments: > >> > >> IMHO the presented problems are not worthwhile to solve. > > > > I’m not sure I understand.  The problem pointed out is a security > problem in certain applications. > > Are you saying we shouldn’t invest time in these applications? > > Or are you saying this should instead be solved within the > application (which is perfectly possible, but not something we can > expect developers to always get right)? > > > >> Additionally, I > >> would prefer if the CORE working group finishes already chartered > items > >> rather than always adding new stuff. > > > > I think we can agree on this, but addressing a security problem > does have a special importance. > > > > Grüße, Carsten > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > From nobody Thu Oct 26 05:43:33 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEB513AD2D for ; Thu, 26 Oct 2017 05:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 dpnFJs8RFHxy for ; Thu, 26 Oct 2017 05:43:30 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 98C8513A292 for ; Thu, 26 Oct 2017 05:43:29 -0700 (PDT) X-AuditID: c1b4fb2d-fc3a89c00000268d-5b-59f1d86f942e Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 38.D3.09869.F68D1F95; Thu, 26 Oct 2017 14:43:27 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.134]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Thu, 26 Oct 2017 14:43:25 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig CC: "core@ietf.org WG (core@ietf.org)" , Joakim Brorsson Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHIENhbGwgZm9yIEFkb3B0aW9uIG9uIGRyYWZ0LWFt?= =?utf-8?Q?suess-core-repeat-request-tag-00?= Thread-Index: AQHTPSAxaWuW9otw3kSS8ugFnBWbrqL0IB6AgAHWjgCAAAeCAIAABN6AgAAy/AA= Date: Thu, 26 Oct 2017 12:43:25 +0000 Message-ID: References: <1a9f165d-6994-a92f-3e93-faabf9c690ba@gmx.net> <26860663-b0c3-981a-5b91-34645786968b@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: <273173FF9153C4419CE90BAA69298841@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2J7uG7+jY+RBjt61S32vV3PbLF05z1W i1u/e5gcmD0Wb9rP5tF25C+Tx5IlP5kCmKO4bFJSczLLUov07RK4Mq6c2cZUMM+84sx35wbG F6ZdjJwcEgImEi2nutlBbCGBI4wSZ5dLdjFyAdlLGCVO7DrHBJJgE3CReNDwCMwWETCUuD5z OiuIzSwQLfFi23kmkAZhgRZGiUeve1hAHBGBVkaJpiXXWCE6/CQ+L1oH1s0ioCoxs2U7C4jN K2AhMXfnGlaIdaeYJJbebAEr4hSwlji7cw8biM0oICbx/dQaJoh14hK3nsxngrhbQGLJnvPM ELaoxMvH/8CWiQroSeztaWeDiCtKXJ2+HKieA6hXU2L9Ln2IMdYSS3/eYYewFSWmdD9kh7hH UOLkzCcsExjFZyHZNguhexaS7llIumch6V7AyLqKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQT IzAGD275rbuDcfVrx0OMAhyMSjy8tRc/RgqxJpYVV+YeYpTgYFYS4bW6BhTiTUmsrEotyo8v Ks1JLT7EKM3BoiTO67DvQoSQQHpiSWp2ampBahFMlomDU6qBMerkxQdx77zXSGeUPFayVF4X 47T+Wbpc6cKvVwuZzD/GZF5KPMtreCC2sEnBad91Xy5NrdvpS1uY7Lyrd0RKrKt+ukvxyOtG Ay+2ORM/hS15nxTetjuj0N5ZmF8zb5dXzgIei3MGPFufr3mwtCvzQsjL4KnGMr6r9vtc073q 0tr3/aKX1mYRJZbijERDLeai4kQAaRJ+Dr0CAAA= Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 12:43:31 -0000 SGkgSGFubmVzLCANCg0KVGhlcmUgYXBwZWFycyB0byBiZSBwcm9mb3VuZCBjb25mdXNpb24gYWJv dXQgd2hhdCB0aGlzIGRyYWZ0IGlzIGFib3V0LCBzbw0KaXQgaXMgZXZlbiBoYXJkIHRvIG1hcCB0 aGUgc3RhdGVtZW50cyBtYWRlIGluIHlvdXIgbWFpbCB0byB0aGUgZHJhZnQuDQoNClRoZSBwcm9i bGVtIHN0YXRlbWVudHMgbGVhZGluZyB1cCB0byB0aGlzIGRyYWZ0IGFyZSBhZGRyZXNzaW5nIGlz c3VlcyB3aXRoDQpDb0FQIGV2ZW4gd2hlbiBhIHNlY3VyaXR5IHByb3RvY29sIHN1Y2ggYXMgRFRM UyBpcyB1c2VkLiBUaGUgYXR0YWNrcyBjYW4NCmJlIGNhcnJpZWQgb3V0IGJ5IG9uLXBhdGggYXR0 YWNrZXJzIGFuZCB0aHVzIGRvZXMgbm90IHJlcXVpcmUgYSBwcm94eS4NCg0KVGhlIGRyYWZ0IGNv bnRhaW5zIHNlY3VyaXR5IHVwZGF0ZXMuIFNlY3VyaXR5IHVwZGF0ZXMgaW4gZ2VuZXJhbCBhcmUg b2YNCnRoZSBuYXR1cmUgdGhhdCB5b3UgbWFrZSB0aGVtIHdoZW4geW91IHJlYWxpc2UgdGhhdCB0 aGVyZSBpcyBhIHBvdGVudGlhbA0KaXNzdWUsIGV2ZW4gaWYgeW91IGhhdmUgbm90IGV4cGVyaWVu Y2VkIGFuIGF0dGFjay4gSWYgQVJNIGlzIG9ubHkgbWFraW5nDQpzZWN1cml0eSB1cGRhdGVzIGFm dGVyIGFuIGF0dGFjayBpcyBhIGZhY3QgSSB0aGluayBtYW55IHBlb3BsZSB3b3VsZCBub3QNCmRh cmUgdG8gdXNlIEFSTSBiYXNlZCBkZXZpY2VzLg0KDQpQbGVhc2UgYmUgc3BlY2lmaWMgd2l0aCB5 b3VyIGNvbmNlcm5zIGJ5IHJlZmVyZW5jaW5nIHRoZSBhdHRhY2tzIHdoaWNoIGFyZQ0KcHJvdGVj dGVkIGFnYWluc3QgcmF0aGVyIHRoYW4gbWFrZSBzd2VlcGluZyBhcmd1bWVudHMuDQoNCg0KR8O2 cmFuDQoNCg0KDQoNCg0KT24gMjAxNy0xMC0yNiAxMzo0MSwgImNvcmUgb24gYmVoYWxmIG9mIEhh bm5lcyBUc2Nob2ZlbmlnIg0KPGNvcmUtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaGFu bmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4gd3JvdGU6DQoNCj5IaSBKb2FraW0sDQo+DQo+SSBmdWxs eSB1bmRlcnN0YW5kIHRoYXQgdHJ1c3QgaXMgbm90IGJsYWNrIGFuZCB3aGl0ZS4NCj4NCj5XaGVu IEkgcmVhZCBhIGRvY3VtZW50IEkgaGF2ZSB0byBmaWd1cmUgb3V0IHdoZXRoZXIgdGhpcyBpcyBz b21ldGhpbmcgd2UNCj5hdCBBUk0gYWxzbyBlbmNvdW50ZXIgaW4gb3VyIGRlcGxveW1lbnRzLiBJ IGFtIGFsc28gaGFwcHkgdG8gbGVhcm4gd2hlbg0KPm90aGVyIGNvbXBhbmllcyBlbmNvdW50ZXIg ZGVwbG95bWVudCBjaGFsbGVuZ2VzIGFuZCBzaGFyZSB0aGVtDQo+KGluY2x1ZGluZyBzb2x1dGlv bnMpIHdpdGggdGhlIHJlc3Qgb2YgdGhlIGNvbW11bml0eS4NCj4NCj5IZXJlLCBpdCBhcHBlYXJz LCB0aGF0IHRoZSByZXF1aXJlbWVudHMganVzdCBmYWxsIG91dCBvZiB0aGUgYmx1ZSBza3kuDQo+ DQo+SWYgeW91LCBDYXJzdGVuLCBKaW0sIGFuZCBNYWxpc2EgaGF2ZSBJb1QgZGVwbG95bWVudHMg dGhhdCBuZWVkIHRoaXMNCj50aGVuIHlvdSBzaG91bGQgc2F5ICJ5ZXMsIHdlIG5lZWQgdGhpcyBm b3Igb3VyIGRlcGxveW1lbnQiLiBUaGlzIGlzIHRoZQ0KPnB1cnBvc2Ugb2YgdGhlIGNhbGwgZm9y IGFkb3B0aW9uLg0KPg0KPkNpYW8NCj5IYW5uZXMNCj4NCj5PbiAxMC8yNi8yMDE3IDAxOjI0IFBN LCBKb2FraW0gQnJvcnNzb24gd3JvdGU6DQo+PiBIZWxsbyBIYW5uZXMuDQo+PiANCj4+IFRoZSBz aXR1YXRpb24gaXMgaW4gbXkgb3BpbmlvbiBtdWNoIG1vcmUgbnVhbmNlZC4gVHJ1c3QgaXMgbm90 IGFsbCBvcg0KPj4gbm90aGluZy4gDQo+PiANCj4+IFdlIG1pZ2h0IHdhbnQgdG8gdHJ1c3QgYSBw cm94eSB3aXRoIGF2YWlsYWJpbGl0eSwgaW4gb3JkZXIgdG8gb2J0YWluDQo+PiBhc3luY2hyb25p Y2l0eS4gQnV0IHdlIGNhbiBub3QgdHJ1c3QgdGhlIHByb3h5IHdpdGggYWN0dWFsIHBsYWludGV4 dA0KPj4gZGF0YSwgc2luY2UgdGhlIGRhdGEgb3duZXIgYW5kIHRoZSBpbmZyYXN0cnVjdHVyZSBv d25lciBtaWdodCBub3QgYmUgdGhlDQo+PiBzYW1lIHBlcnNvbi4NCj4+IA0KPj4gV2l0aG91dCBz ZXBhcmF0aW5nIHRoZSBjb25jZXB0cyBvZiBjb25maWRlbnRpYWxpdHksIGludGVncml0eSBhbmQN Cj4+IGF2YWlsYWJpbGl0eSwgd2UgYmVjb21lIHZlcnkgbGltaXRlZCBpbiBob3cgd2UgY2FuIGRl c2lnbiBzZWN1cmUNCj4+c3lzdGVtcy4NCj4+IA0KPj4gUmVnYXJkcw0KPj4gSm9ha2ltDQo+PiAN Cj4+IDIwMTctMTAtMjYgMTI6NTcgR01UKzAyOjAwIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMu dHNjaG9mZW5pZ0BnbXgubmV0DQo+PiA8bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+ PjoNCj4+IA0KPj4gICAgIEhpIENhcnN0ZW4sDQo+PiANCj4+ICAgICBJIGZhaWwgdG8gdW5kZXJz dGFuZCB0aGUgcmVhc29uaW5nLg0KPj4gDQo+PiAgICAgWW91IHdhbnQgZW5kLXRvLWVuZCBzZWN1 cml0eSBidXQgdGhlbiB5b3UgcHV0IGEgcHJveHkgaW4gdGhlIG1pZGRsZS4NCj4+ICAgICBBcmNo aXRlY3R1cmFsbHkgbm90IGEgZ3JlYXQgaWRlYSBzaW5jZSB5b3UgZG9uJ3QgaGF2ZSB0byBkbyB0 aGF0Lg0KPj4gDQo+PiAgICAgTm93IHRoZSBwcm94eSBpcyB0aGVyZS4gWW91IHNlZW0gdG8gdHJ1 c3QgdGhlIHByb3h5IHRvIHByb2Nlc3MgYW5kDQo+PnJlbGF5DQo+PiAgICAgeW91ciBtZXNzYWdl cy4gUHJvYmFibHkgdGhlIHByb3h5IGRvZXMgbXVjaCBpbiBvcmRlciB0byBqdXN0aWZ5IHRoZQ0K Pj4gICAgIGV4aXN0ZW5jZS4NCj4+IA0KPj4gICAgIEJ1dCB0aGVuIHRoZSBwcm94eSB5b3UgcHJl dmlvdXNseSB0cnVzdGVkIGJlY29tZXMgZXZpbCBhbmQgbW91bnRzDQo+PiAgICAgYXR0YWNrcyBh Z2FpbnN0IHlvdXIgY29tbXVuaWNhdGlvbi4NCj4+IA0KPj4gICAgIFRoZW4sIHlvdSBhZGQgdGhp cyBleHRlbnNpb24uDQo+PiANCj4+ICAgICBIb3dldmVyLCB5b3UgbmljZWx5IHRydXN0IHRoZSBw cm94eSBub3QgdG8gZG8gYWxsIHNvcnRzIG9mIG90aGVyDQo+PnRoaW5ncy4NCj4+ICAgICBGb3Ig ZXhhbXBsZSwgaXQgY291bGQganVzdCBkcm9wIHlvdXIgbWVzc2FnZXMuIEl0IGNvdWxkIGFsc28g ZGVsYXkNCj4+eW91cg0KPj4gICAgIG1lc3NhZ2VzICh3aGljaCB3b3VsZCBoYXZlIHByZXR0eSBu YXN0eSBlZmZlY3RzIGluIGFuIGluZHVzdHJpYWwgSW9UDQo+PiAgICAgZW52aXJvbm1lbnQgd2hl cmUgdGltaW5nIG1hdHRlcnMpLiBUaGVuLCB5b3UgYWxzbyBleHBvc2UgbG90cyBvZg0KPj4gICAg IG1ldGEtZGF0YSB0byB0aGlzIHByb3h5IGFzIHdlbGwgKGxlYWRpbmcgdG8gcHJpdmFjeSB2aW9s YXRpb25zKS4NCj4+VGhhdCdzDQo+PiAgICAgc2VlbXMganVzdCBmaW5lIChhbmQgbWF5YmUgYmUg Y292ZXJlZCBhcyBwYXJ0IG9mIGEgbGF0ZXIgZHJhZnQpLg0KPj4gDQo+PiAgICAgRm9yIHRoaXMg cmVhc29uIEkgYmVsaWV2ZSB0aGUgc3RvcnkgaXMgY29uc3RydWN0ZWQuDQo+PiANCj4+ICAgICBJ ZiB5b3UgYmVsaWV2ZSB0aGUgZmVhdHVyZSBpcyBlc3NlbnRpYWwgZm9yIE9TQ09BUCwgYXMgaXQg c291bmRzDQo+PmZyb20NCj4+ICAgICB5b3VyIHNlY29uZCByZXNwb25zZSwgdGhlbiB3aHkgaXMg dGhpcyBub3QgcGFydCBvZiBPU0NPQVAgKHdoaWNoIGlzDQo+PmFsc28NCj4+ICAgICBzdGlsbCB3 b3JrIGluIHByb2dyZXNzKT8NCj4+IA0KPj4gICAgIENpYW8NCj4+ICAgICBIYW5uZXMNCj4+IA0K Pj4gICAgIE9uIDEwLzI1LzIwMTcgMDg6NTMgQU0sIENhcnN0ZW4gQm9ybWFubiB3cm90ZToNCj4+ ICAgICA+IEhpIEhhbm5lcywNCj4+ICAgICA+DQo+PiAgICAgPiBPbiBPY3QgNCwgMjAxNywgYXQg MTY6NTAsIEhhbm5lcyBUc2Nob2ZlbmlnDQo+PiAgICAgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5u ZXQgPG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj4NCj4+d3JvdGU6DQo+PiAgICAg Pj4NCj4+ICAgICA+PiBUd28gY29tbWVudHM6DQo+PiAgICAgPj4NCj4+ICAgICA+PiBJTUhPIHRo ZSBwcmVzZW50ZWQgcHJvYmxlbXMgYXJlIG5vdCB3b3J0aHdoaWxlIHRvIHNvbHZlLg0KPj4gICAg ID4NCj4+ICAgICA+IEnigJltIG5vdCBzdXJlIEkgdW5kZXJzdGFuZC4gIFRoZSBwcm9ibGVtIHBv aW50ZWQgb3V0IGlzIGEgc2VjdXJpdHkNCj4+ICAgICBwcm9ibGVtIGluIGNlcnRhaW4gYXBwbGlj YXRpb25zLg0KPj4gICAgID4gQXJlIHlvdSBzYXlpbmcgd2Ugc2hvdWxkbuKAmXQgaW52ZXN0IHRp bWUgaW4gdGhlc2UgYXBwbGljYXRpb25zPw0KPj4gICAgID4gT3IgYXJlIHlvdSBzYXlpbmcgdGhp cyBzaG91bGQgaW5zdGVhZCBiZSBzb2x2ZWQgd2l0aGluIHRoZQ0KPj4gICAgIGFwcGxpY2F0aW9u ICh3aGljaCBpcyBwZXJmZWN0bHkgcG9zc2libGUsIGJ1dCBub3Qgc29tZXRoaW5nIHdlIGNhbg0K Pj4gICAgIGV4cGVjdCBkZXZlbG9wZXJzIHRvIGFsd2F5cyBnZXQgcmlnaHQpPw0KPj4gICAgID4N Cj4+ICAgICA+PiBBZGRpdGlvbmFsbHksIEkNCj4+ICAgICA+PiB3b3VsZCBwcmVmZXIgaWYgdGhl IENPUkUgd29ya2luZyBncm91cCBmaW5pc2hlcyBhbHJlYWR5IGNoYXJ0ZXJlZA0KPj4gICAgIGl0 ZW1zDQo+PiAgICAgPj4gcmF0aGVyIHRoYW4gYWx3YXlzIGFkZGluZyBuZXcgc3R1ZmYuDQo+PiAg ICAgPg0KPj4gICAgID4gSSB0aGluayB3ZSBjYW4gYWdyZWUgb24gdGhpcywgYnV0IGFkZHJlc3Np bmcgYSBzZWN1cml0eSBwcm9ibGVtDQo+PiAgICAgZG9lcyBoYXZlIGEgc3BlY2lhbCBpbXBvcnRh bmNlLg0KPj4gICAgID4NCj4+ICAgICA+IEdyw7zDn2UsIENhcnN0ZW4NCj4+ICAgICA+DQo+PiAN Cj4+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gICAgIGNvcmUgbWFpbGluZyBsaXN0DQo+PiAgICAgY29yZUBpZXRmLm9yZyA8bWFpbHRvOmNv cmVAaWV0Zi5vcmc+DQo+PiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3JlDQo+PiAgICAgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29y ZT4NCj4+IA0KPj4gDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj5jb3JlIG1haWxpbmcgbGlzdA0KPmNvcmVAaWV0Zi5vcmcNCj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0K From nobody Thu Oct 26 05:58:22 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAA013B1A9 for ; Thu, 26 Oct 2017 05:58:20 -0700 (PDT) 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] 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 xwJVaufT9ncI for ; Thu, 26 Oct 2017 05:58:17 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 635B113F581 for ; Thu, 26 Oct 2017 05:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9QCwDCQ012116; Thu, 26 Oct 2017 14:58:13 +0200 (CEST) Received: from client-0210.vpn.uni-bremen.de (client-0210.vpn.uni-bremen.de [134.102.107.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yN6W90XvDzDWZN; Thu, 26 Oct 2017 14:58:13 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <26860663-b0c3-981a-5b91-34645786968b@gmx.net> Date: Thu, 26 Oct 2017 14:58:12 +0200 Cc: =?utf-8?Q?Jaime_Jim=C3=A9nez?= , "core@ietf.org WG (core@ietf.org)" X-Mao-Original-Outgoing-Id: 530715491.824179-245612c09ac5ce1083cd20654bcbbd41 Content-Transfer-Encoding: quoted-printable Message-Id: <0B5A47AC-B260-4147-A700-5DC6A886A577@tzi.org> References: <1a9f165d-6994-a92f-3e93-faabf9c690ba@gmx.net> <26860663-b0c3-981a-5b91-34645786968b@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 12:58:20 -0000 On Oct 26, 2017, at 12:57, Hannes Tschofenig = wrote: >=20 > You want end-to-end security but then you put a proxy in the middle. Hi Hannes, the freshness vulnerability addressed here indeed occurs with proxies. But it also occurs with anything else that can hold back and replay = traffic, including routers and even possibly an unrelated wireless node = that manages to jam the forwarding to the receiving node while making a = copy of the original transmission. Decryption capability is not = required for this to work. This is a bit like some of the well-known = key fob vulnerabilities. It is possible to address this at the application level (Web = applications typically do), and for a while I thought that would be = going to be all we need. As far as I understand, the argument is that defining a standard CoAP = option for this reduces the variability and makes it more likely that = the mechanism actually will work right, more independent of the security = acuity of the application developer. That is typically an argument to = which the IETF is quite accessible. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Oct 26 06:52:31 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1A5138BCD for ; Thu, 26 Oct 2017 06:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lightingaad.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYl3QrHfYMjC for ; Thu, 26 Oct 2017 06:52:26 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10064.outbound.protection.outlook.com [40.107.1.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E57C13F4A9 for ; Thu, 26 Oct 2017 06:52:26 -0700 (PDT) Received: from HE1P121CA0008.EURP121.PROD.OUTLOOK.COM (2603:10a6:23:2b::18) by HE1P121MB0010.EURP121.PROD.OUTLOOK.COM (2a01:111:e400:e2b0::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 26 Oct 2017 13:52:23 +0000 Received: from HE1EUR02FT053.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::209) by HE1P121CA0008.outlook.office365.com (2603:10a6:23:2b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4 via Frontend Transport; Thu, 26 Oct 2017 13:52:23 +0000 Authentication-Results: spf=neutral (sender IP is 13.81.48.91) smtp.mailfrom=philips.com; tzi.org; dkim=fail (signature did not verify) header.d=lightingaad.onmicrosoft.com;tzi.org; dmarc=fail action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 13.81.48.91 is neither permitted nor denied by domain of philips.com) Received: from LIGHT-EDGE-2.lighting.com (13.81.48.91) by HE1EUR02FT053.mail.protection.outlook.com (10.152.11.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.156.4 via Frontend Transport; Thu, 26 Oct 2017 13:52:23 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (213.199.154.180) by autodiscover.lighting.com (10.0.0.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.669.32; Thu, 26 Oct 2017 15:52:01 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightingaad.onmicrosoft.com; s=selector1-lighting-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pStj3/yIhCbrYc9Ju7RVVXrg2DyXonBsA9KVsPIhaKI=; b=kY+43VcBE5Rvs/jbKIMmteLy+0GXfDHnHGjuLlWtYdlMgEM7zdHRGSzPvKXSC2O8f9n0Y7f7hU0yKX0F+o1xmpZjrhceEUIyjDcau7trpGMeXtv9DAECY55XYuSncy8L4b+PDjAE8rnnS3RbaLMOANwSVH9hD1oUiyi/BeYVNI4= Received: from DB6P121MB0038.EURP121.PROD.OUTLOOK.COM (129.75.191.85) by DB6P121MB0038.EURP121.PROD.OUTLOOK.COM (129.75.191.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Thu, 26 Oct 2017 13:51:59 +0000 Received: from DB6P121MB0038.EURP121.PROD.OUTLOOK.COM ([129.75.191.85]) by DB6P121MB0038.EURP121.PROD.OUTLOOK.COM ([129.75.191.85]) with mapi id 15.20.0156.007; Thu, 26 Oct 2017 13:51:59 +0000 From: Esko Dijk To: Carsten Bormann , Stuart Longland CC: "core@ietf.org WG (core@ietf.org)" Thread-Topic: [core] Simple registration and URI length restrictions Thread-Index: AQHTTWXYRvrbsvtunUm746jMyX4i4qL0OnwwgAGA+wCAAAEtAIAAaa2A Date: Thu, 26 Oct 2017 13:51:59 +0000 Message-ID: References: <48729a59-f5e8-e20a-f1cb-7a0bb64b1d8d@vrt.com.au> <72045bd2-f3e9-015d-4ee5-37cdc0b40700@vrt.com.au> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@lighting.com; x-originating-ip: [80.255.245.238] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1; DB6P121MB0038; 6:yOgIeQPqHdnS8oYhNaP6KMOlsOaqVo1ZU0NnGsXUwC7sBz/Ke4mwlL/gh4Fnn+DF7vqSxEQl7RhS6nXvmy3ORaQszTj8SSGidNwU0fo7VzqSbOm4OpLyiCBmUZLozrV0yriA858x2wtfDO4NqEHbBvFt9/PD+NDj/2egX5bc1mlnXrD+OZ4pATATUysvjVCygX84u/hM+wG02fw08kUhLXeQ4tx6VYyC5R9qAniZ4spOHxQ4RZL0ST21o0gNDXWMc7yIwjs8U7TLUEuEVAs0PmtmgR9zsDuZS6C1QSGonCRVea9YeBW6L7y8sbzmZSI/l/0kUMGugziLo8tgMemuwA==; 5:XqZSt79c/bSWWUyRNci8hJRW2RH1ZVPR3uoKm6GunP+sg/nNXhaoq9HO7VVvegIyVuMx4Wg/PUBoSkaGCCnk6vEvm95c9WdUU4XspboDQPmciJvPTVN7Wg9qfPiSmpVHLh7VQxyfBAyfk9wJP7UP+A==; 24:X5G0We4rlnsJxkvptFR93P8fztZBx1fy8MUh7NCdLeDSbHMru+3RpckqfgvC2q1G9ZEU3OsyY7Z0f7eEr3ggxXrlPEKxu63BMD1Mp2D0ZpQ=; 7:ZsJvZyJt2zZJ4cKB0XlGRfb4lzArhTVAx3KFGuqgbWnFzEc61aICJ3xZtMws+CP4oXnI/j0cFVK5dcn5J503yK2lufV6jCBQufI8lJpk9xQ2ZuVbVgWO9RMdYA89i8jxtMLmg54plLNK6EabaOmYa+rjbUbj6lGyDVGGor+ypByAlq0Yr3QdEo9uaizAewXW/x30II7C5rO1VB4+zVBvw2af9LwhAsk31Zjq43aOS5A= x-ms-exchange-antispam-srfa-diagnostics: SSOS; X-MS-Office365-Filtering-Correlation-Id: 7f8f5d7f-b89a-4225-e20f-08d51c78c8e7 X-Microsoft-Antispam-Untrusted: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:DB6P121MB0038; X-MS-TrafficTypeDiagnostic: DB6P121MB0038:|HE1P121MB0010: x-exchange-antispam-report-test: UriScan:(46150409022019)(260087099026482); UriScan:(46150409022019)(260087099026482); X-Microsoft-Antispam-PRVS: x-exchange-antispam-report-cfa-test: =?utf-8?B?QkNMOjA7UENMOjA7UlVMRUlEOigxMDAwMDA3MDAxMDEpKDEwMDEwNTAwMDA5?= =?utf-8?B?NSkoMTAwMDAwNzAxMTAxKSgxMDAxMDUzMDAwOTUpKDEwMDAwMDcwMjEwMSko?= =?utf-8?B?MTAwMTA1MTAwMDk1KSg2MDQwNDUwKSgyNDAxMDQ3KSg1MDA1MDA2KSg4MTIx?= =?utf-8?B?NTAxMDQ2KSgzMjMxMDIwKSgxMDIwMTUwMTA0NikoMzAwMjAwMSkoMTAwMDAw?= =?utf-8?B?NzAzMTAxKSgxMDAxMDU0MDAwOTUpKDkzMDA2MDk1KSg5MzAwMTA5NSkoNjA0?= =?utf-8?B?MTI0OCkoMjAxNjExMjM1NTUwMjUpKDIwMTYxMTIzNTYyMDI1KSgyMDE2MTEy?= =?utf-8?B?MzU1ODEwMCkoMjAxNjExMjM1NjAwMjUpKDIwMTcwMzEzMTQyMzA3NSkoMjAx?= =?utf-8?B?NzAyMjgxNTI4MDc1KSgyMDE3MDMwNjE0MjEwNzUpKDIwMTcwMzA2MTQwNjE1?= =?utf-8?B?MykoMjAxNjExMjM1NjQwMjUpKDYwNzIxNDgpKDIwMTcwODA3MTc0MjAxMSko?= =?utf-8?B?MTAwMDAwNzA0MTAxKSgxMDAxMDUyMDAwOTUpKDEwMDAwMDcwNTEwMSkoMTAw?= =?utf-8?B?MTA1NTAwMDk1KTtTUlZSOkRCNlAxMjFNQjAwMzg7QkNMOjA7UENMOjA7UlVM?= =?utf-8?B?RUlEOigxMDAwMDA4MDAxMDEpKDEwMDExMDAwMDA5NSkoMTAwMDAwODAxMTAx?= =?utf-8?B?KSgxMDAxMTAzMDAwOTUpKDEwMDAwMDgwMjEwMSkoMTAwMTEwMTAwMDk1KSgx?= =?utf-8?B?MDAwMDA4MDMxMDEpKDEwMDExMDQwMDA5NSkoMTAwMDAwODA0MTAxKSgxMDAx?= =?utf-8?B?MTAyMDAwOTUpKDEwMDAwMDgwNTEwMSkoMTAwMTEwNTAwMDk1KTtTUlZSOkRC?= =?utf-8?B?NlAxMjFNQjAwMzg7QkNMOjA7UENMOjA7UlVMRUlEOigxMDAwMDA3MDAxMDEp?= =?utf-8?B?KDEwMDEwNTAwMDA5NSkoMTAwMDAwNzAxMTAxKSgxMDAxMDUzMDAwOTUpKDEw?= =?utf-8?B?MDAwMDcwMjEwMSkoMTAwMTA1MTAwMDk1KSg2MDk1MTM1KSgyNDAxMDQ3KSg4?= =?utf-8?B?MTIxNTAxMDQ2KSg1MDA1MDA2KSgzMjMxMDIwKSgxMDAwMDA3MDMxMDEpKDEw?= =?utf-8?B?MDEwNTQwMDA5NSkoMzAwMjAwMSkoOTMwMDYwOTUpKDkzMDAzMDk1KSgxMDIw?= =?utf-8?B?MTUwMTA0NikoNjA1NTAyNikoNjA5NjAzNSkoMjAxNjExMjM1NjMwMjUpKDIw?= =?utf-8?B?MTYxMTIzNTY1MDI1KSgyMDE2MTEyMzU1NjAyNSkoMjAxNjExMjM1NjEwMjUp?= =?utf-8?B?KDIwMTYxMTIzNTU5MTAwKSgyMDE3MDMxMzE0MzAwNzUpKDIwMTcwMzEzMTQz?= =?utf-8?B?MzA3NSkoMjAxNzAzMTMxNDQ4MDc1KSgyMDE3MDMxNjEyNTkxNTApKDIwMTcw?= =?utf-8?B?MzE1MTA0MjE1MykoMjAxNzA4MDcxNzQyMDExKSgxMDAwMDA3MDQxMDEpKDEw?= =?utf-8?B?MDEwNTIwMDA5NSkoMTAwMDAwNzA1MTAxKSgxMDAxMDU1MDAwOTUpO1NSVlI6?= =?utf-8?B?SEUxUDEyMU1CMDAxMDtCQ0w6MDtQQ0w6MDtSVUxFSUQ6KDEwMDAwMDgwMDEw?= =?utf-8?B?MSkoMTAwMTEwMDAwMDk1KSgxMDAwMDA4MDExMDEpKDEwMDExMDMwMDA5NSko?= =?utf-8?B?MTAwMDAwODAyMTAxKSgxMDAxMTAxMDAwOTUpKDEwMDAwMDgwMzEwMSkoMTAw?= =?utf-8?B?MTEwNDAwMDk1KSg0MDAwMDYpKDEwMDAwMDgwNDEwMSkoMTAwMTEwMjAwMDk1?= =?utf-8?B?KSgxMDAwMDA4MDUxMDEpKDEwMDExMDUwMDA5NSk7U1JWUjpIRTFQMTIxTUIw?= =?utf-8?Q?010;?= x-forefront-prvs: 04724A515E X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(199003)(13464003)(85714005)(189002)(24454002)(4326008)(6436002)(6506006)(5660300001)(8936002)(9686003)(55016002)(50986999)(97736004)(101416001)(86362001)(229853002)(53936002)(6246003)(6306002)(25786009)(106356001)(105586002)(2950100002)(7696004)(76176999)(54356999)(68736007)(3660700001)(110136005)(316002)(305945005)(74316002)(3280700002)(8676002)(33656002)(2906002)(966005)(66066001)(2900100001)(6116002)(189998001)(3846002)(102836003)(7736002)(81166006)(478600001)(81156014)(53546010)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P121MB0038; H:DB6P121MB0038.EURP121.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: lighting.com does not designate permitted sender hosts) SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P121MB0038 X-CrossPremisesHeadersFilteredBySendConnector: LIGHT-EDGE-2.lighting.com X-OrganizationHeadersPreserved: LIGHT-EDGE-2.lighting.com X-EOPAttributedMessage: 0 X-Matching-Connectors: 131534995437273900; (); (fd2a86c0-868a-4d63-2575-08d435642d86) X-MS-Exchange-Transport-CrossTenantHeadersStripped: HE1EUR02FT053.eop-EUR02.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:13.81.48.91; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(336005)(39380400002)(39860400002)(376002)(346002)(2980300002)(199003)(13464003)(189002)(24454002)(85714005)(7736002)(2950100002)(97736004)(81166006)(3846002)(68736007)(106466001)(498600001)(6116002)(102836003)(2900100001)(50466002)(81156014)(33656002)(8936002)(25786009)(105586002)(8676002)(229853002)(956001)(5660300001)(23676002)(2906002)(93886005)(316002)(110136005)(55016002)(53546010)(966005)(6246003)(66066001)(86362001)(189998001)(76176999)(356003)(6306002)(47776003)(6506006)(7696004)(69596002)(53936002)(54356999)(4326008)(50986999)(74316002)(9686003)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P121MB0010; H:LIGHT-EDGE-2.lighting.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT053; 1:SpBlPw9i7iIot8iYINvsqsHwT5qzmsZXEDoyK3WiFhVg914Oy0zCs/xrVi+C183pmWJ/CFHzdeh+CqR7rAaKithpP3hL4tTsQ/3CUlwt3Z1Ne5tQtCfxI7PPk0zxQpOF X-DkimResult-Test: Failed X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(3002016)(4534020)(4628075)(201703131517081)(2017052603238); SRVR:HE1P121MB0010; X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0010; 3:30O5Kqo/pv9Z5F9K3dNuM4Ey+Su3eR8wcUmhUFWc+a1Zn07MqQ7kj3ZbyFJpsiZuo+s7qGaCcnjniuRxax884OnCSvNe/jl89TED0VPcFya2JeJ3HvzaMiHy206GRAxYOcjMSctezW106Vv/ofm2IgB7IeHcZU32DNMJiQh28iShUwkQb2o2sTMi7nue0TzCGTgPI5vv1m40QwGeZwKjkPQ0gFGqfc1R/68ku4P8FHtVtjMqNKSMGX2Kbh6tbbfoqwqvDyjtHa225/sDzIL2dNzkkMgeQUMXW34Im8k2jpHFtecFfzCXpAhd8+WVWFM7gcVC/QotZE62y6HkTquKGQ==; 25:8akibMd+5JIPYjg/PASS3DuS7nPUqKWKG79pb0yEImbh/oRTtyaagMQ9yXTrQ7eoEb9b7ZD6pC0I+LFUIjj/as3nXyfN1jvDH98WSZdrY9dlI3mlb1ln+pO2rjv/RoKbGH8eoWqU54KeAc+rQyKO9OULerfTNN8BrmS3S+cLDQ5K5By4M0OhTaamV/MrNNvOR+UENPHMPyoH4IcOzP3g/4T4qp2F11HnJH8Ym8ndKgbNvwx16I9QfT6BQYp1rsEdvLUoyYV+nKfVhCldjdNDws6LkDfL31KLbjSH7aifjj1G4NaUYJnzgOweFhMNqMDMI/7FGBXfrUENNUfuxp8nCw==; 31:rJ/j2k4nSVrGNTEixh9H00IDoDp7nj20lbBV7kl+1gAp+7d3lYXDKXcHS8OSASWYIe2hvi+MeURti40NVHcMwZ5ibEWq2ix3F3DAJFPNEn0/Xw5kkIJBFm4xIwfZn283dn1j7V08WWM8mzU56M32Lw9SlD4vh3D+leanTwRyKKGkDeXkuif3o+LT1eQzIFisNRGTsGjZcvC8aXqQCTg/LIDpsS0GmO8jZhS9ucL8ZAY= X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0010; 4:8HZkSeYJ/S/8kmcBaeyqaJcGOG8pJUQ6UhxF5j81DqFXdmfITVUBM4LkZYN3/MXDj2ULbZGPMGDviffEDn88xjkLse3K88jnBGs2yEwxySmXLhqK70HwjGDZkYcwbHRhp17fJjL/B4WvoK7fjW9V/vYhBCj8uqo+jy3I4bCtEMuIT+bgHLOmjPHPic9+j9ey2sYxy4GQPCqgjI6QWOrvVDWpNqO/3OF5IWO4Y4jxyiGJSdWA1a+s4ZuqloxQji9oeW7wHxmad6QrR/jYG3UXaKZZyx8fjGhCfb3ufjaYJhQ3AEcwrKpaKaTeIxEkLejiX1EDWErO6SnLzX8hkdpLfQ== X-Forefront-PRVS: 04724A515E X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQMTIxTUIwMDEwOzIzOjFsVnVEY2lKaXcrdG5FZk1ORW1TU2F6UU1Q?= =?utf-8?B?N0ZIeW5JTy9KL2UwS0szSzJjdTI5V2hqdjBNNERZWUtZN2x4N1RXWnhOd2NK?= =?utf-8?B?Z3ZzekU1eWdKbHJVeXhUeHl5Ukd4SVlzaDIxNmI4SldQYnJkM3FWU1FWYmF5?= =?utf-8?B?UGFWVjZtdnYrZXVVeGx1RVZ6Z0xGUklqZjlhaGVoUE96ZVR1RVVwT3NRS2VL?= =?utf-8?B?T0hxd1pDQVdaUkVDb0Q2TzdSemkxaitIOStyanVzQ2dlTWFkajgwSDJMZmVS?= =?utf-8?B?ZVBhdGwwaEZ4bkdjb3JEb3BYWVdJWGltVlIycmVCSUdkeUF4aFg1OFd0QmVt?= =?utf-8?B?bzhJYnhOTE5DVE1wOElmMmV2ckxTV1M1dGxHeDBnYnVhQkc3eFl4TXZSdExW?= =?utf-8?B?VEJ3WEVwVVFUK0NFeE8zbkJ0cFFyeUh2ejU0SGorS01aNXFuN2lKMmphREFM?= =?utf-8?B?VTI3ck9NT1JsbWE1NWlNa3B5TE9hU1RiZjF4a1M5RG5va2J5MnBRWU9TSExD?= =?utf-8?B?UDNHVmREWnRYWFErTFdZRTFrRS96WStCMmVsa1VJcUwyQzkzeTFHdVNZYk05?= =?utf-8?B?UnJ1ajlVR0Q5QlJJSVE2cGJ2TWdGRmhHcnE3TlE1TVR0bEpCNDBhL3BvTFY2?= =?utf-8?B?UUI4a3NkU2ZFZ1dyejFvY2ZES0dWbVg1SmgvR1dRc2RnMGZkVXkraE1YM3ZR?= =?utf-8?B?RmxNRWxQT0dmSHZIeHFOUk00UFBmTzRGQk9EWUlpY29xcTFWaEVFeGwyVTA0?= =?utf-8?B?b3VRck43WkxBZTZVMGFTTXV6ZllhaHdIQi9NMHhMUmFWYXpZUlFmOHhCWk9R?= =?utf-8?B?Z0hzd2ttN05ieDBqMUwwTGJaNW5MMTNPRkpZMUNXRlZLWG5lVlhmeWFsTjc3?= =?utf-8?B?M2pRN25GRDdIcTNURXRHcmJMUHBjeUQvQnpVbE1hRE1IdmR0cFRpeGFwTmhm?= =?utf-8?B?Uk54dnV0WExMVE01Y2c2eWZhbk1idENOTWI5d25lTWgrV1lmZk1IM2JXMkRq?= =?utf-8?B?WHhXZ010MWFhV1NtdTVRTDhYMlk5ZGVYMWxuMWtmUXJoNVFJZGRvUk9Ea1lj?= =?utf-8?B?OG9ITGhwYTBMWUswelhBWUl2cVdTYjNnYzgvYmw0ZW1ja1BlbnFHMEtCa2Zi?= =?utf-8?B?WkFybEl4NVJ1ZXV2QzkrbkdYT3NEL0J3Y2ZJSWhWUlRYY3ZtcStLQzBUZzJC?= =?utf-8?B?Q2s0dDJobGVOaVpreFRJckZhc0VOOTJSaU8wVk1JUnMzU1ovbEthM1JGbTBo?= =?utf-8?B?OFlteFYrMmwvVUxjUmd5a2RSQ2hjRjNDT2l3bnNFaUJVaXdnQmpwNG5ubmtx?= =?utf-8?B?bHFPUHRVNTJkdVN4bDRnczUxajFPTDZ5V2dtZ0o4VklmR0dzRDhVdEdTOGxt?= =?utf-8?B?ZnNhUFFvVWhFemdnSkF5RUVWZjJESGJ5Z3B3OG9TenNFQjVTVytIdnFrR2VK?= =?utf-8?B?S1JqMFRtbEwvTXVzZ1VaQjdLS3VkS0JoZVN4bW5MWWhCZHluMkwrc3YzWmpH?= =?utf-8?B?YTdXZEtYWHQycXZWU2dON1R3S0FYTWpyM0g3cEVlbm9ibFVtQ0t4cmQrSFlI?= =?utf-8?B?cnFPTXkxRmZTb3VPMXdaMm5FMFdCZ204U1k2V1lPWWQvOGtXY3hSaXBhcGJW?= =?utf-8?B?STRWOVk3TVU1VWgraGdxL3JwaW44cXNGcS85Q0xPTE80L0MrZWgwL2YxV3lp?= =?utf-8?B?ZUx0V3YwQmRsTUhBWGRDUlI3VXVGdnoxa050aDZOcDRjNjZ0bFE5d0xVcGtR?= =?utf-8?B?R056WCtZejM0cm1tdmpyZjRveEg2ZWJzdlFXdFdJQjJPYzZXdlhkUk1BRnJU?= =?utf-8?B?NldZajgyTlZ5RHN5MDNRZ2t0cWczQTNiVFRRUlBSUDhsT0E9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0010; 6:eKj2edSuft+IRBDQY2PhCg2+/8l1T6UABaSEDsub36c5bhO5fbs/jQ3LFWcyLHinTf/iPbEBJedVTp/hWHa5BmccCo5a6VdXbyX6MFGJYPeEK/lXiANJtyQ5xASe0k1xm4OO7deQCD7L+XDTPA9VXigg1oR2v8CLej8o9gV/KVQslnKZnEd+j7Hl8IrndsJG9KoDLoizMj4zTMWddaWhUa7/2yXFTPxaWsKswc1WTA5PR3ax26SGqO7Lxy4HLEmPS2v+OrK728B0xWey+i7QnhZaMaX2LVnhBm/TnqTdhnh3zo2sVq6IwUFnQx4QNuj60CI13ydV3pfKr0UAH4tieQ==; 5:nfx/5QgelNgcl6NQ+JOE3UFGLf8I/Vn72qvKiwBRYWIknGdMC0ke4t2f43ufMuS2yeeb6UnWeqjp5Xfpa+7Kd/tn49CfwmTogFR55NPh0ji09/cDBP2A1+vDyixfFa4lAFbHDSP61aLOfslmi/t1VQ==; 24:jrfTivdCDohpJSz0UZi4ZY/kqlEXSjtgZdzbxTQnLIdYNQufngds/JVpB7d054lY3ISrNdLOo9Im70nquSXfzomcMeKveOASwy0eQ/m8Nq4=; 7:6auDE5HayZz95ADHoEqvFu4H/557bKhoahsejpw7bZFoqRHqwuN41hfVUqWmm8NH1+4oApMLf+jDWWCYNJIMPb6CzunSIRU5C5Vu7Qeky5IQ1f0B4+nAir+mvkt84KnCMlwdKFTImNhE5gXwBQF8jXmeErYRw+mky6Ku4chVaux5i0ZC7vOvATEiDKINoSeCPEsNTQZjMeitTZzuo1bNTRqO47RQJOPh6+cgVTADVmM= X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2017 13:52:23.3055 (UTC) X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[13.81.48.91]; Helo=[LIGHT-EDGE-2.lighting.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P121MB0010 Archived-At: Subject: Re: [core] Simple registration and URI length restrictions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 13:52:29 -0000 Q2Fyc3RlbiwNCg0KVGhlIGNsZWFudXAgbG9va3MgZ29vZCAtIHRob3VnaCB0aGUgbXVsdGljYXN0 IGRpc2NvdmVyeSBleGFtcGxlIHN0YXRlcw0KDQpjb2FwOi8vW2ZmMDI6OjFdLy53ZWxsLWtub3du L2NvcmU/cnQ9Y29yZS5yZCoNCg0KQnV0IEkgd291bGQgc3VnZ2VzdCBhIGJldHRlciBwcmFjdGlj ZSBpcyBvbmUgb2YgYmVsb3cgd2l0aCAiQWxsIENvQVAgTm9kZXMiIGFkZHJlc3MNCg0KLSBjb2Fw Oi8vW2ZmMDI6OmZkXS8ud2VsbC1rbm93bi9jb3JlP3J0PWNvcmUucmQNCi0gRm9yIChtZXNoKSBu ZXR3b3JrIHRlY2hub2xvZ2llcyB0aGF0IGRlZmluZSB0aGUgcmVhbG0tbG9jYWwgc2NvcGU6IGNv YXA6Ly9bZmYwMzo6ZmRdLy53ZWxsLWtub3duL2NvcmU/cnQ9Y29yZS5yZA0KLSBSRkM3MjUyIHN1 Z2dlc3RzIHRoYXQgc2NvcGUgNSBpcyBhbHNvIHN1cHBvcnRlZCwgc28gdGhpcyBjYW4gYWxzbyBi ZSBkb25lOiAgIGNvYXA6Ly9bZmYwNTo6ZmRdLy53ZWxsLWtub3duL2NvcmU/cnQ9Y29yZS5yZA0K DQpUaGUgc3VnZ2VzdGlvbiBpcyBhbHNvIHRvIGxvb2sgZm9yICJjb3JlLnJkIiBmb3IgYW4gZW5k cG9pbnQgc2Vla2luZyB0byByZWdpc3Rlciwgbm90ICJjb3JlLnJkKiIgd2hpY2ggd291bGQgcmV0 dXJuIHBvc3NpYmx5IG1hbnkgdW53YW50ZWQgcmVzcG9uc2VzLg0KDQpFc2tvDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDYXJzdGVuIEJvcm1hbm4gW21haWx0bzpjYWJvQHR6 aS5vcmddDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNiwgMjAxNyAwOToyNg0KVG86IFN0dWFy dCBMb25nbGFuZCA8c3R1YXJ0bEB2cnQuY29tLmF1Pg0KQ2M6IEVza28gRGlqayA8ZXNrby5kaWpr QHBoaWxpcHMuY29tPjsgY29yZUBpZXRmLm9yZyBXRyAoY29yZUBpZXRmLm9yZykgPGNvcmVAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIFNpbXBsZSByZWdpc3RyYXRpb24gYW5kIFVSSSBs ZW5ndGggcmVzdHJpY3Rpb25zDQoNCk9uIE9jdCAyNiwgMjAxNywgYXQgMDk6MjIsIFN0dWFydCBM b25nbGFuZCA8c3R1YXJ0bEB2cnQuY29tLmF1PiB3cm90ZToNCj4NCj4gU28gaWYgYSBkZXZpY2Ug ZG9lc24ndCBrbm93IGEgdGFyZ2V0IGFkZHJlc3MsIEknbSBndWVzc2luZyB0aGUgYW55Y2FzdA0K PiBJUCBhZGRyZXNzIGlzIHRoZSBpbnRlbmRlZCBtZWNoYW5pc20gYnkgd2hpY2ggdG8gcGVyZm9y bSBzZXJ2aWNlDQo+IHB1YmxpY2F0aW9uPw0KDQpXZSBoYXZlIHJlY2VudGx5IGNsZWFuZWQgdXAg dGhlIHNlY3Rpb24gIkZpbmRpbmcgYSBSZXNvdXJjZSBEaXJlY3RvcnnigJ0uDQoNCmh0dHBzOi8v Y29yZS13Zy5naXRodWIuaW8vcmVzb3VyY2UtZGlyZWN0b3J5L2RyYWZ0LWlldGYtY29yZS1yZXNv dXJjZS1kaXJlY3RvcnkuaHRtbCNyZmMuc2VjdGlvbi40DQoNClBsZWFzZSBsZXQgdXMga25vdyB3 aGV0aGVyIHRoYXQgd29ya3MgZm9yIHlvdS4NCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgZW1haWwgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQvb3IgbGVnYWxseSBwcm90ZWN0ZWQg dW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1p bmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBlbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVz dHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBlbWFpbC4NCg== From nobody Thu Oct 26 07:13:19 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1084613F5A4 for ; Thu, 26 Oct 2017 07:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lightingaad.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZsXQRJbJZe9 for ; Thu, 26 Oct 2017 07:13:12 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0056.outbound.protection.outlook.com [104.47.0.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3851E13A65C for ; Thu, 26 Oct 2017 07:13:09 -0700 (PDT) Received: from AM5P121CA0002.EURP121.PROD.OUTLOOK.COM (2603:10a6:224:b::16) by HE1P121MB0011.EURP121.PROD.OUTLOOK.COM (2a01:111:e400:e2b0::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 26 Oct 2017 14:13:06 +0000 Received: from HE1EUR02FT053.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::206) by AM5P121CA0002.outlook.office365.com (2603:10a6:224:b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4 via Frontend Transport; Thu, 26 Oct 2017 14:13:06 +0000 Authentication-Results: spf=neutral (sender IP is 13.80.155.198) smtp.mailfrom=philips.com; vrt.com.au; dkim=fail (signature did not verify) header.d=lightingaad.onmicrosoft.com;vrt.com.au; dmarc=fail action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 13.80.155.198 is neither permitted nor denied by domain of philips.com) Received: from EDGE-VM-002.westeurope.cloudapp.azure.com (13.80.155.198) by HE1EUR02FT053.mail.protection.outlook.com (10.152.11.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.156.4 via Frontend Transport; Thu, 26 Oct 2017 14:13:05 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (213.199.154.175) by autodiscover.lighting.com (192.168.0.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1034.26; Thu, 26 Oct 2017 14:12:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightingaad.onmicrosoft.com; s=selector1-lighting-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iRhHiQc2Kog+cEVXIe3CAUD2r7XtVhBlEoeQ8cbM0l0=; b=QxwUsRI/Be/Nx7ZJprcXlcVg0bnZ4fkspeS6mIyc6qA4HyCdwLVriqTh4BEOvFoZ29X++V5iKng1lIRax2mY21XIC4Mz/w1oe9yH2qXUsJVMWlF+I4AOfMjnEfetju6jCrc5Nirs+WXkN+RFJ+uwD3ACJV7jor7tf5z0TbZ5nrE= Received: from DB6P121MB0038.EURP121.PROD.OUTLOOK.COM (129.75.191.85) by DB6P121MB0037.EURP121.PROD.OUTLOOK.COM (129.75.191.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Thu, 26 Oct 2017 14:12:41 +0000 Received: from DB6P121MB0038.EURP121.PROD.OUTLOOK.COM ([129.75.191.85]) by DB6P121MB0038.EURP121.PROD.OUTLOOK.COM ([129.75.191.85]) with mapi id 15.20.0156.007; Thu, 26 Oct 2017 14:12:41 +0000 From: Esko Dijk To: Stuart Longland , "core@ietf.org WG (core@ietf.org)" Thread-Topic: [core] Simple registration and URI length restrictions Thread-Index: AQHTTWXYRvrbsvtunUm746jMyX4i4qL0OnwwgAGA+wCAAG0fMA== Date: Thu, 26 Oct 2017 14:12:40 +0000 Message-ID: References: <48729a59-f5e8-e20a-f1cb-7a0bb64b1d8d@vrt.com.au> <72045bd2-f3e9-015d-4ee5-37cdc0b40700@vrt.com.au> In-Reply-To: <72045bd2-f3e9-015d-4ee5-37cdc0b40700@vrt.com.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@lighting.com; x-originating-ip: [80.255.245.238] x-ms-publictraffictype: Email X-Microsoft-Exchange-Diagnostics-untrusted: 1; DB6P121MB0037; 6:WQwFR5HGgpM9EWfGmQltgavK7QMSKSNWsCX09te2jAW/l9eXZsoozOGRcNufz0VxrECcgTIXCwZVhkEfKUfLzqYQ0GQGuOt+eBsf+raAXFzMNz8uhJTaDqQouomE/9xTlQD5Hag3JdrN/IbKmAvetaJ2hNLgGyhqaZiUUgvq4jTQfZg7Ir9uqGAnBRqCXzVkj0DU4GlSiFR4EE1QS3CDrhAVW8+33g9uDvCWcSqzdgjoGWMln3G4mOZHX0gpswFcV0LTbHUd/xMHIf3q5QbSHxQ30pm3cYs4Vklj5HkM6nRNjgjG5RJRjzD76m3oXR9I9x/lsRqs/2y1NTBo9xnhGQ==; 5:xh1gieBdKezhiodMuSF6iINteLhvSlxqBaDjUb3LaAabN7iMjSRtRfJog6PY8JgIrh8uMMOou8cuO8YDpQAoVSrdKxj+8xB3uxlo2JM9YLt8A2fHGYFS1WHe8+8bBF5y9rml5r7sslPTsj06B2zQ3A==; 24:Lvgz5KsLzJUrrDQb03xdnuAVj5cWkZDyFPwd2VJrBsGhQYMl1F/JPhZTajylZ8Qn73E95POhUioaDYNz9OjVikyKjCZnoirnlQYEO210aCE=; 7:Zmna+H7kpb9H02uP/TX0XviUGQH+1qKrckd5GGhke45gBqOj9EECijJGb3BVj4zmJbOfLu9pQeEqvqYiqT/NrSYPhJgCISC9g0le+m38Xz27XSP+Yq83lh/WfltdN6RPq0Kg+n7CemaVm3Y+N7JeAHnylSzWFGCyvRtAXigIglSC6c8NvNFJZTmGLXBU2pIK7In5bRJCKssVDjUInT8BREyuNhuuybtONk25mFqdy6k= x-ms-exchange-antispam-srfa-diagnostics: SSOS; X-MS-Office365-Filtering-Correlation-Id: 487d7bc1-917e-48c6-d0ec-08d51c7bad48 X-Microsoft-Antispam-Untrusted: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:DB6P121MB0037; X-MS-TrafficTypeDiagnostic: DB6P121MB0037:|HE1P121MB0011: x-exchange-antispam-report-test: UriScan:(166708455590820)(150554046322364)(46150409022019)(260087099026482); UriScan:(166708455590820)(150554046322364)(46150409022019)(260087099026482); X-Microsoft-Antispam-PRVS: x-exchange-antispam-report-cfa-test: =?utf-8?B?QkNMOjA7UENMOjA7UlVMRUlEOigxMDAwMDA3MDAxMDEpKDEwMDEwNTAwMDA5?= =?utf-8?B?NSkoMTAwMDAwNzAxMTAxKSgxMDAxMDUzMDAwOTUpKDEwMDAwMDcwMjEwMSko?= =?utf-8?B?MTAwMTA1MTAwMDk1KSg2MDQwNDUwKSgyNDAxMDQ3KSg4MTIxNTAxMDQ2KSg1?= =?utf-8?B?MDA1MDA2KSgxMDIwMTUwMTA0NikoOTMwMDYwOTUpKDkzMDAxMDk1KSgxMDAw?= =?utf-8?B?MDA3MDMxMDEpKDEwMDEwNTQwMDA5NSkoMzAwMjAwMSkoMzIzMTAyMCkoNjA0?= =?utf-8?B?MTI0OCkoMjAxNjExMjM1NTgxMDApKDIwMTYxMTIzNTY0MDI1KSgyMDE2MTEy?= =?utf-8?B?MzU2MjAyNSkoMjAxNjExMjM1NTUwMjUpKDIwMTYxMTIzNTYwMDI1KSgyMDE3?= =?utf-8?B?MDMxMzE0MjMwNzUpKDIwMTcwMjI4MTUyODA3NSkoMjAxNzAzMDYxNDIxMDc1?= =?utf-8?B?KSgyMDE3MDMwNjE0MDYxNTMpKDYwNzIxNDgpKDIwMTcwODA3MTc0MjAxMSko?= =?utf-8?B?MTAwMDAwNzA0MTAxKSgxMDAxMDUyMDAwOTUpKDEwMDAwMDcwNTEwMSkoMTAw?= =?utf-8?B?MTA1NTAwMDk1KTtTUlZSOkRCNlAxMjFNQjAwMzc7QkNMOjA7UENMOjA7UlVM?= =?utf-8?B?RUlEOigxMDAwMDA4MDAxMDEpKDEwMDExMDAwMDA5NSkoMTAwMDAwODAxMTAx?= =?utf-8?B?KSgxMDAxMTAzMDAwOTUpKDEwMDAwMDgwMjEwMSkoMTAwMTEwMTAwMDk1KSgx?= =?utf-8?B?MDAwMDA4MDMxMDEpKDEwMDExMDQwMDA5NSkoMTAwMDAwODA0MTAxKSgxMDAx?= =?utf-8?B?MTAyMDAwOTUpKDEwMDAwMDgwNTEwMSkoMTAwMTEwNTAwMDk1KTtTUlZSOkRC?= =?utf-8?B?NlAxMjFNQjAwMzc7QkNMOjA7UENMOjA7UlVMRUlEOigxMDAwMDA3MDAxMDEp?= =?utf-8?B?KDEwMDEwNTAwMDA5NSkoMTAwMDAwNzAxMTAxKSgxMDAxMDUzMDAwOTUpKDEw?= =?utf-8?B?MDAwMDcwMjEwMSkoMTAwMTA1MTAwMDk1KSg2MDk1MTM1KSgyNDAxMDQ3KSg1?= =?utf-8?B?MDA1MDA2KSg4MTIxNTAxMDQ2KSgxMDAwMDA3MDMxMDEpKDEwMDEwNTQwMDA5?= =?utf-8?B?NSkoOTMwMDYwOTUpKDkzMDAzMDk1KSgxMDIwMTUwMTA0NikoMzIzMTAyMCko?= =?utf-8?B?MzAwMjAwMSkoNjA1NTAyNikoNjA5NjAzNSkoMjAxNjExMjM1NjUwMjUpKDIw?= =?utf-8?B?MTYxMTIzNTYxMDI1KSgyMDE2MTEyMzU1OTEwMCkoMjAxNjExMjM1NjMwMjUp?= =?utf-8?B?KDIwMTcwMzEzMTQzMDA3NSkoMjAxNzAzMTMxNDMzMDc1KSgyMDE3MDMxMzE0?= =?utf-8?B?NDgwNzUpKDIwMTcwMzE2MTI1OTE1MCkoMjAxNzAzMTUxMDQyMTUzKSgyMDE2?= =?utf-8?B?MTEyMzU1NjAyNSkoMjAxNzA4MDcxNzQyMDExKSgxMDAwMDA3MDQxMDEpKDEw?= =?utf-8?B?MDEwNTIwMDA5NSkoMTAwMDAwNzA1MTAxKSgxMDAxMDU1MDAwOTUpO1NSVlI6?= =?utf-8?B?SEUxUDEyMU1CMDAxMTtCQ0w6MDtQQ0w6MDtSVUxFSUQ6KDEwMDAwMDgwMDEw?= =?utf-8?B?MSkoMTAwMTEwMDAwMDk1KSgxMDAwMDA4MDExMDEpKDEwMDExMDMwMDA5NSko?= =?utf-8?B?MTAwMDAwODAyMTAxKSgxMDAxMTAxMDAwOTUpKDEwMDAwMDgwMzEwMSkoMTAw?= =?utf-8?B?MTEwNDAwMDk1KSg0MDAwMDYpKDEwMDAwMDgwNDEwMSkoMTAwMTEwMjAwMDk1?= =?utf-8?B?KSgxMDAwMDA4MDUxMDEpKDEwMDExMDUwMDA5NSk7U1JWUjpIRTFQMTIxTUIw?= =?utf-8?Q?011;?= x-forefront-prvs: 04724A515E X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(199003)(13464003)(24454002)(189002)(85714005)(106356001)(105586002)(53546010)(189998001)(97736004)(6436002)(229853002)(6506006)(5660300001)(66066001)(7696004)(2906002)(3660700001)(966005)(3280700002)(316002)(86362001)(478600001)(110136005)(2950100002)(25786009)(101416001)(81166006)(81156014)(305945005)(8936002)(33656002)(7736002)(74316002)(50986999)(76176999)(54356999)(53386004)(55016002)(9686003)(6306002)(2900100001)(53936002)(8676002)(6116002)(102836003)(3846002)(68736007)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P121MB0037; H:DB6P121MB0038.EURP121.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: lighting.com does not designate permitted sender hosts) SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P121MB0037 X-EOPAttributedMessage: 0 X-Matching-Connectors: 131535007858766346; (); (fd2a86c0-868a-4d63-2575-08d435642d86) X-MS-Exchange-Transport-CrossTenantHeadersStripped: HE1EUR02FT053.eop-EUR02.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:13.80.155.198; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(336005)(346002)(39380400002)(39860400002)(376002)(2980300002)(24454002)(189002)(199003)(13464003)(85714005)(6506006)(316002)(966005)(498600001)(81166006)(189998001)(53386004)(53936002)(81156014)(23676002)(8676002)(8936002)(102836003)(2900100001)(3846002)(97736004)(6116002)(9686003)(6246003)(229853002)(6306002)(53546010)(956001)(55016002)(2906002)(2950100002)(54356999)(105586002)(68736007)(86362001)(25786009)(33656002)(76176999)(22756006)(50986999)(106466001)(305945005)(7736002)(74316002)(66066001)(7696004)(47776003)(356003)(5660300001)(110136005)(50466002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P121MB0011; H:EDGE-VM-002.westeurope.cloudapp.azure.com; FPR:; SPF:Neutral; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; HE1EUR02FT053; 1:xtLpn7SmfatgGqRc+/wNW8opswinVwZcRikjxTlbZA0rrLj8wFVwRf/ne7Hm5XcWagJPMw0oxwC7AEaeOb4MXoE5TLEoGbu6km0o8mn1+/1a647HH708B0zOZKZr3vNA X-DkimResult-Test: Failed X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(3002016)(4534020)(4628075)(201703131517081)(2017052603199); SRVR:HE1P121MB0011; X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0011; 3:qg5UQmCKIb7Ikjr/9yItSw0WxmReGd+vvLumKEOEtv1GVLIoTicx3QGxQMzkhwXZvqMh46SOCESwbWJ9melUa7E4oWlSzuh5OBM4ieETalYLdRYcE+ETH3l1Hl7OKYdUrSl0/MdystweXXIsxH0/WTLTLQhCCk7IqPocfiN1qwt8bLAKkUebe/EtMs4pSjc1hY1bHtrHM4HbQ49WEjTkq7BifHahB0OUeBMMnKBAxUAJCXET9ujSBcICukOgPnt02HI2NdtfSTPVAoXdjJJzUi4mxJ90yV2Np3H+dVItwNHM0y16uZGeT0cur3nTmpwqfUAL3o1ix4VpKrB8kDTqMtcVs2rUK8N7TECOG0vflII=; 25:dVUwnK8ZEmMGSubsiQ+jQN3ZJ8D0rO5PWfCllr4hZeOUHZ8s+Cc1qHhYOKXXWHWl9EH29b1yRTE+RBEiZKW/2g4Hq8rZexLzRvndkwIrbs9/CK4yIZGZwDB5szhRYhDp1yNL3A8C9zNND+xwPGP/a8xN9yle3pwolZTaI4q0OA/IIBQZIXA1eOSiFEwF3d4KiD1M84sI5WHc/nvlE6AKrzsUgkHhO5AzqAhCmThCWuFz8WlIxrLJt4StKCjY6nvdEfIIWg/O0jJEIigDtfBXbIquYxJBWC1zJZBrtRPq5mKHwDtSaIJVjYWkMTux6GY0+a+Mz2JC4m+Z4hfUqk8cVw== X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0011; 31:JlFDsYj2Qgj0aIolkzIm1Pies0vyjN8ciI423qA0saRHzn5lufRc9ImxCXeHwsGpRgf6HWTR7AQkn5u+uYvA1ah7lxjSEC7drCTi3e8IeT7DfYXrgEtOIK7fDrUMk/NT+WVcfEfS54/OlHSunKLCyxu8Aw0eeEizwhnkCMIbex8zK49dhj8Hqeo4n7Qhx2Byl8bWIA5uIY24ZH0+NEJLJI+SYxI4WLuDkfSTlhP73Js=; 4:klYVdwlSz5r97yg2IDoeiJe0mK3/AVUOvqek38XwfBWor2AaSNl56BpXaNFTKnRnLTqp5qwrNTHfxJuuYh+TAZXbzbcgWQhs0T3drkfusidBCh+26T9xL7+tE5f/5iQ0g7+EiBUpKFSy70gT4F57ApWob8xbzEY0MREVbr75GMc3BYM7h1tRqNiyjsfwEYvL62okbxmp+Fe55yphapm/ZlZOy/92ExzHQkfroDitywyTdMxVkW0KKm7tZHH+sfhAt3dkkrbp1KSM4S/RzA0qBWgyN8utSPkmXgvzoQoT5cuoAsbiEiT7U8ekRSIOZfjNALLiFnf202nB1XFxHJ4D1J/CtusC45p4x8B+BR1MrGsuWP1wRZ2kq1jHmoiuw5hQqd8FVmwRyEYQ0rvEm5HOWA== X-Forefront-PRVS: 04724A515E X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQMTIxTUIwMDExOzIzOm5PUlJXUlZZN0Y4SE1mRldvMDZBdEs0cTAv?= =?utf-8?B?QnBwRmNFaHdrbEpRTmFRZUp3N3ZqQTA1L1lvNDFzU3h5TFpNdGYyY210cDIz?= =?utf-8?B?ODAxRVJ4NjhGWTRDNUx1QWpKZHp6Tm5vbVUyYW55Y0diM1pCeHBwblNhQkJT?= =?utf-8?B?T00vUXBYVmpDTk5TTnozVTV2eTNHV0FNZ1I4RVBPTGRSTjlscGJZQWpxajdv?= =?utf-8?B?MVJJQ3hsdzV2T3J5dEVmT2U3WHlSRjFHOWRnSVc3azZsQklFRUxqU2gvUEU0?= =?utf-8?B?WjNYM0s3WFdGbXpFcjY2UTVzSExTcE16Ny95VUxJS0QwaFBZUTRzUUNVd20x?= =?utf-8?B?eksySVUrVmphVmpHU2hlVkN1bEIxV1FzaXlKRmZKZm9hNUphenRJZlh2NU1x?= =?utf-8?B?VTI2cDNoVWFiRVhwb21rTEx2eFRzaUFXKzU2UG5LUTUyRTFXS0lJRnV0V0ly?= =?utf-8?B?NmNiREc0cXlEbW4zR2lxbWRZMG5CRlRKN3d0S2xhclNDeHJsc1B2UGRJL1d4?= =?utf-8?B?MzY2Y1RtUWpNNDhZT1MzRXhlYjVhZnh6d2wwbWdrNytuQUdEekxMUU5KaGJx?= =?utf-8?B?ZkJFbHB6TmpmYVdnKzFTQTNGdFFRcDZnZUtvaXpxS2VEUmhQSDI3VURaa2FW?= =?utf-8?B?V2xtNW01TmpwNTdBTHJicXVuQnBtay9WT1U5TnN1RHloalhEUitDUmlJeXhy?= =?utf-8?B?MEh3dVlvWkFxbG5YNSsvdU9JT0dBcHl2V29Gd3NHSGJOUTd5RkJiTEZNNGY4?= =?utf-8?B?MHN6bW1mWkF2eUxINkxTSm5CSjVOZU0zWll1ZXRuVzZLWjhnMDZONXpDOGlh?= =?utf-8?B?ZXBiN3JYdU9yUndWMkZ0SkU3dG5TdHBZQW9Tc05ZYjJiS0tDMlNnb3pvZk9W?= =?utf-8?B?bjBhWlZqZFhzMktQbXB4YzUwT0M3ZUFTK3NkOCsyeGp2dEdrM1UvVFMrWEty?= =?utf-8?B?R1l0cnlDbHJZYnd3YnhzSW5tR0tFclVFb1VMQlFNc1M3S0dHd25XNjVqdkQy?= =?utf-8?B?YXZwYXBSVW5BQUFQVjdlYXROVUREVVo5WUdYK1JkUlhSbDBNVlZqTVpER0NG?= =?utf-8?B?Yy9Sa29rUkp1S2FUQjZwOEpjU296OVB3SUR0RExSekMydmxvRVoybVlPWDhk?= =?utf-8?B?MG9CNjZCWTRMNFpaRXROK2RXbHBaRzdQYjByZlJ6NEpwaE43bSt5ZGowbUNj?= =?utf-8?B?UHAvaDIwVWt3UmEybys0VjYrNGpGdEplTjVNWWszNExsWTF1eTQ2Q1gzaXlw?= =?utf-8?B?U2JtRWJRTWJXTXlZVHdsdnN3YnRtei9BNkZXVkZjSTk4bEY5RXJCTkdlc2d0?= =?utf-8?B?d2E0VEpsczFMQ2FvU0xnV3IwbGVXVGRlWUF5L0VPOHUxLzV3NDRFUkgzRGUy?= =?utf-8?B?U2l1NXFzZDR1b05vckF3S0pLYU5ia2VFVjZMbFlubW5Wd3FQWTFOQk1KSGcv?= =?utf-8?B?U0o4aDZJMkV2bWlML0xIbXEreVR6NUxjdlNtYmJXc25Qb0tZRmNYaDNMVUdV?= =?utf-8?B?a25ta2xObTBWMFJDVjluN3NNbytuTnpkZE90Z2pOaHNRa2Fhei93NklRcGVv?= =?utf-8?B?SEg0KzVzTzhrTXhRTkdPclZaR1BGUW9RYzF0NmNYdnRneEZ4UjNocHhGNmVC?= =?utf-8?B?eUplWnd5TDRPeVprcm5NSUNLaXNyNUFEdnFRRWo1KzJuaHVqNDJuaXJxTldJ?= =?utf-8?B?RnlhbnFGOUh0NEhtMGxNU3FHRGF6N1RLUnZUaEhicUd3eHJsVlBsbnM2OXJS?= =?utf-8?B?aUhpRXlHMDl1aUk1TEpIMDlxbmt4emV2MEx0SUxjbGtrVll4dTlsRG9BN3dn?= =?utf-8?Q?/jC4CM6uFZu5o?= X-Microsoft-Exchange-Diagnostics: 1; HE1P121MB0011; 6:8ikBQI5iSV+EZTISULbTe13SoR8LVfhvKyczpPNKyuulomSB1brtPnQN2UAKwJqeHP03w7BoU8DVrmZIsPZ11KCvsFf/FNkBgaSmPGpJiuTZowpaqUxp/txMx27+q9Z5BBgWAZPLvD7T6/F+BBLXoBvbP3tuunXVpN6Zqvm89PV8YxEm2x1QKSOPTyzykV1r5qkrj1uQRMyMGh2CZ1nf6S5uarZ8QeSkfLO5ygKlklPr1t9oVKTZl4z9Txd7Wj1TyQf+WbQulu9JwMAlhW9AfFEF1gvptdQvZ2yOlwb/7UEIpr36IGgyZIiVoCSO2cetIsidWaBEnVUhv/QkX37D2Q==; 5:lStPk/Z5tyGz3b/Wu43URc579d3PBnbBxXeuaSsE/1hIRbq2F3SpcI3EPN3J8zAOWM8LgihMO6SbzAKBXFcZXrRtx6DI+A/3ucHW335zkNCFwrfCGWCGbC5Q4EpRYrdtWJV4TjkBtLiYT1wlmDb1iQ==; 24:+ZIe8Jyoy2Kvu1fffc4GD5C0I4xHPTvDBxFRSC7IpuLBEEv/76Pnx3MBUotKHeBaQyH+a3a9WHAWFiUTFdej+kptcQpcd9Xk2/TyotLqqSw=; 7:nWGvic9/ZrXqdpxDY909Xek4wFYYXsjnM7duw6j6Gj0UnvsExwWUYrKTS9Uz0N9KUKPX5P5+bZKR9JCq87/75TO1SwOLzZMVXHLgz4tcaV6CM8Wy1g525DHiUc5B5keO56XBUo/As7F2vOnsRZzLpvz0+mL9PF1nYkTRU9T4Joit91ms3NI25js4AvCYC678958pClaa1wJPLQ6yDms50ntpcbr7g9Lpk6nFv6zTT/4= X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2017 14:13:05.4391 (UTC) X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[13.80.155.198]; Helo=[EDGE-VM-002.westeurope.cloudapp.azure.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P121MB0011 Archived-At: Subject: Re: [core] Simple registration and URI length restrictions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 14:13:18 -0000 SGksDQoNCj4gSXMgaXQgcGFydGljdWxhcmx5IGhhcm1mdWwgdG8gZG8gYSBQT1NUIHRvIGEgbXVs dGljYXN0IGFkZHJlc3M/DQo+IFByZXN1bWFibHkgdGhlIG90aGVyIG5vZGVzIG5vdCBzZXQgdXAg YXMgUkQgY291bGQganVzdCBpZ25vcmUgdGhlIFBPU1QuDQoNCkkgd291bGQgc2F5IHRoZSBpbXBh Y3Qgb2YgbXVsdGljYXN0IFBPU1QgLy53ZWxsLWtub3duL2NvcmUgdG8gdHJpZ2dlciBTaW1wbGUg UmVnaXN0cmF0aW9uIGlzIGFib3V0IHRoZSBzYW1lIGFzIGEgbXVsdGljYXN0IEdFVCAvLndlbGwt a25vd24vY29yZSB3aGljaCBtYXkgYmUgdXNlZCBmb3IgZGlzY292ZXJpbmcgUkRzLiAgSXQgbWF5 IG9mIGNvdXJzZSBsZWFkIHRvIGxvdHMgb2YgdHJhZmZpYyBpZiB0aGVyZSBhcmUgbWFueSBSRHMg YWN0aXZlLCB3aG8gd2lsbCBlYWNoIHF1ZXJ5IHRoZSBlbmRwb2ludCBmb3IgaXRzIHJlc291cmNl cyBhZnRlciByZWNlaXZpbmcgdGhlIFBPU1QuDQoNCj4gSSB3YXMgcGxhbm5pbmcgdG8gaGF2ZSB0 aGUgbm9kZXMgUE9TVCB0byBjb2FwOi8vW2ZmMDU6OmZkXS8ud2VsbC1rbm93bi9jb3Jl4oCmIGF0 IHRoZSBtb21lbnQgSSdtIGp1c3QgdW5pY2FzdGluZyBpdA0KDQpUaGUgY3VycmVudCBSRCBkcmFm dCBpcyBub3QgcmVhbGx5IGNsZWFyIG9uIHdoZXRoZXIgYW4gUkQgd2lsbCBhY2NlcHQgYSBtdWx0 aWNhc3QgcmVxdWVzdCB0aGF0IFBPU1RzIHRvIC8ud2VsbC1rbm93bi9jb3JlLiAgSWYgd2Ugd2Fu dCB0byByZWx5IG9uIHRoYXQgYmVoYXZpb3IsIGl0IHNob3VsZCBiZSBzcGVjaWZpZWQgY2xlYXJs eSBpbiBkcmFmdC1SRC4gTm9ybWFsbHkgb25seSByZXNvdXJjZXMgc3BlY2lmaWNhbGx5IGNvbmZp Z3VyZWQgdG8gc3VwcG9ydCBtdWx0aWNhc3Qgd2lsbCBhY2NlcHQgYSBtdWx0aWNhc3QgcmVxdWVz dDsgb3RoZXIgcmVzb3VyY2VzIHdpbGwgc2lsZW50bHkgaWdub3JlIHRoZSByZXF1ZXN0LiBTZWUg ZS5nLiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzM5MCNzZWN0aW9uLTIuNyB0aGF0 IHN1bW1hcml6ZXMgdGhlIHJlcXVpcmVtZW50cy4gSSB3b3VsZCBhc3N1bWUgdGhhdCBzdXBwb3J0 aW5nIG11bHRpY2FzdCBHRVQgZm9yIGEgcmVzb3VyY2UgKGxpa2UgLy53ZWxsLWtub3duL2NvcmUp IGRvZXNuJ3QgaW1wbHkgdGhhdCBtdWx0aWNhc3QtUE9TVCBpcyBuZWNlc3NhcmlseSBzdXBwb3J0 ZWQuLi4/ICAgSW4gY2FzZSB3ZSBsaWtlIHRvIHN1cHBvcnQgc3VjaCBtdWx0aWNhc3QsIHRoZW4g d2Ugc2hvdWxkIGxpc3QgYSB1bmljYXN0IGV4YW1wbGUgZm9yIFNpbXBsZSBSZWdpc3RyYXRpb24g YW5kIGEgbXVsdGljYXN0IGV4YW1wbGUgZm9yIGl0Lg0KDQpFc2tvDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBTdHVhcnQgTG9uZ2xhbmQgW21haWx0bzpzdHVhcnRsQHZydC5j b20uYXVdDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNiwgMjAxNyAwOToyMg0KVG86IEVza28g RGlqayA8ZXNrby5kaWprQHBoaWxpcHMuY29tPjsgY29yZUBpZXRmLm9yZyBXRyAoY29yZUBpZXRm Lm9yZykgPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIFNpbXBsZSByZWdpc3Ry YXRpb24gYW5kIFVSSSBsZW5ndGggcmVzdHJpY3Rpb25zDQoNCk9uIDI1LzEwLzE3IDE4OjUyLCBF c2tvIERpamsgd3JvdGU6DQo+IEluIGdlbmVyYWwgdGhlIHByb2JsZW0gaW4gT3BlblRocmVhZCBD TEkgY29kZSBzaG91bGQgYmUgZml4ZWQgYW55aG93LA0KPiBiZWNhdXNlIHlvdSBjYW4gbmV2ZXIg a25vdyBhdCB3aGljaCBVUkkgcGVvcGxlIHdpbGwgaG9zdCB0aGVpciBSRC4gSXQNCj4gbWF5IGJl IHZlcnkgbG9uZyEgRXNwZWNpYWxseSB3aGVuIE9wZW5UaHJlYWQgY29kZSBlbmRzIHVwIGludG8N Cj4gcHJvZHVjdHMgaXQgbmVlZHMgdG8gYmUgcmlnaHQuDQoNClRoaXMgaXMgdHJ1ZSwgZXNwZWNp YWxseSBpZiBpdCdzIGFjdHVhbGx5IGltcGxlbWVudGVkIGFzIGEgSFRUUCBzZXJ2aWNlIG9uIHRo ZSBvdGhlciBzaWRlIG9mIGEgcHJveHkuICAoSSdkIGhvcGUgbm90LCBidXQgeW91IG5ldmVyIGtu b3cuKQ0KDQpJIGhhdmUgaW4gZmFjdCwgYW1lbmRlZCBPcGVuVGhyZWFkIHRvIGNvcGUgd2l0aCB0 aGlzOg0KaHR0cHM6Ly9naXRodWIuY29tL3ZydHN5c3RlbXMvb3BlbnRocmVhZC9jb21taXQvZmQ4 YjZmZDI0NjBmMmFiYmJmMjMxOGYxN2QzODQ4NzQyZmYxNTAwOQ0KDQpJJ2xsIHJhaXNlIGl0IHdp dGggdGhlbSBvbiB0aGVpciBtYWlsaW5nIGxpc3QgYW5kIHNlZSBhYm91dCBtYWtpbmcgdGhpcyBj b25maWd1cmFibGUgaW4gdGhlIHNvdXJjZXMgKEknbSB0aGlua2luZyBhICNkZWZpbmUpLiAgVGhh bmtmdWxseSBpdCBkb2Vzbid0IGFwcGVhciB0byBiZSBhIGxpbWl0YXRpb24gb2YgdGhlIHVuZGVy bHlpbmcgQ29BUCBjbGllbnQuDQoNCj4gU3RpbGwgYSBnb29kIHF1ZXN0aW9uIEkgdGhpbmssIGJl Y2F1c2UgdGhlIGN1cnJlbnQgZHJhZnQgc3RhdGVzIHRoYXQNCj4gYW4gZW5kcG9pbnQgZmlyc3Qg ZGlzY292ZXJzIFJEKHMpIGFuZCB0aGVuIHB1Ymxpc2hlcyBpdHNlbGYgKHVzaW5nIHRoZQ0KPiBT ZWN0aW9uIDUuMy4yIFBPU1QgYXBwcm9hY2gpIHRvIG9uZSBvciBtb3JlIHNlbGVjdGVkIFJEKHMp LiBTaW5jZSB0aGUNCj4gZW5kcG9pbnQgYWxyZWFkeSBkaWQgdGhlIGRpc2NvdmVyeSwgaXQga25v d3MgdGhlIHJlc291cmNlIGF0IHdoaWNoIHRoZQ0KPiBSRCBzZXJ2aWNlIHJlc2lkZXMgKGUuZy4g L3JkKS4gU28gd2h5IGRvZXNuJ3QgaXQgdXNlIHRoYXQgcmVzb3VyY2UgL3JkDQo+IHRvIHB1Ymxp c2ggaXRzZWxmPyBUaGF0J3MgdGhlIFJEIHdoZXJlIHRoZSBkZXZpY2Ugd2FudHMgdG8gcmVnaXN0 ZXIuDQoNCldlbGwsIHRoYXQncyB3aHkgSSB3b25kZXJlZCBpZiB0aGVyZSB3YXMgYW4gb21pc3Np b24gaGVyZS4gIEkgY291bGQgc2VlIGdvb2QgcmVhc29ucyBmb3IgdXNpbmcgYC53ZWxsLWtub3du L2NvcmVgLCBidXQgaXQgYWxzbyBtYWRlIG1lIHdvbmRlciBpZiBhIHN1aXRhYmxlIGhhbGYtd2F5 IGNvbXByb21pc2UgY291bGQgYmUgdXNlZC4NCg0KQXJndWFibHkgdGhlcmUncyBub3RoaW5nIHN0 b3BwaW5nIG1lIGZyb20gYnJlYWtpbmcgb3V0IG15IGZ1bmN0aW9uIHRoYXQgcmVwbGllcyB0byBg LndlbGwta25vd24vY29yZWAgd2l0aCB0aGUgbGlzdCBvZiBlbmRwb2ludHMgYW5kIGNhbGxpbmcg dGhhdCB0byBnZW5lcmF0ZSB0aGUgYFBPU1RgIHBheWxvYWQgd2hlbiByZWdpc3RlcmluZyBpZiBJ J20gZ29pbmcgdG8gZG8gaXQgdGhlIGxvbmcgd2F5LiA6LSkNCg0KPiBPbmUgdmFsaWQgcmVhc29u IHRvIHN0aWxsIHVzZSAvLndlbGwta25vd24vY29yZSBpcyB0aGUgZmFjdCB0aGF0DQo+IHNvbWV0 aW1lcyBvbmx5IHRoZSBJUHY2IGFkZHJlc3MsIG9yIGFuIElQdjYgaG9zdG5hbWUsIG9mIHRoZSBS RCBjYW4gYmUNCj4gZGlzdHJpYnV0ZWQgaW4gYSBuZXR3b3JrIHVzaW5nIHNwZWNpZmljIG1lYW5z LiBFLmcuDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtcmVz b3VyY2UtZGlyZWN0b3J5LTExI3NlY3QNCj4gaW9uLTkuMiBzdGF0ZXMgaG93IGFuIE5EIG9wdGlv biBjYW4gZG8gdGhpcy4gSW4gc29tZSBkZXBsb3ltZW50cyBpdA0KPiBtYXkgYmUgYSB3ZWxsLWtu b3duIGFueWNhc3QgSVAgYWRkcmVzcyBwb2ludGluZyB0byB0aGUgbmVhcmVzdCBSRC4gSW4NCj4g dGhlc2UgY2FzZXMgdGhlIGNsaWVudCBkb2Vzbid0IGtub3cgKHlldCkgdGhlIHNwZWNpZmljIHJl c291cmNlIHRvDQo+IGNvbnRhY3QgdGhlIFJELCBzbyB1c2luZyBhIHdlbGwta25vd24gcmVzb3Vy Y2UgaGVscHMgdG8gb3ZlcmNvbWUgdGhpcw0KPiBpc3N1ZS4NCg0KU28gaWYgYSBkZXZpY2UgZG9l c24ndCBrbm93IGEgdGFyZ2V0IGFkZHJlc3MsIEknbSBndWVzc2luZyB0aGUgYW55Y2FzdCBJUCBh ZGRyZXNzIGlzIHRoZSBpbnRlbmRlZCBtZWNoYW5pc20gYnkgd2hpY2ggdG8gcGVyZm9ybSBzZXJ2 aWNlIHB1YmxpY2F0aW9uPw0KDQo+ICoqIE5vdGUgZm9yIFJEIGVkaXRvcnMgSSBhc3N1bWUgbXVs dGljYXN0IFBPU1RpbmcgdG8gbXVsdGlwbGUgUkRzIGlzDQo+IG5vdCBzdXBwb3J0ZWQgZXZlbiB0 aG91Z2ggU2VjdGlvbiA1LjMuMiB1c2VzIGEgbXVsdGljYXN0IGFkZHJlc3MNCj4gW2ZmMDI6OjFd IGluIHRoZSBleGFtcGxlLiAoVGhpcyBzZWVtcyB3cm9uZyBoZXJlPykuIEFsc28gaW4gdGhlDQo+ IGN1cnJlbnQgZHJhZnQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBTaW1wbGUgUmVnaXN0cmF0aW9u IDUuMy4xIGFuZA0KPiBTaW1wbGUgUHVibGlzaGluZyA1LjMuMiBpcyBub3QgY2xlYXIuIChUaGV5 IGFwcGVhciBkaWZmZXJlbnQNCj4gbWVjaGFuaXNtcywgYnV0IHdoZW4gbG9va2luZyBjbG9zZXIg dGhleSBhcHBlYXIgdGhlIHNhbWUNCj4gbWVjaGFuaXNtLi4uKSBSRC0wOCBmb3IgZXhhbXBsZSBt YWtlcyBtb3JlIGNsZWFyIHRoYXQgdGhlc2UgYXJlIG9uZQ0KPiBhbmQgdGhlIHNhbWUgcHJvY2Vz cy4gTGV0J3MgZ2l2ZSB0aGVzZSB0d28gb25lIG5hbWUgdGhlbj8NCg0KSXMgaXQgcGFydGljdWxh cmx5IGhhcm1mdWwgdG8gZG8gYSBQT1NUIHRvIGEgbXVsdGljYXN0IGFkZHJlc3M/DQpQcmVzdW1h Ymx5IHRoZSBvdGhlciBub2RlcyBub3Qgc2V0IHVwIGFzIFJEIGNvdWxkIGp1c3QgaWdub3JlIHRo ZSBQT1NULg0KDQpJIHdhcyBwbGFubmluZyB0byBoYXZlIHRoZSBub2RlcyBQT1NUIHRvIGNvYXA6 Ly9bZmYwNTo6ZmRdLy53ZWxsLWtub3duL2NvcmXigKYgYXQgdGhlIG1vbWVudCBJJ20ganVzdCB1 bmljYXN0aW5nIGl0IGFzIEknbSBmaW5kaW5nIGBub2RlLWNvYXBgIGEgbGl0dGxlIHJlbHVjdGFu dCB0byBqb2luIG11bHRpY2FzdCBJUHY2IGdyb3Vwcy4NCg0KVGhlIGludHJpY2FjaWVzIG9mIG11 bHRpY2FzdCBwcm9ncmFtbWluZyBpcyBzb21ldGhpbmcgSSdtIHN0aWxsIGp1c3QgZ2V0dGluZyBt eSBoZWFkIGFyb3VuZCwgYW5kIGluIHRoZSBJUHY2IGNvbnRleHQgaW4gcGFydGljdWxhcjsgd2hp bGUgSSd2ZSBiZWVuIGV4cGVyaW1lbnRpbmcgd2l0aCBpdCBwcml2YXRlbHkgYXQgaG9tZSwgdGhp cyBoYXMgbGFyZ2VseSBiZWVuIHVuaWNhc3QgY29tbXVuaWNhdGlvbnMuDQoNCkknbGwgaGF2ZSBh IGxvb2sgYXQgdXNpbmcgYW55Y2FzdCBhZGRyZXNzZXMsIHNlZSBpZiB0aGF0IG9mZmVycyBhIHZp YWJsZSBzb2x1dGlvbiB0b28uICBJIGRvbid0IHdhbnQgdG8gaGFyZC1jb2RlIGFkZHJlc3NlcyBp ZiBJIGNhbiBhdm9pZCBpdC4gOi0pDQoNCk1hbnkgdGhhbmtzLg0KUmVnYXJkcywNCi0tDQogICAg IF8gX19fICAgICAgICAgICAgIFN0dWFydCBMb25nbGFuZCAtIFN5c3RlbXMgRW5naW5lZXINClwg IC98XykgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIFQ6ICs2MSA3IDM1MzUgOTYxOQ0KIFwv IHwgXCB8ICAgICAzOGIgRG91Z2xhcyBTdHJlZXQgICAgRjogKzYxIDcgMzUzNSA5Njk5DQogICBT WVNURU1TICAgIE1pbHRvbiBRTEQgNDA2NCAgICAgICBodHRwOi8vd3d3LnZydC5jb20uYXUNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBlbWFpbCBtYXkgYmUgY29uZmlkZW50aWFsIGFuZC9vciBsZWdhbGx5IHByb3Rl Y3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5 IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRp c3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIGVtYWlsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFu ZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIGVtYWlsLg0K From nobody Thu Oct 26 12:26:49 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3575213F452 for ; Thu, 26 Oct 2017 12:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 J7kOjEdJ7bXo for ; Thu, 26 Oct 2017 12:26:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 7BBF213F5EC for ; Thu, 26 Oct 2017 12:26:46 -0700 (PDT) Received: from [192.168.91.204] ([80.92.116.6]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LiWzQ-1dc2sa2Qg8-00cj0y; Thu, 26 Oct 2017 21:26:36 +0200 To: Carsten Bormann Cc: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , "core@ietf.org WG (core@ietf.org)" References: <1a9f165d-6994-a92f-3e93-faabf9c690ba@gmx.net> <26860663-b0c3-981a-5b91-34645786968b@gmx.net> <0B5A47AC-B260-4147-A700-5DC6A886A577@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Thu, 26 Oct 2017 21:26:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <0B5A47AC-B260-4147-A700-5DC6A886A577@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:P8UCrKwbV8jDTkQO+M6RFq+R2WqksXEMf+ATITO4CmsbHnPCrPz 4ty8/eSTe6+07XjiW/YwJugTUKrYKgQaXVo8aeVKWnqaqVlLa0nUpn911j4eDKswFS0pZhT hJUmh4Oxzek2LkDJCrsvNWAhzYXsiBo27b3qhYh5d6idhJdekDuomKuEdheBykGMBK8Y1fP DanPeL3V4RRmVExKcX6cg== X-UI-Out-Filterresults: notjunk:1;V01:K0:slOsVS2POBc=:14ewxU7090xJZMTzg90Ai3 6vXEstGpB/YH558PUMDCS3WHI19Z4ZBiqxm2C4kJRf2CLVaaqaKjWuw4oRkMZiISbqM0H867x Z3LoHqqhZLs2NeiX6ziXwCioik3fp04t9NUqc0iYHmu8WbE/zsUHBGYkHeYux9urOPNP5IFT0 B1WXySlEucS6cpZjCjqXOVpqVnvARLnOlVT4I5FM7bmITpPxJdMemTyMtb1yvuCHdZihCiB4K AiDwt69ZL4c05zP0vPcEbuyRJyvOkfHd0m+CphR7S6BO+ME5FrQmALhyTStRjLeVwGJeHWXFR ck2gOaXIkeS5R7ew3rlDAu79l+sKWUWLTKeucdsvCbcz6hl5Mi4BGPQLwbhiW1YxUdiNkCb4z Fq9FeMXmRvX93KGVmz9wQ5eV8gf/pPyIN9jPrxcPdNiEzy6zTBrzEfcE9wZQiELvaLt6DZVQH DMNYLKlh/jWgTEgeFbtxAcS1CV++XmbVPBkh/earlAm+kMl50n/gyb0bqccXjXYDhTDPY4r1w YpFEQTOFB+kt14RcXp9Z5yJNg9/nJCTV3BUcaVhD+lB/FNF7bM26IE9DMForI7JKo+rD8s5YK etjLNIJFOLJ0EDj0krBCm+vnbe8bP9cqB0tmIhi4p+41zirrxmhz/+1qBvW5YVMRsgKjjPUgA O6Q+JIUvJk6nK1tyTOod2SAdFeYcnVnjsol4q4VkLZiw6KflFnbOJJyDYTQ8+eU3srh/HisVa 0QXnncZMJGec8DcwcJcurodKa0gd7QUGeinpNUGk5DH7bCp7RZQDQOtzE6ADK4arsx0+G6cca qejt78QmT4oXyYeHX9QpC5fBjqP1wcFkf6at/NFju8q7rgjAA8= Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 19:26:48 -0000 Hi Carsten, we are not deploying gateways in the way that they would need this functionality. I believe that should be OK. >From the way you phrase it below it sounds like you should include the functionality in the OSCOAP spec. Ciao Hannes On 10/26/2017 02:58 PM, Carsten Bormann wrote: > On Oct 26, 2017, at 12:57, Hannes Tschofenig wrote: >> >> You want end-to-end security but then you put a proxy in the middle. > > Hi Hannes, > > the freshness vulnerability addressed here indeed occurs with proxies. > But it also occurs with anything else that can hold back and replay traffic, including routers and even possibly an unrelated wireless node that manages to jam the forwarding to the receiving node while making a copy of the original transmission. Decryption capability is not required for this to work. This is a bit like some of the well-known key fob vulnerabilities. > > It is possible to address this at the application level (Web applications typically do), and for a while I thought that would be going to be all we need. > As far as I understand, the argument is that defining a standard CoAP option for this reduces the variability and makes it more likely that the mechanism actually will work right, more independent of the security acuity of the application developer. That is typically an argument to which the IETF is quite accessible. > > Grüße, Carsten > From nobody Thu Oct 26 12:40:19 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1EF13F5F2 for ; Thu, 26 Oct 2017 12:40:17 -0700 (PDT) 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] 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 Se3r7hFc4ED4 for ; Thu, 26 Oct 2017 12:40:15 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 ADC2A13F5AD for ; Thu, 26 Oct 2017 12:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9QJe9gK014072; Thu, 26 Oct 2017 21:40:09 +0200 (CEST) Received: from client-0008.vpn.uni-bremen.de (client-0008.vpn.uni-bremen.de [134.102.107.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yNHQx01d3zDWgN; Thu, 26 Oct 2017 21:40:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Thu, 26 Oct 2017 21:40:08 +0200 Cc: =?utf-8?Q?Jaime_Jim=C3=A9nez?= , "core@ietf.org WG (core@ietf.org)" X-Mao-Original-Outgoing-Id: 530739607.788951-c62e36013d29d33ee736801ba2214d64 Content-Transfer-Encoding: quoted-printable Message-Id: <82347E34-277C-4F88-97D8-1EB24138BFD4@tzi.org> References: <1a9f165d-6994-a92f-3e93-faabf9c690ba@gmx.net> <26860663-b0c3-981a-5b91-34645786968b@gmx.net> <0B5A47AC-B260-4147-A700-5DC6A886A577@tzi.org> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 19:40:17 -0000 On Oct 26, 2017, at 21:26, Hannes Tschofenig = wrote: >=20 > Hi Carsten, >=20 > we are not deploying gateways in the way that they would need this > functionality. I believe that should be OK. No routers, no unrelated wireless nodes either? I=E2=80=99m not sure we are communicating. > =46rom the way you phrase it below it sounds like you should include = the > functionality in the OSCOAP spec. I don=E2=80=99t think information that is needed to secure a pure-DTLS = implementation should be hidden in the OSCORE spec. Gr=C3=BC=C3=9Fe, Carsten >=20 > Ciao > Hannes >=20 > On 10/26/2017 02:58 PM, Carsten Bormann wrote: >> On Oct 26, 2017, at 12:57, Hannes Tschofenig = wrote: >>>=20 >>> You want end-to-end security but then you put a proxy in the middle. >>=20 >> Hi Hannes, >>=20 >> the freshness vulnerability addressed here indeed occurs with = proxies. >> But it also occurs with anything else that can hold back and replay = traffic, including routers and even possibly an unrelated wireless node = that manages to jam the forwarding to the receiving node while making a = copy of the original transmission. Decryption capability is not = required for this to work. This is a bit like some of the well-known = key fob vulnerabilities. >>=20 >> It is possible to address this at the application level (Web = applications typically do), and for a while I thought that would be = going to be all we need. >> As far as I understand, the argument is that defining a standard CoAP = option for this reduces the variability and makes it more likely that = the mechanism actually will work right, more independent of the security = acuity of the application developer. That is typically an argument to = which the IETF is quite accessible. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >=20 From nobody Fri Oct 27 06:55:56 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6663B13F56D; Fri, 27 Oct 2017 06:55:54 -0700 (PDT) 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] 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 Tcn_2erDF1j4; Fri, 27 Oct 2017 06:55:53 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 15AB613F569; Fri, 27 Oct 2017 06:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9RDtEBu012153; Fri, 27 Oct 2017 15:55:14 +0200 (CEST) Received: from client-0068.vpn.uni-bremen.de (client-0068.vpn.uni-bremen.de [134.102.107.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yNlkV0ww4zDWvX; Fri, 27 Oct 2017 15:55:14 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <004701d3342c$49dcaa40$dd95fec0$@augustcellars.com> Date: Fri, 27 Oct 2017 15:55:13 +0200 Cc: draft-ietf-core-senml@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 530805313.260744-fdd76e27290af6a428792090b3e7584a Content-Transfer-Encoding: quoted-printable Message-Id: <0FC31E93-F4EF-484F-8A87-922E18F65498@tzi.org> References: <004701d3342c$49dcaa40$dd95fec0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-senml - Last Call comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 13:55:54 -0000 On Sep 23, 2017, at 07:24, Jim Schaad wrote: >=20 > * Section 6 - I am sad, but I understand the reasons for the decision, = that > Octets are not encoded as binary values. Hi Jim, the intention is that the bytes (=E2=80=9Coctets=E2=80=9D in French) of = the data value are encoded as a CBOR byte string; o Characters in the String Value are encoded using a definite length text string (type 3). Octets in the Data Value are encoded using a definite length byte string (type 2). Is that not binary enough? Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Oct 27 08:45:29 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359EA13F59C; Fri, 27 Oct 2017 08:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVdkhiWUj4kV; Fri, 27 Oct 2017 08:45:18 -0700 (PDT) Received: from zproxy120.enst.fr (zproxy120.enst.fr [IPv6:2001:660:330f:2::c1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000961389E1; Fri, 27 Oct 2017 08:45:17 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id B8B4680D2B; Fri, 27 Oct 2017 17:45:16 +0200 (CEST) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id CQ6tYZSCj3zS; Fri, 27 Oct 2017 17:45:16 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 1CC9B80E1F; Fri, 27 Oct 2017 17:45:16 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy120.enst.fr 1CC9B80E1F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1509119116; bh=pY2dklhIOTNovZpUtUwtSJGkmpGw5pU6hadXSsrQVHQ=; h=MIME-Version:From:Date:Message-ID:To; b=n50wr+R+dFAsDRIVLwUaTNxMPlhdYQhH9STIp8Y2/avN1k3pUN0DGVpKWxtfzXal3 nR6n3/iiM42wT6kYrTa0smr2A7d+2cA10yPMaz83xtHk1hy26PR/Z4PQdVgrSALTul DqVJ41wWvxU3m4giji3Eu7jlO/asHhWl7C7m1zTw= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id 08OMN3YvGyPC; Fri, 27 Oct 2017 17:45:16 +0200 (CEST) Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by zproxy120.enst.fr (Postfix) with ESMTPSA id BF16D80D2B; Fri, 27 Oct 2017 17:45:15 +0200 (CEST) Received: by mail-vk0-f44.google.com with SMTP id t184so4431612vka.6; Fri, 27 Oct 2017 08:45:15 -0700 (PDT) X-Gm-Message-State: AMCzsaXiLzgxILBmUfmLKqIkBwNr62KMhNATqWXkV27VHqoOWExSG/Uo RDLkrEeLv7aO8nz+PyLSRFsl0IKzOBh4c+ffmeI= X-Google-Smtp-Source: ABhQp+SNM3O+PySQvUtTtnpPWQMq+1vrv7t1MdfS7V7cvO4zehEojWe1c4+DRi2Jwni3fJIwrczgPzeIGNX7l/sr3q4= X-Received: by 10.31.16.72 with SMTP id g69mr705373vki.197.1509119114449; Fri, 27 Oct 2017 08:45:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.60.163 with HTTP; Fri, 27 Oct 2017 08:44:34 -0700 (PDT) In-Reply-To: <150911482196.22189.6442387199539378067.idtracker@ietfa.amsl.com> References: <150911482196.22189.6442387199539378067.idtracker@ietfa.amsl.com> From: Laurent Toutain Date: Fri, 27 Oct 2017 17:44:34 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "core@ietf.org WG" , lp-wan Cc: Ana Minaburo Content-Type: multipart/alternative; boundary="001a114323f8bd9b2a055c892c63" Archived-At: Subject: [core] Fwd: New Version Notification for draft-toutain-core-time-scale-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 15:45:20 -0000 --001a114323f8bd9b2a055c892c63 Content-Type: text/plain; charset="UTF-8" Hi, We just published this draft for a new CoAP option called Time Scale. From your view, it will be useful for CoAP servers responding to clients connected to a LPWAN network. Since clients are sleeping most of the time, interactions will take longer. Servers must adapt their behavior. We would like to have a feedback from the CoAP community on this proposal. Laurent and Ana. ---------- Forwarded message ---------- From: Date: Fri, Oct 27, 2017 at 4:33 PM Subject: New Version Notification for draft-toutain-core-time-scale-00.txt To: Laurent Toutain , Ana Minaburo < ana@ackl.io>, Laurent Toutain A new version of I-D, draft-toutain-core-time-scale-00.txt has been successfully submitted by Laurent Toutain and posted to the IETF repository. Name: draft-toutain-core-time-scale Revision: 00 Title: CoAP Time Scale Option Document date: 2017-10-26 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-toutain-core- time-scale-00.txt Status: https://datatracker.ietf.org/doc/draft-toutain-core-time- scale/ Htmlized: https://tools.ietf.org/html/draft-toutain-core-time-scale-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-toutain-core- time-scale-00 Abstract: SCHC compression mechanism for LPWAN network enables IPv6 on devices connected to a constrained network (LPWAN). They can communicate with a CoAP server located anywhere in the Internet. LPWAN network characteristics limits the number of exchanges and may impose a long RTT. The CoAP server must be aware of these properties to manage correctly requests. The Time Scale option allows a device to inform a CoAP server of the duration the message ID value should be kept in memory to manage correctly message duplication. 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. The IETF Secretariat --001a114323f8bd9b2a055c892c63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We just published this dra= ft for a new CoAP option called Time Scale. From your view, it will be usef= ul for CoAP servers responding to clients connected to a LPWAN network. Sin= ce clients are sleeping most of the time, interactions will take longer. Se= rvers must adapt their behavior.

We would like to have a feedb= ack from the CoAP community on this proposal.

Laurent and Ana.=

---------- Forwarded= message ----------
From: <internet-drafts@ie= tf.org>
Date: Fri, Oct 27, 2017 at 4:33 PM
Subject: New= Version Notification for draft-toutain-core-time-scale-00.txt
To: Laure= nt Toutain <Laurent= .Toutain@imt-atlantique.fr>, Ana Minaburo <ana@ackl.io>, Laurent Toutain <laurent.toutain@imt-atlantique.fr>


A new version of I-D, draft-toutain-core-time-scale-00.txt
has been successfully submitted by Laurent Toutain and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-toutain-core-time-scale=
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CoAP Time Scale Option
Document date:=C2=A0 2017-10-26
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-toutain-= core-time-scale-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-toutain-core-time-scal= e/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://tools.ietf.org/html/draft-toutain-core-time-scale-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-toutain-core-ti= me-scale-00


Abstract:
=C2=A0 =C2=A0SCHC compression mechanism for LPWAN network enables IPv6 on d= evices
=C2=A0 =C2=A0connected to a constrained network (LPWAN).=C2=A0 They can com= municate
=C2=A0 =C2=A0with a CoAP server located anywhere in the Internet.=C2=A0 LPW= AN network
=C2=A0 =C2=A0characteristics limits the number of exchanges and may impose = a long
=C2=A0 =C2=A0RTT.=C2=A0 The CoAP server must be aware of these properties t= o manage
=C2=A0 =C2=A0correctly requests.=C2=A0 The Time Scale option allows a devic= e to inform
=C2=A0 =C2=A0a CoAP server of the duration the message ID value should be k= ept in
=C2=A0 =C2=A0memory to manage correctly message duplication.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a114323f8bd9b2a055c892c63-- From nobody Sat Oct 28 01:11:37 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF83113FAD5 for ; Sat, 28 Oct 2017 01:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 tvfof0reeJlV for ; Sat, 28 Oct 2017 01:11:34 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 F1E7213FAB3 for ; Sat, 28 Oct 2017 01:11:33 -0700 (PDT) X-AuditID: c1b4fb30-2ddc39c000001b7f-fe-59f43bb44cbe Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FB.25.07039.4BB34F95; Sat, 28 Oct 2017 10:11:32 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.134]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Sat, 28 Oct 2017 10:11:02 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG (core@ietf.org)" CC: Hannes Tschofenig , =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , "John Mattsson" , =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , Carsten Bormann Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgQ2FsbCBmb3IgQWRvcHRpb24gb24gZHJhZnQtYW1z?= =?utf-8?Q?uess-core-repeat-request-tag-00?= Thread-Index: AQHTTklA874vzSS9W0K+J3Md6FlYeaL19g8AgABsg4CAAAPJAIACZCCA Date: Sat, 28 Oct 2017 08:11:02 +0000 Message-ID: <2122B908-7B31-4F54-9C5A-E3452FA02258@ericsson.com> References: <1a9f165d-6994-a92f-3e93-faabf9c690ba@gmx.net> <26860663-b0c3-981a-5b91-34645786968b@gmx.net> <0B5A47AC-B260-4147-A700-5DC6A886A577@tzi.org> <82347E34-277C-4F88-97D8-1EB24138BFD4@tzi.org> In-Reply-To: <82347E34-277C-4F88-97D8-1EB24138BFD4@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/signed; boundary="Apple-Mail=_A42FE783-DD6B-4B15-99E3-D0FD59209917"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUyM2J7uO4W6y+RBs/fC1gsv/CcxeLIlLus Fvverme2uDnjFJMDi8eaeWsYPbbuv8vksWTJTyaPaYsyA1iiuGxSUnMyy1KL9O0SuDLuHdnO XrDPoWLRs60sDYwPbboYOTkkBEwktm49z9TFyMUhJHCEUWLRvCPMEM4SRok/tyayg1SxCThL fHrWCGaLCJhJbNn1lRWkiFmgm0niS9N3RhBHWKCZUeLr4i3sII6IQAujxJO7h5kgWtwk9nRc YwaxWQRUJaZtvQcW5xWwl7i0ZDbU8qdMEn0rz7GAJDgFrCU+L33NCmIzCohJfD+1BqyBWUBc 4taT+UwQl4tIPLx4mg3CFpV4+fgfK4StJLHo9mcmiPumMEq8+dDODrFNUOLkzCcsExhFZiGZ NQtZ3SwkdbMYOYASSRJ9E6og6rUlli18zQxha0rs717OgimuIdH5bSIrhG0q8froR0YI21pi xq+DbBC2osSU7ofsCxi5VzGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIERvrBLb8NdjC+fO54 iFGAg1GJhzdI7UukEGtiWXFl7iFGFaA5jzasvsAoxZKXn5eqJMI7VwkozZuSWFmVWpQfX1Sa k1p8iFGag0VJnNdx34UIIYH0xJLU7NTUgtQimCwTB6dUA2OM18c9Ir/Wrldge5u8yF8k0dDl 1HzZ5RPuPDp5Q5rR2vkdy1Xlbek/dm+wFJ0ja6rGHq/oue3vG9fvF5yCrr3M+bm5ysNSxjje dcsneYdfLMI2pV+08yexBOr9uhh+MFD//hWX/85csU6yd/aoHNSOWMO7cLG675c5/z5IvtoW vyuj23n+vQlKLMUZiYZazEXFiQCPHm2a/AIAAA== Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_Call_for_Adoption_on_draft-amsu?= =?utf-8?q?ess-core-repeat-request-tag-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 28 Oct 2017 08:11:36 -0000 --Apple-Mail=_A42FE783-DD6B-4B15-99E3-D0FD59209917 Content-Type: multipart/alternative; boundary="Apple-Mail=_433F7453-3E28-446A-8D72-853CBF2B2968" --Apple-Mail=_433F7453-3E28-446A-8D72-853CBF2B2968 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear CoRE WG, I have extended few more days the call for adoption of this draft as = there was a lively discussion around it. I believe that at this point the group has expressed rough consensus for = the adoption of this draft. https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00 = =20= We ask the authors to please send a new version under draft-ietf-core as = soon as possible. The draft can also be set under CoRE=E2=80=99s = repository -like the rest of the drafts- if so they want. Ciao, - - Jaime Jim=C3=A9nez= --Apple-Mail=_433F7453-3E28-446A-8D72-853CBF2B2968 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear CoRE WG,

I have extended few more days the call for adoption of this = draft as there was a lively discussion around it.
I = believe that at this point the group has expressed rough consensus for = the adoption of this draft.

https://tools.ietf.org/html/draft-amsuess-core-repeat-request-t= ag-00 

We ask the authors to please send a new version under = draft-ietf-core as soon as possible. The draft can also be set under = CoRE=E2=80=99s repository -like the rest of the drafts- if so they = want.

Ciao,
- - = Jaime Jim=C3=A9nez
= --Apple-Mail=_433F7453-3E28-446A-8D72-853CBF2B2968-- --Apple-Mail=_A42FE783-DD6B-4B15-99E3-D0FD59209917 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMrTCCBe8w ggPXoAMCAQICEGjDnK4TEsyfW0+Qr43kvSowDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjA5MTMy MzExWhcNMTcxMjA5MTMyMzEwWjBpMREwDwYDVQQKDAhFcmljc3NvbjEXMBUGA1UEAwwOSmFpbWUg Smltw6luZXoxKTAnBgkqhkiG9w0BCQEWGmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tMRAwDgYD VQQFEwdlamFqaW1uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz9DiTCOChb1bYXyr VSnjxfVxZ+NGqajFezGGSWAWycgkTkiVdHu7Ek89luoUCU9D8KukeSlzeIFu+TdcANzelWOUqm53 Dh64KfoutxkI1g1FOk8+o45tjBFqw7xknXyEUhZ9/XLqaXuRdw7sCvO91Z05R37hwGhscO7M0fgv lRtWBxaqbC/Ikvjo+PPqt5zpx+GFaqsJ0+4ZQWjrb6I+8e8EAxCpLqB9HmCAztI+zog/tzaSDQdd gQVjLDAndvnKRziQvOrYc5kvJHkXzLcWITDYmi5pZrgNRBJL2poiwSopQPlF5bGjaRYu2WBytXe2 SDEj1viuqpae1vxy7+AdUwIDAQABo4IBwDCCAbwwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUH AQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUF BzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwJQYDVR0RBB4wHIEaamFpbWUuamltZW5lekBlcmljc3Nvbi5jb20wVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud DgQWBBQ58oLpEh/5VlA3MqHd3ggGy2cPpzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9L NzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBABcJc9IVKYtDtvxGDcoFbAFvNeiH +bRaEu1d9BWRhjtb8ZAU586LmsSwblH+2rbFRtisroKUwq7tZyjQtCrL7Rma0yM74p5PNZ7sGfmz yNZT33hfTZEDo7bjKdaUg0ELBzQvttjIIr7tBVf9cpdOAyOkGn3oqGEomPizRDiKrXBD3V8oMibX nQDb90hg8TJmLb9mqyaRnu1ztxV2585qJUXXPAt1v6qUy23V+tmOE7JzMxrQwa5UupoS/muaQSsR 7Evde7pXBg8jERM7o4VZJIA7LI55ogyb37O7W2zhITXzbHgjQzLoS6MonjIPegCv3pLgdLx0zXhp SUT19qg2LmX1sXTxLJBSJp5eev+x8B7H14taM8FpsAVGLccstjPuxOabdmNNaEvfSBL7GPtQ5Sil DTMdbxhtuFPlP+1p4tPC6A/85YQozqTKCgk28emo8UupTt28DZgfP5b7xpBbnrsA/2aRYpmV2Ay8 BOd8g4O+ZP0WZD9/vPddUDBYPpJiSulKe6uj15vsiiBY4D272VS0dMpwXOvmkKKS/ZAmarywk0hy bl2mb+GW456+N8CESWD4JIHABoXxVAaa0GdGEyL1lSEmw7jOU2h5UAhlhHqPudpSoaLJgqateP2C hWYGv/DwkR9bVpuO8k1ohfjJA4n0qgxfOkWU23sZgo6495KjMIIGtjCCBJ6gAwIBAgIRAKAMy8yb mZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNV BAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXs MmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHf Ozlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FA cLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenI UwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP 5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA1 41dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6Mqe aTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYB BQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20w SwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxp YXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYB BAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNv bmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9 kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg 36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiX g5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ 6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5 tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6 n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHr ZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApIC AQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEwMjgwODExMDJaMCMGCSqGSIb3DQEJBDEWBBQW WFVQ9kx76sRArB+rcLbPk1z05zBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhBow5yuExLMn1tPkK+N5L0q MF8GCyqGSIb3DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjANBgkqhkiG9w0BAQEFAASC AQAahmIw8u2gihZYX30WLSEoBJ26vYrYggItDR2SU7yo9zTkZMc7Kv0mtA0u8c4Ab/wdzG9OMKoj C2nDKZJGA7ObZjjm1rDlo8Ecn2hsDY+r90OohafDr6I4RmPuYZ1+MeSzJvXKbC4PlA7PyHsjFiv2 L7iE3QT3DZli7mlmcFB5Yyum7Pcc62WgQfxRLhFS3ezhesNr/4fQhTisW476Mgj3iLvxF7wD8VSI 1bat2El2LLoOyYzyY2jSO2Gz0h+jF991dwI/gEJZFSGox/OeMIWrE6+ilQ4AjU3wV5uyMk9StEz0 WX+jPxjvCxqsCQ+cF8L540KYHxLXK/u4rw3Dnzj8AAAAAAAA --Apple-Mail=_A42FE783-DD6B-4B15-99E3-D0FD59209917-- From nobody Sat Oct 28 02:32:15 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634E713A214; Sat, 28 Oct 2017 02:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 jMO1bBYd6Mbq; Sat, 28 Oct 2017 02:32:11 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 04AF813942F; Sat, 28 Oct 2017 02:32:10 -0700 (PDT) X-AuditID: c1b4fb30-2ddc39c000001b7f-b5-59f44e980f98 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F8.AC.07039.89E44F95; Sat, 28 Oct 2017 11:32:09 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Sat, 28 Oct 2017 11:32:05 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Jim Schaad , core CC: "draft-ietf-core-senml@ietf.org" Thread-Topic: draft-ietf-core-senml - Last Call comments Thread-Index: AdM0KFeJbiwpO4JKRpGarGSVA2iHYwbloI8A Date: Sat, 28 Oct 2017 09:32:05 +0000 Message-ID: References: <004701d3342c$49dcaa40$dd95fec0$@augustcellars.com> In-Reply-To: <004701d3342c$49dcaa40$dd95fec0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7qO5Mvy+RBn8Pc1jse7ue2eLnuyXM Fqunf2dzYPbYOGc6m8eSJT+ZApiiuGxSUnMyy1KL9O0SuDK6XvxgLHihWHF+wxb2BsbVUl2M nBwSAiYSS57MYgWxhQSOMEosWGzfxcgFZC9mlLiw/Sg7SIJNwF5i8pqPjCC2iICtxPF/18Fs ZgFXid9rb4LZwgLmEgfnP2GFqLGQ6Hi2AareSKJv9lTmLkYODhYBVYnP26NAwrxAI/fOvskG sdde4vXqBywgNqeAg8TpaU+ZQGxGATGJ76fWMEGsEpe49WQ+E8TNAhJL9pxnhrBFJV4+/scK YStJrNh+Ceo0PYkbU6ewQdjWEqvbPrFA2NoSyxa+Zoa4QVDi5MwnLBMYxWYhWTELSfssJO2z kLTPQtK+gJF1FaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZgfB3c8ttgB+PL546HGAU4GJV4 eGucvkQKsSaWFVfmHmKU4GBWEuG96AMU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuu470KEkEB6 YklqdmpqQWoRTJaJg1OqgdFRsjL48M1lit5txSrbVNYczf1nxPrWI32L6/0bvW7MW659nvjz rkW6xCSX63t8q3ydHyo1723cfKpCrTpReqbsfP8trpZ9k5kKeU4d/rrx6jXVzV2eIpUeHOy7 mIRZrtX+2yHwsta5+u3CHzNKNTftP7Baga8nbJJR5mtvtrnz/X4cY+gO8FBiKc5INNRiLipO BAAxJvBgqwIAAA== Archived-At: Subject: Re: [core] draft-ietf-core-senml - Last Call comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 28 Oct 2017 09:32:13 -0000 Thank you for the review Jim!=20 Here are two PRs addressing all the issues you raised: https://github.com/core-wg/senml-spec/pull/83 https://github.com/core-wg/senml-spec/pull/81 Comments inline. There doesn't seem to be any controversy with these issues= so we suggest to merge the PRs on Monday and submit a new version. The onl= y substantial change is the clarification on how to handle Version field in= resolved records. Cheers, Ari > On 23 Sep 2017, at 8.24, Jim Schaad wrote: >=20 > I believe that this document is ready to proceed with some nits. >=20 > I am not really setup to do a competent review on the technical aspects o= f > the document, however they seem to be clear to me. >=20 > * Section 4.2 - Update Time: I suggest that the sentence starts w/ "An > optional value in sections that represents the maximum time". The time > after optional confused me as I initially read this as a time not as a de= lta > time. There may also be a requirement here that an actual time value exi= st > somewhere so that one can compute the absolute time that an update should > occur by. Makes sense. I also aligned the text of update time better with the other d= efinitions. > * Section 4.4 - It is not clear to me that all of the base values in sect= ion > 4.1 provide all of the information needed in order to resolve. While I c= an > infer most of them, I am unclear what to do with Version. Good catch. This turned out to be a bit more substantial issue than we firs= t thought since you actually need to have the version field, if it's someth= ing else than the default, in all the resolved records. We suggest to change this to: A SenML Record is referred to as "resolved" if it does not contain any base values, i.e., labels starting with character 'b', except for Version field (see below), and has no relative times. To resolve the records the base values of the SenML Pack (if any) are applied to the Record. That is, name and base name are concatenated, base time is added to the time of the Record, if the Record did not contain Unit the Base Unit is applied to the record, etc. In addition the records need to be in chronological order. [...] The Version field MUST NOT be present in resolved records if the SenML version defined in this document is used and MUST be present otherwise in all the resolved SenML Records. > * Section 4.4 - It may be a good idea to indicate in this section that al= l > base values are to start with the letter b so that if a new base value is > found by a resolver it will know that it has a problem. Fixed with above. > * Section 6 - It might be a good idea to also provide the example in CBOR > Diagnostic notation. That is easier to read and gives a better idea of > what the content structure is. Agree, we'll add one (see PR 81). > * Section 9 - I have a problem here because in CoAP fragments are not > currently transmitted thus the example in 9.1 is probably not a useful it= em > if you are trying to reduce the transmission size. Do you just want to u= se > a query parameter instead? If not then you need to provide some addition= al > explanation. The fragment identifier is not trying to reduce transmission size. Exactly = same representation is transmitted whether fragment ID is there or not. It'= s used only in client side. We tried to explain this in the first paragraph= of sec 9. > * Section 12.1 - You might want to include a note for the RFC editor to > reverse the order of note 1 and note 2 as they do not appear in that orde= r > in the table. Good catch, fixed. > * Section 12.2 - I am not clear that the column "XML Type" should refer t= o > XML. I assume that this is also the type used for JSON and CBOR. True. Changed that to just "Type". Also changed "ID" to "EXI ID". > * Section 14 - You might want to re-iterate the Privacy consideration tha= t > you noted in Section 4.3 when dealing with name assignment. The section = you > are dealing with has a reference for dealing with IPv6, but not for the > other recommended name times. ACK, we updated the privacy considerations section, now pointing to also RF= C 6973, and refer to privacy section from 4.3.= From nobody Sat Oct 28 17:35:23 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C5813A41A; Sat, 28 Oct 2017 17:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 VM5yskSmk0Ss; Sat, 28 Oct 2017 17:35:20 -0700 (PDT) Received: from mail4.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 D95F513A296; Sat, 28 Oct 2017 17:35:19 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1509237313; h=from:subject:to:date:message-id; bh=iBbRnroO3NtHgsETYUJzGBd+z44rSq2Y4icPP6I4UlM=; b=fy8CVGR2lgSIvVA46ATPi76OMwxH7o6Qu0LdGdDWNPI0PiVeGxLW5jXMSoKIKmHIRObhdK+S5nL h5ens+W4Rd0Ko7sDMnnSDWsUUChMeEYYo8XAktrDfHy+NDouavB9Is+TuicsvF7t+RGc0Pm4G2+uj BuXA5uB7Lz8sI3niSYKKiV4tdQuamAqoMD14IyPWtaI2uxV9Y5km0E3wumrZLERO6bXTAlrem/u8D EOnQtb+wDU/d6stATemowS3xQGOppQdkRmq5Ovkaei18Kz5GmjKr/W8/+CM/ZKOzmyGWSaYgpolk/ TToi2ErcYEp0PdnLiAAas7sbutzDenAAMZug== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 28 Oct 2017 17:35:13 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 28 Oct 2017 17:34:12 -0700 From: Jim Schaad To: =?iso-8859-1?Q?'Ari_Ker=E4nen'?= , 'core' CC: References: <004701d3342c$49dcaa40$dd95fec0$@augustcellars.com> In-Reply-To: Date: Sat, 28 Oct 2017 17:35:08 -0700 Message-ID: <00a101d3504d$c77d2e10$56778a30$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQK4cJqD7J1L/sFgmAUbaGazCiVngALDt4fAoRmcjlA= X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [core] draft-ietf-core-senml - Last Call comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 29 Oct 2017 00:35:22 -0000 Looks fine. > -----Original Message----- > From: Ari Ker=E4nen [mailto:ari.keranen@ericsson.com] > Sent: Saturday, October 28, 2017 2:32 AM > To: Jim Schaad ; core > Cc: draft-ietf-core-senml@ietf.org > Subject: Re: draft-ietf-core-senml - Last Call comments >=20 > Thank you for the review Jim! >=20 > Here are two PRs addressing all the issues you raised: > https://github.com/core-wg/senml-spec/pull/83 > https://github.com/core-wg/senml-spec/pull/81 >=20 > Comments inline. There doesn't seem to be any controversy with these > issues so we suggest to merge the PRs on Monday and submit a new = version. > The only substantial change is the clarification on how to handle = Version field > in resolved records. >=20 >=20 > Cheers, > Ari >=20 >=20 > > On 23 Sep 2017, at 8.24, Jim Schaad wrote: > > > > I believe that this document is ready to proceed with some nits. > > > > I am not really setup to do a competent review on the technical > > aspects of the document, however they seem to be clear to me. > > > > * Section 4.2 - Update Time: I suggest that the sentence starts w/ = "An > > optional value in sections that represents the maximum time". The > > time after optional confused me as I initially read this as a time = not > > as a delta time. There may also be a requirement here that an = actual > > time value exist somewhere so that one can compute the absolute time > > that an update should occur by. >=20 > Makes sense. I also aligned the text of update time better with the = other > definitions. >=20 > > * Section 4.4 - It is not clear to me that all of the base values in > > section > > 4.1 provide all of the information needed in order to resolve. = While > > I can infer most of them, I am unclear what to do with Version. >=20 > Good catch. This turned out to be a bit more substantial issue than we first > thought since you actually need to have the version field, if it's something > else than the default, in all the resolved records. >=20 > We suggest to change this to: >=20 > A SenML Record is referred to as "resolved" if it does not contain = any base > values, i.e., labels starting with character 'b', except for Version field (see > below), and has no relative times. To resolve the records the base = values of > the SenML Pack (if any) are applied to the Record. That is, name and = base > name are concatenated, base time is added to the time of the Record, = if the > Record did not contain Unit the Base Unit is applied to the record, = etc. In > addition the records need to be in chronological order. [...] >=20 > The Version field MUST NOT be present in resolved records if the = SenML > version defined in this document is used and MUST be present otherwise = in > all the resolved SenML Records. >=20 >=20 > > * Section 4.4 - It may be a good idea to indicate in this section = that > > all base values are to start with the letter b so that if a new base > > value is found by a resolver it will know that it has a problem. >=20 > Fixed with above. >=20 > > * Section 6 - It might be a good idea to also provide the example in CBOR > > Diagnostic notation. That is easier to read and gives a better = idea of > > what the content structure is. >=20 > Agree, we'll add one (see PR 81). >=20 > > * Section 9 - I have a problem here because in CoAP fragments are = not > > currently transmitted thus the example in 9.1 is probably not a = useful > > item if you are trying to reduce the transmission size. Do you just > > want to use a query parameter instead? If not then you need to > > provide some additional explanation. >=20 > The fragment identifier is not trying to reduce transmission size. = Exactly same > representation is transmitted whether fragment ID is there or not. = It's used > only in client side. We tried to explain this in the first paragraph = of sec 9. >=20 > > * Section 12.1 - You might want to include a note for the RFC editor > > to reverse the order of note 1 and note 2 as they do not appear in > > that order in the table. >=20 > Good catch, fixed. >=20 > > * Section 12.2 - I am not clear that the column "XML Type" should > > refer to XML. I assume that this is also the type used for JSON and CBOR. >=20 > True. Changed that to just "Type". Also changed "ID" to "EXI ID". >=20 > > * Section 14 - You might want to re-iterate the Privacy = consideration > > that you noted in Section 4.3 when dealing with name assignment. = The > > section you are dealing with has a reference for dealing with IPv6, > > but not for the other recommended name times. >=20 > ACK, we updated the privacy considerations section, now pointing to = also > RFC 6973, and refer to privacy section from 4.3. From nobody Sun Oct 29 05:54:33 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E1C13FE86; Sun, 29 Oct 2017 05:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ooz8syTVd26P; Sun, 29 Oct 2017 05:54:31 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 48DD913FADB; Sun, 29 Oct 2017 05:54:27 -0700 (PDT) X-AuditID: c1b4fb25-debff70000000c94-54-59f5cf81d35d Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 49.B9.03220.18FC5F95; Sun, 29 Oct 2017 13:54:25 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Sun, 29 Oct 2017 13:54:24 +0100 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Peter Saint-Andre - Filament , "draft-ietf-core-senml@ietf.org" CC: core Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dMQyBvbiBkcmFmdC1pZXRmLWNvcmUtY29hcC1zZW5t?= =?utf-8?Q?l?= Thread-Index: AQHS/oQaqDg1pfroaU+/t65FgWCHvaJa+00AgAAdpoCAAhnLgIAACd2AgJ4fr4A= Date: Sun, 29 Oct 2017 12:54:23 +0000 Message-ID: <6AEB2319-23C5-459F-85FB-8CB6EA86BA20@ericsson.com> References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> <5559A4D7-0D55-403D-A3C7-527942640A15@ericsson.com> <1243a4c8-5ce6-642e-faf3-5dda093d13df@filament.com> <5AA558F8-BD20-4871-806B-251155922C56@ericsson.com> <96c526a2-aa7f-5ec3-6e5d-13562b3a8310@filament.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <247E4A01FA6DEB428FBA8490DF027619@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2K7tG7j+a+RBhfvSVvse7ue2eLnuyXM FrPPBDswe1zaNJvdY8mSn0wBTFFcNimpOZllqUX6dglcGfNXnWYq+MBW8f7BN7YGxhtsXYyc HBICJhLv771l7GLk4hASOMwoseZ4M5SzmFHiy8MHLCBVbAK2Ek9a97F2MXJwiAhUScxeoAUS ZhaQkDi78jAriC0skCqxaEM3M4gtIpAmMenPXyjbT+Latv3sIDaLgKrEkS/zwRbzCthL3P// nRVi105miZ0fpoAlOAUcJJ6u+AFmMwqISXw/tYYJYpm4xK0n85kgrhaQWLLnPDOELSrx8vE/ VghbSWLR7c9MIHcyC2hKrN+lD9FqLXH53WkWCFtRYkr3Q3aIGwQlTs58wjKBUWwWkg2zELpn IemehaR7FpLuBYysqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECo+vglt+qOxgvv3E8xCjA wajEw6u9+mukEGtiWXFl7iFGCQ5mJRHeSUuAQrwpiZVVqUX58UWlOanFhxilOViUxHkd912I EBJITyxJzU5NLUgtgskycXBKNTAazP2wMDzwxsKOuez8x+5Mm3J/6xrruxlfN53quD357eXP AZckLCZJTSg117uR0CkVJqwffCiplkmas4nbxsvCwEfkTLX+/Gt1F198dt3O86Aj9f6bNfYX Jv13b1udffCScOGspbrR695OUJTYolFYyvuk4Y2owxLeA5wCstuuLUy4MM/7uluBEktxRqKh FnNRcSIAVP7jk6oCAAA= Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 29 Oct 2017 12:54:32 -0000 SGkgUGV0ZXIgZXQgYWwsDQoNClRoZXJlJ3Mgbm93IGEgc2V0IG9mIFBScyBhZGRyZXNzaW5nIGFs bCB0aGUgY29tbWVudHMgaW4gdGhpcyB0aHJlYWQuDQoNCkNsYXJpZmljYXRpb24gdG8gbmFtZSBj aGFyYWN0ZXIgcmVzdHJpY3Rpb25zIGZvciBVUklzOg0KaHR0cHM6Ly9naXRodWIuY29tL2NvcmUt d2cvc2VubWwtc3BlYy9wdWxsLzg1DQoNClJlbW92aW5nIHJlZmVyZW5jZSB0byBtZXNoIGFuZCA4 MCBieXRlcyBvZiBwYXlsb2FkOg0KaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvc2VubWwtc3Bl Yy9wdWxsLzg2DQoNClJlbW92ZWQgSUVTRyBhcHByb3ZhbCBmcm9tIHVuaXQgYW5kIGxhYmVsIHJl dmlldyBwb2xpY3k6DQpodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9zZW5tbC1zcGVjL3B1bGwv ODANCg0KQWRkZWQgQ29SRSBpbnRlcmZhY2VzIGFzIGV4YW1wbGUgb2Ygc2V0dGluZyB0YXJnZXQg c2VtYW50aWNzIGZvciBhY3R1YXRpb24gdXNhZ2U6DQpodHRwczovL2dpdGh1Yi5jb20vY29yZS13 Zy9zZW5tbC1zcGVjL3B1bGwvODcNCg0KTm9uZSBvZiB0aGVzZSBhcmUgcmVhbGx5IHRlY2huaWNh bCBjaGFuZ2VzIGJ1dCB3b3J0aCBhIHF1aWNrIGxvb2sgYmVmb3JlIHdlIG1lcmdlLg0KDQoNCkNo ZWVycywNCkFyaQ0KDQo= From nobody Mon Oct 30 02:59:37 2017 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 3C83B139095; Mon, 30 Oct 2017 02:59:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150935757616.3385.7992678944201561252@ietfa.amsl.com> Date: Mon, 30 Oct 2017 02:59:36 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-echo-request-tag-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 09:59:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Echo and Request-Tag Authors : Christian Amsüss John Mattsson Göran Selander Filename : draft-ietf-core-echo-request-tag-00.txt Pages : 17 Date : 2017-10-30 Abstract: This document defines two optional extensions to the Constrained Application Protocol (CoAP): the Echo option and the Request-Tag option. Each of these options when integrity protected, such as with DTLS or OSCORE, protects against certain attacks on CoAP message exchanges. The Echo option enables a CoAP server to verify the freshness of a request by requiring the CoAP client to make another request and include a server-provided challenge. The Request-Tag option allows the CoAP server to match message fragments belonging to the same request message, fragmented using the CoAP Block-Wise Transfer mechanism. This document also specifies additional processing requirements on Block1 and Block2 options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-00 https://datatracker.ietf.org/doc/html/draft-ietf-core-echo-request-tag-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 06:33:59 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08B213F89F; Mon, 30 Oct 2017 06:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 fh5pR_uG49U8; Mon, 30 Oct 2017 06:33:56 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 ADCD613F4FF; Mon, 30 Oct 2017 06:33:49 -0700 (PDT) X-AuditID: c1b4fb2d-fc3a89c00000268d-af-59f72a3bcc49 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C5.1E.09869.B3A27F95; Mon, 30 Oct 2017 14:33:47 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.134]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Mon, 30 Oct 2017 14:33:46 +0100 From: Mert Ocak To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , Jim Schaad , "draft-silverajan-core-coap-protocol-negotiation@ietf.org" CC: "draft-ietf-core-resource-directory@ietf.org" , "core@ietf.org" , Tracker issue 36 Thread-Topic: [core] My endpoint has two addresses Thread-Index: AdMmk6dW81pdiJqPSXWDaAjV6O6d9QBz61CAApdOL4AHrrG6AA== Date: Mon, 30 Oct 2017 13:33:46 +0000 Message-ID: <0622F24B-37A1-4E9A-AEA1-3832BC6DF816@ericsson.com> References: <007801d32694$51c49790$f54dc6b0$@augustcellars.com> <1f46d054a227bdba7dc07e5c22bd1549@xs4all.nl> <20170921120110.pkuulxfux2vfusjm@hephaistos.amsuess.com> In-Reply-To: <20170921120110.pkuulxfux2vfusjm@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <3AE093EFD647474BA9B115F2E549B268@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2K7iq611vdIg90zTCw2L7jNZrHv7Xpm iwPfzS3u3u1ltlg9/TubxaOZy1gc2Dw2zpnO5rF38TUmjyVLfjJ5NM5dyBrAEsVlk5Kak1mW WqRvl8CVsWvNYsaCfxIVLYsKGxjXSHQxcnJICJhIXGh5ztLFyMUhJHCYUeLGs4VQzhJGiZbT dxhBqtgENCR29V9lAkmICNxhlJi1/y4riMMs0MYkMf/PNCaQKmEBQ4krR/eBdYgIGEl0br3J CmE7SXz+0s8GYrMIqEpcerkTqIaDg1fAXqLhlwTEtpWMEsceb2YGqeEUcJXY29AGNpNRQEzi +6k1YDazgLhE05eVrBB3C0gs2XOeGcIWlXj5+B9YXFRAT+L3sZfsEHEliUW3PzOB7GIW0JRY v0sfYoy1xNWXL1ghbEWJKd0Pwcp5BQQlTs58wjKBUXwWkm2zELpnIemehaR7FpLuBYysqxhF i1OLi3PTjYz1Uosyk4uL8/P08lJLNjECI/Xglt+6OxhXv3Y8xCjAwajEw3tc6XukEGtiWXFl 7iFGCQ5mJRHeVYpAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwO+y5ECAmkJ5akZqemFqQWwWSZ ODilGhhD70g/X3BdfHFTYPK6aQmui0+yFu06EdjnJs87uXdjzJrl+zwZnS/cb7r8q9mPaR9D WvSn47V2d3fKFu91qzZ54XbAQJbp4uIeealuKRfG+JPLbbf5fjocWyTWvfT95KRtf3cyT/q4 eJvUEiW/F0flzIrFzjO8mim0UvwXU5H0Gf185u1dm8WVWIozEg21mIuKEwGi51fG0AIAAA== Archived-At: Subject: Re: [core] My endpoint has two addresses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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 Oct 2017 13:33:57 -0000 SGkgQ2hyaXN0aWFuLA0KDQpUaGUgaXNzdWUgSmltIHJhaXNlZCB3YXMgbm90IGNvdmVyZWQgd2l0 aCBwcm90b2NvbC1uZWdvdGlhdGlvbiBkcmFmdCBpbmRlZWQgaW4gdGhlIHZlcnNpb24gd2UgZGlz Y3Vzc2VkIGluIFByYWd1ZS4gVGhhdCB2ZXJzaW9uIHByb3Bvc2VkIGEgd2F5IHRvIGV4cG9zZSBh bHRlcm5hdGl2ZSB0cmFuc3BvcnRzIG9uIGEgcGVyLXNlcnZlciBiYXNpcy4gSG93ZXZlciwgaW4g dGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBmb3IgU2luZ2Fwb3JlLCB3ZSBhcmUgaW50cm9k dWNpbmcgYSBuZXcgbGluayBhdHRyaWJ1dGUgIm9sIiA6IG90aGVyIGxvY2F0aW9ucywgaW4gd2hp Y2ggdGhlIENvQVAgc2VydmVyIGNhbiBleHBvc2UgdGhlIHNhbWUgcmVzb3VyY2Ugb24gZGlmZmVy ZW50IGxvY2F0aW9ucy90cmFuc3BvcnRzLiBUaGUgbmV3IGF0dHJpYnV0ZSB3b3JrcyBhcyBhIHBl ciByZXNvdXJjZSBiYXNpcyBhbmQgY2FuIGJlIHVzZWQgYm90aCBvbiBSRCBvciBvbiAvLndlbGwt a25vd24vY29yZS4gVGhpcyB3YXkgZW5hYmxlcyBleHBvc2luZyByZXNvdXJjZXMgYm90aCBwZXIt c2VydmVyIG9yIHBlci1yZXNvdXJjZSBvbiB0aGUgc2FtZSBzZXJ2ZXIsIHNvbWV0aGluZyB3ZSBo YWQgc2V2ZXJhbCBkaXNjdXNzaW9ucyBhYm91dCBpbiBQcmFndWUuIFRoZSBuZXcgYXR0cmlidXRl IGFsc28gcHJldmVudHMgb3ZlcmxvYWRpbmcgdGhlIG1lYW5pbmcgb2YgImNvbiIsIHNpbmNlIHRo ZSBvcmlnaW5hbCBpZGVhIG9mICJjb24iIHdhcyBub3QgaW50ZW5kZWQgZm9yIHBlci1yZXNvdXJj ZS4NCg0KVGhpcyBhcHByb2FjaCBjYW4gYmUgdXNlZCBmb3IgZXhwb3NpbmcgdGhlIHNhbWUgcmVz b3VyY2Ugb24gZGlmZmVyZW50IHJhdyBhZGRyZXNzZXMgYXMgaW4gdGhlIEppbSdzIGlzc3VlIHNp bmNlIHdlIGFyZSBub3QgcmVzdHJpY3RpbmcgdGhlIHVzZSBvZiAib2wiIGZvciBqdXN0IGRpZmZl cmVudCB0cmFuc3BvcnRzLiANCg0KQ2hlZXJzLA0KTWVydA0KDQoNCk9uIDIxLzA5LzIwMTcsIDE1 LjAxLCAiQ2hyaXN0aWFuIEFtc8O8c3MiIDxjaHJ5c25AZnNmZS5vcmc+IHdyb3RlOg0KDQogICAg SGVsbG8gSmltLA0KICAgIEhlbGxvIEJpbGwgYW5kIE1lcnQsDQogICAgDQogICAgT24gRnJpLCBT ZXAgMDgsIDIwMTcgYXQgMDk6Mjg6NDFBTSArMDIwMCwgcGV0ZXIgdmFuIGRlciBTdG9rIHdyb3Rl Og0KICAgID4gRm9yIHRoZSBtb21lbnQsIHdlIG1hZGUgdGhlIG1vZGVsIHN1Y2ggdGhhdCBhbmQg ZXh0ZW5zaW9uIHRvIG11bHRpcGxlDQogICAgPiBjb250ZXh0cyBpcyBwb3NzaWJsZSwgYnV0IG5v dCB5ZXQgc3VwcG9ydGVkIGJ5IHRoZSBSRCwgZ2l2ZW4gdGhhdCBhbGwgdGhlc2UNCiAgICA+IGV4 dGVuc2lvbnMgYXJlIHN0aWxsIHVuZGVyIGRpc2N1c3Npb24sDQogICAgDQogICAgTW9yZSBjb25j cmV0ZWx5LCB0aGlzIGlzIHdoZXJlIEkgaG9wZSB0aGF0DQogICAgY29yZS1jb2FwLXByb3RvY29s LW5lZ290aWF0aW9uIHdpbGwgdGFrZSBvdmVyLiBXZSdyZSBkZWxpYmVyYXRlbHkNCiAgICBrZWVw aW5nIG11bHRpcGxlLWJhc2UtYWRkcmVzc2VzIG91dCBvZiByZXNvdXJjZS1kaXJlY3RvcnkgKGFu IGVhcmxpZXINCiAgICBzdGF0ZSBhbHJlYWR5IGFsbG93ZWQgbW9yZSB0aGFuIG9uZSBhZGRyZXNz KSBzbyB0aGlzIGNhbiBiZQ0KICAgIGNvbXByZWhlbnNpdmVseSBzcGVjaWZpZWQgdGhlcmUgYmFz ZWQgb24gbW9kZWwgdGhhdCBjb250YWlucyBvbmx5IHRoZQ0KICAgIGV4dGVuc2lvbiBwb2ludCBm b3IgaXQuDQogICAgDQogICAgQmlsbCBhbmQgTWVydCwgSmltIHRoZSBpc3N1ZSBKaW0gcmFpc2Vk IGlzIG5vdCBmdWxseSBjb3ZlcmVkIGJ5IHRoZQ0KICAgIHByb3RvY29sLW5lZ290aWF0aW9uIGRy YWZ0IG9yIHdoYXQgd2UgdGFsa2VkIGFib3V0IGluIFByYWd1ZSwgYnV0DQogICAgaW52b2x2ZXMg dGhlIGNob2ljZSBvZiBhbiBJbnRlcm5ldCBsYXllciB3aGVuIHJhdyBhZGRyZXNzZXMgYXJlIHVz ZWQuDQogICAgV2lsbCB3ZSBiZSBhYmxlIHRvIHVzZSB0aGUgbWVjaGFuaXNtcyBpbnRyb2R1Y2Vk IHRoZXJlIGluIHRoZSBhYnNlbmNlIG9mDQogICAgaG9zdG5hbWVzIGZvciBhbiBJUHY0IGFuZCBh biBJUHY2IGFkZHJlc3NlcyAob3IgbXVsdGlwbGUgSVB2Ng0KICAgIGFkZHJlc3Nlcyk/DQogICAg DQogICAgQmVzdCByZWdhcmRzDQogICAgQ2hyaXN0aWFuDQogICAgDQogICAgLS0gDQogICAgVGhp cyBtYXkgc2VlbSBhIGJpdCB3ZWlyZCwgYnV0IHRoYXQncyBva2F5LCBiZWNhdXNlIGl0IGlzIHdl aXJkLg0KICAgICAgLS0gcGVybGRhdGEoMSkgYWJvdXQgcGVybCB2YXJpYWJsZXMNCiAgICANCg0K From nobody Mon Oct 30 10:02:01 2017 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 703E38384; Mon, 30 Oct 2017 10:02:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150938292042.7924.17350195865298271704@ietfa.amsl.com> Date: Mon, 30 Oct 2017 10:02:00 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-sid-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 17:02:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : YANG Schema Item iDentifier (SID) Authors : Michel Veillette Alexander Pelov Filename : draft-ietf-core-sid-02.txt Pages : 23 Date : 2017-10-30 Abstract: YANG Schema Item iDentifiers (SID) are globally unique 64-bit unsigned numbers used to identify YANG items. This document defines the semantics, the registration, and assignment processes of SIDs. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned SIDs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-sid-02 https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 11:31:50 2017 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 512F713F609; Mon, 30 Oct 2017 11:31:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150938830831.7809.14214960601515419982@ietfa.amsl.com> Date: Mon, 30 Oct 2017 11:31:48 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-resource-directory-12.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 18:31:48 -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 : CoRE Resource Directory Authors : Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Christian Amsüss Filename : draft-ietf-core-resource-directory-12.txt Pages : 64 Date : 2017-10-30 Abstract: In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resource descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-resource-directory-12 https://datatracker.ietf.org/doc/html/draft-ietf-core-resource-directory-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 14:43:15 2017 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 04E1D13FBD5; Mon, 30 Oct 2017 14:43:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150939978698.7740.10114502650104125687@ietfa.amsl.com> Date: Mon, 30 Oct 2017 14:43:07 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 21:43:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets Authors : Carsten Bormann Simon Lemay Hannes Tschofenig Klaus Hartke Bilhanan Silverajan Brian Raymor Filename : draft-ietf-core-coap-tcp-tls-10.txt Pages : 50 Date : 2017-10-30 Abstract: The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-10 https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-tcp-tls-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 15:19:02 2017 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 973F913F9FA; Mon, 30 Oct 2017 15:18:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940193158.28396.16650149475168468883@ietfa.amsl.com> Date: Mon, 30 Oct 2017 15:18:51 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-11.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 22:18:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Media Types for Sensor Measurement Lists (SenML) Authors : Cullen Jennings Zach Shelby Jari Arkko Ari Keranen Carsten Bormann Filename : draft-ietf-core-senml-11.txt Pages : 47 Date : 2017-10-30 Abstract: This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), eXtensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use this media type in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-senml-11 https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 15:31:52 2017 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 DBBF013FBDA; Mon, 30 Oct 2017 15:31:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940270186.28270.826505128628572533@ietfa.amsl.com> Date: Mon, 30 Oct 2017 15:31:41 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-cocoa-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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 Oct 2017 22:31:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : CoAP Simple Congestion Control/Advanced Authors : Carsten Bormann August Betzler Carles Gomez Ilker Demirkol Filename : draft-ietf-core-cocoa-02.txt Pages : 17 Date : 2017-10-30 Abstract: The CoAP protocol needs to be implemented in such a way that it does not cause persistent congestion on the network it uses. The CoRE CoAP specification defines basic behavior that exhibits low risk of congestion with minimal implementation requirements. It also leaves room for combining the base specification with advanced congestion control mechanisms with higher performance. This specification defines more advanced, but still simple CoRE Congestion Control mechanisms, called CoCoA. The core of these mechanisms is a Retransmission TimeOut (RTO) algorithm that makes use of Round-Trip Time (RTT) estimates, in contrast with how the RTO is determined as per the base CoAP specification (RFC 7252). The mechanisms defined in this document have relatively low complexity, yet they improve the default CoAP RTO algorithm. The design of the mechanisms in this specification has made use of input from simulations and experiments in real networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-cocoa/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-cocoa-02 https://datatracker.ietf.org/doc/html/draft-ietf-core-cocoa-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-cocoa-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 31 02:32:58 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A4613F6FB; Tue, 31 Oct 2017 02:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 55a64X3HCi_3; Tue, 31 Oct 2017 02:32:50 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4ED01395F0; Tue, 31 Oct 2017 02:32:49 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7C7D54830E; Tue, 31 Oct 2017 10:32:45 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 80A462A; Tue, 31 Oct 2017 10:32:41 +0100 (CET) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6286657; Tue, 31 Oct 2017 10:32:41 +0100 (CET) Received: (nullmailer pid 12829 invoked by uid 1000); Tue, 31 Oct 2017 09:32:40 -0000 Date: Tue, 31 Oct 2017 10:32:40 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Cc: draft-ietf-core-resource-directory@ietf.org Message-ID: <20171031093240.wfwdhs7dwkfofheh@hephaistos.amsuess.com> References: <150938830831.7809.14214960601515419982@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7rqtqwgn2fqpj2c3" Content-Disposition: inline In-Reply-To: <150938830831.7809.14214960601515419982@ietfa.amsl.com> User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: [core] resource-directory-12: Request for reviews, annotated Change Log X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: 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, 31 Oct 2017 09:32:58 -0000 --7rqtqwgn2fqpj2c3 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE working group, On Mon, Oct 30, 2017 at 11:31:48AM -0700, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Constrained RESTful Environments WG of t= he IETF. With the document nearing completion, the authors would like to ask the working group for reviews on the submitted draft. Even though the document contains a change log, some changes were big enough to deserve some more explanation, so we'd like to provide the WG with some further notes and examples with the changelog entries: ---- o clarified where relative references are resolved, and how context and anchor interact o new appendix on the interaction with RFCs 6690, 5988 and 3986 In particular, we now preserve the full resolved statements from Link Format documents submitted to the RD, including the context and link relations. This means that at resource lookup, clients need to be able to understand the anchor=3D attribute. Key example: | Req: GET /rd-lookup/res?rt=3Dtemperature | | Res: 2.05 Content | ;rt=3D"temperature";if=3D"sensor";anchor=3D"coap://[2001:d= b8::123]" Example of a more complex original statement: | Req: GET /rd-lookup/res?rel=3Ddescribedby | | Res: 2.05 Content | ;rel=3D"describedby";anchor=3D"coap://= [2001:db8::123]/sensors/temp" ---- o lookup interface: group and endpoint lookup return group and registration resources as link targets This removes the need for a dedicated "list all groups/endpoints" interface on the registration side. Key example: | Req: GET /rd-lookup/ep?et=3Dpower-node | | Res: 2.05 Content | ;con=3D"coap://[2001:db8::127]";ep=3D"node5";et=3D"power-node";= ct=3D"40";lt=3D"600", | ;con=3D"coap://[2001:db8::129]";ep=3D"node7";et=3D"power-node";= ct=3D"40";lt=3D"600";d=3D"floor-3" Note that as with all URIs in the RD, none of the concrete paths is prescribed. Were a different implementation used, the same example could be: | Req: GET /~resdir/ep-lookup?et=3Dpower-node | | Res: 2.05 Content | ;con=3D"coap://[2001:db8::127]";ep=3D"node5";et=3D"p= ower-node";lt=3D"600", | ;con=3D"coap://[2001:db8::129]";ep=3D"node7"= ;et=3D"power-node";lt=3D"600";d=3D"floor-3" This also allows an unambiguous syntax for putting registered endpoints into groups: | Req: POST /rd-group?gp=3Dlights&con=3Dcoap://[ff35:30:2001:db8::1] | Payload: | , | | Res: 2.01 Created | Location: /rd-group/12 ---- o updated chapter "Finding a Resource Directory"; now distinguishes configuration-provided, network-provided and heuristic sources Endpoints can be pre-configured to use a particular way to find their RD, be it per IP uni-, multi- or anycast, DNS name or DNS-SD service. Endpoints without explicit configuration look for an RD location that comes with the network (eg. from SLAAC); in absence thereof, heuristics for finding an RD are described (multicast discovery, ask the 6LBR). ---- Further changes: o added Content Model section, including ER diagram o removed domain lookup interface; domains are now plain attributes of groups and endpoints o improved text on: atomicity, idempotency, lookup with multiple parameters, endpoint removal, simple registration o updated LWM2M description o lookup interface: search parameters work the same across all entities o removed all methods that modify links in an existing registration (POST with payload, PATCH and iPATCH) o removed plurality definition (was only needed for link modification) o enhanced IANA registry text =20 o state that lookup resources can be observable o More examples and improved text Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --7rqtqwgn2fqpj2c3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAln4QzUACgkQOY0REtOk veEc9RAArH3oXRZfh/arjvLeTblNW3G6+N57vJCf/kuLNh2OX1nowUSFmB+m+AzF Sj9jPEtVF+gV0VQ5V5TuOl5oKYTG0rViZxLawT3gMmu5So/tlpCmbbuBXvRXkGYB yw8swNLhlFQkt+7oWexgZzuKYycEzxqBdJX/cE/dpteBc7skLbBagR1wMH2cldS4 Y+DQw/B4iQDbM7Iks8vBMVr/ILvLEta2ctO3rOTpdu1YUQI9aqc2ubGGvIW08gsR BoHYYE70J1A3udo+1TiwBnIMVm3uFT8QDTamf84M3x4JhdzjtTqieLz9WufOOkKG oP0JtSsNyrP/9YYIGfnVXsbnkctuac74xLQY6NkFqOoKhZvGUtHON+QJEs4pj+zN ZVDEwf0KEMhI+KQ/IKj3pPwM+Ug4ZR8G632hladqxenZKwLNwcp4aQ2VYL5X7xH7 8ZaHFs0BWIWrNDv6m0GeZsxssn31gRpP7wH2/wX3ymGKKpBTPihuT/+H3a3aOpuW t4uv0kML1gPHHpieNHN87wyKyb0xxWTBAclcQnZU47f/Uug/S2RuieCRw7EoaeAO J9XXYl1Hz8TVuVB6GpyaKufUKJCcFCxTRDkzJXRVNzfyHPOFq1Do6uHiKzI5OZza SW/1m5i3pC1NzbiabfLVLxaYXpLVGj6ktJTzS28Qhc1O18YKIXQ= =G28X -----END PGP SIGNATURE----- --7rqtqwgn2fqpj2c3-- From nobody Tue Oct 31 17:26:04 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30D113F5C4; Tue, 31 Oct 2017 17:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 uUCdT-Xx052X; Tue, 31 Oct 2017 17:26:01 -0700 (PDT) Received: from mail4.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 3C0FF13F1EB; Tue, 31 Oct 2017 17:26:01 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1509495956; h=from:subject:to:date:message-id; bh=iEjWE+w6mn/VZOwnkoI0HwtMyzijGTUrZJGT6xp/gO4=; b=TgQlbdYp1Rxxjgd3mXPmmh2eY5X5SdvFVuXKWg3F/MmAkHuC618SUm7+VDco1K94ac3x/VWhciX rTCeFbUgX4bpVCHHlaYyoWDa9aKFfG0O7FUuRMOTG/fn3O/DdqjKee8URt/lwkUgPRxsJBX0hA4hE tdIQg/TA0i2286h1jdpPF74ZaQOxcYi1nIJuivCQDF3VObS2AwHfcThUJnsajHIks1OmlRrITyPW/ lmmT0ZN08W+6TR+kCgH3+tol9A0zryU8/mkY9Z+TPgZYORj87EaG5uxkhGItuXjvWHp3ln6+QIx+C h1HQ4rqqSsWMDtUpJmy48llOEgU/pybh3DFQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 31 Oct 2017 17:25:55 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 31 Oct 2017 17:24:54 -0700 From: Jim Schaad To: CC: 'core' Date: Tue, 31 Oct 2017 17:25:50 -0700 Message-ID: <01e301d352a7$fa605670$ef210350$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdNSmIID5/EW2XAeSaqyf51/E/WReA== X-Originating-IP: [192.168.1.162] Archived-At: Subject: [core] Questions/Review on draft-ietf-core-resource-directory-12 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 00:26:03 -0000 Over all I think that I understand this version better, but there are still some things that I am going to need to ask questions about or comment on. Note this is not a pass from writing code, just from trying to do some design work. 1. When creating a group registration, can the link to an endpoint be on a different resource directory? This second RD could be either on a different machine or on the same machine (i.e. coap vs coaps). If the answer is no, then do we need to think about some type of relation attribute in the case that multiple are listed somewhere? 2. Is there supposed to be an update/patch operation on groups or is this a replace operation ala what is done for endpoints? 3. Are groups supposed to age out of existence? Based on the current text I would say that this is a no. 4. Should have text on what happens to a group when an endpoint which ages out of existence. 5. When registering groups, is there a requirement that all of the endpoints be in the same domain as the group is? 6. In section 7.3 - First it would be better to be much more explicit on the set of items to be matched than the one statement that is current present. From what is there, it is not clear to me that one would return a group if one of the resources of an endpoint in the group has the desired attribute. However, based on everything else, it would appear to be true. Thus the search would be to go up the model (Figure 2) to all ancestor notes and down the tree to all descendent notes. Is this a correct understanding? 7. In section 7.3 - If doing a compound search criteria - Does all of the criteria need to be matched on ANY node in the search or ALL of the criteria on one node in the search? Consider "?d=example.com&rt=foobar" which would match the 'd' on the endpoint but the 'rt' on a resource. So two questions - the first would be looking at two different items at two different levels (i.e. group and resource), the second would be two items at the same level (i.e. two different resources/endpoints which are children/grandchildren of me). Jim From nobody Tue Oct 31 20:40:25 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A514213F85D; Tue, 31 Oct 2017 20:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=augustcellars.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 XxBOqxSYOKuD; Tue, 31 Oct 2017 20:40:22 -0700 (PDT) Received: from mail4.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 14E8513F854; Tue, 31 Oct 2017 20:40:22 -0700 (PDT) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1509507617; h=from:subject:to:date:message-id; bh=DHONgHjWTQvSb/MAVaXMwl9LXCXDXnz1UrguN87uaNo=; b=KhpmF5pbju6CUF9Xr7QOJamMoxVMh0RMN+mV8aKwzo0JkEamytAW9mSqtfG+X2XbYfe24g40M/p 2WWevMzqpcjtBodwiS8hArJBYI78bqW2RexNLD5+wp0v7GHESaub9lpqJBtzhPyxTf3+y5bWO2Cz2 8RLqm/xt091jywJW0tVUMQJVNYUYFHgKesL6aZeG2tJA6wqxEaNl/wKogiZ3YTh0i/PwAzQFeycEa T1LdgGtBII1+834IN1zG//cMDOIc3B9T5G+zi9Wvv/tQzolTV5UlYs7SIIx24tOYByX0QdatYHGLf bI2sSewPNX/j/qWH2EGdeXQEYx11c7JovVUA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 31 Oct 2017 20:40:16 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 31 Oct 2017 20:39:15 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: , References: <004701d3342c$49dcaa40$dd95fec0$@augustcellars.com> <0FC31E93-F4EF-484F-8A87-922E18F65498@tzi.org> In-Reply-To: <0FC31E93-F4EF-484F-8A87-922E18F65498@tzi.org> Date: Tue, 31 Oct 2017 20:40:11 -0700 Message-ID: <01e801d352c3$212fd6c0$638f8440$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQK4cJqD7J1L/sFgmAUbaGazCiVngALPGf6eoR4pmBA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] draft-ietf-core-senml - Last Call comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 03:40:24 -0000 Carsten, Sorry for the slow reply on this, I needed to figure out what my problem = was and why I was not getting a good interpretation. My real issue boils down to the table that you are asking IANA to create = as a registry. I believe that this table is missing a number of columns = and some of the data in it may be considered to be wrong. The fact that = I asked for the column 'XML Type' to be changed to 'Type' is probably = not helping here. I think that the columns for the table should probably be: Name, Label, Type, CBOR Key, XML/JSON Type, EXI ID, Note The Type column holds the abstract type, which as long as it maps = directly to a CBOR Type means that column is not needed. The XML/JSON type for "Data Value" should probably hold "Base64 string" = which, while the expected item, should be made explicit. =20 Jim > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Friday, October 27, 2017 6:55 AM > To: Jim Schaad > Cc: draft-ietf-core-senml@ietf.org; core@ietf.org > Subject: Re: draft-ietf-core-senml - Last Call comments >=20 > On Sep 23, 2017, at 07:24, Jim Schaad wrote: > > > > * Section 6 - I am sad, but I understand the reasons for the = decision, > > that Octets are not encoded as binary values. >=20 > Hi Jim, >=20 > the intention is that the bytes (=E2=80=9Coctets=E2=80=9D in French) = of the data value are > encoded as a CBOR byte string; >=20 > o Characters in the String Value are encoded using a definite = length > text string (type 3). Octets in the Data Value are encoded = using > a definite length byte string (type 2). >=20 > Is that not binary enough? >=20 > Gr=C3=BC=C3=9Fe, Carsten