From nobody Wed May 2 13:44:15 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B9112DA23 for ; Wed, 2 May 2018 13:44:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 HTCJVc67FaVQ for ; Wed, 2 May 2018 13:44:11 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 B604F12DA19 for ; Wed, 2 May 2018 13:44:11 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id g14-v6so15422717ioc.7 for ; Wed, 02 May 2018 13:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=to:from:subject:openpgp:autocrypt:message-id:date:user-agent :mime-version; bh=+9w8+EdE43XAHQYNRkuF7P5iaEK4R6VMYF0b3vIF0os=; b=HKu5zLOMIoOjqnHs0EzSoLZpRfydQiGyOs9P32pQQUif3+JIR+G5vwMsBaGri/gkOm yMm49Q1ncIbfBROJMiMDIIeBYZY1/+wSbHw7ldl2YW9BQgSCD8D6Bbr4vu+Jey8+apRe TduLJ5weH4dsjI5pBymG9g89nsbLpq14UJ9eo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version; bh=+9w8+EdE43XAHQYNRkuF7P5iaEK4R6VMYF0b3vIF0os=; b=UHn3eAzq3rX1aQk2O+IqJl+VY5eJ1OuTd/1YsotsRGu/WmeyWYNmXKdux2brAGPu8v ndYJs3TX6OPc+mL/OueNBl0UAfqLoxOQ0+xkPqzcXyAxbud323btrqmiECDrz0OIxJvA Jxm+SEbuhmqJ4JoWodUC5+gN2/QM9ATWuL/fGY+tnM6mIu/w5WR33CA9wfyfnRuAml6c FE8zwR3BEhZiTGoK5eAObbNrYlWR5norkKE9H6MVCfJUhUPEsXG/HufNQcuuUcKR5P7/ HNPAoy6auH+0XQk+VwDc9mL+gSSaC4Z+1Vwk8bcjN8rs9Cw+eLUXpRjYlH9svpk2sanj mhuA== X-Gm-Message-State: ALQs6tCltblMEHgq1aYFkiEIzVPbgDb8BDOZIyCKr33gOg2U2E2HRxBj 7juV6kTDL0JpVLANu7jfdUvMoQ== X-Google-Smtp-Source: AB8JxZo0TG1HM31Pe1Sr2N+vEcTuKIBejuQewG36aRipFmoYHHj1jBcWU79f42+idsxXKbgOwbihBg== X-Received: by 2002:a6b:3207:: with SMTP id y7-v6mr21725752ioy.191.1525293850909; Wed, 02 May 2018 13:44:10 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id g200-v6sm3041044itb.26.2018.05.02.13.44.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 May 2018 13:44:10 -0700 (PDT) To: core@ietf.org From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <93758001-b5f6-9c92-97f8-47886839e44c@mozilla.com> Date: Wed, 2 May 2018 14:44:08 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LukYu2pGtlytfzUPqaqy4mMjVRTUnWVZj" Archived-At: Subject: [core] feedback on draft-ietf-core-dev-urn-01 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, 02 May 2018 20:44:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LukYu2pGtlytfzUPqaqy4mMjVRTUnWVZj Content-Type: multipart/mixed; boundary="EbpbWY8FJfcth5hmX2hZCFsKC063alnAY"; protected-headers="v1" From: Peter Saint-Andre To: core@ietf.org Message-ID: <93758001-b5f6-9c92-97f8-47886839e44c@mozilla.com> Subject: feedback on draft-ietf-core-dev-urn-01 --EbpbWY8FJfcth5hmX2hZCFsKC063alnAY Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Here is a bit more feedback on the URN namespace for device identifiers: 1. Let's drop the pointer to RFC 3406, which was obsoleted by RFC 8141. 2. The text about not expecting these URNs to be resolved, and about not using r-components from RFC 8141, seems appropriate. 3. As to q-components (RFC 8141, Section 2.3.2), I don't see a need for passing parameters to devices identified by DEV URNs, so the text about not using q-components also seems appropriate. However, I'm curious if other folks know of scenarios where this functionality might be useful. 4. What about f-components? Consider these examples from the spec: urn:dev:ow:264437f5000000ed_humidity # The laundry sensor's # humidity part urn:dev:ow:264437f5000000ed_temperature # The laundry sensor's # temperature part The fact that these are "parts" of a sensor makes me wonder if using f-components would be better: urn:dev:ow:264437f5000000#ed_humidity urn:dev:ow:264437f5000000#ed_temperature 5. The organization-defined identifiers (Section 4.3) concern me. I've seen many unregistered, invalid URN "namespaces" (e.g., "urn:cisco:foo" while I was at Cisco). This is a bad idea all around, yet I expect that many people will take the easy way out. Can we strike this section from the spec and recommend use of the urn:example namespace (BCP 183)? Peter --EbpbWY8FJfcth5hmX2hZCFsKC063alnAY-- --LukYu2pGtlytfzUPqaqy4mMjVRTUnWVZj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlrqIxgACgkQZWGMGH9o FKkSvA/+N2GGe3mtPO8tx43jgIt/e6c4Tj2Z7Lvj55eo8f1nDhSHaTem9svUeJzQ 0HTJpS9EAQ9oHOtrZmucjWJQ1elTUGHCm3gS3NTvi1VUFnTPXAhs7zn610MbjunP 1R7X25rNJ8jUqpiq6lBcWPoBtF+C54/XV6f0oXVCMl3MXDgmFdqOl3EttQsLqhl6 fWy3fj+TQ3I8KLZOZ19js4k9Q9I8G8lxGxCRJ0RHrc6Oj0h/w1CNATOHirq91QpJ d4f+pAWVgK096CQ1Q/dNNz0iW6i76DAOB4YhB8zdfclMxfnau/UQ8sY03Ize6oyc 8IbJLXJDccIBjwhdwOOMT78V/w5wdfU5eqSWSoVObnMidRdo05kEq1vSCTW+om+R LF/ovEv87PIq74TFE60fhGa5vRag9Zm//rhSk6Mo9tvuov/dwIRr6lT/7IxHtwSg y5T2GxTiuPh2Fu6yGaan22MclMs7r4xPRxDXOBBrRFGMoMuBsK+thEbRCiqaBN1W LEBfADlAZzH2Iux5jS+WOEU2qCWtP3AktTbCDsfy3cqAaMxNBgL0OMLhY4ipPB2M 4Lp9NjGzUj2WNP8gWiR4N1JDqGUOaYedIbUokLduQuvXNV3SAyyeKpEsl4E2/tjo C23bW3/tySHhuQ5YEByRHH90wPRzPVUVJGI/MQDYxfQzjXJa3VU= =bRI9 -----END PGP SIGNATURE----- --LukYu2pGtlytfzUPqaqy4mMjVRTUnWVZj-- From nobody Fri May 4 05:36:57 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F05E126BF7 for ; Fri, 4 May 2018 05:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M75KdRCVciMv for ; Fri, 4 May 2018 05:36:54 -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 2D58D120047 for ; Fri, 4 May 2018 05:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525437412; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kUWhf98J/4TjIrLiYQtZtffF0g+0hC3eWRWQ0/Wjepw=; b=PF8ZT4cctbfeEkV0ObbBPBB6VIcsVkxXHQbnmjvudYeZrlVhKCR7Pa1KLMGnKF9W ev6sSLqAUSYhfXSlYCITkHUwaLU1/hk7Et3zuVZnCKs09h6hu0CsshxTJ8kyMkbv apua2AKI3YtOKSku/9eCQ/ymaSpOorJlVnbXfQDyXBs=; X-AuditID: c1b4fb3a-112a09c00000729c-90-5aec53e4d072 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 50.CB.29340.4E35CEA5; Fri, 4 May 2018 14:36:52 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.20]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0382.000; Fri, 4 May 2018 14:36:16 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Michael Richardson , "core@ietf.org" Thread-Topic: [core] OSCORE Inner/Outer duplication Thread-Index: AQHT3xdEkcFqWwTa3EKDoZX8qtx+ZKQfis+A Date: Fri, 4 May 2018 12:36:15 +0000 Message-ID: References: <29840.1524936895@obiwan.sandelman.ca> In-Reply-To: <29840.1524936895@obiwan.sandelman.ca> 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: [147.214.162.217] Content-Type: text/plain; charset="utf-8" Content-ID: <5DBCF7B7CA3C44489C39A6DB8F9C3E9E@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2J7uO6T4DdRBn+viFrse7ue2aLnUD+7 A5PHkiU/mTxa5uxhDmCK4rJJSc3JLEst0rdL4Mr4+mkaY8EFkYqTc74wNjD2iHQxcnJICJhI PJh1lqWLkYtDSOAIo8Tvd9vYIZxFjBJTNnxnBqliE3CReNDwiKmLkYNDRCBQYvJiD5CwsICR xJRHN6HCxhLvr3GAhEWAwu2d08A6WQRUJPYuOsEKYvMKWEjM/HybFaRcCKjm5MJKkDAnUOff 96sYQWxGATGJ76fWMIHYzALiEreezGeCOFNAYsme88wQtqjEy8f/wEaKCuhJ7O1pZ4OIK0s8 vL0X7BpmAU2J9bv0IcZYS+zduIINwlaUmNL9kB3iGkGJkzOfsExgFJuFZNsshO5ZSLpnIeme haR7ASPrKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAeDq45bfVDsaDzx0PMQpwMCrx8Obb vYkSYk0sK67MPcQowcGsJMI769DrKCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8TmkWUUIC6Ykl qdmpqQWpRTBZJg5OqQbGbI5vnypMD3Jurb2tdqesLrHxuYNG1K0H56SO68+xEFzXt42xfneh 29Z5QuuE5vD6btKqvfHDO291+2xVf23fz19fWYbWrzo13+HgUg/ppxwBeflX3iusfDNbZaao +OzjT/bzcVgzP1tRez7Gbfv55PsC/ncl/i/MLRa7c77NIfF1eJD+KomzSizFGYmGWsxFxYkA IgKcX6MCAAA= Archived-At: Subject: Re: [core] OSCORE Inner/Outer duplication 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, 04 May 2018 12:36:56 -0000 SGkgTWljaGFlbCwNCg0KVGhhbmtzIGZvciBjb21tZW50cy4gVGhlIGxhc3Qgc2VudGVuY2Ugb2Yg dGhlIHBhcmFncmFwaCB5b3UgcmVmZXJyZWQgdG8gaXMNCmEgcmVtbmFudCBmcm9tIGFuIG9sZGVy IHZlcnNpb24gb2YgdGhlIHNwZWNpZmljYXRpb24uIFRoZSBwcm9jZXNzaW5nIG9mDQpJbm5lciBh bmQgT3V0ZXIgYXJlIGRlcGVuZGVudCBvbiB0aGUgbWVzc2FnZSBmaWVsZCBpbiBxdWVzdGlvbiwg c28gaW4gZmFjdA0KbmVpdGhlciB0aGlzIHN0YXRlbWVudCBub3IgdGhlIHRoZSBzdGF0ZW1lbnQg eW91IHN1Z2dlc3RlZCBhcmUgdmFsaWQgaW4NCmdlbmVyYWwuIFdlIHdpbGwgdHJ5IHRvIG1ha2Ug dGhlIGRlc2NyaXB0aW9uIG1vcmUgY2xlYXIgb24gdGhpcyBwb2ludCBpbg0KdGhlIG5leHQgdXBk YXRlLg0KDQpUaGFua3MNCkfDtnJhbg0KDQoNCk9uIDIwMTgtMDQtMjgsIDE5OjM0LCAiY29yZSBv biBiZWhhbGYgb2YgTWljaGFlbCBSaWNoYXJkc29uIg0KPGNvcmUtYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgbWNyK2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCg0KPg0KPnNlY3Rpb24g NC4wIG9mIGRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkgZW5kcyB3aXRoOg0KPg0KPiAg IEFuIE9TQ09SRSBtZXNzYWdlIG1heSBjb250YWluIGJvdGggYW4gSW5uZXIgYW5kIGFuIE91dGVy IGluc3RhbmNlIG9mDQo+ICAgYSBjZXJ0YWluIENvQVAgbWVzc2FnZSBmaWVsZC4gIElubmVyIG1l c3NhZ2UgZmllbGRzIGFyZSBpbnRlbmRlZCBmb3INCj4gICB0aGUgcmVjZWl2aW5nIGVuZHBvaW50 LCB3aGVyZWFzIE91dGVyIG1lc3NhZ2UgZmllbGRzIGFyZSB1c2VkIHRvDQo+ICAgZW5hYmxlIHBy b3h5IG9wZXJhdGlvbnMuICBJbm5lciBhbmQgT3V0ZXIgbWVzc2FnZSBmaWVsZHMgYXJlDQo+ICAg cHJvY2Vzc2VkIGluZGVwZW5kZW50bHkuDQo+DQo+SW4gT3V0ZXIgaW5zdGFuY2Ugb2YgYSBDb0FQ IG1lc3NhZ2UgZmllbGQgd2lsbCBiZSBpbnRlZ3JpdHkgcHJvdGVjdGVkIGlmDQo+aXQncw0KPmlu IHRoZSBjbGFzcyBJIG1lc3NhZ2UgYXJlYS4gIENoYW5nZXMgdG8gaXQgd291bGQgY2F1c2UgdGhl IGludGVncml0eQ0KPmNoZWNrDQo+dG8gZmFpbCBhbmQgdGhlIGVudGlyZSBtZXNzYWdlIHRvIGJl IHJlamVjdGVkLiAgU3VjaCBhIG1lc3NhZ2UgZmllbGQgaXMNCj5lZmZlY3RpdmVseSByZWFkLW9u bHkgdG8gcHJveGllcy4NCj4NCj5JZiB0aGUgbWVzc2FnZSBmaWVsZCBpbnN0YW5jZSBpcyBpbiB0 aGUgY2xhc3MgVSBidWNrZXQsIHRoZW4gaXQgY291bGQgYmUNCj5tb2RpZmllZCBieSBwcm94aWVz LiAgSWYgYW4gaW5zdGFuY2UgYWxzbyBleGlzdHMgaW4gdGhlIEUgb3IgSSBidWNrZXRzLA0KPnRo ZW4gYSByZWNlaXZlciBjb3VsZCBkZXRlcm1pbmUgaWYgdGhlIGNvcHkgaW4gVSBidWNrZXQgaGFk IGJlZW4gbW9kaWZpZWQsDQo+YXNzdW1pbmcgaXQgaXMgcmVhc29uYWJsZSBmb3IgdGhlIG1lc3Nh Z2UgZmllbGRzIHRvIGJlIHRoZSBzYW1lIQ0KPg0KPkkgdGhpbmsgdGhhdCB0aGUgYWJvdmUgdGV4 dCBpbiBzZWN0aW9uIDQuMCBzaG91bGQgaW5kaWNhdGUgdGhhdCB0aGUgdHdvDQo+b2NjdXJhbmNl cyBvZiB0aGUgZmllbGRzIChJbm5lciBhbmQgT3V0ZXIpIGFyZSBzZW1hbnRpY2FsbHkgZGlmZmVy ZW50LCBhbmQNCj5yZWNlaXZlcnMgU0hPVUxEIE5PVCBhdHRlbXB0IHRvIG1ha2Ugc3VyZSB0aGV5 IGFyZSBpZGVudGljYWwuDQo+DQo+T1NDT1JFIHVzZXMgdGhpcyBpbiA0LjEuMy41LiAgTm8tUmVz cG9uc2UgaW4gZGlmZmVyZW50IHdheXMsIGZvciBpbnN0YW5jZS4NCj4NCj4tLSANCj5NaWNoYWVs IFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBX b3Jrcw0KPiAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQo+DQo+DQo+DQoNCg== From nobody Mon May 7 06:50:09 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F25124235 for ; Mon, 7 May 2018 06:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 Rfmd9I_vvECN for ; Mon, 7 May 2018 06:50:05 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0068.outbound.protection.outlook.com [104.47.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C431D120227 for ; Mon, 7 May 2018 06:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fzTtexgSVmZucQsXpcfSiitUOje/PTFgdNtQwGACrjE=; b=WYWhO076JPOHawLI9FtlKwPGFS8TciNuYw60iRnTxv8hhqd7Bblg7qVLfXSGedRqTfftcznSewvmvw6MBxQO0VIWa1DWXD+L3HFySPdqO5Hv2O8o5k2eVdkUUYkDnSVYnhL76NSLCWeTrQl7u/bVToTglX0sbmItOeBvy5FLV2c= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1261.eurprd08.prod.outlook.com (10.167.197.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.17; Mon, 7 May 2018 13:50:02 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::4004:973e:4b3:ef88]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::4004:973e:4b3:ef88%18]) with mapi id 15.20.0735.018; Mon, 7 May 2018 13:50:02 +0000 From: Hannes Tschofenig To: "core@ietf.org" Thread-Topic: Conclusion -- Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPmCfncz1IX5t6GRJaeO0C+mMHM9Q== Date: Mon, 7 May 2018 13:50:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1261; 7:NrQTTfOY9GQbB8GeaQPk4/CtMGtcooeUavrqZE/bFG4PZKqAYIIv/HbiVcUHR9jTqPBmLv4Xq9gS7WUNbUwNJXotRKxqdYdidCmSgJSUaUbJ63lZPDrXYSAlka+RRcrcCxr4lE+Cr/r5q9r6AzZh0TOStH+s+m7Pr1htMEwsIfIo9A/3FNEBPBMUHeTTDgDPdfFuB72S1wNDT0cY4oGwUhLCNJMDpRVUstH+RVhaewTrRgXjEaUfkBeiVpdpg6Yy x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1261; x-ms-traffictypediagnostic: VI1PR0801MB1261: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR0801MB1261; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1261; x-forefront-prvs: 066517B35B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(396003)(376002)(366004)(346002)(39860400002)(189003)(53754006)(199004)(40434004)(5660300001)(8936002)(72206003)(316002)(2501003)(5250100002)(26005)(186003)(2900100001)(3846002)(5890100001)(6116002)(790700001)(7696005)(8676002)(478600001)(486006)(476003)(99286004)(14454004)(59450400001)(5630700001)(6916009)(1730700003)(81166006)(81156014)(102836004)(68736007)(6506007)(9686003)(97736004)(6306002)(3660700001)(86362001)(55016002)(5640700003)(54896002)(2351001)(66066001)(106356001)(105586002)(74316002)(2906002)(53936002)(7736002)(25786009)(3280700002)(6436002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1261; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 6Pc4UX/wBIZz3IHlI7RyPoPJ4U8v1aj0AdtGr1fdm860f4Pb478dbzMPUQm9gUGvXC9Uta6cngnZYmDr2gYHRR5+dZ1t+2pnbYcV6qKBFMlu2xBzBmHigxkCKx2HGZyqoiqDtndhZBihkY3a5y217ydWndo3OvAV3sZ8+mwLMysJjvg1XqfnbScPsctIi6kR spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112B9A4410DA3EDE39183BEFA9B0VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 9be4f793-c902-459e-eea7-08d5b4216e77 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9be4f793-c902-459e-eea7-08d5b4216e77 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2018 13:50:02.1973 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1261 Archived-At: Subject: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 07 May 2018 13:50:08 -0000 --_000_VI1PR0801MB2112B9A4410DA3EDE39183BEFA9B0VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I hope that all the discussion around the endpoint name / endpoint client n= ame have helped to make you think about the security implications of sendin= g an unauthenticated identifier. I would like to come to a conclusion and here is my attempt. Since we the RD document also defines the third party provisioning I would = suggest to make the endpoint name optional in the draft. I would also encourage the chairs to find out whether the third party provi= sioning is actually something in this group has gained some experience with= . Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB2112B9A4410DA3EDE39183BEFA9B0VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I hope that all the discussion around the endpoint n= ame / endpoint client name have helped to make you think about the security= implications of sending an unauthenticated identifier.

 

I would like to come to a conclusion and here is my = attempt.

 

Since we the RD document also defines the third part= y provisioning I would suggest to make the endpoint name optional in the dr= aft.

 

I would also encourage the chairs to find out whethe= r the third party provisioning is actually something in this group has gain= ed some experience with.

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB2112B9A4410DA3EDE39183BEFA9B0VI1PR0801MB2112_-- From nobody Mon May 7 06:53:04 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F49124319 for ; Mon, 7 May 2018 06:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 tjJJiFgFxsqs for ; Mon, 7 May 2018 06:53:01 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0047.outbound.protection.outlook.com [104.47.0.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB125124235 for ; Mon, 7 May 2018 06:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ixt+8SliNeChRuZCtY51jYB4+qUbfreWifMseE0oYdQ=; b=DnJq59IrAFx3hKam5PJu8kI9vEBhhS9A2NebL+SzN9Q/Vz8eMFFJhgI9EaqjbEm8niCEe0J64dxEG3EyjMaIX9eybd28BdBRxSHDZL++s/6Bgl2PF+TtTcryxiYXeW0UZG+vYy1B5uj+SXax8adWB9Zve81zZvexiRnInaTuLLo= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1933.eurprd08.prod.outlook.com (10.173.73.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.17; Mon, 7 May 2018 13:52:58 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::4004:973e:4b3:ef88]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::4004:973e:4b3:ef88%18]) with mapi id 15.20.0735.018; Mon, 7 May 2018 13:52:58 +0000 From: Hannes Tschofenig To: "core@ietf.org" Thread-Topic: SUIT Hackathon Thread-Index: AdPmCka7zJos02g8R+KKiX6ur4O6uA== Date: Mon, 7 May 2018 13:52:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1933; 7:b49QUGXhesNPtqblXkmEM8GM6gxPo0J5QQqqRJ43oPPHvWQl1TrB8NcfRUcnDMjAVG1l+EqAbAax13g2ufUi/PQkQ16TxRicVgxml+yMD9QqtmjWN4PzkXh1bB29SULkT0wP4I4tY7+oVL1SlPdwYaXf8iX628hiUbqT5HX0h8WFApLz5AQHSdSUM+85ZY8wsqiMNfe2YkDAtJKTurKvOF8VDBcC+kNlXIH0dmD88b6YqhMcYAVI0tscl6rC8bpO x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1933; x-ms-traffictypediagnostic: VI1PR0801MB1933: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0801MB1933; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1933; x-forefront-prvs: 066517B35B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(346002)(39380400002)(376002)(396003)(40434004)(199004)(189003)(53754006)(72206003)(478600001)(476003)(966005)(486006)(25786009)(2900100001)(68736007)(54896002)(1730700003)(21615005)(6116002)(3846002)(790700001)(9686003)(3480700004)(6306002)(97736004)(8936002)(55016002)(6436002)(5890100001)(2501003)(5250100002)(8676002)(5630700001)(236005)(5640700003)(81166006)(81156014)(221733001)(2906002)(5660300001)(33656002)(6506007)(102836004)(74316002)(99286004)(3280700002)(606006)(7116003)(14454004)(7696005)(7736002)(59450400001)(53936002)(66066001)(316002)(26005)(105586002)(106356001)(2351001)(186003)(3660700001)(6916009)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1933; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: JgYZjjJWIZslNnLAA4+vwy8DQJZ6aU8DEr2Tw4RV6wKg6OqMaPp0eBhWRAJrYXJkI7nKlLmtMMFGgqNNjXi9gmEx7vDxxiudZG5lQUW+BnCUasqZ2yZI7pO5l5IL/D9uA0tg9Bb7w3g7mvM/vNU/LfHE5od0HYMUOD+G105MSnyoZJ9fqiLKkSl/3+VN3cNl spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211231AB61B762E84727662EFA9B0VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 59368b13-7d00-40c6-31cf-08d5b421d75b X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 59368b13-7d00-40c6-31cf-08d5b421d75b X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2018 13:52:58.1854 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1933 Archived-At: Subject: [core] SUIT Hackathon 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, 07 May 2018 13:53:04 -0000 --_000_VI1PR0801MB211231AB61B762E84727662EFA9B0VI1PR0801MB2112_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, for those who have not been active in the recently formed SUIT working grou= p I would like to draw your attention to an upcoming Hackathon on the firmw= are update manifest format. Here is the info: https://www.ietf.org/mail-archive/web/suit/current/msg00454.html In a nutshell, the event takes place in Berlin June 5th & 6th and is hosted= by the "Freie Universit=E4t Berlin". Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB211231AB61B762E84727662EFA9B0VI1PR0801MB2112_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

for those who have not been active in the recently f= ormed SUIT working group I would like to draw your attention to an upcoming= Hackathon on the firmware update manifest format.

Here is the info:

https://www.ietf.org/mail-archive/web/suit/current= /msg00454.html

 

In a nutshell, the event takes=
 place in Berlin June 5th & 6th and is hosted by the “Freie Unive=
rsit=E4t Berlin”. 
 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB211231AB61B762E84727662EFA9B0VI1PR0801MB2112_-- From nobody Mon May 7 06:54:14 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AA6124319 for ; Mon, 7 May 2018 06:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-8UNcBU_AzZ for ; Mon, 7 May 2018 06:54:11 -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 1E707124235 for ; Mon, 7 May 2018 06:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525701249; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CIB9jmo4/7j4Z791HPtqxGxesZFUtVrlQaWQX8dNqXs=; b=Hnh1do5h1o9l5zCZEtlnXBttU2399pfG4am2mCOvgVYYhdBqQecKl2VTLLcvs217 9jG9ayTAC9S9ZlNef1LuRwHi+6vMyCk1JzIAC/3eDPPOvQlUi8nUqldMBW9Q+A9h 26RJCS8kYUNa+3rqujjiJbnOWRzCPVTbtu7Z3i/cO2o=; X-AuditID: c1b4fb3a-d35ff7000000729c-3c-5af05a8154c3 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 25.C1.29340.18A50FA5; Mon, 7 May 2018 15:54:09 +0200 (CEST) Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.382.0; Mon, 7 May 2018 15:54:09 +0200 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id E1D07481AB8; Mon, 7 May 2018 16:54:08 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 9740D481AA4; Mon, 7 May 2018 16:54:08 +0300 (EEST) To: Hannes Tschofenig , "core@ietf.org" References: From: Mohit Sethi Message-ID: Date: Mon, 7 May 2018 16:54:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7B30B00D553A20E322FF0662" Content-Language: en-US X-AV-Checked: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2J7oG5j1Icog6WzZS32vV3PbHFzxikm ByaPNfPWMHosWfKTKYApissmJTUnsyy1SN8ugStj7cTTjAWPdCrad9Q1MO5R7mLk5JAQMJE4 ev0TUxcjF4eQwBFGiXPLz7BBONsZJd7872OEcDYzSryYPxOqbCGjxK/ZqxlB+oUFQiTaTkwF s0WA7LWvTzF3MXIAFSVI9B6WAAmzCehJdJ47zgxi8wrYS7Se2Q1mswioSFz/eZkNxBYViJC4 d/4TG0SNoMTJmU9YQGxOgUSJ7gXXwUYyC4RJLOo0BAkzC4hL3HoynwniA2WJBS2LwC4QElCX 2NpxgHECo9AsJJNmIXTPQtINEbaXeLC1DCIsL7H97RxmCFtf4vqd+6ww8eats5kXMLKvYhQt Ti0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMkYNbflvtYDz43PEQowAHoxIPL2fAhygh1sSy4src Q4wSHMxKIrxsykAh3pTEyqrUovz4otKc1OJDjNIcLErivE5pFlFCAumJJanZqakFqUUwWSYO TqkGRtPV26Q2z7RZbhRtF3RBaGJ5QtkS05azd/9V5cRkb1MX92358EIsqHibjsLpCylFS595 fWydl5l45Caj1/7cgAK1CwIuUu+8Qo0XfnGY+zy3MbquKXWpyMRFLRPXZxQWO+51upLIdO7v eXffgrj8WL2Ee2cXuyyOkJo67c13/Y7KHnE7eS0PJZbijERDLeai4kQA7awrW40CAAA= Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 07 May 2018 13:54:13 -0000 --------------7B30B00D553A20E322FF0662 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Hi Hannes, Thank you for summarizing the discussion on this important topic thus far. Could you also very briefly explain what does third-party provisioning mean for you? --Mohit On 05/07/2018 04:50 PM, Hannes Tschofenig wrote: > > Hi all, > > I hope that all the discussion around the endpoint name / endpoint > client name have helped to make you think about the security > implications of sending an unauthenticated identifier. > > I would like to come to a conclusion and here is my attempt. > > Since we the RD document also defines the third party provisioning I > would suggest to make the endpoint name optional in the draft. > > I would also encourage the chairs to find out whether the third party > provisioning is actually something in this group has gained some > experience with. > > Ciao > > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------7B30B00D553A20E322FF0662 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit

Hi Hannes,

Thank you for summarizing the discussion on this important topic thus far.

Could you also very briefly explain what does third-party provisioning mean for you?

--Mohit


On 05/07/2018 04:50 PM, Hannes Tschofenig wrote:

Hi all,

 

I hope that all the discussion around the endpoint name / endpoint client name have helped to make you think about the security implications of sending an unauthenticated identifier.

 

I would like to come to a conclusion and here is my attempt.

 

Since we the RD document also defines the third party provisioning I would suggest to make the endpoint name optional in the draft.

 

I would also encourage the chairs to find out whether the third party provisioning is actually something in this group has gained some experience with.

 

Ciao

Hannes

 

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

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

--------------7B30B00D553A20E322FF0662-- From nobody Mon May 7 07:16:57 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F541252BA for ; Mon, 7 May 2018 07:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 VdXfI-XWtLyO for ; Mon, 7 May 2018 07:16:53 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20044.outbound.protection.outlook.com [40.107.2.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35A61205D3 for ; Mon, 7 May 2018 07:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=p5ho7RwcUtNNAcAISBzvMkbl/bRsm3bigr97/RMmddg=; b=KQMWpPAObJSpWfcsEavp7QocYzRMsgbV1LFXSrxKbyY2r8xyChY/RVd9469J3WTvVvzyzxkWVj742NCFIYoBWRVzSUw7gog2yVcfl8ho68syefv5OF33MWI6QLp8UZSeHvunq8H9wZRECahPvPIBQnc6T56b7V+a3jzdmOodHmA= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1598.eurprd08.prod.outlook.com (10.167.211.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.18; Mon, 7 May 2018 14:16:49 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::4004:973e:4b3:ef88]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::4004:973e:4b3:ef88%18]) with mapi id 15.20.0735.018; Mon, 7 May 2018 14:16:49 +0000 From: Hannes Tschofenig To: Mohit Sethi , "core@ietf.org" Thread-Topic: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPmCfncz1IX5t6GRJaeO0C+mMHM9QAAOSUAAADDndA= Date: Mon, 7 May 2018 14:16:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1598; 7:N2Dx53wHzm7IfNYA+xsAqugPZmVNo0shnicLgA5QHyAGUOfLqwhBvTJQ4X1t/9Y7GztVc7eye/CORYnOEGqfKO+Je0t9/lGQ5xVWl7iSVJAiO6Th7VnTvnf9qNFtVm0csNg91lz4oM6hKbAUSIHf0qwZtNjhM7cswpPV+FrsnCpM1yA/YQ5Z9wj/xvac0OUFl4eUapMmC3GpKmL2TJAQCnG0VtLIo1pSL2VMi1lHI+o7O8pj0GVq8TLjEDiajIVW x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1598; x-ms-traffictypediagnostic: VI1PR0801MB1598: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(192374486261705)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0801MB1598; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1598; x-forefront-prvs: 066517B35B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(376002)(39380400002)(396003)(346002)(40434004)(53754006)(189003)(199004)(76176011)(54896002)(25786009)(110136005)(229853002)(33656002)(66066001)(7696005)(5660300001)(478600001)(2900100001)(72206003)(966005)(486006)(7736002)(476003)(186003)(345774005)(316002)(26005)(6306002)(74316002)(55016002)(3280700002)(236005)(106356001)(105586002)(9686003)(2501003)(6506007)(53546011)(5250100002)(5890100001)(2906002)(59450400001)(6436002)(3660700001)(68736007)(11346002)(99286004)(53936002)(102836004)(6246003)(8676002)(81156014)(606006)(3846002)(446003)(8936002)(97736004)(86362001)(14454004)(81166006)(790700001)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1598; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: dhfbdsqpaGRHpmeXVQu9/KJogHhDGF/R2RjfafX/N4OyOOGxdKn8VCIL6gzZP9YGNFD3+vZ2xvx5+HxZdMZsyNfmprqsZS2lkvLm8VW27PuadtSkiQcOs5afHnBZvW/ulFZEz3iVAX7PmruCRU55ZPABXaHbiOacbiNY0qFZbjFOyWsbqCafE6m0J6Tasg+j spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21121FAE34CE76841CF6DBE1FA9B0VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 46238f91-a501-4ee9-4a98-08d5b4252cac X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 46238f91-a501-4ee9-4a98-08d5b4252cac X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2018 14:16:49.8290 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1598 Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 07 May 2018 14:16:55 -0000 --_000_VI1PR0801MB21121FAE34CE76841CF6DBE1FA9B0VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was referring to this functionality: https://tools.ietf.org/html/draft-ie= tf-core-resource-directory-13#section-5.3.2 From: Mohit Sethi [mailto:mohit.m.sethi@ericsson.com] Sent: 07 May 2018 15:54 To: Hannes Tschofenig; core@ietf.org Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in R= D draft Hi Hannes, Thank you for summarizing the discussion on this important topic thus far. Could you also very briefly explain what does third-party provisioning mean= for you? --Mohit On 05/07/2018 04:50 PM, Hannes Tschofenig wrote: Hi all, I hope that all the discussion around the endpoint name / endpoint client n= ame have helped to make you think about the security implications of sendin= g an unauthenticated identifier. I would like to come to a conclusion and here is my attempt. Since we the RD document also defines the third party provisioning I would = suggest to make the endpoint name optional in the draft. I would also encourage the chairs to find out whether the third party provi= sioning is actually something in this group has gained some experience with= . Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB21121FAE34CE76841CF6DBE1FA9B0VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was referring to thi= s functionality: https://tools.ietf.org/html/draft-ietf-core-resource-directory-13#section-5= .3.2

 

 

From: Mohit Sethi [mailto:mohit.m.sethi@ericsson.com]
Sent: 07 May 2018 15:54
To: Hannes Tschofenig; core@ietf.org
Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Na= me in RD draft

 

Hi Hannes,

Thank you for summarizing the discussion on this important topic thus fa= r.

Could you also very briefly explain what does third-party provisioning m= ean for you?

--Mohit

 

On 05/07/2018 04:50 PM, Hannes Tschofenig wrote:

Hi all,

 

I hope that all the discussion around the endpoint n= ame / endpoint client name have helped to make you think about the security= implications of sending an unauthenticated identifier.

 

I would like to come to a conclusion and here is my = attempt.

 

Since we the RD document also defines the third part= y provisioning I would suggest to make the endpoint name optional in the dr= aft.

 

I would also encourage the chairs to find out whethe= r the third party provisioning is actually something in this group has gain= ed some experience with.

 

Ciao

Hannes

 

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


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

&nbs= p;

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB21121FAE34CE76841CF6DBE1FA9B0VI1PR0801MB2112_-- From nobody Mon May 7 09:09:48 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE47126DFF for ; Mon, 7 May 2018 09:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 7fEq3hjhtvKw for ; Mon, 7 May 2018 09:09:43 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (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 5BFC3120726 for ; Mon, 7 May 2018 09:09:43 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w47G9cGZ014060 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 7 May 2018 18:09:39 +0200 Received: from DEFTHW99ERIMSX.ww902.siemens.net (defthw99erimsx.ww902.siemens.net [139.22.70.134]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id w47G9LJk030559 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 7 May 2018 18:09:38 +0200 Received: from DEFTHW99ERCMSX.ww902.siemens.net (139.22.70.70) by DEFTHW99ERIMSX.ww902.siemens.net (139.22.70.134) with Microsoft SMTP Server (TLS) id 14.3.389.1; Mon, 7 May 2018 18:09:29 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.120]) by DEFTHW99ERCMSX.ww902.siemens.net ([139.22.70.70]) with mapi id 14.03.0389.001; Mon, 7 May 2018 18:09:28 +0200 From: "Kovatsch, Matthias" To: Hannes Tschofenig , Mohit Sethi , "core@ietf.org" Thread-Topic: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPmCfncz1IX5t6GRJaeO0C+mMHM9f//4EIAgAAGVoD//8jf8A== Date: Mon, 7 May 2018 16:09:28 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01F36340@DEFTHW99EL4MSX.ww902.siemens.net> References: In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.17] Content-Type: multipart/alternative; boundary="_000_4EBB3DDD0FBF694CA2A87838DF129B3C01F36340DEFTHW99EL4MSXw_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 07 May 2018 16:09:46 -0000 --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01F36340DEFTHW99EL4MSXw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Hannes, dear list To my knowledge, third-party provisioning functionality is in particular us= ed for lighting systems; maybe Peter can comment on this. I am aware of a f= ew business units that would also want to have this functionality in the RD= . Furthermore, I have use cases for Web Things that provide a REST interfac= e, but do not implement RD registration; with the third-party provisioning = they can become part of CoRE environments as well. Making the Endpoint Client Name optional is a good solution in my opinion, = when it is clearly defined which security protocol identifiers shall be tak= en as Endpoint Client Name. I am not even sure if I understand the current = "mostly mandatory" correctly). Overall, it would be good to describe the us= age of security context well, as there are different possibilities (cf. cer= tificate vs Raw Public Key vs PSK). Furthermore, the draft is a bit too fuzzy about the authorization, in parti= cular for registration. It feels obvious that also third-party provisioning= needs to be authorized to use the Endpoint Client Name to be registered, b= ut hearing Hannes's concerns, it probably should be stated concretely. The = role of Domain is also rather implicit here; to my understanding, there can= be duplicate Endpoint Client Names as long as they have different Domains. Kind regards, Matthias Von: core [mailto:core-bounces@ietf.org] Im Auftrag von Hannes Tschofenig Gesendet: Montag, 7. Mai 2018 16:17 An: Mohit Sethi; core@ietf.org Betreff: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in R= D draft I was referring to this functionality: https://tools.ietf.org/html/draft-ie= tf-core-resource-directory-13#section-5..3.2 From: Mohit Sethi [mailto:mohit.m.sethi@ericsson.com] Sent: 07 May 2018 15:54 To: Hannes Tschofenig; core@ietf.org Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in R= D draft Hi Hannes, Thank you for summarizing the discussion on this important topic thus far. Could you also very briefly explain what does third-party provisioning mean= for you? --Mohit On 05/07/2018 04:50 PM, Hannes Tschofenig wrote: Hi all, I hope that all the discussion around the endpoint name / endpoint client n= ame have helped to make you think about the security implications of sendin= g an unauthenticated identifier. I would like to come to a conclusion and here is my attempt. Since we the RD document also defines the third party provisioning I would = suggest to make the endpoint name optional in the draft. I would also encourage the chairs to find out whether the third party provi= sioning is actually something in this group has gained some experience with= . Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_4EBB3DDD0FBF694CA2A87838DF129B3C01F36340DEFTHW99EL4MSXw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Hannes,

dear list=

 

To my knowledge, third-part= y provisioning functionality is in particular used for lighting systems; ma= ybe Peter can comment on this. I am aware of a few business units that would also want to have this functionality in the RD. Furthermo= re, I have use cases for Web Things that provide a REST interface, but do n= ot implement RD registration; with the third-party provisioning they can be= come part of CoRE environments as well.

  

Making the Endpoint Client Name optional is a good solution in=
 my opinion, when it is clearly defined which security protocol identifiers=
 shall be taken as Endpoint Client Name. I am not even sure if I understand=
 the current “mostly mandatory” correctly). Overall, it =
would be good to describe the usage of security context well, as there are =
different possibilities (cf. certificate vs Raw Public Key vs PSK).

 

Furthermore, the draft is a= bit too fuzzy about the authorization, in particular for registration. It = feels obvious that also third-party provisioning needs to be authorized to use the Endpoint Client Name to be registered, but hearin= g Hannes’s concerns, it probably should be stated concretely. The rol= e of Domain is also rather implicit here; to my understanding, there can be= duplicate Endpoint Client Names as long as they have different Domains.

 

Kind regards,

Matthias<= /p>

 

 

Von: core [mailto:core-bounces@ietf.org] Im Auftrag von Hannes Tschofenig
Gesendet: Montag, 7.= Mai 2018 16:17
An: Mohit Sethi; core@ietf.org
Betreff: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Na= me in RD draft

 

I was r= eferring to this functionality: https://tools.ietf.org/html/draft-ietf-core-resource-directory-13#section-5= ..3.2

&n= bsp;

&n= bsp;

From: Mohit Sethi [mailto:mohit.m.= sethi@ericsson.com]
Sent: 07 May 2018 15:54
To: Hannes Tschofenig; core@ietf.or= g
Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Na= me in RD draft

 

Hi Hannes,

Thank you for summarizing the discussion on this im= portant topic thus far.

Could you also very briefly explain what does third= -party provisioning mean for you?

--Mohit

 

On 05/07/2018 04:50 PM, Hannes = Tschofenig wrote:

Hi all,

 

I hope that all the discussion = around the endpoint name / endpoint client name have helped to make you thi= nk about the security implications of sending an unauthenticated identifier= .

 

I would like to come to a concl= usion and here is my attempt.

 

Since we the RD document also d= efines the third party provisioning I would suggest to make the endpoint na= me optional in the draft.

 

I would also encourage the chai= rs to find out whether the third party provisioning is actually something i= n this group has gained some experience with.

 

Ciao

Hannes

 

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

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

 

IMPO= RTANT NOTICE: The contents of this email and any attachments are confidenti= al and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the co= ntents to any other person, use it for any purpose, or store or copy the in= formation in any medium. Thank you.

--_000_4EBB3DDD0FBF694CA2A87838DF129B3C01F36340DEFTHW99EL4MSXw_-- From nobody Mon May 7 10:45:25 2018 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 2D933127775; Mon, 7 May 2018 10:45:24 -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.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152571512412.1291.13614070644338014583@ietfa.amsl.com> Date: Mon, 07 May 2018 10:45:24 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-15.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, 07 May 2018 17:45:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Sensor Measurement Lists (SenML) Authors : Cullen Jennings Zach Shelby Jari Arkko Ari Keranen Carsten Bormann Filename : draft-ietf-core-senml-15.txt Pages : 52 Date : 2018-05-07 Abstract: This specification defines a format 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 one of these media types 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-15 https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-15 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 May 7 10:52:48 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AC4127076 for ; Mon, 7 May 2018 10:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT4rB95BLCc5 for ; Mon, 7 May 2018 10:52:40 -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 571CA127869 for ; Mon, 7 May 2018 10:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525715556; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WwNTMDrA0EByP8U06PshzIixjngHI9muaWdVSIYFxdY=; b=R4oFGlSJMmYG/4WfJCVnMcuO6fys9TrDg0msY2ZhqqhGQJUlmcHjNRTEoNR6RGL3 /ELggMEHAdicMlF/ToTHDeR/mmTi3dNEa9EvTTLXVoFSQURZ9pfbXRTaHOagmJBs QylUiYiAt0r3I31SnN/k6FunHUe2364uvwnytbZaG3Y=; X-AuditID: c1b4fb25-5c3ff700000064d0-69-5af09263aeed Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A9.E8.25808.36290FA5; Mon, 7 May 2018 19:52:36 +0200 (CEST) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSHC017.ericsson.se (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 7 May 2018 19:52:35 +0200 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 7 May 2018 19:52:35 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Mon, 7 May 2018 19:52:34 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Ben Campbell CC: The IESG , "draft-ietf-core-senml@ietf.org" , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core-chairs@ietf.org" , core Thread-Topic: Ben Campbell's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) Thread-Index: AQHT1UHn+Jopg1j5+EC0sj/ycG3/7aQkjFAA Date: Mon, 7 May 2018 17:52:34 +0000 Message-ID: References: <152385571314.20985.5160681583375127961.idtracker@ietfa.amsl.com> In-Reply-To: <152385571314.20985.5160681583375127961.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="utf-8" Content-ID: <346B1C205953C84EBBD4FC885AC8C430@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUyM2K7q27KpA9RBlPfM1nM7zzNbrFt4wU2 i31v1zNb/Hy3hNlixp+JzA6sHkuW/GTymLXzCUsAUxSXTUpqTmZZapG+XQJXRlv7JuaCGRoV d8+9Z2xgnKLexcjJISFgIrHq5AmWLkYuDiGBI4wSp049ZoRwNjNKrJm9nA2kSkjgK6NE+3So qqWMEg+OvmIFSbAJ2Eo8ad0HZosIKEk8b94KVsQs8JJR4vXDXkaQhLBArMS8E3PYIIriJL4t ncoIYRtJXHixgB3EZhFQkXi+/RALiM0rYC/x7u9BRojNvhL35p4Hi3MK+Ems2L4RLM4oICbx /dQaJhCbWUBc4taT+UwQ/whILNlznhnCFpV4+fgfK4StJLH32HWgORxA9ZoS63fpQ7RaSyzo f8AOYStKTOl+yA5xgqDEyZlPWCBOUJW4+u8V4wRGyVlIts1CmDQLyaRZSCbNQjJpASPrKkbR 4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzA+D245bfqDsbLbxwPMQpwMCrx8FblfIgSYk0sK67M PcQowcGsJMLLpgwU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzvvQfHOUkEB6YklqdmpqQWoRTJaJ g1OqgZEv++F55dyCN3lHKruvnHkq+4xNrmJHW7FRY4fe8g0K7MFF3eFJK3btNWN4mtqp+lBt 0vSbUgv9BNtqOE4E2MgErP5r6P5X8blQ4f8i9ZeT93k5cs8uvZloz3639MvjqmdRCnzXv4oY uX5s5fyyz6yAM+WiUfRplW8y2seOtBSUNT9Lu+vPoMRSnJFoqMVcVJwIAPMTncjbAgAA Archived-At: Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 07 May 2018 17:52:42 -0000 VGhhbmsgeW91IGZvciB0aGUgcmV2aWV3IEJlbiENCg0KV2UgaGF2ZSBub3cgc3VibWl0dGVkIGEg bmV3IHJldmlzaW9uIG9mIHRoZSBTZW5NTCBkcmFmdCB0aGF0IGFkZHJlc3NlcyBhbGwgdGhlIElF U0cgcmV2aWV3IGNvbW1lbnRzOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtY29yZS1zZW5tbC0xNQ0KDQpGb3IgYW5zd2VycyB0byB5b3VyIHJldmlldyBjb21tZW50cywg cGxlYXNlIHNlZSBiZWxvdy4NCg0KDQpUaGFua3MsDQpBcmkNCg0KPiBPbiAxNiBBcHIgMjAxOCwg YXQgOC4xNSwgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+IHdyb3RlOg0KPiANCj4gQmVu IENhbXBiZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0K PiBkcmFmdC1pZXRmLWNvcmUtc2VubWwtMTQ6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9uZGlu ZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0K PiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwg ZnJlZSB0byBjdXQgdGhpcw0KPiBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4g DQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1l bnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElF U0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50 LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0K PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvcmUtc2VubWwv DQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiANCj4gSG9wZWZ1bGx5IHRoaXMgaXMgZWFzeSB0byBhZGRyZXNzOg0KPiANCj4gwqc0Ljcg IHRhbGtzIGFib3V0IGhvdyBTZW5NTCBjYW4gYWxzbyBiZSB1c2VkIHRvIGNvbmZpZ3VyZSBwYXJh bWV0ZXJzIGFuZA0KPiBjb250cm9sbGluZyBhY3R1YXRvcnMuIFRoYXQgY2FwYWJpbGl0eSBoYXMg c29tZSByYXRoZXIgc2lnbmlmaWNhbnQgc2VjdXJpdHkNCj4gaW1wbGljYXRpb25zLCBidXQgSSBm YWlsZWQgdG8gZmluZCBtZW50aW9uIG9mIGl0IGluIHRoZSBzZWN1cml0eQ0KPiBjb25zaWRlcmF0 aW9ucy4gVGhhdCBuZWVkcyB0byBiZSBleHBsaWNpdGx5IGRpc2N1c3NlZC4NCg0KTm93IFNlY3Rp b24gMTMgbWVudGlvbnMgYWN0dWF0b3IgdXNlIGV4cGxpY2l0bHk6IA0KDQogIFdoZW4gU2VuTUwg aXMgdXNlZCBmb3IgY29uZmlndXJhdGlvbiBvcg0KICBhY3R1YXRpb24sIGl0IGNhbiBiZSB1c2Vk IHRvIGNoYW5nZSB0aGUgc3RhdGUgb2Ygc3lzdGVtcyBhbmQgYWxzbw0KICBpbXBhY3QgdGhlIHBo eXNpY2FsIHdvcmxkLCBlLmcuLCBieSB0dXJuaW5nIG9mZiBhIGhlYXRlciBvciBvcGVuaW5nIGEN CiAgbG9jay4NCg0KICBUaGUgU2VuTUwgZm9ybWF0cyBhbG9uZSBkbyBub3QgcHJvdmlkZSBhbnkg c2VjdXJpdHkgYW5kIGluc3RlYWQgcmVseQ0KICBvbiB0aGUgcHJvdG9jb2wgdGhhdCBjYXJyaWVz IHRoZW0gdG8gcHJvdmlkZSBzZWN1cml0eS4gIEFwcGxpY2F0aW9ucw0KICB1c2luZyBTZW5NTCBu ZWVkIHRvIGxvb2sgYXQgdGhlIG92ZXJhbGwgY29udGV4dCBvZiBob3cgdGhlc2UgZm9ybWF0cw0K ICB3aWxsIGJlIHVzZWQgdG8gZGVjaWRlIGlmIHRoZSBzZWN1cml0eSBpcyBhZGVxdWF0ZS4gIElu IHBhcnRpY3VsYXINCiAgZm9yIHNlbnNpdGl2ZSBzZW5zb3IgZGF0YSBhbmQgYWN0dWF0aW9uIHVz ZSBpdCBpcyBpbXBvcnRhbnQgdG8gZW5zdXJlDQogIHRoYXQgcHJvcGVyIHNlY3VyaXR5IG1lY2hh bmltcyBhcmUgdXNlZC4NCg0KDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiANCj4gU3Vic3RhbnRpdmU6DQo+IA0KPiDCpzQuNDogIklmIHRoaXMgdmFsdWUg aXMgYSB2ZXJzaW9uIG51bWJlciBsYXJnZXIgdGhhbiB0aGUgdmVyc2lvbiB3aGljaCB0aGUNCj4g IHN5c3RlbSB1bmRlcnN0YW5kcywgdGhlIHN5c3RlbSBTSE9VTEQgTk9UIHVzZSB0aGlzIG9iamVj dC4iDQo+IA0KPiBXaHkgbm90IE1VU1QgTk9UPyBBcmUgdGhlcmUgc2l0dWF0aW9ucyB3aGVyZSBh biBpbXBsZW1lbnRhdGlvbiBtaWdodCByZWFzb25hYmx5DQo+IHVzZSBhbiBvYmplY3Qgd2l0aCBh IGhpZ2hlciB2ZXJzaW9uIG51bWJlciB0aGFuIHRoZSBpbXBsZW1lbnRhdGlvbiB1bmRlcnN0YW5k cz8NCg0KR29vZCBwb2ludC4gQ2hhbmdlZCB0byAiTVVTVCBOT1QiLg0KDQo+IEVkaXRvcmlhbC9O aXRzOg0KPiANCj4gVGhlIHRpdGxlIGlzIG1pc2xlYWRpbmcuIEl0IG1ha2VzIGl0IHNvdW5kIGxp a2UgdGhlIGRvY3VtZW50IGlzIGp1c3QNCj4gcmVnaXN0ZXJpbmcgbWVkaWEgdHlwZXM7IGluIGZh Y3QgaXQgZGVmaW5lcyBTZW5NTC4NCg0KT3RoZXIgcmV2aWV3ZXJzIG1lbnRpb25lZCB0aGUgc2Ft ZS4gQ2hhbmdlZCB0aGlzIHRvICJTZW5zb3IgTWVhc3VyZW1lbnQgTGlzdHMgKFNlbk1MKSINCg0K PiDCpzEsIGZpcnN0IHBhcmFncmFwaDogIlRoaXMgZm9ybWF0IHdhcyBkZWZpbmVkLi4uIjogVGhl IGFudGVjZWRlbnQgb2YgInRoaXMiIGlzDQo+IHVuY2xlYXIsIHNpbmNlIHRoZSBmYWN0IHRoZSBk b2N1bWVudCBkZWZpbmVzIFNlbk1MIGhhcyBub3QgeWV0IGJlZW4gbWVudGlvbmVkLg0KDQpDaGFu Z2VkIHRvICJUaGUgU2VuTUwgZm9ybWF0IGlzIGRlZmluZWQuLi4iDQoNCj4gwqc0LjMsIHRhYmxl IDE6IFdoYXQgZG8gdGhlIGFzdGVyaXNrcyBtZWFuPw0KDQpUaGUgZmlyc3Qgc2VudGVuY2UgYWZ0 ZXIgdGFibGUgd2FzIHN1cHBvc2VkIHRvIGhhdmUgYXN0ZXJpc2sgdG8gaW5kaWNhdGUgZXhwbGFu YXRpb24uIE5vdyBpdCBzYXlzOg0KDQogICgqKSBEYXRhIFZhbHVlIGlzIGJhc2U2NCBlbmNvZGVk IHN0cmluZyB3aXRoIFVSTCBzYWZlIGFscGhhYmV0IGFzDQogIGRlZmluZWQgaW4gU2VjdGlvbiA1 IG9mIFtSRkM0NjQ4XSwgd2l0aCBwYWRkaW5nIG9taXR0ZWQuDQoNCj4gwqc1LjEuMiwgcGFyYWdy YXBoIHN0YXJ0aW5nIHdpdGggIk5vdGUgdGhhdC4uLiI6IEknbSBzdXJwcmlzZWQgdG8gZmluZCBu b3JtYXRpdmUNCj4gcmVxdWlyZW1lbnRzIGJ1cmllZCBpbiBhIG5vdGUgaW4gYW4gZXhhbXBsZS4N Cg0KV2UgbW92ZWQgdGhlIFNlbnNNTCBub3JtYXRpdmUgdGV4dCBub3cgdG8gYSBuZXcgc2VjdGlv biAoNC43KS4NCg0KPiDCpzEwLCBmaXJzdCBwYXJhZ3JhcGg6ICIgdGhlIGFuIGludGVncmF0ZWQg c3VtLi4uIjogY29tcGV0aW5nIGFydGljbGVzLg0KDQpGaXhlZC4NCg0KPiDCpzE0OiAiU2Vuc29y IGRhdGEgY2FuIHJhbmdlIGZyb20gaW5mb3JtYXRpb24gd2l0aCBhbG1vc3Qgbm8gc2VjdXJpdHkN Cj4gIGNvbnNpZGVyYXRpb25zLi4uIg0KPiBzL3NlY3VyaXR5L3ByaXZhY3kNCg0KRml4ZWQu From nobody Mon May 7 10:56:08 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5BA128954 for ; Mon, 7 May 2018 10:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSy_Hdb2vSQM for ; Mon, 7 May 2018 10:56:02 -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 13F19127076 for ; Mon, 7 May 2018 10:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525715760; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=X4QjrkmCHJ8h/qeuMf0ccKg/W8/CdfFUDs5RvOO97cM=; b=IUw1S5L56jjxJygboH82VeKmmbdxJ4qT0BQPwzVW/IymhzE4Y9bcJyLeOgVPr9nV J7M7irpmSNS0GCIbRfloJhRsVB7ACNpsJ+cD2sTuzhg1lfB1+5TYQAhiIGxzeo26 Gllt5Wl35C21R1EcBjmgJ/1weJUOvCY37IHkUWPW5T8=; X-AuditID: c1b4fb30-4c8039c000007681-e9-5af09330c3e7 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 53.7A.30337.03390FA5; Mon, 7 May 2018 19:56:00 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSHC009.ericsson.se (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 7 May 2018 19:55:59 +0200 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 7 May 2018 19:55:59 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Mon, 7 May 2018 19:55:59 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Benjamin Kaduk CC: The IESG , "draft-ietf-core-senml@ietf.org" , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core-chairs@ietf.org" , core Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) Thread-Index: AQHT14bG3vAIeJGLoECcXBuH3Y6fJ6QkiLkA Date: Mon, 7 May 2018 17:55:59 +0000 Message-ID: <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> In-Reply-To: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="utf-8" Content-ID: <80FE84D00784EB4E957480BC7E5BE721@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUyM2K7rq7B5A9RBj/+S1ts23iBzWLf2/XM Fj/fLWG2mPFnIrPF8o0zmRxYPZYs+cnk0XTmKHMAUxSXTUpqTmZZapG+XQJXxu17XcwFLaEV b+88YmxgfBPUxcjJISFgItG/bAo7iC0kcIRRYtf/xC5GLiB7M6PEk6tbWCGcr4wSUxZ0MEI4 SxkldjasBmthE7CVeNK6jxXEFhFQkjjXcBasiFngJaPE64e9jCAJYYF4ib33GtkhihIkru2a zgJhG0ncutEL1swioCKxfnUbG4jNK2AvMXPDJEaIm3wklq95D1bDKeArsX7pKjCbUUBM4vup NUwgNrOAuMStJ/OZIP4RkFiy5zwzhC0q8fLxP1YIW0li77HrQHs5gOo1Jdbv0odotZaY2nmW EcJWlJjS/ZAd4gRBiZMzn7BAnKAqcfXfK8YJjJKzkGybhTBpFpJJs5BMmoVk0gJG1lWMosWp xUm56UZGeqlFmcnFxfl5enmpJZsYgfF7cMtvgx2ML587HmIU4GBU4uEtzPkQJcSaWFZcmXuI UYKDWUmEl00ZKMSbklhZlVqUH19UmpNafIhRmoNFSZzXwm9zlJBAemJJanZqakFqEUyWiYNT qoFR++zRDa76kSY3PgTk+844Jiz9qFWi+r+lV6TnR538v5/enf9Uo9VQX/L2ZMQjIWnTKxvC Npsbt3x66/xm/qLdRVfCVvZsS+nUXpd//pFHD6NOhKD/g5vB/qwiyjfr4md8+MR6df3Ubwve FcyWYbCY/eBBKLPHlKuCHBsuFfwXrRBzL5L78eanEktxRqKhFnNRcSIA0tQy0dsCAAA= Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 07 May 2018 17:56:06 -0000 VGhhbmsgeW91IGZvciB0aGUgcmV2aWV3IEJlbmphbWluIQ0KDQpXZSBoYXZlIG5vdyBzdWJtaXR0 ZWQgYSBuZXcgcmV2aXNpb24gb2YgdGhlIFNlbk1MIGRyYWZ0IHRoYXQgYWRkcmVzc2VzIGFsbCB0 aGUgSUVTRyByZXZpZXcgY29tbWVudHM6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1jb3JlLXNlbm1sLTE1DQoNCkZvciBhbnN3ZXJzIHRvIHlvdXIgcmV2aWV3IGNvbW1l bnRzLCBwbGVhc2Ugc2VlIGJlbG93Lg0KDQoNClRoYW5rcywNCkFyaQ0KDQo+IE9uIDE5IEFwciAy MDE4LCBhdCA1LjMzLCBCZW5qYW1pbiBLYWR1ayA8a2FkdWtATUlULkVEVT4gd3JvdGU6DQo+IA0K PiBCZW5qYW1pbiBLYWR1ayBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlv biBmb3INCj4gZHJhZnQtaWV0Zi1jb3JlLXNlbm1sLTE0OiBEaXNjdXNzDQo+IA0KPiBXaGVuIHJl c3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0 byBhbGwNCj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMu IChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZl ci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cv c3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBk b2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQg aGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3Jl LXNlbm1sLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gDQo+IEkgYWdyZWUgd2l0aCBCZW4ncyBESVNDVVNTLg0KDQpUaGlzIHdhcyBh ZGRyZXNzZWQgaW4gdGhlIHVwZGF0ZWQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGV4dDoNCmh0 dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL3Nlbm1sLXNwZWMvcHVsbC8xMDYvY29tbWl0cy9iOTEx MDkwY2UyZDEyZDM5NGQyNDM2NThmNjM2NTIyYmIzZGNjMzM1DQoNCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtc2VubWwtMTUjc2VjdGlvbi0xMw0KDQo+IEFkZGl0 aW9uYWxseSwgSSBoYXZlIHNlcmlvdXMgcmVzZXJ2YXRpb25zIGFib3V0IGludHJvZHVjaW5nIHRo ZQ0KPiBjb25jZXB0IG9mICJiYXNlIGZpZWxkcyIgdGhhdCBhcHBseSB0byBzdWJzZXF1ZW50IGFy cmF5IGVsZW1uZXRzDQo+IHVubGVzcyBvdmVycmlkZGVuLiAgSXQgc2VlbXMgdG8gdmlvbGF0ZSBh biBhYnN0cmFjdGlvbiBiYXJyaWVyIGZvcg0KPiBhdCBsZWFzdCBzb21lIG9mIHRoZSBzZXJpYWxp emF0aW9uIGZvcm1hdHMsIGFuZCBwcmV2ZW50cyBzbmlwcGV0cw0KPiBmcm9tIGJlaW5nIGNvbXBv c2FibGUgYW5kIGNvbW11dGFibGUgYWJzZW50IHRoZQ0KPiByZXNvbHV0aW9uL25vcm1hbGl6YXRp b24gcHJvY2Vzcy4gIEl0IGRvZXMgbm90IHNlZW0gbGlrZSB0aGUgbWFya3VwDQo+IGxhbmd1YWdl IGFuZCB0aGUgZG9jdW1lbnQgY29udGFpbiBzdWZmaWVudCBzYWZlZ3VhcmRzIGFnYWluc3QgbWlz dXNlDQo+IHRvIHByZXZlbnQgc2VjdXJpdHkgaG9sZXMgKGJvdGggc2Vuc29yIGRhdGEgYW5kIGNv bW1hbmRzIGNvdWxkIGJlDQo+IG1pc2ludGVycHJldGVkKS4gIEl0IHNlZW1zIHRoYXQgc29tZSBz dWJzdGFudGlhbGx5IGV4cGFuZGVkIHRleHQNCj4gc2hvdWxkIGJlIGFkZGVkIG9uIHRoZSBoYXph cmRzIG9mIHRoZSBub24tcmVzb2x2ZWQgZm9ybWF0IGFuZCBnaXZpbmcNCj4gZ3VpZGFuY2Ugb24g d2hlbiByZXNvbHV0aW9uL25vcm1hbGl6YXRpb24gbXVzdCBiZSBwZXJmb3JtZWQgaW4gb3JkZXIN Cj4gdG8gYXZvaWQgY29ycmVjdG5lc3MgYW5kIHNlY3VyaXR5IGlzc3Vlcy4NCg0KVGhlIGJhc2Ug dmFsdWVzIGZlYXR1cmUgaXMgc29tZXRoaW5nIHRoYXQgdGhlIFdHIGRlY2lkZWQgaXMgaW1wb3J0 YW50IHRvIGhhdmUuIFdlIGFkZGVkIG5vdyB0ZXh0IGFib3V0IHRoZSBzZWN1cml0eSBpbXBsaWNh dGlvbnMgYW5kIHJlbWVkaWVzLCBhbHNvIHRha2luZyBpbnRvIGFjY291bnQgQWxleGV5J3MgZm9s bG93LXVwcyBpbiB0aGlzIHRocmVhZDogaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvc2VubWwt c3BlYy9wdWxsLzEwOS9maWxlcw0KDQo+IFRoZXJlIGFsc28gc2VlbSB0byBiZSBzaXplYWJsZSBy aXNrcyBhc3NvY2lhdGVkIHdpdGggdGhlIHNlbWFudGljcw0KPiBmb3IgdGltZSB2YWx1ZXMuICBJ biBwYXJ0aWN1bGFyLCBib3RoIHdpdGggdGhlIHVzZSBvZiBhbg0KPiBpbXBsaWNpdC0ibm93LWlz aCIsIGFuZCB3aXRoIHBvc2l0aXZlIGFuZCBuZWdhdGl2ZSB2YWx1ZXMgYmVpbmcNCj4gaW50ZXJw cmV0ZWQgd2l0aCByZXNwZWN0IHRvIGEgZGlmZmVyZW50IGFic29sdXRlIHRpbWUgYmFzZS4gIChU aGUNCj4gaW52b2x2ZW1lbnQgb2YgYmFzZSB0aW1lIGlzIGEgZnVydGhlciBjb21wbGljYXRpb24g LS0gSSBkbyBub3QNCj4gcmVtZW1iZXIgYW55IGRpc2N1c3Npb24gb2YgdGhlIGludGVyYWN0aW9u IG9mIGEgKHBvc2l0aXZlKSBiYXNlIHRpbWUNCj4gYW5kIGEgbmVnYXRpdmUgcmVndWxhciB0aW1l LCBmb3IgZXhhbXBsZS4gIEkgYWxzbyBkbyBub3QgcmVtZW1iZXINCj4gYW55IGRpc2N1c3Npb24g b2YgaG93IHRoZSAibm93LWlzaCIgc2VtYW50aWNzIG1ha2UgaXQgYWN0aXZlbHkNCj4gaGFybWZ1 bCB0byBkbyB0aGluZ3MgbGlrZSBzdG9yZS1hbmQtZm9yd2FyZCBvciBhcmNoaXZlIFNlbk1MIGRh dGENCj4gKGFnYWluLCBhYnNlbnQgbm9ybWFsaXphdGlvbiksIG9yIHdoYXQgc29ydCBvZiBncmFu dWxhcml0eSB0aGUNCj4gIm5vdy1pc2giIHNlbWFudGljcyBhcmUgZXhwZWN0ZWQgdG8gYWRoZXJl IHRvLiAgKElzICJ5ZXN0ZXJkYXkiDQo+IHN0aWxsIGNvbnNpZGVyZWQgInJvdWdobHkgbm93Ij8p ICBJIHVuZGVyc3RhbmQgdGhlIGRlc2lyZSBmb3IgdGhpcw0KPiBzb3J0IG9mIHNlbWFudGljcywg YnV0IHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gc2VlbXMgdG8gbGVhdmUgbWFueQ0KPiBwb3Rl bnRpYWwgcHJvYmxlbXMgZXhwb3NlZC4NCg0KV2UgY2xhcmlmaWVkIHRoZSAibm93IiBpc3N1ZSAo YWxzbyB0byBhZGRyZXNzIG90aGVyIGNvbW1lbnRzIG9uIHRoaXMgdG9waWMpLiBUaGUgbmV3IHRl eHQgaW4gc2VjdGlvbiA0LjUuMyBzYXlzOg0KDQogIE9idmlvdXNseSwgIm5vdyItcmVmZXJlbmNl ZCBTZW5NTCByZWNvcmRzIGFyZSBvbmx5IHVzZWZ1bCB3aXRoaW4gYQ0KICBzcGVjaWZpYyBjb21t dW5pY2F0aW9uIGNvbnRleHQgKGUuZy4sIGJhc2VkIG9uIGluZm9ybWF0aW9uIG9uIHdoZW4NCiAg dGhlIFNlbk1MIHBhY2ssIG9yIGEgc3BlY2lmaWMgcmVjb3JkIGluIGEgU2Vuc01MIHN0cmVhbSwg d2FzIHNlbnQpIG9yDQogIHRvZ2V0aGVyIHdpdGggc29tZSBvdGhlciBjb250ZXh0IGluZm9ybWF0 aW9uIHRoYXQgY2FuIGJlIHVzZWQgZm9yDQogIGRlcml2aW5nIGEgbWVhbmluZyBvZiAibm93Ijsg dGhlIGV4cGVjdGF0aW9uIGZvciBhbnkgYXJjaGl2YWwgdXNlIGlzDQogIHRoYXQgdGhleSB3aWxs IGJlIHByb2Nlc3NlZCBpbnRvIFVUQy1yZWZlcmVuY2VkIHJlY29yZHMgYmVmb3JlIHRoYXQNCiAg Y29udGV4dCB3b3VsZCBjZWFzZSB0byBiZSBhdmFpbGFibGUuICBUaGlzIHNwZWNpZmljYXRpb24g ZGVsaWJlcmF0ZWx5DQogIGxlYXZlcyB0aGUgYWNjdXJhY3kgb2YgIm5vdyIgdmVyeSB2YWd1ZSBh cyBpdCBpcyBkZXRlcm1pbmVkIGJ5IHRoZQ0KICBvdmVyYWxsIHN5c3RlbXMgdGhhdCB1c2UgU2Vu TUwuICBJbiBhIHN5c3RlbSB3aGVyZSBhIHNlbnNvciB3aXRob3V0DQogIHdhbGwtY2xvY2sgdGlt ZSBzZW5kcyBhIFNlbk1MIHJlY29yZCB3aXRoIGEgIm5vdyItcmVmZXJlbmNlZCB0aW1lDQogIG92 ZXIgYSBoaWdoIHNwZWVkIFJTIDQ4NSBsaW5rIHRvIGFuIGVtYmVkZGVkIHN5c3RlbSB3aXRoIGFj Y3VyYXRlDQogIHRpbWUgdGhhdCByZXNvbHZlcyAibm93IiBiYXNlZCBvbiB0aGUgdGltZSBvZiBy ZWNlcHRpb24sIHRoZQ0KICByZXN1bHRpbmcgdGltZSB1bmNlcnRhaW50eSBjb3VsZCBiZSB3aXRo aW4gMSBtcy4gIEF0IHRoZSBvdGhlcg0KICBleHRyZW1lLCBhIGRlcGxveW1lbnQgdGhhdCBzZW5k cyBTZW5NTCB3aW5kIHNwZWVkIHJlYWRpbmdzIG92ZXIgYSBMRU8NCiAgc2F0ZWxsaXRlIGxpbmsg ZnJvbSBhIG1vdW50YWluIHZhbGxleSBtaWdodCBoYXZlIHJlc3VsdGluZyByZWNlcHRpb24NCiAg dGltZSB2YWx1ZXMgdGhhdCBhcmUgZWFzaWx5IGEgZG96ZW4gbWludXRlcyBvZmYgdGhlIGFjdHVh bCB0aW1lIG9mDQogIHRoZSBzZW5zb3IgcmVhZGluZywgd2l0aCB0aGUgdGltZSB1bmNlcnRhaW50 eSBkZXBlbmRpbmcgb24gc2F0ZWxsaXRlDQogIGxvY2F0aW9ucyBhbmQgY29uZGl0aW9ucy4NCg0K DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gU2Vj dGlvbiA0LjQNCj4gDQo+IEp1c3QgIkNvbnNpZGVyYXRpb25zIiBpcyBhbiB1bnVzdWFsIHN1Ympl Y3QgdGl0bGUuDQoNCldlIHJlLXN0cnVjdHJ1dGVkIHRoaXMgcGFydCBhIGJpdCBhbmQgYWRkZWQg c3ViLXRpdGxlcyB0byB0aGlzIHNlY3Rpb24gYW5kIHNwbGl0IGl0IGludG8gIkV4dGVuc2liaWxp dHkiICg0LjQpIGFuZCAiUmVjb3JkcyBhbmQgVGhlaXIgRmllbGRzICg0LjUpLiBTaG91bGQgYmUg bW9yZSBjbGVhciAmIHVzdWFsIG5vdy4NCg0KPiBIYXZpbmcgbm8gVW5pdCBhbmQgbm8gQmFzZSBV bml0IGlzIGFsbG93ZWQsIGJ1dCB5b3UgZG9uJ3Qgc2F5IHdoYXQNCj4gdGhlIHNlbWFudGljcyBh cmUgaW4gdGhhdCBjYXNlIChwcmVzdW1hYmx5IGp1c3QgYSBkaW1lbnNpb25sZXNzDQo+IGNvdW50 ZXIgZm9yIGludGVnZXJzLCB3aXRoIHVuaXRzIG5vdCByZWFsbHkgYmVpbmcgYXBwbGljYWJsZSB0 bw0KPiBub24tbnVtZXJpYyB0eXBlcykuICBJbnRlcmVzdGluZ2x5LCBTZWN0aW9uIDUuMS43IGRl ZW1zIGl0IGZpdCB0bw0KPiB1c2UgIi8iIGZvciB0aGUgdW5pdCBmb3IgYSBib29sZWFuIHZhbHVl LCBldmVuIHRob3VnaCAiLyIgaXMNCj4gc3VwcG9zZWQgdG8gYmUgYSAoY29udGludW91cy9mbG9h dGluZy1wb2ludCkgcmF0aW8uDQoNClRoZSBhcHBsaWNhdGlvbiB1c2luZyBTZW5NTCBtYXkgaGF2 ZSBhZGRpdGlvbmFsIHdheXMgdG8gY29udmV5IHRoZSB1bml0IGluZm9ybWF0aW9uICh3aGVyZSBu ZWVkZWQpLCBhcyBpcyB0aGUgY2FzZSB3aXRoIGUuZy4sIEx3TTJNIHVzZSBvZiBTZW5NTC4gV2Ug Y2xhcmlmaWVkIHRoaXMgaW4gdGhlIHRleHQgbm93Og0KDQogIElmIHRoZSBSZWNvcmQgaGFzIG5v IFVuaXQsIHRoZSBCYXNlIFVuaXQgaXMgdXNlZCBhcyB0aGUgVW5pdC4gSGF2aW5nDQogIG5vIFVu aXQgYW5kIG5vIEJhc2UgVW5pdCBpcyBhbGxvd2VkOyBhbnkgaW5mb3JtYXRpb24gdGhhdCBtYXkg YmUNCiAgcmVxdWlyZWQgYWJvdXQgdW5pdHMgYXBwbGljYWJsZSB0byB0aGUgdmFsdWUgdGhlbiBu ZWVkcyB0byBiZSBwcm92aWRlZCANCiAgYnkgdGhlIGFwcGxpY2F0aW9uIGNvbnRleHQuDQoNCj4g U2VjdGlvbiA0LjUNCj4gDQo+IEp1c3QgdG8gZG91YmxlLWNoZWNrOiB5b3UgcmVhbGx5IGRvIHdh bnQgdG8gcHJpdmlsZWdlIHRoaXMNCj4gc3BlY2lmaWNhdGlvbidzIHZlcnNpb24gZm9yIGV0ZXJu aXR5LCBmb3IgdGhlIHB1cnBvc2Ugb2YgYmVpbmcNCj4gb21pdHRlZCBmcm9tIHJlc29sdmVkIHJl Y29yZHM/DQoNClllcy4NCg0KPiBTZWN0aW9uIDEyLjEgaXMgdGhlcmUgbm90IHNvbWUgb3RoZXIg dW5pdHMgcmVnaXN0cnkgd2UgY2FuIHVzZT8gIEkNCj4gZmVhciBiZWdldHRpbmcgaHR0cHM6Ly94 a2NkLmNvbS85MjcvICAuICBBbHNvLCBob3cgaXMvc2hvdWxkIHRoZQ0KPiB0YWJsZSBiZSBzb3J0 ZWQ/DQoNCldlIGFyZSBub3QgdHJ5aW5nIHRvIHJlcGxhY2UgYWxsIG90aGVyIHN1Y2ggcmVnaXN0 cmllcy4gSW4gV0lTSEkgd29yaywgd2UgaGF2ZW7igJl0IGVuY291bnRlcmVkIHN1Y2ggYSByZWdp c3RyeSBlaXRoZXIuIChUaGUgcHJvYmxlbSB0aGlzIG9uZSBzb2x2ZXMgaXMgdG8gZ2l2ZSBBU0NJ SSBuYW1lcyB0byB1bml0cyB0aGF0IGFyZSB1c2VmdWwgaW4gU2VuTUwuKQ0KDQpUaGUgdGFibGUg aXMgaW4gbm8gcGFydGljdWxhciBvcmRlciAoYW5kIGRvZXNu4oCZdCBoYXZlIHRvIGJlKTsgdGhl IGN1cnJlbnQgb3JkZXIgc2VlbWVkIHVzZWZ1bCB0byB0aGUgYXV0aG9ycy4NCg0KPiBBbHNvIGlu IFNlY3Rpb24gMTIuMSwgbnVtYmVyIDksIGlzIHRoZSBuZWVkIGZvciBjYXNlIHNlbnNpdGl2aXR5 IGluDQo+IFVuaXRzIChvciBvdGhlcndpc2U/KSBub3JtYXRpdmVseSBjb3ZlcmVkIGFueXdoZXJl PyAgSWYgbm90LCBzaG91bGQNCj4gaXQ/DQoNCldlIGFkZGVkIHRvIGVuZCBvZiBzZWN0aW9uIDM6 DQoNCiAgQWxsIGNvbXBhcmlzb25zIG9mIHRleHQgc3RyaW5ncyANCiAgYXJlIHBlcmZvcm1lZCBi eXRlLWJ5LWJ5dGUgKGFuZCB0aGVyZWZvcmUgbmVjZXNzYXJpbHkgY2FzZS1zZW5zaXRpdmUpLg0K DQoNCj4gU2VjdGlvbiAxMg0KPiANCj4gQXJlIEJhc2UgZmllbGRzIHN1cHBvc2VkIHRvIGdldCBu ZWdhdGl2ZSBDQk9SIGxhYmVscw0KPiAoYW5kIG5vdCBvdGhlciBmaWVsZHMpPyAgSXMgdGhpcyBt ZW50aW9uZWQgZXhwbGljaXRseSBzb21ld2hlcmU/DQo+IChZZXMsIEkga25vdyB0aGF0IHRoZSBp bnRlbnQgaXMgZm9yIG5vIG1vcmUgQ0JPUiBsYWJsZWxzIHRvIGJlDQo+IGFsbG9jYXRlZCwgYnV0 IHRoYXQgaXMgb25seSBhIFNIT1VMRC1sZXZlbCByZXF1aXJlbWVudC4pDQoNCkFkZGVkIHRvIHNl Y3Rpb24gNjogIlRoZSBiYXNlIHZhbHVlcyBhcmUgZ2l2ZW4gbmVnYXRpdmUgQ0JPUiBsYWJlbHMg YW5kIG90aGVycyBub24tbmVnYXRpdmUgbGFiZWxzLiINCg0KPiBJbg0KPiAgRXh0ZW5zaW9ucyB0 aGF0IGFyZSBtYW5kYXRvcnkgdG8gdW5kZXJzdGFuZCB0byBjb3JyZWN0bHkgcHJvY2VzcyB0aGUN Cj4gIFBhY2sgTVVTVCBoYXZlIGEgbGFiZWwgbmFtZSB0aGF0IGVuZHMgd2l0aCB0aGUgJ18nIGNo YXJhY3Rlci4NCj4gc2hvdWxkIHRoYXQgc2F5IHNvbWV0aGluZyBhYm91dCAibWFuZGF0b3J5IHRv IHVuZGVyc3RhbmQgYnV0IG5vdA0KPiBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQiPyAgKEFsc28g aW4gMTIuMy4xIGV0IHNlcT8pDQoNClRoaXMgc3BlY2lmaWNhdGlvbiBkb2Vzbid0IGFjdHVhbGx5 IGRlZmluZSB5ZXQgYW55IGV4dGVuc2lvbnMgYW5kIGFsbCB0aGUgbGFiZWxzIGluIHRoaXMgc3Bl Y2lmaWNhdGlvbiBhcmUgYnkgZGVmaW5pdGlvbiBtYW5kYXRvcnkgdG8gdW5kZXJzdGFuZCwgc28g d2UgZG9uJ3QgdGhpbmsgdGhpcyBpcyBuZWNlc3NhcnkuDQoNCj4gU2VjdGlvbiAxMw0KPiANCj4g V2h5IGFyZSB3ZSB0YWxraW5nIGFib3V0ICJleGVjdXRhYmxlIGNvbnRlbnQiIGF0IGFsbD8gIEl0 IHNlZW1zDQo+IHF1aXRlIHVucmVsYXRlZCB0byB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQuDQoN ClRoaXMgd2FzIHJlcXVlc3RlZCBieSBBbGV4ZXkgZHVlIHRvIGZhY3QgdGhhdCBtZWRpYSB0eXBl IHJldmlld3Mgb2Z0ZW4gYXNrIGFib3V0IHRoaXMu From nobody Mon May 7 11:00:03 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A729127AD4 for ; Mon, 7 May 2018 11:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENj6dlqxv-ca for ; Mon, 7 May 2018 10:59:57 -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 E07ED127869 for ; Mon, 7 May 2018 10:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525715994; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2xhHPN1//HFppimwnWkze3rRIruDLa3RvCqOWObFtT8=; b=IgRd7/dtWBbSruWYkBZ7a1daGiQuobHG6Y4nZjfIlhF43xlNIPNYTu7qPJ5ebYKs GKAuZ4Z7TKVTKiUtj//qw0NNXdkjbd0/huI6sT34X7DDjXEchJL66KZO4lQ7pWWF gzhqsHUJAg7/BTZzVKmXoHrGJw+0jslciszROhrOCCM=; X-AuditID: c1b4fb2d-adbff700000055bf-1f-5af0941a5082 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 63.DD.21951.A1490FA5; Mon, 7 May 2018 19:59:54 +0200 (CEST) Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.382.0; Mon, 7 May 2018 19:59:53 +0200 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 4E4FD481AB8; Mon, 7 May 2018 20:59:53 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id C8970481AA4; Mon, 7 May 2018 20:59:52 +0300 (EEST) To: "Kovatsch, Matthias" , Hannes Tschofenig , Mohit Sethi , "core@ietf.org" References: <4EBB3DDD0FBF694CA2A87838DF129B3C01F36340@DEFTHW99EL4MSX.ww902.siemens.net> From: Mohit Sethi Message-ID: Date: Mon, 7 May 2018 20:59:52 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01F36340@DEFTHW99EL4MSX.ww902.siemens.net> Content-Type: multipart/alternative; boundary="------------45D66FA797C5D69B7BE3692A" Content-Language: en-US X-AV-Checked: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbFdVFdqyocog//PJS32vV3PbHFzxikm i8YJLxgdmD3WzFvD6LFkyU8mj+0nJzEFMEdx2aSk5mSWpRbp2yVwZZw4eI6toGMBY8XFEztY Ghif1XYxcnJICJhILDp5k7WLkYtDSOAIo8S9G1egnO2MEm/vnGcBqRIS2MwosfVhBERiIaPE 6zObmEASwgIhEm0npjKCJEQEtjFKzDvzgxmiajeTxOqHC8Ha2QT0JDrPHWcGsXkF7CUuHN8F ZrMIqEj87lnMDmKLCkRI3Dv/iQ2iRlDi5MwnYL2cQPH5T9vAtjELhEn0P+5hg7DFJW49mc8E 8YSyxIKWRYwQp6pLbO04wDiBUWgWklGzkLTPQtI+i5EDyLaXeLC1DCIsL9G8dTYzhK0vcf3O fVZk8QWM7KsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAmPo4JbfujsYV792PMQowMGoxMPb n/MhSog1say4MvcQowQHs5IIL5syUIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv3qo9UUIC6Ykl qdmpqQWpRTBZJg5OqQbGBj7TyrZ/HC5pj6vljOb//b/nrGhe0uNZ2xq7fqTb8Wyf7sM6q4hr yvbSHXu+6bofUbsceTz/h56XxwL3hwo6vvU7CybfvLwr+HTe+ymu3m+jrW+V9bifmyg268bD p3wO2iHqi3b6XjhWm/H2TKrF8aWLn2S+qNn64uCcg4m1n6YVSCot+tcaqsRSnJFoqMVcVJwI AOyyLnqdAgAA Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 07 May 2018 18:00:00 -0000 --------------45D66FA797C5D69B7BE3692A Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Hi Matthias, Thanks for bringing forward the use-case. I have implemented an earlier version of the RD. I agree, the current text on "mostly mandatory" leaves much to be desired. And +1 on request for more clear text about different possibilities (cf. certificate vs Raw Public Key vs PSK). --Mohit On 05/07/2018 07:09 PM, Kovatsch, Matthias wrote: > > Dear Hannes, > > dear list > > To my knowledge, third-party provisioning functionality is in > particular used for lighting systems; maybe Peter can comment on this. > I am aware of a few business units that would also want to have this > functionality in the RD. Furthermore, I have use cases for Web Things > that provide a REST interface, but do not implement RD registration; > with the third-party provisioning they can become part of CoRE > environments as well. > > Making the Endpoint Client Name optional is a good solution in my > opinion, when it is clearly defined which security protocol > identifiers shall be taken as Endpoint Client Name. I am not even sure > if I understand the current “mostly mandatory” correctly). Overall, it > would be good to describe the usage of security context well, as there > are different possibilities (cf. certificate vs Raw Public Key vs PSK). > > Furthermore, the draft is a bit too fuzzy about the authorization, in > particular for registration. It feels obvious that also third-party > provisioning needs to be authorized to use the Endpoint Client Name to > be registered, but hearing Hannes’s concerns, it probably should be > stated concretely. The role of Domain is also rather implicit here; to > my understanding, there can be duplicate Endpoint Client Names as long > as they have different Domains. > > Kind regards, > > Matthias > > *Von:*core [mailto:core-bounces@ietf.org] *Im Auftrag von *Hannes > Tschofenig > *Gesendet:* Montag, 7. Mai 2018 16:17 > *An:* Mohit Sethi; core@ietf.org > *Betreff:* Re: [core] Conclusion -- Endpoint Client Name / Endpoint > Name in RD draft > > I was referring to this functionality: > https://tools.ietf.org/html/draft-ietf-core-resource-directory-13#section-5...3.2 > > > *From:*Mohit Sethi [mailto:mohit.m.sethi@ericsson.com] > *Sent:* 07 May 2018 15:54 > *To:* Hannes Tschofenig; core@ietf.org > *Subject:* Re: [core] Conclusion -- Endpoint Client Name / Endpoint > Name in RD draft > > Hi Hannes, > > Thank you for summarizing the discussion on this important topic thus > far. > > Could you also very briefly explain what does third-party provisioning > mean for you? > > --Mohit > > On 05/07/2018 04:50 PM, Hannes Tschofenig wrote: > > Hi all, > > I hope that all the discussion around the endpoint name / endpoint > client name have helped to make you think about the security > implications of sending an unauthenticated identifier.. > > I would like to come to a conclusion and here is my attempt. > > Since we the RD document also defines the third party provisioning > I would suggest to make the endpoint name optional in the draft. > > I would also encourage the chairs to find out whether the third > party provisioning is actually something in this group has gained > some experience with. > > Ciao > > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments > are confidential and may also be privileged. If you are not the > intended recipient, please notify the sender immediately and do > not disclose the contents to any other person, use it for any > purpose, or store or copy the information in any medium. Thank you. > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------45D66FA797C5D69B7BE3692A Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Hi Matthias,

Thanks for bringing forward the use-case.

I have implemented an earlier version of the RD. I agree, the current text on "mostly mandatory" leaves much to be desired. And +1 on request for more clear text about different possibilities (cf. certificate vs Raw Public Key vs PSK).

--Mohit

On 05/07/2018 07:09 PM, Kovatsch, Matthias wrote:

Dear Hannes,

dear list

 

To my knowledge, third-party provisioning functionality is in particular used for lighting systems; maybe Peter can comment on this. I am aware of a few business units that would also want to have this functionality in the RD. Furthermore, I have use cases for Web Things that provide a REST interface, but do not implement RD registration; with the third-party provisioning they can become part of CoRE environments as well.

 

Making the Endpoint Client Name optional is a good solution in my opinion, when it is clearly defined which security protocol identifiers shall be taken as Endpoint Client Name. I am not even sure if I understand the current “mostly mandatory” correctly). Overall, it would be good to describe the usage of security context well, as there are different possibilities (cf. certificate vs Raw Public Key vs PSK).

 

Furthermore, the draft is a bit too fuzzy about the authorization, in particular for registration. It feels obvious that also third-party provisioning needs to be authorized to use the Endpoint Client Name to be registered, but hearing Hannes’s concerns, it probably should be stated concretely. The role of Domain is also rather implicit here; to my understanding, there can be duplicate Endpoint Client Names as long as they have different Domains.

 

Kind regards,

Matthias

 

 

Von: core [mailto:core-bounces@ietf.org] Im Auftrag von Hannes Tschofenig
Gesendet: Montag, 7. Mai 2018 16:17
An: Mohit Sethi; core@ietf.org
Betreff: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft

 

I was referring to this functionality: https://tools.ietf.org/html/draft-ietf-core-resource-directory-13#section-5...3.2

 

 

From: Mohit Sethi [mailto:mohit.m.sethi@ericsson.com]
Sent: 07 May 2018 15:54
To: Hannes Tschofenig; core@ietf.org
Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft

 

Hi Hannes,

Thank you for summarizing the discussion on this important topic thus far.

Could you also very briefly explain what does third-party provisioning mean for you?

--Mohit

 

On 05/07/2018 04:50 PM, Hannes Tschofenig wrote:

Hi all,

 

I hope that all the discussion around the endpoint name / endpoint client name have helped to make you think about the security implications of sending an unauthenticated identifier..

 

I would like to come to a conclusion and here is my attempt.

 

Since we the RD document also defines the third party provisioning I would suggest to make the endpoint name optional in the draft.

 

I would also encourage the chairs to find out whether the third party provisioning is actually something in this group has gained some experience with.

 

Ciao

Hannes

 

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

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

 

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



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

--------------45D66FA797C5D69B7BE3692A-- From nobody Mon May 7 11:00:26 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4E3128954 for ; Mon, 7 May 2018 11:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiH9Ysjptdk1 for ; Mon, 7 May 2018 11:00:09 -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 DCA6612DA68 for ; Mon, 7 May 2018 11:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525716007; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8cnXqKZc9+t4Tgf6uYZtCM7uo2LHI52OyQETmq/OqCo=; b=NeBt0ugDvhpmAzCNW/DJJieE0zPbcG7/GCQq3kuSLpdeXpU/gKLFlKkKLl1Qo/E0 O/bli4nVCAB7wq/hTfGtOCIEv+Wdk5SjjIYFbuKuxn0v4r+Q1/TsiRcTuutzt52a 2wvXVltZ9vUDQveUVKoZj3Up605F+2dcCzM7dnyMfE8=; X-AuditID: c1b4fb25-5c3ff700000064d0-0d-5af094270419 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 91.B9.25808.72490FA5; Mon, 7 May 2018 20:00:07 +0200 (CEST) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSHC007.ericsson.se (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 7 May 2018 20:00:06 +0200 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 7 May 2018 20:00:06 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Mon, 7 May 2018 20:00:06 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Adam Roach CC: The IESG , "draft-ietf-core-senml@ietf.org" , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core-chairs@ietf.org" , core Thread-Topic: Adam Roach's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) Thread-Index: AQHT164GXZXCzc15v0CK+eOmi31/vqQkiZGA Date: Mon, 7 May 2018 18:00:06 +0000 Message-ID: References: <152412205332.28757.3125528615459674307.idtracker@ietfa.amsl.com> In-Reply-To: <152412205332.28757.3125528615459674307.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUyM2K7uq76lA9RBhOX8lns+buI3WLbxgts Fvverme2+PluCbPFjD8TmR1YPZYs+cnkMWvnE5YApigum5TUnMyy1CJ9uwSujA/PtzAWTLCv uLxnBVsD4wHbLkZODgkBE4kD+x8zdjFycQgJHGGUONL5nQ3C2cwoseHNemYI5yujxLrJF5gg nKWMEn+//WUD6WcTsJV40rqPFcQWEVCUaDt8E6yDWeAlo8Trh71Agzk4hAWiJS59r4OoiZH4 urOZGcI2klhyr48JxGYRUJHYdfUhmM0rYC9xq3cCG0irkICvxJcJaiBhTgE/iY/bb4KtZRQQ k/h+ag1YObOAuMStJ/OZIN4RkFiy5zwzhC0q8fLxP1YIW0li77HrLCAjmQU0Jdbv0odotZZ4 uHkWG4StKDGl+yE7xAWCEidnPmEBsYUEVCWu/nvFOIFRchaSbbMQJs1CMmkWkkmzkExawMi6 ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMweg9u+a26g/HyG8dDjAIcjEo8vFU5H6KEWBPL iitzDzFKcDArifCyKQOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8z403xwlJJCeWJKanZpakFoE k2Xi4JRqYCw6ra118Or8+iSxvY0qEUr74t7sFHjDmLVX9u+uZe/nsIVclkmZyn5uu+aFPddl k3XnMM59keybPVlU/b+Vu8XCQ82rs9tCel34jh/N9F/hsDZcWjFRa9KvykUbQkOE1/M/00xc /8qL1XwKW8Z0z6brmTyrSq/rXypfHvvoxLL8eV2XeaZpsimxFGckGmoxFxUnAgCxzNjk2gIA AA== Archived-At: Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 07 May 2018 18:00:19 -0000 VGhhbmsgeW91IGZvciB0aGUgcmV2aWV3IEFkYW0hDQoNCldlIGhhdmUgbm93IHN1Ym1pdHRlZCBh IG5ldyByZXZpc2lvbiBvZiB0aGUgU2VuTUwgZHJhZnQgdGhhdCBhZGRyZXNzZXMgYWxsIHRoZSBJ RVNHIHJldmlldyBjb21tZW50czoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWNvcmUtc2VubWwtMTUNCg0KRm9yIGFuc3dlcnMgdG8geW91ciByZXZpZXcgY29tbWVudHMs IHBsZWFzZSBzZWUgYmVsb3cuDQoNCg0KVGhhbmtzLA0KQXJpDQoNCj4gT24gMTkgQXByIDIwMTgs IGF0IDEwLjE0LCBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPiB3cm90ZToNCj4gDQo+IEFk YW0gUm9hY2ggaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ IGRyYWZ0LWlldGYtY29yZS1zZW5tbC0xNDogRGlzY3Vzcw0KPiANCj4gV2hlbiByZXNwb25kaW5n LCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBm cmVlIHRvIGN1dCB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiAN Cj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVu dC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVT RyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQs IGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS1zZW5tbC8N Cj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IA0KPiBUaGFua3MgdG8gZXZlcnlvbmUgd2hvIGNvbnRyaWJ1dGVkIHRvIHRoaXMgZG9jdW1l bnQuDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IMKnOSBkZWZpbmVzIGEgVVJJIGZy YWdtZW50IGlkZW50aWZpY2F0aW9uIHNjaGVtZSB0aGF0IGlzIGludGVuZGVkIHRvIGFwcGx5IHRv DQo+IHNlbm1sK3htbCAvIHNlbnNtbCt4bWwuIFNpbmNlIHRoaXMgdXNlcyB0aGUgIit4bWwiIHN0 cnVjdHVyZWQgc3ludGF4IHN1ZmZpeCwgaXQNCj4gaGFzIHRvIGNvbXBseSB3aXRoIHRoZSBmcmFn bWVudCBpZGVudGlmaWVyIGNvbnNpZGVyYXRpb25zIGFzc29jaWF0ZWQgd2l0aCB0aGF0DQo+IHN1 ZmZpeC4gU2VlOg0KPiANCj4gaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvbWVkaWEt dHlwZS1zdHJ1Y3R1cmVkLXN1ZmZpeC9tZWRpYS10eXBlLXN0cnVjdHVyZWQtc3VmZml4LnhodG1s DQo+IA0KPiBJbiBwYXJ0aWN1bGFyLCAreG1sIGhhcyByZXF1aXJlbWVudHMgYXJvdW5kIGNpdGlu ZyBzZWN0aW9uIDUgb2YgUkZDIDczMDMNCj4gKHdoaWNoIHRoaXMgZG9jdW1lbnQgZG9lc24ndCks IGFzIHdlbGwgYXMgcmVxdWlyaW5nIHN1cHBvcnQgZm9yIGVsZW1lbnQoKQ0KPiBmcmFnbWVudHM7 IGUuZy46DQo+IA0KPiBjb2FwOi8vZXhhbXBsZS5jb20vdGVtcCNlbGVtZW50KC8xLzMpDQo+IA0K PiBtdXN0IGJlIGFsbG93ZWQgYXMgYW4gYWxpYXMgZm9yDQo+IA0KPiBjb2FwOi8vZXhhbXBsZS5j b20vdGVtcCNyZWM9Mw0KPiANCj4gSWYgeW91IHdhbnQgdG8gcmVzdHJpY3Qgb3RoZXIgYXNwZWN0 cyBvZiBYUG9pbnRlckZyYW1ld29yayBmcmFnbWVudCBpZGVudGlmaWVycywNCj4gSSBiZWxpZXZl IHlvdSdsbCBoYXZlIHRvIHNheSBzbyBleHBsaWNpdGx5Lg0KDQpXZSBhZGRlZCBYUG9pbnRlckZy YW1ld29yayBhcyBhbHRlcm5hdGl2ZSB3YXkgZm9yIFhNTCBhbmQgRVhJOg0KaHR0cHM6Ly9naXRo dWIuY29tL2NvcmUtd2cvc2VubWwtc3BlYy9wdWxsLzExNS9maWxlcw0KDQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLXNlbm1sLTE1I3NlY3Rpb24tOS4yDQoNCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBJIHNoYXJl IEJlbmphbWluJ3MgY29uY2VybnMgYWJvdXQgdGhlIGFtYmlndWl0eSBvZiB0aW1lIGhhbmRsaW5n LCBhbmQgQmVuJ3MNCj4gY29uY2VybnMgYWJvdXQgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBv ZiB3cml0aW5nIHRvIGRldmljZXMuDQoNCkZpeGVkIChzZWUgQmVuamFtaW4ncyBhbmQgQmVuJ3Mg cmV2aWV3IHRocmVhZHMgZm9yIGRldGFpbHMpLg0KDQo+IEkgYWxzbyBoYXZlIGNvbmNlcm5zIGFi b3V0IHRoZSBub3Rpb24gb2YgIm5vdyIgYW5kIHJlbGF0aXZlIHRpbWVzIHdpdGggdGhlDQo+IHN0 cmVhbWluZyBmb3JtYXRzOiBpcyBpdCByZWxhdGl2ZSB0byB0aGUgdGltZSB0aGUgc3RyZWFtIHdh cyBvcGVuZWQ/IE9yDQo+IHJlbGF0aXZlIHRvIHRoZSB0aW1lIHRoZSByZWNvcmQgd2FzIHJlY2Vp dmVkPyBHaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBoaWdobGlnaHRzDQo+IHRpbWUgcHJlY2lzaW9u cyBkb3duIHRvIHRoZSBzdWItbWljcm9zZWNvbmQgbGV2ZWwsIGFuZCBnaXZlbiB0aGF0IHRoZSBy ZWNvcmQNCj4gc2l6ZXMgYXJlIGxpa2VseSB0byBiZSBtdWNoIHNtYWxsZXIgdGhhbiB0aGUgVENQ IG1heGltdW0gc2VnbWVudCBzaXplLCB0aGlzDQo+IHByZXN1bWFibHkgbmVlZHMgdG8gdGFrZSBp bnRvIGNvbnNpZGVyYXRpb24gcG9zc2libGUgYnVmZmVyaW5nIGVmZmVjdHMgZHVlIHRvDQo+IE5h Z2xlJ3MgYWxnb3JpdGhtLg0KDQpXZSBjbGFyaWZpZWQgdGhlICJub3ciIGFzcGVjdCBpbiBzZWN0 aW9uIDQuNS4zOg0KDQogIE9idmlvdXNseSwgIm5vdyItcmVmZXJlbmNlZCBTZW5NTCByZWNvcmRz IGFyZSBvbmx5IHVzZWZ1bCB3aXRoaW4gYQ0KICBzcGVjaWZpYyBjb21tdW5pY2F0aW9uIGNvbnRl eHQgKGUuZy4sIGJhc2VkIG9uIGluZm9ybWF0aW9uIG9uIHdoZW4NCiAgdGhlIFNlbk1MIHBhY2ss IG9yIGEgc3BlY2lmaWMgcmVjb3JkIGluIGEgU2Vuc01MIHN0cmVhbSwgd2FzIHNlbnQpIG9yDQog IHRvZ2V0aGVyIHdpdGggc29tZSBvdGhlciBjb250ZXh0IGluZm9ybWF0aW9uIHRoYXQgY2FuIGJl IHVzZWQgZm9yDQogIGRlcml2aW5nIGEgbWVhbmluZyBvZiAibm93IjsgdGhlIGV4cGVjdGF0aW9u IGZvciBhbnkgYXJjaGl2YWwgdXNlIGlzDQogIHRoYXQgdGhleSB3aWxsIGJlIHByb2Nlc3NlZCBp bnRvIFVUQy1yZWZlcmVuY2VkIHJlY29yZHMgYmVmb3JlIHRoYXQNCiAgY29udGV4dCB3b3VsZCBj ZWFzZSB0byBiZSBhdmFpbGFibGUuICBUaGlzIHNwZWNpZmljYXRpb24gZGVsaWJlcmF0ZWx5DQog IGxlYXZlcyB0aGUgYWNjdXJhY3kgb2YgIm5vdyIgdmVyeSB2YWd1ZSBhcyBpdCBpcyBkZXRlcm1p bmVkIGJ5IHRoZQ0KICBvdmVyYWxsIHN5c3RlbXMgdGhhdCB1c2UgU2VuTUwuICBJbiBhIHN5c3Rl bSB3aGVyZSBhIHNlbnNvciB3aXRob3V0DQogIHdhbGwtY2xvY2sgdGltZSBzZW5kcyBhIFNlbk1M IHJlY29yZCB3aXRoIGEgIm5vdyItcmVmZXJlbmNlZCB0aW1lDQogIG92ZXIgYSBoaWdoIHNwZWVk IFJTIDQ4NSBsaW5rIHRvIGFuIGVtYmVkZGVkIHN5c3RlbSB3aXRoIGFjY3VyYXRlDQogIHRpbWUg dGhhdCByZXNvbHZlcyAibm93IiBiYXNlZCBvbiB0aGUgdGltZSBvZiByZWNlcHRpb24sIHRoZQ0K ICByZXN1bHRpbmcgdGltZSB1bmNlcnRhaW50eSBjb3VsZCBiZSB3aXRoaW4gMSBtcy4gIEF0IHRo ZSBvdGhlcg0KICBleHRyZW1lLCBhIGRlcGxveW1lbnQgdGhhdCBzZW5kcyBTZW5NTCB3aW5kIHNw ZWVkIHJlYWRpbmdzIG92ZXIgYSBMRU8NCiAgc2F0ZWxsaXRlIGxpbmsgZnJvbSBhIG1vdW50YWlu IHZhbGxleSBtaWdodCBoYXZlIHJlc3VsdGluZyByZWNlcHRpb24NCiAgdGltZSB2YWx1ZXMgdGhh dCBhcmUgZWFzaWx5IGEgZG96ZW4gbWludXRlcyBvZmYgdGhlIGFjdHVhbCB0aW1lIG9mDQogIHRo ZSBzZW5zb3IgcmVhZGluZywgd2l0aCB0aGUgdGltZSB1bmNlcnRhaW50eSBkZXBlbmRpbmcgb24g c2F0ZWxsaXRlDQogIGxvY2F0aW9ucyBhbmQgY29uZGl0aW9ucy4NCg0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gDQo+IMKnNC4zOg0KPiANCj4+ICB8ICAgIERhdGEgVmFsdWUgfCB2ZCAgICB8ICAg ICAgICAgIDggfCBTdHJpbmcgKCopIHwgc3RyaW5nICgqKSB8DQo+IA0KPiBJIGZpbmQgbm93aGVy ZSBpbiB0aGUgZG9jdW1lbnQgdGhhdCBleHBsYWlucyB3aGF0IHRoZXNlICIoKikiIG5vdGF0aW9u cyBtZWFuLg0KDQpUaGUgZmlyc3Qgc2VudGVuY2UgYWZ0ZXIgdGFibGUgd2FzIHN1cHBvc2VkIHRv IGhhdmUgYXN0ZXJpc2sgdG8gaW5kaWNhdGUgZXhwbGFuYXRpb24uIE5vdyBpdCBzYXlzOg0KDQog KCopIERhdGEgVmFsdWUgaXMgYmFzZTY0IGVuY29kZWQgc3RyaW5nIHdpdGggVVJMIHNhZmUgYWxw aGFiZXQgYXMNCiBkZWZpbmVkIGluIFNlY3Rpb24gNSBvZiBbUkZDNDY0OF0sIHdpdGggcGFkZGlu ZyBvbWl0dGVkLg0KDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gwqc4Og0KPiANCj4+IDgu ICBFWEkgUmVwcmVzZW50YXRpb24gKGFwcGxpY2F0aW9uL3Nlbm1sLWV4aSkNCj4gDQo+IEFsbCB0 aGUgb3RoZXIgTUlNRSB0eXBlcyBoZXJlIHVzZSB0aGUgc3RydWN0dXJlZCBzeW50YXggZm9ybWF0 LCB3aGljaCBtYWtlcw0KPiB0aGlzIG9uZSBzdGljayBvdXQgYXMgdW5uZWNlc3NhcmlseSBkaWZm ZXJlbnQuIEdpdmVuIHRoYXQgdGhlIGJhcnJpZXIgZm9yDQo+IHJlZ2lzdGVyaW5nICtleGkgYXMg YSBzdWZmaXggaXMgImV4cGVydCByZXZpZXcsIiBhbmQgdGhlIG9ubHkgcmVhbCByZXF1aXJlbWVu dA0KPiB0aGF0IGV4cGVydCBpcyBnb2luZyB0byBjaGVjayBpcyBhIHJlZmVyZW5jZSBzdWl0YWJs ZSBmb3Igbm9ybWF0aXZlbHkgY2l0aW5nDQo+ICh3aGljaCBFWEkgaXMgYnkgdmlydHVlIG9mIGl0 cyBhcHBlYXJhbmNlIGluIHRoZSAiTm9ybWF0aXZlDQo+IFJlZmVyZW5jZXMiIHNlY3Rpb24gb2Yg dGhpcyBkb2N1bWVudCksIGl0IHNlZW1zIHRoYXQgdGhlIGNvcnJlY3QgKGFuZCBlYXN5KQ0KPiB0 aGluZyB0byBkbyBoZXJlIGlzIHNpbXBseSBnbyBhaGVhZCBhbmQgcmVnaXN0ZXIgIitleGkiLg0K PiANCj4gQXMgYW4gZXhhbXBsZTogd2UganVzdCBkaWQgdGhpcyBmb3IgK2d6aXA7IHNlZSB0aGUg UkZDIEVkaXRvciBOb3RlIGF0DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtdXRhLXNtdHAtdGxzcnB0L3dyaXRldXAvDQoNCldlIGhhdmUgdHJpZWQgdGhhdCBw YXRoIGFscmVhZHksIG11bHRpcGxlIHRpbWVzLCBhbmQgZHJhZnQtc2hlbGJ5LWV4aS1yZWdpc3Ry YXRpb24gaGFzIGJlZW4gZGlzY3Vzc2VkIGVhcmxpZXIgYXMgcG90ZW50aWFsIHNvbHV0aW9uLCBi dXQgaXQgZGlkbid0IHByb2dyZXNzIHdlbGwuIEF0IHRoaXMgbW9tZW50IHdlIGNhbid0IGFmZm9y ZCB0byB3YWl0IGFueW1vcmUgdW5mb3J0dW5hdGVseS4= From nobody Mon May 7 11:03:24 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6099D127873 for ; Mon, 7 May 2018 11:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eto1P6phzi0V for ; Mon, 7 May 2018 11:03:12 -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 1A611127909 for ; Mon, 7 May 2018 11:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525716190; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jIMZ9XwqVPH7b9LU37oQm+ACUoLRNpFEMt0CxgkV71Q=; b=KY253g1J5RO8uYw1ocGm2rHxWZPimm+mYEAOTsqojcEZgjc1Cfc0YgRJzONFba+M WHZ9EvX+0WxFO8Lwsy3+vfzjF7faJKI6SOVj6xskDhAHt6q2DiMl0Z6hoMDwBrlG dQqz6IrAnPC3MJICV80Ao31iup40rp+vMtR4OD5dRIA=; X-AuditID: c1b4fb2d-ac3ff700000055bf-d9-5af094dedd34 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7D.3E.21951.ED490FA5; Mon, 7 May 2018 20:03:10 +0200 (CEST) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSHC017.ericsson.se (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 7 May 2018 20:03:09 +0200 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 7 May 2018 20:03:09 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Mon, 7 May 2018 20:03:09 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Eric Rescorla CC: The IESG , "draft-ietf-core-senml@ietf.org" , =?iso-8859-1?Q?Jaime_Jim=E9nez?= , "core-chairs@ietf.org" , core Thread-Topic: Eric Rescorla's No Objection on draft-ietf-core-senml-14: (with COMMENT) Thread-Index: AQHT1bz07f24qKA53ECCs/YGzWki+KQkjk0A Date: Mon, 7 May 2018 18:03:09 +0000 Message-ID: References: <152390856344.19573.405946028706072168.idtracker@ietfa.amsl.com> In-Reply-To: <152390856344.19573.405946028706072168.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUyM2K7q+69KR+iDKaslrbYtvECm8W+t+uZ LX6+W8JsseL1OXaLGX8mMjuweixZ8pPJY/LjNuYApigum5TUnMyy1CJ9uwSujI8zjzAW3PCs eNA9kbmBcaNFFyMnh4SAicSJP6eZuxi5OIQEjjBK/Pv4mw3C2cwosWjCQ6jMV0aJhxsWMUI4 Sxkl1vZ+YgLpZxOwl5i85iMjiC0ioCDx688JFpAiZoGXjBLN1yYxgySEBcIl9j7YDtTAAVQU IfHxNhtEvZHE/dOrwWwWARWJWVuPsoDYvEAzj5/ZABYXEvCRWH/8J9guTgFfialds8FsRgEx ie+n1oDZzALiEreezGeC+EdAYsme88wQtqjEy8f/WCFsJYm9x66zQNTrSdyYOoUNwraW2HPr K5StLbFs4WtmiBsEJU7OfMICcYOqxNV/rxgnMErOQrJuFpJRs5CMmoVk1CwkoxYwsq5iFC1O LS7OTTcy1kstykwuLs7P08tLLdnECIzhg1t+6+5gXP3a8RCjAAejEg9vf86HKCHWxLLiytxD jBIczEoivGzKQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8eqv2RAkJpCeWpGanphakFsFkmTg4 pRoYe1hjrGdufD7Z03vzEnbfpRd46vq12t+HtDT+3Pi+Rk5LM1t8ptuFhMu/7U1+789l/md8 Zoay67r3nkYSNyzq0hYVlP2L69uiuvVkUfT9d0dzatlMJ1jy9cR/5w/UWKNz+3SIU0Qeo0Nb y+ovTHMk7rQt5LN68embzpYryypEFk9vyXqzMUtFiaU4I9FQi7moOBEA9itqFN0CAAA= Archived-At: Subject: Re: [core] Eric Rescorla's No Objection on draft-ietf-core-senml-14: (with COMMENT) 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, 07 May 2018 18:03:15 -0000 Thank you for the review Eric! We have now submitted a new revision of the SenML draft that addresses all = the IESG review comments: https://tools.ietf.org/html/draft-ietf-core-senml-15 For answers to your review comments, please see below. Thanks, Ari > On 16 Apr 2018, at 22.56, Eric Rescorla wrote: >=20 > Eric Rescorla has entered the following ballot position for > draft-ietf-core-senml-14: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-core-senml/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D4594 >=20 >=20 > COMMENTS >>=20 >> Abstract >>=20 >> 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 >=20 > You're kind of burying the lede here. This document defines SenML, it > doesn't just define media type. True, and also commented by others. Changed now to: This specification defines a format for representing simple sensor measurements and device parameters in the Sensor Measurement Lists (SenML).=20 >> measurement every second, batch up 60 of them, and then send the >> batch to a server. It would include the relative time each >> measurement was made compared to the time the batch was sent in each >> SenML Record. The server might have accurate NTP time and use the >> time it received the data, and the relative offset, to replace the >> times in the SenML with absolute times before saving the SenML Pack >=20 > You use "Pack" here before you define it in S 3. Changed to: The server might have accurate NTP time and use the time it received the data, and the relative offset, to replace the times in the SenML with absolute times before saving the SenML information in a document database. >> kinds of fields: base and regular. The base fields can be included >> in any SenML Record and they apply to the entries in the Record. >> Each base field also applies to all Records after it up to, but not >> including, the next Record that has that same base field. All base >> fields are optional. Regular fields can be included in any SenML >> Record and apply only to that Record. >=20 > It looks like it's permissible to intermix Base and Regular fields in > the same record. Assuming that's so, it would be helpful to say so. Yes, made this now more explicit: kinds of fields: base and regular. Both the base fields and the regular fields can be included in any SenML Record. The base fields apply to the entries in the Record and also to all Records after it up to, but not including, the next Record that has that same base field. All base fields are optional. Regular fields can be included in any SenML Record and apply only to that Record. >> ("vs" for "String Value") and binary data ("vd" for "Data Value"). >> Exactly one value field MUST appear unless there is Sum field in >> which case it is allowed to have no Value field. >>=20 >> Sum: Integrated sum of the values over time. Optional. This field >> is in the unit specified in the Unit value multiplied by seconds. >=20 > This text is hard to read, but the dimensional analysis seems > potentially wrong, for at least some measurements. I assume you're > thinking of something like watts and watt-hours. but if the value is > for instance bits, then "bit-seconds" is not a meaningful unit, and > yet you might want to sum these. True. The name "sum" is actually not fully correct, but there are historica= l reasons why it's called so. Updated the text to reflect this: Sum: Integrated sum of the values over time. Optional. This field is in the unit specified in the Unit value multiplied by seconds. For historical reason it is named sum instead of integral. Also clarified more the use of the sum in Section 10. >> The SenML format can be extended with further custom fields. Both >> new base and regular fields are allowed. See Section 12.2 for >> details. Implementations MUST ignore fields they don't recognize >> unless that field has a label name that ends with the '_' character >> in which case an error MUST be generated. >=20 > How does this map to CBOR? I see you explain this later, but here > would be helpful We discussed this and concluded that the SenML is format agnostic in this m= atter so there should be no surprise here.=20 >> concatenated name MUST consist only of characters out of the set "A" >> to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", and "_"; >> furthermore, it MUST start with a character out of the set "A" to >> "Z", "a" to "z", or "0" to "9". This restricted character set was >> chosen so that concatenated names can be used directly within various >> URI schemes (including segments of an HTTP path with no special >=20 > Assuming I am understanding this correctly, then "/" is a problem > inside a path component. Yes, clarified this with: URI schemes (including segments of an HTTP path with no special encoding; note that a name that contains "/" characters maps into multiple URI path segments)=20 >> specified above puts strict limits on the URI schemes and URN >> namespaces that can be used. As a result, implementers need to take >> care in choosing the naming scheme for concatenated names, because >> such names both need to be unique and need to conform to the >> restricted character set. One approach is to include a bit string >> that has guaranteed uniqueness (such as a 1-wire address). Some of >=20 > citation for 1-wire please. Added informative reference: [AN1796] Linke, B., "Overview of 1-Wire Technology and Its Use", June 2008, . >> | Encoding | Size | Compressed Size | >> +----------+------+-----------------+ >> | JSON | 573 | 206 | >> | XML | 649 | 235 | >> | CBOR | 254 | 196 | >> | EXI | 161 | 184 | >=20 > Compression not working out so well for EXI Indeed. >> To select a single SenML Record, the "rec" scheme followed by a >> single number is used. For the purpose of numbering records, the >> first record is at position 1. A range of records can be selected by >> giving the first and the last record number separated by a '-' >> character. Instead of the second number, the '*' character can be >=20 > This is an odd notation as * usually means "all". Why not just omit > the terminal #? Yes, we re-used the fragment format from RFC7111 that was using the termina= l "*": https://tools.ietf.org/html/rfc7111#section-2.1 Seems to make sense to be consistent here, but no strong opinions. >> New entries can be added to the registration by Expert Review as >> defined in [RFC8126]. Experts should exercise their own good >> judgment but need to consider that shorter labels should have more >> strict review. New entries should not be made that counteract the >> advice at the end of Section 4.4. >=20 > Note that you say earlier that you don't expect to define new CBOR > integers. That should probably be repeated here. We had a second look at this and the recommendation two paragraphs earlier = seemed to be quite sufficient to cover this. This paragraph was now slightl= y modified to reference new structure of Section 4 though.=20 >> Sensor data can range from information with almost no security >> considerations, such as the current temperature in a given city, to >> highly sensitive medical or location data. This specification >> provides no security protection for the data but is meant to be used >> inside another container or transport protocol such as S/MIME >> [RFC5751] or HTTP with TLS [RFC5246] that can provide integrity, >=20 > This is the wrong citation for HTTP over TLS. That's RFC 2818. Fixed. >> We would like to thank Alexander Pelov, Alexey Melnikov, Andrew >> McClure, Andrew McGregor, Bjoern Hoehrmann, Christian Amsuess, >> Christian Groves, Daniel Peintner, Jan-Piet Mens, Jim Schaad, Joe >> Hildebrand, John Klensin, Karl Palsson, Lennart Duhrsen, Lisa >> Dusseault, Lyndsay Campbell, Martin Thomson, Michael Koster, Peter >> Saint-Andre, Roni Even, and Stephen Farrell, for their review >=20 > Nit: no comma after Farrell Fixed.= From nobody Mon May 7 11:22:30 2018 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 018E012D96A; Mon, 7 May 2018 11:22:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-core-senml@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152571733599.1308.13648923348663871501.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2018 11:22:15 -0700 Archived-At: Subject: [core] Adam Roach's No Objection on draft-ietf-core-senml-15: (with COMMENT) 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, 07 May 2018 18:22:18 -0000 Adam Roach has entered the following ballot position for draft-ietf-core-senml-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and comments. From nobody Mon May 7 17:02:18 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A2812D810; Mon, 7 May 2018 17:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 yffqFlC2kx-Q; Mon, 7 May 2018 17:02:08 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 2C24712D7F7; Mon, 7 May 2018 17:02:07 -0700 (PDT) X-AuditID: 1209190e-dd7ff70000000240-27-5af0e8fe4ab4 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id A3.A5.00576.EF8E0FA5; Mon, 7 May 2018 20:02:07 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w48021fp007967; Mon, 7 May 2018 20:02:02 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w4801vX8015056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 May 2018 20:01:59 -0400 Date: Mon, 7 May 2018 19:01:57 -0500 From: Benjamin Kaduk To: Ari =?iso-8859-1?Q?Ker=E4nen?= Cc: The IESG , "draft-ietf-core-senml@ietf.org" , Jaime =?iso-8859-1?Q?Jim=E9nez?= , "core-chairs@ietf.org" , core Message-ID: <20180508000154.GY84491@kduck.kaduk.org> References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsUixG6nrvv/xYcog9WNzBbXrv1ns9i28QKb xb6365ktfr5bwmwx489EZouPfRNZHdg8fn29yuaxZMlPpgCmKC6blNSczLLUIn27BK6Ma+/P MhXcMqxYeXoacwPjFo0uRk4OCQETibPTl7J2MXJxCAksZpLo6JnOBuFsYJS48Xk7O4RzhUli 96pX7CAtLAIqEjfeTGcCsdmA7Ibuy8xdjBwcIgK2Eq8P14HUMwv8Y5S4vfceK0iNsEC8xN57 jWC9vEDr2l42QA1tYpSYdPQEK0RCUOLkzCcsIDazgI7Ezq132ECGMgtISyz/xwERlpdo3jqb GcTmFHCQ2H7sBNhMUQFlib19h9gnMArOQjJpFpJJsxAmzUIyaQEjyypG2ZTcKt3cxMyc4tRk 3eLkxLy81CJdY73czBK91JTSTYygCOCU5NvBOKnB+xCjAAejEg/vj4IPUUKsiWXFlbmHGCU5 mJREebkfvI8S4kvKT6nMSCzOiC8qzUktPsQowcGsJMLLpgxUzpuSWFmVWpQPk5LmYFES5xXY DJQSSE8sSc1OTS1ILYLJynBwKEnwCgIjXUiwKDU9tSItM6cEIc3EwQkynAdoeAhIDW9xQWJu cWY6RP4Uoy5Hx/spPcxCLHn5ealS4rzbnoOsASnKKM2DmwNKXBLZ+2teMYoDvSXMOwNkFA8w 6cFNegW0hAloiSDId7zFJYkIKakGxoyj/NN6eH9mmvoLrunR0LZ6sNmNk31u95EOzjfVGfmT WY5WGwjMOeWYIqMgzPmlxsNtxdtYhzOeEaanVx9e73MlY/5Gf4MJzvUl+qpxDvM9rs05e5xN J2cp/xmJ3lmvjHQXK505OLf5+7nDT3ZMecPY3LlGNoeJJVLIj2daac4coxhZv0ZOJZbijERD Leai4kQAFGeJ9zcDAAA= Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 08 May 2018 00:02:11 -0000 On Mon, May 07, 2018 at 05:55:59PM +0000, Ari Keränen wrote: > > We have now submitted a new revision of the SenML draft that addresses all the IESG review comments: > https://tools.ietf.org/html/draft-ietf-core-senml-15 > > For answers to your review comments, please see below. Thanks for the updates, they are definitely improvements! A few comments inline. > > > On 19 Apr 2018, at 5.33, Benjamin Kaduk wrote: > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I agree with Ben's DISCUSS. > > This was addressed in the updated security considerations text: > https://github.com/core-wg/senml-spec/pull/106/commits/b911090ce2d12d394d243658f636522bb3dcc335 > > https://tools.ietf.org/html/draft-ietf-core-senml-15#section-13 I would of course like to hear from Ben as well, but it would probably be good to say a bit more about what "proper security mechanisms" are, perhaps that they are use "to provide data integrity, confidentiality, and source authentication as appropriate for the usage". > > Additionally, I have serious reservations about introducing the > > concept of "base fields" that apply to subsequent array elemnets > > unless overridden. It seems to violate an abstraction barrier for > > at least some of the serialization formats, and prevents snippets > > from being composable and commutable absent the > > resolution/normalization process. It does not seem like the markup > > language and the document contain suffient safeguards against misuse > > to prevent security holes (both sensor data and commands could be > > misinterpreted). It seems that some substantially expanded text > > should be added on the hazards of the non-resolved format and giving > > guidance on when resolution/normalization must be performed in order > > to avoid correctness and security issues. > > The base values feature is something that the WG decided is important to have. We added now text about the security implications and remedies, also taking into account Alexey's follow-ups in this thread: https://github.com/core-wg/senml-spec/pull/109/files The text about use outside of a Pack is probably the minimal change needed on this issue (though of course I would not object if more text was added, perhaps noting that "the smallest functional quantum for non-resolved SenML Records is the Pack, that provides the needed context for the Base Values"). But please use your judgment on what volume of discussion is appropriate given the intended usage and audience. > > There also seem to be sizeable risks associated with the semantics > > for time values. In particular, both with the use of an > > implicit-"now-ish", and with positive and negative values being > > interpreted with respect to a different absolute time base. (The > > involvement of base time is a further complication -- I do not > > remember any discussion of the interaction of a (positive) base time > > and a negative regular time, for example. I also do not remember > > any discussion of how the "now-ish" semantics make it actively > > harmful to do things like store-and-forward or archive SenML data > > (again, absent normalization), or what sort of granularity the > > "now-ish" semantics are expected to adhere to. (Is "yesterday" > > still considered "roughly now"?) I understand the desire for this > > sort of semantics, but the current specification seems to leave many > > potential problems exposed. > > We clarified the "now" issue (also to address other comments on this topic). The new text in section 4.5.3 says: > > Obviously, "now"-referenced SenML records are only useful within a > specific communication context (e.g., based on information on when > the SenML pack, or a specific record in a SensML stream, was sent) or > together with some other context information that can be used for > deriving a meaning of "now"; the expectation for any archival use is > that they will be processed into UTC-referenced records before that > context would cease to be available. This specification deliberately > leaves the accuracy of "now" very vague as it is determined by the > overall systems that use SenML. In a system where a sensor without > wall-clock time sends a SenML record with a "now"-referenced time > over a high speed RS 485 link to an embedded system with accurate > time that resolves "now" based on the time of reception, the > resulting time uncertainty could be within 1 ms. At the other > extreme, a deployment that sends SenML wind speed readings over a LEO > satellite link from a mountain valley might have resulting reception > time values that are easily a dozen minutes off the actual time of > the sensor reading, with the time uncertainty depending on satellite > locations and conditions. This is definitely helpful to have, but I think I still have some questions about how things work. (Perhaps they can be answered in this thread and no change to the document would be needed.) The existing text seems to be pretty clear that the base time and (non-base) time are first added, and then the special semantics for positive and non-positive values are applied. Things could potentially get exciting in some scenarios, though, as a collection of Records (whether Pack or streaming) could cross over the discontinuity. Consider, for example, a small negative base time, and a series of records with increasing time values, that cross the zero threshold and suddenly appear decades in the past. Do we need to say more to warn about this possibility, or is it perhaps better to only give the special semantics to one of the (base time, time) values and not their sum? (I guess it would have to be something a little complicated like "if base time is present, it gets the special semantics and time is added to it, but if base time is not present then time gets special semantics".) > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- Thanks for all these updates, they look good. -Benjamin From nobody Mon May 7 23:54:40 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E1E12704A for ; Mon, 7 May 2018 23:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BA7oNK-ACSnM for ; Mon, 7 May 2018 23:54:36 -0700 (PDT) Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.39]) (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 1734F126CC7 for ; Mon, 7 May 2018 23:54:35 -0700 (PDT) Received: from 1fFwW9-0004BE-Tm by out11a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fFwW9-0004D8-Ul; Mon, 07 May 2018 23:54:33 -0700 Received: by emcmailer; Mon, 07 May 2018 23:54:33 -0700 Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fFwW9-0004BE-Tm; Mon, 07 May 2018 23:54:33 -0700 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; Tue, 8 May 2018 08:54:32 +0200 To: References: <4EBB3DDD0FBF694CA2A87838DF129B3C01F36340@DEFTHW99EL4MSX.ww902.siemens.net> CC: 'Samuel Erdtman' From: Ludwig Seitz Message-ID: <28fbfdb2-9880-11b7-1e26-47fc7889a12c@ri.se> Date: Tue, 8 May 2018 08:54:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162) X-Outbound-IP: 194.218.146.197 X-Env-From: ludwig.seitz@ri.se X-Proto: esmtps X-Revdns: X-HELO: sp-mail-2.sp.se X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128 X-Authenticated_ID: X-PolicySMART: 14510320 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 08 May 2018 06:54:39 -0000 On 2018-05-07 19:59, Mohit Sethi wrote: > Hi Matthias, > > Thanks for bringing forward the use-case. > > I have implemented an earlier version of the RD. I agree, the current > text on "mostly mandatory" leaves much to be desired. And +1 on request > for more clear text about different possibilities (cf. certificate vs > Raw Public Key vs PSK). > > --Mohit Samuel and I have thought about a similar issue in the ACE context (i.e. mapping PSK and RPK to endpoint identifiers, see https://tools.ietf.org/html/draft-erdtman-ace-rpcc-02). For RPK I like the method implemented in Californium quite much (thanks Matthias I guess), based on RFC 6920 section 3 (ni URI format). Here's the relevant text form our draft: "Note to implementers: Authorization servers can use the following method to map a Raw Public Key to a client identifier: The client identifier is generated from the Raw Public Key using the procedure specified in section 3 of [RFC6920]. The digest is calculated on the Raw Public Key only (not on the SubjectPublicKeyInfo used in the handshake). An example is shown in Figure 1." /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Tue May 8 00:22:32 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D27D12D877 for ; Tue, 8 May 2018 00:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 sHkKvGSka4hn for ; Tue, 8 May 2018 00:22:28 -0700 (PDT) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 2E0EB12711E for ; Tue, 8 May 2018 00:22:27 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:206]) by smtp-cloud9.xs4all.net with ESMTPA id Fwx6fir8FHgC9Fwx6fIb7G; Tue, 08 May 2018 09:22:24 +0200 Received: from AMontpellier-654-1-136-226.w90-0.abo.wanadoo.fr ([90.0.95.226]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 08 May 2018 09:22:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 08 May 2018 09:22:24 +0200 From: peter van der Stok To: "Kovatsch, Matthias" Cc: Hannes Tschofenig , Mohit Sethi , core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01F36340@DEFTHW99EL4MSX.ww902.siemens.net> References: <4EBB3DDD0FBF694CA2A87838DF129B3C01F36340@DEFTHW99EL4MSX.ww902.siemens.net> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfKWMyqnKUGyZRJUlXl+Ar2cFQP45bsF9mX9MZeZ+pmsQi0fh8qIkTUiuA4CEVP2QXKIagME1G5R0maHEn6K0OcsBqXvREE60NRAf9iQ8xC8S25d3ZD1a iWRcnyUdeHuspGzUE9zDHTl/xw/optov4G7vnDm4ofxGu9Yna9nejQfXIoh11p9bDOhnC29ff45xy+SLdCO3NM25/tMUIPj6owbWO7aBGj92lylJQFfxPUUR W8YORYRMbr/MSSO56IeEYdLztnr+RSSCRVbrx3yNYCo= Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 08 May 2018 07:22:31 -0000 Kovatsch, Matthias schreef op 2018-05-07 18:09: > Dear Hannes, > > dear list > > To my knowledge, third-party provisioning functionality is in > particular used for lighting systems; maybe Peter can comment on this. On request, some background. For buildings, the installation is done by installation companies with their own tools and procedures. Installation can be done in phases by different companies. Their is at this moment not one general approach or installation protocol. The problem is that the architect and people around have produced drawings with cabling and equipment situated at precise physical locations in the drawing. Equipment, cabling etc are identified with numbers ,names, what have you. There are descriptions which discuss the functionality and the relation between the equipment. All this knowledge has to be transferred to the equipment without making too many "one of a kind" pieces. In he "olde times" much was solved by the cabling, that limited the control possibilities. These IP times, anything can reach anything else. One approach is to store parts of this information into the RD, which can be queried by the equipment. I hope this make the wish for an RD with third party access understandable. From nobody Tue May 8 00:35:52 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4371D1270B4 for ; Tue, 8 May 2018 00:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 H_QPQ4DkTBCF for ; Tue, 8 May 2018 00:35:49 -0700 (PDT) Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (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 3F35912704A for ; Tue, 8 May 2018 00:35:49 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:200]) by smtp-cloud8.xs4all.net with ESMTPA id Fx9zf3Y4pJwIgFx9zf2xoT; Tue, 08 May 2018 09:35:43 +0200 Received: from AMontpellier-654-1-136-226.w90-0.abo.wanadoo.fr ([90.0.95.226]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 08 May 2018 09:35:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 08 May 2018 09:35:43 +0200 From: peter van der Stok To: Hannes Tschofenig Cc: core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <9970c70fea6ea457c74c8ae3ca303f76@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfFNpC5rHgZYK7i7PDm2+/jmpoiMTUQumrrDDNgw1nb+WMsO9laPrsrVplL51fw2JmjnrVixyAAiwEqfaBrSB98jrZcRN2eBcF86ZdHzZ79Qac5mueYk/ +nchxsIrGVy2zE/uYNjFpgc13VpKq+9O03ABIthkVItVg3J9u2B7cBIfZRofe2cojXsYQEDLUUmOBLV9O1ldfohzIQoqvU9K+SsI85z0GmATm09TKDakPXW/ Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 08 May 2018 07:35:51 -0000 Hi Hannes, Hannes Tschofenig schreef op 2018-05-07 15:50: > Hi all, > > I hope that all the discussion around the endpoint name / endpoint > client name have helped to make you think about the security > implications of sending an unauthenticated identifier. To summarize what I understand. A token provided by the authorization server (AS) contains the authenticated endpoint value (eventually the domain value). This endpoint value can be provided by the AS client or is provided by the AS. Provision by the AS client makes the token larger. > > I would like to come to a conclusion and here is my attempt. > > Since we the RD document also defines the third party provisioning I > would suggest to make the endpoint name optional in the draft. I probably misunderstand the meaning of optional. What I understand from making ep optional, is that ep is not returned in the lookup interface unless explicitly requested Differentiation between registrations (endpoints) cannot be done by ep (,d) value, but should be done differently (how?). > > I would also encourage the chairs to find out whether the third party > provisioning is actually something in this group has gained some > experience with. I sent an earlier e-mail about this subject, I hope it was clear enough > > Ciao I am not clear how to go forward. I could imagine an additional draft that specifies how to use RD with the AS and additional functionality needed in AS and RD. Peter > > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue May 8 01:08:07 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738471270A0; Tue, 8 May 2018 01:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 0yTjUc8qLNvc; Tue, 8 May 2018 01:07:51 -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 28F05120726; Tue, 8 May 2018 01:07:49 -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 w4887j78000459; Tue, 8 May 2018 10:07:45 +0200 (CEST) Received: from [192.168.182.168] (LMontsouris-657-1-54-35.w80-11.abo.wanadoo.fr [80.11.67.35]) (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 40gBtR5gxPzDXmc; Tue, 8 May 2018 10:07:43 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-D3398F3D-39C9-4D92-ADC7-74FD9696B4FF Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (15E302) In-Reply-To: <20180508000154.GY84491@kduck.kaduk.org> Date: Tue, 8 May 2018 10:07:41 +0200 Cc: =?utf-8?Q?Ari_Ker=C3=A4nen?= , core , "core-chairs@ietf.org" , The IESG , "draft-ietf-core-senml@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <44DB4CCE-62E7-43FF-9E0B-9AF27E14EE87@tzi.org> References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> <20180508000154.GY84491@kduck.kaduk.org> To: Benjamin Kaduk Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 08 May 2018 08:08:00 -0000 --Apple-Mail-D3398F3D-39C9-4D92-ADC7-74FD9696B4FF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable One interesting consequence of the "now" interpretation is that we can't sen= d an actuator message that says "switch on the light five seconds from now".= I think this limitation (which became relevant late as we started thinking a= bout actuator messages late) is indeed worth mention -- more so than saying t= he more inconsequential "you can't express a measurement you will take five s= econds later than sending it".=20 Sent from mobile >> On 8. May 2018, at 02:01, Benjamin Kaduk wrote: >>=20 >> On Mon, May 07, 2018 at 05:55:59PM +0000, Ari Ker=C3=A4nen wrote: >>=20 >> We have now submitted a new revision of the SenML draft that addresses al= l the IESG review comments: >> https://tools.ietf.org/html/draft-ietf-core-senml-15 >>=20 >> For answers to your review comments, please see below. >=20 > Thanks for the updates, they are definitely improvements! A few > comments inline. >=20 >>=20 >>> On 19 Apr 2018, at 5.33, Benjamin Kaduk wrote: >>>=20 >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>>=20 >>> I agree with Ben's DISCUSS. >>=20 >> This was addressed in the updated security considerations text: >> https://github.com/core-wg/senml-spec/pull/106/commits/b911090ce2d12d394d= 243658f636522bb3dcc335 >>=20 >> https://tools.ietf.org/html/draft-ietf-core-senml-15#section-13 >=20 > I would of course like to hear from Ben as well, but it would > probably be good to say a bit more about what "proper security > mechanisms" are, perhaps that they are use "to provide data > integrity, confidentiality, and source authentication as appropriate > for the usage". >=20 >>> Additionally, I have serious reservations about introducing the >>> concept of "base fields" that apply to subsequent array elemnets >>> unless overridden. It seems to violate an abstraction barrier for >>> at least some of the serialization formats, and prevents snippets >>> from being composable and commutable absent the >>> resolution/normalization process. It does not seem like the markup >>> language and the document contain suffient safeguards against misuse >>> to prevent security holes (both sensor data and commands could be >>> misinterpreted). It seems that some substantially expanded text >>> should be added on the hazards of the non-resolved format and giving >>> guidance on when resolution/normalization must be performed in order >>> to avoid correctness and security issues. >>=20 >> The base values feature is something that the WG decided is important to h= ave. We added now text about the security implications and remedies, also ta= king into account Alexey's follow-ups in this thread: https://github.com/cor= e-wg/senml-spec/pull/109/files >=20 > The text about use outside of a Pack is probably the minimal change > needed on this issue (though of course I would not object if more > text was added, perhaps noting that "the smallest functional quantum > for non-resolved SenML Records is the Pack, that provides the needed > context for the Base Values"). But please use your judgment on what > volume of discussion is appropriate given the intended usage and > audience. >=20 >>> There also seem to be sizeable risks associated with the semantics >>> for time values. In particular, both with the use of an >>> implicit-"now-ish", and with positive and negative values being >>> interpreted with respect to a different absolute time base. (The >>> involvement of base time is a further complication -- I do not >>> remember any discussion of the interaction of a (positive) base time >>> and a negative regular time, for example. I also do not remember >>> any discussion of how the "now-ish" semantics make it actively >>> harmful to do things like store-and-forward or archive SenML data >>> (again, absent normalization), or what sort of granularity the >>> "now-ish" semantics are expected to adhere to. (Is "yesterday" >>> still considered "roughly now"?) I understand the desire for this >>> sort of semantics, but the current specification seems to leave many >>> potential problems exposed. >>=20 >> We clarified the "now" issue (also to address other comments on this topi= c). The new text in section 4.5.3 says: >>=20 >> Obviously, "now"-referenced SenML records are only useful within a >> specific communication context (e.g., based on information on when >> the SenML pack, or a specific record in a SensML stream, was sent) or >> together with some other context information that can be used for >> deriving a meaning of "now"; the expectation for any archival use is >> that they will be processed into UTC-referenced records before that >> context would cease to be available. This specification deliberately >> leaves the accuracy of "now" very vague as it is determined by the >> overall systems that use SenML. In a system where a sensor without >> wall-clock time sends a SenML record with a "now"-referenced time >> over a high speed RS 485 link to an embedded system with accurate >> time that resolves "now" based on the time of reception, the >> resulting time uncertainty could be within 1 ms. At the other >> extreme, a deployment that sends SenML wind speed readings over a LEO >> satellite link from a mountain valley might have resulting reception >> time values that are easily a dozen minutes off the actual time of >> the sensor reading, with the time uncertainty depending on satellite >> locations and conditions. >=20 > This is definitely helpful to have, but I think I still have some > questions about how things work. (Perhaps they can be answered in > this thread and no change to the document would be needed.) >=20 > The existing text seems to be pretty clear that the base time and > (non-base) time are first added, and then the special semantics for > positive and non-positive values are applied. Things could > potentially get exciting in some scenarios, though, as a collection > of Records (whether Pack or streaming) could cross over the > discontinuity. Consider, for example, a small negative base time, > and a series of records with increasing time values, that cross the > zero threshold and suddenly appear decades in the past. Do we need > to say more to warn about this possibility, or is it perhaps better > to only give the special semantics to one of the (base time, time) > values and not their sum? (I guess it would have to be something a > little complicated like "if base time is present, it gets the > special semantics and time is added to it, but if base time is not > present then time gets special semantics".) >=20 >>=20 >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >=20 > Thanks for all these updates, they look good. >=20 > -Benjamin >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 --Apple-Mail-D3398F3D-39C9-4D92-ADC7-74FD9696B4FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
One interestin= g consequence of the "now" interpretation is that we can't send an actuator m= essage that says "switch on the light five seconds from now". I think this l= imitation (which became relevant late as we started thinking about actuator m= essages late) is indeed worth mention -- more so than saying the more incons= equential "you can't express a measurement you will take five seconds later t= han sending it". 

Sent from = mobile

On 8. May 2018,= at 02:01, Benjamin Kaduk <kaduk@mit.edu= > wrote:

On Mon, Ma= y 07, 2018 at 05:55:59PM +0000, Ari Ker=C3=A4nen wrote:

We have now submitted a new revision of the SenML draft that addresses all= the IESG review comments:
= https= ://tools.ietf.org/html/draft-ietf-core-senml-15
<= blockquote type=3D"cite">
For answers to your review comments, please see below.
=

Thanks for the updates, they are definit= ely improvements!  A few
comments inline.


On 19 Apr 2018, at 5.33,= Benjamin Kaduk <kaduk@MIT.EDU> w= rote:

---------------------------------= -------------------------------------
DISCUSS:
<= /blockquote>
---------------------------------------------------------------------= -

I agree with Ben's DISCUSS.
=

This was addressed in the updated secu= rity considerations text:
<= span>https://github.com/core-wg/senml-spec/p= ull/106/commits/b911090ce2d12d394d243658f636522bb3dcc335

https://tools.ietf.org/html/draft-ietf-core-senml-15#sect= ion-13

I would of course l= ike to hear from Ben as well, but it would
probably be good t= o say a bit more about what "proper security
mechanisms" are= , perhaps that they are use "to provide data
integrity, conf= identiality, and source authentication as appropriate
for th= e usage".

Additionally, I have serious reservations about introduci= ng the
concept of "base fields" that apply to subsequent a= rray elemnets
=
unless overridden.  It seems to violate= an abstraction barrier for
at least some of the serializat= ion formats, and prevents snippets
from being composable a= nd commutable absent the
resolution/normalization process.=  It does not seem like the markup
=
language and the d= ocument contain suffient safeguards against misuse
to prev= ent security holes (both sensor data and commands could be
misinterpreted).  It seems that some substantially expanded text
should be added on the hazards of the non-resolved format and g= iving
guidance on when resolution/normalization must be pe= rformed in order
to avoid correctness and security issues.=
=
The base values feature is s= omething that the WG decided is important to have. We added now text about t= he security implications and remedies, also taking into account Alexey's fol= low-ups in this thread: https://github.com/core-wg/senml-spec/pull/109/files=

The text about use outside of a Pack= is probably the minimal change
needed on this issue (though= of course I would not object if more
text was added, perhap= s noting that "the smallest functional quantum
for non-resol= ved SenML Records is the Pack, that provides the needed
cont= ext for the Base Values").  But please use your judgment on what=
volume of discussion is appropriate given the intended usage and
audience.

There also seem to be sizeable risks assoc= iated with the semantics
for time values.  In particu= lar, both with the use of an
implicit-"now-ish", and with p= ositive and negative values being
interpreted with respect= to a different absolute time base.  (The
involvement= of base time is a further complication -- I do not
<= /blockquote>
rememb= er any discussion of the interaction of a (positive) base time
<= span>and a negative regular time, for example.  I also do not remember<= /span>
any discussion of how the "now-ish" semantics make it acti= vely
harmful to do things like store-and-forward or archiv= e SenML data
<= blockquote type=3D"cite">(again, absent normalization), or what sort o= f granularity the
"now-ish" semantics are expected to adhe= re to.  (Is "yesterday"
still considered "roughly now= "?)  I understand the desire for this
sort of semanti= cs, but the current specification seems to leave many
pote= ntial problems exposed.

We c= larified the "now" issue (also to address other comments on this topic). The= new text in section 4.5.3 says:

 O= bviously, "now"-referenced SenML records are only useful within a
=
 specific communication c= ontext (e.g., based on information on when
 the SenML pack, or a specific record in a SensM= L stream, was sent) or
 together with some other context information that can be used for
 deriving a mean= ing of "now"; the expectation for any archival use is
 that they will be processed into UTC= -referenced records before that
 context would cease to be available.  This specificat= ion deliberately
&nb= sp;leaves the accuracy of "now" very vague as it is determined by the=
 overall systems that= use SenML.  In a system where a sensor without
=
 wall-clock time sends a SenML record w= ith a "now"-referenced time
 over a high speed RS 485 link to an embedded system with accur= ate
 time that r= esolves "now" based on the time of reception, the
 resulting time uncertainty could be with= in 1 ms.  At the other
 extreme, a deployment that sends SenML wind speed readings ove= r a LEO
 satell= ite link from a mountain valley might have resulting reception
 time values that are easily= a dozen minutes off the actual time of
 the sensor reading, with the time uncertainty depe= nding on satellite
&= nbsp;locations and conditions.

This is definitely helpful to have, but I think I still have somequestions about how things work.  (Perhaps they can be answered i= n
this thread and no change to the document would be needed.= )

The existing text seems to be pretty clea= r that the base time and
(non-base) time are first added, an= d then the special semantics for
positive and non-positive v= alues are applied.  Things could
potentially get exciti= ng in some scenarios, though, as a collection
of Records (wh= ether Pack or streaming) could cross over the
discontinuity.=  Consider, for example, a small negative base time,
an= d a series of records with increasing time values, that cross the
= zero threshold and suddenly appear decades in the past.  Do we ne= ed
to say more to warn about this possibility, or is it perh= aps better
to only give the special semantics to one of the (= base time, time)
values and not their sum?  (I guess it= would have to be something a
little complicated like "if ba= se time is present, it gets the
special semantics and time i= s added to it, but if base time is not
present then time get= s special semantics".)

=
----------------------------------------------------------------= ------
COMMENT:
------------------------= ----------------------------------------------

Thanks for all these updates, they look good.<= /span>

-Benjamin

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


= --Apple-Mail-D3398F3D-39C9-4D92-ADC7-74FD9696B4FF-- From nobody Tue May 8 04:20:36 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D78212D943 for ; Tue, 8 May 2018 04:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 fQ2VNSfVNTJr for ; Tue, 8 May 2018 04:20:28 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00079.outbound.protection.outlook.com [40.107.0.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D02612D944 for ; Tue, 8 May 2018 04:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P0D+sZWg0tyj0U0LJ5qO7PX6jsx4wevO85rNugpBzTQ=; b=mWOTh8xdzzjg3Lx4WQQCMegA3qfqeqIOpteo2OYUXUKV5jBJu9rzFbocTvs5SovLfiCYXqccjvZIXGhZ/ybSvKxRontpKck3YzYZjVCm2OnRGhSA6qKh+xG6QgTiSrJ2UcCJI4eDSTBuNJOi2rzhrZiHHpNRRvC1sXcmU7Btgr8= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1293.eurprd08.prod.outlook.com (10.167.197.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.17; Tue, 8 May 2018 11:20:24 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::4004:973e:4b3:ef88]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::4004:973e:4b3:ef88%18]) with mapi id 15.20.0735.018; Tue, 8 May 2018 11:20:24 +0000 From: Hannes Tschofenig To: "consultancy@vanderstok.org" , "Kovatsch, Matthias" CC: Mohit Sethi , "core@ietf.org" Thread-Topic: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPmCfncz1IX5t6GRJaeO0C+mMHM9QAAOSUAAADDndAAA/ZdAAAf4kIAAAgtFAA= Date: Tue, 8 May 2018 11:20:24 +0000 Message-ID: References: <4EBB3DDD0FBF694CA2A87838DF129B3C01F36340@DEFTHW99EL4MSX.ww902.siemens.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [213.120.252.178] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1293; 7:KBuAvJc7o7pOUblJmEQj/fXcsBWTmnSYl/k5LTaGIDGh2J6crWszciH+T4FFCxBtJexVkDRGejoZkEGM9zGbto9/2Srwk9kHJQfI/tHp1ZzqddbxEZzfcYIayVLC/rJLJzqmVha4/BPr9IVxYXN5x3NNuL+/LT9nAgn+HJJuW18RjwZrkvNK/DnFy2d37LVJnAd46HtYOTuoO8E5qKFvGbTiQczeahBJphYsQTxufqa3Lz+M/Q135bK5Iysz4VuV x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1293; x-ms-traffictypediagnostic: VI1PR0801MB1293: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0801MB1293; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1293; x-forefront-prvs: 0666E15D35 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(366004)(39380400002)(396003)(376002)(189003)(199004)(40434004)(377424004)(13464003)(110136005)(66066001)(55016002)(54906003)(25786009)(478600001)(53936002)(9686003)(476003)(2906002)(6246003)(486006)(4326008)(102836004)(72206003)(74316002)(3280700002)(86362001)(68736007)(59450400001)(316002)(3660700001)(105586002)(6506007)(26005)(53546011)(6116002)(8676002)(93886005)(3846002)(76176011)(7736002)(7696005)(33656002)(99286004)(8936002)(305945005)(5250100002)(446003)(229853002)(186003)(5660300001)(14454004)(106356001)(5890100001)(81166006)(97736004)(2501003)(81156014)(11346002)(6436002)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1293; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: CNIBDYp6q8atOu72Tva0cXhjzeNLW6V50TDBuwKEjrijIw2qoo1CbjQHLnli7BSZpZBMiBqAYpr+N1ZwTN4v3Sv2Cfy8YXq4nJNpgrM+RV+azvX5pqZMAK6jhHsZwfzzIHjia1eys7uPN634GdcWUkczRy2zitA7490/uxPH1TEeYhl1HEOrb5Zp/IvuKE/g spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: e46ff2b6-2be2-4357-0d75-08d5b4d5b1c3 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: e46ff2b6-2be2-4357-0d75-08d5b4d5b1c3 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2018 11:20:24.5083 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1293 Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 08 May 2018 11:20:34 -0000 Peter, I would personally feel more comfortable if we standardize functionality th= at some people have gained some experience already. If we don't involve the= domain experts then we will most likely get it wrong. What about separating this functionality from the RD draft, reach out to th= ese companies, and then put the result of the investigations into a separat= e document? There are some folks in the group who work closely with indoor = commercial lighting companies and they could for sure help. Ciao Hannes -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl] Sent: 08 May 2018 08:22 To: Kovatsch, Matthias Cc: Hannes Tschofenig; Mohit Sethi; core@ietf.org Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in R= D draft Kovatsch, Matthias schreef op 2018-05-07 18:09: > Dear Hannes, > > dear list > > To my knowledge, third-party provisioning functionality is in > particular used for lighting systems; maybe Peter can comment on this. On request, some background. For buildings, the installation is done by installation companies with thei= r own tools and procedures. Installation can be done in phases by different companies. Their is at this moment not one general approach or installation protocol. The problem is that the architect and people around have produced drawings = with cabling and equipment situated at precise physical locations in the dr= awing. Equipment, cabling etc are identified with numbers ,names, what have you. There are descriptions which discuss the functionality and the relation bet= ween the equipment. All this knowledge has to be transferred to the equipment without making to= o many "one of a kind" pieces. In he "olde times" much was solved by the cabling, that limited the control= possibilities. These IP times, anything can reach anything else. One approach is to store parts of this information into the RD, which can b= e queried by the equipment. I hope this make the wish for an RD with third party access understandable. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Tue May 8 11:57:23 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99DE129C6D for ; Tue, 8 May 2018 11:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.331 X-Spam-Level: X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt7CzShJawNp for ; Tue, 8 May 2018 11:57:18 -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 6B7D41270AC for ; Tue, 8 May 2018 11:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525805833; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=H4kAi98y76JNZwK+G3A3qrbGwUkI0JStJ8o/V07ONt4=; b=b++vYtrQoug0yPRNo2Z287bUjhM91qSaG/EoFu5/QzYc/EMqbXjif2MAgnj9QRBM RKn5GqeG0Lvi5Xf4RY0GX++8iltYWMJ7/yzrwXXxCkNVBv19Ql4sDV0RzN9WeuC3 xMOMWzA9QI2KCF7P7Un78XbPrZK/K0wCwKqhcyoIVyo=; X-AuditID: c1b4fb25-fa3ff700000079fb-e6-5af1f309352b Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C8.3D.31227.903F1FA5; Tue, 8 May 2018 20:57:13 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSHC008.ericsson.se (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 8 May 2018 20:57:13 +0200 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 8 May 2018 20:57:12 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Tue, 8 May 2018 20:57:12 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Benjamin Kaduk CC: The IESG , "draft-ietf-core-senml@ietf.org" , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core-chairs@ietf.org" , core Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) Thread-Index: AQHT14bG3vAIeJGLoECcXBuH3Y6fJ6QkiLkAgABmQYCAAT0wAA== Date: Tue, 8 May 2018 18:57:12 +0000 Message-ID: <3C160A2B-D307-4504-A20C-082F5953952C@ericsson.com> References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> <20180508000154.GY84491@kduck.kaduk.org> In-Reply-To: <20180508000154.GY84491@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="utf-8" Content-ID: <0328D7CC342CC84DB919815FDC827D99@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGIsWRmVeSWpSXmKPExsUyM2K7li7n549RBgtaTS22bbzAZrHv7Xpm i5/vljBbzPgzkdli+caZTA6sHkuW/GTyaDpzlDmAKYrLJiU1J7MstUjfLoErY+PRQ8wFV4Ir rk7na2A8ENjFyMEhIWAisW5GWBcjF4eQwBFGiU9/VzJDOJsZJZbtesgO4XxllNiyYBNbFyMn kLOUUWJ1qySIzSZgK/GkdR8riC0ioCSx+GwLG0gDs8BLRonXD3sZQRLCAvESe+81skMUJUhc 2zWdBcJ2ktjet50JxGYRUJFouPmXGcTmFbCXuP5zBSPE5rWMErs+vGQCuZVTwFTi83QBkBpG ATGJ76fWgPUyC4hL3HoyH8yWEBCQWLLnPDOELSrx8vE/VghbSWLvsessIGOYBTQl1u/Sh2i1 lli6ZxHUGEWJKd0P2SFOEJQ4OfMJC8S/qhJX/71inMAoOQvJtlkIk2YhmTQLyaRZSCYtYGRd xShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYuwe3/FbdwXj5jeMhRgEORiUe3pz0j1FCrIll xZW5hxglOJiVRHiVZYFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR+ab44SEkhPLEnNTk0tSC2C yTJxcEo1MAp5/5KxMzjHeu5o3PHsb8ef6jFxJV1wnRdxUI3t5O7E5qZk3spDwXMrkkQ3C5za tDEvZWW/hPb8X9OnSmyr6p+7eLfc7QfLrV0Moj+/MvUQnSRbLPX4w8fPG5RcHu8S/NNp6366 WmjT7PTdl2Q/rDsW7Knefo059euHeuaXGnz71r75/fH3uzwlluKMREMt5qLiRADp0Rf32QIA AA== Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 08 May 2018 18:57:21 -0000 DQoNCj4gT24gOCBNYXkgMjAxOCwgYXQgMy4wMSwgQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5l ZHU+IHdyb3RlOg0KPiANCj4gT24gTW9uLCBNYXkgMDcsIDIwMTggYXQgMDU6NTU6NTlQTSArMDAw MCwgQXJpIEtlcsOkbmVuIHdyb3RlOg0KPj4gDQo+PiBXZSBoYXZlIG5vdyBzdWJtaXR0ZWQgYSBu ZXcgcmV2aXNpb24gb2YgdGhlIFNlbk1MIGRyYWZ0IHRoYXQgYWRkcmVzc2VzIGFsbCB0aGUgSUVT RyByZXZpZXcgY29tbWVudHM6DQo+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1jb3JlLXNlbm1sLTE1DQo+PiANCj4+IEZvciBhbnN3ZXJzIHRvIHlvdXIgcmV2aWV3IGNv bW1lbnRzLCBwbGVhc2Ugc2VlIGJlbG93Lg0KPiANCj4gVGhhbmtzIGZvciB0aGUgdXBkYXRlcywg dGhleSBhcmUgZGVmaW5pdGVseSBpbXByb3ZlbWVudHMhICBBIGZldw0KPiBjb21tZW50cyBpbmxp bmUuDQoNClRoYW5rIHlvdSBmb3IgeW91ciBmYXN0IHJlcGx5IEJlbiEgDQoNCkknbGwgYW5zd2Vy IG5vdyBiZWxvdyAobW9zdGx5KSBqdXN0IG9uIG15IGJlaGFsZiAoaXQgdGFrZXMgYWx3YXlzIGEg Yml0IG9mIGV4dHJhIHRpbWUgdG8gZ2V0IGNvbnNlbnN1cyBhY3Jvc3MgbXVsdGlwbGUgYXV0aG9y cyBpbiBtdWx0aXBsZSB0aW1lIHpvbmVzIGFuZCB3aXRoIGJ1c3kgc2NoZWR1bGVzKS4NCg0KPj4+ IE9uIDE5IEFwciAyMDE4LCBhdCA1LjMzLCBCZW5qYW1pbiBLYWR1ayA8a2FkdWtATUlULkVEVT4g d3JvdGU6DQo+Pj4gDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IERJU0NVU1M6DQo+Pj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4+IA0KPj4+IEkgYWdyZWUgd2l0aCBCZW4ncyBESVNDVVNTLg0KPj4gDQo+PiBU aGlzIHdhcyBhZGRyZXNzZWQgaW4gdGhlIHVwZGF0ZWQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg dGV4dDoNCj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL3Nlbm1sLXNwZWMvcHVsbC8xMDYv Y29tbWl0cy9iOTExMDkwY2UyZDEyZDM5NGQyNDM2NThmNjM2NTIyYmIzZGNjMzM1DQo+PiANCj4+ IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtc2VubWwtMTUjc2Vj dGlvbi0xMw0KPiANCj4gSSB3b3VsZCBvZiBjb3Vyc2UgbGlrZSB0byBoZWFyIGZyb20gQmVuIGFz IHdlbGwsIGJ1dCBpdCB3b3VsZA0KPiBwcm9iYWJseSBiZSBnb29kIHRvIHNheSBhIGJpdCBtb3Jl IGFib3V0IHdoYXQgInByb3BlciBzZWN1cml0eQ0KPiBtZWNoYW5pc21zIiBhcmUsIHBlcmhhcHMg dGhhdCB0aGV5IGFyZSB1c2UgInRvIHByb3ZpZGUgZGF0YQ0KPiBpbnRlZ3JpdHksIGNvbmZpZGVu dGlhbGl0eSwgYW5kIHNvdXJjZSBhdXRoZW50aWNhdGlvbiBhcyBhcHByb3ByaWF0ZQ0KPiBmb3Ig dGhlIHVzYWdlIi4NCg0KVGhpcyBzb3VuZHMgZ29vZCB0byBtZS4gSSBtYWRlIGEgc2ltcGxlIFBS IGZvciB0aGlzOg0KaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvc2VubWwtc3BlYy9wdWxsLzEy Ni9maWxlcw0KDQpJIGFkZGVkICJlLmcuIiB0byBwb2ludCBvdXQgdGhlc2UgYXJlIG5vdCB0aGUg b25seSBjb25zaWRlcmF0aW9ucyBhbmQgQ3VsbGVuIGFsc28gcG9pbnRlZCBvdXQgdGhhdCB0aGlz IGNvdWxkIGJlIGJldHRlciB3aXRob3V0ICJzb3VyY2UiIGluICJzb3VyY2UgYXV0aGVudGljYXRp b24iIHNpbmNlIGFsc28gb3RoZXIgYXV0aGVudGljYXRpb24gY291bGQgYmUgaW1wb3J0YW50LiBJ IGFncmVlIHdpdGggQ3VsbGVuIGhlcmU7IGlzIHRoYXQgT0sgY2hhbmdlIHRvIHlvdSB0b28/DQoN Cj4+PiBBZGRpdGlvbmFsbHksIEkgaGF2ZSBzZXJpb3VzIHJlc2VydmF0aW9ucyBhYm91dCBpbnRy b2R1Y2luZyB0aGUNCj4+PiBjb25jZXB0IG9mICJiYXNlIGZpZWxkcyIgdGhhdCBhcHBseSB0byBz dWJzZXF1ZW50IGFycmF5IGVsZW1uZXRzDQo+Pj4gdW5sZXNzIG92ZXJyaWRkZW4uICBJdCBzZWVt cyB0byB2aW9sYXRlIGFuIGFic3RyYWN0aW9uIGJhcnJpZXIgZm9yDQo+Pj4gYXQgbGVhc3Qgc29t ZSBvZiB0aGUgc2VyaWFsaXphdGlvbiBmb3JtYXRzLCBhbmQgcHJldmVudHMgc25pcHBldHMNCj4+ PiBmcm9tIGJlaW5nIGNvbXBvc2FibGUgYW5kIGNvbW11dGFibGUgYWJzZW50IHRoZQ0KPj4+IHJl c29sdXRpb24vbm9ybWFsaXphdGlvbiBwcm9jZXNzLiAgSXQgZG9lcyBub3Qgc2VlbSBsaWtlIHRo ZSBtYXJrdXANCj4+PiBsYW5ndWFnZSBhbmQgdGhlIGRvY3VtZW50IGNvbnRhaW4gc3VmZmllbnQg c2FmZWd1YXJkcyBhZ2FpbnN0IG1pc3VzZQ0KPj4+IHRvIHByZXZlbnQgc2VjdXJpdHkgaG9sZXMg KGJvdGggc2Vuc29yIGRhdGEgYW5kIGNvbW1hbmRzIGNvdWxkIGJlDQo+Pj4gbWlzaW50ZXJwcmV0 ZWQpLiAgSXQgc2VlbXMgdGhhdCBzb21lIHN1YnN0YW50aWFsbHkgZXhwYW5kZWQgdGV4dA0KPj4+ IHNob3VsZCBiZSBhZGRlZCBvbiB0aGUgaGF6YXJkcyBvZiB0aGUgbm9uLXJlc29sdmVkIGZvcm1h dCBhbmQgZ2l2aW5nDQo+Pj4gZ3VpZGFuY2Ugb24gd2hlbiByZXNvbHV0aW9uL25vcm1hbGl6YXRp b24gbXVzdCBiZSBwZXJmb3JtZWQgaW4gb3JkZXINCj4+PiB0byBhdm9pZCBjb3JyZWN0bmVzcyBh bmQgc2VjdXJpdHkgaXNzdWVzLg0KPj4gDQo+PiBUaGUgYmFzZSB2YWx1ZXMgZmVhdHVyZSBpcyBz b21ldGhpbmcgdGhhdCB0aGUgV0cgZGVjaWRlZCBpcyBpbXBvcnRhbnQgdG8gaGF2ZS4gV2UgYWRk ZWQgbm93IHRleHQgYWJvdXQgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBhbmQgcmVtZWRpZXMs IGFsc28gdGFraW5nIGludG8gYWNjb3VudCBBbGV4ZXkncyBmb2xsb3ctdXBzIGluIHRoaXMgdGhy ZWFkOiBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9zZW5tbC1zcGVjL3B1bGwvMTA5L2ZpbGVz DQo+IA0KPiBUaGUgdGV4dCBhYm91dCB1c2Ugb3V0c2lkZSBvZiBhIFBhY2sgaXMgcHJvYmFibHkg dGhlIG1pbmltYWwgY2hhbmdlDQo+IG5lZWRlZCBvbiB0aGlzIGlzc3VlICh0aG91Z2ggb2YgY291 cnNlIEkgd291bGQgbm90IG9iamVjdCBpZiBtb3JlDQo+IHRleHQgd2FzIGFkZGVkLCBwZXJoYXBz IG5vdGluZyB0aGF0ICJ0aGUgc21hbGxlc3QgZnVuY3Rpb25hbCBxdWFudHVtDQo+IGZvciBub24t cmVzb2x2ZWQgU2VuTUwgUmVjb3JkcyBpcyB0aGUgUGFjaywgdGhhdCBwcm92aWRlcyB0aGUgbmVl ZGVkDQo+IGNvbnRleHQgZm9yIHRoZSBCYXNlIFZhbHVlcyIpLiAgQnV0IHBsZWFzZSB1c2UgeW91 ciBqdWRnbWVudCBvbiB3aGF0DQo+IHZvbHVtZSBvZiBkaXNjdXNzaW9uIGlzIGFwcHJvcHJpYXRl IGdpdmVuIHRoZSBpbnRlbmRlZCB1c2FnZSBhbmQNCj4gYXVkaWVuY2UuDQoNCkkgdGhpbmsgdGhl IGxhc3QgcGFydCBvZiB0aGUgdXBkYXRlZCAoaW4gLTE1KSBzZWN1cml0eSBzZWN0aW9uIG5vdyBl c3NlbnRpYWxseSBzYXlzIHRoYXQ6DQoNCiAgIFNlbk1MIFJlY29yZHMgYXJlIGludGVuZGVkIHRv IGJlIGludGVycHJldGVkIGluIHRoZSBjb250ZXh0IG9mIGFueQ0KICAgYXBwbGljYWJsZSBiYXNl IHZhbHVlcy4gIElmIHJlY29yZHMgYmVjb21lIHNlcGFyYXRlZCBmcm9tIHRoZSByZWNvcmQNCiAg IHRoYXQgZXN0YWJsaXNoZXMgdGhlIGJhc2UgdmFsdWVzLCB0aGUgZGF0YSB3aWxsIGJlIHVzZWxl c3Mgb3IsIHdvcnNlLA0KICAgd3JvbmcuICBDYXJlIG5lZWRzIHRvIGJlIHRha2VuIGluIGtlZXBp bmcgdGhlIGludGVncml0eSBvZiBhIFBhY2sNCiAgIHRoYXQgY29udGFpbnMgdW5yZXNvbHZlZCBT ZW5NTCBSZWNvcmRzIChzZWUgU2VjdGlvbiA0LjYpLg0KDQooaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtY29yZS1zZW5tbC0xNSNzZWN0aW9uLTEzKQ0KDQo+Pj4gVGhlcmUg YWxzbyBzZWVtIHRvIGJlIHNpemVhYmxlIHJpc2tzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2VtYW50 aWNzDQo+Pj4gZm9yIHRpbWUgdmFsdWVzLiAgSW4gcGFydGljdWxhciwgYm90aCB3aXRoIHRoZSB1 c2Ugb2YgYW4NCj4+PiBpbXBsaWNpdC0ibm93LWlzaCIsIGFuZCB3aXRoIHBvc2l0aXZlIGFuZCBu ZWdhdGl2ZSB2YWx1ZXMgYmVpbmcNCj4+PiBpbnRlcnByZXRlZCB3aXRoIHJlc3BlY3QgdG8gYSBk aWZmZXJlbnQgYWJzb2x1dGUgdGltZSBiYXNlLiAgKFRoZQ0KPj4+IGludm9sdmVtZW50IG9mIGJh c2UgdGltZSBpcyBhIGZ1cnRoZXIgY29tcGxpY2F0aW9uIC0tIEkgZG8gbm90DQo+Pj4gcmVtZW1i ZXIgYW55IGRpc2N1c3Npb24gb2YgdGhlIGludGVyYWN0aW9uIG9mIGEgKHBvc2l0aXZlKSBiYXNl IHRpbWUNCj4+PiBhbmQgYSBuZWdhdGl2ZSByZWd1bGFyIHRpbWUsIGZvciBleGFtcGxlLiAgSSBh bHNvIGRvIG5vdCByZW1lbWJlcg0KPj4+IGFueSBkaXNjdXNzaW9uIG9mIGhvdyB0aGUgIm5vdy1p c2giIHNlbWFudGljcyBtYWtlIGl0IGFjdGl2ZWx5DQo+Pj4gaGFybWZ1bCB0byBkbyB0aGluZ3Mg bGlrZSBzdG9yZS1hbmQtZm9yd2FyZCBvciBhcmNoaXZlIFNlbk1MIGRhdGENCj4+PiAoYWdhaW4s IGFic2VudCBub3JtYWxpemF0aW9uKSwgb3Igd2hhdCBzb3J0IG9mIGdyYW51bGFyaXR5IHRoZQ0K Pj4+ICJub3ctaXNoIiBzZW1hbnRpY3MgYXJlIGV4cGVjdGVkIHRvIGFkaGVyZSB0by4gIChJcyAi eWVzdGVyZGF5Ig0KPj4+IHN0aWxsIGNvbnNpZGVyZWQgInJvdWdobHkgbm93Ij8pICBJIHVuZGVy c3RhbmQgdGhlIGRlc2lyZSBmb3IgdGhpcw0KPj4+IHNvcnQgb2Ygc2VtYW50aWNzLCBidXQgdGhl IGN1cnJlbnQgc3BlY2lmaWNhdGlvbiBzZWVtcyB0byBsZWF2ZSBtYW55DQo+Pj4gcG90ZW50aWFs IHByb2JsZW1zIGV4cG9zZWQuDQo+PiANCj4+IFdlIGNsYXJpZmllZCB0aGUgIm5vdyIgaXNzdWUg KGFsc28gdG8gYWRkcmVzcyBvdGhlciBjb21tZW50cyBvbiB0aGlzIHRvcGljKS4gVGhlIG5ldyB0 ZXh0IGluIHNlY3Rpb24gNC41LjMgc2F5czoNCj4+IA0KPj4gIE9idmlvdXNseSwgIm5vdyItcmVm ZXJlbmNlZCBTZW5NTCByZWNvcmRzIGFyZSBvbmx5IHVzZWZ1bCB3aXRoaW4gYQ0KPj4gIHNwZWNp ZmljIGNvbW11bmljYXRpb24gY29udGV4dCAoZS5nLiwgYmFzZWQgb24gaW5mb3JtYXRpb24gb24g d2hlbg0KPj4gIHRoZSBTZW5NTCBwYWNrLCBvciBhIHNwZWNpZmljIHJlY29yZCBpbiBhIFNlbnNN TCBzdHJlYW0sIHdhcyBzZW50KSBvcg0KPj4gIHRvZ2V0aGVyIHdpdGggc29tZSBvdGhlciBjb250 ZXh0IGluZm9ybWF0aW9uIHRoYXQgY2FuIGJlIHVzZWQgZm9yDQo+PiAgZGVyaXZpbmcgYSBtZWFu aW5nIG9mICJub3ciOyB0aGUgZXhwZWN0YXRpb24gZm9yIGFueSBhcmNoaXZhbCB1c2UgaXMNCj4+ ICB0aGF0IHRoZXkgd2lsbCBiZSBwcm9jZXNzZWQgaW50byBVVEMtcmVmZXJlbmNlZCByZWNvcmRz IGJlZm9yZSB0aGF0DQo+PiAgY29udGV4dCB3b3VsZCBjZWFzZSB0byBiZSBhdmFpbGFibGUuICBU aGlzIHNwZWNpZmljYXRpb24gZGVsaWJlcmF0ZWx5DQo+PiAgbGVhdmVzIHRoZSBhY2N1cmFjeSBv ZiAibm93IiB2ZXJ5IHZhZ3VlIGFzIGl0IGlzIGRldGVybWluZWQgYnkgdGhlDQo+PiAgb3ZlcmFs bCBzeXN0ZW1zIHRoYXQgdXNlIFNlbk1MLiAgSW4gYSBzeXN0ZW0gd2hlcmUgYSBzZW5zb3Igd2l0 aG91dA0KPj4gIHdhbGwtY2xvY2sgdGltZSBzZW5kcyBhIFNlbk1MIHJlY29yZCB3aXRoIGEgIm5v dyItcmVmZXJlbmNlZCB0aW1lDQo+PiAgb3ZlciBhIGhpZ2ggc3BlZWQgUlMgNDg1IGxpbmsgdG8g YW4gZW1iZWRkZWQgc3lzdGVtIHdpdGggYWNjdXJhdGUNCj4+ICB0aW1lIHRoYXQgcmVzb2x2ZXMg Im5vdyIgYmFzZWQgb24gdGhlIHRpbWUgb2YgcmVjZXB0aW9uLCB0aGUNCj4+ICByZXN1bHRpbmcg dGltZSB1bmNlcnRhaW50eSBjb3VsZCBiZSB3aXRoaW4gMSBtcy4gIEF0IHRoZSBvdGhlcg0KPj4g IGV4dHJlbWUsIGEgZGVwbG95bWVudCB0aGF0IHNlbmRzIFNlbk1MIHdpbmQgc3BlZWQgcmVhZGlu Z3Mgb3ZlciBhIExFTw0KPj4gIHNhdGVsbGl0ZSBsaW5rIGZyb20gYSBtb3VudGFpbiB2YWxsZXkg bWlnaHQgaGF2ZSByZXN1bHRpbmcgcmVjZXB0aW9uDQo+PiAgdGltZSB2YWx1ZXMgdGhhdCBhcmUg ZWFzaWx5IGEgZG96ZW4gbWludXRlcyBvZmYgdGhlIGFjdHVhbCB0aW1lIG9mDQo+PiAgdGhlIHNl bnNvciByZWFkaW5nLCB3aXRoIHRoZSB0aW1lIHVuY2VydGFpbnR5IGRlcGVuZGluZyBvbiBzYXRl bGxpdGUNCj4+ICBsb2NhdGlvbnMgYW5kIGNvbmRpdGlvbnMuDQo+IA0KPiBUaGlzIGlzIGRlZmlu aXRlbHkgaGVscGZ1bCB0byBoYXZlLCBidXQgSSB0aGluayBJIHN0aWxsIGhhdmUgc29tZQ0KPiBx dWVzdGlvbnMgYWJvdXQgaG93IHRoaW5ncyB3b3JrLiAgKFBlcmhhcHMgdGhleSBjYW4gYmUgYW5z d2VyZWQgaW4NCj4gdGhpcyB0aHJlYWQgYW5kIG5vIGNoYW5nZSB0byB0aGUgZG9jdW1lbnQgd291 bGQgYmUgbmVlZGVkLikNCj4gDQo+IFRoZSBleGlzdGluZyB0ZXh0IHNlZW1zIHRvIGJlIHByZXR0 eSBjbGVhciB0aGF0IHRoZSBiYXNlIHRpbWUgYW5kDQo+IChub24tYmFzZSkgdGltZSBhcmUgZmly c3QgYWRkZWQsIGFuZCB0aGVuIHRoZSBzcGVjaWFsIHNlbWFudGljcyBmb3INCj4gcG9zaXRpdmUg YW5kIG5vbi1wb3NpdGl2ZSB2YWx1ZXMgYXJlIGFwcGxpZWQuICBUaGluZ3MgY291bGQNCj4gcG90 ZW50aWFsbHkgZ2V0IGV4Y2l0aW5nIGluIHNvbWUgc2NlbmFyaW9zLCB0aG91Z2gsIGFzIGEgY29s bGVjdGlvbg0KPiBvZiBSZWNvcmRzICh3aGV0aGVyIFBhY2sgb3Igc3RyZWFtaW5nKSBjb3VsZCBj cm9zcyBvdmVyIHRoZQ0KPiBkaXNjb250aW51aXR5LiAgQ29uc2lkZXIsIGZvciBleGFtcGxlLCBh IHNtYWxsIG5lZ2F0aXZlIGJhc2UgdGltZSwNCj4gYW5kIGEgc2VyaWVzIG9mIHJlY29yZHMgd2l0 aCBpbmNyZWFzaW5nIHRpbWUgdmFsdWVzLCB0aGF0IGNyb3NzIHRoZQ0KPiB6ZXJvIHRocmVzaG9s ZCBhbmQgc3VkZGVubHkgYXBwZWFyIGRlY2FkZXMgaW4gdGhlIHBhc3QuICBEbyB3ZSBuZWVkDQo+ IHRvIHNheSBtb3JlIHRvIHdhcm4gYWJvdXQgdGhpcyBwb3NzaWJpbGl0eSwgb3IgaXMgaXQgcGVy aGFwcyBiZXR0ZXINCj4gdG8gb25seSBnaXZlIHRoZSBzcGVjaWFsIHNlbWFudGljcyB0byBvbmUg b2YgdGhlIChiYXNlIHRpbWUsIHRpbWUpDQo+IHZhbHVlcyBhbmQgbm90IHRoZWlyIHN1bT8gIChJ IGd1ZXNzIGl0IHdvdWxkIGhhdmUgdG8gYmUgc29tZXRoaW5nIGENCj4gbGl0dGxlIGNvbXBsaWNh dGVkIGxpa2UgImlmIGJhc2UgdGltZSBpcyBwcmVzZW50LCBpdCBnZXRzIHRoZQ0KPiBzcGVjaWFs IHNlbWFudGljcyBhbmQgdGltZSBpcyBhZGRlZCB0byBpdCwgYnV0IGlmIGJhc2UgdGltZSBpcyBu b3QNCj4gcHJlc2VudCB0aGVuIHRpbWUgZ2V0cyBzcGVjaWFsIHNlbWFudGljcyIuKQ0KDQpHb29k IHBvaW50IHdpdGggdGhlIGRpc2NvbnRpbnVpdHkuIEl0IHNlZW1zIGxpa2Ugd29ydGggcG9pbnRp bmcgb3V0IHRoZSByaXNrIG9yIG1ha2luZyBiZXN0IHVzZSBvZiBpdC4NCg0KSSdsbCBoYXZlIGEg bG9vayBob3cgdG8gYmVzdCBhZGRyZXNzIHRoaXMuDQoNCg0KPj4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ PiBDT01NRU5UOg0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFRoYW5rcyBmb3IgYWxsIHRoZXNl IHVwZGF0ZXMsIHRoZXkgbG9vayBnb29kLg0KDQpUaGFuayB5b3Ugb25jZSBtb3JlIQ0KDQoNCkNo ZWVycywNCkFyaQ0KDQo= From nobody Tue May 8 12:02:14 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E0E127978; Tue, 8 May 2018 12:02:12 -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, 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 EJla-bYoCK25; Tue, 8 May 2018 12:02:10 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 D596112D77C; Tue, 8 May 2018 12:02:04 -0700 (PDT) X-AuditID: 12074422-601ff70000000aba-d2-5af1f429e0a1 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 55.B3.02746.A24F1FA5; Tue, 8 May 2018 15:02:03 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w48J1vsO028610; Tue, 8 May 2018 15:01:58 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w48J1qE3011343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 May 2018 15:01:54 -0400 Date: Tue, 8 May 2018 14:01:52 -0500 From: Benjamin Kaduk To: Ari =?iso-8859-1?Q?Ker=E4nen?= Cc: The IESG , "draft-ietf-core-senml@ietf.org" , Jaime =?iso-8859-1?Q?Jim=E9nez?= , "core-chairs@ietf.org" , core Message-ID: <20180508190151.GF84491@kduck.kaduk.org> References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> <20180508000154.GY84491@kduck.kaduk.org> <3C160A2B-D307-4504-A20C-082F5953952C@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3C160A2B-D307-4504-A20C-082F5953952C@ericsson.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsUixG6nrqv95WOUQc9DXotr1/6zWWzbeIHN Yt/b9cwWP98tYbaY8Wcis8XHvomsDmwev75eZfNYsuQnUwBTFJdNSmpOZllqkb5dAldG94v9 jAVHtSu6N09mamDsUO5i5OSQEDCR6Fq3mr2LkYtDSGAxk8SWv59ZIZwNjBLXmt5DZa4wSTza foAdpIVFQEXi/enZYDYbkN3QfZm5i5GDQ0TAVuL14TqQemaBf4wSt/feYwWpERaIl9h7rxGs nhdoXdPJbjaIoY8ZJbbO2sACkRCUODnzCZjNLKAjsXPrHTaQocwC0hLL/3FAhOUlmrfOZgax OQUcJJZdmwlmiwooS+ztO8Q+gVFwFpJJs5BMmoUwaRaSSQsYWVYxyqbkVunmJmbmFKcm6xYn J+blpRbpmurlZpbopaaUbmIER4CL0g7Gif+8DjEKcDAq8fBK7PwYJcSaWFZcmXuIUZKDSUmU 1+cDUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr7IsUI43JbGyKrUoHyYlzcGiJM4ruPlDlJBA emJJanZqakFqEUxWhoNDSYL39yegRsGi1PTUirTMnBKENBMHJ8hwHqDhgp9BhhcXJOYWZ6ZD 5E8xKkqJ87aDJARAEhmleXC9oAQlkb2/5hWjONArwryPQVbwAJMbXPcroMFMIIMfvAcZXJKI kJJqYJTfKhvUWZATZWHn+Uki9P3JzF0fLTddCW14uGZVveUMVTOWer6WnqbtfCfW6/s3H96w X8jIz7+n5tv8n3O5O+c/flXhErS3s0f1TsiSA5U696ZdXadu63tDvqBdNyzaJySwZPrqt+1M +ZNXBP6X4+zcfzsh2bzN6sE1o9azv2wSjv4SDHS9q8RSnJFoqMVcVJwIAJz0y5orAwAA Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 08 May 2018 19:02:13 -0000 On Tue, May 08, 2018 at 06:57:12PM +0000, Ari Keränen wrote: > > > > On 8 May 2018, at 3.01, Benjamin Kaduk wrote: > > > > On Mon, May 07, 2018 at 05:55:59PM +0000, Ari Keränen wrote: > >> > >> We have now submitted a new revision of the SenML draft that addresses all the IESG review comments: > >> https://tools.ietf.org/html/draft-ietf-core-senml-15 > >> > >> For answers to your review comments, please see below. > > > > Thanks for the updates, they are definitely improvements! A few > > comments inline. > > Thank you for your fast reply Ben! > > I'll answer now below (mostly) just on my behalf (it takes always a bit of extra time to get consensus across multiple authors in multiple time zones and with busy schedules). Understood. > >>> On 19 Apr 2018, at 5.33, Benjamin Kaduk wrote: > >>> > >>> ---------------------------------------------------------------------- > >>> DISCUSS: > >>> ---------------------------------------------------------------------- > >>> > >>> I agree with Ben's DISCUSS. > >> > >> This was addressed in the updated security considerations text: > >> https://github.com/core-wg/senml-spec/pull/106/commits/b911090ce2d12d394d243658f636522bb3dcc335 > >> > >> https://tools.ietf.org/html/draft-ietf-core-senml-15#section-13 > > > > I would of course like to hear from Ben as well, but it would > > probably be good to say a bit more about what "proper security > > mechanisms" are, perhaps that they are use "to provide data > > integrity, confidentiality, and source authentication as appropriate > > for the usage". > > This sounds good to me. I made a simple PR for this: > https://github.com/core-wg/senml-spec/pull/126/files > > I added "e.g." to point out these are not the only considerations and Cullen also pointed out that this could be better without "source" in "source authentication" since also other authentication could be important. I agree with Cullen here; is that OK change to you too? Yes, thanks. > >>> Additionally, I have serious reservations about introducing the > >>> concept of "base fields" that apply to subsequent array elemnets > >>> unless overridden. It seems to violate an abstraction barrier for > >>> at least some of the serialization formats, and prevents snippets > >>> from being composable and commutable absent the > >>> resolution/normalization process. It does not seem like the markup > >>> language and the document contain suffient safeguards against misuse > >>> to prevent security holes (both sensor data and commands could be > >>> misinterpreted). It seems that some substantially expanded text > >>> should be added on the hazards of the non-resolved format and giving > >>> guidance on when resolution/normalization must be performed in order > >>> to avoid correctness and security issues. > >> > >> The base values feature is something that the WG decided is important to have. We added now text about the security implications and remedies, also taking into account Alexey's follow-ups in this thread: https://github.com/core-wg/senml-spec/pull/109/files > > > > The text about use outside of a Pack is probably the minimal change > > needed on this issue (though of course I would not object if more > > text was added, perhaps noting that "the smallest functional quantum > > for non-resolved SenML Records is the Pack, that provides the needed > > context for the Base Values"). But please use your judgment on what > > volume of discussion is appropriate given the intended usage and > > audience. > > I think the last part of the updated (in -15) security section now essentially says that: > > SenML Records are intended to be interpreted in the context of any > applicable base values. If records become separated from the record > that establishes the base values, the data will be useless or, worse, > wrong. Care needs to be taken in keeping the integrity of a Pack > that contains unresolved SenML Records (see Section 4.6). > > (https://tools.ietf.org/html/draft-ietf-core-senml-15#section-13) Okay. (Now I have forgotten if I actually said or only intended to say, do you want to have a note about how when the streaming media type is used, the underlying transport must be reliable?) > > The existing text seems to be pretty clear that the base time and > > (non-base) time are first added, and then the special semantics for > > positive and non-positive values are applied. Things could > > potentially get exciting in some scenarios, though, as a collection > > of Records (whether Pack or streaming) could cross over the > > discontinuity. Consider, for example, a small negative base time, > > and a series of records with increasing time values, that cross the > > zero threshold and suddenly appear decades in the past. Do we need > > to say more to warn about this possibility, or is it perhaps better > > to only give the special semantics to one of the (base time, time) > > values and not their sum? (I guess it would have to be something a > > little complicated like "if base time is present, it gets the > > special semantics and time is added to it, but if base time is not > > present then time gets special semantics".) > > Good point with the discontinuity. It seems like worth pointing out the risk or making best use of it. > > I'll have a look how to best address this. Sure, I expect it to require some thought to figure out what's best. -Benjamin From nobody Wed May 9 01:03:06 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D193F12EAE1 for ; Wed, 9 May 2018 01:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 59FJaW3g3Zqc for ; Wed, 9 May 2018 01:03:02 -0700 (PDT) Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (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 E467412711E for ; Wed, 9 May 2018 01:03:01 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:213]) by smtp-cloud7.xs4all.net with ESMTPA id GK3sfkTdv8U07GK3sfu6wv; Wed, 09 May 2018 10:02:59 +0200 Received: from AMontpellier-654-1-136-226.w90-0.abo.wanadoo.fr ([90.0.95.226]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 09 May 2018 10:02:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 09 May 2018 10:02:56 +0200 From: peter van der Stok To: Hannes Tschofenig Cc: consultancy@vanderstok.org, "Kovatsch, Matthias" , Mohit Sethi , core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <4EBB3DDD0FBF694CA2A87838DF129B3C01F36340@DEFTHW99EL4MSX.ww902.siemens.net> Message-ID: <6d8a9b8a6c67f7f7022ace8bd9c8d374@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfBcFkP6Q9W71SPo/EyFc0Yk7xFdEuuQwtvkFKgMKUiUQeoOaLKbEg0budTaMA5S51j2aRW7KzrZZIzz2OFAqKLiSiPVuVD7zzFoE8qlBvuVm2gUPtcO9 nKKjz/uxwA55+BQbILoC3x/RJaJh1juBSVW23GZ+05fQ7ONtVjapkOm/S7zhJaaUBrhN1EH79hRqBRN9VQb1paDmXGrnNq34sOQICiPgd6ggIJ3kK8Q3wEDM ZYLcVYu6HxmhONezbA+5fE/x5QTb0sPAc8dHRJiyveaVvqARM6ILqR4AZ0ivaUen Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 09 May 2018 08:03:05 -0000 Hi Hannes, I share your concerns, But there are some additional aspects. for 3rd party registration the con= is used. con= will also be used to indicate alternative transports. Suppressing con= seems really a waste in this stage. On the other hand, even suppressing con= for third parties, the anchor attribute also permits to refer to third parties. Removing the anchor attribute is cumbersome to say the least. Possibly @others want to react. For the moment using con= for 3rd party registration creates one registration at the time. The Authorization server can also in this case assign endpoint values and prevent ep value stealing. I will try to get some concrete feedback on 3rd party registration. I will keep you informed. Peter Hannes Tschofenig schreef op 2018-05-08 13:20: > Peter, > > I would personally feel more comfortable if we standardize > functionality that some people have gained some experience already. If > we don't involve the domain experts then we will most likely get it > wrong. > > What about separating this functionality from the RD draft, reach out > to these companies, and then put the result of the investigations into > a separate document? There are some folks in the group who work > closely with indoor commercial lighting companies and they could for > sure help. > > Ciao > Hannes > > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: 08 May 2018 08:22 > To: Kovatsch, Matthias > Cc: Hannes Tschofenig; Mohit Sethi; core@ietf.org > Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name > in RD draft > > Kovatsch, Matthias schreef op 2018-05-07 18:09: >> Dear Hannes, >> >> dear list >> >> To my knowledge, third-party provisioning functionality is in >> particular used for lighting systems; maybe Peter can comment on this. > > On request, some background. > For buildings, the installation is done by installation companies with > their own tools and procedures. > Installation can be done in phases by different companies. > Their is at this moment not one general approach or installation > protocol. > > The problem is that the architect and people around have produced > drawings with cabling and equipment situated at precise physical > locations in the drawing. > Equipment, cabling etc are identified with numbers ,names, what have > you. > There are descriptions which discuss the functionality and the > relation between the equipment. > All this knowledge has to be transferred to the equipment without > making too many "one of a kind" pieces. > In he "olde times" much was solved by the cabling, that limited the > control possibilities. > These IP times, anything can reach anything else. > One approach is to store parts of this information into the RD, which > can be queried by the equipment. > > I hope this make the wish for an RD with third party access > understandable. > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. From nobody Wed May 9 01:20:39 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691D812DA43 for ; Wed, 9 May 2018 01:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 gPeJiP9Y6Ks9 for ; Wed, 9 May 2018 01:20:33 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0055.outbound.protection.outlook.com [104.47.0.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12AE5127286 for ; Wed, 9 May 2018 01:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+Asg4p5U0MNBSyn5UyY9AmStkQq+AZkjdluM67TaJS0=; b=ajIj/cajrE7ck78oTAOTm0Ugmb9YMgXrslQW7roYMyQ0FR6MNTdbUH68zSd3TbFo5oInss72l+e3TWAEZfu/mlbhnNRjNg9d7FQE1kXyaikoFBHCbTYSIyjmEUpqrGCXEVRzbj2fjs+Du1S/2eKL2GmnIbD6I/bTjOsC61yvkx4= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1759.eurprd08.prod.outlook.com (10.168.67.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.19; Wed, 9 May 2018 08:20:30 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::4004:973e:4b3:ef88]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::4004:973e:4b3:ef88%18]) with mapi id 15.20.0735.018; Wed, 9 May 2018 08:20:29 +0000 From: Hannes Tschofenig To: "consultancy@vanderstok.org" CC: "Kovatsch, Matthias" , Mohit Sethi , "core@ietf.org" Thread-Topic: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPmCfncz1IX5t6GRJaeO0C+mMHM9QAAOSUAAADDndAAA/ZdAAAf4kIAAAgtFAAAK4fsAAAAlUEw Date: Wed, 9 May 2018 08:20:29 +0000 Message-ID: References: <4EBB3DDD0FBF694CA2A87838DF129B3C01F36340@DEFTHW99EL4MSX.ww902.siemens.net> <6d8a9b8a6c67f7f7022ace8bd9c8d374@xs4all.nl> In-Reply-To: <6d8a9b8a6c67f7f7022ace8bd9c8d374@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [213.120.252.178] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1759; 7:rwtuzSVHXnDlUBBFvTeSbcIO7t8FdB6wR7wx6a171s+pfY2phvHY6xp3c5H7VtMTFwUVzD6Wj1Y8i7csxiZ7U2FKqSlY15J6/eWnjGKp2k2PU1jmqkuFkrtmcCStDy+HDI93xmzvND9vWdFnGqoG7uZ2Ioeg5FQ3TCrTGSRJSWwqsah6GS2SfyZC8c5H0KkHY7h8zniSjziIBnqIkx0CSYVtii8orjMf1F71I3mxLR6f54hsN9Z5LNq9x4+nPRS5 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1759; x-ms-traffictypediagnostic: VI1PR0801MB1759: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR0801MB1759; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1759; x-forefront-prvs: 0667289FF8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39380400002)(39860400002)(396003)(346002)(376002)(13464003)(189003)(377424004)(199004)(40434004)(66066001)(4326008)(7696005)(59450400001)(53546011)(6436002)(446003)(54906003)(102836004)(6506007)(93886005)(6916009)(25786009)(26005)(2501003)(186003)(5890100001)(99286004)(316002)(72206003)(9686003)(5250100002)(11346002)(76176011)(486006)(478600001)(55016002)(74316002)(6246003)(2906002)(68736007)(105586002)(81156014)(8676002)(14454004)(86362001)(5640700003)(7736002)(5660300001)(305945005)(2900100001)(8936002)(33656002)(97736004)(106356001)(2351001)(81166006)(3660700001)(476003)(3846002)(229853002)(1730700003)(3280700002)(53936002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1759; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: NCeRDPA2NjEpKej653VcKzZ6KMIJsd2N6CBC0p1EOms5WSory4NQWh6rNaNwNM6ZQMDXNtM2x4fm5tp7aPD887S/hqHpwltCkjbvs7vaXMMvhmsMMisUJRKQWYhLk88QT+Hu62Ib0mZDI521LvVzNgJ/cC5yw+wxLeKLFTg+uiMyoEKHeVrQYQQW8ptioEDh spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 471ab697-e695-48ad-40c2-08d5b585ba13 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 471ab697-e695-48ad-40c2-08d5b585ba13 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2018 08:20:29.9113 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1759 Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 09 May 2018 08:20:37 -0000 Hi Peter, I have not even looked at the con parameter but I wonder how well it can wo= rk in practice given firewalls and NATs... Ciao Hannes -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl] Sent: 09 May 2018 09:03 To: Hannes Tschofenig Cc: consultancy@vanderstok.org; Kovatsch, Matthias; Mohit Sethi; core@ietf.= org Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in R= D draft Hi Hannes, I share your concerns, But there are some additional aspects. for 3rd party registration the con=3D is used. con=3D will also be used to indicate alternative transports. Suppressing co= n=3D seems really a waste in this stage. On the other hand, even suppressing con=3D for third parties, the anchor at= tribute also permits to refer to third parties. Removing the anchor attribu= te is cumbersome to say the least. Possibly @others want to react. For the moment using con=3D for 3rd party registration creates one registra= tion at the time. The Authorization server can also in this case assign endpoint values and p= revent ep value stealing. I will try to get some concrete feedback on 3rd party registration. I will = keep you informed. Peter Hannes Tschofenig schreef op 2018-05-08 13:20: > Peter, > > I would personally feel more comfortable if we standardize > functionality that some people have gained some experience already. If > we don't involve the domain experts then we will most likely get it > wrong. > > What about separating this functionality from the RD draft, reach out > to these companies, and then put the result of the investigations into > a separate document? There are some folks in the group who work > closely with indoor commercial lighting companies and they could for > sure help. > > Ciao > Hannes > > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: 08 May 2018 08:22 > To: Kovatsch, Matthias > Cc: Hannes Tschofenig; Mohit Sethi; core@ietf.org > Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name > in RD draft > > Kovatsch, Matthias schreef op 2018-05-07 18:09: >> Dear Hannes, >> >> dear list >> >> To my knowledge, third-party provisioning functionality is in >> particular used for lighting systems; maybe Peter can comment on this. > > On request, some background. > For buildings, the installation is done by installation companies with > their own tools and procedures. > Installation can be done in phases by different companies. > Their is at this moment not one general approach or installation > protocol. > > The problem is that the architect and people around have produced > drawings with cabling and equipment situated at precise physical > locations in the drawing. > Equipment, cabling etc are identified with numbers ,names, what have > you. > There are descriptions which discuss the functionality and the > relation between the equipment. > All this knowledge has to be transferred to the equipment without > making too many "one of a kind" pieces. > In he "olde times" much was solved by the cabling, that limited the > control possibilities. > These IP times, anything can reach anything else. > One approach is to store parts of this information into the RD, which > can be queried by the equipment. > > I hope this make the wish for an RD with third party access > understandable. > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Thu May 10 00:28:25 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BF112785F for ; Thu, 10 May 2018 00:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 1M3XSJ620tjl for ; Thu, 10 May 2018 00:28:21 -0700 (PDT) Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (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 8BDB212E91F for ; Thu, 10 May 2018 00:28:20 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:216]) by smtp-cloud8.xs4all.net with ESMTPA id GfzofIgGSJwIgGfzofABQc; Thu, 10 May 2018 09:28:19 +0200 Received: from AMontpellier-654-1-136-226.w90-0.abo.wanadoo.fr ([90.0.95.226]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 10 May 2018 09:28:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 10 May 2018 09:28:12 +0200 From: peter van der Stok To: Hannes Tschofenig Cc: consultancy@vanderstok.org, "Kovatsch, Matthias" , Mohit Sethi , core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <4EBB3DDD0FBF694CA2A87838DF129B3C01F36340@DEFTHW99EL4MSX.ww902.siemens.net> <6d8a9b8a6c67f7f7022ace8bd9c8d374@xs4all.nl> Message-ID: <936152edef2aad1f5258eeb5fb47f64c@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfOsAroj+Bl3c1Ln6c6ltPgsJ2Jx1HD6Q3vvgV2tXWa/opYokGwGe1s3OE9cspnJjOyH/UKpr4sDpMjkpt2QA7PdVb8SKX2VAVcuDjMUYkiQuD6pitqKb 3+p5aqNPkvrMhI6Bjk/lN42QEJ1mI7SbrIYEwhzlLfw1pr3EamFvUX9q9Ey8gc2pEzle6iqg/55AzmgmgJ5mgivbsOyhGb8bu3eDD2ZIISARTUsMwcdtA0Me Bg1aNb7Z5iAOb5yag2dTJrhMy7ecRpZMAl8efNx0ukfjnMjuRDzvjs+nsnc+mJy0 Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 10 May 2018 07:28:24 -0000 Hannes Tschofenig schreef op 2018-05-09 10:20: > Hi Peter, > > I have not even looked at the con parameter but I wonder how well it > can work in practice given firewalls and NATs... > Hi Hannes, some more background. Resource Directory was originally foreseen to handle unicast resource discovery within a Lowpan. Building installations foresee that the resources and the RD are all located within the same administration domain (e.g. no NATs, or Firewalls between RD and interested endpoints.) When services administered by the RD are accessed from outside the administration domain, the use of DNS is recommended. For that reason we prepare the RD-DNS-SD draft. When the Commissioning Tool is outside the administration domain (you never know), access from CT to the RD also should pass via DNS IMO. Independent of the network location of the CT, the CT can for example fill link-local addresses into the RD, when RD and endpoints are all on the same link. I think that the best way forward is indeed an additional secure RD draft. I don't know what my co-authors or Matthias think. Cheerio, Peter From nobody Thu May 10 04:41:11 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60190124207; Thu, 10 May 2018 04:41:09 -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 SbBzIXWYo8TR; Thu, 10 May 2018 04:41:07 -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 4A9B81201F2; Thu, 10 May 2018 04:41:06 -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 3B17449AE5; Thu, 10 May 2018 13:41:04 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0E1E76F; Thu, 10 May 2018 13:41:03 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id B3CD25A; Thu, 10 May 2018 13:41:02 +0200 (CEST) Received: (nullmailer pid 12237 invoked by uid 1000); Thu, 10 May 2018 11:41:02 -0000 Date: Thu, 10 May 2018 13:41:02 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Francesca Palombini Cc: Klaus Hartke , "core@ietf.org" , "draft-tcs-coap-no-response-option@ietf.org" Message-ID: <20180510114100.GA9530@hephaistos.amsuess.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] No-Response option and OSCORE 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, 10 May 2018 11:41:09 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Francesca, I've been reviewing the current OSCORE and stumbled upon the No-Resposne section I had previousy missed when working through the deltas. G=F6ran mentioned that No-Response had been discussed so I read through tis thread but found no points addressing those specific concerns -- could you have a look at those notes? On Mon, Jan 15, 2018 at 01:34:28PM +0000, Francesca Palombini wrote: > Considering the part I had missed about congestion control, my new > proposal is: the client must set No-Response as inner and outer. (Roughly copied from an earlier mail to G=F6ran) Why must this be set to the same as the current draft says? Assume I'm updating some value regularly and don't particularly care about short network outages as the next value will be sent soon anyway, but I do want to know when the server won't accept any more updates. I would want to send a protected "NON POST No-Response:2.xx" request. If I, as prescribed, set No-Response:2.xx both outer and inner, then if the server answers protected-4.04 (which is outer-2.01), then the server may know to ignore the outer No-Response, but a surprised proxy would not and swallow the 4.04. If only an inner No-Response:2.xx is were sent, the proxy expects an unconditional response, and might respond late with a 5.04 Gateway Timeout. (That's also bad but not as bad as the above). I'd suggest picking an outer value that is not specified yet (say, "1", and call it "at the origin's disretion"). Without proxies, this will be ignored and the origin looks at the inner one. Proxies would either fail with Bad Option (which can be a desirable outcome, given that otherwise they won't be behaving properly) or (hopefully) forward it as "I know that this is a No-Response, I can't tell the condition, but I'm prepared to receive a response if one comes along but no response is OK as well". (RFC7967 has no provisions what to do if No-Response is known but its value unspecified). It's late and this is not a well-thought-through suggestion, so feel free to ignore it. (Turns out it's not easy to make OSCORE work through proxies, but then again, that's why we have it.) Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --jI8keyz6grp/JLjh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlr0L8gACgkQOY0REtOk veEQ3A//boz8wRhBSdFYML6Of41PWtALlYpMoiQMAXqKMFRW5H/FsNnZfrkL4Ra0 mCdwMF2TYShmxwVQ/I+izJS5ku1Bit94J1iRifjJSJhmSZ37vH7JhK1ETEHwBAYS CJvg4N/YoR8eL5XHavDpxqSOKxkdIhfUWMJgoJlUDl+ntGk7iqqL/+lup0w2NZg7 4Dfb32DBiWw3SoHyMdZgHX/4Wna2+n5Fd/inipra4QFlttalY5g68R6yyqJenjDJ Fv5nq+Zj6+1MWUMpO59F3E3JASfQDSEChQVoMbe4fucLEnpsGfc0L6/MYek1WlCo LIU38LTm0BaP6t3P4c13lb5YTP66EaXnuABntIbgbBBq4J2rJAbFuuO0O72TgVmY 08ImnsG3gGHRI/dIuGi7+di2AjlbMKexqCE1wOnXw0c9EZC+wRRUnrb4NLWKdCWO Vpby/+WY6K5BsLQqvpknry3WWDen0W3Td81Yh4GJO9lafzDBKMFY5tAFyqnxJSL4 eZjJvsnDW1S9XkxuXlkpvXKCHVx9VnZOAuwrwM3Qb1Mwq/C31IsGG7AYIsneOj/e wTXv7XwRIXGOy1sfG3K8LTnMkgUPnSUUT8fD1nzX0GhCjx7c9JadgnD3tAG3PZIl jn+sMPs8T5aUmNwuHTHItWqkTaD8HJBoKAD7h79ekRYYhBkoGzs= =OwAE -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From nobody Thu May 10 11:20:44 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E9312EB5E; Thu, 10 May 2018 11:20:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 4wcOwA2K_t5t; Thu, 10 May 2018 11:20:41 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7AF51270A3; Thu, 10 May 2018 11:20:40 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 10 May 2018 11:18:00 -0700 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= , 'Francesca Palombini' CC: , , 'Klaus Hartke' References: <20180510114100.GA9530@hephaistos.amsuess.com> In-Reply-To: <20180510114100.GA9530@hephaistos.amsuess.com> Date: Thu, 10 May 2018 11:20:31 -0700 Message-ID: <00c001d3e88b$96722ec0$c3568c40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKwyqfVoRTetNOnQR/pQa3rkbPo4gBcLc3EAuIqgv4CWeyUtaJCvgKw Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] No-Response option and OSCORE 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, 10 May 2018 18:20:42 -0000 > -----Original Message----- > From: core On Behalf Of Christian Ams=FCss > Sent: Thursday, May 10, 2018 4:41 AM > To: Francesca Palombini > Cc: draft-tcs-coap-no-response-option@ietf.org; core@ietf.org; Klaus Hartke > > Subject: Re: [core] No-Response option and OSCORE >=20 > Hello Francesca, >=20 > I've been reviewing the current OSCORE and stumbled upon the No- > Resposne section I had previousy missed when working through the = deltas. >=20 > G=F6ran mentioned that No-Response had been discussed so I read = through tis > thread but found no points addressing those specific concerns -- could = you > have a look at those notes? >=20 > On Mon, Jan 15, 2018 at 01:34:28PM +0000, Francesca Palombini wrote: > > Considering the part I had missed about congestion control, my new > > proposal is: the client must set No-Response as inner and outer. >=20 > (Roughly copied from an earlier mail to G=F6ran) >=20 > Why must this be set to the same as the current draft says? Assume I'm > updating some value regularly and don't particularly care about short > network outages as the next value will be sent soon anyway, but I do = want to > know when the server won't accept any more updates. I would want to = send > a protected "NON POST No-Response:2.xx" request. >=20 > If I, as prescribed, set No-Response:2.xx both outer and inner, then = if the > server answers protected-4.04 (which is outer-2.01), then the server = may > know to ignore the outer No-Response, but a surprised proxy would not = and > swallow the 4.04. This is a huge problem and needs to be solved. >=20 > If only an inner No-Response:2.xx is were sent, the proxy expects an > unconditional response, and might respond late with a 5.04 Gateway > Timeout. (That's also bad but not as bad as the above). I am not sure that I worry about this. First I think that the proxy in = this case is being overly helpful. Given that we are looking at a NON = request, it makes sense that there is no response ever coming back from anybody. = It would be different if this were a CON request. You are going to get the exact same behavior from a proxy which does not implement the = No-Response option so this is not going to be new. >=20 > I'd suggest picking an outer value that is not specified yet (say, = "1", and call it > "at the origin's disretion"). Without proxies, this will be ignored = and the origin > looks at the inner one. Proxies would either fail with Bad Option = (which can > be a desirable outcome, given that otherwise they won't be behaving > properly) or (hopefully) forward it as "I know that this is a = No-Response, I > can't tell the condition, but I'm prepared to receive a response if = one comes > along but no response is OK as well". > (RFC7967 has no provisions what to do if No-Response is known but its value > unspecified). If you are going to do this, it might be better to say that you are not interested in 8.xx messages which could be defined as being - no proxies = are to generate responses. Jim >=20 > It's late and this is not a well-thought-through suggestion, so feel = free to > ignore it. (Turns out it's not easy to make OSCORE work through = proxies, but > then again, that's why we have it.) >=20 > Best regards > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Fri May 11 03:37:54 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA457127078; Fri, 11 May 2018 03:37:52 -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 QOauJFhPcp8i; Fri, 11 May 2018 03:37:50 -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 B80241241F3; Fri, 11 May 2018 03:37:50 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id A064F49AE8; Fri, 11 May 2018 12:37:48 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id F0F956F; Fri, 11 May 2018 12:37:46 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 99E9C5A; Fri, 11 May 2018 12:37:46 +0200 (CEST) Received: (nullmailer pid 13107 invoked by uid 1000); Fri, 11 May 2018 10:37:45 -0000 Date: Fri, 11 May 2018 12:37:45 +0200 From: 'Christian =?iso-8859-1?Q?Ams=FCss'?= To: Jim Schaad Cc: 'Francesca Palombini' , draft-tcs-coap-no-response-option@ietf.org, core@ietf.org, 'Klaus Hartke' Message-ID: <20180511103744.GF23148@hephaistos.amsuess.com> References: <20180510114100.GA9530@hephaistos.amsuess.com> <00c001d3e88b$96722ec0$c3568c40$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I3tAPq1Rm2pUxvsp" Content-Disposition: inline In-Reply-To: <00c001d3e88b$96722ec0$c3568c40$@augustcellars.com> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] No-Response option and OSCORE 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, 11 May 2018 10:37:53 -0000 --I3tAPq1Rm2pUxvsp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi jim and OSCORE developers, On Thu, May 10, 2018 at 11:20:31AM -0700, Jim Schaad wrote: > > If I, as prescribed, set No-Response:2.xx both outer and inner, then > > if the server answers protected-4.04 (which is outer-2.01), then the > > server may know to ignore the outer No-Response, but a surprised > > proxy would not and swallow the 4.04. >=20 > This is a huge problem and needs to be solved. Glad I did not just miss an old solution. > > If only an inner No-Response:2.xx is were sent, the proxy expects an > > unconditional response, and might respond late with a 5.04 Gateway > > Timeout. (That's also bad but not as bad as the above). >=20 > I am not sure that I worry about this. First I think that the proxy in t= his > case is being overly helpful. Given that we are looking at a NON request, > it makes sense that there is no response ever coming back from anybody. = It > would be different if this were a CON request. The proxy might have forwarded it as a CON, or over reliable transport. > You are going to get the exact same behavior from a proxy which does > not implement the No-Response option so this is not going to be new. I don't think so. No-Response is unsafe-to-forward, so it "lead[s] to 4.02 Bad Option" per RFC7252 Section 5.7.1. > > I'd suggest picking an outer value that is not specified yet (say, > > "1", and call it "at the origin's disretion"). [...] >=20 > If you are going to do this, it might be better to say that you are not > interested in 8.xx messages which could be defined as being - no proxies = are > to generate responses. Indeed, expressing the code as 0x80 is better; there can never be 8.xx codes so this is obviously magic, while someone could still define 1.xx codes to be ignored. Bringing this to concrete proposals: A: the simple one "No-Response is an inner and outer option; the inner option always reflects the intention of the operation, and an OSCORE server ignores the outer. A client usually sets only the inner No-Response option, but MAY set the outer to 26 ('ignore all known codes') if the inner is set to 26. The client MUST be prepared to receive and discard 5.04 errors =66rom intermediaries." B: extend No-Response "We define a new No-Response value, 128, described as 'Not interested in some responses'. A server receiving that option decides based on some context (eg. other options like OSCORE) whether or not the client is interested in the response; if it has no such context, it SHOULD respond with 4.02 Bad Option. A proxy processing the option must forward response messages it receives, but never sends a 5.04 error if it receives no response. (It may still send a 5.04 if it forwards the request over a secure or reliable connection that can not be established, or if it forwards the request as a CON and receives no ACK.) No-Response is an inner and outer option; [... as above]. If a client sets the inner option, itSHOULD set the outer option to 128 ('Not interested in some responses'), or be prepared to receive and discard 5.04 errors from intermediaries." Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --I3tAPq1Rm2pUxvsp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlr1cnUACgkQOY0REtOk veGR6BAA0dnL/CacMJ8x4T+TrzBCgBk4KzopnCKnC5fy1EUmiCPIPMzC/Zuvpzf1 ekhpivSxy2dQ1Im7NGRVi1m/AK5cXaFm5sAz8QiO8jl/P6wOprGm+hvu7i6P2Sh6 rTDHZgQfh/4N+475qoEPG7Je4cNcpScCbevAoL6vXFVDhONAz06x2je49eMplmQk +SrZQYa4mpADdMkVKZ1GfDHQlN/si6djhD4t1c61gwkcQWsKCO+3oDjDa9rqcMMG cVJGF68eektKH3NDhSkyAcATEni09Ri6955YNtKBINLR690Eox2kdD5v229VDIKx IAZzCagDX09dm7Y+YPTZYtt9CF88+9JaJLJQyibYGXXtMLikCoRqEUjnciC6V25J EBH50Jsb635GZMzVm76VwAUQEgfFTqWiXHme43vv9eoBMqXWoeTLMnBSBb2UvwGY OYz9q46riQxc+pyn9zwN9EegsnSYTlAsLHxiCyLJ/8+yg12T6+Tp+DQDF6RcXJk0 Lu8l4HNabx8PtDINeCeQvyBEWThmVq9Ogo/v78+g7l0yq6MdOcI841bmpR71+kT2 5Bb8tagPZUtzviWpK3aHZwjh6C8+jQt21nCNFAP7YlfJeJ4xHn+ds+y5wS9LiJJ9 tQHXNZDnq/QScIhAEPpRo2GdIM3cdJyszYznRtCvELTbNhx3DEU= =Re3H -----END PGP SIGNATURE----- --I3tAPq1Rm2pUxvsp-- From nobody Fri May 11 08:39:17 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D285124205; Fri, 11 May 2018 08:39:16 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 QI1ACHbU45vY; Fri, 11 May 2018 08:39:14 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91F31241F8; Fri, 11 May 2018 08:39:13 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 11 May 2018 08:36:31 -0700 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= CC: 'Francesca Palombini' , , , 'Klaus Hartke' References: <20180510114100.GA9530@hephaistos.amsuess.com> <00c001d3e88b$96722ec0$c3568c40$@augustcellars.com> <20180511103744.GF23148@hephaistos.amsuess.com> In-Reply-To: <20180511103744.GF23148@hephaistos.amsuess.com> Date: Fri, 11 May 2018 08:39:04 -0700 Message-ID: <015601d3e93e$334a2e20$99de8a60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKwyqfVoRTetNOnQR/pQa3rkbPo4gBcLc3EAuIqgv4CWeyUtQFRSVzxAlt6aMKiJr6voA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [core] No-Response option and OSCORE 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, 11 May 2018 15:39:16 -0000 I believe that this is correct. I am agnostic as to which solution is chosen. Jim > -----Original Message----- > From: 'Christian Ams=FCss' > Sent: Friday, May 11, 2018 3:38 AM > To: Jim Schaad > Cc: 'Francesca Palombini' ; = draft-tcs- > coap-no-response-option@ietf.org; core@ietf.org; 'Klaus Hartke' > > Subject: Re: [core] No-Response option and OSCORE >=20 > Hi jim and OSCORE developers, >=20 > On Thu, May 10, 2018 at 11:20:31AM -0700, Jim Schaad wrote: > > > If I, as prescribed, set No-Response:2.xx both outer and inner, = then > > > if the server answers protected-4.04 (which is outer-2.01), then = the > > > server may know to ignore the outer No-Response, but a surprised > > > proxy would not and swallow the 4.04. > > > > This is a huge problem and needs to be solved. >=20 > Glad I did not just miss an old solution. >=20 > > > If only an inner No-Response:2.xx is were sent, the proxy expects = an > > > unconditional response, and might respond late with a 5.04 Gateway > > > Timeout. (That's also bad but not as bad as the above). > > > > I am not sure that I worry about this. First I think that the proxy > > in this case is being overly helpful. Given that we are looking at a > > NON request, it makes sense that there is no response ever coming = back > > from anybody. It would be different if this were a CON request. >=20 > The proxy might have forwarded it as a CON, or over reliable = transport. >=20 > > You are going to get the exact same behavior from a proxy which does > > not implement the No-Response option so this is not going to be new. >=20 > I don't think so. No-Response is unsafe-to-forward, so it "lead[s] to > 4.02 Bad Option" per RFC7252 Section 5.7.1. >=20 > > > I'd suggest picking an outer value that is not specified yet (say, > > > "1", and call it "at the origin's disretion"). [...] > > > > If you are going to do this, it might be better to say that you are > > not interested in 8.xx messages which could be defined as being - no > > proxies are to generate responses. >=20 > Indeed, expressing the code as 0x80 is better; there can never be 8.xx codes > so this is obviously magic, while someone could still define 1.xx = codes to be > ignored. >=20 >=20 > Bringing this to concrete proposals: >=20 > A: the simple one >=20 > "No-Response is an inner and outer option; the inner option always reflects > the intention of the operation, and an OSCORE server ignores the = outer. A > client usually sets only the inner No-Response option, but MAY set the outer > to 26 ('ignore all known codes') if the inner is set to 26. The client MUST be > prepared to receive and discard 5.04 errors from intermediaries." >=20 > B: extend No-Response >=20 > "We define a new No-Response value, 128, described as 'Not interested = in > some responses'. A server receiving that option decides based on some > context (eg. other options like OSCORE) whether or not the client is > interested in the response; if it has no such context, it SHOULD = respond with > 4.02 Bad Option. A proxy processing the option must forward response > messages it receives, but never sends a 5.04 error if it receives no response. > (It may still send a 5.04 if it forwards the request over a secure or reliable > connection that can not be established, or if it forwards the request = as a CON > and receives no > ACK.) >=20 > No-Response is an inner and outer option; [... as above]. If a client = sets the > inner option, itSHOULD set the outer option to 128 ('Not interested in some > responses'), or be prepared to receive and discard > 5.04 errors from intermediaries." >=20 >=20 > Best regards > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Fri May 11 10:05:52 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91142124319 for ; Fri, 11 May 2018 10:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiPxhF9v1TlV for ; Fri, 11 May 2018 10:05:44 -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 012AF1242F7 for ; Fri, 11 May 2018 10:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526058342; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=w612owzqQliArYqC5c7lVvws8JGzEEB+SHu2Y66jGQg=; b=OB8HfxpQJxLgr/w9XUuI1GLUAhGrujwWf8ygztyQyz6UT/b5+Zv2MQa+BclwLj8x ysPPeXkebsFn/CCF30hKMN0Y8+E3pztlhKIVxlxcLKU0P9buN/sVAscvBq7iCOL9 YiIDcrR18NfgmSniBuh9wg8QCUfOA1rxhnH6J06OsZ8=; X-AuditID: c1b4fb30-e77ff7000000169b-d6-5af5cd6531e6 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 44.22.05787.56DC5FA5; Fri, 11 May 2018 19:05:41 +0200 (CEST) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSHC024.ericsson.se (153.88.183.90) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 11 May 2018 19:05:41 +0200 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 11 May 2018 19:05:40 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Fri, 11 May 2018 19:05:40 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Benjamin Kaduk , core , Alexey Melnikov , The IESG CC: "core-chairs@ietf.org" , "draft-ietf-core-senml@ietf.org" , "Carsten Bormann" , Cullen Jennings Thread-Topic: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) Thread-Index: AQHT14bG3vAIeJGLoECcXBuH3Y6fJ6QkiLkAgABmQYCAAIe3gIAFTUsA Date: Fri, 11 May 2018 17:05:40 +0000 Message-ID: <0C881DE7-7991-4E3C-A8C8-B77AEC2F55CC@ericsson.com> References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> <20180508000154.GY84491@kduck.kaduk.org> <44DB4CCE-62E7-43FF-9E0B-9AF27E14EE87@tzi.org> In-Reply-To: <44DB4CCE-62E7-43FF-9E0B-9AF27E14EE87@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.153] Content-Type: multipart/signed; boundary="Apple-Mail=_04E4A033-1E2A-4194-AFAE-2129444B3C6C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUyM2J7lG7q2a9RBjNvW1vsf3+IyeLIlLus Fts2XmCz2Pd2PbPFz3dLmC0+rP/BaDHjz0Rmi+UbZzI5cHjsPHWAzWPJkp9MHpfPf2T0aDpz lNlj2qLMANYoLpuU1JzMstQifbsEroyJby+wFqwOr5j6v7aBsTGgi5GTQ0LAROL2opOMXYxc HEICRxgl1v36zQrhbGGUeH7xOStIlZDAN0aJf0fzIRLLGCX+nHzACJJgE7CXmLzmI5gtIlAn 8bdzA1g3s8BuRonbuy6ydzFycAgLpEks3F0GUZMu8f/jc2YI203i+VoIm0VAVeLH193sIDYv 0Mwvr5dBnXSPUWLxydNMIAlOAWuJdzdXg9mMAmIS30+tAbOZBcQlbj2ZzwTxj4jEw4un2SBs UYmXj/+xQthKEnuPXWeBOG4Ko8SuFeeZIbYJSpyc+YQF4k1Viav/XjFOYBSfhWTuLGQ9s5D0 QBQlSbzYcokZwtaWWLbwNZDNAWTrSExeyIgqDGF/PH+ECcI2lXh99CNUjbXEjF8H2SBsRYkp 3Q/ZFzByr2IULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQITC4Ht/w22MH48rnjIUYBDkYlHl7G bV+jhFgTy4orcw8xqgDNebRh9QVGKZa8/LxUJRHefSu+RAnxpiRWVqUW5ccXleakFh9ilOZg URLntfDbHCUkkJ5YkpqdmlqQWgSTZeLglGpgdD5+7tjt3LdHt17/e27SxuDKYyfPKOZ/2zo9 TnPdtL9mOknt8WyPSxR+80xade97huj2CVkX7IJiU/5Y3r4Xd9DLsWhWzN7TUcXOW1q/Gsb1 54p2c4ku42/nmNTz2s2gxmrzpFlB03lllNIflx/wWeUlvmPPzVye52x3rZ5pOd7POvLS0/nF FSWW4oxEQy3mouJEAAz7VLI2AwAA Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 11 May 2018 17:05:46 -0000 --Apple-Mail=_04E4A033-1E2A-4194-AFAE-2129444B3C6C Content-Type: multipart/alternative; boundary="Apple-Mail=_E385E14E-8695-4C04-A4FB-9EF369CCCC14" --Apple-Mail=_E385E14E-8695-4C04-A4FB-9EF369CCCC14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, While addressing the IESG review comments regarding the use of time in = SenML we came up with a simple way to enable SenML Records to express = also relative times in the future that would have minimal impact to any = existing use of SenML. We could use the following definition: Values greater than or equal to 2**28 represent an absolute time = relative to the Unix epoch. Values less than 2**28 represent time = relative to the current time. That is, instead of only values less than zero, also values less than = 2**28 (268,435,456) would be used to express relative time. Negative = values and zero are still times in past and "now" respectively, as = before. Time values from zero to 2**28 would be relative times in the = future. The only change this causes in the current use of SenML is that the = smallest absolute time expressible in SenML becomes 1978-07-04 21:24:16 = UTC instead of 1970-01-01 00:00 UTC. The absolute times after 1978 are = still exactly the same ("Seconds after Unix epoch"). We are not aware of = any deployments with SenML data between 1970 and 1978 that would be = impacted negatively by this.=20 For details, see: https://github.com/core-wg/senml-spec/pull/129/files Would anyone have concerns about including this change in SenML before = publication? Since we are already very late in the process and we need to get SenML = published as RFC very soon, we would also need to agree on this very = soon. Thanks, Ari, Carsten, Cullen= --Apple-Mail=_E385E14E-8695-4C04-A4FB-9EF369CCCC14 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all,

While addressing the IESG review comments regarding the use = of time in SenML we came up with a simple way to enable SenML Records to = express also relative times in the future that would have minimal impact = to any existing use of SenML. We could use the following = definition:

  Values greater than or equal to 2**28 = represent an absolute time relative to the Unix epoch. Values less than = 2**28 represent time relative to the current time.

That is, instead of only values less than zero, also values = less than 2**28 (268,435,456) would be used to express relative time. = Negative values and zero are still times in past and "now" respectively, = as before. Time values from zero to 2**28 would be relative times in the = future.

The only change this causes in the current use of = SenML is that the smallest absolute time expressible in SenML becomes = 1978-07-04 21:24:16 UTC instead of 1970-01-01 00:00 UTC. The absolute = times after 1978 are still exactly the same ("Seconds after Unix = epoch"). We are not aware of any deployments with SenML data between = 1970 and 1978 that would be impacted negatively by this. 

For details, see:
https://github.com/core-wg/senml-spec/pull/129/files=

Would anyone have concerns about including this change in = SenML before publication?

Since we are already very = late in the process and we need to get SenML published as RFC very soon, = we would also need to agree on this very soon.


Thanks,
Ari, = Carsten, Cullen= --Apple-Mail=_E385E14E-8695-4C04-A4FB-9EF369CCCC14-- --Apple-Mail=_04E4A033-1E2A-4194-AFAE-2129444B3C6C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMwDCCBfYw ggPeoAMCAQICEDcTcXMuXOfOJx3rdG/2/hgwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE3MTIwNDE0MTM0NFoXDTIwMTIwNDE0MTM0M1owZTERMA8GA1UECgwIRXJpY3Nzb24xFTAT BgNVBAMMDEFyaSBLZXLDpG5lbjEnMCUGCSqGSIb3DQEJARYYYXJpLmtlcmFuZW5AZXJpY3Nzb24u Y29tMRAwDgYDVQQFEwdlYXJpa2VyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhSVX rojnPX+oZh2GIgZ/K+/xppl7EN60UI+Vq5SHm6C2ns9/vKek9EgrUV5Zqgqz4gncT1H/3BMA8XOP ONemPIcegFR2nxkG4v+S3rRxRMdMPgBJwkZQcSDLvT9R/ZgSPckmOtMFsWeoNxdZMUXWfZh52aFk MF3NlAnXy2UiMmbGAAkHVyUjScSDWAGeGXyZV1Cn5qvoaO/Fd9G4DX646nFrfLjNSnMX6FouZoLh rkBs6xE62vtRp3z+kLO6UC8CY9e8Qn/cm6xp9B+KrE2/Un99PpbuxLx0GMXq+/cuB4CdiPn+Ka2X 0E66sWiXRoiJz4COm182hV/akOGBjGfzTwIDAQABo4IBvjCCAbowSAYDVR0fBEEwPzA9oDugOYY3 aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCB ggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29t MEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxp bmRpdmlkdWFsY2F2My5jZXIwIwYDVR0RBBwwGoEYYXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9y eS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcD AjAdBgNVHQ4EFgQU0dBcPI0/9JLIXr4Qwu+jTumFvcUwHwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc 45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBVWCBhZPB3PkGIx4FF guinomjcmL1iZ+icJEWLJ/DyF7559hzn0jDNT14gFEVKJZ/zt6pxlkmNzBaMe6O7cy/NaynWoeeK uzM61w2tR+UUGhjs3evX20b7PZsT9uONk+K25IiAKhfbwiAtkukhydiDueJZefBHfEaKmGwQ87eZ Hent/5cu13L7WpT+sCNmhbfqZm5iTWVXqci30Z+G4fX/IhB3mnFMOPniPdM4u/8qsQrAIVBguSGj rOs6JykmTsOSNgY0vCZoNNHG56ExAcoNb59eLXGLv95JxXRicQuPFca4TceiMSQsHw5999r/lMgJ 8E3YdMBJcnRixumcDE9PKMTGYrOXea51DPrHnA/pMeEzSyW1fzAdVASFTnDS7It9P3KpZVgpOr70 YjTZL2TMP67UBa1+1tYrYJAgZQATjd9pkasJyGRP5+djPlvU+nJ/kfjmv+myawD0nreIULOeKUqW j0zjt9A8SyqkVa8N8TiN2hupKZBen9orty9igASFyPm86pH9s826bvBZ6BBl0Ox/Lfm9mXz6+1Gs oCT/puZR9qJrOpCgar4MXU4vuxCVvUdsyaQluWusF/wKyHrB0RUV7Lq96AFIjC06eZwAU33Y2Uqn bh/ysnEzXsz2lY0bo6yYIaHHKjiTUEefr2dddB9I3tB2oukZ+FB+kkvcuDCCBsIwggSqoAMCAQIC EFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUxMDI3 MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNz c29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDs 8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meisbhkqUXkL 7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdDdxhVW4Le o0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RSBSAwqBsh ZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v 9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocyBmpC+zJA mKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUML ky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtlj HWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6 nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwID AQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1 c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIB ADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8v Y3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7GZ6X nHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3 DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5QtaZi ObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj0uKv dASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQysshU cqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1uJGx6ELP OiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvE A155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7j ewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2 zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2 x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgft Yug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhA3E3FzLlznzicd63Rv9v4Y MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE4MDUxMTE3MDUzOFowIwYJKoZIhvcNAQkEMRYEFM0zi9CyvUfUaQqPci+ajGUZbY7PMGoGCSsG AQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhA3E3FzLlznzicd63Rv9v4YMGwGCyqGSIb3DQEJ EAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNz c29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEDcTcXMuXOfOJx3rdG/2/hgwDQYJKoZIhvcNAQEBBQAE ggEAXMyRsGLF+68H/g6geEyWFTsIfc3I0IpXtkBQclBp6JJayyMiDjrY3o7Q/QHP+wFRP0izcz0T r6hAfz/aE2dxb3tNnVuwRV1T5+plILvJVrZ1RN73FtepPuzNr4nw/vhVvYAp711c5L0gvhsdpMeO 8UDcFGH0LlrkFp+MRq1hARaBS1RiauVQzUj9x7ddXzlqz0MzsSBlScHyT+/pfqgt8K4hzWQ4Bu0L Zwl9VxzVjFwuYMofcDFtC+RD/oioFdnlJifQTL/NBSKwel29bvP1WzHMrqYODWZy4QkNkSJC1WkM XlyQEyTsbS4jxqeA0XjOaz7cq9uws7U6PubX/uGEpwAAAAAAAA== --Apple-Mail=_04E4A033-1E2A-4194-AFAE-2129444B3C6C-- From nobody Sat May 12 05:39:52 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECA7124BAC; Sat, 12 May 2018 05:39: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 RZxH-1Hvx7vj; Sat, 12 May 2018 05:39:49 -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 C5E4A12E890; Sat, 12 May 2018 05:39: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 C494A49799; Sat, 12 May 2018 14:39:45 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A7EBE6F; Sat, 12 May 2018 14:39:44 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E216E5A; Sat, 12 May 2018 14:39:43 +0200 (CEST) Received: (nullmailer pid 13837 invoked by uid 1000); Sat, 12 May 2018 12:39:41 -0000 Date: Sat, 12 May 2018 14:39:41 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Ari =?iso-8859-1?Q?Ker=E4nen?= Cc: Benjamin Kaduk , core , Alexey Melnikov , The IESG , "core-chairs@ietf.org" , "draft-ietf-core-senml@ietf.org" Message-ID: <20180512123939.GA3655@hephaistos.amsuess.com> References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> <20180508000154.GY84491@kduck.kaduk.org> <44DB4CCE-62E7-43FF-9E0B-9AF27E14EE87@tzi.org> <0C881DE7-7991-4E3C-A8C8-B77AEC2F55CC@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <0C881DE7-7991-4E3C-A8C8-B77AEC2F55CC@ericsson.com> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 12 May 2018 12:39:51 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Ari, hello ADs, On Fri, May 11, 2018 at 05:05:40PM +0000, Ari Ker=E4nen wrote: > Values greater than or equal to 2**28 represent an absolute time > relative to the Unix epoch. Values less than 2**28 represent time > relative to the current time. I appreciate that change. It does not impact my deployments of SenML but allows using it with CoRE interfaces more consistently. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlr24IQACgkQOY0REtOk veFXaw//RNX1DUsZVOjswTvtVkDlx2ntNrYvUo8Qkc6HsAYtPb/AIpsrojYC4czW 3LY6eo3eqEscr5ujqL6GMWSa3oKSRGIPR6B6tdt/IWTZO4FuJdJM8RJMzO1WW+OC sVdPWYPH1ZtTxmcnaM3BfsUtPrxSAj2trFTpCZHUvIVHx1vrI7rmD96HW03QSwXK oA/48Ja0U595AWYA1hOvUmRe128Rp/oRcVtrAR+3jgPkLsozhQtsK6hGYySVbW3o OmEVAcYVZf22A7yuuzVgee0KOrtG8L91p8XPLZcQEVCVKT9+XJMfvgA2XuS9NiAW BFYlJuAunmyHeOyuO81ZozBvijFJBQd+wppXbrCc6AlUotFfjJNWrduDO6JCr2MZ DfFhnJKB4IZTHRjHF4ZSnL+ksQAX51e8hubj6GvggXMaeQeVDQCdl+7LaD+EAdbJ KClZwy8m6yLebA3q69NWPO9AIxIZBa5/YCTynt3VZKn2IbFgnQsgIDkcra/R5yrD Va9oJ/wpRXTiNY7x6NvYRYmVu5xz8N2dQZddrndHOX8tL/Py7wo9L+PW68YgT8Cu 2SDHw4KgMEaLht17o90MZZiTaZqkG+U+GKWxaSHJlheqxOwChLkGcJ2hs2gkNwkS iHtz2qCR3IgLNr8hotNPPtJ/4gQnRGXnxUKjtRNrlH5aNKmhERo= =AW2H -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From nobody Sat May 12 13:50:41 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CF0127369; Sat, 12 May 2018 13:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.197 X-Spam-Level: X-Spam-Status: No, score=-1.197 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=svI3/820; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HhTSdE5y Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SItg6ckaxjOf; Sat, 12 May 2018 13:50:33 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EADA1270AB; Sat, 12 May 2018 13:50:33 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0FEB125BF0; Sat, 12 May 2018 16:50:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sat, 12 May 2018 16:50:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; 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; s=fm3; bh=jlTgiKHJ87/UmZUNtgNb8isqBvxL4 4zyfB0N3MpmNdU=; b=svI3/820bvc0rpkZhyZb0jifjE5J8ECs5kJfnY1Ngjsf/ AGVO5/AR7rltAjpxGwq6fotlam0/dUOEDp+HzXg4P8Z0zntg+Zv2mAoZXFq/MbOZ 3B+gza+CEKZl2PdGWvQanzFvCYw6l3WfqrxfCjWJ77h//gpcHRTlK+CvQjnXGoIo 6wCt4vbLFKJFb0txY6NUa8MSsP8H1yZZZoO9jIL0GRqDSjPS4FVig0ldODT4jJPg gPIMFCjaW+xUENPG8uGPInMseYa3jZXm0t/i0hdTbtTw5AW7pfDICtiL5VZZ0Ag7 DgmscMNlTqI+8lKXbROaJuutKDw9ptPS8Pi5JWSHA== 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; s=fm2; bh=jlTgiK HJ87/UmZUNtgNb8isqBvxL44zyfB0N3MpmNdU=; b=HhTSdE5yB0KI2+zPT59C9W Wf7VsUzbX/0xid1skmQijUoKc9n4Jvcc77PvtKDmjor49CfozHTpmw9TOyTfgsct DNDc4xk4QkFWupwRWFKKF6BpDOhjF/G4cv8X5Jno+QbpYc/kb/VjtLYgXv1PuB5I FzM19EPCjCGYxqdOYCD3zTuUN5RG6YGufHg2As5jFNe+JtARsyhlsR2FVA9AalLg bJEvNd5w+ph6S8I8PSvozDTkNHX2+eNZS9HaxoSMpkMcMh+5Su5NzZeqSuoJw3xf pwUix6CHsMEsF0YAp1YIB+H5au4j0NJlzYPLlPKDfXMhPE4nCk0o/nZtwvutP5VQ == X-ME-Sender: Received: from [192.168.1.77] (ppp109-252-166-127.pppoe.spdop.ru [109.252.166.127]) by mail.messagingengine.com (Postfix) with ESMTPA id 80A811025E; Sat, 12 May 2018 16:50:31 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-84BB8ACE-BE57-4CCB-B40A-EADDC7A739D5 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: <0C881DE7-7991-4E3C-A8C8-B77AEC2F55CC@ericsson.com> Date: Sun, 13 May 2018 00:02:29 +0300 Cc: Benjamin Kaduk , core , The IESG , "core-chairs@ietf.org" , "draft-ietf-core-senml@ietf.org" , Carsten Bormann , Cullen Jennings Content-Transfer-Encoding: 7bit Message-Id: <3C64FC4D-B771-4B43-BC19-DE7BD1132173@fastmail.fm> References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> <20180508000154.GY84491@kduck.kaduk.org> <44DB4CCE-62E7-43FF-9E0B-9AF27E14EE87@tzi.org> <0C881DE7-7991-4E3C-A8C8-B77AEC2F55CC@ericsson.com> To: =?utf-8?Q?Ari_Ker=C3=A4nen?= Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 12 May 2018 20:50:35 -0000 --Apple-Mail-84BB8ACE-BE57-4CCB-B40A-EADDC7A739D5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ari, > On 11 May 2018, at 20:05, Ari Ker=C3=A4nen wrot= e: >=20 > Hi all, >=20 > While addressing the IESG review comments regarding the use of time in Sen= ML we came up with a simple way to enable SenML Records to express also rela= tive times in the future that would have minimal impact to any existing use o= f SenML. We could use the following definition: >=20 > Values greater than or equal to 2**28 represent an absolute time relativ= e to the Unix epoch. Values less than 2**28 represent time relative to the c= urrent time. >=20 > That is, instead of only values less than zero, also values less than 2**2= 8 (268,435,456) would be used to express relative time. Negative values and z= ero are still times in past and "now" respectively, as before. Time values f= rom zero to 2**28 would be relative times in the future. >=20 > The only change this causes in the current use of SenML is that the smalle= st absolute time expressible in SenML becomes 1978-07-04 21:24:16 UTC instea= d of 1970-01-01 00:00 UTC. The absolute times after 1978 are still exactly t= he same ("Seconds after Unix epoch"). We are not aware of any deployments wi= th SenML data between 1970 and 1978 that would be impacted negatively by thi= s.=20 >=20 > For details, see: > https://github.com/core-wg/senml-spec/pull/129/files >=20 > Would anyone have concerns about including this change in SenML before pub= lication? >=20 > Since we are already very late in the process and we need to get SenML pub= lished as RFC very soon, we would also need to agree on this very soon. No objections from me personally, but please double check with the WG. Best Regards, Alexey= --Apple-Mail-84BB8ACE-BE57-4CCB-B40A-EADDC7A739D5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Ari,

On 11= May 2018, at 20:05, Ari Ker=C3=A4nen <ari.keranen@ericsson.com> wrote:

Hi all,=

While addressing the IESG review comments regarding the use of time in Se= nML we came up with a simple way to enable SenML Records to express also rel= ative times in the future that would have minimal impact to any existing use= of SenML. We could use the following definition:

  Values grea= ter than or equal to 2**28 represent an absolute time relative to the Unix e= poch. Values less than 2**28 represent time relative to the current time.

That is, instead of only values less than zero, also values less than 2**28= (268,435,456) would be used to express relative time. Negative values and z= ero are still times in past and "now" respectively, as before. Time values f= rom zero to 2**28 would be relative times in the future.

The only change t= his causes in the current use of SenML is that the smallest absolute time ex= pressible in SenML becomes 1978-07-04 21:24:16 UTC instead of 1970-01-01 00:= 00 UTC. The absolute times after 1978 are still exactly the same ("Seconds a= fter Unix epoch"). We are not aware of any deployments with SenML data betwe= en 1970 and 1978 that would be impacted negatively by this. 

For deta= ils, see:
https://github.com/core-wg/senml-spe= c/pull/129/files
=
Would anyone have concerns about including this chan= ge in SenML before publication?

Since we are already very late in the proc= ess and we need to get SenML published as RFC very soon, we would also need t= o agree on this very soon.

No objections from me personally, bu= t please double check with the WG.

Best Regards,
Alexey
= --Apple-Mail-84BB8ACE-BE57-4CCB-B40A-EADDC7A739D5-- From nobody Sat May 12 14:15:34 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2AA12E8E7; Sat, 12 May 2018 14:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qb2DBYnl9s1Q; Sat, 12 May 2018 14:15:31 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 5DD1712EACD; Sat, 12 May 2018 14:15:31 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id b130-v6so7599105oif.12; Sat, 12 May 2018 14:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RVR4SDNuIXG7JZoDxzu8aTMJ0pGPhBw/yQmG0Rz199Y=; b=Kjgoh3kZ6jBBdfm42yyT7ZZmkCn7xM+/+Zb93BJFb6s5cf+3h2djsG0mMgCCLvAeEt BikXsDGhI9vVWe/maC+/LMICuqGBwQHiLKvzPjPx6Kj6QTU1zLphObfnfrqMEHpqfzML 5EZzHohc8WFPctrG/y8IyhnJgiWtl5jYpKf4fM089dXiJsyX+zghjclaFlvKIANp8f/5 ReF866SJK3EHcDDbqr2JqtKc4zW9JG9EGHHe2pl60ruyyflvnpa3CoYS89SvhpiW7ess gLezSlBzuCC1KMmEYH2Bgy7W1u4gR1BNUj0vCsGn9ktvk1zyDxrLRi47vdh6Ki1XaRlb gvGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RVR4SDNuIXG7JZoDxzu8aTMJ0pGPhBw/yQmG0Rz199Y=; b=tv/6bvs+63pwf7gOjEcuQvD7P4+F+GRGqTUzHpklxHJWilYPpz6NIlWlXqZWJFv9i9 rYsEEwZohKMyLJ9y1YW5a3L1nUAf0B7NEjKdAF3yPsVeocutRzjxWEJFKvFEiINU6UH6 MAYrn4jvPAH6dmYPCiD1+kNgeTlLI9tFJqs/ncs+ZrTBFl04X0q+UJKSZ3gttEm2rn79 5IuOgM0tf+PXZULErJ7ZfuqAR+Af4VImaAGJDjXdhx6nbzSiSrhwRZCuddBdjmYXlaBX V8TXfUJnrF7gu7oXJ98+Lvxue4WtcNQ3zuTN7XBkZy/V2ixQqnclffs22Bs/iLV5ZZR8 sJ3Q== X-Gm-Message-State: ALKqPwd5hxyPe271Ftc7RpKqFaupu7xH1xWoFOPWuqIRlHUbptMA5YmG Udh8c7GBLt+3x4IIz2hqgNc= X-Google-Smtp-Source: AB8JxZqmQlk405Lv6t/IWZ02F3HJRRvOYwcgqMfJdvxLwSwNLFQYlT+H+KDTTXsz2/UC/RP7bYYATA== X-Received: by 2002:aca:eb4c:: with SMTP id j73-v6mr2862752oih.109.1526159730611; Sat, 12 May 2018 14:15:30 -0700 (PDT) Received: from [10.0.0.3] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id b45-v6sm4100848otb.55.2018.05.12.14.15.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 May 2018 14:15:29 -0700 (PDT) From: Michael Koster Message-Id: <7FD83B7D-DB09-4198-9DE6-26A0F5F1B2D9@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_14411A1F-C535-4C86-9CD5-31271070A044" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 12 May 2018 14:15:22 -0700 In-Reply-To: <3C64FC4D-B771-4B43-BC19-DE7BD1132173@fastmail.fm> Cc: =?utf-8?Q?Ari_Ker=C3=A4nen?= , "core-chairs@ietf.org" , "draft-ietf-core-senml@ietf.org" , Benjamin Kaduk , core , The IESG To: Alexey Melnikov References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> <20180508000154.GY84491@kduck.kaduk.org> <44DB4CCE-62E7-43FF-9E0B-9AF27E14EE87@tzi.org> <0C881DE7-7991-4E3C-A8C8-B77AEC2F55CC@ericsson.com> <3C64FC4D-B771-4B43-BC19-DE7BD1132173@fastmail.fm> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 12 May 2018 21:15:33 -0000 --Apple-Mail=_14411A1F-C535-4C86-9CD5-31271070A044 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 Michael Koster > On May 12, 2018, at 2:02 PM, Alexey Melnikov = wrote: >=20 > Hi Ari, >=20 > On 11 May 2018, at 20:05, Ari Ker=C3=A4nen > wrote: >=20 >> Hi all, >>=20 >> While addressing the IESG review comments regarding the use of time = in SenML we came up with a simple way to enable SenML Records to express = also relative times in the future that would have minimal impact to any = existing use of SenML. We could use the following definition: >>=20 >> Values greater than or equal to 2**28 represent an absolute time = relative to the Unix epoch. Values less than 2**28 represent time = relative to the current time. >>=20 >> That is, instead of only values less than zero, also values less than = 2**28 (268,435,456) would be used to express relative time. Negative = values and zero are still times in past and "now" respectively, as = before. Time values from zero to 2**28 would be relative times in the = future. >>=20 >> The only change this causes in the current use of SenML is that the = smallest absolute time expressible in SenML becomes 1978-07-04 21:24:16 = UTC instead of 1970-01-01 00:00 UTC. The absolute times after 1978 are = still exactly the same ("Seconds after Unix epoch"). We are not aware of = any deployments with SenML data between 1970 and 1978 that would be = impacted negatively by this.=20 >>=20 >> For details, see: >> https://github.com/core-wg/senml-spec/pull/129/files = >>=20 >> Would anyone have concerns about including this change in SenML = before publication? >>=20 >> Since we are already very late in the process and we need to get = SenML published as RFC very soon, we would also need to agree on this = very soon. >=20 > No objections from me personally, but please double check with the WG. >=20 > Best Regards, > Alexey > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_14411A1F-C535-4C86-9CD5-31271070A044 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

Michael = Koster

On = May 12, 2018, at 2:02 PM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi Ari,

On 11 May 2018, = at 20:05, Ari Ker=C3=A4nen <ari.keranen@ericsson.com> wrote:

Hi = all,

While addressing the IESG review comments = regarding the use of time in SenML we came up with a simple way to = enable SenML Records to express also relative times in the future that = would have minimal impact to any existing use of SenML. We could use the = following definition:

  Values greater = than or equal to 2**28 represent an absolute time relative to the Unix = epoch. Values less than 2**28 represent time relative to the current = time.

That is, instead of only values less than zero, = also values less than 2**28 (268,435,456) would be used to express = relative time. Negative values and zero are still times in past and = "now" respectively, as before. Time values from zero to 2**28 would be = relative times in the future.

The only = change this causes in the current use of SenML is that the smallest = absolute time expressible in SenML becomes 1978-07-04 21:24:16 UTC = instead of 1970-01-01 00:00 UTC. The absolute times after 1978 are still = exactly the same ("Seconds after Unix epoch"). We are not aware of any = deployments with SenML data between 1970 and 1978 that would be impacted = negatively by this. 

For details, see:
https://github.com/core-wg/senml-spec/pull/129/files=

Would anyone have concerns about including this change in = SenML before publication?

Since we are already very = late in the process and we need to get SenML published as RFC very soon, = we would also need to agree on this very soon.

No objections from me personally, but = please double check with the WG.

Best Regards,
Alexey
_____________________________________________= __
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_14411A1F-C535-4C86-9CD5-31271070A044-- From nobody Sun May 13 10:21:09 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF5B1200B9; Sun, 13 May 2018 10:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 o-QWq0wK_v02; Sun, 13 May 2018 10:20:58 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD0C71241FC; Sun, 13 May 2018 10:20:58 -0700 (PDT) Received: from mail-qt0-f173.google.com ([209.85.216.173]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1fHug1-0002mZ-TC; Sun, 13 May 2018 19:20:54 +0200 Received: by mail-qt0-f173.google.com with SMTP id f13-v6so13324841qtp.10; Sun, 13 May 2018 10:20:53 -0700 (PDT) X-Gm-Message-State: ALKqPwcFD23CFjGEtzxnH5+sa2IRlMFUEEDjkXYxUXzJFjoYVK7otkEl Nu6HFbn91LXJfkJO03UUht/Qw4wJ1IAfy0mpR5U= X-Google-Smtp-Source: AB8JxZqZEwtQVTpglPPQDC60VgSrjcDZx9SpddgRJyqnvXYfF6jdicJqaE6FcZ4gJ1nw5KYSh4NGeNRu5kLeXkpvmdU= X-Received: by 2002:a0c:c342:: with SMTP id j2-v6mr5958496qvi.49.1526232052831; Sun, 13 May 2018 10:20:52 -0700 (PDT) MIME-Version: 1.0 References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> <20180508000154.GY84491@kduck.kaduk.org> <44DB4CCE-62E7-43FF-9E0B-9AF27E14EE87@tzi.org> <0C881DE7-7991-4E3C-A8C8-B77AEC2F55CC@ericsson.com> <3C64FC4D-B771-4B43-BC19-DE7BD1132173@fastmail.fm> <7FD83B7D-DB09-4198-9DE6-26A0F5F1B2D9@gmail.com> In-Reply-To: <7FD83B7D-DB09-4198-9DE6-26A0F5F1B2D9@gmail.com> From: Klaus Hartke Date: Sun, 13 May 2018 19:20:40 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Michael Koster Cc: Alexey Melnikov , Benjamin Kaduk , The IESG , core , "core-chairs@ietf.org" , "draft-ietf-core-senml@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005a9bfc056c1997aa" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1526232058; f35fa1fd; X-HE-SMSGID: 1fHug1-0002mZ-TC Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 13 May 2018 17:21:02 -0000 --0000000000005a9bfc056c1997aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Sat 12. May 2018 at 23:15, Michael Koster wrote: > +1 > > Michael Koster > > On May 12, 2018, at 2:02 PM, Alexey Melnikov > wrote: > > Hi Ari, > > On 11 May 2018, at 20:05, Ari Ker=C3=A4nen wro= te: > > Hi all, > > While addressing the IESG review comments regarding the use of time in > SenML we came up with a simple way to enable SenML Records to express als= o > relative times in the future that would have minimal impact to any existi= ng > use of SenML. We could use the following definition: > > Values greater than or equal to 2**28 represent an absolute time > relative to the Unix epoch. Values less than 2**28 represent time relativ= e > to the current time. > > That is, instead of only values less than zero, also values less than > 2**28 (268,435,456) would be used to express relative time. Negative valu= es > and zero are still times in past and "now" respectively, as before. Time > values from zero to 2**28 would be relative times in the future. > > The only change this causes in the current use of SenML is that the > smallest absolute time expressible in SenML becomes 1978-07-04 21:24:16 U= TC > instead of 1970-01-01 00:00 UTC. The absolute times after 1978 are still > exactly the same ("Seconds after Unix epoch"). We are not aware of any > deployments with SenML data between 1970 and 1978 that would be impacted > negatively by this. > > For details, see: > https://github.com/core-wg/senml-spec/pull/129/files > > Would anyone have concerns about including this change in SenML before > publication? > > Since we are already very late in the process and we need to get SenML > published as RFC very soon, we would also need to agree on this very soon= . > > > No objections from me personally, but please double check with the WG. > > Best Regards, > Alexey > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0000000000005a9bfc056c1997aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1



On Sat 12. May 2018 at 23:1= 5, Michael Koster <michae= ljohnkoster@gmail.com> wrote:
+1

Michael Koster

On Ma= y 12, 2018, at 2:02 PM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Hi Ari,

On 11 May 2018, at 20:05, Ari K= er=C3=A4nen <ari.keranen@ericsson.com> wrote:

Hi all,

While addressing the IESG review comments regard= ing the use of time in SenML we came up with a simple way to enable SenML R= ecords to express also relative times in the future that would have minimal= impact to any existing use of SenML. We could use the following definition= :

=C2=A0=C2=A0Values greater than = or equal to 2**28 represent an absolute time relative to the Unix epoch. Va= lues less than 2**28 represent time relative to the current time.
That is, instead of only values less than z= ero, also values less than 2**28 (268,435,456) would be used to express rel= ative time. Negative values and zero are still times in past and "now&= quot; respectively, as before. Time values from zero to 2**28 would be rela= tive times in the future.

The only= change this causes in the current use of SenML is that the smallest absolu= te time expressible in SenML becomes 1978-07-04 21:24:16 UTC instead of 197= 0-01-01 00:00 UTC. The absolute times after 1978 are still exactly the same= ("Seconds after Unix epoch"). We are not aware of any deployment= s with SenML data between 1970 and 1978 that would be impacted negatively b= y this.=C2=A0

For details, see:
https://github.com/core-wg/senml-spec/pull/129/files=

Would anyone have concerns about includi= ng this change in SenML before publication?

Since we are already very late in the process and we need to get = SenML published as RFC very soon, we would also need to agree on this very = soon.
No objections from me personally, but please double check with the W= G.

Best Regards,
Alexey
_______= ________________________________________
core mailing list
core@ietf.org
https://www.iet= f.org/mailman/listinfo/core

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--0000000000005a9bfc056c1997aa-- From nobody Sun May 13 11:07:39 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EFF126CBF for ; Sun, 13 May 2018 11:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhklVRS5nPWw for ; Sun, 13 May 2018 11:07: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 BF85312751F for ; Sun, 13 May 2018 11:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526234846; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4wPo1xbkvgVUGOv1jEWoLWLyH29931PuQmaEibq0ulY=; b=KcGGILIfCyg8oLXWqrbr+TblIcFrn9WDq6bgb2b20uRw+iygf6XtYzlaQqdryu9T WB+bcD9jrkk1rJo3MsfS3dKtKAFBcBFDQ+5KbAWwMaQwER4DKmWb8ecdKTuyEFJl 8DJr25OJAbEM8vuSUBSexClsUCbiFCuwLjMMqoniD1I=; X-AuditID: c1b4fb3a-5a4b59c000006a47-3d-5af87ede5a98 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6A.25.27207.EDE78FA5; Sun, 13 May 2018 20:07:26 +0200 (CEST) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESSHC015.ericsson.se (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sun, 13 May 2018 20:06:35 +0200 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sun, 13 May 2018 20:06:35 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Sun, 13 May 2018 20:06:35 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Alexey Melnikov , core CC: Benjamin Kaduk , The IESG , "core-chairs@ietf.org" , "draft-ietf-core-senml@ietf.org" , "Carsten Bormann" , Cullen Jennings Thread-Topic: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) Thread-Index: AQHT14bG3vAIeJGLoECcXBuH3Y6fJ6QkiLkAgABmQYCAAIe3gIAFTUsAgAHUgoCAAWEuAA== Date: Sun, 13 May 2018 18:06:35 +0000 Message-ID: References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> <20180508000154.GY84491@kduck.kaduk.org> <44DB4CCE-62E7-43FF-9E0B-9AF27E14EE87@tzi.org> <0C881DE7-7991-4E3C-A8C8-B77AEC2F55CC@ericsson.com> <3C64FC4D-B771-4B43-BC19-DE7BD1132173@fastmail.fm> In-Reply-To: <3C64FC4D-B771-4B43-BC19-DE7BD1132173@fastmail.fm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="utf-8" Content-ID: <5D83C6811DE19249B1E28DCB86EE63BB@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRmVeSWpSXmKPExsUyM2K7ve69uh9RBqee6lvsf3+IyeLIlLus Fts2XmCz2Pd2PbPFz3dLmC0+rP/BaDHjz0Rmi+UbZzI5cHjsPHWAzWPJkp9MHpfPf2T0aDpz lNlj2qLMANYoLpuU1JzMstQifbsErow9p1rYCmaJVvzYP5e5gfGKSBcjJ4eEgInEx5NtbF2M XBxCAkcYJVbt+w3lbGGUuLV1L5TzjVGie/53JghnGaPEjpubWUH62QRsJZ607gOzRQScJN5t 384KUsQs8J1R4seplUDtHBzCAmkSC3eXQdSkS/z/+JwZwg6TuNo1mQXEZhFQlWh4NgVsDq+A vcTR9/0sEMtOMkl0bp/DDpLgBErMvvcBzGYUEJP4fmoNE4jNLCAucevJfCaIhwQkluw5zwxh i0q8fPyPFcJWkth77DoLyD3MApoS63fpQ7RaS/zaMRdqjKLElO6H7BA3CEqcnPkE7DYhoNuu /nvFOIFRchaSbbMQJs1CMmkWkkmzkExawMi6ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMw 9g9u+W21g/Hgc8dDjAIcjEo8vAzVP6KEWBPLiitzDzFKcDArifAqFgKFeFMSK6tSi/Lji0pz UosPMUpzsCiJ8zqlWUQJCaQnlqRmp6YWpBbBZJk4OKUaGLuv/Mr4mnjnz+WQF01hDG+dXq9u 3hS4M3++/15vUZ4OVR0LDdM76iKPV7fLXlNPvDXbZYNso0PTi/r+pzrrH4oILJi+XufwValN 95N46uZFTHksaJ+q7PLjl0BoZY7Ti1ez97eJqZebaL6xC1xUtjBG6NIT65lKGcf9noe2TnTJ /GPXxvFlnhJLcUaioRZzUXEiAPOhbBn5AgAA Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 13 May 2018 18:07:34 -0000 DQoNCj4gT24gMTMgTWF5IDIwMTgsIGF0IDAuMDIsIEFsZXhleSBNZWxuaWtvdiA8YWFtZWxuaWtv dkBmYXN0bWFpbC5mbT4gd3JvdGU6DQo+IA0KPiBIaSBBcmksDQo+IA0KPiBPbiAxMSBNYXkgMjAx OCwgYXQgMjA6MDUsIEFyaSBLZXLDpG5lbiA8YXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tPiB3cm90 ZToNCj4gDQo+PiBIaSBhbGwsDQo+PiANCj4+IFdoaWxlIGFkZHJlc3NpbmcgdGhlIElFU0cgcmV2 aWV3IGNvbW1lbnRzIHJlZ2FyZGluZyB0aGUgdXNlIG9mIHRpbWUgaW4gU2VuTUwgd2UgY2FtZSB1 cCB3aXRoIGEgc2ltcGxlIHdheSB0byBlbmFibGUgU2VuTUwgUmVjb3JkcyB0byBleHByZXNzIGFs c28gcmVsYXRpdmUgdGltZXMgaW4gdGhlIGZ1dHVyZSB0aGF0IHdvdWxkIGhhdmUgbWluaW1hbCBp bXBhY3QgdG8gYW55IGV4aXN0aW5nIHVzZSBvZiBTZW5NTC4gV2UgY291bGQgdXNlIHRoZSBmb2xs b3dpbmcgZGVmaW5pdGlvbjoNCj4+IA0KPj4gICBWYWx1ZXMgZ3JlYXRlciB0aGFuIG9yIGVxdWFs IHRvIDIqKjI4IHJlcHJlc2VudCBhbiBhYnNvbHV0ZSB0aW1lIHJlbGF0aXZlIHRvIHRoZSBVbml4 IGVwb2NoLiBWYWx1ZXMgbGVzcyB0aGFuIDIqKjI4IHJlcHJlc2VudCB0aW1lIHJlbGF0aXZlIHRv IHRoZSBjdXJyZW50IHRpbWUuDQo+PiANCj4+IFRoYXQgaXMsIGluc3RlYWQgb2Ygb25seSB2YWx1 ZXMgbGVzcyB0aGFuIHplcm8sIGFsc28gdmFsdWVzIGxlc3MgdGhhbiAyKioyOCAoMjY4LDQzNSw0 NTYpIHdvdWxkIGJlIHVzZWQgdG8gZXhwcmVzcyByZWxhdGl2ZSB0aW1lLiBOZWdhdGl2ZSB2YWx1 ZXMgYW5kIHplcm8gYXJlIHN0aWxsIHRpbWVzIGluIHBhc3QgYW5kICJub3ciIHJlc3BlY3RpdmVs eSwgYXMgYmVmb3JlLiBUaW1lIHZhbHVlcyBmcm9tIHplcm8gdG8gMioqMjggd291bGQgYmUgcmVs YXRpdmUgdGltZXMgaW4gdGhlIGZ1dHVyZS4NCj4+IA0KPj4gVGhlIG9ubHkgY2hhbmdlIHRoaXMg Y2F1c2VzIGluIHRoZSBjdXJyZW50IHVzZSBvZiBTZW5NTCBpcyB0aGF0IHRoZSBzbWFsbGVzdCBh YnNvbHV0ZSB0aW1lIGV4cHJlc3NpYmxlIGluIFNlbk1MIGJlY29tZXMgMTk3OC0wNy0wNCAyMToy NDoxNiBVVEMgaW5zdGVhZCBvZiAxOTcwLTAxLTAxIDAwOjAwIFVUQy4gVGhlIGFic29sdXRlIHRp bWVzIGFmdGVyIDE5NzggYXJlIHN0aWxsIGV4YWN0bHkgdGhlIHNhbWUgKCJTZWNvbmRzIGFmdGVy IFVuaXggZXBvY2giKS4gV2UgYXJlIG5vdCBhd2FyZSBvZiBhbnkgZGVwbG95bWVudHMgd2l0aCBT ZW5NTCBkYXRhIGJldHdlZW4gMTk3MCBhbmQgMTk3OCB0aGF0IHdvdWxkIGJlIGltcGFjdGVkIG5l Z2F0aXZlbHkgYnkgdGhpcy4gDQo+PiANCj4+IEZvciBkZXRhaWxzLCBzZWU6DQo+PiBodHRwczov L2dpdGh1Yi5jb20vY29yZS13Zy9zZW5tbC1zcGVjL3B1bGwvMTI5L2ZpbGVzDQo+PiANCj4+IFdv dWxkIGFueW9uZSBoYXZlIGNvbmNlcm5zIGFib3V0IGluY2x1ZGluZyB0aGlzIGNoYW5nZSBpbiBT ZW5NTCBiZWZvcmUgcHVibGljYXRpb24/DQo+PiANCj4+IFNpbmNlIHdlIGFyZSBhbHJlYWR5IHZl cnkgbGF0ZSBpbiB0aGUgcHJvY2VzcyBhbmQgd2UgbmVlZCB0byBnZXQgU2VuTUwgcHVibGlzaGVk IGFzIFJGQyB2ZXJ5IHNvb24sIHdlIHdvdWxkIGFsc28gbmVlZCB0byBhZ3JlZSBvbiB0aGlzIHZl cnkgc29vbi4NCj4gDQo+IE5vIG9iamVjdGlvbnMgZnJvbSBtZSBwZXJzb25hbGx5LCBidXQgcGxl YXNlIGRvdWJsZSBjaGVjayB3aXRoIHRoZSBXRy4NCg0KR3JlYXQhDQoNCkkgc2F3IHRoYXQgQ2hy aXN0aWFuLCBNaWNoYWVsLCBhbmQgS2xhdXMgZnJvbSB0aGUgV0cgYWxyZWFkeSArMSdkICh0aGFu a3MgZ3V5cyEpLiBJZiB0aGVyZSBhcmUgbm8gY29uY2VybnMgcmFpc2VkLCB3ZSBjb3VsZCBzdWJt aXQgYSBuZXcgdmVyc2lvbiB3aXRoIHRoaXMgY2hhbmdlIGluY2x1ZGVkLCBlLmcuLCBhdCB0aGUg ZW5kIG9mIHRoZSB3b3JrIHdlZWsuDQoNCg0KQ2hlZXJzLA0KQXJpDQoNCg== From nobody Tue May 15 00:28:48 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5894D12DA27 for ; Tue, 15 May 2018 00:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 J7r4GF8l8iUk for ; Tue, 15 May 2018 00:28:44 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (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 34DAE127876 for ; Tue, 15 May 2018 00:28:43 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w4F7ScsL018361 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 15 May 2018 09:28:39 +0200 Received: from DEFTHW99ERGMSX.ww902.siemens.net (defthw99ergmsx.ww902.siemens.net [139.22.70.132]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id w4F7Sa7u029856 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 15 May 2018 09:28:38 +0200 Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.120]) by DEFTHW99ERGMSX.ww902.siemens.net ([139.22.70.132]) with mapi id 14.03.0389.001; Tue, 15 May 2018 09:28:38 +0200 From: "Kovatsch, Matthias" To: "consultancy@vanderstok.org" , "Hannes Tschofenig" CC: "core@ietf.org" Thread-Topic: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPmCfncz1IX5t6GRJaeO0C+mMHM9QAhG46AAWOgH0A= Date: Tue, 15 May 2018 07:28:36 +0000 Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01F48F8A@DEFTHW99EL4MSX.ww902.siemens.net> References: <9970c70fea6ea457c74c8ae3ca303f76@xs4all.nl> In-Reply-To: <9970c70fea6ea457c74c8ae3ca303f76@xs4all.nl> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 15 May 2018 07:28:46 -0000 > Von: core [mailto:core-bounces@ietf.org] Im Auftrag von peter van der Sto= k > I probably misunderstand the meaning of optional. > What I understand from making ep optional, is that ep is not returned in = the lookup interface unless explicitly requested Differentiation > between registrations (endpoints) cannot be done by ep > (,d) value, but should be done differently (how?). To my understanding, the proposal is the following: A registration can be done without the "ep" query parameter, iff the Endpoi= nt Client Name can be derived in another way from the registration message.= This way should (or I guess Hannes would say MUST) be the security context= . In that sense, "ep" as registration query parameter becomes optional, but= "ep" remains a central, mandatory attribute in the RD for each registered = resource (used for endpoint lookup, filtering etc.). Thanks Ludwig for your pointer how this could work. @Hannes: Could you provide some more detail, how exactly the Endpoint Clien= t Name is extracted from "security context"? Overall, I like this, but we s= hould provide concrete text on how people should do it. Best, Matthias From nobody Tue May 15 01:15:15 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9152912D77A for ; Tue, 15 May 2018 01:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 gxB3stscNYIg for ; Tue, 15 May 2018 01:15:12 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50054.outbound.protection.outlook.com [40.107.5.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025EE120721 for ; Tue, 15 May 2018 01:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=67HOgalekUOLSQqHSxnmJGzktiUncj0/bAJTfBj/VJo=; b=bUXhlFvnOPlEEK+XXdu/64rk/piLatItMZAJPngb2RxDC/GMKd8VonZihLRKsFs7CeP0hq0nWYAVbzqhBg4HQdkdZlgPq5W6afbHkFBZtT3Bqg8GL96wNuhtCqkrM4aPo8ZzgLNlmQFlDtluJ7e9a6TI+2uOKBAMkVYCA2IDXOk= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2736.eurprd08.prod.outlook.com (10.166.199.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Tue, 15 May 2018 08:15:09 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Tue, 15 May 2018 08:15:07 +0000 From: Hannes Tschofenig To: "Kovatsch, Matthias" , "consultancy@vanderstok.org" CC: "core@ietf.org" Thread-Topic: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft Thread-Index: AdPmCfncz1IX5t6GRJaeO0C+mMHM9QAlTHGAAV/KmAAAAWEEwA== Date: Tue, 15 May 2018 08:15:07 +0000 Message-ID: References: <9970c70fea6ea457c74c8ae3ca303f76@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C01F48F8A@DEFTHW99EL4MSX.ww902.siemens.net> In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01F48F8A@DEFTHW99EL4MSX.ww902.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2736; 7:MCDXSzfYxh9QWEmRgD4+jRMN2qc5B2EJ2Wj2Y/E7E7uW2zzg1JsgJJfjYafWHbqE7DyvdqyW+bRXAJJK3aTONJupBqEgd4E1QC8m51fnqQXMjXRmEQT8gW4WC1RBLtxTgTzbACvlDwkQk7bbs3KnSdYpc+I4kbl4OH4IBlseK9oRgwJlY8mJVHCnaceBocKNe6SPFoyIxkNFsfHSu1sU1kTWESHS1iUr4EVvr2PnhzldtnyNyZlZqMz9pUnZy5pF x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2736; x-ms-traffictypediagnostic: VI1PR0801MB2736: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR0801MB2736; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2736; x-forefront-prvs: 0673F5BE31 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(39860400002)(366004)(39380400002)(189003)(199004)(40434004)(97736004)(316002)(476003)(68736007)(5890100001)(2501003)(3660700001)(486006)(446003)(5250100002)(72206003)(478600001)(66066001)(33656002)(3280700002)(25786009)(2906002)(2900100001)(110136005)(105586002)(6116002)(106356001)(7696005)(186003)(99286004)(6436002)(5660300001)(229853002)(81156014)(11346002)(55016002)(86362001)(9686003)(14454004)(102836004)(8676002)(81166006)(3846002)(26005)(7736002)(59450400001)(53936002)(74316002)(305945005)(4326008)(8936002)(6246003)(6506007)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2736; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: aNP2qQC90lfBf72KQDta6q3vVD7nx5cAgd4aXtqleCqBFrLckGH+44TczmHQ8T/+0hnbSqRFyPtMyIFTKeI/v5R1MzE5z5Su1bqpmOAwCNdh0vlQZcf+6A9WoUjgIfsu5rkcC50aeEE1YGLJMkRpLudfMDVFbrykmAXXGK0d4ioaPNdmgei8J2DgA3v+0xXt spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 21e008c8-ccbc-447d-5286-08d5ba3bf89c X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21e008c8-ccbc-447d-5286-08d5ba3bf89c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2018 08:15:07.8686 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2736 Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 15 May 2018 08:15:14 -0000 @Hannes: Could you provide some more detail, how exactly the Endpoint Clien= t Name is extracted from "security context"? Overall, I like this, but we s= hould provide concrete text on how people should do it. You want to store the security context on the server side and the Endpoint = Client Name points to the identifier part of it. (Other parts of the security context will be relevant for other purposes.) * For PSK-based credential the Endpoint Client Name becomes the PSK Identi= ty * For raw-public keys the Endpoint Client Name becomes the SubjectPublicKe= yInfo structure (or a hash of it). * For certificates the Endpoint Client Name becomes the leftmost CN compon= ent of subject name or the SubjectAltName of the certificate, depending on = what you use. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Tue May 15 02:45:27 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE42112D883; Tue, 15 May 2018 02:45:21 -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 4-P6zgaZkTlx; Tue, 15 May 2018 02:45:19 -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 9A3EA12D7F9; Tue, 15 May 2018 02:45:19 -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 w4F9jEqZ028282; Tue, 15 May 2018 11:45:14 +0200 (CEST) Received: from [192.168.217.102] (p5DC7F793.dip0.t-ipconnect.de [93.199.247.147]) (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 40lXjk2dVSzDXX1; Tue, 15 May 2018 11:45:14 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Tue, 15 May 2018 11:45:13 +0200 Cc: "ace@ietf.org" , core X-Mao-Original-Outgoing-Id: 548070311.775547-263e1e3fb306d3ae62df1f2f68b3fd0f Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP 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, 15 May 2018 09:45:22 -0000 On May 15, 2018, at 10:56, Hannes Tschofenig = wrote: >=20 > I am curious whether it would be possible to ask for early media-type = registration of at least these two types: > - application/pkcs7-mime > - application/pkcs10 There already are registered. I think you are talking about getting Content-Format numbers for these? Do we need any parameters or content-codings with that? Gr=C3=BC=C3=9Fe, Carsten From nobody Tue May 15 03:09:22 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5222B12D86B for ; Tue, 15 May 2018 03:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQUmIfFcpxWO for ; Tue, 15 May 2018 03:09:18 -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 EF15F12D868 for ; Tue, 15 May 2018 03:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526378954; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VoBu8JJmmPGCoPwPijCJZcXnlJl0NcJBDUvDYh8hPlA=; b=OWmonluN1XGVscMCbNQGK3nu8MKJ1MbNOhR/g7BXh4S60s423UiH9IzfpRGD7PWs UA7NtbNnx33IRSgB1qw6jxAXx94dd4ynDsS8QXmMGdlMzE5Ash+F5kdpQTFXbA64 4VkCYR+XDR0kt4dcTnRfGsneapFwSVaLHMLKsnuRWTE=; X-AuditID: c1b4fb30-263479c00000169b-7b-5afab1ca3d5f Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 47.0A.05787.AC1BAFA5; Tue, 15 May 2018 12:09:14 +0200 (CEST) To: undisclosed-recipients:; Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSHC006.ericsson.se (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 15 May 2018 12:09:13 +0200 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 15 May 2018 12:09:13 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Tue, 15 May 2018 12:09:13 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= CC: Alexey Melnikov , core , "draft-ietf-core-senml@ietf.org" , =?utf-8?B?QXJpIEtlcsOkbmVu?= Thread-Topic: [core] WG consensus call for draft-ietf-core-senml amendments Thread-Index: AQHT7DTG4l1lryZLHkSxmp4slDP5mA== Date: Tue, 15 May 2018 10:09:13 +0000 Message-ID: <5734DC8F-9A64-4B82-A7AE-6AEC77144406@ericsson.com> References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> <20180508000154.GY84491@kduck.kaduk.org> <44DB4CCE-62E7-43FF-9E0B-9AF27E14EE87@tzi.org> <0C881DE7-7991-4E3C-A8C8-B77AEC2F55CC@ericsson.com> <3C64FC4D-B771-4B43-BC19-DE7BD1132173@fastmail.fm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: multipart/signed; boundary="Apple-Mail=_C2BCF433-0316-402D-979D-D676747ED96B"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42KZGbFdRffUxl9RBu9+GFrsf3+IyWLf2/XM Fj/fLWF2YPbYeeoAm8eSJT+ZApiiuGxSUnMyy1KL9O0SuDI2z/3DUjB5LWPF4S1/2BsYP89i 7GLk5JAQMJFY+WsNaxcjF4eQwBFGia9P3rKBJEQEZCTmzn4MldjCKHFv1gko5xujxM/9t9kg nGWMEvueXGMFaWETcJb49KyRHSTBLHCIUWLF6XNMIAlhAXeJ6bfms0DM9ZE4u7+REcLWk9j5 bDE7iM0ioCqxZNEtZhCbV8Be4vWSC2B3CAn8Z5I4sigaxOYUcJBYtXMn2ExGATGJ76fWgNnM AuISt57MZ4J4SETi4cXTbBC2qMTLx/9YIWwlib3HrrNAHDeFUeJC02qoZYISJ2c+YYFYpi7x bdZt5gmM4rOQzJ2FrGcWkh6IoiSJfd/PsUPY2hLLFr5mhrA1JfZ3L2fBFNeQ6Pw2kRXCNpV4 ffQjI4RtLTHj10E2CFtRYkr3Q/YFjNyrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQITw8Et vw12ML587niIUYCDUYmH99DaX1FCrIllxZW5hxhVgOY82rD6AqMUS15+XqqSCO9uo59RQrwp iZVVqUX58UWlOanFhxilOViUxHkt/DZHCQmkJ5akZqemFqQWwWSZODilGhiVwlSqXE93dJWt CjFRizz0Q2FPp/X802erTJxUeeN+yhyZaJReudH8Z6vfy92HvkU+k8yf//edxH1H6UctDCwB 86YGSp0MM0+Y8WKFxkbW7ao3FL179+9tn7JJSuhqXvgC3yVSDN3bZnAp1Yec4E+XSbxQoXdV ybHNPOpM4qJo0S27Pt4966/EUpyRaKjFXFScCADjLgUKFAMAAA== Archived-At: Subject: [core] WG consensus call for draft-ietf-core-senml amendments 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, 15 May 2018 10:09:20 -0000 --Apple-Mail=_C2BCF433-0316-402D-979D-D676747ED96B Content-Type: multipart/alternative; boundary="Apple-Mail=_0E4F0097-8C83-4F6A-8006-F8BA52D728D4" --Apple-Mail=_0E4F0097-8C83-4F6A-8006-F8BA52D728D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, there seems to be consensus on the changes to the Times values among = those who participated in the discussion.=20 Just to be sure lets have a last consensus call on this, allowing for = any other concerns to be voiced, ending by EOB Thursday 17th.=20 Ciao! - - Jaime Jim=C3=A9nez > On 13 May 2018, at 21.06, Ari Ker=C3=A4nen = wrote: >=20 >=20 >=20 >> On 13 May 2018, at 0.02, Alexey Melnikov = wrote: >>=20 >> Hi Ari, >>=20 >> On 11 May 2018, at 20:05, Ari Ker=C3=A4nen = wrote: >>=20 >>> Hi all, >>>=20 >>> While addressing the IESG review comments regarding the use of time = in SenML we came up with a simple way to enable SenML Records to express = also relative times in the future that would have minimal impact to any = existing use of SenML. We could use the following definition: >>>=20 >>> Values greater than or equal to 2**28 represent an absolute time = relative to the Unix epoch. Values less than 2**28 represent time = relative to the current time. >>>=20 >>> That is, instead of only values less than zero, also values less = than 2**28 (268,435,456) would be used to express relative time. = Negative values and zero are still times in past and "now" respectively, = as before. Time values from zero to 2**28 would be relative times in the = future. >>>=20 >>> The only change this causes in the current use of SenML is that the = smallest absolute time expressible in SenML becomes 1978-07-04 21:24:16 = UTC instead of 1970-01-01 00:00 UTC. The absolute times after 1978 are = still exactly the same ("Seconds after Unix epoch"). We are not aware of = any deployments with SenML data between 1970 and 1978 that would be = impacted negatively by this.=20 >>>=20 >>> For details, see: >>> https://github.com/core-wg/senml-spec/pull/129/files >>>=20 >>> Would anyone have concerns about including this change in SenML = before publication? >>>=20 >>> Since we are already very late in the process and we need to get = SenML published as RFC very soon, we would also need to agree on this = very soon. >>=20 >> No objections from me personally, but please double check with the = WG. >=20 > Great! >=20 > I saw that Christian, Michael, and Klaus from the WG already +1'd = (thanks guys!). If there are no concerns raised, we could submit a new = version with this change included, e.g., at the end of the work week. >=20 >=20 > Cheers, > Ari >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_0E4F0097-8C83-4F6A-8006-F8BA52D728D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all,

there seems to = be consensus on the changes to the Times values among those who = participated in the discussion. 
Just to be = sure lets have a last consensus call on this, allowing for any other = concerns to be voiced, ending by EOB Thursday = 17th. 

Ciao!
- - Jaime Jim=C3=A9nez

On 13 May 2018, at 21.06, Ari Ker=C3=A4nen <ari.keranen@ericsson.com> wrote:



On 13 = May 2018, at 0.02, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi Ari,

On 11 May 2018, at = 20:05, Ari Ker=C3=A4nen <ari.keranen@ericsson.com> wrote:

Hi all,

While addressing the IESG review comments regarding the use = of time in SenML we came up with a simple way to enable SenML Records to = express also relative times in the future that would have minimal impact = to any existing use of SenML. We could use the following definition:

 Values greater than or equal to 2**28 = represent an absolute time relative to the Unix epoch. Values less than = 2**28 represent time relative to the current time.

That is, instead of only values less than zero, also values = less than 2**28 (268,435,456) would be used to express relative time. = Negative values and zero are still times in past and "now" respectively, = as before. Time values from zero to 2**28 would be relative times in the = future.

The only change this causes in the = current use of SenML is that the smallest absolute time expressible in = SenML becomes 1978-07-04 21:24:16 UTC instead of 1970-01-01 00:00 UTC. = The absolute times after 1978 are still exactly the same ("Seconds after = Unix epoch"). We are not aware of any deployments with SenML data = between 1970 and 1978 that would be impacted negatively by this. 

For details, see:
https://github.com/core-wg/senml-spec/pull/129/files

Would anyone have concerns about including = this change in SenML before publication?

Since we are already very late in the process and we need to = get SenML published as RFC very soon, we would also need to agree on = this very soon.

No objections = from me personally, but please double check with the WG.

Great!

I saw that Christian, Michael, and Klaus from the WG already = +1'd (thanks guys!). If there are no concerns raised, we could submit a = new version with this change included, e.g., at the end of the work = week.


Cheers,
Ari

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

= --Apple-Mail=_0E4F0097-8C83-4F6A-8006-F8BA52D728D4-- --Apple-Mail=_C2BCF433-0316-402D-979D-D676747ED96B Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMxjCCBfww ggPkoAMCAQICEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz MB4XDTE4MDExNjEyMjkzMVoXDTIxMDExNjEyMjkzMFowaTERMA8GA1UECgwIRXJpY3Nzb24xFzAV BgNVBAMMDkphaW1lIEppbcOpbmV6MSkwJwYJKoZIhvcNAQkBFhpqYWltZS5qaW1lbmV6QGVyaWNz c29uLmNvbTEQMA4GA1UEBRMHZWphamltbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AI+DThV/KcZen+MJmBGqpcdYmsas7GdU5GbP2v6kJi3InKvo92Ypf2Ca2GV6WpHrwMwwvWdl+6mP BPsjmjGsJ4UXg2Uu4QRKK6Jqq6azB3+1mBHXOuPu5MwSqRXRsU72fxqEjAT8JZM5xKzqeZ+e7onX vUY2IQnDDo3Y6+hOvPe64N+qwgbQVXLL639YPQjxiKElpZccSmCvShq1N9Ct/i/ecm81uJV4czZN 3Cdt6UYZwelaV+dHeZi07sLPP6MAvFoGOa2sgsyA99V77XwAVu8jY2Z8PEnwrMqAHfhqNEsXnOXs IH3HH/khzjkNVxv/ohlj6jwR1EoJ6kYRlLDEUPsCAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7 oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j cmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlh LmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGmphaW1lLmppbWVuZXpAZXJpY3Nzb24u Y29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUd399BTtL2oFkOMio32TINfqzZe4wHwYDVR0jBBgwFoAUHHsZnpec dqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBU8yzcwgcR S4MZI/xYSuEHqlzNiZMmlK4JbR1kDjd/eY+mYqgM9NPaLqgzt+pdUfbEh7bl+y19UDMXmsbzWS+1 e0Rh76h/TYuo0YLuvW7V+rQKa335v0L/WHNO5F/x4rIHaxUeGboOtuMLuE8jOxe6iUbpuPRWHO9Y glcqSBkHLTs7sDu//kGAzgMb0a8bs07UdG33BP950NfrTzEnHnS4scqnERGIQDElzHpBEe32SuIF 0Xbvl6NSzIvvqu5egdhn/zyQ89n28aWKgxfgsm1Q7ln452mncP55ZYJeb4cFDmIa2yUjbHf9CxeK xtlao5ZGkHLx4iKEwFkVE3KTR9ckCD8C1Cy2kNMRuzC6b6tixbTM8ff0tIDkG8nvb4h/Qi5rfUAW fkPZndQo0Ot9NWiY9aGUr/6DejVE+x1RFhWdeGaWyMpk/8/N7z3uSJIBZY+01mzs3PAGJBFQL6uS naoouYsvlAJ0oBCPn3eAUu4J5IuZfKxPpfpK2Tn+Su0ctU6N6TFAHaFqFyVw7WXky5XwGcIHV8Y4 JKWsknwImPJbolfOnydAPDLD3/ktTd39wdOljSeq0WZeAoZi4GW4ILre4XIy+LrGhgm0xPe7Igtf P3DXIbNVGfvPE/58zm/+bg1Q91Nf2VEYDgGbR1cPDDs9l771qWKsGFvRpq1j87nAADCCBsIwggSq oAMCAQICEFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFT b25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meis bhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdD dxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhlj PA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocy BmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqS Yf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl 2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLd vo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG 46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29j c3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgw BgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpo dHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3Js MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEP Rs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vR lZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2N ZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+ xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0 A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0u ijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9Oia AIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnO qBvxOgftYug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y 3N3Xo5H1MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE4MDUxNTEwMDkxMlowIwYJKoZIhvcNAQkEMRYEFJw+H2ZjWgm1khjoT3PDZUXy/9fm MGoGCSsGAQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhACGyzNtCtGLv+Y3N3Xo5H1MGwGCyqG SIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAIbLM20K0Yu/5jc3dejkfUwDQYJKoZIhvcN AQEBBQAEggEAeEA1EArM5bY73kdJkVthdhoREkjk7HbrrpPSEXyVY84OHDaK9tZCRnjvAd8pGCYi bxB3pFx4/j7J25Uev4X/aigVOeyO6FE1E026bQr5hWzdprukBXY0hXeW75Tg5BxI59bsGe18agJX OXmwpFOkN2KXcUl1JxIGzN1T4Hf/2oCRWP7VmSgm8eUdE3xCqt7fI17CywRLZl8WNBbjMcpvFxZl S9DG0UEgnbJEUookbQWLYODJzf5bKFDMRkmfCadkE4VCdZHRaFzU68IRrGyiqytsTDrRO22dPPmA IbcKicnErI3VGnQQPEVokfTAYYFKSQzvDaN6RR5023rOPlCDPwAAAAAAAA== --Apple-Mail=_C2BCF433-0316-402D-979D-D676747ED96B-- From nobody Wed May 16 01:11:22 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB6512DA0A for ; Wed, 16 May 2018 01:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR3OmtK2cFqj for ; Wed, 16 May 2018 01:11:17 -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 A1F9712D77B for ; Wed, 16 May 2018 01:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526458274; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=82j8UewEY/2BdI2a2hFCLDagCSklXZyKSQ/cCyH0Vx4=; b=HawuUVN++ELtCHGFgR6zbAn4Ny5uJXiR1UJ94b7y9cvHtO1qBeM8t+BFZl+mCFU4 gYUXd2G/Tp65+2safbvCJXnmvgTW06LbkAI9Btvpp0Q4ttqRXp6qwkmmWWQuZ+Ip AoEFK3/JrQY8AKiOtlJT2J4GihyrrMJmlB4w+wLW82I=; X-AuditID: c1b4fb2d-6a1ff7000000050d-50-5afbe7a29043 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 84.79.01293.2A7EBFA5; Wed, 16 May 2018 10:11:14 +0200 (CEST) Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.382.0; Wed, 16 May 2018 10:11:14 +0200 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 66B6048085C; Wed, 16 May 2018 11:11:14 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 016DF48070F; Wed, 16 May 2018 11:11:13 +0300 (EEST) To: =?UTF-8?Q?Jaime_Jim=c3=a9nez?= CC: "draft-ietf-core-senml@ietf.org" , core , Alexey Melnikov References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> <20180508000154.GY84491@kduck.kaduk.org> <44DB4CCE-62E7-43FF-9E0B-9AF27E14EE87@tzi.org> <0C881DE7-7991-4E3C-A8C8-B77AEC2F55CC@ericsson.com> <3C64FC4D-B771-4B43-BC19-DE7BD1132173@fastmail.fm> <5734DC8F-9A64-4B82-A7AE-6AEC77144406@ericsson.com> From: Mohit Sethi Message-ID: <01c1f22f-f178-c967-9b12-70f689768a93@ericsson.com> Date: Wed, 16 May 2018 11:11:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5734DC8F-9A64-4B82-A7AE-6AEC77144406@ericsson.com> Content-Type: multipart/alternative; boundary="------------9EBB845BB51CFFEEE0E94414" Content-Language: en-US X-AV-Checked: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7iu6i57+jDG7cs7LY//4Qk8W+t+uZ LX6+W8LswOyx89QBNo8lS34yBTBFcdmkpOZklqUW6dslcGW0LHrKXnB8GWPFm+MT2RoY24q7 GDk5JARMJI58WsXYxcjFISRwhFGi6c85NghnB6PEjvOXoTKbGSW+P/3BBOEsZJSY9W0zE0i/ sICXxKfbX1hAbBEBe4lbHY9YQIqYBdoZJd40LmGH6NjKLLFs5yawKjYBPYnOc8eZQWxeoI6f 59rYQWwWAVWJk42XwGpEBSIk7p3/xAZRIyhxcuYTsDingIPEkxM7wWxmgTCJdf/nM0PY4hK3 nsxngvhIWWJByyJGEFtIQF1ia8cBxgmMwrOQjJqFpH0WknYI20Ji5vzzjBC2vETz1tlQNRoS rXPmsiOLL2BkX8UoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGFUHt/zW3cG4+rXjIUYBDkYl Hl77J7+jhFgTy4orcw8xSnAwK4nwZvIChXhTEiurUovy44tKc1KLDzFKc7AoifPqrdoTJSSQ nliSmp2aWpBaBJNl4uCUamAU+dCr9HPzraefa4ruPgj8PStpflA806xHP6ybii4wfvx2aP3i EM7TBcd5V2Ue2Xn+2Px7tYenlhgJn1Bb4Pru05HqeWWMk5w7VyhuuL3s1yY/tnLuy0mt5aG/ E4Rf/7DsiRQQbr6zXbQ1eb0+y9KiFanzN57X8d7S1ag50zjQZfqqdV71eyc+VWIpzkg01GIu Kk4EAEIZ2pymAgAA Archived-At: Subject: Re: [core] WG consensus call for draft-ietf-core-senml amendments 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, 16 May 2018 08:11:20 -0000 --------------9EBB845BB51CFFEEE0E94414 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi, I have previously implemented senml. I am fine with the amendments and would like to see the draft move forward. --Mohit On 05/15/2018 01:09 PM, Jaime Jiménez wrote: > Hi all, > > there seems to be consensus on the changes to the Times values among > those who participated in the discussion. > Just to be sure lets have a last consensus call on this, allowing for > any other concerns to be voiced, ending by *EOB Thursday 17th*. > > Ciao! > - - Jaime Jiménez > >> On 13 May 2018, at 21.06, Ari Keränen > > wrote: >> >> >> >>> On 13 May 2018, at 0.02, Alexey Melnikov >> > wrote: >>> >>> Hi Ari, >>> >>> On 11 May 2018, at 20:05, Ari Keränen >> > wrote: >>> >>>> Hi all, >>>> >>>> While addressing the IESG review comments regarding the use of time >>>> in SenML we came up with a simple way to enable SenML Records to >>>> express also relative times in the future that would have minimal >>>> impact to any existing use of SenML. We could use the following >>>> definition: >>>> >>>>  Values greater than or equal to 2**28 represent an absolute time >>>> relative to the Unix epoch. Values less than 2**28 represent time >>>> relative to the current time. >>>> >>>> That is, instead of only values less than zero, also values less >>>> than 2**28 (268,435,456) would be used to express relative time. >>>> Negative values and zero are still times in past and "now" >>>> respectively, as before. Time values from zero to 2**28 would be >>>> relative times in the future. >>>> >>>> The only change this causes in the current use of SenML is that the >>>> smallest absolute time expressible in SenML becomes 1978-07-04 >>>> 21:24:16 UTC instead of 1970-01-01 00:00 UTC. The absolute times >>>> after 1978 are still exactly the same ("Seconds after Unix epoch"). >>>> We are not aware of any deployments with SenML data between 1970 >>>> and 1978 that would be impacted negatively by this. >>>> >>>> For details, see: >>>> https://github.com/core-wg/senml-spec/pull/129/files >>>> >>>> Would anyone have concerns about including this change in SenML >>>> before publication? >>>> >>>> Since we are already very late in the process and we need to get >>>> SenML published as RFC very soon, we would also need to agree on >>>> this very soon. >>> >>> No objections from me personally, but please double check with the WG. >> >> Great! >> >> I saw that Christian, Michael, and Klaus from the WG already +1'd >> (thanks guys!). If there are no concerns raised, we could submit a >> new version with this change included, e.g., at the end of the work week. >> >> >> Cheers, >> Ari >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------9EBB845BB51CFFEEE0E94414 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hi,

I have previously implemented senml. I am fine with the amendments and would like to see the draft move forward.

--Mohit


On 05/15/2018 01:09 PM, Jaime Jiménez wrote:
Hi all,

there seems to be consensus on the changes to the Times values among those who participated in the discussion. 
Just to be sure lets have a last consensus call on this, allowing for any other concerns to be voiced, ending by EOB Thursday 17th. 

Ciao!
- - Jaime Jiménez

On 13 May 2018, at 21.06, Ari Keränen <ari.keranen@ericsson.com> wrote:



On 13 May 2018, at 0.02, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

Hi Ari,

On 11 May 2018, at 20:05, Ari Keränen <ari.keranen@ericsson.com> wrote:

Hi all,

While addressing the IESG review comments regarding the use of time in SenML we came up with a simple way to enable SenML Records to express also relative times in the future that would have minimal impact to any existing use of SenML. We could use the following definition:

 Values greater than or equal to 2**28 represent an absolute time relative to the Unix epoch. Values less than 2**28 represent time relative to the current time.

That is, instead of only values less than zero, also values less than 2**28 (268,435,456) would be used to express relative time. Negative values and zero are still times in past and "now" respectively, as before. Time values from zero to 2**28 would be relative times in the future.

The only change this causes in the current use of SenML is that the smallest absolute time expressible in SenML becomes 1978-07-04 21:24:16 UTC instead of 1970-01-01 00:00 UTC. The absolute times after 1978 are still exactly the same ("Seconds after Unix epoch"). We are not aware of any deployments with SenML data between 1970 and 1978 that would be impacted negatively by this. 

For details, see:
https://github.com/core-wg/senml-spec/pull/129/files

Would anyone have concerns about including this change in SenML before publication?

Since we are already very late in the process and we need to get SenML published as RFC very soon, we would also need to agree on this very soon.

No objections from me personally, but please double check with the WG.

Great!

I saw that Christian, Michael, and Klaus from the WG already +1'd (thanks guys!). If there are no concerns raised, we could submit a new version with this change included, e.g., at the end of the work week.


Cheers,
Ari

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



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

--------------9EBB845BB51CFFEEE0E94414-- From nobody Wed May 16 03:15:48 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7490912D7EA; Wed, 16 May 2018 03:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 wtK0wofz5ff7; Wed, 16 May 2018 03:15:38 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0053.outbound.protection.outlook.com [104.47.1.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E09612D7E4; Wed, 16 May 2018 03:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b6K679zP+l856ON20pDQ7PKdbgKYoYknjGZBttwZyks=; b=G6h0ffspg8O8GWGGkRlQ3+exDk7wsWr7XHYXGhe8DBhwa3ALKLQdtKXgdJX0CG8scI8PuHl92ZTVJCgoH9xLzExtctok6j/v1TIHG8dndfS71veQiwE8P0PiTFYxp+0AshMbh3zcLhXYDxm+3WQQ313yUCbMT/JNFua/0MA/qKw= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1518.eurprd08.prod.outlook.com (10.167.210.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Wed, 16 May 2018 10:15:35 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Wed, 16 May 2018 10:15:35 +0000 From: Hannes Tschofenig To: Carsten Bormann CC: "ace@ietf.org" , core Thread-Topic: [Ace] Early media-type registration for EST over CoAP Thread-Index: AdPsKhcQ9FbwjekBT1SYYUyoYtG38gAB1S+AAAdDwHA= Date: Wed, 16 May 2018 10:15:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.194.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1518; 7:eJfs75bNpaQ8YojPd7RN/gstR2PcBKcoypdule8vmEL7a/LperTflzkhQftETv84WkoCUZNMMb14AVmbZuqr7n1++LDrBPeYEjQzdmylShhrjkxgo1XHr6OsjwuJLZbGBVjSnYcvw0xn4Gp1yOnTQSfLlzM+z2dhrQvLrsrmk+r9M5XF0izuu/Gu2nwCErFrXz6MqJQsXrfJzoq7sbAq0/2mdb3gOF9FvkHJl5jT+rgi85iwtuwxFmnqUAtrBxb5 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1518; x-ms-traffictypediagnostic: VI1PR0801MB1518: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1518; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1518; x-forefront-prvs: 0674DC6DD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(366004)(39860400002)(396003)(376002)(346002)(13464003)(40434004)(57704003)(199004)(189003)(6506007)(86362001)(2906002)(3280700002)(99286004)(14454004)(478600001)(5660300001)(26005)(102836004)(66066001)(55016002)(486006)(53546011)(6436002)(5250100002)(229853002)(76176011)(3846002)(6116002)(11346002)(7696005)(72206003)(446003)(186003)(5890100001)(476003)(59450400001)(305945005)(68736007)(9686003)(3660700001)(2900100001)(53936002)(8936002)(25786009)(74316002)(6916009)(4326008)(7736002)(105586002)(81156014)(81166006)(106356001)(8676002)(33656002)(6246003)(97736004)(54906003)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1518; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 99JY6WnH90yI4IslCSRzbtDADvpp/dVDhti94gblUZokFs23qpVFTrHpR54RY9r3mMEWUsbYq+6R3aByTqSxYfjLy1Chi/AvJ+9BRW6C+/wKKB/AUmtWrKQ9vEW1Rfmm5AiooMbbe3/CwW5mbEUatcMqWQDfhqdZQXkMLmgWVQ6Sr5G284roNaUZMuDf5u3A spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 58e5aac0-1e2c-4471-9e18-08d5bb15f6ed X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 58e5aac0-1e2c-4471-9e18-08d5bb15f6ed X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2018 10:15:35.3486 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1518 Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP 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, 16 May 2018 10:15:41 -0000 SGkgQ2Fyc3RlbiwNCg0KWWVzLCBJIGFtIHRhbGtpbmcgYWJvdXQgdGhlIENvbnRlbnQtRm9ybWF0 IG51bWJlcnMgZm9yIHRoZW0uDQpXb3VsZCBydD0iYWNlLmVzdCIgYmUgdGhlIHBhcmFtZXRlciB5 b3UgYXJlIHRhbGtpbmcgYWJvdXQ/DQoNCkNpYW8NCkhhbm5lcw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIFttYWlsdG86Y2Fib0B0emkub3JnXQ0K U2VudDogMTUgTWF5IDIwMTggMTE6NDUNClRvOiBIYW5uZXMgVHNjaG9mZW5pZw0KQ2M6IGFjZUBp ZXRmLm9yZzsgY29yZQ0KU3ViamVjdDogUmU6IFtBY2VdIEVhcmx5IG1lZGlhLXR5cGUgcmVnaXN0 cmF0aW9uIGZvciBFU1Qgb3ZlciBDb0FQDQoNCk9uIE1heSAxNSwgMjAxOCwgYXQgMTA6NTYsIEhh bm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPiB3cm90ZToNCj4NCj4g SSBhbSBjdXJpb3VzIHdoZXRoZXIgaXQgd291bGQgYmUgcG9zc2libGUgdG8gYXNrIGZvciBlYXJs eSBtZWRpYS10eXBlIHJlZ2lzdHJhdGlvbiBvZiBhdCBsZWFzdCB0aGVzZSB0d28gdHlwZXM6DQo+ IC0gYXBwbGljYXRpb24vcGtjczctbWltZQ0KPiAtIGFwcGxpY2F0aW9uL3BrY3MxMA0KDQpUaGVy ZSBhbHJlYWR5IGFyZSByZWdpc3RlcmVkLg0KDQpJIHRoaW5rIHlvdSBhcmUgdGFsa2luZyBhYm91 dCBnZXR0aW5nIENvbnRlbnQtRm9ybWF0IG51bWJlcnMgZm9yIHRoZXNlPw0KRG8gd2UgbmVlZCBh bnkgcGFyYW1ldGVycyBvciBjb250ZW50LWNvZGluZ3Mgd2l0aCB0aGF0Pw0KDQpHcsO8w59lLCBD YXJzdGVuDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmls ZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRz IHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9y IGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Wed May 16 03:26:49 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8274212D7F1; Wed, 16 May 2018 03:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 8t0iAC0Q3oAk; Wed, 16 May 2018 03:26:46 -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 34F1D12D7EA; Wed, 16 May 2018 03:26:46 -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 w4GAQfcF006666; Wed, 16 May 2018 12:26:41 +0200 (CEST) Received: from [100.75.214.40] (ip-109-41-67-168.web.vodafone.de [109.41.67.168]) (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 40m9b52ZqDzDXlC; Wed, 16 May 2018 12:26:41 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-EA3C581A-0CEB-415E-8ED0-9D97B4CAF75E Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (15E302) In-Reply-To: Date: Wed, 16 May 2018 12:26:40 +0200 Cc: "ace@ietf.org" , core Content-Transfer-Encoding: 7bit Message-Id: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> References: To: Hannes Tschofenig Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP 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, 16 May 2018 10:26:49 -0000 --Apple-Mail-EA3C581A-0CEB-415E-8ED0-9D97B4CAF75E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I was thinking about media type parameters such as charset=3D"utf-8". The RT= value need to be registered separately, but we can be a bit lazy about that= .=20 Sent from mobile > On 16. May 2018, at 12:15, Hannes Tschofenig w= rote: >=20 > Hi Carsten, >=20 > Yes, I am talking about the Content-Format numbers for them. > Would rt=3D"ace.est" be the parameter you are talking about? >=20 > Ciao > Hannes >=20 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: 15 May 2018 11:45 > To: Hannes Tschofenig > Cc: ace@ietf.org; core > Subject: Re: [Ace] Early media-type registration for EST over CoAP >=20 >> On May 15, 2018, at 10:56, Hannes Tschofenig w= rote: >>=20 >> I am curious whether it would be possible to ask for early media-type reg= istration of at least these two types: >> - application/pkcs7-mime >> - application/pkcs10 >=20 > There already are registered. >=20 > I think you are talking about getting Content-Format numbers for these? > Do we need any parameters or content-codings with that? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are confi= dential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you. >=20 >=20 --Apple-Mail-EA3C581A-0CEB-415E-8ED0-9D97B4CAF75E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I was thinking about media type parameters s= uch as charset=3D"utf-8". The RT value need to be registered separately, but= we can be a bit lazy about that. 

Sent from mobile
On 16. May 2018, at 12:15, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi Carsten,

Yes, I am talking about the Content-Format numbers for them.
<= span>Would rt=3D"ace.est" be the parameter you are talking about?
=
Ciao
Hannes
-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org]
Sent:= 15 May 2018 11:45
To: Hannes Tschofenig
Cc:= ace@ietf.org; core
Subj= ect: Re: [Ace] Early media-type registration for EST over CoAP

On May 15, 2018, at 10:56, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrot= e:

I am curious whether it would be possible to ask fo= r early media-type registration of at least these two types:
- application/pkcs7-mime
<= /blockquote>
- application/pkcs10
<= /blockquote>
There already are registered.
<= span>
I think you are talking about getting Content-Format n= umbers for these?
Do we need any parameters or content-codin= gs with that?

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

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

<= span>
= --Apple-Mail-EA3C581A-0CEB-415E-8ED0-9D97B4CAF75E-- From nobody Wed May 16 03:29:50 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87CB12D7F6; Wed, 16 May 2018 03:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 FdxH7qdrOmsv; Wed, 16 May 2018 03:29:47 -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 D364A12D7EA; Wed, 16 May 2018 03:29:46 -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 w4GATfRY008452; Wed, 16 May 2018 12:29:41 +0200 (CEST) Received: from [100.75.214.40] (ip-109-41-67-168.web.vodafone.de [109.41.67.168]) (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 40m9fX6yxpzDXlG; Wed, 16 May 2018 12:29:40 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-7EA8625C-9773-4351-9ECF-487B4CEF489D Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (15E302) In-Reply-To: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> Date: Wed, 16 May 2018 12:29:40 +0200 Cc: "ace@ietf.org" , core Content-Transfer-Encoding: 7bit Message-Id: <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> To: Hannes Tschofenig Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP 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, 16 May 2018 10:29:49 -0000 --Apple-Mail-7EA8625C-9773-4351-9ECF-487B4CEF489D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Forgot to add another example: the content-format numbers for COSE have para= meters.=20 Sent from mobile > On 16. May 2018, at 12:26, Carsten Bormann wrote: >=20 > I was thinking about media type parameters such as charset=3D"utf-8". The R= T value need to be registered separately, but we can be a bit lazy about tha= t.=20 >=20 > Sent from mobile >=20 >> On 16. May 2018, at 12:15, Hannes Tschofenig w= rote: >>=20 >> Hi Carsten, >>=20 >> Yes, I am talking about the Content-Format numbers for them. >> Would rt=3D"ace.est" be the parameter you are talking about? >>=20 >> Ciao >> Hannes >>=20 >> -----Original Message----- >> From: Carsten Bormann [mailto:cabo@tzi.org] >> Sent: 15 May 2018 11:45 >> To: Hannes Tschofenig >> Cc: ace@ietf.org; core >> Subject: Re: [Ace] Early media-type registration for EST over CoAP >>=20 >>> On May 15, 2018, at 10:56, Hannes Tschofenig = wrote: >>>=20 >>> I am curious whether it would be possible to ask for early media-type re= gistration of at least these two types: >>> - application/pkcs7-mime >>> - application/pkcs10 >>=20 >> There already are registered. >>=20 >> I think you are talking about getting Content-Format numbers for these? >> Do we need any parameters or content-codings with that? >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any o= ther person, use it for any purpose, or store or copy the information in any= medium. Thank you. >>=20 >>=20 --Apple-Mail-7EA8625C-9773-4351-9ECF-487B4CEF489D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Forgot to add another example: the content-= format numbers for COSE have parameters. 

Sent from mobile
=

On 16. May 2018, at 12:26, Carsten Bormann <cabo@tzi.org> wrote:

I was thinking about media type parameters such as charset=3D"utf-8". T= he RT value need to be registered separately, but we can be a bit lazy about= that. 

Sent from mobile

On 16. May 2018, at 12:15= , Hannes Tschofenig <Hannes.= Tschofenig@arm.com> wrote:

Hi Carsten,

Yes, I am talking about= the Content-Format numbers for them.
Would rt=3D"ace.est" b= e the parameter you are talking about?

Ciao=
Hannes

-----Original Messa= ge-----
From: Carsten Bormann [mailto:cabo@tzi.org]
Sent: 15 May 2018 11:45To: Hannes Tschofenig
Cc: ace@ietf.org; core
Subject: Re: [Ace] Early media-= type registration for EST over CoAP

On May 1= 5, 2018, at 10:56, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

I a= m curious whether it would be possible to ask for early media-type registrat= ion of at least these two types:
- application/pkcs7-mime
- application/pkcs10
There already are registered.

I thin= k you are talking about getting Content-Format numbers for these?
= Do we need any parameters or content-codings with that?

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

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


= --Apple-Mail-7EA8625C-9773-4351-9ECF-487B4CEF489D-- From nobody Fri May 18 04:29:49 2018 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 3B8F212D7ED; Fri, 18 May 2018 04:29:47 -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.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152664298719.1407.1522355400942797447@ietfa.amsl.com> Date: Fri, 18 May 2018 04:29:47 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-16.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: Fri, 18 May 2018 11:29: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 : Sensor Measurement Lists (SenML) Authors : Cullen Jennings Zach Shelby Jari Arkko Ari Keranen Carsten Bormann Filename : draft-ietf-core-senml-16.txt Pages : 52 Date : 2018-05-18 Abstract: This specification defines a format 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 one of these media types 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-16 https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 18 04:40:14 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B28D12D82F; Fri, 18 May 2018 04:40: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 0x1_uO1_xQBP; Fri, 18 May 2018 04:40:03 -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 5EA89129C6D; Fri, 18 May 2018 04:40:03 -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 w4IBds0c016460; Fri, 18 May 2018 13:39:54 +0200 (CEST) Received: from [192.168.217.114] (p5DC7F793.dip0.t-ipconnect.de [93.199.247.147]) (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 40nR6d5DTWzDWjX; Fri, 18 May 2018 13:39:53 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Fri, 18 May 2018 13:39:52 +0200 Cc: Alexey Melnikov , core , =?utf-8?Q?Ari_Ker=C3=A4nen?= , The IESG , "core-chairs@ietf.org" , "draft-ietf-core-senml@ietf.org" , Cullen Jennings X-Mao-Original-Outgoing-Id: 548336391.373861-47d4b902222e466c1470f301992513fb Content-Transfer-Encoding: quoted-printable Message-Id: References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> <20180508000154.GY84491@kduck.kaduk.org> <44DB4CCE-62E7-43FF-9E0B-9AF27E14EE87@tzi.org> <0C881DE7-7991-4E3C-A8C8-B77AEC2F55CC@ericsson.com> <3C64FC4D-B771-4B43-BC19-DE7BD1132173@fastmail.fm> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 18 May 2018 11:40:06 -0000 Hi Benjamin, after WG input about this late change (all positive) has petered out, = https://tools.ietf.org/html/draft-ietf-core-senml-16 is now out with the = boundary between =E2=80=9Cnow=E2=80=9D-relative and absolute moved from = 0 (1970) to 2**28 (1978). Thank you for making us think this through = once more; the result is so much better. The authors believe that -16 should be addressing all DISCUSSes and = COMMENTs. As we are looking at an OMA deadline (an SDO depending on = this) that could be picking up the new version, we could make good use = of swift approval. Gr=C3=BC=C3=9Fe, Carsten > On May 13, 2018, at 20:06, Ari Ker=C3=A4nen = wrote: >=20 >=20 >=20 >> On 13 May 2018, at 0.02, Alexey Melnikov = wrote: >>=20 >> Hi Ari, >>=20 >> On 11 May 2018, at 20:05, Ari Ker=C3=A4nen = wrote: >>=20 >>> Hi all, >>>=20 >>> While addressing the IESG review comments regarding the use of time = in SenML we came up with a simple way to enable SenML Records to express = also relative times in the future that would have minimal impact to any = existing use of SenML. We could use the following definition: >>>=20 >>> Values greater than or equal to 2**28 represent an absolute time = relative to the Unix epoch. Values less than 2**28 represent time = relative to the current time. >>>=20 >>> That is, instead of only values less than zero, also values less = than 2**28 (268,435,456) would be used to express relative time. = Negative values and zero are still times in past and "now" respectively, = as before. Time values from zero to 2**28 would be relative times in the = future. >>>=20 >>> The only change this causes in the current use of SenML is that the = smallest absolute time expressible in SenML becomes 1978-07-04 21:24:16 = UTC instead of 1970-01-01 00:00 UTC. The absolute times after 1978 are = still exactly the same ("Seconds after Unix epoch"). We are not aware of = any deployments with SenML data between 1970 and 1978 that would be = impacted negatively by this.=20 >>>=20 >>> For details, see: >>> https://github.com/core-wg/senml-spec/pull/129/files >>>=20 >>> Would anyone have concerns about including this change in SenML = before publication? >>>=20 >>> Since we are already very late in the process and we need to get = SenML published as RFC very soon, we would also need to agree on this = very soon. >>=20 >> No objections from me personally, but please double check with the = WG. >=20 > Great! >=20 > I saw that Christian, Michael, and Klaus from the WG already +1'd = (thanks guys!). If there are no concerns raised, we could submit a new = version with this change included, e.g., at the end of the work week. >=20 >=20 > Cheers, > Ari From nobody Fri May 18 05:22:30 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C7B12D881; Fri, 18 May 2018 05:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 pRLVtEKhCvyR; Fri, 18 May 2018 05:22:26 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 6AAAB12D87B; Fri, 18 May 2018 05:22:25 -0700 (PDT) X-AuditID: 12074423-ba1ff7000000275b-f8-5afec57deda0 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id B9.B4.10075.E75CEFA5; Fri, 18 May 2018 08:22:22 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w4ICMFrR021971; Fri, 18 May 2018 08:22:17 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w4ICM8bq017665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 18 May 2018 08:22:11 -0400 Date: Fri, 18 May 2018 07:22:08 -0500 From: Benjamin Kaduk To: Carsten Bormann , Ben Campbell Cc: Alexey Melnikov , core , Ari =?iso-8859-1?Q?Ker=E4nen?= , The IESG , "core-chairs@ietf.org" , "draft-ietf-core-senml@ietf.org" , Cullen Jennings Message-ID: <20180518122159.GQ2249@kduck.kaduk.org> References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> <20180508000154.GY84491@kduck.kaduk.org> <44DB4CCE-62E7-43FF-9E0B-9AF27E14EE87@tzi.org> <0C881DE7-7991-4E3C-A8C8-B77AEC2F55CC@ericsson.com> <3C64FC4D-B771-4B43-BC19-DE7BD1132173@fastmail.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBKsWRmVeSWpSXmKPExsUixG6nrlt39F+UwcrFBhb73x9isrh27T+b xfzO0+wWR6bcZbXYtvECm8W+t+uZLX6+W8Js8WH9D0aLGX8mMjtwevz6epXNY+epA2weS5b8 ZPK4fP4jo8esnU9YPKYtygxgi+KySUnNySxLLdK3S+DK2LhNpOC8bEV//1S2BsZL4l2MnBwS AiYSl1e2MHYxcnEICSxmkrjf8YARJCEksJFR4sZUb4jEVSaJq3efsoIkWARUJaacXcAOYrMJ qEg0dF9mBrFFBJwkHh8/CDaJWeA6k0T7vaVsXYwcHMICaRILd5eB1PAKGEtMnDeLCWLoBmaJ +b8usEEkBCVOznzCAmIzC6hL/Jl3iRmkl1lAWmL5Pw6IsLxE89bZYLs4BawlDlw7CHaDqICy xN6+Q+wTGAVnIZk0C8mkWQiTZiGZtICRZRWjbEpulW5uYmZOcWqybnFyYl5eapGumV5uZole akrpJkZwBLko72B82ed9iFGAg1GJh9dhyt8oIdbEsuLK3EOMkhxMSqK8dln/ooT4kvJTKjMS izPii0pzUosPMUpwMCuJ8BrNAMrxpiRWVqUW5cOkpDlYlMR5BTd/iBISSE8sSc1OTS1ILYLJ ynBwKEnwdh0BahQsSk1PrUjLzClBSDNxcIIM5wEangRSw1tckJhbnJkOkT/FqCglzlsEkhAA SWSU5sH1ghKcRPb+mleM4kCvCPNGgFTxAJMjXPcroMFMQIMZD/wGGVySiJCSamAU2P6scaPl O+4JcUI7f9T7Kb7avua4j4KtqUGC2NOixX0yORsbXK9c194zN0ag5mf0zNRnx3YY/F45w3Xq xdXTeC+v631zc/7DVYkaIptWJ8/YfiVy5ZMP7Rf7XBX+GSW6Kly/ldyXu6cmrXdTSs2G56uv L1CtK0l7MS/ohEAYj8oGs+aalFI+JZbijERDLeai4kQAXxLrZksDAAA= Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 18 May 2018 12:22:28 -0000 Hi Carsten, Thanks for the updates; the 2**28 threshold does seem like a big improvement (and the natural semantics of "add base time to relative time and then compare against the threshold" seems to make perfect sense in that context). I have changed my position to Abstain, since the non-hierachical and especially (potentially) interleaving of base values is still not something I support, but I recognize that there is consensus to move forward with it. If you do have chance to make additional updates, it might still be worth adding an explicit note that the streaming format only makes sense in the presence of a reliable, in-order transport. Since this requirement really ought to be obvious to anyone who understands what is going on, I will not attempt to make this a blocking comment, though. Adding Ben to the To: field since he also has an outstanding DISCUSS position in the datatracker. -Benjamin On Fri, May 18, 2018 at 01:39:52PM +0200, Carsten Bormann wrote: > Hi Benjamin, > > after WG input about this late change (all positive) has petered out, https://tools.ietf.org/html/draft-ietf-core-senml-16 is now out with the boundary between “nowâ€-relative and absolute moved from 0 (1970) to 2**28 (1978). Thank you for making us think this through once more; the result is so much better. > > The authors believe that -16 should be addressing all DISCUSSes and COMMENTs. As we are looking at an OMA deadline (an SDO depending on this) that could be picking up the new version, we could make good use of swift approval. > > Grüße, Carsten > > > > On May 13, 2018, at 20:06, Ari Keränen wrote: > > > > > > > >> On 13 May 2018, at 0.02, Alexey Melnikov wrote: > >> > >> Hi Ari, > >> > >> On 11 May 2018, at 20:05, Ari Keränen wrote: > >> > >>> Hi all, > >>> > >>> While addressing the IESG review comments regarding the use of time in SenML we came up with a simple way to enable SenML Records to express also relative times in the future that would have minimal impact to any existing use of SenML. We could use the following definition: > >>> > >>> Values greater than or equal to 2**28 represent an absolute time relative to the Unix epoch. Values less than 2**28 represent time relative to the current time. > >>> > >>> That is, instead of only values less than zero, also values less than 2**28 (268,435,456) would be used to express relative time. Negative values and zero are still times in past and "now" respectively, as before. Time values from zero to 2**28 would be relative times in the future. > >>> > >>> The only change this causes in the current use of SenML is that the smallest absolute time expressible in SenML becomes 1978-07-04 21:24:16 UTC instead of 1970-01-01 00:00 UTC. The absolute times after 1978 are still exactly the same ("Seconds after Unix epoch"). We are not aware of any deployments with SenML data between 1970 and 1978 that would be impacted negatively by this. > >>> > >>> For details, see: > >>> https://github.com/core-wg/senml-spec/pull/129/files > >>> > >>> Would anyone have concerns about including this change in SenML before publication? > >>> > >>> Since we are already very late in the process and we need to get SenML published as RFC very soon, we would also need to agree on this very soon. > >> > >> No objections from me personally, but please double check with the WG. > > > > Great! > > > > I saw that Christian, Michael, and Klaus from the WG already +1'd (thanks guys!). If there are no concerns raised, we could submit a new version with this change included, e.g., at the end of the work week. > > > > > > Cheers, > > Ari > From nobody Fri May 18 09:31:40 2018 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 BA40112D7F6; Fri, 18 May 2018 09:31:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-core-senml@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152666109875.1677.6784894818175408551.idtracker@ietfa.amsl.com> Date: Fri, 18 May 2018 09:31:38 -0700 Archived-At: Subject: [core] Ben Campbell's No Objection on draft-ietf-core-senml-16: (with COMMENT) 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: Fri, 18 May 2018 16:31:39 -0000 Ben Campbell has entered the following ballot position for draft-ietf-core-senml-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS by adding the additional text to section 13, and for addressing my other comments. The change to section 13 is sufficient for me to clear the discuss, but I suggest adding a sentence to the following effect to the end of the new paragraph: “Malicious use of SenML to change system state could have severe consequences, potentially including violation of physical security, property damage, and even loss of life." From nobody Fri May 18 09:34:58 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2CF12DA24; Fri, 18 May 2018 09:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 MnbOR4FPdVU8; Fri, 18 May 2018 09:34:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CAEBF12D7F6; Fri, 18 May 2018 09:34:55 -0700 (PDT) Received: from [10.18.10.6] (ip-105-232-239-173.texas.us.northamericancoax.com [173.239.232.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4IGYiKF016903 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 18 May 2018 11:34:51 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host ip-105-232-239-173.texas.us.northamericancoax.com [173.239.232.105] claimed to be [10.18.10.6] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A3A2A4DD-FB6B-4AC9-9D3D-C17A312683E9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 18 May 2018 10:34:50 -0600 In-Reply-To: Cc: core , =?utf-8?Q?Jaime_Jim=C3=A9nez?= , "core-chairs@ietf.org" , The IESG , "draft-ietf-core-senml@ietf.org" To: =?utf-8?Q?Ari_Ker=C3=A4nen?= References: <152385571314.20985.5160681583375127961.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 18 May 2018 16:34:57 -0000 --Apple-Mail=_A3A2A4DD-FB6B-4AC9-9D3D-C17A312683E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ari, please see comments inline. I=E2=80=99ve removed sections that = don=E2=80=99t seem to need further discussion. > On May 7, 2018, at 11:52 AM, Ari Ker=C3=A4nen = wrote: >=20 >> Hopefully this is easy to address: >>=20 >> =C2=A74.7 talks about how SenML can also be used to configure = parameters and >> controlling actuators. That capability has some rather significant = security >> implications, but I failed to find mention of it in the security >> considerations. That needs to be explicitly discussed. >=20 > Now Section 13 mentions actuator use explicitly: >=20 > When SenML is used for configuration or > actuation, it can be used to change the state of systems and also > impact the physical world, e.g., by turning off a heater or opening a > lock. >=20 > The SenML formats alone do not provide any security and instead rely > on the protocol that carries them to provide security. Applications > using SenML need to look at the overall context of how these formats > will be used to decide if the security is adequate. In particular > for sensitive sensor data and actuation use it is important to ensure > that proper security mechanims are used. That is sufficient to clear my discuss. However, I suggest adding something to the following effect to the first = paragraph: =E2=80=9CMalicious use of SenML to change system state could have severe = consequences, potentially including violation of physical security, = property damage, and even loss of life." [=E2=80=A6] --Apple-Mail=_A3A2A4DD-FB6B-4AC9-9D3D-C17A312683E9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlr/AKoACgkQgFZKbJXz 1A0fog//WP3e/TZIgsDeP6y2rVl5Za7i66EmP9uSa5gKR/RII1mivq0JKRpu7kLr WY2pFsaEU4U3Vte2z+Zii3MaZDNDfNg54HmmRRXTPXsCGOurYynJf2/AMgLRPcj/ m8VnekN/ZDTa/0/q74NjEWBjIN5vOX5eqll7oDfWjW9UeXpCDbpEryST0gH8A6pg BcjSW+5KTMi5ur9UkXXDCQrX9PtncHgqLvRbOTa/zcWLPt1+z38uAaOHYwdNzQPU th+/8RNbmO9ZG9N9CUA5sp5i4gP6qaykvzbwU9dRDJw8BlgJfI3KxT4CpviK9xEl mtIiP5rHWhfg+FzIVatUmhX7mcd33mASUf/x8uFpoEhLndsigQZo0SHIL/Kdr7hS 3uZry68kvC2UDsdVr+WJgfOftPKbe6TAMx+ApeFvZvjXD1tuq27+eKqPBuWJBBo6 /Xycy56JtILjGai3M6COhA6hTpkJr27fWZENT8PuzFseVSvJ5O56lCsAGgOf3CaR PJ/No4c7pVYOD8fi12pVIuw/sf2BtjhLsbwiVswEU4hiCZu4Rw2UkMbT4GN4EGcM 8FLRdex21mNqoydkB0Wr9/SB1mpOXu+pWe0gwAaqSoXmfsacK3PvkctF+ndWu77X iSj1ptcZwdgv9qMvjbcnHWORZm16qyVellNd2DojLw37XBVeIT0= =cmHC -----END PGP SIGNATURE----- --Apple-Mail=_A3A2A4DD-FB6B-4AC9-9D3D-C17A312683E9-- From nobody Sat May 19 05:56:14 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E66112EAE6 for ; Sat, 19 May 2018 05:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.331 X-Spam-Level: X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CI5n2sO9L-LO for ; Sat, 19 May 2018 05:56:09 -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 F3B8712EAE4 for ; Sat, 19 May 2018 05:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526734567; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Fi+/gNyMIJmrW/treEbVXi3AQY3MRCopHRiF3qzD6Ss=; b=gibbBt4ViJ06DokToynAjc1Wz85meae6X+nHK/FkbYIabt/XAZpbWsh+WOWAYYT/ 1k9EhtqOCr7GxPld6KBX+QaJKcgUCNqhyO/F8FOKzZ92OJ1Khzzq7qC3eH476zeL Hssi56XESGSa8PVDJDDMENtvyDKTRDynUXOZSK4ecg4=; X-AuditID: c1b4fb3a-1dfff70000006a47-df-5b001ee7d528 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A2.EA.27207.7EE100B5; Sat, 19 May 2018 14:56:07 +0200 (CEST) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSHC003.ericsson.se (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 19 May 2018 14:56:06 +0200 Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 19 May 2018 14:56:06 +0200 Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Sat, 19 May 2018 14:56:05 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Ben Campbell CC: core , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= , "core-chairs@ietf.org" , The IESG , "draft-ietf-core-senml@ietf.org" Thread-Topic: Ben Campbell's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) Thread-Index: AQHT1UHn+Jopg1j5+EC0sj/ycG3/7aQkjFAAgBEz7QCAAVU2gA== Date: Sat, 19 May 2018 12:56:05 +0000 Message-ID: <4462B8BD-346F-49E5-B86F-1E2DDB163392@ericsson.com> References: <152385571314.20985.5160681583375127961.idtracker@ietfa.amsl.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.153] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUyM2K7tO5zOYZogz3LhC3md55mt9i28QKb xb6365ktfr5bwmwx489EZgdWjyVLfjJ5zNr5hCWAKYrLJiU1J7MstUjfLoEr4+GLuSwF54Qr 9u94wNrA2CPcxcjJISFgInG19w17FyMXh5DAEUaJzx8bmSGcLYwSC7ZOZIJwvjFK7Np1nAXC WcYo8auhkw2kn03AVuJJ6z5WEFtEQEniefNWFhCbWeAlo8TdJy4gtrBArMS8E3PYIGriJL4t ncoIYTtJfDk0AcxmEVCVmHC5E2wOr4C9xMR73xghlu1glDh9eDFYMydQ4tmPVnYQm1FATOL7 qTVMEMvEJW49mc8E8ZCAxJI955khbFGJl4//sULYShJ7j10HOo4DqF5TYv0ufYhWa4lTvS+g blaUmNL9kB3iBkGJkzOfgMWFgG67+u8V4wRGyVlIts1CmDQLyaRZSCbNQjJpASPrKkbR4tTi 4tx0IyO91KLM5OLi/Dy9vNSSTYzACD645bfVDsaDzx0PMQpwMCrx8B4WY4gWYk0sK67MPcQo wcGsJMKbafE/Sog3JbGyKrUoP76oNCe1+BCjNAeLkjivU5pFlJBAemJJanZqakFqEUyWiYNT qoFR+e+p9tyJPT9nxexf90Jvi2PIjfzDm97uzbt2v6y8QFQ6Y+45YZ4oo9irsgr12StfiuZf YHgxUTMny1B+e42vnbWcdLNKzarsXc8n+Z4Ufv2FRbRstXRk7vyZxtUzahyubYxXWXvi2bJv mxf/dVfJaomYYKXxpfmO3OZHx1dFtjVNYth9vSNOiaU4I9FQi7moOBEAawR74twCAAA= Archived-At: Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT) 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, 19 May 2018 12:56:12 -0000 SGkgQmVuLA0KDQo+IE9uIDE4IE1heSAyMDE4LCBhdCAxOS4zNCwgQmVuIENhbXBiZWxsIDxiZW5A bm9zdHJ1bS5jb20+IHdyb3RlOg0KPiANCj4gSGkgQXJpLCBwbGVhc2Ugc2VlIGNvbW1lbnRzIGlu bGluZS4gSeKAmXZlIHJlbW92ZWQgc2VjdGlvbnMgdGhhdCBkb27igJl0IHNlZW0gdG8gbmVlZCBm dXJ0aGVyIGRpc2N1c3Npb24uDQo+IA0KPj4gT24gTWF5IDcsIDIwMTgsIGF0IDExOjUyIEFNLCBB cmkgS2Vyw6RuZW4gPGFyaS5rZXJhbmVuQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+PiANCj4gDQo+ IA0KPj4+IEhvcGVmdWxseSB0aGlzIGlzIGVhc3kgdG8gYWRkcmVzczoNCj4+PiANCj4+PiDCpzQu NyAgdGFsa3MgYWJvdXQgaG93IFNlbk1MIGNhbiBhbHNvIGJlIHVzZWQgdG8gY29uZmlndXJlIHBh cmFtZXRlcnMgYW5kDQo+Pj4gY29udHJvbGxpbmcgYWN0dWF0b3JzLiBUaGF0IGNhcGFiaWxpdHkg aGFzIHNvbWUgcmF0aGVyIHNpZ25pZmljYW50IHNlY3VyaXR5DQo+Pj4gaW1wbGljYXRpb25zLCBi dXQgSSBmYWlsZWQgdG8gZmluZCBtZW50aW9uIG9mIGl0IGluIHRoZSBzZWN1cml0eQ0KPj4+IGNv bnNpZGVyYXRpb25zLiBUaGF0IG5lZWRzIHRvIGJlIGV4cGxpY2l0bHkgZGlzY3Vzc2VkLg0KPj4g DQo+PiBOb3cgU2VjdGlvbiAxMyBtZW50aW9ucyBhY3R1YXRvciB1c2UgZXhwbGljaXRseToNCj4+ IA0KPj4gV2hlbiBTZW5NTCBpcyB1c2VkIGZvciBjb25maWd1cmF0aW9uIG9yDQo+PiBhY3R1YXRp b24sIGl0IGNhbiBiZSB1c2VkIHRvIGNoYW5nZSB0aGUgc3RhdGUgb2Ygc3lzdGVtcyBhbmQgYWxz bw0KPj4gaW1wYWN0IHRoZSBwaHlzaWNhbCB3b3JsZCwgZS5nLiwgYnkgdHVybmluZyBvZmYgYSBo ZWF0ZXIgb3Igb3BlbmluZyBhDQo+PiBsb2NrLg0KPj4gDQo+PiBUaGUgU2VuTUwgZm9ybWF0cyBh bG9uZSBkbyBub3QgcHJvdmlkZSBhbnkgc2VjdXJpdHkgYW5kIGluc3RlYWQgcmVseQ0KPj4gb24g dGhlIHByb3RvY29sIHRoYXQgY2FycmllcyB0aGVtIHRvIHByb3ZpZGUgc2VjdXJpdHkuICBBcHBs aWNhdGlvbnMNCj4+IHVzaW5nIFNlbk1MIG5lZWQgdG8gbG9vayBhdCB0aGUgb3ZlcmFsbCBjb250 ZXh0IG9mIGhvdyB0aGVzZSBmb3JtYXRzDQo+PiB3aWxsIGJlIHVzZWQgdG8gZGVjaWRlIGlmIHRo ZSBzZWN1cml0eSBpcyBhZGVxdWF0ZS4gIEluIHBhcnRpY3VsYXINCj4+IGZvciBzZW5zaXRpdmUg c2Vuc29yIGRhdGEgYW5kIGFjdHVhdGlvbiB1c2UgaXQgaXMgaW1wb3J0YW50IHRvIGVuc3VyZQ0K Pj4gdGhhdCBwcm9wZXIgc2VjdXJpdHkgbWVjaGFuaW1zIGFyZSB1c2VkLg0KPiANCj4gVGhhdCBp cyBzdWZmaWNpZW50IHRvIGNsZWFyIG15IGRpc2N1c3MuDQo+IA0KPiBIb3dldmVyLCBJIHN1Z2dl c3QgYWRkaW5nIHNvbWV0aGluZyB0byB0aGUgZm9sbG93aW5nIGVmZmVjdCB0byB0aGUgZmlyc3Qg cGFyYWdyYXBoOg0KPiANCj4g4oCcTWFsaWNpb3VzIHVzZSBvZiBTZW5NTCB0byBjaGFuZ2Ugc3lz dGVtIHN0YXRlIGNvdWxkIGhhdmUgc2V2ZXJlIGNvbnNlcXVlbmNlcywgcG90ZW50aWFsbHkgaW5j bHVkaW5nIHZpb2xhdGlvbiBvZiBwaHlzaWNhbCBzZWN1cml0eSwgcHJvcGVydHkgZGFtYWdlLCBh bmQgZXZlbiBsb3NzIG9mIGxpZmUuIg0KPiANCj4gW+KApl0NCg0KR3JlYXQhIEFuZCB0aGlzIGFk ZGl0aW9uIHNvdW5kcyBnb29kIHRvIG1lLiBBbGV4ZXkgbWVudGlvbmVkIHRoYXQgd2UgY291bGQg aW5jbHVkZSB0aGlzIGFzIFJGQyBlZGl0b3Igbm90ZS4gU291bmRlZCBsaWtlIGEgZ29vZCB3YXkg dG8gZW5zdXJlIHdlIGNhbiBtb3ZlIGZvcndhcmQgZWZmaWNpZW50bHkuDQoNCg0KVGhhbmtzLA0K QXJpDQoNCg== From nobody Mon May 21 08:36:55 2018 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 7E8DF12778E; Mon, 21 May 2018 08:36:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-senml@ietf.org, Jaime Jimenez , core@ietf.org, alexey.melnikov@isode.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <152691699851.23053.15613197691181104423.idtracker@ietfa.amsl.com> Date: Mon, 21 May 2018 08:36:38 -0700 Archived-At: Subject: [core] Protocol Action: 'Sensor Measurement Lists (SenML)' to Proposed Standard (draft-ietf-core-senml-16.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, 21 May 2018 15:36:39 -0000 The IESG has approved the following document: - 'Sensor Measurement Lists (SenML)' (draft-ietf-core-senml-16.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ Technical Summary 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. Working Group Summary The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. The document was not controversial. Document Quality There are several existing implementations of the formats described in this document. Personnel Document Shepherd: Jaime Jiménez, Area Director: Alexey Melnikov, RFC Editor Note Please add the following sentence to the end of 1st paragraph of Section 13: Malicious use of SenML to change system state could have severe consequences, potentially including violation of physical security, property damage, and even loss of life. From nobody Mon May 21 13:54:52 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E9F12D88A for ; Mon, 21 May 2018 13:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2S01AcxrU6o for ; Mon, 21 May 2018 13:54:41 -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 3307212D881 for ; Mon, 21 May 2018 13:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526936078; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aJXTv/vKR6uwosxZOyx7i+L61NllRjXdPYAynAKXfAs=; b=LzFhpnOiZvCNsCAXDl/sA4gY0Bl+DX+0CcrydtjM+tTYVNB0S6BQSuTWsim2HeRI 5zHiEkhIDRrcyzAztBww3LZkt2mEeKQc2P/er4VnXfLzWDCo3c/09ZEtcH+u/9bk QRupLGMls+iZRN+lzZyJDB7xBv249qqdO1Um9+xBrCk=; X-AuditID: c1b4fb3a-5a4b59c000006a47-63-5b03320e9ee1 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 53.6B.27207.E02330B5; Mon, 21 May 2018 22:54:38 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.29]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0382.000; Mon, 21 May 2018 22:54:01 +0200 From: Christer Holmberg To: Christer Holmberg , "gen-art@ietf.org" CC: "ietf@ietf.org" , "core@ietf.org" , "draft-ietf-core-cocoa.all@ietf.org" Thread-Topic: [Gen-art] Genart telechat review of draft-ietf-core-cocoa-03 Thread-Index: AQHTvUYHbQwfnCNzf0G5o0Mn9GNFSaQ7ELuA Date: Mon, 21 May 2018 20:54:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72EFC502@ESESSMB109.ericsson.se> References: <152121865400.14492.10787438326929665934@ietfa.amsl.com> In-Reply-To: <152121865400.14492.10787438326929665934@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.165] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7qC6fEXO0wcF2U4t9b9czW8x89ZbV 4uqrzywWzzbOZ3Fg8Viy5CdTAGMUl01Kak5mWWqRvl0CV8bRq+cZC27pVrxvm8XcwHhEp4uR k0NCwETi2OlTLF2MXBxCAkcYJb63XmOHcBYzSqzf3sHUxcjBwSZgIdH9TxukQUQgXmLW4bXM IDazwERGiSffwkFsYQFPieuv+pggarwkHmzdCGUbSfRd7AWrZxFQlWib8IkFxOYV8JV4MeM/ mC0k4CLx5cUMFpBVnAKuElPPx4GEGQXEJL6fWsMEsUpc4taT+UwQNwtILNlznhnCFpV4+fgf K4StJDHr1kawi5kFNCXW79KHaFWUmNL9kB1iq6DEyZlPWCYwis5CMnUWQscsJB2zkHQsYGRZ xShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYKwe3/LbawXjwueMhRgEORiUe3kgD5mgh1sSy 4srcQ4wSHMxKIryfLjFFC/GmJFZWpRblxxeV5qQWH2KU5mBREud1SrOIEhJITyxJzU5NLUgt gskycXBKNTCWingY/Fjzt8BaZF1NcBOTDGfttNrNG9/fZT+dmHJA+2eLbKn773QrIavCh/Fr I/aHTiyeXOi+ZgXri6DQplyJ/5Ldypanbly8MuuwxetfylK6huvuf73GVlbF+/O/3xp7W6Nd 80zulC978cBvBvOz5W/bu3IEi9m/27ws6TjlsH3LorRGDwYlluKMREMt5qLiRAAY8BFskQIA AA== Archived-At: Subject: Re: [core] [Gen-art] Genart telechat review of draft-ietf-core-cocoa-03 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, 21 May 2018 20:54:44 -0000 SGksDQoNCkkgZGlkIHRoZSBnZW4tYXJ0IHJldmlldyBvZiB0aGlzIGRvY3VtZW50IG1vcmUgdGhh biAyIG1vbnRocyBhZ28sIGJ1dCBJIGhhdmVuJ3Qgc2VlbiBhbnkgcmVwbHkgZnJvbSB0aGUgYXV0 aG9ycy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEdlbi1hcnQgW21haWx0bzpnZW4tYXJ0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2VudDogMTYgTWFyY2ggMjAxOCAxODo0NA0KVG86 IGdlbi1hcnRAaWV0Zi5vcmcNCkNjOiBpZXRmQGlldGYub3JnOyBjb3JlQGlldGYub3JnOyBkcmFm dC1pZXRmLWNvcmUtY29jb2EuYWxsQGlldGYub3JnDQpTdWJqZWN0OiBbR2VuLWFydF0gR2VuYXJ0 IHRlbGVjaGF0IHJldmlldyBvZiBkcmFmdC1pZXRmLWNvcmUtY29jb2EtMDMNCg0KUmV2aWV3ZXI6 IENocmlzdGVyIEhvbG1iZXJnDQpSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0KDQpJ IGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2Vu ZXJhbCBBcmVhIFJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50 cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRGIENoYWlyLiBQbGVhc2Ug d2FpdCBmb3IgZGlyZWN0aW9uIGZyb20geW91ciBkb2N1bWVudCBzaGVwaGVyZCBvciBBRCBiZWZv cmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCg0KRm9yIG1vcmUgaW5mb3Jt YXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdA0KDQo8aHR0cHM6Ly90cmFjLmlldGYub3JnL3Ry YWMvZ2VuL3dpa2kvR2VuQXJ0ZmFxPi4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtY29yZS1jb2Nv YS0wMw0KUmV2aWV3ZXI6IENocmlzdGVyIEhvbG1iZXJnDQpSZXZpZXcgRGF0ZTogMjAxOC0wMy0x Ng0KSUVURiBMQyBFbmQgRGF0ZTogTm9uZQ0KSUVTRyBUZWxlY2hhdCBkYXRlOiAyMDE4LTA0LTA1 DQoNClN1bW1hcnk6DQoNCj5Gcm9tIGEgdGVjaG5pY2FsIHBlcnNwZWN0aXZlIEkgZG9u4oCZdCBo YXZlIGFueSBpc3N1ZXMuIEhvd2V2ZXIsIEkgdGhpbmsgDQo+dGhlDQpkb2N1bWVudCBjb3VsZCB1 c2UgcXVpdGUgYSBiaXQgb2YgZWRpdG9yaWFsIGltcHJvdmVtZW50cy4gVGhlcmUgaXMgbG90cyBv ZiBpbmNvbnNpc3RlbnQgdGVybWlub2xvZ3ksIOKAnHNwZWVjaC10by10ZXh04oCdIGV0Yy4gSSB3 aWxsIGZvY3VzIG9uIHBhcnRzIHRoYXQgSSB0aGluayBhcmUgdW5jbGVhci4NCg0KTWFqb3IgaXNz dWVzOiBOL0ENCg0KTWlub3IgaXNzdWVzOiBOL0ENCg0KTml0cy9lZGl0b3JpYWwgY29tbWVudHM6 DQoNCi0tLQ0KDQpHZW5lcmFsOg0KDQpUaGUgZG9jdW1lbnQgdXNlcyBsb3RzIG9mIGRpZmZlcmVu dCwgYW5kIG9mdGVuIGNvbXBsaWNhdGVkLCB0ZXJtaW5vbG9neSBmb3IgcmVmZXJlbmNpbmcgUkZD IDcyNTIuDQoNCkV4YW1wbGU6DQoNCuKAnEluIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBDb0FQIHBy b3RvY29sIFtSRkM3MjUyXSzigKbigJ0NCg0K4oCcVGhlIENvUkUgQ29BUCBzcGVjaWZpY2F0aW9u IGRlZmluZXPigKbigJ0NCg0KRXRjIGV0Yy4NCg0KUGxlYXNlIHVzZSBjb25zaXN0ZW50IHRlcm1p bm9sb2d5LiBJIHN1Z2dlc3QgdG8gc2ltcGx5IHNheSDigJxDb0FQIFtSRkM3MjUyXeKAnSBvciDi gJxbUkZDNzI1Ml3igJ0uDQoNCi0tLQ0KDQpHZW5lcmFsOg0KDQpJbiBzb21lIHBsYWNlcyB0aGUg dGV4dCBzYXlzOg0KDQrigJxUaGUgcHJlc2VudCBzcGVjaWZpY2F0aW9u4oCm4oCdDQoNCkkgc3Vn Z2VzdCB0byBzYXk6DQoNCuKAnFRoaXMgc3BlY2lmaWNhdGlvbuKApuKAnQ0KDQotLS0NCg0KR2Vu ZXJhbDoNCg0KVGhlIGRyYWZ0IHVzZXMg4oCcQ29BUCBlbmRwb2ludOKAnSBhbmQg4oCcZW5kcG9p bnTigJ0gdGVybWlub2xvZ3kuIFBsZWFzZSB1c2UgY29uc2lzdGVudCB0ZXJtaW5vbG9neS4NCg0K LS0tDQoNCkdlbmVyYWw6DQoNClRoZSBkcmFmdCB1c2VzIOKAnFJUTyBlc3RpbWF0b3LigJ0gYW5k IOKAnGVzdGltYXRvcuKAnSB0ZXJtaW5vbG9neS4gUGxlYXNlIHVzZSBjb25zaXN0ZW50IHRlcm1p bm9sb2d5Lg0KDQpBbHNvLCB3aGF0IGlzIGFuIOKAnFJUTyBlc3RpbWF0b3LigJ0/DQoNCi0tLQ0K DQpHZW5lcmFsOg0KDQpTb21lIG9mIHRoZSBzZWN0aW9ucyBhcmUgbmFtZWQg4oCcRGlzY3Vzc2lv buKAnS4gSG93ZXZlciwgdGhleSBzdGlsbCBjb250YWluIG5vcm1hdGl2ZSBwcm9jZWR1cmVzLCBh bmQgZXZlbiBSRkMyMTE5IHRlcm1pbm9sb2d5IChNVVNULCBTSE9VTEQgZXRjKS4gQmVjYXVzZSBv ZiB0aGF0LCBJIHRoaW5rIGl0IGlzIG1vcmUgdGhhbiBhIGRpc2N1c3Npb24uIEEgZGlzY3Vzc2lv biBpcyB0eXBpY2FsbHkgdXNlZCB0byBqdXN0aWZ5IHNvbWV0aGluZywgb3IgdG8gZ2l2ZSBzb21l IGJhY2tncm91bmQsIG5vdCB0byBkZWZpbmUgcHJvY2VkdXJlcy4NCg0KLS0tDQoNClRoZSBBYnN0 cmFjdCBhbmQgdGhlIEludHJvZHVjdGlvbiBzYXk6DQoNCiAgIOKAnENvQVAsIHRoZSBDb25zdHJh aW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCwgbmVlZHMgdG8gYmUgaW1wbGVtZW50ZWQNCiAgIGlu IHN1Y2ggYSB3YXkgdGhhdCBpdCBkb2VzIG5vdCBjYXVzZSBwZXJzaXN0ZW50IGNvbmdlc3Rpb24g b24gdGhlDQogICBuZXR3b3JrIGl0IHVzZXMu4oCdDQoNCldoYXQgZXhhY3RseSBkb2VzIHRoaXMg bWVhbj8gSW1wbGVtZW50ZWQgaW4gd2hhdCB3YXk/DQoNCi0tLQ0KDQpUaGUgdGV4dCBpbiBTZWN0 aW9uIDIgc2F5czoNCg0KICAg4oCcVGhlIHByZXNlbnQgc3BlY2lmaWNhdGlvbiBpcyBiYXNlZCBv biB0aGUgYXBwcm92ZWQgdGV4dCBpbiB0aGUgW1JGQzcyNTJdDQogICBiYXNlIHNwZWNpZmljYXRp b24u4oCdDQoNCkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSDigJxhcHByb3ZlZOKAnSBwYXJ0LiBT aW5jZSBSRkMgNzI1MiBoYXMgYmVlbiBwdWJsaXNoZWQsIEkgYXNzdW1lIHRoZSB0ZXh0IGlzIGFw cHJvdmVkIDopDQoNCi0tLQ0KDQpUaGUgdGV4dCBpbiBTZWN0aW9uIDMgcmVmZXJzIHRvIOKAnFJl c3BvbmRlcuKAnS4gSG93ZXZlciwgaXQgaXMgbm90IGRlZmluZWQvcmVmZXJlbmNlZCBhbnl3aGVy ZS4NCg0KLS0tDQoNClRoZSB0ZXh0IGluIFNlY3Rpb24gNC4zIHNheXM6DQoNCuKAnFRoZSBzdGF0 ZSBvZiB0aGUgUlRPIGVzdGltYXRvcnMgZm9yIGFuIGVuZHBvaW50IFNIT1VMRCBiZSBrZXB0IGFz IGxvbmcgYXMgcG9zc2libGUu4oCdDQoNCkxhdGVyIHRoZSB0ZXh0IHNheXMgdGhhdCB0aGUgUlRP IHN0YXRlIGRlcGVuZHMgb24gd2hldGhlciB0aGVyZSBpcyBvdGhlciBzdGF0ZSAoRFRMUyBldGMp IG9yIG5vdD8gQ2FuIHRoZSBzZW50ZW5jZSBhYm92ZSBiZSByZW1vdmVkPw0KDQotLS0NCg0KVGhl IHRleHQgaW4gU2VjdGlvbiA0LjMgc2F5cyDigJx2ZXJ5IHN0cm9uZ2x5IFJFQ09NTUVOREVE4oCd IGFuZCDigJxzdHJvbmdseSBSRUNPTU1FTkRFROKAnS4gVGhhdCBzb3VuZHMgbGlrZSBhIOKAnFNI T1VMROKAnSBpbiBteSBlYXJzIDopDQoNCi0tLQ0KDQpUaGUgdGV4dCBpbiBTZWN0aW9uIDQuMyB0 YWxrcyBhYm91dCDigJxTdGF0ZSBvZiBSVE8gZXN0aW1hdG9y4oCdIGFuZCDigJxSVE8gc3RhdGXi gJ0uDQpBcmUgdGhlc2UgZGlmZmVyZW50IHN0YXRlcz8NCg0KLS0tDQoNClRoZSB0ZXh0IGluIFNl Y3Rpb24gNSB0YWxrcyBhYm91dCDigJxub24tY29uZmlybWFibGVz4oCdLiBQbGVhc2UgaW5jbHVk ZSBhIHJlZmVyZW5jZSBvciBkZWZpbml0aW9uLg0KDQotLS0NCg0KVGhlIHRleHQgaW4gU2VjdGlv biA3IHNheXM6DQoNCiAgIOKAnFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiwgZS5nLiwg W1JGQzU2ODFdLCBbUkZDMjkxNF0sIGFuZA0KICAgW1JGQzgwODVdIGFwcGx5LiAgU29tZSBpc3N1 ZXMgYXJlIGFscmVhZHkgZGlzY3Vzc2VkIGluIHRoZSBzZWN1cml0eQ0KICAgY29uc2lkZXJhdGlv bnMgb2YgW1JGQzcyNTJdLuKAnQ0KDQpJIGRvbuKAmXQgdGhpbmsgeW91IGNhbiBzYXkg4oCcZS5n LizigJ0gYW5kIOKAnFNvbWUgaXNzdWVz4oCdLiBJdCBuZWVkcyB0byBiZSBjbGVhciB3aGljaCBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhcHBseS4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KR2VuLWFydCBtYWlsaW5nIGxpc3QNCkdlbi1hcnRA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VuLWFydA0K From nobody Wed May 23 05:44:05 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A991126DED for ; Wed, 23 May 2018 05:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 HjcxI0mk2ZE2 for ; Wed, 23 May 2018 05:44:01 -0700 (PDT) Received: from lb1-smtp-cloud9.xs4all.net (lb1-smtp-cloud9.xs4all.net [194.109.24.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4CB31200C5 for ; Wed, 23 May 2018 05:44:00 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:206]) by smtp-cloud9.xs4all.net with ESMTPA id LT7UfikQ0RSWtLT7UfJdPY; Wed, 23 May 2018 14:43:59 +0200 Received: from AMontpellier-654-1-155-119.w90-0.abo.wanadoo.fr ([90.0.250.119]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 23 May 2018 14:43:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 23 May 2018 14:43:56 +0200 From: peter van der Stok To: "Kovatsch, Matthias" Cc: consultancy@vanderstok.org, Hannes Tschofenig , core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01F48F8A@DEFTHW99EL4MSX.ww902.siemens.net> References: <9970c70fea6ea457c74c8ae3ca303f76@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C01F48F8A@DEFTHW99EL4MSX.ww902.siemens.net> Message-ID: <02f2fd175b28e391fbded750d4b4dae5@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfIXzAqHc9sGgN7TehVpDo+X7TJ0aMPRBeVHCYUR7+SfWAz/FUK0i5zoXPhCuqPW4aCZkIzvPf82cvn4gEvUyAvllGaqOf/Qy55vmBqkanM6xg11vnjaQ pHNzmZlSBPB5Btl8hfT4GPQlXiqh3dGvfQaTc031HX19vEdK3dsMqTdFRqiK8ZLBldquAZ8VS1Pgot7HEA302az5TnorRY9yQSWEYrGwVbXCxx9oICD6q9qk F82MCaQZaUPySTqpRCJSZccwNXOo89QZ9Um+tirF+Dk= Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 23 May 2018 12:44:04 -0000 Hi Hannes and Matthias, thanks for this e-mail and the later one by Hannes explaining the question below. I have no problem with the proposed ep value handling as security identifier as explained in Hannes e-mail. However, it will be useful that optionally in the token another ep-value and d-value are transported. The larger token is acceptable in many cases where the installation management requires identifiers that correspond with the naming of the components of the installation. Peter Kovatsch, Matthias schreef op 2018-05-15 09:28: >> Von: core [mailto:core-bounces@ietf.org] Im Auftrag von peter van der >> Stok > >> I probably misunderstand the meaning of optional. >> What I understand from making ep optional, is that ep is not returned >> in the lookup interface unless explicitly requested Differentiation >> between registrations (endpoints) cannot be done by ep >> (,d) value, but should be done differently (how?). > > To my understanding, the proposal is the following: > > A registration can be done without the "ep" query parameter, iff the > Endpoint Client Name can be derived in another way from the > registration message. This way should (or I guess Hannes would say > MUST) be the security context. In that sense, "ep" as registration > query parameter becomes optional, but "ep" remains a central, > mandatory attribute in the RD for each registered resource (used for > endpoint lookup, filtering etc.). > > > Thanks Ludwig for your pointer how this could work. > > @Hannes: Could you provide some more detail, how exactly the Endpoint > Client Name is extracted from "security context"? Overall, I like > this, but we should provide concrete text on how people should do it. > > Best, > Matthias From nobody Wed May 23 05:57:14 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F4A126FB3 for ; Wed, 23 May 2018 05:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 zGRX-t2QIImv for ; Wed, 23 May 2018 05:57:11 -0700 (PDT) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 A49011200C5 for ; Wed, 23 May 2018 05:57:10 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:206]) by smtp-cloud9.xs4all.net with ESMTPA id LTKGfiqpaRSWtLTKGfJhCs; Wed, 23 May 2018 14:57:08 +0200 Received: from AMontpellier-654-1-155-119.w90-0.abo.wanadoo.fr ([90.0.250.119]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 23 May 2018 14:57:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 23 May 2018 14:57:08 +0200 From: peter van der Stok To: Hannes Tschofenig Cc: consultancy@vanderstok.org, "Kovatsch, Matthias" , Mohit Sethi , core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <4EBB3DDD0FBF694CA2A87838DF129B3C01F36340@DEFTHW99EL4MSX.ww902.siemens.net> <6d8a9b8a6c67f7f7022ace8bd9c8d374@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfOcYzLk1s7Kx+eTlmq7PM7mOHBPPVj+FvK/GYCPf2/lvSLIY+FBlk/AD1h5F0jycD8tuhKik/U9Egxh2tgVYHnXQ/st3lW3yY/+A7D9YUqHK2X4czUhb vCjcrHWjQ7jcCJbFYmmRPyhvvyy9SD6W6/PFBo/BviLU3lUo90qLCeTMxe7r5ThgzQa6dyZN9CiIfkZUEC7euXAHPust1zquGVVLxi8uJmwKz+1yZuRfghXZ UhMi2GpZWDFfkdLjsvcikLO2iFE4TkcXPcgzGZO7xrYTn7JOT1/WngepwOwFblCA Archived-At: Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft 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, 23 May 2018 12:57:13 -0000 Hi Hannes, I have had some feedback on the 3rd party registration and the use of con= parameter. Third party registration is a "must" for building installation and people are counting on it. It is especially (but not limited to) registering very small devices and sleeping devices. There is an experimental installation in which 3rd party registration has been tried out with very positive results supporting the installation process quite naturally. The experiment only concerns the functional aspects (that you challenged). It is clear that the security aspects need to be considered in more detail. However, it is generally considered that both the RD and the commissioning tool (3rd party) will not be (very) constrained. Some overhead for the larger tokens is certainly allowed. I hope that we can conclude the discussion on the presence of 3rd party registration for the RD; and continue the security discussion. Peter Hannes Tschofenig schreef op 2018-05-09 10:20: > Hi Peter, > > I have not even looked at the con parameter but I wonder how well it > can work in practice given firewalls and NATs... > > Ciao > Hannes > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: 09 May 2018 09:03 > To: Hannes Tschofenig > Cc: consultancy@vanderstok.org; Kovatsch, Matthias; Mohit Sethi; > core@ietf.org > Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name > in RD draft > > Hi Hannes, > > I share your concerns, But there are some additional aspects. > for 3rd party registration the con= is used. > con= will also be used to indicate alternative transports. Suppressing > con= seems really a waste in this stage. > On the other hand, even suppressing con= for third parties, the anchor > attribute also permits to refer to third parties. Removing the anchor > attribute is cumbersome to say the least. > > Possibly @others want to react. > > For the moment using con= for 3rd party registration creates one > registration at the time. > The Authorization server can also in this case assign endpoint values > and prevent ep value stealing. > > I will try to get some concrete feedback on 3rd party registration. I > will keep you informed. > > Peter > > Hannes Tschofenig schreef op 2018-05-08 13:20: >> Peter, >> >> I would personally feel more comfortable if we standardize >> functionality that some people have gained some experience already. If >> we don't involve the domain experts then we will most likely get it >> wrong. >> >> What about separating this functionality from the RD draft, reach out >> to these companies, and then put the result of the investigations into >> a separate document? There are some folks in the group who work >> closely with indoor commercial lighting companies and they could for >> sure help. >> >> Ciao >> Hannes >> >> >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: 08 May 2018 08:22 >> To: Kovatsch, Matthias >> Cc: Hannes Tschofenig; Mohit Sethi; core@ietf.org >> Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name >> in RD draft >> >> Kovatsch, Matthias schreef op 2018-05-07 18:09: >>> Dear Hannes, >>> >>> dear list >>> >>> To my knowledge, third-party provisioning functionality is in >>> particular used for lighting systems; maybe Peter can comment on >>> this. >> >> On request, some background. >> For buildings, the installation is done by installation companies with >> their own tools and procedures. >> Installation can be done in phases by different companies. >> Their is at this moment not one general approach or installation >> protocol. >> >> The problem is that the architect and people around have produced >> drawings with cabling and equipment situated at precise physical >> locations in the drawing. >> Equipment, cabling etc are identified with numbers ,names, what have >> you. >> There are descriptions which discuss the functionality and the >> relation between the equipment. >> All this knowledge has to be transferred to the equipment without >> making too many "one of a kind" pieces. >> In he "olde times" much was solved by the cabling, that limited the >> control possibilities. >> These IP times, anything can reach anything else. >> One approach is to store parts of this information into the RD, which >> can be queried by the equipment. >> >> I hope this make the wish for an RD with third party access >> understandable. >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose >> the contents to any other person, use it for any purpose, or store or >> copy the information in any medium. Thank you. > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. From nobody Thu May 24 07:16:10 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A6812426E; Thu, 24 May 2018 07:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 pnlBiLjJx7dK; Thu, 24 May 2018 07:15:59 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0077.outbound.protection.outlook.com [104.47.2.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B051200C5; Thu, 24 May 2018 07:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rqWVpeRVvWIuhUTImDZClMQ+iYCquxvfYbJU/YnCfAQ=; b=gMBh1bQXdNcu3dlnMP+uwmfemlZBB9V6zySwW21nQCJUE5kDJHSywsEaUIns+poaLJb/lMdlqYDUHAwzyvvMHeJuOnLpPvacJoT5S+PageaANyAPkRJodGWKHjtMDOzSSl6SdccJI1iQGI7TM/Yh0kXehzXK+RY2zU89utGws7Q= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1310.eurprd08.prod.outlook.com (10.167.197.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.776.11; Thu, 24 May 2018 14:15:54 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::8a:25f5:af5d:4db4]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::8a:25f5:af5d:4db4%17]) with mapi id 15.20.0776.015; Thu, 24 May 2018 14:15:54 +0000 From: Hannes Tschofenig To: Carsten Bormann CC: "ace@ietf.org" , core Thread-Topic: [Ace] Early media-type registration for EST over CoAP Thread-Index: AdPsKhcQ9FbwjekBT1SYYUyoYtG38gAB1S+AAAdDwHAALHlyAAAAGtIAAZoVoYA= Date: Thu, 24 May 2018 14:15:54 +0000 Message-ID: References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> In-Reply-To: <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [195.149.218.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1310; 7:h9NkQNMpfjPDsC3o24SFUl82E3piT7LozTQNJYBQFzTPTuz1ItbpCo375z4/R0aPahcelrIbPaMzlfeumD8YRXjqSTXzhFAfq2jVFXBEUT+HqX64lkh2FaEnF3w7JLaoSnT88b/Z3CZ/Z4LwS7NTz94eJ/q7wxIsXdciAzSjhNV1LKwva/kSPi3E9en/FiMwxm4IOtzp3Zwis8a32RHiqiRb+8vKpBk9/YHy6XAsWLZ4278kkmW/UgJ5h4gh7tVG x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1310; x-ms-traffictypediagnostic: VI1PR0801MB1310: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1310; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1310; x-forefront-prvs: 0682FC00E8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(39380400002)(346002)(376002)(13464003)(40434004)(199004)(57704003)(189003)(53754006)(5890100001)(3280700002)(99286004)(6116002)(105586002)(53936002)(8936002)(72206003)(76176011)(33656002)(6506007)(53546011)(7736002)(3660700001)(7696005)(59450400001)(2906002)(316002)(8676002)(81156014)(14454004)(229853002)(93886005)(54906003)(25786009)(55016002)(97736004)(236005)(5660300001)(106356001)(790700001)(3846002)(6306002)(6436002)(81166006)(54896002)(9686003)(446003)(486006)(66066001)(476003)(11346002)(86362001)(478600001)(6246003)(6916009)(4326008)(102836004)(2900100001)(5250100002)(68736007)(186003)(26005)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1310; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:3; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: tOvngmOWvhy+IQ31aTh5uSso1tosEttGEs0xycsPbxtTfiMwmpdQQEB1S4RwyONcKLaXg+74pLhTDqWVTck8eTyfSXb8ioD+bK9bj0BkwX1sqSpP5uWH4cPJyw1kiVxq4jWqYwQA2AWGsgMF3LleU+yXe6BGfonInxuo1Jg3pt3VVWvGJAYEilxHfM6Nfv7w spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21122EB265DF70E45C26BC80FA6A0VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 4d533754-66c2-4d1a-35bf-08d5c180dc8d X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4d533754-66c2-4d1a-35bf-08d5c180dc8d X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2018 14:15:54.1759 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1310 Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP 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, 24 May 2018 14:16:02 -0000 --_000_VI1PR0801MB21122EB265DF70E45C26BC80FA6A0VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUcnlpbmcgdG8gZmluYWxpemUgdGhpcyBkaXNjdXNzaW9uOiBDb3VsZCB3ZSBk byBhbiBlYXJseSByZWdpc3RyeSBvZiB0aGUgQ29udGVudC1Gb3JtYXQgbnVtYmVycz8NCg0KRnJv bSB0aGUgZGlzY3Vzc2lvbiBzbyBmYXIgSSBiZWxpZXZlIHdlIGNvbmNsdWRlZCB0aGF0IHRoZSBj aGFyc2V0IGlzIHV0Zi04IGFuZCB0aGF0IHRoZXJlIGFyZSBubyBwYXJhbWV0ZXJzLiBJcyB0aGF0 IGNvcnJlY3Q/DQoNCkNpYW8NCkhhbm5lcw0KDQpGcm9tOiBDYXJzdGVuIEJvcm1hbm4gW21haWx0 bzpjYWJvQHR6aS5vcmddDQpTZW50OiAxNiBNYXkgMjAxOCAxMjozMA0KVG86IEhhbm5lcyBUc2No b2ZlbmlnDQpDYzogYWNlQGlldGYub3JnOyBjb3JlDQpTdWJqZWN0OiBSZTogW0FjZV0gRWFybHkg bWVkaWEtdHlwZSByZWdpc3RyYXRpb24gZm9yIEVTVCBvdmVyIENvQVANCg0KRm9yZ290IHRvIGFk ZCBhbm90aGVyIGV4YW1wbGU6IHRoZSBjb250ZW50LWZvcm1hdCBudW1iZXJzIGZvciBDT1NFIGhh dmUgcGFyYW1ldGVycy4NClNlbnQgZnJvbSBtb2JpbGUNCg0KT24gMTYuIE1heSAyMDE4LCBhdCAx MjoyNiwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc8bWFpbHRvOmNhYm9AdHppLm9yZz4+ IHdyb3RlOg0KSSB3YXMgdGhpbmtpbmcgYWJvdXQgbWVkaWEgdHlwZSBwYXJhbWV0ZXJzIHN1Y2gg YXMgY2hhcnNldD0idXRmLTgiLiBUaGUgUlQgdmFsdWUgbmVlZCB0byBiZSByZWdpc3RlcmVkIHNl cGFyYXRlbHksIGJ1dCB3ZSBjYW4gYmUgYSBiaXQgbGF6eSBhYm91dCB0aGF0Lg0KU2VudCBmcm9t IG1vYmlsZQ0KDQpPbiAxNi4gTWF5IDIwMTgsIGF0IDEyOjE1LCBIYW5uZXMgVHNjaG9mZW5pZyA8 SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTxtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNv bT4+IHdyb3RlOg0KSGkgQ2Fyc3RlbiwNCg0KWWVzLCBJIGFtIHRhbGtpbmcgYWJvdXQgdGhlIENv bnRlbnQtRm9ybWF0IG51bWJlcnMgZm9yIHRoZW0uDQpXb3VsZCBydD0iYWNlLmVzdCIgYmUgdGhl IHBhcmFtZXRlciB5b3UgYXJlIHRhbGtpbmcgYWJvdXQ/DQoNCkNpYW8NCkhhbm5lcw0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIFttYWlsdG86Y2Fi b0B0emkub3JnXQ0KU2VudDogMTUgTWF5IDIwMTggMTE6NDUNClRvOiBIYW5uZXMgVHNjaG9mZW5p Zw0KQ2M6IGFjZUBpZXRmLm9yZzxtYWlsdG86YWNlQGlldGYub3JnPjsgY29yZQ0KU3ViamVjdDog UmU6IFtBY2VdIEVhcmx5IG1lZGlhLXR5cGUgcmVnaXN0cmF0aW9uIGZvciBFU1Qgb3ZlciBDb0FQ DQoNCk9uIE1heSAxNSwgMjAxOCwgYXQgMTA6NTYsIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMu VHNjaG9mZW5pZ0Bhcm0uY29tPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj4gd3Jv dGU6DQoNCg0KSSBhbSBjdXJpb3VzIHdoZXRoZXIgaXQgd291bGQgYmUgcG9zc2libGUgdG8gYXNr IGZvciBlYXJseSBtZWRpYS10eXBlIHJlZ2lzdHJhdGlvbiBvZiBhdCBsZWFzdCB0aGVzZSB0d28g dHlwZXM6DQotIGFwcGxpY2F0aW9uL3BrY3M3LW1pbWUNCi0gYXBwbGljYXRpb24vcGtjczEwDQoN ClRoZXJlIGFscmVhZHkgYXJlIHJlZ2lzdGVyZWQuDQoNCkkgdGhpbmsgeW91IGFyZSB0YWxraW5n IGFib3V0IGdldHRpbmcgQ29udGVudC1Gb3JtYXQgbnVtYmVycyBmb3IgdGhlc2U/DQpEbyB3ZSBu ZWVkIGFueSBwYXJhbWV0ZXJzIG9yIGNvbnRlbnQtY29kaW5ncyB3aXRoIHRoYXQ/DQoNCkdyw7zD n2UsIENhcnN0ZW4NCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBw cml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29u dGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3Rv cmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KDQpJ TVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3Ro ZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBp bmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_VI1PR0801MB21122EB265DF70E45C26BC80FA6A0VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgYWxs LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UcnlpbmcgdG8gZmluYWxpemUgdGhpcyBkaXNjdXNzaW9uOiBDb3VsZCB3 ZSBkbyBhbiBlYXJseSByZWdpc3RyeSBvZiB0aGUgQ29udGVudC1Gb3JtYXQgbnVtYmVycz88L3Nw YW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Gcm9tIHRoZSBkaXNjdXNzaW9uIHNvIGZhciBJIGJlbGlldmUgd2UgY29uY2x1ZGVkIHRoYXQg dGhlIGNoYXJzZXQgaXMgdXRmLTggYW5kIHRoYXQgdGhlcmUgYXJlIG5vIHBhcmFtZXRlcnMuIElz IHRoYXQgY29ycmVjdD8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2lhbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IYW5uZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNhYm9AdHppLm9yZ10NCjxicj4NCjxiPlNlbnQ6PC9i PiAxNiBNYXkgMjAxOCAxMjozMDxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWc8YnI+ DQo8Yj5DYzo8L2I+IGFjZUBpZXRmLm9yZzsgY29yZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0FjZV0gRWFybHkgbWVkaWEtdHlwZSByZWdpc3RyYXRpb24gZm9yIEVTVCBvdmVyIENvQVA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPkZvcmdvdCB0byBhZGQgYW5vdGhlciBleGFtcGxlOiB0aGUgY29udGVu dC1mb3JtYXQgbnVtYmVycyBmb3IgQ09TRSBoYXZlIHBhcmFtZXRlcnMuJm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U2VudCBmcm9tJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQiPm1vYmlsZTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gMTYuIE1heSAyMDE4LCBhdCAx MjoyNiwgQ2Fyc3RlbiBCb3JtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIj5j YWJvQHR6aS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIHdh cyB0aGlua2luZyBhYm91dCBtZWRpYSB0eXBlIHBhcmFtZXRlcnMgc3VjaCBhcyBjaGFyc2V0PSZx dW90O3V0Zi04JnF1b3Q7LiBUaGUgUlQgdmFsdWUgbmVlZCB0byBiZSByZWdpc3RlcmVkIHNlcGFy YXRlbHksIGJ1dCB3ZSBjYW4gYmUgYSBiaXQgbGF6eSBhYm91dCB0aGF0LiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNlbnQgZnJvbSZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMHB0Ij5tb2JpbGU8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDE2LiBNYXkgMjAxOCwgYXQg MTI6MTUsIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86SGFubmVzLlRzY2hv ZmVuaWdAYXJtLmNvbSI+SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBD YXJzdGVuLDxicj4NCjxicj4NClllcywgSSBhbSB0YWxraW5nIGFib3V0IHRoZSBDb250ZW50LUZv cm1hdCBudW1iZXJzIGZvciB0aGVtLjxicj4NCldvdWxkIHJ0PSZxdW90O2FjZS5lc3QmcXVvdDsg YmUgdGhlIHBhcmFtZXRlciB5b3UgYXJlIHRhbGtpbmcgYWJvdXQ/PGJyPg0KPGJyPg0KQ2lhbzxi cj4NCkhhbm5lczxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJv bTogQ2Fyc3RlbiBCb3JtYW5uIFs8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIj5tYWlsdG86 Y2Fib0B0emkub3JnPC9hPl08YnI+DQpTZW50OiAxNSBNYXkgMjAxOCAxMTo0NTxicj4NClRvOiBI YW5uZXMgVHNjaG9mZW5pZzxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86YWNlQGlldGYub3JnIj5h Y2VAaWV0Zi5vcmc8L2E+OyBjb3JlPGJyPg0KU3ViamVjdDogUmU6IFtBY2VdIEVhcmx5IG1lZGlh LXR5cGUgcmVnaXN0cmF0aW9uIGZvciBFU1Qgb3ZlciBDb0FQPGJyPg0KPGJyPg0KT24gTWF5IDE1 LCAyMDE4LCBhdCAxMDo1NiwgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpI YW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tIj5IYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPC9hPiZn dDsgd3JvdGU6PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBjdXJp b3VzIHdoZXRoZXIgaXQgd291bGQgYmUgcG9zc2libGUgdG8gYXNrIGZvciBlYXJseSBtZWRpYS10 eXBlIHJlZ2lzdHJhdGlvbiBvZiBhdCBsZWFzdCB0aGVzZSB0d28gdHlwZXM6PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gYXBwbGljYXRpb24v cGtjczctbWltZTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tIGFwcGxpY2F0aW9uL3BrY3MxMDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpUaGVyZSBhbHJlYWR5IGFyZSByZWdpc3RlcmVkLjxicj4NCjxicj4NCkkgdGhpbmsgeW91IGFy ZSB0YWxraW5nIGFib3V0IGdldHRpbmcgQ29udGVudC1Gb3JtYXQgbnVtYmVycyBmb3IgdGhlc2U/ PGJyPg0KRG8gd2UgbmVlZCBhbnkgcGFyYW1ldGVycyBvciBjb250ZW50LWNvZGluZ3Mgd2l0aCB0 aGF0Pzxicj4NCjxicj4NCkdyw7zDn2UsIENhcnN0ZW48YnI+DQo8YnI+DQpJTVBPUlRBTlQgTk9U SUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBj b25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9u IGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCklNUE9S VEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBw ZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5m b3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1PR0801MB21122EB265DF70E45C26BC80FA6A0VI1PR0801MB2112_-- From nobody Thu May 24 07:37:42 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC1B12DA6C; Thu, 24 May 2018 07:37:33 -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 7HwBIKzEN6p4; Thu, 24 May 2018 07:37:30 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) (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 7ACD81271DF; Thu, 24 May 2018 07:37:30 -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 w4OEbLnZ005770; Thu, 24 May 2018 16:37:21 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (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 40sBmc5zryzDXpR; Thu, 24 May 2018 16:37:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Thu, 24 May 2018 16:37:20 +0200 Cc: core , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 548865438.434765-cebc0a28696fff98fb27641412505c1d Content-Transfer-Encoding: quoted-printable Message-Id: <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP 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, 24 May 2018 14:37:34 -0000 On May 24, 2018, at 16:15, Hannes Tschofenig = wrote: >=20 > Hi all, > =20 > Trying to finalize this discussion: Could we do an early registry of = the Content-Format numbers? Yes. =20 > =46rom the discussion so far I believe we concluded that the charset = is utf-8 What charset? I thought we don=E2=80=99t have parameters (see below). > and that there are no parameters. Is that correct? That is my understanding so far, but the point of me asking the question = was to ask the actual experts about these media types. Did we get that = input? Next step: make a proposal and raise this on core-parameters@ietf.org so = we get the needed input from the designated expert. Gr=C3=BC=C3=9Fe, Carsten > =20 > Ciao > Hannes > =20 > From: Carsten Bormann [mailto:cabo@tzi.org]=20 > Sent: 16 May 2018 12:30 > To: Hannes Tschofenig > Cc: ace@ietf.org; core > Subject: Re: [Ace] Early media-type registration for EST over CoAP > =20 > Forgot to add another example: the content-format numbers for COSE = have parameters.=20 >=20 > Sent from mobile >=20 > On 16. May 2018, at 12:26, Carsten Bormann wrote: >=20 > I was thinking about media type parameters such as charset=3D"utf-8". = The RT value need to be registered separately, but we can be a bit lazy = about that.=20 >=20 > Sent from mobile >=20 > On 16. May 2018, at 12:15, Hannes Tschofenig = wrote: >=20 > Hi Carsten, >=20 > Yes, I am talking about the Content-Format numbers for them. > Would rt=3D"ace.est" be the parameter you are talking about? >=20 > Ciao > Hannes >=20 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: 15 May 2018 11:45 > To: Hannes Tschofenig > Cc: ace@ietf.org; core > Subject: Re: [Ace] Early media-type registration for EST over CoAP >=20 > On May 15, 2018, at 10:56, Hannes Tschofenig = wrote: >=20 > =20 > I am curious whether it would be possible to ask for early media-type = registration of at least these two types: > - application/pkcs7-mime > - application/pkcs10 >=20 > There already are registered. >=20 > I think you are talking about getting Content-Format numbers for = these? > Do we need any parameters or content-codings with that? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. >=20 >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. = _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Thu May 24 07:54:50 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F0712708C; Thu, 24 May 2018 07:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 D_xd_CquMNn5; Thu, 24 May 2018 07:54:38 -0700 (PDT) Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) (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 6D0D5126D0C; Thu, 24 May 2018 07:54:38 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:207]) by smtp-cloud7.xs4all.net with ESMTPA id LrdSfBu7i8U07LrdSf2ZXM; Thu, 24 May 2018 16:54:36 +0200 Received: from AMontpellier-654-1-155-119.w90-0.abo.wanadoo.fr ([90.0.250.119]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 24 May 2018 16:54:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 24 May 2018 16:54:34 +0200 From: peter van der Stok To: Carsten Bormann Cc: Hannes Tschofenig , core , ace@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfPxeiFleP9FcGeOV2GvOGaiJ0Dnpp+XnVsFYir8uD27DmaZlzpHp+Ky4Mq0jwL4EflwGpv/6GsSYWR9glXJmYb8NyfaRM7blO98ro0cFa26DJ1NLJ49p gMrfbB3VcSAvVA2s9hkGlsF3AHxuM3iIaiWvN6RqmlppTScJRMR5GAheuLua8OlOlX2UUky5z2qnxHIKMRbA90J/IajMsBvfG3S8doGzPJPup3OcriZpQJvr rLsIcPc6IcnMKE3oSaSzmQ914eW0IMXI7ma+9Pjawho= Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP 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, 24 May 2018 14:54:42 -0000 Ok, I will raise the experts to-morrow. Peter Carsten Bormann schreef op 2018-05-24 16:37: > On May 24, 2018, at 16:15, Hannes Tschofenig > wrote: >> >> Hi all, >> >> Trying to finalize this discussion: Could we do an early registry of >> the Content-Format numbers? > > Yes. > >> From the discussion so far I believe we concluded that the charset is >> utf-8 > > What charset? I thought we don’t have parameters (see below). > >> and that there are no parameters. Is that correct? > > That is my understanding so far, but the point of me asking the > question was to ask the actual experts about these media types. Did > we get that input? > > Next step: make a proposal and raise this on core-parameters@ietf.org > so we get the needed input from the designated expert. > > Grüße, Carsten > > >> >> Ciao >> Hannes >> >> From: Carsten Bormann [mailto:cabo@tzi.org] >> Sent: 16 May 2018 12:30 >> To: Hannes Tschofenig >> Cc: ace@ietf.org; core >> Subject: Re: [Ace] Early media-type registration for EST over CoAP >> >> Forgot to add another example: the content-format numbers for COSE >> have parameters. >> >> Sent from mobile >> >> On 16. May 2018, at 12:26, Carsten Bormann wrote: >> >> I was thinking about media type parameters such as charset="utf-8". >> The RT value need to be registered separately, but we can be a bit >> lazy about that. >> >> Sent from mobile >> >> On 16. May 2018, at 12:15, Hannes Tschofenig >> wrote: >> >> Hi Carsten, >> >> Yes, I am talking about the Content-Format numbers for them. >> Would rt="ace.est" be the parameter you are talking about? >> >> Ciao >> Hannes >> >> -----Original Message----- >> From: Carsten Bormann [mailto:cabo@tzi.org] >> Sent: 15 May 2018 11:45 >> To: Hannes Tschofenig >> Cc: ace@ietf.org; core >> Subject: Re: [Ace] Early media-type registration for EST over CoAP >> >> On May 15, 2018, at 10:56, Hannes Tschofenig >> wrote: >> >> >> I am curious whether it would be possible to ask for early media-type >> registration of at least these two types: >> - application/pkcs7-mime >> - application/pkcs10 >> >> There already are registered. >> >> I think you are talking about getting Content-Format numbers for >> these? >> Do we need any parameters or content-codings with that? >> >> Grüße, Carsten >> >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose >> the contents to any other person, use it for any purpose, or store or >> copy the information in any medium. Thank you. >> >> >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose >> the contents to any other person, use it for any purpose, or store or >> copy the information in any medium. Thank you. >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri May 25 03:23:32 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9E0126C0F; Fri, 25 May 2018 03:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 I6tDRGekSEPz; Fri, 25 May 2018 03:23:23 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17418124D68; Fri, 25 May 2018 03:23:23 -0700 (PDT) Received: from mail-qk0-f181.google.com ([209.85.220.181]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1fM9sX-0000mm-7o; Fri, 25 May 2018 12:23:21 +0200 Received: by mail-qk0-f181.google.com with SMTP id c23-v6so3649493qkb.5; Fri, 25 May 2018 03:23:21 -0700 (PDT) X-Gm-Message-State: ALKqPwdNHNyRhFT42UVuESt9fn+vYUO+4vtu0bgA+ouyuo5wfDtpwDzQ we6xt30nlw2v1hshkKeEtamjTP6LpqHVyq3WWH8= X-Google-Smtp-Source: ADUXVKJZpaawXEYFxfiwu+k2NWLaCXkf/Q2ncWvkBOM10I1sOpu5BlLj5o83w7/N9wbKcVyMv0v6WL0LCCw9Drzohd4= X-Received: by 2002:a37:5fc4:: with SMTP id t187-v6mr1453209qkb.62.1527243800241; Fri, 25 May 2018 03:23:20 -0700 (PDT) MIME-Version: 1.0 References: <0158C0A6-C8D5-4F19-9C12-23BDC8A7768A@tzi.org> <8976A481-6467-4DAD-A5ED-9AE05E9CC62D@tzi.org> <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> In-Reply-To: <7952F818-15C7-4151-8A98-936A6250F5FB@tzi.org> From: Klaus Hartke Date: Fri, 25 May 2018 12:23:09 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Cc: Hannes Tschofenig , "ace@ietf.org" , core Content-Type: multipart/alternative; boundary="00000000000032ee06056d05284c" X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1527243803; 5b1babf7; X-HE-SMSGID: 1fM9sX-0000mm-7o Archived-At: Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP 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, 25 May 2018 10:23:25 -0000 --00000000000032ee06056d05284c Content-Type: text/plain; charset="UTF-8" Carsten Bormann wrote: > Next step: make a proposal and raise this on core-parameters@ietf.org so we get the needed input from the designated expert. Done. https://www.ietf.org/mail-archive/web/core-parameters/current/msg00024.html Klaus --00000000000032ee06056d05284c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Carsten Bormann wrote:
> N= ext step: make a proposal and raise this on core-parameters@ietf.org so we get the n= eeded input from the designated expert.

--00000000000032ee06056d05284c-- From nobody Tue May 29 02:02:46 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCD1127863; Tue, 29 May 2018 02:02:38 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 9zgvEjHmPYvf; Tue, 29 May 2018 02:02:35 -0700 (PDT) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.2.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4294412711E; Tue, 29 May 2018 02:02:35 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id BEE1080342; Tue, 29 May 2018 11:02:33 +0200 (CEST) Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id JlTEsWDNZdra; Tue, 29 May 2018 11:02:33 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 491D7820AA; Tue, 29 May 2018 11:02:33 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr 491D7820AA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1527584553; bh=7IPzhsYgPHxe6OGvBnR/lDnnCR3ZAjZw/jEYGEDYFno=; h=MIME-Version:From:Date:Message-ID:To; b=Js8WiT0ztkKLypty9xragGtvVwd+s96ficO9R4nA5UJjs/hViE/yZSnFDQc8uJjN5 xOlEKM9zKFpjgl8gkpcDmybxJmF1x8zfd8oKxOULv2IHjb8eOoOsalYhn4iKTM01pW /c+ePnr1P1ECVCO2gfSMfKvwGQRKPEyDaHNBBpHc= X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id 3u88QvgI-A0g; Tue, 29 May 2018 11:02:33 +0200 (CEST) Received: from mail-it0-f43.google.com (mail-it0-f43.google.com [209.85.214.43]) by zproxy110.enst.fr (Postfix) with ESMTPSA id E5E48820C8; Tue, 29 May 2018 11:02:32 +0200 (CEST) Received: by mail-it0-f43.google.com with SMTP id 76-v6so2309477itx.4; Tue, 29 May 2018 02:02:32 -0700 (PDT) X-Gm-Message-State: ALKqPweg/YGjaTCSND33UfzVjVQrp1JzmRUm1q0dtXYV2MEsrFgUNTSi p7dVpjv0m/Lo4Ma5D9aTp3sRBXHNiMwR0w7YS8w= X-Google-Smtp-Source: ADUXVKKP1ByXEGJIorePghrRJVl+h4Qf8fmsePBaDTUDOVopnBKr64ZEkjtbMnaVtHNGM1uDeACl2O3xIjMrbuPIjzU= X-Received: by 2002:a24:cfc4:: with SMTP id y187-v6mr14378231itf.26.1527584551480; Tue, 29 May 2018 02:02:31 -0700 (PDT) MIME-Version: 1.0 From: Laurent Toutain Date: Tue, 29 May 2018 11:01:54 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "core@ietf.org WG" Cc: lp-wan , Ana Minaburo Content-Type: multipart/alternative; boundary="0000000000008e35f4056d547e47" Archived-At: Subject: [core] Time Scale Option 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, 29 May 2018 09:02:38 -0000 --0000000000008e35f4056d547e47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, We have published few month ago a draft defining a new CoAP option. https://datatracker.ietf.org/doc/draft-toutain-core-time-scale/ The main idea is to inform a server when devices will not have the same reaction time. Current CoAP RFC defines a default 5 minutes window during which any message will be consider as a retransmission. This delay is too small for LPWAN network, where small bandwidth, duty cycles are introducing larger delays. One solution is to change the default window value, but this period will be too long for =E2=80=9Cregular=E2=80=9D devices and force the= server to memorize more message ID. That=E2=80=99s why we propose the Time Scale option, the client informs the= server of the window period where messages will be considered as retransmitted. The server will be informed for this device and will adapt its timers. We would like to know, as we discussed during London IETF, what is the position of the core wg on this option. Ana and Laurent --0000000000008e35f4056d547e47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

=C2=A0

We have published few month ago a draft defining a new CoAP option.


https://datatracker.ietf.org/doc/draft-toutain-core-time-= scale/


T= he main idea is to inform a server when devices will not have the same reaction time. Current CoAP RFC defines a default 5 minutes window during which any message will be consider as a retransmissio= n. =C2=A0This delay is too small for LPWAN network, where small bandwidth, duty cycles are introducing larger delays. One solut= ion is to change the default window value, but this period will be too long for= =E2=80=9Cregular=E2=80=9D devices and force the server to memorize more message ID.

=C2=A0

That=E2=80=99s why we propose the Time Scale option, the client informs the server of the window period where messages w= ill be considered as retransmitted. The server will be informed for this device= and will adapt its timers.

=C2=A0

We would like to know, as we discussed during London IETF, what is the position of the core wg on this option.

=C2=A0

Ana and Laurent=


--0000000000008e35f4056d547e47-- From nobody Tue May 29 02:37:55 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3711126BF0; Tue, 29 May 2018 02:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 p_3ghea-GECj; Tue, 29 May 2018 02:37:46 -0700 (PDT) Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A35412025C; Tue, 29 May 2018 02:37:44 -0700 (PDT) Received: from mail-qk0-f178.google.com ([209.85.220.178]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1fNb4X-0006qd-1u; Tue, 29 May 2018 11:37:41 +0200 Received: by mail-qk0-f178.google.com with SMTP id z75-v6so10932329qkb.6; Tue, 29 May 2018 02:37:41 -0700 (PDT) X-Gm-Message-State: ALKqPwe7+v6MTJP27rhFDs5ucz3OyHt+TmkOq7V99+6mD2e/lmEeGMqW kg3ph+l2qmh7/2ZPgqPCbEezWx9mtvumYlyfUPk= X-Google-Smtp-Source: ADUXVKJs7hqJ9hfL4V9X5fMMKDZPLZ2DOk9qpckXfqv0M9v1ag4MpCjhyqkO+nBeITMzQRPoJT8MlrmV9amCUY0NSwI= X-Received: by 2002:a37:be42:: with SMTP id o63-v6mr14302670qkf.102.1527586659888; Tue, 29 May 2018 02:37:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:c352:0:0:0:0:0 with HTTP; Tue, 29 May 2018 02:36:59 -0700 (PDT) In-Reply-To: References: From: Klaus Hartke Date: Tue, 29 May 2018 11:36:59 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Laurent Toutain Cc: "core@ietf.org WG" , lp-wan , Ana Minaburo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1527586665; bc536641; X-HE-SMSGID: 1fNb4X-0006qd-1u Archived-At: Subject: Re: [core] Time Scale Option 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, 29 May 2018 09:37:48 -0000 Wouldn't ACK_TIMEOUT, MAX_LATENCY, etc. need to be adjusted, since EXCHANGE_LIFETIME is just a calculated value? Klaus On 29 May 2018 at 11:01, Laurent Toutain wrote: > Hi, > > > > We have published few month ago a draft defining a new CoAP option. > > > https://datatracker.ietf.org/doc/draft-toutain-core-time-scale/ > > > The main idea is to inform a server when devices will not have the same > reaction time. Current CoAP RFC defines a default 5 minutes window during > which any message will be consider as a retransmission. This delay is to= o > small for LPWAN network, where small bandwidth, duty cycles are introduci= ng > larger delays. One solution is to change the default window value, but th= is > period will be too long for =E2=80=9Cregular=E2=80=9D devices and force t= he server to > memorize more message ID. > > > > That=E2=80=99s why we propose the Time Scale option, the client informs t= he server > of the window period where messages will be considered as retransmitted. = The > server will be informed for this device and will adapt its timers. > > > > We would like to know, as we discussed during London IETF, what is the > position of the core wg on this option. > > > > Ana and Laurent > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Tue May 29 03:09:13 2018 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F05612E8E2; Tue, 29 May 2018 03:09: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 iib7pqTt9BBB; Tue, 29 May 2018 03:09:10 -0700 (PDT) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.2.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4028012E8CE; Tue, 29 May 2018 03:09:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 10E128151B; Tue, 29 May 2018 12:09:09 +0200 (CEST) Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id S35Qn0O3v1jH; Tue, 29 May 2018 12:09:08 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 03EA281F06; Tue, 29 May 2018 12:09:08 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr 03EA281F06 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1527588548; bh=eRddiiinUB75sSnsDdP2wfZWqHNV+ADT+OOjanEX2Xo=; h=MIME-Version:From:Date:Message-ID:To; b=lNkooHYqMVsqAjfX9XyprzxRzklRjh6IkyY6ibbVSgwcE1mqzzhRDCc+59jKMcuxA vjYvQdq1OnJRdfOLCorV88Uaprx46BEpewB4t7T5rNmAZc4+QfsJfDn6zRggZUzljq MejF5Z3KV4+Zux2hsXlhDHs3w8+rRGLoGoV6wnZ4= X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id wyISD45oCeVk; Tue, 29 May 2018 12:09:07 +0200 (CEST) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) by zproxy110.enst.fr (Postfix) with ESMTPSA id A1A548151B; Tue, 29 May 2018 12:09:07 +0200 (CEST) Received: by mail-io0-f175.google.com with SMTP id d73-v6so16920437iog.3; Tue, 29 May 2018 03:09:07 -0700 (PDT) X-Gm-Message-State: ALKqPwcDQ9UCXY2TcLu1frkdGSyuA19SKuzf2qnlNlKHvFrshRHybvqB w4PsLsBZ3tkZSXPu4s4nTJzpFHftviqvSk99B/M= X-Google-Smtp-Source: ADUXVKKXnAREXPwEx0Uon40duIdWRitGpdAnbXyMv7AhFTPjLvr1M4qyjyk25D+Pc7SUb+3268i0mAvb0i+SwHAs3oM= X-Received: by 2002:a6b:3a45:: with SMTP id h66-v6mr4510013ioa.113.1527588546012; Tue, 29 May 2018 03:09:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Laurent Toutain Date: Tue, 29 May 2018 12:08:29 +0200 X-Gmail-Original-Message-ID: Message-ID: To: hartke@projectcool.de Cc: "core@ietf.org WG" , lp-wan , Ana Minaburo Content-Type: multipart/alternative; boundary="000000000000a5ed56056d556c96" Archived-At: Subject: Re: [core] Time Scale Option 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, 29 May 2018 10:09:13 -0000 --000000000000a5ed56056d556c96 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Klaus, Yes, ACK_TIMEOUT and MAX_LATENCY are known from the LPWAN device and the value carried in the option result of this computation. Laurent On Tue, May 29, 2018 at 11:37 AM Klaus Hartke wrote= : > Wouldn't ACK_TIMEOUT, MAX_LATENCY, etc. need to be adjusted, since > EXCHANGE_LIFETIME is just a calculated value? > > Klaus > > > On 29 May 2018 at 11:01, Laurent Toutain > wrote: > > Hi, > > > > > > > > We have published few month ago a draft defining a new CoAP option. > > > > > > https://datatracker.ietf.org/doc/draft-toutain-core-time-scale/ > > > > > > The main idea is to inform a server when devices will not have the same > > reaction time. Current CoAP RFC defines a default 5 minutes window duri= ng > > which any message will be consider as a retransmission. This delay is > too > > small for LPWAN network, where small bandwidth, duty cycles are > introducing > > larger delays. One solution is to change the default window value, but > this > > period will be too long for =E2=80=9Cregular=E2=80=9D devices and force= the server to > > memorize more message ID. > > > > > > > > That=E2=80=99s why we propose the Time Scale option, the client informs= the > server > > of the window period where messages will be considered as retransmitted= . > The > > server will be informed for this device and will adapt its timers. > > > > > > > > We would like to know, as we discussed during London IETF, what is the > > position of the core wg on this option. > > > > > > > > Ana and Laurent > > > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > --000000000000a5ed56056d556c96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Klaus,

Yes, ACK_TIMEOUT a= nd MAX_LATENCY are known from the LPWAN device and the value carried in the= option result of this computation.

Laurent

On Tue, May 29, 20= 18 at 11:37 AM Klaus Hartke <ha= rtke@projectcool.de> wrote:
= Wouldn't ACK_TIMEOUT, MAX_LATENCY, etc. need to be adjusted, since
EXCHANGE_LIFETIME is just a calculated value?

Klaus


On 29 May 2018 at 11:01, Laurent Toutain
<= laurent.toutain@imt-atlantique.fr> wrote:
> Hi,
>
>
>
> We have published few month ago a draft defining a new CoAP option. >
>
> https://datatracker.ietf.org/doc= /draft-toutain-core-time-scale/
>
>
> The main idea is to inform a server when devices will not have the sam= e
> reaction time. Current CoAP RFC defines a default 5 minutes window dur= ing
> which any message will be consider as a retransmission.=C2=A0 This del= ay is too
> small for LPWAN network, where small bandwidth, duty cycles are introd= ucing
> larger delays. One solution is to change the default window value, but= this
> period will be too long for =E2=80=9Cregular=E2=80=9D devices and forc= e the server to
> memorize more message ID.
>
>
>
> That=E2=80=99s why we propose the Time Scale option, the client inform= s the server
> of the window period where messages will be considered as retransmitte= d. The
> server will be informed for this device and will adapt its timers.
>
>
>
> We would like to know, as we discussed during London IETF, what is the=
> position of the core wg on this option.
>
>
>
> Ana and Laurent
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org > https://www.ietf.org/mailman/listinfo/core
>
--000000000000a5ed56056d556c96--