From nobody Tue Sep 1 08:41:59 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 B6C601B4D09 for ; Tue, 1 Sep 2015 08:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 k-HN3Od3wnrb for ; Tue, 1 Sep 2015 08:41:54 -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 A35C41B4D0E for ; Tue, 1 Sep 2015 08:41:18 -0700 (PDT) Received: from [192.168.10.156] ([101.53.7.10]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MWxtA-1Z9gGU3xyO-00VwHD; Tue, 01 Sep 2015 17:41:15 +0200 To: "core@ietf.org" , =?UTF-8?Q?G=c3=b6ran_Selander?= , "Cuellar, Jorge" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <55E5C717.8080900@gmx.net> Date: Tue, 1 Sep 2015 17:41:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KvTSeC2lwf783MCqT7I4ufBdaiFJweAGA" X-Provags-ID: V03:K0:mpd7v/XOULIvYSztkLwwOdUAkRqw2hSUKXXms28po+nQ+jsRAGv tyxIE9H2gvA/CB4pgVrBWySyjdo3h5KibALKwAuUf4srtwmfLmeHLiXVM7D3IVDr0UEs78I lXxxJDfFA+6KEsfKlzAcmvLxI6eElP5DSFDP5vwuCux6r9871ftSNtCMZta3dLPxbNwrOCj RYlD23WQromWEn4Om2Fug== X-UI-Out-Filterresults: notjunk:1;V01:K0:29EYPIWmRyM=:IKuwJSzBJpRpGfKiQvoZvB toRBS3/ylCKnGkDPhXjrfiCAlBMJEMbiv4/12WL1UONqls1x/d3mDAKmwPU6iGbm/1N4gSZYa zEHqz09XbviwWUExY/SpO0FTeHxYEN4YmNnbkJnASQkuDy2iMO0koIQW2lFvNlxKHBi14ZtSP rvaOARJcU8GsDIJRuQos2zHw9bwJrQLEHySYDRlL4zshM3yDBcKwtkdgT6a+tTDcHGiH8hVzV Pybuz/Tf6iDazu2cfu/YvIXLFGcJ6qr01LdqVtBV5+4ke/CsxtKBG+SFOjf8Fuizy4QUN+qNE Os22hq3N9XXE0Trdtj9DgK0WiL+ov2QSbU+A2rerIOU/2xIJhpViM511mSfSu9Bvyp5urLwHr KciLiMlZrs3u4s1ij76U7SucNUjhSHy29DoggHTgtxl0sCW1fzSovW6ODMWgwsnJ7oyb2pGAI 3rHQprG5rhT5r0WjJk9bwDWJ0i3Gl7e4/gsUAbSHpPFb1flLdz2EBzWKvDQd2pUuSYcK3bc2E NUtM7iCEwWWdLPF8kythsqQn0w9rx1zgdU0yRCMCErcwf8KzHYBdPwqFpysp/WoJEXaSoibBJ Tj0LU0KnKSgLaHNGp0xDnpi/tKQErbPr+O+qh8AFEvxOLwjdq3M21P8RsdRC/yX8XiYcVTLyR +tNlcdk6gGudOwtPrZLDVEWU5LBjPQRGQ2QGDpAFfFE8myd2qb/ruPmuWw7/QEghp/PT+WnJO i5KK9W/yPisQCR5eEZ2tKYtMUby9AZDzMAN5Ww== Archived-At: Subject: Re: [core] [Ace] COSE requirements from CORE/ACE 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, 01 Sep 2015 15:41:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KvTSeC2lwf783MCqT7I4ufBdaiFJweAGA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Goeran, > we really need MAC-only? I would have said that we do not need MAC only. Ideally, we want to have encryption as often as we can. It does not really cost more in terms of payload size and performance. Ciao Hannes --KvTSeC2lwf783MCqT7I4ufBdaiFJweAGA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV5ccXAAoJEGhJURNOOiAt61cIAIruHWQbQT7W4lfQHn71rFD2 KE9khHozUvyaEQIsAa3EdG+TJVbo/ytYMPBZFaT5/9mMopCtRU8M1J6HG9LGKiv7 LKDn4n1bMorGcYnKeG6BwkRSrvVgB3kqy1UajNrrcNS4LZOzgtVmjUxFiH6OPe+E MbB/4qYZMn/TOpk8l4dy36pcuDkAvkhKnL4sdbpZCUKhzQ6sXc/nyvl6QPdlKBW2 zh/vb0GMeCl5Rmbkm/X0xtnOc6doe0Z2Mcfo+xY21INML4urUVEEVdhL2RVuGWmJ HStLY0N7PDlVIWSm+UFQ7sbDwbEZS7pclCGF8+vASoVLWT2Q/VHP8o1JFec03+E= =jnvv -----END PGP SIGNATURE----- --KvTSeC2lwf783MCqT7I4ufBdaiFJweAGA-- From nobody Tue Sep 1 09:32: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 640EE1B44E4 for ; Tue, 1 Sep 2015 09:32:06 -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 hb7C2abOArbH for ; Tue, 1 Sep 2015 09:32:05 -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 D44841B50A5 for ; Tue, 1 Sep 2015 09:32:04 -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 t81GVxeo007635; Tue, 1 Sep 2015 18:31:59 +0200 (CEST) Received: from alma.local (unknown [134.102.117.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 3n5DSb2tmGzDJLB; Tue, 1 Sep 2015 18:31:59 +0200 (CEST) Message-ID: <55E5D2FE.3060301@tzi.org> Date: Tue, 01 Sep 2015 18:31:58 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: Hannes Tschofenig References: <55E5C717.8080900@gmx.net> In-Reply-To: <55E5C717.8080900@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Cuellar, Jorge" , "core@ietf.org" Subject: Re: [core] [Ace] COSE requirements from CORE/ACE 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, 01 Sep 2015 16:32:06 -0000 Hannes Tschofenig wrote: > Ideally, we want to have encryption as often as we can. That is the mantra when there is personally identifiable information involved. In REST, we also have an important property called "visibility". Where visibility and privacy are in conflict, the latter usually wins. They aren't always. Gr眉脽e, Carsten From nobody Wed Sep 2 03:00: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 EDFF91B52DB for ; Wed, 2 Sep 2015 03:00:41 -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 ThRjQSt7vzCw for ; Wed, 2 Sep 2015 03:00:40 -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 235161B52D6 for ; Wed, 2 Sep 2015 03:00:39 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-61-55e6c8c6f271 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FD.E3.05274.6C8C6E55; Wed, 2 Sep 2015 12:00:38 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.14]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Wed, 2 Sep 2015 12:00:37 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann Thread-Topic: [core] Question about blockwise and object security Thread-Index: AQHQyEi1ifAo4IfuAEaNVGqjiqBkNZ3u9e2AgAF1YACAAbsFAIA3FYkA Date: Wed, 2 Sep 2015 10:00:36 +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> <55B8AFAA.1000802@tzi.org> In-Reply-To: <55B8AFAA.1000802@tzi.org> 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: <4F78013B96D54446AA8B5C34A6BA69B1@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3RvfYiWehBi+ni1gcmXKX1WLf2/XM DkweS5b8ZPKYtigzgCmKyyYlNSezLLVI3y6BK+PQnNnsBfNkKtYu129gPCDdxcjJISFgInFi zjEmCFtM4sK99WxdjFwcQgJHGSX2/ehlhHAWMUr8+3uTEaSKTcBF4kHDI7AOEQEliQsX17CB 2MwCEhJnVx5mBbGFBRwk7t7pYoOocZQ4MnESI4TtJjG9ZR0LiM0ioCIxsX0F2BxeAQuJ3d+3 M4PYQgLnmSQuvowDsTkF1CUarp0Aq2EEuu77qTVMELvEJW49mQ91tYDEkj3nmSFsUYmXj/+B 3SAqoCex8noTG0RcSaJxyROgOAdQr6bE+l36EGOsJZY/vcsOYStKTOl+yA5xjqDEyZlPWCYw SsxCsm0WQvcsJN2zkHTPQtK9gJF1FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgBB7c8lt1 B+PlN46HGAU4GJV4eBMmPAsVYk0sK67MPcQozcGiJM7bzPQgVEggPbEkNTs1tSC1KL6oNCe1 +BAjEwenVAOj7ZWNP2rN3ALWTGPnScrW+P16mrn8Ofe91+JjLAoPVybPKjx2hy2noip5hafV aWFNBW7DdIvYI5Z/D92a1yLYtVwzovbMCpfOTRmfb0ysa7t8252nID3TNfmr7VXhnNTHD41v cHtbrSmYlrcjqy4tWSz6uv3bolxLtb+i5QHvU60E7+1y41FiKc5INNRiLipOBADQNZdkoQIA AA== 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, 02 Sep 2015 10:00:42 -0000 SGkgQ2Fyc3RlbiwNCg0KQ29taW5nIGJhY2sgdG8gdGhpcyB0aHJlYWQsIHNvcnJ5IGZvciB0aGUg ZGVsYXkuDQoNCk9uIDIwMTUtMDctMjkgMTI6NDksICJDYXJzdGVuIEJvcm1hbm4iIDxjYWJvQHR6 aS5vcmc+IHdyb3RlOg0KDQo+PiBNYXliZSB0aGlzIGhhcyBhbHJlYWR5IGJlZW4gZGlzY3Vzc2Vk IGJ1dCBqdXN0IGZvciBjbGFyaWZpY2F0aW9uOiBEbyB3ZQ0KPj4gd2FudCB0byBzZWN1cmUgYmxv Y2t3aXNlIHRyYW5zZmVyIGVuZC10by1lbmQgb3Igc2hvdWxkIHdlIGxlYXZlIHRvIHRoZQ0KPj4g YXBwbGljYXRpb25zIG9mIENvQVA/IEV4YW1wbGUgb2YgdXNlIGNhc2UgbWVudGlvbmVkIGlzIGZp cm13YXJlIHVwZGF0ZS4NCj4NCj5UaGVyZSBhcmUgdHdvIHdheXMgdG8gZG8gdGhpczoNCj5TZWN1 cmUgZWFjaCBleGNoYW5nZSBvZiB0aGUgYmxvY2t3aXNlIHRyYW5zZmVyIG9yIHNlY3VyZSB0aGUg YmxvY2t3aXNlDQo+dHJhbnNmZXIgYXMgYSB3aG9sZS4gIFRoZSBmaXJzdCBvbmUgd2UgYWxtb3N0 IGdldCBmb3IgZnJlZSwgdW5sZXNzIHdlDQo+d2FudCB0byBzdXBwb3J0IHJlLWFycmFuZ2VtZW50 IG9mIGJsb2NrcyBpbiBhIHByb3h5ICh0aGVuIGl0IGdldHMNCj5oYWlyeSkuIA0KDQpUaGlzIGlz IHRoZSBzcHJpbmdpbmcgcG9pbnQsIGlzbuKAmXQgaXQ/DQoNCkluIG9yZGVyIGZvciB0aGUgcmVj ZWl2aW5nIGVuZHBvaW50IHRvIHZlcmlmeSB0aGUgaW50ZWdyaXR5IG9mIHRoZSBibG9jaw0KcmVj ZWl2ZWQsIHRoZSBzZW5kaW5nIGVuZHBvaW50IG11c3QgaGF2ZSBzaWduZWQgc29tZXRoaW5nIHRo YXQgY2FuIGJlDQpyZXByb2R1Y2VkIGJ5IHRoZSByZWNlaXZlci4gV2UgY2Fu4oCZdCBpbiBnZW5l cmFsIGFzc3VtZSBrZXlzIGVzdGFibGlzaGVkDQp3aXRoIHByb3hpZXMsIHNvIHRoZSBibG9jayBw YXJ0aXRpb25pbmcgbXVzdCBiZSBtYWRlIGJ5IHRoZSBzZW5kaW5nDQplbmRwb2ludCBhbmQgcmVz cGVjdGVkIGJ5IHRoZSBwcm94aWVzLg0KDQpFLmcuIGlmIHdlIGRlZmluZSBibG9jayBvcHRpb25z IGFsbW9zdCBhcyBpbiB0aGUgYmxvY2t3aXNlIGRyYWZ0IGFuZA0KYXNzdW1lIHRoZXkgYXJlIHNl dCBieSB0aGUgc2VuZGluZyBlbmRwb2ludCBhbmQgc2FmZS10by1mb3J3YXJkLCB0aGVuDQp1c2lu ZyBvYmplY3Qgc2VjdXJpdHkgbW9kZSBDT0FQIHdlIGdldCBib3RoIGludGVncml0eSBvZiB0aGUg aW5kaXZpZHVhbA0KYmxvY2tzIGFuZCBvZiB0aGUgZW50aXJlIHNlcXVlbmNlIG9mIGJsb2Nrcy4N Cg0KDQooVGhpcyBpcyBvbmUgaW50ZXJwcmV0YXRpb24gb2Yg4oCcYWxtb3N0IC4gLiAuIGZvciBm cmVl4oCdIGJ1dCBtYXliZSB5b3Ugd2VyZQ0KdGhpbmtpbmcgb2Ygc29tZXRoaW5nIGVsc2U/KQ0K DQpIYXZlIHlvdSBjb25zaWRlcmVkIGFueXRoaW5nIGxpa2UgdGhhdCBmb3IgdGhlIGJsb2Nrd2lz ZSBkcmFmdD8NCg0KDQo+IFRoZSBzZWNvbmQgb25lIGlzIGVhc3kgZm9yIHRoZSBwYXlsb2FkLW9u bHkgdmFyaWFudCAoUEFZTCkgdGhhdA0KPnlvdSBhcmUgcHJvcG9zaW5nLA0KDQpZZXMuDQoNCj5z bGlnaHRseSBsZXNzIGVhc3kgZm9yIHRoZSBtZXNzYWdlIHByb3RlY3Rpb24gKENPQVApOg0KPnRo ZSBsYXR0ZXIgd291bGQgbmVlZCBzb21lIHJ1bGVzIGFib3V0IHdoaWNoIG9wdGlvbnMgbmVlZCB0 byBjb2luY2lkZQ0KPmJldHdlZW4gdGhlIGJsb2NrcyB0byBtYWtlIHRoZSBlbnRpcmUgdHJhbnNm ZXIgdmFsaWQuDQoNCkkgZG9u4oCZdCBrbm93IGhvdyB0byBkbyB0aGlzLiBTZWUgYWx0ZXJuYXRp dmUgYWJvdmUuDQoNCj4NCj5JIGNhbiBpbWFnaW5lIHVzZSBjYXNlcyBmb3IgZWFjaCBvZiB0aGVz ZSB2YXJpYW50cy4gIEZvciBhIGZpcm13YXJlDQo+dHJhbnNmZXIgdGhhdCBoYXBwZW5zIG9uIGFu IHVucHJvdGVjdGVkIG5ldHdvcmsgdXNpbmcgTm9TZWMgbW9kZSwgeW91DQo+YWN0dWFsbHkgbWln aHQgd2FudCBib3RoIGF0IHRoZSBzYW1lIHRpbWUgKHByb3RlY3QgdGhlIGJsb2NrcyB0byBtYWtl DQo+ZGVuaWFsIG9mIHNlcnZpY2UgaGFyZGVyLCBwcm90ZWN0IHRoZSB3aG9sZSBiZWNhdXNlIHlv dSBtaWdodCB3YW50IHRvDQo+dXNlIGEgbW9yZSBleHBlbnNpdmUgb3BlcmF0aW9uIHRoZXJlKS4g IE9mIGNvdXJzZSwgdGhlIGZpcnN0IG1heSBiZSBkb25lDQo+YnkgRFRMUyAobm90IHVzaW5nIE5v U2VjIG1vZGUpLCBhbmQgdGhlIHNlY29uZCBtYXkgYmUgZG9uZSBieSBzb21lDQo+YXBwbGljYXRp b24tZGVmaW5lZCBtZWNoYW5pc20gc3BlY2lmaWNhbGx5IHByb3RlY3RpbmcgZmlybXdhcmUgdXBk YXRlcy4NCg0KWWVzIHRoZXJlIGFyZSBvdGhlciBhbHRlcm5hdGl2ZXMuIEhvd2V2ZXIsIEkgdGhp bmsgaXQgaXMgdmVyeSBuYXR1cmFsIHRvDQpvYmplY3Qgc2VjdXJlIGluZGl2aWR1YWwgYmxvY2tz IHJhdGhlciB0aGFuIHJlbHlpbmcgb24gb3RoZXIgc29sdXRpb25zIGlmDQp0aGUgc2l6ZSBvZiBt ZXNzYWdlIGV4Y2VlZHMgYSBjZXJ0YWluIHNpemUuIFVzaW5nICJlbmQtdG8tZW5kIiBibG9jaw0K b3B0aW9ucyBhbmQgbW9kZSBDT0FQIHdvdWxkIGdpdmUgeW91IGJvdGggaW5kaXZpZHVhbCBibG9j ayBhbmQgbWVzc2FnZQ0KcHJvdGVjdGlvbi4NCg0KUmVnYXJkcywNCkfDtnJhbg0KDQo+DQo+R3LD vMOfZSwgQ2Fyc3Rlbg0KDQo= From nobody Wed Sep 2 04:01: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 5A5601AD09C for ; Wed, 2 Sep 2015 04:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.5 X-Spam-Level: **** X-Spam-Status: No, score=4.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_SUMOF=1, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_54=0.6, 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 fS2_kp51KUAB for ; Wed, 2 Sep 2015 04:00:58 -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 E3E3E1ACEB4 for ; Wed, 2 Sep 2015 04:00:57 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id E5D2B44E19; Wed, 2 Sep 2015 13:00:53 +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 A015D23; Wed, 2 Sep 2015 13:00:50 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 77C77376; Wed, 2 Sep 2015 13:00:50 +0200 (CEST) Received: (nullmailer pid 21881 invoked by uid 1000); Wed, 02 Sep 2015 11:00:50 -0000 Date: Wed, 2 Sep 2015 13:00:50 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Ari =?iso-8859-1?Q?Ker=E4nen?= Message-ID: <20150902110049.GA4537@hephaistos.amsuess.com> References: <20150805185458.GC3989@hephaistos.amsuess.com> <55D4B29E.7040401@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZfOjI3PrQbgiZnxM" Content-Disposition: inline In-Reply-To: <55D4B29E.7040401@ericsson.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: core@ietf.org Subject: Re: [core] Status of SenML syntax 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, 02 Sep 2015 11:01:10 -0000 --ZfOjI3PrQbgiZnxM Content-Type: multipart/mixed; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Wed, Aug 19, 2015 at 07:45:18PM +0300, Ari Ker=E4nen wrote: > > [...] is using SenML for backup and replication purposes. >=20 > Interesting. I'd be inclined to say that perhaps SenML is not the right (= or > at least best) format then, but I'd be interested to hear more why you > decided to use SenML for this. It was mostly a "because it is there" decision (implementing that was mainly a matter of having an all-resources batch). We'll probably switch away from it for backups, but it seems the natural way to go for replication. > For sake of discussion (unless it's a typo or other very simple fix), I > think it's better if you propose new text here on the list. Currently the > XML at the SVN is the latest, but there was discussion that maybe we want= to > continue with github and/or markdown. No firm decisions yet on this. As the modifications in -cabo look good, I've decided to start that based on draft-jennings-core-senml-xx-cabo.mkd. While fleshing things out, I've stumbled across some points that might need further discussion: * The trivial example: {"e":[{ "n": "urn:dev:ow:10e2073a01080063", "v":23.5, "u":"Cel" }]} becomes [{}, [{"n": "urn:dev:ow:10e2073a01080063", "v": 23.5, "u": "Cel"}]] and while not being any longer, the data structure is not as trivially obvious as the old one. We could allow skipping empty dictionaries, which might make some forms of concatenation more straightforward, but introduces a type-based switch into the decoder. If no strong opinions are voiced, I'm inclined to leave the alternating dict-list pattern as it was discussed, and maybe just change the first example to use bn and thus be less confusing. * There is a section in the specification I don't fully understand: > Note that in some usage scenarios of SenML the > implementations MAY store or transmit SenML in a stream-like > fashion, where data is collected over time and continuously > added to the object. This mode of operation is optional, but > systems or protocols using SenML in this fashion MUST > specify that they are doing this. [...] Is this intended to apply to transports that technically allow stalling a transfer mid-stream, like HTTP with delays between segments? If so, this should be at least given as an example. In any case, we should add a way of specifying that this is done, because with the current text, different implementations of this are most likely not interoperable, making the whole section rather moot. =20 Attached, you'll find an overhauled version of the SenML draft, please review it and consider it for adoption into the next draft revision. If the development of the SenML specification document moves to a git-based workflow, I'll happily rebase my patches to be available as history; they can also come in handy if any of the changes I've applied so far are more controversial than I had anticipated. My changes in summary: * Changed JSON examples to [{}, []] syntax * Rephrased general semantics section (which was previously tightly coupled with the now obsolete syntax) * Changed JSON serialisation description to reflect new syntax * Updte CBOR serialisation description, numbers and CDDL * Removed strict requirements for consumption and production of floats (Every JSON numeric is permitted, and consumers are only reqired to understand as much as they need). I kindly ask for comments on the abovementioned open points and the new draft version in general. 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 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-jennings-core-senml-xx-amsuess.mkd" Content-Transfer-Encoding: quoted-printable --- stand_alone: true ipr: trust200902 docname: draft-jennings-core-senml-01 cat: std pi: toc: 'yes' symrefs: 'yes' iprnotified: 'yes' strict: 'yes' compact: 'yes' sortrefs: 'yes' colonspace: 'yes' rfcedstyle: 'no' tocdepth: '4' title: |- Media Types for Sensor Markup Language (SENML) abbrev: Sensor Markup area: ART author: - ins: C. Jennings name: Cullen Jennings org: Cisco street: 170 West Tasman Drive city: San Jose region: CA code: '95134' country: USA phone: "+1 408 421-9990" email: fluffy@cisco.com - ins: Z. Shelby name: Zach Shelby org: ARM street: 150 Rose Orchard city: San Jose code: '95134' country: FINLAND # Oh, really? phone: "+1-408-203-9434" email: zach.shelby@arm.com - ins: J. Arkko name: Jari Arkko org: Ericsson street: '' city: Jorvas code: '02420' country: Finland email: jari.arkko@piuha.net - ins: A. Keranen name: Ari Keranen org: Ericsson street: '' city: Jorvas code: '02420' country: Finland email: ari.keranen@ericsson.com normative: RFC5226:=20 BIPM: title: The International System of Units (SI) author: - org: |- Bureau International des Poids et Mesures date: 2006 seriesinfo: "8th": edition NIST811: title: Guide for the Use of the International System of Units (SI) author: - ins: A. Thompson - ins: B. Taylor date: 2008 seriesinfo: NIST: Special Publication 811 RFC3688:=20 W3C.REC-exi-20110310:=20 RFC7159:=20 RFC7303:=20 RFC6838:=20 RFC2119:=20 IEEE.754.1985:=20 UCUM: title: The Unified Code for Units of Measure (UCUM) author: - ins: G. Schadow - ins: C. McDonald date: 2013 target: http://unitsofmeasure.org/ucum.html seriesinfo: Regenstrief Institute and Indiana University School of: Informatics RFC7049:=20 RFC7386: informative: RFC2141:=20 RFC3986:=20 RFC7252:=20 RFC6690:=20 RFC5952:=20 RFC4122:=20 RFC0020:=20 I-D.arkko-core-dev-urn:=20 I-D.greevenbosch-appsawg-cbor-cddl: cddl WADL: target: http://java.net/projects/wadl/sources/svn/content/trunk/www/wad= l20090202.pdf title: Web Application Description Language (WADL) author: - ins: M. J. H. Hadley name: Marc J. Hadley org: Sun Microsystems Inc. date: 2009 --- 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. --- middle # Overview Connecting sensors to the internet is not new, and there have been many protocols designed to facilitate it. This specification defines new media types for carrying simple sensor information in a protocol such as HTTP or CoAP {{RFC7252}} called the Sensor Markup Language (SenML). This format was designed so that processors with very limited capabilities could easily encode a sensor measurement into the media type, while at the same time a server parsing the data could relatively efficiently collect a large number of sensor measurements. There are many types of more complex measurements and measurements that this media type would not be suitable for. A decision was made not to carry most of the meta data about the sensor in this media type to help reduce the size of the data and improve efficiency in decoding. Instead meta-data about a sensor resource can be described out-of-band using the CoRE Link Format {{RFC6690}}. The markup language can= be used for a variety of data flow models, most notably data feeds pushed =66rom a sensor to a collector, and the web resource model where the sensor is requested as a resource representation (GET /sensor/temperature). SenML is defined by a data model for measurements and simple meta-data about measurements and devices. The data is structured as a set of entries. Each entry is an object that has attributes such as a unique identifier for the sensor, the time the measurement was made, and the current value. Serializations for this data model are defined for JSON {{RFC7159}}, CBOR {{RFC7049}}, XML, and Efficient XML = Interchange (EXI) {{W3C.REC-exi-20110310}}. For example, the following shows a measurement from a temperature gauge encoded in the JSON syntax. ~~~~ [{}, [{"n": "urn:dev:ow:10e2073a01080063", "v": 23.5, "u": "Cel"}]] ~~~~ In the example above, the set contains a single measurement for a sensor named "urn:dev:ow:10e2073a01080063" with a temperature of 23.5 degrees Celsius. # Requirements and Design Goals The design goal is to be able to send simple sensor measurements in small packets on mesh networks from large numbers of constrained devices. Keeping the total size of payload under 80 bytes makes this easy to use on a wireless mesh network. It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on a 8 bit microprocessor. Experience with Google power meter and large scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request. This "batch" upload capability allows the server side to efficiently support a large number of devices. It also conveniently supports batch transfers =66rom proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time. The multiple measurements could be from multiple related sensors or =66rom the same sensor but at different times. # Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIO= NAL" in this document are to be interpreted as described in {{RFC2119}}. # Semantics {#semant} Each representation carries a serialisation of a single SenML set of measurements and/or parameters. The serialisations have a number of optional attributes valid for all entries (root attributes) and a mandatory= set of entries. ## Root attributes Base Name : This is a string that is prepended to the names found in the entries. This attribute is optional. Base Time : A base time that is added to the time found in an entry. This attribute is optional. Base Units : A base unit that is assumed for all entries, unless otherwise indicated. This attribute is optional. Version : Version number of media type format. This attribute is optional positive integer and defaults to 1 if not present. ## Entry attributes Each SenML entry contains several attributes, some of which are optional and some of which are mandatory. Name : Name of the sensor or parameter. When appended to the Base Name attribute, this must result in a globally unique identifier for the resource. The name is optional, if the Base Name is present. If the name is missing, Base Name must uniquely identify the resource. This can be used to represent a large series of measurements from the same sensor without having to repeat its identifier on every measurement. Units : Units for a measurement value. Value : Value of the entry. Optional if a Sum value is present, otherwise required. Values are represented using three basic data types, Floating point numbers ("v" field for "Value"), Booleans ("bv" for "Boolean Value") and Strings ("sv" for "String Value"). Exactly one of these three fields MUST appear. Sum : Integrated sum of the values over time. Optional. This attribute is in the units specified in the Unit value multiplied by seconds. Time : Time when value was recorded. Optional. Update Time : A time in seconds that represents the maximum time before this sensor will provide an updated reading for a measurement. This can be used to detect the failure of sensors or communications path from the sensor. Optional. {: vspace=3D'1'} The SenML format can be extended with further custom root or entry attribut= es. Root attribute extensions pertain to all entries, whereas extensions in an entry only pertain to that. ## Attribute interpretation Systems reading SenML MUST check for the Version attribute. If this value is a version number larger than the version which the system understands, the system SHOULD NOT use this object. This allows the version number to indicate that the object contains mandatory to understand attributes. New version numbers can only be defined in an RFC that updates this specification or it successors. The Name value is concatenated to the Base Name value to get the name of the sensor. The resulting name needs to uniquely identify and differentiate the sensor from all others. If the object is a representation resulting from the request of a URI {{RFC3986}}, then in the= absence of the Base Name attribute, this URI is used as the default value of Base Name. Thus in this case the Name field needs to be unique for that URI, for example an index or subresource name of sensors handled by the URI. Alternatively, for objects not related to a URI, a unique name is required. In any case, it is RECOMMENDED that the full names are represented as URIs or URNs {{RFC2141}}. One way to create a unique name is to include a EUI-48 or EUI-64 identifier (A MAC address) or some other bit string that is guaranteed uniqueness (such as a 1-wire address) that is assigned to the device. Some of the examples in this draft use the device URN type as specified in {{I-D.arkko-core-dev-= urn}}. UUIDs {{RFC4122}} are another way to generate a unique name. The resulting concatenated name MUST consist only of characters out of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_" and it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9". This restricted character set was chosen so that these names can be directly used as in other types of URI including segments of an HTTP path with no special encoding. {{RFC5952}} contains advice on encoding= an IPv6 address in a name. If either the Base Time or Time value is missing, the missing attribute is considered to have a value of zero. The Base Time and Time values are added together to get the time of measurement. A time of zero indicates that the sensor does not know the absolute time and the measurement was made roughly "now". A negative value is used to indicate seconds in the past from roughly "now". A positive value is used to indicate the number of seconds, excluding leap seconds, since the start of the year 1970 in UTC. Representing the statistical characteristics of measurements can be very complex. Future specification may add new attributes to provide better information about the statistical properties of the measurement. # Associating Meta-data SenML is designed to carry the minimum dynamic information about measurements, and for efficiency reasons does not carry more static meta-data about the device, object or sensors. Instead, it is assumed that this meta-data is carried out of band. For web resources using SenML representations, this meta-data can be made available using the CoRE Link Format {{RFC6690}}. The CoRE Link Format provides a simple way to describe Web Links, and in particular allows a web server to describe resources it is hosting. The list of links that a web server has available, can be discovered by retrieving the /.well-known/core resource, which returns the list of links in the CoRE Link Format. Each link may contain attributes, for example title, resource type, interface description and content-type. The most obvious use of this link format is to describe that a resource is available in a SenML format in the first place. The relevant media type indicator is included in the Content-Type (ct=3D) attribute. Further semantics about a resource can be included in the Resource Type and Interface Description attributes. The Resource Type (rt=3D) attribute is meant to give a semantic meaning to that resource. For example rt=3D"outdoor-temperature" would indicate static semantic meaning in addition to the unit information included in SenML. The Interface Description (if=3D) attribute is used to describe the REST interface of a resource, and may include e.g. a reference to a WADL description {{WADL}}. # JSON Representation (application/senml+json) A JSON representation of SenML is the JSON text serialization of a JSON arr= ay as specified by {{RFC7159}}. The array MUST have even length and contain, in alternation, root objects and entry arrays, starting with a root object. All of the data is UTF-8, but since this is for machine to machine communications on constrained systems, only characters with code points between U+0001 and U+007F are allowed which corresponds to the ASCII {{RFC0020}} subset of UTF-8. A root object is a JSON object that represents root attributes as object members according to the following table. All members are OPTIONAL, but, if present, MUST be of the indicated value type. The object MAY contain other members to represent root attribute extensions. | SenML | Member | Value | | Base Name | bn | String | | Base Time | bt | Number | | Base Units | bu | Number | | Version | ver | Number | {:cols=3D'r l l'} The root attributes defined there are valid for all entries in the following array. Subsequent root objects are merged into the preceding root elements using the JSON merge patch mechanisms of {{RFC7386}}. As none of the defined root attributes allow the JSON value `null`, implementations MAY initialize their state from an empty root object and tr= eat even the first root object as a JSON merge patch. An entry array is a JSON array of JSON objects representing entries. The en= try attributes are represented as object members according to the following tab= le. All members are OPTIONAL, but, if present, MUST be of the indicated type. At least one of the "v", "sv", "bv" and "s" members MUST be present, there MUST NOT be more than one of the "v", "sv" and "bv" members. The object MAY contain other members to represent entry attribute extension= s. Measurement or Parameter Entries: | SenML | Member | Value | | Name | n | String | | Units | u | String | | Value | v | Floating point | | String Value | sv | String | | Boolean Value | bv | Boolean | | Value Sum | s | Floating point | | Time | t | Number | | Update Time | ut | Number | {:cols=3D'r l l'} Systems receiving measurements MUST understand all numeric types permitted = in JSON to the precision they are using them, and SHOULD be able to recognize = and indicate overflows. The number of significant digits in any measurement is not relevant, so a reading of 1.1 has exactly the same semantic meaning as 1.10, and 2000 is equivalent to 2e4. In systems producing SenML, the mantissa SHOULD be less than 19 characters long and the exponent SHOULD be less than 5 characters long. This allows time values to have better than micro second precision over the next 100 years. ## Examples ### Single Datapoint The following shows a temperature reading taken approximately "now" by a 1-wire sensor device that was assigned the unique 1-wire address of 10e2073a01080063: ~~~~ [{}, [{"n": "urn:dev:ow:10e2073a01080063", "v": 23.5}]] ~~~~ ### Multiple Datapoints {#co-ex} The following example shows voltage and current now, i.e., at an unspecified time. The device has an EUI-64 MAC address of 0024befffe804ff1. ~~~~ [ {"bn": "urn:dev:mac:0024befffe804ff1/"}, [ {"n": "voltage", "t": 0, "u": "V", "v": 120.1}, {"n": "current", "t": 0, "u": "A", "v": 1.2} ] ] ~~~~ The next example is similar to the above one, but shows current at Tue Jun 8 18:01:16 UTC 2010 and at each second for the previous 5 seconds. ~~~~ [ { "bn": "urn:dev:mac:0024befffe804ff1/", "bt": 1276020076, "bu": "A", "ver": 1 } [ {"n": "voltage", "u": "V", "v": 120.1}, ], {"bn": "urn:dev:mac:0024befffe804ff1/current"}, [ {"t": -5, "v": 1.2}, {"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} ] ] ~~~~ Note that in some usage scenarios of SenML the implementations MAY store or transmit SenML in a stream-like fashion, where data is collected over time and continuously added to the object. This mode of operation is optional, but systems or protocols using SenML in this fashion MUST specify that they are doing this. In this situation the SenML stream can be sent and received in a partial fashion, i.e., a measurement entry can be read as soon as it is received and only not when the entire SenML object is complete. For instance, the following stream of measurements may be sent from the producer of a SenML object to the consumer of that SenML object, and each measurement object may be reported at the time it arrives: ~~~~ [ { "bn": "http://[2001:db8::1]", "bt": 1320067464, "bu": "%RH" }, [ {"v": 21.2, "t": 0}, {"v": 21.3, "t": 10}, {"v": 21.4, "t": 20}, {"v": 21.4, "t": 30}, {"v": 21.5, "t": 40}, {"v": 21.5, "t": 50}, {"v": 21.5, "t": 60}, {"v": 21.6, "t": 70}, {"v": 21.7, "t": 80}, {"v": 21.5, "t": 90} =2E.. ~~~~ ### Multiple Measurements {#an-co-ex} The following example shows humidity measurements from a mobile device with an IPv6 address 2001:db8::1, starting at Mon Oct 31 13:24:24 UTC 2011. The device also provides position data, which is provided in the same measurement or parameter array as separate entries. Note time is used to for correlating data that belongs together, e.g., a measurement and a parameter associated with it. Finally, the device also reports extra data about its battery status at a separate time. ~~~~ [ { "bn": "http://[2001:db8::1]", "bt": 1320067464, "bu": "%RH" }, [ {"v": 20.0, "t": 0}, {"sv": "E 24' 30.621", "u": "lon", "t": 0}, {"sv": "N 60' 7.965", "u": "lat", "t": 0}, {"v": 20.3, "t": 60 }, {"sv": "E 24' 30.622", "u": "lon", "t": 60}, {"sv": "N 60' 7.965", "u": "lat", "t": 60}, {"v": 20.7, "t": 120 }, {"sv": "E 24' 30.623", "u": "lon", "t": 120}, {"sv": "N 60' 7.966", "u": "lat", "t": 120}, {"v": 98.0, "u": "%EL", "t": 150}, {"v": 21.2, "t": 180}, {"sv": "E 24' 30.628", "u": "lon", "t": 180}, {"sv": "N 60' 7.967", "u": "lat", "t": 180} ] } ~~~~ ### Collection of Resources {#rest-ex} The following example shows how to query one device that can provide multiple measurements. The example assumes that a client has fetched information from a device at 2001:db8::2 by performing a GET operation on http://[2001:db8::2] at Mon Oct 31 16:27:09 UTC 2011, and has gotten two separate values as a result, a temperature and humidity measurement. ~~~~ [ { "bn": "http://[2001:db8::2]/", "bt": 1320078429, "ver": 1 }, [ {"n": "temperature", "v": 27.2, "u": "Cel"}, {"n": "humidity", "v": 80, "u": "%RH"} ] ] ~~~~ # CBOR Representation (application/senml+cbor) {#sec-cbor} The CBOR {{RFC7049}} representation is equivalent to the JSON representation, with the following changes: * For compactness, the CBOR representation uses integers for the map keys defined in {{tbl-cbor-labels}}. This table is conclusive, i.e., there is no intention to define any additional integer map keys; any extensions will use string map keys. * For JSON Numbers, the CBOR representation can use integers, floating point numbers, or decimal fractions (CBOR Tag 4); the common limitations of JSON implementations are not relevant for these. For the version number, however, only an unsigned integer is allowed. | Name | JSON label | CBOR label | | Version | ver | -1 | | Base Name | bn | -2 | | Base Time | bt | -3 | | Base Units | bu | -4 | | Name | n | 0 | | Units | u | 1 | | Value | v | 2 | | String Value | sv | 3 | | Boolean Value | bv | 4 | | Value Sum | s | 5 | | Time | t | 6 | | Update Time | ut | 7 | {: #tbl-cbor-labels cols=3D"r l r" title=3D"CBOR representation: integers f= or map keys"} For reference, the CBOR representation can be described with the CDDL {{-cddl}} specification in {{senmlcddl}}. ~~~~ CDDL SenML =3D [+ pair] pair =3D ( root: rootobject, entries: [* meas], ) rootobject =3D { ? bn =3D> tstr, ; Base Name ? bt =3D> numeric, ; Base Time ? bu =3D> tstr, ; Base Units ? ver =3D> uint, ; Version * tstr =3D> any, ; (Extension) } meas =3D { ? n =3D> tstr, ; Name ? u =3D> tstr, ; Units ? ( v =3D> numeric // ; Numeric Value sv =3D> tstr // ; String Value bv =3D> bool ) ; Boolean Value ? s =3D> numeric, ; Value Sum ? t =3D> numeric, ; Time ? ut =3D> numeric, ; Update Time } numeric =3D number / decfrac ver =3D -1 v =3D 2 bn =3D -2 sv =3D 3 bt =3D -3 bv =3D 4 bu =3D -4 s =3D 5 n =3D 0 t =3D 6 u =3D 1 ut =3D 7 ~~~~ {: #senmlcddl title=3D"CDDL specification for CBOR SenML"} # XML Representation (application/senml+xml) {#sec-xml-examle} A SenML object can also be represented in XML format as defined in this section. The following example shows an XML example for the same sensor measurement as in {{co-ex}}. ~~~~ ~~~~ The RelaxNG schema for the XML is: ~~~~ default namespace =3D "urn:ietf:params:xml:ns:senml" namespace rng =3D "http://relaxng.org/ns/structure/1.0" e =3D element e { attribute n { xsd:string }?, attribute u { xsd:string }?, attribute v { xsd:float }?, attribute sv { xsd:string }?, attribute bv { xsd:boolean }?, attribute s { xsd:decimal }?, attribute t { xsd:int }?, attribute ut { xsd:int }?, p* } senml =3D element senml { attribute bn { xsd:string }?, attribute bt { xsd:int }?, attribute bu { xsd:string }?, attribute ver { xsd:int }?, e* } start =3D senml ~~~~ # EXI Representation (application/senml-exi) For efficient transmission of SenML over e.g. a constrained network, Efficient XML Interchange (EXI) can be used. This encodes the XML Schema structure of SenML into binary tags and values rather than ASCII text. An EXI representation of SenML SHOULD be made using the strict schema-mode of EXI. This mode however does not allow tag extensions to the schema, and therefore any extensions will be lost in the encoding. For uses where extensions need to be preserved in EXI, the non-strict schema mode of EXI MAY be used. The EXI header option MUST be included. An EXI schemaID options MUST be set to the value of "a" indicating the scheme provided in this specification. Future revisions to the schema can change this schemaID to allow for backwards compatibility. When the data will be transported over CoAP or HTTP, an EXI Cookie SHOULD NOT be used as it simply makes things larger and is redundant to information provided in the Content-Type header. The following XSD Schema is generated from the RelaxNG and used for strict schema guided EXI processing. ~~~~ ~~~~ The following shows a hexdump of the EXI produced from encoding the following XML example. Note that while this example is similar to the first example in {{co-ex}} in JSON format. ~~~~ ~~~~ Which compresses to the following displayed in hexdump: ~~~~ 00000000 a0 30 0d 85 01 d7 57 26 e3 a6 46 57 63 a6 f7 73 00000010 a3 13 06 53 23 03 73 36 13 03 13 03 83 03 03 63 00000020 36 21 2e cd ed 8e 8c 2c ec a8 00 00 d5 95 88 4c 00000030 02 08 4b 1b ab 93 93 2b 73 a2 00 00 34 14 19 00 00000040 c0 ~~~~ The above example used the bit packed form of EXI but it is also possible to use a byte packed form of EXI which can makes it easier for a simple sensor to produce valid EXI without really implementing EXI. Consider the example of a temperature sensor that produces a value in tenths of degrees Celsius over a range of 0.0 to 55.0. It would produce an XML SenML file such as: ~~~~ ~~~~ The compressed form, using the byte alignment option of EXI, for the above XML is the following: ~~~~ 00000000 a00048806c200200 1d75726e3a646576 |..H.l ...urn:dev| 00000010 3a6f773a31306532 3037336130313038 |:ow:10e2073a0108| 00000020 3030363303010674 656d700306646567 |0063...temp..deg| 00000030 430100e701010001 02 |C........| ~~~~ A small temperature sensor devices that only generates this one EXI file does not really need an full EXI implementation. It can simple hard code the output replacing the one wire device ID starting at byte 0x14 and going to byte 0x23 with it's device ID, and replacing the value "0xe7 0x01" at location 0x33 to 0x34 with the current temperature. The EXI Specification {{W3C.REC-exi-20110310}} contains the full information on how floating point numbers are represented, but for the purpose of this sensor, the temperature can be converted to an integer in tenths of degrees (231 in this example). EXI stores 7 bits of the integer in each byte with the top bit set to one if there are further bytes. So the first bytes at location 0x33 is set to low 7 bits of the integer temperature in tenths of degrees plus 0x80. In this example 231 & 0x7F + 0x80 =3D 0xE7. The second byte at location 0x34 is set to the integer temperature in tenths of degrees right shifted 7 bits. In this example 231 >> 7 =3D 0x01. # Usage Considerations The measurements support sending both the current value of a sensor as well as the an integrated sum. For many types of measurements, the sum is more useful than the current value. For example, an electrical meter that measures the energy a given computer uses will typically want to measure the cumulative amount of energy used. This is less prone to error than reporting the power each second and trying to have something on the server side sum together all the power measurements. If the network between the sensor and the meter goes down over some period of time, when it comes back up, the cumulative sum helps reflect what happened while the network was down. A meter like this would typically report a measurement with the units set to watts, but it would put the sum of energy used in the "s" attribute of the measurement. It might optionally include the current power in the "v" attribute. While the benefit of using the integrated sum is fairly clear for measurements like power and energy, it is less obvious for something like temperature. Reporting the sum of the temperature makes it easy to compute averages even when the individual temperature values are not reported frequently enough to compute accurate averages. Implementors are encouraged to report the cumulative sum as well as the raw value of a given sensor. Applications that use the cumulative sum values need to understand they are very loosely defined by this specification, and depending on the particular sensor implementation may behave in unexpected ways. Applications should be able to deal with the following issues: 1. Many sensors will allow the cumulative sums to "wrap" back to zero after the value gets sufficiently large. 1. Some sensors will reset the cumulative sum back to zero when the device is reset, loses power, or is replaced with a different sensor. 1. Applications cannot make assumptions about when the device started accumulating values into the sum. Typically applications can make some assumptions about specific sensors that will allow them to deal with these problems. A common assumption is that for sensors whose measurement values are always positive, the sum should never get smaller; so if the sum does get smaller, the application will know that one of the situations listed above has happened. # IANA Considerations Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with the RFC number of this specification. ## Units Registry {#sec-units} IANA will create a registry of unit symbols. The primary purpose of this registry is to make sure that symbols uniquely map to give type of measurement. Definitions for many of these units can be found in {{NIST8= 11}} and {{BIPM}}. In addition to the units in this table, any of the Unified Code for Units of Measure {{UCUM}} in case sensitive form (c/s column) can be prepended by the string "UCUM:" and used in SenML. | Symbol | Description | Reference | | m | meter | RFC-AAAA | | kg | kilogram | RFC-AAAA | | s | second | RFC-AAAA | | A | ampere | RFC-AAAA | | K | kelvin | RFC-AAAA | | cd | candela | RFC-AAAA | | mol | mole | RFC-AAAA | | Hz | hertz | RFC-AAAA | | rad | radian | RFC-AAAA | | sr | steradian | RFC-AAAA | | N | newton | RFC-AAAA | | Pa | pascal | RFC-AAAA | | J | joule | RFC-AAAA | | W | watt | RFC-AAAA | | C | coulomb | RFC-AAAA | | V | volt | RFC-AAAA | | F | farad | RFC-AAAA | | Ohm | ohm | RFC-AAAA | | S | siemens | RFC-AAAA | | Wb | weber | RFC-AAAA | | T | tesla | RFC-AAAA | | H | henry | RFC-AAAA | | Cel | degrees Celsius | RFC-AAAA | | lm | lumen | RFC-AAAA | | lx | lux | RFC-AAAA | | Bq | becquerel | RFC-AAAA | | Gy | gray | RFC-AAAA | | Sv | sievert | RFC-AAAA | | kat | katal | RFC-AAAA | | pH | pH acidity | RFC-AAAA | | % | Value of a switch (note 1) | RFC-AAAA | | count | counter value | RFC-AAAA | | %RH | Relative Humidity | RFC-AAAA | | m2 | area | RFC-AAAA | | l | volume in liters | RFC-AAAA | | m/s | velocity | RFC-AAAA | | m/s2 | acceleration | RFC-AAAA | | l/s | flow rate in liters per second | RFC-AAAA | | W/m2 | irradiance | RFC-AAAA | | cd/m2 | luminance | RFC-AAAA | | Bspl | bel sound pressure level | RFC-AAAA | | bit/s | bits per second | RFC-AAAA | | lat | degrees latitude (note 2) | RFC-AAAA | | lon | degrees longitude (note 2) | RFC-AAAA | | %EL | remaining battery energy level in percents | RFC-AAAA | | EL | remaining battery energy level in seconds | RFC-AAAA | | beat/m | Heart rate in beats per minute | RFC-AAAA | | beats | Cumulative number of heart beats | RFC-AAAA | {:cols=3D'r l l'} * Note 1: A value of 0.0 indicates the switch is off while 100.0 indicates on. * Note 2: Assumed to be in WGS84 unless another reference frame is known for the sensor. New entries can be added to the registration by either Expert Review or IESG Approval as defined in {{RFC5226}}. Experts should exercise their own good judgment but need to consider the following guidelines: 1. There needs to be a real and compelling use for any new unit to be added. 1. Units should define the semantic information and be chosen carefully. Implementors need to remember that the same word may be used in different real-life contexts. For example, degrees when measuring latitude have no semantic relation to degrees when measuring temperature; thus two different units are needed. 1. These measurements are produced by computers for consumption by computers. The principle is that conversion has to be easily be done when both reading and writing the media type. The value of a single canonical representation outweighs the convenience of easy human representations or loss of precision in a conversion. 1. Use of SI prefixes such as "k" before the unit is not allowed. Instead one can represent the value using scientific notation such a 1.2e3. 1. For a given type of measurement, there will only be one unit type defined. So for length, meters are defined and other lengths such as mile, foot, light year are not allowed. For most cases, the SI unit is preferred. 1. Symbol names that could be easily confused with existing common units or units combined with prefixes should be avoided. For example, selecting a unit name of "mph" to indicate something that had nothing to do with velocity would be a bad choice, as "mph" is commonly used to mean miles per hour. 1. The following should not be used because the are common SI prefixes: Y, Z, E, P, T, G, M, k, h, da, d, c, n, u, p, f, a, z, y, Ki, Mi, Gi, Ti, Pi, Ei, Zi, Yi. 1. The following units should not be used as they are commonly used to represent other measurements Ky, Gal, dyn, etg, P, St, Mx, G, Oe, Gb, sb, Lmb, ph, Ci, R, RAD, REM, gal, bbl, qt, degF, Cal, BTU, HP, pH, B/s, psi, Torr, atm, at, bar, kWh. 1. The unit names are case sensitive and the correct case needs to be used, but symbols that differ only in case should not be allocated. 1. A number after a unit typically indicates the previous unit raised to that power, and the / indicates that the units that follow are the reciprocal. A unit should have only one / in the name. ## Media Type Registration {#sec-iana-media} The following registrations are done following the procedure specified in {{RFC6838}} and {{RFC7303}}. Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with the RFC number of this specification. ### senml+json Media Type Registration Type name: application Subtype name: senml+json Required parameters: none Optional parameters: none Encoding considerations: Must be encoded as using a subset of the encoding allowed in {{RFC7159}}. Specifically, only the ASCII {{RFC0020}} subset of the UTF-8 characters are allowed. This simplifies implementation of very simple system and does not impose any significant limitations as all this data is meant for machine to machine communications and is not meant to be human readable. Security considerations: Sensor data can contain a wide range of information ranging from information that is very public, such the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information. This format does not provide any security and instead relies on the transport protocol that carries it to provide security. Given applications need to look at the overall context of how this media type will be used to decide if the security is adequate. Interoperability considerations: Applications should ignore any JSON key value pairs that they do not understand. This allows backwards compatibility extensions to this specification. The "ver" field can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the JSON object. Published specification: RFC-AAAA Applications that use this media type: The type is used by systems that report electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems. Additional information: Magic number(s): none File extension(s): senml Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings \ Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings \ Change controller: IESG ### senml+cbor Media Type Registration Type name: application Subtype name: senml+cbor Required parameters: none Optional parameters: none Encoding considerations: TBD Security considerations: TBD Interoperability considerations: TBD Published specification: RFC-AAAA Applications that use this media type: The type is used by systems that report electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems. Additional information: Magic number(s): none File extension(s): senml Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings \ Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings \ Change controller: IESG ### senml+xml Media Type Registration Type name: application Subtype name: senml+xml Required parameters: none Optional parameters: none Encoding considerations: TBD Security considerations: TBD Interoperability considerations: TBD Published specification: RFC-AAAA Applications that use this media type: TBD Additional information: Magic number(s): none File extension(s): senml Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings \ Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings \ Change controller: IESG ### senml-exi Media Type Registration Type name: application Subtype name: senml-exi Required parameters: none Optional parameters: none Encoding considerations: TBD Security considerations: TBD Interoperability considerations: TBD Published specification: RFC-AAAA Applications that use this media type: TBD Additional information: Magic number(s): none File extension(s): senml Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings \ Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings \ Change controller: IESG ## XML Namespace Registration {#sec-iana-url} This document registers the following XML namespaces in the IETF XML registry defined in {{RFC3688}}. URI: urn:ietf:params:xml:ns:senml Registrant Contact: The IESG. XML: N/A, the requested URIs are XML namespaces # Security Considerations {#sec-sec} See {{sec-privacy}}. Further discussion of security properties can be found in {{sec-iana-media}}. # Privacy Considerations {#sec-privacy} Sensor data can range from information with almost no security considerations, such as the current temperature in a given city, to highly sensitive medical or location data. This specification provides no security protection for the data but is meant to be used inside another container or transport protocol such as S/MIME or HTTP with TLS that can provide integrity, confidentiality, and authentication information about the source of the data. # Acknowledgement We would like to thank Lisa Dusseault, Joe Hildebrand, Lyndsay Campbell, Martin Thomson, John Klensin, Bjoern Hoehrmann, and Carsten Bormann for their review comments. The CBOR Representation text was contributed by Carsten Bormann. --- back --EeQfGwPcQSOJBaQU-- --ZfOjI3PrQbgiZnxM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJV5tbeAAoJEDmNERLTpL3hpUcQAK33WUm51FJKRRexcIkA1E3c pM2ncsRHOyZgvgJiEQLh1K/DSU4K6WhuJU4gEhrBOZwkg9ywxl8j8yxW/UTeFk0b xkhC/LO0ZII7Rd/iPZbY0nzOAN4eM3a+nNlZzhOxRxqzl9Vj6fLA+sIcPuryORWJ I8FJJTEDxp3sKmzNAfndI59Vi/9kxSp5kX2dhnmvvxh8/o8xlQ5cCsn7XXPSE73j OZI/lWwQ3WatpQjfTzIKLljhEDNszghfpbsxp6GmIodf59luasbtgdsaN17QzyJ2 GBUC1+eFT0R8NmnjLUcEE6Vrk5DUpV+Vb9CQrCbsh56Hbw0O7YEVzPhxKokgrGCr w1bF06Xvm94ALRG6Q11ikB8M3Bkgqi5eUZTnC/FWNF00NyI88jYUnofH5ecCsO9f pzHRWpDjJt2Df6pYEHulzKwyN+WH4vJ0FXh0tEN37wQ2tIIWDGNtDvCtLINq8Shx 7yLnfadJ1RVBCV+RT+hZ73iO5cu5kBD2o/CkK5MHAmPZSAOCAcJkSLZHKOpyTMsb 4od2aMTd5kjwFp3bl3ovEgzCC5ESGkwvQPLHEhNeKc7fyAdyMv2T/+h6hrXG0cns HCxI3AK6H9e8UZTXG94sbnl/AIV9pmH5TdtJu2cLdxvMXK6eMIi91UgfB2G+tEiX hKrLomGhRu7WT7Ts6l8d =8osp -----END PGP SIGNATURE----- --ZfOjI3PrQbgiZnxM-- From nobody Wed Sep 2 11:49:30 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 8D9AD1B2EE7 for ; Wed, 2 Sep 2015 11:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-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 6tgFHqEl_VzT for ; Wed, 2 Sep 2015 11:49:27 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659671B2C60 for ; Wed, 2 Sep 2015 11:49:25 -0700 (PDT) Received: from DB4PR06CA0083.eurprd06.prod.outlook.com (10.162.49.51) by DBXPR06MB285.eurprd06.prod.outlook.com (10.141.11.16) with Microsoft SMTP Server (TLS) id 15.1.256.15; Wed, 2 Sep 2015 18:49:05 +0000 Received: from AM1FFO11FD039.protection.gbl (2a01:111:f400:7e00::165) by DB4PR06CA0083.outlook.office365.com (2a01:111:e400:9866::51) with Microsoft SMTP Server (TLS) id 15.1.256.15 via Frontend Transport; Wed, 2 Sep 2015 18:49:05 +0000 Authentication-Results: spf=fail (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=tridonic.com; Received-SPF: Fail (protection.outlook.com: domain of tridonic.com does not designate 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATBRAGMSX02.itiso.net; Received: from ATBRAGMSX02.itiso.net (146.108.200.10) by AM1FFO11FD039.mail.protection.outlook.com (10.174.64.228) with Microsoft SMTP Server (TLS) id 15.1.262.18 via Frontend Transport; Wed, 2 Sep 2015 18:49:04 +0000 Received: from ATDOAGMSX02.itiso.net ([169.254.4.181]) by ATBRAGMSX02.itiso.net ([169.254.2.97]) with mapi id 14.03.0224.002; Wed, 2 Sep 2015 20:49:04 +0200 From: Somaraju Abhinav To: =?windows-1256?Q?Core_=FD=5Bcore=40ietf=2Eorg=5D=FD?= Thread-Topic: [core] Is hashing mandatory in CoMI? Thread-Index: AdDlr17vegMovSUlTn+0GMd1TibeNA== Date: Wed, 2 Sep 2015 18:49:03 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0866F4@ATDOAGMSX02.itiso.net> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.8.124] Content-Type: multipart/alternative; boundary="_000_0E9A48AB39AF3547ACD28A6DE3E2906A0866F4ATDOAGMSX02itison_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD039; 1:p+0RIn52Oyu1ckwR7VB7Bi4X6McZWPuXmvNjR4FvoKZwNXGTOKlLfmkdUd4Rj9oibcGR/2pmktywrT9QYn8GvoU8niURxNR7f9T+wz8cJMo3ZLMzHYi7hgro6JbYtPwGqtOdcZNVZ7teBAEacCcxX6giuGF9Pxsw6NiM2aU9AWvYhwW3GlJoAl5gz67qrChU/5d7htOn5TLAlQnECiYfWGhOvkGh9m0HKobi9OWH7qgAWk8afxhUPQbCapBH+L0sdCMr8LTGCvfNyF9TQsjsir/7PKziA4ShSJwjo+0mjhnEsHCJ5XAcQ8NCpDRHfRm5U7dHKCldvuy2dZW08v9WtQTb5kI+r1y3oUk15G3vEZn0TSalCccVdgmnIeaKS3uF X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(1109001)(3050300001)(339900001)(164054003)(189002)(199003)(5003600100002)(5001860100001)(104016003)(5001830100001)(2900100001)(2930100002)(86362001)(69596002)(77156002)(6806004)(5001960100002)(5007970100001)(2920100001)(87936001)(107886002)(110136002)(189998001)(84326002)(85426001)(5890100001)(5004730100002)(62966003)(26826002)(102836002)(229853001)(450100001)(106466001)(54356999)(50986999)(92566002)(33656002)(46102003)(53416004)(4001540100001)(66066001)(64706001)(81156007)(105606002)(16236675004)(55846006); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR06MB285; H:ATBRAGMSX02.itiso.net; FPR:; SPF:Fail; PTR:unknown.zgrp.net; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DBXPR06MB285; 2:2KcT6dj/SK7c2ZVK5pqo8VOF9Q5JHYdt56QyZg6WJr/m+Cx4r3Hn5ygaMwPmP6dWKwYs1ceNJiyYwwONK4OuIog68+FDFK8Exe6gNcUD3i/8yccxeigW40M6XrjAwf+6b7t2IeBEYMWr+q1znldLswJ7gX79PTy0wGDqgO13i58=; 3:5tKxAZsZfZ8t9Rz+ZRoKx+qzAEXsa2+TtUiYoPShRsR84tL0x2tOFzljOJmsy2rN5D7UkEsbbciI23ds068u/DTT8j9Xyr2zNsdM3h5fzxLfyulqSJhQcqpSIt8iikipxRwWddnxNum+DmCpYJyuM9BQ4kv/h2R+BpxsLat2Qum0Yd4FJ0Pw6adbj91C4zhCRM46iA7cAbZq+m254ucn7uSjfJ3AtS57tJRQKUZCLrJzApsqSJFVmW9FV1h0oIkK; 25:vQKuzAqS3YIGsUTS5XxQWu6GKAGWZsr0RBmUPQJI8Mlah3tx6MdQ/UhNhmM5klhSL7LVithtr+W3OWCTmC2Nz/C7u/mEFIWNHe4EePCJThQIuQGf143jxqaKHk/LGxfQioxlMuD9QReBzSiqxAhr7hK+P/0VLwiDbxUqLgkMZWFAteXhJt1/VPUrB5i7SA5vyhQMA7FrprMcZfG+nyQvUCCIVr7lSw6eG1pT2/2kiM0IE3/nudb8/sjUAr9ZJn1DRGDMwiOuRrCJokbZ40IrCA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR06MB285; X-Microsoft-Exchange-Diagnostics: 1; DBXPR06MB285; 20:mmnJIPvXUkYfh1Cu5MpastII0C6TyFGtJ0FSmTwLx+v9dgYFSK9bpB2OA1NP0GAuQqoMcnP3v2lhSeKzvT5VQjanvNN2iIgUSKDIz1O/4s9lEHZsJxFZ6RLNU88aRDBODpQ1e5BQHDFLAVif3oLL1U9MYvq1ifpDvXjP3atMfS2UEzqUhU5K2lh+jR880EIAtMY4LSr1sNr0CjnNW4YUojtGpIcEvZ/2QdsHbwVklIBxPLXVRNtPomQHydLr2pUKea4l6q/n//+iweLgGg9UC1v/9MYt9z3RHp7GJTO2oDSThZJJ72rDRqDdQErj9XTPSKqvfg5Rvv5g0+GurmcwrpuXxF7AZ7yyP8gYFwYERaUJ7Dj9ssmpwZgDB/QiQn19j8RtIYXY14mvBwDc+YAzPEvBlIPXS6IK6pCGLGYuX4gaVCLKvYwu03WSqHbIcw7zmkUVK6SXpPd+RslvXxcywl/+wIblHD/4P0SitFl6O/jyXEbJqCR/bvP6kW5tNgnK; 4:Ex3OJXJgGHm6IP/Xvp58dZNGIePq/GuqN2ZanrY6/mzKbZhpy8yCMDZx40ZjjMgYdMt79jlsvyhsAnaWVRVn5cy7Y85KEfML4lhqouGBtiofXGSPKc+YIHg4wvjfa2Uk1uZMer0Nv6FCIgAKgbNiZFUzEX6vD6Xz9ExQk74x/lzGKJshATXEY661fz9jO4xMFKgZ8O/4ASeOVKgc2eDjD/vnza3lXiPsMYVDlOTjyWpgZfCY/GWW8T3hg7uKoty32j72LNWKkywmxVUgoYZrIce7SiMTyKHzMiEtg8r3A5ZMNFtax5VZ4oqmTvXvcSjm X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:DBXPR06MB285; BCL:0; PCL:0; RULEID:; SRVR:DBXPR06MB285; X-Forefront-PRVS: 0687389FB0 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DBXPR06MB285; 23:iVEo3EMwzbf+YGPGgne8TFmLUgA9seQ0TDCRW7R5yB?= =?us-ascii?Q?iuhHpbrCmqYQoRC2Inyc+4DXXB/I3ewHK4Q5pARNDKzUVycRoX8KycIPuQBT?= =?us-ascii?Q?CbLNhSsB5SyJ8LwKG6TIle1etrvmIsnHKS8ABq4tHKiWPpK+zBIbuz3iuYUK?= =?us-ascii?Q?q0NGV1VLUWnUAgo/EyWDkECL8vR+pKYLVs1/qkxsOd371PCHbR3y5dCwpG7L?= =?us-ascii?Q?BBEJEYo7G6p3DhdyFUPWqTYcUzl6KengsNuoF4sLODddlRm4ubKZnlbVu5W+?= =?us-ascii?Q?bDdVpZtVK75zRNvafLSHT2zsBwbN0WIzpq4ldten4fklgMQOWh+WgsMohOQX?= =?us-ascii?Q?0+p7tOQNzcOIcV/g17dBbi1IYcL3wRxJJ7ijLws8ErBFx473sWgo7OW7Ahhp?= =?us-ascii?Q?3WRDnzb/IUp5PEXFsi/712fQ8oIP5wBuNvgTlepj9gPf7p2etbXWUSbmMFEU?= =?us-ascii?Q?117Qj3x1N5avCqFvkAw8tnSm9xZ8K6qyffw0YY+dq/5jEstwOyJmYjyfk0zD?= =?us-ascii?Q?3//a2JyXDLpWZhiwVSmeE0hFjA0W7lDNzizw98MQ7ztzFebsM0AvCvgmVMkR?= =?us-ascii?Q?/UUy6nfoE+BZ3NY3wW7wa/JhLiqgRD7XXwmO5vy1nHCb9osb0NJS5DR7GxD8?= =?us-ascii?Q?ilUsxkG57EfIprvivTMnxsMP5FrMVX1AeJpFlYrbUcgixpwfiR+3mV1PnABj?= =?us-ascii?Q?rYUWgsBFrRKFUvSpGAT5pF3zR/ysd4o+dto5wBtjWHb+tot7i6jXnTUhHvwv?= =?us-ascii?Q?lL8Dkfw7PwcrL6FuOPR/HBdHBWVFcCU0Smk6rlKmJsSuvd2zHkDUCQ4G5uIx?= =?us-ascii?Q?EdgaFlMNTrIl5C3BMO1ZT7TsvZUk9ngXZWpWqVHaUf2IR74vJYJ/sGAZPAsL?= =?us-ascii?Q?7YrYBoFGUdXPxo26GtLk/XgetzQMg6dR/OeZFp2QCtVjGda9e3FUacUxWxXO?= =?us-ascii?Q?/IjEZAg9Wu2Q/bE1Ad/4dPTBR2kHXZ19fE4lp1LdzZzOYsmki56gdOsg9cz2?= =?us-ascii?Q?ByfA79Un2mpDJnuguXZxz3VQpV9W6fv+8gLpz5V4B6jAXgpau4kC4BkspYI1?= =?us-ascii?Q?R5qoFhwSsq67m24W7NJDqvSdSmSys4eUIVol8Bsb90fGaPpafYJuvBAm0fpv?= =?us-ascii?Q?1GjQ5Ts2Y6W3XTR/AdLTC81rtOBf77pfNAbxQ4HKbwWbEMWi7MctP2idW6bV?= =?us-ascii?Q?/T3KI1nb4qUw7T+qQA3FhHRpWhrfEfBc7qpPVMrBnG3Zyz3H+jVbAEuu3UCQ?= =?us-ascii?Q?eVouT1MhF7endB897P0bPbnMkCicBRS0cJEybD3bSHZTza/W7OaVVhHGsDgQ?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR06MB285; 5:G0eJ6cMZO9DwmZze87Qd0ncXdAowFedVPV+8aBOqZtWSmAWjUoWjcRqcZEyOmAH1AEsx8SU79RW+qB+82C1/JGPGPRaOfveQhQ8s5LCc3Ko2k+qwaVyeqVjjIqLaYD04EjhotYPi8wUAx48bF6C6xg==; 24:fR/HGYMmdrOwWXYY5UTOioq++/D9PBRdNRRAliDY9zPPxx2mYXd8/jpio4m5nZXg9Zuio7e0jCcpoAo/tVZRCANIdWpf67MOf7lf8ZjbUmQ=; 20:N7Qo019nLMZb1N/2tn5PBCqr+e6sz7ZEvY39aQ/HOu1wdiMNxo5d1XeSu+go2Jc63RaSdGEJn91+yzByi36F6A== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2015 18:49:04.7857 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATBRAGMSX02.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR06MB285 Archived-At: Subject: [core] Is hashing mandatory in 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, 02 Sep 2015 18:49:29 -0000 --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0866F4ATDOAGMSX02itison_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, I have recently started working with the CoMI draft and one thing that was = not clear to me was if it is mandatory to use the Yang hash of the object i= dentifier? I am thinking of using Yang modules we might design for some con= strained applications that already have short identifiers. Thanks, Abhinav ________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please i= mmediately notify the sender and delete the e-mail and attached documents. = Please note that neither the sender nor the sender's company accept any res= ponsibility for viruses and it is your responsibility to scan or otherwise = check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0866F4ATDOAGMSX02itison_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,
I have recently started working with the CoMI draft and one thing that= was not clear to me was if it is mandatory to use the Yang hash of the obj= ect identifier? I am thinking of using Yang modules we might design for som= e constrained applications that already have short identifiers. 
Thanks,
Abhinav
________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0866F4ATDOAGMSX02itison_-- From nobody Wed Sep 2 13:23: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 90FDF1B29FC for ; Wed, 2 Sep 2015 13:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 I1wCSMAJLpQF for ; Wed, 2 Sep 2015 13:23:19 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0110.outbound.protection.outlook.com [65.55.169.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BD11A710D for ; Wed, 2 Sep 2015 13:23:18 -0700 (PDT) Received: from DM2PR0601MB794.namprd06.prod.outlook.com (10.242.173.142) by DM2PR0601MB1022.namprd06.prod.outlook.com (10.160.215.18) with Microsoft SMTP Server (TLS) id 15.1.256.15; Wed, 2 Sep 2015 20:23:17 +0000 Received: from DM2PR0601MB794.namprd06.prod.outlook.com (10.242.173.142) by DM2PR0601MB794.namprd06.prod.outlook.com (10.242.173.142) with Microsoft SMTP Server (TLS) id 15.1.256.15; Wed, 2 Sep 2015 20:19:00 +0000 Received: from DM2PR0601MB794.namprd06.prod.outlook.com ([10.242.173.142]) by DM2PR0601MB794.namprd06.prod.outlook.com ([10.242.173.142]) with mapi id 15.01.0256.013; Wed, 2 Sep 2015 20:19:00 +0000 From: Michel Veillette To: Somaraju Abhinav , =?windows-1255?Q?Core_=FD=5Bcore=40ietf=2Eorg=5D=FD?= Thread-Topic: [core] Is hashing mandatory in CoMI? Thread-Index: AdDlr17vegMovSUlTn+0GMd1TibeNAADP4xA Date: Wed, 2 Sep 2015 20:18:59 +0000 Message-ID: References: <0E9A48AB39AF3547ACD28A6DE3E2906A0866F4@ATDOAGMSX02.itiso.net> In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A0866F4@ATDOAGMSX02.itiso.net> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-microsoft-exchange-diagnostics: 1; DM2PR0601MB794; 5:lTUEPVQ/aZHcZ5oj5/6KUyiWr/Vn6O29FZPeMx6LKl03f7+QOGYTSVHJ0gGGt7ZTiTATzv6O7GfG8E74EOw7+bEql787GU9vSUVpXWTVzh/hUbjChsCxs3zYwRd08nqR2LjaQqXXPiLpwEnKNn2qNQ==; 24:nk9jGD1AadVaE9bXLht27VVeNdh2kuZG0NUH79DhaJsYbCJh7gp0qWfNaDauwRIYDIk+bEpHuFBiEV9AOwKIN5Q+KdC2JGVwlY56ozECzYk=; 20:W1z08IGTgO7sExI/1hA0UdYgqmU/T2dBME1DcwDfRRMVhCwNhjuaPYbDVw3CTIOLP5tyWjSkqdadDra/WdQhGA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0601MB794; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:DM2PR0601MB794; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0601MB794; x-forefront-prvs: 0687389FB0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(38414003)(199003)(164054003)(68736005)(5001960100002)(19627595001)(122556002)(102836002)(5001860100001)(92566002)(5001770100001)(15975445007)(19625215002)(18206015028)(40100003)(87936001)(46102003)(5001830100001)(107886002)(99936001)(33656002)(62966003)(5890100001)(77156002)(54356999)(76176999)(81156007)(50986999)(74316001)(77096005)(17760045003)(5002640100001)(101416001)(16236675004)(4001540100001)(97736004)(189998001)(86362001)(2900100001)(2950100001)(10400500002)(19617315012)(5007970100001)(5003600100002)(5004730100002)(105586002)(99286002)(64706001)(106356001)(66066001)(19580395003)(19580405001)(76576001)(19300405004)(7099028); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0601MB794; H:DM2PR0601MB794.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_DM2PR0601MB7942D0D992E2BCD2E89D0BAFE690DM2PR0601MB794na_"; type="multipart/alternative" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2015 20:18:59.9575 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0601MB794 X-Microsoft-Exchange-Diagnostics: 1; DM2PR0601MB1022; 2:jk3DvyiaiRWwPdiYTI0MK9z1FQ7rbiGG80oig07E21gvnVkgIoE4uTmCnRtpG33g7jDfhGsnma/P6PcjFgVNxR3g0mVCgfIjwxZGaq4axAPmWo2qQz5H0NiQOxbtZ3DVwpeKvxGM2VawUIfAtYK6OpbJT5nWADUE2sD1U9Y1xCA=; 23:Erqq9UlvI/ezkngF+h7poShFnkcjx/YFSchChhdTFvokFPPf6LnHgt5BvUFUyJZ6wZ+DC07sGXWQBF/3yj/Z4M09EoEob+bDC3/JynC8w7pDAc6JLGO9jZT8EDFaNvVjxMHqRjc3zFd/7DUhTeMHzMPQf5uwg2UmAszwjT1I5P/38dJilnRIo2D8H+23y1rw X-OriginatorOrg: trilliantinc.com Archived-At: Subject: Re: [core] Is hashing mandatory in 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, 02 Sep 2015 20:23:20 -0000 --_004_DM2PR0601MB7942D0D992E2BCD2E89D0BAFE690DM2PR0601MB794na_ Content-Type: multipart/alternative; boundary="_000_DM2PR0601MB7942D0D992E2BCD2E89D0BAFE690DM2PR0601MB794na_" --_000_DM2PR0601MB7942D0D992E2BCD2E89D0BAFE690DM2PR0601MB794na_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable For CoMI, YANG hash are mandatory. We are working of a new draft (CoOL) which will introduce structured (regis= tered) identifier. [cid:image001.jpg@01C868D8.BF0BB7E0] Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-375-0556 ext. 237 michel.veillette@trilliantinc.com www.trilliantinc.com From: core [mailto:core-bounces@ietf.org] On Behalf Of Somaraju Abhinav Sent: 2 septembre 2015 14:49 To: Core =FD[core@ietf.org]=FD Subject: [core] Is hashing mandatory in CoMI? Hi, I have recently started working with the CoMI draft and one thing that was = not clear to me was if it is mandatory to use the Yang hash of the object i= dentifier? I am thinking of using Yang modules we might design for some con= strained applications that already have short identifiers. Thanks, Abhinav ________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please i= mmediately notify the sender and delete the e-mail and attached documents. = Please note that neither the sender nor the sender's company accept any res= ponsibility for viruses and it is your responsibility to scan or otherwise = check this e-mail and any attachments. --_000_DM2PR0601MB7942D0D992E2BCD2E89D0BAFE690DM2PR0601MB794na_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

For CoMI, = YANG hash are mandatory.

We are wor= king of a new draft (CoOL) which will introduce structured (registered) ide= ntifier.

 = ;

3D"cid:=

Michel Veill= ette
System Architecture Director

Trilliant In= c.
Tel: 450-375-0556 ext. 237
michel.veillette@trilliantinc.com

www.trilliantinc.com<= /span>  

 

 = ;

From: = core [mailto:core-bounces@ietf.org] On Behalf Of Somaraju Abhinav
Sent: 2 septembre 2015 14:49
To: Core =FD[core@ietf.org]=FD <core@ietf.org>
Subject: [core] Is hashing mandatory in CoMI?

 

Hi,

I have recently started working with the= CoMI draft and one thing that was not clear to me was if it is mandatory t= o use the Yang hash of the object identifier? I am thinking of using Yang modules we might design for some constrained a= pplications that already have short identifiers. 

Thanks,
Abhinav

____________________________________________________= ____ The contents of this e-mail and any attachments are confidential to th= e intended recipient. They may not be disclosed to or used by or copied in = any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify = the sender and delete the e-mail and attached documents. Please note that n= either the sender nor the sender's company accept any responsibility for vi= ruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

--_000_DM2PR0601MB7942D0D992E2BCD2E89D0BAFE690DM2PR0601MB794na_-- --_004_DM2PR0601MB7942D0D992E2BCD2E89D0BAFE690DM2PR0601MB794na_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=2532; creation-date="Wed, 02 Sep 2015 20:18:57 GMT"; modification-date="Wed, 02 Sep 2015 20:18:57 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxsc Hx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAFgB5AwERAAIRAQMRAf/EAKQAAAMBAQEBAAAAAAAAAAAA AAUGBwQDCAABAAMBAQEBAAAAAAAAAAAAAAMEBQIBAAYQAAEDAgMFAgYOCwAAAAAAAAIBAwQFBgAR EiFBExQHMSJRYdEyQhVxUpIjM3OTszRUdFYXCKFicqKyU7Q1FjY4EQABAgQDBQYFBAMAAAAAAAAB AgMAESEEMVESQWGRsRPwcYEiMhShwUJSBdEjMzRigrL/2gAMAwEAAhEDEQA/APR10XQxQ2GRFk5t TmFwqfT2vhHj3/siPpFuxha5QneXgZApqWr0pG2AlvTajVKgh1CW9OktHk9Gpy8GnRC3g49qEpBp vRCJEX0d+MpJJrCVq4txfnJURiE0QncT9R490a6bc+VxDBdMyhVNXUh8XJHI8uP9IiOZZ7u+C5+x mOnHQusoMzefu6T6VzlPFKh6knmPhSUKt70rrSlXqdQolZYj0NtOLHjqoaxAG0UkyVktupF9LFi2 XbaQFJ83bfHrhFxqJSry9t0Idk3H1pvF2W1SK8IlDECeV9GgTJxVQcsmi9quH7hm2ZlqTj2zhK3d uHZ6VYdsor9CuiNb9EiU69rggpcbaOLMUn20VUJ0ibXTkCp72op5qYkOslxRLSToiq28EJAcUNcA rur9dfvGgnQbqp0SiS24xnDcebRyQhSDQibRWzUkMUQEyLtRcHYaSG1a0KKhPwpAX3VFxOlaQky8 awNol7XRI64y7eenkdGbOQIQ9DaCiAypD3kHVsVPDgjlsgWoWB5qc4G3cLNyUT8tYDdN78vevUK7 CmVwG5UOK0cKZKRpppgyI9RESBkmaJltRcGu7ZpCkSTQmsoDaXLi0rmqoEUGwLgkRrNcqV03BCn8 OSQlU2nQVgRXQgNqaC2mrUvg34QumgXNLaSKYQ/bOkNzWoGuMFfxKsD7wwPlw8uBezd+08IJ7tr7 hBn1xSPVq1TnWFpqDxFnI6HA0dmriZ6MvHngPTVq0yM8oL1Ey1TpnAb8SrA+8MD5cPLg3s3ftPCB e7a+4QVC4KEdMcqrdQjOUxpFVyaDoEyKJ25mKqO/AukrVpkdWUF6qdOqYlEwtDrj6xu+p06tv06D Q44vrBmoptq4oPiDSKZuEBam1Utgpik/+N0tgpCiqkx4RNY/IanCFSCdkVfn4P1lr3Y+XEvScop6 hnClVLflypc2py3eVemO8i3KUhFYdNbVUNWyVdhyCTzu1NaeDACnbEl61UpSlqOkqOmf2o3b1fOC FvUmj0544avN860mlmAJ5DHYLPQLTa5LtFe+52kWea7k6kAQe1YbbOmY1DZ9o3DmraZwqT6NUI01 ZDqqTsaZT5TZHmpkrU5yEhkuea8SLw1NV7csDKTyiY6wtKpnEKQeCyj4plOKDXv7FUfsr3zZYba9 Q74+hc9J7oiP5Yvp1wfFRv4nMW/zOCfGI/4jFXhADp3a1JvDqZXIteRySyAy5SojhAROJJAEUiHv dji78Hu3lMsJKKYD4QC1ZS68oK384JdTaRBo/VGzqZABW4cSPAbYBSUlQUnOr5xZquBWbhWwtRxJ P/Igl2gIeQkYCXMxtt3/AKRnfGyv6dcZd/pjw5xtr+2fHlCn05/0i/vsDHzh4au/5W+8wra/xudw hms2fbELoZNK42HJcB2pkARGTVs3XtLZgKGipl5ikviTC1wlZuhoodMMsKQLY66jVCtLkWK9TXjh WNUGzcaJWJfOPkAqo91zzFFUTtw0kOhVXE8BCyi0RRs8TGm15j59E70iESqwxIgONCu4nZDaFl7P DTGHkj3LZ3HlGmVH26xvHOHrpX0psOu2DTapVaasifK4/Ff48gPMkONjkIOCGwQTdhK9vnUOlKTQ S2DKHLOyaW0FKFTPPOAPSihxCv68LNeJx2hKzLYcjqaippGmA02SqOnvIJLtTB75w9JDg9VPiIDZ Njqrb+mvwMCem1jW5XOpNdodRYJynQQllHaFwwVFZlNtBmQqhLkJLgt3crQylQNTLlArS3Qt5STg J849Heo6X/I/ePy4+d6iov8ATTAu4ofMyDWBPWDUG2FKRxGldhOMbe5KEk4aelkupCy8KYCoZQld N6j5VaVyrSaSP8tnzifRX5ivgKw3xjCSow7DktcgXtljN1dlQQfBwzywAduxiEhSp+ky2aVDT/qH Uy4GKJHNs4CN1pp1ogcje+ySjk6a8dFZ1cqmhB4uSdmX6cH2Vi+kgpk4CKpx0z9VPTvgnWRA6POA zRsCjuoTioqoKKC5kqJmuzxYM36h3w256T3RIvy90ulwplbWDWY9VU246GLDUltQyJzJV5hprPPx Z4rflVqUEzSU45fIxL/GISCqSgrDP5xx6O0qkxepNbfiVuPUJBx5SHEaalNmCLKaVSInmm210qiJ 3SXt8GO361FlIKSKjLI745YoSHlEKBoc8479VaXSpPVW3ZMmssQZLbcNG4TrUk3HEGY4oqJNNG2m pV0pqJPHsxyyWoMKASSK1plHbxCS+klUsM84+oVLpQdepkwKyw7NVyQq0wWpKOoqsKiopk0jPdTb sPHnVq9qBpMqVpnxjzaE+6J1VrSuXCFqxKJQmbRvVpm4oslp6GyLz4MTBFkUM8iNDZEiRf1EJcM3 Lii43NJFcx+sL2zaQ2vzDDf+kaG6Jai9FeUl3CyjHrdXIdSbjyya5ng/BE2rQu7W9fe05YyXHPcz CfpwmMOMa6aPbyKvqxkcY6w7Z6lf461y13n6k5VODlGqGjleHsyzjatPD7PFjKnmddUeaeaceMdS 09oovyyyVhwjDbVEobfS68Y4XFFejvOQFemCxMRtnTIRRQxJkXC1rsTQK5b8EecV10HSfqpMZd8Y abT0VjUNmefdFd6QRYsXp3SWIsxuewHMaJbQuAB5yXVXIXRbNNKrltHdiTfqJeUSJYchFSxADQAM 8ecJvTamUxjrDdMpirsS5TvP8WA21JFxrVNbItRuNA0uhe6uk18WzDd4tRt0ApIFK0yhS0QkXCyD M1pXOFA7cI78rblnXYrc83ZByGWItRSQ2BPorjZKyw4JCLmlNSLkuzDnV/aT1EUptTLDeYV6X7qu mutdiv0i88rVfrpe4PyYhak5RbkrOP/Z --_004_DM2PR0601MB7942D0D992E2BCD2E89D0BAFE690DM2PR0601MB794na_-- From nobody Wed Sep 2 16:09: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 8BABC1A8AF0 for ; Wed, 2 Sep 2015 16:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 shZit8Y04T2B for ; Wed, 2 Sep 2015 16:09:08 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::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 4882F1A8924 for ; Wed, 2 Sep 2015 16:09:08 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so34013643wic.0 for ; Wed, 02 Sep 2015 16:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=qqVbqvKe9TwA2ZbQ3zppr+nNZSNvYTh46XA7vxkYbzk=; b=G7mWO/SQVtcSWeKO8MrchzPX3Q513O3VTTx7Pocp+D52R5Enn/lA41bVVJTbFL7FDd wRtzlz+2JSwGaCx7yDZJU7/CdmRgwDey7otoD85qM6PjtAZu0MRhhAlQnjuCF/oHR2+I idx2PRTEBU0wrUzzCkrls1LgAiW3tCKJxRLhESxEJmlqDAikYOCOxxF6ZGX4vbBqOV6V YkrTZe9ejiY43AAst672wM5Xz1DMWaTRjZL/6cfg52TcQX6mFgKpotrSimdHB5YCs9sc GXNJFmMJxO2VaBk71jyHcY2vux6/+9S/GT6UrUDoxVH9KUzGYy8pJgIfVqfsPiZcY2og uOUQ== X-Received: by 10.194.58.130 with SMTP id r2mr44733499wjq.72.1441235346853; Wed, 02 Sep 2015 16:09:06 -0700 (PDT) MIME-Version: 1.0 References: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> <55CBACAD.9090401@gmx.net> <557A6C8AF976114EBAD8852183CF3F371D7A5A0A@SMTP1.etri.info> <55DC64AE.1030105@gmx.net> In-Reply-To: <55DC64AE.1030105@gmx.net> From: Simon Lemay Date: Wed, 02 Sep 2015 23:08:56 +0000 Message-ID: To: Hannes Tschofenig , weigengyu , =?UTF-8?B?6rOg7ISd6rCR?= Content-Type: multipart/alternative; boundary=047d7ba96ec2e314f9051ecbc09f Archived-At: Cc: core@ietf.org 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: Wed, 02 Sep 2015 23:09:10 -0000 --047d7ba96ec2e314f9051ecbc09f Content-Type: text/plain; charset=UTF-8 Hi all, Sorry for the delay Carsten writes: "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" I do like this idea for larger payload, where would the writing need to be? in the Block Draft? as for "new blocksize needs to be a clean fraction of the 1024byte block.", I ment multiplier (:P, my bad) to allow for block size message to be proxied, but this would require some testing to see how feasible and easy it is to implement To Gengyu question, as it was discussed at IETF, the risk of keeping all unused field on reliable transport is that they may be overloaded and get different meaning on different transport layer, example adding a different semantic to RST type. As for the proxy situation, i saw the approach number 1 that Hannes mentioned, but the proxy question is a very valid one that needs a lot of exploration. As for the length, since this is the last issue before we bring the draft as a working group item, I think it would be good to have a conference call with everybody who is interested in the subject to voice concern one more time, and come up with an unique approach i create a doodle, i added as much options as possible time wise to get the maximum amount of people. http://doodle.com/xti53ksybm95pzh4 Cheers Simon On Tue, Aug 25, 2015 at 5:50 AM Hannes Tschofenig wrote: > Hi Gengyu, > > thanks for your response and the question you raised. Here is my > impression about what happens in this case: > > On 08/20/2015 12:25 PM, weigengyu wrote: > > But if the usage senario is that there are three nodes; > > C is a CoAP client, S is a CoAP server, and I is an intermediary. > > CoAP Client -------------- Intermediary --------------- CoAP > Server > > C I S > > > > Suppose, transport layer protocol between C and I is TCP and that beween > > I and S is UDP. > > If all the CoAP messages between C and I are NON, > > which message between I and S shoule be CON? > > The CoAP client would use TCP with the gateway and the data transfer > would be transmitted reliably due to the nature of TCP (regardless of > what CoAP says). > > Then, when the data is at the gateway a new CoAP over UDP message would > be created and sent to the CoAP server. For the CoAP client the > interaction with the CoAP server isn't visible since the entire > communication terminates at the gateway. As such, the gateway needs to > have some application level knowledge to know whether the application > demands reliable transport or not. > > I see two possible approaches: > > 1) The gateway assumes that the use of TCP between the client and itself > is an indication that the client wants reliable data transfer and > therefore would replicate this functionality also in the exchange of > data between the gateway and the server. It would therefore use CON. > > 2) The gateway re-uses whatever is conveyed in the CoAP message. For > example, if the CoAP message from the client is a CON then it would be a > CON also on the other side. > > Do you believe the draft should recommend one way or should this be left > open for deployments to choose? > > Ciao > Hannes > > --047d7ba96ec2e314f9051ecbc09f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Sorry for the delay
<= br>
Carsten writes:
"A new szx=3D7 to enable larger block sizes could sim= ply indicate that the
total body is to ass= embled serially from the payloads provided in
sequence; this only really makes sense when keeping a sequence of block= s
within an instance of a sequence-preserv= ing transport.=C2=A0 But I would
write thi= s up separately, not in this draft"

I do like this idea for larger pay= load, where would the=C2=A0writing=C2=A0need to be? in the Block Draft? =C2=A0
=

<= div>as for "new blocksize needs to be a clean fraction of the 1024byte block.",= =C2=A0I ment mul= tiplier (:P, my bad) to allow for block size message to be proxied, but thi= s would require some testing to see how=C2=A0feasible=C2=A0and easy it is to implement

To Gengyu question, as it was discussed at IETF, the risk of ke= eping all unused field on reliable transport is that they may be overloaded= and get different meaning on different transport layer, example adding a d= ifferent semantic to RST type.=C2=A0 As for the proxy situation, i saw the = approach number 1 that Hannes mentioned, but the proxy question is a very v= alid one that needs a lot of exploration.

As for t= he length, since this is the last issue before we bring the draft as a work= ing group item, =C2=A0I th= ink it would be good to have a conference call with everybody who is intere= sted in the subject to voice concern one more time, and come up with an uni= que approach

= i create a doodle, i added as much options as possible time wise to get the= maximum amount of people.


=
Cheers

Simon


On Tue, Aug 25, 2015 at 5:50 AM H= annes Tschofenig <hannes.ts= chofenig@gmx.net> wrote:
Hi = Gengyu,

thanks for your response and the question you raised. Here is my
impression about what happens in this case:

On 08/20/2015 12:25 PM, weigengyu wrote:
> But if the usage senario is that there are three nodes;
> C is a CoAP client, S is a CoAP server, and I is an intermediary.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 CoAP Client -------------- Intermediary ---= ------------ CoAP Server
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 C=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I S
>
> Suppose, transport layer protocol between C and I is TCP and that bewe= en
> I and S is UDP.
> If all the CoAP messages between C and I are NON,
> which message between I and S shoule be CON?

The CoAP client would use TCP with the gateway and the data transfer
would be transmitted reliably due to the nature of TCP (regardless of
what CoAP says).

Then, when the data is at the gateway a new CoAP over UDP message would
be created and sent to the CoAP server. For the CoAP client the
interaction with the CoAP server isn't visible since the entire
communication terminates at the gateway. As such, the gateway needs to
have some application level knowledge to know whether the application
demands reliable transport or not.

I see two possible approaches:

1) The gateway assumes that the use of TCP between the client and itself is an indication that the client wants reliable data transfer and
therefore would replicate this functionality also in the exchange of
data between the gateway and the server. It would therefore use CON.

2) The gateway re-uses whatever is conveyed in the CoAP message.=C2=A0 For<= br> example, if the CoAP message from the client is a CON then it would be a CON also on the other side.

Do you believe the draft should recommend one way or should this be left open for deployments to choose?

Ciao
Hannes

--047d7ba96ec2e314f9051ecbc09f-- From nobody Wed Sep 2 16:15: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 1AF5F1B38BF for ; Wed, 2 Sep 2015 16:15:20 -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 RG2v2fS3qQuS for ; Wed, 2 Sep 2015 16:15:18 -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 2E1C71A0383 for ; Wed, 2 Sep 2015 16:15:18 -0700 (PDT) Received: by lbcjc2 with SMTP id jc2so14914004lbc.0 for ; Wed, 02 Sep 2015 16:15:16 -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=Peplxn+UcgnMYLkA7vsC8fZgM3wXsGptEtKWiZCOZEw=; b=dPNHDtKUECdbfIBi9LVAPztXlGqK9iLDg5+AJiP20uEJtwpeBEXVivcYuh5Jx2HYnM 45Ln41w1oUnp3/yaz4tEqY+MJYsEpNO52nHty+k4YNya1tmU2TKNKxkLgOQbUPdOLc90 Y6f1gKYh0+H+7zuLm9G9wxPzwXLNEy5TowL8SB6lN7QG8uilx8GIYI8vkQv7eXrdqlPs m5oVS9fuJEquNXDSheZ5h/nBwIDvqyBrz/sY8WtrVzelrIoCFVhQVEgMAyuI6V+77FmZ tCtb2CpcagPMRz3+REl3iVNXKwn3uziynvgOYfB3d/LOAGGDkP5QAvk8mx9ila0m1Gcd GqdQ== X-Gm-Message-State: ALoCoQn+G1NEjEfb8zc7FZnP3FJAtL3WznsqcvOFat8kb9Cw80WBgFvv0PA9/41MxR8ryOGEQjHL MIME-Version: 1.0 X-Received: by 10.152.20.98 with SMTP id m2mr18258682lae.119.1441235716391; Wed, 02 Sep 2015 16:15:16 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Wed, 2 Sep 2015 16:15:16 -0700 (PDT) In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A0866F4@ATDOAGMSX02.itiso.net> References: <0E9A48AB39AF3547ACD28A6DE3E2906A0866F4@ATDOAGMSX02.itiso.net> Date: Wed, 2 Sep 2015 16:15:16 -0700 Message-ID: From: Andy Bierman To: Somaraju Abhinav Content-Type: multipart/alternative; boundary=089e01419b5ce9ed29051ecbd6d5 Archived-At: Cc: =?UTF-8?B?Q29yZSDigI5bY29yZUBpZXRmLm9yZ13igI4=?= Subject: Re: [core] Is hashing mandatory in 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, 02 Sep 2015 23:15:20 -0000 --089e01419b5ce9ed29051ecbd6d5 Content-Type: text/plain; charset=UTF-8 Hi, CoMI does not have an option for using plain URIs and identifier strings instead of object numbers. Andy On Wed, Sep 2, 2015 at 11:49 AM, Somaraju Abhinav < abhinav.somaraju@tridonic.com> wrote: > Hi, > I have recently started working with the CoMI draft and one thing that was > not clear to me was if it is mandatory to use the Yang hash of the object > identifier? I am thinking of using Yang modules we might design for some > constrained applications that already have short identifiers. > Thanks, > Abhinav > ________________________________________________________ The contents of > this e-mail and any attachments are confidential to the intended recipient. > They may not be disclosed to or used by or copied in any way by anyone > other than the intended recipient. If this e-mail is received in error, > please immediately notify the sender and delete the e-mail and attached > documents. Please note that neither the sender nor the sender's company > accept any responsibility for viruses and it is your responsibility to scan > or otherwise check this e-mail and any attachments. > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --089e01419b5ce9ed29051ecbd6d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

CoMI does not have an option for us= ing plain URIs and identifier strings
instead of object numbers.<= /div>

Andy


=
On Wed, Sep 2, 2015 at 11:49 AM, Somaraju Abhina= v <abhinav.somaraju@tridonic.com> wrote:
Hi,
I have recently started working with the CoMI draft and one thing that= was not clear to me was if it is mandatory to use the Yang hash of the obj= ect identifier? I am thinking of using Yang modules we might design for som= e constrained applications that already have short identifiers.=C2=A0
Thanks,
Abhinav
________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and = it is your responsibility to scan or otherwise check this e-mail and any attachments.

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


--089e01419b5ce9ed29051ecbd6d5-- From nobody Wed Sep 2 17:30: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 34D131B50A0 for ; Wed, 2 Sep 2015 17:30:04 -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 21myYg_KG3Zf for ; Wed, 2 Sep 2015 17:30:02 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F871B556D for ; Wed, 2 Sep 2015 17:30:01 -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 t830Tj46008375; Thu, 3 Sep 2015 02:29:46 +0200 (CEST) Received: from alma.local (p5DC7F76C.dip0.t-ipconnect.de [93.199.247.108]) (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 3n631P0MdfzDJnM; Thu, 3 Sep 2015 02:29:44 +0200 (CEST) Message-ID: <55E79477.2060105@tzi.org> Date: Thu, 03 Sep 2015 02:29:43 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: Simon Lemay References: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> <55CBACAD.9090401@gmx.net> <557A6C8AF976114EBAD8852183CF3F371D7A5A0A@SMTP1.etri.info> <55DC64AE.1030105@gmx.net> 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] 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: Thu, 03 Sep 2015 00:30:04 -0000 Simon Lemay wrote: > Hi all, > > Sorry for the delay > > Carsten writes: > "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" > > I do like this idea for larger payload, where would the writing need to > be? in the Block Draft? Procedurally, the Block Draft is done in the WG and is being submitted to the IESG (any day now). So the answer should be: A third draft, or we may want to pull this in here in the TCP/TLS draft if this is really considered an indispensable part of the TCP binding. > as for "new blocksize needs to be a clean fraction of the 1024byte > block.", I ment multiplier (:P, my bad) to allow for block size message > to be proxied, but this would require some testing to see > how feasible and easy it is to implement Right; if this is about block-by-block proxying, this would still be a bit icky because it's not easy to reconstruct the block number. Prototyping is the right way to get this right, and that is another reason for a third draft. > As for the length, since this is the last issue before we bring the > draft as a working group item, I think it would be good to have a > conference call with everybody who is interested in the subject to voice > concern one more time, and come up with an unique approach > > i create a doodle, i added as much options as possible time wise to get > the maximum amount of people. > > http://doodle.com/xti53ksybm95pzh4 As a WG chair, I need to point out that anything that is discussed on such an informal call would be like a hallway discussion at an IETF; if we really want to nail down things, we might call a virtual interim (i.e., such a phone call formally announced with a two-week announcement interval) -- but the two are not mutually exclusive. Gr眉脽e, Carsten From nobody Wed Sep 2 21:45: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 294EF1A908E for ; Wed, 2 Sep 2015 21:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.512 X-Spam-Level: X-Spam-Status: No, score=0.512 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] 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 depK2R-k9yYX for ; Wed, 2 Sep 2015 21:45:53 -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 EB9B11AC3BF for ; Wed, 2 Sep 2015 21:45:52 -0700 (PDT) X-ASG-Debug-ID: 1441255550-06daaa5cf3132200001-aa7cYp Received: from NISSONITE.InterDigital.com (nissonite.interdigital.com [10.2.64.252]) by smtp-in1.interdigital.com with ESMTP id ImsI60Dk33XYD03f (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 03 Sep 2015 00:45:51 -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.0248.002; Thu, 3 Sep 2015 00:45:46 -0400 From: "Rahman, Akbar" To: "consultancy@vanderstok.org" , Michael Koster , Core Thread-Topic: [core] pubsub and sleepy node proxy X-ASG-Orig-Subj: RE: [core] pubsub and sleepy node proxy Thread-Index: AQHQ47uC+G7xgzFvBUWihAonddpx2Z4qPB1g Date: Thu, 3 Sep 2015 04:45:45 +0000 Message-ID: <36F5869FE31AB24485E5E3222C288E1F347AFBF4@NABESITE.InterDigital.com> References: <25093c7d75ade3f78e471b55816d0bac@xs4all.nl> In-Reply-To: <25093c7d75ade3f78e471b55816d0bac@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.247.108] 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: 1441255551 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.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22181 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [core] pubsub and sleepy node proxy 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, 03 Sep 2015 04:45:54 -0000 Hi Peter, I am still reading the pubsub draft, but did want to give support for your = sleepy node draft (draft-zotti-core-sleepy-nodes-03). The sleepy node prox= y concept that you describe will be useful in many scenarios. One related = comment that I did have on your draft is that it seems a bit fixated on the= 6LoWPAN scenario. But as we have discussed many times during IETF meeting= s and on various mailing lists, the sleepy node scenario is useful beyond 6= LoWPAN deployments (e.g. https://tools.ietf.org/html/draft-arkko-core-sleep= y-sensors-01 ). So I think it would be useful if you clarified that in y= our draft. Best Regards, Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok Sent: Monday, August 31, 2015 3:06 AM To: Michael Koster ; Core Subject: [core] pubsub and sleepy node proxy Hi Michael, Looking at the pubsub draft and at our sleepy node proxy draft, I come to t= he conclusion that there are good arguments to maintain both. Following the reasoning of Matthieu Vial, there are already a good argument= s for the sleepy node (SN) proxy (aka mirror server) to exist next to the R= D. Namely: Where an end-point can delegate its links to the RD for discovery, an end-p= oint can delegate the links AND the associated resource values to the SN-pr= oxy. The SN-proxy resources have the same lifetime as SN resources. The SN-proxy resource values are directly linked to the resources of a give= n SN. In contrast the pubsub handles anonymous values. The origin can be added bu= t that means adding attributes to the topics. The pubsub handles the more abstract topics, where the SN-proxy is concerne= d with the resources. The lifetime of the values in the pubsub server is not directly linked to t= he lifetime of the originating resources. For me these are the arguments that motivate the existence of the pubsub dr= aft next to the sleepy node draft. Looking forward to your reaction. Greetings Teresa and Peter _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Wed Sep 2 22:22: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 8B8941B370C for ; Wed, 2 Sep 2015 22:22:52 -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, HTML_MESSAGE=0.001, 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 cj-AeeNWnTwo for ; Wed, 2 Sep 2015 22:22:50 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63C651B2C89 for ; Wed, 2 Sep 2015 22:22:49 -0700 (PDT) Received: from DB4PR06CA0075.eurprd06.prod.outlook.com (10.162.49.43) by DB5PR06MB1320.eurprd06.prod.outlook.com (10.162.222.18) with Microsoft SMTP Server (TLS) id 15.1.256.15; Thu, 3 Sep 2015 05:22:31 +0000 Received: from AM1FFO11FD021.protection.gbl (2a01:111:f400:7e00::152) by DB4PR06CA0075.outlook.office365.com (2a01:111:e400:9866::43) with Microsoft SMTP Server (TLS) id 15.1.256.15 via Frontend Transport; Thu, 3 Sep 2015 05:22:32 +0000 Authentication-Results: spf=fail (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; yumaworks.com; dkim=none (message not signed) header.d=none; yumaworks.com; dmarc=none action=none header.from=tridonic.com; Received-SPF: Fail (protection.outlook.com: domain of tridonic.com does not designate 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATDOAGMSX01.itiso.net; Received: from ATDOAGMSX01.itiso.net (146.108.200.10) by AM1FFO11FD021.mail.protection.outlook.com (10.174.64.210) with Microsoft SMTP Server (TLS) id 15.1.262.18 via Frontend Transport; Thu, 3 Sep 2015 05:22:31 +0000 Received: from ATDOAGMSX02.itiso.net ([169.254.4.181]) by ATDOAGMSX01.itiso.net ([146.108.41.67]) with mapi id 14.03.0224.002; Thu, 3 Sep 2015 07:22:30 +0200 From: Somaraju Abhinav To: Andy Bierman Thread-Topic: [core] Is hashing mandatory in CoMI? Thread-Index: AdDlr17vegMovSUlTn+0GMd1TibeNAAFResAABEEPi8= Date: Thu, 3 Sep 2015 05:22:29 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A086953@ATDOAGMSX02.itiso.net> References: <0E9A48AB39AF3547ACD28A6DE3E2906A0866F4@ATDOAGMSX02.itiso.net>, In-Reply-To: Accept-Language: en-US, de-AT Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0E9A48AB39AF3547ACD28A6DE3E2906A086953ATDOAGMSX02itison_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD021; 1:6S3zIruYxMcikVNTvsz3loSiygUvm65jf02/VTp9My0TAATZRadthvWK2Hp1D5rna0qAWUwTV3JT5XIp1Q8zxPxqNNBvGtbt2/Gk1JoY/ptFyqdUcz6nl6WdvSIh7t/g2bUEH3lxfSJ3fKNqIzSjB4AQiVMk/X6X+OqNIrPPtHTlSuhiNSR0BQT/QcVfBghuJq2DgddlP2W/L6ztewqIsXfUhLdMDg8JwmpvfJfSg1JMiRksLWTuviqBewmBhYIVbGW5w6qOsNX1gM9LXFGThFT2l6GrDbmt68efwgfdEw4t4dtuhSeIU+0QuDNyenF+ X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(1109001)(339900001)(164054003)(199003)(24454002)(189002)(377454003)(51914003)(105606002)(110136002)(85426001)(189998001)(5001860100001)(15975445007)(5007970100001)(55846006)(5001960100002)(2950100001)(2920100001)(5890100001)(5001830100001)(2900100001)(81156007)(102836002)(16236675004)(4001540100001)(77156002)(62966003)(46102003)(19580405001)(53416004)(6806004)(54356999)(86362001)(64706001)(19617315012)(106466001)(19580395003)(104016003)(26826002)(50986999)(33656002)(84326002)(5003600100002)(69596002)(92566002)(76176999)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR06MB1320; H:ATDOAGMSX01.itiso.net; FPR:; SPF:Fail; PTR:unknown.zgrp.net; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB5PR06MB1320; 2:jzi5OKvKbvoxT23p/5ykK3D4jZRMSclBT0X+JBj4Pmi5GjDF2EA02G+f/L0Hole33OgxHJGZKh7oLqxwZGKQKl0+vdvzKhTBcj27rcLdaxhbmuyMZnoedPr3aFhQ3KJ1bwLhtW67Xtbr2VnbItmsiL6oiBxBuSyh1TJycwaRc6w=; 3:C9Yx1sVFBGwue9jnNuiuRo+k52rYtJ6Ai/6KvE9ZcwA7ggf0PCrRrYKs2yRkna9G9e83jeTWEUGOtQpax0PFoBuauEiqxSD+QztHj60yI3GPpkHvY2mRYs0P6F2b4W86Ee+2Yf2NTdV1fwh0r9sm4hUJs32WBaWNFz9HbntaCJRIiSrp25gl63eHNQnoM15bsQDEO3r7wWsmK4wKkKEAiGnBOWx57XAyZr0O4BvhrTQCDHmC7rltzZ654plclW5b; 25:ljkr9pO6GlHMmrw4L9Ytb96l3SAX7hs+v1pC9SmBuiEHQRSoiIaz9wziqd+QdLHYSCJH+1QDEF6N0S6zt/2KurVBw2JOllAZF1XFVOiGO1ZVacvnK7jiliVrOOZkbUJ8mAMOpyBDOtp59YVDjTz2adv2tHWUpbYsmxMmjhsvXEyDLVcsX9cdVvWiD81ehQ2fhscvh/EVPLfCtQuH46I1tpmrJtARfAi1/58iyTH+8j9h/QksAWkwiJB6BlHnyHMbwTFYzhnXad+BR/YlvfjpYw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR06MB1320; X-Microsoft-Exchange-Diagnostics: 1; DB5PR06MB1320; 20:IONOcKMmWzeYyMqrzo/h1oF7CCb+4+oDqm55tP1TUiTsqjl+Zily02MotZBgEY4BXVmTUIaZ5rpIOjusnkHUsqF2TutLNQBPXGShV3aw5RXvQW7eCwaWHWa+pknA5qVHGdR2s9uFrUz9dUVpyX2cubpBAja8SDGP7lUmSkhc5Stu6iOrEZwIG381E5YqQrBYjTjuGMmlwU1hQooVcFfXzm7TQe2o8kCwnrNc7k5ECtgeGXM3frjaiGgNLFQJVvzuyCfhDjYyvhmLAigv9VgHMUeISv546t+S47Qid5aN07AKOOTowsS4vep/rERHF1yJRL5IVrqoGLBhdfQJcYz21RWpSsOyOfFON4vPSKMQRKXUDyVtNIoEAGhGtlNeYWCpB9f0CNnUjYddHXJLpwxVnoL+Dj1RMOadkkJsU5AP4jBr5HCJUSPyZ0GI828ZsZnGq/PivKFwgtZbhk0i1GmW4/Iuzc9baDnq6Bg8wl+4CQ4k3fKiRKze8Qy+T1ihaTNa; 4:NVBqaGRMn/g0V+NwY6wnxnnLJLZq1M4IH83Bsp0zia5AMgXLPIL+Z/iFgvyJqdtLcVr/w3WChHBzJEyUzH9w7k/S86knMOItK9u+Gsn+UCZwN59gHvf1s2SU7D5hx6fR+NcMpmiYXZ93pfkyOBeBmRyn+rwMrvwmkmVFL/nKpX63f5DoiT2qV+K3OjdsI+7VeN01hTKMl8mXLPD9m3A2tFm3wtTtZXty8CIAPEvIj1vo3jhGRMQ3lG2Wuq3p/9XpJXPX6wApcHAxN2qJ46jlfsvVveQc7yEZxmEll9vxy/uM62/h+oVNdJHxr4l21ZK0 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:DB5PR06MB1320; BCL:0; PCL:0; RULEID:; SRVR:DB5PR06MB1320; X-Forefront-PRVS: 0688BF9B46 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB5PR06MB1320; 23:DRtdPBMPqbpigUoqsaQMbY6fJLYbOOACZiPhwF/xl?= =?us-ascii?Q?y34rbqFQQ5y74/gGF2Bo8nHs6iYc7Q44/CbMp+jIwIGdKHbIb7VC/lZdAiX+?= =?us-ascii?Q?Q/hx+iwDtNonmuwifTqXSMFx3IqE4NSkrpy7+mEck4de7+c3Z+G6d0QtpWTP?= =?us-ascii?Q?cJ1W7LhG5n6atVyjby65aob8eNdgVMNgpDF9f6kEv/TRJN/v8UQa4Pu1yeyH?= =?us-ascii?Q?lIyxlmbb1TRmwQiTKmOOBG8RX9Api1ifpLTspMJPnvloK9qy8rh+DhWnUAir?= =?us-ascii?Q?cAUSLHhxPxhQxndNKuSpTw+TkeAOcV9/XrtzaR26l0i+eFDUiwzzli/bhwRQ?= =?us-ascii?Q?aQjcQTxeYd75ZemlgxZ5JVJxmhjr5d2BEmdF4pJZK20VcdWx429UJ3VSWJd8?= =?us-ascii?Q?gfkAd0wJ+a5cvEVPcp3bmreES1E3xZT/sZQLyeOxIBakSha5zq8VsuUtIEae?= =?us-ascii?Q?butrtn90k8jGRYSf+ZN0EN8Meu4H/4ye1emsLoELDTMnFu/fa3vgRX/U85GE?= =?us-ascii?Q?4c9SLJSsxkR0FPI4UKWTjrh+t/Opa8SmPrQMMW6aC8bNb6Lhu+HGprRGyzro?= =?us-ascii?Q?3K9eq62fXxjhRih9pEPDbtxvarUM9j2JiOuURXu7L8D+E06wRbCOlo2Nv8Cs?= =?us-ascii?Q?46d6/nPRGvsAAQz+JKoMSRvHuI4rVmQYrWPRKy0Vdw4KRSO5eMHMeIPUVqpR?= =?us-ascii?Q?jfQxAoNwODAir5tw5Nz3Vc5RT1xirWNlErhBdqJHJX3LrSiA/SLEzfPQNnL0?= =?us-ascii?Q?7aujTHrErPtjdkR4CRbSWDjo8+Tl0LQQ1iLMzLH+Nui0sEvJdbEobwDTwWcW?= =?us-ascii?Q?hdb/QRt5fXqTxp4PveD3BfbCbQoF+XCrYBn9Nf6Ze1QSQtoLwJ8xtSNb875q?= =?us-ascii?Q?/EFR5rAvD7mn8dzpms3z42DhPMqnL2c9x87PuNYUW3bpFvc7wpUEJ24xZ8Hz?= =?us-ascii?Q?Gy4p4ts/C511ArMDBIJ1HBARKh+iOTEPeFiIXnNpWqbp6eUr8C881n8UNmr2?= =?us-ascii?Q?yI8X6C02I35E8THF46RWguTwo2U3Bni4KHA9u1+yxVNWgdVQQIupcHwuiwVt?= =?us-ascii?Q?+s1onFupvdj6IoGCVR4UzKcH4vYq86WadOZVdZG5BPBkDPrej/QtM7RaE7nK?= =?us-ascii?Q?84OyPMgerm+J7k1TwvYwiI/xkciAaPVjDAfd9v+gFpoUoeR2Zpp/qGzgEAWy?= =?us-ascii?Q?+Gy+Y5SKRhwYIbQ/nGJ1sz86OCgEJUSm1Xv7oEtdDN7/e9q5EJ4j9nrAbQNd?= =?us-ascii?Q?jb2fi5svOMY/h4iVxt8QUdayTbmG9pJiwXKXeNkgPWP6uouaLUXDjctg24SB?= =?us-ascii?Q?j44JwoFqVxkNQU5WNI5QcVEzDmbw7ZU3K+KPnDysmHB?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR06MB1320; 5:JU8v5Giou9W7XsdECSPuP6SWPsvOPBWfC6omocvF2POircyG3tOeUQHrP7jBhu2EZwrLY4qq8Wxk3bsBNRMEfjCZLMGXgckcPtkWNGxpyU938nSDHv9rPJbNF+1mLflqkb7Un2ehDVdX5dP8g5irUQ==; 24:wD98uXpFQZrPatIiyFWQlcrGXAc9BmRxZczs4w02yUKIScrvQ1KAhyN3ulKPRdAb+XgSBv1c0XQhOOkb+de/Fy6hanwRndZl8bjRxgng2Ds=; 20:q9c0gOE+IfolVwPg4LBXI7IlQvv7OHl4xwBJlH85dMoaKpfB2YL0gLDLaQJnNk5ueRQ1LrhiHA52l11fK7W9aA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2015 05:22:31.5876 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATDOAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR06MB1320 Archived-At: Cc: =?windows-1256?Q?Core_=FD=5Bcore=40ietf=2Eorg=5D=FD?= Subject: Re: [core] Is hashing mandatory in 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: Thu, 03 Sep 2015 05:22:52 -0000 --_000_0E9A48AB39AF3547ACD28A6DE3E2906A086953ATDOAGMSX02itison_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Thanks for the info. It might help to put that statement in the draft. Sent from my Windows Phone ________________________________ From: Andy Bierman Sent: =FD03/=FD09/=FD2015 01:15 To: Somaraju Abhinav Cc: Core =FD[core@ietf.org]=FD Subject: Re: [core] Is hashing mandatory in CoMI? Hi, CoMI does not have an option for using plain URIs and identifier strings instead of object numbers. Andy On Wed, Sep 2, 2015 at 11:49 AM, Somaraju Abhinav > wrote: Hi, I have recently started working with the CoMI draft and one thing that was = not clear to me was if it is mandatory to use the Yang hash of the object i= dentifier? I am thinking of using Yang modules we might design for some con= strained applications that already have short identifiers. Thanks, Abhinav ________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please i= mmediately notify the sender and delete the e-mail and attached documents. = Please note that neither the sender nor the sender's company accept any res= ponsibility for viruses and it is your responsibility to scan or otherwise = check this e-mail and any attachments. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please i= mmediately notify the sender and delete the e-mail and attached documents. = Please note that neither the sender nor the sender's company accept any res= ponsibility for viruses and it is your responsibility to scan or otherwise = check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A086953ATDOAGMSX02itison_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Thanks for th= e info. It might help to put that statement in the draft.

Sent from my Windows Phone
From: Andy Bierman
Sent: =FD03= /=FD09/=FD2015 01:15
To: Somaraju Abhinav
Cc: Core =FD[core@ietf.org]=FD
Subject: Re: [= core] Is hashing mandatory in CoMI?

Hi,

CoMI does not have an option for using plain URIs and identifier strin= gs
instead of object numbers.

Andy


On Wed, Sep 2, 2015 at 11:49 AM, Somaraju Abhina= v <abhi= nav.somaraju@tridonic.com> wrote:
Hi,
I have recently started working with the CoMI draft and one thing that= was not clear to me was if it is mandatory to use the Yang hash of the obj= ect identifier? I am thinking of using Yang modules we might design for som= e constrained applications that already have short identifiers. 
Thanks,
Abhinav
________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments.

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


________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A086953ATDOAGMSX02itison_-- From nobody Fri Sep 4 05:00: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 9D80C1B3E58 for ; Fri, 4 Sep 2015 05:00:47 -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 8Js_9ZfNI2nH for ; Fri, 4 Sep 2015 05:00:43 -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 D50101B449C for ; Fri, 4 Sep 2015 05:00:42 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-0b-55e987e8e490 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 74.2F.29154.8E789E55; Fri, 4 Sep 2015 14:00:41 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.14]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Fri, 4 Sep 2015 14:00:40 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann Thread-Topic: [core] [Ace] COSE requirements from CORE/ACE Thread-Index: AQHQ5MykKuSi+Gv28UKsvNSZTz7UMp4nvFAAgASMtwA= Date: Fri, 4 Sep 2015 12:00:39 +0000 Message-ID: References: <55E5C717.8080900@gmx.net> <55E5D2FE.3060301@tzi.org> In-Reply-To: <55E5D2FE.3060301@tzi.org> 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.19] Content-Type: text/plain; charset="utf-8" Content-ID: <5F313EED7C11C04EA5249F1D5E3C251C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM+Jvje7L9pehBu2/WSyOTLnLarHv7Xpm i5szTjFZ3Dq7iNWBxWPNvDWMHkuW/GTy2H5yEpPHtEWZASxRXDYpqTmZZalF+nYJXBkHv31n LDjHVnH6+1PGBsYdbF2MnBwSAiYSU88/ZoSwxSQu3FsPFOfiEBI4yigx/14zE0hCSGARo8Sn CcogNpuAi8SDhkdgcREBJYkLF9eADWIWaGKU6H6jDWILC1hKdO1rgqqxkmiY1gdnd/fvYe5i 5OBgEVCR2DpFGCTMK2AhcXbdUUaQsJCAo8T3I+ogYU4BdYmeua9YQGxGoNO+n1rDBLFJXOLW k/lMECcLSCzZc54ZwhaVePn4HyuILSqgJ7HyehPUi4oS7U8bwMYzC2hKrN+lDzHGWuL78W2M ELaixJTuh+wQ1whKnJz5hGUCo8QsJNtmIXTPQtI9C0n3LCTdCxhZVzGKFqcWF+emGxnppRZl JhcX5+fp5aWWbGIERunBLb+tdjAefO54iFGAg1GJh1fh94tQIdbEsuLK3EOM0hwsSuK8zUwP QoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwzrrBO3f13nLjzGK2LWIV3r07qmQ4XOYWP3tZ XOAit5OVa3dBR0zT1O6q3OemD/UjTMI23HR94vhtfRffx1+NPbPkLEJCVXO2Ge07rbxY33Dm 7KxvXvncvkp8k4FJR23nrV+f6i+tOyimIsbIJj3h3B35l8wcL3fGWz05cFTRaMMOl/1sl08o sRRnJBpqMRcVJwIApAiHJbMCAAA= Archived-At: Cc: Hannes Tschofenig , "Cuellar, Jorge" , "core@ietf.org" Subject: Re: [core] [Ace] COSE requirements from CORE/ACE 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, 04 Sep 2015 12:00:47 -0000 SGkgQ2Fyc3Rlbg0KDQpPbiAyMDE1LTA5LTAxIDE4OjMxLCAiQ2Fyc3RlbiBCb3JtYW5uIiA8Y2Fi b0B0emkub3JnPiB3cm90ZToNCg0KPkhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOg0KPj4gSWRlYWxs eSwgd2Ugd2FudCB0byBoYXZlIGVuY3J5cHRpb24gYXMgb2Z0ZW4gYXMgd2UgY2FuLg0KPg0KPlRo YXQgaXMgdGhlIG1hbnRyYSB3aGVuIHRoZXJlIGlzIHBlcnNvbmFsbHkgaWRlbnRpZmlhYmxlIGlu Zm9ybWF0aW9uDQo+aW52b2x2ZWQuDQo+DQo+SW4gUkVTVCwgd2UgYWxzbyBoYXZlIGFuIGltcG9y dGFudCBwcm9wZXJ0eSBjYWxsZWQgInZpc2liaWxpdHkiLg0KPldoZXJlIHZpc2liaWxpdHkgYW5k IHByaXZhY3kgYXJlIGluIGNvbmZsaWN0LCB0aGUgbGF0dGVyIHVzdWFsbHkgd2lucy4NCj5UaGV5 IGFyZW4ndCBhbHdheXMuDQoNCkRvZXMgdGhhdCBtZWFuIHRoYXQgd2UgbmVlZCBNQUMtb25seSBv ciBub3Q/IElmIHlvdSBhcmUgYmFzaW5nIHNpZ25pZmljYW50DQphY3Rpb25zIG9uIOKAnHZpc2li bGXigJ0gZGF0YSwgd291bGRu4oCZdCB5b3UgYWxzbyB3YW50IHRvIHZlcmlmeSB0aGUgZGF0YT8N Cg0KUmVnYXJkcywNCkfDtnJhbg0KDQo+DQo+R3LDvMOfZSwgQ2Fyc3Rlbg0KDQo= From nobody Fri Sep 4 05:18: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 33E141B2C71 for ; Fri, 4 Sep 2015 05:18:18 -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 kIfozoIk7S4e for ; Fri, 4 Sep 2015 05:18:16 -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 95BAF1B3B3C for ; Fri, 4 Sep 2015 05:16:43 -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 t84CGbRD024164; Fri, 4 Sep 2015 14:16:37 +0200 (CEST) Received: from alma.local (unknown [134.102.117.150]) (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 3n6yfY02xJzDKXy; Fri, 4 Sep 2015 14:16:36 +0200 (CEST) Message-ID: <55E98BA3.3040106@tzi.org> Date: Fri, 04 Sep 2015 14:16:35 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <55E5C717.8080900@gmx.net> <55E5D2FE.3060301@tzi.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Hannes Tschofenig , "Cuellar, Jorge" , "core@ietf.org" Subject: Re: [core] [Ace] COSE requirements from CORE/ACE 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, 04 Sep 2015 12:18:18 -0000 G枚ran Selander wrote: >>> Ideally, we want to have encryption as often as we can. >> > >> >That is the mantra when there is personally identifiable information >> >involved. >> > >> >In REST, we also have an important property called "visibility". >> >Where visibility and privacy are in conflict, the latter usually wins. >> >They aren't always. > > Does that mean that we need MAC-only or not? Yes. > If you are basing significant > actions on 鈥渧isible鈥 data, wouldn鈥檛 you also want to verify the data? You might want to. However, the party benefiting from the visibility is not necessary a party to the security associations that allow integrity checks on the data. So that may limit what you can do. Gr眉脽e, Carsten From nobody Fri Sep 4 06:17: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 BED961B2D43 for ; Fri, 4 Sep 2015 06:17: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 WieEEz5-hkYj for ; Fri, 4 Sep 2015 06:17:30 -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 76D611B2CBE for ; Fri, 4 Sep 2015 06:17:29 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-96-55e999e77419 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9C.DC.17026.7E999E55; Fri, 4 Sep 2015 15:17:27 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.14]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Fri, 4 Sep 2015 15:17:27 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann Thread-Topic: [core] [Ace] COSE requirements from CORE/ACE Thread-Index: AQHQ5MykKuSi+Gv28UKsvNSZTz7UMp4nvFAAgASMtwD//+LtgIAAMoUA Date: Fri, 4 Sep 2015 13:17:26 +0000 Message-ID: References: <55E5C717.8080900@gmx.net> <55E5D2FE.3060301@tzi.org> <55E98BA3.3040106@tzi.org> In-Reply-To: <55E98BA3.3040106@tzi.org> 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.16] Content-Type: text/plain; charset="utf-8" Content-ID: <1D92B8F38D54C1459470BA9ED627A69E@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM+Jvje7zmS9DDa4s07M4MuUuq8W+t+uZ LW7OOMVkcevsIlYHFo8189YweixZ8pPJY/vJSUwe0xZlBrBEcdmkpOZklqUW6dslcGV8unqf rWAPZ8Wt/uXMDYxzOLsYOTkkBEwkvl/uYISwxSQu3FvP1sXIxSEkcJRRYtb+lewQziJGiRf7 L7KCVLEJuEg8aHjEBGKLCChJXLi4hg3EZhZoYpTofqMNYgsLWEp07WuCqrGSaJjWB2W7SRxa cBfMZhFQkVj3YBqYzStgIXHs1mtmEFtIoJtRou1uCojNKaAu8bCvHew6RqDrvp9awwSxS1zi 1pP5TBBXC0gs2XOeGcIWlXj5+B/YnaICehIrrzexQcQVJXaebQeq4QDq1ZRYv0sfYoy1xLLv 01kgbEWJKd0P2SHOEZQ4OfMJywRgECDZNguhexaS7llIumch6V7AyLqKUbQ4tbg4N93IWC+1 KDO5uDg/Ty8vtWQTIzBWD275rbuDcfVrx0OMAhyMSjy8Cr9fhAqxJpYVV+YeYpTmYFES521h ehAqJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdH8lNtN7a8lvxWfJ1hPeWSenCnadLLhbe1m b54n8xNfZ0rkOEh8l+C/JOvZfoOB5++LyVPPrrYPY645e2ECl1ly02z5RNuoy89yD0XFLtI7 /GBftK7T5cXq4T4s9h8tL57QCfh/NVek1Ld5Sd76d/1PM2c0PFb1W/im49DnPdFMUVcPxH4y eKbEUpyRaKjFXFScCAAAnHZxtgIAAA== Archived-At: Cc: Hannes Tschofenig , "Cuellar, Jorge" , "core@ietf.org" Subject: Re: [core] [Ace] COSE requirements from CORE/ACE 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, 04 Sep 2015 13:17:31 -0000 DQoNCk9uIDIwMTUtMDktMDQgMTQ6MTYsICJDYXJzdGVuIEJvcm1hbm4iIDxjYWJvQHR6aS5vcmc+ IHdyb3RlOg0KDQo+R8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KPj4+PiBJZGVhbGx5LCB3ZSB3YW50 IHRvIGhhdmUgZW5jcnlwdGlvbiBhcyBvZnRlbiBhcyB3ZSBjYW4uDQo+Pj4gPg0KPj4+ID5UaGF0 IGlzIHRoZSBtYW50cmEgd2hlbiB0aGVyZSBpcyBwZXJzb25hbGx5IGlkZW50aWZpYWJsZSBpbmZv cm1hdGlvbg0KPj4+ID5pbnZvbHZlZC4NCj4+PiA+DQo+Pj4gPkluIFJFU1QsIHdlIGFsc28gaGF2 ZSBhbiBpbXBvcnRhbnQgcHJvcGVydHkgY2FsbGVkICJ2aXNpYmlsaXR5Ii4NCj4+PiA+V2hlcmUg dmlzaWJpbGl0eSBhbmQgcHJpdmFjeSBhcmUgaW4gY29uZmxpY3QsIHRoZSBsYXR0ZXIgdXN1YWxs eSB3aW5zLg0KPj4+ID5UaGV5IGFyZW4ndCBhbHdheXMuDQo+PiANCj4+IERvZXMgdGhhdCBtZWFu IHRoYXQgd2UgbmVlZCBNQUMtb25seSBvciBub3Q/DQo+DQo+WWVzLg0KPg0KPj4gSWYgeW91IGFy ZSBiYXNpbmcgc2lnbmlmaWNhbnQNCj4+IGFjdGlvbnMgb24g4oCcdmlzaWJsZeKAnSBkYXRhLCB3 b3VsZG7igJl0IHlvdSBhbHNvIHdhbnQgdG8gdmVyaWZ5IHRoZSBkYXRhPw0KPg0KPllvdSBtaWdo dCB3YW50IHRvLiAgSG93ZXZlciwgdGhlIHBhcnR5IGJlbmVmaXRpbmcgZnJvbSB0aGUgdmlzaWJp bGl0eSBpcw0KPm5vdCBuZWNlc3NhcnkgYSBwYXJ0eSB0byB0aGUgc2VjdXJpdHkgYXNzb2NpYXRp b25zIHRoYXQgYWxsb3cgaW50ZWdyaXR5DQo+Y2hlY2tzIG9uIHRoZSBkYXRhLiAgU28gdGhhdCBt YXkgbGltaXQgd2hhdCB5b3UgY2FuIGRvLg0KDQpDb3VsZCB5b3UgcGxlYXNlIHByb3ZpZGUgYW4g ZXhhbXBsZT8NCg0KVGhhbmtzDQpHw7ZyYW4NCg0K From nobody Fri Sep 4 06:50: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 48AD41B4B68 for ; Fri, 4 Sep 2015 06:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.851 X-Spam-Level: X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_FR=0.35, 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 HhQDvGvLSVbo for ; Fri, 4 Sep 2015 06:50:00 -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 1B7CE1B4B5E for ; Fri, 4 Sep 2015 06:49:59 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.211]) by smtp-cloud2.xs4all.net with ESMTP id D1pw1r00f4ZF39u011pwPS; Fri, 04 Sep 2015 15:49:57 +0200 Received: from AMontpellier-654-1-89-216.w90-28.abo.wanadoo.fr ([90.28.128.216]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 04 Sep 2015 15:49:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 04 Sep 2015 15:49:56 +0200 From: peter van der Stok To: "Rahman, Akbar" Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F347AFBF4@NABESITE.InterDigital.com> References: <25093c7d75ade3f78e471b55816d0bac@xs4all.nl> <36F5869FE31AB24485E5E3222C288E1F347AFBF4@NABESITE.InterDigital.com> Message-ID: <9efa234430f9fa6be3895edffc09cb4e@xs4all.nl> X-Sender: stokcons@xs4all.nl (DvDTPMQckzz9SUlPAA8/I6r6Yqc61YNK) User-Agent: XS4ALL Webmail Archived-At: Cc: Michael Koster , Core Subject: Re: [core] pubsub and sleepy node proxy 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: Fri, 04 Sep 2015 13:50:03 -0000 Hi Akbar, thanks for your support. I once read the draft you mentioned, but forgot about it. I will return with some suggestions later next week, Peter Rahman, Akbar schreef op 2015-09-03 06:45: > Hi Peter, > > > I am still reading the pubsub draft, but did want to give support for > your sleepy node draft (draft-zotti-core-sleepy-nodes-03). The sleepy > node proxy concept that you describe will be useful in many scenarios. > One related comment that I did have on your draft is that it seems a > bit fixated on the 6LoWPAN scenario. But as we have discussed many > times during IETF meetings and on various mailing lists, the sleepy > node scenario is useful beyond 6LoWPAN deployments (e.g. > https://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01 ). > So I think it would be useful if you clarified that in your draft. > > > Best Regards, > > > Akbar > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der > Stok > Sent: Monday, August 31, 2015 3:06 AM > To: Michael Koster ; Core > Subject: [core] pubsub and sleepy node proxy > > Hi Michael, > > Looking at the pubsub draft and at our sleepy node proxy draft, I come > to the conclusion that there are good arguments to maintain both. > > Following the reasoning of Matthieu Vial, there are already a good > arguments for the sleepy node (SN) proxy (aka mirror server) to exist > next to the RD. > Namely: > Where an end-point can delegate its links to the RD for discovery, an > end-point can delegate the links AND the associated resource values to > the SN-proxy. > The SN-proxy resources have the same lifetime as SN resources. > The SN-proxy resource values are directly linked to the resources of a > given SN. > > In contrast the pubsub handles anonymous values. The origin can be > added but that means adding attributes to the topics. > The pubsub handles the more abstract topics, where the SN-proxy is > concerned with the resources. > The lifetime of the values in the pubsub server is not directly linked > to the lifetime of the originating resources. > > For me these are the arguments that motivate the existence of the > pubsub draft next to the sleepy node draft. > > Looking forward to your reaction. > > Greetings > Teresa and Peter > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sat Sep 5 06:14: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 67C131B5577 for ; Sat, 5 Sep 2015 06:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 8-so29c1V5MI for ; Sat, 5 Sep 2015 06:14:54 -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 387C71B5572 for ; Sat, 5 Sep 2015 06:14:54 -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 t85DElA8024815; Sat, 5 Sep 2015 15:14:47 +0200 (CEST) Received: from alma.local (p5DCCDB06.dip0.t-ipconnect.de [93.204.219.6]) (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 3n7bvB58pCzDK1r; Sat, 5 Sep 2015 15:14:46 +0200 (CEST) Message-ID: <55EAEAC4.3080309@tzi.org> Date: Sat, 05 Sep 2015 15:14:44 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <55E5C717.8080900@gmx.net> <55E5D2FE.3060301@tzi.org> <55E98BA3.3040106@tzi.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Hannes Tschofenig , "Cuellar, Jorge" , "core@ietf.org" Subject: Re: [core] [Ace] COSE requirements from CORE/ACE 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, 05 Sep 2015 13:14:55 -0000 >>>>> In REST, we also have an important property called "visibility". >>>>> Where visibility and privacy are in conflict, the latter usually wins. >>>>> They aren't always. >>> Does that mean that we need MAC-only or not? >> Yes. >> >>> If you are basing significant >>> actions on 鈥渧isible鈥 data, wouldn鈥檛 you also want to verify the data? >> You might want to. However, the party benefiting from the visibility is >> not necessary a party to the security associations that allow integrity >> checks on the data. So that may limit what you can do. > > Could you please provide an example? Sure. Imaging a scenario where we have a server that is an electricity meter, and a client that is some billing system controlled by the electricity vendor. The electricity meter provides regular updates of the energy consumed (or provided) to the billing system. These two nodes have a need for end-to-end integrity and therefore use a MAC. In this scenario, the meter does not talk directly to the billing system via IP, but uses another system in the home as a CoAP proxy. The confidentiality requirements are covered by using DTLS between the meter and the proxy as well as another DTLS connection between the proxy and the vendor. The proxy has a requirement for visibility here: It needs a way to ensure that only the data the home owner has agreed to provide actually makes it to the vendor. (It also may want to make use of these data for an independent in-home display; the integrity desired is also provided by the DTLS connection to the meter.) As usual in the multi-hop scenarios that benefit from DTLS, the proxy has a legitimate role in the conversation, with its own security requirements. Still, we need end-to-end security between the systems supplied by the electricity vendor, and this is where COSE would come in. Gr眉脽e, Carsten From nobody Sun Sep 6 08:17: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 B361A1B48A5 for ; Fri, 4 Sep 2015 05:54:00 -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 4PteWQvuens0 for ; Fri, 4 Sep 2015 05:53:58 -0700 (PDT) Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [146.101.78.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344001B48A2 for ; Fri, 4 Sep 2015 05:53:57 -0700 (PDT) Received: from emea-cam-gw2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-3-cait9I8rQ3GOJYnvq0J43w-1; Fri, 04 Sep 2015 13:53:55 +0100 Received: from EMEA-CAM-GW3.Emea.Arm.com (10.1.106.86) by emea-cam-gw2.Emea.Arm.com (10.1.105.150) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 4 Sep 2015 13:53:54 +0100 Received: from george.Emea.Arm.com ([fe80::4c19:a8f:5c9a:76df]) by EMEA-CAM-GW3.Emea.Arm.com ([::1]) with mapi; Fri, 4 Sep 2015 13:53:54 +0100 From: Hannes Tschofenig To: Carsten Bormann , =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= Date: Fri, 4 Sep 2015 13:49:38 +0100 Thread-Topic: [core] [Ace] COSE requirements from CORE/ACE Thread-Index: AdDnC44nR9Xr29+6SZOOiaINAKUM0gABIZGw Message-ID: References: <55E5C717.8080900@gmx.net> <55E5D2FE.3060301@tzi.org> <55E98BA3.3040106@tzi.org> In-Reply-To: <55E98BA3.3040106@tzi.org> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 X-MC-Unique: cait9I8rQ3GOJYnvq0J43w-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-Mailman-Approved-At: Sun, 06 Sep 2015 08:17:21 -0700 Cc: "Cuellar, Jorge" , "core@ietf.org" Subject: Re: [core] [Ace] COSE requirements from CORE/ACE 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, 04 Sep 2015 12:54:00 -0000 Q2Fyc3RlbiwNCg0KSSBkb24ndCB0aGluayB0aGVyZSBpcyBhIHJlcXVpcmVtZW50IGluIFJFU1Qg dGhhdCBzYXlzIGVhdmVzZHJvcHBlcnMgaGF2ZSB0byBiZSBhYmxlIHRvIHJlYWQgdGhlIGRhdGEu DQpUaGF0J3MgaGFyZCB0byBiZWxpZXZlLg0KDQpDaWFvDQpIYW5uZXMNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNhYm9AdHppLm9y Z10NClNlbnQ6IDA0IFNlcHRlbWJlciAyMDE1IDE5OjE3DQpUbzogR8O2cmFuIFNlbGFuZGVyDQpD YzogY29yZUBpZXRmLm9yZzsgQ3VlbGxhciwgSm9yZ2U7IEhhbm5lcyBUc2Nob2ZlbmlnDQpTdWJq ZWN0OiBSZTogW2NvcmVdIFtBY2VdIENPU0UgcmVxdWlyZW1lbnRzIGZyb20gQ09SRS9BQ0UNCg0K R8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KPj4+IElkZWFsbHksIHdlIHdhbnQgdG8gaGF2ZSBlbmNy eXB0aW9uIGFzIG9mdGVuIGFzIHdlIGNhbi4NCj4+ID4NCj4+ID5UaGF0IGlzIHRoZSBtYW50cmEg d2hlbiB0aGVyZSBpcyBwZXJzb25hbGx5IGlkZW50aWZpYWJsZSBpbmZvcm1hdGlvbg0KPj4gPmlu dm9sdmVkLg0KPj4gPg0KPj4gPkluIFJFU1QsIHdlIGFsc28gaGF2ZSBhbiBpbXBvcnRhbnQgcHJv cGVydHkgY2FsbGVkICJ2aXNpYmlsaXR5Ii4NCj4+ID5XaGVyZSB2aXNpYmlsaXR5IGFuZCBwcml2 YWN5IGFyZSBpbiBjb25mbGljdCwgdGhlIGxhdHRlciB1c3VhbGx5IHdpbnMuDQo+PiA+VGhleSBh cmVuJ3QgYWx3YXlzLg0KPg0KPiBEb2VzIHRoYXQgbWVhbiB0aGF0IHdlIG5lZWQgTUFDLW9ubHkg b3Igbm90Pw0KDQpZZXMuDQoNCj4gSWYgeW91IGFyZSBiYXNpbmcgc2lnbmlmaWNhbnQNCj4gYWN0 aW9ucyBvbiDigJx2aXNpYmxl4oCdIGRhdGEsIHdvdWxkbuKAmXQgeW91IGFsc28gd2FudCB0byB2 ZXJpZnkgdGhlIGRhdGE/DQoNCllvdSBtaWdodCB3YW50IHRvLiAgSG93ZXZlciwgdGhlIHBhcnR5 IGJlbmVmaXRpbmcgZnJvbSB0aGUgdmlzaWJpbGl0eSBpcyBub3QgbmVjZXNzYXJ5IGEgcGFydHkg dG8gdGhlIHNlY3VyaXR5IGFzc29jaWF0aW9ucyB0aGF0IGFsbG93IGludGVncml0eSBjaGVja3Mg b24gdGhlIGRhdGEuICBTbyB0aGF0IG1heSBsaW1pdCB3aGF0IHlvdSBjYW4gZG8uDQoNCkdyw7zD n2UsIENhcnN0ZW4NCg0KDQotLSBJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhp cyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNv IGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRo ZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBv ciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiAgVGhhbmsgeW91 Lg0KDQpBUk0gTGltaXRlZCwgUmVnaXN0ZXJlZCBvZmZpY2UgMTEwIEZ1bGJvdXJuIFJvYWQsIENh bWJyaWRnZSBDQjEgOU5KLCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcywgQ29tcGFueSBO bzogIDI1NTc1OTANCkFSTSBIb2xkaW5ncyBwbGMsIFJlZ2lzdGVyZWQgb2ZmaWNlIDExMCBGdWxi b3VybiBSb2FkLCBDYW1icmlkZ2UgQ0IxIDlOSiwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2Fs ZXMsIENvbXBhbnkgTm86ICAyNTQ4NzgyDQo= From nobody Mon Sep 7 11:31:59 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 080561B2BFB for ; Mon, 7 Sep 2015 11:31:58 -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_50=0.8, 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 8vzu1ND21QJR for ; Mon, 7 Sep 2015 11:31:55 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::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 A37DB1A9071 for ; Mon, 7 Sep 2015 11:31:55 -0700 (PDT) Received: by obuk4 with SMTP id k4so67018039obu.2 for ; Mon, 07 Sep 2015 11:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=XBkRDsCu67q0OVHHFBcwkPIsouOdSaUN0EQPI8037W0=; b=yeyhZLh4CWMXLFLV01h2VSX1YDyw6H0SpoEkML21rMtbVC5jxQBZalGxxcr55ScB3X 7L2C+JjBa9sBqrmQXuHCtsI6eOeGy6yu26pTLvs0Vzn2zBxfGyI3VN7xOI1sgJNCjmb5 RabeCh1tZ0oUI14bEQvi5ZYxSDJw6DF8Y4EeI0wXMpA0TF8DxpYW8gZRC7i9XrbHcV// uFbMpnYJYhSWCjsCq630wMK5gx8F/hKysrGze/+qYZm1YFa6gZ4YzH5wiG+/UQId2ZNg /7WvpBR8osEHJywLkAdOf2daNlrS/PszsC/olwzTIYJwCBCeuac6tlZSG7jL0kQcqice BqKw== X-Received: by 10.60.85.73 with SMTP id f9mr14395008oez.66.1441650715030; Mon, 07 Sep 2015 11:31:55 -0700 (PDT) MIME-Version: 1.0 References: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> <55CBACAD.9090401@gmx.net> <557A6C8AF976114EBAD8852183CF3F371D7A5A0A@SMTP1.etri.info> <55DC64AE.1030105@gmx.net> <55E79477.2060105@tzi.org> In-Reply-To: <55E79477.2060105@tzi.org> From: Simon Lemay Date: Mon, 07 Sep 2015 18:31:45 +0000 Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e0111d108c27a1c051f2c76e3 Archived-At: Cc: core@ietf.org 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, 07 Sep 2015 18:31:58 -0000 --089e0111d108c27a1c051f2c76e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, So there is only 2 people who have given there availability for the "hallway virtual meeting" (http://doodle.com/xti53ksybm95pzh4) (thanks you :)) So at this point, it might be better to Jump to the Virtual interim, and schedule it. I am not sure what the process it for that, but i would like to get it started so we can have the interim in 2 week. Chairmans, how can we get the ball rolling on this? Thanks Simon On Wed, Sep 2, 2015 at 5:29 PM Carsten Bormann wrote: > Simon Lemay wrote: > > Hi all, > > > > Sorry for the delay > > > > Carsten writes: > > "A new szx=3D7 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 block= s > > within an instance of a sequence-preserving transport. But I would > > write this up separately, not in this draft" > > > > I do like this idea for larger payload, where would the writing need to > > be? in the Block Draft? > > Procedurally, the Block Draft is done in the WG and is being submitted > to the IESG (any day now). > So the answer should be: A third draft, or we may want to pull this in > here in the TCP/TLS draft if this is really considered an indispensable > part of the TCP binding. > > > as for "new blocksize needs to be a clean fraction of the 1024byte > > block.", I ment multiplier (:P, my bad) to allow for block size message > > to be proxied, but this would require some testing to see > > how feasible and easy it is to implement > > Right; if this is about block-by-block proxying, this would still be a > bit icky because it's not easy to reconstruct the block number. > Prototyping is the right way to get this right, and that is another > reason for a third draft. > > > As for the length, since this is the last issue before we bring the > > draft as a working group item, I think it would be good to have a > > conference call with everybody who is interested in the subject to voic= e > > concern one more time, and come up with an unique approach > > > > i create a doodle, i added as much options as possible time wise to get > > the maximum amount of people. > > > > http://doodle.com/xti53ksybm95pzh4 > > As a WG chair, I need to point out that anything that is discussed on > such an informal call would be like a hallway discussion at an IETF; if > we really want to nail down things, we might call a virtual interim > (i.e., such a phone call formally announced with a two-week announcement > interval) -- but the two are not mutually exclusive. > > Gr=C3=BC=C3=9Fe, Carsten > --089e0111d108c27a1c051f2c76e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

So there is only 2 people who h= ave given there availability for the "hallway virtual meeting" (<= a href=3D"http://doodle.com/xti53ksybm95pzh4" rel=3D"noreferrer" target=3D"= _blank" style=3D"font-size:13.2px;line-height:19.8px">http://doodle.com/xti= 53ksybm95pzh4) =C2=A0(thanks you :))

So at thi= s point, it might be better to Jump to the Virtual interim, and schedule it= .=C2=A0 I am not sure what the process it for that, but i would like to get= it started so we can have the interim in 2 week.

= Chairmans, how can we get the ball rolling on this?

Thanks

Simon

On Wed, Sep 2, 2015 at 5:29 PM Carsten Bormann <= cabo@tzi.org> wrote:
Simon Lemay wrote:
> Hi all,
>
> Sorry for the delay
>
> Carsten writes:
> "A new szx=3D7 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 bloc= ks
> within an instance of a sequence-preserving transport.=C2=A0 But I wou= ld
> write this up separately, not in this draft"
>
> I do like this idea for larger payload, where would the writing need t= o
> be? in the Block Draft?

Procedurally, the Block Draft is done in the WG and is being submitted
to the IESG (any day now).
So the answer should be: A third draft, or we may want to pull this in
here in the TCP/TLS draft if this is really considered an indispensable
part of the TCP binding.

> as for "new blocksize needs to be a clean fraction of the 1024byt= e
> block.", I ment multiplier (:P, my bad) to allow for block size m= essage
> to be proxied, but this would require some testing to see
> how feasible and easy it is to implement

Right; if this is about block-by-block proxying, this would still be a
bit icky because it's not easy to reconstruct the block number.
Prototyping is the right way to get this right, and that is another
reason for a third draft.

> As for the length, since this is the last issue before we bring the > draft as a working group item,=C2=A0 I think it would be good to have = a
> conference call with everybody who is interested in the subject to voi= ce
> concern one more time, and come up with an unique approach
>
> i create a doodle, i added as much options as possible time wise to ge= t
> the maximum amount of people.
>
> http://doodle.com/xti53ksybm95pzh4

As a WG chair, I need to point out that anything that is discussed on
such an informal call would be like a hallway discussion at an IETF; if
we really want to nail down things, we might call a virtual interim
(i.e., such a phone call formally announced with a two-week announcement interval) -- but the two are not mutually exclusive.

Gr=C3=BC=C3=9Fe, Carsten
--089e0111d108c27a1c051f2c76e3-- From nobody Mon Sep 7 13:15: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 882E71B46FA for ; Mon, 7 Sep 2015 13:15: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 qbmPFCjSU_CP for ; Mon, 7 Sep 2015 13:15:23 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD741B4629 for ; Mon, 7 Sep 2015 13:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t87KF2eq001966; Mon, 7 Sep 2015 22:15:03 +0200 (CEST) Received: from alma.local (p5DCCDB06.dip0.t-ipconnect.de [93.204.219.6]) (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 3n91796qc8z4tX8; Mon, 7 Sep 2015 22:15:01 +0200 (CEST) Message-ID: <55EDF044.5020304@tzi.org> Date: Mon, 07 Sep 2015 22:15:00 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: Simon Lemay References: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> <55CBACAD.9090401@gmx.net> <557A6C8AF976114EBAD8852183CF3F371D7A5A0A@SMTP1.etri.info> <55DC64AE.1030105@gmx.net> <55E79477.2060105@tzi.org> 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] 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, 07 Sep 2015 20:15:23 -0000 Simon Lemay wrote: > Chairmans, how can we get the ball rolling on this? Hmm. Do people even care about the issue? Should Andrew toss a coin? We should schedule a virtual interim if we can get a bit more than three people to join. Maybe we should start with another doodle? Gr眉脽e, Carsten From nobody Tue Sep 8 03:41: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 2BEBE1AD2C4 for ; Tue, 8 Sep 2015 03:41:12 -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 qn1Rer0c-1rG for ; Tue, 8 Sep 2015 03:41:10 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E281AD2B2 for ; Tue, 8 Sep 2015 03:41:09 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-07-55eebb42f234 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1E.5D.27359.24BBEE55; Tue, 8 Sep 2015 12:41:07 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.214]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Tue, 8 Sep 2015 12:41:06 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann Thread-Topic: [core] [Ace] COSE requirements from CORE/ACE Thread-Index: AQHQ5MykKuSi+Gv28UKsvNSZTz7UMp4nvFAAgASMtwD//+LtgIAAMoUAgAFwDwCABK2XAA== Date: Tue, 8 Sep 2015 10:41:05 +0000 Message-ID: References: <55E5C717.8080900@gmx.net> <55E5D2FE.3060301@tzi.org> <55E98BA3.3040106@tzi.org> <55EAEAC4.3080309@tzi.org> In-Reply-To: <55EAEAC4.3080309@tzi.org> 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.18] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM+Jvja7z7nehBk27BS2OTLnLarHv7Xpm i5szTjFZ3Dq7iNWBxWPNvDWMHkuW/GTy2H5yEpPHtEWZASxRXDYpqTmZZalF+nYJXBln/kxn KTggVTHxwlPWBsYXkl2MnBwSAiYSk8//YIawxSQu3FvP1sXIxSEkcJRRYufRm2wgCSGBxYwS b6dUg9hsAi4SDxoeMYHYIgJKEhcurgGrYRZoYpTofqMNYgsLWEp07WuCqrGSaJjWB2WHSfy6 fIwFxGYRUJHYPf0JI4jNK2AhcXrLbGaIxVcZJf6s6gQr4hRQl/j44inYdYxA130/tYYJYpm4 xK0n85kgrhaQWLLnPNQHohIvH/9jBbFFBfQkVl5vYoOIK0p8fLUPaBkHUK+mxPpd+hBjrCWO 3pvLCGErSkzpfsgOcY+gxMmZT1gmMErMQrJtFkL3LCTds5B0z0LSvYCRdRWjaHFqcVJuupGR XmpRZnJxcX6eXl5qySZGYKwe3PLbYAfjy+eOhxgFOBiVeHgTK9+FCrEmlhVX5h5ilOZgURLn bWZ6ECokkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUWC1WLJlZKV28u8Zjt1b0pQ+Xe2xUJGU Oj2B13VVebfBoiZ1uSZBGa6q6U9vd/zXj75prhu/PzzMvHJF3NTi0s2Pjx9Vivr4fdPzT3/W FvRL2JtKTpD5caGMIcJ3x5pWP+1LpftLzmSJ7D6VLNydJnnxTdulT2GCW/WuGTULm3Ytju1g l0lTYinOSDTUYi4qTgQAvAGIebYCAAA= Archived-At: Cc: Hannes Tschofenig , "Cuellar, Jorge" , "core@ietf.org" Subject: Re: [core] [Ace] COSE requirements from CORE/ACE 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, 08 Sep 2015 10:41:12 -0000 DQoNCk9uIDIwMTUtMDktMDUgMTU6MTQsICJDYXJzdGVuIEJvcm1hbm4iIDxjYWJvQHR6aS5vcmc+ IHdyb3RlOg0KDQo+Pj4+Pj4gSW4gUkVTVCwgd2UgYWxzbyBoYXZlIGFuIGltcG9ydGFudCBwcm9w ZXJ0eSBjYWxsZWQgInZpc2liaWxpdHkiLg0KPj4+Pj4+IFdoZXJlIHZpc2liaWxpdHkgYW5kIHBy aXZhY3kgYXJlIGluIGNvbmZsaWN0LCB0aGUgbGF0dGVyIHVzdWFsbHkNCj4+Pj4+PndpbnMuDQo+ Pj4+Pj4gVGhleSBhcmVuJ3QgYWx3YXlzLg0KPj4+PiBEb2VzIHRoYXQgbWVhbiB0aGF0IHdlIG5l ZWQgTUFDLW9ubHkgb3Igbm90Pw0KPj4+IFllcy4NCj4+Pg0KPj4+PiBJZiB5b3UgYXJlIGJhc2lu ZyBzaWduaWZpY2FudA0KPj4+PiBhY3Rpb25zIG9uIOKAnHZpc2libGXigJ0gZGF0YSwgd291bGRu 4oCZdCB5b3UgYWxzbyB3YW50IHRvIHZlcmlmeSB0aGUgZGF0YT8NCj4+PiBZb3UgbWlnaHQgd2Fu dCB0by4gIEhvd2V2ZXIsIHRoZSBwYXJ0eSBiZW5lZml0aW5nIGZyb20gdGhlIHZpc2liaWxpdHkN Cj4+PmlzDQo+Pj4gbm90IG5lY2Vzc2FyeSBhIHBhcnR5IHRvIHRoZSBzZWN1cml0eSBhc3NvY2lh dGlvbnMgdGhhdCBhbGxvdyBpbnRlZ3JpdHkNCj4+PiBjaGVja3Mgb24gdGhlIGRhdGEuICBTbyB0 aGF0IG1heSBsaW1pdCB3aGF0IHlvdSBjYW4gZG8uDQo+PiANCj4+IENvdWxkIHlvdSBwbGVhc2Ug cHJvdmlkZSBhbiBleGFtcGxlPw0KPg0KPlN1cmUuDQo+DQo+SW1hZ2luZyBhIHNjZW5hcmlvIHdo ZXJlIHdlIGhhdmUgYSBzZXJ2ZXIgdGhhdCBpcyBhbiBlbGVjdHJpY2l0eSBtZXRlciwNCj5hbmQg YSBjbGllbnQgdGhhdCBpcyBzb21lIGJpbGxpbmcgc3lzdGVtIGNvbnRyb2xsZWQgYnkgdGhlIGVs ZWN0cmljaXR5DQo+dmVuZG9yLiAgVGhlIGVsZWN0cmljaXR5IG1ldGVyIHByb3ZpZGVzIHJlZ3Vs YXIgdXBkYXRlcyBvZiB0aGUgZW5lcmd5DQo+Y29uc3VtZWQgKG9yIHByb3ZpZGVkKSB0byB0aGUg YmlsbGluZyBzeXN0ZW0uICBUaGVzZSB0d28gbm9kZXMgaGF2ZSBhDQo+bmVlZCBmb3IgZW5kLXRv LWVuZCBpbnRlZ3JpdHkgYW5kIHRoZXJlZm9yZSB1c2UgYSBNQUMuDQo+DQo+SW4gdGhpcyBzY2Vu YXJpbywgdGhlIG1ldGVyIGRvZXMgbm90IHRhbGsgZGlyZWN0bHkgdG8gdGhlIGJpbGxpbmcgc3lz dGVtDQo+dmlhIElQLCBidXQgdXNlcyBhbm90aGVyIHN5c3RlbSBpbiB0aGUgaG9tZSBhcyBhIENv QVAgcHJveHkuICBUaGUNCj5jb25maWRlbnRpYWxpdHkgcmVxdWlyZW1lbnRzIGFyZSBjb3ZlcmVk IGJ5IHVzaW5nIERUTFMgYmV0d2VlbiB0aGUgbWV0ZXINCj5hbmQgdGhlIHByb3h5IGFzIHdlbGwg YXMgYW5vdGhlciBEVExTIGNvbm5lY3Rpb24gYmV0d2VlbiB0aGUgcHJveHkgYW5kDQo+dGhlIHZl bmRvci4gIFRoZSBwcm94eSBoYXMgYSByZXF1aXJlbWVudCBmb3IgdmlzaWJpbGl0eSBoZXJlOiBJ dCBuZWVkcyBhDQo+d2F5IHRvIGVuc3VyZSB0aGF0IG9ubHkgdGhlIGRhdGEgdGhlIGhvbWUgb3du ZXIgaGFzIGFncmVlZCB0byBwcm92aWRlDQo+YWN0dWFsbHkgbWFrZXMgaXQgdG8gdGhlIHZlbmRv ci4gIChJdCBhbHNvIG1heSB3YW50IHRvIG1ha2UgdXNlIG9mIHRoZXNlDQo+ZGF0YSBmb3IgYW4g aW5kZXBlbmRlbnQgaW4taG9tZSBkaXNwbGF5OyB0aGUgaW50ZWdyaXR5IGRlc2lyZWQgaXMgYWxz bw0KPnByb3ZpZGVkIGJ5IHRoZSBEVExTIGNvbm5lY3Rpb24gdG8gdGhlIG1ldGVyLikNCj4NCj5B cyB1c3VhbCBpbiB0aGUgbXVsdGktaG9wIHNjZW5hcmlvcyB0aGF0IGJlbmVmaXQgZnJvbSBEVExT LCB0aGUgcHJveHkNCj5oYXMgYSBsZWdpdGltYXRlIHJvbGUgaW4gdGhlIGNvbnZlcnNhdGlvbiwg d2l0aCBpdHMgb3duIHNlY3VyaXR5DQo+cmVxdWlyZW1lbnRzLiAgU3RpbGwsIHdlIG5lZWQgZW5k LXRvLWVuZCBzZWN1cml0eSBiZXR3ZWVuIHRoZSBzeXN0ZW1zDQo+c3VwcGxpZWQgYnkgdGhlIGVs ZWN0cmljaXR5IHZlbmRvciwgYW5kIHRoaXMgaXMgd2hlcmUgQ09TRSB3b3VsZCBjb21lIGluLg0K DQpZZXMsIEkgdGhpbmsgdGhhdCBpcyBhIGdvb2QgZXhhbXBsZS4gVGhlcmUgYXJlIGtleXMgZXN0 YWJsaXNoZWQgYW5kIGRhdGENCmNhbiBiZSB2ZXJpZmllZCBieSB0aGUgaW50ZXJtZWRpYXRlLCBi dXQgdXNpbmcgYSBkaWZmZXJlbnQgcHJvdG9jb2wuDQoNClNvLCB1bmxlc3MgdGhlcmUgYXJlIGZ1 cnRoZXIgY29tbWVudHMsIEkgdGFrZSBpdCB0aGUgYW5zd2VyIHRvIOKAnDIuDQpNQUMtb25seT/i gJ0gaXMg4oCceWVz4oCdLg0KDQpBbnkgb3BpbmlvbnMgb24gdGhlIG90aGVyIHR3byBxdWVzdGlv bnM/DQoNCijigJwxLiBNZXNzYWdlIHNpemXigJ0gYW5kIOKAnDMuIFN5bW1ldHJpYyBlbmNyeXB0 aW9uICsgYXN5bW1ldHJpYyBzaWduYXR1cmXigJ0sDQpzZWU6DQpodHRwOi8vbWFpbGFyY2hpdmUu aWV0Zi5vcmcvYXJjaC9tc2cvY29yZS9iczRkSkNCa1Y1Z0dkeUp3dDlSR1AzdmdQRzgNCikNCg0K UmVnYXJkcw0KR8O2cmFuDQoNCg0KDQoNCg== From nobody Tue Sep 8 04:06: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 670E61B3C50 for ; Tue, 8 Sep 2015 04:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 EH1TYjII9Zam for ; Tue, 8 Sep 2015 04:06:45 -0700 (PDT) Received: from smtp2.ugent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id 49AAC1B2E3F for ; Tue, 8 Sep 2015 04:06:45 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp2.ugent.be (Postfix) with ESMTP id 7186612C4A4; Tue, 8 Sep 2015 13:06:44 +0200 (CEST) X-Virus-Scanned: by UGent DICT Received: from smtp2.ugent.be ([IPv6:::ffff:157.193.49.126]) by localhost (mcheck2.UGent.be [::ffff:157.193.43.11]) (amavisd-new, port 10024) with ESMTP id wUuIiLvAd_kf; Tue, 8 Sep 2015 13:06:43 +0200 (CEST) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp2.ugent.be (Postfix) with ESMTP id 682FF12C48B; Tue, 8 Sep 2015 13:06:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id 344F82E; Tue, 8 Sep 2015 13:06:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7ckPiphpvnX; Tue, 8 Sep 2015 13:06:43 +0200 (CEST) Received: from [157.193.135.182] (dhcp-zdpt-182.intec.ugent.be [157.193.135.182]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fvdabeele) by mail2.intec.ugent.be (Postfix) with ESMTPSA id 1A30D2D; Tue, 8 Sep 2015 13:06:43 +0200 (CEST) From: Floris Van den Abeele To: Carsten Bormann References: <55D1EB00.2050006@tzi.org> X-Enigmail-Draft-Status: N1110 Message-ID: <55EEC142.5020303@intec.ugent.be> Date: Tue, 8 Sep 2015 13:06:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55D1EB00.2050006@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Miltered: at jchkm1 with ID 55EEC143.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 55EEC143.000 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 55EEC143.000 on smtp2.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Publicly accessible Resource Directory? 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, 08 Sep 2015 11:06:47 -0000 I've put up an IPv6-only public RD at coap://rd.iot.test.iminds.be or coap://[2001:6a8:1d80:23::155] (coaps is also supported but it is a bit shaky). The implementation is lagging behind the I-d quite a bit: e.g. there is no support for groups/json/cbor/pagination at the moment, nor any other changes since draft-shelby-core-resource-directory-04 (so beginning 2013). It is also rather picky about registration requests: you should always specify a content-type option. I'll look into bringing the implementation up to speed, but can't promise anything short term. Groeten, Floris On 17-08-15 16:09, Carsten Bormann wrote: > Which CoAP resource directories are out there for people to play with? > (Sadly, coap.me doesn't have one yet.) > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > From nobody Tue Sep 8 07:59:47 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 6B3131B35B4 for ; Tue, 8 Sep 2015 07:59:46 -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 ZjXW_RJWe3ak for ; Tue, 8 Sep 2015 07:59: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 2F3AF1B3302 for ; Tue, 8 Sep 2015 07:59:43 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 6A670428C2; Tue, 8 Sep 2015 16:59:40 +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 A481023; Tue, 8 Sep 2015 16:59:39 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 7BCC9CF; Tue, 8 Sep 2015 16:59:39 +0200 (CEST) Received: (nullmailer pid 31693 invoked by uid 1000); Tue, 08 Sep 2015 14:59:30 -0000 Date: Tue, 8 Sep 2015 16:59:30 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Peter van der Stok Message-ID: <20150908145930.GB4537@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R+My9LyyhiUvIEro" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: core@ietf.org Subject: [core] Concurrent modifications suggestion in draft-vanderstok-core-patch-01 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, 08 Sep 2015 14:59:46 -0000 --R+My9LyyhiUvIEro Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Peter, after reading through draft-vanderstok-core-patch-01, I'm curious about the "Concurrent modification" (more than one incoming patch at the same time) error handling recommendation: Why 4.09 (Conflict)? As I'd currently implement a client, this would cause re-fetching and three-way merging happiness and/or user interaction, while the 5.03 I'd rather expect in such a situation ("Hold your horses, I can't apply two patches at once") would just have the client retry again, and, unless there is a real 4.09 Conflict, send a successful response. Hoping this is not considered premature nitpicking 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 --R+My9LyyhiUvIEro Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJV7vfKAAoJEDmNERLTpL3hsz8QAI5ACa3G+dk/Gcks2BN6LX3R F0sIStcUF1u6rnYd4pXSwNSqNyucULIbISwBmrN3Md8PD4KNV3F90KD4WQbXPea/ hhk0KB9zIy47nN2KkjgVWHxhvM1LERRnmz1I5iw1MOJNVw8tZ7+zxBL7ctm55x2w QFQz1lx0hPLMekirfn2iWU3GJKf3h/X8HInT+zF04wMB444j4ali28NVFbRXs/z0 HMDNwE9AR+0BIpoC+bv6k1MnlbfUbVAwWfnWoRSvxHkUIMXXh3RV2LrTWuhuopxc kxJCCgeMhILbWbLHoHCL3IL+4Ix+kJ8ufSzdXhjUJt/UfrmxqFNV8lTzbSZm89nm D34UVWBmv6sshy+QHoddXftr0P+5g2HuvF1ajEUinflvrlFgdUSDxrkuE8HGpMiz QuG9MuuIePv1tT8UtGK6QT2Hy9ZmiuNUxVezn+5MCgz1TxTAheFRbQTga2aCIHRr R/Jdp3I/tIb609q8H59hsZ4hRh7yLMbMeqFDYnPXqZIJDMCPpP+MRsxMA7XHV9Tm ZCNgAStG8YKE67yzGJOFjjWdFr/NHuBeCRjY8hJFqm/On+vMiEhpFgFlrlZ001Sr 0XeERGICjI3FI6chmGIJMRTFaR98y+nH6E8UOswgjAQxyBJ8SYBaS2fTLITEAjpz GldJK/cn3QN2HrWuKxwD =szJe -----END PGP SIGNATURE----- --R+My9LyyhiUvIEro-- From nobody Tue Sep 8 13:34: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 58E9E1B2B05 for ; Tue, 8 Sep 2015 13:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 uC1hZWzLScEJ for ; Tue, 8 Sep 2015 13:34:29 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (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 DC43D1AD1F5 for ; Tue, 8 Sep 2015 13:34:28 -0700 (PDT) Received: by obbbh8 with SMTP id bh8so93960692obb.0 for ; Tue, 08 Sep 2015 13:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=BiWtPGItJt00rvvwaho3NKuTD7yON8FJwHq6+OBNTwc=; b=uM1HOpyK/7J7et6/RzKWVCd4ANv945OOWT3xbI9WA2rjuecyM46xUWvr10AAtlQ2+Y FJozwpvxFA7nTDErO5dpUyASiZqc4wy8kP9wUT1cFvYx128T70pOZKJQv++eiO01z+ue VSjdERHNqnP1V0B7Opd9avtIxUT3JJaJpfy2MnDpL7Ir5arn+HjLtz6yxxu34HXJ/3hB o8l5l6CWb6+mR8SjAZSqcztrFc0ZiarfMsbfUHY8PChWvjidNbdabr/eplHGWN6lXwz6 rQEO0ZJxctiSCNok0dI3fCLDi1Qsb2gza6f65pYqQTsS+nglOPyfK6/nx5xi6nJIX5Cv yQAg== X-Received: by 10.182.44.198 with SMTP id g6mr22589104obm.25.1441744468289; Tue, 08 Sep 2015 13:34:28 -0700 (PDT) MIME-Version: 1.0 References: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> <55CBACAD.9090401@gmx.net> <557A6C8AF976114EBAD8852183CF3F371D7A5A0A@SMTP1.etri.info> <55DC64AE.1030105@gmx.net> <55E79477.2060105@tzi.org> <55EDF044.5020304@tzi.org> In-Reply-To: <55EDF044.5020304@tzi.org> From: Simon Lemay Date: Tue, 08 Sep 2015 20:34:18 +0000 Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c2e8fee3af62051f424aac Archived-At: Cc: core@ietf.org 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: Tue, 08 Sep 2015 20:34:30 -0000 --001a11c2e8fee3af62051f424aac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes i think we should start a Doodle for the interim meeting. Thanks Simon On Mon, Sep 7, 2015 at 1:15 PM Carsten Bormann wrote: > Simon Lemay wrote: > > Chairmans, how can we get the ball rolling on this? > > Hmm. Do people even care about the issue? Should Andrew toss a coin? > > We should schedule a virtual interim if we can get a bit more than three > people to join. Maybe we should start with another doodle? > > Gr=C3=BC=C3=9Fe, Carsten > --001a11c2e8fee3af62051f424aac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes i think we should start a Doodle for the interim meeti= ng.

Thanks

Simon
On Mon, Sep 7, 2015 at 1:15 PM= Carsten Bormann <cabo@tzi.org> w= rote:
Simon Lemay wrote:
> Chairmans, how can we get the ball rolling on this?

Hmm.=C2=A0 Do people even care about the issue?=C2=A0 Should Andrew toss a = coin?

We should schedule a virtual interim if we can get a bit more than three people to join.=C2=A0 Maybe we should start with another doodle?

Gr=C3=BC=C3=9Fe, Carsten
--001a11c2e8fee3af62051f424aac-- From nobody Wed Sep 9 00:27: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 719E71A88DC for ; Wed, 9 Sep 2015 00:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.449 X-Spam-Level: X-Spam-Status: No, score=0.449 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, 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 d3-x4GjKqVWu for ; Wed, 9 Sep 2015 00:27:32 -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 D26991B3D8D for ; Wed, 9 Sep 2015 00:27:31 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.204]) by smtp-cloud3.xs4all.net with ESMTP id EvTU1r00L4QBLo201vTUZZ; Wed, 09 Sep 2015 09:27:29 +0200 Received: from AMontpellier-654-1-89-216.w90-28.abo.wanadoo.fr ([90.28.128.216]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 09 Sep 2015 09:27:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 09 Sep 2015 09:27:28 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <20150908145930.GB4537@hephaistos.amsuess.com> Message-ID: X-Sender: stokcons@xs4all.nl (RiaT29EI3817aTrPjT9Z27VvCF0UB8eq) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] Fwd: Re: Concurrent modifications suggestion in draft-vanderstok-core-patch-01 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, 09 Sep 2015 07:27:34 -0000 Hi Christian, thanks for the remark. We were rather hoping that reactions on the error codes, like yours, would be sent in. 409 is a http code, but 4.09 is not cited in RFC7252, and is new to CoAP. The text for 409 in http/1.1 status code registry is below, for a reminder: ---------- The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required. Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type. ----------- It looks rather appropriate. 503 is used in "temporary" overload situations independent of server state, but (contrary to 4.09) is defined in 7252. I assume you have no other clients which implemented code for 4.09. So you are free to code it as appropriate. Do you suggest that additional information should be included in the 4.09 return code? Looking forward to hear additional details. Peter PS May be you could explain what "re-fetching and three-way merging happiness and/or user interaction" means. For the moment I am guessing. Peter Christian Ams眉ss schreef op 2015-09-08 16:59: > Hello Peter, > > after reading through draft-vanderstok-core-patch-01, I'm curious about > the "Concurrent modification" (more than one incoming patch at the same > time) error handling recommendation: Why 4.09 (Conflict)? > > As I'd currently implement a client, this would cause re-fetching and > three-way merging happiness and/or user interaction, while the 5.03 I'd > rather expect in such a situation ("Hold your horses, I can't apply two > patches at once") would just have the client retry again, and, unless > there is a real 4.09 Conflict, send a successful response. > > Hoping this is not considered premature nitpicking > Christian From nobody Wed Sep 9 03: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 157961B36BB for ; Wed, 9 Sep 2015 03:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, 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 ji7mi7Kio60Z for ; Wed, 9 Sep 2015 03:19:06 -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 6F7291B3658 for ; Wed, 9 Sep 2015 03:19:05 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.204]) by smtp-cloud3.xs4all.net with ESMTP id EyJw1r0074QBLo201yJwlj; Wed, 09 Sep 2015 12:18:56 +0200 Received: from AMontpellier-654-1-89-216.w90-28.abo.wanadoo.fr ([90.28.128.216]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 09 Sep 2015 12:18:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 09 Sep 2015 12:18:56 +0200 From: peter van der Stok To: "Rahman, Akbar" Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F347AFBF4@NABESITE.InterDigital.com> References: <25093c7d75ade3f78e471b55816d0bac@xs4all.nl> <36F5869FE31AB24485E5E3222C288E1F347AFBF4@NABESITE.InterDigital.com> Message-ID: X-Sender: stokcons@xs4all.nl (Zkbgfk2euh4DXA3BuMRhufyJLgq8yTHm) User-Agent: XS4ALL Webmail Archived-At: Cc: Michael Koster , Core Subject: Re: [core] pubsub and sleepy node proxy 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, 09 Sep 2015 10:19:09 -0000 Hi Akbar, After reading the arkko-core-sleepy draft I do have some concrete questions for you: Do you want the following additions to the proxy: - a http endpoint - storage of historical values - numbering of messages by sleepy node to estimate the reliability and to order them - Use of NON messages from sleepy to proxy In the arkko draft there is considerable motivation of design choices. Do you want more design motivation in the our zotti-core-sleepy draft? Is there anything specific I did not pick up? Thanks for your reaction, Peter Rahman, Akbar schreef op 2015-09-03 06:45: > Hi Peter, > > > I am still reading the pubsub draft, but did want to give support for > your sleepy node draft (draft-zotti-core-sleepy-nodes-03). The sleepy > node proxy concept that you describe will be useful in many scenarios. > One related comment that I did have on your draft is that it seems a > bit fixated on the 6LoWPAN scenario. But as we have discussed many > times during IETF meetings and on various mailing lists, the sleepy > node scenario is useful beyond 6LoWPAN deployments (e.g. > https://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01 ). > So I think it would be useful if you clarified that in your draft. > > > Best Regards, > > > Akbar > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der > Stok > Sent: Monday, August 31, 2015 3:06 AM > To: Michael Koster ; Core > Subject: [core] pubsub and sleepy node proxy > > Hi Michael, > > Looking at the pubsub draft and at our sleepy node proxy draft, I come > to the conclusion that there are good arguments to maintain both. > > Following the reasoning of Matthieu Vial, there are already a good > arguments for the sleepy node (SN) proxy (aka mirror server) to exist > next to the RD. > Namely: > Where an end-point can delegate its links to the RD for discovery, an > end-point can delegate the links AND the associated resource values to > the SN-proxy. > The SN-proxy resources have the same lifetime as SN resources. > The SN-proxy resource values are directly linked to the resources of a > given SN. > > In contrast the pubsub handles anonymous values. The origin can be > added but that means adding attributes to the topics. > The pubsub handles the more abstract topics, where the SN-proxy is > concerned with the resources. > The lifetime of the values in the pubsub server is not directly linked > to the lifetime of the originating resources. > > For me these are the arguments that motivate the existence of the > pubsub draft next to the sleepy node draft. > > Looking forward to your reaction. > > Greetings > Teresa and Peter > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Sep 9 03:35: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 2F2A61A00D0 for ; Wed, 9 Sep 2015 03:35:18 -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 feElfXr0RU1H for ; Wed, 9 Sep 2015 03:35:16 -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 733641A00E4 for ; Wed, 9 Sep 2015 03:35:14 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 2CD9C428C0; Wed, 9 Sep 2015 12:35:12 +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 2D3CB23; Wed, 9 Sep 2015 12:35:11 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [213.129.230.10]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id B4ABC2E; Wed, 9 Sep 2015 12:35:10 +0200 (CEST) Received: (nullmailer pid 13347 invoked by uid 1000); Wed, 09 Sep 2015 10:11:33 -0000 Date: Wed, 9 Sep 2015 12:11:33 +0200 From: Christian =?iso-8859-1?B?QW1z/N9z?= To: consultancy@vanderstok.org Message-ID: <20150909101133.GD4537@hephaistos.amsuess.com> References: <20150908145930.GB4537@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xB0nW4MQa6jZONgY" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Core Subject: Re: [core] Concurrent modifications suggestion in draft-vanderstok-core-patch-01 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, 09 Sep 2015 10:35:18 -0000 --xB0nW4MQa6jZONgY Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Peter, The point I'd fokus on in the 4(.)09 description is > The request could not be completed due to a conflict with the current > *state of the resource*. =2E As PATCH is supposed to be atomic, by the time the conflicting second request arrives, the resource's state can be the original or the altered state; let's for the sake of the argument assume that the patches would apply cleanly in either sequence. The "Concurrent modification" situation happens because the requests "cannot be queued", which in my opinion matches well with RFC 2616's description of "temporary overloading". > 503 is used in "temporary" overload situations independent of server stat= e, I assume you mean resource state here -- as far as I understand, 503 is precisely about the server's (the process's) state. > This code is only allowed in situations where it is > expected that the user might be able to resolve the conflict and resubmit > the request. The response body SHOULD include enough This is why I mentioned "re-fetching an three-way merging...", so I'll explain: If a client sees 4.09, they would be required to resolve the conflict. This would normally mean fetching the resource again, and constructing a new resource state that contains both the changes done on the server since the client last fetched it and the client's own changes. (Whether this is implemented as a three-way merge[1] or else is an implementation detail, but in any case has potential of being messy). The client may even need to call for user interaction because it can't do any merging by itself, or (as I'd expect of many tiny embedded implementations) indicate failure. That is a comparatively complex process that might, as in the example above with the two PATCH requests applying cleanly in either order, be completely uncalled for, and the more sane behavior would be for the client to try sending its request again after some seconds -- *then* both will see whether it can be applied. For things to happen that way, the server should not send 4.09, but 5.03. I hope that clarifies what I've tried to put into a short mail before Christian [1] https://en.wikipedia.org/wiki/Merge_(version_control)#Three-way_merge --=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 --xB0nW4MQa6jZONgY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJV8AXSAAoJEDmNERLTpL3hEVoP/RK827CikWJ1WAh1IN6Bc3hu kGB9WkcPuCfhnnzH85+NPmoZwDcHZXc5VZuPCY8K8uIMg36Y33i4uNclS54Rwxr/ bCxUJWWsGbGxTegox6I5x0GYgqgAGANUyKJ8IvufEyNbxrfynwMBr8vBqMHDqipC lVBO/OaUXx3FXcbZk6vN7DrQMZkVEbCYzIfwH3haR9z/45PRkRTYPDZwy1HaAjyh CZj+r+YmvqXwsoYDksnOlxQRxXs+FeOxHz19kZ1COCW4hegI2uzqvj8rbRFCdei9 OAupRkEgp7zZh4f7qgpezwbSSrUsPkPs1GS6exXLgTj+IQME53+4EcQDk/Qc3urD 47p4ZAEbokdrFbil1h+tNMJ/uqjNukJqbm9MYN0HoS6x5iP8xF2V8XWEkDw+QBw0 FPy647/auwFLFSeRSQJaItU0IcX4RT2fn6p3POgDSxF2+7lPoGnIuc3eADiohAYO PDQshN/Ymcjk2nruZx41GeRu8NPee3r+WUqVz/YzDZfCBkDqS86znZnMpRnXbrCg 21F4HQ86R+EHPeucjYoZ1dubhy0mvJMusA6OqlE9dFp3cR5t3agNnr03Dkj0dP31 Zj3pPe+FhIeZtuIgsEweToVrgmB0X5JU9ozpc66Io5Z6kOTnch3FzBrDVqa7cypV RGovFf1NCKKiFL+sKSg8 =cXBf -----END PGP SIGNATURE----- --xB0nW4MQa6jZONgY-- From nobody Thu Sep 10 03: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 A582D1B38DE for ; Thu, 10 Sep 2015 03:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 3OJ6Kiq3O0ol for ; Thu, 10 Sep 2015 03:04:18 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6F01A891D for ; Thu, 10 Sep 2015 03:04:17 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.216]) by smtp-cloud3.xs4all.net with ESMTP id FN4E1r00L4fjQrE01N4ECC; Thu, 10 Sep 2015 12:04:15 +0200 Received: from AMontpellier-654-1-89-216.w90-28.abo.wanadoo.fr ([90.28.128.216]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 10 Sep 2015 12:04:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 10 Sep 2015 12:04:14 +0200 From: peter van der Stok To: =?UTF-8?Q?Christian_Ams=C3=BC=C3=9Fs?= Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20150909101133.GD4537@hephaistos.amsuess.com> References: <20150908145930.GB4537@hephaistos.amsuess.com> <20150909101133.GD4537@hephaistos.amsuess.com> Message-ID: <2455258a29e2d7bf4bbe75d2df4c3f26@xs4all.nl> X-Sender: stokcons@xs4all.nl (lLizKjf+OEmuH9PildhQvqQArEZRQikt) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] Concurrent modifications suggestion in draft-vanderstok-core-patch-01 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, 10 Sep 2015 10:04:20 -0000 Hi Christian, Many thanks for the elaborate answer; This helps a lot and makes me realize that some additional text may be useful in the draft. Let me rephrase in my own concepts that I understand. The following things are possible: 1) The request arrives at the server, and the request queue is full. (this also handles the case that the server can handle only one request at the time and is busy) 2) The request is entered in the server queue and multiple concurrent processes handle as many requests. N processes concurrently overwrite the same subset of values leading to inconsistent resource state 3) The request is entered in the server queue; requests are handled sequentially (atomically) and an earlier request is handled after a later request (whatever way this is detected). Add 1) error return 5.03 is clearly required Add 2) error return 4.09 seems required; When patch is atomic, an earlier consistent resource state should be recovered by the server. Add 2.1) when the server recovers to a consistent state, the client is not required to do anything and 4.09 is not appropriate; Create a new error? Add 3) This is the point of discussion? You prefer error 5.03? what about a new error to cover the situation? Or is there a 4th possibility that I am not aware of? I understand "cannot be queued" as case 1. Is that correct? Sorry to insist so much on clearly understanding; but I think it is important to get it right. These things are sources of unreproducible errors. Peter Christian Ams眉脽s schreef op 2015-09-09 12:11: > Hi Peter, > > The point I'd fokus on in the 4(.)09 description is > >> The request could not be completed due to a conflict with the current >> *state of the resource*. > > . As PATCH is supposed to be atomic, by the time the conflicting second > request arrives, the resource's state can be the original or the > altered > state; let's for the sake of the argument assume that the patches would > apply cleanly in either sequence. > > The "Concurrent modification" situation happens because the requests > "cannot be queued", which in my opinion matches well with RFC 2616's > description of "temporary overloading". > > >> 503 is used in "temporary" overload situations independent of server >> state, > > I assume you mean resource state here -- as far as I understand, 503 is > precisely about the server's (the process's) state. > >> This code is only allowed in situations where it is >> expected that the user might be able to resolve the conflict and >> resubmit >> the request. The response body SHOULD include enough > > This is why I mentioned "re-fetching an three-way merging...", so I'll > explain: > > If a client sees 4.09, they would be required to resolve the conflict. > This would normally mean fetching the resource again, and constructing > a > new resource state that contains both the changes done on the server > since the client last fetched it and the client's own changes. (Whether > this is implemented as a three-way merge[1] or else is an > implementation > detail, but in any case has potential of being messy). The client may > even need to call for user interaction because it can't do any merging > by itself, or (as I'd expect of many tiny embedded implementations) > indicate failure. > > That is a comparatively complex process that might, as in the example > above with the two PATCH requests applying cleanly in either order, be > completely uncalled for, and the more sane behavior would be for the > client to try sending its request again after some seconds -- *then* > both will see whether it can be applied. For things to happen that way, > the server should not send 4.09, but 5.03. > > I hope that clarifies what I've tried to put into a short mail before > Christian > > [1] > https://en.wikipedia.org/wiki/Merge_(version_control)#Three-way_merge From nobody Thu Sep 10 04:07:46 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 39B8C1B3D81 for ; Thu, 10 Sep 2015 04:07:45 -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_20=-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 0eVLtlrG2vvi for ; Thu, 10 Sep 2015 04:07:43 -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 233741B3A52 for ; Thu, 10 Sep 2015 04:07:42 -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 50B5E44F32; Thu, 10 Sep 2015 13:07:40 +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 42DEE23; Thu, 10 Sep 2015 13:07:39 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0F5652E; Thu, 10 Sep 2015 13:07:39 +0200 (CEST) Received: (nullmailer pid 17791 invoked by uid 1000); Thu, 10 Sep 2015 11:07:29 -0000 Date: Thu, 10 Sep 2015 13:07:29 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: consultancy@vanderstok.org Message-ID: <20150910110729.GF4485@hephaistos.amsuess.com> References: <20150908145930.GB4537@hephaistos.amsuess.com> <20150909101133.GD4537@hephaistos.amsuess.com> <2455258a29e2d7bf4bbe75d2df4c3f26@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ar8KwLu88Tj76bHi" Content-Disposition: inline In-Reply-To: <2455258a29e2d7bf4bbe75d2df4c3f26@xs4all.nl> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Core Subject: Re: [core] Concurrent modifications suggestion in draft-vanderstok-core-patch-01 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, 10 Sep 2015 11:07:45 -0000 --Ar8KwLu88Tj76bHi Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Peter, On Thu, Sep 10, 2015 at 12:04:14PM +0200, peter van der Stok wrote: > Sorry to insist so much on clearly understanding; but I think it is > important to get it right. I'm all with you when it comes to taking this seriously. > 1) The request arrives at the server, and the request queue is full. > [...] > > Add 1) error return 5.03 is clearly required Yes, and this is how I read the "Concurrent modification" paragraph in section 3 originally. > 2) The request is entered in the server queue and multiple concurrent > processes handle as many requests. N processes concurrently overwrite the > same subset of values leading to inconsistent resource state > > Add 2) error return 4.09 seems required; When patch is atomic, an earlier > consistent resource state should be recovered by the server. > Add 2.1) when the server recovers to a consistent state, the client is not > required to do anything and 4.09 is not appropriate; Create a new error? Currently, atomicity of a PACH operation is a MUST in the draft, and I don't see any reason why it shouldn't. Unless the server has other means of clean handling, it would protect the resource against such a thing (eg. using locks and queuing the request). A patch either applies in full (2.04) or not (4.09). To illustrate what I mean by "other means of clean handling", assume a resource represents a line-based text, and (by design of the patch content type) a patch can only update a single line; further assume that the patches are transferred in multi-block CoAP transfers to make concurrency really an issue. Then a server could accept different first blocks affecting different lines, knowing that they can be handled separately, and 2.04 them at their respective last blocks. A first block attempting to modify a line that is currently being patched (ie. transfer in progress / not timed out) would be rejected early with 5.03 unless the request can be queued as in 1). > 3) The request is entered in the server queue; requests are handled > sequentially (atomically) and an earlier request is handled after a later > request (whatever way this is detected). >=20 > Add 3) This is the point of discussion? You prefer error 5.03? what about= a > new error to cover the situation? I haven't thought of this point yet, as I wouldn't expect a client to send a consecutive patch atop one it has not received a successful response yet. IMO it is the client's responsibility to ensure that patches are delivered in sequence unless the patch format takes care of that anyway (but in that case, probably neither of the two patches would apply if received out of sequence). (I could envision an example of when something like that *might* make sense, where a GIT history is successively transferred, and the server will belay its answer to a not-yet-applicable commit until it has received the earlier objects, but that's pretty far-fetched and not how it'd probably be done.) > Or is there a 4th possibility that I am not aware of? If I were to enumerate all the special cases, I would only have mentioned 1), based on my understanding of atomic patches and general network practice. Cases 2) and 3) to me sound rather like server and client trying to be smart by being sloppy about atomicity or disregarding the fact that network traffic in general is not ordered, respectively. It is good to consider those cases in the RFC (as they *will* occur in practice), but I'd rather have strict phrasing in the normative part (MUST be processed atomically, MUST NOT rely on the sequence in which they are processed) and mention cases like 2 and 3 in a (possibly non-normative) examples part, outlining how participants could be smart and still stick to the requirements, and under which preconditions that works. 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 --Ar8KwLu88Tj76bHi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJV8WRtAAoJEDmNERLTpL3hhs8P/2aCBrujxevcTMk4sEpKuWyZ WXishFaiCK6fbkzKJRcPdltEFxBgYozy79K767eL1vTA+BNM1EpXtlF64zg2f9/y Tr2mp5qG0jsrHUSKxBLADajobrZocUYCGOX+ki1nmqk9oUR7MGpkzSU5qkfDVOjH cbCOW6JYe3r/RSdDFsvfcCiKntEmd0YxyBTGDIi8CVLea6uQ9XfFimPgb/48TJ+A +F5hd1B8UrFeZ+oFc4uPJeXxS4PT1ySwKJdv5A8e0v1V+cDkEK+OBnZ7ij+ZjZco TighPtbRU+joAfwhLpE2FvR2CtKNRonfW1sP/YjPy22jqJwbPhE5bBqvnvPi9TEn Vsbginny0sTRH3RZ/kemNvOTVlJ9B8lT7X+VV/3PoHNJUJCE8EibPsq1x3Vv0UQw U8Q7TEvLPKntSoRSmQyvCBzn4KBo3ccHY6CuzVIVt642v4U5ymSeti/uTO8WOjT5 XWay56u+jOySJ9QQWOYRhLc9RVlgamStUn8sMwFK5k/lFg+OEtT7tl2h/8Evr7G2 irzYjHsg4Lm8b59dqIDqVdaCZ/+Z7VvF3RmqjnRPytGSqoVDatIl4ikiAX/FV5r5 z2LJAtveJMIkPVlX9bTI4UnZPiQeyyGu4O+dYa3HGIcWz3qLmf5Y1NHHmbrsr0eD /FlZsi6z0Pqf8NjPp4Q/ =CjPc -----END PGP SIGNATURE----- --Ar8KwLu88Tj76bHi-- From nobody Thu Sep 10 05:04:28 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 C6F251B387A for ; Thu, 10 Sep 2015 05:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 GdWlcWKwCHC3 for ; Thu, 10 Sep 2015 05:04:26 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64391AD09D for ; Thu, 10 Sep 2015 05:04:25 -0700 (PDT) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 10 Sep 2015 14:04:23 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.03.0248.002; Thu, 10 Sep 2015 14:04:23 +0200 From: "Kovatsch Matthias" To: Hauke Mehrtens , Hannes Tschofenig , "core@ietf.org WG" Thread-Topic: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" Thread-Index: AQHQ4P6U27zYQmoh2UqQWe7uTlqb2J4gJNuAgBWQKiA= Date: Thu, 10 Sep 2015 12:04:22 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B54CA096E2@MBX210.d.ethz.ch> References: <55DF6438.8030508@gmx.net> <55DF6E51.7000601@hauke-m.de> In-Reply-To: <55DF6E51.7000601@hauke-m.de> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" 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, 10 Sep 2015 12:04:27 -0000 Hi What is the status of this? I would be in favor of fixing this according to= the specification now, in particular, because we want to release Californi= um 1.0.0 soon. Olaf, would you be willing to fix this in TinyDTLS as well? Hannes, how is it currently implemented in mbed TLS? Do you know about othe= r commercial implementations such as WolfSSL or CyaSSL? Ciao Matthias From nobody Thu Sep 10 05:19: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 3AB3D1B5C95 for ; Thu, 10 Sep 2015 05:19:04 -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 rQ5sbAO0IoIj for ; Thu, 10 Sep 2015 05:19:03 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0750E1B5C6F for ; Thu, 10 Sep 2015 05:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t8ACIunP016181; Thu, 10 Sep 2015 14:18:56 +0200 (CEST) Received: from aung.tzi.org (eduroam-pool3-025.wlan.uni-bremen.de [134.102.232.25]) (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 3nBfQS5ZZPzDZ6S; Thu, 10 Sep 2015 14:18:56 +0200 (CEST) From: Olaf Bergmann To: "Kovatsch Matthias" References: <55DF6438.8030508@gmx.net> <55DF6E51.7000601@hauke-m.de> <55877B3AFB359744BA0F2140E36F52B54CA096E2@MBX210.d.ethz.ch> Date: Thu, 10 Sep 2015 14:20:43 +0200 In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54CA096E2@MBX210.d.ethz.ch> (Kovatsch Matthias's message of "Thu, 10 Sep 2015 12:04:22 +0000") Message-ID: <871te6sbxg.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@ietf.org WG" Subject: Re: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" 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, 10 Sep 2015 12:19:04 -0000 "Kovatsch Matthias" writes: > Hi > > What is the status of this? I would be in favor of fixing this > according to the specification now, in particular, because we want to > release Californium 1.0.0 soon. +1 > Olaf, would you be willing to fix this in TinyDTLS as well? Done on 2015-08-26. Wireshark has a bugfix since 2015-09-07. Gr=C3=BC=C3=9Fe Olaf From nobody Thu Sep 10 05:21:46 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 A10341B5DD2 for ; Thu, 10 Sep 2015 05:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MUbAPHgCOQSd for ; Thu, 10 Sep 2015 05:21:42 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43AD31B5DBD for ; Thu, 10 Sep 2015 05:21:42 -0700 (PDT) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 10 Sep 2015 14:21:39 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.03.0248.002; Thu, 10 Sep 2015 14:21:40 +0200 From: "Kovatsch Matthias" To: Olaf Bergmann Thread-Topic: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" Thread-Index: AQHQ4P6U27zYQmoh2UqQWe7uTlqb2J41w9PGgAAASVA= Date: Thu, 10 Sep 2015 12:21:39 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B54CA09742@MBX210.d.ethz.ch> References: <55DF6438.8030508@gmx.net> <55DF6E51.7000601@hauke-m.de> <55877B3AFB359744BA0F2140E36F52B54CA096E2@MBX210.d.ethz.ch> <871te6sbxg.fsf@aung.informatik.uni-bremen.de> In-Reply-To: <871te6sbxg.fsf@aung.informatik.uni-bremen.de> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" 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, 10 Sep 2015 12:21:44 -0000 PiBEb25lIG9uIDIwMTUtMDgtMjYuICBXaXJlc2hhcmsgaGFzIGEgYnVnZml4IHNpbmNlIDIwMTUt MDktMDcuDQoNCk9rYXksIHNvIHRoZSBzdGF0dXMgaXMgdGhhdCBrZWVwaW5nIGl0IGZvciBpbnRl cm9wZXJhYmlsaXR5IGluIHRoZSBmbGllZCBpcyBvZmYgdGhlIHRhYmxlIDopDQpHb29kLCBsZXQn cyBnZXQgdGhlIGZpeCBpbnRvIFNjYW5kaXVtLg0KDQpDaWFvDQpNYXR0aGlhcw0K From nobody Thu Sep 10 06:43:34 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 AF5EF1B315E for ; Thu, 10 Sep 2015 06:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 v8pn44tmdY_T for ; Thu, 10 Sep 2015 06:43:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 3CD661B3E7E for ; Thu, 10 Sep 2015 06:43:21 -0700 (PDT) Received: from [192.168.10.174] ([128.130.240.248]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MfRnb-1ZGadM2l6x-00P8fw; Thu, 10 Sep 2015 15:43:15 +0200 To: Kovatsch Matthias , Hauke Mehrtens , "core@ietf.org WG" , Manuel Pegourie-Gonnard References: <55DF6438.8030508@gmx.net> <55DF6E51.7000601@hauke-m.de> <55877B3AFB359744BA0F2140E36F52B54CA096E2@MBX210.d.ethz.ch> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <55F188F0.6090109@gmx.net> Date: Thu, 10 Sep 2015 15:43:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54CA096E2@MBX210.d.ethz.ch> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TmmWuL7gf7HSlQGjehVWIakHQq3FvmckM" X-Provags-ID: V03:K0:G031oNMHJuZHYPFZhgBM/Ix33crk7+jGZ77+txxoDylfrBSPMdQ g4YMXRd/9mQuG1xYeeiPdG3qrf6HwggOXDS5n9fdzq1kEWRIGzi9iXA/MsV/K3qk5aeMtU7 ojc8Rb6eZE26Ciu55Nr4/kDxePNKKBp1Dz1nMw+n7wv6CDl4bJj/s1R+MzyaPV2tq9ZM1oq ACX/EAbX5bTcAElWCApIw== X-UI-Out-Filterresults: notjunk:1;V01:K0:iMpJGI2ho+0=:lrH8o0GVE/KyDRTsa+BNQh maSvYiB9o9L6mCH6icz6OUrqZTE3mAL+f5t/vjKnKin36u4UZ3E7IZVwJWEbrieCk4E3vOmWk qLeoxmjKohGEqWNTD1eUynG2KL2zHfKgdl4wrk29ZoIryEw8vVE9Ga9l5WX6jndpQZylHnyUd 5nmU8PXjxI01tCe7ZEuzr4c2Ze6u0muEs47jiB7ZdyTKYeyDIP1wZaswqT2bFXma+qYNb1sLI /vDhmgVkLD5iJ5/RzfUQTaUvv7feA8zmScvTzoztArAa3r2HaZ52cJazoFEZnSt7PNXQ0fLmT v2l155NZGsckxUrijS0pKACRanZ+uyQB8zzyUyIkZU1s9dRALrB2Iq8GXCyzptXI1OIaW6DWu vLk0hO9zSpNjfCPS/0qk1z4F8+gDW+lz2sjZLgpjiBNq2NZpAy+8iqjLo0VHdZrgaERjdn+2j /salFRP9+34yHTaNxINH5E8uKLkz33ofcIh6tqGXWuaFNCHm1e/lQP6MF08615cl8PsNi9Yil 5HNgihy9TnIJqEGmXO/DudHTkhjgP0rm0STMAo+XfGUr+snReJ2b+qc2/NU/fOdAnPyMC68b3 n1VZ4ck2BSJQIV2dB5GZ/eWWejgdEiOWX3vzXdlH3IDXFV9A+IDrlFRZecSRcJEdOD+GjOr5t x5z8RHqUsYLqgAx3Jt4fPUhLswO3X75ka/5U4DIS431yxHgYoUbWu25VM/c3jPsfW189MtwGt sFXM7g3StnFlnjoF Archived-At: Subject: Re: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" 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, 10 Sep 2015 13:43:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TmmWuL7gf7HSlQGjehVWIakHQq3FvmckM Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Matthias, On 09/10/2015 02:04 PM, Kovatsch Matthias wrote: > Hi >=20 > What is the status of this? I have not received further info from other implementers. Olaf has already prepared a patch for TinyDTLS and someone has to check what the status in Californium is. > I would be in favor of fixing this > according to the specification now, in particular, because we want to > release Californium 1.0.0 soon. Makes sense. >=20 > Olaf, would you be willing to fix this in TinyDTLS as well? Hannes, > how is it currently implemented in mbed TLS? I let my co-worker Manuel talk about the mbed TLS implementation since he is doing the coding. > Do you know about other > commercial implementations such as WolfSSL or CyaSSL? I can check with them. From their webpage it seems that they do not support raw public key. Ciao Hannes >=20 > Ciao Matthias >=20 --TmmWuL7gf7HSlQGjehVWIakHQq3FvmckM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV8YjwAAoJEGhJURNOOiAtzf0H/0NIEp/bbnMYSzNlcCg+Gh1w 9rSSSbUVRxH1XDzYhhR0IfmhCyvU1kT7Uckk7s5H/ttdHsi31t1luQHvoOOFkELG IsOMzyK4j6FlTvzL2agoM3sRKf4G6oA7hGvg9g5IU8ngF+WqozLLrh6+jkY4e4w6 DxdMcGXBSDRDazo7PT8CoqPwOOH8CHfstIGwzWji4auksETwdYgA9XczMgmc/kyw V1lG6KaND4iPQMU/z2klkq3UbvnpZYKfDWdxSRU1HCPfn/ti9Mu0es25j0g6TqCi +th2j4MdAWdvFPWmBB/HX2zFk/CylJ9Hq8odSu7t6bhhlXg68ApsQviijWdFQ2A= =nzdB -----END PGP SIGNATURE----- --TmmWuL7gf7HSlQGjehVWIakHQq3FvmckM-- From nobody Thu Sep 10 07:02: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 CF1A11B676A for ; Thu, 10 Sep 2015 07:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ExGj58bYxJpY for ; Thu, 10 Sep 2015 07:02:29 -0700 (PDT) Received: from mx.bosch-si.com (mx.bosch-si.com [217.24.201.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98DB1B5EAE for ; Thu, 10 Sep 2015 07:02:28 -0700 (PDT) X-ASG-Debug-ID: 1441893745-040b7f4ae401250001-aa7cYp Received: from immpwimx01.innoimm.local ([10.55.67.25]) by mx.bosch-si.com with ESMTP id eCK7JagBRIDH9YNO (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 10 Sep 2015 16:02:25 +0200 (CEST) X-Barracuda-Envelope-From: Kai.Hudalla@bosch-si.com X-Barracuda-RBL-Trusted-Forwarder: 10.55.67.25 X-ASG-Whitelist: Client Received: from be6vw2exc00.bosch-si.com ([10.56.19.6]) by immpwimx01.innoimm.local over TLS secured channel with Microsoft SMTPSVC(7.5.7601.17514); Thu, 10 Sep 2015 16:02:25 +0200 Received: from BE6PW2EXD01.bosch-si.com ([fe80::5407:24a5:e587:d9d7]) by be6vw2exc00.bosch-si.com ([::1]) with mapi id 14.03.0224.002; Thu, 10 Sep 2015 16:02:24 +0200 X-Barracuda-RBL-IP: 10.56.19.6 From: "Hudalla Kai (INST/ESY)" To: "Kovatsch Matthias" , Olaf Bergmann Thread-Topic: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" X-ASG-Orig-Subj: RE: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" Thread-Index: AQHQ4P6TRZl6U/jXJkGOEyke0pztBp4gJNuAgBV5SQCAACWvkP//3yWAgAA8wHA= Date: Thu, 10 Sep 2015 14:02:23 +0000 Message-ID: References: <55DF6438.8030508@gmx.net> <55DF6E51.7000601@hauke-m.de> <55877B3AFB359744BA0F2140E36F52B54CA096E2@MBX210.d.ethz.ch> <871te6sbxg.fsf@aung.informatik.uni-bremen.de> <55877B3AFB359744BA0F2140E36F52B54CA09742@MBX210.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54CA09742@MBX210.d.ethz.ch> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.56.7.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Sep 2015 14:02:25.0917 (UTC) FILETIME=[52895AD0:01D0EBD1] X-Barracuda-Connect: UNKNOWN[10.55.67.25] X-Barracuda-Start-Time: 1441893745 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: https://217.24.201.142:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bosch-si.com Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" 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, 10 Sep 2015 14:02:36 -0000 Matthias, I agree with you that we should fix this in Scandium before releasing 1.0.0= . I just want to point out that this may result in Californium not being in= teroperable with existing devices/clients that are already out there (based= on already released versions of TinyDTLS, mbed etc.) from the very beginni= ng. I have no clue whether the number of such devices/clients is of any rel= evance or not, though ... Regards, Kai > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Kovatsch > Matthias > Sent: Thursday, September 10, 2015 2:22 PM > To: Olaf Bergmann > Cc: core@ietf.org WG > Subject: Re: [core] Seeking input on Implementations of RFC 7250 "Using > Raw Public Keys in TLS and DTLS" >=20 > > Done on 2015-08-26. Wireshark has a bugfix since 2015-09-07. >=20 > Okay, so the status is that keeping it for interoperability in the > flied is off the table :) Good, let's get the fix into Scandium. >=20 > Ciao > Matthias > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Sep 10 07:20: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 297921B2ADF for ; Thu, 10 Sep 2015 07:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iHUwXGggzIoG for ; Thu, 10 Sep 2015 07:20:44 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 125511A87DB for ; Thu, 10 Sep 2015 07:20:44 -0700 (PDT) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 10 Sep 2015 16:20:41 +0200 Received: from MBX210.d.ethz.ch ([fe80::ed77:7d47:9467:69a9]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.03.0248.002; Thu, 10 Sep 2015 16:20:42 +0200 From: "Kovatsch Matthias" To: "Hudalla Kai (INST/ESY)" , Olaf Bergmann Thread-Topic: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" Thread-Index: AQHQ4P6U27zYQmoh2UqQWe7uTlqb2J41w9PGgAAASVD///sBgIAAIcrw Date: Thu, 10 Sep 2015 14:20:41 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B54CA09931@MBX210.d.ethz.ch> References: <55DF6438.8030508@gmx.net> <55DF6E51.7000601@hauke-m.de> <55877B3AFB359744BA0F2140E36F52B54CA096E2@MBX210.d.ethz.ch> <871te6sbxg.fsf@aung.informatik.uni-bremen.de> <55877B3AFB359744BA0F2140E36F52B54CA09742@MBX210.d.ethz.ch> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" 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, 10 Sep 2015 14:20:46 -0000 > I agree with you that we should fix this in Scandium before releasing 1.0= .0. I > just want to point out that this may result in Californium not being > interoperable with existing devices/clients that are already out there (b= ased > on already released versions of TinyDTLS, mbed etc.) from the very > beginning. I have no clue whether the number of such devices/clients is o= f > any relevance or not, though ... Yes, I am aware of this possibility. Since there are no real numbers availa= ble, we can only speculate. From my experience and talking to many people, = I have the feeling that there are actually no DTLS-based devices out there = that are intended for actual interoperability across vendors or products. T= he applications often even use their own optimizations within their deploym= ent... Thus, I do not see it as a risk, but as a chance to get this right. Ciao Matthias From nobody Thu Sep 10 07:31:00 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 28B6D1B2BA1 for ; Thu, 10 Sep 2015 07:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 NaRikRzoMLFn for ; Thu, 10 Sep 2015 07:30:56 -0700 (PDT) Received: from mx.bosch-si.com (mx.bosch-si.com [217.24.201.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16991B31B4 for ; Thu, 10 Sep 2015 07:30:56 -0700 (PDT) X-ASG-Debug-ID: 1441895455-040b7f70ea00e70001-aa7cYp Received: from immpwimx01.innoimm.local ([10.55.67.25]) by mx.bosch-si.com with ESMTP id UChGJrbd1e0Zj0ZV (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 10 Sep 2015 16:30:55 +0200 (CEST) X-Barracuda-Envelope-From: Kai.Hudalla@bosch-si.com X-Barracuda-RBL-Trusted-Forwarder: 10.55.67.25 X-ASG-Whitelist: Client Received: from be6vw2exc01.bosch-si.com ([10.56.19.7]) by immpwimx01.innoimm.local over TLS secured channel with Microsoft SMTPSVC(7.5.7601.17514); Thu, 10 Sep 2015 16:30:55 +0200 Received: from BE6PW2EXD01.bosch-si.com ([fe80::5407:24a5:e587:d9d7]) by be6vw2exc01.bosch-si.com ([::1]) with mapi id 14.03.0224.002; Thu, 10 Sep 2015 16:30:54 +0200 X-Barracuda-RBL-IP: 10.56.19.7 From: "Hudalla Kai (INST/ESY)" To: "Kovatsch Matthias" , Olaf Bergmann Thread-Topic: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" X-ASG-Orig-Subj: RE: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" Thread-Index: AQHQ4P6TRZl6U/jXJkGOEyke0pztBp4gJNuAgBV5SQCAACWvkP//3yWAgAA8wHD//+SCgIAAI1aA Date: Thu, 10 Sep 2015 14:30:53 +0000 Message-ID: References: <55DF6438.8030508@gmx.net> <55DF6E51.7000601@hauke-m.de> <55877B3AFB359744BA0F2140E36F52B54CA096E2@MBX210.d.ethz.ch> <871te6sbxg.fsf@aung.informatik.uni-bremen.de> <55877B3AFB359744BA0F2140E36F52B54CA09742@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B54CA09931@MBX210.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54CA09931@MBX210.d.ethz.ch> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.56.7.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Sep 2015 14:30:55.0062 (UTC) FILETIME=[4D442F60:01D0EBD5] X-Barracuda-Connect: UNKNOWN[10.55.67.25] X-Barracuda-Start-Time: 1441895455 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: https://217.24.201.142:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bosch-si.com Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" 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, 10 Sep 2015 14:30:58 -0000 Ok, just wanted to make sure we are all on the same page. I have created Bug 477074 [1] in eclipse Bugzilla for Scandium which I will= start working on ... [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D477074 Regards, Kai > -----Original Message----- > From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] > Sent: Thursday, September 10, 2015 4:21 PM > To: Hudalla Kai (INST/ESY); Olaf Bergmann > Cc: core@ietf.org WG > Subject: RE: [core] Seeking input on Implementations of RFC 7250 "Using > Raw Public Keys in TLS and DTLS" >=20 > > I agree with you that we should fix this in Scandium before releasing > > 1.0.0. I just want to point out that this may result in Californium > > not being interoperable with existing devices/clients that are > already > > out there (based on already released versions of TinyDTLS, mbed etc.) > > from the very beginning. I have no clue whether the number of such > > devices/clients is of any relevance or not, though ... >=20 > Yes, I am aware of this possibility. Since there are no real numbers > available, we can only speculate. From my experience and talking to > many people, I have the feeling that there are actually no DTLS-based > devices out there that are intended for actual interoperability across > vendors or products. The applications often even use their own > optimizations within their deployment... >=20 > Thus, I do not see it as a risk, but as a chance to get this right. >=20 > Ciao > Matthias From nobody Thu Sep 10 07:44: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 8E4A71B68D7 for ; Thu, 10 Sep 2015 07:44:20 -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 iwDuam4ifD8o for ; Thu, 10 Sep 2015 07:44:19 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E95C1B68CB for ; Thu, 10 Sep 2015 07:44:18 -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 t8AEiF1k022593; Thu, 10 Sep 2015 16:44:15 +0200 (CEST) Received: from alma.local (eduroam-pool7-2019.wlan.uni-bremen.de [134.102.119.227]) (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 3nBjf70k5YzDYYs; Thu, 10 Sep 2015 16:44:15 +0200 (CEST) Message-ID: <55F1973D.5060200@tzi.org> Date: Thu, 10 Sep 2015 16:44:13 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: Kovatsch Matthias References: <55DF6438.8030508@gmx.net> <55DF6E51.7000601@hauke-m.de> <55877B3AFB359744BA0F2140E36F52B54CA096E2@MBX210.d.ethz.ch> <871te6sbxg.fsf@aung.informatik.uni-bremen.de> <55877B3AFB359744BA0F2140E36F52B54CA09742@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B54CA09931@MBX210.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54CA09931@MBX210.d.ethz.ch> 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] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" 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, 10 Sep 2015 14:44:20 -0000 Kovatsch Matthias wrote: > I have the feeling that there are actually no DTLS-based devices out there that are intended for actual interoperability across vendors or products. I don't have a basis to feel the same wy in general, but I'm pretty sure about this with respect to RPK. Fixing this bug before it gets more widespread is the right thing to do. Gr眉脽e, Carsten From nobody Thu Sep 10 07:46:47 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 32DD81B68CF for ; Thu, 10 Sep 2015 07:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NLU94pvIC21 for ; Thu, 10 Sep 2015 07:43:49 -0700 (PDT) Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [207.82.80.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847011B68CB for ; Thu, 10 Sep 2015 07:43:49 -0700 (PDT) Received: from emea-cam-gw1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-8-fJpMgY_yQrCG2QllbUtU9Q-2; Thu, 10 Sep 2015 15:43:46 +0100 Received: from EMEA-CAM-GW3.Emea.Arm.com (10.1.106.86) by emea-cam-gw1.Emea.Arm.com (10.1.248.203) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 10 Sep 2015 15:43:45 +0100 Received: from bungle.Emea.Arm.com ([fe80::6ccb:73b1:f5c3:796]) by EMEA-CAM-GW3.Emea.Arm.com ([::1]) with mapi; Thu, 10 Sep 2015 15:43:45 +0100 From: Manuel Pegourie-Gonnard To: Hannes Tschofenig Date: Thu, 10 Sep 2015 15:43:44 +0100 Thread-Topic: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" Thread-Index: AdDr1xgN7YrTBRGWSdanefSU8doDNw== Message-ID: <551A11E6-A33F-4EB5-9A65-74CDF58B9147@arm.com> References: <55DF6438.8030508@gmx.net> <55DF6E51.7000601@hauke-m.de> <55877B3AFB359744BA0F2140E36F52B54CA096E2@MBX210.d.ethz.ch> <55F188F0.6090109@gmx.net> In-Reply-To: <55F188F0.6090109@gmx.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 X-MC-Unique: fJpMgY_yQrCG2QllbUtU9Q-2 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Thu, 10 Sep 2015 07:46:45 -0700 Cc: "core@ietf.org WG" Subject: Re: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" 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, 10 Sep 2015 14:43:51 -0000 On 10 Sep 2015, at 15:43, Hannes Tschofenig wro= te: >> >> Olaf, would you be willing to fix this in TinyDTLS as well? Hannes, >> how is it currently implemented in mbed TLS? > > I let my co-worker Manuel talk about the mbed TLS implementation since > he is doing the coding. > It=92s not implemented yet in mbed TLS, should happen in a month or two. Manuel. -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential 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, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 From nobody Fri Sep 11 00:28:46 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 B128F1A8A0B for ; Fri, 11 Sep 2015 00:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 LJF4fmlmpCB6 for ; Fri, 11 Sep 2015 00:28:38 -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 225C11B2FDB for ; Fri, 11 Sep 2015 00:28:37 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.208]) by smtp-cloud2.xs4all.net with ESMTP id FjUb1r00A4VN29601jUbDz; Fri, 11 Sep 2015 09:28:36 +0200 Received: from AMontpellier-654-1-89-216.w90-28.abo.wanadoo.fr ([90.28.128.216]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 11 Sep 2015 09:28:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 11 Sep 2015 09:28:35 +0200 From: peter van der Stok To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20150910110729.GF4485@hephaistos.amsuess.com> References: <20150908145930.GB4537@hephaistos.amsuess.com> <20150909101133.GD4537@hephaistos.amsuess.com> <2455258a29e2d7bf4bbe75d2df4c3f26@xs4all.nl> <20150910110729.GF4485@hephaistos.amsuess.com> Message-ID: <699910a6e837a2887374622ea422cc66@xs4all.nl> X-Sender: stokcons@xs4all.nl (A+oHhxJ5udUQdbwknrlSvJkFNnnfVE0D) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] Concurrent modifications suggestion in draft-vanderstok-core-patch-01 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: Fri, 11 Sep 2015 07:28:44 -0000 Hi Christian, I think to understand the situation. Below some proposed changes to the draft _____________________________________________________________________ Section 3 A PATCH request may fail under certain known conditions. These situations should be dealt with as expressed below. Add: When an error has occurred, and the resulting resource state is inconsistent, the server MUST return to an earlier consistent resource state. Conflicting state: If the modification specified by a PATCH request causes the resource to enter an inconsistent state that the server cannot resolve, the server can return the 4.09 (Conflict) CoAP response. The server SHOULD return the actual resource state to provide the client with the means to create a new consistent resource state. Such a situation might be encountered when a structural modification is applied to a configuration data-store, but the structures being modified do not exist. Conflicting modification: error nr: 4.nr2 => 4.12 "precondition failed" Concurrent modification: error nr 4.09 => 5.03 "Service unavailable" Add: Conflict handling failure: If the modification implies the reservation of resources or the waiting on conditions to become true, leading to a too long request execution time, the server can return 5.03 "service unavailable". _____________________________________________________________________________________ Is this satisfactory to you? Peter Christian Ams眉ss schreef op 2015-09-10 13:07: > Hello Peter, > > On Thu, Sep 10, 2015 at 12:04:14PM +0200, peter van der Stok wrote: >> Sorry to insist so much on clearly understanding; but I think it is >> important to get it right. > > I'm all with you when it comes to taking this seriously. > >> 1) The request arrives at the server, and the request queue is full. >> [...] >> >> Add 1) error return 5.03 is clearly required > > Yes, and this is how I read the "Concurrent modification" paragraph in > section 3 originally. > >> 2) The request is entered in the server queue and multiple concurrent >> processes handle as many requests. N processes concurrently overwrite >> the >> same subset of values leading to inconsistent resource state >> >> Add 2) error return 4.09 seems required; When patch is atomic, an >> earlier >> consistent resource state should be recovered by the server. >> Add 2.1) when the server recovers to a consistent state, the client is >> not >> required to do anything and 4.09 is not appropriate; Create a new >> error? > > Currently, atomicity of a PACH operation is a MUST in the draft, and I > don't see any reason why it shouldn't. Unless the server has other > means > of clean handling, it would protect the resource against such a thing > (eg. using locks and queuing the request). A patch either applies in > full (2.04) or not (4.09). > > To illustrate what I mean by "other means of clean handling", assume a > resource represents a line-based text, and (by design of the patch > content type) a patch can only update a single line; further assume > that > the patches are transferred in multi-block CoAP transfers to make > concurrency really an issue. > > Then a server could accept different first blocks affecting different > lines, knowing that they can be handled separately, and 2.04 them at > their respective last blocks. A first block attempting to modify a line > that is currently being patched (ie. transfer in progress / not timed > out) would be rejected early with 5.03 unless the request can be queued > as in 1). > >> 3) The request is entered in the server queue; requests are handled >> sequentially (atomically) and an earlier request is handled after a >> later >> request (whatever way this is detected). >> >> Add 3) This is the point of discussion? You prefer error 5.03? what >> about a >> new error to cover the situation? > > I haven't thought of this point yet, as I wouldn't expect a client to > send a consecutive patch atop one it has not received a successful > response yet. IMO it is the client's responsibility to ensure that > patches are delivered in sequence unless the patch format takes care of > that anyway (but in that case, probably neither of the two > patches would apply if received out of sequence). > > (I could envision an example of when something like that *might* make > sense, where a GIT history is successively transferred, and the server > will belay its answer to a not-yet-applicable commit until it has > received the earlier objects, but that's pretty far-fetched and not how > it'd probably be done.) > >> Or is there a 4th possibility that I am not aware of? > > If I were to enumerate all the special cases, I would only have > mentioned 1), based on my understanding of atomic patches and general > network practice. > > Cases 2) and 3) to me sound rather like server and client trying to be > smart by being sloppy about atomicity or disregarding the fact that > network traffic in general is not ordered, respectively. It is good to > consider those cases in the RFC (as they *will* occur in practice), but > I'd rather have strict phrasing in the normative part (MUST be > processed > atomically, MUST NOT rely on the sequence in which they are processed) > and mention cases like 2 and 3 in a (possibly non-normative) examples > part, outlining how participants could be smart and still stick to the > requirements, and under which preconditions that works. > > > Best regards > Christian From nobody Fri Sep 11 01:20: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 0D5511B3F54 for ; Fri, 11 Sep 2015 01:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 fA7rgY91aHz3 for ; Fri, 11 Sep 2015 01:20:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 465B91ACC82 for ; Fri, 11 Sep 2015 01:20:34 -0700 (PDT) Received: from [192.168.10.175] ([128.130.240.248]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MSMKx-1ZBw0R09gR-00TRSO; Fri, 11 Sep 2015 10:20:32 +0200 To: Kovatsch Matthias , "Hudalla Kai (INST/ESY)" , Olaf Bergmann References: <55DF6438.8030508@gmx.net> <55DF6E51.7000601@hauke-m.de> <55877B3AFB359744BA0F2140E36F52B54CA096E2@MBX210.d.ethz.ch> <871te6sbxg.fsf@aung.informatik.uni-bremen.de> <55877B3AFB359744BA0F2140E36F52B54CA09742@MBX210.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B54CA09931@MBX210.d.ethz.ch> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <55F28ECB.2070602@gmx.net> Date: Fri, 11 Sep 2015 10:20:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54CA09931@MBX210.d.ethz.ch> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KEpspql0t93rGWncq0uQTXTsNPPHe69UQ" X-Provags-ID: V03:K0:zmxsPWjPtYzGHbNK/gJEq5gxS4tJOpY2ANLh7Can1aueoWNPYTS mSbcPbWvnoMDqevHVya92/ymzKKLMfUyrG9tUugsyhc1ckLFGEOrTpsb4REyTkSbrXpSL5M ySSoGh+9DlNIek4TX9b8WPvLisWPYzLZWs485XjBsHZarLYFE7pFfd9E1NPSeZlam5u3OGy p1B9bFl3mEt31YrbHzoyA== X-UI-Out-Filterresults: notjunk:1;V01:K0:CzfJIJBFNxg=:Suohuu6BDuU9Ix/Q0PMPZ2 Om5UYtXw7AfC9wGfJ7Qy9yesf9SdhH23W0k0LvYwY243hV5XWtZBrzlwn9iD9Mi4DfPSl0qrd GR9+kZx/pXD+CJNHhzCghnf17HGLvY644LLjSCs7Ma89/OFZc7cES8Dk9LZ6cHKNtgIfsqdAI qMoryP/TGdYMI8OEtdUwG1m+SZvOb6gW6Sy1Az270VU7DyHqA/gNm0/JGaYt1DaCkwc9efDFI kfEsEixn4wRy+EMxh4+vSpLHSE30qa2vRirJYayaVSCXHutGPiyJIj8FO7g4OMIQkJZeQ2r3N 1yQ8LoUgd8BdsS5y+WTBC91PJcUKoKzmpIxxNqqCv72Np+di2olvpK5fk6pDFD4oBB24wQnwQ rfqpVq0tPOhb3bnGgof+d5Zx9ImjW4J7EcKxtnVOxIDejwqLAwvs3CNF4KiMvO2XyRcwrID8F rqpMTFBCICtgBRp/ZPVLtrSDGtt17S7dK3ZqMywQ6ofLv/0Jvd1sBgV8NPZwZMOZbllnU1eZw bpIHmxTII22QXVX/EJFiNNWHWdWNy2bieCSJcbN0KiJaBbDOT3bsP8+MXwVqnAeXbmmh02gT5 eWC0mqGx+eWJKN6Iz0ZpgXIHlR184Ljjyds4lhoISYNO1DjlqWST45w96oBBdCZ6QTWNcmRqr jIYkReghgS6IoTT217q1S581LgMq6Nf85zWdESgvNtNMHvVFYWd5E/xruv8yzVcQG+ne7zzZL nJ4wcS4BkoGJNcEJ Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Seeking input on Implementations of RFC 7250 "Using Raw Public Keys in TLS and DTLS" 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, 11 Sep 2015 08:20:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KEpspql0t93rGWncq0uQTXTsNPPHe69UQ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Matthias, On 09/10/2015 04:20 PM, Kovatsch Matthias wrote: > I have the feeling that there are actually no DTLS-based devices out > there that are intended for actual interoperability across vendors or > products. The applications often even use their own optimizations > within their deployment... I agree that it is a bit hard to measure. As it can be read in RFC and in http://www.tschofenig.priv.at/Design-Patterns_HannesTschofenig.pptx, there are different types of deployments for IoT. Some of the most widely used models don't require TLS/DTLS. For those deployment models where DTLS/TLS is applicable two issues can be observed: (a) companies use no communication security (as discussed in the March IETF plenary) or (b) they are focusing on higher-performance IoT devices that use certificate-based authentication (often using A-class processors). So, we are still at an early stage with the deployment of many of the security mechanisms but I am convinced that we get there soon. We are also doing our best to lower the bar for implementers to integrate DTLS/TLS into their IoT applications (which I think is extremely important to actually make a difference for the ordinary implementer). Ciao Hannes --KEpspql0t93rGWncq0uQTXTsNPPHe69UQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV8o7LAAoJEGhJURNOOiAteyEH/0yJekhUpQdn4/cDGVeJQoMp j8xfMEVM/V+1Ldxt4hRBvHgssN+U+I7cIp7KTJgZTgKIpTmF6XJ4V7LWe7qCKnlr C/lcFbZeVEF4R5aUcQREErJHeSrpmmk9ilIAgAqv3KoGV18wp0FGdveY3mvT1IbR QuEgi+tyBi7sMZf3/Fkca6GvnV1p+BjVXFM0bZDtMrtckCoMc42VJvTQESahMF4R Rzk06znVdmxLy9TGZw8SD7DCYqyrFHIoRGqlW1bgIdCWEpIT3BXu83U3JLy0YuyU ujMTMqHqtaNnd5WZebBjLq+aM+BfBZWzNZQ+wNEL/OQdXvA7gJzTE3/Qcrl7rmg= =ZAQs -----END PGP SIGNATURE----- --KEpspql0t93rGWncq0uQTXTsNPPHe69UQ-- From nobody Fri Sep 11 07:54:28 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 726941B4D86 for ; Fri, 11 Sep 2015 07:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 PaQivQu5FYr1 for ; Fri, 11 Sep 2015 07:54:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 7CB991B4D87 for ; Fri, 11 Sep 2015 07:54:24 -0700 (PDT) Received: from [192.168.10.176] ([194.112.182.217]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LpbJm-1YxFTX3a4c-00fVM5 for ; Fri, 11 Sep 2015 16:54:22 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <55F2EB1A.5060409@gmx.net> Date: Fri, 11 Sep 2015 16:54:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QkuCJR8WmulEF3rln1Ox1FKWmkCC1UEB2" X-Provags-ID: V03:K0:Q/esGhgOWFm9kG7KtaWGRiAcJXQkERcHF1PdyPnjixVUpncbJyo qlkctUarM52v9wynPwSdC+D7EAJ1OffdkQWwyShoRdbJMJFHE8nr7TIGHVZie8vJVlW/H12 OKZKVLHKzHQeZYjenuxRWLGxucg3C6J8zhYRhs8J72y+0AeefUaNxA3Yvholu0m9n1BgKMx tiGHQBLV9IbFl+6qyJiyQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:VxWV6t185DE=:CWHFVzbDsnUx55AmkpjXix 8UynQQmI9AwmsrkhClOxeGzR2afDePVBYE1yvPk/rT5auapzWAUkCLcu0qpYA7gEGgsJyzOen aXDZ2SM3z943xEJwX40Ju9oBf9DEHhYfCOtBI1IEgwzhiE8DVQpuwhVYQrixMAhV09myk8sl2 JBjtI2zNpTswMxhXQG4fkbLkuBBr+HImkaJZKyn1tYOLwu4uz2O/3mi/5/N/WuCL0QCNNFbXG za1lvo14rc9PZ6UnuMhoR9amf+c3cKeE4NryevVngIwhVveppBH3LbA7AUxzBvaP9yX3AP0a9 EwXVbxMdAEhBmoRDhfc9/2dMV9gQPHKHtgcB5FNcydv/bv+gikXUXB4XKjjUYcBZXiwWYaTwo pn13sx9J+Sc/6VlTK4ygWvJxOZ7CxVUMf3/zelMyI92Z2pI6vNE0D4RX+A1nmCr+szCquRI76 vJ1TTWPilwbYF8wy3EUOcVAsWH0kqeae9FEYYEEwImfo6n5/i1jaiexiHqCnMYxb9nyjL+W+F UjckI6OMn2fZTkWD+l7i5dZsxhEcIKi4JzN0e//wril8BU+9234algJ3ASNJszORopJlV+sr1 zV+4ObbQCuZ2M+NY8pNf+6AXXFkh7SXNErjkTWFd7YjcJ/+mHBUaBPJkrjQ7F2orTZPE/X/lb Xfh2c6f6SrkJdP6qyO/yLvm5JFegxazCGCraoKEmhtKgtAISYOK27KDX4/e278E9KFGaF7aI7 QcikZpsd3ihBwhMtFutq+rlrBwJ9rztgxaVm6A== Archived-At: Subject: [core] 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: Fri, 11 Sep 2015 14:54:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QkuCJR8WmulEF3rln1Ox1FKWmkCC1UEB2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi COMI authors, I started to read through the COMI specification and I have some basic questions. More questions will follow. What is the reason for tying COMI to CoAP/UDP? What would prevent me from using COMI over HTTP, COMI over CoAP/TCP, COMI over QUIC, COMI over MQTT? While CoAP is a great protocol, not everyone is going to use CoAP and so there has to be an easy way to use this specification on top of other protocols as well. > HTTP uses TCP which is not recommended for CoAP. I am not sure that's entirely correct. RFC 7252 specified the usage of CoAP over UDP but there has been work ongoing to run CoAP over TCP/TLS, as you know. CoAP can also be used over other transports, such as SMS. > A large amount of Management Information Base (MIB) [RFC3418] specifications already exists for monitoring purposes. I would add a reference to the registry that lists those MIBs. Have you guys looked at what data really makes sense in an IoT context? > This data can be accessed in RESTCONF if the server converts the SMIv2 modules to YANG, using the mapping rules defined in [RFC6643]. Is it correct to say that this conversion happens once during the development time rather than runtime? (Needless to say that this makes a huge difference in terms of code complexity and runtime performance.) > Stateless communication is encouraged to keep communications simple and the amount of state information small in line with the design objectives of 6lowpan [RFC4944] [RFC6775], RPL [RFC6650], and CoAP [RFC7252]. This is a strange sentence. With stateless communication you have no state. Typically, you will have to create somewhere else in the protocol stack and only a certain layer is stateless. Additionally, I would remove the references to [RFC4944] [RFC6775], RPL [RFC6650] since these specs are irrelevant for this work. It just creats a longer reference list. > The end goal of CoMI is to provide information exchange over the CoA= P transport protocol in a uniform manner as a first step to the full management functionality as specified in [I-D.ersue-constrained-mgmt]. I personally don't believe that the main value of this specification is the ability to use CoAP. Instead, I believe the value is in re-using existing management objects. The code for the different transport protocols isn't that large after all... > CoMI supports MIB modules which have been translated from SMIv2 to YANG, using [RFC6643]. This mapping is read-only so writable SMIv2 objects need to be converted to YANG using an implementation-specific mapping. I am not sure I understand the implications of this design decision. It sounds like a negative thing to me. > CoMI uses a simple URI to access the management object resources. Complexity introduced by instance selection, or multiple object specification is expressed with uri-query attributes. This sentence is strange. You are saying that the URI is simple but then in the next sentence you talk about complexity due to the query attributes. Is the query attribute the same as a query parameter? When I searched through the document for 'uri-query' then I found pretty much nothing. > Terminology When I look at the terminology section and all the specifications a reader needs to understand in order to be able to read this specification then I don't feel very comfortable. Isn't there a way to make it less complex. After all, you do very little. > o The signature of the CoAP request in the server is standardized. What does signature mean in this context? Are you talking about security stuff here? Ciao Hannes --QkuCJR8WmulEF3rln1Ox1FKWmkCC1UEB2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV8usbAAoJEGhJURNOOiAt+scH/3VXyQw9oo7yFKvabKiAtSJH xKqjdlbIqq7bR81jfsSzMgLAoAxGnF+k6gx+pQWoWd7K2Xl6cwTTkMOZp6zbAmZG 9pONYnH1bXo7thsjUNn3Ht/sJ6hXYcjtXZbHgn3KBTONgsvtX4k6dzCqOltFV9+b 3WL9Gso9ekOxNd66D94WTIGtu/OBfKMk8+u0KwtHwXaFG4J6Gn5ZcPtUlmdDkKny o1eTyIb62xRM56eqGxftssGiOn2htcfhhVFzlk2cZdn7ee4CvgryLMcoaz+SRZix ZlyzVyOyVnk/69Kivo72TYQF3AxKucaxFwAlvwr1C5JHEld/gET2P7lC3WG8ok8= =u3om -----END PGP SIGNATURE----- --QkuCJR8WmulEF3rln1Ox1FKWmkCC1UEB2-- From nobody Fri Sep 11 07:58: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 388221B4DC3 for ; Fri, 11 Sep 2015 07:58:04 -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 ACqEmYrHjliM for ; Fri, 11 Sep 2015 07:58:03 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C801B4D57 for ; Fri, 11 Sep 2015 07:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t8BEvxfW023181; Fri, 11 Sep 2015 16:57:59 +0200 (CEST) Received: from alma.local (eduroam-pool7-2019.wlan.uni-bremen.de [134.102.119.227]) (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 3nCKvW0FNSz1wNt; Fri, 11 Sep 2015 16:57:59 +0200 (CEST) Message-ID: <55F2EBF5.4040308@tzi.org> Date: Fri, 11 Sep 2015 16:57:57 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: Hannes Tschofenig References: <55F2EB1A.5060409@gmx.net> In-Reply-To: <55F2EB1A.5060409@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] 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: Fri, 11 Sep 2015 14:58:04 -0000 Hannes Tschofenig wrote: > What is the reason for tying COMI to CoAP/UDP? What would prevent me > from using COMI over HTTP, COMI over CoAP/TCP, COMI over QUIC, COMI over > MQTT? COMI works over REST, so it will work over all these except MQTT. It is probably still a good idea to have a default expectation which transport will be used with COMI, so calling out for CoAP over (DTLS over) UDP is probably still a good plan. Gr眉脽e, Carsten From nobody Fri Sep 11 09:01:53 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 A84D51B4FF6 for ; Fri, 11 Sep 2015 09:01:52 -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 04XjtxiIW4N9 for ; Fri, 11 Sep 2015 09:01:49 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 4FE951B4FF0 for ; Fri, 11 Sep 2015 09:01:49 -0700 (PDT) Received: by lbcjc2 with SMTP id jc2so42052082lbc.0 for ; Fri, 11 Sep 2015 09:01:47 -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=pD9Tdye2lkJNjYG+44Jb0woQbW+1/Y2/c0uC3nLylT0=; b=N69d4KPozhER7lke3SUV4t76Z3sMdWnblFjTJtc5mwgBUYhmpPLhXeuADmiiXBLsz9 /NGWVrR/VVZ/XEwvnZFiO0iHgdQxTRDt/sPTgkHNQW7sr64MJujN7MJtYpqIYpnHPNKD jvoOvv1HIopNCPC/fTYV5NTYpTpncPi/tv7xpGuqhr3GOZVzrqaBXOLIkj1ttrHy2Zv/ eoRO7Ts9Lie8YX2zwzBYsEDYM3S69kTdkRYspKHhdMYLGgv93drzI07IMWZu/Tw6XQq4 hBfoFutRqwhLH6d7+EHYCu5UMe7OVViN2k8nY5X+dAFFH2kXGAAAoma1awZcZKgRfJxA 8NCg== X-Gm-Message-State: ALoCoQlARVEbp3P54ZPNN0hwhiyiS0X1Lv08KwqkqDfPJj3nJm8AVUnIPJ54fchaZAZMBoTrbLDM MIME-Version: 1.0 X-Received: by 10.152.36.101 with SMTP id p5mr27360048laj.123.1441987307494; Fri, 11 Sep 2015 09:01:47 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Fri, 11 Sep 2015 09:01:47 -0700 (PDT) In-Reply-To: <55F2EB1A.5060409@gmx.net> References: <55F2EB1A.5060409@gmx.net> Date: Fri, 11 Sep 2015 09:01:47 -0700 Message-ID: From: Andy Bierman To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e0158b5bc3bfe94051f7ad582 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] 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: Fri, 11 Sep 2015 16:01:52 -0000 --089e0158b5bc3bfe94051f7ad582 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 11, 2015 at 7:54 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi COMI authors, > > I started to read through the COMI specification and I have some basic > questions. More questions will follow. > > What is the reason for tying COMI to CoAP/UDP? What would prevent me > from using COMI over HTTP, COMI over CoAP/TCP, COMI over QUIC, COMI over > MQTT? > > While CoAP is a great protocol, not everyone is going to use CoAP and so > there has to be an easy way to use this specification on top of other > protocols as well. > > Why can't they use RESTCONF then? The CORE WG should focus on CoAP. The more options, the more complex it gets, not easier. > > HTTP uses TCP which is not recommended for CoAP. > > I am not sure that's entirely correct. RFC 7252 specified the usage of > CoAP over UDP but there has been work ongoing to run CoAP over TCP/TLS, > as you know. CoAP can also be used over other transports, such as SMS. > > > A large amount of Management Information Base (MIB) [RFC3418] > specifications already exists for monitoring purposes. > > I would add a reference to the registry that lists those MIBs. > > Have you guys looked at what data really makes sense in an IoT context? > > Not yet. Since YANG is modular the vendor has lots of freedom to deploy functionality where it is needed. IMO the most significant aspect of CoMI is that is uses modular data models and the management content is decoupled from the protocol. Really small devices with 2 or 3 leafs to export should not bother with CoMI. There is a cost to decoupling the content layer, and it is not worth the cost if that layer is utterly trivial. There are common modules like ietf-interfaces that should be applicable even on IoT devices. > > > This data can be accessed in RESTCONF if the server converts the SMIv2 > modules to YANG, using the mapping rules defined in [RFC6643]. > > Is it correct to say that this conversion happens once during the > development time rather than runtime? (Needless to say that this makes a > huge difference in terms of code complexity and runtime performance.) > > yes -- conversion is with RFC 6643. This produces instance identifiers which are converted to YANG Hashes in CoMI > > Stateless communication is encouraged to > keep communications simple and the amount of state information small > in line with the design objectives of 6lowpan [RFC4944] [RFC6775], > RPL [RFC6650], and CoAP [RFC7252]. > > This is a strange sentence. With stateless communication you have no > state. Typically, you will have to create somewhere else in the protocol > stack and only a certain layer is stateless. > > NETCONF is very stateful. It can take up to 10 roundtrips to complete a single editing transaction. By contrast, RESTCONF or CoMI require 1 roundtrip instead. We will clarify that the management operations are stateless. > Additionally, I would remove the references to [RFC4944] [RFC6775], RPL > [RFC6650] since these specs are irrelevant for this work. It just creats > a longer reference list. > > > The end goal of CoMI is to provide information exchange over the CoAP > transport protocol in a uniform manner as a first step to the full > management functionality as specified in > [I-D.ersue-constrained-mgmt]. > > I personally don't believe that the main value of this specification is > the ability to use CoAP. Instead, I believe the value is in re-using > existing management objects. The code for the different transport > protocols isn't that large after all... > For those of us moving to YANG-based automation, that is the main reason for using CoMI. IMO why not just use SNMP if you just want to poll some existing counters? There is really no business case at all to rip out SNMP and redo all the instrumentation in CoAP/YANG. I don't buy the premise that all this R&D money will be better spent redoing all the instrumentation in CoAP, rather than just providing enough memory to run both SNMP and CoAP > > CoMI supports MIB modules which have been translated > from SMIv2 to YANG, using [RFC6643]. This mapping is read-only so > writable SMIv2 objects need to be converted to YANG using an > implementation-specific mapping. > > I am not sure I understand the implications of this design decision. It > sounds like a negative thing to me. > The read-only restriction is to avoid putting RowStatus into YANG. The edit model for SNMP is not compatible with anything else. Supporting SMIv2 configuration objects is not a priority, > > > CoMI uses a simple URI to access the management object resources. > Complexity introduced by instance selection, or multiple object > specification is expressed with uri-query attributes. > > This sentence is strange. You are saying that the URI is simple but then > in the next sentence you talk about complexity due to the query > attributes. Is the query attribute the same as a query parameter? When I > searched through the document for 'uri-query' then I found pretty much > nothing. > > > Terminology > > When I look at the terminology section and all the specifications a > reader needs to understand in order to be able to read this > specification then I don't feel very comfortable. Isn't there a way to > make it less complex. After all, you do very little. > > > o The signature of the CoAP request in the server is standardized. > > What does signature mean in this context? Are you talking about security > stuff here? > > Ciao > Hannes > > > Andy > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --089e0158b5bc3bfe94051f7ad582 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 11, 2015 at 7:54 AM, Hannes Tschofenig &l= t;hannes.tsc= hofenig@gmx.net> wrote:
Hi = COMI authors,

I started to read through the COMI specification and I have some basic
questions. More questions will follow.

What is the reason for tying COMI to CoAP/UDP? What would prevent me
from using COMI over HTTP, COMI over CoAP/TCP, COMI over QUIC, COMI over MQTT?

While CoAP is a great protocol, not everyone is going to use CoAP and so there has to be an easy way to use this specification on top of other
protocols as well.



Why can't they use = RESTCONF then?
The CORE WG should focus on CoAP.
The mo= re options, the more complex it gets, not easier.

= =C2=A0
> HTTP uses TCP which is not recommended for CoAP.

I am not sure that's entirely correct. RFC 7252 specified the usage of<= br> CoAP over UDP but there has been work ongoing to run CoAP over TCP/TLS,
as you know. CoAP can also be used over other transports, such as SMS.

> A large amount of Management Information Base (MIB) [RFC3418]
=C2=A0 =C2=A0specifications already exists for monitoring purposes.

I would add a reference to the registry that lists those MIBs.

Have you guys looked at what data really makes sense in an IoT context?




Not yet.=
Since YANG is modular the vendor has lots of freedom to deploy
functionality where it is needed.

IMO the= most significant aspect of CoMI is that is uses modular data models
<= div>and the management content is decoupled from the protocol.
Re= ally small devices with 2 or 3 leafs to export should not bother with CoMI.=
There is a cost to decoupling the content layer, and it is not w= orth the
cost if that layer is utterly trivial.

There are common modules like ietf-interfaces that should
be applicable even on IoT devices.

=C2=A0

> This data can be accessed in RESTCONF if the server converts the SMIv2=
modules to YANG, using the mapping rules defined in [RFC6643].

Is it correct to say that this conversion happens once during the
development time rather than runtime? (Needless to say that this makes a huge difference in terms of code complexity and runtime performance.)


yes -- conversion is with RFC 6643.
This produces instance identifiers which are converted to YANG Hash= es in CoMI


=C2=A0
> Stateless communication is encouraged to
=C2=A0 =C2=A0keep communications simple and the amount of state information= small
=C2=A0 =C2=A0in line with the design objectives of 6lowpan [RFC4944] [RFC67= 75],
=C2=A0 =C2=A0RPL [RFC6650], and CoAP [RFC7252].

This is a strange sentence. With stateless communication you have no
state. Typically, you will have to create somewhere else in the protocol stack and only a certain layer is stateless.



NETCONF is very statefu= l.
It can take up to 10 roundtrips to complete a single editing t= ransaction.
By contrast, RESTCONF or CoMI require 1 roundtrip ins= tead.
We will clarify that the management operations are stateles= s.

=C2=A0
=C2=A0
Additionally, I would remove the references to [RFC4944] [RFC6775], RPL
[RFC6650] since these specs are irrelevant for this work. It just creats a longer reference list.

>=C2=A0 =C2=A0 The end goal of CoMI is to provide information exchange o= ver the CoAP
=C2=A0 =C2=A0transport protocol in a uniform manner as a first step to the = full
=C2=A0 =C2=A0management functionality as specified in
=C2=A0 =C2=A0[I-D.ersue-constrained-mgmt].

I personally don't believe that the main value of this specification is=
the ability to use CoAP. Instead, I believe the value is in re-using
existing management objects. The code for the different transport
protocols isn't that large after all...

=

For those of us moving to YANG-based automation, that i= s the main
reason for using CoMI.=C2=A0 IMO why not just use SNMP= if you
just want to poll some existing counters?=C2=A0 There is = really no business case
at all to rip out SNMP and redo all the i= nstrumentation in CoAP/YANG.
I don't buy the premise that all= this R&D money will be better spent redoing all the
instrume= ntation in CoAP, rather than just providing enough memory to run both
=
SNMP and CoAP=C2=A0



> CoMI supports MIB modules which have been translated
=C2=A0 =C2=A0from SMIv2 to YANG, using [RFC6643]. This mapping is read-only= so
=C2=A0 =C2=A0writable SMIv2 objects need to be converted to YANG using an =C2=A0 =C2=A0implementation-specific mapping.

I am not sure I understand the implications of this design decision. It
sounds like a negative thing to me.

The= read-only restriction is to avoid putting RowStatus into YANG.
T= he edit model for SNMP is not compatible with anything else.
Supp= orting SMIv2 configuration objects is not a priority,

<= div>=C2=A0

>=C2=A0 =C2=A0 CoMI uses a simple URI to access the management object re= sources.
=C2=A0 =C2=A0Complexity introduced by instance selection, or multiple objec= t
=C2=A0 =C2=A0specification is expressed with uri-query attributes.

This sentence is strange. You are saying that the URI is simple but then in the next sentence you talk about complexity due to the query
attributes. Is the query attribute the same as a query parameter? When I searched through the document for 'uri-query' then I found pretty m= uch
nothing.

> Terminology

When I look at the terminology section and all the specifications a
reader needs to understand in order to be able to read this
specification then I don't feel very comfortable. Isn't there a way= to
make it less complex. After all, you do very little.

>=C2=A0 =C2=A0 o=C2=A0 The signature of the CoAP request in the server i= s standardized.

What does signature mean in this context? Are you talking about security stuff here?

Ciao
Hannes




Andy
=C2=A0


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


--089e0158b5bc3bfe94051f7ad582-- From nobody Mon Sep 14 00:52: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 A2E491B6019 for ; Mon, 14 Sep 2015 00:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.851 X-Spam-Level: X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_FR=0.35, 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 o9n_-YZPM67Q for ; Mon, 14 Sep 2015 00:52:34 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18BDF1B42EE for ; Mon, 14 Sep 2015 00:52:33 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.204]) by smtp-cloud6.xs4all.net with ESMTP id GvsY1r0064QBLo201vsYcE; Mon, 14 Sep 2015 09:52:32 +0200 Received: from AMontpellier-654-1-59-4.w86-202.abo.wanadoo.fr ([86.202.194.4]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 14 Sep 2015 09:52:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 14 Sep 2015 09:52:32 +0200 From: peter van der Stok To: Andy Bierman Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <55F2EB1A.5060409@gmx.net> Message-ID: <9122c5db87ff69b8b1b8ed403e094f73@xs4all.nl> X-Sender: stokcons@xs4all.nl (l+wz8p7upMtBlH7joVBuIkeEzNBAaffF) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] COMI 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, 14 Sep 2015 07:52:37 -0000 Hi Hannes, thanks for your interest. I will add to the answers by Andy. Andy Bierman schreef op 2015-09-11 18:01: > On Fri, Sep 11, 2015 at 7:54 AM, Hannes Tschofenig > wrote: > >> Hi COMI authors, >> >> I started to read through the COMI specification and I have some >> basic >> questions. More questions will follow. >> >> What is the reason for tying COMI to CoAP/UDP? What would prevent me >> from using COMI over HTTP, COMI over CoAP/TCP, COMI over QUIC, COMI >> over >> MQTT? >> >> While CoAP is a great protocol, not everyone is going to use CoAP >> and so >> there has to be an easy way to use this specification on top of >> other >> protocols as well. I agree with the answer of Andy. As pointed out by Carsten, CoMI can be used on top of other protocols. However, the design exercise was done for small low resource devices connected by LLN, where it is useful to reuse YANG and its accompanying experience and modules, including the MIBs. So, CoAP (DTLS) UDP is the favoured stack. > > Why can't they use RESTCONF then? > The CORE WG should focus on CoAP. > The more options, the more complex it gets, not easier. > >>> HTTP uses TCP which is not recommended for CoAP. >> >> I am not sure that's entirely correct. RFC 7252 specified the usage >> of >> CoAP over UDP but there has been work ongoing to run CoAP over >> TCP/TLS, >> as you know. CoAP can also be used over other transports, such as >> SMS. You're right, this might be better phrased. Although the operative word is "recommend for" and not "used by". >> >>> A large amount of Management Information Base (MIB) [RFC3418] >> specifications already exists for monitoring purposes. >> >> I would add a reference to the registry that lists those MIBs. Good suggestion >> >> Have you guys looked at what data really makes sense in an IoT >> context? This is a VERY open question. IoT represents a huge application domain and depends on the view of your interviewee. Answer is NO, we did not. Any suggestions? > > Not yet. > Since YANG is modular the vendor has lots of freedom to deploy > functionality where it is needed. > > IMO the most significant aspect of CoMI is that is uses modular data > models > and the management content is decoupled from the protocol. > Really small devices with 2 or 3 leafs to export should not bother > with CoMI. May be not. Not sure about this. > There is a cost to decoupling the content layer, and it is not worth > the > cost if that layer is utterly trivial. > > There are common modules like ietf-interfaces that should > be applicable even on IoT devices. > >>> This data can be accessed in RESTCONF if the server converts the >> SMIv2 >> modules to YANG, using the mapping rules defined in [RFC6643]. >> >> Is it correct to say that this conversion happens once during the >> development time rather than runtime? (Needless to say that this >> makes a >> huge difference in terms of code complexity and runtime >> performance.) You mean: state this in the draft > > yes -- conversion is with RFC 6643. > This produces instance identifiers which are converted to YANG Hashes > in CoMI > >>> Stateless communication is encouraged to >> keep communications simple and the amount of state information >> small >> in line with the design objectives of 6lowpan [RFC4944] >> [RFC6775], >> RPL [RFC6650], and CoAP [RFC7252]. >> >> This is a strange sentence. With stateless communication you have no >> state. Typically, you will have to create somewhere else in the >> protocol >> stack and only a certain layer is stateless. > > NETCONF is very stateful. > It can take up to 10 roundtrips to complete a single editing > transaction. > By contrast, RESTCONF or CoMI require 1 roundtrip instead. > We will clarify that the management operations are stateless. > >> Additionally, I would remove the references to [RFC4944] [RFC6775], >> RPL >> [RFC6650] since these specs are irrelevant for this work. It just >> creats >> a longer reference list. Well, it certainly paints a context a single reference which paints the same context would be welcome (suggestion?) >> >>> The end goal of CoMI is to provide information exchange over >> the CoAP >> transport protocol in a uniform manner as a first step to the >> full >> management functionality as specified in >> [I-D.ersue-constrained-mgmt]. >> >> I personally don't believe that the main value of this specification >> is >> the ability to use CoAP. Instead, I believe the value is in re-using >> existing management objects. The code for the different transport >> protocols isn't that large after all... > > For those of us moving to YANG-based automation, that is the main > reason for using CoMI. IMO why not just use SNMP if you > just want to poll some existing counters? There is really no business > case > at all to rip out SNMP and redo all the instrumentation in CoAP/YANG. > I don't buy the premise that all this R&D money will be better spent > redoing all the > instrumentation in CoAP, rather than just providing enough memory to > run both > SNMP and CoAP The point was also that snmpv3 including security is huge. Using Coap and its accompanying security stack (that may evolve) reduces stack size and learning effort for coap using devices. And as Andy points out we seem most added value for those that move to YANG. > >>> CoMI supports MIB modules which have been translated >> from SMIv2 to YANG, using [RFC6643]. This mapping is read-only so >> writable SMIv2 objects need to be converted to YANG using an >> implementation-specific mapping. >> >> I am not sure I understand the implications of this design decision. >> It >> sounds like a negative thing to me. > > The read-only restriction is to avoid putting RowStatus into YANG. > The edit model for SNMP is not compatible with anything else. > Supporting SMIv2 configuration objects is not a priority, > >>> CoMI uses a simple URI to access the management object >> resources. >> Complexity introduced by instance selection, or multiple object >> specification is expressed with uri-query attributes. >> >> This sentence is strange. You are saying that the URI is simple but >> then >> in the next sentence you talk about complexity due to the query >> attributes. Is the query attribute the same as a query parameter? >> When I >> searched through the document for 'uri-query' then I found pretty >> much >> nothing. Ok, will rephrase. We can remove the whole sentence. It is a consequence of the grammar evolution CoMI lived through. >> >>> Terminology >> >> When I look at the terminology section and all the specifications a >> reader needs to understand in order to be able to read this >> specification then I don't feel very comfortable. Isn't there a way >> to >> make it less complex. After all, you do very little. but we reuse quite a lot. I share your concern, and have been thinking about simplifications, with the result of often messing up by misrepresenting YANG concepts (but that may be me) >> >>> o The signature of the CoAP request in the server is >> standardized. >> >> What does signature mean in this context? Are you talking about >> security >> stuff here? signature in the sense of function name, type, and parameter name, type. Ian Sommerville, software engineering. >> >> Ciao >> Hannes > > Andy > greetings, Peter >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Sep 14 03:25: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 C8FA31B31AD for ; Mon, 14 Sep 2015 03:25:23 -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 FcbXAekhqcV7 for ; Mon, 14 Sep 2015 03:25:22 -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 AA4E41B2D2B for ; Mon, 14 Sep 2015 03:25:21 -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 3CB6C44F8A; Mon, 14 Sep 2015 12:25:18 +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 383DF23; Mon, 14 Sep 2015 12:25:01 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 846042E; Mon, 14 Sep 2015 12:25:00 +0200 (CEST) Received: (nullmailer pid 12115 invoked by uid 1000); Mon, 14 Sep 2015 10:24:54 -0000 Date: Mon, 14 Sep 2015 12:24:54 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: consultancy@vanderstok.org Message-ID: <20150914102453.GA1786@hephaistos.amsuess.com> References: <20150908145930.GB4537@hephaistos.amsuess.com> <20150909101133.GD4537@hephaistos.amsuess.com> <2455258a29e2d7bf4bbe75d2df4c3f26@xs4all.nl> <20150910110729.GF4485@hephaistos.amsuess.com> <699910a6e837a2887374622ea422cc66@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <699910a6e837a2887374622ea422cc66@xs4all.nl> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: Core Subject: Re: [core] Concurrent modifications suggestion in draft-vanderstok-core-patch-01 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, 14 Sep 2015 10:25:24 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 11, 2015 at 09:28:35AM +0200, peter van der Stok wrote: > A PATCH request may fail under certain known conditions. These > situations should be dealt with as expressed below. > Add: When an error has occurred, and the resulting resource state is > inconsistent, the server MUST return to an earlier consistent resource > state. Such a wording, in my opinion, might do more harm than good. The draft already says "atomic", that seems comparatively unambiguous to me provided there are no other statements that weaken thet (eg. this one might be read as allowing the server to return to an earlier consistent state than the last one). > Conflicting state: If the modification specified by a PATCH request > causes the resource to enter an inconsistent state that the > server cannot resolve, the server can return the 4.09 (Conflict) > CoAP response. [...] Such a situation might be encountered > when a structural modification is applied to a configuration > data-store, but the structures being modified do not exist. >=20 > Conflicting modification: error nr: 4.nr2 =3D> 4.12 "precondition failed" >=20 > Concurrent modification: error nr 4.09 =3D> 5.03 "Service unavailable" This does sound good to me. I've had a look at RFC5789 (HTTP PATCH) again, where that structure probably originated, and found that 4(.)12 is tied to having a If-Match present, that would be a good idea here too. > The server SHOULD return the actual resource state to provide > the client with the means to create a new consistent resource > state. I think that a diagnostic message (or none) is better suited here. Having diagnostics is a SHOULD of RFC7252, the HTTP PATCH doesn't auto-respond with the latest version either. I'm not saying it can't be done, but it'd need to be done carefully. So far, afaict this would be the first non-successful response code that would transmit a (possibly blockwise'd) content payload. The passage in RFC5789 about concurrent modification made me look up its history w/rt 5(.)03 responses. In [1], the very issue I've brought up on it was discussed in its HTTP equivalent before. They stuck with 409, in my impression didn't drill down deep enough into the "concurrent modification" case. I'm tempted to ask Lisa Dusseault (the author of RFC5789 and [1]) to comment on this thread around [2]; she has definitely given this topic some thought -- have you been in contact with her during this draft? Best regards Christian [1] http://www.ietf.org/mail-archive/web/ietf/current/msg59171.html [2] http://mailarchive.ietf.org/arch/msg/core/JI_TqZQFuMfdTs-MnQuKrrNgCPs --=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 --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIbBAABCAAGBQJV9qBxAAoJEDmNERLTpL3hLW8P+OWDwI9reGy9EyNutq3Xecif yo+Ff9u1ORltPrGOeUV/UFvKW6CxMEuaCNff3qjFbGGKf8xL2HC+K0jmsAz7P/2K V5H+UeZ8LzAf5hmD49W71fFBHm8b4ffGvwYUFnajDwIMDOn6Lgv65Ibz3FY3ybYt 6wUoUzirRrEVVgUg2R4CPMNDESlmZ1hTUIwGQWjZ/aKjhLB1tGrfNcStS4vF2+aK YWkkrd2WoRsQHa8kTtMapXKRRDvxgPkSQt9nNCROouw7iZsUxj4iyL99PDJ6WjI0 FpYDUolxtzxILGvyldYN0HihEt/05CpwVGJVnafWiKW7CGcOiIIII/LiAB9SVT66 eGbguF2L3OhltbXbYxj9ixv5vsNYBJUFgu2F4muUEWTKbKLdyyFqF4IGB9D0MCb+ tHhBeuV0vcauKW/3OsfXuajaQ3FE6YLxdMpy3R7bZxK0z4JFTMulMp1qKTa80aGy h/F6ljQEB0JT84zojUs6q1BXi1rKdcgRDfEOmubgN/HZ6JRX4rBKsCrxinFb+41E Dnh9BsDIAFMd+2nNuFIy6cEsTqEapy3ENwrhwJ3j/6Z46gOd6xQiL3jJiZBn7ZC2 bJffrsv9yu3od+BnH4rukpfiTbkX0v5uHaNXOpPsC9tEFVLv2M6lvFJ3bWgZmxiB Jcbb1h2no1+YYaEgh80= =MuBP -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From nobody Mon Sep 14 10:49: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 9B8F81B3F74; Mon, 14 Sep 2015 10:49:30 -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 g8D7UqNnY-hD; Mon, 14 Sep 2015 10:49:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F8F1B3E94; Mon, 14 Sep 2015 10:49: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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150914174929.23168.56348.idtracker@ietfa.amsl.com> Date: Mon, 14 Sep 2015 10:49:29 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-block-18.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, 14 Sep 2015 17:49:30 -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 : Block-wise transfers in CoAP Authors : Carsten Bormann Zach Shelby Filename : draft-ietf-core-block-18.txt Pages : 33 Date : 2015-09-14 Abstract: CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-block/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-block-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 15 01:15: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 017191B3FDC for ; Tue, 15 Sep 2015 01:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 GMuGCGgSSDKk for ; Tue, 15 Sep 2015 01:15:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 3EF731A8932 for ; Tue, 15 Sep 2015 01:15:06 -0700 (PDT) Received: from [192.168.10.181] ([134.76.0.127]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MAPoQ-1ZUeez3IOg-00BeHM; Tue, 15 Sep 2015 10:15:03 +0200 To: Andy Bierman References: <55F2EB1A.5060409@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <55F7D385.1060908@gmx.net> Date: Tue, 15 Sep 2015 10:15:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rR9jAIaXAPP8AtgibkfQW0DrkioED1Bbs" X-Provags-ID: V03:K0:yGwbvV8eizEY27y/AlQ/HIKgXeB6xZjxgNYh+UDVH3V8ZOoEbiY 2jOQI5LOZKUZ8WoI+WzSgba7i+g9Kp0qA6stU4iL5VDVM7klxBBLk+vIlkQPSg/WS14I4FW w5rP7bYgjWtKcrSqpgxOL6YrxxhnvIY+1NPvQAouQJ+E+wMN88QWtRv8MBJ0NjVy/+fn8ku 4uOCNOwHcWWXpaeha9PYw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Cv3D3srOicQ=:nSGHfAGQBc4CAPx8VUuKX0 L5w2s1xWVIXWu7W579y9ShcQ/ci+8KcpLIu1iGU0SrKvd6lJGJZU/WpSYf36FSPoLO6ZZfQMY ZEP0U6EDcE6qeZjYAsGnNiJgWdfEltBRG3tx4NKQ73PApsMQhgh9Edeg4YZhrLx0s2zlqRpJD /5XKolG7MC2i96dDqamRTSCohw/WDiGVoUISTm8n9ccFawQ0qYRYC4bNIDMeYBVLR/lSHCBUN y4kbtyHXAS84EdQNm57C/gqZJ434TlFjTVv74Mf81eSSeX1X3p5I2QAu1O3TZQVnDW9MTiZPe DWUjttvLskeM6moU8fHGk2XG+hAR/vnkm/sLunen5XzBcqVBN31Wz9HgHCCsaFfWZOKx7q9qz 9lUcWMRRf/w3ccTC+tCKd5a2DhTIHw5fY9JO8XyotmNVPBYo4BrLTIrwDs/V9Nw+fGuocpJgo vMoRPAEueyO0oA93/Op1i6pgnO38VQ7hdwAd+j5dEldcVBTifSSIR2GtDgGTETz1ET5M9QSd2 6Gvzh+rOLVA07TXRt3unUniRkTmWltg93KeMSr8rExO3PwlzV7TqXQ+ljPsHnJD8WL2Kof3qI Q0XWzasrSd73HT5nWGkKJ3XO9sQbXmg9SwuARndE99DsakV3JcR3OuW1RZZhEaEcV6uOSJTor 2y+ZP2m2zt7gOxG0ELWL9Pqr4Chn5efQdKmu/aa2lIq/68OIwNU5P96nZayD5gc8ufbJCzkbV Mw/KL4kDkD0fnEmu Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] 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, 15 Sep 2015 08:15:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rR9jAIaXAPP8AtgibkfQW0DrkioED1Bbs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Andy, thanks for your quick response! On 09/11/2015 06:01 PM, Andy Bierman wrote: > > > On Fri, Sep 11, 2015 at 7:54 AM, Hannes Tschofenig > > wrote: > > Hi COMI authors, > > I started to read through the COMI specification and I have some ba= sic > questions. More questions will follow. > > What is the reason for tying COMI to CoAP/UDP? What would prevent m= e > from using COMI over HTTP, COMI over CoAP/TCP, COMI over QUIC, COMI over > MQTT? > > While CoAP is a great protocol, not everyone is going to use CoAP and so > there has to be an easy way to use this specification on top of oth= er > protocols as well. > > > > Why can't they use RESTCONF then? > The CORE WG should focus on CoAP. > The more options, the more complex it gets, not easier. It is of course a question about what the folks in the CORE working group believe they will be using in their deployments. We hear a lot of folks asking for protocols other than CoAP over UDP. It is hard to say whether they are only interested to hear whether that's is possible or whether they are really interested to deploy HTP2 or QUIC. Hard to say at this point in time but I believe the COMI specification by its nature does not need to be strongly tied to CoAP (which Carsten seems to confirm in his email response). Regarding RESTCONF: Based on your response below it appears that RESTCONF by itself is very wasteful and not very useful for an IoT deployment. > > > > > HTTP uses TCP which is not recommended for CoAP. > > I am not sure that's entirely correct. RFC 7252 specified the usage= of > CoAP over UDP but there has been work ongoing to run CoAP over TCP/TLS, > as you know. CoAP can also be used over other transports, such as S= MS. > > > A large amount of Management Information Base (MIB) [RFC3418] > specifications already exists for monitoring purposes. > > I would add a reference to the registry that lists those MIBs. > > Have you guys looked at what data really makes sense in an IoT context? > > > > > Not yet. > Since YANG is modular the vendor has lots of freedom to deploy > functionality where it is needed. I have to admit I don't fully understand YANG. I have read through OMA LWM2M and compare it against that spec. OMA LWM2M is much easier to understand since it has a simple object structure. > > IMO the most significant aspect of CoMI is that is uses modular data models > and the management content is decoupled from the protocol. > Really small devices with 2 or 3 leafs to export should not bother with= > CoMI. > There is a cost to decoupling the content layer, and it is not worth th= e > cost if that layer is utterly trivial. > > There are common modules like ietf-interfaces that should > be applicable even on IoT devices. > > > > > > This data can be accessed in RESTCONF if the server converts the SMIv2 > modules to YANG, using the mapping rules defined in [RFC6643]. > > Is it correct to say that this conversion happens once during the > development time rather than runtime? (Needless to say that this makes a > huge difference in terms of code complexity and runtime performance= =2E) > > > yes -- conversion is with RFC 6643. > This produces instance identifiers which are converted to YANG Hashes i= n > CoMI > It might be useful to make this clear in the document. > > > > > Stateless communication is encouraged to > keep communications simple and the amount of state information small > in line with the design objectives of 6lowpan [RFC4944] [RFC6775= ], > RPL [RFC6650], and CoAP [RFC7252]. > > This is a strange sentence. With stateless communication you have n= o > state. Typically, you will have to create somewhere else in the protocol > stack and only a certain layer is stateless. > > > > NETCONF is very stateful. > It can take up to 10 roundtrips to complete a single editing transactio= n. > By contrast, RESTCONF or CoMI require 1 roundtrip instead. > We will clarify that the management operations are stateless. > Thanks for clarifying this aspect in a future version of the draft. > > > > Additionally, I would remove the references to [RFC4944] [RFC6775], RPL > [RFC6650] since these specs are irrelevant for this work. It just creats > a longer reference list. > > > The end goal of CoMI is to provide information exchange over > the CoAP > transport protocol in a uniform manner as a first step to the fu= ll > management functionality as specified in > [I-D.ersue-constrained-mgmt]. > > I personally don't believe that the main value of this specification is > the ability to use CoAP. Instead, I believe the value is in re-usin= g > existing management objects. The code for the different transport > protocols isn't that large after all... > > > > For those of us moving to YANG-based automation, that is the main > reason for using CoMI. IMO why not just use SNMP if you > just want to poll some existing counters? There is really no business case > at all to rip out SNMP and redo all the instrumentation in CoAP/YANG. I personally haven't heard anyone asking us to implement SNMP for IoT device management. That's probably because other solutions have been made available already. > I don't buy the premise that all this R&D money will be better spent > redoing all the > instrumentation in CoAP, rather than just providing enough memory to ru= n > both > SNMP and CoAP When you look at the classes of IoT devices described in RFC 7228 then you may notice that this approach does not work too well. Of course, you may question the class descriptions. > > > > > CoMI supports MIB modules which have been translated > from SMIv2 to YANG, using [RFC6643]. This mapping is read-only s= o > writable SMIv2 objects need to be converted to YANG using an > implementation-specific mapping. > > I am not sure I understand the implications of this design decision. It > sounds like a negative thing to me. > > > The read-only restriction is to avoid putting RowStatus into YANG. > The edit model for SNMP is not compatible with anything else. > Supporting SMIv2 configuration objects is not a priority, I guess I will have to do a bit more reading to understand this response.= > > > > > > CoMI uses a simple URI to access the management object resourc= es. > Complexity introduced by instance selection, or multiple object > specification is expressed with uri-query attributes. > > This sentence is strange. You are saying that the URI is simple but then > in the next sentence you talk about complexity due to the query > attributes. Is the query attribute the same as a query parameter? When I > searched through the document for 'uri-query' then I found pretty m= uch > nothing. > > > Terminology > > When I look at the terminology section and all the specifications a= > reader needs to understand in order to be able to read this > specification then I don't feel very comfortable. Isn't there a way= to > make it less complex. After all, you do very little. > > > o The signature of the CoAP request in the server is standardized. > > What does signature mean in this context? Are you talking about security > stuff here? > > Ciao > Hannes > > > Ciao Hannes > > Andy > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --rR9jAIaXAPP8AtgibkfQW0DrkioED1Bbs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV99OGAAoJEGhJURNOOiAtnnoH/1CGJexh0/EcaKBZ+nq8RI6d tHgT3YW2dWDJSUu0oZg2JzBXnGjU64RCADV5Y+2j1YMN5/dwbSwE73Xph7quD3rL z51MXzXcZ8FdG3RipIeU2kBWQ1RdK/ZRYXYUKf1UhiCjspdsMAWsXX7XgKjzlByM c1CSCR00HAJ8ARxjqGXuOP+EFUf296HUIBdtUtB7Vz9JXlUyS2QEg1HA8RfwMSCN UYgRY5juUBU+oZydCk6yNQ2VohLGz7RXQkFtfeH92qTLlzXjwHzwjcKpTP74rG8B X+jXhWESIuNeKBoY4yRRZAL0Ez47MjzVSEWLindYThTKIu6I/PUKR/so4UshtRY= =etT2 -----END PGP SIGNATURE----- --rR9jAIaXAPP8AtgibkfQW0DrkioED1Bbs-- From nobody Tue Sep 15 02:38:03 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 E3E531A7013 for ; Tue, 15 Sep 2015 02:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 D2E5f50IoJc1 for ; Tue, 15 Sep 2015 02:38:00 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C662C1B3929 for ; Tue, 15 Sep 2015 02:37:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 91A6D1352; Tue, 15 Sep 2015 11:37:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id B6mhC6q0QiJq; Tue, 15 Sep 2015 11:37:57 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 15 Sep 2015 11:37:57 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C943C20048; Tue, 15 Sep 2015 11:37:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nx2o8qAxiIux; Tue, 15 Sep 2015 11:37:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 50CB02004E; Tue, 15 Sep 2015 11:37:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 971043721203; Tue, 15 Sep 2015 11:37:52 +0200 (CEST) Date: Tue, 15 Sep 2015 11:37:51 +0200 From: Juergen Schoenwaelder To: Hannes Tschofenig Message-ID: <20150915093750.GB69570@elstar.local> Mail-Followup-To: Hannes Tschofenig , Andy Bierman , "core@ietf.org WG" References: <55F2EB1A.5060409@gmx.net> <55F7D385.1060908@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55F7D385.1060908@gmx.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] COMI X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 09:38:02 -0000 On Tue, Sep 15, 2015 at 10:15:01AM +0200, Hannes Tschofenig wrote: > > > > Why can't they use RESTCONF then? > > The CORE WG should focus on CoAP. > > The more options, the more complex it gets, not easier. > > It is of course a question about what the folks in the CORE working > group believe they will be using in their deployments. We hear a lot of > folks asking for protocols other than CoAP over UDP. It is hard to say > whether they are only interested to hear whether that's is possible or > whether they are really interested to deploy HTP2 or QUIC. Hard to say > at this point in time but I believe the COMI specification by its nature > does not need to be strongly tied to CoAP (which Carsten seems to > confirm in his email response). > > Regarding RESTCONF: Based on your response below it appears that > RESTCONF by itself is very wasteful and not very useful for an IoT > deployment. > Most RESTCONF implementations likely use JSON encoding of the payload but this is actually not hardwired and it should be possible to use something more space efficient if needed (the IETF started to like CBOR, I am not sure whether the industry will pick it up or whether other binary encodings will be used). The only part where RESTCONF is kind of verbose is the way objects are named, using relatively long URLs. Finding ways to reduce the URL verbosity has been driving much of the CoMI discussions as far as I can tell. Whether CoAP is going to rule the IoT world or HTTP/2 or ... is difficult to answer but I bet that the CORE working group has a certain perhaps biased opinion here. ;-) > > Not yet. > > Since YANG is modular the vendor has lots of freedom to deploy > > functionality where it is needed. > > I have to admit I don't fully understand YANG. I have read through OMA > LWM2M and compare it against that spec. OMA LWM2M is much easier to > understand since it has a simple object structure. With YANG getting more widely adapted, we might see the same discussion that we see on the protocol side - use something more mainstream that is not optimal for IoT devices but perhaps good enough or use something tailored for IoT devices but not used widely outside this specific context. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Sep 15 03:00:53 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 63A091B35C6 for ; Tue, 15 Sep 2015 03:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 kdsdxYYnMnL4 for ; Tue, 15 Sep 2015 03:00:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 3A6941B30DB for ; Tue, 15 Sep 2015 03:00:50 -0700 (PDT) Received: from [192.168.10.181] ([134.76.0.127]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LlV71-1Z0Wsg1uqN-00bNIW; Tue, 15 Sep 2015 12:00:41 +0200 To: Andy Bierman , "core@ietf.org WG" , j.schoenwaelder@jacobs-university.de References: <55F2EB1A.5060409@gmx.net> <55F7D385.1060908@gmx.net> <20150915093750.GB69570@elstar.local> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <55F7EC47.8090803@gmx.net> Date: Tue, 15 Sep 2015 12:00:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150915093750.GB69570@elstar.local> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qaf0JSe3q5NPAIdeoIeCBVk3Fw7O7PoDk" X-Provags-ID: V03:K0:dfiZCRCNlTDyxhMqoyNmKqsrbFYBpp5qu+aWoE+5Ym3uWKfIMin vhhq4GW+JSBeHl8bWKCzWkPKYNYPc837u38dFdMHROR6UvAhZdmrwcwd5lYrgQ1+bZN8KIl OLhIqNCE9mabEMvUfeLA2hYrpTEcWuOOU3sLUErbbTqME6rc6x66ann01hGSW6ymTDnckmS mflZ1NHKSy36P1GMYEtSg== X-UI-Out-Filterresults: notjunk:1;V01:K0:LWe2Ci0Vuz4=:VOuIqH4+0IrO53XrOORYgh FlVoeZHYbw0nmOjrc50ZHDZRpO9rGLc9nJRtOJh3gPNJrzm4P936KkxRzsQwbSkZi376GdZ3g CzO1f9DZW9UeO68v+BVgprS7nNM3qTzZHUT6JkOmvNZNxlPqKfx3QUuB3S/8hIjZ673/L2vMR vD9gik1dugfp4+MS3db/XL2/CaEZH3xPQJQhiPZqOVpNHRl3uw1sQOuGhVpDiTEwLwekQ/xOZ M1DIk/TPqTXnUgVJBxNUMY2kfYYLG8SCkV678+OXjkxIDEzXTmh4wJ1U46yStiMPYANlbdccK fyH3BA6FXysR4Bkk1a1V2wTe2tEUpuUfQsit3tHSMkBnjV4m1JRY4Kz+LCMeJVZ2rO/v4xO/p bUARabP3cJ/J5kNAoPqLjXyjgKD+ghzc5XmwSqnsa/D+5DJDkocsN/z8muQZ7nntc2wUMRyEn op+4FIVCtj/W4pQUE3Xb47pY+BJTVBQX5+MuAvZ1SNWrFJ2egwW30eab9ifpCqLMDBZPcTQsy jS62MJ1f3yoiFwFv+mnwqhGdFwdoWX4mJsJWg7UvSOhaz1Cc1qPCUsaHEmnxTwWuJfXMU8vsC yjNuQgTtetbR9G88FNeIIowAtgHMlDDx6m/m5+0sZhCpEChGh+FrtGM8+XHvHsDLCui9eLMpj /byuylpgpoPmcdABAaywpXU0Sl/MWsf9ZMmHVsYcE29swy07n7JKJsJunmZP2xkkAHfAf56s6 Un/GtiOJvg0mgJjF Archived-At: Subject: Re: [core] 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, 15 Sep 2015 10:00:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qaf0JSe3q5NPAIdeoIeCBVk3Fw7O7PoDk Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Juergen, thanks for the feedback. On 09/15/2015 11:37 AM, Juergen Schoenwaelder wrote: > On Tue, Sep 15, 2015 at 10:15:01AM +0200, Hannes Tschofenig wrote: >>> >>> Why can't they use RESTCONF then? >>> The CORE WG should focus on CoAP. >>> The more options, the more complex it gets, not easier. >> >> It is of course a question about what the folks in the CORE working >> group believe they will be using in their deployments. We hear a lot o= f >> folks asking for protocols other than CoAP over UDP. It is hard to say= >> whether they are only interested to hear whether that's is possible or= >> whether they are really interested to deploy HTP2 or QUIC. Hard to say= >> at this point in time but I believe the COMI specification by its natu= re >> does not need to be strongly tied to CoAP (which Carsten seems to >> confirm in his email response). >> >> Regarding RESTCONF: Based on your response below it appears that >> RESTCONF by itself is very wasteful and not very useful for an IoT >> deployment. >> >=20 > Most RESTCONF implementations likely use JSON encoding of the payload > but this is actually not hardwired and it should be possible to use > something more space efficient if needed (the IETF started to like > CBOR, I am not sure whether the industry will pick it up or whether > other binary encodings will be used). The only part where RESTCONF is > kind of verbose is the way objects are named, using relatively long > URLs. Finding ways to reduce the URL verbosity has been driving much > of the CoMI discussions as far as I can tell. >=20 > Whether CoAP is going to rule the IoT world or HTTP/2 or ... is > difficult to answer but I bet that the CORE working group has a > certain perhaps biased opinion here. ;-) >=20 I am new to this network management and so I have to trust what others tell me. From your description it almost sounds like RESTCONF is not a big problem either. Did you or someone else did a performance analysis? It is hard to see whether some of these design will positively impact deployment but my feeling is that we should offer flexibility where it does not cost much. In the area of the underlying protocol it looks like we have a low-hanging fruit. >>> Not yet. >>> Since YANG is modular the vendor has lots of freedom to deploy >>> functionality where it is needed. >> >> I have to admit I don't fully understand YANG. I have read through OMA= >> LWM2M and compare it against that spec. OMA LWM2M is much easier to >> understand since it has a simple object structure. >=20 > With YANG getting more widely adapted, we might see the same discussion= > that we see on the protocol side - use something more mainstream that i= s > not optimal for IoT devices but perhaps good enough or use something > tailored for IoT devices but not used widely outside this specific cont= ext. That's the reason why I look into it. Ciao Hannes >=20 > /js >=20 --qaf0JSe3q5NPAIdeoIeCBVk3Fw7O7PoDk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV9+xIAAoJEGhJURNOOiAtyGYH/3CpZRWXnBcvOrWlqpJOwnEN N8sVxPpCmTAtpg8NszO8ViySXtSXwaCKEipksNJEG04eHAK/FgZ/YvFdFuHx4/GO 988uRuh8nlHf2TP5ZFXrQBuQn4R9KFkbudm18GDr0luSEqiy2K+V+d8p9iLnZVSJ iNC/VOtiZbDHDl9aEA0zTyvRIvj/ZJED6z9fx+iX+k3z44vbvy5HllTJw5IOg18h JazxUfjye47hKHzl4qwJbHyLI7FednAkioSHbD0kcMtuBfXMeUcLp+ntpdCFI5RH sNSUsaGNah160Tvft0i4yJsNxtsWGWfTgveNw1PmuCEyRUfDoleSWbAZHQzafa0= =nyhs -----END PGP SIGNATURE----- --qaf0JSe3q5NPAIdeoIeCBVk3Fw7O7PoDk-- From nobody Tue Sep 15 03:40: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 9DC291A1B0B for ; Tue, 15 Sep 2015 03:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 VLtnCD83TTwi for ; Tue, 15 Sep 2015 03:40:14 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3611B2A06 for ; Tue, 15 Sep 2015 03:40:13 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.195]) by smtp-cloud3.xs4all.net with ESMTP id HNgB1r0044CYHle01NgBnf; Tue, 15 Sep 2015 12:40:12 +0200 Received: from AMontpellier-654-1-59-4.w86-202.abo.wanadoo.fr ([86.202.194.4]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 15 Sep 2015 12:40:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 15 Sep 2015 12:40:11 +0200 From: peter van der Stok To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20150914102453.GA1786@hephaistos.amsuess.com> References: <20150908145930.GB4537@hephaistos.amsuess.com> <20150909101133.GD4537@hephaistos.amsuess.com> <2455258a29e2d7bf4bbe75d2df4c3f26@xs4all.nl> <20150910110729.GF4485@hephaistos.amsuess.com> <699910a6e837a2887374622ea422cc66@xs4all.nl> <20150914102453.GA1786@hephaistos.amsuess.com> Message-ID: X-Sender: stokcons@xs4all.nl (9LNjzRK0iqk6GJIvNf9F3iqwRDtCPwnq) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] Concurrent modifications suggestion in draft-vanderstok-core-patch-01 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, 15 Sep 2015 10:40:20 -0000 Hi Christian, see below. Christian Ams眉ss schreef op 2015-09-14 12:24: >> Add: When an error has occurred, and the resulting resource state is >> inconsistent, the server MUST return to an earlier consistent resource >> state. > > Such a wording, in my opinion, might do more harm than good. Probably, you are right. It is removed. > For failed precondition the following text is suggested Failed precondition: In case the client uses the conditional If- Match or If-None-Match option to define a precondition for the PATCH request, and that precondition fails, then the server can return the 4.12 (Precondition Failed) CoAP error. > >> The server SHOULD return the actual resource state to provide >> the client with the means to create a new consistent resource >> state. > > I think that a diagnostic message (or none) is better suited here. > Having diagnostics is a SHOULD of RFC7252, the HTTP PATCH doesn't > auto-respond with the latest version either. I'm not saying it can't be > done, but it'd need to be done carefully. So far, afaict this would be > the first non-successful response code that would transmit a (possibly > blockwise'd) content payload. We will probably revert to the http text, and add a MAY for returning the resource state. > > I'm tempted to ask Lisa Dusseault (the author of > RFC5789 and [1]) to comment on this thread around [2]; she has > definitely given this topic some thought -- have you been in contact > with her during this draft? Please, go ahead. We did not have contact with her on the topic. > > Best regards > Christian > > [1] http://www.ietf.org/mail-archive/web/ietf/current/msg59171.html > [2] > http://mailarchive.ietf.org/arch/msg/core/JI_TqZQFuMfdTs-MnQuKrrNgCPs Greetings, peter From nobody Tue Sep 15 07:34: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 CDEF41B3FEC for ; Tue, 15 Sep 2015 07:34:02 -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, HTML_MESSAGE=0.001, 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 FAnFAY29gnxf for ; Tue, 15 Sep 2015 07:33:49 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::751]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07EF01B35F1 for ; Tue, 15 Sep 2015 07:33:47 -0700 (PDT) Received: from DB3PR06MB155.eurprd06.prod.outlook.com (10.141.1.146) by DB3PR06MB092.eurprd06.prod.outlook.com (10.141.1.27) with Microsoft SMTP Server (TLS) id 15.1.268.17; Tue, 15 Sep 2015 14:33:29 +0000 Received: from DB5PR06CA0021.eurprd06.prod.outlook.com (10.162.165.31) by DB3PR06MB155.eurprd06.prod.outlook.com (10.141.1.146) with Microsoft SMTP Server (TLS) id 15.1.268.17; Tue, 15 Sep 2015 14:33:25 +0000 Received: from AM1FFO11FD017.protection.gbl (2a01:111:f400:7e00::131) by DB5PR06CA0021.outlook.office365.com (2a01:111:e400:52c2::31) with Microsoft SMTP Server (TLS) id 15.1.268.17 via Frontend Transport; Tue, 15 Sep 2015 14:33:25 +0000 Authentication-Results: spf=fail (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=tridonic.com; Received-SPF: Fail (protection.outlook.com: domain of tridonic.com does not designate 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATDOAGMSX01.itiso.net; Received: from ATDOAGMSX01.itiso.net (146.108.200.10) by AM1FFO11FD017.mail.protection.outlook.com (10.174.64.206) with Microsoft SMTP Server (TLS) id 15.1.262.18 via Frontend Transport; Tue, 15 Sep 2015 14:33:24 +0000 Received: from ATDOAGMSX02.itiso.net ([169.254.4.182]) by ATDOAGMSX01.itiso.net ([169.254.3.31]) with mapi id 14.03.0224.002; Tue, 15 Sep 2015 16:33:23 +0200 From: Somaraju Abhinav To: "core@ietf.org WG" Thread-Topic: [core] CoMI support for YANG notification and RPC Thread-Index: AdDvwvT04pkUut0OTPiQtZs59tyOew== Date: Tue, 15 Sep 2015 14:33:22 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0985F1@ATDOAGMSX02.itiso.net> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.41.149] Content-Type: multipart/alternative; boundary="_000_0E9A48AB39AF3547ACD28A6DE3E2906A0985F1ATDOAGMSX02itison_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD017; 1:GICxT7FrWVJVpbhHFrgTJdPQAbLUQzlPsjh5rjM2NgpfjnQLgyO8z0zHsZvRQutONUvjbvBLSox/JEjvGsBY2h+j/1A8i7zHP+nF/P+9GuYExL7VsBwI0+wAvhRDsFgmuzWmAnywS84fk7IPtf0V4ZHR/OfPTr06XMkrMlPmm3FR+vpuXutoooWAT+yj1J85Zdj8NpEZakWKc9NLLx2Tdn8hVLdS1ZXspfU7Izfy2B8INAFpzQ9WyuL2z5XIh9XELrsJizxMWeKTbbBORRu42JuncKdK2kVwczNxz7BVo0fl5A/BKTFAUqFJ2UbByNqYwSwpYpqhNtnYHmkGZhmXHg== X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(1110001)(1109001)(339900001)(377454003)(164054003)(38414003)(199003)(189002)(24454002)(19300405004)(26826002)(5003600100002)(64706001)(5001830100001)(11100500001)(5007970100001)(19580405001)(5004730100002)(229853001)(6806004)(69596002)(19580395003)(46102003)(86362001)(554214002)(575784001)(19617315012)(10710500005)(104016003)(19625215002)(106466001)(66066001)(110136002)(107886002)(2900100001)(5001920100001)(7110500001)(5001960100002)(33656002)(81156007)(189998001)(4001540100001)(450100001)(87936001)(5001860100001)(15975445007)(54356999)(84326002)(16236675004)(5890100001)(561944003)(85426001)(92566002)(50986999)(15974865002)(2920100001)(55846006)(2420400006)(53416004)(2930100002)(77156002)(105606002)(102836002)(512954002)(62966003)(579004)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR06MB155; H:ATDOAGMSX01.itiso.net; FPR:; SPF:Fail; PTR:unknown.zgrp.net; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3PR06MB155; 2:CRgGVqpMUwrFgIxYfPtjTjAmGiOrhnYGS9MJxQeb9PM5FnHdEWImkU+3GiPMdmLVHm2iId3WDEyQHOheQzRAlnIQAVVFIaWM0WQwSJE7ntMgmlkDQdL2mCFwkMCeRgf5e+eD7CqirTUq1aK3x94CyiRtACozZH1ir0xbqFMXXDw=; 3:1C4B9laiv0CW/crs06kRC6Tal92P8nVrab35c0l54/q9uuN+fcCVqKRTlf7ogqbXmRSOeAj1IXmPQ6u0TjGaQ35zydeeSw4ozW7jasRpZGLQG2uuUq4nB4kbPvUMIDTpZigAsRnJgsXcgP1JfbX88T86AXw13so9lvRvsUZUfBoyKYBE7u9F+LNu8Es9pYM7aAMyc8NyJj9HIWv63L1lNOlbY4D+flDzy61HorsbSvSnD3cY0MshFPM4Of6nJ/yOz7Z7cMu7bZHGPnqyXeQg6w==; 25:3JwG2eMrt3K/i4G6WjKKngdGGiAv5cbbYAEC2W5oeovbgZBo/eNWr5xu6l+Zz0HKgwl7WM8a6bkzZlW2thgaiMf4E0LasTABx1MN3bVtceMtUdjCcmbxhBJy23ROVde7ZNYbGCtDLiRyqIa32UHchxc9qkOcUDv63ZzOPrh4n3EdW8GNU6WaMyQGFMbEL/IJhvhulKgo0po+Vv1gDtiiQCYb5bIS6pFmWhI1GFDMOR2yPX+BAKsPUohAJvFDxXScifzbA6UfqEN1SIXGC8R3Vg== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001)(42140001); SRVR:DB3PR06MB155; X-Microsoft-Exchange-Diagnostics: 1; DB3PR06MB155; 20:t7o2bNJWKQcMI1fdBF9iC1mxJJNLpxzm6C/3F3pc8IJuMNZ0Gg8uJMhAOOW5Ab/AxUIvpdXUdRmxw4cLZ49nNbWgMb0cMNa5hj+QbrXtzmZlVGQ7puAtCHmwka3wSJvOy7Mlvx4ijUX7JVkArftZHDHf/4vlqbJVfy3YmqizTys+2E4IBxWUGTJXV37/OEpCcwgRHAS2RwjPRiAdI5QJQQnHF06X/VHeZ5nGByOh5MMH6Og21tX5wY7ifDwIQW/xN91kFzpT8JrP/WYwX+BPuPzGqq3ZhV/cby5dI70K56BNMrmKQuqMVavglZqnGzbJXCp/MhqQ3cBsCcuRjQxTUsTAIS8CtCWxVQ4xQDmt59mD2wV0vs65/mqqnOtNmvwk7CEYoWVHU0Kssr5oQu3spOQrlaN7lKp1ryMpti1JGPB7CZVdfJWX8RFfS1ssJ5LRigN+VDCSqujx2f9Rj0eImOfJPKHuskz3LAIHw0TLcohrEd9xFnz5gblPz9dbUQqw; 4:P6BsUzJ94pWJotPmv4BezzfyYoY+HLt8ihrJfL1DeLSrYhwdj9icQrmqZSMMozM0ZxGUFzmEearRxxwUSQvvcEBCpPLr395VVVr6LaANiDmQEG34eTAw6LxlUm3kdwHb0PqJ2P6qSJ2wmkJt7rPE+o22cA7jIJrIEm32VbDoUnjy5rMHokRLJdPamyqvAfvEoH6idD2TDYvoVrtXqp0drVJSCN7G3q+yZ3/ApYxGCwV6j81khFH84t3PQDbhucfUQwGT6JRPvYwZMWDkGZa2UVYwuGd2Vwd/0XFzIYleCkmBfgY0cTbPlDzaBMo/o8XLp8pYHA1/wKJurCulZLNMv+kBEJ7fI5i77dwFKxcyQXKp5hOz565lPKua/f5CR9Jz X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(108003899814671); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520058)(520075)(8121501046)(520078)(5005006)(3002001); SRVR:DB3PR06MB155; BCL:0; PCL:0; RULEID:; SRVR:DB3PR06MB155; X-Forefront-PRVS: 070092A9D3 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB3PR06MB155; 23:dWoOwahVzXvzXpIfCiyFg8gXNeZjCpimbVsdHOI7lB?= =?us-ascii?Q?TvXVf/FHbrXcYM588w4CVx+z7xgRRMcF9iFPEebYUk7iUna1+N4GzLZQf78g?= =?us-ascii?Q?83lIiy8XXqpb3x3H0OQEFIzvFNwULcdPRGqMUTLV99vlOo87w1KZB7pIxMoI?= =?us-ascii?Q?0A1LfwSY0fXhlfS/nWRy8srhCVpg+Y+DuSk483fjQM0S6iHNxlq3MQXp1Qgd?= =?us-ascii?Q?cHwBIyNg46xXp7GtyGpA9H/FBBy4TjEtUX9Pz4k1tRBgh/jzrZn8bGFhwisE?= =?us-ascii?Q?GIJGtNv49uZ2cWxzz4UnkpBnFNHvPrmnKBsKy0Ff9sCPhJkZmS391wnBoJzp?= =?us-ascii?Q?QYl2ktWeLHN8nlJzw2bR6g4cNsMFw5fOQiq8LgxWInWDH3rHeyZ7az9/tJO8?= =?us-ascii?Q?/YD/7GO+ibhjtlwYcgoyzlFJCpT2xVqUrtiZHCeWoAbn7d3+XoTjelPs7Kgs?= =?us-ascii?Q?npvGHvfmubBXS0AUxl6zKKHtA6MAx5lsZ/pLSK7AbZee8HJZDIiWfXM0qfQn?= =?us-ascii?Q?a8wCt0x+xsWN1xHQg1DJeJ/7zj3Ds+Yjngpw7G1wmG/poz2KVonYa5bXF7sh?= =?us-ascii?Q?GZssI6vhW60BOXYCH1F/GP93F02JqM5+5Qz1OFLyRX88ULBaVgfyXdhsCYcq?= =?us-ascii?Q?Fj32Yv9CJBOuKd5xCt4BMuPseBT7GeUPKKqx7INgXNAEZI/nZar+0GKv0Jgi?= =?us-ascii?Q?I6POoFGh4OUchi24BW99AWAKOTO23GMiX4XgFBKA4V5zErEo3FFIEucj7SX5?= =?us-ascii?Q?6fRy74+FZK31eUyJ8lFWmRbI9N6+RJrOEh1tTQTF8/HWt2iVCo4o4G5SJ4eZ?= =?us-ascii?Q?ZAFJYlzmQsogeWYz2ueDHV0Ljluu8pJwsbyTvQ3rAPYN6HsAGnJkQQRiRAFp?= =?us-ascii?Q?7aLNe+gdcHsl5JndDpKgw1Q4Pbb8+lzma5iLvsaTS0bNq0ovy+7lfipEBPwL?= =?us-ascii?Q?zhYcVQQNJFaHJkV4T5Upj9zdHBSRf7CG8TOlnsLk16gup2ae1/RMwGejiuqz?= =?us-ascii?Q?BdYRwo1mxHtufT3k5TZiCWERjS4p5YjD30OY8MIL60eEvPmsgTvkyNpzZrQ6?= =?us-ascii?Q?NC5bcY5ZWLDU1Y5xlZWdZf+j89nsAI/00yQiuE5SI2pTkGAZGtm6+tXor1GV?= =?us-ascii?Q?o5C8CPMouOJXegDh1RXdFiJlsaKpNhatxAi8fZUx9awWhLKqse3k9o2DqXcF?= =?us-ascii?Q?+kIYNDIbUtXWOiYt+AIjvpCXq4wP4P1crOwNfbywS2aKUU0jGl9q558QTNil?= =?us-ascii?Q?67hgJ3cGXunzC0Px30kIqr+Uk9ZxDdbVCGeOMOGRupdx8719jrEaKzdp/gqk?= =?us-ascii?Q?pIc0l1i3IyrKZV7sw8VxlNMAx6B+rTufZD2TbvX+yR8ZGKz1xFGqcikptJnG?= =?us-ascii?Q?QKJDUEKlSdulCU5NQ6ZJsCUun7zdJoTPtEYJ0lTGF6eUuxzfIM+N5O2073W6?= =?us-ascii?Q?Ik/djJD7WTlbCowYX2d0A0/IrUoafJl0ITtgvzDYFJPJN001wIya4vU9Fzts?= =?us-ascii?Q?UOYKOjnHXA2KaL7Un+ncgadBPhUWDvVeeRaB8Zaq78UkEkYKhd8debVH04l2?= =?us-ascii?Q?9Y9/DG1duC1iFZidWzIaslz4J/s+OLJDQGGKG32WYZkjA3R5QSlOvqTOfO5o?= =?us-ascii?Q?eLzISeQ3MgJ+83RoBizFiYkvCyUZtIMZ7xVjaPIIBg1DiJ+xFQCU1aJZLr8r?= =?us-ascii?Q?a7ss2DMQzd0TmtzFUMRieAWU5O8wjipED624G1gLbOyoxOllU1Xi12mWhFOp?= =?us-ascii?Q?t+rnrjENpbXzteVEi2WMKp+nVHqCo0p170QAfEjhqh8/Okgd5l1z9jmjyLvP?= =?us-ascii?Q?ECBW43oGVx?= X-Microsoft-Exchange-Diagnostics: 1; DB3PR06MB155; 5:D8Vu1jGdbzianTrjIq6U3vv7mfuR5gUIYoVfLTqAVsKaupnf1UX93CGirPFwTW6ThAF5w9d+k4IxrM2iukO9gBFeB7Y1Y7MvtofTKod/GcNKRqH2TVoM98WjpPAYwEc/wvcSimZ6mgLYykKSe0g2Mg==; 24:n95H1SQEufoSx9QbcN9WtFSPBfcPp+/Hk4MnH3cSKjR8ym//e1zQUby7KcFq1mp7BHCNzZ+ALc18DypLbR5o6xWYuIRjl8GYUsANr7VG6vc=; 20:/GsJqgkR7Q+s+FNjsAEf2bBLJU/fA1AIBUtl1IacnNNO1MRxc3UHuQc5XgIceF5fwUwOHSqKCOJYEF2InTKxVQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2015 14:33:24.6373 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATDOAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR06MB155 X-Microsoft-Exchange-Diagnostics: 1; DB3PR06MB092; 2:FNt+1CLuLqT7FSWFydW7+FIABaXC8GxwrDBZly6YLOB+Uq6G8ESg1ODOajzCs/gjBvgHOVtgnxZpqEHyKW7rRX//Y/0kjN1DGGQtujn7gFHjb6i9kLXkAof9kSaJUzMM1VURBlHtN3jPwU7TPbi3dFaLPWkSWhv4Gp4OXRUSqqg=; 23:5/LpSIRITheUhwDT5csBY1lsbD2VlPBRrv0byi7Z0WcUv3vtGEBgjFqaC8lfXVK+7n8UwhFBnynVRcm4xFcqhTlIRuGMJRvFMaUAE6ld7JrvJ4QrqDDyITJzscGHrmWxlS5Ew9SfWvvfH4SCsEyJ5stj0hTELzi6k9ws3IqvJcaujLMVkMj71r9UAe3RBbs4 X-OriginatorOrg: tridonic.com Archived-At: Subject: [core] CoMI support for YANG notification and RPC 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, 15 Sep 2015 14:34:03 -0000 --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0985F1ATDOAGMSX02itison_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi CoMI authors, I have recently started looking into CoMI and find it is very suitable for = our application. However, I am looking for support for YANG RPCs and see no= mention of RPCs in the CoMI draft. I found a discussion in the mail archiv= e in Core WG and it seems that there was some support for this idea already= but could not find a final decision regarding this topic. Could you please= explain if a decision was made regarding the use of RPCs in CoMI. Thanks, Abhinav Andy Bierman Mon, 20 April 2015 20:40 UTCShow header Hi, This is an interesting proposal -- I support it. There are details to work out of course. There is no proposal for using observe + pub/sub to implement CoMI notifications. I think tradition event notifications are needed because they tend to use less resources. They tend to be aggregations and are sometimes time throttled, often defined with a default periodic interval. On Mon, Apr 20, 2015 at 1:03 PM, Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > The current revision of CoMI (draft-vanderstok-core-comi-06) specify > YANG as data modeling language but do not support two important features = of > this language, notification and protocol operations (RPCs). Support of > these core features of the YANG modeling language should be added to CoMI > for the following reasons: > > > > * CoMI should not be limited to YANG modules specifically defined > for it. > YANG modules already defined with notifications and protocol operations > (RPCs) should be compatible with CoMI. > > * Notifications and protocol operations (RPCs) are optional and > don't require extra resources when not needed. > This would need to be optional to implement in the server. In NETCONF/RESTCONF, they are also all-or-nothing, meaning if notification delivery is supported, than all YANG notification-stmts must be supported. All rpc-stmts must also be supported in every server (no consensus on this point for RESTCONF yet). IMO, CoMI compliance might be different than the original YANG module intended for NETCONF or RESTCONF. It might make sense to let the server * The notification mechanism is complimentary to the already > supported observe mechanism, both mechanism can be supported simultaneous= ly > and address two different use cases. > > * The notification mechanism: > > o Allow a client to subscribe to a notification stream using a single > request (CoAP GET) > > o Allow a client to subscribe to a notification stream without the need > to be aware of the specific data nodes implemented by this server > > o Allow a client to request a replay of past notifications (events > recorded in the absence of this client) > This is optional to implement on a NETCONF or RESTCONF server. IMO not likely this would be supported by a CoMI server. Andy o Allow transfer of multiple information associated to an event, some > can be specific to this event and as such should not be part of the > management data (/mg) > > * RPCs is a controversy subject. > For sure, RPCs shall not be used to replace simple GET or PUT actions, > however there is valid use cases for RPCs such as: > > o To implement complex actions (e.g. "toggle switch" can be implemented > using a combination of GET switch state, ETag and PUT but can be > implemented more efficiently using RPC) > > o A RPC can have both input and output parameters which is not possible > with a GET or a PUT. > > o RPCs may carry information specific to this action and as such should > not be part of the management data (/mg) > > > The following sections show possible text to be added to CoMI to support > Notifications and RPCs. > > > ------------------------------ > > > > 4.4. Protocol operations > > > > The CoMI protocol supports protocol operations defined using the YANG > "rpc" statement. The solution implemented is based on > [I-D.ietf-netconf-restconf] section 3.6. > > > > 4.4.1. Server Support > > > > A COMI server is not required to support COMI protocol operations. Client= s > may determine if a server supports protocol operations by sending a GET > request to "/.well-known/core" including a resource type (RT) parameter > with the value "core.rpc". > > > > 4.4.2. Operation resource > > > > The operation resource is a container that provides access to the > data-model specific protocol operations supported by the server. Protocol > operations are invoked by CoMI clients using a CoAP POST request on this > resource. > > > > 4.4.3. Encoding Operation Input Parameters > > > > If the "rpc" statement has an "input" section, then the "input" node is > provided in the message-body. The encoding of the "input" node follow CBO= R > mapping rules defined in section 5. > > > > For example: > > > > Assuming the following YANG defined rpc. > > > > rpc reboot { > > input { > > leaf delay { > > units seconds; > > type uint32; > > default 0; > > } > > leaf message { type string; } > > leaf language { type string; } > > } > > } > > > > Assuming the module example-ops is module ID 43 or "r" in base64 > > Assuming the following YANG hash values: > > "/example-ops:reboot" =3D 283286310 or "Q4psm" in base64 > > "/example-ops:reboot/example-ops:delay" =3D 980546150 > > "/example-ops:reboot/example-ops:message" =3D 882566796 > > "/example-ops:reboot/example-ops:language" =3D 284280286 > > > > The CoMI client might send the following POST request message: > > > > REQ: POST example.com/RPC/r/Q4psm > > { > > 980546150 : 600, > > 882566796 : "Going down for system maintenance", > > 284280286 : "en-US" > > } > > > > The CoMI server might respond: > > > > RES: 2.00 Ok > > > > 4.4.4. Encoding Operation Output Parameters > > > > If the "rpc" statement has an "output" section, then the "output" node is > provided in the message-body of the CoAP response. The encoding of the > "output" node follow CBOR mapping rules defined in section 5. > > > > > > For example: > > > > Assuming the following YANG defined rpc. > > > > rpc get-reboot-info { > > output { > > leaf reboot-time { > > units seconds; > > type uint32; > > } > > leaf message { type string; } > > leaf language { type string; } > > } > > } > > > > Assuming the module example-ops is module ID 43 or "r" in base64 > > Assuming the following YANG hash values: > > "/example-ops:get-reboot-info" =3D 683557230 or "ovkFu" > > "/example-ops:get-reboot-info/example-ops:reboot-time " =3D 342555434 > > "/example-ops:get-reboot-info/example-ops:message" =3D 762496844 > > "/example-ops:get-reboot-info/example-ops:language" =3D 353194165 > > > > The client might send the following POST request message: > > > > REQ: POST example.com/RPC/r/ovkFu > > > > The server might respond: > > > > RES: 2.05 Content (Content-Format: application/cbor) > > { > > 342555434 : 30, > > 762496844 : "Going down for system maintenance", > > 353194165 : "en-US" > > } > > > ------------------------------ > > > > 4.5. Notifications > > > > The CoMI protocol supports YANG-defined event notifications. The solution > implemented is based on [I-D.ietf-netconf-restconf] section 6. > > > > 4.5.1. Server Support > > > > A COMI server is not required to support COMI notifications. Clients may > determine if a server supports notifications by sending a GET request to > "/.well-known/core" including a resource type (RT) parameter with the val= ue > "core.streams". > > > > 4.5.2. Event Streams > > > > A CoMI server that supports notifications MUST populate a stream resource > for each notification delivery service access point. A CoMI client can > retrieve the list of supported event streams from a CoMI server using the > GET operation on the stream list. > > > > The "restconf-state/streams" container definition in the > "ietf-restconf-monitoring" module (defined in [I-D.ietf-netconf-restconf] > section 9.3) is used to specify the structure and syntax of the child > resources within the "streams" resource. > > > > For example: > > > > Assuming the module ietf-restconf-monitoring is module ID 2 or "C" in > base64 > > Assuming the following YANG hash values: > > "/rcmon:restconf-state/rcmon:streams" =3D 869048475 or "zzKCb" in base64 > > "/rcmon:restconf-state/rcmon:streams/rcmon:Stream" =3D 305096898 > > "/rcmon:restconf-state/rcmon:streams/rcmon:Stream/rcmon:name" =3D 9314638= 46 > > "/rcmon:restconf-state/rcmon:streams/rcmon:Stream/rcmon:description" =3D > 425672327 > > "/rcmon:restconf-state/rcmon:streams/rcmon:Stream/rcmon:replay-support" = =3D > 301154294 > > "/rcmon:restconf-state/rcmon:streams/rcmon:Stream/rcmon:replay-log-creati= on-time" > =3D 126010158 > > "/rcmon:restconf-state/rcmon:streams/rcmon:Stream/rcmon:encoding" =3D > 374857305 > > "/rcmon:restconf-state/rcmon:streams/rcmon:Stream/rcmon:encoding/rcmon:ty= pe" > =3D 836936555 > > "/rcmon:restconf-state/rcmon:streams/rcmon:Stream/rcmon:encoding/rcmon:ev= ents" > =3D 201862865 > > > > The client might send the following request: > > > > REQ: GET example.com/mg/C/zzKCb > > > > The server might send the following response: > > > > RES: 2.05 Content (Content-Type: application/cbor) > > { > > 869048475 : { > > 305096898 : { > > 931463846 : "default", > > 425672327 : "Default event stream", > > 301154294 : true, > > 126010158 : "2015-04-15T15:58:00Z", > > 374857305 : { > > 836936555 : "cbor", > > 201862865 : "coaps://example.com/streams/default" > > } > > }, > > 305096898 : { > > 931463846 : "syslog-critical", > > 425672327 : "Critical and higher severity", > > 301154294 : true, > > 126010158 : "2015-04-14T00:00:00Z", > > 374857305 : { > > 836936555 : "cbor", > > 201862865 : "coaps://example.com/streams/syslog-critical" > > } > > } > > } > > } > > > > 4.5.3. Subscribing to Receive Notifications > > > > CoMI clients can determine the URI for the subscription resource (to > receive notifications) by sending a GET request for the "events" leaf > within the stream list entry. The value returned by the server can be us= ed > for the actual notification subscription. > > > > The client will then send a GET request for the URI returned by the serve= r > with the "Accept" type "application/cbor". > > > > 4.5.3.1. Query parameters > > > > Query parameters are optional to implement, and only available if the > server supports them. > > +------------+---------+-------------------------+ > > | Name | Section | Description | > > +------------+---------+-------------------------+ > > | start-time | 4.8.9 | replay event start time | > > | stop-time | 4.8.10 | replay event stop time | > > | filter | 4.8.8 | content filter | > > +------------+---------+-------------------------+ > > > > CoMI Streams Query Parameters > > > > 4.5.3.2. The "start-time" Query Parameter > > > > The "start-time" parameter is used to trigger the notification replay > feature and indicate that the replay should start at the time specified. > If the stream does not support replay, per the "replay-support" attribute > returned by the stream list entry for the stream resource, then the serve= r > MUST return the error code 4.00 Bad Request. > > > > This parameter is only allowed for GET methods on a /streams data > resource. A 4.00 Bad Request error is returned if used for other methods > or resource types. > > > > If this parameter is not present, then a replay subscription is not being > requested. It is not valid to specify start times that are later than the > current time. If the value specified is earlier than the log can support, > the replay will begin with the earliest available notification. > > > > If the "replay-support" leaf is present in the "stream" entry, then the > server MUST support the "start-time" and "stop-time" query parameters for > that stream. > > > > 4.5.3.3. The "stop-time" Query Parameter > > > > The "stop-time" parameter is used with the replay feature to indicate the > newest notifications of interest. This parameter MUST be used with and ha= ve > a value later than the "start-time" parameter. > > > > This parameter is only allowed for GET methods on a /streams data > resource. A 4.00 Bad Request error is returned if used for other methods > or resource types. > > > > If this parameter is not present, the notifications will continue until > the subscription is terminated. Values in the future are also valid. In > this case the subscription will automatically terminate at the specified > "stop-time". > > > > If the "replay-support" leaf is present in the "stream" entry, then the > server MUST support the "start-time" and "stop-time" query parameters for > that stream. > > > > 4.5.3.4. The "filter" Query Parameter > > > > The "filter" parameter is used to indicate which subset of all possible > events are of interest. If not present, all notifications not precluded b= y > other parameters will be sent. > > > > This parameter is only allowed for GET methods on a /streams data > resource. A 4.00 Bad Request error is returned if used for other methods > or resource types. > > > > The format of this parameter is a comma separated list of module IDs > formatted in base 64. To filter a subset of the notifications defined in = a > module, the module ID is followed by a comma separated list of the YANG > hash values associated to each notification of interest. Each notificatio= n > list is delimited by parentheses and hash values are formatted in base 64= . > > > > For example: > > > > Assuming the module toaster is module ID 47129 or "LgZ" in base64 > > Assuming the module nc-notifications is module ID 18 or "S" in base64 > > Assuming the following YANG hash values: > > "/rc:notification/toast:toastDone" =3D 128560783 or "Hqa6P" in base64 > > "/rc:notification/manageEvent:replayComplete" =3D 162935187 or "JtjGT" > > "/rc:notification/manageEvent:notificationComplete" =3D 901415891 or "1uo= PT" > > > > To subscribe to all notifications of the toaster module, the CoMI client > might send: > > > > REQ: GET /streams/default?filter=3DLgZ > > > > To subscribe to all notifications of both modules, the CoMI client might > send: > > > > REQ: GET /streams/default?filter=3DLgZ,S > > > > To subscribe to the toastDone notification of the toaster module plus the > replayComplete and the notificationComplete notifications of the > nc-notifications module, the CoMI client might send: > > > > REQ: GET /streams/default?filter=3DLgZ(Hqa6P),S(JtjGT,1uoPT) > > > > 4.5.4. Receiving Event Notifications > > > > As defined in section 4.4.3., CoMI clients subscribe to a notification > stream using a CoAP GET request. This request contains a Token which will > be used for all subsequent CoAP messages associated with this notificatio= n > stream. This CoAP response may contain one or multiple notifications, in > the case the status code is set to 2.05 (Content). The CoAP response may > also be empty, in the case the status code is set to 2.00 (Ok). > > > > Subsequent notifications are sent by the CoMI server to each subscribed > CoMI client in a non-confirmable CoAP message containing POST method. The > Token included shall be set to the Token initially received in the > subscription request. The status code of the POST message shall be set to > 2.05 (Content), each POST message may contain one or multiple notificatio= ns. > > > > The structure of each notification is based on the "notification" > container defined below. This container is associated with the module nam= e > "ietf-restconf". > > > > container notification { > > description "Notification message wrapper."; > > leaf event-time { > > type yang:date-and-time; > > mandatory true; > > description "The time the event was generated by the event > source."; > > reference "RFC 5277, section 4, element."; > > } > > } > > > > Notifications are implemented as a single pair CBOR map with the key part > set to the module ID and the value part containing CBOR map of the > notification content. > > > > For example: > > > > Assuming the module toaster is module ID 47129 > > Assuming the following YANG hash values: > > "/rc:notification/toast:toastDone" =3D 128560783 > > "/rc:notification/rc:event-time" =3D 1071794137 > > "/rc:notification/toast:toastDone" =3D 128560783 > > "/rc:notification/toast:toastDone/toast:toastStatus" =3D 30090935 > > > > The CoMI might sent the following CoAP request to subscribe to the > notification stream. > > > > REQ: GET /streams/default&start-time=3D2015-04-01T00:00:00Z (Token 0x7= A1D) > > > > The CoMI might receive the following CoAP response. > > > > RES: 2.05 Content (Token 0x7A1D) > > { > > 47129 : { # module toaster > > 1071794137 : "2015-04-01T12:16:51Z", # leaf event-time > > 128560783 : { # notification > toastDone > > 30090935 : 0 # leaf toastStatus > > } > > } > > } > > { > > 47129 : { # module toaster > > 1071794137 : "2015-04-01T12:19:06Z", # leaf event-time > > 128560783 : { # notification > toastDone > > 30090935 : 1 # leaf toastStatus > > } > > } > > } > > > > After some time, the CoMI might receive the following non-confirmable CoA= P > POST message. > > > > REQ: POST (Token 0x7A1D) > > { > > 47129 : { # module toaster > > 1071794137 : "2015-04-01T18:05:23Z", # leaf event-time > > 128560783 : { # notification > toastDone > > 30090935 : 0 # leaf toastStatus > > } > > } > > } > > > > > > [image: cid:image001.jpg@01C868D8.BF0BB7E0] > > Michel Veillette > System Architecture Director > > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > michel.veillette@trilliantinc.com > > www.trilliantinc.com > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > * Attachment: image001.jpg ________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please i= mmediately notify the sender and delete the e-mail and attached documents. = Please note that neither the sender nor the sender's company accept any res= ponsibility for viruses and it is your responsibility to scan or otherwise = check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0985F1ATDOAGMSX02itison_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi CoMI authors,

I have recently started looking = into CoMI and find it is very suitable for our application. However, I am l= ooking for support for YANG RPCs and see no mention of RPCs in the CoMI draft. I found a discussion in the mail archive in Core W= G and it seems that there was some support for this idea already but could = not find a final decision regarding this topic. Could you please explain if= a decision was made regarding the use of RPCs in CoMI.

Thanks,

Abhinav

 

Andy Bierman <andy@yumaworks.com> Show header

Hi,=

=
 

=
This is an interesting prop=
osal -- I support it.


=
There are details to work o=
ut of course.


=
 

=
There is no proposal for us=
ing observe + pub/sub to


=
implement CoMI notification=
s.


=
 

=
I think tradition event not=
ifications are needed because they tend


=
to use less resources. =
; They tend to be aggregations and are sometimes


=
time throttled, often defin=
ed with a default periodic interval.


=
 

=
 

=
On Mon, Apr 20, 2015 at 1:0=
3 PM, Michel Veillette <


=
Michel.Veillette@trillianti=
nc.com> wrote:


=
 

=
>  The current revi=
sion of CoMI (draft-vanderstok-core-comi-06) specify

=
> YANG as data modeling =
language but do not support two important features of

=
> this language, notific=
ation and protocol operations (RPCs). Support of


=
> these core features of=
 the YANG modeling language should be added to CoMI


=
> for the following reas=
ons:


=
> 


=
> 


=
> 


=
> ·  &n=
bsp;      CoMI should not be limited to YANG modul=
es specifically defined


=
> for it.


=
> YANG modules already d=
efined with notifications and protocol operations


=
> (RPCs) should be compa=
tible with CoMI.


=
> 


=
> ·  &n=
bsp;      Notifications and protocol operations (R=
PCs) are optional and


=
> don’t require ex=
tra resources when not needed.


=
> 


=
 

=
This would need to be optio=
nal to implement in the server.


=
In NETCONF/RESTCONF, they a=
re also all-or-nothing,


=
meaning if notification del=
ivery is supported, than all


=
YANG notification-stmts mus=
t be supported.  All rpc-stmts


=
must also be supported in e=
very server (no consensus


=
on this point for RESTCONF =
yet).


=
 

=
IMO, CoMI compliance might =
be different than the original YANG


=
module intended for NETCONF=
 or RESTCONF.  It might make


=
sense to let the server


=
 

=
 ·   =
      The notification mechanism is complimentary =
to the already


=
> supported observe mech=
anism, both mechanism can be supported simultaneously

=
> and address two differ=
ent use cases.


=
> 


=
> ·  &n=
bsp;      The notification mechanism:


=
> 


=
> o   Allow a =
client to subscribe to a notification stream using a single


=
> request (CoAP GET)


=
> 


=
> o   Allow a =
client to subscribe to a notification stream without the need


=
> to be aware of the spe=
cific data nodes implemented by this server


=
> 


=
> o   Allow a =
client to request a replay of past notifications (events<=
/pre>

=
> recorded in the absenc=
e of this client)


=
> 


=
 

=
This is optional to impleme=
nt on a NETCONF or RESTCONF server.


=
IMO not likely this would b=
e supported by a CoMI server.


=
 

=
 

=
 

=
 

=
Andy

=
 

=
 o   Allow transf=
er of multiple information associated to an event, some

=
> can be specific to thi=
s event and as such should not be part of the


=
> management data (/mg)<=
o:p>


=
> 


=
> ·  &n=
bsp;      RPCs is a controversy subject.


=
> For sure, RPCs shall n=
ot be used to replace simple GET or PUT actions,


=
> however there is valid=
 use cases for RPCs such as:


=
> 


=
> o   To imple=
ment complex actions (e.g. “toggle switch” can be implemented


=
> using a combination of=
 GET switch state, ETag and PUT but can be


=
> implemented more effic=
iently using RPC)


=
> 


=
> o   A RPC ca=
n have both input and output parameters which is not possible


=
> with a GET or a PUT.


=
> 


=
> o   RPCs may=
 carry information specific to this action and as such should


=
> not be part of the man=
agement data (/mg)


=
> 


=
 

=
> 


=
> The following sections=
 show possible text to be added to CoMI to support


=
> Notifications and RPCs=
.


=
> 


=
> 


=
>  ----------------=
--------------


=
> 


=
> 


=
> 


=
> 4.4.  Protocol op=
erations


=
> 


=
> 


=
> 


=
> The CoMI protocol supp=
orts protocol operations defined using the YANG


=
> "rpc" statem=
ent. The solution implemented is based on


=
> [I-D.ietf-netconf-rest=
conf] section 3.6.


=
> 


=
> 


=
> 


=
> 4.4.1.  Server Su=
pport


=
> 


=
> 


=
> 


=
> A COMI server is not r=
equired to support COMI protocol operations. Clients

=
> may determine if a ser=
ver supports protocol operations by sending a GET


=
> request to "/.wel=
l-known/core" including a resource type (RT) parameter


=
> with the value "c=
ore.rpc".


=
> 


=
> 


=
> 


=
> 4.4.2.  Operation=
 resource


=
> 


=
> 


=
> 


=
> The operation resource=
 is a container that provides access to the


=
> data-model specific pr=
otocol operations supported by the server. Protocol


=
> operations are invoked=
 by CoMI clients using a CoAP POST request on this


=
> resource.


=
> 


=
> 


=
> 


=
> 4.4.3.  Encoding =
Operation Input Parameters


=
> 


=
> 


=
> 


=
> If the "rpc"=
 statement has an "input" section, then the "input" nod=
e is


=
> provided in the messag=
e-body. The encoding of the "input" node follow CBOR


=
> mapping rules defined =
in section 5.


=
> 


=
> 


=
> 


=
> For example:


=
> 


=
> 


=
> 


=
> Assuming the following=
 YANG defined rpc.


=
> 


=
> 


=
> 


=
>    rpc =
reboot {


=
> 


=
>    =
;   input {


=
> 


=
>    =
;      leaf delay {


=
> 


=
>    =
;         units seconds;=



=
> 


=
>    =
;         type uint32;


=
> 


=
>    =
;         default 0;


=
> 


=
>    =
;      }


=
> 


=
>    =
;      leaf message { type string; }


=
> 


=
>    =
;      leaf language { type string; }


=
> 


=
>    =
;   }


=
> 


=
>    }


=
> 


=
> 


=
> 


=
> Assuming the module ex=
ample-ops is module ID 43 or "r" in base64

=
> 


=
> Assuming the following=
 YANG hash values:


=
> 


=
> "/example-ops:reb=
oot" =3D 283286310 or "Q4psm" in base64

=
> 


=
> "/example-ops:reb=
oot/example-ops:delay" =3D 980546150


=
> 


=
> "/example-ops:reb=
oot/example-ops:message" =3D 882566796


=
> 


=
> "/example-ops:reb=
oot/example-ops:language" =3D 284280286


=
> 


=
> 


=
> 


=
> The CoMI client might =
send the following POST request message:


=
> 


=
> 


=
> 


=
>    REQ:=
 POST example.com/RPC/r/Q4psm


=
> 


=
>    {


=
> 


=
>    =
;   980546150 : 600,


=
> 


=
>    =
;   882566796 : "Going down for system maintenance",


=
> 


=
>    =
;   284280286 : "en-US"


=
> 


=
>    }


=
> 


=
> 


=
> 


=
> The CoMI server might =
respond:


=
> 


=
> 


=
> 


=
>    RES:=
 2.00 Ok


=
> 


=
> 


=
> 


=
> 4.4.4.  Encoding =
Operation Output Parameters


=
> 


=
> 


=
> 


=
> If the "rpc"=
 statement has an "output" section, then the "output" n=
ode is


=
> provided in the messag=
e-body of the CoAP response. The encoding of the


=
> "output" nod=
e follow CBOR mapping rules defined in section 5.


=
> 


=
> 


=
> 


=
> 


=
> 


=
> For example:


=
> 


=
> 


=
> 


=
> Assuming the following=
 YANG defined rpc.


=
> 


=
> 


=
> 


=
>    rpc =
get-reboot-info {


=
> 


=
>    =
;   output {


=
> 


=
>    =
;      leaf reboot-time {


=
> 


=
>    =
;         units seconds;=



=
> 


=
>    =
;         type uint32;


=
> 


=
>    =
;      }


=
> 


=
>    =
;      leaf message { type string; }


=
> 


=
>    =
;      leaf language { type string; }


=
> 


=
>    =
;   }


=
> 


=
>    }


=
> 


=
> 


=
> 


=
> Assuming the module ex=
ample-ops is module ID 43 or "r" in base64

=
> 


=
> Assuming the following=
 YANG hash values:


=
> 


=
> "/example-ops:get=
-reboot-info" =3D 683557230 or "ovkFu"

=
> 


=
> "/example-ops:get=
-reboot-info/example-ops:reboot-time " =3D 342555434=



=
> 


=
> "/example-ops:get=
-reboot-info/example-ops:message" =3D 762496844

=
> 


=
> "/example-ops:get=
-reboot-info/example-ops:language" =3D 353194165

=
> 


=
> 


=
> 


=
> The client might send =
the following POST request message:


=
> 


=
> 


=
> 


=
>    REQ:=
 POST example.com/RPC/r/ovkFu


=
> 


=
> 


=
> 


=
> The server might respo=
nd:


=
> 


=
> 


=
> 


=
>    RES:=
 2.05 Content (Content-Format: application/cbor)


=
> 


=
>    {


=
> 


=
>    =
;   342555434 : 30,


=
> 


=
>    =
;   762496844 : "Going down for system maintenance",


=
> 


=
>    =
;   353194165 : "en-US"


=
> 


=
>    }


=
> 


=
> 


=
>  ----------------=
--------------


=
> 


=
> 


=
> 


=
> 4.5.  Notificatio=
ns


=
> 


=
> 


=
> 


=
> The CoMI protocol supp=
orts YANG-defined event notifications. The solution


=
> implemented is based o=
n [I-D.ietf-netconf-restconf] section 6.


=
> 


=
> 


=
> 


=
> 4.5.1.  Server Su=
pport


=
> 


=
> 


=
> 


=
> A COMI server is not r=
equired to support COMI notifications. Clients may


=
> determine if a server =
supports notifications by sending a GET request to


=
> "/.well-known/cor=
e" including a resource type (RT) parameter with the value<=
/span>


=
> "core.streams&quo=
t;.


=
> 


=
> 


=
> 


=
> 4.5.2.  Event Str=
eams


=
> 


=
> 


=
> 


=
> A CoMI server that sup=
ports notifications MUST populate a stream resource


=
> for each notification =
delivery service access point. A CoMI client can


=
> retrieve the list of s=
upported event streams from a CoMI server using the


=
> GET operation on the s=
tream list.


=
> 


=
> 


=
> 


=
> The "restconf-sta=
te/streams" container definition in the


=
> "ietf-restconf-mo=
nitoring" module (defined in [I-D.ietf-netconf-restconf]


=
> section 9.3) is used t=
o specify the structure and syntax of the child


=
> resources within the &=
quot;streams" resource.


=
> 


=
> 


=
> 


=
> For example:


=
> 


=
> 


=
> 


=
> Assuming the module ie=
tf-restconf-monitoring is module ID 2 or "C" in=



=
> base64


=
> 


=
> Assuming the following=
 YANG hash values:


=
> 


=
> "/rcmon:restconf-=
state/rcmon:streams" =3D 869048475 or "zzKCb" in base64=



=
> 


=
> "/rcmon:restconf-=
state/rcmon:streams/rcmon:Stream" =3D 305096898

=
> 


=
> "/rcmon:restconf-=
state/rcmon:streams/rcmon:Stream/rcmon:name" =3D 931463846<=
/span>


=
> 


=
> "/rcmon:restconf-=
state/rcmon:streams/rcmon:Stream/rcmon:description" =3D


=
> 425672327


=
> 


=
> "/rcmon:restconf-=
state/rcmon:streams/rcmon:Stream/rcmon:replay-support" =3D<=
/span>


=
> 301154294


=
> 


=
> "/rcmon:restconf-=
state/rcmon:streams/rcmon:Stream/rcmon:replay-log-creation-time"<=
/o:p>


=
> =3D 126010158


=
> 


=
> "/rcmon:restconf-=
state/rcmon:streams/rcmon:Stream/rcmon:encoding" =3D=



=
> 374857305


=
> 


=
> "/rcmon:restconf-=
state/rcmon:streams/rcmon:Stream/rcmon:encoding/rcmon:type"=



=
> =3D 836936555


=
> 


=
> "/rcmon:restconf-=
state/rcmon:streams/rcmon:Stream/rcmon:encoding/rcmon:events"


=
> =3D 201862865


=
> 


=
> 


=
> 


=
> The client might send =
the following request:


=
> 


=
> 


=
> 


=
>    REQ:=
 GET example.com/mg/C/zzKCb


=
> 


=
> 


=
> 


=
> The server might send =
the following response:


=
> 


=
> 


=
> 


=
>    RES:=
 2.05 Content (Content-Type: application/cbor)


=
> 


=
>    {


=
> 


=
>    =
;  869048475 : {


=
> 


=
>    =
;    305096898 : {


=
> 


=
>    =
;      931463846 : "default",=



=
> 


=
>    =
;      425672327 : "Default event stream"=
;,


=
> 


=
>    =
;      301154294 : true,


=
> 


=
>    =
;      126010158 : "2015-04-15T15:58:00Z"=
;,


=
> 


=
>    =
;      374857305 : {


=
> 


=
>    =
;        836936555 : "cbor",


=
> 


=
>    =
;        201862865 : "coaps://examp=
le.com/streams/default"


=
> 


=
>    =
;      }


=
> 


=
>    =
;    },


=
> 


=
>    =
;    305096898 : {


=
> 


=
>    =
;      931463846 : "syslog-critical",


=
> 


=
>    =
;      425672327 : "Critical and higher sever=
ity",


=
> 


=
>    =
;      301154294 : true,


=
> 


=
>    =
;      126010158  : "2015-04-14T00:00:00=
Z",


=
> 


=
>    =
;      374857305 : {


=
> 


=
>    =
;        836936555 : "cbor",


=
> 


=
>    =
;        201862865 : "coaps://examp=
le.com/streams/syslog-critical"


=
> 


=
>    =
;      }


=
> 


=
>    =
;    }


=
> 


=
>    =
;  }


=
> 


=
>    }


=
> 


=
> 


=
> 


=
> 4.5.3.  Subscribi=
ng to Receive Notifications


=
> 


=
> 


=
> 


=
> CoMI clients can deter=
mine the URI for the subscription resource (to


=
> receive notifications)=
 by sending a GET request for the "events" leaf=



=
> within the stream list=
 entry.  The value returned by the server can be used


=
> for the actual notific=
ation subscription.


=
> 


=
> 


=
> 


=
> The client will then s=
end a GET request for the URI returned by the server

=
> with the "Accept&=
quot; type "application/cbor".


=
> 


=
> 


=
> 


=
> 4.5.3.1.  Query p=
arameters


=
> 


=
> 


=
> 


=
> Query parameters are o=
ptional to implement, and only available if the


=
> server supports them.<=
o:p>


=
> 


=
>    =
;         +------------+---=
------+-------------------------+


=
> 


=
>    =
;         | Name   &=
nbsp;   | Section | Description     &nbs=
p;       |


=
> 


=
>    =
;         +------------+---=
------+-------------------------+


=
> 


=
>    =
;         | start-time | 4.8.9 =
;  | replay event start time |


=
> 


=
>    =
;         | stop-time  | 4.8.1=
0  | replay event stop time  |


=
> 


=
>    =
;         | filter   =
;  | 4.8.8   | content filter     &=
nbsp;    |


=
> 


=
>    =
;         +------------+---=
------+-------------------------+


=
> 


=
> 


=
> 


=
>    =
;            &n=
bsp;      CoMI Streams Query Parameters=



=
> 


=
> 


=
> 


=
> 4.5.3.2.  The &qu=
ot;start-time" Query Parameter


=
> 


=
> 


=
> 


=
> The "start-time&q=
uot; parameter is used to trigger the notification replay=



=
> feature and indicate t=
hat the replay should start at the time specified.


=
> If the stream does not=
 support replay, per the "replay-support" attribute


=
> returned by the stream=
 list entry for the stream resource, then the server

=
> MUST return the error =
code 4.00 Bad Request.


=
> 


=
> 


=
> 


=
> This parameter is only=
 allowed for GET methods on a /streams data


=
> resource.  A 4.00=
 Bad Request error is returned if used for other methods<=
/pre>

=
> or resource types.


=
> 


=
> 


=
> 


=
> If this parameter is n=
ot present, then a replay subscription is not being


=
> requested. It is not v=
alid to specify start times that are later than the


=
> current time. If the v=
alue specified is earlier than the log can support,


=
> the replay will begin =
with the earliest available notification.


=
> 


=
> 


=
> 


=
> If the "replay-su=
pport" leaf is present in the "stream" entry, then the<=
/o:p>


=
> server MUST support th=
e "start-time" and "stop-time" query parameters for


=
> that stream.


=
> 


=
> 


=
> 


=
> 4.5.3.3.  The &qu=
ot;stop-time" Query Parameter


=
> 


=
> 


=
> 


=
> The "stop-time&qu=
ot; parameter is used with the replay feature to indicate the


=
> newest notifications o=
f interest. This parameter MUST be used with and have

=
> a value later than the=
 "start-time" parameter.


=
> 


=
> 


=
> 


=
> This parameter is only=
 allowed for GET methods on a /streams data


=
> resource.  A 4.00=
 Bad Request error is returned if used for other methods<=
/pre>

=
> or resource types.


=
> 


=
> 


=
> 


=
> If this parameter is n=
ot present, the notifications will continue until


=
> the subscription is te=
rminated. Values in the future are also valid. In


=
> this case the subscrip=
tion will automatically terminate at the specified


=
> "stop-time".=



=
> 


=
> 


=
> 


=
> If the "replay-su=
pport" leaf is present in the "stream" entry, then the<=
/o:p>


=
> server MUST support th=
e "start-time" and "stop-time" query parameters for


=
> that stream.


=
> 


=
> 


=
> 


=
> 4.5.3.4.  The &qu=
ot;filter" Query Parameter


=
> 


=
> 


=
> 


=
> The "filter"=
 parameter is used to indicate which subset of all possible


=
> events are of interest=
. If not present, all notifications not precluded by

=
> other parameters will =
be sent.


=
> 


=
> 


=
> 


=
> This parameter is only=
 allowed for GET methods on a /streams data


=
> resource.  A 4.00=
 Bad Request error is returned if used for other methods<=
/pre>

=
> or resource types.


=
> 


=
> 


=
> 


=
> The format of this par=
ameter is a comma separated list of module IDs


=
> formatted in base 64. =
To filter a subset of the notifications defined in a

=
> module, the module ID =
is followed by a comma separated list of the YANG


=
> hash values associated=
 to each notification of interest. Each notification

=
> list is delimited by p=
arentheses and hash values are formatted in base 64.

=
> 


=
> 


=
> 


=
> For example:


=
> 


=
> 


=
> 


=
> Assuming the module to=
aster is module ID 47129 or "LgZ" in base64

=
> 


=
> Assuming the module nc=
-notifications is module ID 18 or "S" in base64=



=
> 


=
> Assuming the following=
 YANG hash values:


=
> 


=
> "/rc:notification=
/toast:toastDone" =3D 128560783 or "Hqa6P" in base64


=
> 


=
> "/rc:notification=
/manageEvent:replayComplete" =3D 162935187 or "JtjGT"


=
> 


=
> "/rc:notification=
/manageEvent:notificationComplete" =3D 901415891 or "1uoPT"<=
o:p>


=
> 


=
> 


=
> 


=
> To subscribe to all no=
tifications of the toaster module, the CoMI client


=
> might send:=



=
> 


=
> 


=
> 


=
>    REQ:=
 GET /streams/default?filter=3DLgZ


=
> 


=
> 


=
> 


=
> To subscribe to all no=
tifications of both modules, the CoMI client might


=
> send:


=
> 


=
> 


=
> 


=
>    REQ:=
 GET /streams/default?filter=3DLgZ,S


=
> 


=
> 


=
> 


=
> To subscribe to the to=
astDone notification of the toaster module plus the


=
> replayComplete and the=
 notificationComplete notifications of the


=
> nc-notifications modul=
e, the CoMI client might send:


=
> 


=
> 


=
> 


=
>    REQ:=
 GET /streams/default?filter=3DLgZ(Hqa6P),S(JtjGT,1uoPT)<=
/pre>

=
> 


=
> 


=
> 


=
> 4.5.4.  Receiving=
 Event Notifications


=
> 


=
> 


=
> 


=
> As defined in section =
4.4.3., CoMI clients subscribe to a notification


=
> stream using a CoAP GE=
T request. This request contains a Token which will


=
> be used for all subseq=
uent CoAP messages associated with this notification

=
> stream. This CoAP resp=
onse may contain one or multiple notifications, in


=
> the case the status co=
de is set to 2.05 (Content). The CoAP response may


=
> also be empty, in the =
case the status code is set to 2.00 (Ok).


=
> 


=
> 


=
> 


=
> Subsequent notificatio=
ns are sent by the CoMI server to each subscribed


=
> CoMI client in a non-c=
onfirmable CoAP message containing POST method. The


=
> Token included shall b=
e set to the Token initially received in the


=
> subscription request. =
The status code of the POST message shall be set to


=
> 2.05 (Content), each P=
OST message may contain one or multiple notifications.

=
> 


=
> 


=
> 


=
> The structure of each =
notification is based on the "notification"

=
> container defined belo=
w. This container is associated with the module name

=
> "ietf-restconf&qu=
ot;.


=
> 


=
> 


=
> 


=
>    cont=
ainer notification {


=
> 


=
>    =
;   description "Notification message wrapper.";


=
> 


=
>    =
;   leaf event-time {


=
> 


=
>    =
;      type yang:date-and-time;<=
/pre>

=
> 


=
>    =
;      mandatory true;


=
> 


=
>    =
;      description "The time the event was ge=
nerated by the event


=
> source.";


=
> 


=
>    =
;      reference "RFC 5277, section 4, <ev=
entTime> element.";


=
> 


=
>    =
;   }


=
> 


=
>    }


=
> 


=
> 


=
> 


=
> Notifications are impl=
emented as a single pair CBOR map with the key part


=
> set to the module ID a=
nd the value part containing CBOR map of the


=
> notification content.<=
o:p>


=
> 


=
> 


=
> 


=
> For example:


=
> 


=
> 


=
> 


=
> Assuming the module to=
aster is module ID 47129


=
> 


=
> Assuming the following=
 YANG hash values:


=
> 


=
> "/rc:notification=
/toast:toastDone" =3D 128560783


=
> 


=
> "/rc:notification=
/rc:event-time" =3D 1071794137


=
> 


=
> "/rc:notification=
/toast:toastDone" =3D 128560783


=
> 


=
> "/rc:notification=
/toast:toastDone/toast:toastStatus" =3D 30090935

=
> 


=
> 


=
> 


=
> The CoMI might sent th=
e following CoAP request to subscribe to the


=
> notification stream.


=
> 


=
> 


=
> 


=
>    REQ:=
 GET /streams/default&start-time=3D2015-04-01T00:00:00Z (Token 0x7A1D)<=
o:p>


=
> 


=
> 


=
> 


=
> The CoMI might receive=
 the following CoAP response.


=
> 


=
> 


=
> 


=
>    RES:=
 2.05 Content (Token 0x7A1D)


=
> 


=
>    {


=
> 


=
>    =
;  47129 : {         &nbs=
p;            &=
nbsp;           &nbs=
p;    # module toaster


=
> 


=
>    =
;    1071794137 : "2015-04-01T12:16:51Z", &nb=
sp;        # leaf event-time<=
/span>


=
> 


=
>    =
;    128560783 : {       =
            &nb=
sp;            =
 # notification


=
> toastDone


=
> 


=
>    =
;      30090935 : 0     &=
nbsp;           &nbs=
p;            &=
nbsp; # leaf toastStatus


=
> 


=
>    =
;    }


=
> 


=
>    =
;  }


=
> 


=
>    }


=
> 


=
>    {


=
> 


=
>    =
;  47129 : {         &nbs=
p;            &=
nbsp;           &nbs=
p;    # module toaster


=
> 


=
>    =
;    1071794137 : "2015-04-01T12:19:06Z", &nb=
sp;        # leaf event-time<=
/span>


=
> 


=
>    =
;    128560783 : {       =
            &nb=
sp;            =
 # notification


=
> toastDone


=
> 


=
>    =
;      30090935 : 1     &=
nbsp;           &nbs=
p;            &=
nbsp; # leaf toastStatus


=
> 


=
>    =
;    }


=
> 


=
>    =
;  }


=
> 


=
>    }


=
> 


=
> 


=
> 


=
> After some time, the C=
oMI might receive the following non-confirmable CoAP

=
> POST message.


=
> 


=
> 


=
> 


=
>    REQ:=
 POST (Token 0x7A1D)


=
> 


=
>    {


=
> 


=
>    =
;  47129 : {          &nb=
sp;            =
            &nb=
sp;   # module toaster


=
> 


=
>    =
;    1071794137 : "2015-04-01T18:05:23Z", &nb=
sp;        # leaf event-time<=
/span>


=
> 


=
>    =
;    128560783 : {       =
            &nb=
sp;            =
 # notification


=
> toastDone


=
> 


=
>    =
;      30090935 : 0     &=
nbsp;           &nbs=
p;             =
 # leaf toastStatus


=
> 


=
>    =
;    }


=
> 


=
>    =
;  }


=
> 


=
>    }


=
> 


=
> 


=
> 


=
> 


=
> 


=
> [image: cid:image001.j=
pg@01C868D8.BF0BB7E0]


=
> 


=
> Michel Veillette<=
/o:p>


=
> System Architecture Di=
rector


=
> 


=
> Trilliant Inc.


=
> Tel: 450-375-0556 ext.=
 237


=
> michel.veillette@trill=
iantinc.com


=
> 


=
> www.trilliantinc.com


=
> 


=
> 


=
> 


=
> 


=
> 


=
> ______________________=
_________________________


=
> core mailing list=



=
> core@ietf.org


=
> https://www.ietf.org/m=
ailman/listinfo/core


=
> 


=
> 



·       &nb=
sp;
Attachment: <=
/span>image001.jpg


 
________________________________________________________ The contents of th= is e-mail and any attachments are confidential to the intended recipient. T= hey may not be disclosed to or used by or copied in any way by anyone other= than the intended recipient. If this e-mail is received in error, please immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0985F1ATDOAGMSX02itison_-- From nobody Tue Sep 15 07:55: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 07E171B41A4 for ; Tue, 15 Sep 2015 07:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 9YlnoyBdZ4E6 for ; Tue, 15 Sep 2015 07:55:11 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::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 A413A1A8BB2 for ; Tue, 15 Sep 2015 07:55:11 -0700 (PDT) Received: by obqa2 with SMTP id a2so137266675obq.3 for ; Tue, 15 Sep 2015 07:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=6BYzFESUt5CK+ii5x4W8hBq/IdFL3VPqGLA4FU6ebYA=; b=Xm2o5vynYbwd3+Vl2IqRaj43XwiHsLezEZd0Q6W3rETEol6nfgE5tIEfFq5MmUDxrO WbUSLlvHiHUef5wzVbYqQadsFfyNh4x3uvBlIA5SfVr0Hf8m8H7KOvVxdwLS4TRMQVjq VwQbI0ri7E0k5cwEdSWM0bXjUV7teDkJ7F7cuY9TyWRu+mI5prO2BIInm/B0Ob9Jy/aZ MI8hWXbmvLqKIpQwV2xMEevdlFQ4zjwsKMIpdey+AXNwi0o0nKbuoA66ukt+O6441z2a NrrgkOfo5axgq8Qyv/Z3tszMYH+eLyi60LcI1amyIIYfg0qFHImpm8Nbj7SkYGD5e+vf BG/w== X-Received: by 10.60.130.136 with SMTP id oe8mr18096347oeb.10.1442328911081; Tue, 15 Sep 2015 07:55:11 -0700 (PDT) MIME-Version: 1.0 References: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> <55CBACAD.9090401@gmx.net> <557A6C8AF976114EBAD8852183CF3F371D7A5A0A@SMTP1.etri.info> <55DC64AE.1030105@gmx.net> <55E79477.2060105@tzi.org> <55EDF044.5020304@tzi.org> In-Reply-To: From: Simon Lemay Date: Tue, 15 Sep 2015 14:55:01 +0000 Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e0122a75c64f9a6051fca5e7e Archived-At: Cc: core@ietf.org 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: Tue, 15 Sep 2015 14:55:13 -0000 --089e0122a75c64f9a6051fca5e7e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Any News on The interim meeting?, is it Something I can do or does Chairmans have to do it? Thanks Simon On Tue, Sep 8, 2015 at 1:34 PM Simon Lemay wrote: > Yes i think we should start a Doodle for the interim meeting. > > Thanks > > Simon > > On Mon, Sep 7, 2015 at 1:15 PM Carsten Bormann wrote: > >> Simon Lemay wrote: >> > Chairmans, how can we get the ball rolling on this? >> >> Hmm. Do people even care about the issue? Should Andrew toss a coin? >> >> We should schedule a virtual interim if we can get a bit more than three >> people to join. Maybe we should start with another doodle? >> >> Gr=C3=BC=C3=9Fe, Carsten >> > --089e0122a75c64f9a6051fca5e7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Any News on The interim meeting?, =C2=A0is = it Something I can do or does Chairmans have to do it?

T= hanks

Simon


On Tue, Sep 8, 2015 at 1:34 PM Simon Le= may <simon.lemay@gmail.com&= gt; wrote:
Yes i t= hink we should start a Doodle for the interim meeting.

T= hanks

Simon

=
On Mon, Sep 7, 2015 at 1:15 PM = Carsten Bormann <cabo@= tzi.org> wrote:
Simon Lemay = wrote:
> Chairmans, how can we get the ball rolling on this?

Hmm.=C2=A0 Do people even care about the issue?=C2=A0 Should Andrew toss a = coin?

We should schedule a virtual interim if we can get a bit more than three people to join.=C2=A0 Maybe we should start with another doodle?

Gr=C3=BC=C3=9Fe, Carsten
--089e0122a75c64f9a6051fca5e7e-- From nobody Tue Sep 15 08:00:28 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 083BF1A894B for ; Tue, 15 Sep 2015 08:00:27 -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 e2jThbMqOajp for ; Tue, 15 Sep 2015 08:00: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 0EE101B36D5 for ; Tue, 15 Sep 2015 08:00:24 -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 t8FF030w007159; Tue, 15 Sep 2015 17:00:03 +0200 (CEST) Received: from alma.local (p5DCCDB06.dip0.t-ipconnect.de [93.204.219.6]) (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 3nFnm33J3Mz20hN; Tue, 15 Sep 2015 17:00:03 +0200 (CEST) Message-ID: <55F83271.7000601@tzi.org> Date: Tue, 15 Sep 2015 17:00:01 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: Simon Lemay References: <2EFBC0B2-CA53-4495-B2EE-763E171EC305@gmail.com> <55CBACAD.9090401@gmx.net> <557A6C8AF976114EBAD8852183CF3F371D7A5A0A@SMTP1.etri.info> <55DC64AE.1030105@gmx.net> <55E79477.2060105@tzi.org> <55EDF044.5020304@tzi.org> 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] 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: Tue, 15 Sep 2015 15:00:27 -0000 Setting up a Doodle for Week 41 is something you could be doing. (We need to get more people involved, and then put in the schedule > two weeks before the event, hence Week 41.) Gr眉脽e, Carsten Simon Lemay wrote: > > Any News on The interim meeting?, is it Something I can do or does > Chairmans have to do it? > > Thanks > > Simon > > > On Tue, Sep 8, 2015 at 1:34 PM Simon Lemay > wrote: > > Yes i think we should start a Doodle for the interim meeting. > > Thanks > > Simon > > On Mon, Sep 7, 2015 at 1:15 PM Carsten Bormann > wrote: > > Simon Lemay wrote: > > Chairmans, how can we get the ball rolling on this? > > Hmm. Do people even care about the issue? Should Andrew toss a > coin? > > We should schedule a virtual interim if we can get a bit more > than three > people to join. Maybe we should start with another doodle? > > Gr眉脽e, Carsten > From nobody Tue Sep 15 08:07:30 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 7FB651B340E for ; Tue, 15 Sep 2015 08:07: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 KiVe-rA74r0q for ; Tue, 15 Sep 2015 08:07:25 -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 54DE81B4FF0 for ; Tue, 15 Sep 2015 08:07: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 [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t8FF7LJl022414; Tue, 15 Sep 2015 17:07:21 +0200 (CEST) Received: from alma.local (p5DCCDB06.dip0.t-ipconnect.de [93.204.219.6]) (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 3nFnwT1PrZz21bL; Tue, 15 Sep 2015 17:07:21 +0200 (CEST) Message-ID: <55F83427.2040203@tzi.org> Date: Tue, 15 Sep 2015 17:07:19 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: Somaraju Abhinav References: <0E9A48AB39AF3547ACD28A6DE3E2906A0985F1@ATDOAGMSX02.itiso.net> In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A0985F1@ATDOAGMSX02.itiso.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] CoMI support for YANG notification and RPC 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, 15 Sep 2015 15:07:29 -0000 Somaraju Abhinav wrote: > > However, I am looking for support for YANG RPCs and see no mention of > RPCs in the CoMI draft. Hi Abhinav, I think they just haven't been in the focus so far, maybe just for a lack of imagination for what these RPCs would be used for. Can you tell us a bit more about the way you plan to use YANG RPCs on constrained devices? Gr眉脽e, Carsten From nobody Tue Sep 15 08:21: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 9C0311A00BC for ; Tue, 15 Sep 2015 08:21:07 -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 n6RbrRN9GpMs for ; Tue, 15 Sep 2015 08:21:02 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680021A00C1 for ; Tue, 15 Sep 2015 08:21:00 -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 t8FFKqgR027181 for ; Tue, 15 Sep 2015 17:20:52 +0200 (CEST) Received: from alma.local (p5DCCDB06.dip0.t-ipconnect.de [93.204.219.6]) (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 3nFpD41fmtz20cB; Tue, 15 Sep 2015 17:20:52 +0200 (CEST) Message-ID: <55F83752.3090609@tzi.org> Date: Tue, 15 Sep 2015 17:20:50 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: "core@ietf.org WG" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07 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, 15 Sep 2015 15:21:07 -0000 In Prague, we said we were going to WGLC the HTTP mapping draft after close of the vacation period, which is now behind us. All outstanding tickets are closed, and there was enough time to review the current draft. Three people raised their hands when we asked who would submit reviews (Michael K., Klaus, Darshak), but of course additional reviews beyond that are also very useful. So this starts a working group last call for draft-ietf-core-http-mapping for submission as an informational RFC, ending on 24:00 PDT on Tuesday, September 29, 2015. The draft is located at: https://tools.ietf.org/html/draft-ietf-core-http-mapping-07 Please start a new email thread for each major issue that will need discussion and make sure the subject line includes the draft name and some sort of name for the issue. For minor issues such as typos and things that are not likely to lead to much discussion, it is probably easier to group them all in to one email but again, please make sure the subject line includes the draft name. If you read the draft and think it looks fine, please send a one line email to the list or to the chairs letting us know that so we can get a feel of how broad the review has been. In the unlikely event that you are aware of any patent claims that might apply to systems that implement the suggestions in this draft, please review BCP 78 and BCP 79 and make any appropriate IPR declaration. If you are not sure whether you need to make a declaration or not, please talk to the chairs and we will help get you in touch with people that can provide appropriate advice. Gr眉脽e, Carsten From nobody Tue Sep 15 08:58: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 14C221A1B12 for ; Tue, 15 Sep 2015 08:58:48 -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, 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 u3vskG-XEdGa for ; Tue, 15 Sep 2015 08:58:46 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3991A1B11 for ; Tue, 15 Sep 2015 08:58:45 -0700 (PDT) Received: from VI1PR06CA0029.eurprd06.prod.outlook.com (10.162.116.167) by AMSPR06MB152.eurprd06.prod.outlook.com (10.242.91.27) with Microsoft SMTP Server (TLS) id 15.1.268.17; Tue, 15 Sep 2015 15:58:28 +0000 Received: from AM1FFO11FD010.protection.gbl (2a01:111:f400:7e00::189) by VI1PR06CA0029.outlook.office365.com (2a01:111:e400:587c::39) with Microsoft SMTP Server (TLS) id 15.1.268.17 via Frontend Transport; Tue, 15 Sep 2015 15:58:28 +0000 Authentication-Results: spf=fail (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=tridonic.com; Received-SPF: Fail (protection.outlook.com: domain of tridonic.com does not designate 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATDOAGMSX01.itiso.net; Received: from ATDOAGMSX01.itiso.net (146.108.200.10) by AM1FFO11FD010.mail.protection.outlook.com (10.174.65.99) with Microsoft SMTP Server (TLS) id 15.1.262.18 via Frontend Transport; Tue, 15 Sep 2015 15:58:27 +0000 Received: from ATDOAGMSX02.itiso.net ([169.254.4.182]) by ATDOAGMSX01.itiso.net ([169.254.3.31]) with mapi id 14.03.0224.002; Tue, 15 Sep 2015 17:58:27 +0200 From: Somaraju Abhinav To: Carsten Bormann Thread-Topic: [core] CoMI support for YANG notification and RPC Thread-Index: AQHQ78g9BRZAVS4CG0OsaHDQD8e7Ep49uzlQ Date: Tue, 15 Sep 2015 15:58:25 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A09873D@ATDOAGMSX02.itiso.net> References: <0E9A48AB39AF3547ACD28A6DE3E2906A0985F1@ATDOAGMSX02.itiso.net> <55F83427.2040203@tzi.org> In-Reply-To: <55F83427.2040203@tzi.org> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.41.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD010; 1:ooFryct76nQVkkca6PV+gjk1lb0qhRpqDD+B6HcVoLeHY+XHmkp49hbc7YGNdQ1ErKYeHUEQM+XFQRsssF1049+3CyUT0iwTkCj5fV1r7kgmE2RdQIyteRwPSqUgRJ9JU6vIIJOTqJoUif42VBKDEgBVO9/7owQ8WJBAdbAoj+6e22AfQyaRA/KgdB8W9mkyOo6a28FWW/ukxTapYjYwabomHgQKA+J6tblqoIMnvIafYVXEEvgv9qbQF3Hu/7Cf44w78e2Wn29r311y6XQyZBmVb5+et1DLQoZgDqtTtTRpM3ViClPDvRHgBqfQFmamJhxYt+Vl0lpmZqCeJc8nXQ== X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(1110001)(1109001)(339900001)(13464003)(189002)(199003)(24454002)(76176999)(554214002)(87936001)(54356999)(106466001)(104016003)(53416004)(105606002)(23676002)(106116001)(55846006)(69596002)(50986999)(64706001)(66066001)(26826002)(33656002)(5003600100002)(85426001)(19580405001)(2900100001)(5890100001)(5001920100001)(2920100001)(5001960100002)(5004730100002)(6806004)(5001860100001)(189998001)(86362001)(110136002)(50466002)(2950100001)(19580395003)(102836002)(4001540100001)(11100500001)(92566002)(5001830100001)(62966003)(46102003)(81156007)(77156002)(47776003)(5007970100001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR06MB152; H:ATDOAGMSX01.itiso.net; FPR:; SPF:Fail; PTR:unknown.zgrp.net; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB152; 2:M5Av21LFQQE6SbzD4hIQwbYdP21gUVWzN5TMH2+9TTMRzJm9X3PQzO3cEBAhTdOVdEAj/cAeRhkYVP2+M8rFS2sMx76BHhRxtL2rydDzlX09q81mIWRi0fxIJseJ+yithn+xmJ/TDC3GX7WkpEinioegicR3ahtuDptHPkvykqw=; 3:R4owfw4tLepdUzoCNSHWCBhH//mWaDP4hxMn2XXh+AB2KMlGhS9Mn88MBs9G/aGx9Qcp6d+iONScBfuLumTk/HZDPgAMMGBToTW6uemc7D1WgnjOeDi5fGxE5zrhT4ic4cgPoJQcYA7yJC0NN53HHxC/7lMW7b/aGytKR077KOrO3Grv7E7KfiTGu6U5SL7PFWhlIsPscFW4JaOGg3YSdnbSgWnQUe/ur1txycSwXRYfUBp8k5kg1hWB/FIdBcWY; 25:c6azM+Q6xPFE12anC8rsWAfE2sZWL57qZmjn6aHAyBd1k/b1l/5RYGONen4R5F16OF08oW7gz3btDQX9Vgi9MB8KRtakWn5WEXj165QGKWUDI0M7MHh0J8Weo7N/MEzHrY6cbw1KO9pWy2z2WMCuF8XRsHosTGL7pQje5gkXuAbBZBHpNZaxlRrMnVY8TN+T15v2aXuOI5PqLMFrG5neFBaJZtWEsiVWIpuGKpXWh4R2TWFdceubMe/+Fw7IPfqhe13fuj9CDXtmP3HbwXQWPg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR06MB152; X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB152; 20:1J3WCdmS+K6LqKxIgKAWXdvKcZdaUQFzJMEs7YhzQJN7FLyoLTWqZcbyHndobfgrtpUv7FunUb2HKFDERsTYmsJ+Bo8wYysvpgqgx4XPebkHXnji2RvLj7pnit70hhYguuAZTaXv4E4Hkg/hITgNkFQ1xZarRJATm52vHAS/Dav5Okjl87pkklDGZ/tBYE2VlEIjrtFxxKqytLcSP3CEHVDKQeh7nkSwLw4t5m09pWkGM4vUBO0HL6OqVDvPnX8MDJVUxVAccN0ZYPW4VNcnoiGVHKOz34cI42bOIhNDO/i5tDustc1YqnX2WXzQkzUDLZJIMGSbob5+OWEPWZiOBm8UUSVCBg68HHM8nEPvioOfpyspP5MQ2gv8Ikv33egE7Tvmm6o+eqB7dsKZL53bxvub+OxB3GU49MIZmJawHvYPXI0taPu3ajip0zFiBS0/bpm6Srrqe4GREHhHj6Rd+VdW8CKHyqWI/0Q8LM3UVR4F/8zSAhOyLeu2Jomn6PSa; 4:R/qthDoWztMMND7ErKObp1KKCqLFXGnnDAJ9DXrRq+qoxnTbCz1G9Wb/7vC2JTwrd4sAj97+ZkQGrvz9TtUEexN0crSzyLT7jF+cmJaVAgyTw07DjnL7E01JifFlBK4WQ1bAXwEA492/OSkd1iYC52N4GK0fkHjto5/AYNUeZQGY0q++JYlNPqXEj5OiLFqzgh6S9QrtqUPMhBRd0kDxpaAMRzfe5t19MnDsIbFMLh43N6XkxzNjs3GokrGcNv36onT8pyOVkruOyfHQoi1+Ib1zpj5PZc1B4zDfoSb/X11t2w6Wl6kJxL6ukEimzrOGpfBKjxESyNxxEe2U/4452CnYIkMOjj42BUM0aZo/qbg= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520075)(5005006)(8121501046)(520078)(3002001); SRVR:AMSPR06MB152; BCL:0; PCL:0; RULEID:; SRVR:AMSPR06MB152; X-Forefront-PRVS: 070092A9D3 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVNQUjA2TUIxNTI7MjM6Qm41MGhsakdidWlTTytOODlESEQzVFdubW5I?= =?utf-8?B?WE1mR01yU3JkaVlPZkJFTUMxUmJVYXVLeXVvTzN2TFNJUTlHM2xncll0d3Fl?= =?utf-8?B?dmlackJjMis3MjA5cG1FVVBpMWFudFlHK2hyNm1PWTdwSzc0K0hZMC82T0hD?= =?utf-8?B?b3RTVUhEL2JRbXUwTnpudU5Fd0xubjhxUHZNQkFmK0dsTE13cGJuN3U5RHFz?= =?utf-8?B?UTQ1dXhWNUdNNmF3SktjblJ6MGJMejFXSkhNT0U5YjYzbTVEaWI2Q0lxRGkv?= =?utf-8?B?MnJ1dFhUVGdTZUtHaGVrdkpOR2wxOWhlM0xUZnU0d3pRNllyVFBqVDVjNWR3?= =?utf-8?B?dXRLVWw5ZkwyT0lhZ0FpSk04cDgyK2FCTTZseThVTFRoMG0zNGNLRGZRNlhz?= =?utf-8?B?NkczVTBwejBFS1RCaDhXN2VBNnBVeXZUMUFjSTMwYmw0b0M2c1kwOUx5Y1Zy?= =?utf-8?B?czcrcHFwbWZwWmt3TnRIVmZJbWtuckphVUZkem8wRFRnS1J0bmlBM1ZqUUp5?= =?utf-8?B?a3VEcU45RnhUVkdGdXZZT1R0UTZDSlp0RU52ZzZXb25DekRSQVVwamFLSDhp?= =?utf-8?B?VE9ZTmduS2dCdHBJeFl6Z2NjMll3ajc0THVUMGwzQWpWU00wSCtGcE1wYlF4?= =?utf-8?B?dGpQRUZtTGJSNjVPYjhGbGxqMUdZdjdtOWNRNnpFTitCMFBWdDBIMzl6OWNI?= =?utf-8?B?Kyt5c3RXdmMxZE5YTUZSMTNBQXBVeUo4RGFnRWIzWkh0QXJ0eTFHQUNXaFNT?= =?utf-8?B?K3gzb2NPVTE4aGlQWk5UZXNKUXl2b3BhTlZXTk5ibGlyTDZuVzZWUkZEUnFX?= =?utf-8?B?L2p5UGRaY2s1dUY5YVpFRWNheW9GRlZVdDRuT29aUllyVmQyYmVBMi8xNHg5?= =?utf-8?B?NG1XZ0ZpejgzZVprelBlNlhRTGozSWxKdkcwaklpV2JBd3kyS3JBeVF6Zm9R?= =?utf-8?B?OEJndnRCQml3dUlRKzN3bnZpZVV0ajIzNW41dWNGbGg3M1lBcU9jTkZVdVlk?= =?utf-8?B?RFl0d3RCbGR3Z0xLSURSY3NKWkhjamVjN3FxWFFFTGpyblcveS91OE1oMVA5?= =?utf-8?B?VjdVUFJTVzZaRTNsM3UzTjkycE9UWkoydHU5UWsySWxOSnhWc05ocVMzbXc4?= =?utf-8?B?Nm1MdWZkaW9rMUxvUlZ3S0hIYVdWaFR3YjVrYmdmU3o0WEk5QVNYV3Y5dkpF?= =?utf-8?B?WGt2RU8vRXRsdFhFMDM1V0lGTnRYQ1dQZEZobEtkUWpUc1JDODBXWTNnMEVU?= =?utf-8?B?NVI2RHhUMHRJaTVqK0RoSzBwc00xZHlGdXp0YStXbC9CNlh6YlczZVlkUmtz?= =?utf-8?B?cWxWemNlTmFvd1BKaU0zRWdMd3pZdjJwbDlXb21kd2dLWTZuMVZTN3pxWVQy?= =?utf-8?B?QWVHWC92TlhSOGVIREI3UmROenc1VVdwSU9nMHVKQlZ3QjhBUit0Si93TmZG?= =?utf-8?B?aFUyRm1Edyt5RjBqbVdzL1BaajdwYU8yVldhcytjZVF6a2JMcGl0Y2dETjlB?= =?utf-8?B?azk2ZjJZSlNMY0x2bnZPQTdWRTA4WGRYMzV4a0dURTAzK09jZ3RsekZaanF0?= =?utf-8?B?cE1xK1hyMmVJSnp1M1pvcTBSd0JONnBDUGtGWHFyUmlDSk9RYWNUSkJTanpm?= =?utf-8?B?UUZiMEF5ZGRXK2wwOGNVMWcvL2lJaUoxRVBBNGhtdHByeUV3aGxYVVN3ajJC?= =?utf-8?B?aFFxTUEvUVVFbzdqWGI5S2Rwcy9tVkFZSTN2TEhHdWlWek5lOEJJRHh0cWFj?= =?utf-8?B?R2I5UHFLMXI0NElFWnNBeHlNTmxxUEI0T09LclRETTNsa1BYS0pudlViMzBl?= =?utf-8?B?TGdwdnlBUjRoT3B2dWpXU25EbVFZV1lVRURZMXZoaUxJdnN0b2VEZlhzWnhL?= =?utf-8?B?c1haSzZ1ZDJwRTVDK2RTUThVUVo5aEU1UnVWTE1rVDdxalptYkVHSzZrK1l3?= =?utf-8?Q?jglVXJJDp/HlOVbcs7hAPyWRw2UYM=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB152; 5:GWdmPciTqLf3aw/C82vsarfOJRRmuNXkm9YeconHsPQ9rzF8LwDVIAYvX5CK4p/o38n1IRfb8SctlALpgAnGdPXXZKgJ6ymSpyqX8PVt9uDEq04S4E71XXTx+OPUSFiIbS9a+NXRBZqqG8RjnMpEhQ==; 24:9AtgwMSxB81KyYaDVVBZ7xLcmpItn9TJCdQ0zvXXRj16gW8R20GD9/iVo9R6BcJogzHj/PixIc6nGQKy7PlLHwW1sG1eC3RuxXmDcUbOK8k=; 20:9DgIbUx1Md1GqCbLy4VvBRp/GrK94j/JIjaLZutFDC0nHVwF5j9Qb6bQXn/zAbekDyxY4tjsPdLIq5sbqhlpUw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2015 15:58:27.7025 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATDOAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR06MB152 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] CoMI support for YANG notification and RPC 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, 15 Sep 2015 15:58:48 -0000 SGkgQ2Fyc3RlbiwNCg0KSSBkbyBub3QgaGF2ZSBhIGNvbmNyZXRlIHBsYW4geWV0IHJlZ2FyZGlu ZyB0aGUgdXNhZ2Ugb2YgQ29NSSBhbmQgWUFORzsgcmF0aGVyIEkgYW0gaW52ZXN0aWdhdGluZyBk aWZmZXJlbnQgb3B0aW9ucyBmb3IgZGV2aWNlIG1hbmFnZW1lbnQgYXQgdGhlIG1vbWVudC4NCg0K TXkgbWFpbiB1c2UgY2FzZSBpcyB0byBkbyB3aXRoIGNvbW1lcmNpYWwgYW5kIGluZHVzdHJpYWwg bGlnaHRpbmcuIEluIHRoaXMgYXJlYSwgd2UgdXN1YWxseSBoYXZlIHNlbnNvcnMgdGhhdCBsaW5r IHRvIGFjdHVhdG9ycyB2aWEgYSBjb250cm9sIGZ1bmN0aW9uIG9mIHNvbWUga2luZC4gRm9yIGlu c3RhbmNlLCBhIG1vdGlvbiBzZW5zb3IgbWlnaHQgdXNlIGEgZGVsYXllZCB0aW1lciB0byB0cmln Z2VyIGEgY29udHJvbCBmdW5jdGlvbiB0byB0dXJuIG9mZiBhIGx1bWluYWlyLiBVc3VhbGx5IGEg cHJvZmlsZSBpcyBidWlsdCBpbnRvIHRoZSBjb250cm9sIGZ1bmN0aW9uIHRvIHNsb3dseSBkaW0g ZG93biB0aGUgbHVtaW5haXIgYmVmb3JlIGNvbXBsZXRlbHkgdHVybmluZyBpdCBvZmYuIE1vcmVv dmVyLCBpdCBpcyBwb3NzaWJsZSB0byB0aGluayBvZiBzdGFja2VkIGNvbnRyb2wgZnVuY3Rpb25z IHRvIGluY2x1ZGUgZm9yIGluc3RhbmNlIGxpZ2h0IGludGVuc2l0eSBpbmZvcm1hdGlvbiBmcm9t IGEgc2Vjb25kIHNlbnNvciB0cmlnZ2VyaW5nIGEgZGlmZmVyZW50IHR5cGUgb2YgY29udHJvbCBm dW5jdGlvbi4gSW4gc3VjaCBzaXR1YXRpb25zLCBpdCBtaWdodCBiZSBkZXNpcmFibGUgdG8gdXNl IENvQVAgUE9TVCByZXF1ZXN0cyAoYWxhIFJlc3Rjb25mKSB0byBleGVjdXRlIGFuIGNvbnRyb2wg ZnVuY3Rpb24uIEluIGdlbmVyYWwsIGlmIENvTUkgaXMgdG8gYmUgYXBwbGljYWJsZSBpbiBhIHNp dHVhdGlvbiB3aGVyZSBldmVudCBkcml2ZW4gY29udHJvbCBhbGdvcml0aG1zIG1pZ2h0IGJlIHVz ZWQsIFJQQ3Mgd2lsbCBwbGF5IGFuIGltcG9ydGFudCByb2xlIGluIHN5c3RlbSBkZXNpZ24uDQoN CkkgcmVhbGlzZSB0aGF0IENvTUkgaXMgcHJvYmFibHkgbm90IGRlc2lnbmVkIHdpdGggc3VjaCB1 c2UgY2FzZXMgaW4gbWluZCBhbmQgaXMgbWFpbmx5IHRhcmdldGVkIGF0IG5ldHdvcmsgbWFuYWdl bWVudCBpc3N1ZXMuIEhvd2V2ZXIsIEkgYW0gaW52ZXN0aWdhdGluZyB0aGUgcG9zc2liaWxpdHkg b2YgcmV1c2luZyBhcyBtdWNoIG9mIENvTUkgYXMgcG9zc2libGUgdG8gZGVzaWduIG91ciBjb250 cm9sIGFyY2hpdGVjdHVyZSBpbiBsaWdodGluZy4NCg0KUmVnYXJkcywNCkFiaGluYXYNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNh Ym9AdHppLm9yZ10NClNlbnQ6IERpZW5zdGFnLCAxNS4gU2VwdGVtYmVyIDIwMTUgMTc6MDcNClRv OiBTb21hcmFqdSBBYmhpbmF2DQpDYzogY29yZUBpZXRmLm9yZyBXRw0KU3ViamVjdDogUmU6IFtj b3JlXSBDb01JIHN1cHBvcnQgZm9yIFlBTkcgbm90aWZpY2F0aW9uIGFuZCBSUEMNCg0KU29tYXJh anUgQWJoaW5hdiB3cm90ZToNCj4NCj4gICBIb3dldmVyLCBJIGFtIGxvb2tpbmcgZm9yIHN1cHBv cnQgZm9yIFlBTkcgUlBDcyBhbmQgc2VlIG5vIG1lbnRpb24gb2YNCj4gICBSUENzIGluIHRoZSBD b01JIGRyYWZ0Lg0KDQpIaSBBYmhpbmF2LA0KDQpJIHRoaW5rIHRoZXkganVzdCBoYXZlbid0IGJl ZW4gaW4gdGhlIGZvY3VzIHNvIGZhciwgbWF5YmUganVzdCBmb3IgYSBsYWNrIG9mIGltYWdpbmF0 aW9uIGZvciB3aGF0IHRoZXNlIFJQQ3Mgd291bGQgYmUgdXNlZCBmb3IuDQoNCkNhbiB5b3UgdGVs bCB1cyBhIGJpdCBtb3JlIGFib3V0IHRoZSB3YXkgeW91IHBsYW4gdG8gdXNlIFlBTkcgUlBDcyBv biBjb25zdHJhaW5lZCBkZXZpY2VzPw0KDQpHcsO8w59lLCBDYXJzdGVuDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBUaGUgY29udGVudHMg b2YgdGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQuIFRoZXkgbWF5IG5vdCBiZSBkaXNjbG9zZWQgdG8gb3IgdXNl ZCBieSBvciBjb3BpZWQgaW4gYW55IHdheSBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LiBJZiB0aGlzIGUtbWFpbCBpcyByZWNlaXZlZCBpbiBlcnJvciwgcGxlYXNl IGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIGUtbWFpbCBhbmQg YXR0YWNoZWQgZG9jdW1lbnRzLiBQbGVhc2Ugbm90ZSB0aGF0IG5laXRoZXIgdGhlIHNlbmRlciBu b3IgdGhlIHNlbmRlcidzIGNvbXBhbnkgYWNjZXB0IGFueSByZXNwb25zaWJpbGl0eSBmb3Igdmly dXNlcyBhbmQgaXQgaXMgeW91ciByZXNwb25zaWJpbGl0eSB0byBzY2FuIG9yIG90aGVyd2lzZSBj aGVjayB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzLg0K From nobody Tue Sep 15 15:50: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 B677A1B2D22 for ; Tue, 15 Sep 2015 15:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 5OE2NXDKpekR for ; Tue, 15 Sep 2015 15:50:15 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2751B2D1F for ; Tue, 15 Sep 2015 15:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t8FMo6kj026899; Wed, 16 Sep 2015 00:50:06 +0200 (CEST) Received: from alma.local (p5DCCDB06.dip0.t-ipconnect.de [93.204.219.6]) (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 3nG0BQ2tF7z21L1; Wed, 16 Sep 2015 00:50:06 +0200 (CEST) Message-ID: <55F8A09C.4060002@tzi.org> Date: Wed, 16 Sep 2015 00:50:04 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: Somaraju Abhinav References: <0E9A48AB39AF3547ACD28A6DE3E2906A0985F1@ATDOAGMSX02.itiso.net> <55F83427.2040203@tzi.org> <0E9A48AB39AF3547ACD28A6DE3E2906A09873D@ATDOAGMSX02.itiso.net> In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A09873D@ATDOAGMSX02.itiso.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] CoMI support for YANG notification and RPC 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, 15 Sep 2015 22:50:17 -0000 Hi Abhinav, while it is possible to do application transfers within the COMI framework, one assumption that most people might have was that we'll be a bit more free to use the entirety of REST for those transfers. One draft showing a way to employ REST in the lighting scenario came out just a few hours ago: http://tools.ietf.org/html/draft-hartke-core-lighting-00 This draft is focused on interop work we want to do in Yokohama (e.g., it uses JSON for exposition and not CBOR), but it is indicative of a general direction. Maybe that could be a good basis to compare these approaches. Gr眉脽e, Carsten Somaraju Abhinav wrote: > Hi Carsten, > > I do not have a concrete plan yet regarding the usage of CoMI and YANG; rather I am investigating different options for device management at the moment. > > My main use case is to do with commercial and industrial lighting. In this area, we usually have sensors that link to actuators via a control function of some kind. For instance, a motion sensor might use a delayed timer to trigger a control function to turn off a luminair. Usually a profile is built into the control function to slowly dim down the luminair before completely turning it off. Moreover, it is possible to think of stacked control functions to include for instance light intensity information from a second sensor triggering a different type of control function. In such situations, it might be desirable to use CoAP POST requests (ala Restconf) to execute an control function. In general, if CoMI is to be applicable in a situation where event driven control algorithms might be used, RPCs will play an important role in system design. > > I realise that CoMI is probably not designed with such use cases in mind and is mainly targeted at network management issues. However, I am investigating the possibility of reusing as much of CoMI as possible to design our control architecture in lighting. > > Regards, > Abhinav > > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Dienstag, 15. September 2015 17:07 > To: Somaraju Abhinav > Cc: core@ietf.org WG > Subject: Re: [core] CoMI support for YANG notification and RPC > > Somaraju Abhinav wrote: >> However, I am looking for support for YANG RPCs and see no mention of >> RPCs in the CoMI draft. > > Hi Abhinav, > > I think they just haven't been in the focus so far, maybe just for a lack of imagination for what these RPCs would be used for. > > Can you tell us a bit more about the way you plan to use YANG RPCs on constrained devices? > > Gr眉脽e, Carsten > ________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments. > > From nobody Wed Sep 16 00:39: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 7FE961B384A for ; Wed, 16 Sep 2015 00:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, 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 tv36wcN-W128 for ; Wed, 16 Sep 2015 00:38:56 -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 7D4821B36F3 for ; Wed, 16 Sep 2015 00:38:51 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.199]) by smtp-cloud2.xs4all.net with ESMTP id Hjeo1r00N4Hiz6i01jeopJ; Wed, 16 Sep 2015 09:38:49 +0200 Received: from AMontpellier-654-1-59-4.w86-202.abo.wanadoo.fr ([86.202.194.4]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 16 Sep 2015 09:38:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 16 Sep 2015 09:38:48 +0200 From: peter van der Stok To: Carsten Bormann Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <55F83427.2040203@tzi.org> References: <0E9A48AB39AF3547ACD28A6DE3E2906A0985F1@ATDOAGMSX02.itiso.net> <55F83427.2040203@tzi.org> Message-ID: <4c46654d17e5bc13207def5888e79cc6@xs4all.nl> X-Sender: stokcons@xs4all.nl (pwm4XJ6QV7NqTjir/M0Sl6UGKQ9f6QtI) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] CoMI support for YANG notification and RPC 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, 16 Sep 2015 07:39:01 -0000 Hi Abhinav, Other request for RPC support in CoMI have been expressed earlier from the 6tisch wg. We want to add RPC support once there is a good motivation to do so. The next draft version will probably describe RPC support with such a (hopefully convincing) motivation. We are looking forward to receive statements on the necessity of RPC to reinforce the motivation. Greetings, Peter Carsten Bormann schreef op 2015-09-15 17:07: > Somaraju Abhinav wrote: >> >> However, I am looking for support for YANG RPCs and see no mention >> of >> RPCs in the CoMI draft. > > Hi Abhinav, > > I think they just haven't been in the focus so far, maybe just for a > lack of imagination for what these RPCs would be used for. > > Can you tell us a bit more about the way you plan to use YANG RPCs on > constrained devices? > > Gr眉脽e, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Sep 16 04:47: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 21F7D1A923E for ; Wed, 16 Sep 2015 04:47:53 -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, 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 NjCO2MD5Lz4F for ; Wed, 16 Sep 2015 04:47:50 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97041A9116 for ; Wed, 16 Sep 2015 04:47:49 -0700 (PDT) Received: from DB5PR06CA0012.eurprd06.prod.outlook.com (10.162.165.22) by AMSPR06MB152.eurprd06.prod.outlook.com (10.242.91.27) with Microsoft SMTP Server (TLS) id 15.1.268.17; Wed, 16 Sep 2015 11:47:31 +0000 Received: from DB3FFO11FD035.protection.gbl (2a01:111:f400:7e04::102) by DB5PR06CA0012.outlook.office365.com (2a01:111:e400:52c2::22) with Microsoft SMTP Server (TLS) id 15.1.274.16 via Frontend Transport; Wed, 16 Sep 2015 11:47:31 +0000 Authentication-Results: spf=fail (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=tridonic.com; Received-SPF: Fail (protection.outlook.com: domain of tridonic.com does not designate 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATDOAGMSX01.itiso.net; Received: from ATDOAGMSX01.itiso.net (146.108.200.10) by DB3FFO11FD035.mail.protection.outlook.com (10.47.217.66) with Microsoft SMTP Server (TLS) id 15.1.262.18 via Frontend Transport; Wed, 16 Sep 2015 11:47:30 +0000 Received: from ATDOAGMSX02.itiso.net ([169.254.4.182]) by ATDOAGMSX01.itiso.net ([169.254.3.31]) with mapi id 14.03.0224.002; Wed, 16 Sep 2015 13:47:28 +0200 From: Somaraju Abhinav To: "consultancy@vanderstok.org" , Carsten Bormann Thread-Topic: [core] CoMI support for YANG notification and RPC Thread-Index: AQHQ8FK7PNcgyYq40ESug/siy+ZN5Z4/BGDQ Date: Wed, 16 Sep 2015 11:47:27 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A098B74@ATDOAGMSX02.itiso.net> References: <0E9A48AB39AF3547ACD28A6DE3E2906A0985F1@ATDOAGMSX02.itiso.net> <55F83427.2040203@tzi.org> <4c46654d17e5bc13207def5888e79cc6@xs4all.nl> In-Reply-To: <4c46654d17e5bc13207def5888e79cc6@xs4all.nl> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.41.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD035; 1:iXUHevUwYzryck9hEIBXIPG3md8AA+3fenFZd3gTEuGAzmd5Exef8h1w+5T9/L1qitNF8m0oa5alrVqidCyv8fcLjgJ7lx1lzcdNJSiFLmRkEU8EbGjP9veSrgPU+E5WU1jUfrpkL461ZOaaMMiv/UMX36yLJTf4lykQ23tWdUekUnvEQlZe/dVCDpAQm57YoAU8v3nQIo9O0LPlrG32wmMpeUacv2gUQx/HHallMHoCnru4YiPhkCmYwDeL55QAiia+UQiyotD3LcclreOgRcT5tU8iau1TOQ7xM8kW6q86UvVoeXmyaEpmqK295b8VXof1gUEg/dYbKN+FPOGE2Q== X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(1110001)(1109001)(339900001)(13464003)(189002)(199003)(377424004)(24454002)(51914003)(76176999)(104016003)(2920100001)(54356999)(106466001)(55846006)(106116001)(87936001)(23676002)(554214002)(19580405001)(105606002)(69596002)(53416004)(33656002)(50986999)(5003600100002)(26826002)(66066001)(64706001)(102836002)(81156007)(189998001)(6806004)(2950100001)(5001860100001)(92566002)(2501003)(11100500001)(86362001)(4001540100001)(19580395003)(5001960100002)(15975445007)(50466002)(5001830100001)(2900100001)(5890100001)(85426001)(62966003)(77156002)(5001770100001)(46102003)(47776003)(5007970100001)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR06MB152; H:ATDOAGMSX01.itiso.net; FPR:; SPF:Fail; PTR:unknown.zgrp.net; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB152; 2:x6z+01yEcJD+RNYjMByLv2h9pXUPwnlL4+6S5IBxGUNnM8ZG195CalmptzrNAZJS55ujVZe/pUtpIqalJ9KczizsxW/vSz1HJuEs/YOOVNC6Ay272VVJU1qVj4gNPi6JD2jRfJeOAj9TxOtvj1BjW8p043DMJWaG9ZJLUD6mw/g=; 3:4zpt+3V37ejfcgyibrKNntd5RH+zEtMYIm3TnjvREQgiyPB26SLPO/oobYwiEMRr7IKkLQH9c+GUgeznoNMnLoSnQ/ELvVf+NUWnyMdoqiWDANKEc2yi1nr6OIHOHyMKfVrgCPI4yMy/jmZYN7gUrd6VLj3/4IJwncsr9/xtHX+F0TXDewCyCb7SVUmAODWLnGCB1bclToE+izzI/x+O09n487VYoZA2k6qf5jZzDdnPGIIJlm4dqQNmgqFC98s7; 25:qUgYVCMTi8b2RAtU5zyJUBJqF5Hdc7EzN/+pH8ff/zt7tqpohmFwZdpca7f8hHd/EiciOt7+xUbYrI1iaMAgSqriTCWCO5UrhmAOyDT7cVRQKQSbs9geUv2szBmj9CbTQIXrmJpvRPmDTd4QyIMvH8vwv8wPNeAWareEk+E+eIDXbdQGv1TxNGo0wdg7Ahbwq3OjjoUkz32EMNwl1FEyxlAZiBIvdEa8Y5EOvdVhLb5Kd+p+dVWkJC8YxympkPOFZVQOtXuovw8OD9fuwndCSQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR06MB152; X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB152; 20:ahXbxHasAWGYfFAUQYiv30paOrTQMhyu0WmJTScM9SJbefStWe+UNMStZeAHNo4VbDpRx84rXxSpvwB2ggvqJPJ8U/e/EnY/bmGaxLFYmeJMeSSV5y+DXIGSxGK9c4+v3gN2zcCb5PHQ2IDQ9yDVCwt9orEmxplSUe3I/AYbZDRr/vv1BYADHc1X8vKU4ggkpabBAkFm5rRrKOcajo+uG3+jkggbUzHT0jXLU3EIiIw1QmdUsgK+R7W/ft8U3EKIP57pW4oksl8oiHJ9RvuPuiHXxk7S2J+QovPqQ9KUD1eJV70ldPlZVJ0ypje63UAhNb68Z2JfyEXlKRdDw+rCI3a2XhhUUbLdjjWX2f7bhgqUzyfFxa2EITP7SKd/Am36INXFEVOZAHR+ORKEwtv69KWVTUYBxuO/5h7YAxsyONH6Mxd8qPkDW4OXMNf2XETC+4C1lNRmfqhS9d/53XZFPM+e5s9a21jzZSCz0ClekypKSDcgCr2P1ygHF/1zlOQx; 4:A6cDe+BR7TL2CXl/vkyRNP81DjuEYAjEcaOiIg0yQ4dK2BUJOzkbDIgj9PuGbm372pw1TX+AJE6lg9bjjd+yOedvmRPBrClYLFu1I80ee28gUFGK4bkje+LeWdWxfUdziVXdRy0y82as/ba44ScIE46LdY07twswg9rYMXmwutmrKDmHH7pKRGvUDpatRJBS+t/5aPvCGd534QO8tb8mQFKyutIEhcB2DwpBIAJr7Q7roIIV1Oo5yVIZK6SYBGTv3JLwXDQP2uRkd7gvNOBTj5B7uFTzjQ6My2qxqx8YS32EQs/J20Lm0KNyYG/38FB0G8ZPxWeA5N5yw8DRCxI7CaL6rX+Oe6sO5twsdKi78Qw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520078)(5005006)(8121501046)(520075)(3002001); SRVR:AMSPR06MB152; BCL:0; PCL:0; RULEID:; SRVR:AMSPR06MB152; X-Forefront-PRVS: 07013D7479 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVNQUjA2TUIxNTI7MjM6VElCQmQvd0pRekVtdjRLZ3hQWW5lYVQzNzMr?= =?utf-8?B?YzBxS1lJY1pPdUtjUW9Zd3hjY3I2MVROYzZWTzFHNTVnMk4zdWFGNno0VmpC?= =?utf-8?B?ZC9RYktjTGN3U3QxNm1EOW5vZHI1bFJJcjFUb2llUm8yeW1xdlVUTTVjT1Uy?= =?utf-8?B?Wm1xU1hnWkdKaHBkaGoxTzNLRDZRK1pQSU5EVUVFb2F4WnJLNko5YVNiRDVy?= =?utf-8?B?U1U2cXp3Qy9UOUYrTjFSMEdPVHptVDdqU04zNFVvYzdZQXVJR2pGNFN6Y1R4?= =?utf-8?B?bkVMTksyS0dKRWdXSFVjTnFxZzFadDdpU1FpUFBXZno4K05xM0dIdXFGUFdw?= =?utf-8?B?czVKWUg1M0RIY3VmaUxXWVBIOVRWSEEyb2J2MXRwSkE0R2J6U2lTUHdrZXg2?= =?utf-8?B?VlNTVnQ2ME5jQld3U1BqUSt0UTlReHQwbEYwZGhtK2lqK1U0QkpLWEVWUHlQ?= =?utf-8?B?eXVJRzJpTStKWTJVSG5pTDhsM1VQd2gzb3IwWm1PZDhOQ2NqMWEzL0lEejJ5?= =?utf-8?B?TzBTSUQ5bEF2ZFVVV2QxanBTYXVuTkJrejU1UUcvSW9WZEhtQ240bm5LU1da?= =?utf-8?B?ZnhDUkdYRUhaSDFvTVNLYVkxYkI4M3c4c3FuaWtBZ2VZelFFKzNzdlBsSUNx?= =?utf-8?B?Vy8wRTE2emc3WEJGSVJKUTIyclk5ODdVSXRHenN1Mm40UHJVNU50ajk5NUlG?= =?utf-8?B?TmVLem00UHR5akJpZlg2a0tPN05jN2dRSVlQN2VYcDlpNWJCYlBTRCsrNXI4?= =?utf-8?B?Z1NKWFIwZW5XWG41ZVFoa3JGTDVQclBUM1RuVFBDeUpEZHNzS05NaG9TdEtP?= =?utf-8?B?UitjQ2ltRHpreXBYdWNKbVpnSVh5RGk0aDAxY3VUNEZLY2NZa2tLY3p0SGFP?= =?utf-8?B?OWN4YWp1b0hqNGczRUh0VGkxRDhQdkl1VittUEx2Q1pnb05ra29oQ3dvWEha?= =?utf-8?B?RmJpS2tlbDhPdEdRSEQ5MDBWbEQrRHRQWlMxYzd2dmJ1eE1KeVBhYytobmdN?= =?utf-8?B?ZW1OdDh2MjRBaFM4dGYrVWIyRFVzeFVKVW9JdUpGVEJicjIxaGFoSHRTZC9j?= =?utf-8?B?RDFaT2lkRWNvUkZrclpmN2FyY3BEeGFzSmRicDhQV1E0L1dSM0czMGJQVE9h?= =?utf-8?B?ajlPMXdnRjdiMWd5dDBEQ2NORm1DbkVnd2h1cERUSzFaOVp5MnRqMHhLRFhE?= =?utf-8?B?Si9VdFBwazV5VlIzV0tZTStaMHIwajloM1czNWNHVUdneWo5NTZaVHNwWUs4?= =?utf-8?B?VXltYjhra1NMUkNYV1NOeHVidlA1enlxV1c4ME0vemRiSitjUVlzR2dGUlpD?= =?utf-8?B?VSt1TVNpWktta090ejlwVzMrdDF1MmdZNzdOcHQ0SUxOY093NkxNbTRza2xJ?= =?utf-8?B?aFg2aTk3UkVtdzFyUkhJWFpCVUx4b2NDSEVsM21OaFFFNUluc1pGRmtZaThE?= =?utf-8?B?elJ4dldSeUdIcGVKT3hGQ0xkaDNFYUduemUzQlhPWWhZQzJQZ1Q2aUdKMHVn?= =?utf-8?B?Zno1SGxObTJtMGZkc0tSTTZ2aEMyM3EzeDNpTmxjbzZzNE1LWUVrUGFNc3pk?= =?utf-8?B?MUt3YU5uQ1RZc2RjSitwbUVWa1prNzNtZm1BNVhlQnFEcUR6RWhSRnRtcUtX?= =?utf-8?B?MVJOMUlCRGg3c010eUVQbEVJZVAvZ05obVJKdjJTRE5WR1Fzb1l5QUc2eVEx?= =?utf-8?B?dEZJS0NCZzZrYzM1UG5KbGlhQm90NDFRbENqdjUvYUUzYWwvUS9zSXVvWFZC?= =?utf-8?B?eEdWRkZaWXF0YVpoMURCekoxaXVvaHZPUVBqRFloNkhzL2VVQ2JEMk1TUElU?= =?utf-8?B?V2N1bWtRQnBiWGRtemp2MnJ0SHd1MzJOb1h3Zllac0dWV0ZJZTh0Q2prbEhz?= =?utf-8?B?R0tZcmdHaGNNTVkvcDVxaVlWWHI0VlFHOTFEWS9ZMXBIclk4YjhBbVN6NHhY?= =?utf-8?B?NkxONExXdWFJYXJpcnJ6M3FTOWE5NXpvK093b3NrUzJqUzhmb3FZRHdQajhq?= =?utf-8?B?Z09vYVdLTG1uQjlmT1AwY05hV1AvTG1QMG9MeUlPT0Y3WkRvL3VYQzdzRUFq?= =?utf-8?Q?sck=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB152; 5:msXjErnzd+9bsJGcbViFgytqzo3m4ov748dyrm+xSepmBkS8ZIX3ljh+mB9lTcTmxZ0NErDDTYsR0J8oQqR97kkiLNwHfpF0OyPkGYS4111wJMzw19gysROu7T/gySsWYdFy3y2aLjPPP+btoI2uKw==; 24:ObTkeZzc500TCUx4z5PYcPSL/Qake0GAMhXT1SIHKUQRN5jEkU987vjmOzeTSfF//5qeuPToaY6NVYCQjg+qdQzI5v6C/OThgRaL1Xx7mrw=; 20:/mCK8U2Nd08ZSiSSrjrSGrmB0hf3ikeCxhMb3oaECv9UDzuTv5sxu5pmaJuh3fCmQHobP5nSmoutqXai4pJL8w== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2015 11:47:30.9092 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATDOAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR06MB152 Archived-At: Cc: Core Subject: Re: [core] CoMI support for YANG notification and RPC 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, 16 Sep 2015 11:47:53 -0000 SGkgUGV0ZXIsDQpUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLg0KDQo+V2Ugd2FudCB0byBh ZGQgUlBDIHN1cHBvcnQgb25jZSB0aGVyZSBpcyBhIGdvb2QgbW90aXZhdGlvbiB0byBkbyBzby4N Ckl0IGlzIG5vdCBlbnRpcmVseSBjbGVhciB0byBtZSBleGFjdGx5IHdoYXQgQ29NSSBpcyB0cnlp bmcgdG8gYWNoaWV2ZS4gVGhlIGludHJvZHVjdGlvbiBpbmRpY2F0ZXMgdGhhdCBDb01JIGlzIGEg cmVwbGFjZW1lbnQgZm9yIFJlc3Rjb25mIGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cyAgKCJU aGUgUkVTVENPTkYgcHJvdG9jb2wgaXMgYWRhcHRlZCBhbmQgb3B0aW1pemVkIGZvciB1c2UgaW4g Y29uc3RyYWluZWQgZW52aXJvbm1lbnRzLCB1c2luZyBDb0FQIGluc3RlYWQgb2YgSFRUUCIpLiBJ ZiBDb01JIGlzIG9ubHkgdHJ5aW5nIHRvIHByb3ZpZGUgYSByZXBsYWNlbWVudCBmb3IgUmVzZmNv bmYsIHRoZW4gaXNu4oCZdCB0aGUgZmFjdCB0aGF0IFJlc3Rjb25mIHN1cHBvcnRzIFJQQ3Mgc3Vm ZmljaWVudCB0byByZXF1aXJlIENvTUkgdG8gc3VwcG9ydCBSUENzPw0KDQpBbHRlcm5hdGl2ZWx5 LCB0aGUgb2JqZWN0aXZlcyBvbiBQLjcgaW5kaWNhdGUgdGhhdCBDb01JIGNhbiBiZSB1c2VkIHRv IG1hbmFnZSB0aGUgb3BlcmF0aW9uYWwvcGVyZm9ybWFuY2UgY2hhcmFjdGVyaXN0aWNzIG9mIHRo ZSBjb25zdHJhaW5lZCBkZXZpY2VzLiBCeSBvcGVyYXRpb25hbC9wZXJmb3JtYW5jZSBjaGFyYWN0 ZXJpc3RpY3MgZG8geW91IG9ubHkgbWVhbiBjaGFyYWN0ZXJpc3RpY3MgcmVsYXRlZCB0byB0aGUg bmV0d29yayBsYXllciBhbmQgYmVsb3cgaW4gdGhlIHN0YWNrIG9yIGFsc28gdGhlIGFwcGxpY2F0 aW9uIGxheWVyJ3Mgb3BlcmF0aW9uYWwvcGVyZm9ybWFuY2UgY2hhcmFjdGVyaXN0aWNzPyBJZiBD b01JIGlzIHRvIGJlIHVzZWQgdG8gYWxzbyBtYW5hZ2UgYXBwbGljYXRpb24gbGF5ZXIgYmVoYXZp b3Igb2YgdGhlIGRldmljZXMgKGUuZy4gZGlzY292ZXJpbmcgdGhlIHR5cGUgb2YgQ29BUCByZXNv dXJjZXMgc3VwcG9ydGVkIGJ5IHRoZSBlbmQtcG9pbnRzIGFuZCBjb25maWd1cmluZyB0aGUgaW50 ZXJhY3Rpb24gYmV0d2VlbiBjb25zdHJhaW5lZCBDb0FQIGNsaWVudHMgYW5kIHNlcnZlcnMpIHRo ZW4gaXQgd291bGQgYmUgaGVscGZ1bCB0byBhbHNvIGxvb2sgYXQgdGhlIGFwcGxpY2F0aW9uIGxh eWVyIHVzZSBjYXNlcyB0aGF0IENvTUkgaXMgdHJ5aW5nIHRvIHN1cHBvcnQuIEkgYW0gZ3Vlc3Np bmcgdGhhdCBhbmFseXppbmcgdGhlc2UgdXNlLWNhc2VzIHdpbGwgbW90aXZhdGUgdGhlIG5lZWQg dG8gc3VwcG9ydCBSUENzLg0KDQpSZWdhcmRzLA0KQWJoaW5hdg0KDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IHBldGVyIHZhbiBkZXIgU3RvayBbbWFpbHRvOnN0b2tjb25z QHhzNGFsbC5ubF0NClNlbnQ6IE1pdHR3b2NoLCAxNi4gU2VwdGVtYmVyIDIwMTUgMDk6MzkNClRv OiBDYXJzdGVuIEJvcm1hbm4NCkNjOiBTb21hcmFqdSBBYmhpbmF2OyBDb3JlDQpTdWJqZWN0OiBS ZTogW2NvcmVdIENvTUkgc3VwcG9ydCBmb3IgWUFORyBub3RpZmljYXRpb24gYW5kIFJQQw0KDQpI aSBBYmhpbmF2LA0KDQpPdGhlciByZXF1ZXN0IGZvciBSUEMgc3VwcG9ydCBpbiBDb01JIGhhdmUg YmVlbiBleHByZXNzZWQgZWFybGllciBmcm9tIHRoZSA2dGlzY2ggd2cuDQpXZSB3YW50IHRvIGFk ZCBSUEMgc3VwcG9ydCBvbmNlIHRoZXJlIGlzIGEgZ29vZCBtb3RpdmF0aW9uIHRvIGRvIHNvLg0K DQpUaGUgbmV4dCBkcmFmdCB2ZXJzaW9uIHdpbGwgcHJvYmFibHkgZGVzY3JpYmUgUlBDIHN1cHBv cnQgd2l0aCBzdWNoIGEgKGhvcGVmdWxseSBjb252aW5jaW5nKSBtb3RpdmF0aW9uLg0KV2UgYXJl IGxvb2tpbmcgZm9yd2FyZCB0byByZWNlaXZlIHN0YXRlbWVudHMgb24gdGhlIG5lY2Vzc2l0eSBv ZiBSUEMgdG8gcmVpbmZvcmNlIHRoZSBtb3RpdmF0aW9uLg0KDQpHcmVldGluZ3MsDQoNClBldGVy DQoNCkNhcnN0ZW4gQm9ybWFubiBzY2hyZWVmIG9wIDIwMTUtMDktMTUgMTc6MDc6DQo+IFNvbWFy YWp1IEFiaGluYXYgd3JvdGU6DQo+Pg0KPj4gICBIb3dldmVyLCBJIGFtIGxvb2tpbmcgZm9yIHN1 cHBvcnQgZm9yIFlBTkcgUlBDcyBhbmQgc2VlIG5vIG1lbnRpb24NCj4+IG9mDQo+PiAgIFJQQ3Mg aW4gdGhlIENvTUkgZHJhZnQuDQo+DQo+IEhpIEFiaGluYXYsDQo+DQo+IEkgdGhpbmsgdGhleSBq dXN0IGhhdmVuJ3QgYmVlbiBpbiB0aGUgZm9jdXMgc28gZmFyLCBtYXliZSBqdXN0IGZvciBhDQo+ IGxhY2sgb2YgaW1hZ2luYXRpb24gZm9yIHdoYXQgdGhlc2UgUlBDcyB3b3VsZCBiZSB1c2VkIGZv ci4NCj4NCj4gQ2FuIHlvdSB0ZWxsIHVzIGEgYml0IG1vcmUgYWJvdXQgdGhlIHdheSB5b3UgcGxh biB0byB1c2UgWUFORyBSUENzIG9uDQo+IGNvbnN0cmFpbmVkIGRldmljZXM/DQo+DQo+IEdyw7zD n2UsIENhcnN0ZW4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gY29yZSBtYWlsaW5nIGxpc3QNCj4gY29yZUBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIFRoZSBjb250ZW50cyBvZiB0aGlz IGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVu ZGVkIHJlY2lwaWVudC4gVGhleSBtYXkgbm90IGJlIGRpc2Nsb3NlZCB0byBvciB1c2VkIGJ5IG9y IGNvcGllZCBpbiBhbnkgd2F5IGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNp cGllbnQuIElmIHRoaXMgZS1tYWlsIGlzIHJlY2VpdmVkIGluIGVycm9yLCBwbGVhc2UgaW1tZWRp YXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgZS1tYWlsIGFuZCBhdHRhY2hl ZCBkb2N1bWVudHMuIFBsZWFzZSBub3RlIHRoYXQgbmVpdGhlciB0aGUgc2VuZGVyIG5vciB0aGUg c2VuZGVyJ3MgY29tcGFueSBhY2NlcHQgYW55IHJlc3BvbnNpYmlsaXR5IGZvciB2aXJ1c2VzIGFu ZCBpdCBpcyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIHNjYW4gb3Igb3RoZXJ3aXNlIGNoZWNrIHRo aXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMuDQo= From nobody Wed Sep 16 05:30:58 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 44AED1ACE9E for ; Wed, 16 Sep 2015 05:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, 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 Mkc-PSmHXH76 for ; Wed, 16 Sep 2015 05:30:53 -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 13F5E1A3B9F for ; Wed, 16 Sep 2015 05:30:52 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.199]) by smtp-cloud2.xs4all.net with ESMTP id HoWo1r00Q4Hiz6i01oWoAb; Wed, 16 Sep 2015 14:30:48 +0200 Received: from AMontpellier-654-1-59-4.w86-202.abo.wanadoo.fr ([86.202.194.4]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 16 Sep 2015 14:30:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 16 Sep 2015 14:30:48 +0200 From: peter van der Stok To: Somaraju Abhinav Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A098B74@ATDOAGMSX02.itiso.net> References: <0E9A48AB39AF3547ACD28A6DE3E2906A0985F1@ATDOAGMSX02.itiso.net> <55F83427.2040203@tzi.org> <4c46654d17e5bc13207def5888e79cc6@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A098B74@ATDOAGMSX02.itiso.net> Message-ID: <289a977d59d6e4aac41927e249dd5df2@xs4all.nl> X-Sender: stokcons@xs4all.nl (DxT0SRjoCZwEzk8XMx9euWRitlDo4HuR) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] CoMI support for YANG notification and RPC 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, 16 Sep 2015 12:30:56 -0000 Hi Abhinav, The original purpose of the CoMI is the same as NETCONF: The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. And comparable to RESTCONF This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. CoMI is targeted to constrained devices and uses preferably CoAP instead of http (less verbose). An effort has been made to reduce the payload size by using hashes for the YANG node names. Also not all functionality of RESTCONF has been taken over to reduce complexity of the CoMI code. The configuration of network devices may go beyond the network/transport layer if this is convenient. If CoMI is deemed interesting for application level data manipulation, we like to hear about it. In that context, doing the exercise to model control application data and its manipulations seemed to indicate that RPCs are useful. Greetings, Peter Somaraju Abhinav schreef op 2015-09-16 13:47: > Hi Peter, > Thanks for the clarification. > >> We want to add RPC support once there is a good motivation to do so. > It is not entirely clear to me exactly what CoMI is trying to achieve. > The introduction indicates that CoMI is a replacement for Restconf in > constrained environments ("The RESTCONF protocol is adapted and > optimized for use in constrained environments, using CoAP instead of > HTTP"). If CoMI is only trying to provide a replacement for Resfconf, > then isn鈥檛 the fact that Restconf supports RPCs sufficient to require > CoMI to support RPCs? > > Alternatively, the objectives on P.7 indicate that CoMI can be used to > manage the operational/performance characteristics of the constrained > devices. By operational/performance characteristics do you only mean > characteristics related to the network layer and below in the stack or > also the application layer's operational/performance characteristics? > If CoMI is to be used to also manage application layer behavior of the > devices (e.g. discovering the type of CoAP resources supported by the > end-points and configuring the interaction between constrained CoAP > clients and servers) then it would be helpful to also look at the > application layer use cases that CoMI is trying to support. I am > guessing that analyzing these use-cases will motivate the need to > support RPCs. > > Regards, > Abhinav > > > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Mittwoch, 16. September 2015 09:39 > To: Carsten Bormann > Cc: Somaraju Abhinav; Core > Subject: Re: [core] CoMI support for YANG notification and RPC > > Hi Abhinav, > > Other request for RPC support in CoMI have been expressed earlier from > the 6tisch wg. > We want to add RPC support once there is a good motivation to do so. > > The next draft version will probably describe RPC support with such a > (hopefully convincing) motivation. > We are looking forward to receive statements on the necessity of RPC > to reinforce the motivation. > > Greetings, > > Peter > > Carsten Bormann schreef op 2015-09-15 17:07: >> Somaraju Abhinav wrote: >>> >>> However, I am looking for support for YANG RPCs and see no mention >>> of >>> RPCs in the CoMI draft. >> >> Hi Abhinav, >> >> I think they just haven't been in the focus so far, maybe just for a >> lack of imagination for what these RPCs would be used for. >> >> Can you tell us a bit more about the way you plan to use YANG RPCs on >> constrained devices? >> >> Gr眉脽e, Carsten >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > ________________________________________________________ The contents > of this e-mail and any attachments are confidential to the intended > recipient. They may not be disclosed to or used by or copied in any > way by anyone other than the intended recipient. If this e-mail is > received in error, please immediately notify the sender and delete the > e-mail and attached documents. Please note that neither the sender nor > the sender's company accept any responsibility for viruses and it is > your responsibility to scan or otherwise check this e-mail and any > attachments. From nobody Wed Sep 16 06:25: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 8237B1B3924 for ; Wed, 16 Sep 2015 06:25:08 -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, 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 PakLhqp1sp_O for ; Wed, 16 Sep 2015 06:25:02 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754471B38FC for ; Wed, 16 Sep 2015 06:25:01 -0700 (PDT) Received: from VI1PR06CA0040.eurprd06.prod.outlook.com (10.162.116.178) by HE1PR06MB1484.eurprd06.prod.outlook.com (10.164.50.30) with Microsoft SMTP Server (TLS) id 15.1.268.17; Wed, 16 Sep 2015 13:24:40 +0000 Received: from DB3FFO11FD047.protection.gbl (2a01:111:f400:7e04::103) by VI1PR06CA0040.outlook.office365.com (2a01:111:e400:587c::50) with Microsoft SMTP Server (TLS) id 15.1.274.16 via Frontend Transport; Wed, 16 Sep 2015 13:24:39 +0000 Authentication-Results: spf=fail (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=tridonic.com; Received-SPF: Fail (protection.outlook.com: domain of tridonic.com does not designate 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATBRAGMSX01.itiso.net; Received: from ATBRAGMSX01.itiso.net (146.108.200.10) by DB3FFO11FD047.mail.protection.outlook.com (10.47.217.78) with Microsoft SMTP Server (TLS) id 15.1.262.18 via Frontend Transport; Wed, 16 Sep 2015 13:24:38 +0000 Received: from ATDOAGMSX02.itiso.net ([169.254.4.182]) by ATBRAGMSX01.itiso.net ([169.254.1.190]) with mapi id 14.03.0224.002; Wed, 16 Sep 2015 15:24:38 +0200 From: Somaraju Abhinav To: "consultancy@vanderstok.org" Thread-Topic: [core] CoMI support for YANG notification and RPC Thread-Index: AQHQ8FK7PNcgyYq40ESug/siy+ZN5Z4/BGDQ///wewCAACs34A== Date: Wed, 16 Sep 2015 13:24:38 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A098CF9@ATDOAGMSX02.itiso.net> References: <0E9A48AB39AF3547ACD28A6DE3E2906A0985F1@ATDOAGMSX02.itiso.net> <55F83427.2040203@tzi.org> <4c46654d17e5bc13207def5888e79cc6@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A098B74@ATDOAGMSX02.itiso.net> <289a977d59d6e4aac41927e249dd5df2@xs4all.nl> In-Reply-To: <289a977d59d6e4aac41927e249dd5df2@xs4all.nl> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.41.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD047; 1:r2kcm2KK4KZJOnaxCUYY7ClWRcqPal1z7uUgPpMvGz65NA5KeoKNC9tGrAyuwPPtY8ZmDrMZRNjWOHNLoFFucuszcv2td9m7/lcfxN069u7NHMGjgCXwEP4vlADEEbKzudkoV7zvevQ/Fx+aCTfh4KFTpoUq0OLyAi3meEuJP205TgN9DxIFic6QLlGuZ3QG8+Ja1MTjf+YnOJAIXZOdP/CoE1HZ376mNJecHkQ+4Q6nRWEwP29TL+84l99ixcEWjKCn1bD9KMbgugOphbhQ/AMlUjGyCQGqFuHykmOmPKS4JsWF/9L78+mj54bq/w2IcJdbRqwwBQ2amuHT/SfB/w== X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(1109001)(1110001)(339900001)(51914003)(189002)(24454002)(377424004)(199003)(13464003)(81156007)(2351001)(69596002)(87936001)(5001830100001)(15975445007)(102836002)(66066001)(50466002)(93886004)(554214002)(5001860100001)(5004730100002)(85426001)(5007970100001)(46102003)(64706001)(47776003)(33656002)(5001960100002)(2900100001)(189998001)(2501003)(104016003)(54356999)(106116001)(62966003)(92566002)(5003600100002)(55846006)(2920100001)(85806002)(50986999)(105606002)(110136002)(23676002)(86362001)(5890100001)(2950100001)(26826002)(53416004)(106466001)(6806004)(19580395003)(76176999)(4001540100001)(77156002)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR06MB1484; H:ATBRAGMSX01.itiso.net; FPR:; SPF:Fail; PTR:unknown.zgrp.net; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; HE1PR06MB1484; 2:hwxgses2rYciCaYM0bsEAJSfrQp5hm5BeDYog+wvv1LtGfirBRQ2E0JCt1hRP5q63Wh5+3n5YsO+CVkDvmg6DlizIqntNQBTvA7wUCsC/7nwGYyU4TKdYiVcGSWk7TDPs02y5KOH0wPqNEr54dNA4IVmHgNJvFu8oxuhs0JQKPk=; 3:L9L+mB87mDAz8xt0V7j1lB8d6ctFrRVTeAdwktr0TyC7jBiq0IWGXliE0u5k+n+jO6RQ2b+SQ6uTO17mBzNonWj7vcGpE3RkOgR+9g7sxhTPmUr1dwdEAwajE1KuOcbLQVXYwIkphclLza9znrsz321i9L5DLw3M/GVAR9gQTdTeLxmlkMAUiJDXsbuYd+ZqLDvy/r7YcgzsNGQjzHerHzyESJoqBOqE8/BFNa/J+wV/3dLy68AWuYL+S4kGo6OZ; 25:2HYNKlrICJFDGXzzoyP3bwTj/lgvI2On1ay6hRAp47cXirrr5WQx9lq6Ixs5nFBDOBFBWk+pA1BVwhKI36hp1M3Q5HC54if61ZsMSdWC5cfS46GYI+GoagVp6rZ3tKKCbEjtuPjGAFMIMNO4UtETrDQnK0vxygoTjw1SOoPyn3MQAcHBrIuJQ2bve4Ba9NfO+uWA/EFE62VoTmAJ0eXItXgt0DrOcJbuHympiq9UGSgDlvk5xfoUqZxZdR09OUWTlF7UEBM1xs1sxCfQafMWHg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR06MB1484; X-Microsoft-Exchange-Diagnostics: 1; HE1PR06MB1484; 20:fZQqOkQS9dzxLc0ca9udnJGtff2vh9kXOVAkScK2VuKRCTzoAbyGmeppMxuoNTNSaQbUY4IzXeInx+oyIIzsfynX8jy+F4OZt8NeaNH9kHTlcnl0U1nldqxjaMVbc66BRnBpV6cvYoGd9EwRgxRuajNUAUvxBQ6PUSA8guyyM7KH/9hbhsY9MizqL2Txf90AVKxc3HowqcOF1jjb01FeFZjOznhipRBiinDTMU5OlWt+Kr/yWHMVdkO44E3cAWo9aN58rlVKhjDvbfK+O4o7pGIF4rc137sZBoWVCSSsKXU4inKuy0EipqeeBhq8R0Qb9r5e6IUensskq1l3zfu1uYutKPUspxXmNb9b+uLBScNRz8TFM2ZQhyrv5yQTv9Sqyqso/DpPViA8Tuikg00RF542Th5rP17c4Uz9mCsfMqNRsCdbEL6vLXnnA/mCk6dbpivEf2a9d22Tr6OiDN+RDpz+nY11ltGmWZ2nz6BR9bljZd+2LYnsPEG35QeKc2GA; 4:6YpHgJtzUsvLw3ReF9t4mXZRA5IuK5lRqTWT6CgwM/fl1Hw1anaqE1DHXY7mmmnR6kWU667vO4axYJ9goO+/wl9tVqk/778+jlvtbF2mvLcdK3MBXwtoRoI7tw9+aRzfv4kTCOw9fPaUiM2uN1vbPoYBAiXacwQw4YHkY7stkcaZfRSfN3dUxJGgcfegaYn+WduVH9a7FJION/WyWOwbI37Zx4TwE8N6L1oL0CPQWHVan5WdZpdI/4eCZ3w2g3jiYoti5vYb7h05Rja7lHJac3iuXiDwq1H/yVnTKe2FmWpkkujLzr5j6lNEzKqQGTYUmj94iLeWGgK2lcrk+2qCfPgyWJPm9SPIhvBOeTj2VH8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520078)(5005006)(8121501046)(520075)(3002001); SRVR:HE1PR06MB1484; BCL:0; PCL:0; RULEID:; SRVR:HE1PR06MB1484; X-Forefront-PRVS: 07013D7479 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA2TUIxNDg0OzIzOmRoWHgyOElSeSsvTFJaZER5emRRZjlzL2kz?= =?utf-8?B?OU5BL1ZnWXZ5N3hKWUpjZnV6QS9BRUpwUUM5NGZzRFlOVmhFd0tzT0pUMWxo?= =?utf-8?B?SC9CUXE2ZkJCMU5LUm9URjBGRFM0bzJPYm00TEJHOXBxaElDRFluYjV4WlRp?= =?utf-8?B?NHNwQVFlNGNJeSswc0JyMURCRzR3Uzh0TTgrOThuZk5qYzd5VXRmQ21EZUl6?= =?utf-8?B?blNiaWM3OERvSnplbmZrK3ZSTzRiTUNQOC8yMkxUMzl1YXR6K2IzdlFQUzlB?= =?utf-8?B?aDVIaFZpVktITVlzSHUvTkFtTWdNcjJ4ZjFGeTNMSmhKeXZDY2ZyS2JnaXJx?= =?utf-8?B?NlNZOCs1Ni9hVVdBNW1LNEhRRngwRW1relYyWjdKS3k2aUJGSjJnNUx1Nk1S?= =?utf-8?B?Um43cmRRNVhmTk9kRFllWWJ2ZDFVeHlabVAzZTZvL0VReTlPT1FmaGdBbUFo?= =?utf-8?B?REtjdmI1UHk3NEI5bkxxczlhQ3N0V3JRdi9VQXVtTDdDRFFhd1VwMGFZMUZK?= =?utf-8?B?aEt4cFc5NnNSc0hpUkQvVFlGUXQzNFQ0dHIrdDdOVGtldytQYzNnb2VPSU82?= =?utf-8?B?TnppYktrUGFXb05NOHgySk5XWmRJUHhyMjBjSW95K2FGQnFDWlk1OE5QdWZE?= =?utf-8?B?RStOdGhUNUFpK3ZPZm1XN0YvajRaMDY3V1AxSDl5S0VDUGp2Ri9ibzZRbVFN?= =?utf-8?B?TlZLOGxRM2VvQy92dFhFMkFsTmNzdVEzTkdvWDVmVFVqQWJJZXg2MC9ySy9O?= =?utf-8?B?YmpmUUUzbjB3NkoxSlBZdko3eVozcktRVE5kajZ4cjVUeWtQUUIvYm11VW1y?= =?utf-8?B?dUhDMU1FKzdjWVBmVkZYMjBSTGxnUE9wQk0xVGd5eGx4UjloUXlHTG9xOXpk?= =?utf-8?B?ekp4bFh5clhFbFlyczdCZ2xNNmhaVjRES3BOTWVpL3N0My9wTkdOYi9rTjhW?= =?utf-8?B?d25UaVpUTjdySzQxSVBrUEtEVDBNMnp3RHl5N1lsSi9DOTVVUmxObmNGMHVB?= =?utf-8?B?ckdWU3VNdWdEcStrb0ppc1NpNzlWeU5mWGs1MGlGRHpoVzNjWmZHMk5YSG83?= =?utf-8?B?WUNYek0zTWx5NG5GYzN4KzFwMWxaWVZTbWhTUEZLeUtKcU9RY3pXdGpOeTVV?= =?utf-8?B?N2xTRG5sallQdjVhV3FwOG9VYVdzKzYvWDY2WW1SOERaajNWRUd3cGdLekda?= =?utf-8?B?K2huck5iUkxDLzY0d2w4WENHZE1SUG9Nc0FYWFN6cEJ5VDhkR2ZMcklsMTEv?= =?utf-8?B?Y1VFTk9uSXJMVW4yVHo3VHJsVk40Y09VSzU5eXBqZUpKYXhVNHlDTVhDSXBt?= =?utf-8?B?TytNVklkL0ZyVExlUnJGSmdQd0FIbnd6a3VhU3BtcHJWb2RoWGdCM2I5Y3Uw?= =?utf-8?B?aVd6R1RhZEdoMlYxcUZUaHRuTjlKSndzb2ZLYWpCVTNtdS80Ukhad2p4OG5U?= =?utf-8?B?NTIvdGlNYjd6T3NCM3FVYSt4cWFDMFU1WkJRaVMzMWl3WGkxRU5oLzFJUERi?= =?utf-8?B?N3BDdktnSzZMT1hvU2R1aHNoQVQrbDNNN3R5YnZkUlIvZkI1KzYzaDZia2ly?= =?utf-8?B?Tng4S2J2dldONVNsQWNBeWttMXFqdUNvQVdJSCt4bllBZTFoRFhvUnBZNG9W?= =?utf-8?B?d3NYZkU2SHFGcCtPcElQZVNaNUxSQWRFVkU5TVk5Y1dWcG5SamxLL1ZibXQ1?= =?utf-8?B?c1NYemR0WnJzS25NTjh0OWl4a3J6bGF1RGtrd0xoRnk5Zm9OQlptOStGUW9D?= =?utf-8?B?eU9XMnpDTFlqRUtOS0xOVzFqdE53dnRHVVBWak9QS1Z3d2V3RDR4cis0Mk1L?= =?utf-8?B?VW5MNzhlTDA2UlF3MVAxOEtHc2FEMFMxVkJoZmRjVHNBTWV3SjhjM2hGYk5k?= =?utf-8?B?K2FrOWRoRnAyMVpUaFVCdlhMYmtxVTZrc0ZQclg5UDlXZHVyUzczK2JCVUpo?= =?utf-8?B?Y2YrNFlLb3drb0ZGQi9leHZEU0V2NmVoclRtdWd4WkJFRmdnRlZ0RWpEQ29v?= =?utf-8?B?MWFvSWJGdC9MZGg4Rms4RjVEYk1FSWFzeU50eEVCejBiTVBWS3VDYi9xc3A4?= =?utf-8?Q?BJlNk0XVbqaaW/4g3xEZgu35Y?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR06MB1484; 5:ZGQm8spmH9s2JgH2KwDOZI4YqRgrwwdPTCf1mS2v78amVk05bus+KX44TFu4z1VfeXup6lli1Q3f0WvT6/ukxouEipiCS0QhEe2jZ2lK2QJquzLsubA4rc3Oa0H2JihQnRQfuJpo1GPjb8ib5YMPow==; 24:/OiMt7GWY1RFJPpPGGcUiAJzbG28GSSrTZo2JJmn1sH5W5yymFQgton3NvcpIV/7+wi+/CA5TJ8uLhBqPFxGGmmOqXH0v07y9ggo/QfeGjo=; 20:UGGNRyE75yG10VkeltvgeQM7KmO7vZ4u81TxD0BmKKZWyDGqvGGurDj0kqKuDb+ALcev/ltlvJkp5shiI6+l6w== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2015 13:24:38.8065 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATBRAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR06MB1484 Archived-At: Cc: Core Subject: Re: [core] CoMI support for YANG notification and RPC 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, 16 Sep 2015 13:25:08 -0000 PklmIENvTUkgaXMgZGVlbWVkIGludGVyZXN0aW5nIGZvciBhcHBsaWNhdGlvbiBsZXZlbCBkYXRh IG1hbmlwdWxhdGlvbiwgd2UgbGlrZSB0byBoZWFyIGFib3V0IGl0Lg0KSSBzdGFydGVkIGxvb2tp bmcgaW50byBDb01JIGFzIGFuIGFsdGVybmF0aXZlIHRvIExXTTJNK0lQU08gd2hpY2ggcHJvdmlk ZXMgbWV0aG9kcyBmb3IgYXBwbGljYXRpb24gbGV2ZWwgZGF0YSBtYW5pcHVsYXRpb24gYW5kIGRl dmljZSBtYW5hZ2VtZW50IChpbiBhIHdheSB0aGF0IGNvdWxkIGJlIGV4dGVuZGVkIHRvIGFsc28g ZG8gbmV0d29yayBtYW5hZ2VtZW50KS4gSSBkb27igJl0IHRoaW5rIGl0IGlzIHJlYWxpc3RpYyBl eHBlY3QgYSBjb25zdHJhaW5lZCBkZXZpY2UgdG8gYmUgYm90aCBhbiBMV00yTSBjbGllbnQgYW5k IGEgQ29NSSBzZXJ2ZXIgYW5kIGZyb20gbXkgcG9pbnQgb2YgdmlldyBpdCB3aWxsIGJlIG9uZSBv ciB0aGUgb3RoZXIuIFNvLCBhIHN0YW5kYXJkIHdheSB0aGF0IGFsbG93cyBtZSB0byBkZXBsb3kg bXkgKENvQVAtYmFzZWQpIGFwcGxpY2F0aW9uIG9uIGEgQ29NSSBzZXJ2ZXIgd291bGQgYmUgdmVy eSBpbnRlcmVzdGluZy4gVW5sZXNzIHRoaXMgaGFwcGVucywgSSB3aWxsIHByb2JhYmx5IGVuZCB1 cCB1c2luZyBMV00yTSB0byBkbyBhbHNvIG15IGRldmljZSBtYW5hZ2VtZW50IChPSUMgaXMgYWxz byBub3cgYW4gaW50ZXJlc3RpbmcgYWx0ZXJuYXRpdmUgdGhhdCBkb2VzIGJvdGgpLg0KDQpBYmhp bmF2DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBwZXRlciB2YW4gZGVyIFN0 b2sgW21haWx0bzpzdG9rY29uc0B4czRhbGwubmxdDQpTZW50OiBNaXR0d29jaCwgMTYuIFNlcHRl bWJlciAyMDE1IDE0OjMxDQpUbzogU29tYXJhanUgQWJoaW5hdg0KQ2M6IGNvbnN1bHRhbmN5QHZh bmRlcnN0b2sub3JnOyBDYXJzdGVuIEJvcm1hbm47IENvcmUNClN1YmplY3Q6IFJFOiBbY29yZV0g Q29NSSBzdXBwb3J0IGZvciBZQU5HIG5vdGlmaWNhdGlvbiBhbmQgUlBDDQoNCkhpIEFiaGluYXYs DQoNClRoZSBvcmlnaW5hbCBwdXJwb3NlIG9mIHRoZSBDb01JIGlzIHRoZSBzYW1lIGFzIE5FVENP TkY6DQoNClRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENPTkYpIGRlZmlu ZWQgaW4gdGhpcyBkb2N1bWVudA0KICAgIHByb3ZpZGVzIG1lY2hhbmlzbXMgdG8gaW5zdGFsbCwg bWFuaXB1bGF0ZSwgYW5kIGRlbGV0ZSB0aGUNCiAgICBjb25maWd1cmF0aW9uIG9mIG5ldHdvcmsg ZGV2aWNlcy4NCg0KQW5kIGNvbXBhcmFibGUgdG8gUkVTVENPTkYNClRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIGFuIEhUVFAtYmFzZWQgcHJvdG9jb2wgdGhhdCBwcm92aWRlcyBhDQogICAgcHJvZ3Jh bW1hdGljIGludGVyZmFjZSBmb3IgYWNjZXNzaW5nIGRhdGEgZGVmaW5lZCBpbiBZQU5HLCB1c2lu ZyB0aGUNCiAgICBkYXRhc3RvcmVzIGRlZmluZWQgaW4gTkVUQ09ORi4NCg0KQ29NSSBpcyB0YXJn ZXRlZCB0byBjb25zdHJhaW5lZCBkZXZpY2VzIGFuZCB1c2VzIHByZWZlcmFibHkgQ29BUCBpbnN0 ZWFkIG9mIGh0dHAgKGxlc3MgdmVyYm9zZSkuDQpBbiBlZmZvcnQgaGFzIGJlZW4gbWFkZSB0byBy ZWR1Y2UgdGhlIHBheWxvYWQgc2l6ZSBieSB1c2luZyBoYXNoZXMgZm9yIHRoZSBZQU5HIG5vZGUg bmFtZXMuDQpBbHNvIG5vdCBhbGwgZnVuY3Rpb25hbGl0eSBvZiBSRVNUQ09ORiBoYXMgYmVlbiB0 YWtlbiBvdmVyIHRvIHJlZHVjZSBjb21wbGV4aXR5IG9mIHRoZSBDb01JIGNvZGUuDQoNClRoZSBj b25maWd1cmF0aW9uIG9mIG5ldHdvcmsgZGV2aWNlcyBtYXkgZ28gYmV5b25kIHRoZSBuZXR3b3Jr L3RyYW5zcG9ydCBsYXllciBpZiB0aGlzIGlzIGNvbnZlbmllbnQuDQpJZiBDb01JIGlzIGRlZW1l ZCBpbnRlcmVzdGluZyBmb3IgYXBwbGljYXRpb24gbGV2ZWwgZGF0YSBtYW5pcHVsYXRpb24sIHdl IGxpa2UgdG8gaGVhciBhYm91dCBpdC4NCg0KSW4gdGhhdCBjb250ZXh0LCBkb2luZyB0aGUgZXhl cmNpc2UgdG8gbW9kZWwgY29udHJvbCBhcHBsaWNhdGlvbiBkYXRhIGFuZCBpdHMgbWFuaXB1bGF0 aW9ucyBzZWVtZWQgdG8gaW5kaWNhdGUgdGhhdCBSUENzIGFyZSB1c2VmdWwuDQoNCkdyZWV0aW5n cywNCg0KUGV0ZXINCg0KDQpTb21hcmFqdSBBYmhpbmF2IHNjaHJlZWYgb3AgMjAxNS0wOS0xNiAx Mzo0NzoNCj4gSGkgUGV0ZXIsDQo+IFRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24uDQo+DQo+ PiBXZSB3YW50IHRvIGFkZCBSUEMgc3VwcG9ydCBvbmNlIHRoZXJlIGlzIGEgZ29vZCBtb3RpdmF0 aW9uIHRvIGRvIHNvLg0KPiBJdCBpcyBub3QgZW50aXJlbHkgY2xlYXIgdG8gbWUgZXhhY3RseSB3 aGF0IENvTUkgaXMgdHJ5aW5nIHRvIGFjaGlldmUuDQo+IFRoZSBpbnRyb2R1Y3Rpb24gaW5kaWNh dGVzIHRoYXQgQ29NSSBpcyBhIHJlcGxhY2VtZW50IGZvciBSZXN0Y29uZiBpbg0KPiBjb25zdHJh aW5lZCBlbnZpcm9ubWVudHMgICgiVGhlIFJFU1RDT05GIHByb3RvY29sIGlzIGFkYXB0ZWQgYW5k DQo+IG9wdGltaXplZCBmb3IgdXNlIGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cywgdXNpbmcg Q29BUCBpbnN0ZWFkIG9mDQo+IEhUVFAiKS4gSWYgQ29NSSBpcyBvbmx5IHRyeWluZyB0byBwcm92 aWRlIGEgcmVwbGFjZW1lbnQgZm9yIFJlc2Zjb25mLA0KPiB0aGVuIGlzbuKAmXQgdGhlIGZhY3Qg dGhhdCBSZXN0Y29uZiBzdXBwb3J0cyBSUENzIHN1ZmZpY2llbnQgdG8gcmVxdWlyZQ0KPiBDb01J IHRvIHN1cHBvcnQgUlBDcz8NCj4NCj4gQWx0ZXJuYXRpdmVseSwgdGhlIG9iamVjdGl2ZXMgb24g UC43IGluZGljYXRlIHRoYXQgQ29NSSBjYW4gYmUgdXNlZCB0bw0KPiBtYW5hZ2UgdGhlIG9wZXJh dGlvbmFsL3BlcmZvcm1hbmNlIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgY29uc3RyYWluZWQNCj4g ZGV2aWNlcy4gQnkgb3BlcmF0aW9uYWwvcGVyZm9ybWFuY2UgY2hhcmFjdGVyaXN0aWNzIGRvIHlv dSBvbmx5IG1lYW4NCj4gY2hhcmFjdGVyaXN0aWNzIHJlbGF0ZWQgdG8gdGhlIG5ldHdvcmsgbGF5 ZXIgYW5kIGJlbG93IGluIHRoZSBzdGFjayBvcg0KPiBhbHNvIHRoZSBhcHBsaWNhdGlvbiBsYXll cidzIG9wZXJhdGlvbmFsL3BlcmZvcm1hbmNlIGNoYXJhY3RlcmlzdGljcz8NCj4gSWYgQ29NSSBp cyB0byBiZSB1c2VkIHRvIGFsc28gbWFuYWdlIGFwcGxpY2F0aW9uIGxheWVyIGJlaGF2aW9yIG9m IHRoZQ0KPiBkZXZpY2VzIChlLmcuIGRpc2NvdmVyaW5nIHRoZSB0eXBlIG9mIENvQVAgcmVzb3Vy Y2VzIHN1cHBvcnRlZCBieSB0aGUNCj4gZW5kLXBvaW50cyBhbmQgY29uZmlndXJpbmcgdGhlIGlu dGVyYWN0aW9uIGJldHdlZW4gY29uc3RyYWluZWQgQ29BUA0KPiBjbGllbnRzIGFuZCBzZXJ2ZXJz KSB0aGVuIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gYWxzbyBsb29rIGF0IHRoZQ0KPiBhcHBsaWNh dGlvbiBsYXllciB1c2UgY2FzZXMgdGhhdCBDb01JIGlzIHRyeWluZyB0byBzdXBwb3J0LiBJIGFt DQo+IGd1ZXNzaW5nIHRoYXQgYW5hbHl6aW5nIHRoZXNlIHVzZS1jYXNlcyB3aWxsIG1vdGl2YXRl IHRoZSBuZWVkIHRvDQo+IHN1cHBvcnQgUlBDcy4NCj4NCj4gUmVnYXJkcywNCj4gQWJoaW5hdg0K Pg0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBwZXRlciB2YW4g ZGVyIFN0b2sgW21haWx0bzpzdG9rY29uc0B4czRhbGwubmxdDQo+IFNlbnQ6IE1pdHR3b2NoLCAx Ni4gU2VwdGVtYmVyIDIwMTUgMDk6MzkNCj4gVG86IENhcnN0ZW4gQm9ybWFubg0KPiBDYzogU29t YXJhanUgQWJoaW5hdjsgQ29yZQ0KPiBTdWJqZWN0OiBSZTogW2NvcmVdIENvTUkgc3VwcG9ydCBm b3IgWUFORyBub3RpZmljYXRpb24gYW5kIFJQQw0KPg0KPiBIaSBBYmhpbmF2LA0KPg0KPiBPdGhl ciByZXF1ZXN0IGZvciBSUEMgc3VwcG9ydCBpbiBDb01JIGhhdmUgYmVlbiBleHByZXNzZWQgZWFy bGllciBmcm9tDQo+IHRoZSA2dGlzY2ggd2cuDQo+IFdlIHdhbnQgdG8gYWRkIFJQQyBzdXBwb3J0 IG9uY2UgdGhlcmUgaXMgYSBnb29kIG1vdGl2YXRpb24gdG8gZG8gc28uDQo+DQo+IFRoZSBuZXh0 IGRyYWZ0IHZlcnNpb24gd2lsbCBwcm9iYWJseSBkZXNjcmliZSBSUEMgc3VwcG9ydCB3aXRoIHN1 Y2ggYQ0KPiAoaG9wZWZ1bGx5IGNvbnZpbmNpbmcpIG1vdGl2YXRpb24uDQo+IFdlIGFyZSBsb29r aW5nIGZvcndhcmQgdG8gcmVjZWl2ZSBzdGF0ZW1lbnRzIG9uIHRoZSBuZWNlc3NpdHkgb2YgUlBD DQo+IHRvIHJlaW5mb3JjZSB0aGUgbW90aXZhdGlvbi4NCj4NCj4gR3JlZXRpbmdzLA0KPg0KPiBQ ZXRlcg0KPg0KPiBDYXJzdGVuIEJvcm1hbm4gc2NocmVlZiBvcCAyMDE1LTA5LTE1IDE3OjA3Og0K Pj4gU29tYXJhanUgQWJoaW5hdiB3cm90ZToNCj4+Pg0KPj4+ICAgSG93ZXZlciwgSSBhbSBsb29r aW5nIGZvciBzdXBwb3J0IGZvciBZQU5HIFJQQ3MgYW5kIHNlZSBubyBtZW50aW9uDQo+Pj4gb2YN Cj4+PiAgIFJQQ3MgaW4gdGhlIENvTUkgZHJhZnQuDQo+Pg0KPj4gSGkgQWJoaW5hdiwNCj4+DQo+ PiBJIHRoaW5rIHRoZXkganVzdCBoYXZlbid0IGJlZW4gaW4gdGhlIGZvY3VzIHNvIGZhciwgbWF5 YmUganVzdCBmb3IgYQ0KPj4gbGFjayBvZiBpbWFnaW5hdGlvbiBmb3Igd2hhdCB0aGVzZSBSUENz IHdvdWxkIGJlIHVzZWQgZm9yLg0KPj4NCj4+IENhbiB5b3UgdGVsbCB1cyBhIGJpdCBtb3JlIGFi b3V0IHRoZSB3YXkgeW91IHBsYW4gdG8gdXNlIFlBTkcgUlBDcyBvbg0KPj4gY29uc3RyYWluZWQg ZGV2aWNlcz8NCj4+DQo+PiBHcsO8w59lLCBDYXJzdGVuDQo+Pg0KPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGNvcmUgbWFpbGluZyBsaXN0DQo+ PiBjb3JlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NvcmUNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gVGhlIGNvbnRlbnRzDQo+IG9mIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQNCj4gcmVjaXBpZW50LiBUaGV5IG1h eSBub3QgYmUgZGlzY2xvc2VkIHRvIG9yIHVzZWQgYnkgb3IgY29waWVkIGluIGFueQ0KPiB3YXkg YnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudC4gSWYgdGhpcyBlLW1h aWwgaXMNCj4gcmVjZWl2ZWQgaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoZQ0KPiBlLW1haWwgYW5kIGF0dGFjaGVkIGRvY3VtZW50cy4g UGxlYXNlIG5vdGUgdGhhdCBuZWl0aGVyIHRoZSBzZW5kZXIgbm9yDQo+IHRoZSBzZW5kZXIncyBj b21wYW55IGFjY2VwdCBhbnkgcmVzcG9uc2liaWxpdHkgZm9yIHZpcnVzZXMgYW5kIGl0IGlzDQo+ IHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gc2NhbiBvciBvdGhlcndpc2UgY2hlY2sgdGhpcyBlLW1h aWwgYW5kIGFueQ0KPiBhdHRhY2htZW50cy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fIFRoZSBjb250ZW50cyBvZiB0aGlzIGUtbWFpbCBh bmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkIHJlY2lw aWVudC4gVGhleSBtYXkgbm90IGJlIGRpc2Nsb3NlZCB0byBvciB1c2VkIGJ5IG9yIGNvcGllZCBp biBhbnkgd2F5IGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIElm IHRoaXMgZS1tYWlsIGlzIHJlY2VpdmVkIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgZS1tYWlsIGFuZCBhdHRhY2hlZCBkb2N1bWVu dHMuIFBsZWFzZSBub3RlIHRoYXQgbmVpdGhlciB0aGUgc2VuZGVyIG5vciB0aGUgc2VuZGVyJ3Mg Y29tcGFueSBhY2NlcHQgYW55IHJlc3BvbnNpYmlsaXR5IGZvciB2aXJ1c2VzIGFuZCBpdCBpcyB5 b3VyIHJlc3BvbnNpYmlsaXR5IHRvIHNjYW4gb3Igb3RoZXJ3aXNlIGNoZWNrIHRoaXMgZS1tYWls IGFuZCBhbnkgYXR0YWNobWVudHMuDQo= From nobody Wed Sep 16 23:59: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 57ACD1ACE56 for ; Wed, 16 Sep 2015 23:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 oKE4Rz397crb for ; Wed, 16 Sep 2015 23:59:02 -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 AD3D21ACE50 for ; Wed, 16 Sep 2015 23:59:01 -0700 (PDT) Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 36518C5A40 for ; Thu, 17 Sep 2015 08:58:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter17-d.gandi.net (mfilter17-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id KZr65fzd5z0O for ; Thu, 17 Sep 2015 08:58:56 +0200 (CEST) X-Originating-IP: 193.54.23.146 Received: from Zax.local (unknown [193.54.23.146]) (Authenticated sender: alex@ackl.io) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id D5AC6C5A53 for ; Thu, 17 Sep 2015 08:58:56 +0200 (CEST) To: core@ietf.org References: <0E9A48AB39AF3547ACD28A6DE3E2906A0985F1@ATDOAGMSX02.itiso.net> <55F83427.2040203@tzi.org> <4c46654d17e5bc13207def5888e79cc6@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A098B74@ATDOAGMSX02.itiso.net> <289a977d59d6e4aac41927e249dd5df2@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A098CF9@ATDOAGMSX02.itiso.net> From: Alexander Pelov Message-ID: <55FA64BC.5000206@ackl.io> Date: Thu, 17 Sep 2015 08:59:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A098CF9@ATDOAGMSX02.itiso.net> Content-Type: multipart/alternative; boundary="------------020608050304000902090605" Archived-At: Subject: Re: [core] CoMI support for YANG notification and RPC 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, 17 Sep 2015 06:59:06 -0000 This is a multi-part message in MIME format. --------------020608050304000902090605 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Dear Abhinav, You're mentioning an interesting point. There are indeed several=20 discussions on the future directions of CoMI and the alternative CoOL=20 (the first draft is still in the working, you can look up the ideas in=20 the mailing list). In my opinion, RPC should be included to CoMI (and will be present in=20 CoOL), for the reasons of performance and compatibility with RESTCONF.=20 The perfect examples are the "toggle button" and the "restart button".=20 You could in theory restart a device within a purely RESTfull API, but=20 it would mostly act like RPC (e.g. like putting the device at a=20 run-level 0). Toggling the state of a button requires 2 rounds (GET +=20 PUT), and doing that in an atomic manner makes it way too complex to be=20 reasonable. In the t2t research group there have been some discussions to define=20 what would a RESTfull API look like, at least in the scope of IETF (e.g.=20 CoRE). For me, there was a pretty good consensus that REST covers 95% of=20 the cases and is the way to go. For the remaining 5%, it could be wiser=20 to use RPC-like semantics. The long-term goal would be to define HOW to=20 use RPC in a way consistent with the core REST principles, and in the=20 same time provide enough guidance how to make the distinction of the 95%=20 REST and 5% RPC. The idea that you mention - managing the end-device applications with=20 CoMI/CoOL - is actually pretty interesting. The simplest way to=20 implement this is to add a YANG module, allowing to access the=20 individual applications, something like : module DeviceApplications { container applications { leaf application_id { type int32;} leaf application_uri {type string;} leaf application_module_id {type int32;} leaf application_module_uri {type string;} ... } } This way, you could query the list of installed applications with ease,=20 accessing this application entry point (this is actually quite similar=20 to OneM2M, but in a more generic manner, so I like it better!). After discovering the module ID for your application (which could be=20 YANG hash or CoOL managed module ID), you could query that application=20 module ID, and the sole requirement should be that each application=20 module should have a key "application_id", on which you can select the=20 instance of the application you want to configure. The *application_uri*=20 could simply lead to the entry-point of the resource tree of the=20 application, e.g. you could query: *application_uri/.well-known/core* To sum up, in my opinion your idea is very interesting and is entirely=20 feasible in the context of CoOL (and hopefully CoMI pretty soon). Best, Alexander Le 16/09/2015 15:24, Somaraju Abhinav a =C3=A9crit : >> If CoMI is deemed interesting for application level data manipulation,= we like to hear about it. > I started looking into CoMI as an alternative to LWM2M+IPSO which provi= des methods for application level data manipulation and device management= (in a way that could be extended to also do network management). I don=E2= =80=99t think it is realistic expect a constrained device to be both an L= WM2M client and a CoMI server and from my point of view it will be one or= the other. So, a standard way that allows me to deploy my (CoAP-based) a= pplication on a CoMI server would be very interesting. Unless this happen= s, I will probably end up using LWM2M to do also my device management (OI= C is also now an interesting alternative that does both). > > Abhinav > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Mittwoch, 16. September 2015 14:31 > To: Somaraju Abhinav > Cc: consultancy@vanderstok.org; Carsten Bormann; Core > Subject: RE: [core] CoMI support for YANG notification and RPC > > Hi Abhinav, > > The original purpose of the CoMI is the same as NETCONF: > > The Network Configuration Protocol (NETCONF) defined in this document > provides mechanisms to install, manipulate, and delete the > configuration of network devices. > > And comparable to RESTCONF > This document describes an HTTP-based protocol that provides a > programmatic interface for accessing data defined in YANG, using t= he > datastores defined in NETCONF. > > CoMI is targeted to constrained devices and uses preferably CoAP instea= d of http (less verbose). > An effort has been made to reduce the payload size by using hashes for = the YANG node names. > Also not all functionality of RESTCONF has been taken over to reduce co= mplexity of the CoMI code. > > The configuration of network devices may go beyond the network/transpor= t layer if this is convenient. > If CoMI is deemed interesting for application level data manipulation, = we like to hear about it. > > In that context, doing the exercise to model control application data a= nd its manipulations seemed to indicate that RPCs are useful. > > Greetings, > > Peter > > > Somaraju Abhinav schreef op 2015-09-16 13:47: >> Hi Peter, >> Thanks for the clarification. >> >>> We want to add RPC support once there is a good motivation to do so. >> It is not entirely clear to me exactly what CoMI is trying to achieve. >> The introduction indicates that CoMI is a replacement for Restconf in >> constrained environments ("The RESTCONF protocol is adapted and >> optimized for use in constrained environments, using CoAP instead of >> HTTP"). If CoMI is only trying to provide a replacement for Resfconf, >> then isn=E2=80=99t the fact that Restconf supports RPCs sufficient to = require >> CoMI to support RPCs? >> >> Alternatively, the objectives on P.7 indicate that CoMI can be used to >> manage the operational/performance characteristics of the constrained >> devices. By operational/performance characteristics do you only mean >> characteristics related to the network layer and below in the stack or >> also the application layer's operational/performance characteristics? >> If CoMI is to be used to also manage application layer behavior of the >> devices (e.g. discovering the type of CoAP resources supported by the >> end-points and configuring the interaction between constrained CoAP >> clients and servers) then it would be helpful to also look at the >> application layer use cases that CoMI is trying to support. I am >> guessing that analyzing these use-cases will motivate the need to >> support RPCs. >> >> Regards, >> Abhinav >> >> >> >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Mittwoch, 16. September 2015 09:39 >> To: Carsten Bormann >> Cc: Somaraju Abhinav; Core >> Subject: Re: [core] CoMI support for YANG notification and RPC >> >> Hi Abhinav, >> >> Other request for RPC support in CoMI have been expressed earlier from >> the 6tisch wg. >> We want to add RPC support once there is a good motivation to do so. >> >> The next draft version will probably describe RPC support with such a >> (hopefully convincing) motivation. >> We are looking forward to receive statements on the necessity of RPC >> to reinforce the motivation. >> >> Greetings, >> >> Peter >> >> Carsten Bormann schreef op 2015-09-15 17:07: >>> Somaraju Abhinav wrote: >>>> However, I am looking for support for YANG RPCs and see no mentio= n >>>> of >>>> RPCs in the CoMI draft. >>> Hi Abhinav, >>> >>> I think they just haven't been in the focus so far, maybe just for a >>> lack of imagination for what these RPCs would be used for. >>> >>> Can you tell us a bit more about the way you plan to use YANG RPCs on >>> constrained devices? >>> >>> Gr=C3=BC=C3=9Fe, Carsten >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> ________________________________________________________ The contents >> of this e-mail and any attachments are confidential to the intended >> recipient. They may not be disclosed to or used by or copied in any >> way by anyone other than the intended recipient. If this e-mail is >> received in error, please immediately notify the sender and delete the >> e-mail and attached documents. Please note that neither the sender nor >> the sender's company accept any responsibility for viruses and it is >> your responsibility to scan or otherwise check this e-mail and any >> attachments. > ________________________________________________________ The contents o= f this e-mail and any attachments are confidential to the intended recipi= ent. They may not be disclosed to or used by or copied in any way by anyo= ne other than the intended recipient. If this e-mail is received in error= , please immediately notify the sender and delete the e-mail and attached= documents. Please note that neither the sender nor the sender's company = accept any responsibility for viruses and it is your responsibility to sc= an or otherwise check this e-mail and any attachments. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------020608050304000902090605 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear Abhinav,

You're mentioning an interesting point. There are indeed several discussions on the future directions of CoMI and the alternative CoOL (the first draft is still in the working, you can look up the ideas in the mailing list).

In my opinion, RPC should be included to CoMI (and will be present in CoOL), for the reasons of performance and compatibility with RESTCONF. The perfect examples are the "toggle button" and the "restart button". You could in theory restart a device within a purely RESTfull API, but it would mostly act like RPC (e.g. like putting the device at a run-level 0). Toggling the state of a button requires 2 rounds (GET + PUT), and doing that in an atomic manner makes it way too complex to be reasonable.

In the t2t research group there have been some discussions to define what would a RESTfull API look like, at least in the scope of IETF (e.g. CoRE). For me, there was a pretty good consensus that REST covers 95% of the cases and is the way to go. For the remaining 5%, it could be wiser to use RPC-like semantics. The long-term goal would be to define HOW to use RPC in a way consistent with the core REST principles, and in the same time provide enough guidance how to make the distinction of the 95% REST and 5% RPC.

The idea that you mention - managing the end-device applications with CoMI/CoOL - is actually pretty interesting. The simplest way to implement this is to add a YANG module, allowing to access the individual applications, something like :

module DeviceApplications {
=C2=A0 container applications {
=C2=A0=C2=A0=C2=A0 leaf application_id { type int32;}
=C2=A0=C2=A0=C2=A0 leaf application_uri {type string;}
=C2=A0=C2=A0=C2=A0 leaf application_module_id {type int32;}
=C2=A0=C2=A0=C2=A0 leaf application_module_uri {type string;}
=C2=A0=C2=A0=C2=A0 ...
=C2=A0 }
}

This way, you could query the list of installed applications with ease, accessing this application entry point (this is actually quite similar to OneM2M, but in a more generic manner, so I like it better!).

After discovering the module ID for your application (which could be YANG hash or CoOL managed module ID), you could query that application module ID, and the sole requirement should be that each application module should have a key "application_id", on which you can select the instance of the application you want to configure. The application_uri could simply lead to the entry-point of the resource tree of the application, e.g. you could query: applic= ation_uri/.well-known/core

To sum up, in my opinion your idea is very interesting and is entirely feasible in the context of CoOL (and hopefully CoMI pretty soon).

Best,
Alexander


Le 16/09/2015 15:24, Somaraju Abhinav = a =C3=A9crit=C2=A0:
If CoMI is deemed interesting for application leve=
l data manipulation, we like to hear about it.

I started looking into CoMI as an alternative to LWM=
2M+IPSO which provides methods for application level data manipulation an=
d device management (in a way that could be extended to also do network m=
anagement). I don=E2=80=99t think it is realistic expect a constrained de=
vice to be both an LWM2M client and a CoMI server and from my point of vi=
ew it will be one or the other. So, a standard way that allows me to depl=
oy my (CoAP-based) application on a CoMI server would be very interesting=
. Unless this happens, I will probably end up using LWM2M to do also my d=
evice management (OIC is also now an interesting alternative that does bo=
th).

Abhinav

-----Original Message-----
From: peter van der Stok [mailto:stokcons@xs4all.nl]
Sent: Mittwoch, 16. September 2015 14:31
To: Somaraju Abhinav
Cc: consultancy@vanderstok.org; Carsten Bormann; Core
Subject: RE: [core] CoMI support for YANG notification and RPC

Hi Abhinav,

The original purpose of the CoMI is the same as NETCONF:

The Network Configuration Protocol (NETCONF) defined in this document
    provides mechanisms to install, manipulate, and delete the
    configuration of network devices.

And comparable to RESTCONF
This document describes an HTTP-based protocol that provides a
    programmatic interface for accessing data defined in YANG, using the
    datastores defined in NETCONF.

CoMI is targeted to constrained devices and uses preferably CoAP instead =
of http (less verbose).
An effort has been made to reduce the payload size by using hashes for th=
e YANG node names.
Also not all functionality of RESTCONF has been taken over to reduce comp=
lexity of the CoMI code.

The configuration of network devices may go beyond the network/transport =
layer if this is convenient.
If CoMI is deemed interesting for application level data manipulation, we=
 like to hear about it.

In that context, doing the exercise to model control application data and=
 its manipulations seemed to indicate that RPCs are useful.

Greetings,

Peter


Somaraju Abhinav schreef op 2015-09-16 13:47:

Hi Peter,
Thanks for the clarification.


We want to add RPC support once there is a good =
motivation to do so.

It is not entirely clear to me exactly what CoMI i=
s trying to achieve.
The introduction indicates that CoMI is a replacement for Restconf in
constrained environments  ("The RESTCONF protocol is adapted and
optimized for use in constrained environments, using CoAP instead of
HTTP"). If CoMI is only trying to provide a replacement for Resfconf,
then isn=E2=80=99t the fact that Restconf supports RPCs sufficient to req=
uire
CoMI to support RPCs?

Alternatively, the objectives on P.7 indicate that CoMI can be used to
manage the operational/performance characteristics of the constrained
devices. By operational/performance characteristics do you only mean
characteristics related to the network layer and below in the stack or
also the application layer's operational/performance characteristics?
If CoMI is to be used to also manage application layer behavior of the
devices (e.g. discovering the type of CoAP resources supported by the
end-points and configuring the interaction between constrained CoAP
clients and servers) then it would be helpful to also look at the
application layer use cases that CoMI is trying to support. I am
guessing that analyzing these use-cases will motivate the need to
support RPCs.

Regards,
Abhinav



-----Original Message-----
From: peter van der Stok [mailto:stokcons@xs4all.nl]
Sent: Mittwoch, 16. September 2015 09:39
To: Carsten Bormann
Cc: Somaraju Abhinav; Core
Subject: Re: [core] CoMI support for YANG notification and RPC

Hi Abhinav,

Other request for RPC support in CoMI have been expressed earlier from
the 6tisch wg.
We want to add RPC support once there is a good motivation to do so.

The next draft version will probably describe RPC support with such a
(hopefully convincing) motivation.
We are looking forward to receive statements on the necessity of RPC
to reinforce the motivation.

Greetings,

Peter

Carsten Bormann schreef op 2015-09-15 17:07:

Somaraju Abhinav wrote:

  However, I am looking for support for YANG RPCs and see no mention
of
  RPCs in the CoMI draft.

Hi Abhinav,

I think they just haven't been in the focus so far, maybe just for a
lack of imagination for what these RPCs would be used for.

Can you tell us a bit more about the way you plan to use YANG RPCs on
constrained devices?

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

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

__________________________________________________=
______ The contents
of this e-mail and any attachments are confidential to the intended
recipient. They may not be disclosed to or used by or copied in any
way by anyone other than the intended recipient. If this e-mail is
received in error, please immediately notify the sender and delete the
e-mail and attached documents. Please note that neither the sender nor
the sender's company accept any responsibility for viruses and it is
your responsibility to scan or otherwise check this e-mail and any
attachments.

____________________________________________________=
____ The contents of this e-mail and any attachments are confidential to =
the intended recipient. They may not be disclosed to or used by or copied=
 in any way by anyone other than the intended recipient. If this e-mail i=
s received in error, please immediately notify the sender and delete the =
e-mail and attached documents. Please note that neither the sender nor th=
e sender's company accept any responsibility for viruses and it is your r=
esponsibility to scan or otherwise check this e-mail and any attachments.
_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core

--------------020608050304000902090605-- From nobody Thu Sep 17 02:34: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 213571B2AA2; Thu, 17 Sep 2015 02:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 HCAl082t4zA8; Thu, 17 Sep 2015 02:34:39 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7891B2BBD; Thu, 17 Sep 2015 02:34:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DKAQChh/pV/wQXEqxeg3RpvUIBDYFvAQuFdwKBeBQBAQEBAQEBgQqEIwEBAQQBAQEaUQsQCwcGAQMDAQIoBycfCQgGCwgJEoggtRkBAQGVOwEBAQEBAQEBAQEBAQEBAQEBAQEZhUhqhT6EKhEBDDQNBAeCLk0dgRQFjHw5O4dxhRGJQYQ2gyGRdB8BAYJTHIFcaQGIaoE/AQEB X-IPAS-Result: A2DKAQChh/pV/wQXEqxeg3RpvUIBDYFvAQuFdwKBeBQBAQEBAQEBgQqEIwEBAQQBAQEaUQsQCwcGAQMDAQIoBycfCQgGCwgJEoggtRkBAQGVOwEBAQEBAQEBAQEBAQEBAQEBAQEZhUhqhT6EKhEBDDQNBAeCLk0dgRQFjHw5O4dxhRGJQYQ2gyGRdB8BAYJTHIFcaQGIaoE/AQEB X-IronPort-AV: E=Sophos;i="5.17,545,1437417000"; d="scan'208";a="7592254" In-Reply-To: <55F83752.3090609@tzi.org> References: <55F83752.3090609@tzi.org> To: Carsten Bormann MIME-Version: 1.0 X-KeepSent: A9726B8D:58AF98FE-65257EC3:00320D4E; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Thu, 17 Sep 2015 15:04:26 +0530 X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4|June 07, 2015) at 09/17/2015 15:04:27, Serialize complete at 09/17/2015 15:04:27 Content-Type: multipart/alternative; boundary="=_alternative 0034974365257EC3_=" Archived-At: Cc: core , "core@ietf.org WG" Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07 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, 17 Sep 2015 09:34:42 -0000 This is a multipart message in MIME format. --=_alternative 0034974365257EC3_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I think this draft is indeed an appreciable effort as it will ease out = many implementation decisions for the developers and should be very useful = as an RFC. Dear authors, I have one small comment : Given that No-Response now has a number (284) from IANA in the CoRE option = registry ( http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#optio= n-numbers ) probably it will be a good idea to keep a section to discuss how to = handle this option since this is not there in HTTP. Somewhere in Section 8 = should be a good place for such discussion. = Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ From: Carsten Bormann To: "core@ietf.org WG" Date: 09/15/2015 08:51 PM Subject: [core] WG last-call (WGLC) of = draft-ietf-core-http-mapping-07 Sent by: "core" In Prague, we said we were going to WGLC the HTTP mapping draft after close of the vacation period, which is now behind us. All outstanding tickets are closed, and there was enough time to review the current draft. Three people raised their hands when we asked who would submit reviews (Michael K., Klaus, Darshak), but of course additional reviews beyond that are also very useful. So this starts a working group last call for draft-ietf-core-http-mapping for submission as an informational RFC, ending on 24:00 PDT on Tuesday, September 29, 2015. The draft is located at: https://tools.ietf.org/html/draft-ietf-core-http-mapping-07 Please start a new email thread for each major issue that will need discussion and make sure the subject line includes the draft name and some sort of name for the issue. For minor issues such as typos and things that are not likely to lead to much discussion, it is probably easier to group them all in to one email but again, please make sure the subject line includes the draft name. If you read the draft and think it looks fine, please send a one line email to the list or to the chairs letting us know that so we can get a feel of how broad the review has been. In the unlikely event that you are aware of any patent claims that might apply to systems that implement the suggestions in this draft, please review BCP 78 and BCP 79 and make any appropriate IPR declaration. If you are not sure whether you need to make a declaration or not, please talk to the chairs and we will help get you in touch with people that can provide appropriate advice. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 0034974365257EC3_= MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all,
I think this draft is indeed an appr= eciable effort as it will ease out many implementation decisions for the developers and should be very useful as an RFC.

Dear authors,
I have one small comment :
Given that No-Response now has a num= ber (284) from IANA in the CoRE option registry (<= font size=3D2 color=3Dblue face=3D"sans-serif">http://www.iana.org/assignme= nts/core-parameters/core-parameters.xhtml#option-numbers) probably it will be a good idea to keep a section to discuss how to handle this option since this is not there in HTTP. Somewhere in Section 8 should be a good place for such discussion.



Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________



From:     =    Carsten Bormann <cabo@tz= i.org>
To:     &n= bsp;  "core@ietf.org WG" <core@ietf.org>
Date:     =    09/15/2015 08:51 PM
Subject:   &nbs= p;    [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
Sent by:   &nbs= p;    "core" <core-bounces@ietf.org>



In Prague, we said we were going to WGLC the HTTP mapping draft after
close of the vacation period, which is now behind us.  All outstanding=
tickets are closed, and there was enough time to review the current
draft.  Three people raised their hands when we asked who would submit=
reviews (Michael K., Klaus, Darshak), but of course additional reviews
beyond that are also very useful.

So this starts a working group last call for
draft-ietf-core-http-mapping for submission as an informational RFC,
ending on

 24:00 PDT on Tuesday, September 29, 2015.

The draft is located at:
https://tools.ietf.org/html/draft-ietf-core-htt= p-mapping-07

Please start a new email thread for each major issue that will need
discussion and make sure the subject line includes the draft name and
some sort of name for the issue. For minor issues such as typos and
things that are not likely to lead to much discussion, it is probably
easier to group them all in to one email but again, please make sure
the subject line includes the draft name. If you read the draft and
think it looks fine, please send a one line email to the list or to
the chairs letting us know that so we can get a feel of how broad the
review has been.

In the unlikely event that you are aware of any patent claims that
might apply to systems that implement the suggestions in this draft,
please review BCP 78 and BCP 79 and make any appropriate IPR
declaration. If you are not sure whether you need to make a
declaration or not, please talk to the chairs and we will help get you
in touch with people that can provide appropriate advice.

Gr=FC=DFe, Carsten

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

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 0034974365257EC3_=-- From nobody Thu Sep 17 03:10: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 A3C9F1B2C8F for ; Thu, 17 Sep 2015 03:10:18 -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 EmjSNZ0OerRI for ; Thu, 17 Sep 2015 03:10:14 -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 620F51B2C28 for ; Thu, 17 Sep 2015 03:10:14 -0700 (PDT) Received: from mfilter13-d.gandi.net (mfilter13-d.gandi.net [217.70.178.141]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id E9D53A80EE for ; Thu, 17 Sep 2015 12:10:11 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter13-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter13-d.gandi.net (mfilter13-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id vnI2-LSNMyNJ for ; Thu, 17 Sep 2015 12:10:10 +0200 (CEST) X-Originating-IP: 193.54.23.146 Received: from Zax.local (unknown [193.54.23.146]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 27CC2A80D0 for ; Thu, 17 Sep 2015 12:10:09 +0200 (CEST) To: core@ietf.org References: <55F2EB1A.5060409@gmx.net> <55F7D385.1060908@gmx.net> <20150915093750.GB69570@elstar.local> <55F7EC47.8090803@gmx.net> From: Alexander Pelov Message-ID: <55FA918D.6090708@ackl.io> Date: Thu, 17 Sep 2015 12:10:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F7EC47.8090803@gmx.net> Content-Type: multipart/alternative; boundary="------------020409080005090507060706" Archived-At: Subject: Re: [core] 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: Thu, 17 Sep 2015 10:10:18 -0000 This is a multi-part message in MIME format. --------------020409080005090507060706 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Dear Hannes, I like the management interface being defined on a specific protocol -=20 namely CoAP. Otherwise, we only add layers of interpretation and=20 syntactic translations (as done in OneM2M), which could be: 1) straightforward (and thus useless - instead, write in CoAP directly) 2) not straightforward (which adds a burden to implementers. Instead -=20 use CoAP as the base language, and add mapping to MQTT (for example). I tend to agree with you that we should consider decoupling CoAP from=20 the underlaying transport protocol (which I think comes for free). The=20 rationale would be that we could have CoAP running on top of L2, TCP or=20 other, e.g. in a 6TiSCH or LR-WAN / LPWA network: https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00 https://tools.ietf.org/html/draft-pelov-core-cosol-00 So, I'd be in favor of keeping CoAP as the common language for=20 expressing CoMI, but maybe keep explicit UDP bindings off the draft, and=20 maybe provide them as examples (unless there are some specific needs). I=20 have no strong opinion on this, however. Best, Alexander Le 15/09/2015 12:00, Hannes Tschofenig a =E9crit : > Hi Juergen, > > thanks for the feedback. > > > On 09/15/2015 11:37 AM, Juergen Schoenwaelder wrote: >> On Tue, Sep 15, 2015 at 10:15:01AM +0200, Hannes Tschofenig wrote: >>>> Why can't they use RESTCONF then? >>>> The CORE WG should focus on CoAP. >>>> The more options, the more complex it gets, not easier. >>> It is of course a question about what the folks in the CORE working >>> group believe they will be using in their deployments. We hear a lot = of >>> folks asking for protocols other than CoAP over UDP. It is hard to sa= y >>> whether they are only interested to hear whether that's is possible o= r >>> whether they are really interested to deploy HTP2 or QUIC. Hard to sa= y >>> at this point in time but I believe the COMI specification by its nat= ure >>> does not need to be strongly tied to CoAP (which Carsten seems to >>> confirm in his email response). >>> >>> Regarding RESTCONF: Based on your response below it appears that >>> RESTCONF by itself is very wasteful and not very useful for an IoT >>> deployment. >>> >> Most RESTCONF implementations likely use JSON encoding of the payload >> but this is actually not hardwired and it should be possible to use >> something more space efficient if needed (the IETF started to like >> CBOR, I am not sure whether the industry will pick it up or whether >> other binary encodings will be used). The only part where RESTCONF is >> kind of verbose is the way objects are named, using relatively long >> URLs. Finding ways to reduce the URL verbosity has been driving much >> of the CoMI discussions as far as I can tell. >> >> Whether CoAP is going to rule the IoT world or HTTP/2 or ... is >> difficult to answer but I bet that the CORE working group has a >> certain perhaps biased opinion here. ;-) >> > I am new to this network management and so I have to trust what others > tell me. From your description it almost sounds like RESTCONF is not a > big problem either. > > Did you or someone else did a performance analysis? > > It is hard to see whether some of these design will positively impact > deployment but my feeling is that we should offer flexibility where it > does not cost much. In the area of the underlying protocol it looks lik= e > we have a low-hanging fruit. > >>>> Not yet. >>>> Since YANG is modular the vendor has lots of freedom to deploy >>>> functionality where it is needed. >>> I have to admit I don't fully understand YANG. I have read through OM= A >>> LWM2M and compare it against that spec. OMA LWM2M is much easier to >>> understand since it has a simple object structure. >> With YANG getting more widely adapted, we might see the same discussio= n >> that we see on the protocol side - use something more mainstream that = is >> not optimal for IoT devices but perhaps good enough or use something >> tailored for IoT devices but not used widely outside this specific con= text. > That's the reason why I look into it. > > Ciao > Hannes >> /js >> > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------020409080005090507060706 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Hannes,

I like the management interface being defined on a specific protocol - namely CoAP. Otherwise, we only add layers of interpretation and syntactic translations (as done in OneM2M), which could be:
1) straightforward (and thus useless - instead, write in CoAP directly)
2) not straightforward (which adds a burden to implementers. Instead - use CoAP as the base language, and add mapping to MQTT (for example).

I tend to agree with you that we should consider decoupling CoAP from the underlaying transport protocol (which I think comes for free). The rationale would be that we could have CoAP running on top of L2, TCP or other, e.g. in a 6TiSCH or LR-WAN / LPWA network:
https://tools.ietf.org/html/draft-wan= g-6tisch-6top-coapie-00
https://tools.ietf.org/html/draft-pelov-core= -cosol-00

So, I'd be in favor of keeping CoAP as the common language for expressing CoMI, but maybe keep explicit UDP bindings off the draft, and maybe provide them as examples (unless there are some specific needs). I have no strong opinion on this, however.

Best,
Alexander


Le 15/09/2015 12:00, Hannes Tschofenig a =E9crit=A0:
Hi Juergen,

thanks for the feedback.


On 09/15/2015 11:37 AM, Juergen Schoenwaelder wrote:

On Tue, Sep 15, 2015 at 10:15:01AM +0200, Hannes T=
schofenig wrote:

Why can't they use RESTCONF then?
The CORE WG should focus on CoAP.
The more options, the more complex it gets, not easier.

It is of course a question about what the folks in the CORE working
group believe they will be using in their deployments. We hear a lot of
folks asking for protocols other than CoAP over UDP. It is hard to say
whether they are only interested to hear whether that's is possible or
whether they are really interested to deploy HTP2 or QUIC. Hard to say
at this point in time but I believe the COMI specification by its nature
does not need to be strongly tied to CoAP (which Carsten seems to
confirm in his email response).

Regarding RESTCONF: Based on your response below it appears that
RESTCONF by itself is very wasteful and not very useful for an IoT
deployment.


Most RESTCONF implementations likely use JSON encoding of the payload
but this is actually not hardwired and it should be possible to use
something more space efficient if needed (the IETF started to like
CBOR, I am not sure whether the industry will pick it up or whether
other binary encodings will be used). The only part where RESTCONF is
kind of verbose is the way objects are named, using relatively long
URLs. Finding ways to reduce the URL verbosity has been driving much
of the CoMI discussions as far as I can tell.

Whether CoAP is going to rule the IoT world or HTTP/2 or ... is
difficult to answer but I bet that the CORE working group has a
certain perhaps biased opinion here. ;-)


I am new to this network management and so I have to trust what others
tell me. From your description it almost sounds like RESTCONF is not a
big problem either.

Did you or someone else did a performance analysis?

It is hard to see whether some of these design will positively impact
deployment but my feeling is that we should offer flexibility where it
does not cost much. In the area of the underlying protocol it looks like
we have a low-hanging fruit.


Not yet.
Since YANG is modular the vendor has lots of freedom to deploy
functionality where it is needed.

I have to admit I don't fully understand YANG. I have read through OMA
LWM2M and compare it against that spec. OMA LWM2M is much easier to
understand since it has a simple object structure.

With YANG getting more widely adapted, we might see the same discussion
that we see on the protocol side - use something more mainstream that is
not optimal for IoT devices but perhaps good enough or use something
tailored for IoT devices but not used widely outside this specific contex=
t.

That's the reason why I look into it.

Ciao
Hannes

/js



      

      

      

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


    

    

  


--------------020409080005090507060706--


From nobody Thu Sep 17 09:37: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 EBF5D1A0378 for ; Thu, 17 Sep 2015 09:37:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.512
X-Spam-Level: 
X-Spam-Status: No, score=0.512 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] 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 KMMq1VjG1Ql0 for ; Thu, 17 Sep 2015 09:36:59 -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 9ACEC1A87B8 for ; Thu, 17 Sep 2015 09:36:55 -0700 (PDT)
X-ASG-Debug-ID: 1442507813-06daaa5a7526b80001-aa7cYp
Received: from NISSONITE.InterDigital.com (nissonite.interdigital.com [10.2.64.252]) by smtp-in1.interdigital.com with ESMTP id TaFuklEjc0hamQ95 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Sep 2015 12:36:53 -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.0248.002; Thu, 17 Sep 2015 12:36:52 -0400
From: "Rahman, Akbar" 
To: "consultancy@vanderstok.org" 
Thread-Topic: [core] pubsub and sleepy node proxy
X-ASG-Orig-Subj: RE: [core] pubsub and sleepy node proxy
Thread-Index: AQHQ47uC+G7xgzFvBUWihAonddpx2Z4qPB1ggAoRWACADK6HgA==
Date: Thu, 17 Sep 2015 16:36:50 +0000
Message-ID: <36F5869FE31AB24485E5E3222C288E1F347B91BC@NABESITE.InterDigital.com>
References: <25093c7d75ade3f78e471b55816d0bac@xs4all.nl> <36F5869FE31AB24485E5E3222C288E1F347AFBF4@NABESITE.InterDigital.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.2.86]
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: 1442507813
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.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22636 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO    Envelope rcpt doesn't match header
Archived-At: 
Cc: Michael Koster , Core 
Subject: Re: [core] pubsub and sleepy node proxy
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, 17 Sep 2015 16:37:01 -0000

Hi Peter,

I'm sorry for the delayed response.  Somehow I missed this in my Inbox and =
only noticed it when I was going over the reflector mailing list records.  =
My specific suggestions are:

- Yes, it will be good to give more design motivation in your draft.

- Eliminate the tight dependence to 6LoWPAN technology as it is a CoAP appl=
ication protocol and can be run on any underlying IP network.  I'm not sure=
 if your main motivation for the 6LoWPAN link was due to your L2 security a=
ssumptions in Section 9.  But it seems like an artificially restrictive dep=
endence.

- The link to the PubSub server (section 7) looks tenuous and not that conv=
incing to me.

- Editorial - The arrows between the Proxy and Sleepy Node are all 1 direct=
ional in Figure 1.  But I understood from the text that, for example, WRITE=
, should be a bi-directional between Proxy and Sleepy Node (i.e. a WRITE fr=
om a Configuring node to the Proxy node should ultimately result in a WRITE=
 to the sleepy node from the Proxy).  Did I understand correctly?


Thanks for the good work.


Akbar


-----Original Message-----
From: peter van der Stok [mailto:stokcons@xs4all.nl]
Sent: Wednesday, September 09, 2015 6:19 AM
To: Rahman, Akbar 
Cc: consultancy@vanderstok.org; Michael Koster ; Co=
re 
Subject: RE: [core] pubsub and sleepy node proxy

Hi Akbar,

After reading the arkko-core-sleepy draft I do have some concrete questions=
 for you:

Do you want the following additions to the proxy:
- a http endpoint
- storage of historical values
- numbering of messages by sleepy node to estimate the reliability and to o=
rder them
- Use of NON messages from sleepy to proxy

In the arkko draft there is considerable motivation of design choices.
Do you want more design motivation in the our zotti-core-sleepy draft?

Is there anything specific I did not pick up?

Thanks for your reaction,

Peter

Rahman, Akbar schreef op 2015-09-03 06:45:
> Hi Peter,
>
>
> I am still reading the pubsub draft, but did want to give support for
> your sleepy node draft (draft-zotti-core-sleepy-nodes-03).  The sleepy
> node proxy concept that you describe will be useful in many scenarios.
>  One related comment that I did have on your draft is that it seems a
> bit fixated on the 6LoWPAN scenario.  But as we have discussed many
> times during IETF meetings and on various mailing lists, the sleepy
> node scenario is useful beyond 6LoWPAN deployments (e.g.
> https://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01 ).
> So I think it would be useful if you clarified that in your draft.
>
>
> Best Regards,
>
>
> Akbar
>
> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der
> Stok
> Sent: Monday, August 31, 2015 3:06 AM
> To: Michael Koster ; Core 
> Subject: [core] pubsub and sleepy node proxy
>
> Hi Michael,
>
> Looking at the pubsub draft and at our sleepy node proxy draft, I come
> to the conclusion that there are good arguments to maintain both.
>
> Following the reasoning of Matthieu Vial, there are already a good
> arguments for the sleepy node (SN) proxy (aka mirror server) to exist
> next to the RD.
> Namely:
> Where an end-point can delegate its links to the RD for discovery, an
> end-point can delegate the links AND the associated resource values to
> the SN-proxy.
> The SN-proxy resources have the same lifetime as SN resources.
> The SN-proxy resource values are directly linked to the resources of a
> given SN.
>
> In contrast the pubsub handles anonymous values. The origin can be
> added but that means adding attributes to the topics.
> The pubsub handles the more abstract topics, where the SN-proxy is
> concerned with the resources.
> The lifetime of the values in the pubsub server is not directly linked
> to the lifetime of the originating resources.
>
> For me these are the arguments that motivate the existence of the
> pubsub draft next to the sleepy node draft.
>
> Looking forward to your reaction.
>
> Greetings
> Teresa and Peter
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From nobody Sun Sep 20 07:16: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 1FF451B4FE7 for ; Sun, 20 Sep 2015 07:16:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.16
X-Spam-Level: 
X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 OEiJEu1-ORuQ for ; Sun, 20 Sep 2015 07:16:29 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954051B4FE6 for ; Sun, 20 Sep 2015 07:16:29 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DFC0815D6; Sun, 20 Sep 2015 16:16:27 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id RVvnnwaEnCna; Sun, 20 Sep 2015 16:16:26 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 20 Sep 2015 16:16:26 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43F7C20048; Sun, 20 Sep 2015 16:16:26 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7I7SwcSbbApH; Sun, 20 Sep 2015 16:16:24 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 385D52004E; Sun, 20 Sep 2015 16:16:24 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E65C5372620B; Sun, 20 Sep 2015 16:16:22 +0200 (CEST)
Date: Sun, 20 Sep 2015 16:16:22 +0200
From: Juergen Schoenwaelder 
To: Hannes Tschofenig 
Message-ID: <20150920141621.GA9216@elstar.local>
Mail-Followup-To: Hannes Tschofenig , Andy Bierman , "core@ietf.org WG" 
References: <55F2EB1A.5060409@gmx.net>  <55F7D385.1060908@gmx.net> <20150915093750.GB69570@elstar.local> <55F7EC47.8090803@gmx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55F7EC47.8090803@gmx.net>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "core@ietf.org WG" 
Subject: Re: [core] COMI
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Sep 2015 14:16:32 -0000

On Tue, Sep 15, 2015 at 12:00:39PM +0200, Hannes Tschofenig wrote:
> > 
> > Whether CoAP is going to rule the IoT world or HTTP/2 or ... is
> > difficult to answer but I bet that the CORE working group has a
> > certain perhaps biased opinion here. ;-)
> > 
> 
> I am new to this network management and so I have to trust what others
> tell me. From your description it almost sounds like RESTCONF is not a
> big problem either.
> 
> Did you or someone else did a performance analysis?

Well, we have implemented SNMP including SNMPv3 security on small
devices and bits and pieces of NETCONF and so we understand the issues
with that as a baseline. We once looked at CoAP implementations and we
were surprised that there was room for optimization. But the real
challenge here is to agree on the target device and the target link
layer and the security services provided.

On really small devices, in terms of code size, as long as you do
security in software, our experience is that the security code eats
the largest portion of memory. Data encoding surely matters as well,
SNMP's BER encoding is reasonably compact and fast to process,
NETCONF's XML encoding was a pain on our devices (since we had to go
through flash memory to handle larger message size). The question
question is also whether you have a link layer like 802.15.4 where you
like to avoid sending larger IPv6 packets or you happen to enjoy a
link layer that is not as picky about frame sizes. CoMI uses CBOR
(which is close to BER) so this should be good. The compression of
paths is important if we have to consider links such as 802.15.4 and
we need to be able do meaningful work with tiny frames. If that is
less an issue, RESTCONF with CBOR might be a reasonable choice as
well. But we have not implemented these.

So bottom line: For a real comparison, we need to agree on the
hardware capabilities, whether crypto has to be done in software,
whether it is important to optimize for constrained link layers like
good old 802.15.4 with 127 octet frames.

Some people may argue that devices that need (explicit) management
likely can afford links that are 'better' than 802.15.4 and
microcontroller that are 'better' than C0-C2 while others argue that
spending the engineering time to make something work well with very
constrained links and devices will eventually pay off due to the large
quantities in which IoT devices will appear. While I do have an
opinion, I surely do not have an answer. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Sep 21 01:19: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 6EE8B1A8969 for ; Mon, 21 Sep 2015 01:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.449
X-Spam-Level: 
X-Spam-Status: No, score=0.449 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, 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 DEXY2LVllcja for ; Mon, 21 Sep 2015 01:19:36 -0700 (PDT)
Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3960A1A8940 for ; Mon, 21 Sep 2015 01:19:36 -0700 (PDT)
Received: from webmail.xs4all.nl ([194.109.20.204]) by smtp-cloud3.xs4all.net with ESMTP id KkKZ1r00E4QBLo201kKZ7K; Mon, 21 Sep 2015 10:19:34 +0200
Received: from AMontpellier-654-1-72-200.w90-0.abo.wanadoo.fr ([90.0.47.200]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 21 Sep 2015 10:19:33 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 21 Sep 2015 10:19:33 +0200
From: peter van der Stok 
To: Pthubert , Core 
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
Message-ID: 
X-Sender: stokcons@xs4all.nl (d6CUrwhRG7oKZ495fOjExNb5jjekmPyp)
User-Agent: XS4ALL Webmail
Archived-At: 
Subject: [core] draft-thubert-6lo-routing-dispatch-06
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, 21 Sep 2015 08:19:38 -0000

Hi Pascal,

I read your draft, and was pleased to see that I seem to understand much 
better what is going on.

However, I got confused by your use of dispatch.
In RFC 4944, dispatch represents the last 6 bits of the dispatch header.
In the routing-dispatch draft, dispatch seems to refer to whole dispatch 
header (pattern).
Is that correct, or do I miss something? Or am I nit-picking the 
obvious?


In addition, the note just before section 3.1 did not help me much.

Other NIT:
end of page 3: 19 bits -> 19 bytes

Greetings,

Peter

-- 
Peter van der Stok
mailto: consultancy@vanderstok.org
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248


From nobody Mon Sep 21 05:59: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 1AA4E1B3174 for ; Mon, 21 Sep 2015 05:59:07 -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 VfUzaKPEleV6 for ; Mon, 21 Sep 2015 05:59:05 -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 52A051B3172 for ; Mon, 21 Sep 2015 05:59: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 [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t8LCwsGI005832; Mon, 21 Sep 2015 14:58:54 +0200 (CEST)
Received: from alma.local (p5DCCDB06.dip0.t-ipconnect.de [93.204.219.6]) (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 3nKQnV2CXWz2Rjc; Mon, 21 Sep 2015 14:58:54 +0200 (CEST)
Message-ID: <55FFFF0C.9070709@tzi.org>
Date: Mon, 21 Sep 2015 14:58:52 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.4 (Macintosh/20150825)
MIME-Version: 1.0
To: consultancy@vanderstok.org
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 
Subject: Re: [core] draft-thubert-6lo-routing-dispatch-06
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, 21 Sep 2015 12:59:07 -0000

peter van der Stok wrote:
> In RFC 4944, dispatch represents the last 6 bits of the dispatch header.
> In the routing-dispatch draft, dispatch seems to refer to whole dispatch
> header (pattern).
> Is that correct, or do I miss something? Or am I nit-picking the obvious?

There is even more confusion:

Figure 1 has it as a six-bit subfield of that first byte.
In Figure 2, it is quite obvious that dispatch is the entire first byte.
A comment at the end of page 9 seems to indicate, that dispatch can have
values no larger than 127, so that would make it seven bits.

I think it is less important how RFC 4944 used the term than how we have
been using it since.  Almost all documentation that I'm aware of talks
about the dispatch byte as the first byte of the IEEE 802.15.4 payload,
including the 6LoWPAN book.  RFC 6282 is quite explicit about that
"dispatch octet" (while still using "octet" for byte).

Gr眉脽e, Carsten


From nobody Mon Sep 21 06:56: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 84B091B31FE for ; Mon, 21 Sep 2015 06:56:02 -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 tgVLjY4CJVTr for ; Mon, 21 Sep 2015 06:56:00 -0700 (PDT)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::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 7D4131B3200 for ; Mon, 21 Sep 2015 06:56:00 -0700 (PDT)
Received: by lbpo4 with SMTP id o4so51491260lbp.2 for ; Mon, 21 Sep 2015 06:55:58 -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=3iPzA+ewbIoR0DShJDGFSozUr0ON8BWAb0Z++xnLpA4=; b=afShER/Dm5Nbap8R+6jmh08m4B/G/MRUpeyULo1UaRE7bXkxN57hAyhHEVnkI8zMw4 sEmmHEGq71SwmxggC4Piw29IQhc+O91h3NVY7+YxNCSJWR0ttST9XAjx8DLNgjHLpG0h WnkPOm9tk0mztg5/hn9xm8cUJ1ErTMnTgtM0AziAZN9cVUHs0IjXB9maNsLEqyCjHXN7 +Q1zdrUH5dCJpgedG5adq5fOIWXOp25EJuNF02v9cZHvhz8D6z0l77GPbA3k/yqbPpno 7S3C7Rzwm9mA57/3AmUy8BF65YNKpRtmU62vAXAmQ+QTW2MwP5IYOxjhCd0wDp2F7b7+ XXdw==
MIME-Version: 1.0
X-Received: by 10.152.178.194 with SMTP id da2mr7719253lac.77.1442843758516; Mon, 21 Sep 2015 06:55:58 -0700 (PDT)
Sender: robert.cragie@gmail.com
Received: by 10.25.209.146 with HTTP; Mon, 21 Sep 2015 06:55:58 -0700 (PDT)
In-Reply-To: <55FFFF0C.9070709@tzi.org>
References:  <55FFFF0C.9070709@tzi.org>
Date: Mon, 21 Sep 2015 14:55:58 +0100
X-Google-Sender-Auth: 8ZsB05eptSx--4hdJc_00w7GetY
Message-ID: 
From: Robert Cragie 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=001a11341a34b15f180520423d0e
Archived-At: 
Cc: Core 
Subject: Re: [core] draft-thubert-6lo-routing-dispatch-06
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, 21 Sep 2015 13:56:02 -0000

--001a11341a34b15f180520423d0e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1. I think we just have to accept the definition in RFC4944 has
inconsistencies and we should consider it always as a byte,

Robert

On 21 September 2015 at 13:58, Carsten Bormann  wrote:

> peter van der Stok wrote:
> > In RFC 4944, dispatch represents the last 6 bits of the dispatch header=
.
> > In the routing-dispatch draft, dispatch seems to refer to whole dispatc=
h
> > header (pattern).
> > Is that correct, or do I miss something? Or am I nit-picking the obviou=
s?
>
> There is even more confusion:
>
> Figure 1 has it as a six-bit subfield of that first byte.
> In Figure 2, it is quite obvious that dispatch is the entire first byte.
> A comment at the end of page 9 seems to indicate, that dispatch can have
> values no larger than 127, so that would make it seven bits.
>
> I think it is less important how RFC 4944 used the term than how we have
> been using it since.  Almost all documentation that I'm aware of talks
> about the dispatch byte as the first byte of the IEEE 802.15.4 payload,
> including the 6LoWPAN book.  RFC 6282 is quite explicit about that
> "dispatch octet" (while still using "octet" for byte).
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

--001a11341a34b15f180520423d0e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1. I think we just have to accept the definition in RFC49=
44 has inconsistencies and we should consider it always as a byte,

=
Robert

On 21 September 2015 at 13:58, Carsten Bormann <cabo@tzi.org> wr=
ote:
peter van der Stok =
wrote:

> In RFC 4944, dispatch represents the last 6 bits of the dispatch heade=
r.

> In the routing-dispatch draft, dispatch seems to refer to whole dispat=
ch

> header (pattern).

> Is that correct, or do I miss something? Or am I nit-picking the obvio=
us?



There is even more confusion:



Figure 1 has it as a six-bit subfield of that first byte.

In Figure 2, it is quite obvious that dispatch is the entire first byte.
A comment at the end of page 9 seems to indicate, that dispatch can have
values no larger than 127, so that would make it seven bits.



I think it is less important how RFC 4944 used the term than how we have
been using it since.=C2=A0 Almost all documentation that I'm aware of t=
alks

about the dispatch byte as the first byte of the IEEE 802.15.4 payload,

including the 6LoWPAN book.=C2=A0 RFC 6282 is quite explicit about that

"dispatch octet" (while still using "octet" for byte).<=
br>


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




_______________________________________________

core mailing list

core@ietf.org

https://www.ietf.org/mailman/listinfo/core





--001a11341a34b15f180520423d0e--


From nobody Tue Sep 22 02:59: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 B1E1E1A1B4C for ; Tue, 22 Sep 2015 02:59:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, 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 xWJibLOwKfaL for ; Tue, 22 Sep 2015 02:59:47 -0700 (PDT)
Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2D01A1B59 for ; Tue, 22 Sep 2015 02:59:44 -0700 (PDT)
Received: from webmail.xs4all.nl ([194.109.20.199]) by smtp-cloud6.xs4all.net with ESMTP id L9zi1r00G4Hiz6i019ziXT; Tue, 22 Sep 2015 11:59:42 +0200
Received: from AMontpellier-654-1-72-200.w90-0.abo.wanadoo.fr ([90.0.47.200]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 22 Sep 2015 11:59:42 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 22 Sep 2015 11:59:42 +0200
From: peter van der Stok 
To: "Rahman, Akbar" 
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F347B91BC@NABESITE.InterDigital.com>
References: <25093c7d75ade3f78e471b55816d0bac@xs4all.nl> <36F5869FE31AB24485E5E3222C288E1F347AFBF4@NABESITE.InterDigital.com>  <36F5869FE31AB24485E5E3222C288E1F347B91BC@NABESITE.InterDigital.com>
Message-ID: 
X-Sender: stokcons@xs4all.nl (hFdNhH1lZGw324FKnvvyhnncPzzuSigo)
User-Agent: XS4ALL Webmail
Archived-At: 
Cc: Michael Koster , Core 
Subject: Re: [core] pubsub and sleepy node proxy
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, 22 Sep 2015 09:59:50 -0000

Hi Rahman,

thanks for the concrete suggestions, see below

Rahman, Akbar schreef op 2015-09-17 18:36:
> Hi Peter,
> 
> I'm sorry for the delayed response.  Somehow I missed this in my Inbox
> and only noticed it when I was going over the reflector mailing list
> records.  My specific suggestions are:
> 
> - Yes, it will be good to give more design motivation in your draft.

will think about this

> 
> - Eliminate the tight dependence to 6LoWPAN technology as it is a CoAP
> application protocol and can be run on any underlying IP network.  I'm
> not sure if your main motivation for the 6LoWPAN link was due to your
> L2 security assumptions in Section 9.  But it seems like an
> artificially restrictive dependence.

will look at it; has to do with the history of this work.

> 
> - The link to the PubSub server (section 7) looks tenuous and not that
> convincing to me.

Fully agree, a more appropriate one has been done.

> 
> - Editorial - The arrows between the Proxy and Sleepy Node are all 1
> directional in Figure 1.  But I understood from the text that, for
> example, WRITE, should be a bi-directional between Proxy and Sleepy
> Node (i.e. a WRITE from a Configuring node to the Proxy node should
> ultimately result in a WRITE to the sleepy node from the Proxy).  Did
> I understand correctly?

Ehh, they are inter-actions. I suggest to remove the arrows

> 
> 
> Thanks for the good work.
> 
> 
> Akbar


thanks for the feedback,

Peter
> 
> 
> -----Original Message-----
> From: peter van der Stok [mailto:stokcons@xs4all.nl]
> Sent: Wednesday, September 09, 2015 6:19 AM
> To: Rahman, Akbar 
> Cc: consultancy@vanderstok.org; Michael Koster
> ; Core 
> Subject: RE: [core] pubsub and sleepy node proxy
> 
> Hi Akbar,
> 
> After reading the arkko-core-sleepy draft I do have some concrete
> questions for you:
> 
> Do you want the following additions to the proxy:
> - a http endpoint
> - storage of historical values
> - numbering of messages by sleepy node to estimate the reliability and
> to order them
> - Use of NON messages from sleepy to proxy
> 
> In the arkko draft there is considerable motivation of design choices.
> Do you want more design motivation in the our zotti-core-sleepy draft?
> 
> Is there anything specific I did not pick up?
> 
> Thanks for your reaction,
> 
> Peter
> 
> Rahman, Akbar schreef op 2015-09-03 06:45:
>> Hi Peter,
>> 
>> 
>> I am still reading the pubsub draft, but did want to give support for
>> your sleepy node draft (draft-zotti-core-sleepy-nodes-03).  The sleepy
>> node proxy concept that you describe will be useful in many scenarios.
>>  One related comment that I did have on your draft is that it seems a
>> bit fixated on the 6LoWPAN scenario.  But as we have discussed many
>> times during IETF meetings and on various mailing lists, the sleepy
>> node scenario is useful beyond 6LoWPAN deployments (e.g.
>> https://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01 ).
>> So I think it would be useful if you clarified that in your draft.
>> 
>> 
>> Best Regards,
>> 
>> 
>> Akbar
>> 
>> -----Original Message-----
>> From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der
>> Stok
>> Sent: Monday, August 31, 2015 3:06 AM
>> To: Michael Koster ; Core 
>> Subject: [core] pubsub and sleepy node proxy
>> 
>> Hi Michael,
>> 
>> Looking at the pubsub draft and at our sleepy node proxy draft, I come
>> to the conclusion that there are good arguments to maintain both.
>> 
>> Following the reasoning of Matthieu Vial, there are already a good
>> arguments for the sleepy node (SN) proxy (aka mirror server) to exist
>> next to the RD.
>> Namely:
>> Where an end-point can delegate its links to the RD for discovery, an
>> end-point can delegate the links AND the associated resource values to
>> the SN-proxy.
>> The SN-proxy resources have the same lifetime as SN resources.
>> The SN-proxy resource values are directly linked to the resources of a
>> given SN.
>> 
>> In contrast the pubsub handles anonymous values. The origin can be
>> added but that means adding attributes to the topics.
>> The pubsub handles the more abstract topics, where the SN-proxy is
>> concerned with the resources.
>> The lifetime of the values in the pubsub server is not directly linked
>> to the lifetime of the originating resources.
>> 
>> For me these are the arguments that motivate the existence of the
>> pubsub draft next to the sleepy node draft.
>> 
>> Looking forward to your reaction.
>> 
>> Greetings
>> Teresa and Peter
>> 
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core


From nobody Tue Sep 22 11:57: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 34E681ACD57 for ; Tue, 22 Sep 2015 11:57:35 -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 SEIhOqZlfcwX for ; Tue, 22 Sep 2015 11:57:33 -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 2215C1ACCF2 for ; Tue, 22 Sep 2015 11:57:32 -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 78C1A4505D; Tue, 22 Sep 2015 20:57:30 +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 60BA823; Tue, 22 Sep 2015 20:57:29 +0200 (CEST)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 01A582E; Tue, 22 Sep 2015 20:57:28 +0200 (CEST)
Received: (nullmailer pid 4533 invoked by uid 1000); Tue, 22 Sep 2015 18:57:28 -0000
Date: Tue, 22 Sep 2015 20:57:28 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= 
To: Lisa Dusseault 
Message-ID: <20150922185728.GA25966@hephaistos.amsuess.com>
References: <20150908145930.GB4537@hephaistos.amsuess.com>   <20150909101133.GD4537@hephaistos.amsuess.com> <2455258a29e2d7bf4bbe75d2df4c3f26@xs4all.nl> <20150910110729.GF4485@hephaistos.amsuess.com> <699910a6e837a2887374622ea422cc66@xs4all.nl> <20150914102453.GA1786@hephaistos.amsuess.com> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
Cc: Core 
Subject: Re: [core] Concurrent modifications suggestion in draft-vanderstok-core-patch-01
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, 22 Sep 2015 18:57:35 -0000

--azLHFNyN32YCQGCU
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello Lisa,

there is an current discussion on the CoRE working group mailing list
that in my opinion would benefit on your feedback:

The draft for a PATCH method in CoAP[1] gives recommendations on how to
respond to particular error situations, taking many ideas from HTTP's
PATCH. I've brought up concerns about servers returning 4.09 (CoAPese
for 409 Conflict) when concurrent modification requests can not be
handled by the server. We've dissected the scenarios in the thread
around [2] and wound up with a rough understanding of when to err with
4.09 and when with 5.03 Service Unavailable.

A bit later, it turned out that same question has been brought up when
you defined HTTP's PATCH in [3], where you argued that indicating a
Conflict is the right thing to do even in a concurrent modification
scenario.

You've obviously spent some thought on the semantics of a PATCH request;
could you have a look at the relevant discussion points and give your
ideas on whether a Service Unavailable response is appropriate?

(For your convenience, the IMO relevant passages are quoted below, see
the linked threads for more context).


Best regards
Christian


RFC 5789 (PATCH Method for HTTP):
> Concurrent modification:  Some applications of PATCH might require
>    the server to process requests in the order in which they are
>    received.  If a server is operating under those restrictions, and
>    it receives concurrent requests to modify the same resource, but
>    is unable to queue those requests, the server can usefully
>    indicate this error by using a 409 (Conflict) response.

Christian Ams=FCss wrote:
> If a client sees 4.09, they would be required to resolve the conflict.
> This would normally mean fetching the resource again, [...] may even
> need to call for user interaction because it can't do any merging by
> itself, or (as I'd expect of many tiny embedded implementations)
> indicate failure.

peter van der Stok wrote:
> The following things are possible:
>=20
> 1) The request arrives at the server, and the request queue is full.=20
> (this also handles the case that the server can handle only one request=
=20
> at the time and is busy)
>
> [...]
>
> Add 1) error return 5.03 is clearly required

[1] https://tools.ietf.org/html/draft-vanderstok-core-patch-01
[2] http://mailarchive.ietf.org/arch/msg/core/JI_TqZQFuMfdTs-MnQuKrrNgCPs
[3] http://www.ietf.org/mail-archive/web/ietf/current/msg59171.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

--azLHFNyN32YCQGCU
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJWAaSVAAoJEDmNERLTpL3h2lcQAJA7G3amNB+awxVm0GqqrAs5
96Uxz6eRQFrTxYd9fCsm2TvD6veLiONnqvOCgImFuUq0jvpUoDmfUiR+bDZyZwaE
mlNZs3D549a/U4EDc6G/5LmTloUZUkoM1MTpm9IuoIgS6e75IQ3yp+mtWQnhqw6F
jg7VSPZdHgcpNplVCPxToOYueMk5V8CSq1X1SLknPfJMrL1Z8A3aQ2AeculU5DED
kZVmXI2UhK205iVpcyOiisz6dlYRkg6KT0Dzj85kQI0SmQactNxOqUT66L/XkOZt
bh7DraVi/1QYlVIUrB9HIcrG4UMTsHTS5K94jJ60cQIRKl4JwJYUidjHAQtSp+Yj
8lQXBASGB6BnOc4E6uPGcU4KG49MM2Nk6YjuvnkqxIqsXRntgvpeOfS2AY4ZM1Xd
mQuChNAzIVMP4I3a3Im8RsITs3Arms9URxbOunn2rTcr7pdaHNFx+vBj6aI81d6U
zNuj1gKNO2QQrZfpm5T86HEHlDRm437L3mfLoKXmUOTb6DTI+WEll/VstMkDRDVj
CqIvnltpi+VUdG/A7foee/r72R2cEgcAJm01WKpw+w60vMfe/7yPmAwVXVrMIelf
+30Y86VYpPqLtBJLDgRltOGe4KDcd+3n/8hM9I9xppxZ9asp6YCgbAJDl/Opoq77
SeRLG6I4lqCj02Pv/fqn
=ZouW
-----END PGP SIGNATURE-----

--azLHFNyN32YCQGCU--


From nobody Wed Sep 23 11:06: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 CFBB61A8A1E for ; Wed, 23 Sep 2015 11:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.412
X-Spam-Level: **
X-Spam-Status: No, score=2.412 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] 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 2wiAOFyJmoI6 for ; Wed, 23 Sep 2015 11:06: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 89A921A9035 for ; Wed, 23 Sep 2015 11:00:31 -0700 (PDT)
X-ASG-Debug-ID: 1443031229-06daaa455c23960001-aa7cYp
Received: from NISSONITE.InterDigital.com (nissonite.interdigital.com [10.2.64.252]) by smtp-in1.interdigital.com with ESMTP id qW5FA5kgarOkpXGg (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Sep 2015 14:00:29 -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.0248.002; Wed, 23 Sep 2015 14:00:26 -0400
From: "Rahman, Akbar" 
To: Abhijan Bhattacharyya , Carsten Bormann 
Thread-Topic: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
X-ASG-Orig-Subj: RE: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
Thread-Index: AQHQ78omyjBftircP0+PSVXhf7jhrZ5Au48AgAm4JqA=
Date: Wed, 23 Sep 2015 18:00:25 +0000
Message-ID: <36F5869FE31AB24485E5E3222C288E1F347BAE99@NABESITE.InterDigital.com>
References: <55F83752.3090609@tzi.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.2.229]
x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd
Content-Type: multipart/alternative; boundary="_000_36F5869FE31AB24485E5E3222C288E1F347BAE99NABESITEInterDi_"
MIME-Version: 1.0
X-Barracuda-Connect: nissonite.interdigital.com[10.2.64.252]
X-Barracuda-Start-Time: 1443031229
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.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22828 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message
Archived-At: 
Cc: "core@ietf.org WG" , core 
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
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, 23 Sep 2015 18:06:20 -0000

--_000_36F5869FE31AB24485E5E3222C288E1F347BAE99NABESITEInterDi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Abhijan,


Thanks for your support on the draft!

With regards to your question:

> Given that No-Response now has a number (284) from IANA in the CoRE optio=
n registry (http://www.iana.org/assignments/core-parameters/core-parameters=
.xhtml#option-numbers) probably it will be a good idea to keep a section to=
 discuss how to handle this option since this is not there in HTTP. Somewhe=
re in Section 8 should be a good place for such discussion.


Yes, I agree this is a good topic to add to the draft.  How about something=
 based on the following text:

--------------------------------
8.8 CoAP No Response

CoAP supports sending a Request indicating that "No Response" is required w=
hen the CoAP header option number is set to 284.  An HC Proxy may translate=
 an incoming HTTP Request to a corresponding CoAP Request indicating that n=
o response is required following the guidance in (Ref: http://www.iana.org/=
assignments/core-parameters/core-parameters.xhtml#option-numbers).

---------------------------------


Any feedback?


/Akbar


From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyy=
a
Sent: Thursday, September 17, 2015 5:34 AM
To: Carsten Bormann 
Cc: core ; core@ietf.org WG 
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07

Dear all,
I think this draft is indeed an appreciable effort as it will ease out many=
 implementation decisions for the developers and should be very useful as a=
n RFC.

Dear authors,
I have one small comment :
Given that No-Response now has a number (284) from IANA in the CoRE option =
registry (http://www.iana.org/assignments/core-parameters/core-parameters.x=
html#option-numbers) probably it will be a good idea to keep a section to d=
iscuss how to handle this option since this is not there in HTTP. Somewhere=
 in Section 8 should be a good place for such discussion.



Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________




From:        Carsten Bormann >
To:        "core@ietf.org WG" >
Date:        09/15/2015 08:51 PM
Subject:        [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-=
07
Sent by:        "core" =
>
________________________________



In Prague, we said we were going to WGLC the HTTP mapping draft after
close of the vacation period, which is now behind us.  All outstanding
tickets are closed, and there was enough time to review the current
draft.  Three people raised their hands when we asked who would submit
reviews (Michael K., Klaus, Darshak), but of course additional reviews
beyond that are also very useful.

So this starts a working group last call for
draft-ietf-core-http-mapping for submission as an informational RFC,
ending on

 24:00 PDT on Tuesday, September 29, 2015.

The draft is located at:
https://tools.ietf.org/html/draft-ietf-core-http-mapping-07

Please start a new email thread for each major issue that will need
discussion and make sure the subject line includes the draft name and
some sort of name for the issue. For minor issues such as typos and
things that are not likely to lead to much discussion, it is probably
easier to group them all in to one email but again, please make sure
the subject line includes the draft name. If you read the draft and
think it looks fine, please send a one line email to the list or to
the chairs letting us know that so we can get a feel of how broad the
review has been.

In the unlikely event that you are aware of any patent claims that
might apply to systems that implement the suggestions in this draft,
please review BCP 78 and BCP 79 and make any appropriate IPR
declaration. If you are not sure whether you need to make a
declaration or not, please talk to the chairs and we will help get you
in touch with people that can provide appropriate advice.

Gr=FC=DFe, Carsten

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

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--_000_36F5869FE31AB24485E5E3222C288E1F347BAE99NABESITEInterDi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Abhijan,


 


 


Thanks for your support on the draft!=



 


With regards to your question:


 


>
Given that No-Response now has a number (284) from IANA in the CoRE o=
ption registry (http://www.iana.org/assignments=
/core-parameters/core-parameters.xhtml#option-numbers)
 probably it will be a good idea to keep a section to discuss how to handle=
 this option since this is not there in HTTP. Somewhere in Section 8 should=
 be a good place for such discussion.







 


Yes, I agree this is a good topic to =
add to the draft.  How about something based on the following text:


 


--------------------------------=



8.8 CoAP No Response


 


CoAP supports sending a Request indic=
ating that “No Response” is required when the CoAP header optio=
n number is set to 284.  An HC Proxy may translate an incoming
 HTTP Request to a corresponding CoAP Request indicating that no response i=
s required following the guidance in
(Ref: 
http://www.iana.org/assignments/core-parameters/core-p=
arameters.xhtml#option-numbers).=



 


---------------------------------


 


 


Any feedback?


 


 


/Akbar


 


 


From: core [mailto:core-bounces@ietf=
.org]
On Behalf Of Abhijan Bhattacharyya

Sent: Thursday, September 17, 2015 5:34 AM

To: Carsten Bormann <cabo@tzi.org>

Cc: core <core-bounces@ietf.org>; core@ietf.org WG <core@ie=
tf.org>

Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapp=
ing-07


 


Dear all,


I=
 think this draft is indeed an appreciable effort as it will ease out many =
implementation decisions for the developers and should be very useful as an=
 RFC.




D=
ear authors,


I=
 have one small comment :


G=
iven that No-Response now has a number (284) from IANA in the CoRE option r=
egistry (http://www.iana.org/assignments/core-p=
arameters/core-parameters.xhtml#option-numbers)
 probably it will be a good idea to keep a section to discuss how to handle=
 this option since this is not there in HTTP. Somewhere in Section 8 should=
 be a good place for such discussion.








R=
egards

Abhijan Bhattacharyya

Associate Consultant

Scientist, Innovation Lab, Kolkata, India

Tata Consultancy Services

Mailto: abhijan.bhattachar=
yya@tcs.com

Website: http://www.tcs.com=


____________________________________________

Experience certainty.        IT Services

                     =
;  Business Solutions

                     =
;  Consulting

____________________________________________









From:        Carsten Bormann <cabo@tzi.org>


To:        "core@ietf.org WG" <core@ietf.org>


Date:        09/15/2015 08:51 PM


Subject:        [core] WG last-call (W=
GLC) of draft-ietf-core-http-mapping-07


Sent by:        "core" <<=
a href=3D"mailto:core-bounces@ietf.org">core-bounces@ietf.org>















In Prague, we said we were going to WG=
LC the HTTP mapping draft after

close of the vacation period, which is now behind us.  All outstan=
ding

tickets are closed, and there was enough time to review the current

draft.  Three people raised their hands when we asked who would su=
bmit

reviews (Michael K., Klaus, Darshak), but of course additional reviews<=
/tt>

beyond that are also very useful.



So this starts a working group last call for

draft-ietf-core-http-mapping for submission as an informational RFC,

ending on



 24:00 PDT on Tuesday, September 29, 2015.



The draft is located at:

https://tools.ietf.org/html/draft-=
ietf-core-http-mapping-07



Please start a new email thread for each major issue that will need

discussion and make sure the subject line includes the draft name and

some sort of name for the issue. For minor issues such as typos and

things that are not likely to lead to much discussion, it is probably

easier to group them all in to one email but again, please make sure

the subject line includes the draft name. If you read the draft and

think it looks fine, please send a one line email to the list or to

the chairs letting us know that so we can get a feel of how broad the

review has been.



In the unlikely event that you are aware of any patent claims that=


might apply to systems that implement the suggestions in this draft,

please review BCP 78 and BCP 79 and make any appropriate IPR

declaration. If you are not sure whether you need to make a

declaration or not, please talk to the chairs and we will help get you<=
/tt>

in touch with people that can provide appropriate advice.



Gr=FC=DFe, Carsten



_______________________________________________

core mailing list

core@ietf.org

https://www.ietf.org/mailman/listinfo/core


=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D

Notice: The information contained in this e-mail

message and/or attachments to it may contain 

confidential or privileged information. If you are 

not the intended recipient, any dissemination, use, 

review, distribution, printing or copying of the 

information contained in this e-mail message 

and/or attachments to it are strictly prohibited. If 

you have received this communication in error, 

please notify us by reply e-mail or telephone and 

immediately and permanently delete the message 

and any attachments. Thank you






--_000_36F5869FE31AB24485E5E3222C288E1F347BAE99NABESITEInterDi_--


From nobody Wed Sep 23 14:17: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 A2CD21B2D65; Wed, 23 Sep 2015 14:17: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 oIegoB8JbZj1; Wed, 23 Sep 2015 14:17:15 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FEB61B2C57; Wed, 23 Sep 2015 14:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t8NLH9ob012183; Wed, 23 Sep 2015 23:17:10 +0200 (CEST)
Received: from alma.local (p5DCCDB06.dip0.t-ipconnect.de [93.204.219.6]) (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 3nLslT3Ddlz4q6R; Wed, 23 Sep 2015 23:17:09 +0200 (CEST)
Message-ID: <560316D3.20807@tzi.org>
Date: Wed, 23 Sep 2015 23:17:07 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.4 (Macintosh/20150825)
MIME-Version: 1.0
To: "Rahman, Akbar" 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "core@ietf.org WG" , core 
Subject: [core] Please have another look at no-response (Re: WG last-call (WGLC) of draft-ietf-core-http-mapping-07)
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, 23 Sep 2015 21:17:16 -0000

Rahman, Akbar wrote:
> Any feedback?

We'll need to have a reference.

That (and the current discussion in ACE about unidirectional exchanges)
reminds me that the draft for Option 284 could still benefit from some
final review.  So, if you are interested in this topic, please have a
look at

    http://tools.ietf.org/html/draft-tcs-coap-no-response-option-11.txt

and provide Abhijan (and the core WG list, if you like) with your
feedback, preferably so that he has time to react before the Yokohama
I-D deadline (maybe send in the comments before 2015-10-12).

(To avoid confusion, I'll add that we decided not to make a WG document
out of this option, but there has been some review and some support
already, and we all should be interested in facilitating the extension
registration processes defined in RFC 7252.)

Gr眉脽e, Carsten


From nobody Thu Sep 24 01: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 08E041B37EF for ; Thu, 24 Sep 2015 01:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level: 
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 VXQQscwkOOBJ for ; Thu, 24 Sep 2015 01:10:59 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 42EEA1B37EE for ; Thu, 24 Sep 2015 01:10:57 -0700 (PDT)
Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 06AEA19F5B2 for ; Thu, 24 Sep 2015 16:10:53 +0800 (HKT)
Received: from WeiGengyuPC (unknown [221.219.63.193]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id B1DB419F5B5; Thu, 24 Sep 2015 16:10:51 +0800 (HKT)
Message-ID: 
From: "weigengyu" 
To: "Rahman, Akbar" , "Abhijan Bhattacharyya" , "Carsten Bormann" 
References: <55F83752.3090609@tzi.org>  <36F5869FE31AB24485E5E3222C288E1F347BAE99@NABESITE.InterDigital.com>
In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F347BAE99@NABESITE.InterDigital.com>
Date: Thu, 24 Sep 2015 16:10:50 +0800
Organization: BUPT
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_024C_01D0F6E3.948A8720"
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 , core@ietf.org
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
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, 24 Sep 2015 08:11:03 -0000

这是一封 MIME 格式的多方邮件。

------=_NextPart_000_024C_01D0F6E3.948A8720
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi=EF=BC=8C=20

When a http client accesses a CoAP server,=20
how does the CoAP client of HC proxy create a NON-reposnse option since =
there is not in HTTP.=20
Or it is useless for HC proxy, or not?=20

Regards,

Gengyu WEI
Network Technology Center
School of Computer=20
Beijing University of Posts and Telecommunications

From: Rahman, Akbar=20
Sent: Thursday, September 24, 2015 2:00 AM
To: Abhijan Bhattacharyya ; Carsten Bormann=20
Cc: mailto:core@ietf.org ; core=20
Subject: Re: [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07

Hi Abhijan,

=20

=20

Thanks for your support on the draft!

=20

With regards to your question:

=20

> Given that No-Response now has a number (284) from IANA in the CoRE =
option registry =
(http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#op=
tion-numbers) probably it will be a good idea to keep a section to =
discuss how to handle this option since this is not there in HTTP. =
Somewhere in Section 8 should be a good place for such discussion.=20



=20

Yes, I agree this is a good topic to add to the draft.  How about =
something based on the following text:

=20

--------------------------------

8.8 CoAP No Response

=20

CoAP supports sending a Request indicating that =E2=80=9CNo =
Response=E2=80=9D is required when the CoAP header option number is set =
to 284.  An HC Proxy may translate an incoming HTTP Request to a =
corresponding CoAP Request indicating that no response is required =
following the guidance in (Ref: =
http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#opt=
ion-numbers).

=20

---------------------------------

=20

=20

Any feedback?

=20

=20

/Akbar

=20

=20

From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan =
Bhattacharyya
Sent: Thursday, September 17, 2015 5:34 AM
To: Carsten Bormann 
Cc: core ; core@ietf.org WG 
Subject: Re: [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07

=20

Dear all,=20
I think this draft is indeed an appreciable effort as it will ease out =
many implementation decisions for the developers and should be very =
useful as an RFC.=20

Dear authors,=20
I have one small comment :=20
Given that No-Response now has a number (284) from IANA in the CoRE =
option registry =
(http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#op=
tion-numbers) probably it will be a good idea to keep a section to =
discuss how to handle this option since this is not there in HTTP. =
Somewhere in Section 8 should be a good place for such discussion.=20



Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________




From:        Carsten Bormann =20
To:        "mailto:core@ietf.org%20WG" =20
Date:        09/15/2015 08:51 PM=20
Subject:        [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07=20
Sent by:        "core" =20


-------------------------------------------------------------------------=
-------




In Prague, we said we were going to WGLC the HTTP mapping draft after
close of the vacation period, which is now behind us.  All outstanding
tickets are closed, and there was enough time to review the current
draft.  Three people raised their hands when we asked who would submit
reviews (Michael K., Klaus, Darshak), but of course additional reviews
beyond that are also very useful.

So this starts a working group last call for
draft-ietf-core-http-mapping for submission as an informational RFC,
ending on

24:00 PDT on Tuesday, September 29, 2015.

The draft is located at:
https://tools.ietf.org/html/draft-ietf-core-http-mapping-07

Please start a new email thread for each major issue that will need
discussion and make sure the subject line includes the draft name and
some sort of name for the issue. For minor issues such as typos and
things that are not likely to lead to much discussion, it is probably
easier to group them all in to one email but again, please make sure
the subject line includes the draft name. If you read the draft and
think it looks fine, please send a one line email to the list or to
the chairs letting us know that so we can get a feel of how broad the
review has been.

In the unlikely event that you are aware of any patent claims that
might apply to systems that implement the suggestions in this draft,
please review BCP 78 and BCP 79 and make any appropriate IPR
declaration. If you are not sure whether you need to make a
declaration or not, please talk to the chairs and we will help get you
in touch with people that can provide appropriate advice.

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

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

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain=20
confidential or privileged information. If you are=20
not the intended recipient, any dissemination, use,=20
review, distribution, printing or copying of the=20
information contained in this e-mail message=20
and/or attachments to it are strictly prohibited. If=20
you have received this communication in error,=20
please notify us by reply e-mail or telephone and=20
immediately and permanently delete the message=20
and any attachments. Thank you



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

------=_NextPart_000_024C_01D0F6E3.948A8720
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable














Hi=EF=BC=8C 


 


When a http client accesses a CoAP server, 


how does the CoAP client of HC proxy create a NON-reposnse option =
since=20
there is not in HTTP. =




Or it is useless for HC proxy, or not? 


 


Regards,


 


Gengyu=20
WEI
Network Technology Center
School of Computer 
Beijing =
University of=20
Posts and Telecommunications





 




From: Rahman, Akbar 


Sent: Thursday, September 24, 2015 2:00 AM


To: Abhijan Bhattacharyya =
; Carsten Bormann =




Subject: Re: [core] WG last-call (WGLC) of=20
draft-ietf-core-http-mapping-07


 





Hi=20
Abhijan,


 


 


Thanks=20
for your support on the draft!


 


With=20
regards to your question:


 


>=20
Given that=20
No-Response now has a number (284) from IANA in the CoRE option registry =

(http://www.iana.org/assignments/core-parameters/core-=
parameters.xhtml#option-numbers) probably it =
will be a=20
good idea to keep a section to discuss how to handle this option since =
this is=20
not there in HTTP. Somewhere in Section 8 should be a good place for =
such=20
discussion. 



 


Yes,=20
I agree this is a good topic to add to the draft.  How about =
something=20
based on the following text:


 


--------------------------------


8.8=20
CoAP No Response


 


CoAP=20
supports sending a Request indicating that =E2=80=9CNo Response=E2=80=9D =
is required when the=20
CoAP header option number is set to 284.  An HC Proxy may translate =
an=20
incoming HTTP Request to a corresponding CoAP Request indicating that no =

response is required following the guidance in (Ref: =
http://www.iana.org/assignments/core-parameters/core-=
parameters.xhtml#option-numbers).


 


---------------------------------


 


 


Any=20
feedback?


 


 


/Akbar


 


 


From: core=20
[mailto:core-bounces@ietf.org] On Behalf Of Abhijan=20
Bhattacharyya
Sent: Thursday, September 17, 2015 5:34 =
AM
To:=20
Carsten Bormann <cabo@tzi.org>
Cc: core=20
<core-bounces@ietf.org>; core@ietf.org WG=20
<core@ietf.org>
Subject: Re: [core] WG last-call (WGLC) =
of=20
draft-ietf-core-http-mapping-07


 


Dear =
all,=20

I =
think this=20
draft is indeed an appreciable effort as it will ease out many =
implementation=20
decisions for the developers and should be very useful as an RFC. =



Dear=20
authors, 
I have one =
small=20
comment : 
Given that =
No-Response=20
now has a number (284) from IANA in the CoRE option registry (http://www.iana.org/assignments/core-parameters/core-=
parameters.xhtml#option-numbers) probably it =
will be a=20
good idea to keep a section to discuss how to handle this option since =
this is=20
not there in HTTP. Somewhere in Section 8 should be a good place for =
such=20
discussion. 



Regards
Abhijan=20
Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, =
Kolkata,=20
India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.c=
om
Website:=20
http://www.tcs.com
____________________________________________
E=
xperience=20
certainty.        IT=20
Services
          &=
nbsp;           =20
Business=20
Solutions
          =
             =

Consulting
____________________________________________

=



From:       =20
Carsten=20
Bormann <cabo@tzi.org> =

To:       =20
"mailto:core@ietf.org%20WG" <core@ietf.org> 
Date:       =20
09/15/2015 =
08:51=20
PM 
Subject:       =20
[core] WG=20
last-call (WGLC) of draft-ietf-core-http-mapping-07 
Sent=20
by:        "core" =
<core-bounces@ietf.org>=20












In Prague, we said we were going to WGLC the =
HTTP=20
mapping draft after
close of =
the=20
vacation period, which is now behind us.  All=20
outstanding
tickets are closed, and there was enough time to =
review=20
the current
draft.  Three people raised their hands =
when we=20
asked who would submit
reviews (Michael K., Klaus, Darshak), =
but of=20
course additional reviews
beyond that are also very=20
useful.

So this starts a working group last call=20
for
draft-ietf-core-http-mapping for submission as an =
informational=20
RFC,
ending on

24:00 PDT on Tuesday, =
September 29,=20
2015.

The draft is located at:
=
https://tools.ietf.org/html/draft-ietf-core-http-mapping-07<=
/TT>

Please =
start a=20
new email thread for each major issue that will =
need
discussion and=20
make sure the subject line includes the draft name and
some =
sort of=20
name for the issue. For minor issues such as typos =
and
things that=20
are not likely to lead to much discussion, it is =
probably
easier to=20
group them all in to one email but again, please make =
sure
the=20
subject line includes the draft name. If you read the draft=20
and
think it looks fine, please send a one line email to the =
list or=20
to
the chairs letting us know that so we can get a feel of =
how broad=20
the
review has been.

In the unlikely event =
that you=20
are aware of any patent claims that
might apply to systems =
that=20
implement the suggestions in this draft,
please review BCP =
78 and=20
BCP 79 and make any appropriate IPR
declaration. If you are =
not sure=20
whether you need to make a
declaration or not, please talk =
to the=20
chairs and we will help get you
in touch with people that =
can=20
provide appropriate advice.

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

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


=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: =
The information contained in this=20
e-mail
message and/or attachments to it may contain 
confidential =
or=20
privileged information. If you are 
not the intended recipient, any=20
dissemination, use, 
review, distribution, printing or copying of the =


information contained in this e-mail message 
and/or attachments =
to it=20
are strictly prohibited. If 
you have received this communication in =
error,=20

please notify us by reply e-mail or telephone and 
immediately =
and=20
permanently delete the message 
and any attachments. Thank=20
you





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


------=_NextPart_000_024C_01D0F6E3.948A8720--



From nobody Thu Sep 24 05:53: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 B6EEE1ACE50; Thu, 24 Sep 2015 05:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 zA_5U10ZGMZv; Thu, 24 Sep 2015 05:53:04 -0700 (PDT)
Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 833951ACDC4; Thu, 24 Sep 2015 05:52:59 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2DkAQC07gNW/wQXEqxdDoNqaYMquhQBDYFwAQmFeQIcgWoUAQEBAQEBAYEKhCQBAQEDAQEBARoGSwsFCwkCBwYEAwEBASgDAgICJR8JCAYLCAkSiAsVmgqcOQEBAW+UOAEBAQEBAQEBAQEBAQEBAQEBAQEBAReFSGqFPoJBgWkRAQYGKgoMAQQGAQaCYy+BFAWHNIVJdId2hRKFRoQCFYQhgyGOF4NtHwEBglMcgRZGaYgtgT8BAQE
X-IPAS-Result: A2DkAQC07gNW/wQXEqxdDoNqaYMquhQBDYFwAQmFeQIcgWoUAQEBAQEBAYEKhCQBAQEDAQEBARoGSwsFCwkCBwYEAwEBASgDAgICJR8JCAYLCAkSiAsVmgqcOQEBAW+UOAEBAQEBAQEBAQEBAQEBAQEBAQEBAReFSGqFPoJBgWkRAQYGKgoMAQQGAQaCYy+BFAWHNIVJdId2hRKFRoQCFYQhgyGOF4NtHwEBglMcgRZGaYgtgT8BAQE
X-IronPort-AV: E=Sophos;i="5.17,580,1437417000";  d="scan'208";a="9730432"
X-DISCLAIMER: FALSE
In-Reply-To: 
References: <55F83752.3090609@tzi.org>  <36F5869FE31AB24485E5E3222C288E1F347BAE99@NABESITE.InterDigital.com> 
To: "weigengyu" , "Rahman, Akbar" 
MIME-Version: 1.0
X-KeepSent: 86A82596:2D778C3F-65257ECA:0036D734; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0 March 08, 2013
Message-ID: 
From: Abhijan Bhattacharyya 
Date: Thu, 24 Sep 2015 18:22:54 +0530
X-MIMETrack: Serialize by smdreal on InKolM02/TCS(Release 9.0.1FP4|June  07, 2015) at 09/24/2015 18:22:55, Serialize complete at 09/24/2015 18:22:55, Serialize by Router on InKolM02/TCS(Release 9.0.1FP4|June  07, 2015) at 09/24/2015 18:22:55
Content-Type: multipart/alternative; boundary="=_alternative 0046C32165257ECA_="
Archived-At: 
Cc: core , core@ietf.org
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
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, 24 Sep 2015 12:53:12 -0000

This is a multipart message in MIME format.
--=_alternative 0046C32165257ECA_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

SGkgQWtiYXIsDQpUaGFua3MuDQoNClRha2luZyBjbHVlIGZyb20gR2VuZ3l1J3MgcmVzcG9uc2Ug
SSB3b3VsZCBsaWtlIHRvIHNoYXJlIHRoZSBmb2xsb3dpbmcgDQppbnB1dDoNCg0KVGhlIGRlY2lz
aW9uIHRvIGNvbnZlcnQgYW4gSFRUUCByZXF1ZXN0IHRvIGEgQ29BUCByZXF1ZXN0IHdpdGggIk5v
IA0KUmVzcG9uc2UiIHNob3VsZCBiZSBwdXJlbHkgYmFzZWQgb24gdGhlIGFwcGxpY2F0aW9uIGNv
bnRleHQuIA0KTGV0IHVzIGNvbnNpZGVyIGEgc2NlbmFyaW8uIA0KV2Ugd2FudCB0byBvcGVyYXRl
IHRoZSBsaWdodHMgb2YgYSBidWlsZGluZyBmcm9tIGEgcmVtb3RlIGNvbnRyb2wtY2VudGVyIA0K
KGNvbnRyb2xsaW5nIGNvbW1hbmRzIG1heSBub3QgYmUgZXNzZW50aWFsbHkgbXVsdGljYXN0KS4g
TGV0IHVzIGFzc3VtZSANCnRoYXQgdGhlIGNvbnRyb2wtY2VudGVyIGhhcyBsZWdhY3kgSFRUUCBp
bmZyYXN0cnVjdHVyZS4gQnV0IHRoZSBsaWdodHMgYXJlIA0KQ29BUCBlbmFibGVkLiBTbyB0aGUg
cmVxdWVzdHMgZnJvbSB0aGUgY29udHJvbC1jZW50ZXIgZ29lcyB0aHJvdWdoIGFuIEhDIA0KcHJv
eHkuIFRoZSBhcHBsaWNhdGlvbiByZXF1aXJlbWVudCwgaW4gdGhhdCBjYXNlLCB3aWxsIGRlY2lk
ZSB3aGV0aGVyIHRoZSANCnJlcXVlc3RzIGZyb20gSFRUUCBjbGllbnQgYXJlIHRvIGJlIG1hZGUg
Q29BUCByZXF1ZXN0cyB3aXRoIE5vLVJlc3BvbnNlIG9yIA0Kbm90LiANCg0KQnV0LCB0aGVyZSBp
cyBvbmUgcG9pbnQuIFRoZSBIVFRQIGNsaWVudCBuZWVkcyBhIHJlc3BvbnNlIGFzIHBlciB0aGUg
SFRUUCANCnByb3RvY29sIHJlcXVpcmVtZW50cy4gU28sIHdoYXQgcmVzcG9uc2Ugc2hvdWxkIHBy
b3h5IHJldHVybj8gDQpMb29raW5nIGF0IFRhYmxlIDIgb2YgdGhlIGh0dHAgbWFwcGluZyBkcmFm
dCB3ZSBzZWUgdGhhdCBDb0FQJ3MgMi4wNCANCihDaGFuZ2VkKSBpcyBtYXBwZWQgdG8gZWl0aGVy
IDIwMCAoT0spIG9yIDIwNCAoTm8gQ29udGVudCkgZm9yIHRoZSBIVFRQLiANCkNhbiB3ZSBzdWdn
ZXN0IHRoYXQgaW4gY2FzZXMgYXMgZGVzY3JpYmVkIGFib3ZlIHRoZSBwcm94eSBTSE9VTEQgcmVz
cG9uZCANCndpdGggdGhlIHN0YXR1cyBjb2RlOiAyMDQgIE5vIENvbnRlbnQgPyBUaGlzIHdheSB0
aGUgY2xpZW50IGtub3dzIHRoYXQgDQpOby1SZXNwb25zZSBpcyBlbmFibGVkIGF0IHRoZSBDb0FQ
IHNpZGUgZm9yIHRoZSBwYXJ0aWN1bGFyIFBVVHMuDQoNCkRvZXMgaXQgbWFrZSBzZW5zZT8NCg0K
DQpSZWdhcmRzDQpBYmhpamFuIEJoYXR0YWNoYXJ5eWENCkFzc29jaWF0ZSBDb25zdWx0YW50DQpT
Y2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYQ0KVGF0YSBDb25zdWx0YW5j
eSBTZXJ2aWNlcw0KTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbQ0KV2Vic2l0
ZTogaHR0cDovL3d3dy50Y3MuY29tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KRXhwZXJpZW5jZSBjZXJ0YWludHkuICAgSVQgU2VydmljZXMNCiAgICAgICAg
ICAgICAgICAgICAgICAgIEJ1c2luZXNzIFNvbHV0aW9ucw0KICAgICAgICAgICAgICAgICAgICAg
ICAgQ29uc3VsdGluZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCg0KDQoid2VpZ2VuZ3l1IiA8d2VpZ2VuZ3l1QGJ1cHQuZWR1LmNuPiB3cm90ZSBvbiAwOS8y
NC8yMDE1IDAxOjQwOjUwIFBNOg0KDQo+IEZyb206ICJ3ZWlnZW5neXUiIDx3ZWlnZW5neXVAYnVw
dC5lZHUuY24+DQo+IFRvOiAiUmFobWFuLCBBa2JhciIgPEFrYmFyLlJhaG1hbkBJbnRlckRpZ2l0
YWwuY29tPiwgIkFiaGlqYW4gDQo+IEJoYXR0YWNoYXJ5eWEiIDxhYmhpamFuLmJoYXR0YWNoYXJ5
eWFAdGNzLmNvbT4sICJDYXJzdGVuIEJvcm1hbm4iIA0KPiA8Y2Fib0B0emkub3JnPg0KPiBDYzog
PGNvcmVAaWV0Zi5vcmc+LCAiY29yZSIgPGNvcmUtYm91bmNlc0BpZXRmLm9yZz4NCj4gRGF0ZTog
MDkvMjQvMjAxNSAwMTo1MCBQTQ0KPiBTdWJqZWN0OiBSZTogW2NvcmVdIFdHIGxhc3QtY2FsbCAo
V0dMQykgb2YgDQpkcmFmdC1pZXRmLWNvcmUtaHR0cC1tYXBwaW5nLTA3DQo+IA0KPiBIae+8jCAN
Cj4gDQo+IFdoZW4gYSBodHRwIGNsaWVudCBhY2Nlc3NlcyBhIENvQVAgc2VydmVyLCANCj4gaG93
IGRvZXMgdGhlIENvQVAgY2xpZW50IG9mIEhDIHByb3h5IGNyZWF0ZSBhIE5PTi1yZXBvc25zZSBv
cHRpb24gDQo+IHNpbmNlIHRoZXJlIGlzIG5vdCBpbiBIVFRQLiANCj4gT3IgaXQgaXMgdXNlbGVz
cyBmb3IgSEMgcHJveHksIG9yIG5vdD8gDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gR2VuZ3l1IFdF
SQ0KPiBOZXR3b3JrIFRlY2hub2xvZ3kgQ2VudGVyDQo+IFNjaG9vbCBvZiBDb21wdXRlciANCj4g
QmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMNCj4gDQo+
IEZyb206IFJhaG1hbiwgQWtiYXIgDQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjQsIDIw
MTUgMjowMCBBTQ0KPiBUbzogQWJoaWphbiBCaGF0dGFjaGFyeXlhIDsgQ2Fyc3RlbiBCb3JtYW5u
IA0KPiBDYzogbWFpbHRvOmNvcmVAaWV0Zi5vcmcgOyBjb3JlIA0KPiBTdWJqZWN0OiBSZTogW2Nv
cmVdIFdHIGxhc3QtY2FsbCAoV0dMQykgb2YgDQpkcmFmdC1pZXRmLWNvcmUtaHR0cC1tYXBwaW5n
LTA3DQo+IA0KPiBIaSBBYmhpamFuLA0KPiANCj4gDQo+IFRoYW5rcyBmb3IgeW91ciBzdXBwb3J0
IG9uIHRoZSBkcmFmdCENCj4gDQo+IFdpdGggcmVnYXJkcyB0byB5b3VyIHF1ZXN0aW9uOg0KPiAN
Cj4gPiBHaXZlbiB0aGF0IE5vLVJlc3BvbnNlIG5vdyBoYXMgYSBudW1iZXIgKDI4NCkgZnJvbSBJ
QU5BIGluIHRoZSANCj4gQ29SRSBvcHRpb24gcmVnaXN0cnkgKGh0dHA6Ly93d3cuaWFuYS5vcmcv
YXNzaWdubWVudHMvY29yZS0NCj4gcGFyYW1ldGVycy9jb3JlLXBhcmFtZXRlcnMueGh0bWwjb3B0
aW9uLW51bWJlcnMpIHByb2JhYmx5IGl0IHdpbGwgYmUNCj4gYSBnb29kIGlkZWEgdG8ga2VlcCBh
IHNlY3Rpb24gdG8gZGlzY3VzcyBob3cgdG8gaGFuZGxlIHRoaXMgb3B0aW9uIA0KPiBzaW5jZSB0
aGlzIGlzIG5vdCB0aGVyZSBpbiBIVFRQLiBTb21ld2hlcmUgaW4gU2VjdGlvbiA4IHNob3VsZCBi
ZSBhIA0KPiBnb29kIHBsYWNlIGZvciBzdWNoIGRpc2N1c3Npb24uIA0KDQo+IA0KPiBZZXMsIEkg
YWdyZWUgdGhpcyBpcyBhIGdvb2QgdG9waWMgdG8gYWRkIHRvIHRoZSBkcmFmdC4gIEhvdyBhYm91
dCANCj4gc29tZXRoaW5nIGJhc2VkIG9uIHRoZSBmb2xsb3dpbmcgdGV4dDoNCj4gDQo+IC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IDguOCBDb0FQIE5vIFJlc3BvbnNlDQo+IA0K
PiBDb0FQIHN1cHBvcnRzIHNlbmRpbmcgYSBSZXF1ZXN0IGluZGljYXRpbmcgdGhhdCDigJxObyBS
ZXNwb25zZeKAnSBpcyANCj4gcmVxdWlyZWQgd2hlbiB0aGUgQ29BUCBoZWFkZXIgb3B0aW9uIG51
bWJlciBpcyBzZXQgdG8gMjg0LiAgQW4gSEMgDQo+IFByb3h5IG1heSB0cmFuc2xhdGUgYW4gaW5j
b21pbmcgSFRUUCBSZXF1ZXN0IHRvIGEgY29ycmVzcG9uZGluZyBDb0FQDQo+IFJlcXVlc3QgaW5k
aWNhdGluZyB0aGF0IG5vIHJlc3BvbnNlIGlzIHJlcXVpcmVkIGZvbGxvd2luZyB0aGUgZ3VpZGFu
Y2UgDQppbiANCj4gKFJlZjogaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9jb3JlLXBh
cmFtZXRlcnMvY29yZS0NCj4gcGFyYW1ldGVycy54aHRtbCNvcHRpb24tbnVtYmVycykuDQo+IA0K
PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IA0KPiBBbnkgZmVlZGJh
Y2s/DQo+IA0KPiANCj4gL0FrYmFyDQo+IA0KPiANCj4gRnJvbTogY29yZSBbbWFpbHRvOmNvcmUt
Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFiaGlqYW4gDQpCaGF0dGFjaGFyeXlhDQo+
IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTcsIDIwMTUgNTozNCBBTQ0KPiBUbzogQ2Fyc3Rl
biBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+DQo+IENjOiBjb3JlIDxjb3JlLWJvdW5jZXNAaWV0Zi5v
cmc+OyBjb3JlQGlldGYub3JnIFdHIDxjb3JlQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW2Nv
cmVdIFdHIGxhc3QtY2FsbCAoV0dMQykgb2YgDQpkcmFmdC1pZXRmLWNvcmUtaHR0cC1tYXBwaW5n
LTA3DQo+IA0KPiBEZWFyIGFsbCwgDQo+IEkgdGhpbmsgdGhpcyBkcmFmdCBpcyBpbmRlZWQgYW4g
YXBwcmVjaWFibGUgZWZmb3J0IGFzIGl0IHdpbGwgZWFzZSANCj4gb3V0IG1hbnkgaW1wbGVtZW50
YXRpb24gZGVjaXNpb25zIGZvciB0aGUgZGV2ZWxvcGVycyBhbmQgc2hvdWxkIGJlIA0KPiB2ZXJ5
IHVzZWZ1bCBhcyBhbiBSRkMuIA0KPiANCj4gRGVhciBhdXRob3JzLCANCj4gSSBoYXZlIG9uZSBz
bWFsbCBjb21tZW50IDogDQo+IEdpdmVuIHRoYXQgTm8tUmVzcG9uc2Ugbm93IGhhcyBhIG51bWJl
ciAoMjg0KSBmcm9tIElBTkEgaW4gdGhlIENvUkUgDQo+IG9wdGlvbiByZWdpc3RyeSAoaHR0cDov
L3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9jb3JlLXBhcmFtZXRlcnMvDQo+IGNvcmUtcGFyYW1l
dGVycy54aHRtbCNvcHRpb24tbnVtYmVycykgcHJvYmFibHkgaXQgd2lsbCBiZSBhIGdvb2QgDQo+
IGlkZWEgdG8ga2VlcCBhIHNlY3Rpb24gdG8gZGlzY3VzcyBob3cgdG8gaGFuZGxlIHRoaXMgb3B0
aW9uIHNpbmNlIA0KPiB0aGlzIGlzIG5vdCB0aGVyZSBpbiBIVFRQLiBTb21ld2hlcmUgaW4gU2Vj
dGlvbiA4IHNob3VsZCBiZSBhIGdvb2QgDQo+IHBsYWNlIGZvciBzdWNoIGRpc2N1c3Npb24uIA0K
PiANCj4gDQo+IA0KPiBSZWdhcmRzDQo+IEFiaGlqYW4gQmhhdHRhY2hhcnl5YQ0KPiBBc3NvY2lh
dGUgQ29uc3VsdGFudA0KPiBTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRp
YQ0KPiBUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzDQo+IE1haWx0bzogYWJoaWphbi5iaGF0dGFj
aGFyeXlhQHRjcy5jb20NCj4gV2Vic2l0ZTogaHR0cDovL3d3dy50Y3MuY29tDQo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEV4cGVyaWVuY2UgY2VydGFp
bnR5LiAgICAgICAgSVQgU2VydmljZXMNCj4gICAgICAgICAgICAgICAgICAgICAgICBCdXNpbmVz
cyBTb2x1dGlvbnMNCj4gICAgICAgICAgICAgICAgICAgICAgICBDb25zdWx0aW5nDQo+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiANCj4gDQo+IA0K
PiBGcm9tOiAgICAgICAgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+IA0KPiBUbzogICAg
ICAgICJtYWlsdG86Y29yZUBpZXRmLm9yZyUyMFdHIiA8Y29yZUBpZXRmLm9yZz4gDQo+IERhdGU6
ICAgICAgICAwOS8xNS8yMDE1IDA4OjUxIFBNIA0KPiBTdWJqZWN0OiAgICAgICAgW2NvcmVdIFdH
IGxhc3QtY2FsbCAoV0dMQykgb2YgDQpkcmFmdC1pZXRmLWNvcmUtaHR0cC1tYXBwaW5nLTA3DQo+
IFNlbnQgYnk6ICAgICAgICAiY29yZSIgPGNvcmUtYm91bmNlc0BpZXRmLm9yZz4gDQo+IA0KPiAN
Cj4gDQo+IA0KPiBJbiBQcmFndWUsIHdlIHNhaWQgd2Ugd2VyZSBnb2luZyB0byBXR0xDIHRoZSBI
VFRQIG1hcHBpbmcgZHJhZnQgYWZ0ZXINCj4gY2xvc2Ugb2YgdGhlIHZhY2F0aW9uIHBlcmlvZCwg
d2hpY2ggaXMgbm93IGJlaGluZCB1cy4gIEFsbCBvdXRzdGFuZGluZw0KPiB0aWNrZXRzIGFyZSBj
bG9zZWQsIGFuZCB0aGVyZSB3YXMgZW5vdWdoIHRpbWUgdG8gcmV2aWV3IHRoZSBjdXJyZW50DQo+
IGRyYWZ0LiAgVGhyZWUgcGVvcGxlIHJhaXNlZCB0aGVpciBoYW5kcyB3aGVuIHdlIGFza2VkIHdo
byB3b3VsZCBzdWJtaXQNCj4gcmV2aWV3cyAoTWljaGFlbCBLLiwgS2xhdXMsIERhcnNoYWspLCBi
dXQgb2YgY291cnNlIGFkZGl0aW9uYWwgcmV2aWV3cw0KPiBiZXlvbmQgdGhhdCBhcmUgYWxzbyB2
ZXJ5IHVzZWZ1bC4NCj4gDQo+IFNvIHRoaXMgc3RhcnRzIGEgd29ya2luZyBncm91cCBsYXN0IGNh
bGwgZm9yDQo+IGRyYWZ0LWlldGYtY29yZS1odHRwLW1hcHBpbmcgZm9yIHN1Ym1pc3Npb24gYXMg
YW4gaW5mb3JtYXRpb25hbCBSRkMsDQo+IGVuZGluZyBvbg0KPiANCj4gMjQ6MDAgUERUIG9uIFR1
ZXNkYXksIFNlcHRlbWJlciAyOSwgMjAxNS4NCj4gDQo+IFRoZSBkcmFmdCBpcyBsb2NhdGVkIGF0
Og0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3JlLWh0dHAtbWFw
cGluZy0wNw0KPiANCj4gUGxlYXNlIHN0YXJ0IGEgbmV3IGVtYWlsIHRocmVhZCBmb3IgZWFjaCBt
YWpvciBpc3N1ZSB0aGF0IHdpbGwgbmVlZA0KPiBkaXNjdXNzaW9uIGFuZCBtYWtlIHN1cmUgdGhl
IHN1YmplY3QgbGluZSBpbmNsdWRlcyB0aGUgZHJhZnQgbmFtZSBhbmQNCj4gc29tZSBzb3J0IG9m
IG5hbWUgZm9yIHRoZSBpc3N1ZS4gRm9yIG1pbm9yIGlzc3VlcyBzdWNoIGFzIHR5cG9zIGFuZA0K
PiB0aGluZ3MgdGhhdCBhcmUgbm90IGxpa2VseSB0byBsZWFkIHRvIG11Y2ggZGlzY3Vzc2lvbiwg
aXQgaXMgcHJvYmFibHkNCj4gZWFzaWVyIHRvIGdyb3VwIHRoZW0gYWxsIGluIHRvIG9uZSBlbWFp
bCBidXQgYWdhaW4sIHBsZWFzZSBtYWtlIHN1cmUNCj4gdGhlIHN1YmplY3QgbGluZSBpbmNsdWRl
cyB0aGUgZHJhZnQgbmFtZS4gSWYgeW91IHJlYWQgdGhlIGRyYWZ0IGFuZA0KPiB0aGluayBpdCBs
b29rcyBmaW5lLCBwbGVhc2Ugc2VuZCBhIG9uZSBsaW5lIGVtYWlsIHRvIHRoZSBsaXN0IG9yIHRv
DQo+IHRoZSBjaGFpcnMgbGV0dGluZyB1cyBrbm93IHRoYXQgc28gd2UgY2FuIGdldCBhIGZlZWwg
b2YgaG93IGJyb2FkIHRoZQ0KPiByZXZpZXcgaGFzIGJlZW4uDQo+IA0KPiBJbiB0aGUgdW5saWtl
bHkgZXZlbnQgdGhhdCB5b3UgYXJlIGF3YXJlIG9mIGFueSBwYXRlbnQgY2xhaW1zIHRoYXQNCj4g
bWlnaHQgYXBwbHkgdG8gc3lzdGVtcyB0aGF0IGltcGxlbWVudCB0aGUgc3VnZ2VzdGlvbnMgaW4g
dGhpcyBkcmFmdCwNCj4gcGxlYXNlIHJldmlldyBCQ1AgNzggYW5kIEJDUCA3OSBhbmQgbWFrZSBh
bnkgYXBwcm9wcmlhdGUgSVBSDQo+IGRlY2xhcmF0aW9uLiBJZiB5b3UgYXJlIG5vdCBzdXJlIHdo
ZXRoZXIgeW91IG5lZWQgdG8gbWFrZSBhDQo+IGRlY2xhcmF0aW9uIG9yIG5vdCwgcGxlYXNlIHRh
bGsgdG8gdGhlIGNoYWlycyBhbmQgd2Ugd2lsbCBoZWxwIGdldCB5b3UNCj4gaW4gdG91Y2ggd2l0
aCBwZW9wbGUgdGhhdCBjYW4gcHJvdmlkZSBhcHByb3ByaWF0ZSBhZHZpY2UuDQo+IA0KPiBHcsO8
w59lLCBDYXJzdGVuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KPiA9PT09PS0tLS0tPT09PT0t
LS0tLT09PT09DQo+IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUt
bWFpbA0KPiBtZXNzYWdlIGFuZC9vciBhdHRhY2htZW50cyB0byBpdCBtYXkgY29udGFpbiANCj4g
Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgDQo+IG5v
dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzc2VtaW5hdGlvbiwgdXNlLCANCj4gcmV2
aWV3LCBkaXN0cmlidXRpb24sIHByaW50aW5nIG9yIGNvcHlpbmcgb2YgdGhlIA0KPiBpbmZvcm1h
dGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSANCj4gYW5kL29yIGF0dGFjaG1l
bnRzIHRvIGl0IGFyZSBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiANCj4geW91IGhhdmUgcmVjZWl2
ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCANCj4gcGxlYXNlIG5vdGlmeSB1cyBieSBy
ZXBseSBlLW1haWwgb3IgdGVsZXBob25lIGFuZCANCj4gaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVu
dGx5IGRlbGV0ZSB0aGUgbWVzc2FnZSANCj4gYW5kIGFueSBhdHRhY2htZW50cy4gVGhhbmsgeW91
DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNv
cmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9jb3JlDQo=
--=_alternative 0046C32165257ECA_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFrYmFyLDwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLjwvZm9udD4NCjxicj4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGFraW5nIGNsdWUgZnJvbSBHZW5neXUncyByZXNw
b25zZSBJDQp3b3VsZCBsaWtlIHRvIHNoYXJlIHRoZSBmb2xsb3dpbmcgaW5wdXQ6PC9mb250Pg0K
PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgZGVjaXNpb24gdG8g
Y29udmVydCBhbiBIVFRQIHJlcXVlc3QNCnRvIGEgQ29BUCByZXF1ZXN0IHdpdGggJnF1b3Q7Tm8g
UmVzcG9uc2UmcXVvdDsgc2hvdWxkIGJlIHB1cmVseSBiYXNlZCBvbg0KdGhlIGFwcGxpY2F0aW9u
IGNvbnRleHQuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TGV0
IHVzIGNvbnNpZGVyIGEgc2NlbmFyaW8uIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i
c2Fucy1zZXJpZiI+V2Ugd2FudCB0byBvcGVyYXRlIHRoZSBsaWdodHMgb2YgYSBidWlsZGluZw0K
ZnJvbSBhIHJlbW90ZSBjb250cm9sLWNlbnRlciAoY29udHJvbGxpbmcgY29tbWFuZHMgbWF5IG5v
dCBiZSBlc3NlbnRpYWxseQ0KbXVsdGljYXN0KS4gTGV0IHVzIGFzc3VtZSB0aGF0IHRoZSBjb250
cm9sLWNlbnRlciBoYXMgbGVnYWN5IEhUVFAgaW5mcmFzdHJ1Y3R1cmUuDQpCdXQgdGhlIGxpZ2h0
cyBhcmUgQ29BUCBlbmFibGVkLiBTbyB0aGUgcmVxdWVzdHMgZnJvbSB0aGUgY29udHJvbC1jZW50
ZXINCmdvZXMgdGhyb3VnaCBhbiBIQyBwcm94eS4gVGhlIGFwcGxpY2F0aW9uIHJlcXVpcmVtZW50
LCBpbiB0aGF0IGNhc2UsIHdpbGwNCmRlY2lkZSB3aGV0aGVyIHRoZSByZXF1ZXN0cyBmcm9tIEhU
VFAgY2xpZW50IGFyZSB0byBiZSBtYWRlIENvQVAgcmVxdWVzdHMNCndpdGggTm8tUmVzcG9uc2Ug
b3Igbm90LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi
PkJ1dCwgdGhlcmUgaXMgb25lIHBvaW50LiBUaGUgSFRUUCBjbGllbnQNCm5lZWRzIGEgcmVzcG9u
c2UgYXMgcGVyIHRoZSBIVFRQIHByb3RvY29sIHJlcXVpcmVtZW50cy4gU28sIHdoYXQgcmVzcG9u
c2UNCnNob3VsZCBwcm94eSByZXR1cm4/IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i
c2Fucy1zZXJpZiI+TG9va2luZyBhdCBUYWJsZSAyIG9mIHRoZSBodHRwIG1hcHBpbmcNCmRyYWZ0
IHdlIHNlZSB0aGF0IENvQVAncyAyLjA0IChDaGFuZ2VkKSBpcyBtYXBwZWQgdG8gZWl0aGVyIDIw
MCAoT0spIG9yDQoyMDQgKE5vIENvbnRlbnQpIGZvciB0aGUgSFRUUC4gQ2FuIHdlIHN1Z2dlc3Qg
dGhhdCBpbiBjYXNlcyBhcyBkZXNjcmliZWQNCmFib3ZlIHRoZSBwcm94eSBTSE9VTEQgcmVzcG9u
ZCB3aXRoIHRoZSBzdGF0dXMgY29kZTogPGI+MjA0PC9iPiAmbmJzcDtObw0KQ29udGVudCA/IFRo
aXMgd2F5IHRoZSBjbGllbnQga25vd3MgdGhhdCBOby1SZXNwb25zZSBpcyBlbmFibGVkIGF0IHRo
ZQ0KQ29BUCBzaWRlIGZvciB0aGUgcGFydGljdWxhciBQVVRzLjwvZm9udD4NCjxicj4NCjxicj48
Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RG9lcyBpdCBtYWtlIHNlbnNlPzwvZm9udD4N
Cjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UmVnYXJkczxi
cj4NCkFiaGlqYW4gQmhhdHRhY2hhcnl5YTxicj4NCkFzc29jaWF0ZSBDb25zdWx0YW50PGJyPg0K
U2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWE8YnI+DQpUYXRhIENvbnN1
bHRhbmN5IFNlcnZpY2VzPGJyPg0KTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNv
bTxicj4NCldlYnNpdGU6IDwvZm9udD48YSBocmVmPWh0dHA6Ly93d3cudGNzLmNvbS8+PGZvbnQg
c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly93d3cudGNzLmNvbTwvZm9udD48L2E+PGZv
bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyPg0KRXhwZXJpZW5jZSBjZXJ0YWludHkuICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwO0lUIFNlcnZpY2VzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDtDb25zdWx0aW5nPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mcXVvdDt3ZWln
ZW5neXUmcXVvdDsgJmx0O3dlaWdlbmd5dUBidXB0LmVkdS5jbiZndDsNCndyb3RlIG9uIDA5LzI0
LzIwMTUgMDE6NDA6NTAgUE06PGJyPg0KPGJyPg0KJmd0OyBGcm9tOiAmcXVvdDt3ZWlnZW5neXUm
cXVvdDsgJmx0O3dlaWdlbmd5dUBidXB0LmVkdS5jbiZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+
PGZvbnQgc2l6ZT0yPiZndDsgVG86ICZxdW90O1JhaG1hbiwgQWtiYXImcXVvdDsgJmx0O0FrYmFy
LlJhaG1hbkBJbnRlckRpZ2l0YWwuY29tJmd0OywNCiZxdW90O0FiaGlqYW4gPGJyPg0KJmd0OyBC
aGF0dGFjaGFyeXlhJnF1b3Q7ICZsdDthYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbSZndDss
ICZxdW90O0NhcnN0ZW4NCkJvcm1hbm4mcXVvdDsgPGJyPg0KJmd0OyAmbHQ7Y2Fib0B0emkub3Jn
Jmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBDYzogJmx0O2NvcmVA
aWV0Zi5vcmcmZ3Q7LCAmcXVvdDtjb3JlJnF1b3Q7ICZsdDtjb3JlLWJvdW5jZXNAaWV0Zi5vcmcm
Z3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IERhdGU6IDA5LzI0LzIw
MTUgMDE6NTAgUE08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU3ViamVj
dDogUmU6IFtjb3JlXSBXRyBsYXN0LWNhbGwgKFdHTEMpIG9mIGRyYWZ0LWlldGYtY29yZS1odHRw
LW1hcHBpbmctMDc8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0K
Jmd0OyBIae+8jCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFdoZW4gYSBodHRwIGNsaWVu
dCBhY2Nlc3NlcyBhIENvQVAgc2VydmVyLCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0yPiZndDsgaG93IGRvZXMgdGhlIENvQVAgY2xpZW50IG9mIEhDIHByb3h5IGNyZWF0ZSBhDQpO
T04tcmVwb3Nuc2Ugb3B0aW9uIDxicj4NCiZndDsgc2luY2UgdGhlcmUgaXMgbm90IGluIEhUVFAu
IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBPciBpdCBpcyB1c2VsZXNz
IGZvciBIQyBwcm94eSwgb3Igbm90PyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y
PiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFJlZ2Fy
ZHMsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48
L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBHZW5neXUgV0VJPGJyPg0KJmd0OyBOZXR3
b3JrIFRlY2hub2xvZ3kgQ2VudGVyPGJyPg0KJmd0OyBTY2hvb2wgb2YgQ29tcHV0ZXIgPGJyPg0K
Jmd0OyBCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgYW5kIFRlbGVjb21tdW5pY2F0aW9uczwv
Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4N
Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRnJvbTogUmFobWFuLCBBa2JhciA8L2ZvbnQ+PC90
dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAy
NCwgMjAxNSAyOjAwIEFNPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRv
OiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgOyBDYXJzdGVuIEJvcm1hbm4gPC9mb250PjwvdHQ+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IENjOiA8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzpj
b3JlQGlldGYub3JnPjx0dD48Zm9udCBzaXplPTI+bWFpbHRvOmNvcmVAaWV0Zi5vcmc8L2ZvbnQ+
PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj4NCjsgY29yZSA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+
PGZvbnQgc2l6ZT0yPiZndDsgU3ViamVjdDogUmU6IFtjb3JlXSBXRyBsYXN0LWNhbGwgKFdHTEMp
IG9mIGRyYWZ0LWlldGYtY29yZS1odHRwLW1hcHBpbmctMDc8L2ZvbnQ+PC90dD4NCjxicj48dHQ+
PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IEhpIEFiaGlqYW4sPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7
ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2Zv
bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVGhhbmtzIGZvciB5b3VyIHN1cHBv
cnQgb24gdGhlIGRyYWZ0ITwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAm
bmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgV2l0aCByZWdhcmRz
IHRvIHlvdXIgcXVlc3Rpb246PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7
ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7IEdpdmVu
IHRoYXQgTm8tUmVzcG9uc2Ugbm93IGhhcyBhIG51bWJlcg0KKDI4NCkgZnJvbSBJQU5BIGluIHRo
ZSA8YnI+DQomZ3Q7IENvUkUgb3B0aW9uIHJlZ2lzdHJ5ICg8L2ZvbnQ+PC90dD48YSBocmVmPSJo
dHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2NvcmUtIj48dHQ+PGZvbnQgc2l6ZT0yPmh0
dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvY29yZS08L2ZvbnQ+PC90dD48L2E+PHR0Pjxm
b250IHNpemU9Mj48YnI+DQomZ3Q7IHBhcmFtZXRlcnMvY29yZS1wYXJhbWV0ZXJzLnhodG1sI29w
dGlvbi1udW1iZXJzKSBwcm9iYWJseSBpdCB3aWxsDQpiZTxicj4NCiZndDsgYSBnb29kIGlkZWEg
dG8ga2VlcCBhIHNlY3Rpb24gdG8gZGlzY3VzcyBob3cgdG8gaGFuZGxlIHRoaXMgb3B0aW9uDQo8
YnI+DQomZ3Q7IHNpbmNlIHRoaXMgaXMgbm90IHRoZXJlIGluIEhUVFAuIFNvbWV3aGVyZSBpbiBT
ZWN0aW9uIDggc2hvdWxkIGJlDQphIDxicj4NCiZndDsgZ29vZCBwbGFjZSBmb3Igc3VjaCBkaXNj
dXNzaW9uLiA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5i
c3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFllcywgSSBhZ3JlZSB0
aGlzIGlzIGEgZ29vZCB0b3BpYyB0byBhZGQgdG8gdGhlDQpkcmFmdC4gJm5ic3A7SG93IGFib3V0
IDxicj4NCiZndDsgc29tZXRoaW5nIGJhc2VkIG9uIHRoZSBmb2xsb3dpbmcgdGV4dDo8L2ZvbnQ+
PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+
PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDguOCBDb0FQIE5vIFJlc3BvbnNl
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0
Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBDb0FQIHN1cHBvcnRzIHNlbmRpbmcgYSBSZXF1
ZXN0IGluZGljYXRpbmcgdGhhdA0K4oCcTm8gUmVzcG9uc2XigJ0gaXMgPGJyPg0KJmd0OyByZXF1
aXJlZCB3aGVuIHRoZSBDb0FQIGhlYWRlciBvcHRpb24gbnVtYmVyIGlzIHNldCB0byAyODQuICZu
YnNwO0FuDQpIQyA8YnI+DQomZ3Q7IFByb3h5IG1heSB0cmFuc2xhdGUgYW4gaW5jb21pbmcgSFRU
UCBSZXF1ZXN0IHRvIGEgY29ycmVzcG9uZGluZyBDb0FQPGJyPg0KJmd0OyBSZXF1ZXN0IGluZGlj
YXRpbmcgdGhhdCBubyByZXNwb25zZSBpcyByZXF1aXJlZCBmb2xsb3dpbmcgdGhlIGd1aWRhbmNl
DQppbiA8YnI+DQomZ3Q7IChSZWY6IDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHA6Ly93d3cuaWFu
YS5vcmcvYXNzaWdubWVudHMvY29yZS1wYXJhbWV0ZXJzL2NvcmUtIj48dHQ+PGZvbnQgc2l6ZT0y
Pmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvY29yZS1wYXJhbWV0ZXJzL2NvcmUtPC9m
b250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyBwYXJhbWV0ZXJzLnhodG1s
I29wdGlvbi1udW1iZXJzKS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg
Jm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+
Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEFueSBmZWVkYmFjaz88L2Zv
bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u
dCBzaXplPTI+Jmd0OyAvQWtiYXI8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn
dDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwv
Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9tOiBjb3JlIFs8L2ZvbnQ+
PC90dD48YSBocmVmPSJtYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnIj48dHQ+PGZvbnQgc2l6
ZT0yPm1haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250
IHNpemU9Mj5dDQpPbiBCZWhhbGYgT2YgQWJoaWphbiBCaGF0dGFjaGFyeXlhPGJyPg0KJmd0OyBT
ZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDE3LCAyMDE1IDU6MzQgQU08YnI+DQomZ3Q7IFRvOiBD
YXJzdGVuIEJvcm1hbm4gJmx0O2NhYm9AdHppLm9yZyZndDs8YnI+DQomZ3Q7IENjOiBjb3JlICZs
dDtjb3JlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7OyBjb3JlQGlldGYub3JnIFdHICZsdDtjb3JlQGll
dGYub3JnJmd0Ozxicj4NCiZndDsgU3ViamVjdDogUmU6IFtjb3JlXSBXRyBsYXN0LWNhbGwgKFdH
TEMpIG9mIGRyYWZ0LWlldGYtY29yZS1odHRwLW1hcHBpbmctMDc8L2ZvbnQ+PC90dD4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp
emU9Mj4mZ3Q7IERlYXIgYWxsLCA8YnI+DQomZ3Q7IEkgdGhpbmsgdGhpcyBkcmFmdCBpcyBpbmRl
ZWQgYW4gYXBwcmVjaWFibGUgZWZmb3J0IGFzIGl0IHdpbGwgZWFzZQ0KPGJyPg0KJmd0OyBvdXQg
bWFueSBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbnMgZm9yIHRoZSBkZXZlbG9wZXJzIGFuZCBzaG91
bGQgYmUNCjxicj4NCiZndDsgdmVyeSB1c2VmdWwgYXMgYW4gUkZDLiA8YnI+DQomZ3Q7IDxicj4N
CiZndDsgRGVhciBhdXRob3JzLCA8YnI+DQomZ3Q7IEkgaGF2ZSBvbmUgc21hbGwgY29tbWVudCA6
IDxicj4NCiZndDsgR2l2ZW4gdGhhdCBOby1SZXNwb25zZSBub3cgaGFzIGEgbnVtYmVyICgyODQp
IGZyb20gSUFOQSBpbiB0aGUgQ29SRQ0KPGJyPg0KJmd0OyBvcHRpb24gcmVnaXN0cnkgKDwvZm9u
dD48L3R0PjxhIGhyZWY9Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvY29yZS1wYXJh
bWV0ZXJzLyI+PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRz
L2NvcmUtcGFyYW1ldGVycy88L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQom
Z3Q7IGNvcmUtcGFyYW1ldGVycy54aHRtbCNvcHRpb24tbnVtYmVycykgcHJvYmFibHkgaXQgd2ls
bCBiZSBhIGdvb2QgPGJyPg0KJmd0OyBpZGVhIHRvIGtlZXAgYSBzZWN0aW9uIHRvIGRpc2N1c3Mg
aG93IHRvIGhhbmRsZSB0aGlzIG9wdGlvbiBzaW5jZQ0KPGJyPg0KJmd0OyB0aGlzIGlzIG5vdCB0
aGVyZSBpbiBIVFRQLiBTb21ld2hlcmUgaW4gU2VjdGlvbiA4IHNob3VsZCBiZSBhIGdvb2QNCjxi
cj4NCiZndDsgcGxhY2UgZm9yIHN1Y2ggZGlzY3Vzc2lvbi4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IDxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzPGJyPg0KJmd0OyBBYmhpamFuIEJoYXR0YWNo
YXJ5eWE8YnI+DQomZ3Q7IEFzc29jaWF0ZSBDb25zdWx0YW50PGJyPg0KJmd0OyBTY2llbnRpc3Qs
IElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYTxicj4NCiZndDsgVGF0YSBDb25zdWx0YW5j
eSBTZXJ2aWNlczxicj4NCiZndDsgTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNv
bTxicj4NCiZndDsgV2Vic2l0ZTogPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwOi8vd3d3LnRjcy5j
b20vPjx0dD48Zm9udCBzaXplPTI+aHR0cDovL3d3dy50Y3MuY29tPC9mb250PjwvdHQ+PC9hPjx0
dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj4NCiZndDsgRXhwZXJpZW5jZSBjZXJ0YWludHkuICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwO0lUIFNlcnZpY2VzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw
OyAmbmJzcDtCdXNpbmVzcyBTb2x1dGlvbnM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7
ICZuYnNwO0NvbnN1bHRpbmc8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IEZyb206ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NhcnN0ZW4gQm9y
bWFubiAmbHQ7Y2Fib0B0emkub3JnJmd0Ow0KPGJyPg0KJmd0OyBUbzogJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7JnF1b3Q7PC9mb250PjwvdHQ+PGEgaHJlZj1tYWlsdG86Y29yZUBpZXRmLm9y
ZyUyMFdHPjx0dD48Zm9udCBzaXplPTI+bWFpbHRvOmNvcmVAaWV0Zi5vcmclMjBXRzwvZm9udD48
L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPiZxdW90Ow0KJmx0O2NvcmVAaWV0Zi5vcmcmZ3Q7IDxi
cj4NCiZndDsgRGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDkvMTUvMjAxNSAwODo1
MSBQTSA8YnI+DQomZ3Q7IFN1YmplY3Q6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tjb3Jl
XSBXRyBsYXN0LWNhbGwgKFdHTEMpIG9mDQpkcmFmdC1pZXRmLWNvcmUtaHR0cC1tYXBwaW5nLTA3
PGJyPg0KJmd0OyBTZW50IGJ5OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtjb3Jl
JnF1b3Q7ICZsdDtjb3JlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8L2ZvbnQ+PC90dD4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy
Pg0KJmd0OyBJbiBQcmFndWUsIHdlIHNhaWQgd2Ugd2VyZSBnb2luZyB0byBXR0xDIHRoZSBIVFRQ
IG1hcHBpbmcgZHJhZnQgYWZ0ZXI8YnI+DQomZ3Q7IGNsb3NlIG9mIHRoZSB2YWNhdGlvbiBwZXJp
b2QsIHdoaWNoIGlzIG5vdyBiZWhpbmQgdXMuICZuYnNwO0FsbCBvdXRzdGFuZGluZzxicj4NCiZn
dDsgdGlja2V0cyBhcmUgY2xvc2VkLCBhbmQgdGhlcmUgd2FzIGVub3VnaCB0aW1lIHRvIHJldmll
dyB0aGUgY3VycmVudDxicj4NCiZndDsgZHJhZnQuICZuYnNwO1RocmVlIHBlb3BsZSByYWlzZWQg
dGhlaXIgaGFuZHMgd2hlbiB3ZSBhc2tlZCB3aG8gd291bGQNCnN1Ym1pdDxicj4NCiZndDsgcmV2
aWV3cyAoTWljaGFlbCBLLiwgS2xhdXMsIERhcnNoYWspLCBidXQgb2YgY291cnNlIGFkZGl0aW9u
YWwgcmV2aWV3czxicj4NCiZndDsgYmV5b25kIHRoYXQgYXJlIGFsc28gdmVyeSB1c2VmdWwuPGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7IFNvIHRoaXMgc3RhcnRzIGEgd29ya2luZyBncm91cCBsYXN0IGNh
bGwgZm9yPGJyPg0KJmd0OyBkcmFmdC1pZXRmLWNvcmUtaHR0cC1tYXBwaW5nIGZvciBzdWJtaXNz
aW9uIGFzIGFuIGluZm9ybWF0aW9uYWwgUkZDLDxicj4NCiZndDsgZW5kaW5nIG9uPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IDI0OjAwIFBEVCBvbiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTUuPGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBkcmFmdCBpcyBsb2NhdGVkIGF0Ojxicj4NCiZndDsgPC9m
b250PjwvdHQ+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt
Y29yZS1odHRwLW1hcHBpbmctMDciPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1odHRwLW1hcHBpbmctMDc8L2ZvbnQ+PC90dD48L2E+
PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IDxicj4NCiZndDsgUGxlYXNlIHN0YXJ0IGEgbmV3
IGVtYWlsIHRocmVhZCBmb3IgZWFjaCBtYWpvciBpc3N1ZSB0aGF0IHdpbGwgbmVlZDxicj4NCiZn
dDsgZGlzY3Vzc2lvbiBhbmQgbWFrZSBzdXJlIHRoZSBzdWJqZWN0IGxpbmUgaW5jbHVkZXMgdGhl
IGRyYWZ0IG5hbWUNCmFuZDxicj4NCiZndDsgc29tZSBzb3J0IG9mIG5hbWUgZm9yIHRoZSBpc3N1
ZS4gRm9yIG1pbm9yIGlzc3VlcyBzdWNoIGFzIHR5cG9zIGFuZDxicj4NCiZndDsgdGhpbmdzIHRo
YXQgYXJlIG5vdCBsaWtlbHkgdG8gbGVhZCB0byBtdWNoIGRpc2N1c3Npb24sIGl0IGlzIHByb2Jh
Ymx5PGJyPg0KJmd0OyBlYXNpZXIgdG8gZ3JvdXAgdGhlbSBhbGwgaW4gdG8gb25lIGVtYWlsIGJ1
dCBhZ2FpbiwgcGxlYXNlIG1ha2Ugc3VyZTxicj4NCiZndDsgdGhlIHN1YmplY3QgbGluZSBpbmNs
dWRlcyB0aGUgZHJhZnQgbmFtZS4gSWYgeW91IHJlYWQgdGhlIGRyYWZ0IGFuZDxicj4NCiZndDsg
dGhpbmsgaXQgbG9va3MgZmluZSwgcGxlYXNlIHNlbmQgYSBvbmUgbGluZSBlbWFpbCB0byB0aGUg
bGlzdCBvciB0bzxicj4NCiZndDsgdGhlIGNoYWlycyBsZXR0aW5nIHVzIGtub3cgdGhhdCBzbyB3
ZSBjYW4gZ2V0IGEgZmVlbCBvZiBob3cgYnJvYWQNCnRoZTxicj4NCiZndDsgcmV2aWV3IGhhcyBi
ZWVuLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJbiB0aGUgdW5saWtlbHkgZXZlbnQgdGhhdCB5b3Ug
YXJlIGF3YXJlIG9mIGFueSBwYXRlbnQgY2xhaW1zIHRoYXQ8YnI+DQomZ3Q7IG1pZ2h0IGFwcGx5
IHRvIHN5c3RlbXMgdGhhdCBpbXBsZW1lbnQgdGhlIHN1Z2dlc3Rpb25zIGluIHRoaXMgZHJhZnQs
PGJyPg0KJmd0OyBwbGVhc2UgcmV2aWV3IEJDUCA3OCBhbmQgQkNQIDc5IGFuZCBtYWtlIGFueSBh
cHByb3ByaWF0ZSBJUFI8YnI+DQomZ3Q7IGRlY2xhcmF0aW9uLiBJZiB5b3UgYXJlIG5vdCBzdXJl
IHdoZXRoZXIgeW91IG5lZWQgdG8gbWFrZSBhPGJyPg0KJmd0OyBkZWNsYXJhdGlvbiBvciBub3Qs
IHBsZWFzZSB0YWxrIHRvIHRoZSBjaGFpcnMgYW5kIHdlIHdpbGwgaGVscCBnZXQNCnlvdTxicj4N
CiZndDsgaW4gdG91Y2ggd2l0aCBwZW9wbGUgdGhhdCBjYW4gcHJvdmlkZSBhcHByb3ByaWF0ZSBh
ZHZpY2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEdyw7zDn2UsIENhcnN0ZW48YnI+DQomZ3Q7IDxi
cj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQomZ3Q7IGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBjb3JlQGlldGYub3JnPGJyPg0K
Jmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vY29yZT48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vY29yZTwvZm9udD48L3R0PjwvYT4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg
PT09PT0tLS0tLT09PT09LS0tLS09PT09PTxicj4NCiZndDsgTm90aWNlOiBUaGUgaW5mb3JtYXRp
b24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsPGJyPg0KJmd0OyBtZXNzYWdlIGFuZC9vciBhdHRh
Y2htZW50cyB0byBpdCBtYXkgY29udGFpbiA8YnI+DQomZ3Q7IGNvbmZpZGVudGlhbCBvciBwcml2
aWxlZ2VkIGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIDxicj4NCiZndDsgbm90IHRoZSBpbnRlbmRl
ZCByZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0aW9uLCB1c2UsIDxicj4NCiZndDsgcmV2aWV3LCBk
aXN0cmlidXRpb24sIHByaW50aW5nIG9yIGNvcHlpbmcgb2YgdGhlIDxicj4NCiZndDsgaW5mb3Jt
YXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIG1lc3NhZ2UgPGJyPg0KJmd0OyBhbmQvb3Ig
YXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIDxicj4NCiZndDsg
eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCA8YnI+DQomZ3Q7
IHBsZWFzZSBub3RpZnkgdXMgYnkgcmVwbHkgZS1tYWlsIG9yIHRlbGVwaG9uZSBhbmQgPGJyPg0K
Jmd0OyBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdlIDxicj4N
CiZndDsgYW5kIGFueSBhdHRhY2htZW50cy4gVGhhbmsgeW91PC9mb250PjwvdHQ+DQo8YnI+PHR0
Pjxmb250IHNpemU9Mj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KJmd0OyBjb3JlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgY29yZUBpZXRm
Lm9yZzxicj4NCiZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2NvcmU+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8L2ZvbnQ+PC90dD48L2E+DQo=
--=_alternative 0046C32165257ECA_=--


From Akbar.Rahman@InterDigital.com  Thu Sep 24 10:00: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 1DD1F1B2A77 for ; Thu, 24 Sep 2015 10:00:26 -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, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] 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 WSj-KVyQN5IB for ; Thu, 24 Sep 2015 10:00:22 -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 43BAE1B2A7A for ; Thu, 24 Sep 2015 10:00:07 -0700 (PDT)
X-ASG-Debug-ID: 1443114001-06daaa455c343a0001-aa7cYp
Received: from NISSONITE.InterDigital.com (nissonite.interdigital.com [10.2.64.252]) by smtp-in1.interdigital.com with ESMTP id Gi6lAgSgGgIdTRlr (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Sep 2015 13:00:01 -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.0248.002; Thu, 24 Sep 2015 12:59:56 -0400
From: "Rahman, Akbar" 
To: Abhijan Bhattacharyya , weigengyu 
Thread-Topic: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
X-ASG-Orig-Subj: RE: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
Thread-Index: AQHQ78omyjBftircP0+PSVXhf7jhrZ5Au48AgAm4JqCAATDRAIAATs8A///7bzA=
Date: Thu, 24 Sep 2015 16:59:55 +0000
Message-ID: <36F5869FE31AB24485E5E3222C288E1F347BB47D@NABESITE.InterDigital.com>
References: <55F83752.3090609@tzi.org>  <36F5869FE31AB24485E5E3222C288E1F347BAE99@NABESITE.InterDigital.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.2.229]
x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd
Content-Type: multipart/alternative; boundary="_000_36F5869FE31AB24485E5E3222C288E1F347BB47DNABESITEInterDi_"
MIME-Version: 1.0
X-Barracuda-Connect: nissonite.interdigital.com[10.2.64.252]
X-Barracuda-Start-Time: 1443114001
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.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22861 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE           BODY: HTML included in message
Cc: core , "core@ietf.org" 
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
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, 24 Sep 2015 17:00:26 -0000

--_000_36F5869FE31AB24485E5E3222C288E1F347BB47DNABESITEInterDi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQWJoaWphbiwNCg0KDQpPa2F5LCBwbGVhc2UgcmV2aWV3IHRoZSB1cGRhdGVkIHByb3Bvc2Vk
IHRleHQgZm9yIGRyYWZ0LWlldGYtY29yZS1odHRwLW1hcHBpbmcgYmFzZWQgb24gdGhlIGZlZWRi
YWNrIGZyb20gQ2Fyc3RlbiwgV2VpZ2VuZ3l1IGFuZCB5b3UuDQoNCg0KLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCihOZXcpIFNlY3Rpb24gOC54IOKAnFVzZSBvZiBDb0FQIE5vIFJl
c3BvbnNl4oCdOg0KDQpDb0FQIHN1cHBvcnRzIHNlbmRpbmcgYSBSZXF1ZXN0IGluZGljYXRpbmcg
dGhhdCDigJxObyBSZXNwb25zZeKAnSBpcyByZXF1aXJlZCB3aGVuIHRoZSBDb0FQIGhlYWRlciBv
cHRpb24gbnVtYmVyIGlzIHNldCB0byAyODQgW3NlZSBSZWYtMV0uICBBbiBIQyBQcm94eSBtYXkg
dHJhbnNsYXRlIGFuIGluY29taW5nIEhUVFAgUmVxdWVzdCB0byBhIGNvcnJlc3BvbmRpbmcgQ29B
UCBSZXF1ZXN0IGluZGljYXRpbmcgdGhhdCBObyBSZXNwb25zZSBpcyByZXF1aXJlZCBiYXNlZCBv
biBzb21lIGFwcGxpY2F0aW9uIGtub3dsZWRnZSAoc2VlIFtSZWYtMl0gZm9yIGZ1cnRoZXIgZ3Vp
ZGFuY2UpLiAgSW4gdGhpcyBjYXNlLCBpdCBpcyByZWNvbW1lbmQgdGhhdCB0aGUgSEMgUHJveHkg
U0hPVUxEIHNlbmQgYW4gSFRUUCBSZXNwb25zZSB3aXRoIHN0YXR1cyBjb2RlIDIwNCAoTm8gQ29u
dGVudCkuDQoNCltSZWYtMV0gLSBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2NvcmUt
cGFyYW1ldGVycy9jb3JlLXBhcmFtZXRlcnMueGh0bWwjb3B0aW9uLW51bWJlcnMNCg0KW1JlZi0y
XSAtIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10Y3MtY29hcC1uby1yZXNwb25z
ZS1vcHRpb24tMTENCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KQWxz
bywgQWJoaWphbiwgaXQgbWF5IGJlIGdvb2QgZm9yIHlvdSB0byBwdXQgdGhlIGFwcGxpY2F0aW9u
IHNjZW5hcmlvIHlvdSBvdXRsaW5lZCBiZWxvdyBpbiB5b3VyIGRyYWZ0LXRjcy1jb2FwLW5vLXJl
c3BvbnNlLW9wdGlvbiBhcyB0aGF0IHNob3VsZCBiZSBkb2N1bWVudCB0aGF0IGNvbnRhaW5zIGFs
bCBzdWNoIGd1aWRhbmNlIGluZm9ybWF0aW9uLg0KDQoNCkRvIHlvdSBhZ3JlZT8NCg0KDQovQWti
YXINCg0KDQoNCkZyb206IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSBbbWFpbHRvOmFiaGlqYW4uYmhh
dHRhY2hhcnl5YUB0Y3MuY29tXQ0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyNCwgMjAxNSA4
OjUzIEFNDQpUbzogd2VpZ2VuZ3l1IDx3ZWlnZW5neXVAYnVwdC5lZHUuY24+OyBSYWhtYW4sIEFr
YmFyIDxBa2Jhci5SYWhtYW5ASW50ZXJEaWdpdGFsLmNvbT4NCkNjOiBDYXJzdGVuIEJvcm1hbm4g
PGNhYm9AdHppLm9yZz47IGNvcmVAaWV0Zi5vcmc7IGNvcmUgPGNvcmUtYm91bmNlc0BpZXRmLm9y
Zz4NClN1YmplY3Q6IFJlOiBbY29yZV0gV0cgbGFzdC1jYWxsIChXR0xDKSBvZiBkcmFmdC1pZXRm
LWNvcmUtaHR0cC1tYXBwaW5nLTA3DQoNCkhpIEFrYmFyLA0KVGhhbmtzLg0KDQpUYWtpbmcgY2x1
ZSBmcm9tIEdlbmd5dSdzIHJlc3BvbnNlIEkgd291bGQgbGlrZSB0byBzaGFyZSB0aGUgZm9sbG93
aW5nIGlucHV0Og0KDQpUaGUgZGVjaXNpb24gdG8gY29udmVydCBhbiBIVFRQIHJlcXVlc3QgdG8g
YSBDb0FQIHJlcXVlc3Qgd2l0aCAiTm8gUmVzcG9uc2UiIHNob3VsZCBiZSBwdXJlbHkgYmFzZWQg
b24gdGhlIGFwcGxpY2F0aW9uIGNvbnRleHQuDQpMZXQgdXMgY29uc2lkZXIgYSBzY2VuYXJpby4N
CldlIHdhbnQgdG8gb3BlcmF0ZSB0aGUgbGlnaHRzIG9mIGEgYnVpbGRpbmcgZnJvbSBhIHJlbW90
ZSBjb250cm9sLWNlbnRlciAoY29udHJvbGxpbmcgY29tbWFuZHMgbWF5IG5vdCBiZSBlc3NlbnRp
YWxseSBtdWx0aWNhc3QpLiBMZXQgdXMgYXNzdW1lIHRoYXQgdGhlIGNvbnRyb2wtY2VudGVyIGhh
cyBsZWdhY3kgSFRUUCBpbmZyYXN0cnVjdHVyZS4gQnV0IHRoZSBsaWdodHMgYXJlIENvQVAgZW5h
YmxlZC4gU28gdGhlIHJlcXVlc3RzIGZyb20gdGhlIGNvbnRyb2wtY2VudGVyIGdvZXMgdGhyb3Vn
aCBhbiBIQyBwcm94eS4gVGhlIGFwcGxpY2F0aW9uIHJlcXVpcmVtZW50LCBpbiB0aGF0IGNhc2Us
IHdpbGwgZGVjaWRlIHdoZXRoZXIgdGhlIHJlcXVlc3RzIGZyb20gSFRUUCBjbGllbnQgYXJlIHRv
IGJlIG1hZGUgQ29BUCByZXF1ZXN0cyB3aXRoIE5vLVJlc3BvbnNlIG9yIG5vdC4NCg0KQnV0LCB0
aGVyZSBpcyBvbmUgcG9pbnQuIFRoZSBIVFRQIGNsaWVudCBuZWVkcyBhIHJlc3BvbnNlIGFzIHBl
ciB0aGUgSFRUUCBwcm90b2NvbCByZXF1aXJlbWVudHMuIFNvLCB3aGF0IHJlc3BvbnNlIHNob3Vs
ZCBwcm94eSByZXR1cm4/DQpMb29raW5nIGF0IFRhYmxlIDIgb2YgdGhlIGh0dHAgbWFwcGluZyBk
cmFmdCB3ZSBzZWUgdGhhdCBDb0FQJ3MgMi4wNCAoQ2hhbmdlZCkgaXMgbWFwcGVkIHRvIGVpdGhl
ciAyMDAgKE9LKSBvciAyMDQgKE5vIENvbnRlbnQpIGZvciB0aGUgSFRUUC4gQ2FuIHdlIHN1Z2dl
c3QgdGhhdCBpbiBjYXNlcyBhcyBkZXNjcmliZWQgYWJvdmUgdGhlIHByb3h5IFNIT1VMRCByZXNw
b25kIHdpdGggdGhlIHN0YXR1cyBjb2RlOiAyMDQgIE5vIENvbnRlbnQgPyBUaGlzIHdheSB0aGUg
Y2xpZW50IGtub3dzIHRoYXQgTm8tUmVzcG9uc2UgaXMgZW5hYmxlZCBhdCB0aGUgQ29BUCBzaWRl
IGZvciB0aGUgcGFydGljdWxhciBQVVRzLg0KDQpEb2VzIGl0IG1ha2Ugc2Vuc2U/DQoNCg0KUmVn
YXJkcw0KQWJoaWphbiBCaGF0dGFjaGFyeXlhDQpBc3NvY2lhdGUgQ29uc3VsdGFudA0KU2NpZW50
aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWENClRhdGEgQ29uc3VsdGFuY3kgU2Vy
dmljZXMNCk1haWx0bzogYWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb208bWFpbHRvOmFiaGlq
YW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPg0KV2Vic2l0ZTogaHR0cDovL3d3dy50Y3MuY29tPGh0
dHA6Ly93d3cudGNzLmNvbS8+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KRXhwZXJpZW5jZSBjZXJ0YWludHkuICAgICAgICBJVCBTZXJ2aWNlcw0KICAgICAg
ICAgICAgICAgICAgICAgICBCdXNpbmVzcyBTb2x1dGlvbnMNCiAgICAgICAgICAgICAgICAgICAg
ICAgQ29uc3VsdGluZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCg0KDQoid2VpZ2VuZ3l1IiA8d2VpZ2VuZ3l1QGJ1cHQuZWR1LmNuPG1haWx0bzp3ZWlnZW5n
eXVAYnVwdC5lZHUuY24+PiB3cm90ZSBvbiAwOS8yNC8yMDE1IDAxOjQwOjUwIFBNOg0KDQo+IEZy
b206ICJ3ZWlnZW5neXUiIDx3ZWlnZW5neXVAYnVwdC5lZHUuY248bWFpbHRvOndlaWdlbmd5dUBi
dXB0LmVkdS5jbj4+DQo+IFRvOiAiUmFobWFuLCBBa2JhciIgPEFrYmFyLlJhaG1hbkBJbnRlckRp
Z2l0YWwuY29tPG1haWx0bzpBa2Jhci5SYWhtYW5ASW50ZXJEaWdpdGFsLmNvbT4+LCAiQWJoaWph
bg0KPiBCaGF0dGFjaGFyeXlhIiA8YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb208bWFpbHRv
OmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPj4sICJDYXJzdGVuIEJvcm1hbm4iDQo+IDxj
YWJvQHR6aS5vcmc8bWFpbHRvOmNhYm9AdHppLm9yZz4+DQo+IENjOiA8Y29yZUBpZXRmLm9yZzxt
YWlsdG86Y29yZUBpZXRmLm9yZz4+LCAiY29yZSIgPGNvcmUtYm91bmNlc0BpZXRmLm9yZzxtYWls
dG86Y29yZS1ib3VuY2VzQGlldGYub3JnPj4NCj4gRGF0ZTogMDkvMjQvMjAxNSAwMTo1MCBQTQ0K
PiBTdWJqZWN0OiBSZTogW2NvcmVdIFdHIGxhc3QtY2FsbCAoV0dMQykgb2YgZHJhZnQtaWV0Zi1j
b3JlLWh0dHAtbWFwcGluZy0wNw0KPg0KPiBIae+8jA0KPg0KPiBXaGVuIGEgaHR0cCBjbGllbnQg
YWNjZXNzZXMgYSBDb0FQIHNlcnZlciwNCj4gaG93IGRvZXMgdGhlIENvQVAgY2xpZW50IG9mIEhD
IHByb3h5IGNyZWF0ZSBhIE5PTi1yZXBvc25zZSBvcHRpb24NCj4gc2luY2UgdGhlcmUgaXMgbm90
IGluIEhUVFAuDQo+IE9yIGl0IGlzIHVzZWxlc3MgZm9yIEhDIHByb3h5LCBvciBub3Q/DQo+DQo+
IFJlZ2FyZHMsDQo+DQo+IEdlbmd5dSBXRUkNCj4gTmV0d29yayBUZWNobm9sb2d5IENlbnRlcg0K
PiBTY2hvb2wgb2YgQ29tcHV0ZXINCj4gQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBU
ZWxlY29tbXVuaWNhdGlvbnMNCj4NCj4gRnJvbTogUmFobWFuLCBBa2Jhcg0KPiBTZW50OiBUaHVy
c2RheSwgU2VwdGVtYmVyIDI0LCAyMDE1IDI6MDAgQU0NCj4gVG86IEFiaGlqYW4gQmhhdHRhY2hh
cnl5YSA7IENhcnN0ZW4gQm9ybWFubg0KPiBDYzogbWFpbHRvOmNvcmVAaWV0Zi5vcmcgOyBjb3Jl
DQo+IFN1YmplY3Q6IFJlOiBbY29yZV0gV0cgbGFzdC1jYWxsIChXR0xDKSBvZiBkcmFmdC1pZXRm
LWNvcmUtaHR0cC1tYXBwaW5nLTA3DQo+DQo+IEhpIEFiaGlqYW4sDQo+DQo+DQo+IFRoYW5rcyBm
b3IgeW91ciBzdXBwb3J0IG9uIHRoZSBkcmFmdCENCj4NCj4gV2l0aCByZWdhcmRzIHRvIHlvdXIg
cXVlc3Rpb246DQo+DQo+ID4gR2l2ZW4gdGhhdCBOby1SZXNwb25zZSBub3cgaGFzIGEgbnVtYmVy
ICgyODQpIGZyb20gSUFOQSBpbiB0aGUNCj4gQ29SRSBvcHRpb24gcmVnaXN0cnkgKGh0dHA6Ly93
d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvY29yZS0NCj4gcGFyYW1ldGVycy9jb3JlLXBhcmFtZXRl
cnMueGh0bWwjb3B0aW9uLW51bWJlcnMpIHByb2JhYmx5IGl0IHdpbGwgYmUNCj4gYSBnb29kIGlk
ZWEgdG8ga2VlcCBhIHNlY3Rpb24gdG8gZGlzY3VzcyBob3cgdG8gaGFuZGxlIHRoaXMgb3B0aW9u
DQo+IHNpbmNlIHRoaXMgaXMgbm90IHRoZXJlIGluIEhUVFAuIFNvbWV3aGVyZSBpbiBTZWN0aW9u
IDggc2hvdWxkIGJlIGENCj4gZ29vZCBwbGFjZSBmb3Igc3VjaCBkaXNjdXNzaW9uLg0KDQo+DQo+
IFllcywgSSBhZ3JlZSB0aGlzIGlzIGEgZ29vZCB0b3BpYyB0byBhZGQgdG8gdGhlIGRyYWZ0LiAg
SG93IGFib3V0DQo+IHNvbWV0aGluZyBiYXNlZCBvbiB0aGUgZm9sbG93aW5nIHRleHQ6DQo+DQo+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IDguOCBDb0FQIE5vIFJlc3BvbnNl
DQo+DQo+IENvQVAgc3VwcG9ydHMgc2VuZGluZyBhIFJlcXVlc3QgaW5kaWNhdGluZyB0aGF0IOKA
nE5vIFJlc3BvbnNl4oCdIGlzDQo+IHJlcXVpcmVkIHdoZW4gdGhlIENvQVAgaGVhZGVyIG9wdGlv
biBudW1iZXIgaXMgc2V0IHRvIDI4NC4gIEFuIEhDDQo+IFByb3h5IG1heSB0cmFuc2xhdGUgYW4g
aW5jb21pbmcgSFRUUCBSZXF1ZXN0IHRvIGEgY29ycmVzcG9uZGluZyBDb0FQDQo+IFJlcXVlc3Qg
aW5kaWNhdGluZyB0aGF0IG5vIHJlc3BvbnNlIGlzIHJlcXVpcmVkIGZvbGxvd2luZyB0aGUgZ3Vp
ZGFuY2UgaW4NCj4gKFJlZjogaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9jb3JlLXBh
cmFtZXRlcnMvY29yZS0NCj4gcGFyYW1ldGVycy54aHRtbCNvcHRpb24tbnVtYmVycykuDQo+DQo+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPg0KPiBBbnkgZmVlZGJhY2s/
DQo+DQo+DQo+IC9Ba2Jhcg0KPg0KPg0KPiBGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2Vz
QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWJoaWphbiBCaGF0dGFjaGFyeXlhDQo+IFNlbnQ6IFRo
dXJzZGF5LCBTZXB0ZW1iZXIgMTcsIDIwMTUgNTozNCBBTQ0KPiBUbzogQ2Fyc3RlbiBCb3JtYW5u
IDxjYWJvQHR6aS5vcmc8bWFpbHRvOmNhYm9AdHppLm9yZz4+DQo+IENjOiBjb3JlIDxjb3JlLWJv
dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZz4+OyBjb3JlQGlldGYu
b3JnPG1haWx0bzpjb3JlQGlldGYub3JnPiBXRyA8Y29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBp
ZXRmLm9yZz4+DQo+IFN1YmplY3Q6IFJlOiBbY29yZV0gV0cgbGFzdC1jYWxsIChXR0xDKSBvZiBk
cmFmdC1pZXRmLWNvcmUtaHR0cC1tYXBwaW5nLTA3DQo+DQo+IERlYXIgYWxsLA0KPiBJIHRoaW5r
IHRoaXMgZHJhZnQgaXMgaW5kZWVkIGFuIGFwcHJlY2lhYmxlIGVmZm9ydCBhcyBpdCB3aWxsIGVh
c2UNCj4gb3V0IG1hbnkgaW1wbGVtZW50YXRpb24gZGVjaXNpb25zIGZvciB0aGUgZGV2ZWxvcGVy
cyBhbmQgc2hvdWxkIGJlDQo+IHZlcnkgdXNlZnVsIGFzIGFuIFJGQy4NCj4NCj4gRGVhciBhdXRo
b3JzLA0KPiBJIGhhdmUgb25lIHNtYWxsIGNvbW1lbnQgOg0KPiBHaXZlbiB0aGF0IE5vLVJlc3Bv
bnNlIG5vdyBoYXMgYSBudW1iZXIgKDI4NCkgZnJvbSBJQU5BIGluIHRoZSBDb1JFDQo+IG9wdGlv
biByZWdpc3RyeSAoaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9jb3JlLXBhcmFtZXRl
cnMvDQo+IGNvcmUtcGFyYW1ldGVycy54aHRtbCNvcHRpb24tbnVtYmVycykgcHJvYmFibHkgaXQg
d2lsbCBiZSBhIGdvb2QNCj4gaWRlYSB0byBrZWVwIGEgc2VjdGlvbiB0byBkaXNjdXNzIGhvdyB0
byBoYW5kbGUgdGhpcyBvcHRpb24gc2luY2UNCj4gdGhpcyBpcyBub3QgdGhlcmUgaW4gSFRUUC4g
U29tZXdoZXJlIGluIFNlY3Rpb24gOCBzaG91bGQgYmUgYSBnb29kDQo+IHBsYWNlIGZvciBzdWNo
IGRpc2N1c3Npb24uDQo+DQo+DQo+DQo+IFJlZ2FyZHMNCj4gQWJoaWphbiBCaGF0dGFjaGFyeXlh
DQo+IEFzc29jaWF0ZSBDb25zdWx0YW50DQo+IFNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtv
bGthdGEsIEluZGlhDQo+IFRhdGEgQ29uc3VsdGFuY3kgU2VydmljZXMNCj4gTWFpbHRvOiBhYmhp
amFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTxtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRj
cy5jb20+DQo+IFdlYnNpdGU6IGh0dHA6Ly93d3cudGNzLmNvbTxodHRwOi8vd3d3LnRjcy5jb20v
Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFeHBl
cmllbmNlIGNlcnRhaW50eS4gICAgICAgIElUIFNlcnZpY2VzDQo+ICAgICAgICAgICAgICAgICAg
ICAgICAgQnVzaW5lc3MgU29sdXRpb25zDQo+ICAgICAgICAgICAgICAgICAgICAgICAgQ29uc3Vs
dGluZw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0K
Pg0KPg0KPg0KPiBGcm9tOiAgICAgICAgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc8bWFp
bHRvOmNhYm9AdHppLm9yZz4+DQo+IFRvOiAgICAgICAgIm1haWx0bzpjb3JlQGlldGYub3JnJTIw
V0ciIDxjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPj4NCj4gRGF0ZTogICAgICAg
IDA5LzE1LzIwMTUgMDg6NTEgUE0NCj4gU3ViamVjdDogICAgICAgIFtjb3JlXSBXRyBsYXN0LWNh
bGwgKFdHTEMpIG9mIGRyYWZ0LWlldGYtY29yZS1odHRwLW1hcHBpbmctMDcNCj4gU2VudCBieTog
ICAgICAgICJjb3JlIiA8Y29yZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjb3JlLWJvdW5jZXNA
aWV0Zi5vcmc+Pg0KPg0KPg0KPg0KPg0KPiBJbiBQcmFndWUsIHdlIHNhaWQgd2Ugd2VyZSBnb2lu
ZyB0byBXR0xDIHRoZSBIVFRQIG1hcHBpbmcgZHJhZnQgYWZ0ZXINCj4gY2xvc2Ugb2YgdGhlIHZh
Y2F0aW9uIHBlcmlvZCwgd2hpY2ggaXMgbm93IGJlaGluZCB1cy4gIEFsbCBvdXRzdGFuZGluZw0K
PiB0aWNrZXRzIGFyZSBjbG9zZWQsIGFuZCB0aGVyZSB3YXMgZW5vdWdoIHRpbWUgdG8gcmV2aWV3
IHRoZSBjdXJyZW50DQo+IGRyYWZ0LiAgVGhyZWUgcGVvcGxlIHJhaXNlZCB0aGVpciBoYW5kcyB3
aGVuIHdlIGFza2VkIHdobyB3b3VsZCBzdWJtaXQNCj4gcmV2aWV3cyAoTWljaGFlbCBLLiwgS2xh
dXMsIERhcnNoYWspLCBidXQgb2YgY291cnNlIGFkZGl0aW9uYWwgcmV2aWV3cw0KPiBiZXlvbmQg
dGhhdCBhcmUgYWxzbyB2ZXJ5IHVzZWZ1bC4NCj4NCj4gU28gdGhpcyBzdGFydHMgYSB3b3JraW5n
IGdyb3VwIGxhc3QgY2FsbCBmb3INCj4gZHJhZnQtaWV0Zi1jb3JlLWh0dHAtbWFwcGluZyBmb3Ig
c3VibWlzc2lvbiBhcyBhbiBpbmZvcm1hdGlvbmFsIFJGQywNCj4gZW5kaW5nIG9uDQo+DQo+IDI0
OjAwIFBEVCBvbiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTUuDQo+DQo+IFRoZSBkcmFmdCBp
cyBsb2NhdGVkIGF0Og0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j
b3JlLWh0dHAtbWFwcGluZy0wNw0KPg0KPiBQbGVhc2Ugc3RhcnQgYSBuZXcgZW1haWwgdGhyZWFk
IGZvciBlYWNoIG1ham9yIGlzc3VlIHRoYXQgd2lsbCBuZWVkDQo+IGRpc2N1c3Npb24gYW5kIG1h
a2Ugc3VyZSB0aGUgc3ViamVjdCBsaW5lIGluY2x1ZGVzIHRoZSBkcmFmdCBuYW1lIGFuZA0KPiBz
b21lIHNvcnQgb2YgbmFtZSBmb3IgdGhlIGlzc3VlLiBGb3IgbWlub3IgaXNzdWVzIHN1Y2ggYXMg
dHlwb3MgYW5kDQo+IHRoaW5ncyB0aGF0IGFyZSBub3QgbGlrZWx5IHRvIGxlYWQgdG8gbXVjaCBk
aXNjdXNzaW9uLCBpdCBpcyBwcm9iYWJseQ0KPiBlYXNpZXIgdG8gZ3JvdXAgdGhlbSBhbGwgaW4g
dG8gb25lIGVtYWlsIGJ1dCBhZ2FpbiwgcGxlYXNlIG1ha2Ugc3VyZQ0KPiB0aGUgc3ViamVjdCBs
aW5lIGluY2x1ZGVzIHRoZSBkcmFmdCBuYW1lLiBJZiB5b3UgcmVhZCB0aGUgZHJhZnQgYW5kDQo+
IHRoaW5rIGl0IGxvb2tzIGZpbmUsIHBsZWFzZSBzZW5kIGEgb25lIGxpbmUgZW1haWwgdG8gdGhl
IGxpc3Qgb3IgdG8NCj4gdGhlIGNoYWlycyBsZXR0aW5nIHVzIGtub3cgdGhhdCBzbyB3ZSBjYW4g
Z2V0IGEgZmVlbCBvZiBob3cgYnJvYWQgdGhlDQo+IHJldmlldyBoYXMgYmVlbi4NCj4NCj4gSW4g
dGhlIHVubGlrZWx5IGV2ZW50IHRoYXQgeW91IGFyZSBhd2FyZSBvZiBhbnkgcGF0ZW50IGNsYWlt
cyB0aGF0DQo+IG1pZ2h0IGFwcGx5IHRvIHN5c3RlbXMgdGhhdCBpbXBsZW1lbnQgdGhlIHN1Z2dl
c3Rpb25zIGluIHRoaXMgZHJhZnQsDQo+IHBsZWFzZSByZXZpZXcgQkNQIDc4IGFuZCBCQ1AgNzkg
YW5kIG1ha2UgYW55IGFwcHJvcHJpYXRlIElQUg0KPiBkZWNsYXJhdGlvbi4gSWYgeW91IGFyZSBu
b3Qgc3VyZSB3aGV0aGVyIHlvdSBuZWVkIHRvIG1ha2UgYQ0KPiBkZWNsYXJhdGlvbiBvciBub3Qs
IHBsZWFzZSB0YWxrIHRvIHRoZSBjaGFpcnMgYW5kIHdlIHdpbGwgaGVscCBnZXQgeW91DQo+IGlu
IHRvdWNoIHdpdGggcGVvcGxlIHRoYXQgY2FuIHByb3ZpZGUgYXBwcm9wcmlhdGUgYWR2aWNlLg0K
Pg0KPiBHcsO8w59lLCBDYXJzdGVuDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmc8
bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vY29yZQ0KPiA9PT09PS0tLS0tPT09PT0tLS0tLT09PT09DQo+IE5vdGljZTogVGhlIGlu
Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbA0KPiBtZXNzYWdlIGFuZC9vciBhdHRh
Y2htZW50cyB0byBpdCBtYXkgY29udGFpbg0KPiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp
bmZvcm1hdGlvbi4gSWYgeW91IGFyZQ0KPiBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55
IGRpc3NlbWluYXRpb24sIHVzZSwNCj4gcmV2aWV3LCBkaXN0cmlidXRpb24sIHByaW50aW5nIG9y
IGNvcHlpbmcgb2YgdGhlDQo+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBt
ZXNzYWdlDQo+IGFuZC9vciBhdHRhY2htZW50cyB0byBpdCBhcmUgc3RyaWN0bHkgcHJvaGliaXRl
ZC4gSWYNCj4geW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLA0K
PiBwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhvbmUgYW5kDQo+IGlt
bWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG1lc3NhZ2UNCj4gYW5kIGFueSBh
dHRhY2htZW50cy4gVGhhbmsgeW91DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmc8bWFp
bHRvOmNvcmVAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vY29yZQ0K

--_000_36F5869FE31AB24485E5E3222C288E1F347BB47DNABESITEInterDi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdv
dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p
dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy
Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw
ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1p
bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpw
ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv
cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u
MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPkhpIEFiaGlqYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T2theSwgcGxlYXNlIHJldmlldyB0
aGUgdXBkYXRlZCBwcm9wb3NlZCB0ZXh0IGZvciBkcmFmdC1pZXRmLWNvcmUtaHR0cC1tYXBwaW5n
IGJhc2VkIG9uIHRoZSBmZWVkYmFjayBmcm9tIENhcnN0ZW4sIFdlaWdlbmd5dSBhbmQgeW91Ljxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPihOZXcpIFNlY3Rpb24gOC54IOKAnFVzZSBvZiBDb0FQIE5vIFJlc3BvbnNl4oCdOjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q29BUCBzdXBwb3J0cyBzZW5k
aW5nIGEgUmVxdWVzdCBpbmRpY2F0aW5nIHRoYXQg4oCcTm8gUmVzcG9uc2XigJ0gaXMgcmVxdWly
ZWQgd2hlbiB0aGUgQ29BUCBoZWFkZXIgb3B0aW9uIG51bWJlciBpcyBzZXQgdG8gMjg0IFtzZWUg
UmVmLTFdLiZuYnNwOyBBbiBIQyBQcm94eSBtYXkgdHJhbnNsYXRlDQogYW4gaW5jb21pbmcgSFRU
UCBSZXF1ZXN0IHRvIGEgY29ycmVzcG9uZGluZyBDb0FQIFJlcXVlc3QgaW5kaWNhdGluZyB0aGF0
IE5vIFJlc3BvbnNlIGlzIHJlcXVpcmVkIGJhc2VkIG9uIHNvbWUgYXBwbGljYXRpb24ga25vd2xl
ZGdlIChzZWUgW1JlZi0yXSBmb3IgZnVydGhlciBndWlkYW5jZSkuJm5ic3A7IEluIHRoaXMgY2Fz
ZSwgaXQgaXMgcmVjb21tZW5kIHRoYXQgdGhlIEhDIFByb3h5IFNIT1VMRCBzZW5kIGFuIEhUVFAg
UmVzcG9uc2Ugd2l0aCBzdGF0dXMNCiBjb2RlIDIwNCAoTm8gQ29udGVudCkuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUmVmLTFdPC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy
aWYiPiAtDQo8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9j
b3JlLXBhcmFtZXRlcnMvY29yZS1wYXJhbWV0ZXJzLnhodG1sI29wdGlvbi1udW1iZXJzIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz
YW5zLXNlcmlmIj5odHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2NvcmUtcGFyYW1ldGVy
cy9jb3JlLXBhcmFtZXRlcnMueGh0bWwjb3B0aW9uLW51bWJlcnM8L3NwYW4+PC9hPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUmVmLTJdIC0NCjxhIGhyZWY9Imh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1vcHRpb24tMTEi
Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS1v
cHRpb24tMTE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+QWxzbywgQWJoaWphbiwgaXQgbWF5IGJlIGdvb2QgZm9yIHlvdSB0byBwdXQgdGhlIGFw
cGxpY2F0aW9uIHNjZW5hcmlvIHlvdSBvdXRsaW5lZCBiZWxvdyBpbiB5b3VyIGRyYWZ0LXRjcy1j
b2FwLW5vLXJlc3BvbnNlLW9wdGlvbiBhcyB0aGF0IHNob3VsZCBiZSBkb2N1bWVudA0KIHRoYXQg
Y29udGFpbnMgYWxsIHN1Y2ggZ3VpZGFuY2UgaW5mb3JtYXRpb24uPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RG8geW91
IGFncmVlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPi9Ba2JhcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSBbbWFpbHRv
OmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz
ZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTUgODo1MyBBTTxicj4NCjxiPlRvOjwvYj4gd2VpZ2VuZ3l1
ICZsdDt3ZWlnZW5neXVAYnVwdC5lZHUuY24mZ3Q7OyBSYWhtYW4sIEFrYmFyICZsdDtBa2Jhci5S
YWhtYW5ASW50ZXJEaWdpdGFsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IENhcnN0ZW4gQm9ybWFu
biAmbHQ7Y2Fib0B0emkub3JnJmd0OzsgY29yZUBpZXRmLm9yZzsgY29yZSAmbHQ7Y29yZS1ib3Vu
Y2VzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2NvcmVdIFdHIGxhc3Qt
Y2FsbCAoV0dMQykgb2YgZHJhZnQtaWV0Zi1jb3JlLWh0dHAtbWFwcGluZy0wNzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SGkgQWtiYXIsPC9zcGFuPg0KPGJy
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzLjwvc3Bhbj4gPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp
ZiI+VGFraW5nIGNsdWUgZnJvbSBHZW5neXUncyByZXNwb25zZSBJIHdvdWxkIGxpa2UgdG8gc2hh
cmUgdGhlIGZvbGxvd2luZyBpbnB1dDo8L3NwYW4+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm
Ij5UaGUgZGVjaXNpb24gdG8gY29udmVydCBhbiBIVFRQIHJlcXVlc3QgdG8gYSBDb0FQIHJlcXVl
c3Qgd2l0aCAmcXVvdDtObyBSZXNwb25zZSZxdW90OyBzaG91bGQgYmUgcHVyZWx5IGJhc2VkIG9u
IHRoZSBhcHBsaWNhdGlvbiBjb250ZXh0Lg0KPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkxl
dCB1cyBjb25zaWRlciBhIHNjZW5hcmlvLg0KPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPldl
IHdhbnQgdG8gb3BlcmF0ZSB0aGUgbGlnaHRzIG9mIGEgYnVpbGRpbmcgZnJvbSBhIHJlbW90ZSBj
b250cm9sLWNlbnRlciAoY29udHJvbGxpbmcgY29tbWFuZHMgbWF5IG5vdCBiZSBlc3NlbnRpYWxs
eSBtdWx0aWNhc3QpLiBMZXQgdXMgYXNzdW1lIHRoYXQgdGhlIGNvbnRyb2wtY2VudGVyIGhhcyBs
ZWdhY3kgSFRUUCBpbmZyYXN0cnVjdHVyZS4NCiBCdXQgdGhlIGxpZ2h0cyBhcmUgQ29BUCBlbmFi
bGVkLiBTbyB0aGUgcmVxdWVzdHMgZnJvbSB0aGUgY29udHJvbC1jZW50ZXIgZ29lcyB0aHJvdWdo
IGFuIEhDIHByb3h5LiBUaGUgYXBwbGljYXRpb24gcmVxdWlyZW1lbnQsIGluIHRoYXQgY2FzZSwg
d2lsbCBkZWNpZGUgd2hldGhlciB0aGUgcmVxdWVzdHMgZnJvbSBIVFRQIGNsaWVudCBhcmUgdG8g
YmUgbWFkZSBDb0FQIHJlcXVlc3RzIHdpdGggTm8tUmVzcG9uc2Ugb3Igbm90Lg0KPC9zcGFuPjxi
cj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkJ1dCwgdGhlcmUgaXMgb25lIHBvaW50LiBUaGUgSFRU
UCBjbGllbnQgbmVlZHMgYSByZXNwb25zZSBhcyBwZXIgdGhlIEhUVFAgcHJvdG9jb2wgcmVxdWly
ZW1lbnRzLiBTbywgd2hhdCByZXNwb25zZSBzaG91bGQgcHJveHkgcmV0dXJuPw0KPC9zcGFuPjxi
cj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LHNhbnMtc2VyaWYiPkxvb2tpbmcgYXQgVGFibGUgMiBvZiB0aGUgaHR0cCBtYXBwaW5n
IGRyYWZ0IHdlIHNlZSB0aGF0IENvQVAncyAyLjA0IChDaGFuZ2VkKSBpcyBtYXBwZWQgdG8gZWl0
aGVyIDIwMCAoT0spIG9yIDIwNCAoTm8gQ29udGVudCkgZm9yIHRoZSBIVFRQLiBDYW4gd2Ugc3Vn
Z2VzdCB0aGF0IGluIGNhc2VzIGFzIGRlc2NyaWJlZCBhYm92ZSB0aGUgcHJveHkNCiBTSE9VTEQg
cmVzcG9uZCB3aXRoIHRoZSBzdGF0dXMgY29kZTogPGI+MjA0PC9iPiAmbmJzcDtObyBDb250ZW50
ID8gVGhpcyB3YXkgdGhlIGNsaWVudCBrbm93cyB0aGF0IE5vLVJlc3BvbnNlIGlzIGVuYWJsZWQg
YXQgdGhlIENvQVAgc2lkZSBmb3IgdGhlIHBhcnRpY3VsYXIgUFVUcy48L3NwYW4+DQo8YnI+DQo8
YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OyxzYW5zLXNlcmlmIj5Eb2VzIGl0IG1ha2Ugc2Vuc2U/PC9zcGFuPg0KPGJyPg0KPGJy
Pg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkczxicj4NCkFiaGlqYW4gQmhhdHRhY2hhcnl5
YTxicj4NCkFzc29jaWF0ZSBDb25zdWx0YW50PGJyPg0KU2NpZW50aXN0LCBJbm5vdmF0aW9uIExh
YiwgS29sa2F0YSwgSW5kaWE8YnI+DQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzPGJyPg0KTWFp
bHRvOiA8YSBocmVmPSJtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20iPmFiaGlq
YW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPC9hPjxicj4NCldlYnNpdGU6IDwvc3Bhbj48YSBocmVm
PSJodHRwOi8vd3d3LnRjcy5jb20vIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5odHRwOi8vd3d3LnRjcy5jb208
L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fPGJyPg0KRXhwZXJpZW5jZSBjZXJ0YWludHkuICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwO0lUIFNlcnZpY2VzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDtCdXNpbmVzcyBTb2x1dGlvbnM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NvbnN1
bHRpbmc8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi
cj4NCjwvc3Bhbj48YnI+DQo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi
PiZxdW90O3dlaWdlbmd5dSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndlaWdlbmd5dUBidXB0
LmVkdS5jbiI+d2VpZ2VuZ3l1QGJ1cHQuZWR1LmNuPC9hPiZndDsgd3JvdGUgb24gMDkvMjQvMjAx
NSAwMTo0MDo1MCBQTTo8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPGJyPg0KPHR0PiZndDsg
RnJvbTogJnF1b3Q7d2VpZ2VuZ3l1JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86d2VpZ2VuZ3l1
QGJ1cHQuZWR1LmNuIj53ZWlnZW5neXVAYnVwdC5lZHUuY248L2E+Jmd0OzwvdHQ+PC9zcGFuPg0K
PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IFRvOiAmcXVvdDtS
YWhtYW4sIEFrYmFyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86QWtiYXIuUmFobWFuQEludGVy
RGlnaXRhbC5jb20iPkFrYmFyLlJhaG1hbkBJbnRlckRpZ2l0YWwuY29tPC9hPiZndDssICZxdW90
O0FiaGlqYW4NCjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyBCaGF0dGFjaGFy
eXlhJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5j
b20iPmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPC9hPiZndDssICZxdW90O0NhcnN0ZW4g
Qm9ybWFubiZxdW90Ow0KPC90dD48YnI+DQo8dHQ+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNh
Ym9AdHppLm9yZyI+Y2Fib0B0emkub3JnPC9hPiZndDs8L3R0Pjwvc3Bhbj4gPGJyPg0KPHR0Pjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IENjOiAmbHQ7PGEgaHJlZj0ibWFpbHRv
OmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7Y29yZSZxdW90OyAm
bHQ7PGEgaHJlZj0ibWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZyI+Y29yZS1ib3VuY2VzQGll
dGYub3JnPC9hPiZndDs8L3NwYW4+PC90dD4NCjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdCI+Jmd0OyBEYXRlOiAwOS8yNC8yMDE1IDAxOjUwIFBNPC9zcGFuPjwvdHQ+IDxi
cj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBTdWJqZWN0OiBSZTog
W2NvcmVdIFdHIGxhc3QtY2FsbCAoV0dMQykgb2YgZHJhZnQtaWV0Zi1jb3JlLWh0dHAtbWFwcGlu
Zy0wNzwvc3Bhbj48L3R0Pg0KPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
Ij4mZ3Q7IDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyBIaTwvdHQ+PC9zcGFu
Pjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPu+8jDwvc3Bhbj48L3R0Pjx0dD48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdCI+DQo8L3NwYW4+PC90dD48YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBXaGVuIGEgaHR0cCBjbGllbnQgYWNjZXNzZXMgYSBD
b0FQIHNlcnZlciwgPC9zcGFuPg0KPC90dD48YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQiPiZndDsgaG93IGRvZXMgdGhlIENvQVAgY2xpZW50IG9mIEhDIHByb3h5IGNyZWF0
ZSBhIE5PTi1yZXBvc25zZSBvcHRpb24NCjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+
Jmd0OyBzaW5jZSB0aGVyZSBpcyBub3QgaW4gSFRUUC4gPC90dD48L3NwYW4+PGJyPg0KPHR0Pjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IE9yIGl0IGlzIHVzZWxlc3MgZm9yIEhD
IHByb3h5LCBvciBub3Q/IDwvc3Bhbj4NCjwvdHQ+PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgUmVnYXJkcyw8L3NwYW4+PC90dD4gPGJyPg0KPHR0
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8
YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgR2VuZ3l1IFdFSTwv
c3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyBOZXR3b3JrIFRlY2hub2xvZ3kgQ2Vu
dGVyPC90dD48YnI+DQo8dHQ+Jmd0OyBTY2hvb2wgb2YgQ29tcHV0ZXIgPC90dD48YnI+DQo8dHQ+
Jmd0OyBCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgYW5kIFRlbGVjb21tdW5pY2F0aW9uczwv
dHQ+PC9zcGFuPiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsg
Jm5ic3A7PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dCI+Jmd0OyBGcm9tOiBSYWhtYW4sIEFrYmFyIDwvc3Bhbj48L3R0Pjxicj4NCjx0dD48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDI0
LCAyMDE1IDI6MDAgQU08L3NwYW4+PC90dD4NCjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdCI+Jmd0OyBUbzogQWJoaWphbiBCaGF0dGFjaGFyeXlhIDsgQ2Fyc3RlbiBCb3Jt
YW5uIDwvc3Bhbj4NCjwvdHQ+PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
Ij4mZ3Q7IENjOiA8L3NwYW4+PC90dD48YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+PHR0
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5tYWlsdG86Y29yZUBpZXRmLm9yZzwvc3Bh
bj48L3R0PjwvYT48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiA7IGNvcmUNCjwv
c3Bhbj48L3R0Pjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBT
dWJqZWN0OiBSZTogW2NvcmVdIFdHIGxhc3QtY2FsbCAoV0dMQykgb2YgZHJhZnQtaWV0Zi1jb3Jl
LWh0dHAtbWFwcGluZy0wNzwvc3Bhbj48L3R0Pg0KPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgSGkgQWJoaWphbiw8L3NwYW4+PC90dD4gPGJyPg0K
PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0
PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7PC9z
cGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBU
aGFua3MgZm9yIHlvdXIgc3VwcG9ydCBvbiB0aGUgZHJhZnQhPC9zcGFuPjwvdHQ+DQo8YnI+DQo8
dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+
IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBXaXRoIHJlZ2Fy
ZHMgdG8geW91ciBxdWVzdGlvbjo8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgJmd0OyBHaXZlbiB0aGF0IE5vLVJlc3BvbnNl
IG5vdyBoYXMgYSBudW1iZXIgKDI4NCkgZnJvbSBJQU5BIGluIHRoZQ0KPC9zcGFuPjwvdHQ+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxicj4NCjx0dD4mZ3Q7IENvUkUgb3B0aW9uIHJlZ2lzdHJ5ICg8L3R0Pjwvc3Bhbj48
YSBocmVmPSJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2NvcmUtIj48dHQ+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMv
Y29yZS08L3NwYW4+PC90dD48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7IHBhcmFtZXRlcnMv
Y29yZS1wYXJhbWV0ZXJzLnhodG1sI29wdGlvbi1udW1iZXJzKSBwcm9iYWJseSBpdCB3aWxsIGJl
PC90dD48YnI+DQo8dHQ+Jmd0OyBhIGdvb2QgaWRlYSB0byBrZWVwIGEgc2VjdGlvbiB0byBkaXNj
dXNzIGhvdyB0byBoYW5kbGUgdGhpcyBvcHRpb24gPC90dD48YnI+DQo8dHQ+Jmd0OyBzaW5jZSB0
aGlzIGlzIG5vdCB0aGVyZSBpbiBIVFRQLiBTb21ld2hlcmUgaW4gU2VjdGlvbiA4IHNob3VsZCBi
ZSBhIDwvdHQ+PGJyPg0KPHR0PiZndDsgZ29vZCBwbGFjZSBmb3Igc3VjaCBkaXNjdXNzaW9uLiA8
L3R0Pjxicj4NCjwvc3Bhbj48YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi
PiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdCI+Jmd0OyBZZXMsIEkgYWdyZWUgdGhpcyBpcyBhIGdvb2QgdG9waWMgdG8gYWRkIHRv
IHRoZSBkcmFmdC4gJm5ic3A7SG93IGFib3V0DQo8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0K
PHR0PiZndDsgc29tZXRoaW5nIGJhc2VkIG9uIHRoZSBmb2xsb3dpbmcgdGV4dDo8L3R0Pjwvc3Bh
bj4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOzwv
c3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsg
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PC90dD4NCjxicj4NCjx0dD48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyA4LjggQ29BUCBObyBSZXNwb25zZTwv
c3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsg
Jm5ic3A7PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dCI+Jmd0OyBDb0FQIHN1cHBvcnRzIHNlbmRpbmcgYSBSZXF1ZXN0IGluZGljYXRpbmcgdGhhdCDi
gJxObyBSZXNwb25zZeKAnSBpcw0KPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7
IHJlcXVpcmVkIHdoZW4gdGhlIENvQVAgaGVhZGVyIG9wdGlvbiBudW1iZXIgaXMgc2V0IHRvIDI4
NC4gJm5ic3A7QW4gSEMgPC90dD48YnI+DQo8dHQ+Jmd0OyBQcm94eSBtYXkgdHJhbnNsYXRlIGFu
IGluY29taW5nIEhUVFAgUmVxdWVzdCB0byBhIGNvcnJlc3BvbmRpbmcgQ29BUDwvdHQ+PGJyPg0K
PHR0PiZndDsgUmVxdWVzdCBpbmRpY2F0aW5nIHRoYXQgbm8gcmVzcG9uc2UgaXMgcmVxdWlyZWQg
Zm9sbG93aW5nIHRoZSBndWlkYW5jZSBpbiA8L3R0Pg0KPGJyPg0KPHR0PiZndDsgKFJlZjogPC90
dD48L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9jb3JlLXBh
cmFtZXRlcnMvY29yZS0iPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aHR0cDov
L3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9jb3JlLXBhcmFtZXRlcnMvY29yZS08L3NwYW4+PC90
dD48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7IHBhcmFtZXRlcnMueGh0bWwjb3B0aW9uLW51
bWJlcnMpLjwvdHQ+PC9zcGFuPiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQiPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdCI+Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+
PC90dD4NCjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJz
cDs8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m
Z3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQiPiZndDsgQW55IGZlZWRiYWNrPzwvc3Bhbj48L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJzcDs8L3NwYW4+PC90dD4gPGJy
Pg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IC9Ba2Jhcjwvc3Bhbj48
L3R0PiA8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7
PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0
OyAmbmJzcDs8L3NwYW4+PC90dD4gPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0Ij4mZ3Q7IEZyb206IGNvcmUgWzwvc3Bhbj48L3R0PjxhIGhyZWY9Im1haWx0bzpjb3JlLWJv
dW5jZXNAaWV0Zi5vcmciPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+bWFpbHRv
OmNvcmUtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L3R0PjwvYT48dHQ+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQiPl0gT24gQmVoYWxmIE9mIEFiaGlqYW4gQmhhdHRhY2hhcnl5YTwvc3Bh
bj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVy
IDE3LCAyMDE1IDU6MzQgQU08L3R0Pjxicj4NCjx0dD4mZ3Q7IFRvOiBDYXJzdGVuIEJvcm1hbm4g
Jmx0OzxhIGhyZWY9Im1haWx0bzpjYWJvQHR6aS5vcmciPmNhYm9AdHppLm9yZzwvYT4mZ3Q7PC90
dD48YnI+DQo8dHQ+Jmd0OyBDYzogY29yZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvcmUtYm91bmNl
c0BpZXRmLm9yZyI+Y29yZS1ib3VuY2VzQGlldGYub3JnPC9hPiZndDs7DQo8YSBocmVmPSJtYWls
dG86Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT4gV0cgJmx0OzxhIGhyZWY9Im1haWx0
bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPiZndDs8L3R0Pjxicj4NCjx0dD4mZ3Q7
IFN1YmplY3Q6IFJlOiBbY29yZV0gV0cgbGFzdC1jYWxsIChXR0xDKSBvZiBkcmFmdC1pZXRmLWNv
cmUtaHR0cC1tYXBwaW5nLTA3PC90dD48L3NwYW4+DQo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj4NCjx0dD48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBEZWFyIGFsbCwgPC9zcGFuPjwvdHQ+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDsiPjxicj4NCjx0dD4mZ3Q7IEkgdGhpbmsgdGhpcyBkcmFmdCBpcyBpbmRlZWQgYW4gYXBwcmVj
aWFibGUgZWZmb3J0IGFzIGl0IHdpbGwgZWFzZSA8L3R0Pjxicj4NCjx0dD4mZ3Q7IG91dCBtYW55
IGltcGxlbWVudGF0aW9uIGRlY2lzaW9ucyBmb3IgdGhlIGRldmVsb3BlcnMgYW5kIHNob3VsZCBi
ZSA8L3R0Pjxicj4NCjx0dD4mZ3Q7IHZlcnkgdXNlZnVsIGFzIGFuIFJGQy4gPC90dD48YnI+DQo8
dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IERlYXIgYXV0aG9ycywgPC90dD48YnI+DQo8dHQ+
Jmd0OyBJIGhhdmUgb25lIHNtYWxsIGNvbW1lbnQgOiA8L3R0Pjxicj4NCjx0dD4mZ3Q7IEdpdmVu
IHRoYXQgTm8tUmVzcG9uc2Ugbm93IGhhcyBhIG51bWJlciAoMjg0KSBmcm9tIElBTkEgaW4gdGhl
IENvUkUgPC90dD48YnI+DQo8dHQ+Jmd0OyBvcHRpb24gcmVnaXN0cnkgKDwvdHQ+PC9zcGFuPjxh
IGhyZWY9Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvY29yZS1wYXJhbWV0ZXJzLyI+
PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5odHRwOi8vd3d3LmlhbmEub3JnL2Fz
c2lnbm1lbnRzL2NvcmUtcGFyYW1ldGVycy88L3NwYW4+PC90dD48L2E+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4N
Cjx0dD4mZ3Q7IGNvcmUtcGFyYW1ldGVycy54aHRtbCNvcHRpb24tbnVtYmVycykgcHJvYmFibHkg
aXQgd2lsbCBiZSBhIGdvb2QgPC90dD48YnI+DQo8dHQ+Jmd0OyBpZGVhIHRvIGtlZXAgYSBzZWN0
aW9uIHRvIGRpc2N1c3MgaG93IHRvIGhhbmRsZSB0aGlzIG9wdGlvbiBzaW5jZSA8L3R0Pjxicj4N
Cjx0dD4mZ3Q7IHRoaXMgaXMgbm90IHRoZXJlIGluIEhUVFAuIFNvbWV3aGVyZSBpbiBTZWN0aW9u
IDggc2hvdWxkIGJlIGEgZ29vZCA8L3R0Pjxicj4NCjx0dD4mZ3Q7IHBsYWNlIGZvciBzdWNoIGRp
c2N1c3Npb24uIDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxi
cj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgUmVnYXJkczwvdHQ+PGJyPg0KPHR0PiZn
dDsgQWJoaWphbiBCaGF0dGFjaGFyeXlhPC90dD48YnI+DQo8dHQ+Jmd0OyBBc3NvY2lhdGUgQ29u
c3VsdGFudDwvdHQ+PGJyPg0KPHR0PiZndDsgU2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29s
a2F0YSwgSW5kaWE8L3R0Pjxicj4NCjx0dD4mZ3Q7IFRhdGEgQ29uc3VsdGFuY3kgU2VydmljZXM8
L3R0Pjxicj4NCjx0dD4mZ3Q7IE1haWx0bzogPGEgaHJlZj0ibWFpbHRvOmFiaGlqYW4uYmhhdHRh
Y2hhcnl5YUB0Y3MuY29tIj5hYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTwvYT48L3R0Pjxi
cj4NCjx0dD4mZ3Q7IFdlYnNpdGU6IDwvdHQ+PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cudGNz
LmNvbS8iPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aHR0cDovL3d3dy50Y3Mu
Y29tPC9zcGFuPjwvdHQ+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvdHQ+PGJyPg0KPHR0PiZndDsgRXhwZXJp
ZW5jZSBjZXJ0YWludHkuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lUIFNlcnZpY2VzPC90
dD48YnI+DQo8dHQ+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0
aW9uczwvdHQ+PGJyPg0KPHR0PiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDb25zdWx0
aW5nPC90dD48YnI+DQo8dHQ+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxi
cj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyBGcm9t
OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDYXJzdGVuIEJvcm1hbm4gJmx0OzxhIGhyZWY9
Im1haWx0bzpjYWJvQHR6aS5vcmciPmNhYm9AdHppLm9yZzwvYT4mZ3Q7DQo8L3R0Pjxicj4NCjx0
dD4mZ3Q7IFRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDs8L3R0Pjwvc3Bhbj48
YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyUyMFdHIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQiPm1haWx0bzpjb3JlQGlldGYub3JnJTIwV0c8L3NwYW4+PC90dD48L2E+PHR0
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0
bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPiZndDsNCjwvc3Bhbj48L3R0PjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij48YnI+DQo8dHQ+Jmd0OyBEYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswOS8x
NS8yMDE1IDA4OjUxIFBNIDwvdHQ+PGJyPg0KPHR0PiZndDsgU3ViamVjdDogJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7W2NvcmVdIFdHIGxhc3QtY2FsbCAoV0dMQykgb2YgZHJhZnQtaWV0Zi1j
b3JlLWh0dHAtbWFwcGluZy0wNzwvdHQ+PGJyPg0KPHR0PiZndDsgU2VudCBieTogJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7Y29yZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNv
cmUtYm91bmNlc0BpZXRmLm9yZyI+Y29yZS1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjwvdHQ+
PC9zcGFuPjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyA8L3Nw
YW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZndDsgPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0
Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgSW4gUHJhZ3VlLCB3ZSBzYWlkIHdl
IHdlcmUgZ29pbmcgdG8gV0dMQyB0aGUgSFRUUCBtYXBwaW5nIGRyYWZ0IGFmdGVyPC90dD48YnI+
DQo8dHQ+Jmd0OyBjbG9zZSBvZiB0aGUgdmFjYXRpb24gcGVyaW9kLCB3aGljaCBpcyBub3cgYmVo
aW5kIHVzLiAmbmJzcDtBbGwgb3V0c3RhbmRpbmc8L3R0Pjxicj4NCjx0dD4mZ3Q7IHRpY2tldHMg
YXJlIGNsb3NlZCwgYW5kIHRoZXJlIHdhcyBlbm91Z2ggdGltZSB0byByZXZpZXcgdGhlIGN1cnJl
bnQ8L3R0Pjxicj4NCjx0dD4mZ3Q7IGRyYWZ0LiAmbmJzcDtUaHJlZSBwZW9wbGUgcmFpc2VkIHRo
ZWlyIGhhbmRzIHdoZW4gd2UgYXNrZWQgd2hvIHdvdWxkIHN1Ym1pdDwvdHQ+PGJyPg0KPHR0PiZn
dDsgcmV2aWV3cyAoTWljaGFlbCBLLiwgS2xhdXMsIERhcnNoYWspLCBidXQgb2YgY291cnNlIGFk
ZGl0aW9uYWwgcmV2aWV3czwvdHQ+PGJyPg0KPHR0PiZndDsgYmV5b25kIHRoYXQgYXJlIGFsc28g
dmVyeSB1c2VmdWwuPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IFNvIHRo
aXMgc3RhcnRzIGEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yPC90dD48YnI+DQo8dHQ+Jmd0
OyBkcmFmdC1pZXRmLWNvcmUtaHR0cC1tYXBwaW5nIGZvciBzdWJtaXNzaW9uIGFzIGFuIGluZm9y
bWF0aW9uYWwgUkZDLDwvdHQ+PGJyPg0KPHR0PiZndDsgZW5kaW5nIG9uPC90dD48YnI+DQo8dHQ+
Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IDI0OjAwIFBEVCBvbiBUdWVzZGF5LCBTZXB0ZW1iZXIg
MjksIDIwMTUuPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxicj4NCjx0dD4mZ3Q7IFRoZSBkcmFm
dCBpcyBsb2NhdGVkIGF0OjwvdHQ+PGJyPg0KPHR0PiZndDsgPC90dD48L3NwYW4+PGEgaHJlZj0i
aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1odHRwLW1hcHBpbmct
MDciPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1odHRwLW1hcHBpbmctMDc8L3NwYW4+PC90dD48L2E+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0PiZndDsgUGxlYXNlIHN0YXJ0
IGEgbmV3IGVtYWlsIHRocmVhZCBmb3IgZWFjaCBtYWpvciBpc3N1ZSB0aGF0IHdpbGwgbmVlZDwv
dHQ+PGJyPg0KPHR0PiZndDsgZGlzY3Vzc2lvbiBhbmQgbWFrZSBzdXJlIHRoZSBzdWJqZWN0IGxp
bmUgaW5jbHVkZXMgdGhlIGRyYWZ0IG5hbWUgYW5kPC90dD48YnI+DQo8dHQ+Jmd0OyBzb21lIHNv
cnQgb2YgbmFtZSBmb3IgdGhlIGlzc3VlLiBGb3IgbWlub3IgaXNzdWVzIHN1Y2ggYXMgdHlwb3Mg
YW5kPC90dD48YnI+DQo8dHQ+Jmd0OyB0aGluZ3MgdGhhdCBhcmUgbm90IGxpa2VseSB0byBsZWFk
IHRvIG11Y2ggZGlzY3Vzc2lvbiwgaXQgaXMgcHJvYmFibHk8L3R0Pjxicj4NCjx0dD4mZ3Q7IGVh
c2llciB0byBncm91cCB0aGVtIGFsbCBpbiB0byBvbmUgZW1haWwgYnV0IGFnYWluLCBwbGVhc2Ug
bWFrZSBzdXJlPC90dD48YnI+DQo8dHQ+Jmd0OyB0aGUgc3ViamVjdCBsaW5lIGluY2x1ZGVzIHRo
ZSBkcmFmdCBuYW1lLiBJZiB5b3UgcmVhZCB0aGUgZHJhZnQgYW5kPC90dD48YnI+DQo8dHQ+Jmd0
OyB0aGluayBpdCBsb29rcyBmaW5lLCBwbGVhc2Ugc2VuZCBhIG9uZSBsaW5lIGVtYWlsIHRvIHRo
ZSBsaXN0IG9yIHRvPC90dD48YnI+DQo8dHQ+Jmd0OyB0aGUgY2hhaXJzIGxldHRpbmcgdXMga25v
dyB0aGF0IHNvIHdlIGNhbiBnZXQgYSBmZWVsIG9mIGhvdyBicm9hZCB0aGU8L3R0Pjxicj4NCjx0
dD4mZ3Q7IHJldmlldyBoYXMgYmVlbi48L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJyPg0KPHR0
PiZndDsgSW4gdGhlIHVubGlrZWx5IGV2ZW50IHRoYXQgeW91IGFyZSBhd2FyZSBvZiBhbnkgcGF0
ZW50IGNsYWltcyB0aGF0PC90dD48YnI+DQo8dHQ+Jmd0OyBtaWdodCBhcHBseSB0byBzeXN0ZW1z
IHRoYXQgaW1wbGVtZW50IHRoZSBzdWdnZXN0aW9ucyBpbiB0aGlzIGRyYWZ0LDwvdHQ+PGJyPg0K
PHR0PiZndDsgcGxlYXNlIHJldmlldyBCQ1AgNzggYW5kIEJDUCA3OSBhbmQgbWFrZSBhbnkgYXBw
cm9wcmlhdGUgSVBSPC90dD48YnI+DQo8dHQ+Jmd0OyBkZWNsYXJhdGlvbi4gSWYgeW91IGFyZSBu
b3Qgc3VyZSB3aGV0aGVyIHlvdSBuZWVkIHRvIG1ha2UgYTwvdHQ+PGJyPg0KPHR0PiZndDsgZGVj
bGFyYXRpb24gb3Igbm90LCBwbGVhc2UgdGFsayB0byB0aGUgY2hhaXJzIGFuZCB3ZSB3aWxsIGhl
bHAgZ2V0IHlvdTwvdHQ+PGJyPg0KPHR0PiZndDsgaW4gdG91Y2ggd2l0aCBwZW9wbGUgdGhhdCBj
YW4gcHJvdmlkZSBhcHByb3ByaWF0ZSBhZHZpY2UuPC90dD48YnI+DQo8dHQ+Jmd0OyA8L3R0Pjxi
cj4NCjx0dD4mZ3Q7IEdyw7zDn2UsIENhcnN0ZW48L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PGJy
Pg0KPHR0PiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188L3R0Pjxicj4NCjx0dD4mZ3Q7IGNvcmUgbWFpbGluZyBsaXN0PC90dD48YnI+DQo8dHQ+Jmd0
OyA8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT48L3R0Pjxi
cj4NCjx0dD4mZ3Q7IDwvdHQ+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vY29yZSI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8L3NwYW4+PC90dD48L2E+
DQo8YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgPT09PT0tLS0t
LT09PT09LS0tLS09PT09PTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jmd0OyBOb3Rp
Y2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWw8L3R0Pjxicj4NCjx0
dD4mZ3Q7IG1lc3NhZ2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1heSBjb250YWluIDwvdHQ+
PGJyPg0KPHR0PiZndDsgY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElm
IHlvdSBhcmUgPC90dD48YnI+DQo8dHQ+Jmd0OyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg
YW55IGRpc3NlbWluYXRpb24sIHVzZSwgPC90dD48YnI+DQo8dHQ+Jmd0OyByZXZpZXcsIGRpc3Ry
aWJ1dGlvbiwgcHJpbnRpbmcgb3IgY29weWluZyBvZiB0aGUgPC90dD48YnI+DQo8dHQ+Jmd0OyBp
bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSA8L3R0Pjxicj4NCjx0
dD4mZ3Q7IGFuZC9vciBhdHRhY2htZW50cyB0byBpdCBhcmUgc3RyaWN0bHkgcHJvaGliaXRlZC4g
SWYgPC90dD48YnI+DQo8dHQ+Jmd0OyB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRp
b24gaW4gZXJyb3IsIDwvdHQ+PGJyPg0KPHR0PiZndDsgcGxlYXNlIG5vdGlmeSB1cyBieSByZXBs
eSBlLW1haWwgb3IgdGVsZXBob25lIGFuZCA8L3R0Pjxicj4NCjx0dD4mZ3Q7IGltbWVkaWF0ZWx5
IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG1lc3NhZ2UgPC90dD48YnI+DQo8dHQ+Jmd0OyBh
bmQgYW55IGF0dGFjaG1lbnRzLiBUaGFuayB5b3U8L3R0Pjwvc3Bhbj4gPGJyPg0KPHR0PjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mZ3Q7
IGNvcmUgbWFpbGluZyBsaXN0PC90dD48YnI+DQo8dHQ+Jmd0OyA8YSBocmVmPSJtYWlsdG86Y29y
ZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT48L3R0Pjxicj4NCjx0dD4mZ3Q7IDwvdHQ+PC9z
cGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZSI+
PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2NvcmU8L3NwYW4+PC90dD48L2E+DQo8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_36F5869FE31AB24485E5E3222C288E1F347BB47DNABESITEInterDi_--


From nobody Thu Sep 24 18:37: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 CA5551B4436 for ; Thu, 24 Sep 2015 18:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 8ov7TDaGjaHV for ; Thu, 24 Sep 2015 18:37:03 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 369B41B4434 for ; Thu, 24 Sep 2015 18:37:01 -0700 (PDT)
Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id AB7A319F48F for ; Fri, 25 Sep 2015 09:36:59 +0800 (HKT)
Received: from WeiGengyuPC (unknown [10.8.163.227]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 4971A19F371; Fri, 25 Sep 2015 09:36:59 +0800 (HKT)
Message-ID: 
From: "weigengyu" 
To: "Rahman, Akbar" , "Abhijan Bhattacharyya" 
References: <55F83752.3090609@tzi.org>  <36F5869FE31AB24485E5E3222C288E1F347BAE99@NABESITE.InterDigital.com>   <36F5869FE31AB24485E5E3222C288E1F347BB47D@NABESITE.InterDigital.com>
In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F347BB47D@NABESITE.InterDigital.com>
Date: Fri, 25 Sep 2015 09:36:57 +0800
Organization: BUPT
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01D0F775.B9082F20"
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 , core@ietf.org
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
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, 25 Sep 2015 01:37:08 -0000

这是一封 MIME 格式的多方邮件。

------=_NextPart_000_0048_01D0F775.B9082F20
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Abhijan,=20

Thank you for your explainations.

For CoAP to CoAP proxy, there is not any question to use a NON-response =
option=20
if the CoAP2CoAP Proxy does not have any knowledge about applications.

It is questionalbe that whether the HC proxoy needs to unstandstand =
application sematics.=20
Is it required, or not?=20

Regards,

Gengyu WEI
Network Technology Center
School of Computer=20
Beijing University of Posts and Telecommunications

From: Rahman, Akbar=20
Sent: Friday, September 25, 2015 12:59 AM
To: Abhijan Bhattacharyya ; weigengyu=20
Cc: Carsten Bormann ; core@ietf.org ; core=20
Subject: RE: [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07

Hi Abhijan,

=20

=20

Okay, please review the updated proposed text for =
draft-ietf-core-http-mapping based on the feedback from Carsten, =
Weigengyu and you.

=20

=20

--------------------------------

(New) Section 8.x =E2=80=9CUse of CoAP No Response=E2=80=9D:

=20

CoAP supports sending a Request indicating that =E2=80=9CNo =
Response=E2=80=9D is required when the CoAP header option number is set =
to 284 [see Ref-1].  An HC Proxy may translate an incoming HTTP Request =
to a corresponding CoAP Request indicating that No Response is required =
based on some application knowledge (see [Ref-2] for further guidance).  =
In this case, it is recommend that the HC Proxy SHOULD send an HTTP =
Response with status code 204 (No Content).

=20

[Ref-1] - =
http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#opt=
ion-numbers

=20

[Ref-2] - =
https://tools.ietf.org/html/draft-tcs-coap-no-response-option-11

=20

---------------------------------

=20

=20

Also, Abhijan, it may be good for you to put the application scenario =
you outlined below in your draft-tcs-coap-no-response-option as that =
should be document that contains all such guidance information.

=20

=20

Do you agree?

=20

=20

/Akbar

=20

=20

=20

From: Abhijan Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com]=20
Sent: Thursday, September 24, 2015 8:53 AM
To: weigengyu ; Rahman, Akbar =

Cc: Carsten Bormann ; core@ietf.org; core =

Subject: Re: [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07

=20

Hi Akbar,=20
Thanks.=20

Taking clue from Gengyu's response I would like to share the following =
input:=20

The decision to convert an HTTP request to a CoAP request with "No =
Response" should be purely based on the application context.=20
Let us consider a scenario.=20
We want to operate the lights of a building from a remote control-center =
(controlling commands may not be essentially multicast). Let us assume =
that the control-center has legacy HTTP infrastructure. But the lights =
are CoAP enabled. So the requests from the control-center goes through =
an HC proxy. The application requirement, in that case, will decide =
whether the requests from HTTP client are to be made CoAP requests with =
No-Response or not.=20

But, there is one point. The HTTP client needs a response as per the =
HTTP protocol requirements. So, what response should proxy return?=20
Looking at Table 2 of the http mapping draft we see that CoAP's 2.04 =
(Changed) is mapped to either 200 (OK) or 204 (No Content) for the HTTP. =
Can we suggest that in cases as described above the proxy SHOULD respond =
with the status code: 204  No Content ? This way the client knows that =
No-Response is enabled at the CoAP side for the particular PUTs.=20

Does it make sense?=20


Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________


"weigengyu"  wrote on 09/24/2015 01:40:50 PM:

> From: "weigengyu" =20
> To: "Rahman, Akbar" , "Abhijan=20
> Bhattacharyya" , "Carsten Bormann"=20
> =20
> Cc: , "core" =20
> Date: 09/24/2015 01:50 PM=20
> Subject: Re: [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07=20
>=20
> Hi=EF=BC=8C=20
> =20
> When a http client accesses a CoAP server,=20
> how does the CoAP client of HC proxy create a NON-reposnse option=20
> since there is not in HTTP.=20
> Or it is useless for HC proxy, or not?=20
> =20
> Regards,=20
> =20
> Gengyu WEI
> Network Technology Center
> School of Computer=20
> Beijing University of Posts and Telecommunications=20
> =20
> From: Rahman, Akbar=20
> Sent: Thursday, September 24, 2015 2:00 AM=20
> To: Abhijan Bhattacharyya ; Carsten Bormann=20
> Cc: mailto:core@ietf.org ; core=20
> Subject: Re: [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07=20
> =20
> Hi Abhijan,=20
> =20
> =20
> Thanks for your support on the draft!=20
> =20
> With regards to your question:=20
> =20
> > Given that No-Response now has a number (284) from IANA in the=20
> CoRE option registry (http://www.iana.org/assignments/core-
> parameters/core-parameters.xhtml#option-numbers) probably it will be
> a good idea to keep a section to discuss how to handle this option=20
> since this is not there in HTTP. Somewhere in Section 8 should be a=20
> good place for such discussion.=20

> =20
> Yes, I agree this is a good topic to add to the draft.  How about=20
> something based on the following text:=20
> =20
> --------------------------------=20
> 8.8 CoAP No Response=20
> =20
> CoAP supports sending a Request indicating that =E2=80=9CNo =
Response=E2=80=9D is=20
> required when the CoAP header option number is set to 284.  An HC=20
> Proxy may translate an incoming HTTP Request to a corresponding CoAP
> Request indicating that no response is required following the guidance =
in=20
> (Ref: http://www.iana.org/assignments/core-parameters/core-
> parameters.xhtml#option-numbers).=20
> =20
> ---------------------------------=20
> =20
> =20
> Any feedback?=20
> =20
> =20
> /Akbar=20
> =20
> =20
> From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan =
Bhattacharyya
> Sent: Thursday, September 17, 2015 5:34 AM
> To: Carsten Bormann 
> Cc: core ; core@ietf.org WG 
> Subject: Re: [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07=20
> =20
> Dear all,=20
> I think this draft is indeed an appreciable effort as it will ease=20
> out many implementation decisions for the developers and should be=20
> very useful as an RFC.=20
>=20
> Dear authors,=20
> I have one small comment :=20
> Given that No-Response now has a number (284) from IANA in the CoRE=20
> option registry (http://www.iana.org/assignments/core-parameters/
> core-parameters.xhtml#option-numbers) probably it will be a good=20
> idea to keep a section to discuss how to handle this option since=20
> this is not there in HTTP. Somewhere in Section 8 should be a good=20
> place for such discussion.=20
>=20
>=20
>=20
> Regards
> Abhijan Bhattacharyya
> Associate Consultant
> Scientist, Innovation Lab, Kolkata, India
> Tata Consultancy Services
> Mailto: abhijan.bhattacharyya@tcs.com
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Consulting
> ____________________________________________
>=20
>=20
>=20
>=20
> From:        Carsten Bormann =20
> To:        "mailto:core@ietf.org%20WG" =20
> Date:        09/15/2015 08:51 PM=20
> Subject:        [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07
> Sent by:        "core" =20
>=20
>=20
>=20
>=20
> In Prague, we said we were going to WGLC the HTTP mapping draft after
> close of the vacation period, which is now behind us.  All outstanding
> tickets are closed, and there was enough time to review the current
> draft.  Three people raised their hands when we asked who would submit
> reviews (Michael K., Klaus, Darshak), but of course additional reviews
> beyond that are also very useful.
>=20
> So this starts a working group last call for
> draft-ietf-core-http-mapping for submission as an informational RFC,
> ending on
>=20
> 24:00 PDT on Tuesday, September 29, 2015.
>=20
> The draft is located at:
> https://tools.ietf.org/html/draft-ietf-core-http-mapping-07
>=20
> Please start a new email thread for each major issue that will need
> discussion and make sure the subject line includes the draft name and
> some sort of name for the issue. For minor issues such as typos and
> things that are not likely to lead to much discussion, it is probably
> easier to group them all in to one email but again, please make sure
> the subject line includes the draft name. If you read the draft and
> think it looks fine, please send a one line email to the list or to
> the chairs letting us know that so we can get a feel of how broad the
> review has been.
>=20
> In the unlikely event that you are aware of any patent claims that
> might apply to systems that implement the suggestions in this draft,
> please review BCP 78 and BCP 79 and make any appropriate IPR
> declaration. If you are not sure whether you need to make a
> declaration or not, please talk to the chairs and we will help get you
> in touch with people that can provide appropriate advice.
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core=20
> =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain=20
> confidential or privileged information. If you are=20
> not the intended recipient, any dissemination, use,=20
> review, distribution, printing or copying of the=20
> information contained in this e-mail message=20
> and/or attachments to it are strictly prohibited. If=20
> you have received this communication in error,=20
> please notify us by reply e-mail or telephone and=20
> immediately and permanently delete the message=20
> and any attachments. Thank you=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core=20

------=_NextPart_000_0048_01D0F775.B9082F20
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable












Hi Abhijan, =



 


Thank you for your explainations.


 


For CoAP to CoAP proxy, there is not any question to use a =
NON-response=20
option 


if the CoAP2CoAP Proxy does not have any knowledge about=20
applications.


 


It is questionalbe that whether the HC proxoy needs to unstandstand =

application sematics. 


Is it required, or not? 


 


Regards,


 


Gengyu=20
WEI
Network Technology Center
School of Computer 
Beijing =
University of=20
Posts and Telecommunications





 




From: Rahman, Akbar 


Sent: Friday, September 25, 2015 12:59 AM


To: Abhijan Bhattacharyya =
; weigengyu=20




Subject: RE: [core] WG last-call (WGLC) of=20
draft-ietf-core-http-mapping-07


 





Hi=20
Abhijan,


 


 


Okay,=20
please review the updated proposed text for draft-ietf-core-http-mapping =
based=20
on the feedback from Carsten, Weigengyu and you.


 


 


--------------------------------


(New)=20
Section 8.x =E2=80=9CUse of CoAP No =
Response=E2=80=9D:


 


CoAP=20
supports sending a Request indicating that =E2=80=9CNo Response=E2=80=9D =
is required when the=20
CoAP header option number is set to 284 [see Ref-1].  An HC Proxy =
may=20
translate an incoming HTTP Request to a corresponding CoAP Request =
indicating=20
that No Response is required based on some application knowledge (see =
[Ref-2]=20
for further guidance).  In this case, it is recommend that the HC =
Proxy=20
SHOULD send an HTTP Response with status code 204 (No=20
Content).


 


[Ref-1] - http://www.iana.org/assignments/core-parameters/core-=
parameters.xhtml#option-numbers


 


[Ref-2]=20
- https://tools.ietf.org/html/draft-tcs-coap-no-response-option-11


 


---------------------------------


 


 


Also,=20
Abhijan, it may be good for you to put the application scenario you =
outlined=20
below in your draft-tcs-coap-no-response-option as that should be =
document that=20
contains all such guidance information.


 


 


Do=20
you agree?


 


 


/Akbar


 


 


 


From: Abhijan=20
Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com] 
Sent: =
Thursday,=20
September 24, 2015 8:53 AM
To: weigengyu=20
<weigengyu@bupt.edu.cn>; Rahman, Akbar=20
<Akbar.Rahman@InterDigital.com>
Cc: Carsten Bormann=20
<cabo@tzi.org>; core@ietf.org; core=20
<core-bounces@ietf.org>
Subject: Re: [core] WG last-call =
(WGLC)=20
of draft-ietf-core-http-mapping-07


 


Hi =
Akbar,=20

Thanks.=20


Taking=20
clue from Gengyu's response I would like to share the following =
input:=20


The=20
decision to convert an HTTP request to a CoAP request with "No Response" =
should=20
be purely based on the application context. 
Let us =
consider a=20
scenario. 
We want to =
operate the=20
lights of a building from a remote control-center (controlling commands =
may not=20
be essentially multicast). Let us assume that the control-center has =
legacy HTTP=20
infrastructure. But the lights are CoAP enabled. So the requests from =
the=20
control-center goes through an HC proxy. The application requirement, in =
that=20
case, will decide whether the requests from HTTP client are to be made =
CoAP=20
requests with No-Response or not. 

But, there is =
one=20
point. The HTTP client needs a response as per the HTTP protocol =
requirements.=20
So, what response should proxy return? 
Looking at =
Table 2 of=20
the http mapping draft we see that CoAP's 2.04 (Changed) is mapped to =
either 200=20
(OK) or 204 (No Content) for the HTTP. Can we suggest that in cases as =
described=20
above the proxy SHOULD respond with the status code: 204  No =
Content=20
? This way the client knows that No-Response is enabled at the CoAP side =
for the=20
particular PUTs. 

Does it make=20
sense? 


Regards
Abhijan=20
Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, =
Kolkata,=20
India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.c=
om
Website:=20
http://www.tcs.com
____________________________________________
E=
xperience=20
certainty.        IT=20
Services
          &=
nbsp;           =20
Business=20
Solutions
          =
             =

Consulting
____________________________________________

=

"weigengyu" <weigengyu@bupt.edu.cn> =
wrote on=20
09/24/2015 01:40:50 PM:

> =
From:=20
"weigengyu" <weigengyu@bupt.edu.cn><=
/SPAN>=20

> To: "Rahman, Akbar" <Akbar.Rahman@InterDigital.c=
om>,=20
"Abhijan 
> =
Bhattacharyya"=20
<abhijan.bhattacharyya@tcs.c=
om>,=20
"Carsten Bormann" 
> <cabo@tzi.org> =

> Cc: <core@ietf.org>, "core" <core-bounces@ietf.org>=20

> Date: 09/24/2015 01:50 =
PM=20

> Subject: Re: [core] WG =
last-call=20
(WGLC) of draft-ietf-core-http-mapping-07 
> 
>=20
Hi=EF=BC=8C 
>  
> When a http client accesses a CoAP =
server,=20

> how does the =
CoAP client=20
of HC proxy create a NON-reposnse option 
> since =
there is=20
not in HTTP. 
> Or =
it is=20
useless for HC proxy, or not? 
>  
> Regards, 
>  
> Gengyu WEI
> =
Network=20
Technology Center
> School of Computer 
> =
Beijing=20
University of Posts and Telecommunications 
>  
> From: Rahman, Akbar =

> Sent: Thursday, September 24, 2015 2:00=20
AM 
> To: Abhijan=20
Bhattacharyya ; Carsten Bormann 
> Cc: mailto:core@ietf.org ; core 
> Subject: Re: [core] WG last-call (WGLC) =
of=20
draft-ietf-core-http-mapping-07 
>  
> Hi Abhijan, 
>  
>  
> Thanks for your support on the =
draft!=20

>  =

> With regards to your =
question:=20

>  =

> > Given that No-Response now has a =
number (284)=20
from IANA in the 
> CoRE =
option=20
registry (http://www.iana.org/assignments/core-
>=20
parameters/core-parameters.xhtml#option-numbers) probably it will=20
be
> a good idea to keep a section to discuss how to =
handle this=20
option 
> since this is not there in HTTP. Somewhere in =
Section 8=20
should be a 
> good place for such discussion.=20


> =20

> Yes, I agree =
this is a=20
good topic to add to the draft.  How about 
> =
something based=20
on the following text: 
>  
> =
--------------------------------=20

> 8.8 CoAP No =
Response=20

>  =

> CoAP supports sending a Request =
indicating that =E2=80=9CNo=20
Response=E2=80=9D is 
> =
required when=20
the CoAP header option number is set to 284.  An HC =

> Proxy=20
may translate an incoming HTTP Request to a corresponding =
CoAP
>=20
Request indicating that no response is required following the guidance =
in=20

> (Ref: http://www.iana.org/assignments/core-parameters/core-
>=20
parameters.xhtml#option-numbers). 
>  
> =
---------------------------------=20

>  =

>  
> Any feedback? 
>  
>  
> /Akbar 
>  
>  
> From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan =
Bhattacharyya
> Sent: =
Thursday,=20
September 17, 2015 5:34 AM
> To: Carsten Bormann <cabo@tzi.org>
> Cc: =
core <core-bounces@ietf.org>; core@ietf.org WG <core@ietf.org>
> =
Subject: Re:=20
[core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07=20

>  =

> Dear all, 
> I =
think this=20
draft is indeed an appreciable effort as it will ease 
> =
out many=20
implementation decisions for the developers and should be =

> very=20
useful as an RFC. 
> 
> Dear authors,=20

> I have one small comment : 
> Given =
that=20
No-Response now has a number (284) from IANA in the CoRE =

>=20
option registry (http://www.iana.org/assignments/core-parameters/
>=20
core-parameters.xhtml#option-numbers) probably it will be a good=20

> idea to keep a section to discuss how to handle this =
option=20
since 
> this is not there in HTTP. Somewhere in Section =
8 should=20
be a good 
> place for such discussion. 
> =


> 
> 
> =
Regards
>=20
Abhijan Bhattacharyya
> Associate =
Consultant
>=20
Scientist, Innovation Lab, Kolkata, India
> Tata =
Consultancy=20
Services
> Mailto: abhijan.bhattacharyya@tcs.c=
om
>=20
Website: http://www.tcs.com
>=20
____________________________________________
> Experience =

certainty.        IT=20
Services
>        =
            &=
nbsp;  =20
Business=20
Solutions
>        =
;            =
   =20
Consulting
>=20
____________________________________________
> =

>=20

> 
> 
>=20
From:        Carsten Bormann <cabo@tzi.org> 
>=20
To:        "mailto:core@ietf.org%20WG" <core@ietf.org> 
>=20
Date:        09/15/2015 08:51 PM=20

> Subject:        =
[core] WG=20
last-call (WGLC) of draft-ietf-core-http-mapping-07
> =
Sent=20
by:        "core" <core-bounces@ietf.org>=20

> =

>=20

> 
> 
> In Prague, we said =
we were=20
going to WGLC the HTTP mapping draft after
> close of the =

vacation period, which is now behind us.  All =
outstanding
>=20
tickets are closed, and there was enough time to review the=20
current
> draft.  Three people raised their hands =
when we=20
asked who would submit
> reviews (Michael K., Klaus, =
Darshak),=20
but of course additional reviews
> beyond that are also =
very=20
useful.
> 
> So this starts a working =
group last=20
call for
> draft-ietf-core-http-mapping for submission as =
an=20
informational RFC,
> ending on
> =

>=20
24:00 PDT on Tuesday, September 29, 2015.
> =

> The=20
draft is located at:
> =
https://tools.ietf.org/html/draft-ietf-core-http-mapping-07<=
/TT>
>=20

> Please start a new email thread for each major issue =
that will=20
need
> discussion and make sure the subject line includes =
the=20
draft name and
> some sort of name for the issue. For =
minor=20
issues such as typos and
> things that are not likely to =
lead to=20
much discussion, it is probably
> easier to group them =
all in to=20
one email but again, please make sure
> the subject line =
includes=20
the draft name. If you read the draft and
> think it =
looks fine,=20
please send a one line email to the list or to
> the =
chairs=20
letting us know that so we can get a feel of how broad =
the
>=20
review has been.
> 
> In the unlikely =
event that=20
you are aware of any patent claims that
> might apply to =
systems=20
that implement the suggestions in this draft,
> please =
review BCP=20
78 and BCP 79 and make any appropriate IPR
> declaration. =
If you=20
are not sure whether you need to make a
> declaration or =
not,=20
please talk to the chairs and we will help get you
> in =
touch=20
with people that can provide appropriate advice.
>=20

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

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

>=20
=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
> =
Notice: The=20
information contained in this e-mail
> message and/or =
attachments=20
to it may contain 
> confidential or privileged =
information. If=20
you are 
> not the intended recipient, any dissemination, =
use,=20

> review, distribution, printing or copying of the=20

> information contained in this e-mail message =

>=20
and/or attachments to it are strictly prohibited. If 
> =
you have=20
received this communication in error, 
> please notify us =
by=20
reply e-mail or telephone and 
> immediately and =
permanently=20
delete the message 
> and any attachments. Thank =
you=20

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



------=_NextPart_000_0048_01D0F775.B9082F20--




From nobody Thu Sep 24 19:52:34 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 A995C1B3575 for ; Thu, 24 Sep 2015 19:52:32 -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, HTML_MESSAGE=0.001, 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 32_6rGoSuxoW for ; Thu, 24 Sep 2015 19:52:26 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 03D181B3574 for ; Thu, 24 Sep 2015 19:52:24 -0700 (PDT)
Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 57D0519F39C for ; Fri, 25 Sep 2015 10:52:23 +0800 (HKT)
Received: from WeiGengyuPC (unknown [10.8.163.227]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id BDC9619F499 for ; Fri, 25 Sep 2015 10:52:22 +0800 (HKT)
Message-ID: 
From: "weigengyu" 
To: 
References: <55F83752.3090609@tzi.org>  <36F5869FE31AB24485E5E3222C288E1F347BAE99@NABESITE.InterDigital.com>   <36F5869FE31AB24485E5E3222C288E1F347BB47D@NABESITE.InterDigital.com> 
In-Reply-To: 
Date: Fri, 25 Sep 2015 10:52:17 +0800
Organization: BUPT
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01D0F780.3ED55FB0"
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] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
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, 25 Sep 2015 02:52:32 -0000

这是一封 MIME 格式的多方邮件。

------=_NextPart_000_0038_01D0F780.3ED55FB0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Abhijan,=20

It is questionable that whether the HC proxy needs to unstandstand =
application semantics=20
when translating HTTP message into CoAP message.=20
Is it required, or not?=20

Sorry for typing errors in last email.=20

Regards,

Gengyu WEI
Network Technology Center
School of Computer=20
Beijing University of Posts and Telecommunications

From: Rahman, Akbar=20
Sent: Friday, September 25, 2015 12:59 AM
To: Abhijan Bhattacharyya ; weigengyu=20
Cc: Carsten Bormann ; core@ietf.org ; core=20
Subject: RE: [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07

Hi Abhijan,

=20

=20

Okay, please review the updated proposed text for =
draft-ietf-core-http-mapping based on the feedback from Carsten, =
Weigengyu and you.

=20

=20

--------------------------------

(New) Section 8.x =E2=80=9CUse of CoAP No Response=E2=80=9D:

=20

CoAP supports sending a Request indicating that =E2=80=9CNo =
Response=E2=80=9D is required when the CoAP header option number is set =
to 284 [see Ref-1].  An HC Proxy may translate an incoming HTTP Request =
to a corresponding CoAP Request indicating that No Response is required =
based on some application knowledge (see [Ref-2] for further guidance).  =
In this case, it is recommend that the HC Proxy SHOULD send an HTTP =
Response with status code 204 (No Content).

=20

[Ref-1] - =
http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#opt=
ion-numbers

=20

[Ref-2] - =
https://tools.ietf.org/html/draft-tcs-coap-no-response-option-11

=20

---------------------------------

=20

=20

Also, Abhijan, it may be good for you to put the application scenario =
you outlined below in your draft-tcs-coap-no-response-option as that =
should be document that contains all such guidance information.

=20

=20

Do you agree?

=20

=20

/Akbar

=20

=20

=20

From: Abhijan Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com]=20
Sent: Thursday, September 24, 2015 8:53 AM
To: weigengyu ; Rahman, Akbar =

Cc: Carsten Bormann ; core@ietf.org; core =

Subject: Re: [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07

=20

Hi Akbar,=20
Thanks.=20

Taking clue from Gengyu's response I would like to share the following =
input:=20

The decision to convert an HTTP request to a CoAP request with "No =
Response" should be purely based on the application context.=20
Let us consider a scenario.=20
We want to operate the lights of a building from a remote control-center =
(controlling commands may not be essentially multicast). Let us assume =
that the control-center has legacy HTTP infrastructure. But the lights =
are CoAP enabled. So the requests from the control-center goes through =
an HC proxy. The application requirement, in that case, will decide =
whether the requests from HTTP client are to be made CoAP requests with =
No-Response or not.=20

But, there is one point. The HTTP client needs a response as per the =
HTTP protocol requirements. So, what response should proxy return?=20
Looking at Table 2 of the http mapping draft we see that CoAP's 2.04 =
(Changed) is mapped to either 200 (OK) or 204 (No Content) for the HTTP. =
Can we suggest that in cases as described above the proxy SHOULD respond =
with the status code: 204  No Content ? This way the client knows that =
No-Response is enabled at the CoAP side for the particular PUTs.=20

Does it make sense?=20


Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________


"weigengyu"  wrote on 09/24/2015 01:40:50 PM:

> From: "weigengyu" =20
> To: "Rahman, Akbar" , "Abhijan=20
> Bhattacharyya" , "Carsten Bormann"=20
> =20
> Cc: , "core" =20
> Date: 09/24/2015 01:50 PM=20
> Subject: Re: [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07=20
>=20
> Hi=EF=BC=8C=20
> =20
> When a http client accesses a CoAP server,=20
> how does the CoAP client of HC proxy create a NON-reposnse option=20
> since there is not in HTTP.=20
> Or it is useless for HC proxy, or not?=20
> =20
> Regards,=20
> =20
> Gengyu WEI
> Network Technology Center
> School of Computer=20
> Beijing University of Posts and Telecommunications=20
> =20
> From: Rahman, Akbar=20
> Sent: Thursday, September 24, 2015 2:00 AM=20
> To: Abhijan Bhattacharyya ; Carsten Bormann=20
> Cc: mailto:core@ietf.org ; core=20
> Subject: Re: [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07=20
> =20
> Hi Abhijan,=20
> =20
> =20
> Thanks for your support on the draft!=20
> =20
> With regards to your question:=20
> =20
> > Given that No-Response now has a number (284) from IANA in the=20
> CoRE option registry (http://www.iana.org/assignments/core-
> parameters/core-parameters.xhtml#option-numbers) probably it will be
> a good idea to keep a section to discuss how to handle this option=20
> since this is not there in HTTP. Somewhere in Section 8 should be a=20
> good place for such discussion.=20

> =20
> Yes, I agree this is a good topic to add to the draft.  How about=20
> something based on the following text:=20
> =20
> --------------------------------=20
> 8.8 CoAP No Response=20
> =20
> CoAP supports sending a Request indicating that =E2=80=9CNo =
Response=E2=80=9D is=20
> required when the CoAP header option number is set to 284.  An HC=20
> Proxy may translate an incoming HTTP Request to a corresponding CoAP
> Request indicating that no response is required following the guidance =
in=20
> (Ref: http://www.iana.org/assignments/core-parameters/core-
> parameters.xhtml#option-numbers).=20
> =20
> ---------------------------------=20
> =20
> =20
> Any feedback?=20
> =20
> =20
> /Akbar=20
> =20
> =20
> From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan =
Bhattacharyya
> Sent: Thursday, September 17, 2015 5:34 AM
> To: Carsten Bormann 
> Cc: core ; core@ietf.org WG 
> Subject: Re: [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07=20
> =20
> Dear all,=20
> I think this draft is indeed an appreciable effort as it will ease=20
> out many implementation decisions for the developers and should be=20
> very useful as an RFC.=20
>=20
> Dear authors,=20
> I have one small comment :=20
> Given that No-Response now has a number (284) from IANA in the CoRE=20
> option registry (http://www.iana.org/assignments/core-parameters/
> core-parameters.xhtml#option-numbers) probably it will be a good=20
> idea to keep a section to discuss how to handle this option since=20
> this is not there in HTTP. Somewhere in Section 8 should be a good=20
> place for such discussion.=20
>=20
>=20
>=20
> Regards
> Abhijan Bhattacharyya
> Associate Consultant
> Scientist, Innovation Lab, Kolkata, India
> Tata Consultancy Services
> Mailto: abhijan.bhattacharyya@tcs.com
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Consulting
> ____________________________________________
>=20
>=20
>=20
>=20
> From:        Carsten Bormann =20
> To:        "mailto:core@ietf.org%20WG" =20
> Date:        09/15/2015 08:51 PM=20
> Subject:        [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07
> Sent by:        "core" =20
>=20
>=20
>=20
>=20
> In Prague, we said we were going to WGLC the HTTP mapping draft after
> close of the vacation period, which is now behind us.  All outstanding
> tickets are closed, and there was enough time to review the current
> draft.  Three people raised their hands when we asked who would submit
> reviews (Michael K., Klaus, Darshak), but of course additional reviews
> beyond that are also very useful.
>=20
> So this starts a working group last call for
> draft-ietf-core-http-mapping for submission as an informational RFC,
> ending on
>=20
> 24:00 PDT on Tuesday, September 29, 2015.
>=20
> The draft is located at:
> https://tools.ietf.org/html/draft-ietf-core-http-mapping-07
>=20
> Please start a new email thread for each major issue that will need
> discussion and make sure the subject line includes the draft name and
> some sort of name for the issue. For minor issues such as typos and
> things that are not likely to lead to much discussion, it is probably
> easier to group them all in to one email but again, please make sure
> the subject line includes the draft name. If you read the draft and
> think it looks fine, please send a one line email to the list or to
> the chairs letting us know that so we can get a feel of how broad the
> review has been.
>=20
> In the unlikely event that you are aware of any patent claims that
> might apply to systems that implement the suggestions in this draft,
> please review BCP 78 and BCP 79 and make any appropriate IPR
> declaration. If you are not sure whether you need to make a
> declaration or not, please talk to the chairs and we will help get you
> in touch with people that can provide appropriate advice.
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core=20
> =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain=20
> confidential or privileged information. If you are=20
> not the intended recipient, any dissemination, use,=20
> review, distribution, printing or copying of the=20
> information contained in this e-mail message=20
> and/or attachments to it are strictly prohibited. If=20
> you have received this communication in error,=20
> please notify us by reply e-mail or telephone and=20
> immediately and permanently delete the message=20
> and any attachments. Thank you=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core=20



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

------=_NextPart_000_0038_01D0F780.3ED55FB0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

















Hi Abhijan, =



 


It is questionable that whether the HC proxy needs to unstandstand=20
application semantics 


when translating HTTP message into CoAP message. 


Is it required, or not? 


 


Sorry for typing errors in last email. 


 


Regards,


 


Gengyu=20
WEI
Network Technology Center
School of Computer 
Beijing =
University of=20
Posts and Telecommunications





 




From: Rahman, Akbar 


Sent: Friday, September 25, 2015 12:59 AM


To: Abhijan Bhattacharyya =
; weigengyu=20




Subject: RE: [core] WG last-call (WGLC) of=20
draft-ietf-core-http-mapping-07


 





Hi=20
Abhijan,


 


 


Okay,=20
please review the updated proposed text for draft-ietf-core-http-mapping =
based=20
on the feedback from Carsten, Weigengyu and you.


 


 


--------------------------------


(New)=20
Section 8.x =E2=80=9CUse of CoAP No =
Response=E2=80=9D:


 


CoAP=20
supports sending a Request indicating that =E2=80=9CNo Response=E2=80=9D =
is required when the=20
CoAP header option number is set to 284 [see Ref-1].  An HC Proxy =
may=20
translate an incoming HTTP Request to a corresponding CoAP Request =
indicating=20
that No Response is required based on some application knowledge (see =
[Ref-2]=20
for further guidance).  In this case, it is recommend that the HC =
Proxy=20
SHOULD send an HTTP Response with status code 204 (No=20
Content).


 


[Ref-1] - http://www.iana.org/assignments/core-parameters/core-=
parameters.xhtml#option-numbers


 


[Ref-2]=20
- https://tools.ietf.org/html/draft-tcs-coap-no-response-option-11


 


---------------------------------


 


 


Also,=20
Abhijan, it may be good for you to put the application scenario you =
outlined=20
below in your draft-tcs-coap-no-response-option as that should be =
document that=20
contains all such guidance information.


 


 


Do=20
you agree?


 


 


/Akbar


 


 


 


From: Abhijan=20
Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com] 
Sent: =
Thursday,=20
September 24, 2015 8:53 AM
To: weigengyu=20
<weigengyu@bupt.edu.cn>; Rahman, Akbar=20
<Akbar.Rahman@InterDigital.com>
Cc: Carsten Bormann=20
<cabo@tzi.org>; core@ietf.org; core=20
<core-bounces@ietf.org>
Subject: Re: [core] WG last-call =
(WGLC)=20
of draft-ietf-core-http-mapping-07


 


Hi =
Akbar,=20

Thanks.=20


Taking=20
clue from Gengyu's response I would like to share the following =
input:=20


The=20
decision to convert an HTTP request to a CoAP request with "No Response" =
should=20
be purely based on the application context. 
Let us =
consider a=20
scenario. 
We want to =
operate the=20
lights of a building from a remote control-center (controlling commands =
may not=20
be essentially multicast). Let us assume that the control-center has =
legacy HTTP=20
infrastructure. But the lights are CoAP enabled. So the requests from =
the=20
control-center goes through an HC proxy. The application requirement, in =
that=20
case, will decide whether the requests from HTTP client are to be made =
CoAP=20
requests with No-Response or not. 

But, there is =
one=20
point. The HTTP client needs a response as per the HTTP protocol =
requirements.=20
So, what response should proxy return? 
Looking at =
Table 2 of=20
the http mapping draft we see that CoAP's 2.04 (Changed) is mapped to =
either 200=20
(OK) or 204 (No Content) for the HTTP. Can we suggest that in cases as =
described=20
above the proxy SHOULD respond with the status code: 204  No =
Content=20
? This way the client knows that No-Response is enabled at the CoAP side =
for the=20
particular PUTs. 

Does it make=20
sense? 


Regards
Abhijan=20
Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, =
Kolkata,=20
India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.c=
om
Website:=20
http://www.tcs.com
____________________________________________
E=
xperience=20
certainty.        IT=20
Services
          &=
nbsp;           =20
Business=20
Solutions
          =
             =

Consulting
____________________________________________

=

"weigengyu" <weigengyu@bupt.edu.cn> =
wrote on=20
09/24/2015 01:40:50 PM:

> =
From:=20
"weigengyu" <weigengyu@bupt.edu.cn><=
/SPAN>=20

> To: "Rahman, Akbar" <Akbar.Rahman@InterDigital.c=
om>,=20
"Abhijan 
> =
Bhattacharyya"=20
<abhijan.bhattacharyya@tcs.c=
om>,=20
"Carsten Bormann" 
> <cabo@tzi.org> =

> Cc: <core@ietf.org>, "core" <core-bounces@ietf.org>=20

> Date: 09/24/2015 01:50 =
PM=20

> Subject: Re: [core] WG =
last-call=20
(WGLC) of draft-ietf-core-http-mapping-07 
> 
>=20
Hi=EF=BC=8C 
>  
> When a http client accesses a CoAP =
server,=20

> how does the =
CoAP client=20
of HC proxy create a NON-reposnse option 
> since =
there is=20
not in HTTP. 
> Or =
it is=20
useless for HC proxy, or not? 
>  
> Regards, 
>  
> Gengyu WEI
> =
Network=20
Technology Center
> School of Computer 
> =
Beijing=20
University of Posts and Telecommunications 
>  
> From: Rahman, Akbar =

> Sent: Thursday, September 24, 2015 2:00=20
AM 
> To: Abhijan=20
Bhattacharyya ; Carsten Bormann 
> Cc: mailto:core@ietf.org ; core 
> Subject: Re: [core] WG last-call (WGLC) =
of=20
draft-ietf-core-http-mapping-07 
>  
> Hi Abhijan, 
>  
>  
> Thanks for your support on the =
draft!=20

>  =

> With regards to your =
question:=20

>  =

> > Given that No-Response now has a =
number (284)=20
from IANA in the 
> CoRE =
option=20
registry (http://www.iana.org/assignments/core-
>=20
parameters/core-parameters.xhtml#option-numbers) probably it will=20
be
> a good idea to keep a section to discuss how to =
handle this=20
option 
> since this is not there in HTTP. Somewhere in =
Section 8=20
should be a 
> good place for such discussion.=20


> =20

> Yes, I agree =
this is a=20
good topic to add to the draft.  How about 
> =
something based=20
on the following text: 
>  
> =
--------------------------------=20

> 8.8 CoAP No =
Response=20

>  =

> CoAP supports sending a Request =
indicating that =E2=80=9CNo=20
Response=E2=80=9D is 
> =
required when=20
the CoAP header option number is set to 284.  An HC =

> Proxy=20
may translate an incoming HTTP Request to a corresponding =
CoAP
>=20
Request indicating that no response is required following the guidance =
in=20

> (Ref: http://www.iana.org/assignments/core-parameters/core-
>=20
parameters.xhtml#option-numbers). 
>  
> =
---------------------------------=20

>  =

>  
> Any feedback? 
>  
>  
> /Akbar 
>  
>  
> From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan =
Bhattacharyya
> Sent: =
Thursday,=20
September 17, 2015 5:34 AM
> To: Carsten Bormann <cabo@tzi.org>
> Cc: =
core <core-bounces@ietf.org>; core@ietf.org WG <core@ietf.org>
> =
Subject: Re:=20
[core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07=20

>  =

> Dear all, 
> I =
think this=20
draft is indeed an appreciable effort as it will ease 
> =
out many=20
implementation decisions for the developers and should be =

> very=20
useful as an RFC. 
> 
> Dear authors,=20

> I have one small comment : 
> Given =
that=20
No-Response now has a number (284) from IANA in the CoRE =

>=20
option registry (http://www.iana.org/assignments/core-parameters/
>=20
core-parameters.xhtml#option-numbers) probably it will be a good=20

> idea to keep a section to discuss how to handle this =
option=20
since 
> this is not there in HTTP. Somewhere in Section =
8 should=20
be a good 
> place for such discussion. 
> =


> 
> 
> =
Regards
>=20
Abhijan Bhattacharyya
> Associate =
Consultant
>=20
Scientist, Innovation Lab, Kolkata, India
> Tata =
Consultancy=20
Services
> Mailto: abhijan.bhattacharyya@tcs.c=
om
>=20
Website: http://www.tcs.com
>=20
____________________________________________
> Experience =

certainty.        IT=20
Services
>        =
            &=
nbsp;  =20
Business=20
Solutions
>        =
;            =
   =20
Consulting
>=20
____________________________________________
> =

>=20

> 
> 
>=20
From:        Carsten Bormann <cabo@tzi.org> 
>=20
To:        "mailto:core@ietf.org%20WG" <core@ietf.org> 
>=20
Date:        09/15/2015 08:51 PM=20

> Subject:        =
[core] WG=20
last-call (WGLC) of draft-ietf-core-http-mapping-07
> =
Sent=20
by:        "core" <core-bounces@ietf.org>=20

> =

>=20

> 
> 
> In Prague, we said =
we were=20
going to WGLC the HTTP mapping draft after
> close of the =

vacation period, which is now behind us.  All =
outstanding
>=20
tickets are closed, and there was enough time to review the=20
current
> draft.  Three people raised their hands =
when we=20
asked who would submit
> reviews (Michael K., Klaus, =
Darshak),=20
but of course additional reviews
> beyond that are also =
very=20
useful.
> 
> So this starts a working =
group last=20
call for
> draft-ietf-core-http-mapping for submission as =
an=20
informational RFC,
> ending on
> =

>=20
24:00 PDT on Tuesday, September 29, 2015.
> =

> The=20
draft is located at:
> =
https://tools.ietf.org/html/draft-ietf-core-http-mapping-07<=
/TT>
>=20

> Please start a new email thread for each major issue =
that will=20
need
> discussion and make sure the subject line includes =
the=20
draft name and
> some sort of name for the issue. For =
minor=20
issues such as typos and
> things that are not likely to =
lead to=20
much discussion, it is probably
> easier to group them =
all in to=20
one email but again, please make sure
> the subject line =
includes=20
the draft name. If you read the draft and
> think it =
looks fine,=20
please send a one line email to the list or to
> the =
chairs=20
letting us know that so we can get a feel of how broad =
the
>=20
review has been.
> 
> In the unlikely =
event that=20
you are aware of any patent claims that
> might apply to =
systems=20
that implement the suggestions in this draft,
> please =
review BCP=20
78 and BCP 79 and make any appropriate IPR
> declaration. =
If you=20
are not sure whether you need to make a
> declaration or =
not,=20
please talk to the chairs and we will help get you
> in =
touch=20
with people that can provide appropriate advice.
>=20

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

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

>=20
=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
> =
Notice: The=20
information contained in this e-mail
> message and/or =
attachments=20
to it may contain 
> confidential or privileged =
information. If=20
you are 
> not the intended recipient, any dissemination, =
use,=20

> review, distribution, printing or copying of the=20

> information contained in this e-mail message =

>=20
and/or attachments to it are strictly prohibited. If 
> =
you have=20
received this communication in error, 
> please notify us =
by=20
reply e-mail or telephone and 
> immediately and =
permanently=20
delete the message 
> and any attachments. Thank =
you=20

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






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


------=_NextPart_000_0038_01D0F780.3ED55FB0--




From nobody Sun Sep 27 03:38:02 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 81A351ACDB1; Sun, 27 Sep 2015 03:38:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.016
X-Spam-Level: 
X-Spam-Status: No, score=-0.016 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-2.3, RELAY_IS_203=0.994, 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 T4ifanCml4uR; Sun, 27 Sep 2015 03:37:53 -0700 (PDT)
Received: from indelg01.tcs.com (indelg01.tcs.com [203.200.109.55]) by ietfa.amsl.com (Postfix) with ESMTP id 800431ACDAE; Sun, 27 Sep 2015 03:37:50 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2CiBACiwwdW/wQXEqxdDoJJgSFpvx8aAQmFeQKBVREBAQEBAQEBgQqEJAEBAQMBAQEBFwNRCxAFBAINBAMBAQEhBwcnHwkIBgsICQgKiAsVmV6cOgEBAZUFAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4VIaoU+gkGBaREBBgY0DAUHBoMSgRQFhzSFS3SET4MuhRWFRoQDFYQhgyOOKoNtN4I9HIEWRmkBh2GBPwEBAQ
X-IPAS-Result: A2CiBACiwwdW/wQXEqxdDoJJgSFpvx8aAQmFeQKBVREBAQEBAQEBgQqEJAEBAQMBAQEBFwNRCxAFBAINBAMBAQEhBwcnHwkIBgsICQgKiAsVmV6cOgEBAZUFAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4VIaoU+gkGBaREBBgY0DAUHBoMSgRQFhzSFS3SET4MuhRWFRoQDFYQhgyOOKoNtN4I9HIEWRmkBh2GBPwEBAQ
X-IronPort-AV: E=Sophos;i="5.17,597,1437417000"; d="scan'208";a="131270840"
X-DISCLAIMER: FALSE
MIME-Version: 1.0
Importance: Normal
X-Priority: 3 (Normal)
In-Reply-To: 
References: , <55F83752.3090609@tzi.org>  <36F5869FE31AB24485E5E3222C288E1F347BAE99@NABESITE.InterDigital.com>   <36F5869FE31AB24485E5E3222C288E1F347BB47D@NABESITE.InterDigital.com>
From: Abhijan Bhattacharyya 
To: "weigengyu" 
Message-ID: 
Date: Sun, 27 Sep 2015 16:07:42 +0530
X-Mailer: Lotus Domino Web Server Release 9.0.1FP4 June  07, 2015
X-MIMETrack: Serialize by http on InKolM02/TCS(Release 9.0.1FP4|June  07, 2015) at 09/27/2015 16:07:42, Serialize complete at 09/27/2015 16:07:43, Itemize by http on InKolM02/TCS(Release 9.0.1FP4|June  07, 2015) at 09/27/2015 16:07:43, Serialize by smdreal on InKolM02/TCS(Release 9.0.1FP4|June  07, 2015) at 09/27/2015 16:07:43, Serialize by Router on InKolM02/TCS(Release 9.0.1FP4|June  07, 2015) at 09/27/2015 16:07:43
Content-Type: multipart/alternative; boundary="=_alternative 003A623B65257ECD_="
Archived-At: 
Cc: core , core@ietf.org
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
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, 27 Sep 2015 10:38:01 -0000

--=_alternative 003A623B65257ECD_=
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=ISO-8859-1

Hi Akbar,
Thanks!

Hi Gengyu,

>Is it required, or not?=A0
What we intend to ensure is that if any application has a demand to optimiz=
e resources with No-Response option at the CoAP end while the request origi=
nates at the HTTP side, then there should be some guidance in the draft sta=
ting how to handle such situation. It is purely application specific consid=
eration.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
=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
Experience certainty.	IT Services
Business Solutions
Consulting
=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


-----"weigengyu"  wrote: -----

>To: "Rahman, Akbar" , "Abhijan
>Bhattacharyya" 
>From: "weigengyu" 
>Date: 09/25/2015 07:07AM
>Cc: "Carsten Bormann" , , "core"
>
>Subject: Re: [core] WG last-call (WGLC) of
>draft-ietf-core-http-mapping-07
>
>
>
>
>
>
>
>
>
>Hi Abhijan,=20
>=A0
>Thank you for your explainations.
>=A0
>For CoAP to CoAP proxy, there is not any question to use a
>NON-response=20
>option=20
>if the CoAP2CoAP Proxy does not have any knowledge about=20
>applications.
>=A0
>It is questionalbe that whether the HC proxoy needs to unstandstand=20
>application sematics.=20
>Is it required, or not?=20
>=A0
>Regards,
>=A0
>Gengyu=20
>WEI
>Network Technology Center
>School of Computer=20
>Beijing University of=20
>Posts and Telecommunications
>
>
>=A0
>
>From: Rahman, Akbar=20
>Sent: Friday, September 25, 2015 12:59 AM
>To: Abhijan Bhattacharyya ; weigengyu=20
>
>Cc: Carsten=20
>Bormann ; core@ietf.org ; core=20
>Subject: RE: [core] WG last-call (WGLC) of=20
>draft-ietf-core-http-mapping-07
>=A0
>
>
>Hi=20
>Abhijan,
>=A0
>=A0
>Okay,=20
>please review the updated proposed text for
>draft-ietf-core-http-mapping based=20
>on the feedback from Carsten, Weigengyu and you.
>=A0
>=A0
>--------------------------------
>(New)=20
>Section 8.x “Use of CoAP No Response”:
>=A0
>CoAP=20
>supports sending a Request indicating that “No Response” is re=
quired
>when the=20
>CoAP header option number is set to 284 [see Ref-1].=A0 An HC Proxy may
>
>translate an incoming HTTP Request to a corresponding CoAP Request
>indicating=20
>that No Response is required based on some application knowledge (see
>[Ref-2]=20
>for further guidance).=A0 In this case, it is recommend that the HC
>Proxy=20
>SHOULD send an HTTP Response with status code 204 (No=20
>Content).
>=A0
>[Ref-1] -
>http://www.iana.org/assignments/core-parameters/core-parameters.xhtml
>#option-numbers
>=A0
>[Ref-2]=20
>- https://tools.ietf.org/html/draft-tcs-coap-no-response-option-11
>=A0
>---------------------------------
>=A0
>=A0
>Also,=20
>Abhijan, it may be good for you to put the application scenario you
>outlined=20
>below in your draft-tcs-coap-no-response-option as that should be
>document that=20
>contains all such guidance information.
>=A0
>=A0
>Do=20
>you agree?
>=A0
>=A0
>/Akbar
>=A0
>=A0
>=A0
>From: Abhijan=20
>Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com]=20
>Sent: Thursday,=20
>September 24, 2015 8:53 AM
>To: weigengyu=20
>; Rahman, Akbar=20
>
>Cc: Carsten Bormann=20
>; core@ietf.org; core=20
>
>Subject: Re: [core] WG last-call (WGLC)=20
>of draft-ietf-core-http-mapping-07
>=A0
>Hi Akbar,=20
>
>Thanks.=20
>
>
>Taking=20
>clue from Gengyu's response I would like to share the following
>input:=20
>
>
>The=20
>decision to convert an HTTP request to a CoAP request with "No
>Response" should=20
>be purely based on the application context.=20
>Let us consider a=20
>scenario.=20
>We want to operate the=20
>lights of a building from a remote control-center (controlling
>commands may not=20
>be essentially multicast). Let us assume that the control-center has
>legacy HTTP=20
>infrastructure. But the lights are CoAP enabled. So the requests from
>the=20
>control-center goes through an HC proxy. The application requirement,
>in that=20
>case, will decide whether the requests from HTTP client are to be
>made CoAP=20
>requests with No-Response or not.=20
>
>But, there is one=20
>point. The HTTP client needs a response as per the HTTP protocol
>requirements.=20
>So, what response should proxy return?=20
>Looking at Table 2 of=20
>the http mapping draft we see that CoAP's 2.04 (Changed) is mapped to
>either 200=20
>(OK) or 204 (No Content) for the HTTP. Can we suggest that in cases
>as described=20
>above the proxy SHOULD respond with the status code: 204=A0 No Content=20
>? This way the client knows that No-Response is enabled at the CoAP
>side for the=20
>particular PUTs.=20
>
>Does it make=20
>sense?=20
>
>
>Regards
>Abhijan=20
>Bhattacharyya
>Associate Consultant
>Scientist, Innovation Lab, Kolkata,=20
>India
>Tata Consultancy Services
>Mailto: abhijan.bhattacharyya@tcs.com
>Website:=20
>http://www.tcs.com
>=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
>Experience=20
>certainty.=A0=A0=A0=A0=A0=A0=A0 IT=20
>Services
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
>Business=20
>Solutions
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
>Consulting
>=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
>
>
>"weigengyu"  wrote on=20
>09/24/2015 01:40:50 PM:
>
>> From:=20
>"weigengyu" =20
>
>> To: "Rahman, Akbar" ,=20
>"Abhijan=20
>> Bhattacharyya"=20
>,=20
>"Carsten Bormann"=20
>> =20
>> Cc: , "core" =20
>
>> Date: 09/24/2015 01:50 PM=20
>
>> Subject: Re: [core] WG last-call=20
>(WGLC) of draft-ietf-core-http-mapping-07=20
>>=20
>>=20
>Hi=10=81C=20
>>=FF=20
>> When a http client accesses a CoAP server,=20
>
>> how does the CoAP client=20
>of HC proxy create a NON-reposnse option=20
>> since there is=20
>not in HTTP.=20
>> Or it is=20
>useless for HC proxy, or not?=20
>>=FF=20
>> Regards,=20
>>=FF=20
>> Gengyu WEI
>> Network=20
>Technology Center
>> School of Computer=20
>> Beijing=20
>University of Posts and Telecommunications=20
>>=FF=20
>> From: Rahman, Akbar=20
>> Sent: Thursday, September 24, 2015 2:00=20
>AM=20
>> To: Abhijan=20
>Bhattacharyya ; Carsten Bormann=20
>> Cc: mailto:core@ietf.org ; core=20
>> Subject: Re: [core] WG last-call (WGLC) of=20
>draft-ietf-core-http-mapping-07=20
>>=FF=20
>> Hi Abhijan,=20
>>=FF=20
>>=FF=20
>> Thanks for your support on the draft!=20
>
>>=FF=20
>> With regards to your question:=20
>
>>=FF=20
>> > Given that No-Response now has a number (284)=20
>from IANA in the=20
>> CoRE option=20
>registry (http://www.iana.org/assignments/core-
>>=20
>parameters/core-parameters.xhtml#option-numbers) probably it will=20
>be
>> a good idea to keep a section to discuss how to handle this=20
>option=20
>> since this is not there in HTTP. Somewhere in Section 8=20
>should be a=20
>> good place for such discussion.=20
>
>
>>=FF=20
>
>> Yes, I agree this is a=20
>good topic to add to the draft.=FF How about=20
>> something based=20
>on the following text:=20
>>=FF=20
>> --------------------------------=20
>
>> 8.8 CoAP No Response=20
>
>>=FF=20
>> CoAP supports sending a Request indicating that =0F“No=20
>Response=0F” is=20
>> required when=20
>the CoAP header option number is set to 284.=FF An HC=20
>> Proxy=20
>may translate an incoming HTTP Request to a corresponding CoAP
>>=20
>Request indicating that no response is required following the
>guidance in=20
>
>> (Ref: http://www.iana.org/assignments/core-parameters/core-
>>=20
>parameters.xhtml#option-numbers).=20
>>=FF=20
>> ---------------------------------=20
>
>>=FF=20
>>=FF=20
>> Any feedback?=20
>>=FF=20
>>=FF=20
>> /Akbar=20
>>=FF=20
>>=FF=20
>> From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan
>Bhattacharyya
>> Sent: Thursday,=20
>September 17, 2015 5:34 AM
>> To: Carsten Bormann 
>> Cc: core ; core@ietf.org WG 
>> Subject: Re:=20
>[core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07=20
>
>>=FF=20
>> Dear all,=20
>> I think this=20
>draft is indeed an appreciable effort as it will ease=20
>> out many=20
>implementation decisions for the developers and should be=20
>> very=20
>useful as an RFC.=20
>>=20
>> Dear authors,=20
>
>> I have one small comment :=20
>> Given that=20
>No-Response now has a number (284) from IANA in the CoRE=20
>>=20
>option registry (http://www.iana.org/assignments/core-parameters/
>>=20
>core-parameters.xhtml#option-numbers) probably it will be a good=20
>
>> idea to keep a section to discuss how to handle this option=20
>since=20
>> this is not there in HTTP. Somewhere in Section 8 should=20
>be a good=20
>> place for such discussion.=20
>>=20
>
>>=20
>>=20
>> Regards
>>=20
>Abhijan Bhattacharyya
>> Associate Consultant
>>=20
>Scientist, Innovation Lab, Kolkata, India
>> Tata Consultancy=20
>Services
>> Mailto: abhijan.bhattacharyya@tcs.com
>>=20
>Website: http://www.tcs.com
>>=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
>> Experience=20
>certainty.=FF=FF=FF=FF=FF=FF=FF IT=20
>Services
>>=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=20
>Business=20
>Solutions
>>=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=20
>Consulting
>>=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
>>=20
>>=20
>
>>=20
>>=20
>>=20
>From:=FF=FF=FF=FF=FF=FF=FF Carsten Bormann =20
>>=20
>To:=FF=FF=FF=FF=FF=FF=FF "mailto:core@ietf.org%20WG" =20
>>=20
>Date:=FF=FF=FF=FF=FF=FF=FF 09/15/2015 08:51 PM=20
>
>> Subject:=FF=FF=FF=FF=FF=FF=FF [core] WG=20
>last-call (WGLC) of draft-ietf-core-http-mapping-07
>> Sent=20
>by:=FF=FF=FF=FF=FF=FF=FF "core" =20
>
>>=20
>>=20
>
>>=20
>>=20
>> In Prague, we said we were=20
>going to WGLC the HTTP mapping draft after
>> close of the=20
>vacation period, which is now behind us.=FF All outstanding
>>=20
>tickets are closed, and there was enough time to review the=20
>current
>> draft.=FF Three people raised their hands when we=20
>asked who would submit
>> reviews (Michael K., Klaus, Darshak),=20
>but of course additional reviews
>> beyond that are also very=20
>useful.
>>=20
>> So this starts a working group last=20
>call for
>> draft-ietf-core-http-mapping for submission as an=20
>informational RFC,
>> ending on
>>=20
>>=20
>24:00 PDT on Tuesday, September 29, 2015.
>>=20
>> The=20
>draft is located at:
>> https://tools.ietf.org/html/draft-ietf-core-http-mapping-07
>>=20
>
>> Please start a new email thread for each major issue that will=20
>need
>> discussion and make sure the subject line includes the=20
>draft name and
>> some sort of name for the issue. For minor=20
>issues such as typos and
>> things that are not likely to lead to=20
>much discussion, it is probably
>> easier to group them all in to=20
>one email but again, please make sure
>> the subject line includes=20
>the draft name. If you read the draft and
>> think it looks fine,=20
>please send a one line email to the list or to
>> the chairs=20
>letting us know that so we can get a feel of how broad the
>>=20
>review has been.
>>=20
>> In the unlikely event that=20
>you are aware of any patent claims that
>> might apply to systems=20
>that implement the suggestions in this draft,
>> please review BCP=20
>78 and BCP 79 and make any appropriate IPR
>> declaration. If you=20
>are not sure whether you need to make a
>> declaration or not,=20
>please talk to the chairs and we will help get you
>> in touch=20
>with people that can provide appropriate advice.
>>=20
>
>> Gr=81=E1e, 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
>> core mailing=20
>list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core=20
>
>>=20
>=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
>> Notice: The=20
>information contained in this e-mail
>> message and/or attachments=20
>to it may contain=20
>> confidential or privileged information. If=20
>you are=20
>> not the intended recipient, any dissemination, use,=20
>
>> review, distribution, printing or copying of the=20
>
>> information contained in this e-mail message=20
>>=20
>and/or attachments to it are strictly prohibited. If=20
>> you have=20
>received this communication in error,=20
>> please notify us by=20
>reply e-mail or telephone and=20
>> immediately and permanently=20
>delete the message=20
>> and any attachments. Thank you=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
>> core mailing=20
>list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core=20
>
>
--=_alternative 003A623B65257ECD_=
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1
Content-ID: <>


Hi Akbar,
Thanks!

Hi Gengyu,=


>Is it requ=
ired, or not? 
What we intend to ensure is that if an=
y application has a demand to optimize resources with No-Response option at=
 the CoAP end while the request originates at the HTTP side, then there sho=
uld be some guidance in the draft stating how to handle such situation. It =
is purely application specific consideration.

Regards
=0DAbhijan Bhattacharyya
=0D=
Associate Consultant
=0DScienti=
st, Innovation Lab, Kolkata, India
=0DTata Consu=
ltancy Services
=0DMailto: abhijan.bhattacharyya=
@tcs.com
=0DWebsite: http://www.tcs.com
=0D=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
=0DExper=
ience certainty.	IT Services
=0D			Business Solu=
tions
=0D			Consulting
=0D=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
=0D


-----"weigengyu" <weigengyu@b=
upt.edu.cn> wrote: -----

>To: "Rahman, Akbar" <Akbar=
.Rahman@InterDigital.com>, "Abhijan
>Bhattacharyya" <abhijan.bh=
attacharyya@tcs.com>
>From: "weigengyu" <weigengyu@bupt.edu.cn&=
gt;
>Date: 09/25/2015 07:07AM
>Cc: "Carsten Bormann" <cabo@t=
zi.org>, <core@ietf.org>, "core"
><core-bounces@ietf.org&=
gt;
>Subject: Re: [core] WG last-call (WGLC) of
>draft-ietf-cor=
e-http-mapping-07
>
>
>
>
>
>
>>
>
>Hi Abhijan, 
> 
>Thank you for your =
explainations.
> 
>For CoAP to CoAP proxy, there is not an=
y question to use a
>NON-response 
>option 
>if the CoAP2=
CoAP Proxy does not have any knowledge about 
>applications.
>&=
nbsp;
>It is questionalbe that whether the HC proxoy needs to unstand=
stand 
>application sematics. 
>Is it required, or not? 
>=
; 
>Regards,
> 
>Gengyu 
>WEI
>Netw=
ork Technology Center
>School of Computer 
>Beijing University =
of 
>Posts and Telecommunications
>
>
> 
&g=
t;
>From: Rahman, Akbar 
>Sent: Friday, September 25, 2015 12:5=
9 AM
>To: Abhijan Bhattacharyya ; weigengyu 
>
>Cc: Carst=
en 
>Bormann ; core@ietf.org ; core 
>Subject: RE: [core] WG la=
st-call (WGLC) of 
>draft-ietf-core-http-mapping-07
> 
=
>
>
>Hi 
>Abhijan,
> 
> 
>=
Okay, 
>please review the updated proposed text for
>draft-ietf=
-core-http-mapping based 
>on the feedback from Carsten, Weigengyu an=
d you.
> 
> 
>--------------------------------<=
br>>(New) 
>Section 8.x “Use of CoAP No Response”:
=
> 
>CoAP 
>supports sending a Request indicating that &=
#8220;No Response” is required
>when the 
>CoAP header op=
tion number is set to 284 [see Ref-1].  An HC Proxy may
>
>=
;translate an incoming HTTP Request to a corresponding CoAP Request
>=
indicating 
>that No Response is required based on some application k=
nowledge (see
>[Ref-2] 
>for further guidance).  In this c=
ase, it is recommend that the HC
>Proxy 
>SHOULD send an HTTP R=
esponse with status code 204 (No 
>Content).
> 
>[Re=
f-1] -
>http://www.iana.org/assignments/core-parameters/core-paramete=
rs.xhtml
>#option-numbers
> 
>[Ref-2] 
>- http=
s://tools.ietf.org/html/draft-tcs-coap-no-response-option-11
> <=
br>>---------------------------------
> 
> 
>=
;Also, 
>Abhijan, it may be good for you to put the application scena=
rio you
>outlined 
>below in your draft-tcs-coap-no-response-op=
tion as that should be
>document that 
>contains all such guida=
nce information.
> 
> 
>Do 
>you agree?> 
> 
>/Akbar
> 
> 
>=
; 
>From: Abhijan 
>Bhattacharyya [mailto:abhijan.bhattach=
aryya@tcs.com] 
>Sent: Thursday, 
>September 24, 2015 8:53 AM>To: weigengyu 
><weigengyu@bupt.edu.cn>; Rahman, Akbar ><Akbar.Rahman@InterDigital.com>
>Cc: Carsten Bormann 
=
><cabo@tzi.org>; core@ietf.org; core 
><core-bounces@ietf=
.org>
>Subject: Re: [core] WG last-call (WGLC) 
>of draft-ie=
tf-core-http-mapping-07
> 
>Hi Akbar, 
>
>Than=
ks. 
>
>
>Taking 
>clue from Gengyu's response I wo=
uld like to share the following
>input: 
>
>
>The <=
br>>decision to convert an HTTP request to a CoAP request with "No
&g=
t;Response" should 
>be purely based on the application context. 
=
>Let us consider a 
>scenario. 
>We want to operate the 
=
>lights of a building from a remote control-center (controlling
>c=
ommands may not 
>be essentially multicast). Let us assume that the c=
ontrol-center has
>legacy HTTP 
>infrastructure. But the lights=
 are CoAP enabled. So the requests from
>the 
>control-center g=
oes through an HC proxy. The application requirement,
>in that 
&g=
t;case, will decide whether the requests from HTTP client are to be
>=
made CoAP 
>requests with No-Response or not. 
>
>But, th=
ere is one 
>point. The HTTP client needs a response as per the HTTP =
protocol
>requirements. 
>So, what response should proxy return=
? 
>Looking at Table 2 of 
>the http mapping draft we see that =
CoAP's 2.04 (Changed) is mapped to
>either 200 
>(OK) or 204 (N=
o Content) for the HTTP. Can we suggest that in cases
>as described <=
br>>above the proxy SHOULD respond with the status code: 204  No Co=
ntent 
>? This way the client knows that No-Response is enabled at th=
e CoAP
>side for the 
>particular PUTs. 
>
>Does it=
 make 
>sense? 
>
>
>Regards
>Abhijan 
>=
;Bhattacharyya
>Associate Consultant
>Scientist, Innovation Lab=
, Kolkata, 
>India
>Tata Consultancy Services
>Mailto: ab=
hijan.bhattacharyya@tcs.com
>Website: 
>http://www.tcs.com
&=
gt;=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
>Experie=
nce 
>certainty.        IT 
>=
;Services
>         &nbs=
p;             =

>Business 
>Solutions
>     &nb=
sp;            =
     
>Consulting
>=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
>
>
>"weigengyu" <we=
igengyu@bupt.edu.cn> wrote on 
>09/24/2015 01:40:50 PM:
>>> From: 
>"weigengyu" <weigengyu@bupt.edu.cn> 
><=
br>>> To: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>, 
=
>"Abhijan 
>> Bhattacharyya" 
><abhijan.bhattacharyya@=
tcs.com>, 
>"Carsten Bormann" 
>> <cabo@tzi.org> >> Cc: <core@ietf.org>, "core" <core-bounces@ietf.org> =

>
>> Date: 09/24/2015 01:50 PM 
>
>> Subject=
: Re: [core] WG last-call 
>(WGLC) of draft-ietf-core-http-mapping-07=
 
>> 
>> 
>Hi， 
>>  
>&g=
t; When a http client accesses a CoAP server, 
>
>> how does=
 the CoAP client 
>of HC proxy create a NON-reposnse option 
>&=
gt; since there is 
>not in HTTP. 
>> Or it is 
>usele=
ss for HC proxy, or not? 
>>  
>> Regards, 
>&=
gt;  
>> Gengyu WEI
>> Network 
>Technology Ce=
nter
>> School of Computer 
>> Beijing 
>University=
 of Posts and Telecommunications 
>>  
>> From: Rahm=
an, Akbar 
>> Sent: Thursday, September 24, 2015 2:00 
>AM <=
br>>> To: Abhijan 
>Bhattacharyya ; Carsten Bormann 
>>=
; Cc: mailto:core@ietf.org ; core 
>> Subject: Re: [core] WG last-=
call (WGLC) of 
>draft-ietf-core-http-mapping-07 
>>  <=
br>>> Hi Abhijan, 
>>  
>>  
>> =
Thanks for your support on the draft! 
>
>>  
>&g=
t; With regards to your question: 
>
>>  
>> &=
gt; Given that No-Response now has a number (284) 
>from IANA in the =

>> CoRE option 
>registry (http://www.iana.org/assignments/=
core-
>> 
>parameters/core-parameters.xhtml#option-numbers) =
probably it will 
>be
>> a good idea to keep a section to di=
scuss how to handle this 
>option 
>> since this is not ther=
e in HTTP. Somewhere in Section 8 
>should be a 
>> good pla=
ce for such discussion. 
>
>
>>  
>
>=
> Yes, I agree this is a 
>good topic to add to the draft.  H=
ow about 
>> something based 
>on the following text: 
&g=
t;>  
>> -------------------------------- 
>
>=
> 8.8 CoAP No Response 
>
>>  
>> CoAP supp=
orts sending a Request indicating that “No 
>Response” is=
 
>> required when 
>the CoAP header option number is set to=
 284.  An HC 
>> Proxy 
>may translate an incoming HTTP=
 Request to a corresponding CoAP
>> 
>Request indicating tha=
t no response is required following the
>guidance in 
>
>=
> (Ref: http://www.iana.org/assignments/core-parameters/core-
>>=
; 
>parameters.xhtml#option-numbers). 
>>  
>>=
 --------------------------------- 
>
>>  
>>&=
nbsp; 
>> Any feedback? 
>>  
>>  
=
>> /Akbar 
>>  
>>  
>> From: co=
re [mailto:core-bounces@ietf.org] On Behalf Of Abhijan
>Bhattacharyya=

>> Sent: Thursday, 
>September 17, 2015 5:34 AM
>>=
 To: Carsten Bormann <cabo@tzi.org>
>> Cc: core <core-bou=
nces@ietf.org>; core@ietf.org WG <core@ietf.org>
>> Subje=
ct: Re: 
>[core] WG last-call (WGLC) of draft-ietf-core-http-mapping-=
07 
>
>>  
>> Dear all, 
>> I think t=
his 
>draft is indeed an appreciable effort as it will ease 
>&=
gt; out many 
>implementation decisions for the developers and should=
 be 
>> very 
>useful as an RFC. 
>> 
>> D=
ear authors, 
>
>> I have one small comment : 
>> G=
iven that 
>No-Response now has a number (284) from IANA in the CoRE =

>> 
>option registry (http://www.iana.org/assignments/core-=
parameters/
>> 
>core-parameters.xhtml#option-numbers) proba=
bly it will be a good 
>
>> idea to keep a section to discus=
s how to handle this option 
>since 
>> this is not there in=
 HTTP. Somewhere in Section 8 should 
>be a good 
>> place f=
or such discussion. 
>> 
>
>> 
>> 
>=
> Regards
>> 
>Abhijan Bhattacharyya
>> Associat=
e Consultant
>> 
>Scientist, Innovation Lab, Kolkata, India<=
br>>> Tata Consultancy 
>Services
>> Mailto: abhijan.b=
hattacharyya@tcs.com
>> 
>Website: http://www.tcs.com
>=
;> 
>=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>> Experience 
>certainty.      =
  IT 
>Services
>>      &=
nbsp;           &nbs=
p;     
>Business 
>Solutions
>>&n=
bsp;            =
;           
>Consu=
lting
>> 
>=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
>> 
>> 
>
>> 
>> 
&g=
t;> 
>From:        Carsten Borm=
ann <cabo@tzi.org> 
>> 
>To:    &n=
bsp;   "mailto:core@ietf.org%20WG" <core@ietf.org> 
>=
> 
>Date:        09/15/2015 08:=
51 PM 
>
>> Subject:      &nbs=
p; [core] WG 
>last-call (WGLC) of draft-ietf-core-http-mapping-07>> Sent 
>by:        "core"=
 <core-bounces@ietf.org> 
>
>> 
>> 
>>> 
>> 
>> In Prague, we said we were 
>goi=
ng to WGLC the HTTP mapping draft after
>> close of the 
>va=
cation period, which is now behind us.  All outstanding
>> >tickets are closed, and there was enough time to review the 
>c=
urrent
>> draft.  Three people raised their hands when we >asked who would submit
>> reviews (Michael K., Klaus, Darshak=
), 
>but of course additional reviews
>> beyond that are als=
o very 
>useful.
>> 
>> So this starts a working gr=
oup last 
>call for
>> draft-ietf-core-http-mapping for subm=
ission as an 
>informational RFC,
>> ending on
>> <=
br>>> 
>24:00 PDT on Tuesday, September 29, 2015.
>> <=
br>>> The 
>draft is located at:
>> https://tools.ietf=
.org/html/draft-ietf-core-http-mapping-07
>> 
>
>> =
Please start a new email thread for each major issue that will 
>need=

>> discussion and make sure the subject line includes the 
>=
;draft name and
>> some sort of name for the issue. For minor 
=
>issues such as typos and
>> things that are not likely to lead=
 to 
>much discussion, it is probably
>> easier to group the=
m all in to 
>one email but again, please make sure
>> the s=
ubject line includes 
>the draft name. If you read the draft and
&=
gt;> think it looks fine, 
>please send a one line email to the li=
st or to
>> the chairs 
>letting us know that so we can get =
a feel of how broad the
>> 
>review has been.
>> >> In the unlikely event that 
>you are aware of any patent c=
laims that
>> might apply to systems 
>that implement the su=
ggestions in this draft,
>> please review BCP 
>78 and BCP 7=
9 and make any appropriate IPR
>> declaration. If you 
>are =
not sure whether you need to make a
>> declaration or not, 
>=
;please talk to the chairs and we will help get you
>> in touch >with people that can provide appropriate advice.
>> 
>=

>> Gr=FC=DFe, Carsten
>> 
>> 
>=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
>> core =
mailing 
>list
>> core@ietf.org
>> https://www.ietf=
.org/mailman/listinfo/core 
>
>> 
>=3D=3D=3D=3D=3D----=
-=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
>> Notice: The 
>inform=
ation contained in this e-mail
>> message and/or attachments 
&=
gt;to it may contain 
>> confidential or privileged information. I=
f 
>you are 
>> not the intended recipient, any disseminatio=
n, use, 
>
>> review, distribution, printing or copying of t=
he 
>
>> information contained in this e-mail message 
&g=
t;> 
>and/or attachments to it are strictly prohibited. If 
>=
;> you have 
>received this communication in error, 
>> p=
lease notify us by 
>reply e-mail or telephone and 
>> immed=
iately and permanently 
>delete the message 
>> and any atta=
chments. Thank you 
>
>> 
>=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
>> core mailing 
>li=
st
>> core@ietf.org
>> https://www.ietf.org/mailman/listi=
nfo/core 
>
>
--=_alternative 003A623B65257ECD_=--


From nobody Sun Sep 27 21:09: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 927CD1A6FA3 for ; Sun, 27 Sep 2015 21:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level: 
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 pHQJgqOf1vVX for ; Sun, 27 Sep 2015 21:09:19 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id B823F1A6F9F for ; Sun, 27 Sep 2015 21:09:17 -0700 (PDT)
Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id DBB6F19F40E for ; Mon, 28 Sep 2015 12:09:15 +0800 (HKT)
Received: from WeiGengyuPC (unknown [10.103.243.172]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id E0DD619F39C; Mon, 28 Sep 2015 12:09:13 +0800 (HKT)
Message-ID: <95EAA7B6FE5946F392141BB88F7F1D6A@WeiGengyuPC>
From: "weigengyu" 
To: "Abhijan Bhattacharyya" 
References: , <55F83752.3090609@tzi.org>  <36F5869FE31AB24485E5E3222C288E1F347BAE99@NABESITE.InterDigital.com>   <36F5869FE31AB24485E5E3222C288E1F347BB47D@NABESITE.InterDigital.com> 
In-Reply-To: 
Date: Mon, 28 Sep 2015 12:09:12 +0800
Organization: BUPT
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01D0F9E6.7D16E0B0"
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 , core@ietf.org
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
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, 28 Sep 2015 04:09:23 -0000

这是一封 MIME 格式的多方邮件。

------=_NextPart_000_0014_01D0F9E6.7D16E0B0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Abhijan,=20

thank you for your explanations.=20

> if any application has a demand to optimize resources with No-Response =
option at the CoAP end while the request originates at the HTTP side,=20
> then there should be some guidance in the draft stating how to handle =
such situation.
> It is purely application specific consideration.

Yes. =20
I wonder how much intelligence on applications the HC proxy should have, =

and whether the HC proxy draft should touch it.=20

Regards,

Gengyu WEI
Network Technology Center
School of Computer=20
Beijing University of Posts and Telecommunications

From: Abhijan Bhattacharyya=20
Sent: Sunday, September 27, 2015 6:37 PM
To: weigengyu=20
Cc: Akbar.Rahman@InterDigital.com ; Carsten Bormann ; core@ietf.org ; =
core=20
Subject: Re: [core] WG last-call (WGLC) of =
draft-ietf-core-http-mapping-07

Hi Akbar,
Thanks!

Hi Gengyu,

>Is it required, or not?=20
What we intend to ensure is that if any application has a demand to =
optimize resources with No-Response option at the CoAP end while the =
request originates at the HTTP side, then there should be some guidance =
in the draft stating how to handle such situation. It is purely =
application specific consideration.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________



-----"weigengyu"  wrote: -----

>To: "Rahman, Akbar" , "Abhijan
>Bhattacharyya" 
>From: "weigengyu" 
>Date: 09/25/2015 07:07AM
>Cc: "Carsten Bormann" , , "core"
>
>Subject: Re: [core] WG last-call (WGLC) of
>draft-ietf-core-http-mapping-07
>
>
>
>
>
>
>
>
>
>Hi Abhijan,=20
>=20
>Thank you for your explainations.
>=20
>For CoAP to CoAP proxy, there is not any question to use a
>NON-response=20
>option=20
>if the CoAP2CoAP Proxy does not have any knowledge about=20
>applications.
>=20
>It is questionalbe that whether the HC proxoy needs to unstandstand=20
>application sematics.=20
>Is it required, or not?=20
>=20
>Regards,
>=20
>Gengyu=20
>WEI
>Network Technology Center
>School of Computer=20
>Beijing University of=20
>Posts and Telecommunications
>
>
>=20
>
>From: Rahman, Akbar=20
>Sent: Friday, September 25, 2015 12:59 AM
>To: Abhijan Bhattacharyya ; weigengyu=20
>
>Cc: Carsten=20
>Bormann ; core@ietf.org ; core=20
>Subject: RE: [core] WG last-call (WGLC) of=20
>draft-ietf-core-http-mapping-07
>=20
>
>
>Hi=20
>Abhijan,
>=20
>=20
>Okay,=20
>please review the updated proposed text for
>draft-ietf-core-http-mapping based=20
>on the feedback from Carsten, Weigengyu and you.
>=20
>=20
>--------------------------------
>(New)=20
>Section 8.x =E2=80=9CUse of CoAP No Response=E2=80=9D:
>=20
>CoAP=20
>supports sending a Request indicating that =E2=80=9CNo =
Response=E2=80=9D is required
>when the=20
>CoAP header option number is set to 284 [see Ref-1].  An HC Proxy may
>
>translate an incoming HTTP Request to a corresponding CoAP Request
>indicating=20
>that No Response is required based on some application knowledge (see
>[Ref-2]=20
>for further guidance).  In this case, it is recommend that the HC
>Proxy=20
>SHOULD send an HTTP Response with status code 204 (No=20
>Content).
>=20
>[Ref-1] -
>http://www.iana.org/assignments/core-parameters/core-parameters.xhtml
>#option-numbers
>=20
>[Ref-2]=20
>- https://tools.ietf.org/html/draft-tcs-coap-no-response-option-11
>=20
>---------------------------------
>=20
>=20
>Also,=20
>Abhijan, it may be good for you to put the application scenario you
>outlined=20
>below in your draft-tcs-coap-no-response-option as that should be
>document that=20
>contains all such guidance information.
>=20
>=20
>Do=20
>you agree?
>=20
>=20
>/Akbar
>=20
>=20
>=20
>From: Abhijan=20
>Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com]=20
>Sent: Thursday,=20
>September 24, 2015 8:53 AM
>To: weigengyu=20
>; Rahman, Akbar=20
>
>Cc: Carsten Bormann=20
>; core@ietf.org; core=20
>
>Subject: Re: [core] WG last-call (WGLC)=20
>of draft-ietf-core-http-mapping-07
>=20
>Hi Akbar,=20
>
>Thanks.=20
>
>
>Taking=20
>clue from Gengyu's response I would like to share the following
>input:=20
>
>
>The=20
>decision to convert an HTTP request to a CoAP request with "No
>Response" should=20
>be purely based on the application context.=20
>Let us consider a=20
>scenario.=20
>We want to operate the=20
>lights of a building from a remote control-center (controlling
>commands may not=20
>be essentially multicast). Let us assume that the control-center has
>legacy HTTP=20
>infrastructure. But the lights are CoAP enabled. So the requests from
>the=20
>control-center goes through an HC proxy. The application requirement,
>in that=20
>case, will decide whether the requests from HTTP client are to be
>made CoAP=20
>requests with No-Response or not.=20
>
>But, there is one=20
>point. The HTTP client needs a response as per the HTTP protocol
>requirements.=20
>So, what response should proxy return?=20
>Looking at Table 2 of=20
>the http mapping draft we see that CoAP's 2.04 (Changed) is mapped to
>either 200=20
>(OK) or 204 (No Content) for the HTTP. Can we suggest that in cases
>as described=20
>above the proxy SHOULD respond with the status code: 204  No Content=20
>? This way the client knows that No-Response is enabled at the CoAP
>side for the=20
>particular PUTs.=20
>
>Does it make=20
>sense?=20
>
>
>Regards
>Abhijan=20
>Bhattacharyya
>Associate Consultant
>Scientist, Innovation Lab, Kolkata,=20
>India
>Tata Consultancy Services
>Mailto: abhijan.bhattacharyya@tcs.com
>Website:=20
>http://www.tcs.com
>____________________________________________
>Experience=20
>certainty.        IT=20
>Services
>                      =20
>Business=20
>Solutions
>                      =20
>Consulting
>____________________________________________
>
>
>"weigengyu"  wrote on=20
>09/24/2015 01:40:50 PM:
>
>> From:=20
>"weigengyu" =20
>
>> To: "Rahman, Akbar" ,=20
>"Abhijan=20
>> Bhattacharyya"=20
>,=20
>"Carsten Bormann"=20
>> =20
>> Cc: , "core" =20
>
>> Date: 09/24/2015 01:50 PM=20
>
>> Subject: Re: [core] WG last-call=20
>(WGLC) of draft-ietf-core-http-mapping-07=20
>>=20
>>=20
>Hi=EF=BC=8C=20
>> =20
>> When a http client accesses a CoAP server,=20
>
>> how does the CoAP client=20
>of HC proxy create a NON-reposnse option=20
>> since there is=20
>not in HTTP.=20
>> Or it is=20
>useless for HC proxy, or not?=20
>> =20
>> Regards,=20
>> =20
>> Gengyu WEI
>> Network=20
>Technology Center
>> School of Computer=20
>> Beijing=20
>University of Posts and Telecommunications=20
>> =20
>> From: Rahman, Akbar=20
>> Sent: Thursday, September 24, 2015 2:00=20
>AM=20
>> To: Abhijan=20
>Bhattacharyya ; Carsten Bormann=20
>> Cc: mailto:core@ietf.org ; core=20
>> Subject: Re: [core] WG last-call (WGLC) of=20
>draft-ietf-core-http-mapping-07=20
>> =20
>> Hi Abhijan,=20
>> =20
>> =20
>> Thanks for your support on the draft!=20
>
>> =20
>> With regards to your question:=20
>
>> =20
>> > Given that No-Response now has a number (284)=20
>from IANA in the=20
>> CoRE option=20
>registry (http://www.iana.org/assignments/core-
>>=20
>parameters/core-parameters.xhtml#option-numbers) probably it will=20
>be
>> a good idea to keep a section to discuss how to handle this=20
>option=20
>> since this is not there in HTTP. Somewhere in Section 8=20
>should be a=20
>> good place for such discussion.=20
>
>
>> =20
>
>> Yes, I agree this is a=20
>good topic to add to the draft.  How about=20
>> something based=20
>on the following text:=20
>> =20
>> --------------------------------=20
>
>> 8.8 CoAP No Response=20
>
>> =20
>> CoAP supports sending a Request indicating that =E2=80=9CNo=20
>Response=E2=80=9D is=20
>> required when=20
>the CoAP header option number is set to 284.  An HC=20
>> Proxy=20
>may translate an incoming HTTP Request to a corresponding CoAP
>>=20
>Request indicating that no response is required following the
>guidance in=20
>
>> (Ref: http://www.iana.org/assignments/core-parameters/core-
>>=20
>parameters.xhtml#option-numbers).=20
>> =20
>> ---------------------------------=20
>
>> =20
>> =20
>> Any feedback?=20
>> =20
>> =20
>> /Akbar=20
>> =20
>> =20
>> From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan
>Bhattacharyya
>> Sent: Thursday,=20
>September 17, 2015 5:34 AM
>> To: Carsten Bormann 
>> Cc: core ; core@ietf.org WG 
>> Subject: Re:=20
>[core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07=20
>
>> =20
>> Dear all,=20
>> I think this=20
>draft is indeed an appreciable effort as it will ease=20
>> out many=20
>implementation decisions for the developers and should be=20
>> very=20
>useful as an RFC.=20
>>=20
>> Dear authors,=20
>
>> I have one small comment :=20
>> Given that=20
>No-Response now has a number (284) from IANA in the CoRE=20
>>=20
>option registry (http://www.iana.org/assignments/core-parameters/
>>=20
>core-parameters.xhtml#option-numbers) probably it will be a good=20
>
>> idea to keep a section to discuss how to handle this option=20
>since=20
>> this is not there in HTTP. Somewhere in Section 8 should=20
>be a good=20
>> place for such discussion.=20
>>=20
>
>>=20
>>=20
>> Regards
>>=20
>Abhijan Bhattacharyya
>> Associate Consultant
>>=20
>Scientist, Innovation Lab, Kolkata, India
>> Tata Consultancy=20
>Services
>> Mailto: abhijan.bhattacharyya@tcs.com
>>=20
>Website: http://www.tcs.com
>>=20
>____________________________________________
>> Experience=20
>certainty.        IT=20
>Services
>>                       =20
>Business=20
>Solutions
>>                       =20
>Consulting
>>=20
>____________________________________________
>>=20
>>=20
>
>>=20
>>=20
>>=20
>From:        Carsten Bormann =20
>>=20
>To:        "mailto:core@ietf.org%20WG" =20
>>=20
>Date:        09/15/2015 08:51 PM=20
>
>> Subject:        [core] WG=20
>last-call (WGLC) of draft-ietf-core-http-mapping-07
>> Sent=20
>by:        "core" =20
>
>>=20
>>=20
>
>>=20
>>=20
>> In Prague, we said we were=20
>going to WGLC the HTTP mapping draft after
>> close of the=20
>vacation period, which is now behind us.  All outstanding
>>=20
>tickets are closed, and there was enough time to review the=20
>current
>> draft.  Three people raised their hands when we=20
>asked who would submit
>> reviews (Michael K., Klaus, Darshak),=20
>but of course additional reviews
>> beyond that are also very=20
>useful.
>>=20
>> So this starts a working group last=20
>call for
>> draft-ietf-core-http-mapping for submission as an=20
>informational RFC,
>> ending on
>>=20
>>=20
>24:00 PDT on Tuesday, September 29, 2015.
>>=20
>> The=20
>draft is located at:
>> https://tools.ietf.org/html/draft-ietf-core-http-mapping-07
>>=20
>
>> Please start a new email thread for each major issue that will=20
>need
>> discussion and make sure the subject line includes the=20
>draft name and
>> some sort of name for the issue. For minor=20
>issues such as typos and
>> things that are not likely to lead to=20
>much discussion, it is probably
>> easier to group them all in to=20
>one email but again, please make sure
>> the subject line includes=20
>the draft name. If you read the draft and
>> think it looks fine,=20
>please send a one line email to the list or to
>> the chairs=20
>letting us know that so we can get a feel of how broad the
>>=20
>review has been.
>>=20
>> In the unlikely event that=20
>you are aware of any patent claims that
>> might apply to systems=20
>that implement the suggestions in this draft,
>> please review BCP=20
>78 and BCP 79 and make any appropriate IPR
>> declaration. If you=20
>are not sure whether you need to make a
>> declaration or not,=20
>please talk to the chairs and we will help get you
>> in touch=20
>with people that can provide appropriate advice.
>>=20
>
>> Gr=C3=BC=C3=9Fe, Carsten
>>=20
>>=20
>_______________________________________________
>> core mailing=20
>list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core=20
>
>>=20
>=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
>> Notice: The=20
>information contained in this e-mail
>> message and/or attachments=20
>to it may contain=20
>> confidential or privileged information. If=20
>you are=20
>> not the intended recipient, any dissemination, use,=20
>
>> review, distribution, printing or copying of the=20
>
>> information contained in this e-mail message=20
>>=20
>and/or attachments to it are strictly prohibited. If=20
>> you have=20
>received this communication in error,=20
>> please notify us by=20
>reply e-mail or telephone and=20
>> immediately and permanently=20
>delete the message=20
>> and any attachments. Thank you=20
>
>>=20
>_______________________________________________
>> core mailing=20
>list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core=20
>
>
------=_NextPart_000_0014_01D0F9E6.7D16E0B0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable








Hi Abhijan, 


 


thank you for your explanations. 


 


> if any =
application=20
has a demand to optimize resources with No-Response option at the CoAP =
end while=20
the request originates at the HTTP side, 


> then =
there should be=20
some guidance in the draft stating how to handle such=20
situation.


> It is =
purely=20
application specific consideration.


 


Yes.  


I wonder how much intelligence on applications the HC proxy should =
have,=20



and whether the HC proxy draft should touch it. 

 

Regards,

 

Gengyu=20
WEI
Network Technology Center
School of Computer 
Beijing =
University of=20
Posts and Telecommunications





 




From: Abhijan Bhattacharyya =



Sent: Sunday, September 27, 2015 6:37 PM



Cc: Akbar.Rahman@InterDigital.c=
om ;=20
Carsten Bormann =
; core@ietf.org ; =
core 


Subject: Re: [core] WG last-call (WGLC) of=20
draft-ietf-core-http-mapping-07


 



Hi Akbar,


Thanks!


 


Hi Gengyu,


 


>Is it required, or not? =



What we intend to ensure is that if any application has a demand to =

optimize resources with No-Response option at the CoAP end while the =
request=20
originates at the HTTP side, then there should be some guidance in the =
draft=20
stating how to handle such situation. It is purely application specific=20
consideration.



Regards
Abhijan=20
Bhattacharyya
Associate =
Consultant
Scientist, Innovation Lab, Kolkata, India
Tata=20
Consultancy Services
Mailto:=20
abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business=20
Solutions
Consulting
____________________________________________

-----"weigengyu" <weigengyu@bupt.edu.cn> wrote:=20
-----

>To: "Rahman, Akbar"=20
<Akbar.Rahman@InterDigital.com>, "Abhijan
>Bhattacharyya"=20
<abhijan.bhattacharyya@tcs.com>
>From: "weigengyu"=20
<weigengyu@bupt.edu.cn>
>Date: 09/25/2015 07:07AM
>Cc: =

"Carsten Bormann" <cabo@tzi.org>, <core@ietf.org>,=20
"core"
><core-bounces@ietf.org>
>Subject: Re: [core] =
WG=20
last-call (WGLC)=20
of
>draft-ietf-core-http-mapping-07
>
>
>
>=

>
>
>
>
>
>Hi=20
Abhijan, 
> 
>Thank you for your explainations.
> =

>For=20
CoAP to CoAP proxy, there is not any question to use =
a
>NON-response=20

>option 
>if the CoAP2CoAP Proxy does not have any =
knowledge about=20

>applications.
> 
>It is questionalbe that whether =
the HC=20
proxoy needs to unstandstand 
>application sematics. 
>Is it =

required, or not? 
> 
>Regards,
> 
>Gengyu=20

>WEI
>Network Technology Center
>School of Computer=20

>Beijing University of 
>Posts and=20
Telecommunications
>
>
> 
>
>From: Rahman, =
Akbar=20

>Sent: Friday, September 25, 2015 12:59 AM
>To: Abhijan=20
Bhattacharyya ; weigengyu 
>
>Cc: Carsten 
>Bormann ;=20
core@ietf.org ; core 
>Subject: RE: [core] WG last-call (WGLC) of=20

>draft-ietf-core-http-mapping-07
> =

>
>
>Hi=20

>Abhijan,
> 
> 
>Okay, 
>please review =
the=20
updated proposed text for
>draft-ietf-core-http-mapping based =

>on=20
the feedback from Carsten, Weigengyu and you.
> 
>=20

>--------------------------------
>(New) 
>Section =
8.x =E2=80=9CUse=20
of CoAP No Response=E2=80=9D:
> 
>CoAP 
>supports =
sending a Request=20
indicating that =E2=80=9CNo Response=E2=80=9D is required
>when =
the 
>CoAP header=20
option number is set to 284 [see Ref-1].  An HC Proxy=20
may
>
>translate an incoming HTTP Request to a corresponding =
CoAP=20
Request
>indicating 
>that No Response is required based on =
some=20
application knowledge (see
>[Ref-2] 
>for further =
guidance). =20
In this case, it is recommend that the HC
>Proxy 
>SHOULD =
send an=20
HTTP Response with status code 204 (No 
>Content).
> =

>[Ref-1]=20
-
>http://www.iana.org/assignments/core-parameters/core-parameters.=
xhtml
>#option-numbers
>=20

>[Ref-2] 
>-=20
https://tools.ietf.org/html/draft-tcs-coap-no-response-option-11
> =


>---------------------------------
> 
> 
>Also, =


>Abhijan, it may be good for you to put the application scenario=20
you
>outlined 
>below in your =
draft-tcs-coap-no-response-option as=20
that should be
>document that 
>contains all such guidance=20
information.
> 
> 
>Do 
>you agree?
> =

>=20

>/Akbar
> 
> 
> 
>From: Abhijan=20

>Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com] =

>Sent:=20
Thursday, 
>September 24, 2015 8:53 AM
>To: weigengyu=20

><weigengyu@bupt.edu.cn>; Rahman, Akbar=20

><Akbar.Rahman@InterDigital.com>
>Cc: Carsten Bormann =


><cabo@tzi.org>; core@ietf.org; core=20

><core-bounces@ietf.org>
>Subject: Re: [core] WG =
last-call=20
(WGLC) 
>of draft-ietf-core-http-mapping-07
> 
>Hi =
Akbar,=20

>
>Thanks. 
>
>
>Taking 
>clue from =

Gengyu's response I would like to share the following
>input:=20

>
>
>The 
>decision to convert an HTTP request =
to a=20
CoAP request with "No
>Response" should 
>be purely based on =
the=20
application context. 
>Let us consider a 
>scenario. =

>We want=20
to operate the 
>lights of a building from a remote control-center =

(controlling
>commands may not 
>be essentially multicast). =
Let us=20
assume that the control-center has
>legacy HTTP =

>infrastructure.=20
But the lights are CoAP enabled. So the requests from
>the=20

>control-center goes through an HC proxy. The application=20
requirement,
>in that 
>case, will decide whether the =
requests from=20
HTTP client are to be
>made CoAP 
>requests with No-Response =
or not.=20

>
>But, there is one 
>point. The HTTP client needs a =

response as per the HTTP protocol
>requirements. 
>So, what =
response=20
should proxy return? 
>Looking at Table 2 of 
>the http =
mapping=20
draft we see that CoAP's 2.04 (Changed) is mapped to
>either 200=20

>(OK) or 204 (No Content) for the HTTP. Can we suggest that in=20
cases
>as described 
>above the proxy SHOULD respond with =
the status=20
code: 204  No Content 
>? This way the client knows that =
No-Response=20
is enabled at the CoAP
>side for the 
>particular PUTs.=20

>
>Does it make 
>sense?=20

>
>
>Regards
>Abhijan=20

>Bhattacharyya
>Associate Consultant
>Scientist, =
Innovation=20
Lab, Kolkata, 
>India
>Tata Consultancy =
Services
>Mailto:=20
abhijan.bhattacharyya@tcs.com
>Website:=20

>http://www.tcs.com
>_______________________________________=
_____
>Experience=20

>certainty.        IT=20

>Services
>        &=
nbsp;           &n=
bsp; =20

>Business=20

>Solutions
>        =
            &=
nbsp; =20

>Consulting
>____________________________________________>
>
>"weigengyu"=20
<weigengyu@bupt.edu.cn> wrote on 
>09/24/2015 01:40:50=20
PM:
>
>> From: 
>"weigengyu" =
<weigengyu@bupt.edu.cn>=20

>
>> To: "Rahman, Akbar" =
<Akbar.Rahman@InterDigital.com>,=20

>"Abhijan 
>> Bhattacharyya"=20

><abhijan.bhattacharyya@tcs.com>, 
>"Carsten Bormann" =


>> <cabo@tzi.org> 
>> Cc: =
<core@ietf.org>, "core"=20
<core-bounces@ietf.org> 
>
>> Date: 09/24/2015 =
01:50 PM=20

>
>> Subject: Re: [core] WG last-call 
>(WGLC) of=20
draft-ietf-core-http-mapping-07 
>> 
>> =

>Hi=EF=BC=8C=20

>>  
>> When a http client accesses a CoAP =
server,=20

>
>> how does the CoAP client 
>of HC proxy create =
a=20
NON-reposnse option 
>> since there is 
>not in HTTP.=20

>> Or it is 
>useless for HC proxy, or not? =

>> =20

>> Regards, 
>>  
>> Gengyu =
WEI
>>=20
Network 
>Technology Center
>> School of Computer =

>>=20
Beijing 
>University of Posts and Telecommunications =

>> =20

>> From: Rahman, Akbar 
>> Sent: Thursday, September =
24, 2015=20
2:00 
>AM 
>> To: Abhijan 
>Bhattacharyya ; Carsten =
Bormann=20

>> Cc: mailto:core@ietf.org ; core 
>> Subject: Re: =
[core] WG=20
last-call (WGLC) of 
>draft-ietf-core-http-mapping-07 =

>> =20

>> Hi Abhijan, 
>>  
>>  =

>>=20
Thanks for your support on the draft! 
>
>>  =

>>=20
With regards to your question: 
>
>>  
>> =
>=20
Given that No-Response now has a number (284) 
>from IANA in the=20

>> CoRE option 
>registry=20
(http://www.iana.org/assignments/core-
>>=20

>parameters/core-parameters.xhtml#option-numbers) probably it =
will=20

>be
>> a good idea to keep a section to discuss how to =
handle=20
this 
>option 
>> since this is not there in HTTP. =
Somewhere in=20
Section 8 
>should be a 
>> good place for such =
discussion.=20

>
>
>>  
>
>> Yes, I agree =
this is a=20

>good topic to add to the draft.  How about 
>> =
something=20
based 
>on the following text: 
>>  
>>=20
-------------------------------- 
>
>> 8.8 CoAP No =
Response=20

>
>>  
>> CoAP supports sending a Request=20
indicating that =E2=80=9CNo 
>Response=E2=80=9D is 
>> =
required when 
>the=20
CoAP header option number is set to 284.  An HC 
>> Proxy=20

>may translate an incoming HTTP Request to a corresponding=20
CoAP
>> 
>Request indicating that no response is required =

following the
>guidance in 
>
>> (Ref:=20
http://www.iana.org/assignments/core-parameters/core-
>>=20

>parameters.xhtml#option-numbers). 
>>  =

>>=20
--------------------------------- 
>
>>  =

>> =20

>> Any feedback? 
>>  
>>  =

>>=20
/Akbar 
>>  
>>  
>> From: core=20
[mailto:core-bounces@ietf.org] On Behalf Of=20
Abhijan
>Bhattacharyya
>> Sent: Thursday, =

>September 17,=20
2015 5:34 AM
>> To: Carsten Bormann =
<cabo@tzi.org>
>>=20
Cc: core <core-bounces@ietf.org>; core@ietf.org WG=20
<core@ietf.org>
>> Subject: Re: 
>[core] WG =
last-call=20
(WGLC) of draft-ietf-core-http-mapping-07 
>
>> =20

>> Dear all, 
>> I think this 
>draft is indeed =
an=20
appreciable effort as it will ease 
>> out many =

>implementation=20
decisions for the developers and should be 
>> very =

>useful as=20
an RFC. 
>> 
>> Dear authors, 
>
>> I =
have one=20
small comment : 
>> Given that 
>No-Response now has a =
number=20
(284) from IANA in the CoRE 
>> 
>option registry=20
(http://www.iana.org/assignments/core-parameters/
>>=20

>core-parameters.xhtml#option-numbers) probably it will be a good =


>
>> idea to keep a section to discuss how to handle =
this option=20

>since 
>> this is not there in HTTP. Somewhere in =
Section 8=20
should 
>be a good 
>> place for such discussion. =

>>=20

>
>> 
>> 
>> Regards
>>=20

>Abhijan Bhattacharyya
>> Associate =
Consultant
>>=20

>Scientist, Innovation Lab, Kolkata, India
>> Tata =
Consultancy=20

>Services
>> Mailto: =
abhijan.bhattacharyya@tcs.com
>>=20

>Website: http://www.tcs.com
>>=20

>____________________________________________
>> =
Experience=20

>certainty.        IT=20

>Services
>>       &nb=
sp;           &nbs=
p;   =20

>Business=20

>Solutions
>>       &n=
bsp;           &nb=
sp;   =20

>Consulting
>>=20

>____________________________________________
>> =

>>=20

>
>> 
>> 
>>=20

>From:        Carsten Bormann=20
<cabo@tzi.org> 
>>=20

>To:       =20
"mailto:core@ietf.org%20WG" <core@ietf.org> 
>>=20

>Date:        09/15/2015 08:51 =
PM=20

>
>> Subject:        =
[core]=20
WG 
>last-call (WGLC) of =
draft-ietf-core-http-mapping-07
>> Sent=20

>by:        "core"=20
<core-bounces@ietf.org> 
>
>> 
>>=20

>
>> 
>> 
>> In Prague, we said we =
were=20

>going to WGLC the HTTP mapping draft after
>> close of =
the=20

>vacation period, which is now behind us.  All=20
outstanding
>> 
>tickets are closed, and there was enough =
time to=20
review the 
>current
>> draft.  Three people raised =
their=20
hands when we 
>asked who would submit
>> reviews =
(Michael K.,=20
Klaus, Darshak), 
>but of course additional reviews
>> =
beyond=20
that are also very 
>useful.
>> 
>> So this =
starts a=20
working group last 
>call for
>> =
draft-ietf-core-http-mapping for=20
submission as an 
>informational RFC,
>> ending =
on
>>=20

>> 
>24:00 PDT on Tuesday, September 29, =
2015.
>>=20

>> The 
>draft is located at:
>>=20
https://tools.ietf.org/html/draft-ietf-core-http-mapping-07
>>=20

>
>> Please start a new email thread for each major =
issue that=20
will 
>need
>> discussion and make sure the subject line =
includes=20
the 
>draft name and
>> some sort of name for the issue. =
For=20
minor 
>issues such as typos and
>> things that are not =
likely to=20
lead to 
>much discussion, it is probably
>> easier to =
group them=20
all in to 
>one email but again, please make sure
>> the =
subject=20
line includes 
>the draft name. If you read the draft =
and
>>=20
think it looks fine, 
>please send a one line email to the list or =

to
>> the chairs 
>letting us know that so we can get a =
feel of=20
how broad the
>> 
>review has been.
>> =

>> In=20
the unlikely event that 
>you are aware of any patent claims=20
that
>> might apply to systems 
>that implement the =
suggestions=20
in this draft,
>> please review BCP 
>78 and BCP 79 and =
make any=20
appropriate IPR
>> declaration. If you 
>are not sure =
whether you=20
need to make a
>> declaration or not, 
>please talk to =
the chairs=20
and we will help get you
>> in touch 
>with people that =
can=20
provide appropriate advice.
>> 
>
>> =
Gr=C3=BC=C3=9Fe,=20
Carsten
>> 
>>=20

>_______________________________________________
>> core =
mailing=20

>list
>> core@ietf.org
>>=20
https://www.ietf.org/mailman/listinfo/core 
>
>>=20

>=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
>&g=
t; Notice: The 
>information=20
contained in this e-mail
>> message and/or attachments =

>to it=20
may contain 
>> confidential or privileged information. If =

>you=20
are 
>> not the intended recipient, any dissemination, use,=20

>
>> review, distribution, printing or copying of the=20

>
>> information contained in this e-mail message =

>>=20

>and/or attachments to it are strictly prohibited. If =

>> you=20
have 
>received this communication in error, 
>> please =
notify us=20
by 
>reply e-mail or telephone and 
>> immediately and=20
permanently 
>delete the message 
>> and any attachments. =
Thank=20
you 
>
>>=20

>_______________________________________________
>> core =
mailing=20

>list
>> core@ietf.org
>>=20
https://www.ietf.org/mailman/listinfo/core=20

>
>

------=_NextPart_000_0014_01D0F9E6.7D16E0B0--



From nobody Sun Sep 27 22:16: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 69D461A8824; Sun, 27 Sep 2015 22:16:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.216
X-Spam-Level: 
X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RELAY_IS_203=0.994, 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 YUw3Vbvk8MJl; Sun, 27 Sep 2015 22:16:26 -0700 (PDT)
Received: from indelg01.tcs.com (indelg01.tcs.com [203.200.109.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8633E1A87DB; Sun, 27 Sep 2015 22:16:22 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2DLAQC2ywhW/wQXEqxcg3hpvToBDYFXGgEJhXkCHIFMFAEBAQEBAQGBCoQkAQEBAwEBAQEXAwZLCwULCQIHBgQDAQEBIQcDAgICJR8JCAYLCAkSiAsVmQicOgEBAW+UIwEBAQEBAQEBAQEBAQEBAQEBAQEBAReFSGqFPoJBgWkRAQYGKgoMAQQHBoJjL4EUBYc0hUt0h32FFYVGhAMVhCGDI44qg20fAQGCUxyBXGmHYoE/AQEB
X-IPAS-Result: A2DLAQC2ywhW/wQXEqxcg3hpvToBDYFXGgEJhXkCHIFMFAEBAQEBAQGBCoQkAQEBAwEBAQEXAwZLCwULCQIHBgQDAQEBIQcDAgICJR8JCAYLCAkSiAsVmQicOgEBAW+UIwEBAQEBAQEBAQEBAQEBAQEBAQEBAReFSGqFPoJBgWkRAQYGKgoMAQQHBoJjL4EUBYc0hUt0h32FFYVGhAMVhCGDI44qg20fAQGCUxyBXGmHYoE/AQEB
X-IronPort-AV: E=Sophos;i="5.17,601,1437417000"; d="scan'208";a="131432545"
X-DISCLAIMER: FALSE
In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F347BB47D@NABESITE.InterDigital.com>
References: <55F83752.3090609@tzi.org>  <36F5869FE31AB24485E5E3222C288E1F347BAE99@NABESITE.InterDigital.com>   <36F5869FE31AB24485E5E3222C288E1F347BB47D@NABESITE.InterDigital.com>
To: "Rahman, Akbar" 
MIME-Version: 1.0
X-KeepSent: BBD22ECC:EFC1B41B-65257ECE:001CB874; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0 March 08, 2013
Message-ID: 
From: Abhijan Bhattacharyya 
Date: Mon, 28 Sep 2015 10:46:14 +0530
X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4|June  07, 2015) at 09/28/2015 10:46:17, Serialize complete at 09/28/2015 10:46:17
Content-Type: multipart/alternative; boundary="=_alternative 001CF37B65257ECE_="
Archived-At: 
Cc: core , "core@ietf.org" 
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
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, 28 Sep 2015 05:16:30 -0000

This is a multipart message in MIME format.
--=_alternative 001CF37B65257ECE_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

SGkgQWtiYXIsDQoNCj4gQWxzbywgQWJoaWphbiwgaXQgbWF5IGJlIGdvb2QgZm9yIHlvdSB0byBw
dXQgdGhlIGFwcGxpY2F0aW9uIA0KPiBzY2VuYXJpbyB5b3Ugb3V0bGluZWQgYmVsb3cgaW4geW91
ciBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS0NCj4gb3B0aW9uIGFzIHRoYXQgc2hvdWxkIGJl
IGRvY3VtZW50IHRoYXQgY29udGFpbnMgYWxsIHN1Y2ggZ3VpZGFuY2UgDQppbmZvcm1hdGlvbi4N
Cj4gDQo+IA0KPiBEbyB5b3UgYWdyZWU/DQoNCkxldCB1cyBjb2xsZWN0IGFsbCB0aGUgY29tbWVu
dHMgd2l0aGluIHRoZSBkZWFkbGluZSAoMjAxNS0xMC0xMikgc2V0IGJ5IA0KQ2Fyc3RlbiB0aGVu
IHdlIG1heSBkZWNpZGUgdGhlIG1vZGlmaWNhdGlvbnMgY29sbGVjdGl2ZWx5LiANCg0KUmVnYXJk
cw0KQWJoaWphbiBCaGF0dGFjaGFyeXlhDQpBc3NvY2lhdGUgQ29uc3VsdGFudA0KU2NpZW50aXN0
LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWENClRhdGEgQ29uc3VsdGFuY3kgU2Vydmlj
ZXMNCk1haWx0bzogYWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20NCldlYnNpdGU6IGh0dHA6
Ly93d3cudGNzLmNvbQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCkV4cGVyaWVuY2UgY2VydGFpbnR5LiAgIElUIFNlcnZpY2VzDQogICAgICAgICAgICAgICAg
ICAgICAgICBCdXNpbmVzcyBTb2x1dGlvbnMNCiAgICAgICAgICAgICAgICAgICAgICAgIENvbnN1
bHRpbmcNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0K
IlJhaG1hbiwgQWtiYXIiIDxBa2Jhci5SYWhtYW5ASW50ZXJEaWdpdGFsLmNvbT4gd3JvdGUgb24g
MDkvMjQvMjAxNSANCjEwOjI5OjU1IFBNOg0KDQo+IEZyb206ICJSYWhtYW4sIEFrYmFyIiA8QWti
YXIuUmFobWFuQEludGVyRGlnaXRhbC5jb20+DQo+IFRvOiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEg
PGFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPiwgd2VpZ2VuZ3l1DQo+IDx3ZWlnZW5neXVA
YnVwdC5lZHUuY24+DQo+IENjOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4sICJjb3Jl
QGlldGYub3JnIiA8Y29yZUBpZXRmLm9yZz4sDQo+IGNvcmUgPGNvcmUtYm91bmNlc0BpZXRmLm9y
Zz4NCj4gRGF0ZTogMDkvMjQvMjAxNSAxMDozMCBQTQ0KPiBTdWJqZWN0OiBSRTogW2NvcmVdIFdH
IGxhc3QtY2FsbCAoV0dMQykgb2YgDQpkcmFmdC1pZXRmLWNvcmUtaHR0cC1tYXBwaW5nLTA3DQo+
IA0KPiBIaSBBYmhpamFuLA0KPiANCj4gDQo+IE9rYXksIHBsZWFzZSByZXZpZXcgdGhlIHVwZGF0
ZWQgcHJvcG9zZWQgdGV4dCBmb3IgZHJhZnQtaWV0Zi1jb3JlLQ0KPiBodHRwLW1hcHBpbmcgYmFz
ZWQgb24gdGhlIGZlZWRiYWNrIGZyb20gQ2Fyc3RlbiwgV2VpZ2VuZ3l1IGFuZCB5b3UuDQo+IA0K
PiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gKE5ldykgU2VjdGlvbiA4
Lngg4oCcVXNlIG9mIENvQVAgTm8gUmVzcG9uc2XigJ06DQo+IA0KPiBDb0FQIHN1cHBvcnRzIHNl
bmRpbmcgYSBSZXF1ZXN0IGluZGljYXRpbmcgdGhhdCDigJxObyBSZXNwb25zZeKAnSBpcyANCj4g
cmVxdWlyZWQgd2hlbiB0aGUgQ29BUCBoZWFkZXIgb3B0aW9uIG51bWJlciBpcyBzZXQgdG8gMjg0
IFtzZWUgDQo+IFJlZi0xXS4gIEFuIEhDIFByb3h5IG1heSB0cmFuc2xhdGUgYW4gaW5jb21pbmcg
SFRUUCBSZXF1ZXN0IHRvIGEgDQo+IGNvcnJlc3BvbmRpbmcgQ29BUCBSZXF1ZXN0IGluZGljYXRp
bmcgdGhhdCBObyBSZXNwb25zZSBpcyByZXF1aXJlZCANCj4gYmFzZWQgb24gc29tZSBhcHBsaWNh
dGlvbiBrbm93bGVkZ2UgKHNlZSBbUmVmLTJdIGZvciBmdXJ0aGVyIA0KPiBndWlkYW5jZSkuICBJ
biB0aGlzIGNhc2UsIGl0IGlzIHJlY29tbWVuZCB0aGF0IHRoZSBIQyBQcm94eSBTSE9VTEQgDQo+
IHNlbmQgYW4gSFRUUCBSZXNwb25zZSB3aXRoIHN0YXR1cyBjb2RlIDIwNCAoTm8gQ29udGVudCku
DQo+IA0KPiBbUmVmLTFdIC0gaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9jb3JlLXBh
cmFtZXRlcnMvY29yZS0NCj4gcGFyYW1ldGVycy54aHRtbCNvcHRpb24tbnVtYmVycw0KPiANCj4g
W1JlZi0yXSAtIA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRjcy1jb2FwLW5v
LXJlc3BvbnNlLW9wdGlvbi0xMQ0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQo+IA0KPiANCj4gQWxzbywgQWJoaWphbiwgaXQgbWF5IGJlIGdvb2QgZm9yIHlvdSB0byBw
dXQgdGhlIGFwcGxpY2F0aW9uIA0KPiBzY2VuYXJpbyB5b3Ugb3V0bGluZWQgYmVsb3cgaW4geW91
ciBkcmFmdC10Y3MtY29hcC1uby1yZXNwb25zZS0NCj4gb3B0aW9uIGFzIHRoYXQgc2hvdWxkIGJl
IGRvY3VtZW50IHRoYXQgY29udGFpbnMgYWxsIHN1Y2ggZ3VpZGFuY2UgDQppbmZvcm1hdGlvbi4N
Cj4gDQo+IA0KPiBEbyB5b3UgYWdyZWU/DQo+IA0KPiANCj4gL0FrYmFyDQo+IA0KPiANCj4gDQo+
IEZyb206IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSBbbWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5
YUB0Y3MuY29tXSANCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyNCwgMjAxNSA4OjUzIEFN
DQo+IFRvOiB3ZWlnZW5neXUgPHdlaWdlbmd5dUBidXB0LmVkdS5jbj47IFJhaG1hbiwgQWtiYXIg
DQo+IDxBa2Jhci5SYWhtYW5ASW50ZXJEaWdpdGFsLmNvbT4NCj4gQ2M6IENhcnN0ZW4gQm9ybWFu
biA8Y2Fib0B0emkub3JnPjsgY29yZUBpZXRmLm9yZzsgY29yZSA8Y29yZS0NCj4gYm91bmNlc0Bp
ZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtjb3JlXSBXRyBsYXN0LWNhbGwgKFdHTEMpIG9mIA0K
ZHJhZnQtaWV0Zi1jb3JlLWh0dHAtbWFwcGluZy0wNw0KPiANCj4gSGkgQWtiYXIsIA0KPiBUaGFu
a3MuIA0KPiANCj4gVGFraW5nIGNsdWUgZnJvbSBHZW5neXUncyByZXNwb25zZSBJIHdvdWxkIGxp
a2UgdG8gc2hhcmUgdGhlIGZvbGxvd2luZyANCmlucHV0Og0KPiANCj4gVGhlIGRlY2lzaW9uIHRv
IGNvbnZlcnQgYW4gSFRUUCByZXF1ZXN0IHRvIGEgQ29BUCByZXF1ZXN0IHdpdGggIk5vIA0KPiBS
ZXNwb25zZSIgc2hvdWxkIGJlIHB1cmVseSBiYXNlZCBvbiB0aGUgYXBwbGljYXRpb24gY29udGV4
dC4gDQo+IExldCB1cyBjb25zaWRlciBhIHNjZW5hcmlvLiANCj4gV2Ugd2FudCB0byBvcGVyYXRl
IHRoZSBsaWdodHMgb2YgYSBidWlsZGluZyBmcm9tIGEgcmVtb3RlIGNvbnRyb2wtDQo+IGNlbnRl
ciAoY29udHJvbGxpbmcgY29tbWFuZHMgbWF5IG5vdCBiZSBlc3NlbnRpYWxseSBtdWx0aWNhc3Qp
LiBMZXQgDQo+IHVzIGFzc3VtZSB0aGF0IHRoZSBjb250cm9sLWNlbnRlciBoYXMgbGVnYWN5IEhU
VFAgaW5mcmFzdHJ1Y3R1cmUuIA0KPiBCdXQgdGhlIGxpZ2h0cyBhcmUgQ29BUCBlbmFibGVkLiBT
byB0aGUgcmVxdWVzdHMgZnJvbSB0aGUgY29udHJvbC0NCj4gY2VudGVyIGdvZXMgdGhyb3VnaCBh
biBIQyBwcm94eS4gVGhlIGFwcGxpY2F0aW9uIHJlcXVpcmVtZW50LCBpbiANCj4gdGhhdCBjYXNl
LCB3aWxsIGRlY2lkZSB3aGV0aGVyIHRoZSByZXF1ZXN0cyBmcm9tIEhUVFAgY2xpZW50IGFyZSB0
byANCj4gYmUgbWFkZSBDb0FQIHJlcXVlc3RzIHdpdGggTm8tUmVzcG9uc2Ugb3Igbm90LiANCj4g
DQo+IEJ1dCwgdGhlcmUgaXMgb25lIHBvaW50LiBUaGUgSFRUUCBjbGllbnQgbmVlZHMgYSByZXNw
b25zZSBhcyBwZXIgdGhlDQo+IEhUVFAgcHJvdG9jb2wgcmVxdWlyZW1lbnRzLiBTbywgd2hhdCBy
ZXNwb25zZSBzaG91bGQgcHJveHkgcmV0dXJuPyANCj4gTG9va2luZyBhdCBUYWJsZSAyIG9mIHRo
ZSBodHRwIG1hcHBpbmcgZHJhZnQgd2Ugc2VlIHRoYXQgQ29BUCdzIDIuMDQNCj4gKENoYW5nZWQp
IGlzIG1hcHBlZCB0byBlaXRoZXIgMjAwIChPSykgb3IgMjA0IChObyBDb250ZW50KSBmb3IgdGhl
IA0KPiBIVFRQLiBDYW4gd2Ugc3VnZ2VzdCB0aGF0IGluIGNhc2VzIGFzIGRlc2NyaWJlZCBhYm92
ZSB0aGUgcHJveHkgDQo+IFNIT1VMRCByZXNwb25kIHdpdGggdGhlIHN0YXR1cyBjb2RlOiAyMDQg
IE5vIENvbnRlbnQgPyBUaGlzIHdheSB0aGUgDQo+IGNsaWVudCBrbm93cyB0aGF0IE5vLVJlc3Bv
bnNlIGlzIGVuYWJsZWQgYXQgdGhlIENvQVAgc2lkZSBmb3IgdGhlIA0KPiBwYXJ0aWN1bGFyIFBV
VHMuIA0KPiANCj4gRG9lcyBpdCBtYWtlIHNlbnNlPyANCj4gDQo+IA0KPiBSZWdhcmRzDQo+IEFi
aGlqYW4gQmhhdHRhY2hhcnl5YQ0KPiBBc3NvY2lhdGUgQ29uc3VsdGFudA0KPiBTY2llbnRpc3Qs
IElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYQ0KPiBUYXRhIENvbnN1bHRhbmN5IFNlcnZp
Y2VzDQo+IE1haWx0bzogYWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20NCj4gV2Vic2l0ZTog
aHR0cDovL3d3dy50Y3MuY29tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+IEV4cGVyaWVuY2UgY2VydGFpbnR5LiAgICAgICAgSVQgU2VydmljZXMNCj4g
ICAgICAgICAgICAgICAgICAgICAgICBCdXNpbmVzcyBTb2x1dGlvbnMNCj4gICAgICAgICAgICAg
ICAgICAgICAgICBDb25zdWx0aW5nDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+IA0KPiANCj4gIndlaWdlbmd5dSIgPHdlaWdlbmd5dUBidXB0LmVkdS5j
bj4gd3JvdGUgb24gMDkvMjQvMjAxNSAwMTo0MDo1MCBQTToNCj4gDQo+ID4gRnJvbTogIndlaWdl
bmd5dSIgPHdlaWdlbmd5dUBidXB0LmVkdS5jbj4gDQo+ID4gVG86ICJSYWhtYW4sIEFrYmFyIiA8
QWtiYXIuUmFobWFuQEludGVyRGlnaXRhbC5jb20+LCAiQWJoaWphbiANCj4gPiBCaGF0dGFjaGFy
eXlhIiA8YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+LCAiQ2Fyc3RlbiBCb3JtYW5uIiAN
Cj4gPiA8Y2Fib0B0emkub3JnPiANCj4gPiBDYzogPGNvcmVAaWV0Zi5vcmc+LCAiY29yZSIgPGNv
cmUtYm91bmNlc0BpZXRmLm9yZz4gDQo+ID4gRGF0ZTogMDkvMjQvMjAxNSAwMTo1MCBQTSANCj4g
PiBTdWJqZWN0OiBSZTogW2NvcmVdIFdHIGxhc3QtY2FsbCAoV0dMQykgb2YgDQpkcmFmdC1pZXRm
LWNvcmUtaHR0cC1tYXBwaW5nLTA3IA0KPiA+IA0KPiA+IEhp77yMIA0KPiA+IA0KPiA+IFdoZW4g
YSBodHRwIGNsaWVudCBhY2Nlc3NlcyBhIENvQVAgc2VydmVyLCANCj4gPiBob3cgZG9lcyB0aGUg
Q29BUCBjbGllbnQgb2YgSEMgcHJveHkgY3JlYXRlIGEgTk9OLXJlcG9zbnNlIG9wdGlvbiANCj4g
PiBzaW5jZSB0aGVyZSBpcyBub3QgaW4gSFRUUC4gDQo+ID4gT3IgaXQgaXMgdXNlbGVzcyBmb3Ig
SEMgcHJveHksIG9yIG5vdD8gDQo+ID4gDQo+ID4gUmVnYXJkcywgDQo+ID4gDQo+ID4gR2VuZ3l1
IFdFSQ0KPiA+IE5ldHdvcmsgVGVjaG5vbG9neSBDZW50ZXINCj4gPiBTY2hvb2wgb2YgQ29tcHV0
ZXIgDQo+ID4gQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlv
bnMgDQo+ID4gDQo+ID4gRnJvbTogUmFobWFuLCBBa2JhciANCj4gPiBTZW50OiBUaHVyc2RheSwg
U2VwdGVtYmVyIDI0LCAyMDE1IDI6MDAgQU0gDQo+ID4gVG86IEFiaGlqYW4gQmhhdHRhY2hhcnl5
YSA7IENhcnN0ZW4gQm9ybWFubiANCj4gPiBDYzogbWFpbHRvOmNvcmVAaWV0Zi5vcmcgOyBjb3Jl
IA0KPiA+IFN1YmplY3Q6IFJlOiBbY29yZV0gV0cgbGFzdC1jYWxsIChXR0xDKSBvZiANCmRyYWZ0
LWlldGYtY29yZS1odHRwLW1hcHBpbmctMDcgDQo+ID4gDQo+ID4gSGkgQWJoaWphbiwgDQo+ID4g
DQo+ID4gDQo+ID4gVGhhbmtzIGZvciB5b3VyIHN1cHBvcnQgb24gdGhlIGRyYWZ0ISANCj4gPiAN
Cj4gPiBXaXRoIHJlZ2FyZHMgdG8geW91ciBxdWVzdGlvbjogDQo+ID4gDQo+ID4gPiBHaXZlbiB0
aGF0IE5vLVJlc3BvbnNlIG5vdyBoYXMgYSBudW1iZXIgKDI4NCkgZnJvbSBJQU5BIGluIHRoZSAN
Cj4gPiBDb1JFIG9wdGlvbiByZWdpc3RyeSAoaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50
cy9jb3JlLQ0KPiA+IHBhcmFtZXRlcnMvY29yZS1wYXJhbWV0ZXJzLnhodG1sI29wdGlvbi1udW1i
ZXJzKSBwcm9iYWJseSBpdCB3aWxsIGJlDQo+ID4gYSBnb29kIGlkZWEgdG8ga2VlcCBhIHNlY3Rp
b24gdG8gZGlzY3VzcyBob3cgdG8gaGFuZGxlIHRoaXMgb3B0aW9uIA0KPiA+IHNpbmNlIHRoaXMg
aXMgbm90IHRoZXJlIGluIEhUVFAuIFNvbWV3aGVyZSBpbiBTZWN0aW9uIDggc2hvdWxkIGJlIGEg
DQo+ID4gZ29vZCBwbGFjZSBmb3Igc3VjaCBkaXNjdXNzaW9uLiANCj4gDQo+ID4gDQo+ID4gWWVz
LCBJIGFncmVlIHRoaXMgaXMgYSBnb29kIHRvcGljIHRvIGFkZCB0byB0aGUgZHJhZnQuICBIb3cg
YWJvdXQgDQo+ID4gc29tZXRoaW5nIGJhc2VkIG9uIHRoZSBmb2xsb3dpbmcgdGV4dDogDQo+ID4g
DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQo+ID4gOC44IENvQVAgTm8g
UmVzcG9uc2UgDQo+ID4gDQo+ID4gQ29BUCBzdXBwb3J0cyBzZW5kaW5nIGEgUmVxdWVzdCBpbmRp
Y2F0aW5nIHRoYXQg4oCcTm8gUmVzcG9uc2XigJ0gaXMgDQo+ID4gcmVxdWlyZWQgd2hlbiB0aGUg
Q29BUCBoZWFkZXIgb3B0aW9uIG51bWJlciBpcyBzZXQgdG8gMjg0LiAgQW4gSEMgDQo+ID4gUHJv
eHkgbWF5IHRyYW5zbGF0ZSBhbiBpbmNvbWluZyBIVFRQIFJlcXVlc3QgdG8gYSBjb3JyZXNwb25k
aW5nIENvQVANCj4gPiBSZXF1ZXN0IGluZGljYXRpbmcgdGhhdCBubyByZXNwb25zZSBpcyByZXF1
aXJlZCBmb2xsb3dpbmcgdGhlIGd1aWRhbmNlIA0KaW4gDQo+ID4gKFJlZjogaHR0cDovL3d3dy5p
YW5hLm9yZy9hc3NpZ25tZW50cy9jb3JlLXBhcmFtZXRlcnMvY29yZS0NCj4gPiBwYXJhbWV0ZXJz
LnhodG1sI29wdGlvbi1udW1iZXJzKS4gDQo+ID4gDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tIA0KPiA+IA0KPiA+IA0KPiA+IEFueSBmZWVkYmFjaz8gDQo+ID4gDQo+ID4g
DQo+ID4gL0FrYmFyIA0KPiA+IA0KPiA+IA0KPiA+IEZyb206IGNvcmUgW21haWx0bzpjb3JlLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBYmhpamFuIA0KQmhhdHRhY2hhcnl5YQ0KPiA+
IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTcsIDIwMTUgNTozNCBBTQ0KPiA+IFRvOiBDYXJz
dGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4NCj4gPiBDYzogY29yZSA8Y29yZS1ib3VuY2VzQGll
dGYub3JnPjsgY29yZUBpZXRmLm9yZyBXRyA8Y29yZUBpZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBS
ZTogW2NvcmVdIFdHIGxhc3QtY2FsbCAoV0dMQykgb2YgDQpkcmFmdC1pZXRmLWNvcmUtaHR0cC1t
YXBwaW5nLTA3IA0KPiA+IA0KPiA+IERlYXIgYWxsLCANCj4gPiBJIHRoaW5rIHRoaXMgZHJhZnQg
aXMgaW5kZWVkIGFuIGFwcHJlY2lhYmxlIGVmZm9ydCBhcyBpdCB3aWxsIGVhc2UgDQo+ID4gb3V0
IG1hbnkgaW1wbGVtZW50YXRpb24gZGVjaXNpb25zIGZvciB0aGUgZGV2ZWxvcGVycyBhbmQgc2hv
dWxkIGJlIA0KPiA+IHZlcnkgdXNlZnVsIGFzIGFuIFJGQy4gDQo+ID4gDQo+ID4gRGVhciBhdXRo
b3JzLCANCj4gPiBJIGhhdmUgb25lIHNtYWxsIGNvbW1lbnQgOiANCj4gPiBHaXZlbiB0aGF0IE5v
LVJlc3BvbnNlIG5vdyBoYXMgYSBudW1iZXIgKDI4NCkgZnJvbSBJQU5BIGluIHRoZSBDb1JFIA0K
PiA+IG9wdGlvbiByZWdpc3RyeSAoaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9jb3Jl
LXBhcmFtZXRlcnMvDQo+ID4gY29yZS1wYXJhbWV0ZXJzLnhodG1sI29wdGlvbi1udW1iZXJzKSBw
cm9iYWJseSBpdCB3aWxsIGJlIGEgZ29vZCANCj4gPiBpZGVhIHRvIGtlZXAgYSBzZWN0aW9uIHRv
IGRpc2N1c3MgaG93IHRvIGhhbmRsZSB0aGlzIG9wdGlvbiBzaW5jZSANCj4gPiB0aGlzIGlzIG5v
dCB0aGVyZSBpbiBIVFRQLiBTb21ld2hlcmUgaW4gU2VjdGlvbiA4IHNob3VsZCBiZSBhIGdvb2Qg
DQo+ID4gcGxhY2UgZm9yIHN1Y2ggZGlzY3Vzc2lvbi4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4g
UmVnYXJkcw0KPiA+IEFiaGlqYW4gQmhhdHRhY2hhcnl5YQ0KPiA+IEFzc29jaWF0ZSBDb25zdWx0
YW50DQo+ID4gU2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWENCj4gPiBU
YXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzDQo+ID4gTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5
eWFAdGNzLmNvbQ0KPiA+IFdlYnNpdGU6IGh0dHA6Ly93d3cudGNzLmNvbQ0KPiA+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRXhwZXJpZW5jZSBjZXJ0
YWludHkuICAgICAgICBJVCBTZXJ2aWNlcw0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgQnVz
aW5lc3MgU29sdXRpb25zDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICBDb25zdWx0aW5nDQo+
ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiANCj4g
PiANCj4gPiANCj4gPiANCj4gPiBGcm9tOiAgICAgICAgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6
aS5vcmc+IA0KPiA+IFRvOiAgICAgICAgIm1haWx0bzpjb3JlQGlldGYub3JnJTIwV0ciIDxjb3Jl
QGlldGYub3JnPiANCj4gPiBEYXRlOiAgICAgICAgMDkvMTUvMjAxNSAwODo1MSBQTSANCj4gPiBT
dWJqZWN0OiAgICAgICAgW2NvcmVdIFdHIGxhc3QtY2FsbCAoV0dMQykgb2YgZHJhZnQtaWV0Zi1j
b3JlLQ0KPiBodHRwLW1hcHBpbmctMDcNCj4gPiBTZW50IGJ5OiAgICAgICAgImNvcmUiIDxjb3Jl
LWJvdW5jZXNAaWV0Zi5vcmc+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IEluIFByYWd1
ZSwgd2Ugc2FpZCB3ZSB3ZXJlIGdvaW5nIHRvIFdHTEMgdGhlIEhUVFAgbWFwcGluZyBkcmFmdCBh
ZnRlcg0KPiA+IGNsb3NlIG9mIHRoZSB2YWNhdGlvbiBwZXJpb2QsIHdoaWNoIGlzIG5vdyBiZWhp
bmQgdXMuICBBbGwgb3V0c3RhbmRpbmcNCj4gPiB0aWNrZXRzIGFyZSBjbG9zZWQsIGFuZCB0aGVy
ZSB3YXMgZW5vdWdoIHRpbWUgdG8gcmV2aWV3IHRoZSBjdXJyZW50DQo+ID4gZHJhZnQuICBUaHJl
ZSBwZW9wbGUgcmFpc2VkIHRoZWlyIGhhbmRzIHdoZW4gd2UgYXNrZWQgd2hvIHdvdWxkIHN1Ym1p
dA0KPiA+IHJldmlld3MgKE1pY2hhZWwgSy4sIEtsYXVzLCBEYXJzaGFrKSwgYnV0IG9mIGNvdXJz
ZSBhZGRpdGlvbmFsIHJldmlld3MNCj4gPiBiZXlvbmQgdGhhdCBhcmUgYWxzbyB2ZXJ5IHVzZWZ1
bC4NCj4gPiANCj4gPiBTbyB0aGlzIHN0YXJ0cyBhIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZv
cg0KPiA+IGRyYWZ0LWlldGYtY29yZS1odHRwLW1hcHBpbmcgZm9yIHN1Ym1pc3Npb24gYXMgYW4g
aW5mb3JtYXRpb25hbCBSRkMsDQo+ID4gZW5kaW5nIG9uDQo+ID4gDQo+ID4gMjQ6MDAgUERUIG9u
IFR1ZXNkYXksIFNlcHRlbWJlciAyOSwgMjAxNS4NCj4gPiANCj4gPiBUaGUgZHJhZnQgaXMgbG9j
YXRlZCBhdDoNCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3Jl
LWh0dHAtbWFwcGluZy0wNw0KPiA+IA0KPiA+IFBsZWFzZSBzdGFydCBhIG5ldyBlbWFpbCB0aHJl
YWQgZm9yIGVhY2ggbWFqb3IgaXNzdWUgdGhhdCB3aWxsIG5lZWQNCj4gPiBkaXNjdXNzaW9uIGFu
ZCBtYWtlIHN1cmUgdGhlIHN1YmplY3QgbGluZSBpbmNsdWRlcyB0aGUgZHJhZnQgbmFtZSBhbmQN
Cj4gPiBzb21lIHNvcnQgb2YgbmFtZSBmb3IgdGhlIGlzc3VlLiBGb3IgbWlub3IgaXNzdWVzIHN1
Y2ggYXMgdHlwb3MgYW5kDQo+ID4gdGhpbmdzIHRoYXQgYXJlIG5vdCBsaWtlbHkgdG8gbGVhZCB0
byBtdWNoIGRpc2N1c3Npb24sIGl0IGlzIHByb2JhYmx5DQo+ID4gZWFzaWVyIHRvIGdyb3VwIHRo
ZW0gYWxsIGluIHRvIG9uZSBlbWFpbCBidXQgYWdhaW4sIHBsZWFzZSBtYWtlIHN1cmUNCj4gPiB0
aGUgc3ViamVjdCBsaW5lIGluY2x1ZGVzIHRoZSBkcmFmdCBuYW1lLiBJZiB5b3UgcmVhZCB0aGUg
ZHJhZnQgYW5kDQo+ID4gdGhpbmsgaXQgbG9va3MgZmluZSwgcGxlYXNlIHNlbmQgYSBvbmUgbGlu
ZSBlbWFpbCB0byB0aGUgbGlzdCBvciB0bw0KPiA+IHRoZSBjaGFpcnMgbGV0dGluZyB1cyBrbm93
IHRoYXQgc28gd2UgY2FuIGdldCBhIGZlZWwgb2YgaG93IGJyb2FkIHRoZQ0KPiA+IHJldmlldyBo
YXMgYmVlbi4NCj4gPiANCj4gPiBJbiB0aGUgdW5saWtlbHkgZXZlbnQgdGhhdCB5b3UgYXJlIGF3
YXJlIG9mIGFueSBwYXRlbnQgY2xhaW1zIHRoYXQNCj4gPiBtaWdodCBhcHBseSB0byBzeXN0ZW1z
IHRoYXQgaW1wbGVtZW50IHRoZSBzdWdnZXN0aW9ucyBpbiB0aGlzIGRyYWZ0LA0KPiA+IHBsZWFz
ZSByZXZpZXcgQkNQIDc4IGFuZCBCQ1AgNzkgYW5kIG1ha2UgYW55IGFwcHJvcHJpYXRlIElQUg0K
PiA+IGRlY2xhcmF0aW9uLiBJZiB5b3UgYXJlIG5vdCBzdXJlIHdoZXRoZXIgeW91IG5lZWQgdG8g
bWFrZSBhDQo+ID4gZGVjbGFyYXRpb24gb3Igbm90LCBwbGVhc2UgdGFsayB0byB0aGUgY2hhaXJz
IGFuZCB3ZSB3aWxsIGhlbHAgZ2V0IHlvdQ0KPiA+IGluIHRvdWNoIHdpdGggcGVvcGxlIHRoYXQg
Y2FuIHByb3ZpZGUgYXBwcm9wcmlhdGUgYWR2aWNlLg0KPiA+IA0KPiA+IEdyw7zDn2UsIENhcnN0
ZW4NCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiA+IGNvcmUgbWFpbGluZyBsaXN0DQo+ID4gY29yZUBpZXRmLm9yZw0KPiA+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZSANCj4gPiA9PT09PS0tLS0tPT09
PT0tLS0tLT09PT09DQo+ID4gTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo
aXMgZS1tYWlsDQo+ID4gbWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgbWF5IGNvbnRh
aW4gDQo+ID4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlvdSBh
cmUgDQo+ID4gbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0aW9uLCB1
c2UsIA0KPiA+IHJldmlldywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBjb3B5aW5nIG9mIHRo
ZSANCj4gPiBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSANCj4g
PiBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIA0K
PiA+IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgDQo+ID4g
cGxlYXNlIG5vdGlmeSB1cyBieSByZXBseSBlLW1haWwgb3IgdGVsZXBob25lIGFuZCANCj4gPiBp
bW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdlIA0KPiA+IGFuZCBh
bnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdSANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGNvcmUgbWFpbGluZyBsaXN0DQo+ID4gY29yZUBp
ZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZSAN
Cg==
--=_alternative 001CF37B65257ECE_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFrYmFyLDwvZm9udD4NCjxicj4NCjxi
cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQWxzbywgQWJoaWphbiwgaXQgbWF5IGJlIGdvb2QgZm9y
IHlvdSB0byBwdXQNCnRoZSBhcHBsaWNhdGlvbiA8YnI+DQomZ3Q7IHNjZW5hcmlvIHlvdSBvdXRs
aW5lZCBiZWxvdyBpbiB5b3VyIGRyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLTxicj4NCiZndDsg
b3B0aW9uIGFzIHRoYXQgc2hvdWxkIGJlIGRvY3VtZW50IHRoYXQgY29udGFpbnMgYWxsIHN1Y2gg
Z3VpZGFuY2UNCmluZm9ybWF0aW9uLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+
Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IERvIHlvdSBhZ3JlZT88L2Zv
bnQ+PC90dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TGV0IHVz
IGNvbGxlY3QgYWxsIHRoZSBjb21tZW50cyB3aXRoaW4NCnRoZSBkZWFkbGluZSAoMjAxNS0xMC0x
Mikgc2V0IGJ5IENhcnN0ZW4gdGhlbiB3ZSBtYXkgZGVjaWRlIHRoZSBtb2RpZmljYXRpb25zDQpj
b2xsZWN0aXZlbHkuIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z
ZXJpZiI+UmVnYXJkczxicj4NCkFiaGlqYW4gQmhhdHRhY2hhcnl5YTxicj4NCkFzc29jaWF0ZSBD
b25zdWx0YW50PGJyPg0KU2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWE8
YnI+DQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzPGJyPg0KTWFpbHRvOiBhYmhpamFuLmJoYXR0
YWNoYXJ5eWFAdGNzLmNvbTxicj4NCldlYnNpdGU6IDwvZm9udD48YSBocmVmPWh0dHA6Ly93d3cu
dGNzLmNvbS8+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly93d3cudGNzLmNv
bTwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRXhwZXJpZW5jZSBjZXJ0
YWludHkuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lUIFNlcnZpY2VzPGJyPg0KICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4NCiAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDtDb25zdWx0aW5nPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNp
emU9Mj4mcXVvdDtSYWhtYW4sIEFrYmFyJnF1b3Q7ICZsdDtBa2Jhci5SYWhtYW5ASW50ZXJEaWdp
dGFsLmNvbSZndDsNCndyb3RlIG9uIDA5LzI0LzIwMTUgMTA6Mjk6NTUgUE06PGJyPg0KPGJyPg0K
Jmd0OyBGcm9tOiAmcXVvdDtSYWhtYW4sIEFrYmFyJnF1b3Q7ICZsdDtBa2Jhci5SYWhtYW5ASW50
ZXJEaWdpdGFsLmNvbSZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg
VG86IEFiaGlqYW4gQmhhdHRhY2hhcnl5YSAmbHQ7YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5j
b20mZ3Q7LA0Kd2VpZ2VuZ3l1PGJyPg0KJmd0OyAmbHQ7d2VpZ2VuZ3l1QGJ1cHQuZWR1LmNuJmd0
OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBDYzogQ2Fyc3RlbiBCb3Jt
YW5uICZsdDtjYWJvQHR6aS5vcmcmZ3Q7LCAmcXVvdDtjb3JlQGlldGYub3JnJnF1b3Q7DQombHQ7
Y29yZUBpZXRmLm9yZyZndDssPGJyPg0KJmd0OyBjb3JlICZsdDtjb3JlLWJvdW5jZXNAaWV0Zi5v
cmcmZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IERhdGU6IDA5LzI0
LzIwMTUgMTA6MzAgUE08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU3Vi
amVjdDogUkU6IFtjb3JlXSBXRyBsYXN0LWNhbGwgKFdHTEMpIG9mIGRyYWZ0LWlldGYtY29yZS1o
dHRwLW1hcHBpbmctMDc8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJy
Pg0KJmd0OyBIaSBBYmhpamFuLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0
OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IE9rYXksIHBsZWFzZSByZXZpZXcg
dGhlIHVwZGF0ZWQgcHJvcG9zZWQgdGV4dA0KZm9yIGRyYWZ0LWlldGYtY29yZS08YnI+DQomZ3Q7
IGh0dHAtbWFwcGluZyBiYXNlZCBvbiB0aGUgZmVlZGJhY2sgZnJvbSBDYXJzdGVuLCBXZWlnZW5n
eXUgYW5kIHlvdS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0
Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAoTmV3KSBTZWN0aW9u
IDgueCDigJxVc2Ugb2YgQ29BUCBObyBSZXNwb25zZeKAnTo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+
PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IENvQVAgc3VwcG9ydHMgc2VuZGluZyBhIFJlcXVlc3QgaW5kaWNhdGluZyB0aGF0DQri
gJxObyBSZXNwb25zZeKAnSBpcyA8YnI+DQomZ3Q7IHJlcXVpcmVkIHdoZW4gdGhlIENvQVAgaGVh
ZGVyIG9wdGlvbiBudW1iZXIgaXMgc2V0IHRvIDI4NCBbc2VlIDxicj4NCiZndDsgUmVmLTFdLiAm
bmJzcDtBbiBIQyBQcm94eSBtYXkgdHJhbnNsYXRlIGFuIGluY29taW5nIEhUVFAgUmVxdWVzdCB0
bw0KYSA8YnI+DQomZ3Q7IGNvcnJlc3BvbmRpbmcgQ29BUCBSZXF1ZXN0IGluZGljYXRpbmcgdGhh
dCBObyBSZXNwb25zZSBpcyByZXF1aXJlZA0KPGJyPg0KJmd0OyBiYXNlZCBvbiBzb21lIGFwcGxp
Y2F0aW9uIGtub3dsZWRnZSAoc2VlIFtSZWYtMl0gZm9yIGZ1cnRoZXIgPGJyPg0KJmd0OyBndWlk
YW5jZSkuICZuYnNwO0luIHRoaXMgY2FzZSwgaXQgaXMgcmVjb21tZW5kIHRoYXQgdGhlIEhDIFBy
b3h5IFNIT1VMRA0KPGJyPg0KJmd0OyBzZW5kIGFuIEhUVFAgUmVzcG9uc2Ugd2l0aCBzdGF0dXMg
Y29kZSAyMDQgKE5vIENvbnRlbnQpLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+
Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgW1JlZi0x
XSAtIDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMv
Y29yZS1wYXJhbWV0ZXJzL2NvcmUtIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly93d3cuaWFuYS5v
cmcvYXNzaWdubWVudHMvY29yZS1wYXJhbWV0ZXJzL2NvcmUtPC9mb250PjwvdHQ+PC9hPjx0dD48
Zm9udCBzaXplPTI+PGJyPg0KJmd0OyBwYXJhbWV0ZXJzLnhodG1sI29wdGlvbi1udW1iZXJzPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0K
PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBbUmVmLTJdIC0gPC9mb250PjwvdHQ+PGEgaHJlZj0i
aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLW9w
dGlvbi0xMSI+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtdGNzLWNvYXAtbm8tcmVzcG9uc2Utb3B0aW9uLTExPC9mb250PjwvdHQ+PC9hPg0KPGJyPjx0
dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0yPiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250PjwvdHQ+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u
dCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn
dDsgQWxzbywgQWJoaWphbiwgaXQgbWF5IGJlIGdvb2QgZm9yIHlvdSB0byBwdXQNCnRoZSBhcHBs
aWNhdGlvbiA8YnI+DQomZ3Q7IHNjZW5hcmlvIHlvdSBvdXRsaW5lZCBiZWxvdyBpbiB5b3VyIGRy
YWZ0LXRjcy1jb2FwLW5vLXJlc3BvbnNlLTxicj4NCiZndDsgb3B0aW9uIGFzIHRoYXQgc2hvdWxk
IGJlIGRvY3VtZW50IHRoYXQgY29udGFpbnMgYWxsIHN1Y2ggZ3VpZGFuY2UNCmluZm9ybWF0aW9u
LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90
dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0
Pjxmb250IHNpemU9Mj4mZ3Q7IERvIHlvdSBhZ3JlZT88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m
Z3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAvQWtiYXI8
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+
DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48
Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y
PiZndDsgRnJvbTogQWJoaWphbiBCaGF0dGFjaGFyeXlhIFs8L2ZvbnQ+PC90dD48YSBocmVmPW1h
aWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbT48dHQ+PGZvbnQgc2l6ZT0yPm1haWx0
bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQg
c2l6ZT0yPl0NCjxicj4NCiZndDsgU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyNCwgMjAxNSA4
OjUzIEFNPGJyPg0KJmd0OyBUbzogd2VpZ2VuZ3l1ICZsdDt3ZWlnZW5neXVAYnVwdC5lZHUuY24m
Z3Q7OyBSYWhtYW4sIEFrYmFyIDxicj4NCiZndDsgJmx0O0FrYmFyLlJhaG1hbkBJbnRlckRpZ2l0
YWwuY29tJmd0Ozxicj4NCiZndDsgQ2M6IENhcnN0ZW4gQm9ybWFubiAmbHQ7Y2Fib0B0emkub3Jn
Jmd0OzsgY29yZUBpZXRmLm9yZzsgY29yZSAmbHQ7Y29yZS08YnI+DQomZ3Q7IGJvdW5jZXNAaWV0
Zi5vcmcmZ3Q7PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW2NvcmVdIFdHIGxhc3QtY2FsbCAoV0dM
Qykgb2YgZHJhZnQtaWV0Zi1jb3JlLWh0dHAtbWFwcGluZy0wNzwvZm9udD48L3R0Pg0KPGJyPjx0
dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0yPiZndDsgSGkgQWtiYXIsIDxicj4NCiZndDsgVGhhbmtzLiA8YnI+DQomZ3Q7IDxicj4NCiZn
dDsgVGFraW5nIGNsdWUgZnJvbSBHZW5neXUncyByZXNwb25zZSBJIHdvdWxkIGxpa2UgdG8gc2hh
cmUgdGhlIGZvbGxvd2luZw0KaW5wdXQ6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBkZWNpc2lv
biB0byBjb252ZXJ0IGFuIEhUVFAgcmVxdWVzdCB0byBhIENvQVAgcmVxdWVzdCB3aXRoICZxdW90
O05vDQo8YnI+DQomZ3Q7IFJlc3BvbnNlJnF1b3Q7IHNob3VsZCBiZSBwdXJlbHkgYmFzZWQgb24g
dGhlIGFwcGxpY2F0aW9uIGNvbnRleHQuDQo8YnI+DQomZ3Q7IExldCB1cyBjb25zaWRlciBhIHNj
ZW5hcmlvLiA8YnI+DQomZ3Q7IFdlIHdhbnQgdG8gb3BlcmF0ZSB0aGUgbGlnaHRzIG9mIGEgYnVp
bGRpbmcgZnJvbSBhIHJlbW90ZSBjb250cm9sLTxicj4NCiZndDsgY2VudGVyIChjb250cm9sbGlu
ZyBjb21tYW5kcyBtYXkgbm90IGJlIGVzc2VudGlhbGx5IG11bHRpY2FzdCkuIExldA0KPGJyPg0K
Jmd0OyB1cyBhc3N1bWUgdGhhdCB0aGUgY29udHJvbC1jZW50ZXIgaGFzIGxlZ2FjeSBIVFRQIGlu
ZnJhc3RydWN0dXJlLg0KPGJyPg0KJmd0OyBCdXQgdGhlIGxpZ2h0cyBhcmUgQ29BUCBlbmFibGVk
LiBTbyB0aGUgcmVxdWVzdHMgZnJvbSB0aGUgY29udHJvbC08YnI+DQomZ3Q7IGNlbnRlciBnb2Vz
IHRocm91Z2ggYW4gSEMgcHJveHkuIFRoZSBhcHBsaWNhdGlvbiByZXF1aXJlbWVudCwgaW4gPGJy
Pg0KJmd0OyB0aGF0IGNhc2UsIHdpbGwgZGVjaWRlIHdoZXRoZXIgdGhlIHJlcXVlc3RzIGZyb20g
SFRUUCBjbGllbnQgYXJlIHRvDQo8YnI+DQomZ3Q7IGJlIG1hZGUgQ29BUCByZXF1ZXN0cyB3aXRo
IE5vLVJlc3BvbnNlIG9yIG5vdC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJ1dCwgdGhlcmUgaXMg
b25lIHBvaW50LiBUaGUgSFRUUCBjbGllbnQgbmVlZHMgYSByZXNwb25zZSBhcyBwZXIgdGhlPGJy
Pg0KJmd0OyBIVFRQIHByb3RvY29sIHJlcXVpcmVtZW50cy4gU28sIHdoYXQgcmVzcG9uc2Ugc2hv
dWxkIHByb3h5IHJldHVybj8NCjxicj4NCiZndDsgTG9va2luZyBhdCBUYWJsZSAyIG9mIHRoZSBo
dHRwIG1hcHBpbmcgZHJhZnQgd2Ugc2VlIHRoYXQgQ29BUCdzIDIuMDQ8YnI+DQomZ3Q7IChDaGFu
Z2VkKSBpcyBtYXBwZWQgdG8gZWl0aGVyIDIwMCAoT0spIG9yIDIwNCAoTm8gQ29udGVudCkgZm9y
IHRoZQ0KPGJyPg0KJmd0OyBIVFRQLiBDYW4gd2Ugc3VnZ2VzdCB0aGF0IGluIGNhc2VzIGFzIGRl
c2NyaWJlZCBhYm92ZSB0aGUgcHJveHkgPGJyPg0KJmd0OyBTSE9VTEQgcmVzcG9uZCB3aXRoIHRo
ZSBzdGF0dXMgY29kZTogMjA0ICZuYnNwO05vIENvbnRlbnQgPyBUaGlzIHdheQ0KdGhlIDxicj4N
CiZndDsgY2xpZW50IGtub3dzIHRoYXQgTm8tUmVzcG9uc2UgaXMgZW5hYmxlZCBhdCB0aGUgQ29B
UCBzaWRlIGZvciB0aGUNCjxicj4NCiZndDsgcGFydGljdWxhciBQVVRzLiA8YnI+DQomZ3Q7IDxi
cj4NCiZndDsgRG9lcyBpdCBtYWtlIHNlbnNlPyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K
Jmd0OyBSZWdhcmRzPGJyPg0KJmd0OyBBYmhpamFuIEJoYXR0YWNoYXJ5eWE8YnI+DQomZ3Q7IEFz
c29jaWF0ZSBDb25zdWx0YW50PGJyPg0KJmd0OyBTY2llbnRpc3QsIElubm92YXRpb24gTGFiLCBL
b2xrYXRhLCBJbmRpYTxicj4NCiZndDsgVGF0YSBDb25zdWx0YW5jeSBTZXJ2aWNlczxicj4NCiZn
dDsgTWFpbHRvOiBhYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbTxicj4NCiZndDsgV2Vic2l0
ZTogPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwOi8vd3d3LnRjcy5jb20vPjx0dD48Zm9udCBzaXpl
PTI+aHR0cDovL3d3dy50Y3MuY29tPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJy
Pg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N
CiZndDsgRXhwZXJpZW5jZSBjZXJ0YWludHkuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lU
IFNlcnZpY2VzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDtCdXNpbmVzcyBT
b2x1dGlvbnM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO0NvbnN1bHRpbmc8
YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJnF1b3Q7d2VpZ2VuZ3l1JnF1b3Q7ICZsdDt3
ZWlnZW5neXVAYnVwdC5lZHUuY24mZ3Q7IHdyb3RlIG9uIDA5LzI0LzIwMTUNCjAxOjQwOjUwIFBN
Ojxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEZyb206ICZxdW90O3dlaWdlbmd5dSZxdW90OyAm
bHQ7d2VpZ2VuZ3l1QGJ1cHQuZWR1LmNuJmd0OyA8YnI+DQomZ3Q7ICZndDsgVG86ICZxdW90O1Jh
aG1hbiwgQWtiYXImcXVvdDsgJmx0O0FrYmFyLlJhaG1hbkBJbnRlckRpZ2l0YWwuY29tJmd0OywN
CiZxdW90O0FiaGlqYW4gPGJyPg0KJmd0OyAmZ3Q7IEJoYXR0YWNoYXJ5eWEmcXVvdDsgJmx0O2Fi
aGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tJmd0OywgJnF1b3Q7Q2Fyc3Rlbg0KQm9ybWFubiZx
dW90OyA8YnI+DQomZ3Q7ICZndDsgJmx0O2NhYm9AdHppLm9yZyZndDsgPGJyPg0KJmd0OyAmZ3Q7
IENjOiAmbHQ7Y29yZUBpZXRmLm9yZyZndDssICZxdW90O2NvcmUmcXVvdDsgJmx0O2NvcmUtYm91
bmNlc0BpZXRmLm9yZyZndDsNCjxicj4NCiZndDsgJmd0OyBEYXRlOiAwOS8yNC8yMDE1IDAxOjUw
IFBNIDxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBSZTogW2NvcmVdIFdHIGxhc3QtY2FsbCAoV0dM
Qykgb2YgZHJhZnQtaWV0Zi1jb3JlLWh0dHAtbWFwcGluZy0wNw0KPGJyPg0KJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyBIae+8jCA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0
OyBXaGVuIGEgaHR0cCBjbGllbnQgYWNjZXNzZXMgYSBDb0FQIHNlcnZlciwgPGJyPg0KJmd0OyAm
Z3Q7IGhvdyBkb2VzIHRoZSBDb0FQIGNsaWVudCBvZiBIQyBwcm94eSBjcmVhdGUgYSBOT04tcmVw
b3Nuc2Ugb3B0aW9uDQo8YnI+DQomZ3Q7ICZndDsgc2luY2UgdGhlcmUgaXMgbm90IGluIEhUVFAu
IDxicj4NCiZndDsgJmd0OyBPciBpdCBpcyB1c2VsZXNzIGZvciBIQyBwcm94eSwgb3Igbm90PyA8
YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBSZWdhcmRzLCA8YnI+DQomZ3Q7
ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBHZW5neXUgV0VJPGJyPg0KJmd0OyAmZ3Q7IE5l
dHdvcmsgVGVjaG5vbG9neSBDZW50ZXI8YnI+DQomZ3Q7ICZndDsgU2Nob29sIG9mIENvbXB1dGVy
IDxicj4NCiZndDsgJmd0OyBCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgYW5kIFRlbGVjb21t
dW5pY2F0aW9ucyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBGcm9tOiBS
YWhtYW4sIEFrYmFyIDxicj4NCiZndDsgJmd0OyBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDI0
LCAyMDE1IDI6MDAgQU0gPGJyPg0KJmd0OyAmZ3Q7IFRvOiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEg
OyBDYXJzdGVuIEJvcm1hbm4gPGJyPg0KJmd0OyAmZ3Q7IENjOiA8L2ZvbnQ+PC90dD48YSBocmVm
PW1haWx0bzpjb3JlQGlldGYub3JnPjx0dD48Zm9udCBzaXplPTI+bWFpbHRvOmNvcmVAaWV0Zi5v
cmc8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj4NCjsgY29yZSA8YnI+DQomZ3Q7ICZn
dDsgU3ViamVjdDogUmU6IFtjb3JlXSBXRyBsYXN0LWNhbGwgKFdHTEMpIG9mIGRyYWZ0LWlldGYt
Y29yZS1odHRwLW1hcHBpbmctMDcNCjxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAm
Z3Q7IEhpIEFiaGlqYW4sIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZu
YnNwOyA8YnI+DQomZ3Q7ICZndDsgVGhhbmtzIGZvciB5b3VyIHN1cHBvcnQgb24gdGhlIGRyYWZ0
ISA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBXaXRoIHJlZ2FyZHMgdG8g
eW91ciBxdWVzdGlvbjogPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0
OyBHaXZlbiB0aGF0IE5vLVJlc3BvbnNlIG5vdyBoYXMgYSBudW1iZXIgKDI4NCkgZnJvbSBJQU5B
DQppbiB0aGUgPGJyPg0KJmd0OyAmZ3Q7IENvUkUgb3B0aW9uIHJlZ2lzdHJ5ICg8L2ZvbnQ+PC90
dD48YSBocmVmPSJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2NvcmUtIj48dHQ+PGZv
bnQgc2l6ZT0yPmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvY29yZS08L2ZvbnQ+PC90
dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7ICZndDsgcGFyYW1ldGVycy9jb3JlLXBh
cmFtZXRlcnMueGh0bWwjb3B0aW9uLW51bWJlcnMpIHByb2JhYmx5IGl0DQp3aWxsIGJlPGJyPg0K
Jmd0OyAmZ3Q7IGEgZ29vZCBpZGVhIHRvIGtlZXAgYSBzZWN0aW9uIHRvIGRpc2N1c3MgaG93IHRv
IGhhbmRsZSB0aGlzIG9wdGlvbg0KPGJyPg0KJmd0OyAmZ3Q7IHNpbmNlIHRoaXMgaXMgbm90IHRo
ZXJlIGluIEhUVFAuIFNvbWV3aGVyZSBpbiBTZWN0aW9uIDggc2hvdWxkDQpiZSBhIDxicj4NCiZn
dDsgJmd0OyBnb29kIHBsYWNlIGZvciBzdWNoIGRpc2N1c3Npb24uIDxicj4NCiZndDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgWWVzLCBJIGFncmVlIHRoaXMgaXMgYSBn
b29kIHRvcGljIHRvIGFkZCB0byB0aGUgZHJhZnQuICZuYnNwO0hvdw0KYWJvdXQgPGJyPg0KJmd0
OyAmZ3Q7IHNvbWV0aGluZyBiYXNlZCBvbiB0aGUgZm9sbG93aW5nIHRleHQ6IDxicj4NCiZndDsg
Jmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tIDxicj4NCiZndDsgJmd0OyA4LjggQ29BUCBObyBSZXNwb25zZSA8YnI+DQomZ3Q7ICZndDsg
Jm5ic3A7IDxicj4NCiZndDsgJmd0OyBDb0FQIHN1cHBvcnRzIHNlbmRpbmcgYSBSZXF1ZXN0IGlu
ZGljYXRpbmcgdGhhdCDigJxObyBSZXNwb25zZeKAnQ0KaXMgPGJyPg0KJmd0OyAmZ3Q7IHJlcXVp
cmVkIHdoZW4gdGhlIENvQVAgaGVhZGVyIG9wdGlvbiBudW1iZXIgaXMgc2V0IHRvIDI4NC4gJm5i
c3A7QW4NCkhDIDxicj4NCiZndDsgJmd0OyBQcm94eSBtYXkgdHJhbnNsYXRlIGFuIGluY29taW5n
IEhUVFAgUmVxdWVzdCB0byBhIGNvcnJlc3BvbmRpbmcNCkNvQVA8YnI+DQomZ3Q7ICZndDsgUmVx
dWVzdCBpbmRpY2F0aW5nIHRoYXQgbm8gcmVzcG9uc2UgaXMgcmVxdWlyZWQgZm9sbG93aW5nIHRo
ZQ0KZ3VpZGFuY2UgaW4gPGJyPg0KJmd0OyAmZ3Q7IChSZWY6IDwvZm9udD48L3R0PjxhIGhyZWY9
Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvY29yZS1wYXJhbWV0ZXJzL2NvcmUtIj48
dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvY29yZS1wYXJh
bWV0ZXJzL2NvcmUtPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyAm
Z3Q7IHBhcmFtZXRlcnMueGh0bWwjb3B0aW9uLW51bWJlcnMpLiA8YnI+DQomZ3Q7ICZndDsgJm5i
c3A7IDxicj4NCiZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJy
Pg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0
OyBBbnkgZmVlZGJhY2s/IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZu
YnNwOyA8YnI+DQomZ3Q7ICZndDsgL0FrYmFyIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgRnJvbTogY29yZSBbPC9mb250PjwvdHQ+
PGEgaHJlZj0ibWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZyI+PHR0Pjxmb250IHNpemU9Mj5t
YWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXpl
PTI+XQ0KT24gQmVoYWxmIE9mIEFiaGlqYW4gQmhhdHRhY2hhcnl5YTxicj4NCiZndDsgJmd0OyBT
ZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDE3LCAyMDE1IDU6MzQgQU08YnI+DQomZ3Q7ICZndDsg
VG86IENhcnN0ZW4gQm9ybWFubiAmbHQ7Y2Fib0B0emkub3JnJmd0Ozxicj4NCiZndDsgJmd0OyBD
YzogY29yZSAmbHQ7Y29yZS1ib3VuY2VzQGlldGYub3JnJmd0OzsgY29yZUBpZXRmLm9yZyBXRyAm
bHQ7Y29yZUBpZXRmLm9yZyZndDs8YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtjb3JlXSBX
RyBsYXN0LWNhbGwgKFdHTEMpIG9mIGRyYWZ0LWlldGYtY29yZS1odHRwLW1hcHBpbmctMDcNCjxi
cj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IERlYXIgYWxsLCA8YnI+DQomZ3Q7
ICZndDsgSSB0aGluayB0aGlzIGRyYWZ0IGlzIGluZGVlZCBhbiBhcHByZWNpYWJsZSBlZmZvcnQg
YXMgaXQgd2lsbA0KZWFzZSA8YnI+DQomZ3Q7ICZndDsgb3V0IG1hbnkgaW1wbGVtZW50YXRpb24g
ZGVjaXNpb25zIGZvciB0aGUgZGV2ZWxvcGVycyBhbmQgc2hvdWxkDQpiZSA8YnI+DQomZ3Q7ICZn
dDsgdmVyeSB1c2VmdWwgYXMgYW4gUkZDLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7
IERlYXIgYXV0aG9ycywgPGJyPg0KJmd0OyAmZ3Q7IEkgaGF2ZSBvbmUgc21hbGwgY29tbWVudCA6
IDxicj4NCiZndDsgJmd0OyBHaXZlbiB0aGF0IE5vLVJlc3BvbnNlIG5vdyBoYXMgYSBudW1iZXIg
KDI4NCkgZnJvbSBJQU5BIGluIHRoZQ0KQ29SRSA8YnI+DQomZ3Q7ICZndDsgb3B0aW9uIHJlZ2lz
dHJ5ICg8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRz
L2NvcmUtcGFyYW1ldGVycy8iPjx0dD48Zm9udCBzaXplPTI+aHR0cDovL3d3dy5pYW5hLm9yZy9h
c3NpZ25tZW50cy9jb3JlLXBhcmFtZXRlcnMvPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXpl
PTI+PGJyPg0KJmd0OyAmZ3Q7IGNvcmUtcGFyYW1ldGVycy54aHRtbCNvcHRpb24tbnVtYmVycykg
cHJvYmFibHkgaXQgd2lsbCBiZSBhIGdvb2QNCjxicj4NCiZndDsgJmd0OyBpZGVhIHRvIGtlZXAg
YSBzZWN0aW9uIHRvIGRpc2N1c3MgaG93IHRvIGhhbmRsZSB0aGlzIG9wdGlvbiBzaW5jZQ0KPGJy
Pg0KJmd0OyAmZ3Q7IHRoaXMgaXMgbm90IHRoZXJlIGluIEhUVFAuIFNvbWV3aGVyZSBpbiBTZWN0
aW9uIDggc2hvdWxkIGJlIGENCmdvb2QgPGJyPg0KJmd0OyAmZ3Q7IHBsYWNlIGZvciBzdWNoIGRp
c2N1c3Npb24uIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7
IDxicj4NCiZndDsgJmd0OyBSZWdhcmRzPGJyPg0KJmd0OyAmZ3Q7IEFiaGlqYW4gQmhhdHRhY2hh
cnl5YTxicj4NCiZndDsgJmd0OyBBc3NvY2lhdGUgQ29uc3VsdGFudDxicj4NCiZndDsgJmd0OyBT
Y2llbnRpc3QsIElubm92YXRpb24gTGFiLCBLb2xrYXRhLCBJbmRpYTxicj4NCiZndDsgJmd0OyBU
YXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzPGJyPg0KJmd0OyAmZ3Q7IE1haWx0bzogYWJoaWphbi5i
aGF0dGFjaGFyeXlhQHRjcy5jb208YnI+DQomZ3Q7ICZndDsgV2Vic2l0ZTogPC9mb250PjwvdHQ+
PGEgaHJlZj1odHRwOi8vd3d3LnRjcy5jb20vPjx0dD48Zm9udCBzaXplPTI+aHR0cDovL3d3dy50
Y3MuY29tPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyAmZ3Q7IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7
IEV4cGVyaWVuY2UgY2VydGFpbnR5LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJVCBTZXJ2
aWNlczxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDtCdXNpbmVzcyBT
b2x1dGlvbnM8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7Q29uc3Vs
dGluZzxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgRnJvbTogJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7Q2Fyc3RlbiBCb3JtYW5uICZsdDtjYWJvQHR6aS5vcmcmZ3Q7DQo8YnI+DQomZ3Q7ICZn
dDsgVG86ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90OzwvZm9udD48L3R0PjxhIGhy
ZWY9bWFpbHRvOmNvcmVAaWV0Zi5vcmclMjBXRz48dHQ+PGZvbnQgc2l6ZT0yPm1haWx0bzpjb3Jl
QGlldGYub3JnJTIwV0c8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj4mcXVvdDsNCiZs
dDtjb3JlQGlldGYub3JnJmd0OyA8YnI+DQomZ3Q7ICZndDsgRGF0ZTogJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7MDkvMTUvMjAxNSAwODo1MSBQTSA8YnI+DQomZ3Q7ICZndDsgU3ViamVjdDog
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W2NvcmVdIFdHIGxhc3QtY2FsbCAoV0dMQykNCm9m
IGRyYWZ0LWlldGYtY29yZS08YnI+DQomZ3Q7IGh0dHAtbWFwcGluZy0wNzxicj4NCiZndDsgJmd0
OyBTZW50IGJ5OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtjb3JlJnF1b3Q7ICZs
dDtjb3JlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEluIFBy
YWd1ZSwgd2Ugc2FpZCB3ZSB3ZXJlIGdvaW5nIHRvIFdHTEMgdGhlIEhUVFAgbWFwcGluZyBkcmFm
dA0KYWZ0ZXI8YnI+DQomZ3Q7ICZndDsgY2xvc2Ugb2YgdGhlIHZhY2F0aW9uIHBlcmlvZCwgd2hp
Y2ggaXMgbm93IGJlaGluZCB1cy4gJm5ic3A7QWxsDQpvdXRzdGFuZGluZzxicj4NCiZndDsgJmd0
OyB0aWNrZXRzIGFyZSBjbG9zZWQsIGFuZCB0aGVyZSB3YXMgZW5vdWdoIHRpbWUgdG8gcmV2aWV3
IHRoZSBjdXJyZW50PGJyPg0KJmd0OyAmZ3Q7IGRyYWZ0LiAmbmJzcDtUaHJlZSBwZW9wbGUgcmFp
c2VkIHRoZWlyIGhhbmRzIHdoZW4gd2UgYXNrZWQgd2hvDQp3b3VsZCBzdWJtaXQ8YnI+DQomZ3Q7
ICZndDsgcmV2aWV3cyAoTWljaGFlbCBLLiwgS2xhdXMsIERhcnNoYWspLCBidXQgb2YgY291cnNl
IGFkZGl0aW9uYWwNCnJldmlld3M8YnI+DQomZ3Q7ICZndDsgYmV5b25kIHRoYXQgYXJlIGFsc28g
dmVyeSB1c2VmdWwuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBTbyB0aGlzIHN0YXJ0
cyBhIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvcjxicj4NCiZndDsgJmd0OyBkcmFmdC1pZXRm
LWNvcmUtaHR0cC1tYXBwaW5nIGZvciBzdWJtaXNzaW9uIGFzIGFuIGluZm9ybWF0aW9uYWwNClJG
Qyw8YnI+DQomZ3Q7ICZndDsgZW5kaW5nIG9uPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyAyNDowMCBQRFQgb24gVHVlc2RheSwgU2VwdGVtYmVyIDI5LCAyMDE1Ljxicj4NCiZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgVGhlIGRyYWZ0IGlzIGxvY2F0ZWQgYXQ6PGJyPg0KJmd0OyAmZ3Q7
IDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p
ZXRmLWNvcmUtaHR0cC1tYXBwaW5nLTA3Ij48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvcmUtaHR0cC1tYXBwaW5nLTA3PC9mb250PjwvdHQ+
PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBQbGVh
c2Ugc3RhcnQgYSBuZXcgZW1haWwgdGhyZWFkIGZvciBlYWNoIG1ham9yIGlzc3VlIHRoYXQgd2ls
bA0KbmVlZDxicj4NCiZndDsgJmd0OyBkaXNjdXNzaW9uIGFuZCBtYWtlIHN1cmUgdGhlIHN1Ympl
Y3QgbGluZSBpbmNsdWRlcyB0aGUgZHJhZnQNCm5hbWUgYW5kPGJyPg0KJmd0OyAmZ3Q7IHNvbWUg
c29ydCBvZiBuYW1lIGZvciB0aGUgaXNzdWUuIEZvciBtaW5vciBpc3N1ZXMgc3VjaCBhcyB0eXBv
cw0KYW5kPGJyPg0KJmd0OyAmZ3Q7IHRoaW5ncyB0aGF0IGFyZSBub3QgbGlrZWx5IHRvIGxlYWQg
dG8gbXVjaCBkaXNjdXNzaW9uLCBpdCBpcw0KcHJvYmFibHk8YnI+DQomZ3Q7ICZndDsgZWFzaWVy
IHRvIGdyb3VwIHRoZW0gYWxsIGluIHRvIG9uZSBlbWFpbCBidXQgYWdhaW4sIHBsZWFzZSBtYWtl
DQpzdXJlPGJyPg0KJmd0OyAmZ3Q7IHRoZSBzdWJqZWN0IGxpbmUgaW5jbHVkZXMgdGhlIGRyYWZ0
IG5hbWUuIElmIHlvdSByZWFkIHRoZSBkcmFmdA0KYW5kPGJyPg0KJmd0OyAmZ3Q7IHRoaW5rIGl0
IGxvb2tzIGZpbmUsIHBsZWFzZSBzZW5kIGEgb25lIGxpbmUgZW1haWwgdG8gdGhlIGxpc3QNCm9y
IHRvPGJyPg0KJmd0OyAmZ3Q7IHRoZSBjaGFpcnMgbGV0dGluZyB1cyBrbm93IHRoYXQgc28gd2Ug
Y2FuIGdldCBhIGZlZWwgb2YgaG93IGJyb2FkDQp0aGU8YnI+DQomZ3Q7ICZndDsgcmV2aWV3IGhh
cyBiZWVuLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSW4gdGhlIHVubGlrZWx5IGV2
ZW50IHRoYXQgeW91IGFyZSBhd2FyZSBvZiBhbnkgcGF0ZW50IGNsYWltcw0KdGhhdDxicj4NCiZn
dDsgJmd0OyBtaWdodCBhcHBseSB0byBzeXN0ZW1zIHRoYXQgaW1wbGVtZW50IHRoZSBzdWdnZXN0
aW9ucyBpbiB0aGlzDQpkcmFmdCw8YnI+DQomZ3Q7ICZndDsgcGxlYXNlIHJldmlldyBCQ1AgNzgg
YW5kIEJDUCA3OSBhbmQgbWFrZSBhbnkgYXBwcm9wcmlhdGUgSVBSPGJyPg0KJmd0OyAmZ3Q7IGRl
Y2xhcmF0aW9uLiBJZiB5b3UgYXJlIG5vdCBzdXJlIHdoZXRoZXIgeW91IG5lZWQgdG8gbWFrZSBh
PGJyPg0KJmd0OyAmZ3Q7IGRlY2xhcmF0aW9uIG9yIG5vdCwgcGxlYXNlIHRhbGsgdG8gdGhlIGNo
YWlycyBhbmQgd2Ugd2lsbCBoZWxwDQpnZXQgeW91PGJyPg0KJmd0OyAmZ3Q7IGluIHRvdWNoIHdp
dGggcGVvcGxlIHRoYXQgY2FuIHByb3ZpZGUgYXBwcm9wcmlhdGUgYWR2aWNlLjxicj4NCiZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgR3LDvMOfZSwgQ2Fyc3Rlbjxicj4NCiZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188YnI+DQomZ3Q7ICZndDsgY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgY29yZUBp
ZXRmLm9yZzxicj4NCiZndDsgJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZT48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQg
c2l6ZT0yPg0KPGJyPg0KJmd0OyAmZ3Q7ID09PT09LS0tLS09PT09PS0tLS0tPT09PT08YnI+DQom
Z3Q7ICZndDsgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWls
PGJyPg0KJmd0OyAmZ3Q7IG1lc3NhZ2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1heSBjb250
YWluIDxicj4NCiZndDsgJmd0OyBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv
bi4gSWYgeW91IGFyZSA8YnI+DQomZ3Q7ICZndDsgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs
IGFueSBkaXNzZW1pbmF0aW9uLCB1c2UsIDxicj4NCiZndDsgJmd0OyByZXZpZXcsIGRpc3RyaWJ1
dGlvbiwgcHJpbnRpbmcgb3IgY29weWluZyBvZiB0aGUgPGJyPg0KJmd0OyAmZ3Q7IGluZm9ybWF0
aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlIDxicj4NCiZndDsgJmd0OyBhbmQv
b3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIDxicj4NCiZn
dDsgJmd0OyB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIDxi
cj4NCiZndDsgJmd0OyBwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhv
bmUgYW5kIDxicj4NCiZndDsgJmd0OyBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRl
IHRoZSBtZXNzYWdlIDxicj4NCiZndDsgJmd0OyBhbmQgYW55IGF0dGFjaG1lbnRzLiBUaGFuayB5
b3UgPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7
IGNvcmVAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU+PHR0Pjxmb250IHNpemU9Mj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8L2ZvbnQ+PC90dD48L2E+PHR0
Pjxmb250IHNpemU9Mj4NCjwvZm9udD48L3R0Pg0K
--=_alternative 001CF37B65257ECE_=--


From nobody Mon Sep 28 07:09:28 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 ECBD51A916A for ; Mon, 28 Sep 2015 07:09:26 -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 vjcS7yvgX5Zm for ; Mon, 28 Sep 2015 07:09:25 -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 0494C1A9163 for ; Mon, 28 Sep 2015 07:09:24 -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 t8SE9La1010535 for ; Mon, 28 Sep 2015 16:09:21 +0200 (CEST)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 3nPm1Y1Ld2z4p3k for ; Mon, 28 Sep 2015 16:09:21 +0200 (CEST)
Received: by wiclk2 with SMTP id lk2so107108812wic.0 for ; Mon, 28 Sep 2015 07:09:20 -0700 (PDT)
X-Received: by 10.180.186.10 with SMTP id fg10mr19323665wic.30.1443449360878;  Mon, 28 Sep 2015 07:09:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.117.226 with HTTP; Mon, 28 Sep 2015 07:08:41 -0700 (PDT)
In-Reply-To: <55F83752.3090609@tzi.org>
References: <55F83752.3090609@tzi.org>
From: Klaus Hartke 
Date: Mon, 28 Sep 2015 16:08:41 +0200
Message-ID: 
To: "core@ietf.org WG" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07
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, 28 Sep 2015 14:09:27 -0000

Here's my review of draft-ietf-core-http-mapping-07:

Overall -- the document is 'Informational', but it makes a lot of use
of requirement keywords (SHOULD, MUST, etc.). Do these keywords
indicate conformance requirements? What happens if a proxy
implementation ignores any of the requirements? Where do
interoperability problems occur in this case? Please review all
occurrences of a requirement keywords in the document and verify that
is really necessary for interoperability. Explain what happens when a
proxy implementation fails to implement a requirement keyword. IMHO
the only requirement is really that the proxy MUST keep up the
illusion that it is an HTTP origin server; everything else seems to be
OPTIONAL to me.

1. "is to reduce variation between proxy implementations, thereby
increasing interoperability" -- where do these interoperability
problems occur? A HTTP-CoAP cross-protocol reverse proxy appears as an
origin server to the HTTP client, so for the HTTP client any such
proxy looks the same.

5. "base URI" -- the term "base URI" has a well-defined meaning in the
context of URI reference resolution (RFC 3986, Section 5). You're
using it here for something else, which is confusing. Please use a
different term.

5.2 "The default URI mapping function is RECOMMENDED to be
implemented" -- why? What happens when this requirement is ignored?

5.3 -- I don't understand this section. What is this? Why do we need
this? How is this different from the default mapping in Section 5.2?
Who uses these templates, the client or the proxy?

5.3 -- Section 5.2 defines a default mapping, 5.3.1 seems to define
three additional mappings, 5.3.2 seems to define yet another mapping.
Section 1 says that one goal of the spec "is to reduce variation
between proxy implementations, thereby increasing interoperability".
How does this multitude of mappings reduce variability?

5.4 -- "to discover the proxy function, the HC proxy SHOULD publish
information related to the location and syntax of the HC proxy
function" -- the proxy is a reverse proxy. It appears as an origin
server to any client. Why does the proxy function need to be
discovered? Who are the "third parties"?

5.4.1 -- Section 5.4 is about discovering the proxy function, 5.4.1 is
about discovering resources, 5.4.2 is about discovering the proxy
function again. This is confusing.

5.4.2 "The first example exercises the CoAP interface" -- why does a
CoAP client need to discover a HTTP-CoAP proxy?

6.5.2. -- to keep the illusion up that the proxy is an origin server,
the proxy MUST rewrite _all_ URIs in _all_ representation formats, not
just Link Formats. This includes _all_ URIs generated on-the-fly by
JavaScript code! Unless the proxy has a very deep understanding of the
application, this is generally not possible. But a reverse proxy with
a very deep understanding of the application is unlikely to use any of
the URI mapping schemes defined in the document. So basically the
whole Section 5 is useless.

6.5.3. "the CoAP diagnostic payload must be used as the HTTP
reason-phrase of the HTTP status line" -- a diagnostic payload is
similar to the HTTP reason phrase, but it can be much more verbose
and, e.g., can include CR-LF line breaks. It's probably best to stick
the diagnostic payload into the payload and use the default reason
phrase for the status code.

7. "4.02 Bad Option | 400 Bad Request" -- can the HTTP client make a
change to its request so that the proxy does not include the bad
option in its CoAP request? If not, the bad option is the proxy's
fault (5xx status code) and not the HTTP client's fault (4xx status
code).

7. "The proxy receiving 2.03 updates the freshness of its cached
representation and returns the entire representation to the HTTP
client." -- If the proxy receives a response indicating that the etag
supplied by the HTTP client is valid, why does the proxy need to send
the representation to the client?

7. "If the HC proxy does not implement a proper authentication method
that can be used to gain access to the target CoAP resource, it can
include a 'dummy' challenge for example "WWW-Authenticate: None"." --
if the proxy cannot gain access to the CoAP resource, it should
probably return a 403 (Forbidden) status code to the HTTP client.

7. "In this case the HC Proxy SHOULD also return a HTTP reason-phrase
in the HTTP status line that starts with the string "405" in order to
facilitate troubleshooting." -- this leads to a status line like
"HTTP/1.1 400 405 Method Not Allowed" which looks wrong and may
confuse implementers.

7. "The value of the HTTP "Retry-After" response-header field is taken
from the value of the CoAP Max-Age Option, if present." -- if the
Max-Age Option is not present, it means that the Max-Age is 60
seconds, not that the representation doesn't have a Max-Age.

8.1 "An HC proxy SHOULD limit the number of requests to CoAP servers
by responding, where applicable, with a cached representation of the
resource." -- The proxy actually MUST perform congestion control as
specified in RFC 7252. Caching is not about congestion control, it is
about efficiency. So, as a matter of quality of implementation, it is
a good idea for a proxy to implement caching. But responding with a
cached representation of the resource is not a tool to enforce
congestion control.

8.1 "Duplicate idempotent pending requests by an HC proxy to the same
CoAP resource SHOULD in general be avoided, by using the same response
for multiple requesting HTTP clients without duplicating the CoAP
request." -- this is not how caching in CoAP works. Please read RFC
7252.

8.1 "According to [RFC7252], a proxy MUST limit the number of
outstanding interactions to a given CoAP server to NSTART." -- this
has already been specified in RFC 7252. There is no need to repeat
that here.

9.2 -- have you submitted the registration to the media-types@ietf.org
mailing list for review? It's probably a good idea to do this before
sending the document to the IESG.

Are there any implementations of this document?

Klaus


From nobody Mon Sep 28 07:36: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 1365F1A92F1 for ; Mon, 28 Sep 2015 07:36:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level: 
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 BsnI4OvHHkX4 for ; Mon, 28 Sep 2015 07:36:27 -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 49D141A92E3 for ; Mon, 28 Sep 2015 07:36:27 -0700 (PDT)
Received: from [192.168.131.140] ([80.92.119.87]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MHH3P-1Zu4CJ3OKJ-00E92J for ; Mon, 28 Sep 2015 16:36:25 +0200
To: "core@ietf.org WG" 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <5609505A.1000807@gmx.net>
Date: Mon, 28 Sep 2015 16:36:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RVM9ePiBTx1cllEiv4aw3rWtjbOCHJSCl"
X-Provags-ID: V03:K0:yc9sFN70PmssHzPQn5ZJlGen6JpHrnz/PrDGe4/+zTZAeM96Vw5 6UKnFhc/Q5ixRHL90NxjEN1o+zm6NUGSPGaElt1+KZhsL7i2RWHCVz6mkGYmnKcqev15qfH 0qDkcKE9LznY63HaEsYiFU+7uVLWZn0XxdkEynsTdn+8YAjYQ/5Q6wbzLqYTCteweaUNg1x UUW9zI86NOIuJQ1pGDjrw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:dzLgDS+V4vs=:47m0SUroRRYc1h5wSINbHR 4cu3nLiTrjaeYlAhV2XoaAgSSi8pMuGWOgnHkOHwOFZn5GccawKdZ0CswdCohYUchiZiyW+/B VFfZg8pIFuhe3Ab2e5qLqN1nmu25+l1boGIqCD+13IlKac2KR4VxTrArUhJZYeUaRbUcnVXDw VfBQkM+lzZBzE6iDCK7ppgm27tThSd419uYiWD+OGMoqzTIM0zpqJKhYstNrmCzlTlcws3WB6 FYLTJWsGHA5FEIxiOeRt02F3QeU5EUQoegsurEOzwrJU+STgtMcoNXzbzjdtvNqWjVUIfB5sL PxpbkjUAhcTu2t0U77jJ6aTMLJ2uXN0eUi1+JAge5AHflvow6ISMChdN61GpwFo1G+UxcpGX6 qAT9aDJ+asp75+6x7o37cfxGuRCS3u8jNcjTAOQ8OytAzHzIvzPTFOV2blqgfeAKI3+eMoxoY VwtU94B8iom90At4NmGh30EA0S6A0zxhQ1I9tEPnr2XcTt3Gz176mM7jj9GK6sg3Dw65UiRrX JTIhCbumy844rt4tRc9rs88mOzn28091nBkhmsC8mOvbkqq9jvJK41KlVd0JjalcV7EB/MUas V5vpbKXIHyOiT21QkAvQbqJr26GO9XMRp03MMJqVPwuzI1MJkD7HHARkI8Fh8iood/WLyzEf3 qOhleZL/OELpuveyBiyFGENck8WdqSHd2C8EMobGYwsQ9gYjvFd1zgy4OY0WFuOyO9CFIeNbj HFd8+DlO95ULMHL8
Archived-At: 
Subject: [core] HTTP Header Parameters in draft-ietf-core-http-mapping-07
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, 28 Sep 2015 14:36:29 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--RVM9ePiBTx1cllEiv4aw3rWtjbOCHJSCl
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Dear authors,

I was wondering what the story for mapping HTTP header fields to CoAP
is. I didn't see anything on that topic in your document (based on
briefly scanning through it).

Ciao
Hannes


--RVM9ePiBTx1cllEiv4aw3rWtjbOCHJSCl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJWCVBaAAoJEGhJURNOOiAtAq8H/1bNJyyz1Kz0YB42CColPNsI
wkGos6RJmmQz36BYT4O/ruG5bCYsHPH/SH7mRMQOy2VAeAbfKxJi8WQkdDJES0nI
1LuFb/oa4WdWfdj4WC1paBQYadlSss+UixLZ0v9jvMZSN+p6kodVUj5Q0VMj4yiX
ak/ixPSs4kznAkMQ2Nal/xOO5rZVlG2nh8R3f19VkYdSo1qYQ0Ly4MSiqMFtqUUy
8oQFlk5ZMrrD6Iy42dnx9DfXrCQs+WkqHnt0PMcr1fVKccCjIiebd22JYQGAdvvw
4+Qk+RlWCQFszrLXanYYu71r5iJpeLM2svA8HMiNPDGyErlSNoJIZoPhk2baTvw=
=H0Uy
-----END PGP SIGNATURE-----

--RVM9ePiBTx1cllEiv4aw3rWtjbOCHJSCl--


From nobody Mon Sep 28 09:40: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 C3F0D1ACE5D for ; Mon, 28 Sep 2015 09:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kmqY79f3pWcH for ; Mon, 28 Sep 2015 09:40:53 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B621ACE5F for ; Mon, 28 Sep 2015 09:40:53 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 50E6331BE0EF2; Mon, 28 Sep 2015 16:40:47 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t8SGen42026263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Sep 2015 18:40:50 +0200
Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.234]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 28 Sep 2015 18:40:49 +0200
From: "FOSSATI, Thomas (Thomas)" 
To: Hannes Tschofenig , "core@ietf.org WG" 
Thread-Topic: [core] HTTP Header Parameters in draft-ietf-core-http-mapping-07
Thread-Index: AQHQ+fsc1HI46NVdMUicbYv8BoQZFJ5SFB8A
Date: Mon, 28 Sep 2015 16:40:49 +0000
Message-ID: 
References: <5609505A.1000807@gmx.net>
In-Reply-To: <5609505A.1000807@gmx.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.5.150821
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8026928C4D0F8047AE071AA43D7C0EAD@exchange.lucent.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [core] HTTP Header Parameters in draft-ietf-core-http-mapping-07
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, 28 Sep 2015 16:40:54 -0000

Hi Hannes,

On 28/09/2015 15:36, "core on behalf of Hannes Tschofenig"
 wrote:
>I was wondering what the story for mapping HTTP header fields to CoAP
>is. I didn't see anything on that topic in your document (based on
>briefly scanning through it).

The idea is that quite a few HTTP request headers are either not really
interesting on the CoAP side and as such they are removed by the proxy
(e.g. User-Agent, Host), or have an implicit mapping (e.g. Content-Length).


The exception are headers that have to do with representation description
& negotiation: Content-Type, Content-Encoding, and the various Accept-*.
Those are discussed quite extensively in section 6.

Please, tell us if you think there is a need for a specific header mapping
that is not in the document already, or if the current mappings are
insufficiently described.

Cheers, t


From nobody Tue Sep 29 02:51: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 3FFF01A6F9A for ; Tue, 29 Sep 2015 02:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 P2Z4l5rb_YsD for ; Tue, 29 Sep 2015 02:51:10 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 66BC41A6F90 for ; Tue, 29 Sep 2015 02:51:10 -0700 (PDT)
Received: from [192.168.131.140] ([80.92.119.87]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M04uG-1aWcGe0r88-00uJ8d; Tue, 29 Sep 2015 11:51:08 +0200
To: "FOSSATI, Thomas (Thomas)" , "core@ietf.org WG" 
References: <5609505A.1000807@gmx.net> 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <560A5EF9.9060302@gmx.net>
Date: Tue, 29 Sep 2015 11:50:49 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XOBt6webVE3Mn6VESCXSB5lP5tJR84jfG"
X-Provags-ID: V03:K0:SAvXqxRhX3UNBn9YQYVYkbdQS/zDqtkBFn/hARY391CnNKHoEyv x6YFaWawmSf0G9nF9CgiOfB5oY54hrk4heIbT60KkZQuxhT8/FqYTelHLfVgiXXSmOSnTYB uPpwzZGH1InnCL9gPYZKLd0TabYuuZeUy1GQEKGBjuaice3KdFLmHA5Ir2XYU41VZ7Fg4oR 6EoUlg3V0B0cs0IVz5m2w==
X-UI-Out-Filterresults: notjunk:1;V01:K0:tS5m41F2QCw=:L0vWV1/+PUrBlcbyMOmuPA +WcwHqGyeJQfs8NyFX1wmMwXXe5ssaPk6cXC3mxH5weDk2eJ9mdnVvj/HFnps5GEZqcqrzCLs fTxZM6aNZhyIrsMtRfiod0a8jVUVvglo27aWK1+RaF6GfKTVqNGrR8riE2wMQ8KyZAIrolEl0 UUAtah7VLh2gY5/hh9EyeyMNaJ7wfhBIsQKitJPbhvo9dnaMrYToRhUqNJGF3k+Rloif3AZTk Tt/XKWVPzgRePc9vVaJtsGxXw4I11Jn1EC07gN+v6psQhrxI5DIEuGkATp7YsUuyWKBbE67MX HGsDZ+CJFcfpmXo+pQyDnmn4EinAX4oObBNuj6677jHWr10m8eOqiBf81CuMIJkH6cci4PAfC hRJ/UILUU3hh4EKtZs5kFx+njKr93A5GpPRjbxKs2pTsxb652DvGnqVYowkXskh3vD2k05/YU nzpf1iJVghpCH9EvG3LgEU2hKp6pXiLLhWAsuaG28jHy1P2vCpsCgt1br0ROVUvrYF58Bq3p8 MS/9ZghjHiC0diFa485Jtwnt3iNTR0pjZAGQ0ZKnPOjebAZrEkMVnT+8aa5PiX/eiVJIxgAsl Ust+jnVq+VWHFhpVWJY5sU9I3uhFdvuTnvg//uMOnxfpbqm9xczriGFJIUwYaH0sPRr1ci2GB Ep4Kx85Zpdp4RHTyPHk+hJbhHnHVoTtwzyLPulL/u410SOotVwDfeDpjbIQBNHaxPP6n4L8Nr 0yn4Ddq8r9rLZ0np
Archived-At: 
Subject: Re: [core] HTTP Header Parameters in draft-ietf-core-http-mapping-07
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, 29 Sep 2015 09:51:12 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--XOBt6webVE3Mn6VESCXSB5lP5tJR84jfG
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Thomas,

thanks for your reply.

I believe you should state this assumption in the document (if not done
already and I failed to notice it).

Whether this assumption is justified or not I don't know but there are
certainly HTTP headers that are used, for example those related to
security. As an example, consider the WWW-Authenticate header.

So, in practical terms it means that those deploying CoAP-HTTP proxies
have to carefully determine how the protocol structure looks like and
how the translation works otherwise they may encounter some unpleasant
surprises.

I guess the reason for not copying the HTTP header into CoAP header is
the size limitation of the header parameters. Correct?

Is there a size limitation of the URI length in CoAP?

Ciao
Hannes


On 09/28/2015 06:40 PM, FOSSATI, Thomas (Thomas) wrote:
> Hi Hannes,
>=20
> On 28/09/2015 15:36, "core on behalf of Hannes Tschofenig"
>  wrote:
>> I was wondering what the story for mapping HTTP header fields to CoAP
>> is. I didn't see anything on that topic in your document (based on
>> briefly scanning through it).
>=20
> The idea is that quite a few HTTP request headers are either not really=

> interesting on the CoAP side and as such they are removed by the proxy
> (e.g. User-Agent, Host), or have an implicit mapping (e.g. Content-Leng=
th).
>=20
>=20
> The exception are headers that have to do with representation descripti=
on
> & negotiation: Content-Type, Content-Encoding, and the various Accept-*=
=2E
> Those are discussed quite extensively in section 6.
>=20
> Please, tell us if you think there is a need for a specific header mapp=
ing
> that is not in the document already, or if the current mappings are
> insufficiently described.
>=20
> Cheers, t
>=20


--XOBt6webVE3Mn6VESCXSB5lP5tJR84jfG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJWCl75AAoJEGhJURNOOiAtWfUIAJ5IgN4/kxFwUmufqUxHTkDY
9mnXM+LkL6knIpF4LthujjGnEy76Y1WHL/XfjCe91zfJ+l8ayh2kD+TOf66J0n1P
3VE/kNahVUbGko/BQrZqGBnlGtJ5ubpN95KxCLZraMpE9X6a6kjxHl3zM92MmhbN
4g2emsV//0HvWzTGrqlVX/DlBOQa6DTla+es1fMNl5D3JBv+RWO6o2gMQgvYHNGI
nKO5JYoQ5d99C1xraZ/niHXKGN9yniihWf2L8qYrbgyZUkyKR6Ucm8sM7jj9dBt6
ZzqBrKMDqOhV+V52RMr93DQug/qyGNT91EZHS78n0JHQFTW4bubLpVTvrK0vogI=
=Q2i9
-----END PGP SIGNATURE-----

--XOBt6webVE3Mn6VESCXSB5lP5tJR84jfG--


From nobody Tue Sep 29 03:55: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 5CBA41A00AE for ; Tue, 29 Sep 2015 03:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level: 
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CuB47czO-yBM for ; Tue, 29 Sep 2015 03:55: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 7AA731A00BD for ; Tue, 29 Sep 2015 03:55: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 t8TAtc25024926; Tue, 29 Sep 2015 12:55:38 +0200 (CEST)
Received: from alma.local (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (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 3nQHgZ5Wrsz4pyt; Tue, 29 Sep 2015 12:55:38 +0200 (CEST)
Date: Tue, 29 Sep 2015 12:55:38 +0200
From: Carsten Bormann 
To: "=?utf-8?Q?core=40ietf.org_WG?=" , "=?utf-8?Q?FOSSATI=2C_Thomas_(Thomas)?=" , Hannes Tschofenig 
Message-ID: 
In-Reply-To: <560A5EF9.9060302@gmx.net>
References: <5609505A.1000807@gmx.net>  <560A5EF9.9060302@gmx.net>
X-Mailer: Airmail (329)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="560a6e2a_339ca906_c441"
Archived-At: 
Subject: Re: [core] HTTP Header Parameters in draft-ietf-core-http-mapping-07
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, 29 Sep 2015 10:55:48 -0000

--560a6e2a_339ca906_c441
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 29 Sep 2015 at 11:51:23, Hannes Tschofenig (hannes.tschofenig=40gmx.ne=
t) wrote:
Is there a size limitation of the URI length in CoAP=3F=C2=A0
As a hard (=E2=80=9Cartificial=E2=80=9D) limitation, CoAP limits the size=
 of each path component and query element to 255 bytes (percent-decoding =
has already been done at this level). =C2=A0But you can have any number o=
f these.

Practically, the whole thing (other options and, possibly, payload includ=
ed) needs to fit into a UDP packet that still gets good delivery probabil=
ity, so, if adaptation layer fragmentation is involved, you want to stay =
within an order of 100 bytes (for most applications, I would say =E2=89=A4=
 80) for most of your messages. =C2=A0But how relevant that consideration=
 is, is highly deployment dependent.

Gr=C3=BC=C3=9Fe, Carsten
--560a6e2a_339ca906_c441
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline



--B_3526536501_1949814--