From nobody Wed Jul 1 02:12:48 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4981A8790 for ; Wed, 1 Jul 2015 02:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3] autolearn=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 cqG3G2mMhd_8 for ; Wed, 1 Jul 2015 02:12:45 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5F01A8772 for ; Wed, 1 Jul 2015 02:12:44 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 575A544861; Wed, 1 Jul 2015 11:12:42 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0881E1FB; Wed, 1 Jul 2015 11:12:39 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 855DE36E; Wed, 1 Jul 2015 11:12:38 +0200 (CEST) Received: (nullmailer pid 29732 invoked by uid 1000); Wed, 01 Jul 2015 09:12:37 -0000 Date: Wed, 1 Jul 2015 11:12:37 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "Rahman, Akbar" Message-ID: <20150701091237.GA9702@hephaistos.amsuess.com> References: <36F5869FE31AB24485E5E3222C288E1F22E04456@NABESITE.InterDigital.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F22E04456@NABESITE.InterDigital.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: core WG Subject: Re: [core] CoRE Resource Directory draft updates X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 09:12:47 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 30, 2015 at 08:56:30PM +0000, Rahman, Akbar wrote: > 4. In section 4.1 (Finding a Directory Server): >=20 > =C2=B7 It states, =E2=80=9C=E2=80=A6 directory servers are found = by simply sending POST requests to that well-known multicast address (detai= ls TBD)=E2=80=9D >=20 > =C2=B7 Should it be GET instead of POST? In the context of the section being 4.1, it makes sense (as 4 is about simple discovery, where the client just POSTs to .well-known/core). It might be a good idea to move it ouf of that section (and generalize the method used), as it is used in 5.1 just as well. Best regards Christian Ams=C3=BCss --=20 Christian Ams=C3=BCss | Energy Harvesting Solutions Gm= bH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --AhhlLboLdkugWU4S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVk678AAoJEDmNERLTpL3h4S8QAJjMoPZGLKPNraCOPlpetjGs thQ7QQAXBHkC7k/LWXLjxesiVC6rXaMEiFb7muddbx3GjTHCxyryIPUQQifUmG3j Ypq9Kz4gHUoX1OVsOLky51BduFu2izLDuO5A34st7dvv091AuHH5nOQ+phsmeep4 whPcLS0F/11vn6NZmxmXWncqcQ5jHCt/R3ZDl7eH7wq//DeBhnk+l1xcWKaFfS0o eaKdtQ6F0U+jVZl4VV+6Uk13QDgVXCVs+jIgFdP7a1mOnjiA38dK4ujw9fPA1bWq 8qj6psICLZYgfwFYMHSUNc4pVWVUDOAmgKpcmBQCirzIrEU/xqSAajgGpI8rD/Bi S6e1s3vLMhlE8iI/B05mTBMmDYp08Nd2Ufq3uU4QlMPx5YEyUQjcDFwXGoB5TzGd jHsdPGoSOogYONnNovkmtMKcUNOaVYs3lM9dFZ8rN/in50cZtry40BnMId3+E8Dx JLZhc3FEfRTb/VynBRv/7BkBWnX22kq1RkaRyCzC+F3gt2cVUlTpBPY8DdXeH9Ws vQi/G6S+2VSoXg4iNkPuCG31YJOCoxvF7+uQlvrQJWsbt8ofJS3ZsZI0Hq/nrtQs iiMpqQSdt2igikb02mLtkSTAMXiapraxn7we6zBVQvarRFTHc02sZUWyoIhnizuW AzWHnzafqqhiYDM2hxPW =xbvj -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From nobody Wed Jul 1 02:28:37 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461F81B2BED for ; Wed, 1 Jul 2015 02:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3] autolearn=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 raDTj_D17QBA for ; Wed, 1 Jul 2015 02:28:35 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E798E1B2BF9 for ; Wed, 1 Jul 2015 02:28:34 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id C6A2944861; Wed, 1 Jul 2015 11:28:32 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id C67CF1FB; Wed, 1 Jul 2015 11:28:31 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9BDA736E; Wed, 1 Jul 2015 11:28:31 +0200 (CEST) Received: (nullmailer pid 31828 invoked by uid 1000); Wed, 01 Jul 2015 09:28:30 -0000 Date: Wed, 1 Jul 2015 11:28:30 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Koster Message-ID: <20150701092830.GB9702@hephaistos.amsuess.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2B/JsCI69OhZNC5r" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: core WG Subject: Re: [core] CoRE Resource Directory draft updates X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 09:28:36 -0000 --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 29, 2015 at 02:15:47PM -0700, Michael Koster wrote: > 1. Remove the simple registration described in the beginning of > section 4. Unless there is a strong specific use case, the basic need > can be easily handled using a configuration tool. I'm using simple registration and find it very handy in sensors that are not capable of parsing link-format, but are hidden behind NAT (typically but not exclusively cellular networks) or otherwise dynamic IPs, so a configuration tool is of no help there. Best regards Christian Ams=FCss --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --2B/JsCI69OhZNC5r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVk7KyAAoJEDmNERLTpL3hrUwP/iQ4iWKl7IZtX9ezIO6NineR fD4Vf+4c84lAqAZukZZiuBG5U+n/xRSvcgsibrSl8Wlj506t2OeKpag8i/te9HzG ObRmZTTNHudG+nSS9Ng3yhrftw1jg/l2EBdTiWxxrXdFn4XKwCyp2teu57rkvt89 7uQ3zgStbhJP2lmpfjIro4gwjS/+d+2tZiC+k1CNRsxIKvz9+RAWLwNfrWteXh1I nxY2gje5Z/edPICQSupSDe1YrMenscYwDRdyNB9WyAt4UIKVJYewOAdVyJWeikzB 9YTFa0Kl9RmFyjcv6BLJ4bi/uFPq88zB9DLKhcsuHLF6AybshV8uVAeKwlqC3vxe L35Xr9J472ljW1VQiV71CDjkZWzIjBdZg7Z61D48S7RCqnOC0eRNJmQftCXAOIbP 10zOel+AWDk2jzhUdoelIxOhxblkgd76iUGqK0gwog4fRsAzrdl6wJz8LvOAFTVg n4a/On1fie7GNZ2TEmmsvz7d617djapi28yJ4ngfj3VoGNzYiWUIGB28eMsGHRfJ 58h40+jeA7es543cT26wDmPrEyUbp9bbPGxibcD6RGsXcLb9vT3joVvv5Htpfe6n 3qumlQ1F9OEW8QwAzF/kv6AlrW0qtEeYlhoCP1ILRF0Z0ZSZbGCrUFO2KkB2q+OQ SoXdZ2fPYbakFpvE4kMD =JkDU -----END PGP SIGNATURE----- --2B/JsCI69OhZNC5r-- From nobody Wed Jul 1 03:16:12 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3EC1B2CE8 for ; Wed, 1 Jul 2015 03:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU9R159cxHPX for ; Wed, 1 Jul 2015 03:16:09 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::792]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BAE01A6EF9 for ; Wed, 1 Jul 2015 03:16:08 -0700 (PDT) Received: from DB4PR04CA0013.eurprd04.prod.outlook.com (10.160.41.23) by VI1PR04MB0895.eurprd04.prod.outlook.com (10.161.106.155) with Microsoft SMTP Server (TLS) id 15.1.201.16; Wed, 1 Jul 2015 10:15:52 +0000 Received: from AM1FFO11FD005.protection.gbl (2a01:111:f400:7e00::160) by DB4PR04CA0013.outlook.office365.com (2a01:111:e400:9852::23) with Microsoft SMTP Server (TLS) id 15.1.207.19 via Frontend Transport; Wed, 1 Jul 2015 10:15:52 +0000 Authentication-Results: spf=none (sender IP is 206.191.242.68) smtp.mailfrom=philips.com; tzi.org; dkim=none (message not signed) header.d=none; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from mail.philips.com (206.191.242.68) by AM1FFO11FD005.mail.protection.outlook.com (10.174.64.87) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Wed, 1 Jul 2015 10:15:50 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.119]) by AMSPRD9003HT003.MGDPHG.emi.philips.com ([141.251.33.80]) with mapi id 14.16.0488.000; Wed, 1 Jul 2015 10:15:46 +0000 From: "Dijk, Esko" To: Carsten Bormann , Hannes Tschofenig Thread-Topic: [core] draft-ietf-core-resource-directory-03 Thread-Index: AQHQs0KMz13fRxWjTEiPoJqsnND3pJ3FIAUAgAFGWNA= Date: Wed, 1 Jul 2015 10:15:45 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6186AF6D0BD@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <5592A986.2060608@gmx.net> <5592AB4E.2050009@tzi.org> In-Reply-To: <5592AB4E.2050009@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.109] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD005; 1:1jrYACFAcrSuBsN/YHggd8xndQOEs+q3yPcRS3rcaY7cruT7R3wzuNZTkZVOxCo8BX7Ws+FuvIs2Bd8qyKsR8XS6/XN3R5/nugZ5kIz95xN/6r7/BkoFFrF51mX4Tc0LqQQ1jM4AO3bH74CW+Ia7nCJTrg9g0rBI26idMslDHb30MnQQa1cjouraOhS1gT7dNOhw/8KgZ+uChRDDC2zoi030ediqEYCKuueOiZNex1FXiqgsQvKl7w3UdgGyZ5C+7jSXBgxkBFzeYWtvEnQtSVXvb4TwmNaqB2RYpqCDBHM= X-Forefront-Antispam-Report: CIP:206.191.242.68; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(428002)(85714005)(13464003)(374574003)(199003)(189002)(104016003)(106466001)(19580405001)(102836002)(50986999)(76176999)(19580395003)(5001960100002)(5003600100002)(46102003)(77156002)(101416001)(106116001)(50466002)(54356999)(66066001)(15975445007)(62966003)(230783001)(23676002)(92566002)(2656002)(6806004)(55846006)(33656002)(87936001)(5001770100001)(189998001)(2950100001)(2920100001)(2900100001)(105586002)(47776003)(567094001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR04MB0895; H:mail.philips.com; FPR:; SPF:None; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB0895; 2:GdyHjC7hNsgOGfMtXgP9CvWbA6Sy/4i3aaWvFjD1Cg254flmWduT46HF6G9ad0AJ; 3:g0q63j1GFRlRFHXq/IbooR3RT6ZmJO7ewiO0v1hMblxWsOS3sumlRbMfx8DpSyN1S2ZDvskz+dhY0Jv6F/0Y2XlOqNPsFevtBHwo+S0nlOJvcXae1a4Jie8/D2OFXqxDwPVcueLATmJNo6tBvQh3jVp77xJgwgtyjeK07h5cxKMAFgFbDgVjt8HWF7gg5DxSP0+0bDukP2fLO1ifJXsdeAbYdIXgwhI0XLUqKq8SziRaiIoN7kZTeJ8WiWV+nsxb; 25:q4rtGV+ot2qsDweByPk5VtUjrEypYxSBwsK6YYz0kq3Ac/EBw8dL9jCqz8g+Jkr3XiVJm/P5oXCMhkzOyB5SeJCfHmiwAdig1Cck+nJbaPfUrLmg3ZXjwkEVAHsDsmE12OS4MB/R3nx0sxTpJZrt7NbKhOAbyr8usD3mxeZC+f9gCKOs9zH3NXgaAO1sYKN82aAv1A2Dxu6zvDP2vPYJtA7MgWUDu3Vc3wCdnObELfuSHIelU/bSSQW6jUKMNb/WgesJcK+pg0+DSEB75rOdQA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR04MB0895; X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB0895; 20:wxlXXapCBp3SSFvPVslFujRny4y2qVzSMhVCr/Br2c2T7QItjGkGKnKryVDvB5bFeBh4y7hmxap+bV2ckGtMcvpYdAD6aD6o4jqXutPdM0ZANnkONQWnfYGVFx3msAJNGeslWTWAncP87Benhvm/Dk6l2zgkzEVgIU/9UMIfFJbzoted7g7Pma6l3YEW6QtLFuf066M9x80aZfWdtNyytBVkCSpmFb92xZFjF/6wJnSPfKj2pvCheiBP6Gbqlp8llP6WLT5sIzCkPnQPnzT6jLJgnN9+ZLAh+a2MSJEtRxUIwIuFRpV9xRjsdWE3IxLlsWV/IaO+ORptiSHl9NnsE79vWqQ5saAfzpa6oFXVS+WnwPPEoQXgmCwHhgjHw2pQGFLlWp4kCQak71vtbBjhkH1odSVVaBf/YawV4Xn/lnGsEY3EeDccHyIlxTiZUiIytSe0yS3sJD4OMl3XZg5y3560L27iy7WykTDqjyR7XJ8dZrQQtdJ7qPzaZV1Wi1bL; 4:XX9BGMwal+HltNABhLFZXOKruQLZ/chXYXaCqTdBZhXLKECm308rCWzXEDczAAW+WBOche53aZQloX/RH40ha4awmBtF15ecShSgZwiGv38UIMHmpvZAo6Fd3+Rda8eOlUC8snQ38UTd8IsdCsGQiEmvMT/rbXZ8Y3LmtVhNbVBwD/cB5kFsVxVO1qLceqRquTq9aGq+VeCL8Vm0UXCGmqjnN8s3NNjgHgA45ashxV72WwxSbXm/SC6p5GQyvw8gb2N2TPNNwutJ+8nhLHYe6Rr5s1SzLOgteYfuUWJKu6o= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:VI1PR04MB0895; BCL:0; PCL:0; RULEID:; SRVR:VI1PR04MB0895; X-Forefront-PRVS: 0624A2429E X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA0TUIwODk1OzIzOnVBZmY3ZjhlWHRsVXJmcGFBMjVrNkg5SVBO?= =?utf-8?B?RGZWSnpGemJxdmV0Rm5WVGw1Y05SNmJacUxiaHpDdDZGOHBqN3NnQXRLcFBm?= =?utf-8?B?SXVxSk41bVY5R0owR1NoSkduajF2VndKdGdHdnVmZm1CaEt5bTdheVM2UFM0?= =?utf-8?B?dW4wRHBqVUxoMW9JVFNlaE4wSE8xTk9oeFF2T2RhNTRTK2d1ckY0K2UyMHZ5?= =?utf-8?B?R0MzOGlSQzJjT2tJNHlTNnVYQnNZa045WnloaHlsd3k1WWFHUmxKaUdkbFFK?= =?utf-8?B?aDNRTjhMNndRbWZCaGdYWnd2bGx3N25GNEZqQ3JEUW1hcUN3bDlpTDNRYllZ?= =?utf-8?B?L3ZQNFo3NlA4ZHJyY0JCbW5RYVhwZ2Q2Tzd1NUNOOVkwb2c5ZGo2VHN1ZWpk?= =?utf-8?B?Y05YM1E1WTlMakYyaFl1VUl3TVFxMGhkZC9ZNGtuL2FBMjRDcXg1aTlUbVFo?= =?utf-8?B?RXlnZEZUbTZHbGt2NEdSR21Vb2dtSGY5ODRZV0E4bG5nY2RNdHdQRjlVb2pS?= =?utf-8?B?TWx5aCtNdUZ1VS9Bc1BFK29NcldVM0N4b3ljc0VwK0N2bXI2WXVicnhqdUMx?= =?utf-8?B?K3F6b1U4SVc5d1FGZW04OW9ZTVZEbXl5cjNNa3FEZ1NQYXhIK2JISzRJVHlG?= =?utf-8?B?amh4ZEFhYlVEeDJjVXkzd3VUV1FXS3hRcmtqcTdtSFRMQmdZZDEwTGNwbmhI?= =?utf-8?B?VGllbGI5VGV4RWVSd2ZnUTVxNkVJQnpsdTk0b2xpWTJqYnR5Q2t0U2NzNHow?= =?utf-8?B?UFBsd3BzWTVzekp3Z0IvTWRkVlNjQW5XeHBWbjVuc21MUGtZbGRLVjFFc2VU?= =?utf-8?B?OTlGR0hjOFdLcHFITE92YUtUSFlBQ1lGY2EvZHdRaDl0UTYwWnRpNWtyVXhp?= =?utf-8?B?Y1lja3pFYW9CQXR4NmVHUDQ5SkJ6WFFRSlhBY0NWQm5yMzJXUkorc280aTNr?= =?utf-8?B?Sy8vakZlakE1NHdTSUkrVHRlWEptK29HYzAyVkRGYmd5ZzZrdS9LQXUySStx?= =?utf-8?B?d3FpTVFiL2JXZERxbWNTMTRNaTB1RCtQOUtFSHp5VDZ3bUh6S3VQY0dYZTda?= =?utf-8?B?aTk1TWdVZ05jUitmTjgzdlY3TlhzakZ2b3dGdngzNFVzaUZQOERwNkRuTTY1?= =?utf-8?B?VldNWkdFN3BlazgyMThXZjRycWZTcllXOGJyYzFhZ0hNSmkzQkdHRy9uQWww?= =?utf-8?B?VmJYZnRuUkRrTlN3SHlIcHF1dmJUSGxPRVptR1NoeThNVkxhZUZYMjd2Y1Y0?= =?utf-8?B?dmpSekFTYUt5WFdEOCsyMDJSdEdvY0MrU2NxREZqRldRQTRrbEdTWEpWaEhG?= =?utf-8?B?Q3o4QXUxWlZRN2dzODlBVElRREN4eExUeTVPRDhJV0F2U3JyNmw5V1FXNlNo?= =?utf-8?B?K1ZsM2pPcnJFMXpSV215bERhVjh3RjcxZkhpODQzcGQwTmp5MlVqMEk1S3Vp?= =?utf-8?B?T2Z0OUgrVkt3alY3V3ZpclI0b1lCSyt6ZGU0Wm5qQXFnR3FxSEZtWUR2NnQ2?= =?utf-8?B?a3U1UT09?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB0895; 5:p4v90D3De0NMbDpvSooEvT4cQr3DeV5Zc/tkUW4VU8Y6xT2wuPxduPKMM3JR+M+fwH6A4nTDOZUxT6elX2o60LbEwUI03kLRuwaYOXA/n/U6ESyDjWRULwwh+prMlWPxNKWqJAtZcPNlUnHIoGvalA==; 24:dxa2KZJqHgdhsdVpsqPFLC8eMfCT69ZA0vU6YJ+zdjJs+U4GXaQynwHQGbhMyXFGyUtSqjOt7ObXmQaYiwfWhnzn8KhxFfxOLfzTTnV6PE0=; 20:d+65MEYgdTmHeifSyJi7c4b2LmFEx4vAgIiEoqwImFSbNxkHUtMY7kp2gz/FDQt83GePDeU6AtB3PD9hG44h4A== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2015 10:15:50.1908 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[206.191.242.68]; Helo=[mail.philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB0895 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-resource-directory-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 10:16:11 -0000 SGVsbG8sDQoNCj4+IGMpIENvdWxkIFJEIHVzZWQgd2l0aCBwcm90b2NvbHMgb3RoZXIgdGhhbiBD b0FQLCBzdWNoIGFzIEhUVFA/DQoNCj5BYnNvbHV0ZWx5LCBzZWUgYWJvdmUuDQoNClRoZXJlIG1h eSBiZSBzb21lIG1pbm9yIGZpeGVzIGluIHRoZSBjdXJyZW50IFJEIGRyYWZ0IG5lZWRlZCB0byBt YWtlIGl0IGZ1bGx5IEhUVFAgY29tcGxpYW50LiBGb3IgZXhhbXBsZSB0aGUgcmVzcG9uc2UgY29k ZXMgbmVlZCB0byBiZSBzcGVjaWZpZWQgaW4gQ29BUCBhcyB3ZWxsIGFzIEhUVFAgY29kZXMgdG8g YmUgY29tcGxldGUuDQpJZiB0aGUgYXV0aG9ycyB3YW50IHRvIHRha2UgdGhpcyBvbiB0aGF0IHdv dWxkIGJlIHBlcmZlY3QuICBPdGhlcndpc2UgSSBjb3VsZCBzdWdnZXN0IHNvbWUgdGV4dCAoYWxy ZWFkeSBhc2tlZCBQZXRlciBpZiBoZSBjb3VsZCBkbyB0aGlzIG9yIGRlbGVnYXRlIHRvIG1lIGlm IG5lZWRlZCkuDQoNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNv cmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJv cm1hbm4NClNlbnQ6IFR1ZXNkYXksIEp1bmUgMzAsIDIwMTUgMTY6NDUNClRvOiBIYW5uZXMgVHNj aG9mZW5pZw0KQ2M6IGNvcmVAaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFJlOiBbY29yZV0gZHJhZnQt aWV0Zi1jb3JlLXJlc291cmNlLWRpcmVjdG9yeS0wMw0KDQpIaSBIYW5uZXMsDQoNCj4gUmVtYXJr OiBXaGF0IHdhcyB0aGUgcmVhc29uIHRoZSBkb2N1bWVudCB0aXRsZSAiQ09SRSBSZXNvdXJjZSBE aXJlY3RvcnkiPw0KPiBDT1JFIGlzIHRoZSBuYW1lIG9mIHRoZSB3b3JraW5nIGdyb3VwLiBOb2Jv ZHkgb3V0c2lkZSB0aGUgSUVURiBrbm93cw0KPiB3aGF0IENPUkUgaXMgYW5kIHRoZSBsaWZldGlt ZSBvZiB3b3JraW5nIGdyb3VwcyBpcyBsaW1pdGVkLg0KDQpUaGUgc2FtZSByZWFzb24gdGhlIHdl bGwta25vd24gbGluayBpcyBjYWxsZWQgLy53ZWxsLWtub3duL2NvcmUgYW5kIG5vdCBzb21ldGhp bmcgd2l0aCBDb0FQIGluIGl0Og0KVGhpcyBjYW4gYmUgdXNlZCB3aXRoIGFueSBvZiB0aGUgdGhy ZWUgUkVTVCB0cmFuc2ZlciBwcm90b2NvbHMsIG5vdCBqdXN0IHdpdGggQ29BUC4NCg0KQ29SRSA9 IENPbnN0cmFpbmVkIFJFU1RmdWwgRW52aXJvbm1lbnRzDQoNCj4gYSkgV2h5IGFyZSB5b3UgdXNp bmcgdGhlIEROUyBpbiB0aGUgbGlnaHRpbmcgZXhhbXBsZSAoZnJvbSBTZWN0aW9uDQo+IDEyLjEp PyBEb2VzIGl0IGdhaW4geW91IGFueSBhZHZhbnRhZ2U/DQoNClVzaW5nIEROUyBpcyBvbmUgZGVw bG95bWVudCBvcHRpb24gdGhhdCBoYXMgb2Z0ZW4gYmVlbiByZXF1ZXN0ZWQuDQoNCj4gYikgVGhl IHVzZSBvZiBETlMtU0QgYWxzbyBhcHBlYXJzIGEgYml0IGFydGlmaWNpYWwgc2luY2UgUkQgYW5k IEROUy1TRA0KPiBwcm92aWRlIG92ZXJsYXBwaW5nIGZ1bmN0aW9uYWxpdHkuDQoNCkV4YWN0bHks IHNvIHRoZSBvYmplY3RpdmUgaXMgdG8gc2hvdyBob3cgdGhleSBjYW4gbm90IG9ubHkgb3Zlcmxh cCwgYnV0IGFjdHVhbGx5IGludGVyd29yay4NCg0KPiBjKSBDb3VsZCBSRCB1c2VkIHdpdGggcHJv dG9jb2xzIG90aGVyIHRoYW4gQ29BUCwgc3VjaCBhcyBIVFRQPw0KDQpBYnNvbHV0ZWx5LCBzZWUg YWJvdmUuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt ZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFw cGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRy ZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUg aGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwg b3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFu ZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBh bGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0K From nobody Thu Jul 2 21:16:35 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD4C1B2B48; Thu, 2 Jul 2015 21:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ni73F5PN08Gl; Thu, 2 Jul 2015 21:16:32 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E801B2B40; Thu, 2 Jul 2015 21:16:31 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-18-55960c9d30af Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 29.33.12828.D9C06955; Fri, 3 Jul 2015 06:16:29 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.19]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0210.002; Fri, 3 Jul 2015 06:16:29 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" , "cose@ietf.org" Thread-Topic: Object Secure CoAP update with COSE size estimates Thread-Index: AQHQtUcIFG/adJKjrk6N8Kdfvk5gYg== Date: Fri, 3 Jul 2015 04:16:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvje5cnmmhBg239Cz2vV3PbDFt61RW ByaPJUt+MgUwRnHZpKTmZJalFunbJXBl9MzYw14wQbjiz/6HjA2MF4S6GDk5JARMJP6+OMwO YYtJXLi3nq2LkYtDSOAoo8Tj6W9YQRJCAosYJQ58LQex2QRcJB40PGICsUWA7I19M8GahQWs Jc40rQCyOYDiDhKn9ulBlOhJrD9zCaycRUBFov3nTWYQm1fAQqJ78jewVkagvd9PrQGrYRYQ l7j1ZD4TxD0CEkv2nGeGsEUlXj7+B3aOKNDMldeb2CDiShJrD29nAVnLLKApsX6XPsQYa4lf 2z+xQNiKElO6H7JDrBWUODnzCcsERtFZSLbNQuiehaR7FpLuWUi6FzCyrmIULU4tLs5NNzLW Sy3KTC4uzs/Ty0st2cQIjJeDW37r7mBc/drxEKMAB6MSD++CN1NDhVgTy4orcw8xSnOwKInz zticFyokkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcUVHyXVfzZX31eXmlrudmTvPeoayuzdj v4+xc4iJqvem+90LpOoW7al9sMHL4vG8rrietb1nd8/lOm+65XuT6P8f5o/FvfSYp298uV2r +j5neN/6F5tvtbf7WbnULhBhjf3Pa+PtufDz548i/2auXfl0y+7Dq+/eehXA0ucQFhX7VC7B 8XiPjhJLcUaioRZzUXEiALM1s5J4AgAA Archived-At: Subject: [core] Object Secure CoAP update with COSE size estimates X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 04:16:34 -0000 DQpTb3JyeSBmb3IgY3Jvc3Nwb3N0aW5nLiBUaGUgdXBkYXRlIG9mIHRoaXMgZHJhZnQgd2FzIGFs cmVhZHkgYW5ub3VudWNlZCBvbg0KdGhlIEFDRSBsaXN0LCBidXQgaXMgYWxzbyByZWxldmFudCB0 byBDT1JFIGFuZCB0aGUgb25nb2luZyBkaXNjdXNzaW9uIGluDQpDT1NFIG9uIGVuY29kaW5nIGZv ciBzaW5nbGUgcmVjaXBpZW50cyBhbmQgbWVzc2FnZSBzaXplIGVzdGltYXRlcy4NCiANCg0KDQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1 cml0eS0wMg0KDQoNCk1haW4gY2hhbmdlcyBmcm9tIC0wMToNCg0KLSBTdXBwb3J0IGZvciBibG9j a3dpc2UgdHJhbnNmZXIgYW5kIGhvdyB0byBzdXBwb3J0IGFueSBDb0FQIG9wdGlvbg0KKEFwcGVu ZGl4IEEpDQotIENPU0UgcHJvZmlsZSAoQXBwZW5kaXggRCkNCi0gTWVzc2FnZSBzaXplIGNhbGN1 bGF0aW9ucyBvZiBNQUMsIEFFQUQsIHNpZ25hdHVyZSwgYW5kIHN5bW1ldHJpYw0KZW5jcnlwdGlv biArIHNpZ25hdHVyZSBmb3IgSk9TRSwgQ09TRSBhbmQgb3B0aW1pemF0aW9ucyAoQXBwZW5kaXgg RSkNCg0KDQoNCkfDtnJhbg0KDQoNCk9uIDIwMTUtMDYtMjkgMTU6NTgsICJpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQp3cm90ZToNCg0KPg0KPkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTAy LnR4dA0KPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRnJhbmNlc2NhIFBhbG9t YmluaSBhbmQgcG9zdGVkIHRvIHRoZQ0KPklFVEYgcmVwb3NpdG9yeS4NCj4NCj5OYW1lOgkJZHJh ZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eQ0KPlJldmlzaW9uOgkwMg0KPlRpdGxlOgkJ SnVuZSAyOSwgMjAxNQ0KPkRvY3VtZW50IGRhdGU6CTIwMTUtMDYtMjkNCj5Hcm91cDoJCUluZGl2 aWR1YWwgU3VibWlzc2lvbg0KPlBhZ2VzOgkJNDMNCj5VUkw6ICAgICAgICAgICAgDQo+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qt c2VjdXJpdHktMDINCj4udHh0DQo+U3RhdHVzOiAgICAgICAgIA0KPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHkvDQo+SHRt bGl6ZWQ6ICAgICAgIA0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWxhbmRl ci1hY2Utb2JqZWN0LXNlY3VyaXR5LTAyDQo+RGlmZjogICAgICAgICAgIA0KPmh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5 LTAyDQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBtZW1vIHByZXNlbnRzIE9TQ09BUCwgYSBzY2hl bWUgZm9yIHByb3RlY3Rpb24gb2YgcmVxdWVzdCBhbmQNCj4gICByZXNwb25zZSBtZXNzYWdlcyBv ZiB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApLA0KPiAgIHVzaW5n IGRhdGEgb2JqZWN0IHNlY3VyaXR5Lg0KPg0KPiAgICAgICAgICAgICAgICAgIA0KPiAgICAgICAg DQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2YNCj5zdWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj5UaGUgSUVU RiBTZWNyZXRhcmlhdA0KPg0KDQo= From nobody Thu Jul 2 23:55:22 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C651B2DCE for ; Thu, 2 Jul 2015 23:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.228 X-Spam-Level: * X-Spam-Status: No, score=1.228 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, T_RP_MATCHES_RCVD=-0.01] autolearn=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 dRQLocq2Xd0p for ; Thu, 2 Jul 2015 23:55:18 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id F38791B2DC6 for ; Thu, 2 Jul 2015 23:55:17 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 4811419F3AE for ; Fri, 3 Jul 2015 14:55:14 +0800 (HKT) Received: from WeiGengyuPC (unknown [10.103.240.2]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 141BD19F390 for ; Fri, 3 Jul 2015 14:55:14 +0800 (HKT) Message-ID: <3A6920B448CE46E39FCFE3B76AB66B13@WeiGengyuPC> From: "weigengyu" To: References: <5592A986.2060608@gmx.net> <5592AB4E.2050009@tzi.org> <031DD135F9160444ABBE3B0C36CED6186AF6D0BD@AMSPRD9003MB066.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED6186AF6D0BD@AMSPRD9003MB066.MGDPHG.emi.philips.com> Date: Fri, 3 Jul 2015 14:55:18 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [core] draft-ietf-core-resource-directory-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 06:55:21 -0000 Hi， Related to RD and DNS-SD, > 9. DNS-SD Mapping > CoRE Resource Discovery is intended to support fine-grained discovery > of hosted resources, their attributes, and possibly other resource > relations [RFC6690]. In contrast, service discovery generally refers > to a coarse-grained resolution of an endpoint’s IP address, port number, > and protocol. > Resource and service discovery are complementary in the case of large > networks, where the latter can facilitate scaling. This document > defines a mapping between CoRE Link Format attributes and DNS-Based > Service Discovery [RFC6763] fields that permits discovery of CoAP > services by either means. The problem is raised because RD operations are associcated with DNS and DNS-SD operations. When doing Domain Name or DNS-SD resolution in INTERNET, it is the DNS prototocol instead of HTTP to be used. So, could RD server be accessed by DNS protocol, or by HTTP in INTERNET? Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Dijk, Esko Sent: Wednesday, July 01, 2015 6:15 PM To: Carsten Bormann ; Hannes Tschofenig Cc: core@ietf.org WG Subject: Re: [core] draft-ietf-core-resource-directory-03 Hello, >> c) Could RD used with protocols other than CoAP, such as HTTP? >Absolutely, see above. There may be some minor fixes in the current RD draft needed to make it fully HTTP compliant. For example the response codes need to be specified in CoAP as well as HTTP codes to be complete. If the authors want to take this on that would be perfect. Otherwise I could suggest some text (already asked Peter if he could do this or delegate to me if needed). Esko -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Tuesday, June 30, 2015 16:45 To: Hannes Tschofenig Cc: core@ietf.org WG Subject: Re: [core] draft-ietf-core-resource-directory-03 Hi Hannes, > Remark: What was the reason the document title "CORE Resource Directory"? > CORE is the name of the working group. Nobody outside the IETF knows > what CORE is and the lifetime of working groups is limited. The same reason the well-known link is called /.well-known/core and not something with CoAP in it: This can be used with any of the three REST transfer protocols, not just with CoAP. CoRE = COnstrained RESTful Environments > a) Why are you using the DNS in the lighting example (from Section > 12.1)? Does it gain you any advantage? Using DNS is one deployment option that has often been requested. > b) The use of DNS-SD also appears a bit artificial since RD and DNS-SD > provide overlapping functionality. Exactly, so the objective is to show how they can not only overlap, but actually interwork. > c) Could RD used with protocols other than CoAP, such as HTTP? Absolutely, see above. Grüße, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Fri Jul 3 00:55:37 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D731A899F for ; Fri, 3 Jul 2015 00:55:36 -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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TT6AJtzca18 for ; Fri, 3 Jul 2015 00:55:34 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 3D2C21A899D for ; Fri, 3 Jul 2015 00:55:34 -0700 (PDT) Received: from localhost ([::1]:52403 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZAvol-00035P-H8; Fri, 03 Jul 2015 00:55:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: consultancy@vanderstok.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 03 Jul 2015 07:55:27 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/383 Message-ID: <060.34b6e9758bfdc67bd6f7f863c9c88041@trac.tools.ietf.org> X-Trac-Ticket-ID: 383 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: consultancy@vanderstok.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: core@ietf.org Subject: [core] #383 (resource-directory): HTTP response codes missing for function set definitions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 07:55:36 -0000 #383: HTTP response codes missing for function set definitions The HTTP response codes should be formally defined for all function sets in addition to the CoAP response codes. Reason: the HTTP response codes are needed when implementing RD with HTTP interfaces. And the HTTP code is not always the "same as CoAP code with dot removed". -- ----------------------------------+---------------------------------------- Reporter: | Owner: consultancy@vanderstok.org esko.dijk@philips.com | Status: new Type: protocol defect | Milestone: Priority: major | Version: Component: resource-directory | Keywords: Severity: - | ----------------------------------+---------------------------------------- Ticket URL: core From nobody Fri Jul 3 01:12:24 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6FA1A907A for ; Fri, 3 Jul 2015 01:12:23 -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, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVUBTC-QKzEX for ; Fri, 3 Jul 2015 01:12:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 1D1881A8FD4 for ; Fri, 3 Jul 2015 01:12:22 -0700 (PDT) Received: from localhost ([::1]:53160 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZAw54-0003yO-TJ; Fri, 03 Jul 2015 01:12:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 03 Jul 2015 08:12:18 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/core/trac/ticket/384 Message-ID: <060.366c667bc15f6d193977446f650055dd@trac.tools.ietf.org> X-Trac-Ticket-ID: 384 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-http-mapping@ietf.org Resent-Message-Id: <20150703081222.1D1881A8FD4@ietfa.amsl.com> Resent-Date: Fri, 3 Jul 2015 01:12:22 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: [core] #384 (http-mapping): Unclear how to discover CoAP resources from a HTTP client through a Proxy X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 08:12:23 -0000 #384: Unclear how to discover CoAP resources from a HTTP client through a Proxy Unclear how to discover CoAP resources from a HTTP client: there is no way currently to trigger a CoAP multicast discovery from a HTTP request. This may leave the reader wondering how to discover resources. A specific solution that we can give (informative) is use of a Resource Directory that has both HTTP and CoAP interfaces. This enables the HTTP client to discover CoAP resources that have been registered onto the RD. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: major | Version: Component: http- | Keywords: mapping | Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From nobody Fri Jul 3 01:19:10 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD641A909A for ; Fri, 3 Jul 2015 01:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.228 X-Spam-Level: * X-Spam-Status: No, score=1.228 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, T_RP_MATCHES_RCVD=-0.01] autolearn=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 y5raJCvMuuss for ; Fri, 3 Jul 2015 01:19:06 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9DA1A9098 for ; Fri, 3 Jul 2015 01:19:05 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id CCC4819F3B4 for ; Fri, 3 Jul 2015 16:19:03 +0800 (HKT) Received: from WeiGengyuPC (unknown [10.103.240.2]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 5BA2B19F3AE; Fri, 3 Jul 2015 16:19:02 +0800 (HKT) Message-ID: <6774557715C44D359E8DB0A51D834031@WeiGengyuPC> From: "weigengyu" To: "Dijk Esko" References: <060.34b6e9758bfdc67bd6f7f863c9c88041@trac.tools.ietf.org> In-Reply-To: <060.34b6e9758bfdc67bd6f7f863c9c88041@trac.tools.ietf.org> Date: Fri, 3 Jul 2015 16:19:06 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: core@ietf.org Subject: Re: [core] #383 (resource-directory): HTTP response codes missing for function set definitions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 08:19:08 -0000 Hi, I have a problem. Whether DNS protocol or HTTP is required when doing RD operations in INTERNET. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: core issue tracker Sent: Friday, July 03, 2015 3:55 PM To: consultancy@vanderstok.org ; esko.dijk@philips.com Cc: core@ietf.org Subject: [core] #383 (resource-directory): HTTP response codes missing for function set definitions #383: HTTP response codes missing for function set definitions The HTTP response codes should be formally defined for all function sets in addition to the CoAP response codes. Reason: the HTTP response codes are needed when implementing RD with HTTP interfaces. And the HTTP code is not always the "same as CoAP code with dot removed". -- ----------------------------------+---------------------------------------- Reporter: | Owner: consultancy@vanderstok.org esko.dijk@philips.com | Status: new Type: protocol defect | Milestone: Priority: major | Version: Component: resource-directory | Keywords: Severity: - | ----------------------------------+---------------------------------------- Ticket URL: core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Fri Jul 3 01:19:56 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223791A90CE; Fri, 3 Jul 2015 01:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPK3Qt4up4Q8; Fri, 3 Jul 2015 01:19:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A111A8900; Fri, 3 Jul 2015 01:19:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150703081951.30762.98296.idtracker@ietfa.amsl.com> Date: Fri, 03 Jul 2015 01:19:51 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-http-mapping-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 08:19:53 -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 Working Group of the IETF. Title : Guidelines for HTTP-CoAP Mapping Implementations Authors : Angelo P. Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk Filename : draft-ietf-core-http-mapping-07.txt Pages : 36 Date : 2015-07-03 Abstract: This document provides reference information for implementing a proxy that performs translation between the HTTP protocol and the CoAP protocol, focusing on the reverse proxy case. It describes how a HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to a HTTP response. Furthermore, it defines a template for URI mapping and provides a set of guidelines for HTTP to CoAP protocol translation and related proxy implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-http-mapping-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-http-mapping-07 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 Jul 3 01:21:26 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF041A1BC8 for ; Fri, 3 Jul 2015 01:21:25 -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, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-rX3YDmsWKP for ; Fri, 3 Jul 2015 01:21:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 EACBC1A9155 for ; Fri, 3 Jul 2015 01:21:12 -0700 (PDT) Received: from localhost ([::1]:54158 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZAwDg-0006Rh-BT; Fri, 03 Jul 2015 01:21:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 03 Jul 2015 08:21:12 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/376#comment:4 Message-ID: <075.b75ce7fdf98ae66477b2c7ebacea79e0@trac.tools.ietf.org> References: <060.d5f29140d8b885894f235764ef20f65f@trac.tools.ietf.org> X-Trac-Ticket-ID: 376 In-Reply-To: <060.d5f29140d8b885894f235764ef20f65f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-http-mapping@ietf.org Resent-Message-Id: <20150703082112.EACBC1A9155@ietfa.amsl.com> Resent-Date: Fri, 3 Jul 2015 01:21:12 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #376 (http-mapping): CoAP 4.05 response can't be translated to HTTP 405 by HC proxy X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 08:21:25 -0000 #376: CoAP 4.05 response can't be translated to HTTP 405 by HC proxy Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Fixed in -07 based on consensus (see previous comment) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: protocol | Status: closed defect | Milestone: Priority: major | Version: Component: http- | Resolution: fixed mapping | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Fri Jul 3 01:22:24 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED2C1A912C for ; Fri, 3 Jul 2015 01:22:23 -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, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtuOqA2Sw4Tm for ; Fri, 3 Jul 2015 01:22:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 ED2BC1A92F7 for ; Fri, 3 Jul 2015 01:22:21 -0700 (PDT) Received: from localhost ([::1]:54199 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZAwEn-00032o-NY; Fri, 03 Jul 2015 01:22:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 03 Jul 2015 08:22:21 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/377#comment:2 Message-ID: <075.40e98729dea5fac0b23cd09f57e9327e@trac.tools.ietf.org> References: <060.26cae6fec524a7bbeab3c29a73258e09@trac.tools.ietf.org> X-Trac-Ticket-ID: 377 In-Reply-To: <060.26cae6fec524a7bbeab3c29a73258e09@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-http-mapping@ietf.org Resent-Message-Id: <20150703082221.ED2BC1A92F7@ietfa.amsl.com> Resent-Date: Fri, 3 Jul 2015 01:22:21 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #377 (http-mapping): Define an open ended HTTP media type "application/x-coap-" ? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 08:22:23 -0000 #377: Define an open ended HTTP media type "application/x-coap-" ? Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Fixed in -07 ; Added IANA section that defines a new HTTP media type "application/coap-payload" and created new Section 6.2 on how to use it. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: Priority: major | Version: Component: http- | Resolution: fixed mapping | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Fri Jul 3 01:25:01 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0DF1ABC74 for ; Fri, 3 Jul 2015 01:24:59 -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, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVZI0sAwVvyy for ; Fri, 3 Jul 2015 01:24:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 3F6EE1A92F7 for ; Fri, 3 Jul 2015 01:24:58 -0700 (PDT) Received: from localhost ([::1]:54365 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZAwHK-0007Ay-1P; Fri, 03 Jul 2015 01:24:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 03 Jul 2015 08:24:58 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/378#comment:2 Message-ID: <075.6ffd02a9360a186af028444a89cb20d0@trac.tools.ietf.org> References: <060.8dbee8da557bd66776e1a11a4082e087@trac.tools.ietf.org> X-Trac-Ticket-ID: 378 In-Reply-To: <060.8dbee8da557bd66776e1a11a4082e087@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-http-mapping@ietf.org Resent-Message-Id: <20150703082458.3F6EE1A92F7@ietfa.amsl.com> Resent-Date: Fri, 3 Jul 2015 01:24:58 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #378 (http-mapping): Include ref to automatic media type mapping update mechanism X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 08:24:59 -0000 #378: Include ref to automatic media type mapping update mechanism Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => wontfix Comment: Authors decided not to address this. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: Priority: minor | Version: Component: http- | Resolution: wontfix mapping | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Fri Jul 3 01:25:49 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C63B1A89E9 for ; Fri, 3 Jul 2015 01:25:47 -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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVI0mjqpEUKp for ; Fri, 3 Jul 2015 01:25:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 5A64C1A89C7 for ; Fri, 3 Jul 2015 01:25:46 -0700 (PDT) Received: from localhost ([::1]:54417 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZAwI5-0002Dj-Kq; Fri, 03 Jul 2015 01:25:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 03 Jul 2015 08:25:45 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: https://xml.resource.org/wg/core/trac/ticket/384#comment:1 Message-ID: <075.55fe138fbdf042cb0bf32677268ed3d2@trac.tools.ietf.org> References: <060.366c667bc15f6d193977446f650055dd@trac.tools.ietf.org> X-Trac-Ticket-ID: 384 In-Reply-To: <060.366c667bc15f6d193977446f650055dd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-http-mapping@ietf.org Resent-Message-Id: <20150703082546.5A64C1A89C7@ietfa.amsl.com> Resent-Date: Fri, 3 Jul 2015 01:25:46 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #384 (http-mapping): Unclear how to discover CoAP resources from a HTTP client through a Proxy X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 08:25:47 -0000 #384: Unclear how to discover CoAP resources from a HTTP client through a Proxy Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Fixed in -07; Section 5.4.1 describes briefly (informative) how to discover CoAP resources from an HTTP client. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: Priority: major | Version: Component: http- | Resolution: fixed mapping | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Fri Jul 3 01:31:12 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A941A86FC for ; Fri, 3 Jul 2015 01:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YcZxz_qV3mv for ; Fri, 3 Jul 2015 01:31:08 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE461A066C for ; Fri, 3 Jul 2015 01:31:07 -0700 (PDT) Received: from AM3PR04MB1457.eurprd04.prod.outlook.com (10.163.186.15) by AM3PR04MB0710.eurprd04.prod.outlook.com (10.160.4.153) with Microsoft SMTP Server (TLS) id 15.1.201.16; Fri, 3 Jul 2015 08:30:46 +0000 Received: from VI1PR04CA0002.eurprd04.prod.outlook.com (10.163.3.12) by AM3PR04MB1457.eurprd04.prod.outlook.com (10.163.186.15) with Microsoft SMTP Server (TLS) id 15.1.201.16; Fri, 3 Jul 2015 08:30:45 +0000 Received: from DB3FFO11FD032.protection.gbl (2a01:111:f400:7e04::126) by VI1PR04CA0002.outlook.office365.com (2a01:111:e400:58e9::12) with Microsoft SMTP Server (TLS) id 15.1.207.19 via Frontend Transport; Fri, 3 Jul 2015 08:30:45 +0000 Authentication-Results: spf=none (sender IP is 206.191.242.68) smtp.mailfrom=philips.com; bupt.edu.cn; dkim=none (message not signed) header.d=none; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from mail.philips.com (206.191.242.68) by DB3FFO11FD032.mail.protection.outlook.com (10.47.217.63) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Fri, 3 Jul 2015 08:30:44 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.135]) by AMSPRD9003HT001.MGDPHG.emi.philips.com ([141.251.33.78]) with mapi id 14.16.0488.000; Fri, 3 Jul 2015 08:30:42 +0000 From: "Dijk, Esko" To: weigengyu Thread-Topic: [core] #383 (resource-directory): HTTP response codes missing for function set definitions Thread-Index: AQHQtWWkO1i4z/sYPk6QlXO/woGbOp3JZw8AgAACjzA= Date: Fri, 3 Jul 2015 08:30:42 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6186AF819D8@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <060.34b6e9758bfdc67bd6f7f863c9c88041@trac.tools.ietf.org> <6774557715C44D359E8DB0A51D834031@WeiGengyuPC> In-Reply-To: <6774557715C44D359E8DB0A51D834031@WeiGengyuPC> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.85.143.215] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD032; 1:fwsdB7qiIh7JCcBecegJM2s0yfdpY59CxgqN8e1UvPcuEu5n5UUi7rsCYzIV9uyufXj46xBenCeKW6r6eDNMeRUIUQRrTSo9uVlpFX0irQn9rcwUj+zA25LFiHJhh7ABmusOGu9twYBQe+2vUNEmqWO3vqw/WNDhRHFCCgEWtHfNKKnQ2qt39D7jypY4CrScokt/HBURJ1U8B7Xge0CtZ0uxwLnGFT9o4M/Sd+0yR4twImwTp/4YITWW3Gl+A+lnozP0A23VByAF2ckhh2Q5Sg== X-Forefront-Antispam-Report: CIP:206.191.242.68; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(428002)(199003)(189002)(85714005)(374574003)(377454003)(47776003)(106116001)(66066001)(54356999)(50986999)(46102003)(5001960100002)(110136002)(105586002)(189998001)(101416001)(6806004)(76176999)(2950100001)(2900100001)(2920100001)(5003600100002)(77156002)(62966003)(104016003)(92566002)(23676002)(2656002)(55846006)(19580405001)(19580395003)(87936001)(2171001)(33656002)(106466001)(86362001)(102836002)(50466002)(15975445007)(567094001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR04MB1457; H:mail.philips.com; FPR:; SPF:None; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM3PR04MB1457; 2:+WUN94Jxfxek3OOlF98qvu8jv6udXTopdTFPz8YtOxMx7s1w/vEOILzmat5mappI; 3:+4xp5f5ox30fBBz4O9vCuwioVNhA6uQipgtbLYWRsOo1UXFoN3azB2bRiYQmip8QmhwfKHI6u6yd/52PFMNrGSDgxRobgKw+V4kbE+S2A35v36hahQWDW+ua/teQD4oFpf16QRaF6HMZLYp+jKpUqkzoNLKoW6krdHOSo5bEn5CG0xWjGRwjbB7RSXid5zZLE57AaczCjUB5fh/DxgVaHPLn2ygrTagJXdU6aUczJuZ59pTnTJOYyXn1/4gvH314; 25:1j415yh8Zsac/jjhRtq2Y4tKg4wNoUM8nq2LJAZEyKtu2YA8r2rX9LxVTe4hLR/vgoqZi41/zP59xpDzMls6Po0ewyuzACCZxjfUUKA2DZ/b/lzT7hI4qs6L3YgcTlOchjBnDHxQ/N7IrUe/9oavVzE2SKbNruWIIUSMilswuFAHonbYr4RWlprJ/d6NBLYBZI4vbKdFnvjhI1C7VjMQlA66DALaF1WFFMZyAxireijRUeYXJYfm6NgFFECYdviobBjgG6AMkynZcMlqWmMAWg== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AM3PR04MB1457; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AM3PR04MB0710; X-Microsoft-Exchange-Diagnostics: 1; AM3PR04MB1457; 20:dAvhTD8qUAHmsugtAJx3j1qkFMaqR6BK9Zyrd06EdmrnEdznCineHuXDInETsMiEglZzazD9wcJ3YtYb+8dPos2lS8bD5eCGN7xNLueVg5cBlySQ3ITxpHJ9CypmqjqSpGucvSEukPiZprujV6GjYOvRjbDVyVZSEihknj+Hv5ClMU7VlqvLcKMAlkjkRhD1R9ujxp13kM1MfI/5AqxxMdU32QyWSYjfu4Xl/bEu7sv7BV3GLbTsheo9qHNehzghpk84bgB+ulJO0Tl9wowMVT6hQWuF1eQg+ODeeCBWMZxcG+UPWq30sKCi3F2GN7NUt519xL7QFvP5nuOqyByLPx4h/AmM5oKtlJs+4VMzPZXigl6pIpTpanFhq5KChJ275xtFGIfcbE5b2e0QzvEnF81G/arnckwjNQTr1SzcOb8EXrN8q4GRVTw4dziAeX3/05E4CI6/GnXjvmVTi4+ydWA+Px23MfGC6BcLIntl+N7rz0hqovqlnbzneyCnGGlF; 4:vmmVCAInUbI32ITdIQnUCtyIvHaAirOpfvr5et97izHpVmbld5dK0zK2aufYZyZ5O8h2fT/PMrIvO0KZNIuoaZ3Qj4QoeK9pGc0orbfw2L+Z/vsQeGCwJZUGCmJJC/7w/VxmuEuA81RAtBK0jjR4y19e58lx7U/SAbummZAjxy6jYk7mDkzU6fw97PIxC+Jq0TZuub3uaQ49SjFvHPvOK9wWQjq95TmflnQtn5XKJYW2+xCA60Ju3ZtGM+K+XlRYzYraGoROyK9Gval0O4Qqm7AYJVBvYEJ89F9/NVL8yr8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AM3PR04MB1457; BCL:0; PCL:0; RULEID:; SRVR:AM3PR04MB1457; X-Forefront-PRVS: 0626C21B10 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTNQUjA0TUIxNDU3OzIzOjR0UXBmREs1U0t4TndBZ3RmandYYi9FVWZO?= =?utf-8?B?NStRcUp2U3pPRWpDN0FYUitjWHFKNi8yTnpjcDd2emRiaWpqKzBhVEtSNFRM?= =?utf-8?B?THV2ZW91bnRycnFtdHJtRGZjbHVHUTZXTlhSQnc3U1JlNjVVTGZTZjMyeUM1?= =?utf-8?B?YVpYbHhCdDV2WnlqUGVYSjV1SGFIUGdYSlhYak84RVYyMzJpbkRCc0NaUU8v?= =?utf-8?B?dmFDT3UvQ0VZeUJJL1ZMaXRMbXVrT2sxQXBqd29hdjc2SklqU3UyRGc5c3d2?= =?utf-8?B?Q0t5WnQ2dlR4S0ZPVnQ4NE55WUVKUEhMdUp4V3BsVXBpZ0p2VDdOSW5Bc2Y5?= =?utf-8?B?U09GRWtCYWZaVTR1Z3BZZzAzOGRKL2ZvQTFBT0dPQlozYmR2VGRSb05ZMGxk?= =?utf-8?B?Q0NCdFhDeXpDelVFcXljd0ZDZ0szUHQvTVBBMThoTEQ3MS9uUTFydytSRzVp?= =?utf-8?B?aGR0YVFjT3Nqei9kSDdkQVJCbmU4bHhaSHJMYUJWaWNjWkova1FoVU9KNkJR?= =?utf-8?B?RzN5VGF2Z1dURnRsT2lXNjhQbHhiQXQrdkFiQzNRYzlGUjdmYStVNjRBa2pO?= =?utf-8?B?cE9OY2htNXZNZ0tDamUycUIzNk9tVldqVFZPUGh1TVlCUjkwY1JKWWdWN28v?= =?utf-8?B?eWZFOFFOSWNtTm9wRlJlOVlnc21PeHRFOFgyMXFjVFBaYThmYitQTVYvWE1o?= =?utf-8?B?TG9TU2pDSzczUFpBSjVKdnpqbE1zSktvT3hCSHpXdURMejZFN0RjRzIzNHRV?= =?utf-8?B?enB6N2xWR0l4Vytyb2JFRlFUK0M0aUlzOU02Q3Q0WHRuWWVmWUVUdjFaSVFR?= =?utf-8?B?TUFzQ05SQVBCaWh1LzBGR2RkRmtlSVptdERrRHhKdnJmclBHTXlDTk8rclhw?= =?utf-8?B?UC9YTjlqOFo2WHp4SXpzOWhJcEJLeDczTThaYkZsRWdWcFJqUlhTb05yNW8x?= =?utf-8?B?bFdNK3didFd4Z1VWaXQ5RVBobnMwZXY2dkplN1lvR3FXKytDb05hVC9GYVll?= =?utf-8?B?ZGl2NjNXNTY5WkliUjFJU1lhclVNMlBIMlc5MCtvUXEyTHIwTHNtZDJVV0h0?= =?utf-8?B?MFVWZmtVczN0M0ZDVEV1Yk52Y3NOL3JDWVgzZ2ZRK3BPSGVqYlQyV29hcXhK?= =?utf-8?B?UDFxdmVFeWYySDg5THdud2xoU3VkbFdRUjRwb0ZwZURYWkI1YjNPU2VFRmVu?= =?utf-8?B?WElVeDZGMGZabHhUSEF4SjN5eStrb2p1RXdlWDduYnNPclZQaWQraHE3NGVv?= =?utf-8?B?ZGR6UHdFZ1A0SnNFVDQ5a0NPREJVWDJjT3RCdUN6eURuRnBIRkpXRm82MGp3?= =?utf-8?B?bUNZOGVYZ0RJZzBzOGQ2RnVIM2RSa21JT3FueG1FQkV3aWtlRFRZOE82Uis5?= =?utf-8?B?TWwwZVpPaThnV0liMUI4M0Z2V1RLbE1XV3JBRXRhWitOOExoTlc0VGEvejM3?= =?utf-8?B?bkxQWWFzMVhpSDJTaDVwdDUzTzdzZ1k2SnErWGJYSzh5bWJVMDN6djJzc0tR?= =?utf-8?Q?L32K2gb+siolfg6IUgR76LBXM=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR04MB1457; 5:1vfAoK44jcMjsTCX0U03ARBVhVEWv8OewnKkKB6G33Kc72/I6aMcaW65psB3mXBDNHvAa3kA7P8TxJdV9SD3zlXyKolWuIoviaTEYGWKjpDBoiq31qPY7H3vacsZqhY0gsFS1tELI1or+5MfTHA2QQ==; 24:OfVncHHHyvj5tH+bADM2tvAbH8v/CKKePH6E5e/2b51FAIHBaudDmsL6v2K1Rh3qUTduQJZi6OyT48UTObF+SYdCe/Mn2UYMVoiazcxPz7M=; 20:9qWjtD5d1zUQeinq/JUqAtZXOuWp8CPkGlsdaCnjVg6uu7nA10LcpxxmxD3jQtyme62eRzKuk+Vc2Sgap6fv1A== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jul 2015 08:30:44.1855 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[206.191.242.68]; Helo=[mail.philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR04MB1457 X-Microsoft-Exchange-Diagnostics: 1; AM3PR04MB0710; 2:3Al14P1wexTYZQcJ8xmOMWDp6Dfs5oBM8zPk4fscZrBvVfqq2eS3H/gb+OIRAmCW; 3:P2IyVkATFQbfYnMYrJhlyhEj3+BQp4O95YbjxYuHJYqDor+whT8AbIM63oiRxX6+TLs3M90gig1IqmvQOJmiFu2WmOn6PH3rr/SvaLkJAlBLlyhgSDIeKFhEZGX7KWaqFG0Y8vZKe7IbqSm0pF6gVJvB9CZcUIRwwjm2Gv6vMzT3o3OAep/S4hFZRqvgfkUOWETQ2SztjQatUfrECW5lZxWbSgphMN1sliAy6zgvvnfKIiht+G9BxrG669KHiKwg; 25:Gjv0Sk0C+bLHjCnllEoyohwpjzZJ9N1KdAJ61rY5r2Oefxv0GLjAMR5O5nhg98NeOFHLcp1XA9YoknG3oJGEQ3fTx9H0N4a7oWrxukq6wZ+u/TbDCVm4nIksd/+bb9V2pa3LaE1g2ywlaelc6fMVYFa4VluRtT7lkk/42bu6WA9yt3O9IwQdlNLMEJx3VsnjgieCYc9YZjVOXNHZ5sWaLrviMmR6XHZaf2EtmYP5hbITl0PJNlTF9aGnuq+NSiF2C3j1CgbId22+jBhQuFEdjQ==; 23:0ijCoyJq3/wL8ToATPHNDVvkXSf+0kgkRa5+kXV1MitNDDUlxef34hlUN5bkng0hIh8wM1P/0y8B4LwxtWfWQP8ytVow4VFI8p/50AjiIb/QqCvlXv0GSxknwaicOpBRL26w9FN+0t0YzasrIftAf/LZ6anFe4l01AFQY6MDN00/VmbIy6f7KggDP1UohYoO2bPCvYzW2CPWpDSW7Hg5fFloZ5rnOqBjv9LXApKl9iP27Dal8KjqwDw8ufJYuotO X-OriginatorOrg: philips.com Archived-At: Cc: "core@ietf.org" Subject: Re: [core] #383 (resource-directory): HTTP response codes missing for function set definitions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 08:31:11 -0000 SGVsbG8sDQoNCkJvdGggQ29BUCBhbmQgSFRUUCBpbnRlcmZhY2VzIGNhbiBiZSB1c2VkIGZvciBv cGVyYXRpb25zIG92ZXIgdGhlIEludGVybmV0Lg0KV2hldGhlciBETlMgaXMgcmVxdWlyZWQgZGVw ZW5kcyBvbiB5b3VyIHVzZSBjYXNlIC8gc2l0dWF0aW9uLCBtYXliZSBnb29kIHRvIGRlc2NyaWJl IHRoZSBwcm9ibGVtIGluIHNvbWUgbW9yZSBkZXRhaWwgaWYgeW91IHRoaW5rIHdlIGNhbiBiZSBv ZiBoZWxwLg0KDQpJIHRoaW5rIEROUyBjb3VsZCBiZSByZXF1aXJlZCBmb3IgSFRUUCBub2Rlcywg Zm9yIENvQVAgbm9kZXMsIGZvciBub25lLCBvciBmb3IgYm90aC4gRGVwZW5kaW5nIG9uIHRoZSBz aXR1YXRpb24vYXBwbGljYXRpb24uDQoNClJlZ2FyZHMNCkVza28NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IHdlaWdlbmd5dSBbbWFpbHRvOndlaWdlbmd5dUBidXB0LmVkdS5j bl0NClNlbnQ6IEZyaWRheSwgSnVseSAwMywgMjAxNSAxMDoxOQ0KVG86IERpamssIEVza28NCkNj OiBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdICMzODMgKHJlc291cmNlLWRpcmVj dG9yeSk6IEhUVFAgcmVzcG9uc2UgY29kZXMgbWlzc2luZyBmb3IgZnVuY3Rpb24gc2V0IGRlZmlu aXRpb25zDQoNCkhpLA0KDQpJIGhhdmUgYSBwcm9ibGVtLg0KV2hldGhlciBETlMgcHJvdG9jb2wg b3IgSFRUUCBpcyByZXF1aXJlZCB3aGVuIGRvaW5nIFJEIG9wZXJhdGlvbnMgaW4gSU5URVJORVQu DQoNClJlZ2FyZHMsDQoNCkdlbmd5dSBXRUkNCk5ldHdvcmsgVGVjaG5vbG9neSBDZW50ZXINClNj aG9vbCBvZiBDb21wdXRlcg0KQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29t bXVuaWNhdGlvbnMNCi0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0NCkZyb206IGNvcmUgaXNzdWUgdHJh Y2tlcg0KU2VudDogRnJpZGF5LCBKdWx5IDAzLCAyMDE1IDM6NTUgUE0NClRvOiBjb25zdWx0YW5j eUB2YW5kZXJzdG9rLm9yZyA7IGVza28uZGlqa0BwaGlsaXBzLmNvbQ0KQ2M6IGNvcmVAaWV0Zi5v cmcNClN1YmplY3Q6IFtjb3JlXSAjMzgzIChyZXNvdXJjZS1kaXJlY3RvcnkpOiBIVFRQIHJlc3Bv bnNlIGNvZGVzIG1pc3NpbmcgZm9yIGZ1bmN0aW9uIHNldCBkZWZpbml0aW9ucw0KDQojMzgzOiBI VFRQIHJlc3BvbnNlIGNvZGVzIG1pc3NpbmcgZm9yIGZ1bmN0aW9uIHNldCBkZWZpbml0aW9ucw0K DQpUaGUgSFRUUCByZXNwb25zZSBjb2RlcyBzaG91bGQgYmUgZm9ybWFsbHkgZGVmaW5lZCBmb3Ig YWxsIGZ1bmN0aW9uIHNldHMgaW4gYWRkaXRpb24gdG8gdGhlIENvQVAgcmVzcG9uc2UgY29kZXMu IFJlYXNvbjogdGhlIEhUVFAgcmVzcG9uc2UgY29kZXMgYXJlIG5lZWRlZCB3aGVuIGltcGxlbWVu dGluZyBSRCB3aXRoIEhUVFAgaW50ZXJmYWNlcy4gQW5kIHRoZSBIVFRQIGNvZGUgaXMgbm90IGFs d2F5cyB0aGUgInNhbWUgYXMgQ29BUCBjb2RlIHdpdGggZG90IHJlbW92ZWQiLg0KDQotLQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLQ0KUmVw b3J0ZXI6ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIE93bmVyOiAgY29uc3VsdGFuY3lA dmFuZGVyc3Rvay5vcmcNCiAgZXNrby5kaWprQHBoaWxpcHMuY29tICAgICAgICAgICB8ICAgICBT dGF0dXM6ICBuZXcNCiAgICAgVHlwZTogIHByb3RvY29sIGRlZmVjdCAgICAgICB8ICBNaWxlc3Rv bmU6DQpQcmlvcml0eTogIG1ham9yICAgICAgICAgICAgICAgICB8ICAgIFZlcnNpb246DQpDb21w b25lbnQ6ICByZXNvdXJjZS1kaXJlY3RvcnkgICAgfCAgIEtleXdvcmRzOg0KU2V2ZXJpdHk6ICAt ICAgICAgICAgICAgICAgICAgICAgfA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvd2cvY29yZS90cmFjL3RpY2tldC8zODM+DQpjb3JlIDxodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvY29yZS8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5 IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBs YXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90 aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1 Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1 bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNv bnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMg b2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= From nobody Fri Jul 3 04:54:04 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201C81B2E56 for ; Fri, 3 Jul 2015 04:54: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmvG2A12tcud for ; Fri, 3 Jul 2015 04:54:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4AB1B2E55 for ; Fri, 3 Jul 2015 04:54:01 -0700 (PDT) Received: from [192.168.131.141] ([195.149.223.251]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LyVpm-1Yw9WD2Uty-015nw9 for ; Fri, 03 Jul 2015 13:53:59 +0200 Message-ID: <55967841.2040501@gmx.net> Date: Fri, 03 Jul 2015 13:55:45 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "core@ietf.org WG" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lQ8DHtSLo7sgHncSDn9mXm7N0w5M1qWkw" X-Provags-ID: V03:K0:hKqBfI6yCljNDn8t4+t/+83NyyZm4nFZFv+6pVYKEf30GET3REY ZqAZtT/YKSO1AhADUpgRc/ku0CKocJH2VKt53SfXV+mEQOXfkBlqiI6lXd3C60WTaK1CoA3 Qw1/wVJv/wu3t161pS9LlBthwa8aimlllfgpcFFbyoNlqfpYRjDASiHTvXV99tChpVTh/nQ BYmfaMD/9cY2AG8GcY1Dw== X-UI-Out-Filterresults: notjunk:1;V01:K0:5+59KsmwQHo=:Z2AUavZU+VNSme+wqdif09 zCLaYbUidIeSDVu8zLuicbf7pfgQmiH+wfZ4Cars4mjm/P4ruyubX3TwDsXlvMIV8EM9wIrd4 fjlLO82VsqXqu+DatCfblKuars1M2xunKVbZIPKO7+zEIoa58mLhm+pp0rVSxx4l+k4ExA9uu DrnfTRKT8NBDtwt0loWqNr93WZ+MdupK8jMPvLFYnvFrYDMSWrFeGCncGlp3tlghBfEK05vA1 bT7s+tAVrwZH7GBcfJCtWzEa/TMtx87NCI6TyR7Wq3lmNQ37b6NJ57vtSMPR8SpDl+oCddQ9T 3KfQ4lgioXngLann/GIK3S3s7a9uq2qwcXVaoiLR+n68WABxhnXXrkPM8GtbzPDeipco3Px1U pBz8ZN5F7rjZHvs7UzaVlyGlAW47bTTx1ShVsp2mNFqOTZeeHDXsMpjiPV4hb2RZYwvdO9zQU XWidtaOlF1E3y07uiLbXLQ6jXSjA3BeMzV8vpEIcsvW3sfxWPcz/osuf1N3d51MeR8IwO/OC4 NQjbSEhTcd+QSyxIRA8akphc+7Y5TzKSlugPYtPrQ0MXsxd46FiZQDg0QCOE7UTTA0TdmeMPA E049B1q/IqdusWudd++JlIgwNfjepbj0z5ZuXOrB5HlFb5Gs+ZMdePuQp4bOOkeFbCsDUrjg3 I9YWPlrRo63IU6NEehugR+xgSCpgUsaeiC8ygSR9/SqZPaA== Archived-At: Subject: [core] Endpoint name in draft-ietf-core-resource-directory-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 11:54:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lQ8DHtSLo7sgHncSDn9mXm7N0w5M1qWkw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I looked at draft-ietf-core-resource-directory-03 (again) and noticed that some terms are used inconsistently. For example, in various places throughout the document the terms 'endpoint' and 'endpoint name' is used. These are two different concepts but when I look at the definition then it turns out that it is defined as follows: ep :=3D Endpoint (mandatory). The endpoint identifier or name of the registering node, unique within that domain. The maximum length of this parameter is 63 bytes. I would suggest to change the description to: ep :=3D Endpoint name (mandatory). The endpoint name is an identifier that MUST be unique within a domain. The maximum length of this parameter is 63 bytes. It might also be worthwhile to mention that there is no assumed structure of this endpoint name identifier (unlike the domain variable that has a structure if is supposed to be mapped to the domain parameter of DNS-SD). Table 1 in the IANA consideration section talks about endpoint name again, which is correct. However, in Section 7 on page 21 the term 'endpoint' is used instead of 'endpoint name' for the 'RD Lookup Function Set'. Ciao Hannes --lQ8DHtSLo7sgHncSDn9mXm7N0w5M1qWkw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVlnhBAAoJEGhJURNOOiAtUWgH/1fbiln/NRsq2MIK7dSR8Bal pDUPLdA4ljwT6bthf4GM78rVawNpT6nLoG4NaEQkwINal8xZCmo8pYXBqIeLbC3K WqnsCdmSSgzdpz4bg3KFa82QHXJybnojDSWc1waJvxo8PvvmpcHO5nOMWf2qxY8q 4B6jkBQm+wkd/oPtB6g2rZmFeNr6eO5DAdLILHU0GuUxlV+mbYr4XSNWgt6UCcr7 Sgl0zjL13yA/+kkq6Wkli90H3H4sXUMBs7ww/WcrJ/jf6KwVodg7YL7FPyfFAqh2 NR3VIOPmuAfxpZR8vH4CRGAgeSnouVsjXK/0TlXEL6I37R0OzKHr9QIM0Fzu4zA= =/Rka -----END PGP SIGNATURE----- --lQ8DHtSLo7sgHncSDn9mXm7N0w5M1qWkw-- From nobody Fri Jul 3 13:41:17 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AC41A878E for ; Fri, 3 Jul 2015 13:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 9zNmmODlTLjM for ; Fri, 3 Jul 2015 13:41:14 -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 107B31A6F29 for ; Fri, 3 Jul 2015 13:41:13 -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 t63Kf9Ai001904; Fri, 3 Jul 2015 22:41:09 +0200 (CEST) Received: from alma.local (p5DC7EA60.dip0.t-ipconnect.de [93.199.234.96]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mNSqn5BHgz3G7l; Fri, 3 Jul 2015 22:41:09 +0200 (CEST) Message-ID: <5596F364.3080004@tzi.org> Date: Fri, 03 Jul 2015 22:41:08 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Hannes Tschofenig References: <55967841.2040501@gmx.net> In-Reply-To: <55967841.2040501@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Endpoint name in draft-ietf-core-resource-directory-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 20:41:16 -0000 Thanks -- the current editor draft now more correctly separates the concepts of endpoint and endpoint name. Grüße, Carsten From nobody Fri Jul 3 18:41:39 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC761B327C for ; Fri, 3 Jul 2015 18:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpQf3C13UWHM for ; Fri, 3 Jul 2015 18:41:37 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::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 E6F081B327A for ; Fri, 3 Jul 2015 18:41:36 -0700 (PDT) Received: by pdbep18 with SMTP id ep18so71362183pdb.1 for ; Fri, 03 Jul 2015 18:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=KYHTbNBCHK4lQ6ryVz74VAe8wfRhG8kQA1PVYd8bLDg=; b=vcTaTGzYfMk3m3yrrkmx3bSjN6EmT2iwO9G+FKwKn8OieP7DSdcAuy4bv0uV1nbhBL qM/doCa/YPgpZwIhRsyBE5+o+PhHJ3lApDRgcrzjmTnIN5MkUerhc0sOUKNmPrZfZi/Z QKCkwpUXb9jJisup76IC50YD1VYGhZa4aVVJgejIbEL2uE/pQUn3dxCyqu8Pkj9h49hQ gZHKFTsLfjWDdvTJ8QkrRNx4t9N9rXUiYGVWoql7EonZLZuQH68A+aiSjfYNQTt8oW4t HwMf57lJtim7G1gDzbeciTwCoGZnhQqJTqLZHVKdn5qPnmDfVUM9tMetpSMBGPFyBKJ8 vapg== X-Received: by 10.70.31.5 with SMTP id w5mr78259905pdh.3.1435974096620; Fri, 03 Jul 2015 18:41:36 -0700 (PDT) Received: from [10.0.0.16] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by mx.google.com with ESMTPSA id j4sm10368375pdg.64.2015.07.03.18.41.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Jul 2015 18:41:35 -0700 (PDT) From: Michael Koster Content-Type: multipart/alternative; boundary="Apple-Mail=_398B95DF-7D1B-4954-ABD0-6A6846637FF1" Message-Id: Date: Fri, 3 Jul 2015 18:41:31 -0700 To: "core@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [core] CoRE link-format href relation duplication? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 01:41:38 -0000 --Apple-Mail=_398B95DF-7D1B-4954-ABD0-6A6846637FF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, I can=92t find where we prohibit link-format collections from having = duplicate href values as per the following example: ;ep=3D1;dim=3D8;gt=3D50;lt=3D42.2, ;ep=3D2;dim=3D8;pmax=3D300;gt=3D80;lt=3D75.5 What happens if, for example, an endpoint creates these two links in = it=92s .well-known/core resource or registers these two links in a = resource directory?=20 Michael= --Apple-Mail=_398B95DF-7D1B-4954-ABD0-6A6846637FF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi,

I can=92t find = where we prohibit link-format collections from having duplicate href = values as per the following example:

</3/0/7>;ep=3D1;dim=3D8;gt=3D50;lt=3D=
42.2,
</3/0/7>;ep=3D2;dim=3D8;pmax=3D300;gt=3D80;lt=3D75.5
What happens if, for example, an endpoint creates these two links in = it=92s .well-known/core resource or registers these two links in a = resource = directory? 

Michael
= --Apple-Mail=_398B95DF-7D1B-4954-ABD0-6A6846637FF1-- From nobody Fri Jul 3 21:53:50 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084741A0439 for ; Fri, 3 Jul 2015 21:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 Ylh9Dn3x9LLI for ; Fri, 3 Jul 2015 21:53: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 785951A0423 for ; Fri, 3 Jul 2015 21:53: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 [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t644rf9b017181; Sat, 4 Jul 2015 06:53:41 +0200 (CEST) Received: from alma.local (p5DC7EA60.dip0.t-ipconnect.de [93.199.234.96]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mNgm52zFMz3H7D; Sat, 4 Jul 2015 06:53:41 +0200 (CEST) Message-ID: <559766D3.2020902@tzi.org> Date: Sat, 04 Jul 2015 06:53:39 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Michael Koster References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org" Subject: Re: [core] CoRE link-format href relation duplication? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 04:53:49 -0000 Right. Generally speaking, multiple links can have the same href. That is the reason links-json is not a map from href values to attributes, but an array of objects where href is treated as if it were another attribute. Now the specific example has a problem because the attributes there are meant to have a single value per resource. But that is a property of the attribute. The below would not exhibit this problem: ;ep=1;dim=8, ;pmax=300;gt=80;lt=75.5 Grüße, Carsten Michael Koster wrote: > Hi, > > I can’t find where we prohibit link-format collections from having > duplicate href values as per the following example: > > |;ep=1;dim=8;gt=50;lt=42.2, > ;ep=2;dim=8;pmax=300;gt=80;lt=75.5| > > What happens if, for example, an endpoint creates these two links in > it’s .well-known/core resource or registers these two links in a > resource directory? > > Michael > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sat Jul 4 10:28:37 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CE01B29B4 for ; Sat, 4 Jul 2015 10:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=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 yGOPEbgjA9ev for ; Sat, 4 Jul 2015 10:28:34 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (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 A3B781B29B2 for ; Sat, 4 Jul 2015 10:28:34 -0700 (PDT) Received: by pdjd13 with SMTP id d13so81139242pdj.0 for ; Sat, 04 Jul 2015 10:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+4uQuVBSjmLQ/OmNgVKil4MGvoAz679mf1CVavs+W2s=; b=NpJXTSTXlSaZr+EUAIcFX/FM1xkSB69JKeEgsNHjkaeLFTuSShGFWNU4f6P+CfvT2a nZu4lPm+VR8Gs8pusD5zRRZuiNEhPRSLs8MJ6SoPPJya2RMiNaXdgenmRoVEPx/M/Z+z F5EsdNTaZS8i/fZrBipGvF0uy8IghA40O9XOO628Qfxo5WtQLNACwDOYXwvVdDjRYUso Plg04X/NqP9sgnjnDPaDlJoGViUmKQbxrOqAwBgJAN1wNmvt5CBreVuNrhV5TPJUZOsX 2FIkNfWC2GI+Tw0enLBDT4e7pBnbgcj/Lpm562rswWnfKbpvcsn6eE/ExbB3yvMdFDS6 YXPw== X-Received: by 10.66.121.101 with SMTP id lj5mr87733031pab.113.1436030914371; Sat, 04 Jul 2015 10:28:34 -0700 (PDT) Received: from [10.0.0.16] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by mx.google.com with ESMTPSA id fk4sm12840266pbb.80.2015.07.04.10.28.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Jul 2015 10:28:33 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Koster In-Reply-To: <559766D3.2020902@tzi.org> Date: Sat, 4 Jul 2015 10:28:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <03A2EF83-4F27-4973-ABFC-9EA8D75D2B31@gmail.com> References: <559766D3.2020902@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "core@ietf.org" Subject: Re: [core] CoRE Interfaces update: CoRE link-format href relation duplication? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 17:28:36 -0000 Thanks, that=92s what I would expect.=20 The example, from LWM2M, is meant to provide for discovery of multiple = observers on a resource, each with different notification attributes. = This is an example of multiple values for an attribute of a given = resource.=20 ;ep=3D1;dim=3D8;gt=3D50;lt=3D42.2, ;ep=3D2;dim=3D8;pmax=3D300;gt=3D80;lt=3D75.5 In this example, there re 2 LWM2M servers (as CoAP clients) observing = the resource. ep=3D1 means "short server ID =93 and ep=3D2 is for short = server ID 2 To interpret this, I need to group href and ep as a tuple and associate = the following relations with each tuple of (href, ep). This seems = strange to me and I=92d like to think of a better way.=20 On a related subject, I=92m updating the CoRE Interfaces draft, and in = particular cleaning up the specification around binding attributes in = 4.1 and resource observation attributes in 5.9 (pmin, pmax,lt, gt, st). = In section 5.9 it states that the query parameters MUST be treated as = resources that are read using GET and set using PUT. I am proposing to add GET link-format to the function set of observable = interfaces for reading the attributes back from a resource. But this = introduces a question when there is more than one CoAP client observing = a resource and each is allowed to set the attributes. Should we = constrain to just one set of attributes per resource and define some = rules for what happens when multiple clients set attributes differently? = Or should we try to provide for multiple sets of attributes to be = concurrently active. If so, should we provide a discovery or read = method? Michael On Jul 3, 2015, at 9:53 PM, Carsten Bormann wrote: > Right. Generally speaking, multiple links can have the same href. = That > is the reason links-json is not a map from href values to attributes, > but an array of objects where href is treated as if it were another > attribute. >=20 > Now the specific example has a problem because the attributes there = are > meant to have a single value per resource. But that is a property of > the attribute. The below would not exhibit this problem: >=20 > ;ep=3D1;dim=3D8, > ;pmax=3D300;gt=3D80;lt=3D75.5 >=20 > Gr=FC=DFe, Carsten >=20 >=20 > Michael Koster wrote: >> Hi, >>=20 >> I can=92t find where we prohibit link-format collections from having >> duplicate href values as per the following example: >>=20 >> |;ep=3D1;dim=3D8;gt=3D50;lt=3D42.2, >> ;ep=3D2;dim=3D8;pmax=3D300;gt=3D80;lt=3D75.5| >>=20 >> What happens if, for example, an endpoint creates these two links in >> it=92s .well-known/core resource or registers these two links in a >> resource directory?=20 >>=20 >> Michael >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From nobody Sun Jul 5 07:16:50 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CB51A898B for ; Sun, 5 Jul 2015 07:16:50 -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=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJAuCv1UuqUE for ; Sun, 5 Jul 2015 07:16:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6791E1A8989 for ; Sun, 5 Jul 2015 07:16:48 -0700 (PDT) Received: from [192.168.131.129] ([195.149.223.251]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MIuft-1Z9GoW3Imv-002Tb6 for ; Sun, 05 Jul 2015 16:16:46 +0200 Message-ID: <55993C2F.1030109@gmx.net> Date: Sun, 05 Jul 2015 16:16:15 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "core@ietf.org WG" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Tt36mMh467jwtvJEbtgWXGBm1ofNdjUGq" X-Provags-ID: V03:K0:3XqNNeqkCioBv4LGePKIiSCcNjiiQUl713Z1b7X7FsCS8itEWvB hXlnd7znZOS1MtSDqoLQ40oPibmJoVNjZBo7YjAhdjCMBHibobCmgVV2JxbSW00nPB8h/Rf QgEgoo5ftAll0frGKe+kgeCZABZH9zxkoFCafUabWh/MnMeIi+z7T570RAlhvWtzAzEAKFK UTm5fs6dtvt2whc1jjZLQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Q88tWsGJumI=:1GR5twwIWobD/VveCQ01qO DuYIDV/LHipWjmj8vOqHGHzddKXz9gUKwjaPfwcdTyYg6rcX27iEvMkuPxe2JoPpeAoeW9tFz QXXrSultxCBm6NFzv9VDPErv1bZBh+v6T3ndXJFul+4Lm9+k408ru3m5pEJAix3XQnVJ2RTzl YF78puAyn2vXMuJvThtLbf/qxfA3P97N6DXVEpCn7DtJRF/jScU3oBnDUwVWQBWGtx9qmMLYz xFpN+rD8i9wjkFc4yCrtG5fOofL4PhekP6o7+CKq1hgobex1s1qJxKfYc6uiUKWTCo46+kUeX nY59Nq8xmK7Wbex+89VZQnr5O5aYWmZE08yL2gPuNH1ZVAhZK/z00aHOcyP8IKNJNqhbuUvmR WBDhTjfV9T7oJ/GtLoFKm338Gw2yWd4Vnm2bvFTmwFaVgKT0D7dJ+QW58v4AlpAIo6P22Jkqg HpamlSdIXzRuaG4yWjeeswfKVWYnrQEtmHPv42GAeb+gc1SssCc7w11UEVQ2LJ6PJdyGQKpjc C/EZzP22951uK+C7QZzDbrsibtfru/LQv0s2tnQYtlHINLjq2uv5YLeLRDDcnaQ3l4bOCeA7f SG5rtoKlzkegP349Kkw5OY1MYzlPiFPWNVd/KMt8lVdyGuxdpFMzHgkzZ8IONtyL+4tuQbNut RFPrsr2J0htWYg/WEfhnN5yzSlTMcv4AR9/jGIvdZOk6Thw== Archived-At: Subject: [core] IETF#92 Meeting Minutes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 14:16:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Tt36mMh467jwtvJEbtgWXGBm1ofNdjUGq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, Hi Andrew, In an attempt to update the draft I wanted to take a look at the meeting minutes from the discussion we had at IETF 92 (Dallas meeting) but I failed to find the meeting minutes. Am I already too confused to find them or have no meeting minutes been uploaded? Ciao Hannes --Tt36mMh467jwtvJEbtgWXGBm1ofNdjUGq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVmTwwAAoJEGhJURNOOiAtA1oIAITEfm+SaDEE9HzKTdr9z168 Z+qZUiP1AL+AyDCmxfu05RgRvtfveiiN8YIN8hSr7vjU8pqVexHaKvoIbKUkGM6R hFyBnA+j4uLbZ69/sfwX1ZEMFeyKayrXQEXspObYvlHYnElUrUDwqob1k6I0OsgF XSAzvT9aDAyHUvOeF7QhPhJ3pCWLVem0Mwx2c3od0sE6aVOuLRX8BIDuaILAB6qq SKMF1MwYFfF0Ct+Yg/dUgFSPuEVr3Y6M4SVkljNGq07v/rSnd4TFAHJJzs2GbBca LRjUwHxZ4CghBquESA80OvXHFR78jrQCxab2R0VE3lC05MpZJ7gFtnC6apn3sk4= =c5VZ -----END PGP SIGNATURE----- --Tt36mMh467jwtvJEbtgWXGBm1ofNdjUGq-- From nobody Sun Jul 5 08:24:17 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2971A8F4B for ; Sun, 5 Jul 2015 08:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.513 X-Spam-Level: X-Spam-Status: No, score=0.513 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665, WEIRD_PORT=0.001] autolearn=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 idaokK3w6kqN for ; Sun, 5 Jul 2015 08:24:15 -0700 (PDT) Received: from smtp-in1.interdigital.com (host-64-47-120-121.masergy.com [64.47.120.121]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0401A8F39 for ; Sun, 5 Jul 2015 08:24:15 -0700 (PDT) X-ASG-Debug-ID: 1436109853-06daaa10bb149980001-aa7cYp Received: from NISSONITE.InterDigital.com (nissonite.interdigital.com [10.2.64.252]) by smtp-in1.interdigital.com with ESMTP id 32uFIm69YbjKQ1nY (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Sun, 05 Jul 2015 11:24:13 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NISSONITE.InterDigital.com ([::1]) with mapi id 14.03.0210.002; Sun, 5 Jul 2015 11:24:15 -0400 From: "Rahman, Akbar" To: Hannes Tschofenig , "core@ietf.org WG" Thread-Topic: [core] IETF#92 Meeting Minutes X-ASG-Orig-Subj: RE: [core] IETF#92 Meeting Minutes Thread-Index: AQHQty1OpuEKeqjdk0GnFZHn4uohQZ3M/qVg Date: Sun, 5 Jul 2015 15:24:15 +0000 Message-ID: <36F5869FE31AB24485E5E3222C288E1F22E05C99@NABESITE.InterDigital.com> References: <55993C2F.1030109@gmx.net> In-Reply-To: <55993C2F.1030109@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.247.79] x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: nissonite.interdigital.com[10.2.64.252] X-Barracuda-Start-Time: 1436109853 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=WEIRD_PORT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.20475 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 WEIRD_PORT URI: Uses non-standard port number for HTTP Archived-At: Subject: Re: [core] IETF#92 Meeting Minutes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 15:24:16 -0000 Hi Hannes, The raw minutes can be found at http://etherpad.tools.ietf.org:9000/p/notes-ietf-92-core?useMonospaceFont= =3Dtrue /Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, July 05, 2015 10:16 AM To: core@ietf.org WG Subject: [core] IETF#92 Meeting Minutes Hi Carsten, Hi Andrew, In an attempt to update the draft I wanted to take a look at th= e meeting minutes from the discussion we had at IETF 92 (Dallas meeting) but I failed to find the meeting minutes. Am I already too confused to find them or have no meeting minutes been uplo= aded? Ciao Hannes From nobody Sun Jul 5 08:36:49 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74A01A9103 for ; Sun, 5 Jul 2015 08:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, WEIRD_PORT=0.001] autolearn=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 Jr8SzvIiwqIQ for ; Sun, 5 Jul 2015 08:36: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 F23871A9104 for ; Sun, 5 Jul 2015 08:36: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 t65Fag8s011821; Sun, 5 Jul 2015 17:36:42 +0200 (CEST) Received: from alma.local (p5DC7EA60.dip0.t-ipconnect.de [93.199.234.96]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mPYzZ0mPhz3GDX; Sun, 5 Jul 2015 17:36:42 +0200 (CEST) Message-ID: <55994F08.8060509@tzi.org> Date: Sun, 05 Jul 2015 17:36:40 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: "Rahman, Akbar" References: <55993C2F.1030109@gmx.net> <36F5869FE31AB24485E5E3222C288E1F22E05C99@NABESITE.InterDigital.com> In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F22E05C99@NABESITE.InterDigital.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] IETF#92 Meeting Minutes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 15:36:49 -0000 Rahman, Akbar wrote: > Hi Hannes, > > The raw minutes can be found at > > http://etherpad.tools.ietf.org:9000/p/notes-ietf-92-core?useMonospaceFont=true Indeed, and my usual plan is to review those based on the audio recordings and submit the result. For some reason, the audio recordings for the second slot only became available on May 12, just after I had left for an extended period of traveling. As a result, the review (and thus the submission) never happened. Mea culpa. (And, yes, I also need the minutes to prepare for Prague. Ouch. It takes a chunk of real time to do the review, which I won't have before Tuesday.) Grüße, Carsten From nobody Mon Jul 6 02:48:49 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484EC1AC408 for ; Mon, 6 Jul 2015 02:48:48 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr94uSmEOm0r for ; Mon, 6 Jul 2015 02:48:45 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955111AC405 for ; Mon, 6 Jul 2015 02:48:43 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.207]) by smtp-cloud2.xs4all.net with ESMTP id oxog1q00U4U4Moq01xogWl; Mon, 06 Jul 2015 11:48:41 +0200 Received: from [2001:983:a264:1:d44e:be6c:37f2:ccaa] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 06 Jul 2015 11:48:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 06 Jul 2015 11:48:40 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20150706080246.9568.50189.idtracker@ietfa.amsl.com> References: <20150706080246.9568.50189.idtracker@ietfa.amsl.com> Message-ID: <27d0f38ee28c57c511f0afd0eb82bc8d@xs4all.nl> X-Sender: stokcons@xs4all.nl (PtTq5MdjE9rZK7a12snNV1DiTQ/Ltgob) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-patch-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 09:48:48 -0000 Hi all, We submitted a new version of the patch draft. Example has been added, content formats have been specified (needs more work), caching has been reviewed. error handling is improved. Discussion on idem potency and atomicity is still needed. Peter A new version of I-D, draft-vanderstok-core-patch-01.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-core-patch Revision: 01 Title: Patch Method for Constrained Application Protocol (CoAP) Document date: 2015-07-06 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-vanderstok-core-patch-01.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-core-patch/ Htmlized: https://tools.ietf.org/html/draft-vanderstok-core-patch-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-patch-01 Abstract: The existing Constrained Application Protocol (CoAP) PUT method only allows a complete replacement of a resource. This does not permit applications to perform partial resource modifications. In case of resources with larger or complex data, or in situations where a resource continuity is required, replacing a resource is not an option. Several applications using CoAP will need to perform partial resource modifications. This proposal adds a new CoAP method, PATCH, to modify an existing CoAP resource partially. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Jul 6 02:51:57 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F8F1AC418 for ; Mon, 6 Jul 2015 02:51:54 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4ZssakbevDM for ; Mon, 6 Jul 2015 02:51:53 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9DD1AC41B for ; Mon, 6 Jul 2015 02:51:52 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.207]) by smtp-cloud2.xs4all.net with ESMTP id oxrp1q00Q4U4Moq01xrpBJ; Mon, 06 Jul 2015 11:51:49 +0200 Received: from [2001:983:a264:1:d44e:be6c:37f2:ccaa] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 06 Jul 2015 11:51:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 06 Jul 2015 11:51:49 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20150706072338.13421.52989.idtracker@ietfa.amsl.com> References: <20150706072338.13421.52989.idtracker@ietfa.amsl.com> Message-ID: X-Sender: stokcons@xs4all.nl (JdSuvtUTC4XUDZQyvOy2YWzjNwpJiCRi) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] Fwd: New Version Notification for draft-vanderstok-core-comi-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 09:51:55 -0000 Hi all, we have submitted a new comi draft. Many improvements and modifications have been applied. Much discussed change is the extension to different resource name numbering schemes. Peter A new version of I-D, draft-vanderstok-core-comi-07.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-core-comi Revision: 07 Title: CoAP Management Interface Document date: 2015-07-05 Group: Individual Submission Pages: 60 URL: https://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-07.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ Htmlized: https://tools.ietf.org/html/draft-vanderstok-core-comi-07 Diff: https://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-comi-07 Abstract: This document describes a network management interface for constrained devices, called CoMI. CoMI is an adaptation of the RESTCONF protocol for use in constrained devices and networks. It is designed to reduce the message sizes, server code size, and application development complexity. The Constrained Application Protocol (CoAP) is used to access management data resources specified in YANG, or SMIv2 converted to YANG. The payload of the CoMI message is encoded in Concise Binary Object Representation (CBOR). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Jul 6 07:03:41 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E781A87A8 for ; Mon, 6 Jul 2015 07:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.736 X-Spam-Level: * X-Spam-Status: No, score=1.736 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_TR=0.935, HTML_MESSAGE=0.001] autolearn=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 CPT1SvTrg0rK for ; Mon, 6 Jul 2015 07:03:39 -0700 (PDT) Received: from mail.adanabtu.edu.tr (mail.adanabtu.edu.tr [193.140.97.12]) by ietfa.amsl.com (Postfix) with ESMTP id B56A81A21B5 for ; Mon, 6 Jul 2015 07:03:38 -0700 (PDT) X-MDAV-Result: clean X-MDAV-Processed: mail.adanabtu.edu.tr, Mon, 06 Jul 2015 17:04:27 +0300 Received: from WorldClient by mail.adanabtu.edu.tr (MDaemon PRO v14.0.4) with ESMTP id md50000575004.msg for ; Mon, 06 Jul 2015 17:04:25 +0300 X-Spam-Processed: mail.adanabtu.edu.tr, Mon, 06 Jul 2015 17:04:25 +0300 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: akdemir@adanabtu.edu.tr X-Return-Path: akdemir@adanabtu.edu.tr X-Envelope-From: akdemir@adanabtu.edu.tr X-MDaemon-Deliver-To: core@ietf.org Received: by adanabtu.edu.tr via WorldClient with HTTP; Mon, 06 Jul 2015 17:04:21 +0300 Date: Mon, 06 Jul 2015 17:04:21 +0300 From: "Alper Kamil Demir" To: core@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0706-1404-21-03-PART_BREAK" Message-ID: X-Mailer: WorldClient 14.0.4 Archived-At: Subject: [core] A Research on Setting Transmission Parameters Configured to Values Specific to the Application Environment X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:03:40 -0000 --0706-1404-21-03-PART_BREAK Content-Type: text/plain; charset="us-ascii" Is there any research paper on setting CoAP transmission parameters (Chapter 4.8) configured to values specific to the application environment? Because RFC7252 states that: The values for ACK_TIMEOUT, ACK_RANDOM_FACTOR, MAX_RETRANSMIT, NSTART, DEFAULT_LEISURE (Section 8.2), and PROBING_RATE may be configured to values specific to the application environment (including dynamically adjusted values); however, the configuration method is out of scope of this document. Best regards, Alper K. Demir --0706-1404-21-03-PART_BREAK Content-Type: text/html; charset="us-ascii"
Is there any research paper on setting CoAP transmission parameters (Chapter 4.8) configured to values specific to the application environment? 
 
Because RFC7252 states that:
The values for ACK_TIMEOUT, ACK_RANDOM_FACTOR, MAX_RETRANSMIT,
   NSTART, DEFAULT_LEISURE (Section 8.2), and 
PROBING_RATE may be
   configured to values specific to the application environment
   (including dynamically adjusted values); however, the configuration
   method is out of scope of this document.
 
Best regards,
Alper K. Demir
--0706-1404-21-03-PART_BREAK-- From nobody Mon Jul 6 07:33:36 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA101A88C2 for ; Mon, 6 Jul 2015 07:33:34 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUPpyLjXFp99 for ; Mon, 6 Jul 2015 07:33:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA69A1A88C3 for ; Mon, 6 Jul 2015 07:33:19 -0700 (PDT) Received: from [192.168.131.129] ([195.149.223.251]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MGip3-1ZGoHc28wL-00DVbH; Mon, 06 Jul 2015 16:33:17 +0200 Message-ID: <559A91AA.3080304@gmx.net> Date: Mon, 06 Jul 2015 16:33:14 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Carsten Bormann , "Rahman, Akbar" References: <55993C2F.1030109@gmx.net> <36F5869FE31AB24485E5E3222C288E1F22E05C99@NABESITE.InterDigital.com> <55994F08.8060509@tzi.org> In-Reply-To: <55994F08.8060509@tzi.org> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="V5Bsv7e50PIgTmshUHpEjj14Ra1o0VVa1" X-Provags-ID: V03:K0:vCHMr04QZkqL2BGiySuyAKkoY25xnkpvU5ylfcSy40Ps6TDKtwo a+gMhmtyVtcPKy4q3bPNomviHm9GkpewH5x7Ptzh5dRV+R9g51yTFUZ++GXHeVeXflg1kz7 mswj9ZT4XMEVIBL2aGmx2uxtBos41dXhhvX91DDy9Q1AnPwa+dW87rPNPRn/4TXhHVaz0DR npXo8lzyY6WeMppWjvNKQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:hg7DW70Kb4c=:74KxvpqltMG6eTzOqLkwwF bv8TgTZavvPPr5caiovSQwJKE8ownsIWIx/qUAVaib1bQEuqmVkazdNhchzwDca5CAGDH7MH/ HttLfgXZXzhps8I9uaRMi8D3ZnBKLfoh8UHn4CXMXlg10+6A55pYVZEohHrGK9981r5Iq013p DBphMsQcA3bxaNUPK5T8JkuKscre8cHQXPJlQeMzeVBE8X70YAATAraDmLQRybClnzhp191qZ yvRoAsuM1Pa5I4yYlBLQ/PsZ/p4g7MoBE2WUws5BKhj2iQhWEvTa0B0Zu7dMn7qIfQxnfQQeh RRDM2WbjNEE+2H4YoOUa7rXibb9X+cBlksj4g2zuReregECNdvYc+/TjS5R7YhVquj43HjeQF 3KUSPJc/tuSRcRSbeK4oEpYB99OyMC1QS0QTMKskdxpwnkXCq8BgEov54emPXTc/hZw76afsG u/iZvE9A+56yOhnzSx/1SI5EOLGs/VZSbe0x/5zehTksc0n9Q+CepDw1sclAo62wu0sQIVvSq 7Al04mx+6FO+vl8SQofhdVqL6UXHzRVTP8SQHbcSJTKR3apf+gx56W3lhUTmwM88UOE5C43mj 5QvGVQXrlMUnOYgK9BUFTr418lFDu5pSMj6yN/g4afPYP3rShNI4tfDs7fs/gbtZAB68oRWxf kaZJSkPo1DgG+S6wLPHWze4fB8vO6SOZtZLw6ZZ9WFfbD5g== Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] IETF#92 Meeting Minutes X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:33:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V5Bsv7e50PIgTmshUHpEjj14Ra1o0VVa1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for the link. That was helpful. Ciao Hannes On 07/05/2015 05:36 PM, Carsten Bormann wrote: > Rahman, Akbar wrote: >> Hi Hannes, >> >> The raw minutes can be found at >> >> http://etherpad.tools.ietf.org:9000/p/notes-ietf-92-core?useMonospaceF= ont=3Dtrue >=20 > Indeed, and my usual plan is to review those based on the audio > recordings and submit the result. For some reason, the audio recording= s > for the second slot only became available on May 12, just after I had > left for an extended period of traveling. As a result, the review (and= > thus the submission) never happened. Mea culpa. >=20 > (And, yes, I also need the minutes to prepare for Prague. Ouch. It > takes a chunk of real time to do the review, which I won't have before > Tuesday.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 --V5Bsv7e50PIgTmshUHpEjj14Ra1o0VVa1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVmpGqAAoJEGhJURNOOiAtKgMH+wZyvuaWDVAbGjA3pU21j+vJ dOv/YcJBGw6lKJ2SXYdHl7PbhMlU/oBaUOJUIuiWclynxRbja0MvTvWSrY4Cw6Hk TtHTnZqeX7SLse+4dsGXoqYR7BrOD+k0e8p8AYqXX5hG5P0utU5X82fGI3Bk06C/ hs8W44D+pAXX4EEfR2hK0ZRIFPBWopY7E5U7KZTZAb/z3q8FM6wu0sQHMX/l8aun oGOlaISWrvvdIiDinVlS8XOScRljolEOeUghI7FbgMcdnYTkcwgG23bf4XtsvAmZ hDL5FxsfARllOijFOZJfDRWBmV0APqtwUgG0ebaqQaFHRX9/DZTFVVveo/svdQU= =30aV -----END PGP SIGNATURE----- --V5Bsv7e50PIgTmshUHpEjj14Ra1o0VVa1-- From nobody Mon Jul 6 07:47:39 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64801B2A81; Mon, 6 Jul 2015 07:47:36 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOxpLfx6qy6z; Mon, 6 Jul 2015 07:47:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1492B1B29F1; Mon, 6 Jul 2015 07:47:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706144729.3572.50770.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 07:47:29 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-interfaces-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 14:47:37 -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 Working Group of the IETF. Title : CoRE Interfaces Authors : Zach Shelby Matthieu Vial Michael Koster Filename : draft-ietf-core-interfaces-03.txt Pages : 27 Date : 2015-07-06 Abstract: This document defines well-known REST interface descriptions for Batch, Sensor, Parameter and Actuator types for use in contrained web servers using the CoRE Link Format. A short reference is provided for each type that can be efficiently included in the interface description attribute of the CoRE Link Format. These descriptions are intended to be for general use in resource designs or for inclusion in more specific interface profiles. In addition, this document defines the concepts of Function Set and Binding. The former is the basis element to create RESTful profiles and the latter helps the configuration of links between resources located on one or more endpoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-interfaces-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-interfaces-03 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 Jul 6 08:17:51 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2851B2AA5 for ; Mon, 6 Jul 2015 08:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_vPJNzNh9q0 for ; Mon, 6 Jul 2015 08:17:43 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F871A8A20 for ; Mon, 6 Jul 2015 08:17:40 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id F12A8449C7 for ; Mon, 6 Jul 2015 17:17:38 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id C001023F for ; Mon, 6 Jul 2015 17:17:37 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9B0C336E for ; Mon, 6 Jul 2015 17:17:37 +0200 (CEST) Received: (nullmailer pid 14717 invoked by uid 1000); Mon, 06 Jul 2015 15:17:37 -0000 Date: Mon, 6 Jul 2015 17:17:37 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: <20150706151737.GA6467@hephaistos.amsuess.com> References: <20150706144729.3572.50770.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: <20150706144729.3572.50770.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-interfaces-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 15:17:46 -0000 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello core-interfaces authors, I've previously expressed my concern for the consistency of the name resolution in core-interfaces (querying /s gives "n":"light" which should be /s/light, but querying /s/humidity gives "n":"humidity" which should be /s/humidity), and they still apply to the latest draft. Do my suggestions in [1] catch the idea of the draft correctly, let me know and I'll shape them into patches. Best regards Christian Ams=FCss [1] https://www.ietf.org/mail-archive/web/core/current/msg05787.html --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVmpwNAAoJEDmNERLTpL3hYUEP/jYOSqHtOFBafzbuzj+0GbGK /nRM7AnZLojIUfLmHtnJ1LtcTi3ZhA2TLlV8W0hsxtTMOEnKg7HJCqYujtO/ER6a 1mtAJ7vWPq7p6U/gTqWSoe6ytlbIYoQOHQJPOsySWsBnJHzpwAQWiTdYyeYn2nD/ liA26Hhiw0JyH5PpXpeUNAz6PiC3+qYWuTwoaoJdAU2tbak9prjDvNHdQ+xM1hPs LKJIvQOXAExqc4luHipYTHudozXRb/zK92BEEV/bii6hMELvtsNX5CX+j3aWbD7t ukLtxCBBJCop829IPY+wGRZ0XDIgO+cq6tOKW6MrfcE3VW0hLyPY3eRihX9VPvw6 +JgJErZ3I2iNDlyJYSyh8wBpYCH4gsStMC+Umi9t+l1va80TzkZWrAmvDwJIZIUm sU+PCFAhaQ57VjFxRCichf3n/460QEtbhX2beOydRKVR0CFsqX9I7GlsIsuGZlzu BwN/kwkdIsclJ/9Zdd/xBEC7+FlktkzZqwMP5w4nS7qcPSOiOiEjCS2hPKqp79Zo 9iaf1cKJHCEq+XposFVR+IfAf0gVQaCACfp0qJW1RwRaeYzq7ue+WbXxPrBeZc1U 7eXpD4T46QSmAqsnnPJy6CO5uOrNZfLWGFCK0Hm79KdPCxFSGa3Fj5tqsAgImB8F JoVUR4ZARuNrs5LmcAK0 =jKAD -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- From nobody Mon Jul 6 08:28:35 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352D51B2B72; Mon, 6 Jul 2015 08:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 2nbKZIl8SXSf; Mon, 6 Jul 2015 08:28:20 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B391B2B60; Mon, 6 Jul 2015 08:28:03 -0700 (PDT) Received: from mfilter42-d.gandi.net (mfilter42-d.gandi.net [217.70.178.172]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id E0036A815A; Mon, 6 Jul 2015 17:28:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter42-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter42-d.gandi.net (mfilter42-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id wdgOilRnmF7Q; Mon, 6 Jul 2015 17:27:59 +0200 (CEST) X-Originating-IP: 192.44.77.246 Received: from dhcp-salsa-i-129-152.rennes.enst-bretagne.fr (nat-asr-salsa.rennes.enst-bretagne.fr [192.44.77.246]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id AC3A3A80DC; Mon, 6 Jul 2015 17:27:58 +0200 (CEST) From: Alexander Pelov To: core@ietf.org, 6tisch@ietf.org Message-ID: <559A9E7F.7030709@ackl.io> Date: Mon, 6 Jul 2015 17:27:59 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Laurent Toutain , t2trg@irtf.org, Yannick Delibie Subject: [core] Annoncement draft-pelov-core-cosol-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 15:28:25 -0000 Dear all, I'd like to bring to your attention a new document, which was submitted this weekend: draft-pelov-core-cosol-00 It presents a new type of far-reaching, low-rate radio technologies (such as Semtech LoRa and SigFox) and an extensible mechanism to operate these networks based on CoAP. We document the way REST can be used to manage these networks. You can find the current text at the following address: https://tools.ietf.org/html/draft-pelov-core-cosol-00 We would be happy to discuss with anyone interested the contents of the draft and the possible future works on it. Also, we will be glad if there is any possibility to present even briefly during a session. Best, Alexander From nobody Mon Jul 6 10:31:10 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E551A01A9 for ; Mon, 6 Jul 2015 10:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MTXLaVw-dtZ for ; Mon, 6 Jul 2015 10:31:08 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (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 CC19E1A0406 for ; Mon, 6 Jul 2015 10:31:07 -0700 (PDT) Received: by laar3 with SMTP id r3so164695843laa.0 for ; Mon, 06 Jul 2015 10:31:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=qNKOMFmuqiVHYKo55kTOYIkD2za69/M53uznqXDkWHQ=; b=U/Udw+105y2F8GsPTH50sFvVW+ZbUxUgfrKX9OBJrLJ8Cv3KrBr3zjA10XhMcQhw+S yIrfs90XGjAv/kn8yRtrOpYxzYj0lE0dGiFKykCgcldLO1se7EM2fNwJA5uQkw0QHdUu nE20VY89grvJ9JDgzH7vu+mE1aVLsIrMG4xRnm4lMmVjDKcjl/M9F/vFYO48g86w9i3x 9NAmdAbKhgvtI16F7fHnU02Lh0MykLz8pEbXOzLVoi1TbWK3PlTlAyQIg0hgUgqE8RJF TW9mRUqeelnZSny7tkiowTNGCjXurA+AJ6gBQ2+6VSYDZCGpYDPPfJWc7BWBGlfrJ6WO 3DJw== X-Gm-Message-State: ALoCoQn9zavx8w/5u56T/HH2lpPE5X52cbh6Mt0YEz4ISAwYgskUuMVwIBoDOmdwc86/e/9yWr2x MIME-Version: 1.0 X-Received: by 10.112.55.207 with SMTP id u15mr734lbp.88.1436203866268; Mon, 06 Jul 2015 10:31:06 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 6 Jul 2015 10:31:06 -0700 (PDT) Date: Mon, 6 Jul 2015 10:31:06 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" , Core Content-Type: multipart/alternative; boundary=001a113403d8463ea6051a3845c3 Archived-At: Subject: [core] YANG Packages draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 17:31:09 -0000 --001a113403d8463ea6051a3845c3 Content-Type: text/plain; charset=UTF-8 Hi, I submitted a new draft for defining YANG packages. http://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt IMO this could be useful for organizing YANG modules. It may also be applicable for CoMI, by allowing a tiny number of packages to be advertised to the client, instead of a relatively large number of modules. Andy --001a113403d8463ea6051a3845c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I submitted a new draft for definin= g YANG packages.


IMO this c= ould be useful for organizing YANG modules.
It may also be applic= able for CoMI, by allowing
a tiny number of packages to be advert= ised to the client,
instead of a relatively large number of modul= es.



Andy
<= br>
--001a113403d8463ea6051a3845c3-- From nobody Mon Jul 6 13:11:12 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26971ACE2B for ; Mon, 6 Jul 2015 13:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mewhQei3dEZs for ; Mon, 6 Jul 2015 13:11:09 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0734.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FA51ACDF0 for ; Mon, 6 Jul 2015 13:11:09 -0700 (PDT) Received: from DBXPR04CA0052.eurprd04.prod.outlook.com (10.141.8.180) by VI1PR04MB1472.eurprd04.prod.outlook.com (10.163.166.152) with Microsoft SMTP Server (TLS) id 15.1.207.19; Mon, 6 Jul 2015 20:10:51 +0000 Received: from DB3FFO11FD033.protection.gbl (2a01:111:f400:7e04::130) by DBXPR04CA0052.outlook.office365.com (2a01:111:e400:9414::52) with Microsoft SMTP Server (TLS) id 15.1.207.19 via Frontend Transport; Mon, 6 Jul 2015 20:10:52 +0000 Authentication-Results: spf=none (sender IP is 206.191.242.36) smtp.mailfrom=philips.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from mail.philips.com (206.191.242.36) by DB3FFO11FD033.mail.protection.outlook.com (10.47.217.64) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Mon, 6 Jul 2015 20:10:49 +0000 Received: from AMSPRD9002MB029.MGDPHG.emi.philips.com ([169.254.4.124]) by AMSPRD9002HT003.MGDPHG.emi.philips.com ([141.251.32.208]) with mapi id 14.16.0488.000; Mon, 6 Jul 2015 20:10:48 +0000 From: "Zotti, Teresa" To: "core@ietf.org" Thread-Topic: New Version Notification for draft-zotti-core-sleepy-nodes-03.txt Thread-Index: AQHQuBEgv6NW8Mr1lkOCAC208JCXtZ3O2LhQ Date: Mon, 6 Jul 2015 20:10:47 +0000 Message-ID: References: <20150706172802.9191.26641.idtracker@ietfa.amsl.com> In-Reply-To: <20150706172802.9191.26641.idtracker@ietfa.amsl.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.153.6.32] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD033; 1:wf/nU2rX81XctvXhXV1CdoIS4ftYXCZOtV9oL93ZCJeSgqUm2xzkw4CfHVo4c25zFjQ6yE2GovPSWQSPaMRuOX1A9ty+/ZCgpLjXNeSb8/OKYpzY6L8OmNwyGopWRhQwniyTmgBo4U2RAWxbFhhxcL04Y2lS2VUUOmrxZyAH4obOWUQw6jcHzgtRONFrZHQsXJ3dNZY41YTTgyU8svEE9B37NWzwPfaL+SL1HIHb42AAmxFRDvVHkflSn2mL6YiZDcsYhNZS4Jhf3rVAI1+MLQ== X-Forefront-Antispam-Report: CIP:206.191.242.36; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(428002)(85714005)(199003)(377424004)(374574003)(189002)(71364002)(76176999)(47776003)(33656002)(2351001)(2656002)(87936001)(86362001)(50986999)(5003600100002)(106466001)(77156002)(2900100001)(230783001)(5001960100002)(106116001)(92566002)(6806004)(54356999)(2950100001)(101416001)(107886002)(102836002)(2501003)(104016003)(110136002)(105586002)(19580395003)(5001920100001)(66066001)(189998001)(46102003)(23676002)(62966003)(55846006)(15975445007)(50466002)(567094001)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR04MB1472; H:mail.philips.com; FPR:; SPF:None; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1472; 2:7oogKvVgx+oZe883E17KhGUo+2eN34Zth7Mj96Cc+QPQl+vS5X2COif2yZhcV1OR; 3:92lBo1eAqvQZYpADiQ0dZdQ9WNJojCeB3ORUEqEPO8uwUBb1YPC/0vUTfDX/S8p/ewCD9k0dHyjWxYSvPFJw3XUL/B+jydfo4CsoiWryAUPcwEq59c7ZoAJqgT63jdNWBpRWxZ+vLhfa2vRdm+pbpKtIdyjsFnUYVxy5e7/7Jxhz08QSL+6CcZ7XM/eD2jVhQ5TIP6K8P3OVbIZJw6riRKZUs8nziHRf4C0mJ/OXWKXAy5/qvHpttOuRNU9O2BeU; 25:zU3TYV5BhLFnzIQpn2SN0x0II3ybZKL7rGdWcCKw3SksefxoPaVCKhm59Qk2dQLga/+XSGbgdjjhYh+H3PWF/knjtYeDHVDE4wyeyjq/f+3oTZoBRAuf295l19Z5ET/6hN04Ivfm33m/ZjzFlmH7ij0Yhrpgj7ijLJ2P4fRWbox50ejsO7bJDQaixzhMoFisxvvme7HXQuZCAmsofEU3QrBhLiLpmTGj0L/23JAEHMGtI0GXxSDCkUwxsLAzy/K0Lm8Je79Nj3ifvYAS7q6N3A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR04MB1472; X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1472; 20:pwF0TKpJXRzGCNVPD8JPOG0l3AX8S9c+zGIhTDfZgqgbucmsE8Y8S5P6lO2aBh3jtMinb5OVhcUIlbnejXJIiaBOrKy+w1RxTOOccS/A0Na7sHVjG4LgnVMFHG50qv4e6a4FIRvjU+Fbc1K8O7PyjfHd6dv2QWvA/DfARvRlqUqgtDnzUlDA30UfGAbmuc94Md5invurttRzLP7WvwOGXaW3jjRP6As7izthRR//yRSOJ7w6MfMwu2sMDSuloRVy3uOCWFXhzDjO2hqOtrLTd//QW+40RHS4Kn8oih6KYxQ3Pkgrx9K4MQgtLZVFszbeoDavJAI6tC1Vyk99ZXKQcv/t47EaMkBZHQzKYueJ/axeQn9ZDDWtJ+iqJsbHGDo1cGh5Y7SIh6zU1Gmxcyhj1H7cHxHZJALollRocRI9t/LBHe46goAGgv/s6nugouLX2Kz1aNz+Ib8HhEoDWu5HuzSknl2l7mP5OVBQTeHtBTRbK38umuvb3VtR2INFYy2k; 4:9IVWTuuA0Ptgd6Lh0U/sxU3AaAVABe++8CPA69uSDe9HlgfthMaDkwSBp2Jqnw8eY5Me2DIJ+issluUZfhfZhcLSAgPFSOMAr4xhxUbeBCGuZbrvTQmuYdwogGuO6beltpC31HG2YXqq5OGjEbyv19N4LLvbd74LjTwb26RX+pU+XyPLqpQ82c3yFk6TqxlSeobm6OACIhg0hlmKT9C+mdEEd3oy8l7Xgr9K3tEYMy/fXxU6dwO7EW2BcYh7PjufVv0iWe2kRgDOFJDpWmkzPh1qn0GV9zy5NzisvHDuupk= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:VI1PR04MB1472; BCL:0; PCL:0; RULEID:; SRVR:VI1PR04MB1472; X-Forefront-PRVS: 06290ECA9D X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA0TUIxNDcyOzIzOnBzQ285dTJIcmxmVnFlZEVnT2dQTjBQTnNx?= =?utf-8?B?ZGFXcTZGeUhzamswVzdGN0l5NEhWYTlRd1dOa0tYdUtRTk00SWN2bGNWdURC?= =?utf-8?B?cldqaFZtWlZianNqaGM4MmtWdkhNMGhhVlR5eDhjVlU3Q3Z4VUcrMkZYUHZ4?= =?utf-8?B?eU51SEVpb0hoWWN5R3RqYkZTQlVyWkZUZDcyTTJyenhId1hiTUkzeStHYkpB?= =?utf-8?B?RElTMHV1RDZDOGRKZms0Z1JpNVFVTDhTZjRXVmkxczRsdVFWNG5hYWtGSndC?= =?utf-8?B?dlFuMFRyRHd6b2d3WnNPV1lQOXhCTlQ4WDB4WGJvYWFGbXpkS0d6MmVmUmNF?= =?utf-8?B?Zk5jN2ZhRlJ3cjRyd1gxL0Vtd2d4RkpUa3FXcXNxYjFwWHJQRFJIckxmMTZ5?= =?utf-8?B?V3c3NWNkbzJvOVpRdEluaTcwdGN5RHEvRk9jSkZrN3R0cnkxaVBDUjJqOHZO?= =?utf-8?B?REF1K3NESFNiYmN3UEJybTBnVGpBNnRIdVhaemwvRkoxdzhCNGRYRHUwdWtC?= =?utf-8?B?VTNVbVpIS1ovMG1uM214NG1RR1dGZVlqUHliREtpRkc4QUQzUmdqOVVMc3RH?= =?utf-8?B?RTlmYUNWZXNzWWRRc1NCNWtGNTNpRjhCK0hUWFZtUEtxcmJTK2YwRUJENHZI?= =?utf-8?B?VVMxSlBiUzVIbVUwbWloMXg3eHZwVkFpa2RrMUszdHNXYWd5VFd6bTB3Z0dh?= =?utf-8?B?SU5CdlRKMkZBZTVnSkJjZ3ROdzVoUFFhaTlhTUtRdDQyQUZPaEUvT21vOXdl?= =?utf-8?B?RlNFb3NVQVRTV3hqWTZ3bDlxZ01lcXByWE9NL1cwT3J5K0wzL3Fwd09SQURC?= =?utf-8?B?ODJPZFJESk5sSU4rL3pwbmc0U3J0YkRjOTF5dHNqLzk0SXZGL0Q4RTZoU2dh?= =?utf-8?B?ekFIT3ViMkQrNk8wU2h5L3ZxTXRTR0t6RmFJWkRPNC91bTRDREQ2czNwaE1v?= =?utf-8?B?bHY0M2hJVlN6c29xZzRUd2xYcUZidWZvRXVrWkQ3aFQyUXNHNXltcHU2R2Ni?= =?utf-8?B?anhQb1BFdGxxdWQrWnVoL1doSjdhNkQ5RC9veGtRdmpvcVkyU083YUtoQWI0?= =?utf-8?B?eFpHSWNwZzc3V0FERjEvR1N0bHBWSDNuVE1jdEV5ZEpKemlBWlN1c29xQm5n?= =?utf-8?B?T1BuU01QcWVHVUNsOHNLTWIvM2xqcUl0Q0NPSlVIakhlUS8xNFVJSDV5eWZt?= =?utf-8?B?SGNxSmE0RU0vYlIxMURKM0xxUjhLalNyVzEySFNQTURCcnRLUGpFQk5ZeVpz?= =?utf-8?B?ZzFXRjliZmR3SVdGa2FBZGRYbGlmYWpiSjFjZ0hSeldOZUtPa3A0NGQ4V2hN?= =?utf-8?B?ZW54eGNvRjJHeGR6N3JkUzdmTUE5SVRWclYzaEUzN0N5akR5aUN4TE45KytB?= =?utf-8?B?OHU1NFB0dVEwVGpGV3BZMVBtWmFVS05tcEtLK1dTM0N2VElNbFJyVGZQOStF?= =?utf-8?B?UW1obU0wakJVVmJYTGV3MmxrOVlnamlreVJQcDRzMmNXMmdSZkw5V3NZelZq?= =?utf-8?B?djRjNWZ5eitTVEhHNzBpYzcxN2JGOUJBN0JTK2hCTEdUZGRIdE02UlBmSGg2?= =?utf-8?B?WWc5ZkxKTmZQU3dsQXZQZzdVZlkxVzNJMHFRaW4rOXA2dHM5MVZZUUJsRmpq?= =?utf-8?Q?RIKE9phbe8AYwhqQZvyV?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR04MB1472; 5:utJcG79YNl8+yWCC39COxEO0f74F0YM1aiLofVcQO6kIwIsUS8myUjSKu4cm6SOzxezTCZEvFVgYCgmGtnfuugq8MvKaWJDHNggk2Vu1PqELnuNl0hx36Aov+44gRXL2xBUYBxYDEeVy/7EyOYwk2Q==; 24:ue0j51VMixez+XD8Ow0TYIQrKsNFAn8eV/WgJBy34kTboPgBvOlbceVcO/J9rHl3X9HV7IQeoVILRji47Q8nXAR2sYayA7jP/8gKcImtgrI=; 20:OiEQCdB/mQPPE+lTSKeF8OkfHXUulhA3QQCVXChidf+dbafpNp8zqaA2uusDBHs85BRERUPqNhwsaME8l+OXxw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2015 20:10:49.6121 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[206.191.242.36]; Helo=[mail.philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB1472 Archived-At: Subject: [core] FW: New Version Notification for draft-zotti-core-sleepy-nodes-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 20:11:12 -0000 RGVhciBhbGwsDQoNCkkgd291bGQgbGlrZSB0byBicmluZyB0byB5b3VyIGF0dGVudGlvbiB0aGUg bGF0ZXN0IHZlcnNpb24gb2YgdGhlIFNsZWVweSBOb2RlcyBkcmFmdCBqdXN0IHN1Ym1pdHRlZCAo aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXpvdHRpLWNvcmUtc2xl ZXB5LW5vZGVzLTAzLnR4dCkuDQoNCldpdGggdGhlIHB1cnBvc2Ugb2YgY2xhcmlmeWluZyB0aGUg aW50ZXJhY3Rpb25zIGludm9sdmluZyBTbGVlcHkgTm9kZXMsIHdlIGFkZGVkIGFuIGhpZ2ggbGV2 ZWwgYXJjaGl0ZWN0dXJlIGRlc2NyaXB0aW9uIGFuZCBtb3JlIGV4YW1wbGVzLg0KQSBuZXcgc2Vj dGlvbiBkZXNjcmliZXMgdGhlIHJvbGUgYW5kIGZ1bmN0aW9uYWxpdGllcyBvZiB0aGUgUmVzb3Vy Y2UgRGlyZWN0b3J5IHRvIHN1cHBvcnQgU2xlZXB5IE5vZGVzLg0KDQpXZSBsb29rIGZvcndhcmQg Zm9yIHlvdXIgZmVlZGJhY2suDQoNCktpbmQgUmVnYXJkcywNCg0KVGVyZXNhDQoNCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC16b3R0aS1jb3JlLXNsZWVweS1ub2Rlcy0wMy50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGVyZXNhIFpvdHRpIGFuZCBwb3N0ZWQgdG8g dGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LXpvdHRpLWNvcmUt c2xlZXB5LW5vZGVzDQpSZXZpc2lvbjogICAgICAgMDMNClRpdGxlOiAgICAgICAgICBTbGVlcHkg Q29BUCBOb2Rlcw0KRG9jdW1lbnQgZGF0ZTogIDIwMTUtMDctMDYNCkdyb3VwOiAgICAgICAgICBJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAyNg0KVVJMOiAgICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16b3R0aS1jb3JlLXNs ZWVweS1ub2Rlcy0wMy50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC16b3R0aS1jb3JlLXNsZWVweS1ub2Rlcy8NCkh0bWxpemVkOiAgICAg ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtem90dGktY29yZS1zbGVlcHktbm9k ZXMtMDMNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtem90dGktY29yZS1zbGVlcHktbm9kZXMtMDMNCg0KQWJzdHJhY3Q6DQogICA2TG9XUEFO IG5ldHdvcmtzIHJlbHkgb24gYXBwbGljYXRpb24gcHJvdG9jb2xzIGxpa2UgQ29BUCB0byBlbmFi bGUNCiAgIFJFU1RmdWwgY29tbXVuaWNhdGlvbnMgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRz LiAgTWFueSBvZiB0aGVzZQ0KICAgbmV0d29ya3MgbWFrZSB1c2Ugb2YgIlNsZWVweSBOb2RlcyI6 IGJhdHRlcnkgcG93ZXJlZCBkZXZpY2VzIHRoYXQNCiAgIHN3aXRjaCBvZmYgdGhlaXIgKHJhZGlv KSBpbnRlcmZhY2UgZHVyaW5nIG1vc3Qgb2YgdGhlIHRpbWUgdG8NCiAgIGNvbnNlcnZlIGJhdHRl cnkgZW5lcmd5LiAgQXMgYSByZXN1bHQgb2YgdGhpcywgU2xlZXB5IE5vZGVzIGNhbm5vdCBiZQ0K ICAgcmVhY2hlZCBtb3N0IG9mIHRoZSB0aW1lLiAgVGhpcyBmYWN0IHByZXZlbnRzIHVzaW5nIG5v cm1hbA0KICAgY29tbXVuaWNhdGlvbiBwYXR0ZXJucyBhcyBzcGVjaWZpZWQgaW4gdGhlIENvUkUg Z3JvdXAsIHNpbmNlIHRoZQ0KICAgc2VydmVyLW1vZGVsIGlzIG5vdCBhcHBsaWNhYmxlIHRvIHRo ZXNlIGRldmljZXMuICBUaGlzIGRvY3VtZW50DQogICBkaXNjdXNzZXMgYW5kIHNwZWNpZmllcyBh biBhcmNoaXRlY3R1cmUgdG8gc3VwcG9ydCBTbGVlcHkgTm9kZXMgc3VjaA0KICAgYXMgYmF0dGVy eS1wb3dlcmVkIHNlbnNvcnMgaW4gNkxvV1BBTiBuZXR3b3JrcyB3aXRoIHRoZSBnb2FsIG9mDQog ICBndWlkaW5nIGFuZCBzdGltdWxhdGluZyB0aGUgZGlzY3Vzc2lvbiBvbiBTbGVlcHkgTm9kZXMg c3VwcG9ydCBmb3INCiAgIENvQVAgaW4gdGhlIENvUkUgV0cuDQoNCg0KDQoNClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5k ZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhl IGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91 IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0 aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0 cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= From nobody Mon Jul 6 13:11:31 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7EF1B31A8 for ; Mon, 6 Jul 2015 13:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG0tbOV9JqGM for ; Mon, 6 Jul 2015 13:11:28 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72CA1B31BE for ; Mon, 6 Jul 2015 13:11:22 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-21-559ae0e8d2fd Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id ED.AD.12828.8E0EA955; Mon, 6 Jul 2015 22:11:20 +0200 (CEST) Received: from Aris-MacBook-Pro-2.local (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.210.2; Mon, 6 Jul 2015 22:11:20 +0200 Message-ID: <559AE0E7.1040801@ericsson.com> Date: Mon, 6 Jul 2015 23:11:19 +0300 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: core References: <20150706195700.4435.91426.idtracker@ietfa.amsl.com> In-Reply-To: <20150706195700.4435.91426.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150706195700.4435.91426.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyM+Jvje6LB7NCDdacsrTY93Y9s8WBaRNY HZg8liz5yeTx5fJntgCmKC6blNSczLLUIn27BK6Mg+9+sBRsEqj4caOTuYFxBW8XIweHhICJ xL9H7F2MnECmmMSFe+vZQGwhgaOMElc+13UxcgHZmxklTp3/zwhSzyugLXHsqQlIDYuAisTN rcfB6tkEbCVWv7rJAmKLCqRIPFuymwnE5hUQlDg58wlYXERAQqLz636wXcwCehLvju4Es4UF vCW2X3zECLHXQeLcpJdgcU4BR4kF16+xQtzmI3Hv1llGiF4LiZnzz0PZ8hLb385hhuhVlbj6 7xXjBEahWUhWz0LSMgtJywJG5lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgSF8cMtv3R2M q187HmIU4GBU4uF9sGJmqBBrYllxZe4hRmkOFiVx3hmb80KFBNITS1KzU1MLUovii0pzUosP MTJxcEo1MFrVOU8smMIlvHzPF9/iKy++fOHnqXKQnDi7de22v7/vSDRce6a8xHbbljkfC38/ kkicqHqd9/XlZ6rZrKZzQisnpBXwZzyS6znyqLxgZ0be6d3cS5xrfXVC11dH9Uy6VO3t3NqT svmW9EOTeQlOyVwx8fKP9j1/yer239h1xeLQld/M7hx736nEUpyRaKjFXFScCACQFnRvQgIA AA== Archived-At: Cc: draft-jennings-core-senml@tools.ietf.org Subject: [core] Fwd: New Version Notification for draft-jennings-core-senml-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 20:11:30 -0000 Hi all, We have now submitted an updated version of the SenML draft (see the announcement below). The main changes from previous revision: - Added CBOR representation format (thanks Carsten!) - Added recommendation for the order of the JSON attributes - Added text how the JSON format can be used in a stream-like fashion - Removed 'minOccurs="0"' from XML schema (is not allowed in attributes) - Lots of smaller editorial fixes and changes Comments and reviews are welcome. Cheers, Ari -------- Forwarded Message -------- Subject: New Version Notification for draft-jennings-core-senml-01.txt Date: Mon, 6 Jul 2015 12:57:00 -0700 From: internet-drafts@ietf.org A new version of I-D, draft-jennings-core-senml-01.txt has been successfully submitted by Ari Keranen and posted to the IETF repository. Name: draft-jennings-core-senml Revision: 01 Title: Media Types for Sensor Markup Language (SENML) Document date: 2015-07-06 Group: Individual Submission Pages: 26 URL: https://www.ietf.org/internet-drafts/draft-jennings-core-senml-01.txt Status: https://datatracker.ietf.org/doc/draft-jennings-core-senml/ Htmlized: https://tools.ietf.org/html/draft-jennings-core-senml-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-jennings-core-senml-01 Abstract: This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Markup Language (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. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Jul 6 14:01:14 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5AB1B3265; Mon, 6 Jul 2015 14:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLF7tC633qqj; Mon, 6 Jul 2015 14:01:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8251C1B3275; Mon, 6 Jul 2015 14:01:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706210110.15618.8966.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 14:01:10 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-links-json-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 21:01:12 -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 Working Group of the IETF. Title : Representing CoRE Formats in JSON and CBOR Authors : Kepeng LI Akbar Rahman Carsten Bormann Filename : draft-ietf-core-links-json-03.txt Pages : 17 Date : 2015-07-06 Abstract: JavaScript Object Notation, JSON (RFC7159) is a text-based data format which is popular for Web based data exchange. Concise Binary Object Representation, CBOR (RFC7049) is a binary data format which has been optimized for data exchange for the Internet of Things (IoT). For many IoT scenarios, CBOR formats will be preferred since it can help decrease transmission payload sizes as well as implementation code sizes compared to other data formats. Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (RFC6690). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON, and similarly, inside constrained environments, in CBOR. This specification defines a common format for this. Group Communication for the Constrained Application Protocol (RFC7390) defines a number of JSON formats for controlling communication between groups of nodes employing the Constrained Application Protocol (CoAP). In a similar vein, this specification defines CBOR variants of these formats. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-links-json/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-links-json-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-links-json-03 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 Jul 6 14:14:08 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113B21A00E8 for ; Mon, 6 Jul 2015 14:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eM9Nxd-caepO for ; Mon, 6 Jul 2015 14:14:04 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946431A0027 for ; Mon, 6 Jul 2015 14:14:03 -0700 (PDT) X-AuditID: c1b4fb25-f79046d000007f53-61-559aef99e6ae Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 1F.53.32595.99FEA955; Mon, 6 Jul 2015 23:14:01 +0200 (CEST) Received: from Aris-MacBook-Pro-2.local (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.210.2; Mon, 6 Jul 2015 23:14:01 +0200 Message-ID: <559AEF98.8020501@ericsson.com> Date: Tue, 7 Jul 2015 00:14:00 +0300 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: core Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3Rnfm+1mhBo3TLCz2vV3PbHFg2gRW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvj2cZNbAXb+SumdP5lbmCcytXFyMkhIWAi 8arnOzOELSZx4d56NhBbSOAoo8STKZZdjFxA9mZGiWmPV7GDJHgFtCVaVr5nBLFZBFQkFpye wwpiswnYSqx+dZMFxBYVSJF4tmQ3E0S9oMTJmU/A4iICEhKdX/eDzWEW0JN4d3QnmC0soCSx 4dUkZoi4hcTM+ecZIWx5ie1v5zBDHKQqcfXfK8YJjPyzkIydhaRlFpKWBYzMqxhFi1OLk3LT jYz1Uosyk4uL8/P08lJLNjECw+/glt+qOxgvv3E8xCjAwajEw/tgxcxQIdbEsuLK3EOM0hws SuK8MzbnhQoJpCeWpGanphakFsUXleakFh9iZOLglGpglD2kuVvry7+fvLXp96bL16eweh+6 8qziQot+Uo/OjeK3W4S2ha6ymRzYaqq+KWjGdk1ObbmKJdqFel8K+l88dd+c0Hxk3WOJw/Yx Wy+tPvy26ppGzVL1RUy2yulvdggnzXlxrTLvbGfi+emTVadFuNZMY1xV8SR2xQmuGVYXZ7jf KL3weemTs0osxRmJhlrMRcWJAJ7JlU0gAgAA Archived-At: Cc: draft-jennings-core-senml@tools.ietf.org Subject: [core] Nested elements for SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 21:14:06 -0000 Hi all, One of the main open issues with the SenML draft is whether we should add support for nested elements and inheriting values. Currently, if one wants to send e.g. multiple current and voltage values, something like this is done: {"bn": "urn:dev:mac:0024befffe804ff1/", "bt": 1276020076, "bu": "A", "e":[ { "n": "voltage", "t": -5, "u": "V", "v": 120.1 }, { "n": "voltage", "t": -3, "u": "V", "v": 120.4 }, { "n": "voltage", "t": -1, "u": "V", "v": 120.5 }, { "n": "voltage", "t": 0, "u": "V", "v": 120.1 }, { "n": "current", "t": -4, "v": 1.30 }, { "n": "current", "t": -3, "v": 0.14e1 }, { "n": "current", "t": -2, "v": 1.5 }, { "n": "current", "t": -1, "v": 1.6 }, { "n": "current", "t": 0, "v": 1.7 }] } With a large batch of measurements repeating the name creates quite a bit of overhead and also it might be valuable to be able to define multiple base/default units. One possible solution would be to allow nested elements. Something like: {"bn": "urn:dev:mac:0024befffe804ff1/", "bt": 1276020076, "nested":[{ "bu": "V", "bn": "voltage", "e":[ { "t": -5, "v": 120.1 }, { "t": -3, "v": 120.4 }, { "t": -1, "v": 120.5 }, { "t": 0, "v": 120.1 }] }, { "bu": "A", "bn": "current", "e":[ { "t": -4, "v": 1.30 }, { "t": -3, "v": 0.14e1 }, { "t": -2, "v": 1.5 }, { "t": -1, "v": 1.6 }, { "t": 0, "v": 1.7 }] } ] } For long batches of measurements this could save considerable amount of bandwidth. But as a downside this complicates SenML generation and parsing quite a bit. Would this added complexity be worth it? And/or is there a better way to achieve the same result? Cheers, Ari From nobody Mon Jul 6 14:15:27 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65B21A000A; Mon, 6 Jul 2015 14:15:24 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kmy2h41UM-wq; Mon, 6 Jul 2015 14:15:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 084431A01F0; Mon, 6 Jul 2015 14:15:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706211519.14074.23950.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 14:15:19 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-resource-directory-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 21:15:25 -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 Working Group of the IETF. Title : CoRE Resource Directory Authors : Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Filename : draft-ietf-core-resource-directory-04.txt Pages : 49 Date : 2015-07-06 Abstract: In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resources descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-resource-directory-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 15:07:10 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7924B1A049A for ; Mon, 6 Jul 2015 15:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=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 wksEqn_JseCR for ; Mon, 6 Jul 2015 15:07:06 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350CA1A86E0 for ; Mon, 6 Jul 2015 15:06: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 t66M6f3Z001294; Tue, 7 Jul 2015 00:06:41 +0200 (CEST) Received: from alma.local (p5DCCC755.dip0.t-ipconnect.de [93.204.199.85]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mQLb51vj2z3HCW; Tue, 7 Jul 2015 00:06:41 +0200 (CEST) Message-ID: <559AFBEF.3070704@tzi.org> Date: Tue, 07 Jul 2015 00:06:39 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= References: <20150706195700.4435.91426.idtracker@ietfa.amsl.com> <559AE0E7.1040801@ericsson.com> In-Reply-To: <559AE0E7.1040801@ericsson.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-jennings-core-senml@tools.ietf.org, core Subject: Re: [core] Fwd: New Version Notification for draft-jennings-core-senml-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 22:07:08 -0000 Ari Keränen wrote: > - Added recommendation for the order of the JSON attributes Hmm. This means -- If I want to heed that recommendation, I can't use standard JSON implementations, because map order typically can't be influenced. -- As a consumer, I still can't rely on this order (it is just a recommendation), so nothing is gained. Lots of downside, no upside. Maybe I don't understand this recommendation. Grüße, Carsten From nobody Mon Jul 6 15:21:25 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13441A21A8 for ; Mon, 6 Jul 2015 15:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43HyQxyjzapQ for ; Mon, 6 Jul 2015 15:21:22 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA571A1B65 for ; Mon, 6 Jul 2015 15:21:21 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-45-559aff5ff717 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 56.D1.25217.F5FFA955; Tue, 7 Jul 2015 00:21:19 +0200 (CEST) Received: from Aris-MacBook-Pro-2.local (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.210.2; Tue, 7 Jul 2015 00:21:18 +0200 Message-ID: <559AFF5E.1000604@ericsson.com> Date: Tue, 7 Jul 2015 01:21:18 +0300 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Carsten Bormann References: <20150706195700.4435.91426.idtracker@ietfa.amsl.com> <559AE0E7.1040801@ericsson.com> <559AFBEF.3070704@tzi.org> In-Reply-To: <559AFBEF.3070704@tzi.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+JvjW78/1mhBp1PzCyOTLnLarHv7Xpm iwPTJrA6MHssWfKTyePL5c9sHtMWZQYwR3HZpKTmZJalFunbJXBlvJ+1k6lgImfFtK2TWBoY p7J3MXJwSAiYSNx8V9LFyAlkiklcuLeerYuRi0NI4CijxPSnDxkhnM2MEot37mAFqeIV0JbY fesvE0gzi4CKxJwPSSBhNgFbidWvbrKA2KICKRLPluxmgigXlDg58wlYXERASeLCxTVsIDaz gIvEsjUX2UDGCAuESWxrqQIJCwlUS7w83A02nVNAXeLOU12IaguJmfPPM0LY8hLNW2czQ5Sr Slz994pxAqPgLCTLZiFpmYWkZQEj8ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwNA9uOW3 1Q7Gg88dDzEKcDAq8fA+WDEzVIg1say4MvcQozQHi5I474zNeaFCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGHkzA4tfrl6p7FL8sSj/mkzkRtuKyUyTlr9Km1ooJ//5wgX965On1rxyntV0 YZ+uV+K+4hSu6S/so7lcrAvOzXp8N0UtueXqC/eS+Q9mnFn929TydZOMZUXlnPvN2z6t7VzK UBP997L29ks/jbwDd63fPHvatS2S+1/5HZnNVJK96sxjk3uvO/OVWIozEg21mIuKEwEccdvb PgIAAA== Archived-At: Cc: draft-jennings-core-senml@tools.ietf.org, core Subject: Re: [core] Fwd: New Version Notification for draft-jennings-core-senml-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 22:21:24 -0000 On 07/07/15 01:06, Carsten Bormann wrote: > Ari Keränen wrote: >> - Added recommendation for the order of the JSON attributes > > Hmm. This means > > -- If I want to heed that recommendation, I can't use standard JSON > implementations, because map order typically can't be influenced. Yes, that's why it's just a recommendation. However, how do the implementations folks use for constrained devices currently work? I know the one I did keeps the order since I used simple structures (i.e., nothing fancy like hash maps) to keep the implementation simple. > -- As a consumer, I still can't rely on this order (it is just a > recommendation), so nothing is gained. > > Lots of downside, no upside. > Maybe I don't understand this recommendation. You don't necessarily need to rely on the order to get benefits. The key benefit is that with a simple parser you can calculate full name and time based on base name and time while parsing the data. If the bn and bt are in the end, you don't know the result before the end of the structure. You can live with that, but it's just more extra cycles you need to use. Cheers, Ari From nobody Mon Jul 6 17:02:29 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDC51A21A4 for ; Mon, 6 Jul 2015 17:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 qf73KUc0RE5e for ; Mon, 6 Jul 2015 17:02:26 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 D1CBD1A1EFE for ; Mon, 6 Jul 2015 17:02:22 -0700 (PDT) Received: by qkeo142 with SMTP id o142so129246960qke.1 for ; Mon, 06 Jul 2015 17:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KUojviUN9hJwnj+n3YSVHtmiNGvAqcb4hmwO+fNvte0=; b=e/ORPLxlYO+aj/m6URBcP2QXRusyoxqdDraMTfPn8nxwAC7Urp0flQ/4ZEDh34Wzdj wcDozWeHan24WJMStJaF5NSymHN3gxNUpt5Mf+QDgBBUmqqEwRf6W0M7BTeuKambpNz4 SxmVPKVt9WCvZ1uriOffSzS33P2l5WCzCvrDVdM92EV5oNCdDfWED6QHCY6Jk4LFcwKi hvlWwloyICvFo5pfvyKnx3u9/pSP1up8EXz9X7wmcOEsEObt3mj2JSiO870dWyQd3zYL YyFhMY1uos9sS1Ly6oOMi1d9b/itjRiU+Ag+5iwYCWnsKEIcXNAfWx6XId8iFS9oZc+1 S9hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KUojviUN9hJwnj+n3YSVHtmiNGvAqcb4hmwO+fNvte0=; b=mGTxMXb8Z7R0F0Mmo6WibAWPbcnsrFW3y3ZEXRT9qHGCipL2g2ARd9fA7Ifn05lCtj L9CGczGc25S9HUcQy+sKHxFgZEg4deHpM7E1t327KDXXIHyM4AB39gBydOMkVwEMwsp5 B3isjS3xvJThcVIYnWXGScE5hTHXgE2Vv+r8fYVwHJ3CPkD+EEJ3yUDquNai3s+5pHPS 2jNGbhrOt4sl3+4WR2113fTCpBlpnzWdez/nr5N4HLgxhiUsIdLG5GnddCF2qx2XdiDT FVp2uJEsNPHO9sy7KuZpxHRIe0VNpra5ZghuB74YhYrZn1nrrd5z6nsuyUSGo3DegxA6 CCWw== X-Gm-Message-State: ALoCoQkE6heEhzj/ZSptM+iVJEb9eAyOaACXz9hNA6iM7zA9jzWJycZpTyONWQ/kVaPWYd4frccD MIME-Version: 1.0 X-Received: by 10.140.133.18 with SMTP id 18mr2661507qhf.84.1436227342069; Mon, 06 Jul 2015 17:02:22 -0700 (PDT) Received: by 10.96.139.232 with HTTP; Mon, 6 Jul 2015 17:02:21 -0700 (PDT) In-Reply-To: <559AEF98.8020501@ericsson.com> References: <559AEF98.8020501@ericsson.com> Date: Tue, 7 Jul 2015 10:02:21 +1000 Message-ID: From: Andrew Mcgregor To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= Content-Type: multipart/alternative; boundary=001a1136fe968abae2051a3dbcce Archived-At: Cc: draft-jennings-core-senml@tools.ietf.org, core Subject: Re: [core] Nested elements for SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 00:02:28 -0000 --001a1136fe968abae2051a3dbcce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How about: {"bn": "urn:dev:mac:0024befffe804ff1/", "bt": 1276020076, "bu": "A", "e":[ { "n": "voltage", "t": [-5, -3, -1, 0], "u": "V", "v": [120.1, 120.4, 120.5, 120.1] }, { "n": "current", "t": [-4, -3, -2, -1, 0], "v": [1.30, 0.14e1, 1.5, 1.6, 1.7] }, } Even more compact, and probably easier to parse. If you require the value and time series to have a different name when they are lists, what about: {"bn": "urn:dev:mac:0024befffe804ff1/", "bt": 1276020076, "bu": "A", "e":[ { "n": "voltage", "ts": [-5, -3, -1, 0], "u": "V", "vs": [120.1, 120.4, 120.5, 120.1] }, { "n": "current", "ts": [-4, -3, -2, -1, 0], "vs": [1.30, 0.14e1, 1.5, 1.6, 1.7] }, } On 7 July 2015 at 07:14, Ari Ker=C3=A4nen wrote: > Hi all, > > One of the main open issues with the SenML draft is whether we should add > support for nested elements and inheriting values. > > Currently, if one wants to send e.g. multiple current and voltage values, > something like this is done: > > {"bn": "urn:dev:mac:0024befffe804ff1/", > "bt": 1276020076, > "bu": "A", > "e":[ > { "n": "voltage", "t": -5, "u": "V", "v": 120.1 }, > { "n": "voltage", "t": -3, "u": "V", "v": 120.4 }, > { "n": "voltage", "t": -1, "u": "V", "v": 120.5 }, > { "n": "voltage", "t": 0, "u": "V", "v": 120.1 }, > { "n": "current", "t": -4, "v": 1.30 }, > { "n": "current", "t": -3, "v": 0.14e1 }, > { "n": "current", "t": -2, "v": 1.5 }, > { "n": "current", "t": -1, "v": 1.6 }, > { "n": "current", "t": 0, "v": 1.7 }] > } > > With a large batch of measurements repeating the name creates quite a bit > of overhead and also it might be valuable to be able to define multiple > base/default units. > > One possible solution would be to allow nested elements. Something like: > > {"bn": "urn:dev:mac:0024befffe804ff1/", > "bt": 1276020076, > "nested":[{ > "bu": "V", > "bn": "voltage", > "e":[ > { "t": -5, "v": 120.1 }, > { "t": -3, "v": 120.4 }, > { "t": -1, "v": 120.5 }, > { "t": 0, "v": 120.1 }] > }, > { > "bu": "A", > "bn": "current", > "e":[ > { "t": -4, "v": 1.30 }, > { "t": -3, "v": 0.14e1 }, > { "t": -2, "v": 1.5 }, > { "t": -1, "v": 1.6 }, > { "t": 0, "v": 1.7 }] > } > ] > } > > For long batches of measurements this could save considerable amount of > bandwidth. But as a downside this complicates SenML generation and parsin= g > quite a bit. > > Would this added complexity be worth it? And/or is there a better way to > achieve the same result? > > > Cheers, > Ari > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --=20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 --001a1136fe968abae2051a3dbcce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How about:
=C2=A0 =C2=A0{"bn": "urn:dev:mac:0024befffe804ff1/<= span style=3D"font-size:12.8000001907349px">",
=C2= =A0 =C2=A0 "bt": 1276020076,
=C2=A0 =C2=A0 &qu= ot;bu": "A",
=C2=A0 =C2=A0 "e":= [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "vol= tage", "t": [-5, -3, -1, 0], "u": "V", &= quot;v": [120.1, 120.4, 120.5, 120.1] },
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 { "n": "current", "t": [-4,= -3, -2, -1, 0], "v": [1.30, 0.14e1, 1.5, 1.6, 1.7] },
=C2=A0 =C2=A0}

Even more compact, and probab= ly easier to parse. If you require the value and time series to have a diff= erent name when they are lists, what about:
=C2=A0 =C2=A0{"bn": "urn:dev:= mac:0024befffe804ff1/&q= uot;,
=C2=A0 =C2=A0 "bt": 1276020076,=C2=A0 =C2=A0 "bu": "A",
= =C2=A0 =C2=A0 "e":[
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 { "n": "voltage", "ts": [-5, -3, -1, 0], = "u": "V", "vs": [120.1, 120.4, 120.5, 120.1] = },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "cu= rrent", "ts": [-4, -3, -2, -1, 0], "vs": [1.30, 0.= 14e1, 1.5, 1.6, 1.7] },
=C2=A0 =C2=A0}

On 7 July 2015 at 07:14, Ari Ker=C3= =A4nen <ari.keranen@ericsson.com> wrote:
Hi all,

One of the main open issues with the SenML draft is whether we should add s= upport for nested elements and inheriting values.

Currently, if one wants to send e.g. multiple current and voltage values, s= omething like this is done:

=C2=A0 =C2=A0{"bn": "urn:dev:mac:0024befffe804ff1/", =C2=A0 =C2=A0 "bt": 1276020076,
=C2=A0 =C2=A0 "bu": "A",
=C2=A0 =C2=A0 "e":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "voltage", "t&q= uot;: -5, "u": "V", "v": 120.1 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "voltage", "t&q= uot;: -3, "u": "V", "v": 120.4 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "voltage", "t&q= uot;: -1, "u": "V", "v": 120.5 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "voltage", "t&q= uot;: 0,=C2=A0 "u": "V", "v": 120.1 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "current", "t&q= uot;: -4, "v": 1.30 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "current", "t&q= uot;: -3, "v": 0.14e1 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "current", "t&q= uot;: -2, "v": 1.5 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "current", "t&q= uot;: -1, "v": 1.6 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "n": "current", "t&q= uot;: 0, "v": 1.7 }]
=C2=A0 =C2=A0}

With a large batch of measurements repeating the name creates quite a bit o= f overhead and also it might be valuable to be able to define multiple base= /default units.

One possible solution would be to allow nested elements. Something like:
=C2=A0 =C2=A0{"bn": "urn:dev:mac:0024befffe804ff1/", =C2=A0 =C2=A0 "bt": 1276020076,
=C2=A0 =C2=A0 "nested":[{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "bu": "V",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "bn": "voltage",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "e":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "t": -5, "v": 120.= 1 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "t": -3, "v": 120.= 4 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "t": -1, "v": 120.= 5 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "t": 0,=C2=A0 "v":= 120.1 }]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "bu": "A",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "bn": "current",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "e":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "t": -4, "v": 1.30= },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "t": -3, "v": 0.14= e1 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "t": -2, "v": 1.5 = },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "t": -1, "v": 1.6 = },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 { "t": 0, "v": 1.7 }= ]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 ]
=C2=A0 =C2=A0 }

For long batches of measurements this could save considerable amount of ban= dwidth. But as a downside this complicates SenML generation and parsing qui= te a bit.

Would this added complexity be worth it? And/or is there a better way to ac= hieve the same result?


Cheers,
Ari

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



--
Andrew McGregor=C2=A0|=C2=A0SRE=C2=A0|=C2=A0andrewm= cgr@google.com=C2=A0|=C2=A0+61 4 1071 2221
--001a1136fe968abae2051a3dbcce-- From nobody Tue Jul 7 05:47:49 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5001A01BA for ; Tue, 7 Jul 2015 05:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=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 gLO3FH2_81_3 for ; Tue, 7 Jul 2015 05:47: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 5B5B91A01AA for ; Tue, 7 Jul 2015 05:47: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 [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t67Clggq026622; Tue, 7 Jul 2015 14:47:42 +0200 (CEST) Received: from alma.local (p5DCCC755.dip0.t-ipconnect.de [93.204.199.85]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mQk7d60Jqz3GG6; Tue, 7 Jul 2015 14:47:41 +0200 (CEST) Message-ID: <559BCA6C.2020402@tzi.org> Date: Tue, 07 Jul 2015 14:47:40 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= References: <20150706195700.4435.91426.idtracker@ietfa.amsl.com> <559AE0E7.1040801@ericsson.com> <559AFBEF.3070704@tzi.org> <559AFF5E.1000604@ericsson.com> In-Reply-To: <559AFF5E.1000604@ericsson.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-jennings-core-senml@tools.ietf.org, core Subject: Re: [core] Fwd: New Version Notification for draft-jennings-core-senml-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 12:47:48 -0000 Ari Keränen wrote: > On 07/07/15 01:06, Carsten Bormann wrote: >> Ari Keränen wrote: >>> - Added recommendation for the order of the JSON attributes >> >> Hmm. This means >> >> -- If I want to heed that recommendation, I can't use standard JSON >> implementations, because map order typically can't be influenced. > > Yes, that's why it's just a recommendation. > > However, how do the implementations folks use for constrained devices > currently work? I know the one I did keeps the order since I used simple > structures (i.e., nothing fancy like hash maps) to keep the > implementation simple. Right. Implementers on the constrained side will have few problems with this. If the assumption is that SenML will mainly be originated by embedded implementations, it may be possible to do this. But then: >> -- As a consumer, I still can't rely on this order (it is just a >> recommendation), so nothing is gained. >> >> Lots of downside, no upside. >> Maybe I don't understand this recommendation. > > You don't necessarily need to rely on the order to get benefits. The key > benefit is that with a simple parser you can calculate full name and > time based on base name and time while parsing the data. If the bn and > bt are in the end, you don't know the result before the end of the > structure. You can live with that, but it's just more extra cycles you > need to use. That assumes that the actual CPU used here matters (or what do you mean by "cycles"?). On a server platform, I'll get the whole map handed to me anyway. On an embedded platform, I may not even have space for two code paths, one that handles the efficient case and one for the general case. So I still think requesting this is a bit questionable, because it asks for something JSON generally can't do. If we really want to make this into a feature, we need to go for arrays (in "record" style, see https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-06#section-2). I.e., turn {"head1":"value1", "head2":"value2", "e" : [...]} into [{"head1":"value1", "head2":"value2"}, [...]] (or even [{"head1":"value1", "head2":"value2"}, ...] if we want to superoptimize this). Grüße, Carsten From nobody Wed Jul 8 02:28:14 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA381B328B for ; Wed, 8 Jul 2015 02:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=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 qpDhREYMyCMH for ; Wed, 8 Jul 2015 02:28:12 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D491B2C4E for ; Wed, 8 Jul 2015 02:28:11 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id CC115449D1; Wed, 8 Jul 2015 11:28:08 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 9700D23; Wed, 8 Jul 2015 11:28:07 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6EDDD3CD; Wed, 8 Jul 2015 11:28:07 +0200 (CEST) Received: (nullmailer pid 3858 invoked by uid 1000); Wed, 08 Jul 2015 09:28:05 -0000 Date: Wed, 8 Jul 2015 11:28:05 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Matthieu Vial Message-ID: <20150708092804.GM10123@hephaistos.amsuess.com> References: <20150706144729.3572.50770.idtracker@ietfa.amsl.com> <20150706151737.GA6467@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+svXpSx+RSEd8UhP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-interfaces-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 09:28:13 -0000 --+svXpSx+RSEd8UhP Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Matthieu, On Tue, Jul 07, 2015 at 11:40:52AM +0200, Matthieu Vial wrote: > > [...] querying /s gives "n":"light" which > > should be /s/light, but querying /s/humidity gives "n":"humidity" which > > should be /s/humidity [...] > > Querying /s gives senml with "n" being a URI relative to the queried URI = /s > so just "light". But that's right to the point: A relative URI `light` based on a URI `coap://my-host/s` evaluates to `coap://my-host/light` by the usual rules of RFC3986 section 5.2. (And the context of the example makes it clear that the intended resource is `coap://my-host/s/light`). My proposed fix to -core-interfaces is to rename the batch from `coap://my-host/s` to `coap://my-host/s/`, then things work out. > Since we don't want to support .. path navigation querying /l gives senml > with absolute path to reference /s/light. Nothing wrong about that; the values of "n" (or more precisely: the complete representable URI) are already restricted to escape friendly characters in draft-jennings-core-senml-01 section 4 ("The resulting concatenated name MUST consist [...]"), so restricting it to only use "downward" relative URIs does not seem too far fetched if so desired. I've only listed the `/l` example because it shows that the intention of the mentioned "concatenation" or "appending" is actually RFC3986 relative URL chaining; it's the `/s` / `humidity` example that produce a wrong URIs, and the `/s/humidity` / `humidity` example that is not technially wrong but overly verbose. But there is agreement that relative URL concatenation should be happening between "bn" and "n", right? Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --+svXpSx+RSEd8UhP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVnO0gAAoJEDmNERLTpL3h2vcP/0BCWYoJ4CYfqdlsH3o8c1zb 4RxP0Gnpinv74kLkDvyhXYtOUlz6x6be0GYf/DNNIgCi8P6/dX7hBet29KJscJuH p6A5JtPm+aj7VsaBh0+CAfMYgfRjjX9ZHsDoGS8KZw/gQvQlxly+b1scsLAgAK6x /VeRzmMaZoVpyELP7nWw8jFxRpIZA5//zcKkSxgxev1fLmD2ffDSjcaOKeDZwV0k qJ6h4daDjWGAfBGMNWghpDbPxqqDYfpDk/3pKgaKhu/6wTwOosB+9odRIjwskPz0 x0j3HtKniKMAoUyrBdEVzIvM6eQ0BMx/tR6+NSmM/UlsIAaBS3t+L/UU3SifWfQ1 8SlhP2zvgyqe38EG//q08aTPzFPaPxdTxDVUkSomFK8X4ooIUqVPYm7EOsq9xdGr Nck9ZY302bw1QoG5TREzcFNRSg3w2hAe6/ApTLtNlTR6/xGUklOPrLYS0ioY2M5E vi8NlojLdIIf3fPKX6mh9xlY/+D+KLcGrcWYdhz5/2v23PxnqUZccPROImfyxRi7 oy+TjiYdh2a3MsHfwIiyU3gORBghpVu8If7Lv7RHuu/JIcjlBtWBpYSuLe6cKWp6 2HTMevaRU8FBfCMmvZLrZkaP+XtL20gG5OWfIY+ZAjoZ6s49gFmzIljme1aBpLZG bw8l4MiwI1mUKIRgwYOB =g6uY -----END PGP SIGNATURE----- --+svXpSx+RSEd8UhP-- From nobody Wed Jul 8 03:09:18 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6431B3409 for ; Wed, 8 Jul 2015 03:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.114 X-Spam-Level: X-Spam-Status: No, score=-0.114 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, MIME_8BIT_HEADER=0.3] autolearn=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 aAr4Mk-h7Ifx for ; Wed, 8 Jul 2015 03:09:16 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54FB11B3407 for ; Wed, 8 Jul 2015 03:09:16 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 262A7449D2; Wed, 8 Jul 2015 12:09:14 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 87F7523; Wed, 8 Jul 2015 12:09:09 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id D8B7D3CD; Wed, 8 Jul 2015 12:09:08 +0200 (CEST) Received: (nullmailer pid 17859 invoked by uid 1000); Wed, 08 Jul 2015 10:09:06 -0000 Date: Wed, 8 Jul 2015 12:09:06 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Ari =?iso-8859-1?Q?Ker=E4nen?= , Carsten Bormann Message-ID: <20150708100906.GO10123@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l3ej7W/Jb2pB3qL2" Content-Disposition: inline In-Reply-To: <559BCA6C.2020402@tzi.org> <559AFF5E.1000604@ericsson.com> <559AEF98.8020501@ericsson.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: draft-jennings-core-senml@tools.ietf.org, core Subject: Re: [core] Fwd: New Version Notification for draft-jennings-core-senml-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 10:09:18 -0000 --l3ej7W/Jb2pB3qL2 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Tue, Jul 07, 2015 at 01:21:18AM +0300, Ari Ker=E4nen wrote: > However, how do the implementations folks use for constrained devices > currently work? I know the one I did keeps the order since I used simple > structures (i.e., nothing fancy like hash maps) to keep the implementation > simple. my embedded version currently throws an error when trailing "bn" values are encountered. It could be easily made to parse them in a single-block request, but for updates received in blockwise mode that's out of the question. On Tue, Jul 07, 2015 at 02:47:40PM +0200, Carsten Bormann wrote: > So I still think requesting this is a bit questionable, because it asks > for something JSON generally can't do. >=20 > [...] >=20 > [{"head1":"value1", "head2":"value2"}, [...]] This would make implementing a correct SenML parser on a constrained system *much* easier, and might make other extensions easier as well (see "Nested elements for SenML" thread, switching there to stay on topic). I'd prefer this form over the form without a second list ([{...}, e1, e2, ...]), as it is clearer and only costs 1-2 bytes. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --l3ej7W/Jb2pB3qL2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVnPa/AAoJEDmNERLTpL3hyS8P+wb5vvxMEB0j0rJMicCWzpay 15G/nboCH/9CiRbdGhsXO+6NgUs3+jr8H8IG/5mi0NLNgoUH1XJWL7KYvX3Fxg16 9Qv5Amh86dxOlYkHHMff7OCcZURfBaotLwfb8Tl3G0YjuZJqbX3up7M9cuIdywg4 qoFtwEY3cN5qnS+12IPT/cLpsV9qw9tUarW1XJwxjLLbv2xPzlRDPwPMuKz6NTw/ wh2Wf8YiAh7yo7fF4Dkf+n30uI9o+3a1DkFu8ISEZYLfOJl8pymZtIavgPCjhfPK b0wNzOAxp+pPMwVudOPBNftvDPmukG5ljZr4KIgPBIVnSaslaZYoJZITBmz3b1XJ Qb8qeXaDN5SdA1pConKFTx/z8AO727ZXpWsCFLpKuF+i5NpEyGPaaGV1a6Yr1qn7 BpxK/kvavufvkpyr3LvuRnH5cDB2yHrBGZTyGsBB4YV3P35Y4aawFCdkeQoeWP1P uJy84aVw8a86vgHEHXPMlE+ee0qqDBjd6iX2zYK60SSyx4WuGehVsIivmY/vgIoY WQuu1vwq4GzUkduXdywZTkNlyB8zkivNlN7cgD5IFwsEzLzcw7ym4GLn18lJSho3 VAqtVdN0VR21ZA4TVct4iWmIgjOStww7PtPtxImzNpyGETSHXWPWZ9VtA9CkJmWg rWJz+GnFOkXGNH+dlsTO =RdPn -----END PGP SIGNATURE----- --l3ej7W/Jb2pB3qL2-- From nobody Wed Jul 8 03:15:13 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5957A1B3411 for ; Wed, 8 Jul 2015 03:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=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 ibKc--aQ75ul for ; Wed, 8 Jul 2015 03:15:10 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B281B3410 for ; Wed, 8 Jul 2015 03:15:10 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0DB33449D2; Wed, 8 Jul 2015 12:15:08 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 331D223; Wed, 8 Jul 2015 12:15:03 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8BDBF3CD; Wed, 8 Jul 2015 12:15:02 +0200 (CEST) Received: (nullmailer pid 19004 invoked by uid 1000); Wed, 08 Jul 2015 10:15:01 -0000 Date: Wed, 8 Jul 2015 12:15:01 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Ari =?iso-8859-1?Q?Ker=E4nen?= Message-ID: <20150708101501.GA6381@hephaistos.amsuess.com> References: <559AEF98.8020501@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <559AEF98.8020501@ericsson.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: draft-jennings-core-senml@tools.ietf.org, core Subject: Re: [core] Nested elements for SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 10:15:11 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Ari, if we follow the headers-first syntax suggested by Carsten[1], there might be a way that is flexible in allowing all header attributes to be batched, but avoids the complexity of nesting: On Tue, Jul 07, 2015 at 12:14:00AM +0300, Ari Ker=E4nen wrote: > {"bn": "urn:dev:mac:0024befffe804ff1/", > "bt": 1276020076, > "nested":[{ > "bu": "V", > "bn": "voltage", > "e":[...1...] > }, > { > "bu": "A", > "bn": "current", > "e":[...2...] > } > ] > } could be represented like this: [ {"bn": "urn:dev:mac:0024befffe804ff1/voltage", "bt": 1276020076, "bu": "V" }, [...1...], {"bn": "current", "bu": "A" }, [...2...] ] The semantics of the later headers would be updating the former. That should be comparatively easy to parse without the need for memory management or nesting depth limits. Best regards Christian [1] https://www.ietf.org/mail-archive/web/core/current/msg06254.html --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVnPglAAoJEDmNERLTpL3hj7EQAK8pE8pL74TQj5QUSQQWwswg 7nK5S5tIMXgK/934ndmkBcnl8G0M/PMLCmjunDotzs3KKiayEPKMR61gLRs+SDEN YJeXwsrydycqZNTmvpaZmNZX6Df2x+bWcmSr8xNtc8oq8SdxYci85KWg299pOqnX d6sabROLYWHQYTwFIce1M7t8b+KpX1icA9TuJBJ1pz0w4YIAoAZpGkReIzcAYag1 OdM6SfHn6Nljj6ob5IxMHRf+X6O8kgld0eGp0uP6izmpo1J/idCj1t30f0jE6Vzs KFtWY3YoNjsvKYaxFTuywguVJ8xOdmJE+ruGbNrc/mD8FNlbBsAiXHXCKRElelbG /e3gz4SUIzp+4+HPcTtg352UtGO4WVFJvDeHooMiBOcxTL3Bt1kZzARn+6D37Y0f PeCx60pR8N1grSKcmGiw7BnQD+YttD8mQ1PxK27DPqfnXmvhYAoj4/xauFPzR8Ew NCfFRwqj5jcD7F51aHi1+y3S774e+Kr+gDQX7X4CD8A3EINjL5HaDAb0YNFL9oD1 rqgPvjbxmtNyomTtCUH0As93reClC4MgpGX1a+ULXQR9zEiwhbrH1fXqAVCWOKES MY9mEuh39Mw9R4kvEa9GCKuj06ALzdTo1bhKlQ5Q+UemMvBoUaHrok6CSW1Akb44 bn+qAvEGNI2TKvQBkrcx =0Qgb -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From nobody Wed Jul 8 08:07:31 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2715E1A0029 for ; Wed, 8 Jul 2015 08:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VF-40QbXoYwr for ; Wed, 8 Jul 2015 08:07:28 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2DEB1A0020 for ; Wed, 8 Jul 2015 08:07:27 -0700 (PDT) X-AuditID: c1b4fb25-f79046d000007f53-94-559d3cad6339 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F4.BA.32595.DAC3D955; Wed, 8 Jul 2015 17:07:26 +0200 (CEST) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.210.2; Wed, 8 Jul 2015 17:07:25 +0200 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 271B860558; Wed, 8 Jul 2015 18:07:28 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 50A54603DA; Wed, 8 Jul 2015 18:07:27 +0300 (EEST) Message-ID: <559D3CAB.9060808@ericsson.com> Date: Wed, 8 Jul 2015 18:07:23 +0300 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Carsten Bormann References: <20150706195700.4435.91426.idtracker@ietfa.amsl.com> <559AE0E7.1040801@ericsson.com> <559AFBEF.3070704@tzi.org> <559AFF5E.1000604@ericsson.com> <559BCA6C.2020402@tzi.org> In-Reply-To: <559BCA6C.2020402@tzi.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvje46m7mhBkvOsVscmXKX1WLf2/XM FgemTWB1YPZYsuQnk8eXy5/ZPKYtygxgjuKySUnNySxLLdK3S+DK+HDpP3vBN4mKz3veMDUw 3hLuYuTkkBAwkbj19DUzhC0mceHeerYuRi4OIYGjjBIn58xmgXC2MkqsufiIGcJZxygx+9p2 JghnBaPE30Pb2UH6eQW0JZbP6gNKcHCwCKhIHDkhABJmE7CVWP3qJguILSqQIvHw729miHJB iZMzn4DFRQSUJC5cXMMGYjMLuEgsW3ORDWSMsECYxLaWKohV2xgl5k47wwwS5xRQl9j0LAqi 3EJi5vzzjBC2vETz1tlQ36hJXD23CcwWElCVuPrvFeMERpFZSDbPQtI+C0n7AkbmVYyixanF SbnpRsZ6qUWZycXF+Xl6eaklmxiBsXBwy2/VHYyX3zgeYhTgYFTi4VVomRMqxJpYVlyZe4hR moNFSZx3xua8UCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MUfvyHgT/jL0/Q1GaLcEm6kXh 3OQF2bOypHZzJgr8PiogOWeCx67eM7ysfjOU8nbNtGvjKhHK/+WWv2eTVJv80vtL3TeF71+m 3B/4UOn3tJcP7kUuSLh5wlysoynZZlXTCe79t3TUlk2sS/3SaatnKHrza4D9g+dzDzWrzD1w fe2DR//ncW8sUmIpzkg01GIuKk4EAJimlBlmAgAA Archived-At: Cc: draft-jennings-core-senml@tools.ietf.org, core Subject: Re: [core] Fwd: New Version Notification for draft-jennings-core-senml-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 15:07:30 -0000 On 07/07/15 15:47, Carsten Bormann wrote: > Ari Keränen wrote: >> On 07/07/15 01:06, Carsten Bormann wrote: >>> Ari Keränen wrote: >>>> - Added recommendation for the order of the JSON attributes >>> >>> Hmm. This means >>> >>> -- If I want to heed that recommendation, I can't use standard JSON >>> implementations, because map order typically can't be influenced. >> >> Yes, that's why it's just a recommendation. >> >> However, how do the implementations folks use for constrained devices >> currently work? I know the one I did keeps the order since I used simple >> structures (i.e., nothing fancy like hash maps) to keep the >> implementation simple. > > Right. Implementers on the constrained side will have few problems with > this. If the assumption is that SenML will mainly be originated by > embedded implementations, it may be possible to do this. Yes, or if you are in control of both endpoints. I'm thinking more along the lines of "if it's easy to do so, do this". > But then: > >>> -- As a consumer, I still can't rely on this order (it is just a >>> recommendation), so nothing is gained. >>> >>> Lots of downside, no upside. >>> Maybe I don't understand this recommendation. >> >> You don't necessarily need to rely on the order to get benefits. The key >> benefit is that with a simple parser you can calculate full name and >> time based on base name and time while parsing the data. If the bn and >> bt are in the end, you don't know the result before the end of the >> structure. You can live with that, but it's just more extra cycles you >> need to use. > > That assumes that the actual CPU used here matters (or what do you mean > by "cycles"?). On a server platform, I'll get the whole map handed to > me anyway. On an embedded platform, I may not even have space for two > code paths, one that handles the efficient case and one for the general > case. CPU cycles and also memory. If you can have the full values while parsing the structure you can (potentially) act accordingly and then forget all the parts you have already processed. If you get the base values only in the end, you can't do that; or you need to parse the structure twice to do that. But good point regarding the two code paths. I'm thinking it would be only a few extra lines of c-code to take advantage of the optimized way, but would probably need to implement it to know for sure. And anyway non-optimized code would work for each approach equally well -- no harm done. > So I still think requesting this is a bit questionable, because it asks > for something JSON generally can't do. > > If we really want to make this into a feature, we need to go for arrays > (in "record" style, see > https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-06#section-2). > > I.e., turn > > {"head1":"value1", "head2":"value2", "e" : [...]} > > into > > [{"head1":"value1", "head2":"value2"}, [...]] > > (or even > > [{"head1":"value1", "head2":"value2"}, ...] > > if we want to superoptimize this). That might be an option too. What are the downsides of this approach? Cheers, Ari From nobody Wed Jul 8 08:17:38 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05F31A004C for ; Wed, 8 Jul 2015 08:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apf9EELPfIrQ for ; Wed, 8 Jul 2015 08:17:35 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378261A0045 for ; Wed, 8 Jul 2015 08:17:35 -0700 (PDT) X-AuditID: c1b4fb25-f79046d000007f53-be-559d3f0d27dc Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0B.FB.32595.D0F3D955; Wed, 8 Jul 2015 17:17:33 +0200 (CEST) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Wed, 8 Jul 2015 17:17:32 +0200 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9DB4C60558; Wed, 8 Jul 2015 18:17:35 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C8A2A603DA; Wed, 8 Jul 2015 18:17:34 +0300 (EEST) Message-ID: <559D3F0B.3050101@ericsson.com> Date: Wed, 8 Jul 2015 18:17:31 +0300 From: =?windows-1252?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: =?windows-1252?Q?Christian_Ams=FCss?= References: <20150708100906.GO10123@hephaistos.amsuess.com> In-Reply-To: <20150708100906.GO10123@hephaistos.amsuess.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+JvjS6v/dxQg/U/1CyWX3jOYnFkyl1W i31v1zNbHJg2gdWBxWPr/rtMHkuW/GTy+HL5M5vHtEWZASxRXDYpqTmZZalF+nYJXBmXPuxi KbjLU/FhwWnGBsZuri5GTg4JAROJyW372SFsMYkL99azdTFycQgJHGWUWPJ/KjuEs5VRYv++ y8wgVUIC6xglXvwIg0isYJS4urebDSTBK6AtceVKJ5jNIqAi8WzSQkYQm03AUeL2w5esILao QIrEw7+/mSHqBSVOznzC0sXIwSEi4Cmxea4qSJhZIE2iv3E7M0hYWCBMYltLFcRaa4nZG2eD dXIK2EjcPLyXEaSEWcBe4sHWMohOeYnmrRAlEgJqElfPbYK6WFXi6r9XjBMYRWYh2TsLoXsW ku4FjMyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQIj4+CW36o7GC+/cTzEKMDBqMTDq9Ay J1SINbGsuDL3EKM0B4uSOO+MzXmhQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgtuwXXWwd9 lBd7uJTn77u5J7Zu6Qq5NfP6FjkL4+7lrRtmW4YocRi+mPXozKeeR+dYT7tZ2wRFN92oML60 ubHkF7/mZNmdLLveZrJffLTOuFLtlTpLk8a8pceVJ+c1/nH1ubLN2lfVMyzIo3DBnvZKgd2J rXx+O4SzNc+s+5Lvnbwg9q2x/EYlluKMREMt5qLiRABqiYnRbQIAAA== Archived-At: Cc: draft-jennings-core-senml@tools.ietf.org, core Subject: Re: [core] Fwd: New Version Notification for draft-jennings-core-senml-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 15:17:37 -0000 Hi, On 08/07/15 13:09, Christian Amsüss wrote: > On Tue, Jul 07, 2015 at 01:21:18AM +0300, Ari Keränen wrote: >> However, how do the implementations folks use for constrained devices >> currently work? I know the one I did keeps the order since I used simple >> structures (i.e., nothing fancy like hash maps) to keep the implementation >> simple. > > my embedded version currently throws an error when trailing "bn" values > are encountered. It could be easily made to parse them in a single-block > request, but for updates received in blockwise mode that's out of the > question. Do you mean that you currently support *only* base values in the beginning? And block-wise transfer indeed complicates things even further since it may take a while to receive the base values if they are in the very end of a large SenML. > On Tue, Jul 07, 2015 at 02:47:40PM +0200, Carsten Bormann wrote: >> So I still think requesting this is a bit questionable, because it asks >> for something JSON generally can't do. >> >> [...] >> >> [{"head1":"value1", "head2":"value2"}, [...]] > > This would make implementing a correct SenML parser on a constrained > system *much* easier, and might make other extensions easier as well > (see "Nested elements for SenML" thread, switching there to stay on > topic). Could you please elaborate a bit how this makes parser easier? Do you mean because of the fixed ordering? Thanks, Ari > I'd prefer this form over the form without a second list ([{...}, e1, > e2, ...]), as it is clearer and only costs 1-2 bytes. > > Best regards > Christian > From nobody Wed Jul 8 08:26:10 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC481A00BE for ; Wed, 8 Jul 2015 08:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGc1U74DBt35 for ; Wed, 8 Jul 2015 08:26:07 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B641A0052 for ; Wed, 8 Jul 2015 08:25:16 -0700 (PDT) X-AuditID: c1b4fb25-f79046d000007f53-1d-559d40dbb4a7 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 30.FC.32595.BD04D955; Wed, 8 Jul 2015 17:25:15 +0200 (CEST) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.210.2; Wed, 8 Jul 2015 17:25:14 +0200 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3FFC860558; Wed, 8 Jul 2015 18:25:17 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B3D89603DA; Wed, 8 Jul 2015 18:25:16 +0300 (EEST) Message-ID: <559D40D9.8040006@ericsson.com> Date: Wed, 8 Jul 2015 18:25:13 +0300 From: =?windows-1252?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: =?windows-1252?Q?Christian_Ams=FCss?= References: <559AEF98.8020501@ericsson.com> <20150708101501.GA6381@hephaistos.amsuess.com> In-Reply-To: <20150708101501.GA6381@hephaistos.amsuess.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvje5th7mhBmsuiFosv/CcxWLf2/XM FgemTWB1YPbYuv8uk8eSJT+ZPL5c/swWwBzFZZOSmpNZllqkb5fAlbHlkFDBU66Kz91HGRsY L7N3MXJySAiYSCz8vJINwhaTuHBvPZDNxSEkcJRRoqfpPjuEs5VR4si1tSwgVUIC6xgl+p/F QSRWMEpcX3mPESTBK6AtcfX2RSYQm0VARWLhFog4m4CjxO2HL1lBbFGBFImHf38zQ9QLSpyc +QRoKAeHiICnxOa5qiBhZgEXiWVrLoJdJCygK/HpzxtGiL1REpM6T4KN5xSwlri3eiUTSCuz gL3Eg61lEK3yEs1bZzNDPKMmcfXcJmaIVlWJq/9eMU5gFJmFZPEshO5ZSLoXMDKvYhQtTi1O yk03MtZLLcpMLi7Oz9PLSy3ZxAiMg4NbfqvuYLz8xvEQowAHoxIPr0LLnFAh1sSy4srcQ4zS HCxK4rwzNueFCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBkUReYWBQ/+e7ma6KXuHvmHGfq XDN/5lyBB1zd8syFVyW33DjFGFn18hm70c85q0uZBCpuvMo+8Ofp3ySRk6bx4TNuyYgHeAQZ BX+a9i1282WJA1ueFidbvL3MxXLf8tiVlGuGd6UlE89wi9/qb3EyDHVe0rwtvsS377vn9c5J 4X0NLryJ67YpsRRnJBpqMRcVJwIAEImUU2QCAAA= Archived-At: Cc: draft-jennings-core-senml@tools.ietf.org, core Subject: Re: [core] Nested elements for SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 15:26:09 -0000 Hi Christian, On 08/07/15 13:15, Christian Amsüss wrote: > Hello Ari, > > if we follow the headers-first syntax suggested by Carsten[1], there > might be a way that is flexible in allowing all header attributes to be > batched, but avoids the complexity of nesting: > > On Tue, Jul 07, 2015 at 12:14:00AM +0300, Ari Keränen wrote: >> {"bn": "urn:dev:mac:0024befffe804ff1/", >> "bt": 1276020076, >> "nested":[{ >> "bu": "V", >> "bn": "voltage", >> "e":[...1...] >> }, >> { >> "bu": "A", >> "bn": "current", >> "e":[...2...] >> } >> ] >> } > > could be represented like this: > > [ > {"bn": "urn:dev:mac:0024befffe804ff1/voltage", > "bt": 1276020076, > "bu": "V" > }, > [...1...], > {"bn": "current", > "bu": "A" > }, > [...2...] > ] > > The semantics of the later headers would be updating the former. That > should be comparatively easy to parse without the need for memory > management or nesting depth limits. That looks like a reasonable approach to me. Although, in the example above, I guess we would need full "bn" also before the second measurement array. Cheers, Ari > Best regards > Christian > > [1] https://www.ietf.org/mail-archive/web/core/current/msg06254.html > From nobody Wed Jul 8 08:33:54 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1801A00B1 for ; Wed, 8 Jul 2015 08:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO8q0fDVFSWh for ; Wed, 8 Jul 2015 08:33:47 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C20991A0074 for ; Wed, 8 Jul 2015 08:33:45 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-ac-559d42d769ab Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F7.BC.12828.7D24D955; Wed, 8 Jul 2015 17:33:43 +0200 (CEST) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.210.2; Wed, 8 Jul 2015 17:33:42 +0200 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A1D1660558; Wed, 8 Jul 2015 18:33:45 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 006E2603DA; Wed, 8 Jul 2015 18:33:44 +0300 (EEST) Message-ID: <559D42D5.6040204@ericsson.com> Date: Wed, 8 Jul 2015 18:33:41 +0300 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Andrew Mcgregor References: <559AEF98.8020501@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvje51p7mhBn836lv0HpvHZrHv7Xpm iwPTJrA6MHss2FTqsWTJTyaPL5c/swUwR3HZpKTmZJalFunbJXBlzL75kK3gu2zFvc9f2BsY Lwl3MXJySAiYSBzp/McOYYtJXLi3ng3EFhI4yiix/Ux9FyMXkL2VUeL3j3ssEM46Rom1F/uY IJwVjBKbP85jBGnhFdCWuLV6JVCCg4NFQEVi4o4wkDCbgK3E6lc3WUBsUYEUiYd/fzNDlAtK nJz5BCwuAtT68Ps2JhCbWcBFYtmai2BXCAvoSnz684YR4qICiS3zz4HVcAoESrQeng9VbyEx c/55RghbXqJ562xmiG/UJK6e28QM0asqcfXfK8YJjCKzkKyehaR9FpL2BYzMqxhFi1OLi3PT jYz1Uosyk4uL8/P08lJLNjECY+Hglt+6OxhXv3Y8xCjAwajEw6vQMidUiDWxrLgy9xCjNAeL kjjvjM15oUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYm7fKq5RmONtXrgwR4jTavCCae8rk d84rrwi5lTXfUVl2Xlll2tcOc1PV0PN+p/Mzr2tIbnjNfE7+fjfvxbKbpWWOqVKz8hpu6G1W WNo8+692lWXD3ujF/14c++PW8Uf6AvdkXZkdkib7XkwJbxGo/sAU8n26uP/nBYmqOq7Tsh0v HFh4ZE22EktxRqKhFnNRcSIAb8S6DWYCAAA= Archived-At: Cc: draft-jennings-core-senml@tools.ietf.org, core Subject: Re: [core] Nested elements for SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 15:33:52 -0000 Thanks Andrew. This is pretty interesting too. I wonder what's the implementation complexity of this compared to the Christian's proposal? And of course it also depends a bit whether we do Carsten's proposal for the headers-first issue. Cheers, Ari On 07/07/15 03:02, Andrew Mcgregor wrote: > How about: > {"bn": "urn:dev:mac:0024befffe804ff1/", > "bt": 1276020076, > "bu": "A", > "e":[ > { "n": "voltage", "t": [-5, -3, -1, 0], "u": "V", "v": [120.1, > 120.4, 120.5, 120.1] }, > { "n": "current", "t": [-4, -3, -2, -1, 0], "v": [1.30, 0.14e1, > 1.5, 1.6, 1.7] }, > } > > Even more compact, and probably easier to parse. If you require the > value and time series to have a different name when they are lists, what > about: > {"bn": "urn:dev:mac:0024befffe804ff1/", > "bt": 1276020076, > "bu": "A", > "e":[ > { "n": "voltage", "ts": [-5, -3, -1, 0], "u": "V", "vs": > [120.1, 120.4, 120.5, 120.1] }, > { "n": "current", "ts": [-4, -3, -2, -1, 0], "vs": [1.30, > 0.14e1, 1.5, 1.6, 1.7] }, > } > > On 7 July 2015 at 07:14, Ari Keränen > wrote: > > Hi all, > > One of the main open issues with the SenML draft is whether we > should add support for nested elements and inheriting values. > > Currently, if one wants to send e.g. multiple current and voltage > values, something like this is done: > > {"bn": "urn:dev:mac:0024befffe804ff1/", > "bt": 1276020076, > "bu": "A", > "e":[ > { "n": "voltage", "t": -5, "u": "V", "v": 120.1 }, > { "n": "voltage", "t": -3, "u": "V", "v": 120.4 }, > { "n": "voltage", "t": -1, "u": "V", "v": 120.5 }, > { "n": "voltage", "t": 0, "u": "V", "v": 120.1 }, > { "n": "current", "t": -4, "v": 1.30 }, > { "n": "current", "t": -3, "v": 0.14e1 }, > { "n": "current", "t": -2, "v": 1.5 }, > { "n": "current", "t": -1, "v": 1.6 }, > { "n": "current", "t": 0, "v": 1.7 }] > } > > With a large batch of measurements repeating the name creates quite > a bit of overhead and also it might be valuable to be able to define > multiple base/default units. > > One possible solution would be to allow nested elements. Something like: > > {"bn": "urn:dev:mac:0024befffe804ff1/", > "bt": 1276020076, > "nested":[{ > "bu": "V", > "bn": "voltage", > "e":[ > { "t": -5, "v": 120.1 }, > { "t": -3, "v": 120.4 }, > { "t": -1, "v": 120.5 }, > { "t": 0, "v": 120.1 }] > }, > { > "bu": "A", > "bn": "current", > "e":[ > { "t": -4, "v": 1.30 }, > { "t": -3, "v": 0.14e1 }, > { "t": -2, "v": 1.5 }, > { "t": -1, "v": 1.6 }, > { "t": 0, "v": 1.7 }] > } > ] > } > > For long batches of measurements this could save considerable amount > of bandwidth. But as a downside this complicates SenML generation > and parsing quite a bit. > > Would this added complexity be worth it? And/or is there a better > way to achieve the same result? > > > Cheers, > Ari > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > > > -- > Andrew McGregor | SRE |andrewmcgr@google.com > | +61 4 1071 2221 From nobody Wed Jul 8 08:39:52 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77FB1A00B4 for ; Wed, 8 Jul 2015 08:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=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 cydsB7bdsWI2 for ; Wed, 8 Jul 2015 08:39:48 -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 4D4A11A00B5 for ; Wed, 8 Jul 2015 08:39:48 -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 t68Fde8r007844; Wed, 8 Jul 2015 17:39:40 +0200 (CEST) Received: from alma.local (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mRPvc1L6Qz3Gkx; Wed, 8 Jul 2015 17:39:40 +0200 (CEST) Message-ID: <559D443A.7030307@tzi.org> Date: Wed, 08 Jul 2015 17:39:38 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= References: <559AEF98.8020501@ericsson.com> <20150708101501.GA6381@hephaistos.amsuess.com> <559D40D9.8040006@ericsson.com> In-Reply-To: <559D40D9.8040006@ericsson.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-jennings-core-senml@tools.ietf.org, core , =?UTF-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= Subject: Re: [core] Nested elements for SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 15:39:50 -0000 Maybe the easiest way to phrase the semantics is that each map in that top-level array is applied to the previous state of the variables as a merge-patch (RFC 7386)? (We could still allow nesting, where making a copy of that state is helpful.) On a meta level, one thing we'll need to understand is how much change we want to absorb -- SenML as defined today is in use in various places. I'm not saying major change is wrong, all I'm saying is that this should be done as a conscious decision. Of course, we can also "pull a COSE" and decide to use a new format for CBOR and stay with the old format for JSON, but that also would need to be a conscious decision*). Grüße, Carsten *) In COSE it was easy to make this decision because the crypto aspect made sure that there is no easy conversion between COSE and JOSE. Here, there probably is. Obviously, the conversion could be required to do more than just JSON <-> COSE and some map key transcoding. Ari Keränen wrote: > That looks like a reasonable approach to me. Although, in the example > above, I guess we would need full "bn" also before the second > measurement array. From nobody Wed Jul 8 23:53:05 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A041AC3B3 for ; Wed, 8 Jul 2015 23:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=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 8UgcvUlaJYeN for ; Wed, 8 Jul 2015 23:53:03 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B9D1AC3B2 for ; Wed, 8 Jul 2015 23:53:02 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 9F0DF44964; Thu, 9 Jul 2015 08:53:00 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id B4DF523; Thu, 9 Jul 2015 08:52:59 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 83505376; Thu, 9 Jul 2015 08:52:59 +0200 (CEST) Received: (nullmailer pid 8287 invoked by uid 1000); Thu, 09 Jul 2015 06:52:59 -0000 Date: Thu, 9 Jul 2015 08:52:59 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Ari =?iso-8859-1?Q?Ker=E4nen?= Message-ID: <20150709065258.GC6381@hephaistos.amsuess.com> References: <20150708100906.GO10123@hephaistos.amsuess.com> <559D3F0B.3050101@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qtZFehHsKgwS5rPz" Content-Disposition: inline In-Reply-To: <559D3F0B.3050101@ericsson.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: draft-jennings-core-senml@tools.ietf.org, core Subject: Re: [core] Fwd: New Version Notification for draft-jennings-core-senml-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 06:53:05 -0000 --qtZFehHsKgwS5rPz Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Ari, On Wed, Jul 08, 2015 at 06:17:31PM +0300, Ari Ker=E4nen wrote: > >my embedded version currently throws an error when trailing "bn" values > >are encountered. It could be easily made to parse them in a single-block > >request, but for updates received in blockwise mode that's out of the > >question. >=20 > Do you mean that you currently support *only* base values in the beginnin= g? Yes, it only supports that ordering. That is not conformant to the draft, but for the header values i'm actually using ("bt", not "v") is easy to achieve even when using a full-featured JSON library (eg. using Python's sort_keys=3DTrue, which sorts "bn", "bt", "e", "v" and is thus happens to work for the time being). > >This would make implementing a correct SenML parser on a constrained > >system *much* easier, and might make other extensions easier as well > >(see "Nested elements for SenML" thread, switching there to stay on > >topic). >=20 > Could you please elaborate a bit how this makes parser easier? Do you mean > because of the fixed ordering? With arbitrary sequences, I have to parse twice through a structure I can't hold in memory. With fixed sequence (no matter how achieved), I can store the relevant "b" values in one data structure, update another to always contain the latest "e" element, and call back interested parties (eg. resources in the batch) all in one pass. Best regards Christian --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --qtZFehHsKgwS5rPz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVnhpHAAoJEDmNERLTpL3h+tkQAKo34416WswWQPqtUgycCTSj AFgJR2jHPxpIBbFlMCUqiTDT3TcXbTrf+QYc3NKNUW55rtdFMYcvj5BTx4EF6K/g 9u8FXcs8nbN4TfUk7gP7aRf8yoO2NfEmUCxagaHT22igCEQNRQewdFl9ESL5mvHB wGqDhfgCIdqP4UY5pIwFvSvXPH3EYDQoPZvDOuIeMwd18ptuA7zdT0ep0BLOQ2ka 8Z2WB54VtEJoGGl654rQUmKuzHvPrHKZQrdKns4cHjpMVv6H31mHx73FxFDijTBE 1S/R6+ShT7vFbXb3LO9e89gdfWnZ15gkubYa15mvhbBXbiZPsWLL7jloUMl9C0gm G78YWUYJhXBSKFi+Yz6kPYlzIeZd4Az0RP8DJL14ETQKCXdHRPRommvlwfp+CxSN 1O+BI1Qu7tg7z25U9F6IOCoD/4CYfJEmCirwG1+7HPYrhbBPreXp3kp1NL0j5Wva 9uyQnngVHuLESiaQScUdI6V6qQT2xpXGdXPvvPkwlYLfBacehsWY88f5L9FTFmM1 5buoqs+KQIxNUeGLPnm7Kw3D8p8zk2f/zI4HmBGVH7bjiP7Ccb/bwR556v2rTiPv Jmiw3eV1UnqydoK9C0lQ4RA8Rjg4dGgcVzpotw8xtm2P3BiGCg+967w6bUQ7VS1C rmF4RrohNw4APEuZS/TZ =2GCl -----END PGP SIGNATURE----- --qtZFehHsKgwS5rPz-- From nobody Thu Jul 9 00:28:55 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955A71AC42B for ; Thu, 9 Jul 2015 00:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.114 X-Spam-Level: X-Spam-Status: No, score=-0.114 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, MIME_8BIT_HEADER=0.3] autolearn=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 oUi9sjs5irTZ for ; Thu, 9 Jul 2015 00:28:50 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43D61AC40E for ; Thu, 9 Jul 2015 00:28:49 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 33BE54497F; Thu, 9 Jul 2015 09:28:47 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 18D7023; Thu, 9 Jul 2015 09:28:45 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id CC4EE376; Thu, 9 Jul 2015 09:28:44 +0200 (CEST) Received: (nullmailer pid 11245 invoked by uid 1000); Thu, 09 Jul 2015 07:28:44 -0000 Date: Thu, 9 Jul 2015 09:28:44 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Ari =?iso-8859-1?Q?Ker=E4nen?= , Carsten Bormann Message-ID: <20150709072843.GA6378@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <559D443A.7030307@tzi.org> <559D40D9.8040006@ericsson.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: draft-jennings-core-senml@tools.ietf.org, core Subject: Re: [core] Nested elements for SenML X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 07:28:51 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Ari, hallo Carsten, On Wed, Jul 08, 2015 at 06:25:13PM +0300, Ari Ker=E4nen wrote: > [ data about `urn:dev:mac:0024befffe804ff1/voltage` and `/current` ] > > That looks like a reasonable approach to me. Although, in the example abo= ve, > I guess we would need full "bn" also before the second measurement array. That, depends on the semantics of "bn". I've always seen "bn" like HTML's `base href=3D` or turtle's `@base`, updating the current base URI (initialized with the resource address) as relative URIs -- but that's being discussed in [1]. On Wed, Jul 08, 2015 at 05:39:38PM +0200, Carsten Bormann wrote: > Maybe the easiest way to phrase the semantics is that each map in that > top-level array is applied to the previous state of the variables as a > merge-patch (RFC 7386)?=20 That would rule out URI joining from one header group to the next, but if the resulting latest "bn" is always applied relative to the document's URI. In the above example, that would mean duplicating that base URI, but I'd be OK with it as it for sake of reusing both RFCs and code components. > (We could still allow nesting, where making a copy of that state is > helpful.) That would enable deduplication of the base URI again. We'd stil have to deal with nesting limitation and figure out a suitable syntax -- if there are use cases for it, why not. > On a meta level, one thing we'll need to understand is how much change > we want to absorb -- SenML as defined today is in use in various places. If this were only about nesting, I'd be more cautious about this, but with the issue of header sequence, existing implementations are either incomplete (like mine, requiring a sequence that is not specified or can not be provided by all implementations easily) or much more complex than they need to be (for parsing multi-block SenML with headers at the end). I don't see how this can be fixed in a backwards compatible way. At least, with the [header, events] format, it would be immediately obvious that a file is senml-01, and if parsers need to be compatible in a transition period, they can switch on the first character. Best regards Christian [1] https://mailarchive.ietf.org/arch/msg/core/I-dxnrJg2tvcY4LMv4sgSm8pWRU --=20 Christian Ams=FCss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVniKoAAoJEDmNERLTpL3hBu0QANDh1i6to3883wxAAjnS14Gh yr2pUMU04fFhiqSTUYSCKXK+fbh+Uxi2D5Rv6ROBh+AF7McdP334XSR6FV3dOW0O V+mfcqXww3eWklK1uqV5JoRcik1jWmZ8o/q0RKskubbHyE1dS0jM6u19C1h4dZo1 +iI5u3W4lxH8MQylvMC1qu6XGAefow0GjsltLDYfVTIMVWqHB/VPwy67G1tsUnnV em7XpHx7OkQNnseo+qljefuomz0ItqFf/UaaKOIToi0qF71UQi2CvPmNtF9Gdc1V rNK/mvcjdcqRRHqtQ+RWX/jyQeMHgRdpra9cMRUEEETUGSX+7AaM55hCq5BarNLG 2/wzfERkueCbcK4YttgZ4W4aOYysrUmrgQZ1cQS4qEXMS9+CvrDG9GN2FJR3Inkg PjbdHyEn3hBQcY8y4QFdI9WcY3B5NvgsX7OISo/txbIb29tegtO22lqghfxA+J2F C3AOU15FGctBBdtL7ZU9HWwNVtNS808uQx+7wr/GhUT7YlTi/LUyR1ZCQeKZVb+j cQxaYP5diuiPuJlxijAEVmCKXKgJ75iRggt8JRVaYGvAzCSsHQFo0bbD/i/QYgde od6pVUrU9a8iPMeN0xGbOAeqiszvizE/0Y8D6M47h0zUUtG6KjJI3oHvyTc0X+bk J9vn7vb2idQU+kRxOm2/ =Lz8h -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From nobody Thu Jul 9 02:15:27 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505111A21C3 for ; Thu, 9 Jul 2015 02:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIXwF-LF3WYv for ; Thu, 9 Jul 2015 02:15:24 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9431A6F2E for ; Thu, 9 Jul 2015 02:15:23 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id t699FGSE002928; Thu, 9 Jul 2015 11:15:17 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 3827D1D53C1; Thu, 9 Jul 2015 11:15:16 +0200 (CEST) Received: from 79.144.153.111 by webmail.entel.upc.edu with HTTP; Thu, 9 Jul 2015 11:16:08 +0200 Message-ID: In-Reply-To: References: Date: Thu, 9 Jul 2015 11:16:08 +0200 From: "Carles Gomez Montenegro" To: "Alper Kamil Demir" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: ACL matched, not delayed by milter-greylist-4.4.3 (dash.upc.es [147.83.2.50]); Thu, 09 Jul 2015 11:15:17 +0200 (CEST) Archived-At: Cc: core@ietf.org Subject: Re: [core] A Research on Setting Transmission Parameters Configured to Values Specific to the Application Environment X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 09:15:26 -0000 Hi Alper, Our team has contributed to the design and evaluation of CoCoA, which adapts ACK_TIMEOUT on the basis of RTT samples [1]. We also experimented with alternative NSTART values (using CoCoA) and alternative ACK_TIMEOUT values (using default CoAP) [2]. I am not aware of research work evaluating the influence of the other parameters you mention on CoAP performance. I hope this helps! Best regards, Carles [1] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoCoA+: an advanced congestion control mechanism for CoAP", Ad-hoc Networks journal, 2015. [2] A. Betzler, C. Gomez, I. Demirkol, M. Kovatsch, "Congestion Control for CoAP cloud services", 8th International Workshop on Service-Oriented Cyber-Physical Systems in Converging Networked Environments (SOCNE) 2014, Barcelona, Spain, Sept. 2014. > Is there any research paper on setting CoAP transmission parameters > (Chapter > 4.8) configured to values specific to the application environment? > > Because RFC7252 states that: > The values for ACK_TIMEOUT, ACK_RANDOM_FACTOR, MAX_RETRANSMIT, > NSTART, DEFAULT_LEISURE (Section 8.2), and PROBING_RATE may be > configured to values specific to the application environment > (including dynamically adjusted values); however, the configuration > method is out of scope of this document. > > Best regards, > Alper K. Demir_______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From william.bertier@inria.fr Fri Jul 10 07:14:40 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1931B2C55 for ; Fri, 10 Jul 2015 07:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbEwooabDlvr for ; Fri, 10 Jul 2015 07:14:36 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328871B2C5A for ; Fri, 10 Jul 2015 07:14:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,446,1432591200"; d="scan'208,217";a="169763812" Received: from zmbs2.inria.fr ([128.93.142.15]) by mail2-relais-roc.national.inria.fr with ESMTP; 10 Jul 2015 16:14:34 +0200 Date: Fri, 10 Jul 2015 16:14:34 +0200 (CEST) From: William Bertier To: core@ietf.org Message-ID: <1931277357.4267342.1436537674832.JavaMail.zimbra@inria.fr> In-Reply-To: <1410780645.4260510.1436536900559.JavaMail.zimbra@inria.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4267341_2079367684.1436537674832" X-Originating-IP: [131.254.12.159] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF38 (Linux)/8.0.9_GA_6191) Thread-Topic: Search catch for interoperability tests Thread-Index: XAwHRsT3P5k4QD2UCx9Ffff904Q/pA== Archived-At: X-Mailman-Approved-At: Fri, 10 Jul 2015 09:51:52 -0700 Subject: [core] Search catch for interoperability tests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 10 Jul 2015 14:19:43 -0000 ------=_Part_4267341_2079367684.1436537674832 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, I am in intership at INRIA research laboratory of Rennes (France). I'm in a team that developed in 2013 a software that carries out interoperability testing. With a wireshark catch (.pcap, .dump), the software checks the compliance of exchanges. My goal is to update the software with the RFC7252 , draft-ietf-core-observe-16 and draft-ietf-core-block-17 . The description of the software : http://www.irisa.fr/tipi/wiki/doku.php/passive_validation_tool_for_coap To use the software, it is online: http://senslab2.irisa.fr/coap/ I am currently developing new test but I can unfortunately not tested due to lack of wireshark catch. I am contacting you because I would like catch (.pcap, .dump), mainly catch that uses the functions observe and block. This would allow you to test your implementation and me to test my new tests. If you provide me catch I assure you that they will be used for my tests and will be deleted afterwards. You can also provide me implementations, I am currently trying https://github.com/openwsn-berkeley/coap Thank you William Bertier ------=_Part_4267341_2079367684.1436537674832 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

I am in= intership at INRIA research laboratory of Rennes (France).

I'm in a team that developed in 2013 a software that carries out interop= erability testing.
With a wireshark catch (.pcap, .dump), the software c= hecks the compliance of exchanges.

My goal is to update t= he software with the RFC7252 , draft-ietf-core-observ= e-16 and dra= ft-ietf-core-block-17.
The description of the software:
To = use the software, it is online:
http://senslab2.irisa.fr/coap/

I am currently deve= loping new test but I can unfortunately not tested due to lack of wireshark= catch.
I am contacting you because I would like catch (.pcap, .dump), m= ainly catch that uses the functions observe and block.

This would allow you to test your implementation and me to test my ne= w tests.


If you provide me catch I assure yo= u that they will be used for my tests and will be deleted afterwards.
Yo= u can also provide me implementations, I am currently trying https://github.com/openwsn-berkeley/= coap

Thank you
William Bertier
<= /html> ------=_Part_4267341_2079367684.1436537674832-- From nobody Fri Jul 10 09:59:50 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A281B2A3E for ; Fri, 10 Jul 2015 09:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 ZGXnVSoUlZrW for ; Fri, 10 Jul 2015 09:59:47 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (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 88E371B2A3F for ; Fri, 10 Jul 2015 09:59:47 -0700 (PDT) Received: by wgxm20 with SMTP id m20so70914367wgx.3 for ; Fri, 10 Jul 2015 09:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=tLABdYG0t/+Yt/kjgHwzEtWuY3PM9CDawk5wA+4v35E=; b=GBxiJK5Tk3tDsxJHIL3cg7TwJwfqQVRK5v9gIbPtoz844K6A6qwX1iaPwBTl7w5cNZ 9FrHUALTRMuPcOmTTZuhWj70rw+hCeyyhub2Xd8M8+8xz1/TQJgbDF6dukiR5bR67Z0i qRYuBHmVVqF0/2pGN2DgHwbZ53SWT1qZRyVPyAOvOLnWGID2MijGELKaThUm9UX5+3s+ 6jyCQwXakkyujXeR0XIA8p7x1qzu68dwAQFqgnXJDxk6Yd8rQ4vd2GGi0bQ3IW8/Dv3x z903smaKPANoqoB7DLkxEKmAX0E7oWmxAvBUdYt1NCvsVy3a8QddhwQkI3t+BoZzjsEP fdGg== X-Received: by 10.180.81.103 with SMTP id z7mr7638362wix.21.1436547586335; Fri, 10 Jul 2015 09:59:46 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.28.134.146 with HTTP; Fri, 10 Jul 2015 09:59:26 -0700 (PDT) In-Reply-To: <1931277357.4267342.1436537674832.JavaMail.zimbra@inria.fr> References: <1410780645.4260510.1436536900559.JavaMail.zimbra@inria.fr> <1931277357.4267342.1436537674832.JavaMail.zimbra@inria.fr> From: Thomas Watteyne Date: Fri, 10 Jul 2015 18:59:26 +0200 X-Google-Sender-Auth: z7Y-8R9TwPtBgvBnl2V9m71kuMI Message-ID: To: William Bertier Content-Type: multipart/alternative; boundary=f46d044288cc9628db051a884cb6 Archived-At: Cc: core Subject: Re: [core] Search catch for interoperability tests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 10 Jul 2015 16:59:49 -0000 --f46d044288cc9628db051a884cb6 Content-Type: text/plain; charset=UTF-8 William, If you want to see block transfer "live", point your Firefox CoPPER extension to http://vs0.inf.ethz.ch/. You might be interested in http://coap.me/ which provides similar functionality to what you describe The OpenWSN CoAP library does not implement observe (see https://openwsn.atlassian.net/wiki/display/OW/CoAP+Python+Library for a list of what it does/does not implement). You're more than welcome to add it. You might also enjoy the test infrastrcture Thomas Thomas On Fri, Jul 10, 2015 at 4:14 PM, William Bertier wrote: > Hello, > > I am in intership at INRIA research laboratory of Rennes (France). > > I'm in a team that developed in 2013 a software that carries out > interoperability testing. > With a wireshark catch (.pcap, .dump), the software checks the compliance > of exchanges. > > My goal is to update the software with the RFC7252 > , draft-ietf-core-observe-16 > and > draft-ietf-core-block-17 > . > The description of the software: > http://www.irisa.fr/tipi/wiki/doku.php/passive_validation_tool_for_coap > To use the software, it is online: > http://senslab2.irisa.fr/coap/ > > I am currently developing new test but I can unfortunately not tested due > to lack of wireshark catch. > I am contacting you because I would like catch (.pcap, .dump), mainly > catch that uses the functions observe and block. > > *This would allow you to test your implementation and me to test my new > tests.* > > > If you provide me catch I assure you that they will be used for my tests > and will be deleted afterwards. > You can also provide me implementations, I am currently trying > https://github.com/openwsn-berkeley/coap > > Thank you > William Bertier > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --f46d044288cc9628db051a884cb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
William,

If you want to see block trans= fer "live", point your Firefox CoPPER extension to=C2=A0http://vs0.inf.ethz.ch/.

You might be interested in=C2=A0http://= coap.me/ which provides similar functionality to what you describe

The OpenWSN CoAP library does not implement observe (s= ee https://openwsn.atlassian.net/wiki/display/OW/CoAP+Python+Library= for a list of what it does/does not implement). You're more than welco= me to add it. You might also enjoy the test infrastrcture

Thomas

Thomas


On F= ri, Jul 10, 2015 at 4:14 PM, William Bertier <william.bertier@inri= a.fr> wrote:
Hello,

I am in intership at INRIA research = laboratory of Rennes (France).

I'm in a team that dev= eloped in 2013 a software that carries out interoperability testing.
Wit= h a wireshark catch (.pcap, .dump), the software checks the compliance of e= xchanges.

My goal is to update the software with the RFC7252 ,= =C2=A0draft-ietf-core-observe-16 and draft-ietf-core-bl= ock-17.
The description of the software:
htt= p://www.irisa.fr/tipi/wiki/doku.php/passive_validation_tool_for_coap
To use the software, it is online:
http://senslab2.irisa.fr/coap/
=
I am currently developing new test but I can unfortunately not te= sted due to lack of wireshark catch.
I am contacting you because I would= like catch (.pcap, .dump), mainly catch that uses the functions observe an= d block.

This would allow you to test your implem= entation and me to test my new tests.


If you= provide me catch I assure you that they will be used for my tests and will= be deleted afterwards.
You can also provide me implementations, I am cu= rrently trying https://github.com/openwsn-berkeley/coap

= Thank you
William Bertier=

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


--f46d044288cc9628db051a884cb6-- From nobody Sun Jul 12 15:38:45 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94F71A89A9; Sun, 12 Jul 2015 15:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoeVyT7In3J9; Sun, 12 Jul 2015 15:38:42 -0700 (PDT) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id BE6151A894F; Sun, 12 Jul 2015 15:38:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 0B6352DB5; Mon, 13 Jul 2015 00:38:41 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon22.um.es Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id onjM2-cPCLU0; Mon, 13 Jul 2015 00:38:40 +0200 (CEST) Received: from [192.168.1.33] (212.Red-81-37-9.dynamicIP.rima-tde.net [81.37.9.212]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon22.um.es (Postfix) with ESMTPSA id 1C5F82DB2; Mon, 13 Jul 2015 00:38:36 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Rafa Marin Lopez In-Reply-To: <559A9E7F.7030709@ackl.io> Date: Mon, 13 Jul 2015 00:38:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <559A9E7F.7030709@ackl.io> To: Alexander Pelov X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Yannick Delibie , Laurent Toutain , t2trg@irtf.org, core@ietf.org, 6tisch@ietf.org Subject: Re: [core] [6tisch] Annoncement draft-pelov-core-cosol-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 12 Jul 2015 22:38:44 -0000 Hi Alexander=20 This is interesting work and use case.=20 Some comments: "It can be used during all stages of the lifecycle of the network, e.g. discovery, authentication, operation. " --> Basically = authentication is based on DTLS... is that what you mean? Figure 3 says associated then authenticated but in the text is different = authenticated -> associated In semi-associated state you mention: "In that state, the Node-F = broadcasts frames, handled by the Node-G, but the network cannot join the Node-F on a regular basis." What do = you mean? The node-G cannot contact node-F?=20 In section 3.3.1: "The frames SHOULD be signed, so that they could be authenticated by the network." This signing = process is before the authentication and key management. How is it = possible to sign the frames? Any pre-shared key? In fact, you say: "and enough information for the Node-G to authenticate the message sender. This can be achieved through a Confirmable CoAP message, where the user data are POSTed to a well- known resource defined on the Node-G. DTLS with integrity check can be used, with long-lived keys negotiated by the Node-F and the network." DTLS is established for protection (Confirmable CoAP message does not = achieve authentication by itself). Again, if DTLS is used and those = messages are authenticated, why do you need authentication phase? In section 3.3.3: "For example, it may provide the AAA server, which could authenticate the Node-F, or its EAP-Identity. " --> Assuming that an AAA = infrastructure is used for authentication ( I think that assumption = should be expressed in the document), typically Node G will have the AAA = client and, actually, it does not need to know the IP address of the AAA = server that authenticates the node F, just the next hop AAA server. On = the other hand, Node G will not typically provide the EAP identity, are = you referring to that? In section 3.3.4=20 The reference to EAP-over-CoAP is = https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-01 and not = [I-D.garcia-core-security] where the general problem of bootstrapping is = explained.=20 Hope this helps. Best Regards. El 06/07/2015, a las 17:27, Alexander Pelov escribi=F3: > Dear all, >=20 > I'd like to bring to your attention a new document, which was = submitted this weekend: draft-pelov-core-cosol-00 >=20 > It presents a new type of far-reaching, low-rate radio technologies = (such as Semtech LoRa and SigFox) and an extensible mechanism to operate = these networks based on CoAP. We document the way REST can be used to = manage these networks. >=20 > You can find the current text at the following address: = https://tools.ietf.org/html/draft-pelov-core-cosol-00 >=20 > We would be happy to discuss with anyone interested the contents of = the draft and the possible future works on it. Also, we will be glad if = there is any possibility to present even briefly during a session. >=20 > Best, > Alexander >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Sun Jul 12 16:17:12 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9C71A8AFE for ; Sun, 12 Jul 2015 16:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfrdxWrPmMRg for ; Sun, 12 Jul 2015 16:17:09 -0700 (PDT) Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com [209.85.160.172]) (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 E61C01A8AFC for ; Sun, 12 Jul 2015 16:17:08 -0700 (PDT) Received: by ykee186 with SMTP id e186so101805112yke.2 for ; Sun, 12 Jul 2015 16:17:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=w+6/jypaiEkUY00fMYAHN8JN9LAXO6TwWLVF3qt0XA4=; b=Y9bcioZ1v6TvnFKdweNF1bqOmPj7YiX8FOJJ2rugtEZrq/J5gGgiZK4q9u9Q2eUX9e 0kbRP9d6C1a3WcTb+tD4N93aPZBYr3hgjdm8QXaNhZkKspjappw29ZYANjbjnF3jG4c8 15UMYa6IY4HYpMqtAEt+esgiDlimJV2zZd6FkqpZUJlUZgzT4seviZ/CLkU9cR+ZG0Q6 ngExLx2sQLRyiYOZEpIWaVjKYcxHwnTLunQk8/ujq9107oEdqehYu044mMlywMpHsxFB G8v/+LYZioVtLu0WtM5tx9NpgAlRJZQzLGahnqbiWD995r7e+21jOzHIWIBuGdhqJ+Kc QHhQ== X-Gm-Message-State: ALoCoQk/LroNFPMTTwb/YOsmM4Fnfs+P2T/pn3tA9iBrx2zBI3yGXHPeGjeYcP804Q966uDnaTtw X-Received: by 10.170.132.74 with SMTP id y71mr35871538ykb.112.1436743028201; Sun, 12 Jul 2015 16:17:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.245.195 with HTTP; Sun, 12 Jul 2015 16:16:28 -0700 (PDT) From: Benjamin Black Date: Sun, 12 Jul 2015 16:16:28 -0700 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary=001a1138e85ad48f3c051ab5cd29 Archived-At: Subject: [core] comments and support for draft-carey-core-std-msg-vs-trans-adapt-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 12 Jul 2015 23:17:10 -0000 --001a1138e85ad48f3c051ab5cd29 Content-Type: text/plain; charset=UTF-8 i have been experimenting with coap for several months for use in production iot applications. i find its design much cleaner and mature than things like mqtt. the main weakness i have encountered is lack of support for a connection-oriented transport. many deployments will involve needing to connect through 3rd party nat or proxy systems that will not support the required udp communication or http-coap translation. reading the tcp and websockets drafts i was disappointed that they involved significant changes to the protocol semantics. i wholeheartedly agree with everything in draft-carey-core-std-msg-vs-trans-adapt-00. there is an additional concern not mentioned in that draft that i believe critical. as mentioned in the tcp draft, rfc7252 does not specify a message length field, instead assuming the transport is able to delineate records. tcp lacks this, requiring additional modifications to the message structure. i support the following: 1) adoption of the (standard ietf) recommendation in draft-carey-core-std-msg-vs-trans-adapt-00 to cleanly delineate the standard message layer from the transport. 2) adoption of the recommendation in draft-carey-core-std-msg-vs-trans-adapt-00 to maintain strict adherence to rfc7252 for that standard message layer. 3) adoption of the recommendation in draft-carey-core-std-msg-vs-trans-adapt-00 to require definitions of new transports specify how they implement the standard set of messaging primitives. 4) further to #3, require transports either support record delineation (as websockets does) or define a record envelope to encapsulate standard messages (as tcp would). failing to adopt these 4 points will, i believe, significantly increase implementation complexity for coap frameworks and for applications using them. worse, this increase in complexity will deliver no benefits. even something as otherwise flawed as mqtt gets this right. without coap adopting these, i and others will have to choose between using an inferior protocol like mqtt or implementing tcp and websockets coap in non-standard but reasonable ways.. b --001a1138e85ad48f3c051ab5cd29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
i have been e= xperimenting with coap for several months for use in production iot applica= tions. i find its design much cleaner and mature than things like mqtt. the= main weakness i have encountered is lack of support for a connection-orien= ted transport. many deployments will involve needing to connect through 3rd= party nat or proxy systems that will not support the required udp communic= ation or http-coap translation.

reading the tc= p and websockets drafts i was disappointed that they involved significant c= hanges to the protocol semantics. i wholeheartedly agree with everything in= =C2=A0draft-carey-core-std-msg-vs-trans-adapt-00. there is an additional co= ncern not mentioned in that draft that i believe critical. as mentioned in = the tcp draft, rfc7252 does not specify a message length field, instead ass= uming the transport is able to delineate records. tcp lacks this, requiring= additional modifications to the message structure.

i support the following:

1) adoption of th= e (standard ietf)=C2=A0recommendation=C2=A0in draft-carey-core-std-msg-vs-t= rans-adapt-00 to cleanly=C2=A0delineate the standard message layer from the= transport.
2) adoption of= the recommendation in draft-carey-core-std-msg-vs-trans-adapt-00 to mainta= in strict adherence to rfc7252 for that standard message layer.
3) adoption of the recommendation in = draft-carey-core-std-msg-vs-trans-adapt-00 to require definitions of new tr= ansports specify how they implement the standard set of messaging primitive= s.
4) further to #3, r= equire transports either support record delineation (as websockets does) or= define a record envelope to encapsulate standard messages (as tcp would).<= /div>

failing to adopt these 4 points will, i believe= , significantly increase implementation complexity for coap frameworks and = for applications using them. worse, this increase in complexity will delive= r no benefits. even something as otherwise flawed as mqtt gets this right. = without coap adopting these, i and others will have to choose between using= an inferior protocol like mqtt or implementing tcp and websockets coap in = non-standard but reasonable ways..


b
--001a1138e85ad48f3c051ab5cd29-- From nobody Mon Jul 13 13:25:24 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4591A88AB; Mon, 13 Jul 2015 13:25:22 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3Q1avELqEXp; Mon, 13 Jul 2015 13:25:19 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0A51A8845; Mon, 13 Jul 2015 13:25:19 -0700 (PDT) Received: from mfilter25-d.gandi.net (mfilter25-d.gandi.net [217.70.178.153]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 9EC8741C04E; Mon, 13 Jul 2015 22:25:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter25-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter25-d.gandi.net (mfilter25-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 73U0JtBzuCGh; Mon, 13 Jul 2015 22:25:16 +0200 (CEST) X-Originating-IP: 85.68.132.137 Received: from Zax-2.local (abo-137-132-68.bdx.modulonet.fr [85.68.132.137]) (Authenticated sender: alex@ackl.io) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 52F8C41C053; Mon, 13 Jul 2015 22:25:15 +0200 (CEST) To: Rafa Marin Lopez References: <559A9E7F.7030709@ackl.io> From: Alexander Pelov Message-ID: <55A41EAA.3000307@ackl.io> Date: Mon, 13 Jul 2015 22:25:14 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6tisch@ietf.org, t2trg@irtf.org, Laurent Toutain , core@ietf.org, Yannick Delibie Subject: Re: [core] Annoncement draft-pelov-core-cosol-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 20:25:22 -0000 Dear Rafa, Thanks for the comments! Please, see inline. Le 13/07/2015 00:38, Rafa Marin Lopez a =E9crit : > Hi Alexander > > This is interesting work and use case. > > Some comments: > > "It can be used during all stages of the lifecycle of the network, > e.g. discovery, authentication, operation. " --> Basically authenti= cation is based on DTLS... is that what you mean? Actually, here we are referring to the use of your draft - EAP-over-CoAP=20 - for the authentication. Upon authentication, the exchanges may be=20 protected with DTLS (which uses the MSK generated after the EAP=20 exchanges), or with the AUTH option you are proposing. I think that this=20 should be the recommended way to do authentication in LRWANs. However, one can imagine having DTLS negotiation (e.g. with PSK), but=20 this seems less flexible and appropriate for this types of networks. What do you think? > Figure 3 says associated then authenticated but in the text is differen= t authenticated -> associated That's a typo. Thanks for catching that - the text is correct, the=20 schema is wrong. It should be "authenticated -> associated". > > In semi-associated state you mention: "In that state, the Node-F broadc= asts frames, handled by the Node-G, > but the network cannot join the Node-F on a regular basis." What do= you mean? The node-G cannot contact node-F? The goal behind the semi-associated state is that there are some network=20 operators that rely heavily on uni-directional traffic (node-F to=20 node-G). Also, there are services which can be implemented in that way=20 (e.g. tracking goods). There CAN be L2 interaction (e.g. L2 ACK), or in=20 some cases even CoAP ACK, but that is not a necessary condition for many=20 applications. To sum up, the case to imagine is a device, which wakes up periodically,=20 and without checking any connectivity or other types of information,=20 sends a message to the network, after which it sleeps again. If there is=20 a network present, and a node-G willing to process the message, then=20 everything works. I strongly believe that this behavior should be managed carefully (e.g.=20 a node-F MUST send a CoAP CONfirmable message every N messages), giving=20 the opportunity to the network to actually interact with the node-F from=20 time to time. Once again, this is a real-world operation scheme of an IoT network=20 operator. > > In section 3.3.1: > > "The frames SHOULD be signed, > so that they could be authenticated by the network." This signing p= rocess is before the authentication and key management. How is it possibl= e to sign the frames? Any pre-shared key? > > In fact, you say: > > "and enough information for the Node-G to > authenticate the message sender. This can be achieved through a > Confirmable CoAP message, where the user data are POSTed to a well- > known resource defined on the Node-G. DTLS with integrity check ca= n > be used, with long-lived keys negotiated by the Node-F and the > network." > > DTLS is established for protection (Confirmable CoAP message does not a= chieve authentication by itself). Again, if DTLS is used and those messag= es are authenticated, why do you need authentication phase? Here I think that one of the transitions in Figure 3 is making the=20 things more complex than it should (and is causing a lot of questions).=20 The Disconnected -> Semi-associated state should be removed. The=20 reasoning behind is, that the device (node-F) MUST authenticate at least=20 once to the network before entering the semi-associated state. This way,=20 there is a secure association between the network and the node-F. The=20 node-F can then sleep for (very) long periods, wake up, and send a=20 signed message to the network. The tricky part is that in the mean time the node-F could have moved and=20 could be located in a different part of the network, e.g. located under=20 a different node-G. For that reason, the sent message should contain=20 enough information, so that a node-G receiving a signer CoAP message=20 could determine the secure association (e.g. to which other node-G in=20 the network it is associated), and forward the message. Note that it may=20 be appropriate to use Constrained Object Signing and Encryption (COSE),=20 instead (in addition of) DTLS. > > In section 3.3.3: > > "For example, it may provide the AAA server, which could authenticate > the Node-F, or its EAP-Identity. " --> Assuming that an AAA infrast= ructure is used for authentication ( I think that assumption should be ex= pressed in the document), typically Node G will have the AAA client and, = actually, it does not need to know the IP address of the AAA server that = authenticates the node F, just the next hop AAA server. On the other hand= , Node G will not typically provide the EAP identity, are you referring t= o that? Yes, you are correct. > > In section 3.3.4 > > The reference to EAP-over-CoAP is https://tools.ietf.org/html/draft-mar= in-ace-wg-coap-eap-01 and not [I-D.garcia-core-security] where the genera= l problem of bootstrapping is explained. Thanks for catching this! > > Hope this helps. > > Best Regards. Thanks a lot for your remarks! Best, Alexander > > > El 06/07/2015, a las 17:27, Alexander Pelov escribi=F3: > >> Dear all, >> >> I'd like to bring to your attention a new document, which was submitte= d this weekend: draft-pelov-core-cosol-00 >> >> It presents a new type of far-reaching, low-rate radio technologies (s= uch as Semtech LoRa and SigFox) and an extensible mechanism to operate th= ese networks based on CoAP. We document the way REST can be used to mana= ge these networks. >> >> You can find the current text at the following address: https://tools.= ietf.org/html/draft-pelov-core-cosol-00 >> >> We would be happy to discuss with anyone interested the contents of th= e draft and the possible future works on it. Also, we will be glad if the= re is any possibility to present even briefly during a session. >> >> Best, >> Alexander >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- > > > > From nobody Tue Jul 14 09:56:49 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F2E1A8A4A for ; Tue, 14 Jul 2015 09:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKzCwDrLmuWF for ; Tue, 14 Jul 2015 09:56:44 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.20]) by ietfa.amsl.com (Postfix) with ESMTP id 101181A8A46 for ; Tue, 14 Jul 2015 09:56:44 -0700 (PDT) Received: from userPC (unknown [122.167.65.129]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 4AFDE782F1B; Tue, 14 Jul 2015 16:56:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1436893003; bh=4MWehSynMX5OjVEuTBKOYxiXUzOZbEO/2+A5E28DtyA=; h=From:To:References:In-Reply-To:Subject:Date; b=Q2cDnD4QAHHsdQVL/O3hM32/T8cyzZ7CYnPVwWKtREqdv+S+aa0S6ZheqGkC6tnHF YmtjWOmTkp0PDAypMo0LyeYQXHvNdFraS4GK3aYRApFcZKaH4QK6lpHPtXW0YRzdrv nzXj9GksKYi55HuAaUAwaRVro9vGZP/87NO9uMT4= From: "Parthasarathi R" To: "'Carsten Bormann'" , References: <20150610214625.13443.77214.idtracker@ietfa.amsl.com> <5578B194.9050309@tzi.org> In-Reply-To: <5578B194.9050309@tzi.org> Date: Tue, 14 Jul 2015 22:26:36 +0530 Message-ID: <007601d0be56$0dec76d0$29c56470$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdCjx8HcEc3PBTHeQlGAPADMId1OLAajHwrg Content-Language: en-us X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=I/SYP4Ug c=1 sm=1 tr=0 a=WrnpueKk+KlqM0udTFK8sQ==:117 a=WrnpueKk+KlqM0udTFK8sQ==:17 a=-NIMs_s3AAAA:8 a=VQADlPdMAAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=ZZnuYtJkoWoA:10 a=48vgC7mUAAAA:8 a=spx1DZ923Fx0K8Jb_rUA:9 a=IC1ZlT4mcp2RauWD:21 a=bd4eIkoCDrMMS9nf:21 a=QEXdDO2ut3YA:10 Archived-At: Subject: Re: [core] Fwd: New Version Notification for draft-tschofenig-core-coap-tcp-tls-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 16:56:46 -0000 Hi Carsten, The draft looks good and it will be useful in case deploying in the = internet wherein the network is behind NAT/firewall. I have few initial comments in CoAP+tcp URI scheme section (sec 6) are = as follows:=20 1) I could not understand the need for the separate namespace. The = actual requirement is to mention the transport for the resource than the = resource itself. It is preferred to mention the transport type as a = parameter rather than URI scheme.=20 2) CoAP TCP shall use the default port as 80. The advantage of 80 as = default port is that the traversal through firewall is better w.r.t TCP = port 80. Regards Partha > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Thursday, June 11, 2015 3:22 AM > To: core@ietf.org WG > Subject: [core] Fwd: New Version Notification for draft-tschofenig- > core-coap-tcp-tls-04.txt >=20 > I have submitted a slight update to the coap-tcp-tls draft. >=20 > Apart from a number of editorial improvements, this now includes three > alternative proposals for the frame length representation. Reasoned > comments why we should or should not veer off the simple 16-bit length > (called alternative L1 in the draft), and, if yes, into which = direction > (L2? L3? what else?), are welcome. >=20 > This is not yet integrated with the text from the websockets draft. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for > draft-tschofenig-core-coap-tcp-tls-04.txt >=20 > A new version of I-D, draft-tschofenig-core-coap-tcp-tls-04.txt > has been successfully submitted by Carsten Bormann and posted to the > IETF repository. >=20 > Name: draft-tschofenig-core-coap-tcp-tls > Revision: 04 > Title: A TCP and TLS Transport for the Constrained > Application Protocol > (CoAP) > Document date: 2015-06-10 > Group: Individual Submission > Pages: 14 > URL: > https://www.ietf.org/internet-drafts/draft-tschofenig-core-coap-tcp- > tls-04.txt > Status: > https://datatracker.ietf.org/doc/draft-tschofenig-core-coap-tcp-tls/ > Htmlized: > https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-04 > Diff: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-tschofenig-core-coap-tcp-tls-04= >=20 > Abstract: > The Hypertext Transfer Protocol (HTTP) has been designed with TCP = as > an underlying transport protocol. The Constrained Application > Protocol (CoAP), which has been inspired by HTTP, has on the other > hand been defined to make use of UDP. Therefore, reliable delivery > and a simple congestion control and flow control mechanism are > provided by the message layer of the CoAP protocol. >=20 > A number of environments benefit from the use of CoAP directly over > a > reliable byte stream that already provides these services. This > document defines the use of CoAP over TCP as well as CoAP over TLS. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Jul 14 13:40:40 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C681A88A4 for ; Tue, 14 Jul 2015 13:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.971 X-Spam-Level: X-Spam-Status: No, score=0.971 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35] autolearn=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 ET6LauRrbnvh for ; Tue, 14 Jul 2015 13:40:38 -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 CE62E1A88A1 for ; Tue, 14 Jul 2015 13:40:37 -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 t6EKeZCi001538 for ; Tue, 14 Jul 2015 22:40:35 +0200 (CEST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mWDJ31WnpzD3Qd for ; Tue, 14 Jul 2015 22:40:35 +0200 (CEST) Received: by wicmv11 with SMTP id mv11so23986173wic.1 for ; Tue, 14 Jul 2015 13:40:34 -0700 (PDT) X-Received: by 10.180.95.35 with SMTP id dh3mr36792464wib.30.1436906434881; Tue, 14 Jul 2015 13:40:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.21.201 with HTTP; Tue, 14 Jul 2015 13:39:55 -0700 (PDT) In-Reply-To: References: From: Klaus Hartke Date: Tue, 14 Jul 2015 22:39:55 +0200 Message-ID: To: Benjamin Black Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] comments and support for draft-carey-core-std-msg-vs-trans-adapt-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 20:40:38 -0000 Benjamin Black wrote: > i support the following: Can you expand on the "why" of this? What are you missing that would be provided by CON/ACK/NON/RST over TCP/WebSockets? Klaus From nobody Tue Jul 14 22:44:29 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B221A6EF2 for ; Tue, 14 Jul 2015 22:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 l_L2klvhhd5G for ; Tue, 14 Jul 2015 22:44:26 -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 179AC1A21BC for ; Tue, 14 Jul 2015 22:44:25 -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 t6F5iMoS018562; Wed, 15 Jul 2015 07:44:22 +0200 (CEST) Received: from alma.local (p5DC7ED13.dip0.t-ipconnect.de [93.199.237.19]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mWSMV16J6zD3LG; Wed, 15 Jul 2015 07:44:22 +0200 (CEST) Message-ID: <55A5F334.2040408@tzi.org> Date: Wed, 15 Jul 2015 07:44:20 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Parthasarathi R References: <20150610214625.13443.77214.idtracker@ietfa.amsl.com> <5578B194.9050309@tzi.org> <007601d0be56$0dec76d0$29c56470$@co.in> In-Reply-To: <007601d0be56$0dec76d0$29c56470$@co.in> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core@ietf.org Subject: Re: [core] Fwd: New Version Notification for draft-tschofenig-core-coap-tcp-tls-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 05:44:28 -0000 Hi Partha, thank you for your input. Parthasarathi R wrote: > Hi Carsten, > > The draft looks good and it will be useful in case deploying in the internet wherein the network is behind NAT/firewall. > > I have few initial comments in CoAP+tcp URI scheme section (sec 6) are as follows: > > 1) I could not understand the need for the separate namespace. The actual requirement is to mention the transport for the resource than the resource itself. It is preferred to mention the transport type as a parameter rather than URI scheme. This is less about stating a need than a statement about the way URIs work. A new scheme does generate a new URI namespace (e.g., http:// vs. https://). A server is of course free to mirror the two namespaces for, say, coap:// and coap+tcp://. (We already have separate namespaces for coap:// and coaps://, see section 6.2 of RFC 7252: Resources made available via the "coaps" scheme have no shared identity with the "coap" scheme even if their resource identifiers indicate the same authority (the same host listening to the same UDP port). They are distinct namespaces and are considered to be distinct origin servers. ) Trying to unify the namespaces for coap:// and coap+tcp:// (and, probably, similarly for coaps:// and coaps+tcp://) is an interesting idea; I'm not sure what the consequences of such a somewhat fundamental change would be. > 2) CoAP TCP shall use the default port as 80. The advantage of 80 as default port is that the traversal through firewall is better w.r.t TCP port 80. I'm not sure that would work too well in practice, as many firewalls do expect HTTP/1-like traffic on port 80. (It would work with simple packet filters.) More importantly, port 80 is HTTP's port (HTTP/1.1, to be precise); do you expect servers to operate some heuristic to distinguish CoAP from HTTP requests? Or should there be an upgrade dance as in section 3.2 of RFC 7540? (Maybe specifying such an upgrade dance for switching from HTTP/1.1 to CoAP is a good thing to have handy...) You are certainly free to use port 80 in a specific deployment where you can make sure there is no conflict with HTTP, it is just not a very good candidate for the default port. Grüße, Carsten From nobody Wed Jul 15 00:24:07 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE781A87E6 for ; Wed, 15 Jul 2015 00:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.259 X-Spam-Level: X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAWBHOQ-HmHw for ; Wed, 15 Jul 2015 00:24:02 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3204D1A87E0 for ; Wed, 15 Jul 2015 00:24:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,477,1432591200"; d="scan'208,217";a="170202415" Received: from zmbs2.inria.fr ([128.93.142.15]) by mail2-relais-roc.national.inria.fr with ESMTP; 15 Jul 2015 09:24:00 +0200 Date: Wed, 15 Jul 2015 09:24:00 +0200 (CEST) From: William Bertier To: Thomas Watteyne Message-ID: <1220732518.4891641.1436945040727.JavaMail.zimbra@inria.fr> In-Reply-To: References: <1410780645.4260510.1436536900559.JavaMail.zimbra@inria.fr> <1931277357.4267342.1436537674832.JavaMail.zimbra@inria.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4891640_1764109000.1436945040726" X-Originating-IP: [131.254.12.159] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF38 (Linux)/8.0.9_GA_6191) Thread-Topic: Search catch for interoperability tests Thread-Index: e2MBS+KDLK9GJNg1lRbb9qIUwVcQ3A== Archived-At: Cc: core Subject: Re: [core] Search catch for interoperability tests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 07:24:05 -0000 ------=_Part_4891640_1764109000.1436945040726 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thomas,=20 Thank you for your reply=20 I was also advised to use californium , I'll try it.=20 ETSI testing ( coap.me ), it was done with our team in 2012. It therefore h= as the same tests.=20 I have a little less than a month internship and I still have much to do. I= do not know if I'll have time to implement Observe. This is why the wiresh= ark catch, would be perfect for me.=20 William=20 ----- Mail original ----- > De: "Thomas Watteyne" > =C0: "William Bertier" > Cc: "core" > Envoy=E9: Vendredi 10 Juillet 2015 18:59:26 > Objet: Re: [core] Search catch for interoperability tests > William, > If you want to see block transfer "live", point your Firefox CoPPER exten= sion > to http://vs0.inf.ethz.ch/ . > You might be interested in http://coap.me/ which provides similar > functionality to what you describe > The OpenWSN CoAP library does not implement observe (see > https://openwsn.atlassian.net/wiki/display/OW/CoAP+Python+Library for a l= ist > of what it does/does not implement). You're more than welcome to add it. = You > might also enjoy the test infrastrcture > Thomas > Thomas > On Fri, Jul 10, 2015 at 4:14 PM, William Bertier < william.bertier@inria.= fr > > wrote: > > Hello, >=20 > > I am in intership at INRIA research laboratory of Rennes (France). >=20 > > I'm in a team that developed in 2013 a software that carries out > > interoperability testing. >=20 > > With a wireshark catch (.pcap, .dump), the software checks the complian= ce > > of > > exchanges. >=20 > > My goal is to update the software with the RFC7252 , > > draft-ietf-core-observe-16 and draft-ietf-core-block-17 . >=20 > > The description of the software : >=20 > > http://www.irisa.fr/tipi/wiki/doku.php/passive_validation_tool_for_coap >=20 > > To use the software, it is online: >=20 > > http://senslab2.irisa.fr/coap/ >=20 > > I am currently developing new test but I can unfortunately not tested d= ue > > to > > lack of wireshark catch. >=20 > > I am contacting you because I would like catch (.pcap, .dump), mainly c= atch > > that uses the functions observe and block. >=20 > > This would allow you to test your implementation and me to test my new > > tests. >=20 > > If you provide me catch I assure you that they will be used for my test= s > > and > > will be deleted afterwards. >=20 > > You can also provide me implementations, I am currently trying > > https://github.com/openwsn-berkeley/coap >=20 > > Thank you >=20 > > William Bertier >=20 > > _______________________________________________ >=20 > > core mailing list >=20 > > core@ietf.org >=20 > > https://www.ietf.org/mailman/listinfo/core >=20 ------=_Part_4891640_1764109000.1436945040726 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
T= homas,

Thank you for your reply<= /span>

I was also= advised to use californium<= /span>, I'll try it.

ETSI testing (coa= p.me), it was done with our team in 2012. It therefore has the same tests.

I= have a little less than a month internship and I still have much to do. I = do not know if I'll have time to implement Observe. This is why the wiresha= rk catch, would be perfect for me.

William
=

De: "Thomas Watteyne" <wa= tteyne@eecs.berkeley.edu>
=C0: "William Bertier" <william.b= ertier@inria.fr>
Cc: "core" <core@ietf.org>
Envoy= =E9: Vendredi 10 Juillet 2015 18:59:26
Objet: Re: [core] Sear= ch catch for interoperability tests

Will= iam,

If you want to see block transfer "live", point you= r Firefox CoPPER extension to http://vs0.inf.ethz= .ch/.

You might be interested in ht= tp://coap.me/ which provides similar functionality to what you describe=

The OpenWSN CoAP library does not implement obser= ve (see https://openwsn.atlassian.net/wiki/di= splay/OW/CoAP+Python+Library for a list of what it does/does not implem= ent). You're more than welcome to add it. You might also enjoy the test inf= rastrcture

Thomas

Thomas<= /div>



On Fri, Jul 10, 2015 at 4:14 PM, William Bertier <william.bertier@in= ria.fr> wrote:
=
Hello,

=
I am in intership at INRIA research laboratory of Rennes (France).

I'm in a team that developed in 2013 a software that carrie= s out interoperability testing.
With a wireshark catch (.pcap, .dump), t= he software checks the compliance of exchanges.

My goal i= s to update the software with the RFC7252 , draft-ietf-core-observe-16 and draft-ietf-= core-block-17.
The description of the software:
To use the software,= it is online:
http://senslab2.irisa.= fr/coap/

I am currently developing new test but I can= unfortunately not tested due to lack of wireshark catch.
I am contactin= g you because I would like catch (.pcap, .dump), mainly catch that uses the= functions observe and block.

This would allow yo= u to test your implementation and me to test my new tests.


If you provide me catch I assure you that they will be used = for my tests and will be deleted afterwards.
You can also provide me imp= lementations, I am currently trying https://github.com/openwsn-berkeley/coap

Thank you
William Bertier

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


<= /blockquote>

------=_Part_4891640_1764109000.1436945040726-- From nobody Wed Jul 15 00:29:24 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FA11A87EA for ; Wed, 15 Jul 2015 00:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6] autolearn=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 AeJ-df_88A2k for ; Wed, 15 Jul 2015 00:29:22 -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 B68901A87E7 for ; Wed, 15 Jul 2015 00:29:21 -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 t6F7TDVB020242; Wed, 15 Jul 2015 09:29:13 +0200 (CEST) Received: from alma.local (unknown [134.102.116.212]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mWVhT0j4NzD3VM; Wed, 15 Jul 2015 09:29:13 +0200 (CEST) Message-ID: <55A60BC8.4030005@tzi.org> Date: Wed, 15 Jul 2015 09:29:12 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: William Bertier References: <1410780645.4260510.1436536900559.JavaMail.zimbra@inria.fr> <1931277357.4267342.1436537674832.JavaMail.zimbra@inria.fr> <1220732518.4891641.1436945040727.JavaMail.zimbra@inria.fr> In-Reply-To: <1220732518.4891641.1436945040727.JavaMail.zimbra@inria.fr> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core Subject: Re: [core] Search catch for interoperability tests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 07:29:23 -0000 > ETSI testing (coap.me), it was done with our team in 2012. It therefore > has the same tests. Actually, the test specs have changed, and also there were some spec changes since 2012 that will impact trace captures. The most recent ETSI CoAP plugtest was in London, March 2014. So I would recommend testing again against coap.me (please ask me if there is any problem with that). By the way, coap.me can also be used to decode (and thus check) packet captures in pcap format. Grüße, Carsten From nobody Wed Jul 15 00:46:06 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7022F1A8847 for ; Wed, 15 Jul 2015 00:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPPVwqzS9B4q for ; Wed, 15 Jul 2015 00:46:03 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EFB11A1B5E for ; Wed, 15 Jul 2015 00:46:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,477,1432591200"; d="scan'208";a="140022046" Received: from zmbs2.inria.fr ([128.93.142.15]) by mail3-relais-sop.national.inria.fr with ESMTP; 15 Jul 2015 09:46:01 +0200 Date: Wed, 15 Jul 2015 09:46:01 +0200 (CEST) From: William Bertier To: Carsten Bormann Message-ID: <1035260517.4900766.1436946361595.JavaMail.zimbra@inria.fr> In-Reply-To: <55A60BC8.4030005@tzi.org> References: <1410780645.4260510.1436536900559.JavaMail.zimbra@inria.fr> <1931277357.4267342.1436537674832.JavaMail.zimbra@inria.fr> <1220732518.4891641.1436945040727.JavaMail.zimbra@inria.fr> <55A60BC8.4030005@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [131.254.12.159] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF38 (Linux)/8.0.9_GA_6191) Thread-Topic: Search catch for interoperability tests Thread-Index: pmpNfdSVZyMKTHCbqyLWpBC1sbFDzg== Archived-At: Cc: core Subject: Re: [core] Search catch for interoperability tests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 07:46:05 -0000 Yes indeed, the objective of my internship is to update the tests already p= resent and add new tests ----- Mail original ----- > De: "Carsten Bormann" > =C0: "William Bertier" > Cc: "Thomas Watteyne" , "core" > Envoy=E9: Mercredi 15 Juillet 2015 09:29:12 > Objet: Re: [core] Search catch for interoperability tests >=20 > > ETSI testing (coap.me), it was done with our team in 2012. It therefore > > has the same tests. >=20 > Actually, the test specs have changed, and also there were some spec > changes since 2012 that will impact trace captures. The most recent > ETSI CoAP plugtest was in London, March 2014. So I would recommend > testing again against coap.me (please ask me if there is any problem > with that). By the way, coap.me can also be used to decode (and thus > check) packet captures in pcap format. >=20 > Gr=FC=DFe, Carsten >=20 From nobody Wed Jul 15 09:45:54 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B7D1A1BCF for ; Wed, 15 Jul 2015 09:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.149 X-Spam-Level: X-Spam-Status: No, score=-0.149 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] autolearn=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 ZdfGOB5DpfQ5 for ; Wed, 15 Jul 2015 09:45: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 866FC1A1BC2 for ; Wed, 15 Jul 2015 09:45: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 [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t6FGjgZ7025705 for ; Wed, 15 Jul 2015 18:45:42 +0200 (CEST) Received: from alma.local (p5DC7F6B9.dip0.t-ipconnect.de [93.199.246.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mWl2Z1KVLzD2d1; Wed, 15 Jul 2015 18:45:42 +0200 (CEST) Date: Wed, 15 Jul 2015 18:45:41 +0200 From: Carsten Bormann To: "=?utf-8?Q?core=40ietf.org_WG?=" Message-ID: In-Reply-To: <5514D0B2.3020809@tzi.org> References: <551095C5.8030405@tzi.org> <5514D0B2.3020809@tzi.org> X-Mailer: Airmail (303) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55a68e35_28338f90_18c" Archived-At: Subject: Re: [core] Charter update proposal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 16:45:52 -0000 --55a68e35_28338f90_18c Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have created yet another updated version of our proposed charter update= : https://svn.tools.ietf.org/svn/wg/core/charter-ietf-core.txt The remaining problem I see is that the charter is relying on DICE for so= me more work (e.g., DTLS over SMS). But DICE may be closing soon, to maybe there is a need for some reallocat= ion here, or maybe that work will not be done. Input is welcome. =C2=A0Ideally, we will discuss this now on the list and= in the hallways and not spend meeting time on wordsmithing. (There will be a quick sync point on the Tuesday agenda which we could us= e to ship it off to Barry.) Gr=C3=BC=C3=9Fe, Carsten On 27 Mar 2015 at 04:38:48, Carsten Bormann (cabo=40tzi.org) wrote: I have updated the below referenced Charter update proposal based on the = =20 minutes from the meeting today. Have I missed anything=3F Comments up to = =20 and during tomorrow's meeting would be particularly welcome. =20 Gr=C3=BC=C3=9Fe, Carsten =20 Carsten Bormann wrote: =20 > As you know, we are overdue for a rechartering, both because much of th= e =20 > work laid out in the original charter is now done, and because there is= =20 > good work going on not yet covered by the charter. =20 > =20 > I have written up a rough draft that still needs a bit of wordsmithing.= =20 > Before we spend time on this, I'd like to get some feedback from the WG= =20 > whether this proposal is going in the right direction. Of course, once = =20 > we are satisfied, we still have to convince the IET=46 and the IESG. =20 > =20 > You can find the current version of the proposal at: =20 > https://svn.tools.ietf.org/svn/wg/core/charter-ietf-core.txt =20 > Comments to the list or right to me are welcome. =20 > =20 > Gr=C3=BC=C3=9Fe, Carsten =20 > =20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20 > core mailing list =20 > core=40ietf.org =20 > https://www.ietf.org/mailman/listinfo/core =20 > =20 > =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20 core mailing list =20 core=40ietf.org =20 https://www.ietf.org/mailman/listinfo/core =20 --55a68e35_28338f90_18c Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hello,

 

analyzing the message flow of some restart/robustnes= s scenarios I found some problems with section 3.1.

 

"A client MUST aggregate such requests and MUST= NOT register more than once for the same target resource. The target resou= rce is identified by all

options in the request that are part of the cache-ke= y."

 

For a restarting client this is hard to fulfill. It&= #8217;s seems to be common in that case to use the same target resource (in= cluding the same "cache-key" options) but with a different random= token. So, if such a request would be denied (caused by violating 3.1) , a client would not be able to reregister without stori= ng the original token "restart save".

 

Searching the mail archive I found, some discussion = on that topic (23.9.2014, Adrian Farrel and Klaus Hartke).

 

"> > Section 3.1

> >

> >    A client ... MUST NOT re= gister more than once for the same target

> >    resource.

> >

> > So, suppose a client does register a secon= d time for the same resource.

> > The server still has to handle it, notwith= standing the "MUST NOT".

> > It can handle it by saying:

> > - I see it is a duplicate, I'll ignore it<= o:p>

> > or

> > - I see it is a duplicate, I'll treat it a= s a protocol violation and

> >   reject it.

> >

> > But in Section 4.1

> >

> >    If an entry

> >    with a matching endpoint= /token pair is already present in the list

> >    (which, for example, hap= pens when the client wishes to reinforce its

> >    interest in a resource),= the server MUST NOT add a new entry but MUST

> >    replace or update the ex= isting one.

> >

> > So, you have written text to describe how = a server handles this case and

> > you have even described why a client might= send a second registration.

> >

> > Can you clarify?

>

> The client can send two things: a request with = a token already in use,

> or a request with a new token. In the first cas= e, the server sees it

> is a duplicate and proceeds as described in sec= tion 4.1. In the latter

> case, it's not a duplicate, because the token i= s different. It's also

> not a protocol violation, because we allow the = client to observe the

> same resource if the cache-key is different. If= the cache-key is not

> different, though, this just wastes the server'= s resource. That's what

> this MUST prevents.

 

That's nicely explained. Add it to the draft?"<= o:p>

 

But I still don’t see, how the client restart = and reregister should be handled (without storing the used token).

 

So any hints will be very welcome.

 

Mit freundlichen Gr=FC=DFen /= Best regards

 

Achim Kraus

 

Bosch Software= Innovations GmbH

Communications= (INST/ESY4)

Stuttgarter Stra=DFe 130=

71332 Waiblingen

GERMANY

ww= w.bosch-si.de

www.blog.bosch-si.com

 

achim.kraus@bosch-si.com

 

Registered office: Berlin, Reg= ister court: Amtsgericht Charlottenburg, HRB 148411 B

Executives: Dr.-Ing. Rainer Ka= llenbach; Michael Hahn

 

--_000_BC36447FF5C62E46BEF3F124D3C1E8921F30DE85imbpw2exd01bosc_-- From nobody Mon Jul 27 03:05:42 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850E61B2AAC for ; Mon, 27 Jul 2015 03:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35] autolearn=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 PonYPwMmysZp for ; Mon, 27 Jul 2015 03:05:39 -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 8FE0F1B2AAA for ; Mon, 27 Jul 2015 03:05:39 -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 t6RA5ace007433 for ; Mon, 27 Jul 2015 12:05:36 +0200 (CEST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mfxbN4Bv8zDM5t for ; Mon, 27 Jul 2015 12:05:36 +0200 (CEST) Received: by wibxm9 with SMTP id xm9so104916822wib.0 for ; Mon, 27 Jul 2015 03:05:36 -0700 (PDT) X-Received: by 10.194.179.136 with SMTP id dg8mr50831355wjc.49.1437991536304; Mon, 27 Jul 2015 03:05:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.21.201 with HTTP; Mon, 27 Jul 2015 03:04:56 -0700 (PDT) In-Reply-To: References: From: Klaus Hartke Date: Mon, 27 Jul 2015 12:04:56 +0200 Message-ID: To: "Kraus Achim (INST/ESY4)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "core@ietf.org" Subject: Re: [core] draft-ietf-core-observe-16 / reregister observation after client restart X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 10:05:40 -0000 Hi Achim, > "A client MUST aggregate such requests and MUST NOT register more than on= ce > for the same target resource. The target resource is identified by all > options in the request that are part of the cache-key." > > For a restarting client this is hard to fulfill. It=E2=80=99s seems to be= common in > that case to use the same target resource (including the same "cache-key" > options) but with a different random token. So, if such a request would b= e > denied (caused by violating 3.1) , a client would not be able to reregist= er > without storing the original token "restart save". When the client restarts, it's fine to "forget" the old token and register with a new token. The old observation will be cleaned up when the server sends the next notification. There is only a short overlap of the two observations, not two long-term observations running at the same time (which is what the 'MUST' prevents). Klaus From nobody Mon Jul 27 03:07:19 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1270B1B2AB3 for ; Mon, 27 Jul 2015 03:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85Jwg3iY19WE for ; Mon, 27 Jul 2015 03:07:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318DA1B2AAA for ; Mon, 27 Jul 2015 03:07:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 662A9BDCB; Mon, 27 Jul 2015 11:07:15 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccTLzSFXId7D; Mon, 27 Jul 2015 11:07:15 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 395CDBE88; Mon, 27 Jul 2015 11:07:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437991635; bh=qHC19sv2F+zhj56cKZgoVVW4cpYL2OaETjNU95Nm04A=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=Mn7fH9hYbWjSxeMfyDUQ/Nhg3RCUJkdQ2JODPUDYf8F7NtbGIap6FLxAXSvMvuXvS wQCx9MCMhU5XKvOqHI1lh7JTmQmulvQPTtOnMGqUmVK4ich3DqsY/cQ+9sd5cvM+rc /YjspZvzt/phdQAAd+GuJI/AxdEYhiOcK1+abifw= Message-ID: <55B602D3.1070302@cs.tcd.ie> Date: Mon, 27 Jul 2015 11:07:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Olaf Bergmann , =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <5570428E.5070500@sics.se> <87oaku75cd.fsf@aung.informatik.uni-bremen.de> <87lhe7arpr.fsf@aung.informatik.uni-bremen.de> <87si8a7ztu.fsf@aung.informatik.uni-bremen.de> In-Reply-To: <87si8a7ztu.fsf@aung.informatik.uni-bremen.de> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: core Subject: Re: [core] Question about blockwise and object security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 10:07:19 -0000 On 27/07/15 09:46, Olaf Bergmann wrote: > 2. if an intermediary splits a protected message into blocks it must add > some sort of integrity protection for the block to enable the > receiver to detect and throw away blocks that have been injected by a > malicious intermediary. FWIW, I don't believe I've ever seen that work. The crucial problems being that the receiver doesn't have any basis on which to accept or reject the actions of an intermediary, and that in general this can happen more than once on a path and it may not be the ultimate receiver who needs to check. All that seems to always add up to something that just doesn't work and you end up with only hop-by-hop or end-to-end security being practical. S. From nobody Mon Jul 27 03:36:49 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8D21B2C23 for ; Mon, 27 Jul 2015 03:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS_BhYY85AZi for ; Mon, 27 Jul 2015 03:27:54 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1141B2B59 for ; Mon, 27 Jul 2015 03:25:20 -0700 (PDT) Received: from mfilter38-d.gandi.net (mfilter38-d.gandi.net [217.70.178.169]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 7C788C5A46; Mon, 27 Jul 2015 12:25:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter38-d.gandi.net Received: from relay2-d.mail.gandi.net ([217.70.183.194]) by mfilter38-d.gandi.net (mfilter38-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id BLc7cdOfeW8e; Mon, 27 Jul 2015 12:25:16 +0200 (CEST) X-Originating-IP: 85.68.132.137 Received: from Zax.local (abo-137-132-68.bdx.modulonet.fr [85.68.132.137]) (Authenticated sender: alex@ackl.io) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id D8D3DC5A49; Mon, 27 Jul 2015 12:25:15 +0200 (CEST) To: Andy Bierman , "consultancy@vanderstok.org" References: <4dde82ad1cd4d261b598cb0e851cdf1c@xs4all.nl> From: Alexander Pelov Message-ID: <55B6070A.1020007@ackl.io> Date: Mon, 27 Jul 2015 12:25:14 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060306030204060108010406" Archived-At: X-Mailman-Approved-At: Mon, 27 Jul 2015 03:36:48 -0700 Cc: Core Subject: Re: [core] YANG Packages for CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 10:27:57 -0000 This is a multi-part message in MIME format. --------------060306030204060108010406 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Andy! Thanks for the draft! Seems a good start to get the things moving in the=20 direction of having a good, structured introspection mechanism for=20 module discovery! I'm not completely sure that it will be a static document. You still=20 need to think of the possibility of a firmware upgrade, in which case=20 you have to consider the clients which have obtained your previous=20 package descriptions. Why don't you want it to be a YANG module? I would suppose that for a=20 structured numbering scheme (such as CoOL) we could have a nice fixed=20 entry point for such introspection resource, e.g. moduleID =3D 1.=20 Alternatively, I would think that it should be discoverable through=20 .well-known/core A point to make is that we can have alias mappings through this=20 introspection mechanism. Defining such an introspection mechanism for=20 the aliases was actually one of the work I was considering for CoOL. Best, Alexander Le 27/07/2015 08:29, Andy Bierman a =E9crit : > > > On Sun, Jul 26, 2015 at 11:26 PM, peter van der Stok=20 > > wrote: > > HI Andy, > > Is the proposal to make YANG packages compulsory over yang-library > in Comi servers and clients? > > > No, it would be optional. > Another solution approach would be to make the module-set-id values > global instead of per-server. That might be less work perhaps. > > > Peter > > > Andy > > > Andy Bierman schreef op 2015-07-26 19:44: > > Hi, > > Michel raised some issues with the YANG library draft > http://datatracker.ietf.org/doc/draft-ietf-netconf-yang-library= / > > Maybe CoMI needs its own optimized module library. > I am concerned that data sizes of the YANG library will be > too big in some really constrained environments. > > I wrote a draft that defines a way to specify the contents of t= he > YANG library in a single static document, called a YANG package= . > http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-packa= ge/ > > If there was a "shorthand" resource that listed YANG packages, > instead > of YANG modules, then the CoMI client that supported YANG packa= ges > could read that instead of the module library. > > The YANG package message response can identify a single package > (e.g. match the firmware) so the size of the response will > remain very > small, and not depend on the entire list of modules, features, > and deviations. The data savings could 1000X for 100 modules. > > The client needs to retrieve the library first-time and anytime= it > changes. > The module-set-id values are per-server, not global. This > could be a > significant bottleneck when a CoMI client starts or restarts, a= nd > manages lots of servers. > > Andy > > > _______________________________________________ > 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 --------------060306030204060108010406 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Andy!

Thanks for the draft! Seems a good start to get the things moving in the direction of having a good, structured introspection mechanism for module discovery!

I'm not completely sure that it will be a static document. You still need to think of the possibility of a firmware upgrade, in which case you have to consider the clients which have obtained your previous package descriptions.

Why don't you want it to be a YANG module? I would suppose that for a structured numbering scheme (such as CoOL) we could have a nice fixed entry point for such introspection resource, e.g. moduleID =3D 1. Alternatively, I would think that it should be discoverable through .well-known/core

A point to make is that we can have alias mappings through this introspection mechanism. Defining such an introspection mechanism for the aliases was actually one of the work I was considering for CoOL.

Best,
Alexander

Le 27/07/2015 08:29, Andy Bierman a =E9crit=A0:


On Sun, Jul 26, 2015 at 11:26 PM, peter van der Stok <stokcons@xs4all.nl> w= rote:
HI Andy,<= br>
Is the proposal to make YANG packages compulsory over yang-library in Comi servers and clients?


No, it would be optional.
Another solution approach would be to make the module-set-id values
global instead of per-server. That might be less work perhaps.


Peter

Andy
=A0

Andy Bierman schreef op 2015-07-26 19:44:
Hi,

Michel raised some issues with the YANG library draft
http://datatracker= .ietf.org/doc/draft-ietf-netconf-yang-library/

Maybe CoMI needs its own optimized module library.
I am concerned that data sizes of the YANG library will be
too big in some really constrained environments.

I wrote a draft that defines a way to specify the contents of the
YANG library in a single static document, called a YANG package.
http://datatracker= .ietf.org/doc/draft-bierman-netmod-yang-package/

If there was a "shorthand" resource that listed YANG packages, instead
of YANG modules, then the CoMI client that supported YANG packages
could read that instead of the module library.

The YANG package message response can identify a single package
(e.g. match the firmware) so the size of the response will remain very
small, and not depend on the entire list of modules, features,
and deviations. The data savings could 1000X for 100 modules.

The client needs to retrieve the library first-time and anytime it
changes.
The module-set-id values are per-server, not global. This could be a
significant bottleneck when a CoMI client starts or restarts, and
manages lots of servers.

Andy


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



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

--------------060306030204060108010406-- From nobody Mon Jul 27 03:58:32 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881071B2BEB for ; Mon, 27 Jul 2015 03:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5dWqwff2AbP for ; Mon, 27 Jul 2015 03:58:30 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720991B2BEA for ; Mon, 27 Jul 2015 03:58:29 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-86-55b60ed3801a Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6B.13.25217.3DE06B55; Mon, 27 Jul 2015 12:58:27 +0200 (CEST) Received: from ESESSMB302.ericsson.se ([169.254.2.152]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0210.002; Mon, 27 Jul 2015 12:58:26 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Olaf Bergmann Thread-Topic: [core] Question about blockwise and object security Thread-Index: AQHQyEi1ifAo4IfuAEaNVGqjiqBkNZ3vJWAA Date: Mon, 27 Jul 2015 10:58:25 +0000 Message-ID: References: <5570428E.5070500@sics.se> <87oaku75cd.fsf@aung.informatik.uni-bremen.de> <87lhe7arpr.fsf@aung.informatik.uni-bremen.de> <87si8a7ztu.fsf@aung.informatik.uni-bremen.de> In-Reply-To: <87si8a7ztu.fsf@aung.informatik.uni-bremen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <983B441EBE8E5A4D833ED9B4A0CABFE5@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM+Jvje5lvm2hBhseS1s0LW5kstj3dj2z xavWO8wOzB5Llvxk8ug99pvNY9qizADmKC6blNSczLLUIn27BK6MnrW9rAVzJCouT2tgbWA8 I97FyMkhIWAi8fXpXjYIW0ziwr31QDYXh5DAUUaJnms7oJwljBL7p85jBqliE3CReNDwiAnE FhFQkdjQ/QzI5uBgFjCXmHkvDyQsLOAgcfdOFxtEiaPEkYmTGCFsI4k5jXPBWlkEVCX2Ln/C AmLzClhIHJmxigli1wtGiaXnn4Ht4hSwlrh77RdYMyPQdd9PrQFrZhYQl7j1ZD4TxNUCEkv2 nGeGsEUlXj7+xwpiiwroSay83gT1mZJE45InrBB3akqs36UPMcZaovvCa3YIW1FiSvdDdoh7 BCVOznzCMoFRYhaSbbMQumch6Z6FpHsWku4FjKyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2 MQLj8uCW31Y7GA8+dzzEKMDBqMTDmxCxNVSINbGsuDL3EKM0B4uSOO+MzXmhQgLpiSWp2amp BalF8UWlOanFhxiZODilGhgZK2aIrNns8HBVSvun2vzkpB8ensuPNjlqFJ587+31M2TFV88l T7bq3156wpGVYQNj27H42WyrYu4uvcscsP7cnejLbau/5udMFpv5s/HL3SrnflZjPzfRkCOu Zxo8ru06IjhRcvYFgR6mtXNmP/61auv9m9n5D86bnTFU3qq2sdSH2+SGjYCIEktxRqKhFnNR cSIAQWfQQ6wCAAA= Archived-At: Cc: core Subject: Re: [core] Question about blockwise and object security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 10:58:31 -0000 SGkgT2xhZiwNCg0KVGhhbmtzIGZvciBjbGFyaWZ5aW5nIHRoZSBhbWJpdGlvbiBsZXZlbC4gT3Vy IGFtYml0aW9uIHdhcyBqdXN0IHRvIHByb3RlY3QNCmJsb2Nrd2lzZSB0cmFuc2ZlciBlbmQtdG8t ZW5kIGFzIGRlZmluZWQgYnkgdGhlIGN1cnJlbnQgZHJhZnQuIElmIHdlIGdvDQpiZXlvbmQgdGhh dCB0aGVuIHRoZXJlIGFyZSBjZXJ0YWlubHkgdGhpbmdzIHdlIGNvdWxkIGRvLCBidXQgSeKAmW0g bm90IHN1cmUNCmlmIHN1Y2ggY2hhbmdlcyBhcmUgYXR0cmFjdGl2ZSBmcm9tIHRoZSBibG9ja3dp c2UgZnVuY3Rpb25hbGl0eSBwb2ludCBvZg0Kdmlldy4gSnVzdCB0byBnaXZlIGEgbmFpdmUgZXhh bXBsZSAod2hpY2ggbWF5IHZlcnkgd2VsbCBiZSBjb21wbGV0ZWx5IG91dA0Kb2Ygc2NvcGUgb3Ig cmVtb3Zpbmcgc29tZSBvZiB0aGUgZGVzaXJhYmxlIHByb3BlcnRpZXMpOiBJZiB0aGUgc2VuZGVy DQpjb3VsZCBpbiBzb21lIHdheSBiZWNvbWUgaW5mb3JtZWQgYWJvdXQgdGhlIG1pbmltdW0gYmxv Y2sgc2l6ZSBmb3IgYQ0KcGFydGljdWxhciB0cmFuc2FjdGlvbiBpdCBjb3VsZCBzcGxpdCB0aGUg cGFja2V0IGZyb20gdGhlIHN0YXJ0LiBFdmVuIGlmDQp0aGlzIHdvdWxkIG5vdCBiZSBhIGRlZmF1 bHQgc29sdXRpb24sIGFsbG93aW5nIHRoaXMgYXMgYSBmYWxsIGJhY2sgY291bGQNCmRlZmluaXRl bHkgaW1wcm92ZSB0aGUgc2l0dWF0aW9uLg0KDQpSZWdhcmRzLA0KR8O2cmFuDQoNCiANCg0KT24g MjAxNS0wNy0yNyAxMDo0NiwgIk9sYWYgQmVyZ21hbm4iIDxiZXJnbWFubkB0emkub3JnPiB3cm90 ZToNCg0KPkhpIEfDtnJhbiwNCj4NCj5Hw7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVy aWNzc29uLmNvbT4gd3JpdGVzOg0KPg0KPj4gSSB0aGluayB0aGUgb3ZlcmFsbCBzZXR0aW5nIHdp dGggdGhlIGJsb2Nrd2lzZSBkcmFmdCBpcyB0aGF0IHRoZSBCbG9jaw0KPj4gb3B0aW9uIGNhbiBi ZSBjaGFuZ2VkIGluIGFuIHVucHJlZGljdGFibGUgd2F5IGJ5IGFuIGludGVybWVkaWFyeSBub2Rl Lg0KPj4gVGhpcyBtYWtlcyBpdCBpbXBvc3NpYmxlIHRvIGludGVncml0eSBwcm90ZWN0IHRoYXQg b3B0aW9uIGVuZC10by1lbmQuDQo+PiBGdXJ0aGVybW9yZSB3aXRob3V0IGFueSByZXN0cmljdGlv bnMgd2hhdCBhbiBpbnRlcm1lZGlhcnkgY2FuIGRvIEkgZG9u4oCZdA0KPj4gc2VlIGhvdyB0byBk ZWZpbmUgYW4gaW52YXJpYW50LCB1bmxlc3MgbW9yZSBpbmZvcm1hdGlvbiBpcyBwcm92aWRlZCB0 bw0KPj50aGUNCj4+IGVuZHBvaW50cyBvciBvdGhlciBhc3N1bXB0aW9ucyBpcyBhZGRlZCBvbiBo b3cgdG8gc3BsaXQgaW50byBibG9ja3MuDQo+Pg0KPj4gKFN0aWxsIHRoZSBlbnRpcmUgbWVzc2Fn ZSBjYW4gYmUgaW50ZWdyaXR5IHByb3RlY3RlZCBhbmQgdmVyaWZpZWQNCj4+IGluZGVwZW5kZW50 bHkgb2YgaG93IGl0IGlzIHNwbGl0IGludG8gYmxvY2tzIGR1cmluZyB0cmFuc2Zlci4pDQo+DQo+ WW91IGFyZSByaWdodC4gQXMgdGhlIGxhdHRlciB3b3VsZCBwdXQgYSBsYXJnZSBidXJkZW4gb250 byB0aGUgY2xpZW50DQo+YmVjYXVzZSBpdCBoYXMgdG8gcHJvdmlkZSBidWZmZXIgc3BhY2UgZm9y IGNvbGxlY3RpbmcgYWxsIGJsb2NrcyBiZWZvcmUNCj5pdCBjYW4gY2hlY2sgdGhlaXIgYXV0aGVu dGljaXR5LCB0aGUgb3B0aW9ucyB0aGF0IEx1ZHdpZyBhbmQgSSBoYXZlDQo+ZGlzY3Vzc2VkIHRv IGRlYWwgd2l0aCB0aGlzIHByb2JsZW0gd2VyZToNCj4NCj4xLiBFaXRoZXIgZm9yYmlkL2RlcHJl Y2F0ZSBpbnRlcm1lZGlhcmllcyB0byBzcGxpdCBhIHByb3RlY3RlZCBtZXNzYWdlDQo+ICAgaW50 byBibG9ja3MsIG9yDQo+DQo+Mi4gaWYgYW4gaW50ZXJtZWRpYXJ5IHNwbGl0cyBhIHByb3RlY3Rl ZCBtZXNzYWdlIGludG8gYmxvY2tzIGl0IG11c3QgYWRkDQo+ICAgc29tZSBzb3J0IG9mIGludGVn cml0eSBwcm90ZWN0aW9uIGZvciB0aGUgYmxvY2sgdG8gZW5hYmxlIHRoZQ0KPiAgIHJlY2VpdmVy IHRvIGRldGVjdCBhbmQgdGhyb3cgYXdheSBibG9ja3MgdGhhdCBoYXZlIGJlZW4gaW5qZWN0ZWQg YnkgYQ0KPiAgIG1hbGljaW91cyBpbnRlcm1lZGlhcnkuDQo+DQo+TXkgcHJldmlvdXMgcG9zdCB3 YXMgYSBmb2xsb3ctdXAgb24gb3B0aW9uICMyIHdoaWNoIGlzIHRoZSBiZXN0IHlvdSBjYW4NCj5k byBpZiB5b3UgZG9uJ3QgZ28gZm9yIG9wdGlvbiAjMS4gKE15IHBlcnNvbmFsIHByZWZlcmVuY2Ug aXMgc3RpbGwgIzEuKQ0KPg0KPg0KPkdyw7zDn2UNCj5PbGFmDQoNCg== From nobody Mon Jul 27 04:22:31 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2363A1AD4A1 for ; Mon, 27 Jul 2015 04:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=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 J07lOjaDo9i3 for ; Mon, 27 Jul 2015 04:22:27 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA971A90BC for ; Mon, 27 Jul 2015 04:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t6RBMNJ4026641; Mon, 27 Jul 2015 13:22:23 +0200 (CEST) Received: from aung.tzi.org (pD9F6198B.dip0.t-ipconnect.de [217.246.25.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mfzHz4BjnzDMHj; Mon, 27 Jul 2015 13:22:23 +0200 (CEST) From: Olaf Bergmann To: =?utf-8?Q?G=C3=B6ran?= Selander References: <5570428E.5070500@sics.se> <87oaku75cd.fsf@aung.informatik.uni-bremen.de> <87lhe7arpr.fsf@aung.informatik.uni-bremen.de> <87si8a7ztu.fsf@aung.informatik.uni-bremen.de> Date: Mon, 27 Jul 2015 13:23:23 +0200 In-Reply-To: (=?utf-8?Q?=22G?= =?utf-8?Q?=C3=B6ran?= Selander"'s message of "Mon, 27 Jul 2015 10:58:25 +0000") Message-ID: <87io95974k.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: core Subject: Re: [core] Question about blockwise and object security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 11:22:30 -0000 Hi G=C3=B6ran, G=C3=B6ran Selander writes: > Thanks for clarifying the ambition level. Our ambition was just to protect > blockwise transfer end-to-end as defined by the current draft. If we go > beyond that then there are certainly things we could do, but I=E2=80=99m = not sure > if such changes are attractive from the blockwise functionality point of > view. Just to give a naive example (which may very well be completely out > of scope or removing some of the desirable properties): If the sender > could in some way become informed about the minimum block size for a > particular transaction it could split the packet from the start. Even if > this would not be a default solution, allowing this as a fall back could > definitely improve the situation. I agree with this view. One problem is that an adversary might be able to inject malicious blocks during transmission to fill the receiver's buffers (the one that must collect all blocks before it can check the MAC tag). This could be mitigated by per-block MICs as suggested. Gr=C3=BC=C3=9Fe Olaf From nobody Mon Jul 27 04:25:41 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E261B2C28 for ; Mon, 27 Jul 2015 04:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 M-P2i3-38to3 for ; Mon, 27 Jul 2015 04:25:35 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (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 4B7231A916C for ; Mon, 27 Jul 2015 04:25:35 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so51191996lbb.1 for ; Mon, 27 Jul 2015 04:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YJgIxsx7VWj0aS4yFvjEx85z7wa+cbpyIjiQf3ybrRI=; b=CUkIqvArM5zSR3KjgpNj9BSMltgQlFnyoIKQ/KFVMXZF/tlIunFliGGH23i4+MocfC NG3QuyxLvmzpCwBe996MGtR1z3QNa+5vt+QZCkNqvty4ibIAdFwpreb43TxKo1TILyh2 gtUwQbnm5G5LEFkywde0HgYQJ1uAFCb0bMkkxojZETl57ad5xVocKfaM/+4v8yrK/rUx GdDCwCWDarY6HfDtbcyYFwn8/ZTP9qxjf6sxm90GwAKq/HET2iG36KPe8vCeF9KumgTt 2FnwZhTBmtCrKtlfUUAZDxH7bDu2c2EzjqX36d6NnQkma4jeNczJgTLyLq31rSgdfLF4 jymA== MIME-Version: 1.0 X-Received: by 10.152.36.102 with SMTP id p6mr26536373laj.19.1437996333585; Mon, 27 Jul 2015 04:25:33 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.25.31.75 with HTTP; Mon, 27 Jul 2015 04:25:33 -0700 (PDT) In-Reply-To: <87si8a7ztu.fsf@aung.informatik.uni-bremen.de> References: <5570428E.5070500@sics.se> <87oaku75cd.fsf@aung.informatik.uni-bremen.de> <87lhe7arpr.fsf@aung.informatik.uni-bremen.de> <87si8a7ztu.fsf@aung.informatik.uni-bremen.de> Date: Mon, 27 Jul 2015 12:25:33 +0100 X-Google-Sender-Auth: seYv_qA_6lwKF06w5M640JOUYs0 Message-ID: From: Robert Cragie To: Olaf Bergmann Content-Type: multipart/alternative; boundary=089e0158b7a4a6dd19051bd99c75 Archived-At: Cc: core Subject: Re: [core] Question about blockwise and object security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 11:25:39 -0000 --089e0158b7a4a6dd19051bd99c75 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 27 July 2015 at 09:46, Olaf Bergmann wrote: > Hi G=C3=B6ran, > > G=C3=B6ran Selander writes: > > > I think the overall setting with the blockwise draft is that the Block > > option can be changed in an unpredictable way by an intermediary node. > > This makes it impossible to integrity protect that option end-to-end. > > Furthermore without any restrictions what an intermediary can do I don= =E2=80=99t > > see how to define an invariant, unless more information is provided to > the > > endpoints or other assumptions is added on how to split into blocks. > The only way I can see this working is to protect the blocks at the originator somehow and then if an intermediary wants to change block size, it effectively has to encapsulated the original blocks. This would work for both splitting and recombining but is certainly awkward in many ways. Also every intermediary would have to further encapsulate. This could get over having to buffer a lot of stuff but is complicated as the target recipient would have to be able to verify data from the originator and all intermediaries. > > > > (Still the entire message can be integrity protected and verified > > independently of how it is split into blocks during transfer.) > > You are right. As the latter would put a large burden onto the client > because it has to provide buffer space for collecting all blocks before > it can check their authenticity, Not necessarily. Firmware download is often cited as a use case and almost invariably the whole firmware image has a check code (cryptographic or otherwise) associated with it before it can actually be used. It therefore has to be stored somewhere, usually in a secondary flash buffer. the options that Ludwig and I have > discussed to deal with this problem were: > > 1. Either forbid/deprecate intermediaries to split a protected message > into blocks, or > Probably the safest option. Then the blocks themselves may not need to be protected. However, unless DTLS protection is end to end, there is still a potential for an intermediary to insert/delete/manipulate blocks > > 2. if an intermediary splits a protected message into blocks it must add > some sort of integrity protection for the block to enable the > receiver to detect and throw away blocks that have been injected by a > malicious intermediary. > Agree - protecting blocks at the originator but this would likely be using something other than DTLS. > > My previous post was a follow-up on option #2 which is the best you can > do if you don't go for option #1. (My personal preference is still #1.) > > > Gr=C3=BC=C3=9Fe > Olaf > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --089e0158b7a4a6dd19051bd99c75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 27 July 2015 at 09:46, Olaf Bergmann <bergmann@tzi.org> wrote:
Hi G=C3=B6ran,

G=C3=B6ran Selander <gora= n.selander@ericsson.com> writes:

> I think the overall setting with the blockwise draft is that the Block=
> option can be changed in an unpredictable way by an intermediary node.=
> This makes it impossible to integrity protect that option end-to-end.<= br> > Furthermore without any restrictions what an intermediary can do I don= =E2=80=99t
> see how to define an invariant, unless more information is provided to= the
> endpoints or other assumptions is added on how to split into blocks.

<RCC>The only way I can see= this working is to protect the blocks at the originator somehow and then i= f an intermediary wants to change block size, it effectively has to encapsu= lated the original blocks. This would work for both splitting and recombini= ng but is certainly awkward in many ways. Also every intermediary would hav= e to further encapsulate. This could get over having to buffer a lot of stu= ff but is complicated as the target recipient would have to be able to veri= fy data from the originator and all intermediaries.</RCC>
= =C2=A0
>
> (Still the entire message can be integrity protected and verified
> independently of how it is split into blocks during transfer.)

You are right. As the latter would put a large burden onto the clien= t
because it has to provide buffer space for collecting all blocks before
it can check their authenticity,

<RCC>= ;Not necessarily. Firmware download is often cited as a use case and almost= invariably the whole firmware image has a check code (cryptographic or oth= erwise) associated with it before it can actually be used. It therefore has= to be stored somewhere, usually in a secondary flash buffer.</RCC>

the options that Ludwig = and I have
discussed to deal with this problem were:

1. Either forbid/deprecate intermediaries to split a protected message
=C2=A0 =C2=A0into blocks, or

<RCC>= ;Probably the safest option. Then the blocks themselves may not need to be = protected. However, unless DTLS protection is end to end, there is still a = potential for an intermediary to insert/delete/manipulate blocks</RCC>= ;=C2=A0

2. if an intermediary splits a protected message into blocks it must add =C2=A0 =C2=A0some sort of integrity protection for the block to enable the<= br> =C2=A0 =C2=A0receiver to detect and throw away blocks that have been inject= ed by a
=C2=A0 =C2=A0malicious intermediary.

&l= t;RCC>Agree - protecting blocks at the originator but this would likely = be using something other than DTLS.</RCC>=C2=A0

My previous post was a follow-up on option #2 which is the best you can
do if you don't go for option #1. (My personal preference is still #1.)=


Gr=C3=BC=C3=9Fe
Olaf

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

--089e0158b7a4a6dd19051bd99c75-- From nobody Mon Jul 27 04:25:50 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349D51A916C for ; Mon, 27 Jul 2015 04:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 wgwbb7EuR4dn for ; Mon, 27 Jul 2015 04:25:41 -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 3664A1B2C28 for ; Mon, 27 Jul 2015 04:25:41 -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 t6RBPY9a003107; Mon, 27 Jul 2015 13:25:35 +0200 (CEST) Received: from aung.tzi.org (pD9F6198B.dip0.t-ipconnect.de [217.246.25.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mfzMf3fyszDMKB; Mon, 27 Jul 2015 13:25:34 +0200 (CEST) From: Olaf Bergmann To: Stephen Farrell References: <5570428E.5070500@sics.se> <87oaku75cd.fsf@aung.informatik.uni-bremen.de> <87lhe7arpr.fsf@aung.informatik.uni-bremen.de> <87si8a7ztu.fsf@aung.informatik.uni-bremen.de> <55B602D3.1070302@cs.tcd.ie> Date: Mon, 27 Jul 2015 13:26:34 +0200 In-Reply-To: <55B602D3.1070302@cs.tcd.ie> (Stephen Farrell's message of "Mon, 27 Jul 2015 11:07:15 +0100") Message-ID: <87egjt96z9.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: core Subject: Re: [core] Question about blockwise and object security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 11:25:42 -0000 Stephen Farrell writes: > On 27/07/15 09:46, Olaf Bergmann wrote: >> 2. if an intermediary splits a protected message into blocks it must add >> some sort of integrity protection for the block to enable the >> receiver to detect and throw away blocks that have been injected by a >> malicious intermediary. > > FWIW, I don't believe I've ever seen that work. The crucial problems > being that the receiver doesn't have any basis on which to accept or > reject the actions of an intermediary, and that in general this can > happen more than once on a path and it may not be the ultimate receiver > who needs to check. All that seems to always add up to something that > just doesn't work and you end up with only hop-by-hop or end-to-end > security being practical. Yes, I completely agree! Gr=C3=BC=C3=9Fe Olaf From nobody Mon Jul 27 07:48:04 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40B81B2E67 for ; Mon, 27 Jul 2015 07:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6UJgq4zosNY for ; Mon, 27 Jul 2015 07:48:01 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327C71B2E66 for ; Mon, 27 Jul 2015 07:48:01 -0700 (PDT) Received: by pdrg1 with SMTP id g1so53272640pdr.2 for ; Mon, 27 Jul 2015 07:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version; bh=xb3E87p5favhVIXR7H0KxEEXTpPq7JQQfTXfOSK9cH0=; b=fefjVSL1yMMcaoXQFLaw84Pk+BdZNUoiHzlPXaoEQ3z2twC8h4RptQJ8Kd0VZ52MXH A/qTeSiroxywglTMHtW4HoRAfZFW2aT774EstuE4Bdp3glWLwyb5xKdrphFrHBDN/0Y7 YiVOqT9L2o6ekN45CmsObVtTeQEqg2I1mDDzzHYByWc7UrM65PLmqmxlibqhXkZAJoIU j1w547s4nXDmIkpfWc3Wxaudm1mwwg3A+z0mDCNeYYR9GZ71CyMd8UuzZcdzlwhwjaLi Azi4TiKRTJMfDlnh+swH6QwxCjdqOo/0UAGUvC8FahnQQY+zSUxhsGdmDAn1R1dInflo pfrg== X-Received: by 10.70.0.71 with SMTP id 7mr69131258pdc.157.1438008480636; Mon, 27 Jul 2015 07:48:00 -0700 (PDT) Received: from [192.168.0.16] (S0106bc4dfb8df4d3.vc.shawcable.net. [174.7.22.172]) by smtp.gmail.com with ESMTPSA id r6sm29954878pdn.24.2015.07.27.07.47.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jul 2015 07:47:58 -0700 (PDT) From: Simon Lemay X-Pgp-Agent: GPGMail 2.5 Content-Type: multipart/signed; boundary="Apple-Mail=_48AEA858-E5C9-49E8-96AF-4BD680994E1B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 27 Jul 2015 07:47:55 -0700 Message-Id: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> To: "core@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Subject: [core] Lenght shim X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 14:48:03 -0000 --Apple-Mail=_48AEA858-E5C9-49E8-96AF-4BD680994E1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, So after the meeting on Friday, a few of up stayed to talk about the = different alternatives on how to represent the length information in = CoAP over TCP (reliable transport) 2 option came out of the meeting. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94- Option A 2 byte shim with new Blocking option for bigger application layer = fragmentation This would consists of 2 bytes (16 bits) giving a max length of 64kb. = we would also add a new size option in the block size for FFFF (minus = the header). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length Shim |Ver| T | TKL | Code | Token (TKL +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | bytes) ... | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The new blocksize needs to be a clean fraction of the 1024byte block. = This is needed for proxying blocksize across different transport layer. Pros: -easy to manage -can be remove is faming is not needed -application layer fragmentation helps with multiplexing request Cons -Does not support larger than 16 bits. -could not do streaming =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94- Option B Option like split length with a no length option for reliable transport = that already have a framing The initial byte of the frame contains two nibbles, in a similar way to = the CoAP option encoding (Section 3.1 of [RFC7252]). The first nibble is = used to indicate the length of the options (including any option = delimiter), and the payload (if any); it does not include the Code byte = or the Token bytes. The first nibble is interpreted as a 4-bit unsigned = integer. A value between 0 and 12 directly indicates the length of the = options/payload, in bytes. The other three values have a special = meaning: 13: An 8-bit unsigned integer follows the initial byte and = indicates the length of options/payload minus 13. 14: A 16-bit unsigned = integer in network byte order follows the initial byte and indicates the = length of options/payload minus 269. 15: A 32-bit unsigned integer in = network byte order follows the initial byte and indicates the length of = options/payload minus 65805. 16: no framing. The second nibble of the = initial byte indicates the token length. Example: 01 43 7f is a frame = just containing a 2.03 code with the token 7f. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Len | TKL | Len+ bytes... | Code | TKL bytes ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pros: -supports larger payload -flexible (dynamic payload size) -removed the Message Type field Cons: -Large message might be difficult to parse or flush for more constraint = node. -cannot be removed if underlining implementation does not need framing Let me know what you guys think, any pro or cons missing and what we = should process to Cheers Simon --Apple-Mail=_48AEA858-E5C9-49E8-96AF-4BD680994E1B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVtkScAAoJELlmKj7tHRvwxzMP/jdjHAqOE22vdZWw8aLaBb61 o+GvTFuhv+dcBF5eCfcxf9Ces5Jm1lcIQ9MIj652ZRJ91W1iL1rvZE9gqp+CQpEB 3mElbkoVPDlFJFL4ZaqEYTWvhK2XdqZ+CTsKE1xyZB/xHwcYm72gHOsoVQBpF7/l +w/MuXO9FA/mvHR+Jvg30E2edNF8en2IN552WQoMv1ncBxMsealLxtgavtTqD0Hn ThCJQtOI1gvUwA2GIdpdWKBv3vWiAgBKev6qDqQDLbyiPX/YQKrDrLZ9kXAxYwFq h0FyZlUnJuwxQW/16NPsui27X++ed5VSgi3n2UdsC7v8K8YiU4vH8dOHDI+X+8IJ N1/IT4BNMech8SdIYA0ir3/XvCM55IEJQqvGtUM5h55tZkIdJhmeq37GnxlDBl/Z OD/7Y/2Brige83qqaALAzo5nk30oo5VVvMn9XtYSuLE4pNWV4ZCJfwRKgFOQul0k ZL1PdVHFLdW8Vt1pvKO4YRMhOJzy04BYnjkWzZi7yQdFB6z4QthTStnyKwIeoUHI NA7FvKumCVArH2G99iZnZdS0PRG9Wzk1He90OKmPPXnjOmqrTUVBGc/hHZQEiD6g qShhrG5OOA6DBXOCz/ZIDDH/erhpdwKc8bBeKJBFFw1Is3zCIG+zlu6Of5U6TCrg F/0UXHTEvz2RD99AVxuc =DLpg -----END PGP SIGNATURE----- --Apple-Mail=_48AEA858-E5C9-49E8-96AF-4BD680994E1B-- From nobody Mon Jul 27 08:12:36 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5871B2E6A for ; Mon, 27 Jul 2015 08:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3v0dyNIWs72 for ; Mon, 27 Jul 2015 08:12:32 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 8DE2B1B2E65 for ; Mon, 27 Jul 2015 08:12:32 -0700 (PDT) Received: by padck2 with SMTP id ck2so53060387pad.0 for ; Mon, 27 Jul 2015 08:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=0oUuQa8APm5z9GGc7qJ0Q4jhUII/AD2pIkVw7a8Ef90=; b=H9fjSI3D8O5Ve0UUFcj0rzzu4TpUApYpHguTq507W0VfPRgdxkch9oTWtIBs9x+WCJ t2K7TUTMsl4yqc0UKQW96f7ulZgPlhjJmJYrSpfp/PQmWMERq+oDb/pko0Hr8a5OsucO PoKskcF7iGFJ+fKATzww5Dv68fHyS+CdcfJ3iQAqK/t/1Lnw61G3X3qIiicQR9+pAkZS 5eSIAEbmJ0CQ3Yx3o431wua8U8r3xav++x6BYEAoT2YoHDynwhWzqPZcDC2KOYVpDosb oHutyHV2HzLqnA1nAtzk2uR7szFMerCiRU+bP/rcttdcW+bwr6FZQJtaH1qqxwuyTQDU VQBQ== X-Received: by 10.66.160.104 with SMTP id xj8mr65233541pab.24.1438009952112; Mon, 27 Jul 2015 08:12:32 -0700 (PDT) Received: from [192.168.0.16] (S0106bc4dfb8df4d3.vc.shawcable.net. [174.7.22.172]) by smtp.gmail.com with ESMTPSA id fl3sm30029784pdb.30.2015.07.27.08.12.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jul 2015 08:12:31 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7CC3D21F-3EE8-4857-BAB3-8CF7CAED719B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Simon Lemay In-Reply-To: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> Date: Mon, 27 Jul 2015 08:12:29 -0700 Message-Id: <22FE55A2-2D05-48D9-AA1A-2F572B4F2637@gmail.com> References: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Klaus Hartke Subject: Re: [core] Lenght shim X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 15:12:34 -0000 --Apple-Mail=_7CC3D21F-3EE8-4857-BAB3-8CF7CAED719B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Made a few correction (Thank you Klaus for pointing them out :) ) Cheers Simon > On Jul 27, 2015, at 7:47 AM, Simon Lemay = wrote: >=20 > Hi, >=20 > So after the meeting on Friday, a few of up stayed to talk about the = different alternatives on how to represent the length information in = CoAP over TCP (reliable transport) >=20 > 2 option came out of the meeting. >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94- > Option A > 2 byte shim with new Blocking option for bigger application layer = fragmentation >=20 > This would consists of 2 bytes (16 bits) giving a max length of 64kb. = we would also add a new size option in the block size for FFFF (minus = the header). >=20 >=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length |Ver| T | TKL | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token (if any, TKL bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > The new blocksize needs to be a clean fraction of the 1024byte block. = This is needed for proxying blocksize across different transport layer. >=20 > Pros: > -easy to manage > -can be remove is faming is not needed > -application layer fragmentation helps with multiplexing request >=20 >=20 >=20 > Cons > -Does not support larger than 16 bits. > -could not do streaming >=20 >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94- > Option B > Option like split length with a no length option for reliable = transport that already have a framing >=20 > The initial byte of the frame contains two nibbles, in a similar way = to the CoAP option encoding (Section 3.1 of [RFC7252]). The first nibble = is used to indicate the length of the options (including any option = delimiter), and the payload (if any); it does not include the Code byte = or the Token bytes. The first nibble is interpreted as a 4-bit unsigned = integer. A value between 0 and 12 directly indicates the length of the = options/payload, in bytes. The other three values have a special = meaning: 13: An 8-bit unsigned integer follows the initial byte and = indicates the length of options/payload minus 13. 14: A 16-bit unsigned = integer in network byte order follows the initial byte and indicates the = length of options/payload minus 269. 15: A 32-bit unsigned integer in = network byte order follows the initial byte and indicates the length of = options/payload minus 65805. The second nibble of the initial byte = indicates the token length. Example: 01 43 7f is a frame just containing = a 2.03 code with the token 7f. >=20 >=20 >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Len | TKL | Len+ bytes... | Code | TKL bytes ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1 1 1 1 1 1 1 1| Payload (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > Pros: > -supports larger payload > -flexible (dynamic payload size) > -removed the Message Type field >=20 >=20 > Cons: > -Large message might be difficult to parse or flush for more = constraint node. > -cannot be removed if underlining implementation does not need framing (Need to specify an option for no framing, 12?) >=20 > Let me know what you guys think, any pro or cons missing and what we = should process to >=20 > Cheers >=20 > Simon >=20 >=20 --Apple-Mail=_7CC3D21F-3EE8-4857-BAB3-8CF7CAED719B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVtkpdAAoJELlmKj7tHRvwpNgP/01+e1vzLEUTZS/UEbZe4Af+ npoMWwzNJK3U80/+1KXwEyTbTS2V5Z6qUg0Jg5YJmk09NeAFlCi50/dyWgQDhOwi D7xgI4HB0FQKP2q1nKXvGMfTj+cEJXfNt3uvR3LBc3PD8Y/i17N8NlgykucN+MMo JS4wYC7vyM1eKbwsx+/EMFAGOXossNQatlPxV6T7PTjyHmBdsWh97udzkDDdOkYD J2qNR4IxuMhiqMTQIzwDsYt46wWD6WDTE390uQ/cR+ZL327W9OvlJduEcgWGkbm8 mGKuDqMRAh23mDZX3O73g98nENja8hL3wO5FpKYhrZuhKKcquPnnoPVwa1bfTiWe tYkjlZxWxZxWvlHCO6+L/fSWH4QMP4IsiYTjCqcdMMNQsnKc2Z3aZ5bidDvzBMfa P8RLx50yNBzL4EAmmvk09IYa2e670ClrT2l9JCDJHanoixdBaDR+S1ayll0rGWvT O9bzjvSZhD7/k9GRHjUDENmfFoWbOCdf9SK0bL119ULddmmeRZNk78vEM6gFD8mb HNVQyLokRDnrCuGX2CdQYxxmEiPw8ROZYb5jmgz4lKEijLAFesGwwFpxtccr0lly N42SeL0ivMdYGK0dWwqmUkYniuWP9QUKXqIazSR9E4i9/VwO9Wvg+IkknVB7AR1v td+3Agtv8kRFEjK9J8m3 =4OWF -----END PGP SIGNATURE----- --Apple-Mail=_7CC3D21F-3EE8-4857-BAB3-8CF7CAED719B-- From nobody Mon Jul 27 08:34:36 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9F11B2E9F for ; Mon, 27 Jul 2015 08:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 CUHtMGGMydDL for ; Mon, 27 Jul 2015 08:34:28 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95E71B2ED8 for ; Mon, 27 Jul 2015 08:34:21 -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 t6RFYHSu003350; Mon, 27 Jul 2015 17:34:17 +0200 (CEST) Received: from alma.local (p5DC7F6B9.dip0.t-ipconnect.de [93.199.246.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mg4td4M6lzDHhr; Mon, 27 Jul 2015 17:34:17 +0200 (CEST) Message-ID: <55B64F77.5090701@tzi.org> Date: Mon, 27 Jul 2015 17:34:15 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Simon Lemay References: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> In-Reply-To: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Lenght shim X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 15:34:30 -0000 Hi Simon, thanks for writing this up. In Option A, the length shim can simply be elided for transports that provide framing. There is no T, just two bits that we want to set to some predefined value (say, 01). (You already sent a corrected picture for the 16-bit message length.) In Option B, there is not really a need to indicate a length for transports that provide framing. I'd say, for this case the 4-bit length field is always set to 0. Maybe remove "with a no length option for reliable transport that already have a framing" from the short description as this is a detail. I don't understand the cons listed for B, because B still is as short A if the Option A length shim could be elided, and shorter in many other cases. The other con is really about sending large messages in the first place, not about option B! It's 64 KiB - 1 B, not 64 kb... There needs to be a specification of what is included in the length. (For option A, this would likely be everything after the length shim, but we also could use a small offset, e.g., length=0 could indicate a two-byte message, length=1, 3-byte, etc.) A new szx=7 to enable larger block sizes could simply indicate that the total body is to assembled serially from the payloads provided in sequence; this only really makes sense when keeping a sequence of blocks within an instance of a sequence-preserving transport. But I would write this up separately, not in this draft. (And please expand on "The new blocksize needs to be a clean fraction of the 1024byte block. This is needed for proxying blocksize across different transport layer.".) Grüße, Carsten Simon Lemay wrote: > Hi, > > So after the meeting on Friday, a few of up stayed to talk about the different alternatives on how to represent the length information in CoAP over TCP (reliable transport) > > 2 option came out of the meeting. > > ——————————————————- > Option A > 2 byte shim with new Blocking option for bigger application layer fragmentation > > This would consists of 2 bytes (16 bits) giving a max length of 64kb. we would also add a new size option in the block size for FFFF (minus the header). > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length Shim |Ver| T | TKL | Code | Token (TKL > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | bytes) ... | Options (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1 1 1 1 1 1 1 1| Payload (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The new blocksize needs to be a clean fraction of the 1024byte block. This is needed for proxying blocksize across different transport layer. > > Pros: > -easy to manage > -can be remove is faming is not needed > -application layer fragmentation helps with multiplexing request > > > > Cons > -Does not support larger than 16 bits. > -could not do streaming > > > ——————————————————- > Option B > Option like split length with a no length option for reliable transport that already have a framing > > The initial byte of the frame contains two nibbles, in a similar way to the CoAP option encoding (Section 3.1 of [RFC7252]). The first nibble is used to indicate the length of the options (including any option delimiter), and the payload (if any); it does not include the Code byte or the Token bytes. The first nibble is interpreted as a 4-bit unsigned integer. A value between 0 and 12 directly indicates the length of the options/payload, in bytes. The other three values have a special meaning: 13: An 8-bit unsigned integer follows the initial byte and indicates the length of options/payload minus 13. 14: A 16-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 269. 15: A 32-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 65805. 16: no framing. The second nibble of the initial byte indicates the token length. Example: 01 43 7f is a frame j ust containing a 2.03 code with the token 7f. > > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Len | TKL | Len+ bytes... | Code | TKL bytes ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1 1 1 1 1 1 1 1| Payload (if any) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Pros: > -supports larger payload > -flexible (dynamic payload size) > -removed the Message Type field > > > Cons: > -Large message might be difficult to parse or flush for more constraint node. > -cannot be removed if underlining implementation does not need framing > > Let me know what you guys think, any pro or cons missing and what we should process to > > Cheers > > Simon > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Jul 27 11:01:15 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127501B311E for ; Mon, 27 Jul 2015 11:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsckJUy8NXM5 for ; Mon, 27 Jul 2015 11:01:10 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (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 51E691B302A for ; Mon, 27 Jul 2015 11:01:10 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so58854999lbb.0 for ; Mon, 27 Jul 2015 11:01:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MTyOghUC0iJm1B5fJcqb3lysUf8A/6Jm5qR6wAYBZes=; b=CX78dfYdkhVDkXoAPgsYBD/6As2iO1yY1EJ4Vux9iPK/u9ZDnpg17+B9x90TIlMWQg u9PVJAEpT/PNlf2oj6PY9SfCSod9myrk1fxfSnSpFVnYa5q7tJmczFcJ2ZY7/FgiC8me X+MEY7tr7JJw+4mL0UsD2XwlXMBlu3gfBMrMZLJLQpXL/PpBdi5dFKX1B3gnnd0/QFLN UPXgS+PZ+cwBT4ngcxlSxjucwzYnkbeaKIXipOV0QKAOmlcLz1WU/L+wHPKmkrTRYlsN PW8spyuF+4Z1pGytx5tjhCnijuymM/RCyzG+0g09a+cVyzQBCUcRRPCRr/32qROH/fwG 2HIQ== X-Gm-Message-State: ALoCoQlJMy7j3Wyt+Ii5wyOqkMmKbfqixgn8QmSnk/FREgTiCRtdZDV2Q/a1KrOGjDEDLLK59Cc3 MIME-Version: 1.0 X-Received: by 10.152.87.205 with SMTP id ba13mr27412628lab.37.1438020068690; Mon, 27 Jul 2015 11:01:08 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 27 Jul 2015 11:01:08 -0700 (PDT) In-Reply-To: <55B6070A.1020007@ackl.io> References: <4dde82ad1cd4d261b598cb0e851cdf1c@xs4all.nl> <55B6070A.1020007@ackl.io> Date: Mon, 27 Jul 2015 11:01:08 -0700 Message-ID: From: Andy Bierman To: Alexander Pelov Content-Type: multipart/alternative; boundary=001a11c3539a5fe4a2051bdf238f Archived-At: Cc: Core Subject: Re: [core] YANG Packages for CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 18:01:14 -0000 --001a11c3539a5fe4a2051bdf238f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 27, 2015 at 3:25 AM, Alexander Pelov wrote: > Hi Andy! > > Thanks for the draft! Seems a good start to get the things moving in the > direction of having a good, structured introspection mechanism for module > discovery! > > I'm not completely sure that it will be a static document. You still need > to think of the possibility of a firmware upgrade, in which case you have > to consider the clients which have obtained your previous package > descriptions. > > Each package has a name and a revision-date. The expected use for CoMI would be a new package revision for each firmware release. > Why don't you want it to be a YANG module? I would suppose that for a > structured numbering scheme (such as CoOL) we could have a nice fixed ent= ry > point for such introspection resource, e.g. moduleID =3D 1. Alternatively= , I > would think that it should be discoverable through .well-known/core > > Not sure what you mean. This is static data used to identify a set of YANG modules. Do you mean why not have the contents of a package be YANG objects to read from the server? This would be even more data than the current YANG module library. The point of a package list is to avoid listing all the modules, features, and revision dates. There is a YANG Package Identifier in sec. 4 urn:ietf:params:xml:ns:yang:pkg?name=3Dexample-sensor314&rev=3D2015-07-01 This would be the entire response needed to discover the entire YANG implementation by the server. The size remains the same no matter how many modules and features are added over time. > A point to make is that we can have alias mappings through this > introspection mechanism. Defining such an introspection mechanism for the > aliases was actually one of the work I was considering for CoOL. > > RESTCONF and NETCONF provide the ability for the client to retrieve the schema, and get all the meta-data, for every module. IMO this should be done by a centralized server in CoMI. But I agree the package data could include alias mappings. This might be a way to convert YANG Hash to COOL for example, to optimize frequently used identifiers.. > Best, > Alexander > Andy > > Le 27/07/2015 08:29, Andy Bierman a =C3=A9crit : > > > > On Sun, Jul 26, 2015 at 11:26 PM, peter van der Stok < > stokcons@xs4all.nl> wrote: > >> HI Andy, >> >> Is the proposal to make YANG packages compulsory over yang-library in >> Comi servers and clients? >> >> > No, it would be optional. > Another solution approach would be to make the module-set-id values > global instead of per-server. That might be less work perhaps. > > > Peter >> > > Andy > > >> >> Andy Bierman schreef op 2015-07-26 19:44: >> >>> Hi, >>> >>> Michel raised some issues with the YANG library draft >>> http://datatracker.ietf.org/doc/draft-ietf-netconf-yang-library/ >>> >>> Maybe CoMI needs its own optimized module library. >>> I am concerned that data sizes of the YANG library will be >>> too big in some really constrained environments. >>> >>> I wrote a draft that defines a way to specify the contents of the >>> YANG library in a single static document, called a YANG package. >>> http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ >>> >>> If there was a "shorthand" resource that listed YANG packages, instead >>> of YANG modules, then the CoMI client that supported YANG packages >>> could read that instead of the module library. >>> >>> The YANG package message response can identify a single package >>> (e.g. match the firmware) so the size of the response will remain very >>> small, and not depend on the entire list of modules, features, >>> and deviations. The data savings could 1000X for 100 modules. >>> >>> The client needs to retrieve the library first-time and anytime it >>> changes. >>> The module-set-id values are per-server, not global. This could be a >>> significant bottleneck when a CoMI client starts or restarts, and >>> manages lots of servers. >>> >>> Andy >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >> > > > _______________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > > --001a11c3539a5fe4a2051bdf238f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 27, 2015 at 3:25 AM, Alexander Pelov <= alexander@ackl.io> wrote:
=20 =20 =20
Hi Andy!

Thanks for the draft! Seems a good start to get the things moving in the direction of having a good, structured introspection mechanism for module discovery!

I'm not completely sure that it will be a static document. You stil= l need to think of the possibility of a firmware upgrade, in which case you have to consider the clients which have obtained your previous package descriptions.


Each package has a name and = a revision-date.
The expected use for CoMI would be a new
package revision for each firmware release.


to read from the server?=C2=A0 This would be even more data than the
current YANG module library.

The point of a= package list is to avoid listing all the modules, features,
and = revision dates.=C2=A0 There is a YANG Package Identifier in sec. 4









=C2=A0
Best,
Alexander

Andy
=C2= =A0

Le 27/07/2015 08:29, Andy Bierman a =C3=A9crit=C2=A0:


On Sun, Jul 26, 2015 at 11:26 PM, peter van der Stok <stokcons@xs4all.nl> wrote:
HI Andy,

Is the proposal to make YANG packages compulsory over yang-library in Comi servers and clients?


No, it would be optional.
Another solution approach would be to make the module-set-id values
global instead of per-server. That might be less work perhaps.


Peter

Andy
=C2=A0

Andy Bierman schreef op 2015-07-26 19:44:
Hi,

Michel raised some issues with the YANG library draft
http://datatracker.i= etf.org/doc/draft-ietf-netconf-yang-library/

Maybe CoMI needs its own optimized module library.
I am concerned that data sizes of the YANG library will be
too big in some really constrained environments.

I wrote a draft that defines a way to specify the contents of the
YANG library in a single static document, called a YANG package.
http://datatracker= .ietf.org/doc/draft-bierman-netmod-yang-package/

If there was a "shorthand" resource that listed Y= ANG packages, instead
of YANG modules, then the CoMI client that supported YANG packages
could read that instead of the module library.

The YANG package message response can identify a single package
(e.g. match the firmware) so the size of the response will remain very
small, and not depend on the entire list of modules, features,
and deviations. The data savings could 1000X for 100 modules.

The client needs to retrieve the library first-time and anytime it
changes.
The module-set-id values are per-server, not global. This could be a
significant bottleneck when a CoMI client starts or restarts, and
manages lots of servers.

Andy


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



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


--001a11c3539a5fe4a2051bdf238f-- From nobody Mon Jul 27 14:37:15 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB321B3106 for ; Mon, 27 Jul 2015 14:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.655 X-Spam-Level: X-Spam-Status: No, score=0.655 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOt6HpAgr9xK for ; Mon, 27 Jul 2015 14:37:12 -0700 (PDT) Received: from ni.com (skprod3.natinst.com [130.164.80.24]) (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 0C5B41B3258 for ; Mon, 27 Jul 2015 14:37:11 -0700 (PDT) Received: from US-AUS-MAIL4.amer.corp.natinst.com (nb-snip2-1338.natinst.com [130.164.19.135]) by us-aus-skprod3.natinst.com (8.15.0.59/8.15.0.59) with ESMTP id t6RLbAGv006130 for ; Mon, 27 Jul 2015 16:37:10 -0500 To: Core MIME-Version: 1.0 X-KeepSent: 7777CDDA:34EC1897-86257E8F:006BA12D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP6 November 22, 2013 From: Rodney Cummings Message-ID: Date: Mon, 27 Jul 2015 16:37:11 -0500 X-MIMETrack: Serialize by Router on US-AUS-MAIL4/AUS/M/NIC(Release 8.5.3FP6 HF1218|December 12, 2014) at 07/27/2015 04:37:11 PM, Serialize complete at 07/27/2015 04:37:11 PM Content-Type: multipart/alternative; boundary="=_alternative 0076C29A86257E8F_=" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-07-27_03:, , signatures=0 Archived-At: Subject: [core] Questions on CoMI rehash map X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 21:37:14 -0000 This is a multipart message in MIME format. --=_alternative 0076C29A86257E8F_= Content-Type: text/plain; charset="US-ASCII" Hello, I have some potentially naive questions on the rehash map specified in sections 5.2 and 5.3 of the latest CoMI draft 07: https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ I apologize if these questions have already been discussed. If we can find ways to get the client and server "in sync" with regard to hash collisions, we could remove the need for the ietf-yang-hash module. Removing ietf-yang-hash would result in more efficient and constrained processing, such as removing the need to store extra "path" objects when multiple objects in a module collide. Some questions: 1. Is it possible to mandate a mechanism for the server to report all supported data nodes to the client? 2. Is it possible to specify the traversal algorithm that both client and server use to create hashes for data nodes? 3. When a hash collision occurs, is it possible to specify the algorithm to create a new hash repetitively until a non-colliding hash is found? For item #1, if the CoAP interfaces of section 3 are not sufficient, we could potentially use the new YANG package proposal. Regardless of challenges with the hash collision, this seems like something that the server should deliver to the client with a clear mechanism, so that the client knows what is supported in the server. This needs to be mandatory, in order to avoid the situation in which the client accesses a data node that the server is unfamiliar with, resulting in an unexpected hash collision. Error detection/reporting on access to unsupported objects is best performed at the client, not the server. Once we have used item #1 to bring client and server in sync on the data nodes to be hashed, items #2 and #3 are intended to ensure that client and server resolve the hash collisions in exactly the same order and the same way. Item #2 specifies the order in which modules are evaluated for hash (e.g. alphabetical), as well as the order in which each module's data nodes are traversed (e.g. breadth first). Item #3 specifies how to rehash in order to avoid collision (e.g. increment the seed for murmur3_32 until collision free). If both client and server use exactly the same traversal and the same collision resolution, the ietf-yang-hash module is no longer needed. Maybe I am missing something fundamental? Thanks ---------------------------- Rodney Cummings Principal Software Architect, Industrial/Embedded Networks National Instruments Tel: (512) 683-8544 Fax: (512) 683-8661 Email: Rodney.Cummings@ni.com --=_alternative 0076C29A86257E8F_= Content-Type: text/html; charset="US-ASCII" Hello,

I have some potentially naive questions on the rehash map specified in sections 5.2 and 5.3 of the latest CoMI draft 07:
        https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/
I apologize if these questions have already been discussed.

If we can find ways to get the client and server "in sync" with regard to hash collisions, we could remove the need for the ietf-yang-hash module. Removing ietf-yang-hash would result in more efficient and constrained processing, such as removing the need to store extra "path" objects when multiple objects in a module collide.

Some questions:
1. Is it possible to mandate a mechanism for the server to report all supported data nodes to the client?
2. Is it possible to specify the traversal algorithm that both client and server use to create hashes for data nodes?
3. When a hash collision occurs, is it possible to specify the algorithm to create a new hash repetitively until a non-colliding hash is found?

For item #1, if the CoAP interfaces of section 3 are not sufficient, we could potentially use the new YANG package proposal. Regardless of challenges with the hash collision, this seems like something that the server should deliver to the client with a clear mechanism, so that the client knows what is supported in the server. This needs to be mandatory, in order to avoid the situation in which the client accesses a data node that the server is unfamiliar with, resulting in an unexpected hash collision. Error detection/reporting on access to unsupported objects is best performed at the client, not the server.

Once we have used item #1 to bring client and server in sync on the data nodes to be hashed, items #2 and #3 are intended to ensure that client and server resolve the hash collisions in exactly the same order and the same way. Item #2 specifies the order in which modules are evaluated for hash (e.g. alphabetical), as well as the order in which each module's data nodes are traversed (e.g. breadth first). Item #3 specifies how to rehash in order to avoid collision (e.g. increment the seed for murmur3_32 until collision free).

If both client and server use exactly the same traversal and the same collision resolution, the ietf-yang-hash module is no longer needed.

Maybe I am missing something fundamental?

Thanks

----------------------------
Rodney Cummings
Principal Software Architect, Industrial/Embedded Networks
National Instruments
Tel: (512) 683-8544
Fax: (512) 683-8661
Email: Rodney.Cummings@ni.com







        --=_alternative 0076C29A86257E8F_=-- From nobody Mon Jul 27 15:21:18 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2471B34DA for ; Mon, 27 Jul 2015 15:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0b2u_MjbnbO for ; Mon, 27 Jul 2015 15:21:13 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (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 3D6801B34D8 for ; Mon, 27 Jul 2015 15:21:13 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so62861362lbb.1 for ; Mon, 27 Jul 2015 15:21:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=F2Yj3nZdkrhQ1Nc79XsLxUmPuoEmnsaK/OSXPuT4gFc=; b=P/WKhYR886i4NfHOAzhj8zA3tQaLV/pzkW3wh49KfPpe2xsIKf5JmieI7/RLKkCG92 JJ4V2PWr5gqsp3QDSqDatRyx9nJ/O+p7DqDzxhYaNKShenG10oIZykcSYUsl5W84Cwfc OQ8DdwkZcd/BSfrfiWzlvVnf8mAkEFCS+7MayJ3JDf154Era8Cn9rLyiM3TXO8xhbeCC 1a2J7CPdu4IwsIzOw6eLWgSC5EbByxdRsFGDOX6HgpahnRo5XUU/UCqxj5ELEnaHSWhD ZuxLFe06ijG7qUJmypPiD6KIzWX+Hm3B+PTJEm337mbbKVdGhhz7o8ThqkQj0Asld30G HnIA== X-Gm-Message-State: ALoCoQm7ZlzOkmDzJQ5upNrwhk/DMfhT/8sWCBQVb58pEvl+Om9xW+VRi+gZKRbtIIjvJ/O9a10e MIME-Version: 1.0 X-Received: by 10.112.155.164 with SMTP id vx4mr29128638lbb.38.1438035671582; Mon, 27 Jul 2015 15:21:11 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 27 Jul 2015 15:21:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 27 Jul 2015 15:21:11 -0700 Message-ID: From: Andy Bierman To: Rodney Cummings Content-Type: multipart/alternative; boundary=089e01228a92612206051be2c580 Archived-At: Cc: Core Subject: Re: [core] Questions on CoMI rehash map X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 22:21:16 -0000 --089e01228a92612206051be2c580 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 27, 2015 at 2:37 PM, Rodney Cummings wrote: > Hello, > > I have some potentially naive questions on the rehash map specified in > sections 5.2 and 5.3 of the latest CoMI draft 07: > https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ > I apologize if these questions have already been discussed. > > If we can find ways to get the client and server "in sync" with regard to > hash collisions, we could remove the need for the ietf-yang-hash module. > Removing ietf-yang-hash would result in more efficient and constrained > processing, such as removing the need to store extra "path" objects when > multiple objects in a module collide. > > The rehash mechanism is being reworked (again), but it does not go away. Can you explain your solution in more detail? > Some questions: > 1. Is it possible to mandate a mechanism for the server to report all > supported data nodes to the client? > There is a resource /mg/mod.uri that indicates the URI of the YANG library data for the server. This is how YANG reports all the supported data nodes. > 2. Is it possible to specify the traversal algorithm that both client and > server use to create hashes for data nodes? > No because YANG allows data to be added in the middle of a sibling-set. YANG also supports sub-modules and the order they are parsed could affect module order. One important property of the YANG Hash is that is does not change over time. If /foo/bar is defined in version 1, then it has to remain the same value in version 2, 3, etc. This allows clients compiled in firmware against version 1 to keep working. 3. When a hash collision occurs, is it possible to specify the algorithm to > create a new hash repetitively until a non-colliding hash is found? > This may be possible, but it assumes the client knows the full set of hashes on the server. Michel has proposed a rehash scheme (offline) that is being discussed. It fixes some problems with rehash, but cost an extra "rehash" bit in the ID, which makes rehashed IDs 31 bits, not 30. > > For item #1, if the CoAP interfaces of section 3 are not sufficient, we > could potentially use the new YANG package proposal. Regardless of > challenges with the hash collision, this seems like something that the > server should deliver to the client with a clear mechanism, so that the > client knows what is supported in the server. This needs to be mandatory, > in order to avoid the situation in which the client accesses a data node > that the server is unfamiliar with, resulting in an unexpected hash > collision. Error detection/reporting on access to unsupported objects is > best performed at the client, not the server. > > Once we have used item #1 to bring client and server in sync on the data > nodes to be hashed, items #2 and #3 are intended to ensure that client and > server resolve the hash collisions in exactly the same order and the same > way. Item #2 specifies the order in which modules are evaluated for hash > (e.g. alphabetical), as well as the order in which each module's data nodes > are traversed (e.g. breadth first). Item #3 specifies how to rehash in > order to avoid collision (e.g. increment the seed for murmur3_32 until > collision free). > > If both client and server use exactly the same traversal and the same > collision resolution, the ietf-yang-hash module is no longer needed. > > Maybe I am missing something fundamental? > This may work. There might be some rehash info that needs to be sent if a rehashed ID is used by the client. > > Thanks > Andy > > ---------------------------- > Rodney Cummings > Principal Software Architect, Industrial/Embedded Networks > National Instruments > Tel: (512) 683-8544 > Fax: (512) 683-8661 > Email: Rodney.Cummings@ni.com > > > > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --089e01228a92612206051be2c580 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 27, 2015 at 2:37 PM, Rodney Cummings <= rodney.cummings= @ni.com> wrote:
Hello,

I have some potentially naive ques= tions on the rehash map specified in sections 5.2 and 5.3 of the latest CoMI draft 07:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.i= etf.org/doc/draft-vanderstok-core-comi/
I apologize if these questions hav= e already been discussed.

If we can find ways to get the cli= ent and server "in sync" with regard to hash collisions, we could remove the need for the ietf-yang-hash module. Removing ietf-yang-hash would result in more efficient and constrained processing, such as removing the need to store extra "path" objects when multiple objects in a module collide.



The rehash mechanism is= being reworked (again), but it does not go away.
Can you explain= your solution in more detail?
=C2=A0
Some questions:
1. Is it possible to mandate a mec= hanism for the server to report all supported data nodes to the client?


There is a resource /mg= /mod.uri that indicates the URI of the YANG library data
for the = server. This is how YANG reports all the supported data nodes.
=C2=A0
2. Is it possible to specify the traversal algorithm that both client and server use to create hashes for data nodes?<= /font>

No because YANG allows data to be adde= d in the middle of a sibling-set.
YANG also supports sub-modules = and the order they are parsed
could affect module order.

One important property of the YANG Hash is that is does no= t
change over time. If /foo/bar is defined in version 1,
then it has to remain the same value in version 2, 3, etc.
This= allows clients compiled in firmware against version 1
to keep wo= rking.



3. When a hash collision= occurs, is it possible to specify the algorithm to create a new hash repetitively until a non-colliding hash is found?

This may be possible, but it assumes t= he client knows the full set of hashes
on the server.
<= br>
Michel has proposed a rehash scheme (offline) that is being d= iscussed.
It fixes some problems with rehash, but cost an extra &= quot;rehash" bit in the ID,
which makes rehashed IDs 31 bits= , not 30.


=C2=A0

For item #1, if the CoAP interface= s of section 3 are not sufficient, we could potentially use the new YANG package proposal. Regardless of challenges with the hash collision, this seems like something that the server should deliver to the client with a clear mechanism, so that the client knows what is supported in the server= . This needs to be mandatory, in order to avoid the situation in which the client accesses a data node that the server is unfamiliar with, resulting in an unexpected hash collision. Error detection/reporting on access to unsupported objects is best performed at the client, not the server.

Once we have used item #1 to bring= client and server in sync on the data nodes to be hashed, items #2 and #3 are intended to ensure that client and server resolve the hash collisions in exactly the same order and the same way. Item #2 specifies the order in which modules are evaluated for hash (e.g. alphabetical), as well as the order in which each module's data nodes are traversed (e.g. breadth fir= st). Item #3 specifies how to rehash in order to avoid collision (e.g. increment the seed for murmur3_32 until collision free).

If both client and server use exac= tly the same traversal and the same collision resolution, the ietf-yang-hash module is no longer needed.

Maybe I am missing something funda= mental?


This may work. There mi= ght be some rehash info that needs to be
sent if a rehashed ID is= used by the client.

=C2=A0

Thanks


Andy
=C2=A0

----------------------------
Rodney Cummings
Principal Software Architect, Industrial/Embedded Networks
National Instruments
Tel: (512) 683-8544
Fax: (512) 683-8661
Email: Rodney.C= ummings@ni.com







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


--089e01228a92612206051be2c580-- From nobody Mon Jul 27 15:49:10 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CE61B34F5 for ; Mon, 27 Jul 2015 15:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z88ARY_TIvwh for ; Mon, 27 Jul 2015 15:49:06 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1591B33C6 for ; Mon, 27 Jul 2015 15:49:06 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 27 Jul 2015 15:49:03 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Mon, 27 Jul 2015 15:49:03 -0700 From: Michelle Cotton To: "core@ietf.org" Thread-Topic: [core] Range issue in core-parameters registry Thread-Index: AQHQxUFH/jFy/PPrsUWUbnVd8xn09Z3pcWeAgAAEBICABnzugA== Date: Mon, 27 Jul 2015 22:49:03 +0000 Message-ID: References: <55B0DE45.2060701@tzi.org> <16FC8F43-3BBF-4AAE-9EC5-4F23C1272470@arm.com> In-Reply-To: <16FC8F43-3BBF-4AAE-9EC5-4F23C1272470@arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3520856941_6112929" MIME-Version: 1.0 Archived-At: Cc: Barry Leiba Subject: Re: [core] Range issue in core-parameters registry X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 22:49:08 -0000 --B_3520856941_6112929 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Any resolution of what needs to be done here? Thanks in advance. Michelle Cotton Protocol Parameters Engagement Manager ICANN On 7/23/15, 5:44 AM, "Zach Shelby" wrote: >Carsten, > >Yes, the 0..255 range should be used sparingly, preferably for widely >used RFCs and CoRE specifications. No problem here. > >The problem is what to do with other requests? Since we have not done a >great unification of media types, we are now getting requests for those >on a one-by-one basis as they come into use on CoAP. The natural place to >assign these would be 256-9999, the jump from 255 to 10000 is pretty >extreme. I would prefer to use the experimental range for things that >really are experimental, and assign requests based on solid >specifications to 256-9999. > >Maybe time to give up on the great unification experiment? We need to do >it very soon, or end up with a bunch of duplicates. > >Zach > >On Jul 23, 2015, at 3:29 PM, Carsten Bormann wrote: > >> The range 256-9999 has been put away for the great unification of media >> type and content format registries, something we haven't quite gotten to >> (it will involve some discussion of updating existing registries etc.). >> >> TL;DR: Everything is as it should be. >> >> That said, the instructions for the expert about 0..255 are not very >> specific. The idea is of course not to use up that space in a jiffy, so >> some pushback is expected from the expert; the preference for allocating >> these golden 1-byte numbers should go to IETF review specifications. >> >> Gr=FC=DFe, Carsten >> >> >> Michelle Cotton wrote: >>> Hello! >>> >>> After consultations with Barry Leiba and the expert for the >>> core-parameters registry (Zach Shelby) we believe that the range >>> descriptions in the following registry may be backwards: >>> >>>=20 >>>http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#co >>>ntent-formats >>> >>> The registration procedures as defined in RFC 7252 are as follows: >>> >>> 0-255 Expert Review >>> 256-9999 IETF Review or IESG Approval >>> >>> It has been suggested that possibly an errata is needed to reverse the >>> ranges so the Expert Review range is much larger. >>> Any issues with this plan? Thoughts? Comments? >>> >>> I have copied the designated expert for this registry as well. >>> >>> Thank you, >>> >>> Michelle Cotton >>> Protocol Parameters Engagement Manager >>> IANA Department >>> ICANN >>> >>> _______________________________________________ >>> 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 > >Zach Shelby >Vice President, Marketing >ARM Internet of Things BU >www.arm.com >US: +1 (408) 203-9434 >Finland: +358 407796297 >Skype: zdshelby >LinkedIn: fi.linkedin.com/in/zachshelby/ > > >-- 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. > >ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >Registered in England & Wales, Company No: 2557590 >ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >Registered in England & Wales, Company No: 2548782 > --B_3520856941_6112929 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITugYJKoZIhvcNAQcCoIITqzCCE6cCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYYwggb2MIIF3qADAgECAhAFLoNW3qD4JhFZyohPBtNqMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMzAzMjAwMDAw MDBaFw0xNjAzMjAxMjAwMDBaMIGfMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9u IGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczENMAsGA1UECxMESUFOQTEYMBYGA1UE AxMPTWljaGVsbGUgQ290dG9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxWwq bCL/Xkl+g9mKzyjxA8YKyTJgMKkfuNPm2Pi5iWmUGpAHkSCUX/YKf1rninFM8JkzffVgInmx juZQRW7lP2796RU0UAUdEsbfDcE5l4dj8h7omA2HkiwvKgxBwegr8VHjzUxOzSetAio5Y2qA Fs7EY97BX6aulzP+tyKi5+7GSBRq+SguiLYETk4FZo8nmyK8E0210+ozwlUQ0VSfkpWluyc/ wQtRo/vQYoM0DPgVaxkE9r20ReyqaE+mxN2pqKl8qoiNMUAnbJIVUSfZhIxS4yoVKNLsOJzo CYSrD6JgNOmzbEOfrTMWMAhh1RCqp5bcaZ4Zlq2lbrIGHzPgSwIDAQABo4IDaDCCA2QwHwYD VR0jBBgwFoAUFQASKxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFFcRyKFrxJAiHzozbxx0 fzjeiYmeMCQGA1UdEQQdMBuBGW1pY2hlbGxlLmNvdHRvbkBpY2Fubi5vcmcwDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB9BgNVHR8EdjB0MDigNqA0 hjJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDA4 oDagNIYyaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5j cmwwggHFBgNVHSAEggG8MIIBuDCCAbQGCmCGSAGG/WwEAQIwggGkMDoGCCsGAQUFBwIBFi5o dHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYB BQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQA aQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEA bgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAA YQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUA bQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAA YQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMHcGCCsGAQUFBwEBBGswaTAkBggrBgEFBQcw AYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEEGCCsGAQUFBzAChjVodHRwOi8vY2FjZXJ0 cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNydDAMBgNVHRMBAf8EAjAA MA0GCSqGSIb3DQEBBQUAA4IBAQAzABp5GDSqoV3ty0YLFXRO8ZlHtgsLOP+5AmAS9P0mDEny uO6xbrWK/Oi+9/UfcnYKYUGkFvukHBFLowWakQngPhHLjEhNl2QYC4dbQWLd9z4gZWBWYVzs EreLwUSbRbE3G1r/lkUK3EYO5xAAWtFcv0I4Ixd3//0zxg0ohWW7fm22ypXr8HIBffpptim+ 6oO6X55ME5789phHZZDQt6haEHyMnAQNW2SL6e8cgSL30lPcpStRCXriyXBdoSI+oW83+9u3 SvhjG9WXw8sso9oWMBWo8BhSTERNzLYbxQMazYHW5L/BUBUICTR6l3W96+rjpPZDZVpd9wgR AG54dZ+mMIIGzTCCBbWgAwIBAgIQBv35A5YDreoACus/J7u6GzANBgkqhkiG9w0BAQUFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMDYx MTEwMDAwMDAwWhcNMjExMTEwMDAwMDAwWjBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDogi2Z +crCQpWlgHNAcNKeVlRcqcTSQQaPyTP8TUWRXIGf7Syc+BZZ3561JBXCmLm0d0ncicQK2q/L XmvtrbBxMevPOkAMRk2T7It6NggDqww0/hhJgv7HxzFIgHweog+SDlDJxofrNj/YMMP/pvf7 os1vcyP+rFYFkPAyIRaJxnCI+QWXfaPHQ90C6Ds97bFBo+0/vtuVSMTuHrPyvAwrmdDGXRJC geGDboJzPyZLFJCuWWYKxI2+0s4Grq2Eb0iEm09AufFM8q+Y+/bOQF1c9qjxL6/siSLyaxhl scFzrdfx2M8eCnRcQrhofrfVdwonVnwPYqQ/MhRglf0HBKIJAgMBAAGjggN6MIIDdjAOBgNV HQ8BAf8EBAMCAYYwOwYDVR0lBDQwMgYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYI KwYBBQUHAwQGCCsGAQUFBwMIMIIB0gYDVR0gBIIByTCCAcUwggG0BgpghkgBhv1sAAEEMIIB pDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0 b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQA aABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMA IABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQA IABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIA dAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUA ZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjALBglghkgBhv1s AxUwEgYDVR0TAQH/BAgwBgEB/wIBADB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0 dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGln aWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNydDCBgQYDVR0fBHoweDA6oDig NoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNy bDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9v dENBLmNybDAdBgNVHQ4EFgQUFQASKxOYspkH7R7for5XDStnAs0wHwYDVR0jBBgwFoAUReui r/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAEZQPsm3KCSnOB22WymvUs9S 6TFHq1Zce9UNC0Gz7+x1H3Q48rJcYaKclcNQ5IK5I9G6OoZyrTh4rHVdFxc0ckeFlFbR67s2 hHfMJKXzBBlVqefj56tizfuLLZDCwNK1lL1eT7EF0g49GqkUW6aGMWKoqDPkmzmnxPXOHXh2 lCVz5Cqrz5x2S+1fwksW5EtwTACJHvzFebxMElf+X+EevAJdqP77BzhPDcZdkbkPZ0XN1oPt 55INjbFpjE/7WeAjD9KqrgB87pxCDs+R1ye3Fu4Pw718CqDuLAhVhSK46xgaTfwqIa1JMYNH lXdx3LEbS0scEJx3FMGdTy9alQgpECYwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5 MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWV MmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ /hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X 8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk 2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYE FEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgP MA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/M zhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLi l4Qf6WXvh+DfwWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6 ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR 34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6 CkUvovDyMYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1 cmVkIElEIENBLTECEAUug1beoPgmEVnKiE8G02owCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJ BDEWBBTptZIAmqGfwZnqsGU1XPClapG4YDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNTA3MjcyMjQ5MDFaMA0GCSqGSIb3DQEBAQUABIIBAL71NyfFaoZs XN2NXXxYs0tgm3Ap4XQaVAfU33eQd7DJzCTZtXSdmdwoPKpnkWnv+8rjXJJEO1/nswLTUPy6 yr0EuJ+z3pojA/w7LBUYXCsc4wcraekXr2pmrzP5g1/kLxF5j1ddWe4sZWJXFj9z6OcPi3Ck drsA1SpybF3v3ifoTX8CUlKNhNswKb3MjFC5Fv+tpGmvurb70K8o3Qkx6NVHTZQgvJCE+8h2 +WLQUT5hVOzGJSIKK6BIMUMzTXaTsyzMqpMrOSH0bg2xjFg8Y98OccM97rQeruSOus0+RvUV j4bSfig3piifzlJg5S+cj8qnQ8Gxn/3ly0e5LaNoaDE= --B_3520856941_6112929-- From nobody Mon Jul 27 19:56:08 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8511A86F4 for ; Mon, 27 Jul 2015 19:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 5buqL24jLzit for ; Mon, 27 Jul 2015 19:56:06 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C9B1A86E4 for ; Mon, 27 Jul 2015 19:56:05 -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 t6S2tZCP010473; Tue, 28 Jul 2015 04:55:35 +0200 (CEST) Received: from alma.local (p5DC7F6B9.dip0.t-ipconnect.de [93.199.246.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mgN0l2nZVzDHRY; Tue, 28 Jul 2015 04:55:35 +0200 (CEST) Message-ID: <55B6EF25.2020804@tzi.org> Date: Tue, 28 Jul 2015 04:55:33 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Zach Shelby References: <55B0DE45.2060701@tzi.org> <16FC8F43-3BBF-4AAE-9EC5-4F23C1272470@arm.com> In-Reply-To: <16FC8F43-3BBF-4AAE-9EC5-4F23C1272470@arm.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Michelle Cotton , "core@ietf.org" Subject: Re: [core] Range issue in core-parameters registry X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 02:56:08 -0000 Zach Shelby wrote: > Carsten, > > Yes, the 0..255 range should be used sparingly, preferably for widely used RFCs and CoRE specifications. No problem here. > > The problem is what to do with other requests? Since we have not done a great unification of media types, we are now getting requests for those on a one-by-one basis as they come into use on CoAP. The natural place to assign these would be 256-9999, the jump from 255 to 10000 is pretty extreme. I would prefer to use the experimental range for things that really are experimental, and assign requests based on solid specifications to 256-9999. There is no difference in quality between an assigned value of 256 and an assigned value of 10123 -- both need two bytes in the packet. > > Maybe time to give up on the great unification experiment? We need to do it very soon, or end up with a bunch of duplicates. To me it seems we should accelerate the unification. The most expedient approach would be to simply assign the values from https://svn.tools.ietf.org/svn/wg/core/mediatypes.txt for each combination of an existing media type and the identity content coding that is being requested. (Note how this file grows over time by (pseudo-)randomly assigning numbers to new media types, while keeping the assignments of old media types stable.) We probably need to write up how this happens in order to satisfy the "reserved for future use in IETF specifications (IETF Review or IESG Approval)" requirement of RFC 7252. For a while, we can continue generating these numbers in the WG, but ultimately it should be IANA that is generating the numbers alongside a media type registration. Grüße, Carsten > > Zach > > On Jul 23, 2015, at 3:29 PM, Carsten Bormann wrote: > >> The range 256-9999 has been put away for the great unification of media >> type and content format registries, something we haven't quite gotten to >> (it will involve some discussion of updating existing registries etc.). >> >> TL;DR: Everything is as it should be. >> >> That said, the instructions for the expert about 0..255 are not very >> specific. The idea is of course not to use up that space in a jiffy, so >> some pushback is expected from the expert; the preference for allocating >> these golden 1-byte numbers should go to IETF review specifications. >> >> Grüße, Carsten >> >> >> Michelle Cotton wrote: >>> Hello! >>> >>> After consultations with Barry Leiba and the expert for the >>> core-parameters registry (Zach Shelby) we believe that the range >>> descriptions in the following registry may be backwards: >>> >>> http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats >>> >>> The registration procedures as defined in RFC 7252 are as follows: >>> >>> 0-255 Expert Review >>> 256-9999 IETF Review or IESG Approval >>> >>> It has been suggested that possibly an errata is needed to reverse the >>> ranges so the Expert Review range is much larger. >>> Any issues with this plan? Thoughts? Comments? >>> >>> I have copied the designated expert for this registry as well. >>> >>> Thank you, >>> >>> Michelle Cotton >>> Protocol Parameters Engagement Manager >>> IANA Department >>> ICANN >>> >>> _______________________________________________ >>> 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 > > Zach Shelby > Vice President, Marketing > ARM Internet of Things BU > www.arm.com > US: +1 (408) 203-9434 > Finland: +358 407796297 > Skype: zdshelby > LinkedIn: fi.linkedin.com/in/zachshelby/ > > > -- 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. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 > > > From nobody Mon Jul 27 23:23:36 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1A51A1BDE for ; Mon, 27 Jul 2015 23:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6N0g40a9W6pw for ; Mon, 27 Jul 2015 23:23:34 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3463C1A1BDD for ; Mon, 27 Jul 2015 23:23:34 -0700 (PDT) X-AuditID: c1b4fb25-f79046d000007f53-ef-55b71fe468c9 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 88.A7.32595.4EF17B55; Tue, 28 Jul 2015 08:23:32 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.149]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Tue, 28 Jul 2015 08:23:31 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: core Thread-Topic: [core] Question about blockwise and object security Thread-Index: AQHQyEi1ifAo4IfuAEaNVGqjiqBkNZ3u9e2AgAF1YAA= Date: Tue, 28 Jul 2015 06:23:31 +0000 Message-ID: References: <5570428E.5070500@sics.se> <87oaku75cd.fsf@aung.informatik.uni-bremen.de> <87lhe7arpr.fsf@aung.informatik.uni-bremen.de> <87si8a7ztu.fsf@aung.informatik.uni-bremen.de> <55B602D3.1070302@cs.tcd.ie> In-Reply-To: <55B602D3.1070302@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <47BA8096493E744AA88372A2891A7A7C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM+Jvje4T+e2hBj3ThCz2vV3PbDF97zV2 ByaPtd1X2TyWLPnJFMAUxWWTkpqTWZZapG+XwJWxovsva8Eb7orNN5+xNDAe4e5i5OSQEDCR 6H11nAXCFpO4cG89WxcjF4eQwFFGiUtb5rFDOEsYJWYeOgRWxSbgIvGg4RETiC0iICHR+XU/ O4jNLKAvsX/acbC4sICDxN07XWwQNY4SRyZOYoSwrSS2H7sBVsMioCrx9kIvM4jNK2Ah8XPW eWaIZa1MEvM+9YMN5RTQlJjc/hmsiBHovO+n1jBBLBOXuPVkPhPE2QISS/acZ4awRSVePv7H CmKLCuhJrLzexAYRV5JYdPszUD0HUK+mxPpd+hBjrCUWnLjBCmErSkzpfsgOcY+gxMmZT1gm MErMQrJtFkL3LCTds5B0z0LSvYCRdRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYBwe3PJb dQfj5TeOhxgFOBiVeHgVHm0LFWJNLCuuzD3EKM3BoiTOO2NzXqiQQHpiSWp2ampBalF8UWlO avEhRiYOTqkGxsD5LPP7fBdEJFaUXMgtDrrMNG1z55/tVd31czzs5rF8WvwpajMHV7rs5pjp k79mbZr6Zb25SELRuznde0NOdTX4NnsGVjoG3AoVWHRK27F514dFigbHrQ0//jtw5tQH4b49 rAY/Iwt9JrCInHVujVh6fkEqu+RKfb+P21R3X/cxXK+82ktplxJLcUaioRZzUXEiACbSUXik AgAA Archived-At: Subject: Re: [core] Question about blockwise and object security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 06:23:36 -0000 DQoNCk9uIDIwMTUtMDctMjcgMTI6MDcsICJTdGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVuLmZhcnJl bGxAY3MudGNkLmllPiB3cm90ZToNCg0KPg0KPg0KPk9uIDI3LzA3LzE1IDA5OjQ2LCBPbGFmIEJl cmdtYW5uIHdyb3RlOg0KPj4gMi4gaWYgYW4gaW50ZXJtZWRpYXJ5IHNwbGl0cyBhIHByb3RlY3Rl ZCBtZXNzYWdlIGludG8gYmxvY2tzIGl0IG11c3QgYWRkDQo+PiAgICBzb21lIHNvcnQgb2YgaW50 ZWdyaXR5IHByb3RlY3Rpb24gZm9yIHRoZSBibG9jayB0byBlbmFibGUgdGhlDQo+PiAgICByZWNl aXZlciB0byBkZXRlY3QgYW5kIHRocm93IGF3YXkgYmxvY2tzIHRoYXQgaGF2ZSBiZWVuIGluamVj dGVkIGJ5IGENCj4+ICAgIG1hbGljaW91cyBpbnRlcm1lZGlhcnkuDQo+DQo+RldJVywgSSBkb24n dCBiZWxpZXZlIEkndmUgZXZlciBzZWVuIHRoYXQgd29yay4gVGhlIGNydWNpYWwgcHJvYmxlbXMN Cj5iZWluZyB0aGF0IHRoZSByZWNlaXZlciBkb2Vzbid0IGhhdmUgYW55IGJhc2lzIG9uIHdoaWNo IHRvIGFjY2VwdCBvcg0KPnJlamVjdCB0aGUgYWN0aW9ucyBvZiBhbiBpbnRlcm1lZGlhcnksIGFu ZCB0aGF0IGluIGdlbmVyYWwgdGhpcyBjYW4NCj5oYXBwZW4gbW9yZSB0aGFuIG9uY2Ugb24gYSBw YXRoIGFuZCBpdCBtYXkgbm90IGJlIHRoZSB1bHRpbWF0ZSByZWNlaXZlcg0KPndobyBuZWVkcyB0 byBjaGVjay4gQWxsIHRoYXQgc2VlbXMgdG8gYWx3YXlzIGFkZCB1cCB0byBzb21ldGhpbmcgdGhh dA0KPmp1c3QgZG9lc24ndCB3b3JrIGFuZCB5b3UgZW5kIHVwIHdpdGggb25seSBob3AtYnktaG9w IG9yIGVuZC10by1lbmQNCj5zZWN1cml0eSBiZWluZyBwcmFjdGljYWwuDQoNCg0KTWF5YmUgdGhp cyBoYXMgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZCBidXQganVzdCBmb3IgY2xhcmlmaWNhdGlvbjog RG8gd2UNCndhbnQgdG8gc2VjdXJlIGJsb2Nrd2lzZSB0cmFuc2ZlciBlbmQtdG8tZW5kIG9yIHNo b3VsZCB3ZSBsZWF2ZSB0byB0aGUNCmFwcGxpY2F0aW9ucyBvZiBDb0FQPyBFeGFtcGxlIG9mIHVz ZSBjYXNlIG1lbnRpb25lZCBpcyBmaXJtd2FyZSB1cGRhdGUuDQoNCiANCg0KUmVnYXJkcywNCkfD tnJhbg0KDQoNCg0KDQo+DQo+Uy4NCg0K From nobody Tue Jul 28 00:04:22 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204741A6EDC for ; Tue, 28 Jul 2015 00:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oG9RIGCE63jh for ; Tue, 28 Jul 2015 00:04:15 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1EF1A3BA0 for ; Tue, 28 Jul 2015 00:04:14 -0700 (PDT) Received: from mfilter20-d.gandi.net (mfilter20-d.gandi.net [217.70.178.148]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 56AB341C05A; Tue, 28 Jul 2015 09:04:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter20-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter20-d.gandi.net (mfilter20-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id xYUGL81roTjl; Tue, 28 Jul 2015 09:04:09 +0200 (CEST) X-Originating-IP: 85.68.132.137 Received: from Zax.local (abo-137-132-68.bdx.modulonet.fr [85.68.132.137]) (Authenticated sender: alex@ackl.io) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 8E3F841C07B; Tue, 28 Jul 2015 09:04:08 +0200 (CEST) To: Andy Bierman References: <4dde82ad1cd4d261b598cb0e851cdf1c@xs4all.nl> <55B6070A.1020007@ackl.io> From: Alexander Pelov Message-ID: <55B72969.4050006@ackl.io> Date: Tue, 28 Jul 2015 09:04:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060001000506080707020405" Archived-At: Cc: Core Subject: Re: [core] YANG Packages for CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 07:04:19 -0000 This is a multi-part message in MIME format. --------------060001000506080707020405 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Andy, Le 27/07/2015 20:01, Andy Bierman a =C3=A9crit : > > > On Mon, Jul 27, 2015 at 3:25 AM, Alexander Pelov > wrote: > > Hi Andy! > > Thanks for the draft! Seems a good start to get the things moving > in the direction of having a good, structured introspection > mechanism for module discovery! > > I'm not completely sure that it will be a static document. You > still need to think of the possibility of a firmware upgrade, in > which case you have to consider the clients which have obtained > your previous package descriptions. > > > Each package has a name and a revision-date. > The expected use for CoMI would be a new > package revision for each firmware release. I meant that there should be a mechanism for the client to be notified=20 when the YANG package definition changes. This may be a rare event, but=20 imagine a new client arrives and discovers the server 1 minute before=20 the server gets a new firmware release (or some other event, making it=20 change its package definition). I would think that if a client is expected to keep long-term association=20 to the server, it should use Observe or NOTIFY. The latter will work if=20 the package is defined as module. > > Why don't you want it to be a YANG module? I would suppose that > for a structured numbering scheme (such as CoOL) we could have a > nice fixed entry point for such introspection resource, e.g. > moduleID =3D 1. Alternatively, I would think that it should be > discoverable through .well-known/core > > > Not sure what you mean. > This is static data used to identify a set of YANG modules. > Do you mean why not have the contents of a package be YANG objects > to read from the server? This would be even more data than the > current YANG module library. > > The point of a package list is to avoid listing all the modules, featur= es, > and revision dates. There is a YANG Package Identifier in sec. 4 > > urn:ietf:params:xml:ns:yang:pkg?name=3Dexample-sensor314&rev=3D2015-= 07-01 > > This would be the entire response needed to discover the entire YANG > implementation by the server. The size remains the same no matter how m= any > modules and features are added over time. Ah, OK! Now I understand! It was not obvious to me that you were aiming=20 at having the package definition be detached from the server. I like=20 that! This, however makes me think about something else - you should=20 have a way to obtain the package from the sensor. However, this goes a=20 little bit in the sense of having YANG packages being mandatory for=20 CoMI. I like the "uses-package" statement, as this could be used to have=20 full definition of the modules on a server. I would suppose that you could represent the information of a YANG=20 package as a YANG module. Then, a client could query the server with a=20 select/fields statement to obtain only the package identifier. IF the=20 client wants, it could obtain the whole package content from the server: E.g. for a YANG module definition such as: module yang-package { ... leaf yang-package-uri { type string; } container package { leaf organization {type string;} leaf contact {type string;} leaf description {type string;} leaf revision {type string;} container imports-module { key module-name; leaf module-name {type string;} leaf module-cool-id {type int32;} } container uses-module { ... } ... } } module ID for this module would be fixed in CoOL to 1, so=20 yang-package-uri will have CoOL ID 2049. In CoOL this would be as getting : GET /cdat?fields(2049) Response: { 2049:"urn:ietf:params:xml:ns:yang:pkg?name=3Dexample-sensor314&rev=3D2015= -07-01" } Maybe this could be even more optimized. Now, if the client has no idea how to find this URN, it would simply =20 GET /cdat?fields(2048) and retrieve the YANG package information from=20 the server. > > > > > A point to make is that we can have alias mappings through this > introspection mechanism. Defining such an introspection mechanism > for the aliases was actually one of the work I was considering for > CoOL. > > > RESTCONF and NETCONF provide the ability for the client to retrieve > the schema, and get all the meta-data, for every module. > IMO this should be done by a centralized server in CoMI. > > But I agree the package data could include alias mappings. > This might be a way to convert YANG Hash to COOL for example, > to optimize frequently used identifiers.. Maybe this should also be the way to handle alias attribution, e.g. add=20 a "alias" statement, which indicates the mapping alias-id -> CoOL id /=20 CoMI hash / full identifier. module yang-package { .... container alias { key cool-id; leaf cool-id {type int32}; leaf alias-id {type int32}; } } So you can GET /cdat?fields(2058) and have { 2058: [ {11: 29834394, 12:1}, {11: 99999999, 12:2} {11: 88888384, 12:3} ] } assuming the following CoOL id automatic attribution: alias -> node ID=3D10 cool-id -> node Id=3D11 alias-id -> node ID=3D12 and some random IDs to be mapped (29834394, 99999999, 88888384). Ideally, of course, you would be fetching this information from a server=20 somewhere on the Internet, so that you don't fetch from your constrained=20 server. Best, Alexander > > > > > Best, > Alexander > > > Andy > > > Le 27/07/2015 08:29, Andy Bierman a =C3=A9crit : >> >> >> On Sun, Jul 26, 2015 at 11:26 PM, peter van der Stok >> > wrote: >> >> HI Andy, >> >> Is the proposal to make YANG packages compulsory over >> yang-library in Comi servers and clients? >> >> >> No, it would be optional. >> Another solution approach would be to make the module-set-id value= s >> global instead of per-server. That might be less work perhaps. >> >> >> Peter >> >> >> Andy >> >> >> Andy Bierman schreef op 2015-07-26 19:44: >> >> Hi, >> >> Michel raised some issues with the YANG library draft >> http://datatracker.ietf.org/doc/draft-ietf-netconf-yang-li= brary/ >> >> Maybe CoMI needs its own optimized module library. >> I am concerned that data sizes of the YANG library will be >> too big in some really constrained environments. >> >> I wrote a draft that defines a way to specify the >> contents of the >> YANG library in a single static document, called a YANG >> package. >> http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-= package/ >> >> If there was a "shorthand" resource that listed YANG >> packages, instead >> of YANG modules, then the CoMI client that supported YANG >> packages >> could read that instead of the module library. >> >> The YANG package message response can identify a single >> package >> (e.g. match the firmware) so the size of the response >> will remain very >> small, and not depend on the entire list of modules, >> features, >> and deviations. The data savings could 1000X for 100 modul= es. >> >> The client needs to retrieve the library first-time and >> anytime it >> changes. >> The module-set-id values are per-server, not global. This >> could be a >> significant bottleneck when a CoMI client starts or >> restarts, and >> manages lots of servers. >> >> Andy >> >> >> _______________________________________________ >> 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 > > --------------060001000506080707020405 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Andy,

Le 27/07/2015 20:01, Andy Bierman a =C3=A9crit=C2=A0:


On Mon, Jul 27, 2015 at 3:25 AM, Alexander Pelov <alexander@ackl.io> wro= te:
Hi Andy!

Thanks for the draft! Seems a good start to get the things moving in the direction of having a good, structured introspection mechanism for module discovery!

I'm not completely sure that it will be a static document. You still need to think of the possibility of a firmware upgrade, in which case you have to consider the clients which have obtained your previous package descriptions.


Each package has a name and a revision-date.
The expected use for CoMI would be a new
package revision for each firmware release.
I meant that there should be a mechanism for the client to be notified when the YANG package definition changes. This may be a rare event, but imagine a new client arrives and discovers the server 1 minute before the server gets a new firmware release (or some other event, making it change its package definition).

I would think that if a client is expected to keep long-term association to the server, it should use Observe or NOTIFY. The latter will work if the package is defined as module.


=C2=A0
Why don't you wa= nt it to be a YANG module? I would suppose that for a structured numbering scheme (such as CoOL) we could have a nice fixed entry point for such introspection resource, e.g. moduleID =3D 1. Alternatively, I would think that it should be discoverable through .well-known/core


Not sure what you mean.
This is static data used to identify a set of YANG modules.
Do you mean why not have the contents of a package be YANG objects
to read from the server?=C2=A0 This would be even more d= ata than the
current YANG module library.

The point of a package list is to avoid listing all the modules, features,
and revision dates.=C2=A0 There is a YANG Package Identi= fier in sec. 4

  urn:ietf:params:xml:ns:yang:pkg?name=3Dexample-sensor314=
&rev=3D2015-07-01

This would be the entire response needed to discover the entire YANG
implementation by the server. The size remains the same no matter how many
modules and features are added over time.

Ah, OK! Now I understand! It was not obvious to me that you were aiming at having the package definition be detached from the server. I like that! This, however makes me think about something else - you should have a way to obtain the package from the sensor. However, this goes a little bit in the sense of having YANG packages being mandatory for CoMI. I like the "uses-package" statement, as this could be used to have full definition of the modules on a server.

I would suppose that you could represent the information of a YANG package as a YANG module. Then, a client could query the server with a select/fields statement to obtain only the package identifier. IF the client wants, it could obtain the whole package content from the server:

E.g. for a YANG module definition such as:
module yang-package {
=C2=A0 ...
=C2=A0 leaf yang-package-uri {
=C2=A0=C2=A0=C2=A0 type string;
=C2=A0 }

=C2=A0 container package {
=C2=A0=C2=A0=C2=A0 leaf organization {type string;}
=C2=A0=C2=A0=C2=A0 leaf contact {type string;}
=C2=A0=C2=A0=C2=A0 leaf description {type string;}
=C2=A0=C2=A0=C2=A0 leaf revision {type string;}
=C2=A0=C2=A0=C2=A0 container imports-module {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key module-name;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf module-name {type string;}<= br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf module-cool-id {type int32;= }
=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 container uses-module {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...
=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 ...
=C2=A0 }
}

module ID for this module would be fixed in CoOL to 1, so yang-package-uri will have CoOL ID 2049.

In CoOL this would be as getting :
GET /cdat?fields(2049)

Response:
{
2049:"urn:ietf:params:xml:ns:yang:pkg?name=3Dexample-sensor314&rev=3D= 2015-07-01"
}

Maybe this could be even more optimized.

Now, if the client has no idea how to find this URN, it would simply=C2=A0 GET /cdat?fields(2048) and retrieve the YANG package information from the server.




=C2=A0
A point to make = is that we can have alias mappings through this introspection mechanism. Defining such an introspection mechanism for the aliases was actually one of the work I was considering for CoOL.


RESTCONF and NETCONF provide the ability for the client to retrieve
the schema, and get all the meta-data, for every module.
IMO this should be done by a centralized server in CoMI.

But I agree the package data could include alias mappings.
This might be a way to convert YANG Hash to COOL for example,
to optimize frequently used identifiers..

Maybe this should also be the way to handle alias attribution, e.g. add a "alias" statement, which indicates the mapping alias-id -> CoOL id / CoMI hash / full identifier.

module yang-package {
....
=C2=A0 container alias {
=C2=A0=C2=A0=C2=A0 key cool-id;
=C2=A0=C2=A0=C2=A0 leaf cool-id {type int32};
=C2=A0=C2=A0=C2=A0 leaf alias-id {type int32};
=C2=A0 }
}

So you can GET /cdat?fields(2058) and have
{
=C2=A0 2058: [
=C2=A0=C2=A0=C2=A0 {11: 29834394, 12:1},
=C2=A0 =C2=A0 {11: 99999999, 12:2}
=C2=A0 =C2=A0 {11: 88888384, 12:3}
=C2=A0 ]
}

assuming the following CoOL id automatic attribution:
alias -> node ID=3D10
cool-id -> node Id=3D11
alias-id -> node ID=3D12
and some random IDs to be mapped (29834394, 99999999, 88888384).

Ideally, of course, you would be fetching this information from a server somewhere on the Internet, so that you don't fetch from your constrained server.

Best,
Alexander




=C2=A0
Best,
Alexander

Andy
=C2=A0

Le 27/07/2015 08:29, Andy Bierman a =C3=A9crit=C2=A0= :


On Sun, Jul 26, 2015 at 11:26 PM, peter van der Stok &l= t;stokcons@xs4all.nl&= gt; wrote:
HI Andy,

Is the proposal to make YANG packages compulsory over yang-library in Comi servers and clients?


No, it would be optional.
Another solution approach would be to make the module-set-id values
global instead of per-server. That might be less work perhaps.


Peter

Andy
=C2=A0

Andy Bierman schreef op 2015-07-26 19:44:
Hi,

Michel raised some issues with the YANG library draft
http:/= /datatracker.ietf.org/doc/draft-ietf-netconf-yang-library/

Maybe CoMI needs its own optimized module library.
I am concerned that data sizes of the YANG library will be
too big in some really constrained environments.

I wrote a draft that defines a way to specify the contents of the
YANG library in a single static document, called a YANG package.
http:/= /datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/

If there was a "shorthand" resource that listed YANG packages, instead
of YANG modules, then the CoMI client that supported YANG packages
could read that instead of the module library.

The YANG package message response can identify a single package
(e.g. match the firmware) so the size of the response will remain very
small, and not depend on the entire list of modules, features,
and deviations. The data savings could 1000X for 100 modules.

The client needs to retrieve the library first-time and anytime it
changes.
The module-set-id values are per-server, not global. This could be a
significant bottleneck when a CoMI client starts or restarts, and
manages lots of servers.

Andy


_______________________________________________
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



--------------060001000506080707020405-- From nobody Tue Jul 28 00:47:29 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203AB1A7025 for ; Tue, 28 Jul 2015 00:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.061 X-Spam-Level: X-Spam-Status: No, score=-4.061 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-e6vPvwAd2j for ; Tue, 28 Jul 2015 00:47:26 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C091A701D for ; Tue, 28 Jul 2015 00:47:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,561,1432591200"; d="scan'208";a="171849307" Received: from zmbs2.inria.fr ([128.93.142.15]) by mail2-relais-roc.national.inria.fr with ESMTP; 28 Jul 2015 09:47:24 +0200 Date: Tue, 28 Jul 2015 09:47:24 +0200 (CEST) From: William Bertier To: Carsten Bormann Message-ID: <371832648.7815014.1438069644282.JavaMail.zimbra@inria.fr> In-Reply-To: <1035260517.4900766.1436946361595.JavaMail.zimbra@inria.fr> References: <1410780645.4260510.1436536900559.JavaMail.zimbra@inria.fr> <1931277357.4267342.1436537674832.JavaMail.zimbra@inria.fr> <1220732518.4891641.1436945040727.JavaMail.zimbra@inria.fr> <55A60BC8.4030005@tzi.org> <1035260517.4900766.1436946361595.JavaMail.zimbra@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [131.254.12.159] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF38 (Linux)/8.0.9_GA_6191) Thread-Topic: Search catch for interoperability tests Thread-Index: pmpNfdSVZyMKTHCbqyLWpBC1sbFDzjhqJBqx Archived-At: Cc: core Subject: Re: [core] Search catch for interoperability tests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 07:47:28 -0000 Hello, Is it possible to have access to the specification of tests of London 2014 = ? My document dates back to 2012 (ETSI CTI Plugtests Guide Draft V0.0.13 (201= 2-11))=20 William Bertier ----- Mail original ----- > De: "William Bertier" > =C0: "Carsten Bormann" > Cc: "Thomas Watteyne" , "core" > Envoy=E9: Mercredi 15 Juillet 2015 09:46:01 > Objet: Re: [core] Search catch for interoperability tests >=20 > Yes indeed, the objective of my internship is to update the tests already > present and add new tests >=20 > ----- Mail original ----- > > De: "Carsten Bormann" > > =C0: "William Bertier" > > Cc: "Thomas Watteyne" , "core" > > Envoy=E9: Mercredi 15 Juillet 2015 09:29:12 > > Objet: Re: [core] Search catch for interoperability tests > >=20 > > > ETSI testing (coap.me), it was done with our team in 2012. It therefo= re > > > has the same tests. > >=20 > > Actually, the test specs have changed, and also there were some spec > > changes since 2012 that will impact trace captures. The most recent > > ETSI CoAP plugtest was in London, March 2014. So I would recommend > > testing again against coap.me (please ask me if there is any problem > > with that). By the way, coap.me can also be used to decode (and thus > > check) packet captures in pcap format. > >=20 > > Gr=FC=DFe, Carsten > >=20 >=20 From nobody Tue Jul 28 02:42:41 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6FA1A882D for ; Tue, 28 Jul 2015 02:42:39 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_bnVWpNyoJW for ; Tue, 28 Jul 2015 02:42:37 -0700 (PDT) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CFB1A87A5 for ; Tue, 28 Jul 2015 02:42:36 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.217]) by smtp-cloud3.xs4all.net with ESMTP id xliT1q0084h15BW01liTVC; Tue, 28 Jul 2015 11:42:27 +0200 Received: from [2001:983:a264:1:3948:5a3f:df60:1149] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 28 Jul 2015 11:42:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 28 Jul 2015 11:42:27 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> X-Sender: stokcons@xs4all.nl (0JU4QCuWECJD/sU8Psiq/+wVgxJOCqs8) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] Patch idempotent? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 09:42:40 -0000 Hi all, During the CoRE meeting on friday, the suggestion was done that an idem-potent patch in CoAP should be called iPatch and that Patch itself is not necessarily idempotent. I can identify 2 reasons why patch should not be idempotent: 1) the patch adds new sections to a resource and is not idem-potent when for example new sections are identified by invocation date and time. 2) the patch changes the content of the resource as function of the resource state e.g. incrementing its values Other possibilities, not identified by me, may exist. 3) An idempotent Patch can be restricted to replacing a subset of the variables in the resource to the same subset with possibly different values. RF6902 restricts its operations to add, remove, move, copy, replace. The way the operations add, remove, replace are specified in 6902 implies their idem-potency; copy and move are not because dependent on the resource state. RFC7396 supports only the operations add, remove and replace, and is consequently an idem-potent format. My proposal is to specify Patch for CoAP to be non-idempotent conforming to the http interpretation. This being said, we can add a new method to CoAP, called "iPatch", which is idem-potent and probably fulfils what most applications want Patch to do (RFC7396 semantics). The Patch command could then also include RPC semantics like toggle, or INC(x), or actuator settings, currently excluded by an idem-potent PUT in CoAP. Looking forward to other opinions, peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From nobody Tue Jul 28 10:46:08 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF80E1B2CA7 for ; Tue, 28 Jul 2015 10:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fA7LTHi-OLAc for ; Tue, 28 Jul 2015 10:46:04 -0700 (PDT) Received: from ni.com (skprod2.natinst.com [130.164.80.23]) (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 B7C7B1A895D for ; Tue, 28 Jul 2015 10:46:04 -0700 (PDT) Received: from US-AUS-MAIL4.amer.corp.natinst.com (nb-snip2-1338.natinst.com [130.164.19.135]) by us-aus-skprod2.natinst.com (8.15.0.59/8.15.0.59) with ESMTP id t6SHjxtK020568; Tue, 28 Jul 2015 12:45:59 -0500 In-Reply-To: References: To: Andy Bierman MIME-Version: 1.0 X-KeepSent: 2491F43F:D9A2A037-86257E90:005DFAEE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP6 November 22, 2013 From: Rodney Cummings Message-ID: Date: Tue, 28 Jul 2015 12:45:59 -0500 X-MIMETrack: Serialize by Router on US-AUS-MAIL4/AUS/M/NIC(Release 8.5.3FP6 HF1218|December 12, 2014) at 07/28/2015 12:45:59 PM, Serialize complete at 07/28/2015 12:45:59 PM Content-Type: multipart/alternative; boundary="=_alternative 0061982E86257E90_=" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-07-28_09:, , signatures=0 Archived-At: Cc: Core Subject: Re: [core] Questions on CoMI rehash map X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 17:46:06 -0000 This is a multipart message in MIME format. --=_alternative 0061982E86257E90_= Content-Type: text/plain; charset="US-ASCII" Andy Bierman wrote on 07/27/2015 05:21:11 PM: > The rehash mechanism is being reworked (again), but it does not go away. > Can you explain your solution in more detail? I'd be happy to provide more detail, but I suspect that I may be misinterpreting some fundamental assumptions for the CoMI client/server interaction. I'd like to check those assumptions first (see below). > There is a resource /mg/mod.uri that indicates the URI of the YANG > library data > for the server. This is how YANG reports all the supported data nodes. Great. I wasn't sure if this covered conditional data nodes (if-feature). > On Mon, Jul 27, 2015 at 2:37 PM, Rodney Cummings > 2. Is it possible to specify the traversal algorithm that both >> client and server use to create hashes for data nodes? Andy Bierman wrote on 07/27/2015 05:21:11 PM: > No because YANG allows data to be added in the middle of a sibling-set. > YANG also supports sub-modules and the order they are parsed > could affect module order. > > One important property of the YANG Hash is that is does not > change over time. If /foo/bar is defined in version 1, > then it has to remain the same value in version 2, 3, etc. > This allows clients compiled in firmware against version 1 > to keep working. This is probably the fundamental issue. For a given version of the server's firmware, the server knows its own data node hierarchy, and therefore it can determine where rehash is needed. When the server's firmware upgrades from version 1 to version 2, it is safe for the server to assume that the client is aware of this upgrade. If the client did not perform the firmware upgrade itself, it can query the version when CoMI starts up. The question seems to be: When the server upgrades from version 1 to 2, what can the client assume regarding the hash values of data nodes supported in both version 1 and 2? You seem to be saying that the client can assume that the hash values for version 1 data nodes are not changed. In other words, the client can assume that the server orders its traversal of the hierarchy as oldest-first. My concern is that I don't see that mandated in the draft. As a client, I cannot really assume this sort of thing unless I go outside the scope of the standard (i.e. product-specific). If I don't want to make product-specific assumptions as a client, my alternative is to re-evaluate all hash values when I detect version 2. In other words, I assumed that the client performs the following steps: 1. Check to see if the server's data nodes have changed (/mg/mod.uri, server version, etc). 2. If data nodes have not changed, re-use hash values from a previous session with this server. 3. If data nodes changed, read ietf-yang-hash and re-calculate hash values for all data nodes. It sounds like my assumption is incorrect. If so, it might be helpful to clarify in the next draft. > Andy > >> Rodney Cummings > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=_alternative 0061982E86257E90_= Content-Type: text/html; charset="US-ASCII" Andy Bierman <andy@yumaworks.com> wrote on 07/27/2015 05:21:11 PM:
> The rehash mechanism is being reworked (again), but it does not go away.
> Can you explain your solution in more detail?

I'd be happy to provide more detail, but I suspect that I may be
misinterpreting some fundamental assumptions for the CoMI client/server
interaction. I'd like to check those assumptions first (see below).

> There is a resource /mg/mod.uri that indicates the URI of the YANG
> library data
> for the server. This is how YANG reports all the supported data nodes.

Great. I wasn't sure if this covered conditional data nodes (if-feature).

> On Mon, Jul 27, 2015 at 2:37 PM, Rodney Cummings <rodney.cummings@ni.com wrote:
>> 2. Is it possible to specify the traversal algorithm that both
>> client and server use to create hashes for data nodes?

Andy Bierman <andy@yumaworks.com> wrote on 07/27/2015 05:21:11 PM:
> No because YANG allows data to be added in the middle of a sibling-set.
> YANG also supports sub-modules and the order they are parsed
> could affect module order.
>
> One important property of the YANG Hash is that is does not
> change over time. If /foo/bar is defined in version 1,
> then it has to remain the same value in version 2, 3, etc.
> This allows clients compiled in firmware against version 1
> to keep working.

This is probably the fundamental issue.

For a given version of the server's firmware, the server knows its
own data node hierarchy, and therefore it can determine where rehash
is needed.

When the server's firmware upgrades from version 1 to version 2, it is
safe for the server to assume that the client is aware of this upgrade.
If the client did not perform the firmware upgrade itself,
it can query the version when CoMI starts up.

The question seems to be:
        When the server upgrades from version 1 to 2, what can the client
        assume regarding the hash values of data nodes supported in both
        version 1 and 2?

You seem to be saying that the client can assume that the hash values
for version 1 data nodes are not changed. In other words, the client can assume
that the server orders its traversal of the hierarchy as oldest-first.
My concern is that I don't see that mandated in the draft. As a client,
I cannot really assume this sort of thing unless I go outside the scope
of the standard (i.e. product-specific).

If I don't want to make product-specific assumptions as a client,
my alternative is to re-evaluate all hash values when I detect version 2.

In other words, I assumed that the client performs the following steps:
1. Check to see if the server's data nodes have changed (/mg/mod.uri, server version, etc).
2. If data nodes have not changed, re-use hash values from a previous session with this server.
3. If data nodes changed, read ietf-yang-hash and re-calculate hash values for all data nodes.

It sounds like my assumption is incorrect. If so, it might be helpful to clarify in the next draft.

> Andy
>  
>> Rodney Cummings
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
 --=_alternative 0061982E86257E90_=-- From nobody Tue Jul 28 19:19:09 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008EE1B3519 for ; Tue, 28 Jul 2015 19:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlQArejCO7nx for ; Tue, 28 Jul 2015 19:19:04 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 815261B3504 for ; Tue, 28 Jul 2015 19:19:03 -0700 (PDT) Received: by lbbqi7 with SMTP id qi7so86450542lbb.3 for ; Tue, 28 Jul 2015 19:19:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HnrOZKKxz59Y0N92Bb8hqIpQpB8kmkof8tLZUQmZs7U=; b=ZDzW65rHdkWcH9I27IoWfaJwy9XFM73thmG/MemSYV4jmggVwp5vof+kvG4zvaaRV1 ekM7FL9HNpo7g73hdmk39BALyOvRTl6C+brR2yx488ePa4D/9A2WnMerJ8v/K40T7oUQ HI+qBOFtfKMb/VhBbqDID9ryEwoXpXJVYerHu6QDPmQ+QUee9J84mcgjvPLvhQIWcI7F JlSdSpsLXpMra/ej9cWwQ0e8A/JQ4q2Cc+xfbK6BKZehhYoRY7nag3pXo/oNDol8Z3Vi 6o5YJ8yteU9NJ83ByxijDEMTEDedXpt5u67s3iSIgy/yr1DbyqYG5Mk4l3SpfJpr8+wt O+ZA== X-Gm-Message-State: ALoCoQnsDAYMMLPrZ2NpPozUbcPYrxkvfOS3hhl6Q3I2YB6TG8CnMO5H3XmSAuvfD+ZDJ/s5Cp/P MIME-Version: 1.0 X-Received: by 10.112.46.130 with SMTP id v2mr35727882lbm.119.1438136341885; Tue, 28 Jul 2015 19:19:01 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 28 Jul 2015 19:19:01 -0700 (PDT) In-Reply-To: <55B72969.4050006@ackl.io> References: <4dde82ad1cd4d261b598cb0e851cdf1c@xs4all.nl> <55B6070A.1020007@ackl.io> <55B72969.4050006@ackl.io> Date: Tue, 28 Jul 2015 19:19:01 -0700 Message-ID: From: Andy Bierman To: Alexander Pelov Content-Type: multipart/alternative; boundary=001a1134aee8cc0d0b051bfa35f2 Archived-At: Cc: Core Subject: Re: [core] YANG Packages for CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 02:19:08 -0000 --001a1134aee8cc0d0b051bfa35f2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 28, 2015 at 12:04 AM, Alexander Pelov wrote: > Hi Andy, > > Le 27/07/2015 20:01, Andy Bierman a =C3=A9crit : > > > > On Mon, Jul 27, 2015 at 3:25 AM, Alexander Pelov < > alexander@ackl.io> wrote: > >> Hi Andy! >> >> Thanks for the draft! Seems a good start to get the things moving in the >> direction of having a good, structured introspection mechanism for modul= e >> discovery! >> >> I'm not completely sure that it will be a static document. You still nee= d >> to think of the possibility of a firmware upgrade, in which case you hav= e >> to consider the clients which have obtained your previous package >> descriptions. >> >> > Each package has a name and a revision-date. > The expected use for CoMI would be a new > package revision for each firmware release. > > I meant that there should be a mechanism for the client to be notified > when the YANG package definition changes. This may be a rare event, but > imagine a new client arrives and discovers the server 1 minute before the > server gets a new firmware release (or some other event, making it change > its package definition). > I agree. There can be a YANG Package Library URI /mg/pkg.uri URI of the YANG Package Library resource to GET or Observe The package data tree could be much smaller than the module library tree. container packages { leaf pkg-set-id { type uint32; } list package { key name; leaf name { type string; } leaf rev { type yang:revision-date; } } } { "packages": { "pkg-set-id":42, "package": [ { "name":"example-sensor314", "rev":"2015-06-14" } ] } } > I would think that if a client is expected to keep long-term association > to the server, it should use Observe or NOTIFY. The latter will work if t= he > package is defined as module. > > > > >> Why don't you want it to be a YANG module? I would suppose that for a >> structured numbering scheme (such as CoOL) we could have a nice fixed en= try >> point for such introspection resource, e.g. moduleID =3D 1. Alternativel= y, I >> would think that it should be discoverable through .well-known/core >> >> > Not sure what you mean. > This is static data used to identify a set of YANG modules. > Do you mean why not have the contents of a package be YANG objects > to read from the server? This would be even more data than the > current YANG module library. > > The point of a package list is to avoid listing all the modules, > features, > and revision dates. There is a YANG Package Identifier in sec. 4 > > urn:ietf:params:xml:ns:yang:pkg?name=3Dexample-sensor314&rev=3D2015-07= -01 > > > This would be the entire response needed to discover the entire YANG > implementation by the server. The size remains the same no matter how man= y > modules and features are added over time. > > > Ah, OK! Now I understand! It was not obvious to me that you were aiming a= t > having the package definition be detached from the server. I like that! > This, however makes me think about something else - you should have a way > to obtain the package from the sensor. However, this goes a little bit in > the sense of having YANG packages being mandatory for CoMI. I like the > "uses-package" statement, as this could be used to have full definition o= f > the modules on a server. > > I would suppose that you could represent the information of a YANG packag= e > as a YANG module. Then, a client could query the server with a > select/fields statement to obtain only the package identifier. IF the > client wants, it could obtain the whole package content from the server: > > E.g. for a YANG module definition such as: > module yang-package { > ... > leaf yang-package-uri { > type string; > } > > container package { > leaf organization {type string;} > leaf contact {type string;} > leaf description {type string;} > leaf revision {type string;} > container imports-module { > key module-name; > leaf module-name {type string;} > leaf module-cool-id {type int32;} > } > container uses-module { > ... > } > ... > } > } > > The point of the YANG package is that it serves as an offline handle for lots of YANG details related to a set of modules. NETCONF and RESTCONF just advertise the conformance details for each module (name, revision, features, deviations). There is a operation in both protocols to allow the client to retrieve the actual YANG files. There is no YANG module that modules YANG module contents. The same approach should be used in CoMI, except I would expect a centralized server to have that data, not any constrained servers. module ID for this module would be fixed in CoOL to 1, so yang-package-uri > will have CoOL ID 2049. > > In CoOL this would be as getting : > GET /cdat?fields(2049) > > Response: > { > > 2049:"urn:ietf:params:xml:ns:yang:pkg?name=3Dexample-sensor314&rev=3D2015= -07-01" > } > > Maybe this could be even more optimized. > I don't know if package numbers are really needed. The entire package library above would fit in 128 bytes. Andy > > Now, if the client has no idea how to find this URN, it would simply GET > /cdat?fields(2048) and retrieve the YANG package information from the > server. > > > > > > >> A point to make is that we can have alias mappings through this >> introspection mechanism. Defining such an introspection mechanism for th= e >> aliases was actually one of the work I was considering for CoOL. >> >> > RESTCONF and NETCONF provide the ability for the client to retrieve > the schema, and get all the meta-data, for every module. > IMO this should be done by a centralized server in CoMI. > > But I agree the package data could include alias mappings. > This might be a way to convert YANG Hash to COOL for example, > to optimize frequently used identifiers.. > > > Maybe this should also be the way to handle alias attribution, e.g. add a > "alias" statement, which indicates the mapping alias-id -> CoOL id / CoMI > hash / full identifier. > > module yang-package { > .... > container alias { > key cool-id; > leaf cool-id {type int32}; > leaf alias-id {type int32}; > } > } > > So you can GET /cdat?fields(2058) and have > { > 2058: [ > {11: 29834394, 12:1}, > {11: 99999999, 12:2} > {11: 88888384, 12:3} > ] > } > > assuming the following CoOL id automatic attribution: > alias -> node ID=3D10 > cool-id -> node Id=3D11 > alias-id -> node ID=3D12 > and some random IDs to be mapped (29834394, 99999999, 88888384). > > Ideally, of course, you would be fetching this information from a server > somewhere on the Internet, so that you don't fetch from your constrained > server. > > Best, > Alexander > > > > > > >> Best, >> Alexander >> > > Andy > > >> >> Le 27/07/2015 08:29, Andy Bierman a =C3=A9crit : >> >> >> >> On Sun, Jul 26, 2015 at 11:26 PM, peter van der Stok < >> stokcons@xs4all.nl> wrote: >> >>> HI Andy, >>> >>> Is the proposal to make YANG packages compulsory over yang-library in >>> Comi servers and clients? >>> >>> >> No, it would be optional. >> Another solution approach would be to make the module-set-id values >> global instead of per-server. That might be less work perhaps. >> >> >> Peter >>> >> >> Andy >> >> >>> >>> Andy Bierman schreef op 2015-07-26 19:44: >>> >>>> Hi, >>>> >>>> Michel raised some issues with the YANG library draft >>>> http://datatracker.ietf.org/doc/draft-ietf-netconf-yang-library/ >>>> >>>> Maybe CoMI needs its own optimized module library. >>>> I am concerned that data sizes of the YANG library will be >>>> too big in some really constrained environments. >>>> >>>> I wrote a draft that defines a way to specify the contents of the >>>> YANG library in a single static document, called a YANG package. >>>> http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ >>>> >>>> If there was a "shorthand" resource that listed YANG packages, instead >>>> of YANG modules, then the CoMI client that supported YANG packages >>>> could read that instead of the module library. >>>> >>>> The YANG package message response can identify a single package >>>> (e.g. match the firmware) so the size of the response will remain very >>>> small, and not depend on the entire list of modules, features, >>>> and deviations. The data savings could 1000X for 100 modules. >>>> >>>> The client needs to retrieve the library first-time and anytime it >>>> changes. >>>> The module-set-id values are per-server, not global. This could be a >>>> significant bottleneck when a CoMI client starts or restarts, and >>>> manages lots of servers. >>>> >>>> Andy >>>> >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>> >> >> >> _______________________________________________ >> core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core >> >> >> > > --001a1134aee8cc0d0b051bfa35f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 28, 2015 at 12:04 AM, Alexander Pelov <= ;a@ackl.io> wr= ote:
=20 =20 =20
Hi Andy,

Le 27/07/2015 20:01, Andy Bierman a =C3=A9crit=C2=A0:


On Mon, Jul 27, 2015 at 3:25 AM, Alexander Pelov <alexander@ackl.io> wrote:
Hi Andy!

Thanks for the draft! Seems a good start to get the things moving in the direction of having a good, structured introspection mechanism for module discovery!

I'm not completely sure that it will be a static document. You still need to think of the possibility of a firmware upgrade, in which case you have to consider the clients which have obtained your previous package descriptions.


Each package has a name and a revision-date.
The expected use for CoMI would be a new
package revision for each firmware release.
I meant that there should be a mechanism for the client to be notified when the YANG package definition changes. This may be a rare event, but imagine a new client arrives and discovers the server 1 minute before the server gets a new firmware release (or some other event, making it change its package definition).
<= /blockquote>


I agree.
There can= be a YANG Package Library URI

=C2=A0 /mg/pkg.uri<= /div>

URI of the YANG Package Library resource to GET or= Observe

The package data tree could be much small= er than the module library tree.

=C2=A0 container = packages {
=C2=A0 =C2=A0 =C2=A0leaf pkg-set-id { type uint32; }
=C2=A0 =C2=A0 =C2=A0list package {
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 key name;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf name { type str= ing; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf rev { type yang:revision-= date; }
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}
=

=C2=A0 { "packages": {
= =C2=A0 =C2=A0 =C2=A0"pkg-set-id":42,
=C2=A0 =C2=A0 =C2= =A0"package": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0{
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name":"example-sensor314= ",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "rev":"= 2015-06-14"
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 = =C2=A0 =C2=A0]
=C2=A0 =C2=A0}
=C2=A0}



I would think that if a client is expected to keep long-term association to the server, it should use Observe or NOTIFY. The latter will work if the package is defined as module.


=C2=A0
Why don't you = want it to be a YANG module? I would suppose that for a structured numbering scheme (such as CoOL) we could have a nice fixed entry point for such introspection resource, e.g. moduleID =3D 1. Alternatively, I would think that it should be discoverable through .well-known/core


Not sure what you mean.
This is static data used to identify a set of YANG modules.
Do you mean why not have the contents of a package be YANG objects
to read from the server?=C2=A0 This would be even more dat= a than the
current YANG module library.

The point of a package list is to avoid listing all the modules, features,
and revision dates.=C2=A0 There is a YANG Package Identifi= er in sec. 4

  urn:ietf:params:xml:ns:yang:pkg?name=3Dexample-sensor314&=
;rev=3D2015-07-01

This would be the entire response needed to discover the entire YANG
implementation by the server. The size remains the same no matter how many
modules and features are added over time.

Ah, OK! Now I understand! It was not obvious to me that you were aiming at having the package definition be detached from the server. I like that! This, however makes me think about something else - you should have a way to obtain the package from the sensor. However, this goes a little bit in the sense of having YANG packages being mandatory for CoMI. I like the =20 "uses-package" statement, as this could be used to have full definition of the modules on a server.

I would suppose that you could represent the information of a YANG package as a YANG module. Then, a client could query the server with a select/fields statement to obtain only the package identifier. IF the client wants, it could obtain the whole package content from the server:

E.g. for a YANG module definition such as:
module yang-package {
=C2=A0 ...
=C2=A0 leaf yang-package-uri {
=C2=A0=C2=A0=C2=A0 type string;
=C2=A0 }

=C2=A0 container package {
=C2=A0=C2=A0=C2=A0 leaf organization {type string;}
=C2=A0=C2=A0=C2=A0 leaf contact {type string;}
=C2=A0=C2=A0=C2=A0 leaf description {type string;}
=C2=A0=C2=A0=C2=A0 leaf revision {type string;}
=C2=A0=C2=A0=C2=A0 container imports-module {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key module-name;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf module-name {type string;} =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf module-cool-id {type int32;}<= br> =C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 container uses-module {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...
=C2=A0=C2=A0=C2=A0 }
=20 =C2=A0=C2=A0=C2=A0 ...
=C2=A0 }
}



The point of = the YANG package is that it serves as an offline handle
for lots = of YANG details related to a set of modules.

NETCO= NF and RESTCONF just advertise the conformance details
for each m= odule (name, revision, features, deviations). There is
a <get-= schema> operation in both protocols to allow the client to retrieve
the actual YANG files.=C2=A0 There is no YANG module that modules
YANG module contents.

The same approach <= ;get-pkg-schema> should be used in CoMI,
except I would ex= pect a centralized server to have that data,
not any constrained = servers.




<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
module ID for this module would be fixed in CoOL to 1, so yang-package-uri will have CoOL ID 2049.

In CoOL this would be as getting :
GET /cdat?fields(2049)

Response:
{
2049:"urn:ietf:params:xml:ns:yang:pkg?name=3Dexample-sensor314&rev= =3D2015-07-01"
}


Maybe this could be even more optimized.

I don't know if pac= kage numbers are really needed.
The entire package library above = would fit in 128 bytes.



<= div>Andy

=C2=A0

Now, if the client has no idea how to find this URN, it would simply=C2=A0 GET /cdat?fields(2048) and retrieve the YANG package information from the server.




=C2=A0
A point to make is that we can have alias mappings through this introspection mechanism. Defining such an introspection mechanism for the aliases was actually one of the work I was considering for CoOL.


RESTCONF and NETCONF provide the ability for the client to retrieve
the schema, and get all the meta-data, for every module.
IMO this should be done by a centralized server in CoMI.

But I agree the package data could include alias mappings.
This might be a way to convert YANG Hash to COOL for example,
to optimize frequently used identifiers..

Maybe this should also be the way to handle alias attribution, e.g. add a "alias" statement, which indicates the mapping alias-id= -> CoOL id / CoMI hash / full identifier.

module yang-package {
....
=C2=A0 container alias {
=C2=A0=C2=A0=C2=A0 key cool-id;
=C2=A0=C2=A0=C2=A0 leaf cool-id {type int32};
=C2=A0=C2=A0=C2=A0 leaf alias-id {type int32};
=C2=A0 }
}

So you can GET /cdat?fields(2058) and have
{
=C2=A0 2058: [
=C2=A0=C2=A0=C2=A0 {11: 29834394, 12:1},
=C2=A0 =C2=A0 {11: 99999999, 12:2}
=C2=A0 =C2=A0 {11: 88888384, 12:3}
=C2=A0 ]
}

assuming the following CoOL id automatic attribution:
alias -> node ID=3D10
cool-id -> node Id=3D11
alias-id -> node ID=3D12
and some random IDs to be mapped (29834394, 99999999, 88888384).

Ideally, of course, you would be fetching this information from a server somewhere on the Internet, so that you don't fetch from your constrained server.

Best,
Alexander




=C2=A0
Best,
Alexander

Andy
=C2=A0

Le 27/07/2015 08:29, Andy Bierman a =C3=A9crit=C2=A0:<= br>


On Sun, Jul 26, 2015 at 11:26 PM, peter van der Stok <= stokcons@xs4all.nl> wrote:
HI Andy,

Is the proposal to make YANG packages compulsory over yang-library in Comi servers and clients?


No, it would be optional.
Another solution approach would be to make the module-set-id values
global instead of per-server. That might be less work perhaps.


Peter

Andy
=C2=A0

Andy Bierman schreef op 2015-07-26 19:44:
Hi,

Michel raised some issues with the YANG library draft
http://d= atatracker.ietf.org/doc/draft-ietf-netconf-yang-library/

Maybe CoMI needs its own optimized module library.
I am concerned that data sizes of the YANG library will be
too big in some really constrained environments.

I wrote a draft that defines a way to specify the contents of the
YANG library in a single static document, called a YANG package.
http:/= /datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/

If there was a "shorthand" resource t= hat listed YANG packages, instead
of YANG modules, then the CoMI client that supported YANG packages
could read that instead of the module library.

The YANG package message response can identify a single package
(e.g. match the firmware) so the size of the response will remain very
small, and not depend on the entire list of modules, features,
and deviations. The data savings could 1000X for 100 modules.

The client needs to retrieve the library first-time and anytime it
changes.
The module-set-id values are per-server, not global. This could be a
significant bottleneck when a CoMI client starts or restarts, and
manages lots of servers.

Andy


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



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




--001a1134aee8cc0d0b051bfa35f2-- From nobody Wed Jul 29 01:33:35 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156981A879D for ; Wed, 29 Jul 2015 01:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6jt2rpYKxUX for ; Wed, 29 Jul 2015 01:33:29 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486421A873D for ; Wed, 29 Jul 2015 01:33:28 -0700 (PDT) Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 7638541C07A; Wed, 29 Jul 2015 10:33:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter16-d.gandi.net (mfilter16-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id J_7Bju_kUf2E; Wed, 29 Jul 2015 10:33:23 +0200 (CEST) X-Originating-IP: 178.251.23.166 Received: from Zax.local (unknown [178.251.23.166]) (Authenticated sender: alex@ackl.io) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 375DE41C076; Wed, 29 Jul 2015 10:33:14 +0200 (CEST) To: Andy Bierman References: <4dde82ad1cd4d261b598cb0e851cdf1c@xs4all.nl> <55B6070A.1020007@ackl.io> <55B72969.4050006@ackl.io> From: Alexander Pelov Message-ID: <55B88FC9.7070107@ackl.io> Date: Wed, 29 Jul 2015 10:33:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060605030801090703000306" Archived-At: Cc: Core Subject: Re: [core] YANG Packages for CoMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 08:33:34 -0000 This is a multi-part message in MIME format. --------------060605030801090703000306 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Andy, Le 29/07/2015 04:19, Andy Bierman a =C3=A9crit : > > > On Tue, Jul 28, 2015 at 12:04 AM, Alexander Pelov > wrote: > > Hi Andy, > > Le 27/07/2015 20:01, Andy Bierman a =C3=A9crit : >> >> >> On Mon, Jul 27, 2015 at 3:25 AM, Alexander Pelov >> > wrote: >> >> Hi Andy! >> >> Thanks for the draft! Seems a good start to get the things >> moving in the direction of having a good, structured >> introspection mechanism for module discovery! >> >> I'm not completely sure that it will be a static document. >> You still need to think of the possibility of a firmware >> upgrade, in which case you have to consider the clients which >> have obtained your previous package descriptions. >> >> >> Each package has a name and a revision-date. >> The expected use for CoMI would be a new >> package revision for each firmware release. > I meant that there should be a mechanism for the client to be > notified when the YANG package definition changes. This may be a > rare event, but imagine a new client arrives and discovers the > server 1 minute before the server gets a new firmware release (or > some other event, making it change its package definition). > > > > I agree. > There can be a YANG Package Library URI > > /mg/pkg.uri > > URI of the YANG Package Library resource to GET or Observe > > The package data tree could be much smaller than the module library tre= e. > > container packages { > leaf pkg-set-id { type uint32; } > list package { > key name; > leaf name { type string; } > leaf rev { type yang:revision-date; } > } > } > > > { "packages": { > "pkg-set-id":42, > "package": [ > { > "name":"example-sensor314", > "rev":"2015-06-14" > } > ] > } > } > I suppose in a YANG hash world you need to multiply the file locations=20 so that you can have this information in a convenient place. In a=20 numbering scheme with managed IDs you can allocate predefined module IDs=20 for the important modules. This one seems to be of great importance! Do you think that we could re-use the RFC 6022 - YANG module for NETCONF=20 monitoring? It seems to me that it does exactly what the YANG package=20 you are proposing. In both cases (packages or RFC 6022) if we have the introspection=20 information exposed as YANG module, we don't need to invent additional=20 mechanisms. By performing a select/fields filtering, a client can obtain=20 in a lightweight fashion the information that concerns it. If the client=20 wants, it could obtain the full schema information, but that is not=20 necessary. > > > I would think that if a client is expected to keep long-term > association to the server, it should use Observe or NOTIFY. The > latter will work if the package is defined as module. > >> >> Why don't you want it to be a YANG module? I would suppose >> that for a structured numbering scheme (such as CoOL) we >> could have a nice fixed entry point for such introspection >> resource, e.g. moduleID =3D 1. Alternatively, I would think >> that it should be discoverable through .well-known/core >> >> >> Not sure what you mean. >> This is static data used to identify a set of YANG modules. >> Do you mean why not have the contents of a package be YANG objects >> to read from the server? This would be even more data than the >> current YANG module library. >> >> The point of a package list is to avoid listing all the modules, >> features, >> and revision dates. There is a YANG Package Identifier in sec. 4 >> >> urn:ietf:params:xml:ns:yang:pkg?name=3Dexample-sensor314&rev=3D= 2015-07-01 >> >> This would be the entire response needed to discover the entire YA= NG >> implementation by the server. The size remains the same no matter >> how many >> modules and features are added over time. > > Ah, OK! Now I understand! It was not obvious to me that you were > aiming at having the package definition be detached from the > server. I like that! This, however makes me think about something > else - you should have a way to obtain the package from the > sensor. However, this goes a little bit in the sense of having > YANG packages being mandatory for CoMI. I like the "uses-package" > statement, as this could be used to have full definition of the > modules on a server. > > I would suppose that you could represent the information of a YANG > package as a YANG module. Then, a client could query the server > with a select/fields statement to obtain only the package > identifier. IF the client wants, it could obtain the whole package > content from the server: > > E.g. for a YANG module definition such as: > module yang-package { > ... > leaf yang-package-uri { > type string; > } > > container package { > leaf organization {type string;} > leaf contact {type string;} > leaf description {type string;} > leaf revision {type string;} > container imports-module { > key module-name; > leaf module-name {type string;} > leaf module-cool-id {type int32;} > } > container uses-module { > ... > } > ... > } > } > > > > The point of the YANG package is that it serves as an offline handle > for lots of YANG details related to a set of modules. > > NETCONF and RESTCONF just advertise the conformance details > for each module (name, revision, features, deviations). There is > a operation in both protocols to allow the client to retri= eve > the actual YANG files. There is no YANG module that modules > YANG module contents. > > The same approach should be used in CoMI, > except I would expect a centralized server to have that data, > not any constrained servers. I don't understand the need of modeling the YANG module contents. Once=20 you have the conformance details (name, revision, features, deviations),=20 you can try and fetch them from an remote store (or have them locally).=20 If you don't have access to this information, you need to fetch their=20 schema. Do you see an intermediate level of details? For me, the introspection mechanism should be implemented as a YANG=20 module. There is no need to invent new mechanisms, when we have an=20 existing one. I would imagine that you could declare the YANG hash of=20 this module in the .well-known/core if you want to be flexible. Best, Alexander > > > > > module ID for this module would be fixed in CoOL to 1, so > yang-package-uri will have CoOL ID 2049. > > In CoOL this would be as getting : > GET /cdat?fields(2049) > > Response: > { > 2049:"urn:ietf:params:xml:ns:yang:pkg?name=3Dexample-sensor314&rev=3D= 2015-07-01" > } > > > Maybe this could be even more optimized. > > > > I don't know if package numbers are really needed. > The entire package library above would fit in 128 bytes. > > > > Andy > > > Now, if the client has no idea how to find this URN, it would > simply GET /cdat?fields(2048) and retrieve the YANG package > information from the server. > >> >> >> >> >> A point to make is that we can have alias mappings through >> this introspection mechanism. Defining such an introspection >> mechanism for the aliases was actually one of the work I was >> considering for CoOL. >> >> >> RESTCONF and NETCONF provide the ability for the client to retriev= e >> the schema, and get all the meta-data, for every module. >> IMO this should be done by a centralized server in CoMI. >> >> But I agree the package data could include alias mappings. >> This might be a way to convert YANG Hash to COOL for example, >> to optimize frequently used identifiers.. > > Maybe this should also be the way to handle alias attribution, > e.g. add a "alias" statement, which indicates the mapping alias-id > -> CoOL id / CoMI hash / full identifier. > > module yang-package { > .... > container alias { > key cool-id; > leaf cool-id {type int32}; > leaf alias-id {type int32}; > } > } > > So you can GET /cdat?fields(2058) and have > { > 2058: [ > {11: 29834394, 12:1}, > {11: 99999999, 12:2} > {11: 88888384, 12:3} > ] > } > > assuming the following CoOL id automatic attribution: > alias -> node ID=3D10 > cool-id -> node Id=3D11 > alias-id -> node ID=3D12 > and some random IDs to be mapped (29834394, 99999999, 88888384). > > Ideally, of course, you would be fetching this information from a > server somewhere on the Internet, so that you don't fetch from > your constrained server. > > Best, > Alexander > >> >> >> >> >> Best, >> Alexander >> >> >> Andy >> >> >> Le 27/07/2015 08:29, Andy Bierman a =C3=A9crit : >>> >>> >>> On Sun, Jul 26, 2015 at 11:26 PM, peter van der Stok >>> > wrote: >>> >>> HI Andy, >>> >>> Is the proposal to make YANG packages compulsory over >>> yang-library in Comi servers and clients? >>> >>> >>> No, it would be optional. >>> Another solution approach would be to make the module-set-id >>> values >>> global instead of per-server. That might be less work perhaps= . >>> >>> >>> Peter >>> >>> >>> Andy >>> >>> >>> Andy Bierman schreef op 2015-07-26 19:44: >>> >>> Hi, >>> >>> Michel raised some issues with the YANG library draft >>> http://datatracker.ietf.org/doc/draft-ietf-netconf-ya= ng-library/ >>> >>> Maybe CoMI needs its own optimized module library. >>> I am concerned that data sizes of the YANG library >>> will be >>> too big in some really constrained environments. >>> >>> I wrote a draft that defines a way to specify the >>> contents of the >>> YANG library in a single static document, called a >>> YANG package. >>> http://datatracker.ietf.org/doc/draft-bierman-netmod-= yang-package/ >>> >>> If there was a "shorthand" resource that listed YANG >>> packages, instead >>> of YANG modules, then the CoMI client that supported >>> YANG packages >>> could read that instead of the module library. >>> >>> The YANG package message response can identify a >>> single package >>> (e.g. match the firmware) so the size of the >>> response will remain very >>> small, and not depend on the entire list of modules, >>> features, >>> and deviations. The data savings could 1000X for 100 >>> modules. >>> >>> The client needs to retrieve the library first-time >>> and anytime it >>> changes. >>> The module-set-id values are per-server, not global. >>> This could be a >>> significant bottleneck when a CoMI client starts or >>> restarts, and >>> manages lots of servers. >>> >>> Andy >>> >>> >>> _______________________________________________ >>> 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 >> >> > > --------------060605030801090703000306 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Andy,

Le 29/07/2015 04:19, Andy Bierman a =C3=A9crit=C2=A0:


On Tue, Jul 28, 2015 at 12:04 AM, Alexander Pelov <a@ackl.io> wrote:
Hi Andy,

Le 27/07/2015 20:01, Andy Bierman a =C3=A9crit=C2=A0= :


On Mon, Jul 27, 2015 at 3:25 AM, Alexander Pelov <alexander@ackl.io>= ; wrote:
Hi Andy!

Thanks for the draft! Seems a good start to get the things moving in the direction of having a good, structured introspection mechanism for module discovery!

I'm not completely sure that it will be a static document. You still need to think of the possibility of a firmware upgrade, in which case you have to consider the clients which have obtained your previous package descriptions.


Each package has a name and a revision-date.
The expected use for CoMI would be a new
package revision for each firmware release.<= /div>
I meant that there should be a mechanism for the client to be notified when the YANG package definition changes. This may be a rare event, but imagine a new client arrives and discovers the server 1 minute before the server gets a new firmware release (or some other event, making it change its package definition).


I agree.
There can be a YANG Package Library URI

=C2=A0 /mg/pkg.uri

URI of the YANG Package Library resource to GET or Observe

The package data tree could be much smaller than the module library tree.

=C2=A0 container packages {
=C2=A0 =C2=A0 =C2=A0leaf pkg-set-id { type uint32; }
=C2=A0 =C2=A0 =C2=A0list package {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 key name;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf name { type string; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf rev { type yang:revisio= n-date; }
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}


=C2=A0 { "packages": {
=C2=A0 =C2=A0 =C2=A0"pkg-set-id":42,
=C2=A0 =C2=A0 =C2=A0"package": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name":"example-senso= r314",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "rev":"2015-06-14"
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0}
=C2=A0}


I suppose in a YANG hash world you need to multiply the file locations so that you can have this information in a convenient place. In a numbering scheme with managed IDs you can allocate predefined module IDs for the important modules. This one seems to be of great importance!

Do you think that we could re-use the RFC 6022 - YANG module for NETCONF monitoring? It seems to me that it does exactly what the YANG package you are proposing.

In both cases (packages or RFC 6022) if we have the introspection information exposed as YANG module, we don't need to invent additional mechanisms. By performing a select/fields filtering, a client can obtain in a lightweight fashion the information that concerns it. If the client wants, it could obtain the full schema information, but that is not necessary.



I would think that if a client is expected to keep long-term association to the server, it should use Observe or NOTIFY. The latter will work if the package is defined as module.


=C2=A0
Why don't you want it to be a YANG module? I would suppose that for a structured numbering scheme (such as CoOL) we could have a nice fixed entry point for such introspection resource, e.g. moduleID =3D 1. Alternatively, I would think that it should be discoverable through .well-known/core


Not sure what you mean.
This is static data used to identify a set of YANG modules.
Do you mean why not have the contents of a package be YANG objects
to read from the server?=C2=A0 This would be even more data than the
current YANG module library.

The point of a package list is to avoid listing all the modules, features,
and revision dates.=C2=A0 There is a YANG Package Identifier in sec. 4

  urn:ietf:params:xml:ns:yang:pkg?name=3Dexamp=
le-sensor314&rev=3D2015-07-01

This would be the entire response needed to discover the entire YANG
implementation by the server. The size remains the same no matter how many
modules and features are added over time.

Ah, OK! Now I understand! It was not obvious to me that you were aiming at having the package definition be detached from the server. I like that! This, however makes me think about something else - you should have a way to obtain the package from the sensor. However, this goes a little bit in the sense of having YANG packages being mandatory for CoMI. I like the "uses-package" statement, as this could be used to have full definition of the modules on a server.

I would suppose that you could represent the information of a YANG package as a YANG module. Then, a client could query the server with a select/fields statement to obtain only the package identifier. IF the client wants, it could obtain the whole package content from the server:

E.g. for a YANG module definition such as:
module yang-package {
=C2=A0 ...
=C2=A0 leaf yang-package-uri {
=C2=A0=C2=A0=C2=A0 type string;
=C2=A0 }

=C2=A0 container package {
=C2=A0=C2=A0=C2=A0 leaf organization {type string;}
=C2=A0=C2=A0=C2=A0 leaf contact {type string;}
=C2=A0=C2=A0=C2=A0 leaf description {type string;}
=C2=A0=C2=A0=C2=A0 leaf revision {type string;}
=C2=A0=C2=A0=C2=A0 container imports-module {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key module-name;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf module-name {ty= pe string;}
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf module-cool-id = {type int32;}
=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 container uses-module {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...
=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 ...
=C2=A0 }
}



The point of the YANG package is that it serves as an offline handle
for lots of YANG details related to a set of modules.

NETCONF and RESTCONF just advertise the conformance details
for each module (name, revision, features, deviations). There is
a <get-schema> operation in both protocols to allow the client to retrieve
the actual YANG files.=C2=A0 There is no YANG module tha= t modules
YANG module contents.

The same approach <get-pkg-schema> should be used in CoMI,
except I would expect a centralized server to have that data,
not any constrained servers.

I don't understand the need of modeling the YANG module contents. Once you have the conformance details (name, revision, features, deviations), you can try and fetch them from an remote store (or have them locally). If you don't have access to this information, you need to fetch their schema. Do you see an intermediate level of details?

For me, the introspection mechanism should be implemented as a YANG module. There is no need to invent new mechanisms, when we have an existing one. I would imagine that you could declare the YANG hash of this module in the .well-known/core if you want to be flexible.
Best,
Alexander





module ID for th= is module would be fixed in CoOL to 1, so yang-package-uri will have CoOL ID 2049.

In CoOL this would be as getting :
GET /cdat?fields(2049)

Response:
{
2049:"urn:ietf:params:xml:ns:yang:pkg?name=3Dexample-sensor314&rev=3D= 2015-07-01"
}


Maybe this could= be even more optimized.


I don't know if package numbers are really needed.
The entire package library above would fit in 128 bytes.



Andy

=C2=A0

Now, if the client has no idea how to find this URN, it would simply=C2=A0 GET /cdat?fields(2048) and retrieve th= e YANG package information from the server.




=C2=A0
A po= int to make is that we can have alias mappings through this introspection mechanism. Defining such an introspection mechanism for the aliases was actually one of the work I was considering for CoOL.


RESTCONF and NETCONF provide the ability for the client to retrieve
the schema, and get all the meta-data, for every module.
IMO this should be done by a centralized server in CoMI.

But I agree the package data could include alias mappings.
This might be a way to convert YANG Hash to COOL for example,
to optimize frequently used identifiers..

Maybe this should also be the way to handle alias attribution, e.g. add a "alias" statement, which indicates the mapping alias-id -> CoOL id / CoMI hash / full identifier.

module yang-package {
....
=C2=A0 container alias {
=C2=A0=C2=A0=C2=A0 key cool-id;
=C2=A0=C2=A0=C2=A0 leaf cool-id {type int32};
=C2=A0=C2=A0=C2=A0 leaf alias-id {type int32};
=C2=A0 }
}

So you can GET /cdat?fields(2058) and have
{
=C2=A0 2058: [
=C2=A0=C2=A0=C2=A0 {11: 29834394, 12:1},
=C2=A0 =C2=A0 {11: 99999999, 12:2}
=C2=A0 =C2=A0 {11: 88888384, 12:3}
=C2=A0 ]
}

assuming the following CoOL id automatic attribution:
alias -> node ID=3D10
cool-id -> node Id=3D11
alias-id -> node ID=3D12
and some random IDs to be mapped (29834394, 99999999, 88888384).

Ideally, of course, you would be fetching this information from a server somewhere on the Internet, so that you don't fetch from your constrained server.

Best,
Alexander




=C2=A0
Best= ,
Alexander

Andy
=C2=A0

Le 27/07/2015 08:29, Andy Bierman a =C3=A9crit=C2=A0:


On Sun, Jul 26, 2015 at 11:26 PM, peter van der Stok <stokcons@xs4all= .nl> wrote:
HI Andy,
Is the proposal to make YANG packages compulsory over yang-library in Comi servers and clients?


No, it would be optional.
Another solution approach would be to make the module-set-id values
global instead of per-server. That might be less work perhaps.


Peter

Andy
=C2=A0

Andy Bierman schreef op 2015-07-26 19:44:
Hi,

Michel raised some issues with the YANG library draft
http://datatr= acker.ietf.org/doc/draft-ietf-netconf-yang-library/

Maybe CoMI needs its own optimized module library.
I am concerned that data sizes of the YANG library will be
too big in some really constrained environments.

I wrote a draft that defines a way to specify the contents of the
YANG library in a single static document, called a YANG package.<= br> http://datatr= acker.ietf.org/doc/draft-bierman-netmod-yang-package/

If there was a "shorthand" resource that listed YANG packages, instead
of YANG modules, then the CoMI client that supported YANG packages
could read that instead of the module library.

The YANG package message response can identify a single package
(e.g. match the firmware) so the size of the response will remain very
small, and not depend on the entire list of modules, features,
and deviations. The data savings could 1000X for 100 modules.

The client needs to retrieve the library first-time and anytime it
changes.
The module-set-id values are per-server, not global. This could be a
significant bottleneck when a CoMI client starts or restarts, and
manages lots of servers.

Andy


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



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





--------------060605030801090703000306-- From nobody Wed Jul 29 01:36:41 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E59B1B34C4 for ; Wed, 29 Jul 2015 01:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35] autolearn=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 aRrHILt7Tnl4 for ; Wed, 29 Jul 2015 01:36:38 -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 A35511B34AA for ; Wed, 29 Jul 2015 01:36:37 -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 t6T8aXDI005564; Wed, 29 Jul 2015 10:36:33 +0200 (CEST) Received: from alma.local (p5DC7F6B9.dip0.t-ipconnect.de [93.199.246.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mh7Wj3k30zDGnd; Wed, 29 Jul 2015 10:36:33 +0200 (CEST) Message-ID: <55B8908F.8020808@tzi.org> Date: Wed, 29 Jul 2015 10:36:31 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: consultancy@vanderstok.org References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> In-Reply-To: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Core Subject: Re: [core] Patch idempotent? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 08:36:39 -0000 Hi Peter, I also believe that, if we are going down the idempotent alley, we'll need to distinguish PATCH (not necessarily idempotent, like HTTP PATCH) from iPATCH (idempotent, something new). Whether, in the end, we want to add both to CoAP: I don't have an opinion on that yet. A few more data points: RFC 6902 "add" is not necessarily idempotent. See http://tools.ietf.org/html/rfc6902#appendix-A.2 for an illustration. (Doing the patch again leads to { "foo": [ "bar", "qux", "qux", "baz" ] }) Similar with "remove": http://tools.ietf.org/html/rfc6902#appendix-A.4 In contrast, RFC 7396 operations always appear to be idempotent, but then, there are no array operations in RFC 7396 at all. Positional array operations are harder to get idempotent because positions change because of the operation. Getting idempotency for array operations would require some content searching (i.e., if "the item" is already there, don't add it again; if it is already gone, don't remove another one in its place -- this requires a way to express what is meant by "the item"). Grüße, Carsten From nobody Wed Jul 29 01:49:43 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752181A898C for ; Wed, 29 Jul 2015 01:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 873_7J8ojOpV for ; Wed, 29 Jul 2015 01:49:41 -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 745A01A8989 for ; Wed, 29 Jul 2015 01:49:41 -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 t6T8ncTv005097; Wed, 29 Jul 2015 10:49:38 +0200 (CEST) Received: from alma.local (p5DC7F6B9.dip0.t-ipconnect.de [93.199.246.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mh7pp3NPFzDH0f; Wed, 29 Jul 2015 10:49:38 +0200 (CEST) Message-ID: <55B893A1.5040807@tzi.org> Date: Wed, 29 Jul 2015 10:49:37 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: William Bertier References: <1410780645.4260510.1436536900559.JavaMail.zimbra@inria.fr> <1931277357.4267342.1436537674832.JavaMail.zimbra@inria.fr> <1220732518.4891641.1436945040727.JavaMail.zimbra@inria.fr> <55A60BC8.4030005@tzi.org> <1035260517.4900766.1436946361595.JavaMail.zimbra@inria.fr> <371832648.7815014.1438069644282.JavaMail.zimbra@inria.fr> In-Reply-To: <371832648.7815014.1438069644282.JavaMail.zimbra@inria.fr> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core Subject: Re: [core] Search catch for interoperability tests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 08:49:42 -0000 William Bertier wrote: > Hello, > > Is it possible to have access to the specification of tests of London 2014 ? Certainly! They are up at https://github.com/cabo/td-coap4/ Grüße, Carsten From nobody Wed Jul 29 02:22:52 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0072A1A0110 for ; Wed, 29 Jul 2015 02:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Plvm5jP-oNjq for ; Wed, 29 Jul 2015 02:22:47 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 01BE21A00F9 for ; Wed, 29 Jul 2015 02:22:46 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id C642A19F6B5 for ; Wed, 29 Jul 2015 17:22:43 +0800 (HKT) Received: from WeiGengyuPC (unknown [114.246.133.13]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 8F76D19F4E2; Wed, 29 Jul 2015 17:22:43 +0800 (HKT) Message-ID: From: "weigengyu" To: References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> In-Reply-To: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> Date: Wed, 29 Jul 2015 17:22:38 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: core@ietf.org Subject: Re: [core] Patch idempotent? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 09:22:50 -0000 HI Peter, It seems not to be a critical issue to be idempotent. Probably, conditional request can handle this issue. In RFC5789, "PATCH is neither safe nor idempotent as defined by [RFC2616], Section 9.1." "A PATCH request can be issued in such a way as to be idempotent, which also helps prevent bad outcomes from collisions between two PATCH requests on the same resource in a similar time frame. Collisions from multiple PATCH requests may be more dangerous than PUT collisions because some patch formats need to operate from a known base-point or else they will corrupt the resource. Clients using this kind of patch application SHOULD use a conditional request such that the request will fail if the resource has been updated since the client last accessed the resource. For example, the client can use a strong ETag [RFC2616] in an If-Match header on the PATCH request." In RFC 6902, it is not mention to be idempotent. "JavaScript Object Notation (JSON) [RFC4627] is a common format for the exchange and storage of structured data. HTTP PATCH [RFC5789] extends the Hypertext Transfer Protocol (HTTP) [RFC2616] with a method to perform partial modifications to resources." "JSON Patch is a format (identified by the media type "application/ json-patch+json") for expressing a sequence of operations to apply to a target JSON document; it is suitable for use with the HTTP PATCH method." Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: peter van der Stok Sent: Tuesday, July 28, 2015 5:42 PM To: Core Subject: [core] Patch idempotent? Hi all, During the CoRE meeting on friday, the suggestion was done that an idem-potent patch in CoAP should be called iPatch and that Patch itself is not necessarily idempotent. I can identify 2 reasons why patch should not be idempotent: 1) the patch adds new sections to a resource and is not idem-potent when for example new sections are identified by invocation date and time. 2) the patch changes the content of the resource as function of the resource state e.g. incrementing its values Other possibilities, not identified by me, may exist. 3) An idempotent Patch can be restricted to replacing a subset of the variables in the resource to the same subset with possibly different values. RF6902 restricts its operations to add, remove, move, copy, replace. The way the operations add, remove, replace are specified in 6902 implies their idem-potency; copy and move are not because dependent on the resource state. RFC7396 supports only the operations add, remove and replace, and is consequently an idem-potent format. My proposal is to specify Patch for CoAP to be non-idempotent conforming to the http interpretation. This being said, we can add a new method to CoAP, called "iPatch", which is idem-potent and probably fulfils what most applications want Patch to do (RFC7396 semantics). The Patch command could then also include RPC semantics like toggle, or INC(x), or actuator settings, currently excluded by an idem-potent PUT in CoAP. Looking forward to other opinions, peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Wed Jul 29 02:52:07 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD561A016C; Wed, 29 Jul 2015 02:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJz0_rJRC6-v; Wed, 29 Jul 2015 02:52:01 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4404D1A014B; Wed, 29 Jul 2015 02:52:00 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud2.xs4all.net with ESMTP id y9ry1q00A4K0fSy019ryx9; Wed, 29 Jul 2015 11:51:58 +0200 Received: from [2001:983:a264:1:c1be:6f72:376d:3179] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 29 Jul 2015 11:51:58 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_da384acec34e3fd491aadd2ae706c4b8" Date: Wed, 29 Jul 2015 11:51:58 +0200 From: peter van der Stok To: Core , 6tisch <6tisch@ietf.org> Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@xs4all.nl (M/GY/OOTAWxp38Cc9HQu/EXiApqHqrvN) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] hash clash probabilities X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 09:52:05 -0000 --=_da384acec34e3fd491aadd2ae706c4b8 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi all, Given the discussion about the use of bits in the URI for CoMI, it is reasonable to look at the probability that a hash clash occurs, In the attached table I set out the clash probability of the number of names in a server versus the hash size. Currently the hash size is 30 bits and is proposed to be reduced to 29. The table show that by removing a bit in the hash, the clash probability increases with a factor 2 with 5.000 names and a 30 bit hash, the clash probability in one server is 10% With 30.000 names and a 32 bit hash value the clash probability in one server is also 10% A higher probability than 10% looks unwanted to me and a probability of 1% looks adequate to keep the client re-hash table size small. To estimate the size of the hash, the number of names per server should be estimated. A hash size of 29 seems reasonable when the expected number of names per server remains smaller than 3000. Has anybody an idea about the number of names in a reduced resource server? Looking forward to your reaction, Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 --=_da384acec34e3fd491aadd2ae706c4b8 Content-Transfer-Encoding: base64 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="hash clashes.docx" Content-Disposition: attachment; filename="hash clashes.docx"; size=14661 UEsDBBQABgAIAAAAIQAXqy8sZgEAAFQFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lMtuwjAQRfeV+g+Wt1Vi6KKqKgKLPpYtUukHGHsCVv2SbV5/3zGBqKqASAU2kZKZe++ZJJ7BaG00 WUKIytmK9sseJWCFk8rOKvo1eSseKYmJW8m1s1DRDUQ6Gt7eDCYbD5Gg2saKzlPyT4xFMQfDY+k8 WKzULhie8DbMmOfim8+A3fd6D0w4m8CmImUPOhy8QM0XOpHXNT5uSMDUlDw3fTmqospk/brIFXZQ E0DHPyLuvVaCJ6yzpZV/yIodVYnKbU+cKx/vsOFIQq4cD9jpPvB1BiWBjHlI79xgF1u5IJl0YmFQ WZ62OcDp6loJaPXZzQcnIEb8TkaXbcVwZff8Rzli2miIl6dofLvjISUUXANg59yJsILp59Uofpl3 gtSYO+FTDZfHaK07IRKeWmiu/bM5tjanIrFzHJyPuAXCP8beH9msLnBgDyGp039dm4jWZ88HeRtI kAey2XYnDn8AAAD//wMAUEsDBBQABgAIAAAAIQAekRq37wAAAE4CAAALAAgCX3JlbHMvLnJlbHMg ogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAArJLBasMwDEDvg/2D0b1R2sEYo04vY9DbGNkHCFtJTBPb2GrX/v082NgCXelhR8vS05PQ enOcRnXglF3wGpZVDYq9Cdb5XsNb+7x4AJWFvKUxeNZw4gyb5vZm/cojSSnKg4tZFYrPGgaR+IiY zcAT5SpE9uWnC2kiKc/UYySzo55xVdf3mH4zoJkx1dZqSFt7B6o9Rb6GHbrOGX4KZj+xlzMtkI/C 3rJdxFTqk7gyjWop9SwabDAvJZyRYqwKGvC80ep6o7+nxYmFLAmhCYkv+3xmXBJa/ueK5hk/Nu8h WbRf4W8bnF1B8wEAAP//AwBQSwMEFAAGAAgAAAAhACU3jJAIAQAAtQMAABwACAF3b3JkL19yZWxz L2RvY3VtZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJPL TsMwEEX3SPyDNXvipECFUJ1uUKVuIXyAG08Si/ghewrk7zGtoKmoIhZZzrXm3OPFrNafpmfvGKJ2 VkCR5cDQ1k5p2wp4rTY3D8AiSatk7ywKGDDCury+Wj1jLyktxU77yBLFRgEdkX/kPNYdGhkz59Gm l8YFIymNoeVe1m+yRb7I8yUPYwaUZ0y2VQLCVt0CqwaP/2G7ptE1Prl6b9DShQr+gbsXJEqfiwkr Q4skYBRmiQj8sshiTpH4x+InmVIoZlWgocexwGGeql/OWU9pF0/th/EYFlMO93M6NM5SJXf9yOM3 mpK4m1NCm3QPJwGDSstjWGRomm8HfnZs5RcAAAD//wMAUEsDBBQABgAIAAAAIQDCopQ12AMAAC4L AAARAAAAd29yZC9kb2N1bWVudC54bWykVt9v2zgMfj9g/4Ph99R25vwymg5t2gQFukOw7p4HRZZt obYkSErS3uH+9yMlO3HXQ5c1D4Eoifz4kRQZX355bupgx7ThUszD5CIOAyaozLko5+Ff35eDaRgY S0ROainYPHxhJvxy9emPy32WS7ptmLABQAiT7RWdh5W1KosiQyvWEHPRcKqlkYW9oLKJZFFwyqK9 1Hk0jJPYSUpLyowBfwsidsSELVzzFk0qJuCykLohFra6jBqin7ZqAOiKWL7hNbcvgB2POxg5D7da ZC3E4EAITTJPqF06C32KX29y22bAeYw0q4GDFKbi6hjGR9HgsupAdu8FsWvqTm+vkvS8Gtxqsofl CHgK/dwbNbVn/j5iEp9QEYQ4WJxC4bXPjklDuDg6/lBqeslNRr8HMPwZQJXnFWel5VYd0fh5aPfi 6YCFnf0bWG2R+6GZ88g8VkRBBzY0uy+F1GRTAyMoWQBZD/BZh1cwcTYyf8FVBfsMJlb+bR7GcXIz noyWYXd0ywqyrS3eLNP4Op21lvIJZ8WjJdqCKs9BAW0EacDTj5W8IfQpjFBXd1Br/RNK+9BBVBkX NRcsyLmx3x0WSjcH6eEgIUm0Vhl7tjgu6fM8HMWj2XgKGvRlHg5H48ksjZ130CoKRu2d160dDEYT BsBmMh6CsJmHn6dJpw9jeK0DDCgJAx/OmlO71SxIWhX6526liao4XWpQWOurS5KVvZMHSZ9MW0vy gZb3jSbkoiKiZNdGQQTIB9xHv/B/rtce1C2xJNjqt33xayjlMwZoIGXqQAuks9HEDuqBMeMGUtFW K/7fanU63oIgAV+ct8k9Hmkt9xUjuely/hrFbV+x2NRcLXldoweUA52xZsOAlb7PsdcIPtYHY1vJ Z/Wf4fQ6jmfDm8FiFC8GaTy5G1zP0slgEt9N0jidJotk8S9aJ2m2NfiqSH2reFfiUydwm00/J/zT 2hHXCRibI9StjmLkg0CuRtNvkJ7IyVYzSysUC4i1PY96Fy4xx1zgzigoz2b/VeZQGbK10iXjudAN rkAweHale2np+PS819LR0VxpY1dMNgEKkGtg5ODJDuLwqp0KHguJvJyTWrw6iPyJ44+MWxF+7q7X D/29b0Y/uFA+zjOQdX9M3on8MCRdD2cKrw0QXh/GY2/4uqFcPv4NV/B3nSQz/ADbZxXI4+nnqZ+r qvxK0NhK+KpI0tTNX83LCl9zu91Ia2Vz3Nes6N3iG2c4BuMpbgspbW9bbq3b+sGYUVkbODWKUOZ1 3DGMy5XmGB6mYc3hIcA4HXdx+hCd6P9tME3th9nVfwAAAP//AwBQSwMEFAAGAAgAAAAhAH8Zk+KR CgAADEgAABUAAAB3b3JkL21lZGlhL2ltYWdlMS5lbWbMnF+IXUcdx39nszFtqBpLsK2GuonRila9 2d1sdgXN0tgm2BbXGjAPBZsYpcW0DTYmqX9gqSD4ZKkP9d+bYIv4EsiLEDCUgCB9KDSpRSWI9lE0 VNS8iM7nnvneO/d37+TM2e5JHJzOzPnO+X5/58zvO+fu8d5UZnbMhuX5KbOVajh++mNmP7/NbObe B+8zq+yWA2bPBPym5BzK6iazxWmzQwF7yWHn9260V/45ZYHA7g51JtRA95FqubJtob8l1Kkt5/+A 7OlYmftwqCtx7o7labsl8t25fPOgvzNwqN9bnupzTfdHq3u3L28aYNPLNuhvtzr+HVYf+28ok45t tjo2Fc35QJzz9iBye+xT7hiea7fGfrid9u5kztbhuQOecOtW1Q9l9X4b6m60yXGmWmkMd4bKWOWH IYDPhRvbBedaOFhj6v8bx13Jccovf/Xbfqt14bh4wMRPeSDUo6H+JM7DQ8xlTPlPVcez3a7EI5TV vZP7k8tDoR6v6nz6GxeVlHMcrMvMPjsc/PyYHbGvhf+urfRCPb3v3Bbyn+thPP/qmeqT91w9uTq7 4dRSGP9ra3Xs+MUzFfPovxFMdyDMefQvV0+CExL42XDs/dMPHmQOPGAcP/TAG9WfDl6pegFDk2OT YqEwN4epnLt8av8fX4VjXAt8Z7phhWPnNkyed/RkvbVp3bmOJo9zIhfxotV7D+d8L9TbYl9F2Dut zpm0kLuUY6H/hH3dHg8r+OWwhjP2pH0l/PeJsK6PhyNPBZx1ocJDe3Oob4v8jNM+GPNowz4zyKMN Np5Hzw7v8rrkkXLn05fGc2f1tTNVb/vVQe4cujSaO+AXLo3nDsd97nAsE0JSfpOd8/Lrp/b/NWhd TnKCIt40d7a8Np47ft5iGPs84n6nOUXgh0L9bqjvCfX5UD8eMRVhHMvly0ro7wp3mfWlpnpofCvU C5FnQzWuIYxgcxoPGxp324It2r320aC2p69FjklXOai+tLdWNf/nJ2gLa9JeDNpzA+3FYu2jkf9n E7SFNWnPB+1dYZXbap+N/P+YoC2sSXu2r91rrT09VfPvmxrXFlay3j3b3Vr7YOT/wQRtYU3au4P2 bLjztfZSo7b31SOhftu4f7Wv9kdMRRgeycUBD/e+Z6O6OX/1+apxLWEl93txcM27i+83HoIff3lt YU3aS/37PRu1F4q18RD8+MtrCyvx10K4+rbaeAh+/OW1hZX4a24N2ngIfvzltYWVrPeugb/KtfEQ /PjLawsr8deeoFm6l+f89Rmr/fXFiKkIa/LXbAt/9fmqcS1hTde8J1zz/GCt2/kLfvzltYU1ac/1 73d7bTwEP/7y2sLK9hXlWbk2HoIff3ltYWX7yp41+Qt+/OW1hZXtK3Nr8hf8+MtrCyvbV8r3U++v o6GeCPWI1f46FTEVYXBey1/186s3opvqeY/Bice8nrCyXNO+Mld8z/ER/HjMawsrybW5wWel+WJt fAQ/HvPawspyTR4r18ZH8OMxry2sLNeU5+Xa+Ah+POa1hZU9w7Te5dr4CH485rWFlTzDFlvsqTmP fcNqj30/YirCmjxWP8N6I7qpnvcYnHjM6wkre44p19p5DH485rWFlT3HtK+Va+Mj+PGY1xbW1d6C j+DHY15bWNneolxr5zH48ZjXFtbV3oKP4MdjXlvYeu8tOY89Z7XHXoiYirAmj8239BiceMzrCSu5 7qXB+4bZ4nuOj+DHY15bWEmezw/eN5Rr4yP48ZjXFtbV3oKP4MdjXltYV3sLPoIfj3ltYV3tLfgI fjzmtYWt996S89gvrPbYryOmIqzJYwstPQYnHvN6wpque6G/3vq81s5j8OMxry2sJNfmBnnezmPw 4zGvLawk14bvUcu18RH8eMxrC2vSHn2P2s5j8OMxry2s5Dk2fI/azmPw4zGvLaxkPx++R23Wznns Jas99ruIqQhr8thiS4/Bice8nrCyz+e657uK7zk+gh+PeW1hJZ/PlwZ7ajuPwY/HvLawrp7f+Ah+ POa1hXX1/MZH8OMxry2sq+c3PoIfj3ltYev9/PYeOxbqV0P9vdUe+3vEVITx3YVcHIds+M6jZ6Pa Xtd7DW685nWFtfsM0c5r8OM1ry2s3WeIdl6DH695bWFlf5+09zl+gh+veW1h7f4+aec1+PGa1xbW 7t1HuTZ+gh+veW1hZe8+3rrX3rTaa5uqca+BNXlN7z56NqrtdVOvkdNwk+9eV1jZXqN1L/caOQ0/ +e61hXXlc3IafvLdawvryufkNPzku9cW1pXPyWn4yXevLWy9fZ7L981Vne/vm5DvYE35zvvltvlO XsFNznldYe0+O7fLOfjJOa8trN1n53Jt8gp+cs5rCyvx2vA7COXa5BX85JzXFlayxw6/g7D2nNsR c27PhJwDa8o5vfvqWXnOsbZws+5eV1hXeyxrCz/r7rWFdbXHsrbws+5eW9h677Hpunfdvz32KSXz uS9U4v9EVbef9WsSsfC/7H1ZCf0FEsyurXU24eP9ck7rXZbXOm6Tv/94xB4Lf2c/FXoz/Vg2W/l3 IGkZb4p9Yiq5b9+0Ot7v2Pi1CGu6b5+y8TzJrSOaeP5Nq7n5e8TrCuPYtXRn43e25A9476nqc/ns 5XmFNfPW38dKeZ+L5/KM87zCmnh5tnreP8dz2cc8r7Bm3nr/SHlnp+pz2aM8r7Bm3npvSHmfieey /3heYc289ed5v7ffZXXekL/xnH6rORxXn98l7Ih9eLdbve+lfOqTv3cM5078rvxP4zx9r/3W5Fyu /QJtvLbL1fj3noVttfy1nwj948HvTwanH+67nW8fn7CnTTvAl8KRw2EHeHTgdflelXugCs41+/1A x5jPfpDe5y7vIXOo+r3B9dBU8b9x2BiPX7x4sd+Kk+Mfin34xck8adH/YGi3xTlpAUvje6+N/n5m IY71uwjxsDaUlE88YOTM0QT7cdKn6HcXb+X3FWnc19JWvuoaFPP11MaHlPXWTteLtU/Xi3EuNjDW RDlHeyPWhL8vKTdiTb5wA7VfuIHa/76B2vuvgw8o8gHloWTvnhQbZSXZyOhyznrHhr/Yk1OP5mLT XFpi0xi+pQ5iw4dpbIxzsWkuLbFp3FVs+DSNjXEuNs2lJTaNu4oNH6exMc7Fprm0xKZxV7Hh8zQ2 xrnYNJeW2DTuKjb2gTQ2xrnYNJeW2DTuKjae1WlsjHOxaa5+g61xV7HxuZCi2H4UxyV7r86Fj9pF bOlnEGK71mcQShpb+pm7i+dCz0ZjY5yLDYy1pNWYc7qK7YCNxsY4FxsYsdFq3GVsj9hobIxzsYER G63GXcZ22kZjY5yLDYzYaDXuMrZnbTQ2xrnYwIiNVuMuY3vRRmNjnIsNjNhoNe4ytvM2GhvjXGxg xEarcZexvW6jsTHOxQZGbLQadxnbFRuNjXEuNjBio9W4y9huqkZjY5yLDYzYaDXuMrYZFxvjXGxg xEarcZexLbrYGOdiAyM2Wo27jG3FxcY4FxtY+u/U0K5HbHo/xnvBtCgOjqtf8q4ufWeWvkvLvRO8 34b3Y6ON/rsm9xn/X2D9fo5/D+fDy2Y7I0+8ttW6Dvucsy1ycs7Ucs1HeYfV72Mp4PT/BwAA//8D AFBLAwQUAAYACAAAACEAqlIl3yMGAACLGgAAFQAAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbOxZTYsb Nxi+F/ofxNwdf834Y4k32GM7abObhOwmJUd5Rp5RrBkZSd5dEwIlORYKpWnpoYHeeihtAwn0kv6a bVPaFPIXqtF4bMmWWdpsYClZw1ofz/vq0ftKjzSey1dOEgKOEOOYph2neqniAJQGNMRp1HHuHA5L LQdwAdMQEpqijjNH3Lmy++EHl+GOiFGCgLRP+Q7sOLEQ051ymQeyGfJLdIpS2TemLIFCVllUDhk8 ln4TUq5VKo1yAnHqgBQm0u3N8RgHCBxmLp3dwvmAyH+p4FlDQNhB5hoZFgobTqrZF59znzBwBEnH keOE9PgQnQgHEMiF7Og4FfXnlHcvl5dGRGyx1eyG6m9htzAIJzVlx6LR0tB1PbfRXfpXACI2cYPm oDFoLP0pAAwCOdOci471eu1e31tgNVBetPjuN/v1qoHX/Nc38F0v+xh4BcqL7gZ+OPRXMdRAedGz xKRZ810Dr0B5sbGBb1a6fbdp4BUoJjidbKArXqPuF7NdQsaUXLPC2547bNYW8BWqrK2u3D4V29Za Au9TNpQAlVwocArEfIrGMJA4HxI8Yhjs4SiWC28KU8plc6VWGVbq8n/2cVVJRQTuIKhZ500B32jK +AAeMDwVHedj6dXRIG9e/vjm5XNw+ujF6aNfTh8/Pn30s8XqGkwj3er191/8/fRT8Nfz714/+cqO 5zr+958+++3XL+1AoQNfff3sjxfPXn3z+Z8/PLHAuwyOdPghThAHN9AxuE0TOTHLAGjE/p3FYQyx btFNIw5TmNlY0AMRG+gbc0igBddDZgTvMikTNuDV2X2D8EHMZgJbgNfjxADuU0p6lFnndD0bS4/C LI3sg7OZjrsN4ZFtbH8tv4PZVK53bHPpx8igeYvIlMMIpUiArI9OELKY3cPYiOs+DhjldCzAPQx6 EFtDcohHxmpaGV3DiczL3EZQ5tuIzf5d0KPE5r6Pjkyk3BWQ2FwiYoTxKpwJmFgZw4ToyD0oYhvJ gzkLjIBzITMdIULBIESc22xusrlB97qUF3va98k8MZFM4IkNuQcp1ZF9OvFjmEytnHEa69iP+EQu UQhuUWElQc0dktVlHmC6Nd13MTLSffbeviOV1b5Asp4Zs20JRM39OCdjiJTz8pqeJzg9U9zXZN17 t7IuhfTVt0/tunshBb3LsHVHrcv4Nty6ePuUhfjia3cfztJbSG4XC/S9dL+X7v+9dG/bz+cv2CuN Vpf44qqu3CRb7+1jTMiBmBO0x5W6czm9cCgbVUUZLR8TprEsLoYzcBGDqgwYFZ9gER/EcCqHqaoR Ir5wHXEwpVyeD6rZ6jvrILNkn4Z5a7VaPJlKAyhW7fJ8KdrlaSTy1kZz9Qi2dK9qkXpULghktv+G hDaYSaJuIdEsGs8goWZ2LizaFhatzP1WFuprkRW5/wDMftTw3JyRXG+QoDDLU25fZPfcM70tmOa0 a5bptTOu55Npg4S23EwS2jKMYYjWm8851+1VSg16WSg2aTRb7yLXmYisaQNJzRo4lnuu7kk3AZx2 nLG8GcpiMpX+eKabkERpxwnEItD/RVmmjIs+5HEOU135/BMsEAMEJ3Kt62kg6YpbtdbM5nhBybUr Fy9y6ktPMhqPUSC2tKyqsi93Yu19S3BWoTNJ+iAOj8GIzNhtKAPlNatZAEPMxTKaIWba4l5FcU2u FlvR+MVstUUhmcZwcaLoYp7DVXlJR5uHYro+K7O+mMwoypL01qfu2UZZhyaaWw6Q7NS068e7O+Q1 VivdN1jl0r2ude1C67adEm9/IGjUVoMZ1DLGFmqrVpPaOV4ItOGWS3PbGXHep8H6qs0OiOJeqWob rybo6L5c+X15XZ0RwRVVdCKfEfziR+VcCVRroS4nAswY7jgPKl7X9WueX6q0vEHJrbuVUsvr1ktd z6tXB1610u/VHsqgiDipevnYQ/k8Q+aLNy+qfePtS1Jcsy8FNClTdQ8uK2P19qVa2/72BWAZmQeN 2rBdb/capXa9Oyy5/V6r1PYbvVK/4Tf7w77vtdrDhw44UmC3W/fdxqBValR9v+Q2Khn9VrvUdGu1 rtvstgZu9+Ei1nLmxXcRXsVr9x8AAAD//wMAUEsDBBQABgAIAAAAIQAWVpfvrAMAALQJAAARAAAA d29yZC9zZXR0aW5ncy54bWy0Vt1u2zYUvh+wdzB0PcWyItuJWqeI47hNEa9F5T0AJVI2Ef6BpOy4 w959h5QY2WlReCt6Zep855/fOfTbd8+cDXZEGyrFLBpdJNGAiEpiKjaz6K/1Mr6KBsYigRGTgsyi AzHRu5vff3u7zw2xFtTMAFwIk/NqFm2tVflwaKot4chcSEUEgLXUHFn41JshR/qpUXEluUKWlpRR eximSTKJOjdyFjVa5J2LmNNKSyNr60xyWde0It1PsNDnxG1NFrJqOBHWRxxqwiAHKcyWKhO88f/r DcBtcLL7URE7zoLefpScUe5eavxicU56zkBpWRFj4II4CwlS0QfOvnH0EvsCYncleldgPkr86Tjz 8X9zkL5yYNg5lbTQIy010i1PujJ4lT9shNSoZMBKKGcAGUU3QMuvUvLBPldEV3A3wOkkiYYOgI7I urDIEoA3GnHg4iyqGEGiVcCkRg2za1QWVipQ2iFIcpp29tUWaVRZoguFKujrnRRWSxb0sPxT2jvg tYa2dxae5f2paCcGLATikPbJFKwkBkrv80bT8zvrDHx0KP4o5OtAEiZcU0zWrl2FPTCyhOQL+pXc CvyxMZaCRz8LP5HBjxIgwkX+BBe8PiiyJMg20KZfFMzfxJJRtaJaS/0gMBDhlwWjdU00BKBArBXQ h2q5933+QBCGxfqTcYfHNII1jU04fJHSBtUkWWbJbXbdZurQHplcjrNR9j3k/j69m3bEOUV6b8OX qDx3K+6zDidHoQFvLe4QLzVFg5VbgkOnUeqnORUBLwlMNTlGiqYMYBy3gOGIsSXMWAD84PEcU6MW pPZntkJ60/vtNPR3pTDPH198uWVA9HstG9Wie41US42gMsqyzpIK+0h5kJumLIKVgD10BDUCf9pp 36e+PfvcwhX7EXtEnipel4j4/byjEtOFowFZIaVaNpWb0SxidLO1I0cAC18Y3kr/UW7SDks9lraY /0CVqwy0u0MvS4PsSO8yyC57WRZkWS8bB9m4l02CbOJkW5hjzah4AmKHo5PXkjG5J/hDj38japtg tkiRRbtzgV6yFXRL2Ax2OXmG9U0wtfAXRFHM0bPb5unEmXfaDB1kY090HeaU1akHjCwKI3Vi7Cn+ Khf3FlQU6FgceNmv+D/axBk1sAYUvAZW6oC98dho7J8JuwYWP8HFfiH1HBmCOwzL6gG7l6q1+Xt6 n6Sj8WgRp3dXkzhLpkl8Pb6dxvOreTZfXF8uFsvpP90Uhr9bN/8CAAD//wMAUEsDBBQABgAIAAAA IQBbbf2TCQEAAPEBAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWyU0cFKAzEQBuC74DssubfZFhVZ ui2IVLyIoD5Ams62wUwmzKSu9ekda61IL/WWSTIfM/yT2TvG6g1YAqXWjIa1qSB5Woa0as3L83xw bSopLi1dpASt2YKY2fT8bNI3PSyeoBT9KZUqSRr0rVmXkhtrxa8BnQwpQ9LHjhhd0ZJXFh2/bvLA E2ZXwiLEULZ2XNdXZs/wKQp1XfBwS36DkMqu3zJEFSnJOmT50fpTtJ54mZk8iOg+GL89dCEdmNHF EYTBMwl1ZajL7CfaUdo+qncnjL/A5f+A8QFA39yvErFbRI1AJ6kUM1PNgHIJGD5gTnzD1Auw/bp2 MVL/+HCnhf0T1PQTAAD//wMAUEsDBBQABgAIAAAAIQAik5godQEAAPsCAAARAAgBZG9jUHJvcHMv Y29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMkk1PwzAMhu9I/Icq 9zbtyteqrpMA7cQkJIZA3ELibWFtEiXeyv49abt1VOzAKXb8+I3zJvn0uyqDHVgntZqQJIpJAIpr IdVqQl4Xs/COBA6ZEqzUCiZkD45Mi8uLnJuMawvPVhuwKMEFXkm5jJsJWSOajFLH11AxF3lC+eJS 24qhT+2KGsY3bAV0FMc3tAJkgiGjjWBoekVykBS8lzRbW7YCglMooQKFjiZRQk8sgq3c2Ya28ous JO4NnEWPxZ7+drIH67qO6rRF/fwJfZ8/vbRXDaVqvOJAilzwDCWWUOT0FPrIbT+/gGO33Sc+5hYY alsY8HMGO6YC4VeHetOix3Jj/Ab2tbbCeZFB5jEBjltp0D9nd8Rgw9Mlczj377uUIO73Z0/7SzWN Fnay+SVF0hJ9mh8s7yYEEXirss7YY+UtfXhczEgxipPrML4NR+NFPM7SNIvjj2bIQf9JsDoM8H/F q6HiUaDzafhdix8AAAD//wMAUEsDBBQABgAIAAAAIQCe/91iIAsAAARwAAAPAAAAd29yZC9zdHls ZXMueG1svJ3bcts4Eobvt2rfgaWr3QtHlo+Ja5wp24nHrokznsiZXEMkJGENElweYnuffgGQkig3 QbHBHl/ZotQfQPz9g2gepF9+fY5l8JNnuVDJ+Wjybn8U8CRUkUgW56PvD9d770dBXrAkYlIl/Hz0 wvPRrx//+Y9fns7y4kXyPNCAJD+Lw/PRsijSs/E4D5c8Zvk7lfJEvzlXWcwK/TJbjGOWPZbpXqji lBViJqQoXsYH+/snoxqT9aGo+VyE/JMKy5gnhY0fZ1xqokrypUjzFe2pD+1JZVGaqZDnud7pWFa8 mIlkjZkcAVAswkzlal680ztT98iidPhk3/4Xyw3gGAc4WAPi8Ox2kaiMzaQefd2TQMNGH/XwRyr8 xOeslEVuXmb3Wf2yfmX/XKukyIOnM5aHQjzoljUkFpp3c5HkYqTf4SwvLnLBWt9cmn9a3wnzorH5 UkRiNDYt5v/Tb/5k8nx0cLDacmV6sLVNsmSx2saTvd8umz2xm75PzaaZ5p6PWLY3vTCB43rHqr+N 3U1fv7INpywUth02L7jOrMnJvoFKYRL54PjD6sW30owtKwtVN2IB1d81dgxGXCecTr9p5QL9Lp9/ UeEjj6aFfuN8ZNvSG7/f3mdCZTrTz0cfbJt645TH4kZEEU8aH0yWIuI/ljz5nvNos/3Pa5ut9YZQ lYn+//B0YrNA5tHn55CnJvf1uwkzmnw1AdJ8uhSbxm34f1ewSa1EW/ySMzMBBJPXCNt9FOLAROSN vW1nlq/23X4K1dDhWzV09FYNHb9VQydv1dDpWzX0/q0aspi/syGRRPy5MiJsBlB3cRxuRHMcZkNz HF5CcxxWQXMcTkBzHImO5jjyGM1xpCmCU6jQlYWNZD90ZHs3d/cxwo+7+5Dgx919BPDj7p7w/bi7 53c/7u7p3I+7e/b24+6erPHcaqkV3GqbJcVgl82VKhJV8KDgz8NpLNEsWxXR8MxBj2ckO0mAqWa2 +kA8mBYy+3p3hliT+h/PC1PIBWoezMWizHQxPbTjPPnJpS5rAxZFmkcIzHhRZo4R8cnpjM95xpOQ UyY2HdRUgkFSxjOC3EzZgozFk4h4+FZEkklhndC6fl4akwiCpI5ZmKnhXVOMbH74IvLhY2UgwWUp JSdifaVJMcsaXhtYzPDSwGKGVwYWM7wwaGhGNUQ1jWikahrRgNU0onGr8pNq3Goa0bjVNKJxq2nD x+1BFNJO8c1Vx6T/ubsrqcx57MH9mIpFwvQCYPjhpj5nGtyzjC0yli4Dc1a6HdvcZ2w7lyp6CR4o jmlrEtW63qbIld5rkZTDB3SLRmWuNY/IXmsekcHWvOEWu9PLZLNAu6GpZ6blrGg1rSX1Mu2UybJa 0A53GyuGZ9jGANciy8ls0I4lyOCvZjlr5KSY+Ta9HN6xDWu4rV7PSqTdq5EEvZQqfKSZhm9eUp7p suxxMOlaSameeERHnBaZqnKtafkDK0kvy3+O0yXLha2VthD9D/WrK+DBHUsH79C9ZCKh0e3zXsyE DOhWEDcPd1+CB5WaMtMMDA3wUhWFismY9ZnAf/3gs3/TdPBCF8HJC9HeXhCdHrKwK0FwkKlIKiIi 6WWmSATJMdTyfucvM8WyiIZ2n/HqppOCExGnLE6rRQeBt/S8+KTnH4LVkOX9xTJhzgtRmeqBBNY4 bZiXs//wcPhU91UFJGeG/igLe/7RLnVtNB1u+DJhCzd8iWDV1IcHk78EO7uFG76zWziqnb2SLM+F 8xKqN49qd1c86v0dXvzVPCVVNi8l3QCugGQjuAKSDaGSZZzklHtseYQ7bHnU+0uYMpZHcErO8n7L REQmhoVRKWFhVDJYGJUGFkYqwPA7dBqw4bfpNGDD79WpYERLgAaMKs9ID/9EV3kaMKo8szCqPLMw qjyzMKo8O/wU8PlcL4LpDjENJFXONZB0B5qk4HGqMpa9ECE/S75gBCdIK9p9pubmaQSVVDdxEyDN OWpJuNiucFQi/+Azsq4ZFmW/CM6IMimVIjq3tjng2Mjte9d2hdknOQZ34V6ykC+VjHjm2Cd3rK6X p9VjGa+7b7vR67TnF7FYFsF0uT7b38Sc7O+MXBXsW2G7G2wb85PV8yxtYXc8EmW86ih8mOLksH+w zeit4KPdwZuVxFbkcc9I2ObJ7sjNKnkr8rRnJGzzfc9I69OtyC4/fGLZY2sinHblz7rGcyTfaVcW rYNbm+1KpHVkWwqedmXRllWCizA0VwugOv08447vZx53PMZFbgrGTm5Kb1+5EV0G+8Z/CnNkx0ya tr313RNg3reL6F4z55+lqs7bb11w6v9Q161eOCU5D1o5h/0vXG3NMu5x7D3duBG95x03ovcE5Eb0 momc4agpyU3pPTe5Eb0nKTcCPVvBIwJutoLxuNkKxvvMVpDiM1sNWAW4Eb2XA24E2qgQgTbqgJWC G4EyKgj3MiqkoI0KEWijQgTaqHABhjMqjMcZFcb7GBVSfIwKKWijQgTaqBCBNipEoI0KEWijeq7t neFeRoUUtFEhAm1UiEAb1a4XBxgVxuOMCuN9jAopPkaFFLRRIQJtVIhAGxUi0EaFCLRRIQJlVBDu ZVRIQRsVItBGhQi0UatHDf2NCuNxRoXxPkaFFB+jQgraqBCBNipEoI0KEWijQgTaqBCBMioI9zIq pKCNChFoo0IE2qj2YuEAo8J4nFFhvI9RIcXHqJCCNipEoI0KEWijQgTaqBCBNipEoIwKwr2MCilo o0IE2qgQ0ZWf9SVK1232E/xZT+cd+/0vXdWd+tZ8lLuJOuyPWvXKzer/LMKlUo9B64OHh7be6AcR MymUPUXtuKze5NpbIlAXPv+46n7Cp0kf+KVL9bMQ9popgB/1jQTnVI66Ur4ZCYq8o65Mb0aCVedR 1+zbjASHwaOuSdf6cnVTij4cgeCuaaYRPHGEd83WjXA4xF1zdCMQjnDXzNwIhAPcNR83Ao8DMzm/ jj7uOU4n6/tLAaErHRuEUzehKy2hVqvpGBqjr2huQl/13IS+MroJKD2dGLywbhRaYTfKT2poM6zU /kZ1E7BSQ4KX1ADjLzVEeUsNUX5Sw4kRKzUkYKX2n5zdBC+pAcZfaojylhqi/KSGhzKs1JCAlRoS sFIPPCA7Mf5SQ5S31BDlJzVc3GGlhgSs1JCAlRoSvKQGGH+pIcpbaojykxpUyWipIQErNSRgpYYE L6kBxl9qiPKWGqK6pLZnUbakRincCMctwhqBuANyIxA3OTcCPaqlRrRntdQgeFZLUKuV5rhqqSma m9BXPTehr4xuAkpPJwYvrBuFVtiN8pMaVy21Se1vVDcBKzWuWnJKjauWOqXGVUudUuOqJbfUuGqp TWpctdQmtf/k7CZ4SY2rljqlxlVLnVLjqiW31LhqqU1qXLXUJjWuWmqTeuAB2YnxlxpXLXVKjauW 3FLjqqU2qXHVUpvUuGqpTWpcteSUGlctdUqNq5Y6pcZVS26pcdVSm9S4aqlNaly11CY1rlpySo2r ljqlxlVLnVI7qqXx09YPMBm2/UEy/eHiJeXmO7gbD8xE1XeQ1hcB7Qdvo/UPJZlg05Og/kmqerPt cH3BsGrRBsKmwqVuK6y/PcnRVP0tqOvHeOx3oL5u2PFVqbYjmyFYfboe0s2l0OpzW5c9O/tdmCHv 6LOVpHOMKtVcHfxQp+GuHur+zGT1o136n9sk0oCn+gerqp5Gz6xC6fevuJR3rPq0St0flXxeVO9O 9u1D86/en1Xf/+aMz+xE4QSMtztTvax/OMwx3tU3wtdXsJ0padzQMtz2doqhI73p2+q//OP/AQAA //8DAFBLAwQUAAYACAAAACEAGY/LP8QBAADtBAAAEgAAAHdvcmQvZm9udFRhYmxlLnhtbLyS24rb MBCG7wt9B6H7jWUn2YNZZ9mmGyiUXpTtAyiKbIvqYDRK3Lx9R7LjtoSlCYXKIOR/Zj6Nfubx6YfR 5CA9KGcrms8YJdIKt1O2qei3183NPSUQuN1x7ays6FECfVq9f/fYl7WzAQjWWyiNqGgbQldmGYhW Gg4z10mLwdp5wwP++iYz3H/fdzfCmY4HtVVahWNWMHZLR4y/hOLqWgn50Ym9kTak+sxLjURnoVUd nGj9JbTe+V3nnZAA+GajB57hyk6YfHEGMkp4B64OM3zM2FFCYXnO0snoX4DldYBiAhhRfmqs83yr 0XzshCCMrkb3SV9abjCw5lptvUqBjlsHMsfYgeuKsoJt2BL3+C3YPO40i4mi5R5khAyJbJBrbpQ+ nlToFcAQ6FQQ7Uk/cK9iU0MIVIOBPWxZRV8YrmKzoYOSV3SBwvN6Uop4V1r5qMwnhUVFJM6Q8ZCq ROJMOXhnNjhw5sSrMhLIF9mTr85w+4YjBbtFJ5boR3RmfpUjPnGvdaR4+d2RNSp394v5mSMPf3dk 4FzuyDgb5LNq2vDmhMS5+F8T8hxbRkP+nJCC3X048yO9/h8nZDzA6icAAAD//wMAUEsDBBQABgAI AAAAIQCtduY7yAEAANEDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAJxTQW7bMBC8F+gfBN5j2UFbFAatoHBQ5NA2Bqwk5w21sohSJEFuhLiv 71KMFbnNKTrNDJfD4S4lr557UwwYonZ2I1aLpSjQKtdoe9iIu/r7xVdRRALbgHEWN+KIUVxVHz/I XXAeA2mMBVvYuBEdkV+XZVQd9hAXvGx5pXWhB2IaDqVrW63w2qmnHi2Vl8vllxKfCW2DzYWfDEV2 XA/0XtPGqZQv3tdHz36VrLH3BgirX2mnkeUkyNoRmFr3WK1YnojcwQFj0jKQDy40sVrKMgO57SCA Im5dKpox+c17oxUQt7T6qVVw0bVU3I45i7RblvMSydn3qJ6CpmPyn1P5Q9ucIgNOFeAQwHcv0SYm 9woMbvnWVQsmoixfBXmDkCa6A53yDbQeUJELRdR/eKaXoniEiKlXGzFA0GBJ5LJMRmx8pFDVmgx7 T3yE87I51p9SyAzOC0cyZmB8nm48Id62fDd6I+xqHnbMkKPO4syTnc74x3Xreg+W+1tOiBv8O975 2l2nZ/HSw3NxNvMHTd3eg8rDeVOXe1ax4XFOE5kEecP5g0nuvNcesDnV/L+Q3tN9/kOr1efFkr/x AZ00fgbTr1P9BQAA//8DAFBLAQItABQABgAIAAAAIQAXqy8sZgEAAFQFAAATAAAAAAAAAAAAAAAA AAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAB6RGrfvAAAATgIAAAsAAAAA AAAAAAAAAAAAnwMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhACU3jJAIAQAAtQMAABwAAAAA AAAAAAAAAAAAvwYAAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHNQSwECLQAUAAYACAAAACEA wqKUNdgDAAAuCwAAEQAAAAAAAAAAAAAAAAAJCQAAd29yZC9kb2N1bWVudC54bWxQSwECLQAUAAYA CAAAACEAfxmT4pEKAAAMSAAAFQAAAAAAAAAAAAAAAAAQDQAAd29yZC9tZWRpYS9pbWFnZTEuZW1m UEsBAi0AFAAGAAgAAAAhAKpSJd8jBgAAixoAABUAAAAAAAAAAAAAAAAA1BcAAHdvcmQvdGhlbWUv dGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAWVpfvrAMAALQJAAARAAAAAAAAAAAAAAAAACoeAAB3 b3JkL3NldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQBbbf2TCQEAAPEBAAAUAAAAAAAAAAAAAAAA AAUiAAB3b3JkL3dlYlNldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQAik5godQEAAPsCAAARAAAA AAAAAAAAAAAAAEAjAABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQCe/91iIAsAAARw AAAPAAAAAAAAAAAAAAAAAOwlAAB3b3JkL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAGY/LP8QB AADtBAAAEgAAAAAAAAAAAAAAAAA5MQAAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAh AK125jvIAQAA0QMAABAAAAAAAAAAAAAAAAAALTMAAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAAAwA DAAEAwAAKzYAAAAA --=_da384acec34e3fd491aadd2ae706c4b8-- From nobody Wed Jul 29 03:11:10 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C2D1A0242 for ; Wed, 29 Jul 2015 03:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.528 X-Spam-Level: * X-Spam-Status: No, score=1.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, T_RP_MATCHES_RCVD=-0.01] autolearn=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 VCdTeY6OZRS7 for ; Wed, 29 Jul 2015 03:11:06 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 876391A0161 for ; Wed, 29 Jul 2015 03:11:04 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id BD72F19F4E0 for ; Wed, 29 Jul 2015 18:11:02 +0800 (HKT) Received: from WeiGengyuPC (unknown [114.246.133.13]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 3BF2B19F486; Wed, 29 Jul 2015 18:11:02 +0800 (HKT) Message-ID: <5800DFACB3C149638A139D518C3E9B9F@WeiGengyuPC> From: "weigengyu" To: =?utf-8?Q?G=C3=B6ran_Selander?= References: <5570428E.5070500@sics.se> <87oaku75cd.fsf@aung.informatik.uni-bremen.de> <87lhe7arpr.fsf@aung.informatik.uni-bremen.de> <87si8a7ztu.fsf@aung.informatik.uni-bremen.de> <55B602D3.1070302@cs.tcd.ie> In-Reply-To: Date: Wed, 29 Jul 2015 18:10:56 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: core@ietf.org Subject: Re: [core] Question about blockwise and object security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 10:11:08 -0000 Hi Göran, My opinion is that CoAP should have the capability to secure blockwise transfer end-to-end. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Göran Selander Sent: Tuesday, July 28, 2015 2:23 PM To: core Subject: Re: [core] Question about blockwise and object security On 2015-07-27 12:07, "Stephen Farrell" wrote: > > >On 27/07/15 09:46, Olaf Bergmann wrote: >> 2. if an intermediary splits a protected message into blocks it must add >> some sort of integrity protection for the block to enable the >> receiver to detect and throw away blocks that have been injected by a >> malicious intermediary. > >FWIW, I don't believe I've ever seen that work. The crucial problems >being that the receiver doesn't have any basis on which to accept or >reject the actions of an intermediary, and that in general this can >happen more than once on a path and it may not be the ultimate receiver >who needs to check. All that seems to always add up to something that >just doesn't work and you end up with only hop-by-hop or end-to-end >security being practical. Maybe this has already been discussed but just for clarification: Do we want to secure blockwise transfer end-to-end or should we leave to the applications of CoAP? Example of use case mentioned is firmware update. Regards, Göran > >S. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Wed Jul 29 03:49:22 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418571A8716 for ; Wed, 29 Jul 2015 03:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] autolearn=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 w0wdIOTjbDia for ; Wed, 29 Jul 2015 03:49:20 -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 515281A86E8 for ; Wed, 29 Jul 2015 03:49:20 -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 t6TAnGqn018266; Wed, 29 Jul 2015 12:49:16 +0200 (CEST) Received: from alma.local (p5DC7F6B9.dip0.t-ipconnect.de [93.199.246.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mhBSr3nZnzDJ7k; Wed, 29 Jul 2015 12:49:16 +0200 (CEST) Message-ID: <55B8AFAA.1000802@tzi.org> Date: Wed, 29 Jul 2015 12:49:14 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <5570428E.5070500@sics.se> <87oaku75cd.fsf@aung.informatik.uni-bremen.de> <87lhe7arpr.fsf@aung.informatik.uni-bremen.de> <87si8a7ztu.fsf@aung.informatik.uni-bremen.de> <55B602D3.1070302@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core Subject: Re: [core] Question about blockwise and object security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 10:49:21 -0000 > Maybe this has already been discussed but just for clarification: Do we > want to secure blockwise transfer end-to-end or should we leave to the > applications of CoAP? Example of use case mentioned is firmware update. There are two ways to do this: Secure each exchange of the blockwise transfer or secure the blockwise transfer as a whole. The first one we almost get for free, unless we want to support re-arrangement of blocks in a proxy (then it gets hairy). The second one is easy for the payload-only variant (PAYL) that you are proposing, slightly less easy for the message protection (COAP): the latter would need some rules about which options need to coincide between the blocks to make the entire transfer valid. I can imagine use cases for each of these variants. For a firmware transfer that happens on an unprotected network using NoSec mode, you actually might want both at the same time (protect the blocks to make denial of service harder, protect the whole because you might want to use a more expensive operation there). Of course, the first may be done by DTLS (not using NoSec mode), and the second may be done by some application-defined mechanism specifically protecting firmware updates. Grüße, Carsten From nobody Wed Jul 29 11:56:21 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF9C1ACE0F for ; Wed, 29 Jul 2015 11:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RVohtx0O8BX for ; Wed, 29 Jul 2015 11:56:18 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19231ACE17 for ; Wed, 29 Jul 2015 11:56:08 -0700 (PDT) Received: from CO2PR0601MB792.namprd06.prod.outlook.com (10.141.247.144) by CO2PR0601MB790.namprd06.prod.outlook.com (10.141.247.142) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 29 Jul 2015 18:56:06 +0000 Received: from CO2PR0601MB792.namprd06.prod.outlook.com ([10.141.247.144]) by CO2PR0601MB792.namprd06.prod.outlook.com ([10.141.247.144]) with mapi id 15.01.0219.023; Wed, 29 Jul 2015 18:56:06 +0000 From: Michel Veillette To: Carsten Bormann , "consultancy@vanderstok.org" Thread-Topic: [core] Patch idempotent? Thread-Index: AQHQyRnDaZhy5mr1Bk6ZMh8Ui25H553yISKAgACqUFA= Date: Wed, 29 Jul 2015 18:56:06 +0000 Message-ID: References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> <55B8908F.8020808@tzi.org> In-Reply-To: <55B8908F.8020808@tzi.org> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none; x-originating-ip: [207.96.192.122] x-microsoft-exchange-diagnostics: 1; CO2PR0601MB790; 5:+0NhK57phePbHDvc87lOX078pEp+DQxlAICQsNUTSPXkTADWShutVHWX/F49O0m9SJCjjVsX3Bbjz6aUAC7IhBECIbL948i+bUb+pDErWiNbov0wT+y8rjV0bXko6gS3NKjnw9Ylm0xt/t3bcbNCpg==; 24:BOqbqXl83m+POlqqSyF66PHR1XN31yOZ3SqfyxZOhVZ7ZB18bByUP++75rsb/aLxLjUIyjLH3sybQKrML1ZJrOBF0hfQo786J/hcmtBAX3k=; 20:ucIr/dLm4EvGr6yjvCu8wIvdHg8BTIKNOq/z6kKUE7TpLUSrCH/HnQu4kqPf3vPFkLbr4pOqkROSVW7gqxmwlg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR0601MB790; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO2PR0601MB790; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0601MB790; x-forefront-prvs: 0652EA5565 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(38414003)(13464003)(15974865002)(189998001)(5002640100001)(40100003)(99286002)(86362001)(106116001)(122556002)(5001960100002)(92566002)(66066001)(76176999)(50986999)(19580395003)(46102003)(54356999)(19580405001)(2900100001)(2950100001)(5003600100002)(102836002)(15975445007)(77096005)(87936001)(76576001)(2656002)(74316001)(2501003)(5001770100001)(33656002)(62966003)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0601MB790; H:CO2PR0601MB792.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2015 18:56:06.2182 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0601MB790 Archived-At: Cc: Core Subject: Re: [core] Patch idempotent? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 18:56:20 -0000 SGkgQ2Fyc3RlbiwgSGkgUGV0ZXINCg0KQXNzdW1pbmc6DQotIFlBTkcgaXMgdXNlZCBhcyBtb2Rl bGluZyBsYW5ndWFnZQ0KLSBrZXlzIGlzIGFsd2F5cyBkZWZpbmVkIGZvciBsaXN0cw0KLSBBbGwg a2V5KHMpIGFyZSBwcm92aWRlZCBkdXJpbmcgYSBQT1NUIG9yIERFTEVURSBvcGVyYXRpb25zDQot IE9ubHkgZ2xvYmFsIG9wZXJhdGlvbnMgYXJlIGFsbG93ZWQgb24gbGVhZi1saXN0cw0KDQpBcmUg d2Ugbm90IGRlYWxpbmcgd2l0aCBqdXN0IGlkZW1wb3RlbnQgcGF0Y2ggb3BlcmF0aW9ucz8NCklm IG5vdCwgd2hpY2ggdXNlIGNhc2VzIGFyZSBub3QgaWRlbXBvdGVudD8NCg0KTWljaGVsIFZlaWxs ZXR0ZQ0KU3lzdGVtIEFyY2hpdGVjdHVyZSBEaXJlY3Rvcg0KVHJpbGxpYW50IEluYy4NClRlbDog NDUwLTM3NS0wNTU2IGV4dC4gMjM3DQptaWNoZWwudmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20N Cnd3dy50cmlsbGlhbnRpbmMuY29tIMKgIA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg Q2Fyc3RlbiBCb3JtYW5uDQpTZW50OiAyOSBqdWlsbGV0IDIwMTUgMDQ6MzcNClRvOiBjb25zdWx0 YW5jeUB2YW5kZXJzdG9rLm9yZw0KQ2M6IENvcmUNClN1YmplY3Q6IFJlOiBbY29yZV0gUGF0Y2gg aWRlbXBvdGVudD8NCg0KSGkgUGV0ZXIsDQoNCkkgYWxzbyBiZWxpZXZlIHRoYXQsIGlmIHdlIGFy ZSBnb2luZyBkb3duIHRoZSBpZGVtcG90ZW50IGFsbGV5LCB3ZSdsbCBuZWVkIHRvIGRpc3Rpbmd1 aXNoIFBBVENIIChub3QgbmVjZXNzYXJpbHkgaWRlbXBvdGVudCwgbGlrZSBIVFRQIFBBVENIKSBm cm9tIGlQQVRDSCAoaWRlbXBvdGVudCwgc29tZXRoaW5nIG5ldykuICBXaGV0aGVyLCBpbiB0aGUg ZW5kLCB3ZSB3YW50IHRvIGFkZCBib3RoIHRvIENvQVA6IEkgZG9uJ3QgaGF2ZSBhbiBvcGluaW9u IG9uIHRoYXQgeWV0Lg0KDQpBIGZldyBtb3JlIGRhdGEgcG9pbnRzOg0KDQpSRkMgNjkwMiAiYWRk IiBpcyBub3QgbmVjZXNzYXJpbHkgaWRlbXBvdGVudC4NCg0KU2VlDQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM2OTAyI2FwcGVuZGl4LUEuMg0KZm9yIGFuIGlsbHVzdHJhdGlvbi4NCg0K KERvaW5nIHRoZSBwYXRjaCBhZ2FpbiBsZWFkcyB0bw0KICAgeyAiZm9vIjogWyAiYmFyIiwgInF1 eCIsICJxdXgiLCAiYmF6IiBdIH0pDQoNClNpbWlsYXIgd2l0aCAicmVtb3ZlIjoNCg0KaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjkwMiNhcHBlbmRpeC1BLjQNCg0KSW4gY29udHJhc3Qs IFJGQyA3Mzk2IG9wZXJhdGlvbnMgYWx3YXlzIGFwcGVhciB0byBiZSBpZGVtcG90ZW50LCBidXQg dGhlbiwgdGhlcmUgYXJlIG5vIGFycmF5IG9wZXJhdGlvbnMgaW4gUkZDIDczOTYgYXQgYWxsLiAg UG9zaXRpb25hbCBhcnJheSBvcGVyYXRpb25zIGFyZSBoYXJkZXIgdG8gZ2V0IGlkZW1wb3RlbnQg YmVjYXVzZSBwb3NpdGlvbnMgY2hhbmdlIGJlY2F1c2Ugb2YgdGhlIG9wZXJhdGlvbi4gIEdldHRp bmcgaWRlbXBvdGVuY3kgZm9yIGFycmF5IG9wZXJhdGlvbnMgd291bGQgcmVxdWlyZSBzb21lIGNv bnRlbnQgc2VhcmNoaW5nIChpLmUuLCBpZiAidGhlIGl0ZW0iIGlzIGFscmVhZHkgdGhlcmUsIGRv bid0IGFkZCBpdCBhZ2FpbjsgaWYgaXQgaXMgYWxyZWFkeSBnb25lLCBkb24ndCByZW1vdmUgYW5v dGhlciBvbmUgaW4gaXRzIHBsYWNlIC0tIHRoaXMgcmVxdWlyZXMgYSB3YXkgdG8gZXhwcmVzcyB3 aGF0IGlzIG1lYW50IGJ5ICJ0aGUgaXRlbSIpLg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcg bGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3JlDQo= From nobody Thu Jul 30 00:28:38 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9A01AC3CE for ; Thu, 30 Jul 2015 00:28:36 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeFEY307EaPY for ; Thu, 30 Jul 2015 00:28:34 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1653C1AC3DC for ; Thu, 30 Jul 2015 00:28:33 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud2.xs4all.net with ESMTP id yXUV1q00U4K0fSy01XUVx6; Thu, 30 Jul 2015 09:28:31 +0200 Received: from [2001:983:a264:1:6c86:6fc1:5bfd:d2e8] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 30 Jul 2015 09:28:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 30 Jul 2015 09:28:29 +0200 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> <55B8908F.8020808@tzi.org> Message-ID: <16941c08700306440c34513453e0719a@xs4all.nl> X-Sender: stokcons@xs4all.nl (RGrqu4JgXHR09cw3Wv41dJtYscaJnOnn) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] Patch idempotent? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 07:28:36 -0000 Hi Michel, > - YANG is used as modeling language Is not valid for other applications that (may) use Patch in CoAP. For example the use of move, add and copy suggested by RFC 6902 are not idempotent. Peter Michel Veillette schreef op 2015-07-29 20:56: > Hi Carsten, Hi Peter > > Assuming: > - YANG is used as modeling language > - keys is always defined for lists > - All key(s) are provided during a POST or DELETE operations > - Only global operations are allowed on leaf-lists > > Are we not dealing with just idempotent patch operations? > If not, which use cases are not idempotent? > > Michel Veillette > System Architecture Director > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > michel.veillette@trilliantinc.com > www.trilliantinc.com   > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: 29 juillet 2015 04:37 > To: consultancy@vanderstok.org > Cc: Core > Subject: Re: [core] Patch idempotent? > > Hi Peter, > > I also believe that, if we are going down the idempotent alley, we'll > need to distinguish PATCH (not necessarily idempotent, like HTTP > PATCH) from iPATCH (idempotent, something new). Whether, in the end, > we want to add both to CoAP: I don't have an opinion on that yet. > > A few more data points: > > RFC 6902 "add" is not necessarily idempotent. > > See > http://tools.ietf.org/html/rfc6902#appendix-A.2 > for an illustration. > > (Doing the patch again leads to > { "foo": [ "bar", "qux", "qux", "baz" ] }) > > Similar with "remove": > > http://tools.ietf.org/html/rfc6902#appendix-A.4 > > In contrast, RFC 7396 operations always appear to be idempotent, but > then, there are no array operations in RFC 7396 at all. Positional > array operations are harder to get idempotent because positions change > because of the operation. Getting idempotency for array operations > would require some content searching (i.e., if "the item" is already > there, don't add it again; if it is already gone, don't remove another > one in its place -- this requires a way to express what is meant by > "the item"). > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Jul 30 01:27:33 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BA01B2CE2 for ; Thu, 30 Jul 2015 01:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 mDjEaIazk2uK for ; Thu, 30 Jul 2015 01:27:30 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777461B2CE1 for ; Thu, 30 Jul 2015 01:27:29 -0700 (PDT) Received: by lahh5 with SMTP id h5so20599633lah.2 for ; Thu, 30 Jul 2015 01:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=j18mXhk7xxCcNj9dtOdyz+ymaXrNjFTsUMYauJIi21M=; b=lShe19E8UxUtPIEKAszJh8SNCVUi9LokWPK3DsUjoxCQfLBGfI7KN8e/OUyf9/NR2r Q57DglrNSstEo9s0zC6mvABrrENTXRDtlwouaTRo+1IEtobJElEk07QCok0Ytq2MKBy5 AwjYDSbMSpGeU2R0L12u6pUzyrHy1VLoWTNC11xQZSj7S1AIasF1yCUmdwd0qJwrWMa4 H/44AEMagGtV1cxaW4kbvHvUNPHbgspmodCWMVioQ8hpCoPI/bL4w98Fv5JfwH4kBJDm EGKW9ZEfhoHoLPijvKDdHKYsb9GaIDfrswyLLqdmuxSWOHSsddnD8Uv6dgK9wDR3pqKl 1XcA== MIME-Version: 1.0 X-Received: by 10.152.197.2 with SMTP id iq2mr43307111lac.103.1438244847955; Thu, 30 Jul 2015 01:27:27 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.25.31.75 with HTTP; Thu, 30 Jul 2015 01:27:27 -0700 (PDT) In-Reply-To: References: <191bfb9c554053d41bca8aa56a77d49f@xs4all.nl> Date: Thu, 30 Jul 2015 09:27:27 +0100 X-Google-Sender-Auth: 43tnABfZrpUu60rfiLN6yauQd8s Message-ID: From: Robert Cragie To: weigengyu Content-Type: multipart/alternative; boundary=001a11340b0643350d051c137911 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Patch idempotent? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 08:27:32 -0000 --001a11340b0643350d051c137911 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I tend to agree - why does PATCH need to be idempotent? Only two of its applications (replace, delete) seem obviously idempotent. The partial operation of PATCH also implies its operation in a sequence. Then the idempotency of the whole sequence needs to be considered. Robert On 29 July 2015 at 10:22, weigengyu wrote: > HI Peter, > > It seems not to be a critical issue to be idempotent. > Probably, conditional request can handle this issue. > > In RFC5789, > "PATCH is neither safe nor idempotent as defined by [RFC2616], Section > 9.1." > "A PATCH request can be issued in such a way as to be idempotent, > which also helps prevent bad outcomes from collisions between two > PATCH requests on the same resource in a similar time frame. > Collisions from multiple PATCH requests may be more dangerous than > PUT collisions because some patch formats need to operate from a > known base-point or else they will corrupt the resource. Clients > using this kind of patch application SHOULD use a conditional request > such that the request will fail if the resource has been updated > since the client last accessed the resource. For example, the client > can use a strong ETag [RFC2616] in an If-Match header on the PATCH > request." > > In RFC 6902, it is not mention to be idempotent. > "JavaScript Object Notation (JSON) [RFC4627] is a common format for > the exchange and storage of structured data. HTTP PATCH [RFC5789] > extends the Hypertext Transfer Protocol (HTTP) [RFC2616] with a > method to perform partial modifications to resources." > "JSON Patch is a format (identified by the media type "application/ > json-patch+json") for expressing a sequence of operations to apply to > a target JSON document; it is suitable for use with the HTTP PATCH > method." > > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: peter van der Stok > Sent: Tuesday, July 28, 2015 5:42 PM > To: Core > Subject: [core] Patch idempotent? > > > Hi all, > > During the CoRE meeting on friday, the suggestion was done that an > idem-potent patch in CoAP should be called iPatch and that Patch itself > is not necessarily idempotent. > > I can identify 2 reasons why patch should not be idempotent: > > 1) the patch adds new sections to a resource and is not idem-potent when > for example new sections are identified by invocation date and time. > 2) the patch changes the content of the resource as function of the > resource state e.g. incrementing its values > > Other possibilities, not identified by me, may exist. > > 3) An idempotent Patch can be restricted to replacing a subset of the > variables in the resource to the same subset with possibly different > values. > > RF6902 restricts its operations to add, remove, move, copy, replace. > The way the operations add, remove, replace are specified in 6902 > implies their idem-potency; copy and move are not because dependent on > the resource state. > > RFC7396 supports only the operations add, remove and replace, and is > consequently an idem-potent format. > > My proposal is to specify Patch for CoAP to be non-idempotent conforming > to the http interpretation. > This being said, we can add a new method to CoAP, called "iPatch", which > is idem-potent and probably fulfils what most applications want Patch to > do (RFC7396 semantics). > > The Patch command could then also include RPC semantics like toggle, or > INC(x), or actuator settings, currently excluded by an idem-potent PUT > in CoAP. > > Looking forward to other opinions, > > peter > > > > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > www: www.vanderstok.org > tel NL: +31(0)492474673 F: +33(0)966015248 > > _______________________________________________ > 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 > --001a11340b0643350d051c137911 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I tend to agree - why does PATCH need to be idempotent? On= ly two of its applications (replace, delete) seem obviously idempotent. The= partial operation of PATCH also implies its operation in a sequence. Then = the idempotency of the whole sequence needs to be considered.

Robert

On 29 July 2015 at 10:22, weigengyu <weigengyu@bupt.edu.cn&= gt; wrote:
HI Peter,

It seems not to be a critical issue to be idempotent.
Probably, conditional request can handle this issue.

In RFC5789,
"PATCH is neither safe nor idempotent as defined by [RFC2616], Section= 9.1."
"A PATCH request can be issued in such a way as to be idempotent,
=C2=A0 which also helps prevent bad outcomes from collisions between two =C2=A0 PATCH requests on the same resource in a similar time frame.
=C2=A0Collisions from multiple PATCH requests may be more dangerous than =C2=A0PUT collisions because some patch formats need to operate from a
=C2=A0known base-point or else they will corrupt the resource.=C2=A0 Client= s
=C2=A0using this kind of patch application SHOULD use a conditional request=
=C2=A0such that the request will fail if the resource has been updated
=C2=A0since the client last accessed the resource.=C2=A0 For example, the c= lient
=C2=A0can use a strong ETag [RFC2616] in an If-Match header on the PATCH re= quest."

In RFC 6902, it is not mention to be idempotent.
"JavaScript Object Notation (JSON) [RFC4627] is a common format for =C2=A0the exchange and storage of structured data.=C2=A0 HTTP PATCH [RFC578= 9]
=C2=A0extends the Hypertext Transfer Protocol (HTTP) [RFC2616] with a
=C2=A0method to perform partial modifications to resources."
"JSON Patch is a format (identified by the media type "applicatio= n/
=C2=A0 json-patch+json") for expressing a sequence of operations to ap= ply to
=C2=A0 a target JSON document; it is suitable for use with the HTTP PATCH m= ethod."


Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: peter van der Stok
Sent: Tuesday, July 28, 2015 5:42 PM
To: Core
Subject: [core] Patch idempotent?

Hi all,

During the CoRE meeting on friday, the suggestion was done that an
idem-potent patch in CoAP should be called iPatch and that Patch itself
is not necessarily idempotent.

I can identify 2 reasons why patch should not be idempotent:

1) the patch adds new sections to a resource and is not idem-potent when for example new sections are identified by invocation date and time.
2) the patch changes the content of the resource as function of the
resource state e.g. incrementing its values

Other possibilities, not identified by me, may exist.

3) An idempotent Patch can be restricted to replacing a subset of the
variables in the resource to the same subset with possibly different
values.

RF6902 restricts its operations to add, remove, move, copy, replace.
The way the operations add, remove, replace are specified in 6902
implies their idem-potency; copy and move are not because dependent on
the resource state.

RFC7396 supports only the operations add, remove and replace, and is
consequently an idem-potent format.

My proposal is to specify Patch for CoAP to be non-idempotent conforming to the http interpretation.
This being said, we can add a new method to CoAP, called "iPatch"= , which
is idem-potent and probably fulfils what most applications want Patch to do (RFC7396 semantics).

The Patch command could then also include RPC semantics like toggle, or
INC(x), or actuator settings, currently excluded by an idem-potent PUT
in CoAP.

Looking forward to other opinions,

peter



--
Peter van der Stok
vanderstok consultancy
mailto: con= sultancy@vanderstok.org
www: www.vanderstok.org
tel NL: +31(0)492474673=C2=A0 =C2=A0 =C2=A0F: +33(0)966015248

_______________________________________________
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

--001a11340b0643350d051c137911-- From nobody Fri Jul 31 06:02:11 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB301A6EE1 for ; Fri, 31 Jul 2015 06:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xASB5EPdyhwc for ; Fri, 31 Jul 2015 06:02:05 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503031A1BE4 for ; Fri, 31 Jul 2015 06:02:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,584,1432591200"; d="scan'208,217";a="141699932" Received: from zmbs2.inria.fr ([128.93.142.15]) by mail3-relais-sop.national.inria.fr with ESMTP; 31 Jul 2015 15:02:03 +0200 Date: Fri, 31 Jul 2015 15:02:03 +0200 (CEST) From: William Bertier To: core Message-ID: <157066052.8635933.1438347723122.JavaMail.zimbra@inria.fr> In-Reply-To: <386682558.8635105.1438347496964.JavaMail.zimbra@inria.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8635932_1195455112.1438347723122" X-Originating-IP: [131.254.12.159] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF38 (Linux)/8.0.9_GA_6191) Thread-Topic: Question about plugtest 2014 + proxy configuration Thread-Index: OGcmdXMcWlwNrJQ00eiJFKy3WiSaMQ== Archived-At: Subject: [core] Question about plugtest 2014 + proxy configuration X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jul 2015 13:02:10 -0000 ------=_Part_8635932_1195455112.1438347723122 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, The tests with a configuration with proxy (TD_COAP_CORE_24 ... 29) They was removed from the documentation PlugTest 2014: https://github.com/cabo/td-coap4/ The tests have been deleted or not present in the documentation? William Bertier ------=_Part_8635932_1195455112.1438347723122 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello,

The tests with a configuration with proxy (TD_COAP_CORE_24 ... 29)
They was removed from the documentation PlugTest 2014:
https://github.com/cabo/td-coap4/

The tests have been deleted or not present in the documentation?

William Bertier
------=_Part_8635932_1195455112.1438347723122-- From nobody Fri Jul 31 08:05:24 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696BF1A03A1 for ; Fri, 31 Jul 2015 08:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 4age6QNrSdfX for ; Fri, 31 Jul 2015 08:05:22 -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 B78F41A039A for ; Fri, 31 Jul 2015 08:05:21 -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 t6VF5GN3011986; Fri, 31 Jul 2015 17:05:16 +0200 (CEST) Received: from alma.local (p5DC7F6B9.dip0.t-ipconnect.de [93.199.246.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mjX3J3RrkzDGml; Fri, 31 Jul 2015 17:05:16 +0200 (CEST) Message-ID: <55BB8EAA.3060000@tzi.org> Date: Fri, 31 Jul 2015 17:05:14 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: William Bertier References: <157066052.8635933.1438347723122.JavaMail.zimbra@inria.fr> In-Reply-To: <157066052.8635933.1438347723122.JavaMail.zimbra@inria.fr> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core Subject: Re: [core] Question about plugtest 2014 + proxy configuration X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jul 2015 15:05:23 -0000 I seem to remember that we simply didn't have a proxy available to test this with. Grüße, Carsten William Bertier wrote: > Hello, > > The tests with a configuration with proxy (TD_COAP_CORE_24 ... 29) > They was removed from the documentation PlugTest 2014: > https://github.com/cabo/td-coap4/ > > The tests have been deleted or not present in the documentation? > > William Bertier > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core