From nobody Mon Feb 1 00:20:14 2016 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 1E59E1A8A3A; Mon, 1 Feb 2016 00:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] 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 oVXPDp9-_REv; Mon, 1 Feb 2016 00:20:05 -0800 (PST) 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 2D90C1A8A29; Mon, 1 Feb 2016 00:20:04 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-27-56af1532b7ea Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4D.B8.02707.2351FA65; Mon, 1 Feb 2016 09:20:02 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.151]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Mon, 1 Feb 2016 09:20:01 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "ietf@ietf.org" Thread-Topic: [core] Last Call: (Block-wise transfers in CoAP) to Proposed Standard Thread-Index: AQHRI9sb/ga71FS+3UKAe+rFI8Rp+56t6kEAgGQBhwCABV8vgA== Date: Mon, 1 Feb 2016 08:20:00 +0000 Message-ID: References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com> <063a01d15a22$24099250$6c1cb6f0$@augustcellars.com> In-Reply-To: <063a01d15a22$24099250$6c1cb6f0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUyM2K7lq6R6Powg103eS2+P7/GYrFt4wU2 i31v1zNbNB6ax2ixevp3NotnG+ezOLB5bJwznc1j56y77B5LlvxkCmCO4rJJSc3JLEst0rdL 4MrY9XQta8GcVYwV89u/szQwvlnK2MXIwSEhYCJxdaV8FyMnkCkmceHeerYuRi4OIYHDjBJH VzZAOYsZJeb/XcsMUsUm4CLxoOERE4gtIuAhcev5FFaQImaBE4wSD/4fBksICxRLfG3bxA5R VCJx4fRGNgjbSeL76YVgg1gEVCSunp7DCmLzClhIPJ/TywqxbRmjxJc1u8DO4xRwkHg01wak hhHovO+n1oDNZxYQl7j1ZD4TxNkCEkv2nGeGsEUlXj7+xwrSKiqgJ9F1pAIirCSx6PZnJpAw s4CmxPpd+hBTrCUm7/oKNVFRYkr3Q3aIawQlTs58wjKBUWIWkmWzELpnIemehaR7FpLuBYys qxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjECI/fglt8GOxhfPnc8xCjAwajEw/th4rowIdbE suLK3EOMEhzMSiK8e78ChXhTEiurUovy44tKc1KLDzFKc7AoifMe5F8UJiSQnliSmp2aWpBa BJNl4uCUamBUNurm/D9beF/Q8yz59BXzjirfuXf7iG+e0r1HzhFb2CcdZBB+1FdZHpK64Oar kDd5jgcvCJYIuchxftuVxbg7LCTj3oULImKuxR83a7NHrcvckbm81GHhr3ZuTqfzzFopJ782 Lwz9E9MjZnj/7pK3/9hSL54QC94gybcxL/RI0oN8ub9cPpVKLMUZiYZazEXFiQAhMnk52AIA AA== Archived-At: Cc: "draft-ietf-core-block@ietf.org" , "core-chairs@ietf.org" , "barryleiba@gmail.com" , "core@ietf.org" Subject: Re: [core] Last Call: (Block-wise transfers in CoAP) to Proposed Standard 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, 01 Feb 2016 08:20:09 -0000 SGkgSmltDQoNClRoYW5rcyBmb3IgcGlja2luZyB1cCB0aGUgdGhyZWFkLg0KDQpXZSBzcGVudCBz b21lIHRpbWUgaW4gUHJhZ3VlIHRoaW5raW5nIGFib3V0IHRoaXMuIFlvdSBhcmUgcmlnaHQgdGhh dCB0aGVyZQ0KYXJlIGRpZmZlcmVudCBvcHRpb25zIHdpdGggZGlmZmVyZW50IGNoYXJhY3Rlcmlz dGljcy4gSGVyZSBhcmUgdGhlIGNhc2VzDQp3ZSBoYXZlIGNvbnNpZGVyZWQuDQoNCkp1c3QgdG8g cmVjYXAgdGhlIG9iamVjdGl2ZSwgdGhpcyBpcyBhYm91dCBwcm90ZWN0aW5nIGNvbW11bmljYXRp b24NCmJldHdlZW4gQ29BUCBjbGllbnQgYW5kIENvQVAgc2VydmVyIHdoaWxlIGFsbG93aW5nIGxl Z2l0aW1hdGUgb3BlcmF0aW9ucw0Kb2Ygb25lIG9yIG1vcmUgaW50ZXJtZWRpYXJ5IENvQVAgcHJv eGllcy4gQ2xpZW50IGFuZCBzZXJ2ZXIgYXJlIGFzc3VtZWQgdG8NCmhhdmUgYSBzZWN1cml0eSBh c3NvY2lhdGlvbi4NCg0KT24gYSBoaWdoIGxldmVsIHRoZSBjYW5kaWRhdGUgc29sdXRpb25zIGFy ZSBlaXRoZXIgYnVpbHQgZW50aXJlbHkgb24gdG9wDQpvZiBDb0FQIG9yIGFkZCBuZXcgQ29BUCBv cHRpb25zLg0KDQpMb29raW5nIGF0IHRoZSBmb3JtZXIgZmlyc3QsIG9uZSBzb2x1dGlvbiBpcyB0 byB3cmFwIGp1c3QgdGhlIENvQVANCnBheWxvYWQvY29udGVudCwgZS5nLiB1c2luZyBDT1NFIFsx XS4gKFdlIGNhbGxlZCB0aGlzIG9iamVjdCBzZWN1cml0eSBvZg0KY29udGVudCwgT1NDT04pLiBU aGlzIGlzIHVzZWZ1bCBpZiB0aGUgcGF5bG9hZCBpbmNsdWRlcyBjZXJ0YWluIG1ldGEgZGF0YSwN Cmxpa2UgaW4gdGhlIGNhc2Ugb2YgQ1dULCBvciBpZiBjZXJ0YWluIGluZm9ybWF0aW9uLCBzdWNo IGFzIHJlc291cmNlDQppZGVudGlmaWVyIGV0Yy4sIGlzIGltcGxpY2l0IGZyb20gdGhlIHNlY3Vy aXR5IGFzc29jaWF0aW9uLg0KDQpUaGlzIHNvbHV0aW9uIGhvd2V2ZXIgZG9lcyBub3QgcHJvdGVj dCB0aGUgbWV0YWRhdGEgc2VudCBpbiB0aGUgQ29BUA0KbWVzc2FnZSwgc3VjaCBhcyBlLmcuIENv ZGUgKEdFVC9ERUxFVEUvZXRjKSwgVXJpLVBhdGggb3IgQ29udGVudCBGb3JtYXQuDQpFdmVuIGlm IHN1Y2ggaW5mb3JtYXRpb24gd291bGQgYmUgaW50ZWdyaXR5IHByb3RlY3RlZCwgZS5nLiB1c2lu Zw0KRXh0ZXJuYWwtQUFEIGluIFsxXSwgaXQgbmVpdGhlciBwcm90ZWN0cyBtZXNzYWdlcyB3aGlj aCBkbyBub3QgaGF2ZQ0KcGF5bG9hZCwgbGlrZSBlLmcuIEdFVCByZXF1ZXN0cywgbm9yIGRvZXMg aXQgYWRkcmVzcyBjb25maWRlbnRpYWxpdHkNCmRlc2lyYWJsZSBmb3IgYSBzdWJzZXQgb2Ygc3Vj aCBtZXRhZGF0YSBmb3IgcHJpdmFjeSByZWFzb25zLg0KDQpBbiBhbHRlcm5hdGl2ZSBzb2x1dGlv biBvbiB0b3Agb2YgQ29BUCBpcyB0byBtb3ZlIHRoZSBSRVNUZnVsIHByb3RvY29sIG91dA0Kb2Yg Q29BUCBhbmQgb25seSB1c2UgUE9TVCB3aXRoIHNvbWUgZHVtbXkgVXJpLVBhdGgsIENvbnRlbnQg Rm9ybWF0IGV0Yy4gSW4NCnRoaXMgd2F5IGFsbCBtZXNzYWdlcyBjb3VsZCBjYXJyeSBhIHByb3Rl Y3RlZCBvYmplY3QgYXMgaW4gWzFdIGFuZCB0aGUNCm5hdHVyZSBvZiB0aGUgaW50ZXJhY3Rpb24g YW5kIGNvbnRlbnQgaXMgY29udGFpbmVkIGluIHRoaXMgb2JqZWN0LiBUaGlzIGlzDQpwcm9iYWJs eSB2aW9sYXRpbmcgdGhlIHB1cnBvc2Ugb2YgQ29BUCB0b28gbXVjaCB0byBiZSBvZiBhbnkgaW50 ZXJlc3QuDQoNClRob3NlIGFyZSB0aGUgb25seSBzb2x1dGlvbnMgd2UgaGF2ZSBjb25zaWRlcmVk IG9uIHRvcCBvZiBDb0FQLiBJJ20gbm90DQpzdXJlIGlmIHRoZSBzb2x1dGlvbiB5b3UgcHJvcG9z ZSBpcyByZWxhdGVkIHRvIG9uZSBvZiB0aGVzZT8NCg0KQWxsIG90aGVyIHNvbHV0aW9ucyBJJ20g YXdhcmUgb2Ygd2hpY2ggYWRkcmVzcyB0aGUgZ2VuZXJhbCBwcm9ibGVtIHNwYWNlLA0KZS5nLiBP U0NPQVAsIGFyZSBidWlsdCAid2l0aGluIiBDb0FQLCB1c2luZyBDb0FQIG9wdGlvbnMgdG8gY2Fy cnkNCnByb3RlY3RlZCBvYmplY3RzIChzdWNoIGFzIFsxXSkgd2hpY2ggaW5jbHVkZSBpbnRlZ3Jp dHkgcHJvdGVjdGlvbiBvZiB0aGUNCnBheWxvYWQgYW5kIG1ldGEtZGF0YS4gTm93LCB3aGF0IGhh cHBlbnMgaWYgdGhlIHBheWxvYWQgaXMgbGFyZ2U/IElmIHRoZQ0Kb3JpZ2luYXRpbmcgZW5kcG9p bnQgZG9lcyB0aGUgZnJhZ21lbnRhdGlvbiB0aGVuIHRoZSBkZXN0aW5hdGlvbiBlbmRwb2ludA0K Y2FuIHZlcmlmeSB0aGUgaW50ZWdyaXR5LiBJZiBhIHByb3h5IHVzaW5nIHRoZSBibG9ja3dpc2Ug ZHJhZnQNCihyZS0pZnJhZ21lbnRzIHRoZSBwYXlsb2FkICh3aGljaCBhbHNvIGNoYW5nZXMgYSBC bG9jayBvcHRpb24pIHN1Y2ggdGhhdA0KaXQgaXMgZGlmZmVyZW50IHdoZW4gcmVhY2hpbmcgdGhl IGRlc3RpbmF0aW9uIGVuZHBvaW50LCB0aGVuIGludGVncml0eQ0KdmVyaWZpY2F0aW9uIHdpbGwg ZmFpbC4gVGhlIGRlc3RpbmF0aW9uIGVuZHBvaW50IGNhbm5vdCBkaXN0aW5ndWlzaCBhDQpsZWdp dGltYXRlIGludHJvZHVjdGlvbi9jaGFuZ2Ugb2YgcGF5bG9hZCBhbmQgQmxvY2sgb3B0aW9uIGZy b20gYW55IG90aGVyDQpjaGFuZ2Ugb2YgdGhlIG1lc3NhZ2UsIGhlbmNlIGl0IGNhbm5vdCB2ZXJp ZnkgaW50ZWdyaXR5LiBUaGlzIGNhbiBiZSB1c2VkDQp0byBkaXNhYmxlIGludGVncml0eSBwcm90 ZWN0aW9uIGF0IENvQVAgbGF5ZXIgYWxzbyBmb3Igc2hvcnRlciBtZXNzYWdlcywNCnNpbmNlIHRo ZSBkZXN0aW5hdGlvbiBlbmRwb2ludCBtdXN0IHRyZWF0IHRoZSBleGlzdGVuY2Ugb2YgYSBCbG9j ayBvcHRpb24NCmFzIGEgZ2VuZXJpYyAic2VjdXJpdHkgb2ZmIiBidXR0b24uDQoNClRoaXMgaXMg cXVpdGUgZGlmZmVyZW50IGZyb20gdGhlIENvQVAgb3B0aW9ucyBzdGFuZGFyZGl6ZWQgc28gZmFy IHdoZXJlDQp5b3UgY2FuIHByb3RlY3QgaW5kaXZpZHVhbCBtZXNzYWdlcyBiZXR3ZWVuIGNsaWVu dCBhbmQgc2VydmVyIGF0IHRoZSBzYW1lDQp0aW1lIGFzIGFsbG93aW5nIGxlZ2l0aW1hdGUgcHJv eHkgb3BlcmF0aW9uLCBldmVuIHZlcmlmeWluZyB0aGF0DQppbnRlcm1lZGlhdGUgbm9kZXMgaGFz IHBlcmZvcm1lZCB0aGUgY29ycmVjdCBDb0FQIG9wdGlvbiBtYW5pcHVsYXRpb25zDQpzdWNoIGFz IGUuZy4gd2hlbiBmb3J3YXJkIHByb3hpZXMgY2hhbmdlIHRoZSBVcmktKiBvcHRpb25zIG1ha2lu ZyB0aGUNCm1lc3NhZ2UgcmVhY2ggdGhlIGNvcnJlY3QgZGVzdGluYXRpb24gVVJJLg0KDQpJTUhP IENvQVAgc2hvdWxkIG5vdCBhbGxvdyBhbiBpbnRlcm1lZGlhdGUgZGV2aWNlIHRvIGxlZ2l0aW1h dGVseSB0dXJuIG9mZg0KaW50ZWdyaXR5IHByb3RlY3RpbmcgYmV0d2VlbiBjbGllbnQgYW5kIHNl cnZlci4gQ29BUCBzaG91bGQgZGVmaW5pdGVseQ0Kc3VwcG9ydCBpbnRlZ3JpdHkgcHJvdGVjdGlv biBvZiBzaG9ydCBtZXNzYWdlcyBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyDQp0aHJvdWdoIHBy b3hpZXMuIFRoaXMgaXMgd2hlcmUgQ29BUCBzaGluZXMgYnJpZ2h0bHkuIEdpdmVuIHRoYXQsIGl0 IGlzDQpzdHJhaWdodGZvcndhcmQgdG8gaW50ZWdyaXR5IHByb3RlY3QgbWVzc2FnZXMgZnJhZ21l bnRlZCBhdCB0aGUgZW5kcG9pbnRzLg0KQW5kIHdpdGggdGhlIEJsb2NrIG9wdGlvbnMgaW50ZWdy aXR5IHByb3RlY3RlZCB0aGUgZW50aXJlIG1lc3NhZ2UgYnVpbHQgdXANCm9mIHRoZSBmcmFnbWVu dHMgaXMgYXV0b21hdGljYWxseSBwcm90ZWN0ZWQgYXMgd2VsbC4NCg0KR8O2cmFuDQoNClsxXSBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3NlLW1zZw0KDQoNCg0KDQoN Ck9uIDIwMTYtMDEtMjkgMDA6MTgsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNv bT4gd3JvdGU6DQoNCj5Hw7ZyYW4sDQo+DQo+SSBmaW5hbGx5IGdvdCBjYXVnaHQgdXAgb24gcmVh ZGluZyB0aGUgQ09SRSBtYWlsaW5nIGxpc3QgKGxvdHMgb2YgYm9yZWRvbQ0KPm9uIGlzc3VlcyBJ IGRvbuKAmXQgdGhpbmsgSSBjYXJlIGFib3V0KSBhbmQgSSBkaWQgbm90IGZpbmQgYW55IHJlc3Bv bnNlcyB0bw0KPnlvdXIgbWFpbCBvbiB0aGlzIGlzc3VlLiAgSSB3b3VsZCBsaWtlIHRvIHByb3Bv c2UgYSBkaWZmZXJlbnQgc29sdXRpb24gdG8NCj50aGUgcHJvYmxlbSB3aGljaCBJIHRoaW5rIHlv dSB3aWxsIGZpbmQgYm90aCB3b3JrYWJsZSBhbmQgcG90ZW50aWFsIG5vdA0KPnJlcXVpcmluZyBh bnkgdXBkYXRlcyB0byB0aGUgY3VycmVudCBkcmFmdC4NCj4NCj5XaGVuIEkgcmVhZCB0aGlzIGRy YWZ0IHRoZSBmaXJzdCB0aW1lLCBJIHJlYWQgaXQgYXMgYSBuZXR3b3JrDQo+ZnJhZ21lbnRhdGlv biBkcmFmdCByYXRoZXIgdGhhbiBhcyBhIG1lc3NhZ2luZyBkcmFmdC4gIEFzIHN1Y2ggSSBkaWQg bm90DQo+aGF2ZSB0aGUgc2FtZSBjb25jZXJucyBhYm91dCBvYmplY3Qgc2VjdXJpdHkgYXMgeW91 IHNlZW0gdG8gaGF2ZS4gIEkgbWFkZQ0KPnRoZSBkZWNpc2lvbiB0aGF0IEkgd291bGQgYXBwbHkg dGhlIHNlY3VyaXR5IHRvIHRoZSBlbnRpcmV0eSBvZiB0aGUNCj5tZXNzYWdlIGJlaW5nIHNlbnQs IGFuZCB0aGVuIGZyYWdtZW50IGl0IGludG8gYmxvY2tzIGFmdGVyd2FyZHMuICBTdWNoIGFuDQo+ YXBwcm9hY2ggYWxsb3dzIGZvciBhIG51bWJlciBvZiB0aGluZ3MgdGhhdCB5b3UgYXJlIGhhdmlu ZyBwcm9ibGVtcyB3aXRoDQo+dG8gYmUgaWdub3JlZC4NCj4NCj5Ib3cgdGhlIGZyYWdtZW50YXRp b24gaXMgZG9uZSwgaXMgY2hhbmdlIG9yIGlzIHJlbW92ZWQgYmVjb21lIGltbWF0ZXJpYWwNCj5h cyB0aGUgZW5kIHJlY2lwaWVudCB3b3VsZCBuZWVkIHRvIGhhdmUgYWxsIG9mIHRoZSBmcmFnbWVu dHMgZGVsaXZlcmVkDQo+YW5kIGluIHRoZSBjb3JyZWN0IG9yZGVyIGluIG9yZGVyIHRvIHByb2Nl c3MgdGhlIG1lc3NhZ2UgYW5kIGRvDQo+dmFsaWRhdGlvbi4NCj4NCj5PdmVyaGVhZCBpcyBzbWFs bGVyIGJlY2F1c2UgdGhlIG92ZXJoZWFkIG9mIGVuY3J5cHRpbmcvc2lnbmluZyBhdCB0aGUNCj5v YmplY3Qgc2VjdXJpdHkgbGV2ZWwgaXMgZG9uZSBvbmNlIHJhdGhlciB0aGFuIG9uY2UgcGVyIGZy YWdtZW50LiAgVGhpcw0KPmFsbG93cyBmb3IgZmV3ZXIgYnl0ZXMgdG8gYmUgc2VudCBhY3Jvc3Mg dGhlIHdpcmUuDQo+DQo+VGhlIGhlYWRlcnMgb2YgdGhlIGZpcnN0IG1lc3NhZ2UgaW4gdGhlIGZy YWdtZW50IGFyZSB0aGUgb25lcyB0aGF0IHRoZQ0KPm9iamVjdCBzZWN1cml0eSBzeXN0ZW0gd291 bGQgYmUgdXNpbmcgYm90aCBmb3Igc2VjdXJpdHkgY2FsY3VsYXRpb24NCj5wdXJwb3NlcyBhbmQg Zm9yIHRoZSByZWNlaXZlciB0byBwcm9jZXNzIHRoZSB2YWxpZGF0ZWQgbWVzc2FnZS4NCj4NCj5U aGVyZSBhcmUgc3RpbGwgc29tZSBxdWVzdGlvbiB0aGF0IHBvdGVudGlhbGx5IG5lZWQgdG8gYmUg ZGVhbHQgd2l0aDoNCj4NCj4xKSBBcmUgdGhlIGJsb2NrIG9wdGlvbiBoZWFkZXJzIGF1dGhlbnRp Y2F0ZWQ/ICBUaGUgcHJvYmFibGUgYW5zd2VyDQo+c2hvdWxkIGJlIG5vIGFzIHRoZXkgYXJlIGRl c2lnbmVkIHRvIGJlIGNoYW5nZWQgYnkgaW50ZXJtZWRpYXJpZXMuICBUaGlzDQo+Y2FuIGJlIGRl ZmVycmVkIHVudGlsIHRoZSBnZW5lcmFsIGRpc2N1c3Npb24gYWJvdXQgdGhlIHJlc3Qgb2YgdGhl DQo+Y3VycmVudCBoZWFkZXJzLg0KPg0KPjIpIFdoYXQgb3B0aW9ucyBhcmUgcmVxdWlyZWQgdG8g YmUgY29waWVkIGZvcndhcmQgaW50byBzdWJzZXF1ZW50DQo+bWVzc2FnZXMgYW5kIHdoaWNoIGNh biBiZSBvbWl0dGVkPyAgSSB3YXMgdW5hYmxlIHRvIGZpbmQgYW55IGd1aWRhbmNlIG9uDQo+dGhp cyBpc3N1ZSBmcm9tIHJlYWRpbmcgdGhlIGRvY3VtZW50IGFuZCB0aHVzIHdvdWxkIG5haXZlbHkg bWFrZSB0aGUNCj5hc3N1bXB0aW9uIHRoYXQgYWxsIG9wdGlvbnMgbm90IHNwZWNpZmllZCBieSB0 aGlzIGRvY3VtZW50IGFyZSBjb3BpZWQNCj5mb3J3YXJkIGFuZCBzaG91bGQgYmUgY2hlY2tlZCB0 byBtYWtlIHN1cmUgdGhhdCB0aGV5IGFyZSB1bmNoYW5nZWQgaW4NCj5mdXR1cmUgbWVzc2FnZXMu ICBIb3dldmVyIEkgZG91YnQgdGhhdCBpcyB0aGUgZGVzaXJlIG9mIHRoZSBhdXRob3JzLg0KPlRo aXMgaG93ZXZlciBpcyBub3QgYSBzZWN1cml0eSBzcGVjaWZpYyBpc3N1ZSBhbmQgbmVlZHMgdG8g YmUgYWRkcmVzc2VkDQo+aW4gdGhpcyBkb2N1bWVudC4NCj4NCj4zKSBEbyB3ZSB3YW50IHRvIGFw cGx5IHBlciBtZXNzYWdlIHNlY3VyaXR5IGFzIHdlbGwgLSB0aGF0IGlzIGFuIGlzc3VlDQo+dGhh dCBjYW4gYW5kIHNob3VsZCBiZSBwdW50ZWQgdG8gYSBmdXR1cmUgb2JqZWN0IHNlY3VyaXR5IGRy YWZ0Lg0KPkhvd2V2ZXIsIEkgZG9uJ3Qgc2VlIHRoZSBwb2ludCBleGNlcHQgdG8gcHJvdGVjdCB0 aGUgQUNLL05BQ0sgb3IgbGFjayBvZg0KPm9uIGVhY2ggaW5kaXZpZHVhbCBob3AuICBCdXQgdGhp cyBpcyBwb2ludC10by1wb2ludCBub3QgZW5kLXRvLWVuZC4NCj4NCj5KaW0NCj4NCj4NCj4NCj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR8O2cmFuIFNlbGFuZGVyDQo+PiBTZW50OiBX ZWRuZXNkYXksIE5vdmVtYmVyIDI1LCAyMDE1IDExOjA3IFBNDQo+PiBUbzogaWV0ZkBpZXRmLm9y Zw0KPj4gQ2M6IGRyYWZ0LWlldGYtY29yZS1ibG9ja0BpZXRmLm9yZzsgY29yZS1jaGFpcnNAaWV0 Zi5vcmc7IGNvcmVAaWV0Zi5vcmc7DQo+PiBiYXJyeWxlaWJhQGdtYWlsLmNvbQ0KPj4gU3ViamVj dDogUmU6IFtjb3JlXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLWNvcmUtYmxvY2stMTgudHh0Pg0K Pj4oQmxvY2std2lzZSB0cmFuc2ZlcnMNCj4+IGluIENvQVApIHRvIFByb3Bvc2VkIFN0YW5kYXJk DQo+PiANCj4+IA0KPj4gDQo+PiBUaGVyZSB3YXMgYSB0aHJlYWQgb24gdGhlIENvUkUgV0cgbWFp bGluZyBsaXN0IGEgY291cGxlIG9mIG1vbnRocyBhZ28NCj4+b24gdGhlDQo+PiB0b3BpYyBvZiBi bG9ja3dpc2UgYW5kIG9iamVjdCBzZWN1cml0eS4gVGhlIHN0YXJ0aW5nIHBvaW50IHdhcyBhDQo+ PnF1ZXN0aW9uIGlmIENvQVANCj4+IHByb3hpZXMgY2FuIChyZS0pcGFydGl0aW9uIG1lc3NhZ2Vz IGludG8gYmxvY2tzIGFzIGRlZmluZWQgaW4gdGhpcw0KPj5kcmFmdCwgYW5kIHRoZQ0KPj4gaW1w bGljYXRpb25zIG9uIGVuZC10by1lbmQgc2VjdXJpdHkgYmV0d2VlbiBjbGllbnQgYW5kIHNlcnZl ciB0aHJvdWdoDQo+PnN1Y2ggYQ0KPj4gcHJveHkuIFRoZSBjb25jbHVzaW9ucyBvZiB0aGF0IGRp c2N1c3Npb24gaGFzIGFuIGltcGFjdCBvbiB0aGlzIGRyYWZ0LA0KPj5idXQgdGhlcmUNCj4+IGFy ZSBubyBjb25zaWRlcmF0aW9ucyBvZiB0aGlzIGtpbmQgbWFkZSBpbiB2ZXJzaW9uIC0xOC4gTW9y ZSBkZXRhaWxzDQo+PmFyZSBnaXZlbg0KPj4gYmVsb3csIGluY2x1ZGluZyBzb21lIGFsdGVybmF0 aXZlIHByb3Bvc2FscyBmb3IgaG93IHRvIGFkZHJlc3MgdGhpcy4NCj4+QXBvbG9naWVzDQo+PiBm b3IgdGhlIGxvbmcgZS1tYWlsLg0KPj4gDQo+PiANCj4+IEJhY2tncm91bmQ6DQo+PiANCj4+IFRo ZXJlIGlzIGFuIG9uZ29pbmcgZGlzY3Vzc2lvbiBpbiBDb1JFIGFuZCBBQ0UgV0dzIHNpbmNlIGEg eWVhciBvbiB0aGUNCj4+ZW5kLXRvLQ0KPj4gZW5kIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgQ29B UCwgaS5lLiBwcm90ZWN0aW5nIHRoZSBjb21tdW5pY2F0aW9uDQo+PmJldHdlZW4gYQ0KPj4gY2xp ZW50IGFuZCBhIHNlcnZlciB0aHJvdWdoIHByb3hpZXMuIFJGQyA3MjUyIGFuZCBvdGhlciBzcGVj aWZpY2F0aW9ucw0KPj5pbiB0aGUNCj4+IENvQVAgc3VpdGUgZGVmaW5lIGEgc2V0IG9mIGxlZ2l0 aW1hdGUgcHJveHkgb3BlcmF0aW9ucyBvbiBDb0FQIG1lc3NhZ2VzDQo+PndoaWNoDQo+PiByZXF1 aXJlcyBEVExTIHRvIGJlIHRlcm1pbmF0ZWQgYXQgcHJveGllcy4gVGhpcyBpbXBsaWVzIHRoYXQg dGhlIHByb3h5DQo+PmhhcyBhY2Nlc3MNCj4+IG5vdCBvbmx5IHdpdGggdGhlIGRhdGEgcmVxdWly ZWQgZm9yIHBlcmZvcm0gdGhlIGludGVuZGVkIHByb3h5DQo+Pm9wZXJhdGlvbiBidXQgaXMNCj4+ IGFsc28gYWJsZSB0byBlYXZlc2Ryb3Agb3IgbWFuaXB1bGF0ZSBhbnkgcGFydCBvZiB0aGUgQ29B UCBwYXlsb2FkIGFuZA0KPj4gbWV0YWRhdGEgaW4gdHJhbnNpdCBiZXR3ZWVuIGNsaWVudCBhbmQg c2VydmVyIHdpdGhvdXQgYmVpbmcgcHJvdGVjdGVkIG9yDQo+PiBkZXRlY3RlZCBieSBEVExTLg0K Pj4gDQo+PiANCj4+IE9uZSB3YXkgdG8gbWl0aWdhdGUgdGhpcyB0aHJlYXQgaXMgdG8gY29tcGxl bWVudCBvciByZXBsYWNlIERUTFMgd2l0aA0KPj4gYXBwbGljYXRpb24gbGF5ZXIgcHJvdGVjdGlv biBvZiBDb0FQIHBheWxvYWQgYW5kIG1ldGFkYXRhIGJldHdlZW4NCj4+Y2xpZW50IGFuZA0KPj4g c2VydmVyIGZvciB0aGUgdXNlIGNhc2VzIHdoZXJlIHRoZSBwcm94eSBzaG91bGQgbm90IGJlIGZ1 bGx5IHRydXN0ZWQuDQo+PiBUaGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBpbiB0aGUgQ29SRSBXRyBt ZWV0aW5ncyBkdXJpbmcgdGhlIHRocmVlIGxhc3QNCj4+SUVURiBGMkYNCj4+IG1lZXRpbmdzIGFu ZCB0aGVyZSBhcmUgZHJhZnQgc29sdXRpb25zIHVzaW5nIHRoZSBtZXNzYWdlIGZvcm1hdCBiZWlu Zw0KPj4gZGV2ZWxvcGVkIGluIHRoZSBDT1NFIFdHLg0KPj4gDQo+PiANCj4+IFdpdGggdGhlIENP QVAgcHJveHkgb3BlcmF0aW9ucyBzdGFuZGFyZGl6ZWQgc28gZmFyIGl0IGhhcyBiZWVuIHBvc3Np YmxlDQo+PnRvDQo+PiBwcm90ZWN0IHRoZSBDb0FQIG1lc3NhZ2VzIGFkZXF1YXRlbHkgd2l0aCBz ZWN1cml0eSBvbiB0cmFuc3BvcnQgbGF5ZXIsDQo+PiBhcHBsaWNhdGlvbiBsYXllciBvciBhIGNv bWJpbmF0aW9uIHRoZXJlb2YuIEluIHRoZSBjYXNlIHdoZXJlIHRoZQ0KPj5sZWdpdGltYXRlDQo+ PiBwcm94eSBvcGVyYXRpb24gaXMgcHJlZGljdGFibGUgYnkgY2xpZW50IGFuZCBzZXJ2ZXIsIGFw cGxpY2F0aW9uIGxheWVyDQo+PnNlY3VyaXR5IGNhbg0KPj4gYmUgZGVmaW5lZCB0byBib3RoIHZl cmlmeSB0aGF0IG5vIGlsbGVnaXRpbWF0ZSBjaGFuZ2VzIGhhcyBiZWVuDQo+PnBlcmZvcm1lZCBh cw0KPj4gd2VsbCBhcyB2ZXJpZnlpbmcgdGhlIGxlZ2l0aW1hdGUgY2hhbmdlcy4gSW4gdGhlIGNh c2Ugd2hlcmUgcHJveHkNCj4+b3BlcmF0aW9ucyBhcmUNCj4+IG5vdCBwcmVkaWN0YWJsZSDigJQg ZXZlbiBpZiB0aGUgZGF0YSB0aGUgcHJveHkgaXMgb3BlcmF0aW5nIG9uIGNhbm5vdCBiZQ0KPj5w cm90ZWN0ZWQNCj4+IOKAlCBpdCBoYXMgc28gZmFyIGJlZW4gcG9zc2libGUgdG8gdXNlIG90aGVy IGluZm9ybWF0aW9uIGVsZW1lbnRzIHRvDQo+PnByb3ZpZGUgdGhlDQo+PiByZXF1aXJlZCBlbmQt dG8tZW5kIHNlY3VyaXR5IHByb3Blcml0aWVzLiAgRm9yIGV4YW1wbGUsIHRoZSBDb0FQIGhlYWRl cg0KPj5maWVsZA0KPj4gVG9rZW4gbWF5IGJlIGNoYW5nZWQgYnkgYSBwcm94eSwgYnV0IGluc3Rl YWQgYSB0cmFuc2FjdGlvbiBpZGVudGlmaWVyDQo+PmNhbiBiZQ0KPj4gaW50cm9kdWNlZCBpbiB0 aGUgYXBwbGljYXRpb24gc2VjdXJpdHkgd3JhcHBlciAoQ09TRQ0KPj4gaGVhZGVyKSB0byBkZWZp bmUgYSBtZXNzYWdlIChleGNoYW5nZSkgaWRlbnRpZmllciBjb21tb24gdG8gY2xpZW50IGFuZA0K Pj5zZXJ2ZXIuDQo+PiANCj4+IA0KPj4gQmxvY2t3aXNlOg0KPj4gDQo+PiBXaXRoIHRoZSBkZWZp bml0aW9uIG9mIGJsb2Nrd2lzZSB0cmFuc2ZlciBhcyBzcGVjaWZpZWQgaW4gdGhpcyBkcmFmdCBh DQo+PnByb3h5IG1heQ0KPj4gcGFydGl0aW9uIG9yIHJlLXBhcnRpdGlvbmluZyBhIG1lc3NhZ2Ug aW50byBibG9ja3Mgd2hlcmUgdGhlIHNpemUgb2YNCj4+dGhlIGJsb2Nrcw0KPj4gYXJlIGRlY2lk ZWQgYnkgdGhlIHByb3h5LiBBcyBhIGNvbnNlcXVlbmNlLCBpdCBpcyBub3QgcG9zc2libGUgdG8N Cj4+aW50ZWdyaXR5IHByb3RlY3QNCj4+IGluZGl2aWR1YWwgYmxvY2tzIGVuZC10by1lbmQgYmV0 d2VlbiBjbGllbnQgYW5kIHNlcnZlcjogRFRMUyBkb2VzIG5vdA0KPj5wcm90ZWN0DQo+PiB0aGUg bWVzc2FnZSBkYXRhIHdpdGhpbiB0aGUgcHJveHksIGFuZCBhcHBsaWNhdGlvbiBsYXllciBpbnRl Z3JpdHkNCj4+cHJvdGVjdGlvbiBvZg0KPj4gaW5kaXZpZHVhbCBibG9ja3MgY2Fubm90IGJlIHBl cmZvcm1lZCB1bmxlc3MgdGhlIHBhcnRpdGlvbmluZyBpbnRvDQo+PmJsb2NrcyBhcw0KPj4gcmVj ZWl2ZWQgYnkgb25lIGVuZHBvaW50IGlzIGlkZW50aWNhbCB0byB0aGF0IHNlbnQgYnkgdGhlIG90 aGVyDQo+PmVuZHBvaW50LiBIZW5jZSwNCj4+IHdoZW4gQ29BUCBCbG9jayBvcHRpb25zIGFyZSB1 c2VkIGFzIGRlZmluZWQgaW4gdGhpcyBkcmFmdCwgZW5kLXRvLWVuZA0KPj5zZWN1cml0eQ0KPj4g b2YgdGhlIGluZGl2aWR1YWwgQ29BUCByZXF1ZXN0IGFuZCByZXNwb25zZSBicmVha3MgZG93bi4g Rm9yIGV4YW1wbGU6IGENCj4+cHJveHkNCj4+IG1heSBhZGRCbG9jayBvcHRpb25zLCBzZW5kIGFu eSBudW1iZXIgb2YgYmxvY2tzIHdpdGggYW55IHBheWxvYWQgdG8gYW4NCj4+IGVuZHBvaW50IHdp dGhvdXQgYmVpbmcgcG9zc2libGUgdG8gZGV0ZWN0IG9yIHByb3RlY3QgYWdhaW5zdC4gSW4NCj4+ Y29udHJhc3QgdG8gdGhlDQo+PiBleGlzdGluZyBzdGFuZGFyZHMgaW4gdGhlIENvQVAgc3VpdGUs IGluIHRoaXMgY2FzZSBpdCBpcyBub3QgcG9zc2libGUNCj4+dG8gYnlwYXNzIHRoZQ0KPj4gY29u c3RydWN0aW9uIGFuZCBkZWZpbmUgYSBzZWN1cmUgZW5kLXRvLWVuZCBibG9jayBwYXJ0aXRpb25p bmcgd2l0aA0KPj5sZXNzIHRoYW4NCj4+IGRpc2FibGluZyBibG9jayBwYXJ0aXRpb25pbmcgYXMg c3BlY2lmaWVkIGluIHRoaXMgZHJhZnQuDQo+PiANCj4+IA0KPj4gT25lIHNvbHV0aW9uIHRvIHRo aXMgaXMgdG8gZGlzYWxsb3cgcHJveGllcyB0byByZS1wYXJ0aXRpb24gYSBtZXNzYWdlLA0KPj50 aHVzDQo+PiByZWRlZmluZSB0aGUgQmxvY2sgb3B0aW9ucyBzdWNoIHRoYXQgdGhleSBhcmUgcG9z c2libGUgdG8gaW50ZWdyaXR5DQo+PnByb3RlY3QgZW5kLQ0KPj4gdG8tZW5kLiAgSW50ZWdyaXR5 IHByb3RlY3RpbmcgZWFjaCBibG9jayBhbmQgY29ycmVzcG9uZGluZyBCbG9jaw0KPj5vcHRpb25z IGFzDQo+PiBkZWZpbmVkIGluIHRoZSBjdXJyZW50IGRyYWZ0IGhhcyBhZGRpdGlvbmFsIGJlbmVm aXRzOiBJZiBhbnkgYmxvY2sgaW4NCj4+dGhlIHNlcXVlbmNlDQo+PiBmYWlscyB2ZXJpZmljYXRp b24sIGl0IGNhbiBiZSBpbmRpdmlkdWFsbHkgcmVxdWVzdGVkIHRvIGJlIHJlc2VudC4gV2hlbg0K Pj5hbGwgYmxvY2tzDQo+PiBoYXMgYmVlbiB2ZXJpZmllZCB0aGUgZW50aXJlIG1lc3NhZ2UgaGFz IGJlZW4gdmVyaWZpZWQuICBBIHJlY2VpdmluZw0KPj5ub2RlIG1heQ0KPj4gZXZlbiBwZXJmb3Jt IGNlcnRhaW4gYWN0aW9ucyBiYXNlZCBvbiByZWNlaXZlZCB2ZXJpZmllZCBibG9ja3MgYmVmb3Jl DQo+PnRoZSBlbnRpcmUNCj4+IG1lc3NhZ2UgaGFzIGJlZW4gcmVjZWl2ZWQuDQo+PiANCj4+IA0K Pj4gSW5zdGVhZCBvZiBkZWxlZ2F0aW5nIHRvIHByb3hpZXMgdG8gcGFydGl0aW9uIGludG8gYmxv Y2tzLCB0aGUgc2VuZGluZw0KPj5lbmRwb2ludA0KPj4gd291bGQgbmVlZCB0byBhbnRpY2lwYXRl IG9yIGdldCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgcmVsZXZhbnQgYmxvY2sNCj4+c2l6ZSwgZS5n Lg0KPj4gdXNpbmcgYSBzaXplIGluZGljYXRpb24gaW4gdGhlIGxpbmstZm9ybWF0IGRlc2NyaXB0 aW9uIFtSRkM2OTkwXS4NCj4+QWRkaXRpb25hbA0KPj4gbWV0aG9kcyBmb3IgYmxvY2tzaXplIGRp c2NvdmVyeSBtYXkgYWxzbyBiZSBkZWZpbmVkLg0KPj4gV2hpbGUgdGhpcyBtYXkgbm90IGJlIGFz IHNpbXBsZSBhcyBsZWF2aW5nIGl0IGVudGlyZWx5IHRvIHRoZSBwcm94eSB0bw0KPj5kZWNpZGUs DQo+PiBjb25zaWRlcmluZyB0aGUgYWRkaXRpb25hbCBzZWN1cml0eSBiZW5lZml0cyBJIGJlbGll dmUgdGhpcyBpcyB0aGUNCj4+cmlnaHQgdHJhZGUgb2ZmIHRvDQo+PiBtYWtlLg0KPj4gDQo+PiAN Cj4+IEFuIGFsdGVybmF0aXZlIHNvbHV0aW9uIGlzIHRvIHByZXZlbnQgcHJveGllcyBmcm9tIHJl LXBhcnRpdGlvbmluZyBhDQo+Pm1lc3NhZ2Ugb25seQ0KPj4gaW4gdGhlIGNhc2Ugd2hlcmUgZW5k LXRvLWVuZCBzZWN1cml0eSBvZiBDb0FQIG1lc3NhZ2UgaXMgYXBwbGllZCwgd2hpY2gNCj4+aW4N Cj4+IGN1cnJlbnQgc29sdXRpb24gcHJvcG9zYWxzIGlzIGluZGljYXRlZCB3aXRoIHRoZSBwcmVz ZW5jZSBvZiBhIGNlcnRhaW4NCj4+Q29BUA0KPj4gb3B0aW9uIFggKHdoaWNoIGUuZy4gY29udGFp bnMgdGhlIENPU0Ugb2JqZWN0KS4NCj4+IFRoaXMgd291bGQgaGF2ZSB0aGUgc2FtZSBiZW5lZml0 cyBhcyB0aGUgcHJldmlvdXMgc29sdXRpb24sIGJ1dA0KPj5yZXF1aXJlcyB0aGUNCj4+IGNvZGUg aW4gdGhlIHByb3h5IGltcGxlbWVudGluZyB0aGlzIGRyYWZ0IHRvIGJlIGF3YXJlIG9mIG9wdGlv biBYLCBhbmQNCj4+aGVuY2UNCj4+IHRoYXQgZGVwZW5kZW5jeSBuZWVkcyB0byBiZSBzcGVjaWZp ZWQgaW4gdGhpcyBkcmFmdC4gQW5kIG9wdGlvbiBYIGlzIG5vdA0KPj4gc3RhbmRhcmRpemVkIHll dCwgc28gd291bGQgcmVxdWlyZSBpbnRyb2R1Y2luZyBhIHBsYWNlaG9sZGVyLg0KPj4gDQo+PiAN Cj4+IFRoZXJlIGFyZSBvdGhlciBhbHRlcm5hdGl2ZXMgYXMgd2VsbCBidXQgdGhpcyBlLW1haWwg aXMgYWxyZWFkeSB0b28NCj4+bG9uZy4NCj4+IFRoZSBtYWluIHBvaW50IEkgd2FudGVkIHRvIG1h a2UgaXMgdGhhdCBnaXZlbiB0aGF0IHdlIG5vdyBoYXZlIGEgYmV0dGVyDQo+PiB1bmRlcnN0YW5k aW5nIG9mIGhvdyB0byBhY2hpZXZlIHNlY3VyaXR5IGJldHdlZW4gY2xpZW50IGFuZCBzZXJ2ZXIN Cj4+dGhyb3VnaA0KPj4gcHJveGllcyBjb21wYXJlZCB0byB3aGVuIFJGQzcyNTIgd2FzIHdyaXR0 ZW4sIG15IG9waW5vbiBpcyB0aGF0IHdlDQo+PnNob3VsZA0KPj4gbm90IGlnbm9yZSB0aGVzZSBz ZWN1cml0eSBpc3N1ZXMgaW4gbmV3IHN0YW5kYXJkcy4NCj4+IA0KPj4gDQo+PiANCj4+IEfDtnJh bg0KPj4gDQo+PiANCj4+IA0KPj4gT24gMjAxNS0xMS0yMCAyMjozMiwgIlRoZSBJRVNHIiA8aWVz Zy1zZWNyZXRhcnlAaWV0Zi5vcmc+IHdyb3RlOg0KPj4gDQo+PiA+DQo+PiA+VGhlIElFU0cgaGFz IHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBDb25zdHJhaW5lZCBSRVNUZnVsDQo+PiA+RW52 aXJvbm1lbnRzIFdHIChjb3JlKSB0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0K Pj4gPi0gJ0Jsb2NrLXdpc2UgdHJhbnNmZXJzIGluIENvQVAnDQo+PiA+ICA8ZHJhZnQtaWV0Zi1j b3JlLWJsb2NrLTE4LnR4dD4gYXMgUHJvcG9zZWQgU3RhbmRhcmQNCj4+ID4NCj4+ID5UaGUgSUVT RyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29s aWNpdHMNCj4+ID5maW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vi c3RhbnRpdmUgY29tbWVudHMgdG8gdGhlDQo+PiA+aWV0ZkBpZXRmLm9yZyBtYWlsaW5nIGxpc3Rz IGJ5IDIwMTUtMTItMDQuIEV4Y2VwdGlvbmFsbHksIGNvbW1lbnRzIG1heQ0KPj4gPmJlIHNlbnQg dG8gaWVzZ0BpZXRmLm9yZyBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJldGFpbiB0 aGUNCj4+ID5iZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQg c29ydGluZy4NCj4+ID4NCj4+ID5BYnN0cmFjdA0KPj4gPg0KPj4gPg0KPj4gPiAgIENvQVAgaXMg YSBSRVNUZnVsIHRyYW5zZmVyIHByb3RvY29sIGZvciBjb25zdHJhaW5lZCBub2RlcyBhbmQNCj4+ ID4gICBuZXR3b3Jrcy4gIEJhc2ljIENvQVAgbWVzc2FnZXMgd29yayB3ZWxsIGZvciB0aGUgc21h bGwgcGF5bG9hZHMgd2UNCj4+ID4gICBleHBlY3QgZnJvbSB0ZW1wZXJhdHVyZSBzZW5zb3JzLCBs aWdodCBzd2l0Y2hlcywgYW5kIHNpbWlsYXINCj4+ID4gICBidWlsZGluZy1hdXRvbWF0aW9uIGRl dmljZXMuICBPY2Nhc2lvbmFsbHksIGhvd2V2ZXIsIGFwcGxpY2F0aW9ucw0KPj4gPiAgIHdpbGwg bmVlZCB0byB0cmFuc2ZlciBsYXJnZXIgcGF5bG9hZHMgLS0gZm9yIGluc3RhbmNlLCBmb3IgZmly bXdhcmUNCj4+ID4gICB1cGRhdGVzLiAgV2l0aCBIVFRQLCBUQ1AgZG9lcyB0aGUgZ3J1bnQgd29y ayBvZiBzbGljaW5nIGxhcmdlDQo+PiA+ICAgcGF5bG9hZHMgdXAgaW50byBtdWx0aXBsZSBwYWNr ZXRzIGFuZCBlbnN1cmluZyB0aGF0IHRoZXkgYWxsIGFycml2ZQ0KPj4gPiAgIGFuZCBhcmUgaGFu ZGxlZCBpbiB0aGUgcmlnaHQgb3JkZXIuDQo+PiA+DQo+PiA+ICAgQ29BUCBpcyBiYXNlZCBvbiBk YXRhZ3JhbSB0cmFuc3BvcnRzIHN1Y2ggYXMgVURQIG9yIERUTFMsIHdoaWNoDQo+PiA+ICAgbGlt aXRzIHRoZSBtYXhpbXVtIHNpemUgb2YgcmVzb3VyY2UgcmVwcmVzZW50YXRpb25zIHRoYXQgY2Fu IGJlDQo+PiA+ICAgdHJhbnNmZXJyZWQgd2l0aG91dCB0b28gbXVjaCBmcmFnbWVudGF0aW9uLiAg QWx0aG91Z2ggVURQIHN1cHBvcnRzDQo+PiA+ICAgbGFyZ2VyIHBheWxvYWRzIHRocm91Z2ggSVAg ZnJhZ21lbnRhdGlvbiwgaXQgaXMgbGltaXRlZCB0byA2NCBLaUINCj4+ID4gICBhbmQsIG1vcmUg aW1wb3J0YW50bHksIGRvZXNuJ3QgcmVhbGx5IHdvcmsgd2VsbCBmb3IgY29uc3RyYWluZWQNCj4+ ID4gICBhcHBsaWNhdGlvbnMgYW5kIG5ldHdvcmtzLg0KPj4gPg0KPj4gPiAgIEluc3RlYWQgb2Yg cmVseWluZyBvbiBJUCBmcmFnbWVudGF0aW9uLCB0aGlzIHNwZWNpZmljYXRpb24gZXh0ZW5kcw0K Pj4gPiAgIGJhc2ljIENvQVAgd2l0aCBhIHBhaXIgb2YgIkJsb2NrIiBvcHRpb25zLCBmb3IgdHJh bnNmZXJyaW5nIG11bHRpcGxlDQo+PiA+ICAgYmxvY2tzIG9mIGluZm9ybWF0aW9uIGZyb20gYSBy ZXNvdXJjZSByZXByZXNlbnRhdGlvbiBpbiBtdWx0aXBsZQ0KPj4gPiAgIHJlcXVlc3QtcmVzcG9u c2UgcGFpcnMuICBJbiBtYW55IGltcG9ydGFudCBjYXNlcywgdGhlIEJsb2NrIG9wdGlvbnMNCj4+ ID4gICBlbmFibGUgYSBzZXJ2ZXIgdG8gYmUgdHJ1bHkgc3RhdGVsZXNzOiB0aGUgc2VydmVyIGNh biBoYW5kbGUgZWFjaA0KPj4gPiAgIGJsb2NrIHRyYW5zZmVyIHNlcGFyYXRlbHksIHdpdGggbm8g bmVlZCBmb3IgYSBjb25uZWN0aW9uIHNldHVwIG9yDQo+PiA+ICAgb3RoZXIgc2VydmVyLXNpZGUg bWVtb3J5IG9mIHByZXZpb3VzIGJsb2NrIHRyYW5zZmVycy4NCj4+ID4NCj4+ID4gICBJbiBzdW1t YXJ5LCB0aGUgQmxvY2sgb3B0aW9ucyBwcm92aWRlIGEgbWluaW1hbCB3YXkgdG8gdHJhbnNmZXIN Cj4+ID4gICBsYXJnZXIgcmVwcmVzZW50YXRpb25zIGluIGEgYmxvY2std2lzZSBmYXNoaW9uLg0K Pj4gPg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPlRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWEN Cj4+ID5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvcmUtYmxv Y2svDQo+PiA+DQo+PiA+SUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KPj4gPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS1ibG9jay9iYWxs b3QvDQo+PiA+DQo+PiA+DQo+PiA+Tm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3VibWl0 dGVkIGRpcmVjdGx5IG9uIHRoaXMgSS1ELg0KPj4gPg0KPj4gPg0KPj4gDQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gY29yZSBtYWlsaW5nIGxp c3QNCj4+IGNvcmVAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY29yZQ0KPg0KDQo= From nobody Mon Feb 1 12:31:43 2016 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 E2B6B1B3629; Mon, 1 Feb 2016 12:31:37 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 aSfDdXVXKa9p; Mon, 1 Feb 2016 12:31:34 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C061B3628; Mon, 1 Feb 2016 12:31:34 -0800 (PST) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id DC8BA38F00; Mon, 1 Feb 2016 12:31:32 -0800 (PST) From: "Jim Schaad" To: =?UTF-8?Q?'G=C3=B6ran_Selander'?= , References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com> <063a01d15a22$24099250$6c1cb6f0$@augustcellars.com> In-Reply-To: Date: Mon, 1 Feb 2016 12:28:59 -0800 Message-ID: <00d701d15d2f$2f849840$8e8dc8c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQH/N40dZG+wyPslqrIqOShIBqjspwKyJuasAbm/U5kCBtFh256IVemQ Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, barryleiba@gmail.com, core@ietf.org Subject: Re: [core] Last Call: (Block-wise transfers in CoAP) to Proposed Standard 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, 01 Feb 2016 20:31:38 -0000 G=C3=B6ran, You apparently have missed the main point of what I was saying in my = message. I see both of these cases as having a single message to be protected: 1. I am sending a small message that does not get fragmented 2. I am sending a large message that needs to be fragmented into 5 = messages using the Block-wise transfer options. In both cases I am doing an integrity protection/encryption operation on = a single message that might later be fragmented into multiple pieces. I = do not want to integrity protect each of the 5 block transfer messages = independently because of a number of problems which you have pointed out = about messages getting re-fragmented in transit. Additionally, I do not = want to deal with each messages separately because I do not want to be = in a situation where a block could be changed for a different block from = a different stream. This would be the case of sending A1 A2 A3 A4 and receiving A1 A2 B3 A4 = where each of the fragments individually verifies, but the entire stream = has been changed. Doing a single integrity operation over the entire = stream of (A1 A2 A3 A4) means that receiving (A1 A2 B3 A4) would fail to = validate because the entire stream of bytes would fail validation. This means that I treat security identically if the block options are = there or if the block options are not there. There are other discussions that need to be dealt with about options and = how they interact with security, but the report of the group working on = this has not yet come up for review. I am just worried about getting = this draft finished. jim > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Monday, February 01, 2016 12:20 AM > To: Jim Schaad ; ietf@ietf.org > Cc: draft-ietf-core-block@ietf.org; core-chairs@ietf.org; = core@ietf.org; > barryleiba@gmail.com > Subject: Re: [core] Last Call: = (Block-wise transfers > in CoAP) to Proposed Standard >=20 > Hi Jim >=20 > Thanks for picking up the thread. >=20 > We spent some time in Prague thinking about this. You are right that = there are > different options with different characteristics. Here are the cases = we have > considered. >=20 > Just to recap the objective, this is about protecting communication = between > CoAP client and CoAP server while allowing legitimate operations of = one or > more intermediary CoAP proxies. Client and server are assumed to have = a > security association. >=20 > On a high level the candidate solutions are either built entirely on = top of CoAP or > add new CoAP options. >=20 > Looking at the former first, one solution is to wrap just the CoAP > payload/content, e.g. using COSE [1]. (We called this object security = of content, > OSCON). This is useful if the payload includes certain meta data, like = in the case > of CWT, or if certain information, such as resource identifier etc., = is implicit > from the security association. >=20 > This solution however does not protect the metadata sent in the CoAP = message, > such as e.g. Code (GET/DELETE/etc), Uri-Path or Content Format. > Even if such information would be integrity protected, e.g. using = External-AAD in > [1], it neither protects messages which do not have payload, like e.g. = GET > requests, nor does it address confidentiality desirable for a subset = of such > metadata for privacy reasons. >=20 > An alternative solution on top of CoAP is to move the RESTful protocol = out of > CoAP and only use POST with some dummy Uri-Path, Content Format etc. = In this > way all messages could carry a protected object as in [1] and the = nature of the > interaction and content is contained in this object. This is probably = violating the > purpose of CoAP too much to be of any interest. >=20 > Those are the only solutions we have considered on top of CoAP. I'm = not sure if > the solution you propose is related to one of these? >=20 > All other solutions I'm aware of which address the general problem = space, e.g. > OSCOAP, are built "within" CoAP, using CoAP options to carry protected = objects > (such as [1]) which include integrity protection of the payload and = meta-data. > Now, what happens if the payload is large? If the originating endpoint = does the > fragmentation then the destination endpoint can verify the integrity. = If a proxy > using the blockwise draft (re-)fragments the payload (which also = changes a > Block option) such that it is different when reaching the destination = endpoint, > then integrity verification will fail. The destination endpoint cannot = distinguish a > legitimate introduction/change of payload and Block option from any = other > change of the message, hence it cannot verify integrity. This can be = used to > disable integrity protection at CoAP layer also for shorter messages, = since the > destination endpoint must treat the existence of a Block option as a = generic > "security off" button. >=20 > This is quite different from the CoAP options standardized so far = where you can > protect individual messages between client and server at the same time = as > allowing legitimate proxy operation, even verifying that intermediate = nodes has > performed the correct CoAP option manipulations such as e.g. when = forward > proxies change the Uri-* options making the message reach the correct > destination URI. >=20 > IMHO CoAP should not allow an intermediate device to legitimately turn = off > integrity protecting between client and server. CoAP should definitely = support > integrity protection of short messages between client and server = through > proxies. This is where CoAP shines brightly. Given that, it is = straightforward to > integrity protect messages fragmented at the endpoints. > And with the Block options integrity protected the entire message = built up of the > fragments is automatically protected as well. >=20 > G=C3=B6ran >=20 > [1] https://tools.ietf.org/html/draft-ietf-cose-msg >=20 >=20 >=20 >=20 >=20 > On 2016-01-29 00:18, "Jim Schaad" wrote: >=20 > >G=C3=B6ran, > > > >I finally got caught up on reading the CORE mailing list (lots of > >boredom on issues I don=E2=80=99t think I care about) and I did not = find any > >responses to your mail on this issue. I would like to propose a > >different solution to the problem which I think you will find both > >workable and potential not requiring any updates to the current = draft. > > > >When I read this draft the first time, I read it as a network > >fragmentation draft rather than as a messaging draft. As such I did > >not have the same concerns about object security as you seem to have. > >I made the decision that I would apply the security to the entirety = of > >the message being sent, and then fragment it into blocks afterwards. > >Such an approach allows for a number of things that you are having > >problems with to be ignored. > > > >How the fragmentation is done, is change or is removed become > >immaterial as the end recipient would need to have all of the = fragments > >delivered and in the correct order in order to process the message = and > >do validation. > > > >Overhead is smaller because the overhead of encrypting/signing at the > >object security level is done once rather than once per fragment. = This > >allows for fewer bytes to be sent across the wire. > > > >The headers of the first message in the fragment are the ones that = the > >object security system would be using both for security calculation > >purposes and for the receiver to process the validated message. > > > >There are still some question that potentially need to be dealt with: > > > >1) Are the block option headers authenticated? The probable answer > >should be no as they are designed to be changed by intermediaries. > >This can be deferred until the general discussion about the rest of = the > >current headers. > > > >2) What options are required to be copied forward into subsequent > >messages and which can be omitted? I was unable to find any guidance > >on this issue from reading the document and thus would naively make = the > >assumption that all options not specified by this document are copied > >forward and should be checked to make sure that they are unchanged in > >future messages. However I doubt that is the desire of the authors. > >This however is not a security specific issue and needs to be = addressed > >in this document. > > > >3) Do we want to apply per message security as well - that is an = issue > >that can and should be punted to a future object security draft. > >However, I don't see the point except to protect the ACK/NACK or lack > >of on each individual hop. But this is point-to-point not = end-to-end. > > > >Jim > > > > > > > >> -----Original Message----- > >> From: core [mailto:core-bounces@ietf.org] On Behalf Of G=C3=B6ran = Selander > >> Sent: Wednesday, November 25, 2015 11:07 PM > >> To: ietf@ietf.org > >> Cc: draft-ietf-core-block@ietf.org; core-chairs@ietf.org; > >>core@ietf.org; barryleiba@gmail.com > >> Subject: Re: [core] Last Call: > >>(Block-wise transfers in CoAP) to Proposed Standard > >> > >> > >> > >> There was a thread on the CoRE WG mailing list a couple of months = ago > >>on the topic of blockwise and object security. The starting point = was > >>a question if CoAP proxies can (re-)partition messages into blocks = as > >>defined in this draft, and the implications on end-to-end security > >>between client and server through such a proxy. The conclusions of > >>that discussion has an impact on this draft, but there are no > >>considerations of this kind made in version -18. More details are > >>given below, including some alternative proposals for how to = address > >>this. > >>Apologies > >> for the long e-mail. > >> > >> > >> Background: > >> > >> There is an ongoing discussion in CoRE and ACE WGs since a year on > >>the > >>end-to- > >> end security properties of CoAP, i.e. protecting the communication > >>between a client and a server through proxies. RFC 7252 and other > >>specifications in the CoAP suite define a set of legitimate proxy > >>operations on CoAP messages which requires DTLS to be terminated at > >>proxies. This implies that the proxy has access not only with the > >>data required for perform the intended proxy operation but is also > >>able to eavesdrop or manipulate any part of the CoAP payload and > >>metadata in transit between client and server without being = protected > >>or detected by DTLS. > >> > >> > >> One way to mitigate this threat is to complement or replace DTLS = with > >>application layer protection of CoAP payload and metadata between > >>client and server for the use cases where the proxy should not be > >>fully trusted. > >> This has been discussed in the CoRE WG meetings during the three = last > >>IETF F2F meetings and there are draft solutions using the message > >>format being developed in the COSE WG. > >> > >> > >> With the COAP proxy operations standardized so far it has been > >>possible to protect the CoAP messages adequately with security on > >>transport layer, application layer or a combination thereof. In the > >>case where the legitimate proxy operation is predictable by client > >>and server, application layer security can be defined to both = verify > >>that no illegitimate changes has been performed as well as = verifying > >>the legitimate changes. In the case where proxy operations are not > >>predictable =E2=80=94 even if the data the proxy is operating on = cannot be > >>protected =E2=80=94 it has so far been possible to use other = information > >>elements to provide the required end-to-end security properities. > >>For example, the CoAP header field Token may be changed by a proxy, > >>but instead a transaction identifier can be introduced in the > >>application security wrapper (COSE > >> header) to define a message (exchange) identifier common to client > >>and server. > >> > >> > >> Blockwise: > >> > >> With the definition of blockwise transfer as specified in this = draft > >>a proxy may partition or re-partitioning a message into blocks = where > >>the size of the blocks are decided by the proxy. As a consequence, = it > >>is not possible to integrity protect individual blocks end-to-end > >>between client and server: DTLS does not protect the message data > >>within the proxy, and application layer integrity protection of > >>individual blocks cannot be performed unless the partitioning into > >>blocks as received by one endpoint is identical to that sent by the > >>other endpoint. Hence, when CoAP Block options are used as defined = in > >>this draft, end-to-end security of the individual CoAP request and > >>response breaks down. For example: a proxy may addBlock options, = send > >>any number of blocks with any payload to an endpoint without being > >>possible to detect or protect against. In contrast to the existing > >>standards in the CoAP suite, in this case it is not possible to = bypass > >>the construction and define a secure end-to-end block partitioning > >>with less than disabling block partitioning as specified in this > >>draft. > >> > >> > >> One solution to this is to disallow proxies to re-partition a > >>message, thus redefine the Block options such that they are = possible > >>to integrity protect end- to-end. Integrity protecting each block > >>and corresponding Block options as defined in the current draft has > >>additional benefits: If any block in the sequence fails = verification, > >>it can be individually requested to be resent. When all blocks has > >>been verified the entire message has been verified. A receiving = node > >>may even perform certain actions based on received verified blocks > >>before the entire message has been received. > >> > >> > >> Instead of delegating to proxies to partition into blocks, the = sending > >>endpoint > >> would need to anticipate or get information about the relevant = block > >>size, e.g. > >> using a size indication in the link-format description [RFC6990]. > >>Additional > >> methods for blocksize discovery may also be defined. > >> While this may not be as simple as leaving it entirely to the proxy = to > >>decide, > >> considering the additional security benefits I believe this is the > >>right trade off to > >> make. > >> > >> > >> An alternative solution is to prevent proxies from re-partitioning = a > >>message only > >> in the case where end-to-end security of CoAP message is applied, = which > >>in > >> current solution proposals is indicated with the presence of a = certain > >>CoAP > >> option X (which e.g. contains the COSE object). > >> This would have the same benefits as the previous solution, but > >>requires the > >> code in the proxy implementing this draft to be aware of option X, = and > >>hence > >> that dependency needs to be specified in this draft. And option X = is not > >> standardized yet, so would require introducing a placeholder. > >> > >> > >> There are other alternatives as well but this e-mail is already too > >>long. > >> The main point I wanted to make is that given that we now have a = better > >> understanding of how to achieve security between client and server > >>through > >> proxies compared to when RFC7252 was written, my opinon is that we > >>should > >> not ignore these security issues in new standards. > >> > >> > >> > >> G=C3=B6ran > >> > >> > >> > >> On 2015-11-20 22:32, "The IESG" wrote: > >> > >> > > >> >The IESG has received a request from the Constrained RESTful > >> >Environments WG (core) to consider the following document: > >> >- 'Block-wise transfers in CoAP' > >> > as Proposed Standard > >> > > >> >The IESG plans to make a decision in the next few weeks, and = solicits > >> >final comments on this action. Please send substantive comments to = the > >> >ietf@ietf.org mailing lists by 2015-12-04. Exceptionally, comments = may > >> >be sent to iesg@ietf.org instead. In either case, please retain = the > >> >beginning of the Subject line to allow automated sorting. > >> > > >> >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 file can be obtained via > >> >https://datatracker.ietf.org/doc/draft-ietf-core-block/ > >> > > >> >IESG discussion can be tracked via > >> >https://datatracker.ietf.org/doc/draft-ietf-core-block/ballot/ > >> > > >> > > >> >No IPR declarations have been submitted directly on this I-D. > >> > > >> > > >> > >> _______________________________________________ > >> core mailing list > >> core@ietf.org > >> https://www.ietf.org/mailman/listinfo/core > > From nobody Mon Feb 1 13:55:16 2016 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 24DB81B377B; Mon, 1 Feb 2016 13:55:13 -0800 (PST) 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 s-h_fCxWK4gQ; Mon, 1 Feb 2016 13:55:08 -0800 (PST) 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 814CF1B3770; Mon, 1 Feb 2016 13:55:06 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-80-56afd4381780 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4B.F5.02707.834DFA65; Mon, 1 Feb 2016 22:55:04 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.151]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0248.002; Mon, 1 Feb 2016 22:55:04 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "ietf@ietf.org" Thread-Topic: [core] Last Call: (Block-wise transfers in CoAP) to Proposed Standard Thread-Index: AQHRI9sb/ga71FS+3UKAe+rFI8Rp+56t6kEAgGQBhwCABV8vgIAAuuuAgAAozgA= Date: Mon, 1 Feb 2016 21:55:03 +0000 Message-ID: References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com> <063a01d15a22$24099250$6c1cb6f0$@augustcellars.com> <00d701d15d2f$2f849840$8e8dc8c0$@augustcellars.com> In-Reply-To: <00d701d15d2f$2f849840$8e8dc8c0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <7769EEE346022A4695B6CCA5F2223650@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGIsWRmVeSWpSXmKPExsUyM2K7t67FlfVhBo+2S1l8f36NxWLbxgts Fvverme2aDw0j9Fi9fTvbBbPNs5ncWDz2DhnOpvHzll32T2WLPnJFMAcxWWTkpqTWZZapG+X wJWx7dZp1oIdNxgret/fZ25g/HCJsYuRk0NCwERi1tmbbBC2mMSFe+vBbCGBw4wSbXuluxi5 gOzFjBIHGy6zgiTYBFwkHjQ8YgKxRQQ8JG49n8IKUsQscIJR4sH/w2AJYYFiia9tm9ghikok LpzeyAZh+0kcO9kHZrMIqEj83D+dBcTmFbCQOL3oAwvEtm4midtzTjKDJDgFHCSub58INogR 6Lzvp9aALWAWEJe49WQ+E8TZAhJL9pxnhrBFJV4+/gd0EQeHqICeRNeRCoiwksSi25+ZQMLM ApoS63fpQ0yxlvix5RfUREWJKd0P2SHOEZQ4OfMJywRGiVlIls1C6J6FpHsWku5ZSLoXMLKu YhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAiM3YNbfhvsYHz53PEQowAHoxIP74ei9WFCrIll xZW5hxglOJiVRHgDlgCFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8652BkoJpCeWpGanphakFsFk mTg4pRoY1z9x4TN+suzqR12O56qmzuzvXtzxSj1ycdfTb09LWJozji1d1bp+vcwq+31KAhp/ Z7HKNRVqHLkrHDQnuTDjTOxD5ey5d5+vYJv/wCuTJ3aD3MqqG/+6lm2bov1Pf5r/mlpt5yr9 33HxrOlHbG4YrQz7s883XEXsR5rGjh6571OnNDHf8+F1U2Ipzkg01GIuKk4EANQPmnfZAgAA Archived-At: Cc: "draft-ietf-core-block@ietf.org" , "core-chairs@ietf.org" , "barryleiba@gmail.com" , "core@ietf.org" Subject: Re: [core] Last Call: (Block-wise transfers in CoAP) to Proposed Standard 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, 01 Feb 2016 21:55:13 -0000 SmltLA0KDQpZZXMsIGFwcGFyZW50bHkgd2UgZG8gdGFsayBwYXN0IGVhY2ggb3RoZXIuIElubGlu ZS4NCg0KT24gMjAxNi0wMi0wMSAyMToyOCwgIkppbSBTY2hhYWQiIDxpZXRmQGF1Z3VzdGNlbGxh cnMuY29tPiB3cm90ZToNCg0KPkfDtnJhbiwNCj4NCj5Zb3UgYXBwYXJlbnRseSBoYXZlIG1pc3Nl ZCB0aGUgbWFpbiBwb2ludCBvZiB3aGF0IEkgd2FzIHNheWluZyBpbiBteQ0KPm1lc3NhZ2UuDQo+ DQo+SSBzZWUgYm90aCBvZiB0aGVzZSBjYXNlcyBhcyBoYXZpbmcgYSBzaW5nbGUgbWVzc2FnZSB0 byBiZSBwcm90ZWN0ZWQ6DQo+MS4gIEkgYW0gc2VuZGluZyBhIHNtYWxsIG1lc3NhZ2UgdGhhdCBk b2VzIG5vdCBnZXQgZnJhZ21lbnRlZA0KPjIuICBJIGFtIHNlbmRpbmcgYSBsYXJnZSBtZXNzYWdl IHRoYXQgbmVlZHMgdG8gYmUgZnJhZ21lbnRlZCBpbnRvIDUNCj5tZXNzYWdlcyB1c2luZyB0aGUg QmxvY2std2lzZSB0cmFuc2ZlciBvcHRpb25zLg0KPg0KPkluIGJvdGggY2FzZXMgSSBhbSBkb2lu ZyBhbiBpbnRlZ3JpdHkgcHJvdGVjdGlvbi9lbmNyeXB0aW9uIG9wZXJhdGlvbiBvbg0KPmEgc2lu Z2xlIG1lc3NhZ2UgdGhhdCBtaWdodCBsYXRlciBiZSBmcmFnbWVudGVkIGludG8gbXVsdGlwbGUg cGllY2VzLg0KDQpJIGRvbuKAmXQgdW5kZXJzdGFuZCBob3cgeW91ciBzb2x1dGlvbiBwcm90ZWN0 cyBDb0FQIG1ldGFkYXRhIGxpa2UgQ29kZSwNCkNvbnRlbnQtRm9ybWF0IGFuZCBVcmktUGF0aC4g SSBtYXkgYmUgd3JvbmcgYnV0IGl0IHNlZW1zIHlvdSBhcmUgb25seQ0KcHJvdGVjdGluZyBDb0FQ IHBheWxvYWQsIHdoaWNoIGlzIHN1ZmZpY2llbnQgZm9yIGNlcnRhaW4gdXNlIGNhc2VzLCBidXQN CmZvciBvdGhlciB1c2UgY2FzZXMgd2UgYWxzbyBuZWVkIHRvIHByb3RlY3QgbWV0YWRhdGEuIFRo ZSBibG9ja3dpc2UgZHJhZnQNCmFwcGxpZXMgdG8gYm90aCBraW5kIG9mIHVzZSBjYXNlcy4NCg0K DQo+IEkgZG8gbm90IHdhbnQgdG8gaW50ZWdyaXR5IHByb3RlY3QgZWFjaCBvZiB0aGUgNSBibG9j ayB0cmFuc2ZlciBtZXNzYWdlcw0KPmluZGVwZW5kZW50bHkgYmVjYXVzZSBvZiBhIG51bWJlciBv ZiBwcm9ibGVtcyB3aGljaCB5b3UgaGF2ZSBwb2ludGVkIG91dA0KPmFib3V0IG1lc3NhZ2VzIGdl dHRpbmcgcmUtZnJhZ21lbnRlZCBpbiB0cmFuc2l0Lg0KDQpNeSBwb2ludCBvZiB2aWV3IGlzIHRo YXQgbWVzc2FnZXMgc2hvdWxkIG5vdCBiZSByZS1mcmFnbWVudGVkIGluIHRyYW5zaXQuDQoNCj4g QWRkaXRpb25hbGx5LCBJIGRvIG5vdCB3YW50IHRvIGRlYWwgd2l0aCBlYWNoIG1lc3NhZ2VzIHNl cGFyYXRlbHkNCj5iZWNhdXNlIEkgZG8gbm90IHdhbnQgdG8gYmUgaW4gYSBzaXR1YXRpb24gd2hl cmUgYSBibG9jayBjb3VsZCBiZSBjaGFuZ2VkDQo+Zm9yIGEgZGlmZmVyZW50IGJsb2NrIGZyb20g YSBkaWZmZXJlbnQgc3RyZWFtLg0KDQpUaGlzIGlzIG5vdCBhbiBpc3N1ZSBpZiB5b3UgaW50ZWdy aXR5IHByb3RlY3QgdGhlIGFwcHJvcHJpYXRlIEJsb2NrDQpvcHRpb24sIHdoaWNoIGNvbnRhaW5z IHRoZSBudW1iZXIgb2YgdGhlIGJsb2NrIGFuZCBpZiBpdCBpcyB0aGUgbGFzdC4NClJlLWZyYWdt ZW50YXRpb24gcHJldmVudHMgQmxvY2sgb3B0aW9ucyBmcm9tIGJlaW5nIHBvc3NpYmxlIHRvIGlu dGVncml0eQ0KcHJvdGVjdCBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyLg0KDQo+DQo+VGhpcyB3 b3VsZCBiZSB0aGUgY2FzZSBvZiBzZW5kaW5nIEExIEEyIEEzIEE0IGFuZCByZWNlaXZpbmcgQTEg QTIgQjMgQTQNCj53aGVyZSBlYWNoIG9mIHRoZSBmcmFnbWVudHMgaW5kaXZpZHVhbGx5IHZlcmlm aWVzLCBidXQgdGhlIGVudGlyZSBzdHJlYW0NCj5oYXMgYmVlbiBjaGFuZ2VkLiAgRG9pbmcgYSBz aW5nbGUgaW50ZWdyaXR5IG9wZXJhdGlvbiBvdmVyIHRoZSBlbnRpcmUNCj5zdHJlYW0gb2YgKEEx IEEyIEEzIEE0KSBtZWFucyB0aGF0IHJlY2VpdmluZyAoQTEgQTIgQjMgQTQpIHdvdWxkIGZhaWwg dG8NCj52YWxpZGF0ZSBiZWNhdXNlIHRoZSBlbnRpcmUgc3RyZWFtIG9mIGJ5dGVzIHdvdWxkIGZh aWwgdmFsaWRhdGlvbi4NCg0KVGhpcyBpcyBub3QgYW4gaXNzdWUgaWYgeW91IGludGVncml0eSBw cm90ZWN0IHRoZSBhcHByb3ByaWF0ZSBCbG9jayBvcHRpb24uDQoNCg0KPg0KPlRoaXMgbWVhbnMg dGhhdCBJIHRyZWF0IHNlY3VyaXR5IGlkZW50aWNhbGx5IGlmIHRoZSBibG9jayBvcHRpb25zIGFy ZQ0KPnRoZXJlIG9yIGlmIHRoZSBibG9jayBvcHRpb25zIGFyZSBub3QgdGhlcmUuDQoNClllcywg c2luY2UgeW91IGZvY3VzIG9uIGFuIG92ZXItdGhlLXRvcCBzb2x1dGlvbiB5b3UgY2FuIGRvIHRo YXQuIEJ1dCB0aGUNCm9ubHkgb3Zlci10aGUtdG9wIHNvbHV0aW9uIEkga25vdyBvZiB0aGF0IHBy b3RlY3RzIG1ldGFkYXRhIGlzIHRoZSBvbmUNCm1lbnRpb25lZCBiZWxvdyB3aGljaCBtb3ZlcyBS RVNUIG91dCBvZiBDb0FQLg0KDQo+DQo+VGhlcmUgYXJlIG90aGVyIGRpc2N1c3Npb25zIHRoYXQg bmVlZCB0byBiZSBkZWFsdCB3aXRoIGFib3V0IG9wdGlvbnMgYW5kDQo+aG93IHRoZXkgaW50ZXJh Y3Qgd2l0aCBzZWN1cml0eSwgYnV0IHRoZSByZXBvcnQgb2YgdGhlIGdyb3VwIHdvcmtpbmcgb24N Cj50aGlzIGhhcyBub3QgeWV0IGNvbWUgdXAgZm9yIHJldmlldy4gSSBhbSBqdXN0IHdvcnJpZWQg YWJvdXQgZ2V0dGluZyB0aGlzDQo+ZHJhZnQgZmluaXNoZWQuDQoNCkFuZCBJ4oCZbSB3b3JyaWVk IHRoYXQgdGhpcyBkcmFmdCB2b2lkcyB0aGUgY2FuZGlkYXRlIHNvbHV0aW9ucyBmb3INCnByb3Rl Y3RpbmcgcGF5bG9hZCBhbmQgbWV0YWRhdGEuDQoNCkfDtnJhbg0KDQoNCj4NCj5qaW0NCj4NCj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBHw7ZyYW4gU2VsYW5kZXIgW21h aWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb21dDQo+PiBTZW50OiBNb25kYXksIEZlYnJ1 YXJ5IDAxLCAyMDE2IDEyOjIwIEFNDQo+PiBUbzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxs YXJzLmNvbT47IGlldGZAaWV0Zi5vcmcNCj4+IENjOiBkcmFmdC1pZXRmLWNvcmUtYmxvY2tAaWV0 Zi5vcmc7IGNvcmUtY2hhaXJzQGlldGYub3JnOyBjb3JlQGlldGYub3JnOw0KPj4gYmFycnlsZWli YUBnbWFpbC5jb20NCj4+IFN1YmplY3Q6IFJlOiBbY29yZV0gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0 Zi1jb3JlLWJsb2NrLTE4LnR4dD4NCj4+KEJsb2NrLXdpc2UgdHJhbnNmZXJzDQo+PiBpbiBDb0FQ KSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPj4gDQo+PiBIaSBKaW0NCj4+IA0KPj4gVGhhbmtzIGZv ciBwaWNraW5nIHVwIHRoZSB0aHJlYWQuDQo+PiANCj4+IFdlIHNwZW50IHNvbWUgdGltZSBpbiBQ cmFndWUgdGhpbmtpbmcgYWJvdXQgdGhpcy4gWW91IGFyZSByaWdodCB0aGF0DQo+PnRoZXJlIGFy ZQ0KPj4gZGlmZmVyZW50IG9wdGlvbnMgd2l0aCBkaWZmZXJlbnQgY2hhcmFjdGVyaXN0aWNzLiBI ZXJlIGFyZSB0aGUgY2FzZXMgd2UNCj4+aGF2ZQ0KPj4gY29uc2lkZXJlZC4NCj4+IA0KPj4gSnVz dCB0byByZWNhcCB0aGUgb2JqZWN0aXZlLCB0aGlzIGlzIGFib3V0IHByb3RlY3RpbmcgY29tbXVu aWNhdGlvbg0KPj5iZXR3ZWVuDQo+PiBDb0FQIGNsaWVudCBhbmQgQ29BUCBzZXJ2ZXIgd2hpbGUg YWxsb3dpbmcgbGVnaXRpbWF0ZSBvcGVyYXRpb25zIG9mIG9uZQ0KPj5vcg0KPj4gbW9yZSBpbnRl cm1lZGlhcnkgQ29BUCBwcm94aWVzLiBDbGllbnQgYW5kIHNlcnZlciBhcmUgYXNzdW1lZCB0byBo YXZlIGENCj4+IHNlY3VyaXR5IGFzc29jaWF0aW9uLg0KPj4gDQo+PiBPbiBhIGhpZ2ggbGV2ZWwg dGhlIGNhbmRpZGF0ZSBzb2x1dGlvbnMgYXJlIGVpdGhlciBidWlsdCBlbnRpcmVseSBvbg0KPj50 b3Agb2YgQ29BUCBvcg0KPj4gYWRkIG5ldyBDb0FQIG9wdGlvbnMuDQo+PiANCj4+IExvb2tpbmcg YXQgdGhlIGZvcm1lciBmaXJzdCwgb25lIHNvbHV0aW9uIGlzIHRvIHdyYXAganVzdCB0aGUgQ29B UA0KPj4gcGF5bG9hZC9jb250ZW50LCBlLmcuIHVzaW5nIENPU0UgWzFdLiAoV2UgY2FsbGVkIHRo aXMgb2JqZWN0IHNlY3VyaXR5DQo+Pm9mIGNvbnRlbnQsDQo+PiBPU0NPTikuIFRoaXMgaXMgdXNl ZnVsIGlmIHRoZSBwYXlsb2FkIGluY2x1ZGVzIGNlcnRhaW4gbWV0YSBkYXRhLCBsaWtlDQo+Pmlu IHRoZSBjYXNlDQo+PiBvZiBDV1QsIG9yIGlmIGNlcnRhaW4gaW5mb3JtYXRpb24sIHN1Y2ggYXMg cmVzb3VyY2UgaWRlbnRpZmllciBldGMuLCBpcw0KPj5pbXBsaWNpdA0KPj4gZnJvbSB0aGUgc2Vj dXJpdHkgYXNzb2NpYXRpb24uDQo+PiANCj4+IFRoaXMgc29sdXRpb24gaG93ZXZlciBkb2VzIG5v dCBwcm90ZWN0IHRoZSBtZXRhZGF0YSBzZW50IGluIHRoZSBDb0FQDQo+Pm1lc3NhZ2UsDQo+PiBz dWNoIGFzIGUuZy4gQ29kZSAoR0VUL0RFTEVURS9ldGMpLCBVcmktUGF0aCBvciBDb250ZW50IEZv cm1hdC4NCj4+IEV2ZW4gaWYgc3VjaCBpbmZvcm1hdGlvbiB3b3VsZCBiZSBpbnRlZ3JpdHkgcHJv dGVjdGVkLCBlLmcuIHVzaW5nDQo+PkV4dGVybmFsLUFBRCBpbg0KPj4gWzFdLCBpdCBuZWl0aGVy IHByb3RlY3RzIG1lc3NhZ2VzIHdoaWNoIGRvIG5vdCBoYXZlIHBheWxvYWQsIGxpa2UgZS5nLg0K Pj5HRVQNCj4+IHJlcXVlc3RzLCBub3IgZG9lcyBpdCBhZGRyZXNzIGNvbmZpZGVudGlhbGl0eSBk ZXNpcmFibGUgZm9yIGEgc3Vic2V0IG9mDQo+PnN1Y2gNCj4+IG1ldGFkYXRhIGZvciBwcml2YWN5 IHJlYXNvbnMuDQo+PiANCj4+IEFuIGFsdGVybmF0aXZlIHNvbHV0aW9uIG9uIHRvcCBvZiBDb0FQ IGlzIHRvIG1vdmUgdGhlIFJFU1RmdWwgcHJvdG9jb2wNCj4+b3V0IG9mDQo+PiBDb0FQIGFuZCBv bmx5IHVzZSBQT1NUIHdpdGggc29tZSBkdW1teSBVcmktUGF0aCwgQ29udGVudCBGb3JtYXQgZXRj LiBJbg0KPj50aGlzDQo+PiB3YXkgYWxsIG1lc3NhZ2VzIGNvdWxkIGNhcnJ5IGEgcHJvdGVjdGVk IG9iamVjdCBhcyBpbiBbMV0gYW5kIHRoZQ0KPj5uYXR1cmUgb2YgdGhlDQo+PiBpbnRlcmFjdGlv biBhbmQgY29udGVudCBpcyBjb250YWluZWQgaW4gdGhpcyBvYmplY3QuIFRoaXMgaXMgcHJvYmFi bHkNCj4+dmlvbGF0aW5nIHRoZQ0KPj4gcHVycG9zZSBvZiBDb0FQIHRvbyBtdWNoIHRvIGJlIG9m IGFueSBpbnRlcmVzdC4NCj4+IA0KPj4gVGhvc2UgYXJlIHRoZSBvbmx5IHNvbHV0aW9ucyB3ZSBo YXZlIGNvbnNpZGVyZWQgb24gdG9wIG9mIENvQVAuIEknbSBub3QNCj4+c3VyZSBpZg0KPj4gdGhl IHNvbHV0aW9uIHlvdSBwcm9wb3NlIGlzIHJlbGF0ZWQgdG8gb25lIG9mIHRoZXNlPw0KPj4gDQo+ PiBBbGwgb3RoZXIgc29sdXRpb25zIEknbSBhd2FyZSBvZiB3aGljaCBhZGRyZXNzIHRoZSBnZW5l cmFsIHByb2JsZW0NCj4+c3BhY2UsIGUuZy4NCj4+IE9TQ09BUCwgYXJlIGJ1aWx0ICJ3aXRoaW4i IENvQVAsIHVzaW5nIENvQVAgb3B0aW9ucyB0byBjYXJyeSBwcm90ZWN0ZWQNCj4+b2JqZWN0cw0K Pj4gKHN1Y2ggYXMgWzFdKSB3aGljaCBpbmNsdWRlIGludGVncml0eSBwcm90ZWN0aW9uIG9mIHRo ZSBwYXlsb2FkIGFuZA0KPj5tZXRhLWRhdGEuDQo+PiBOb3csIHdoYXQgaGFwcGVucyBpZiB0aGUg cGF5bG9hZCBpcyBsYXJnZT8gSWYgdGhlIG9yaWdpbmF0aW5nIGVuZHBvaW50DQo+PmRvZXMgdGhl DQo+PiBmcmFnbWVudGF0aW9uIHRoZW4gdGhlIGRlc3RpbmF0aW9uIGVuZHBvaW50IGNhbiB2ZXJp ZnkgdGhlIGludGVncml0eS4NCj4+SWYgYSBwcm94eQ0KPj4gdXNpbmcgdGhlIGJsb2Nrd2lzZSBk cmFmdCAocmUtKWZyYWdtZW50cyB0aGUgcGF5bG9hZCAod2hpY2ggYWxzbw0KPj5jaGFuZ2VzIGEN Cj4+IEJsb2NrIG9wdGlvbikgc3VjaCB0aGF0IGl0IGlzIGRpZmZlcmVudCB3aGVuIHJlYWNoaW5n IHRoZSBkZXN0aW5hdGlvbg0KPj5lbmRwb2ludCwNCj4+IHRoZW4gaW50ZWdyaXR5IHZlcmlmaWNh dGlvbiB3aWxsIGZhaWwuIFRoZSBkZXN0aW5hdGlvbiBlbmRwb2ludCBjYW5ub3QNCj4+ZGlzdGlu Z3Vpc2ggYQ0KPj4gbGVnaXRpbWF0ZSBpbnRyb2R1Y3Rpb24vY2hhbmdlIG9mIHBheWxvYWQgYW5k IEJsb2NrIG9wdGlvbiBmcm9tIGFueQ0KPj5vdGhlcg0KPj4gY2hhbmdlIG9mIHRoZSBtZXNzYWdl LCBoZW5jZSBpdCBjYW5ub3QgdmVyaWZ5IGludGVncml0eS4gVGhpcyBjYW4gYmUNCj4+dXNlZCB0 bw0KPj4gZGlzYWJsZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBhdCBDb0FQIGxheWVyIGFsc28gZm9y IHNob3J0ZXIgbWVzc2FnZXMsDQo+PnNpbmNlIHRoZQ0KPj4gZGVzdGluYXRpb24gZW5kcG9pbnQg bXVzdCB0cmVhdCB0aGUgZXhpc3RlbmNlIG9mIGEgQmxvY2sgb3B0aW9uIGFzIGENCj4+Z2VuZXJp Yw0KPj4gInNlY3VyaXR5IG9mZiIgYnV0dG9uLg0KPj4gDQo+PiBUaGlzIGlzIHF1aXRlIGRpZmZl cmVudCBmcm9tIHRoZSBDb0FQIG9wdGlvbnMgc3RhbmRhcmRpemVkIHNvIGZhciB3aGVyZQ0KPj55 b3UgY2FuDQo+PiBwcm90ZWN0IGluZGl2aWR1YWwgbWVzc2FnZXMgYmV0d2VlbiBjbGllbnQgYW5k IHNlcnZlciBhdCB0aGUgc2FtZSB0aW1lDQo+PmFzDQo+PiBhbGxvd2luZyBsZWdpdGltYXRlIHBy b3h5IG9wZXJhdGlvbiwgZXZlbiB2ZXJpZnlpbmcgdGhhdCBpbnRlcm1lZGlhdGUNCj4+bm9kZXMg aGFzDQo+PiBwZXJmb3JtZWQgdGhlIGNvcnJlY3QgQ29BUCBvcHRpb24gbWFuaXB1bGF0aW9ucyBz dWNoIGFzIGUuZy4gd2hlbg0KPj5mb3J3YXJkDQo+PiBwcm94aWVzIGNoYW5nZSB0aGUgVXJpLSog b3B0aW9ucyBtYWtpbmcgdGhlIG1lc3NhZ2UgcmVhY2ggdGhlIGNvcnJlY3QNCj4+IGRlc3RpbmF0 aW9uIFVSSS4NCj4+IA0KPj4gSU1ITyBDb0FQIHNob3VsZCBub3QgYWxsb3cgYW4gaW50ZXJtZWRp YXRlIGRldmljZSB0byBsZWdpdGltYXRlbHkgdHVybg0KPj5vZmYNCj4+IGludGVncml0eSBwcm90 ZWN0aW5nIGJldHdlZW4gY2xpZW50IGFuZCBzZXJ2ZXIuIENvQVAgc2hvdWxkIGRlZmluaXRlbHkN Cj4+c3VwcG9ydA0KPj4gaW50ZWdyaXR5IHByb3RlY3Rpb24gb2Ygc2hvcnQgbWVzc2FnZXMgYmV0 d2VlbiBjbGllbnQgYW5kIHNlcnZlciB0aHJvdWdoDQo+PiBwcm94aWVzLiBUaGlzIGlzIHdoZXJl IENvQVAgc2hpbmVzIGJyaWdodGx5LiBHaXZlbiB0aGF0LCBpdCBpcw0KPj5zdHJhaWdodGZvcndh cmQgdG8NCj4+IGludGVncml0eSBwcm90ZWN0IG1lc3NhZ2VzIGZyYWdtZW50ZWQgYXQgdGhlIGVu ZHBvaW50cy4NCj4+IEFuZCB3aXRoIHRoZSBCbG9jayBvcHRpb25zIGludGVncml0eSBwcm90ZWN0 ZWQgdGhlIGVudGlyZSBtZXNzYWdlIGJ1aWx0DQo+PnVwIG9mIHRoZQ0KPj4gZnJhZ21lbnRzIGlz IGF1dG9tYXRpY2FsbHkgcHJvdGVjdGVkIGFzIHdlbGwuDQo+PiANCj4+IEfDtnJhbg0KPj4gDQo+ PiBbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29zZS1tc2cNCj4+ IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBPbiAyMDE2LTAxLTI5IDAwOjE4LCAiSmltIFNjaGFh ZCIgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdyb3RlOg0KPj4gDQo+PiA+R8O2cmFuLA0KPj4g Pg0KPj4gPkkgZmluYWxseSBnb3QgY2F1Z2h0IHVwIG9uIHJlYWRpbmcgdGhlIENPUkUgbWFpbGlu ZyBsaXN0IChsb3RzIG9mDQo+PiA+Ym9yZWRvbSBvbiBpc3N1ZXMgSSBkb27igJl0IHRoaW5rIEkg Y2FyZSBhYm91dCkgYW5kIEkgZGlkIG5vdCBmaW5kIGFueQ0KPj4gPnJlc3BvbnNlcyB0byB5b3Vy IG1haWwgb24gdGhpcyBpc3N1ZS4gIEkgd291bGQgbGlrZSB0byBwcm9wb3NlIGENCj4+ID5kaWZm ZXJlbnQgc29sdXRpb24gdG8gdGhlIHByb2JsZW0gd2hpY2ggSSB0aGluayB5b3Ugd2lsbCBmaW5k IGJvdGgNCj4+ID53b3JrYWJsZSBhbmQgcG90ZW50aWFsIG5vdCByZXF1aXJpbmcgYW55IHVwZGF0 ZXMgdG8gdGhlIGN1cnJlbnQgZHJhZnQuDQo+PiA+DQo+PiA+V2hlbiBJIHJlYWQgdGhpcyBkcmFm dCB0aGUgZmlyc3QgdGltZSwgSSByZWFkIGl0IGFzIGEgbmV0d29yaw0KPj4gPmZyYWdtZW50YXRp b24gZHJhZnQgcmF0aGVyIHRoYW4gYXMgYSBtZXNzYWdpbmcgZHJhZnQuICBBcyBzdWNoIEkgZGlk DQo+PiA+bm90IGhhdmUgdGhlIHNhbWUgY29uY2VybnMgYWJvdXQgb2JqZWN0IHNlY3VyaXR5IGFz IHlvdSBzZWVtIHRvIGhhdmUuDQo+PiA+SSBtYWRlIHRoZSBkZWNpc2lvbiB0aGF0IEkgd291bGQg YXBwbHkgdGhlIHNlY3VyaXR5IHRvIHRoZSBlbnRpcmV0eSBvZg0KPj4gPnRoZSBtZXNzYWdlIGJl aW5nIHNlbnQsIGFuZCB0aGVuIGZyYWdtZW50IGl0IGludG8gYmxvY2tzIGFmdGVyd2FyZHMuDQo+ PiA+U3VjaCBhbiBhcHByb2FjaCBhbGxvd3MgZm9yIGEgbnVtYmVyIG9mIHRoaW5ncyB0aGF0IHlv dSBhcmUgaGF2aW5nDQo+PiA+cHJvYmxlbXMgd2l0aCB0byBiZSBpZ25vcmVkLg0KPj4gPg0KPj4g PkhvdyB0aGUgZnJhZ21lbnRhdGlvbiBpcyBkb25lLCBpcyBjaGFuZ2Ugb3IgaXMgcmVtb3ZlZCBi ZWNvbWUNCj4+ID5pbW1hdGVyaWFsIGFzIHRoZSBlbmQgcmVjaXBpZW50IHdvdWxkIG5lZWQgdG8g aGF2ZSBhbGwgb2YgdGhlIGZyYWdtZW50cw0KPj4gPmRlbGl2ZXJlZCBhbmQgaW4gdGhlIGNvcnJl Y3Qgb3JkZXIgaW4gb3JkZXIgdG8gcHJvY2VzcyB0aGUgbWVzc2FnZSBhbmQNCj4+ID5kbyB2YWxp ZGF0aW9uLg0KPj4gPg0KPj4gPk92ZXJoZWFkIGlzIHNtYWxsZXIgYmVjYXVzZSB0aGUgb3Zlcmhl YWQgb2YgZW5jcnlwdGluZy9zaWduaW5nIGF0IHRoZQ0KPj4gPm9iamVjdCBzZWN1cml0eSBsZXZl bCBpcyBkb25lIG9uY2UgcmF0aGVyIHRoYW4gb25jZSBwZXIgZnJhZ21lbnQuICBUaGlzDQo+PiA+ YWxsb3dzIGZvciBmZXdlciBieXRlcyB0byBiZSBzZW50IGFjcm9zcyB0aGUgd2lyZS4NCj4+ID4N Cj4+ID5UaGUgaGVhZGVycyBvZiB0aGUgZmlyc3QgbWVzc2FnZSBpbiB0aGUgZnJhZ21lbnQgYXJl IHRoZSBvbmVzIHRoYXQgdGhlDQo+PiA+b2JqZWN0IHNlY3VyaXR5IHN5c3RlbSB3b3VsZCBiZSB1 c2luZyBib3RoIGZvciBzZWN1cml0eSBjYWxjdWxhdGlvbg0KPj4gPnB1cnBvc2VzIGFuZCBmb3Ig dGhlIHJlY2VpdmVyIHRvIHByb2Nlc3MgdGhlIHZhbGlkYXRlZCBtZXNzYWdlLg0KPj4gPg0KPj4g PlRoZXJlIGFyZSBzdGlsbCBzb21lIHF1ZXN0aW9uIHRoYXQgcG90ZW50aWFsbHkgbmVlZCB0byBi ZSBkZWFsdCB3aXRoOg0KPj4gPg0KPj4gPjEpIEFyZSB0aGUgYmxvY2sgb3B0aW9uIGhlYWRlcnMg YXV0aGVudGljYXRlZD8gIFRoZSBwcm9iYWJsZSBhbnN3ZXINCj4+ID5zaG91bGQgYmUgbm8gYXMg dGhleSBhcmUgZGVzaWduZWQgdG8gYmUgY2hhbmdlZCBieSBpbnRlcm1lZGlhcmllcy4NCj4+ID5U aGlzIGNhbiBiZSBkZWZlcnJlZCB1bnRpbCB0aGUgZ2VuZXJhbCBkaXNjdXNzaW9uIGFib3V0IHRo ZSByZXN0IG9mIHRoZQ0KPj4gPmN1cnJlbnQgaGVhZGVycy4NCj4+ID4NCj4+ID4yKSBXaGF0IG9w dGlvbnMgYXJlIHJlcXVpcmVkIHRvIGJlIGNvcGllZCBmb3J3YXJkIGludG8gc3Vic2VxdWVudA0K Pj4gPm1lc3NhZ2VzIGFuZCB3aGljaCBjYW4gYmUgb21pdHRlZD8gIEkgd2FzIHVuYWJsZSB0byBm aW5kIGFueSBndWlkYW5jZQ0KPj4gPm9uIHRoaXMgaXNzdWUgZnJvbSByZWFkaW5nIHRoZSBkb2N1 bWVudCBhbmQgdGh1cyB3b3VsZCBuYWl2ZWx5IG1ha2UgdGhlDQo+PiA+YXNzdW1wdGlvbiB0aGF0 IGFsbCBvcHRpb25zIG5vdCBzcGVjaWZpZWQgYnkgdGhpcyBkb2N1bWVudCBhcmUgY29waWVkDQo+ PiA+Zm9yd2FyZCBhbmQgc2hvdWxkIGJlIGNoZWNrZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhleSBh cmUgdW5jaGFuZ2VkIGluDQo+PiA+ZnV0dXJlIG1lc3NhZ2VzLiAgSG93ZXZlciBJIGRvdWJ0IHRo YXQgaXMgdGhlIGRlc2lyZSBvZiB0aGUgYXV0aG9ycy4NCj4+ID5UaGlzIGhvd2V2ZXIgaXMgbm90 IGEgc2VjdXJpdHkgc3BlY2lmaWMgaXNzdWUgYW5kIG5lZWRzIHRvIGJlIGFkZHJlc3NlZA0KPj4g PmluIHRoaXMgZG9jdW1lbnQuDQo+PiA+DQo+PiA+MykgRG8gd2Ugd2FudCB0byBhcHBseSBwZXIg bWVzc2FnZSBzZWN1cml0eSBhcyB3ZWxsIC0gdGhhdCBpcyBhbiBpc3N1ZQ0KPj4gPnRoYXQgY2Fu IGFuZCBzaG91bGQgYmUgcHVudGVkIHRvIGEgZnV0dXJlIG9iamVjdCBzZWN1cml0eSBkcmFmdC4N Cj4+ID5Ib3dldmVyLCBJIGRvbid0IHNlZSB0aGUgcG9pbnQgZXhjZXB0IHRvIHByb3RlY3QgdGhl IEFDSy9OQUNLIG9yIGxhY2sNCj4+ID5vZiBvbiBlYWNoIGluZGl2aWR1YWwgaG9wLiAgQnV0IHRo aXMgaXMgcG9pbnQtdG8tcG9pbnQgbm90IGVuZC10by1lbmQuDQo+PiA+DQo+PiA+SmltDQo+PiA+ DQo+PiA+DQo+PiA+DQo+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gRnJv bTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEfDtnJh biBTZWxhbmRlcg0KPj4gPj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyNSwgMjAxNSAxMTow NyBQTQ0KPj4gPj4gVG86IGlldGZAaWV0Zi5vcmcNCj4+ID4+IENjOiBkcmFmdC1pZXRmLWNvcmUt YmxvY2tAaWV0Zi5vcmc7IGNvcmUtY2hhaXJzQGlldGYub3JnOw0KPj4gPj5jb3JlQGlldGYub3Jn OyAgYmFycnlsZWliYUBnbWFpbC5jb20NCj4+ID4+IFN1YmplY3Q6IFJlOiBbY29yZV0gTGFzdCBD YWxsOiA8ZHJhZnQtaWV0Zi1jb3JlLWJsb2NrLTE4LnR4dD4NCj4+ID4+KEJsb2NrLXdpc2UgdHJh bnNmZXJzICBpbiBDb0FQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPj4gPj4NCj4+ID4+DQo+PiA+ Pg0KPj4gPj4gVGhlcmUgd2FzIGEgdGhyZWFkIG9uIHRoZSBDb1JFIFdHIG1haWxpbmcgbGlzdCBh IGNvdXBsZSBvZiBtb250aHMgYWdvDQo+PiA+Pm9uIHRoZSAgdG9waWMgb2YgYmxvY2t3aXNlIGFu ZCBvYmplY3Qgc2VjdXJpdHkuIFRoZSBzdGFydGluZyBwb2ludCB3YXMNCj4+ID4+YSBxdWVzdGlv biBpZiBDb0FQICBwcm94aWVzIGNhbiAocmUtKXBhcnRpdGlvbiBtZXNzYWdlcyBpbnRvIGJsb2Nr cyBhcw0KPj4gPj5kZWZpbmVkIGluIHRoaXMgZHJhZnQsIGFuZCB0aGUgIGltcGxpY2F0aW9ucyBv biBlbmQtdG8tZW5kIHNlY3VyaXR5DQo+PiA+PmJldHdlZW4gY2xpZW50IGFuZCBzZXJ2ZXIgdGhy b3VnaCBzdWNoIGEgIHByb3h5LiBUaGUgY29uY2x1c2lvbnMgb2YNCj4+ID4+dGhhdCBkaXNjdXNz aW9uIGhhcyBhbiBpbXBhY3Qgb24gdGhpcyBkcmFmdCwgYnV0IHRoZXJlICBhcmUgbm8NCj4+ID4+ Y29uc2lkZXJhdGlvbnMgb2YgdGhpcyBraW5kIG1hZGUgaW4gdmVyc2lvbiAtMTguIE1vcmUgZGV0 YWlscyBhcmUNCj4+ID4+Z2l2ZW4gIGJlbG93LCBpbmNsdWRpbmcgc29tZSBhbHRlcm5hdGl2ZSBw cm9wb3NhbHMgZm9yIGhvdyB0byBhZGRyZXNzDQo+PiA+PnRoaXMuDQo+PiA+PkFwb2xvZ2llcw0K Pj4gPj4gZm9yIHRoZSBsb25nIGUtbWFpbC4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4gQmFja2dyb3Vu ZDoNCj4+ID4+DQo+PiA+PiBUaGVyZSBpcyBhbiBvbmdvaW5nIGRpc2N1c3Npb24gaW4gQ29SRSBh bmQgQUNFIFdHcyBzaW5jZSBhIHllYXIgb24NCj4+ID4+dGhlDQo+PiA+PmVuZC10by0NCj4+ID4+ IGVuZCBzZWN1cml0eSBwcm9wZXJ0aWVzIG9mIENvQVAsIGkuZS4gcHJvdGVjdGluZyB0aGUgY29t bXVuaWNhdGlvbg0KPj4gPj5iZXR3ZWVuIGEgIGNsaWVudCBhbmQgYSBzZXJ2ZXIgdGhyb3VnaCBw cm94aWVzLiBSRkMgNzI1MiBhbmQgb3RoZXINCj4+ID4+c3BlY2lmaWNhdGlvbnMgaW4gdGhlICBD b0FQIHN1aXRlIGRlZmluZSBhIHNldCBvZiBsZWdpdGltYXRlIHByb3h5DQo+PiA+Pm9wZXJhdGlv bnMgb24gQ29BUCBtZXNzYWdlcyB3aGljaCAgcmVxdWlyZXMgRFRMUyB0byBiZSB0ZXJtaW5hdGVk IGF0DQo+PiA+PnByb3hpZXMuIFRoaXMgaW1wbGllcyB0aGF0IHRoZSBwcm94eSBoYXMgYWNjZXNz ICBub3Qgb25seSB3aXRoIHRoZQ0KPj4gPj5kYXRhIHJlcXVpcmVkIGZvciBwZXJmb3JtIHRoZSBp bnRlbmRlZCBwcm94eSBvcGVyYXRpb24gYnV0IGlzICBhbHNvDQo+PiA+PmFibGUgdG8gZWF2ZXNk cm9wIG9yIG1hbmlwdWxhdGUgYW55IHBhcnQgb2YgdGhlIENvQVAgcGF5bG9hZCBhbmQNCj4+ID4+ bWV0YWRhdGEgaW4gdHJhbnNpdCBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyIHdpdGhvdXQgYmVp bmcgcHJvdGVjdGVkDQo+PiA+Pm9yICBkZXRlY3RlZCBieSBEVExTLg0KPj4gPj4NCj4+ID4+DQo+ PiA+PiBPbmUgd2F5IHRvIG1pdGlnYXRlIHRoaXMgdGhyZWF0IGlzIHRvIGNvbXBsZW1lbnQgb3Ig cmVwbGFjZSBEVExTIHdpdGgNCj4+ID4+YXBwbGljYXRpb24gbGF5ZXIgcHJvdGVjdGlvbiBvZiBD b0FQIHBheWxvYWQgYW5kIG1ldGFkYXRhIGJldHdlZW4NCj4+ID4+Y2xpZW50IGFuZCAgc2VydmVy IGZvciB0aGUgdXNlIGNhc2VzIHdoZXJlIHRoZSBwcm94eSBzaG91bGQgbm90IGJlDQo+PiA+PmZ1 bGx5IHRydXN0ZWQuDQo+PiA+PiBUaGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBpbiB0aGUgQ29SRSBX RyBtZWV0aW5ncyBkdXJpbmcgdGhlIHRocmVlIGxhc3QNCj4+ID4+SUVURiBGMkYgIG1lZXRpbmdz IGFuZCB0aGVyZSBhcmUgZHJhZnQgc29sdXRpb25zIHVzaW5nIHRoZSBtZXNzYWdlDQo+PiA+PmZv cm1hdCBiZWluZyAgZGV2ZWxvcGVkIGluIHRoZSBDT1NFIFdHLg0KPj4gPj4NCj4+ID4+DQo+PiA+ PiBXaXRoIHRoZSBDT0FQIHByb3h5IG9wZXJhdGlvbnMgc3RhbmRhcmRpemVkIHNvIGZhciBpdCBo YXMgYmVlbg0KPj4gPj5wb3NzaWJsZSB0byAgcHJvdGVjdCB0aGUgQ29BUCBtZXNzYWdlcyBhZGVx dWF0ZWx5IHdpdGggc2VjdXJpdHkgb24NCj4+ID4+dHJhbnNwb3J0IGxheWVyLCAgYXBwbGljYXRp b24gbGF5ZXIgb3IgYSBjb21iaW5hdGlvbiB0aGVyZW9mLiBJbiB0aGUNCj4+ID4+Y2FzZSB3aGVy ZSB0aGUgbGVnaXRpbWF0ZSAgcHJveHkgb3BlcmF0aW9uIGlzIHByZWRpY3RhYmxlIGJ5IGNsaWVu dA0KPj4gPj5hbmQgc2VydmVyLCBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0eSBjYW4gIGJlIGRl ZmluZWQgdG8gYm90aCB2ZXJpZnkNCj4+ID4+dGhhdCBubyBpbGxlZ2l0aW1hdGUgY2hhbmdlcyBo YXMgYmVlbiBwZXJmb3JtZWQgYXMgIHdlbGwgYXMgdmVyaWZ5aW5nDQo+PiA+PnRoZSBsZWdpdGlt YXRlIGNoYW5nZXMuIEluIHRoZSBjYXNlIHdoZXJlIHByb3h5IG9wZXJhdGlvbnMgYXJlICBub3QN Cj4+ID4+cHJlZGljdGFibGUg4oCUIGV2ZW4gaWYgdGhlIGRhdGEgdGhlIHByb3h5IGlzIG9wZXJh dGluZyBvbiBjYW5ub3QgYmUNCj4+ID4+cHJvdGVjdGVkICDigJQgaXQgaGFzIHNvIGZhciBiZWVu IHBvc3NpYmxlIHRvIHVzZSBvdGhlciBpbmZvcm1hdGlvbg0KPj4gPj5lbGVtZW50cyB0byBwcm92 aWRlIHRoZSAgcmVxdWlyZWQgZW5kLXRvLWVuZCBzZWN1cml0eSBwcm9wZXJpdGllcy4NCj4+ID4+ Rm9yIGV4YW1wbGUsIHRoZSBDb0FQIGhlYWRlciBmaWVsZCAgVG9rZW4gbWF5IGJlIGNoYW5nZWQg YnkgYSBwcm94eSwNCj4+ID4+YnV0IGluc3RlYWQgYSB0cmFuc2FjdGlvbiBpZGVudGlmaWVyIGNh biBiZSAgaW50cm9kdWNlZCBpbiB0aGUNCj4+ID4+YXBwbGljYXRpb24gc2VjdXJpdHkgd3JhcHBl ciAoQ09TRQ0KPj4gPj4gaGVhZGVyKSB0byBkZWZpbmUgYSBtZXNzYWdlIChleGNoYW5nZSkgaWRl bnRpZmllciBjb21tb24gdG8gY2xpZW50DQo+PiA+PmFuZCBzZXJ2ZXIuDQo+PiA+Pg0KPj4gPj4N Cj4+ID4+IEJsb2Nrd2lzZToNCj4+ID4+DQo+PiA+PiBXaXRoIHRoZSBkZWZpbml0aW9uIG9mIGJs b2Nrd2lzZSB0cmFuc2ZlciBhcyBzcGVjaWZpZWQgaW4gdGhpcyBkcmFmdA0KPj4gPj5hIHByb3h5 IG1heSAgcGFydGl0aW9uIG9yIHJlLXBhcnRpdGlvbmluZyBhIG1lc3NhZ2UgaW50byBibG9ja3Mg d2hlcmUNCj4+ID4+dGhlIHNpemUgb2YgdGhlIGJsb2NrcyAgYXJlIGRlY2lkZWQgYnkgdGhlIHBy b3h5LiBBcyBhIGNvbnNlcXVlbmNlLCBpdA0KPj4gPj5pcyBub3QgcG9zc2libGUgdG8gaW50ZWdy aXR5IHByb3RlY3QgIGluZGl2aWR1YWwgYmxvY2tzIGVuZC10by1lbmQNCj4+ID4+YmV0d2VlbiBj bGllbnQgYW5kIHNlcnZlcjogRFRMUyBkb2VzIG5vdCBwcm90ZWN0ICB0aGUgbWVzc2FnZSBkYXRh DQo+PiA+PndpdGhpbiB0aGUgcHJveHksIGFuZCBhcHBsaWNhdGlvbiBsYXllciBpbnRlZ3JpdHkg cHJvdGVjdGlvbiBvZg0KPj4gPj5pbmRpdmlkdWFsIGJsb2NrcyBjYW5ub3QgYmUgcGVyZm9ybWVk IHVubGVzcyB0aGUgcGFydGl0aW9uaW5nIGludG8NCj4+ID4+YmxvY2tzIGFzICByZWNlaXZlZCBi eSBvbmUgZW5kcG9pbnQgaXMgaWRlbnRpY2FsIHRvIHRoYXQgc2VudCBieSB0aGUNCj4+ID4+b3Ro ZXIgZW5kcG9pbnQuIEhlbmNlLCAgd2hlbiBDb0FQIEJsb2NrIG9wdGlvbnMgYXJlIHVzZWQgYXMg ZGVmaW5lZCBpbg0KPj4gPj50aGlzIGRyYWZ0LCBlbmQtdG8tZW5kIHNlY3VyaXR5ICBvZiB0aGUg aW5kaXZpZHVhbCBDb0FQIHJlcXVlc3QgYW5kDQo+PiA+PnJlc3BvbnNlIGJyZWFrcyBkb3duLiBG b3IgZXhhbXBsZTogYSBwcm94eSAgbWF5IGFkZEJsb2NrIG9wdGlvbnMsIHNlbmQNCj4+ID4+YW55 IG51bWJlciBvZiBibG9ja3Mgd2l0aCBhbnkgcGF5bG9hZCB0byBhbiAgZW5kcG9pbnQgd2l0aG91 dCBiZWluZw0KPj4gPj5wb3NzaWJsZSB0byBkZXRlY3Qgb3IgcHJvdGVjdCBhZ2FpbnN0LiBJbiBj b250cmFzdCB0byB0aGUgIGV4aXN0aW5nDQo+PiA+PnN0YW5kYXJkcyBpbiB0aGUgQ29BUCBzdWl0 ZSwgaW4gdGhpcyBjYXNlIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBieXBhc3MNCj4+ID4+dGhlICBj b25zdHJ1Y3Rpb24gYW5kIGRlZmluZSBhIHNlY3VyZSBlbmQtdG8tZW5kIGJsb2NrIHBhcnRpdGlv bmluZw0KPj4gPj53aXRoIGxlc3MgdGhhbiAgZGlzYWJsaW5nIGJsb2NrIHBhcnRpdGlvbmluZyBh cyBzcGVjaWZpZWQgaW4gdGhpcw0KPj4gPj5kcmFmdC4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4gT25l IHNvbHV0aW9uIHRvIHRoaXMgaXMgdG8gZGlzYWxsb3cgcHJveGllcyB0byByZS1wYXJ0aXRpb24g YQ0KPj4gPj5tZXNzYWdlLCB0aHVzICByZWRlZmluZSB0aGUgQmxvY2sgb3B0aW9ucyBzdWNoIHRo YXQgdGhleSBhcmUgcG9zc2libGUNCj4+ID4+dG8gaW50ZWdyaXR5IHByb3RlY3QgZW5kLSAgdG8t ZW5kLiAgSW50ZWdyaXR5IHByb3RlY3RpbmcgZWFjaCBibG9jaw0KPj4gPj5hbmQgY29ycmVzcG9u ZGluZyBCbG9jayBvcHRpb25zIGFzICBkZWZpbmVkIGluIHRoZSBjdXJyZW50IGRyYWZ0IGhhcw0K Pj4gPj5hZGRpdGlvbmFsIGJlbmVmaXRzOiBJZiBhbnkgYmxvY2sgaW4gdGhlIHNlcXVlbmNlICBm YWlscyB2ZXJpZmljYXRpb24sDQo+PiA+Pml0IGNhbiBiZSBpbmRpdmlkdWFsbHkgcmVxdWVzdGVk IHRvIGJlIHJlc2VudC4gV2hlbiBhbGwgYmxvY2tzICBoYXMNCj4+ID4+YmVlbiB2ZXJpZmllZCB0 aGUgZW50aXJlIG1lc3NhZ2UgaGFzIGJlZW4gdmVyaWZpZWQuICBBIHJlY2VpdmluZyBub2RlDQo+ PiA+Pm1heSAgZXZlbiBwZXJmb3JtIGNlcnRhaW4gYWN0aW9ucyBiYXNlZCBvbiByZWNlaXZlZCB2 ZXJpZmllZCBibG9ja3MNCj4+ID4+YmVmb3JlIHRoZSBlbnRpcmUgIG1lc3NhZ2UgaGFzIGJlZW4g cmVjZWl2ZWQuDQo+PiA+Pg0KPj4gPj4NCj4+ID4+IEluc3RlYWQgb2YgZGVsZWdhdGluZyB0byBw cm94aWVzIHRvIHBhcnRpdGlvbiBpbnRvIGJsb2NrcywgdGhlDQo+PnNlbmRpbmcNCj4+ID4+ZW5k cG9pbnQNCj4+ID4+IHdvdWxkIG5lZWQgdG8gYW50aWNpcGF0ZSBvciBnZXQgaW5mb3JtYXRpb24g YWJvdXQgdGhlIHJlbGV2YW50IGJsb2NrDQo+PiA+PnNpemUsIGUuZy4NCj4+ID4+IHVzaW5nIGEg c2l6ZSBpbmRpY2F0aW9uIGluIHRoZSBsaW5rLWZvcm1hdCBkZXNjcmlwdGlvbiBbUkZDNjk5MF0u DQo+PiA+PkFkZGl0aW9uYWwNCj4+ID4+IG1ldGhvZHMgZm9yIGJsb2Nrc2l6ZSBkaXNjb3Zlcnkg bWF5IGFsc28gYmUgZGVmaW5lZC4NCj4+ID4+IFdoaWxlIHRoaXMgbWF5IG5vdCBiZSBhcyBzaW1w bGUgYXMgbGVhdmluZyBpdCBlbnRpcmVseSB0byB0aGUgcHJveHkNCj4+dG8NCj4+ID4+ZGVjaWRl LA0KPj4gPj4gY29uc2lkZXJpbmcgdGhlIGFkZGl0aW9uYWwgc2VjdXJpdHkgYmVuZWZpdHMgSSBi ZWxpZXZlIHRoaXMgaXMgdGhlDQo+PiA+PnJpZ2h0IHRyYWRlIG9mZiB0bw0KPj4gPj4gbWFrZS4N Cj4+ID4+DQo+PiA+Pg0KPj4gPj4gQW4gYWx0ZXJuYXRpdmUgc29sdXRpb24gaXMgdG8gcHJldmVu dCBwcm94aWVzIGZyb20gcmUtcGFydGl0aW9uaW5nIGENCj4+ID4+bWVzc2FnZSBvbmx5DQo+PiA+ PiBpbiB0aGUgY2FzZSB3aGVyZSBlbmQtdG8tZW5kIHNlY3VyaXR5IG9mIENvQVAgbWVzc2FnZSBp cyBhcHBsaWVkLA0KPj53aGljaA0KPj4gPj5pbg0KPj4gPj4gY3VycmVudCBzb2x1dGlvbiBwcm9w b3NhbHMgaXMgaW5kaWNhdGVkIHdpdGggdGhlIHByZXNlbmNlIG9mIGENCj4+Y2VydGFpbg0KPj4g Pj5Db0FQDQo+PiA+PiBvcHRpb24gWCAod2hpY2ggZS5nLiBjb250YWlucyB0aGUgQ09TRSBvYmpl Y3QpLg0KPj4gPj4gVGhpcyB3b3VsZCBoYXZlIHRoZSBzYW1lIGJlbmVmaXRzIGFzIHRoZSBwcmV2 aW91cyBzb2x1dGlvbiwgYnV0DQo+PiA+PnJlcXVpcmVzIHRoZQ0KPj4gPj4gY29kZSBpbiB0aGUg cHJveHkgaW1wbGVtZW50aW5nIHRoaXMgZHJhZnQgdG8gYmUgYXdhcmUgb2Ygb3B0aW9uIFgsDQo+ PmFuZA0KPj4gPj5oZW5jZQ0KPj4gPj4gdGhhdCBkZXBlbmRlbmN5IG5lZWRzIHRvIGJlIHNwZWNp ZmllZCBpbiB0aGlzIGRyYWZ0LiBBbmQgb3B0aW9uIFggaXMNCj4+bm90DQo+PiA+PiBzdGFuZGFy ZGl6ZWQgeWV0LCBzbyB3b3VsZCByZXF1aXJlIGludHJvZHVjaW5nIGEgcGxhY2Vob2xkZXIuDQo+ PiA+Pg0KPj4gPj4NCj4+ID4+IFRoZXJlIGFyZSBvdGhlciBhbHRlcm5hdGl2ZXMgYXMgd2VsbCBi dXQgdGhpcyBlLW1haWwgaXMgYWxyZWFkeSB0b28NCj4+ID4+bG9uZy4NCj4+ID4+IFRoZSBtYWlu IHBvaW50IEkgd2FudGVkIHRvIG1ha2UgaXMgdGhhdCBnaXZlbiB0aGF0IHdlIG5vdyBoYXZlIGEN Cj4+YmV0dGVyDQo+PiA+PiB1bmRlcnN0YW5kaW5nIG9mIGhvdyB0byBhY2hpZXZlIHNlY3VyaXR5 IGJldHdlZW4gY2xpZW50IGFuZCBzZXJ2ZXINCj4+ID4+dGhyb3VnaA0KPj4gPj4gcHJveGllcyBj b21wYXJlZCB0byB3aGVuIFJGQzcyNTIgd2FzIHdyaXR0ZW4sIG15IG9waW5vbiBpcyB0aGF0IHdl DQo+PiA+PnNob3VsZA0KPj4gPj4gbm90IGlnbm9yZSB0aGVzZSBzZWN1cml0eSBpc3N1ZXMgaW4g bmV3IHN0YW5kYXJkcy4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+IEfDtnJhbg0KPj4gPj4N Cj4+ID4+DQo+PiA+Pg0KPj4gPj4gT24gMjAxNS0xMS0yMCAyMjozMiwgIlRoZSBJRVNHIiA8aWVz Zy1zZWNyZXRhcnlAaWV0Zi5vcmc+IHdyb3RlOg0KPj4gPj4NCj4+ID4+ID4NCj4+ID4+ID5UaGUg SUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIENvbnN0cmFpbmVkIFJFU1RmdWwN Cj4+ID4+ID5FbnZpcm9ubWVudHMgV0cgKGNvcmUpIHRvIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcg ZG9jdW1lbnQ6DQo+PiA+PiA+LSAnQmxvY2std2lzZSB0cmFuc2ZlcnMgaW4gQ29BUCcNCj4+ID4+ ID4gIDxkcmFmdC1pZXRmLWNvcmUtYmxvY2stMTgudHh0PiBhcyBQcm9wb3NlZCBTdGFuZGFyZA0K Pj4gPj4gPg0KPj4gPj4gPlRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUg bmV4dCBmZXcgd2Vla3MsIGFuZA0KPj5zb2xpY2l0cw0KPj4gPj4gPmZpbmFsIGNvbW1lbnRzIG9u IHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0bw0KPj50aGUN Cj4+ID4+ID5pZXRmQGlldGYub3JnIG1haWxpbmcgbGlzdHMgYnkgMjAxNS0xMi0wNC4gRXhjZXB0 aW9uYWxseSwgY29tbWVudHMNCj4+bWF5DQo+PiA+PiA+YmUgc2VudCB0byBpZXNnQGlldGYub3Jn IGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZQ0KPj4gPj4gPmJlZ2lu bmluZyBvZiB0aGUgU3ViamVjdCBsaW5lIHRvIGFsbG93IGF1dG9tYXRlZCBzb3J0aW5nLg0KPj4g Pj4gPg0KPj4gPj4gPkFic3RyYWN0DQo+PiA+PiA+DQo+PiA+PiA+DQo+PiA+PiA+ICAgQ29BUCBp cyBhIFJFU1RmdWwgdHJhbnNmZXIgcHJvdG9jb2wgZm9yIGNvbnN0cmFpbmVkIG5vZGVzIGFuZA0K Pj4gPj4gPiAgIG5ldHdvcmtzLiAgQmFzaWMgQ29BUCBtZXNzYWdlcyB3b3JrIHdlbGwgZm9yIHRo ZSBzbWFsbCBwYXlsb2Fkcw0KPj53ZQ0KPj4gPj4gPiAgIGV4cGVjdCBmcm9tIHRlbXBlcmF0dXJl IHNlbnNvcnMsIGxpZ2h0IHN3aXRjaGVzLCBhbmQgc2ltaWxhcg0KPj4gPj4gPiAgIGJ1aWxkaW5n LWF1dG9tYXRpb24gZGV2aWNlcy4gIE9jY2FzaW9uYWxseSwgaG93ZXZlciwgYXBwbGljYXRpb25z DQo+PiA+PiA+ICAgd2lsbCBuZWVkIHRvIHRyYW5zZmVyIGxhcmdlciBwYXlsb2FkcyAtLSBmb3Ig aW5zdGFuY2UsIGZvcg0KPj5maXJtd2FyZQ0KPj4gPj4gPiAgIHVwZGF0ZXMuICBXaXRoIEhUVFAs IFRDUCBkb2VzIHRoZSBncnVudCB3b3JrIG9mIHNsaWNpbmcgbGFyZ2UNCj4+ID4+ID4gICBwYXls b2FkcyB1cCBpbnRvIG11bHRpcGxlIHBhY2tldHMgYW5kIGVuc3VyaW5nIHRoYXQgdGhleSBhbGwN Cj4+YXJyaXZlDQo+PiA+PiA+ICAgYW5kIGFyZSBoYW5kbGVkIGluIHRoZSByaWdodCBvcmRlci4N Cj4+ID4+ID4NCj4+ID4+ID4gICBDb0FQIGlzIGJhc2VkIG9uIGRhdGFncmFtIHRyYW5zcG9ydHMg c3VjaCBhcyBVRFAgb3IgRFRMUywgd2hpY2gNCj4+ID4+ID4gICBsaW1pdHMgdGhlIG1heGltdW0g c2l6ZSBvZiByZXNvdXJjZSByZXByZXNlbnRhdGlvbnMgdGhhdCBjYW4gYmUNCj4+ID4+ID4gICB0 cmFuc2ZlcnJlZCB3aXRob3V0IHRvbyBtdWNoIGZyYWdtZW50YXRpb24uICBBbHRob3VnaCBVRFAN Cj4+c3VwcG9ydHMNCj4+ID4+ID4gICBsYXJnZXIgcGF5bG9hZHMgdGhyb3VnaCBJUCBmcmFnbWVu dGF0aW9uLCBpdCBpcyBsaW1pdGVkIHRvIDY0IEtpQg0KPj4gPj4gPiAgIGFuZCwgbW9yZSBpbXBv cnRhbnRseSwgZG9lc24ndCByZWFsbHkgd29yayB3ZWxsIGZvciBjb25zdHJhaW5lZA0KPj4gPj4g PiAgIGFwcGxpY2F0aW9ucyBhbmQgbmV0d29ya3MuDQo+PiA+PiA+DQo+PiA+PiA+ICAgSW5zdGVh ZCBvZiByZWx5aW5nIG9uIElQIGZyYWdtZW50YXRpb24sIHRoaXMgc3BlY2lmaWNhdGlvbg0KPj5l eHRlbmRzDQo+PiA+PiA+ICAgYmFzaWMgQ29BUCB3aXRoIGEgcGFpciBvZiAiQmxvY2siIG9wdGlv bnMsIGZvciB0cmFuc2ZlcnJpbmcNCj4+bXVsdGlwbGUNCj4+ID4+ID4gICBibG9ja3Mgb2YgaW5m b3JtYXRpb24gZnJvbSBhIHJlc291cmNlIHJlcHJlc2VudGF0aW9uIGluIG11bHRpcGxlDQo+PiA+ PiA+ICAgcmVxdWVzdC1yZXNwb25zZSBwYWlycy4gIEluIG1hbnkgaW1wb3J0YW50IGNhc2VzLCB0 aGUgQmxvY2sNCj4+b3B0aW9ucw0KPj4gPj4gPiAgIGVuYWJsZSBhIHNlcnZlciB0byBiZSB0cnVs eSBzdGF0ZWxlc3M6IHRoZSBzZXJ2ZXIgY2FuIGhhbmRsZSBlYWNoDQo+PiA+PiA+ICAgYmxvY2sg dHJhbnNmZXIgc2VwYXJhdGVseSwgd2l0aCBubyBuZWVkIGZvciBhIGNvbm5lY3Rpb24gc2V0dXAg b3INCj4+ID4+ID4gICBvdGhlciBzZXJ2ZXItc2lkZSBtZW1vcnkgb2YgcHJldmlvdXMgYmxvY2sg dHJhbnNmZXJzLg0KPj4gPj4gPg0KPj4gPj4gPiAgIEluIHN1bW1hcnksIHRoZSBCbG9jayBvcHRp b25zIHByb3ZpZGUgYSBtaW5pbWFsIHdheSB0byB0cmFuc2Zlcg0KPj4gPj4gPiAgIGxhcmdlciBy ZXByZXNlbnRhdGlvbnMgaW4gYSBibG9jay13aXNlIGZhc2hpb24uDQo+PiA+PiA+DQo+PiA+PiA+ DQo+PiA+PiA+DQo+PiA+PiA+DQo+PiA+PiA+VGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYQ0K Pj4gPj4gPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS1i bG9jay8NCj4+ID4+ID4NCj4+ID4+ID5JRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlh DQo+PiA+PiA+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3Jl LWJsb2NrL2JhbGxvdC8NCj4+ID4+ID4NCj4+ID4+ID4NCj4+ID4+ID5ObyBJUFIgZGVjbGFyYXRp b25zIGhhdmUgYmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuDQo+PiA+PiA+DQo+ PiA+PiA+DQo+PiA+Pg0KPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+ID4+IGNvcmUgbWFpbGluZyBsaXN0DQo+PiA+PiBjb3JlQGlldGYub3Jn DQo+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCj4+ID4N Cj4NCj4NCg0K From nobody Mon Feb 1 14:55:17 2016 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 6C2131B385A; Mon, 1 Feb 2016 14:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpK0i-9qBLL5; Mon, 1 Feb 2016 14:55:04 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE7D1B3858; Mon, 1 Feb 2016 14:55:04 -0800 (PST) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 31C582CA08; Mon, 1 Feb 2016 14:55:03 -0800 (PST) From: "Jim Schaad" To: =?UTF-8?Q?'G=C3=B6ran_Selander'?= , References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com> <063a01d15a22$24099250$6c1cb6f0$@augustcellars.com> <00d701d15d2f$2f849840$8e8dc8c0$@augustcellars.com> In-Reply-To: Date: Mon, 1 Feb 2016 14:52:27 -0800 Message-ID: <00e601d15d43$3b5938b0$b20baa10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQH/N40dZG+wyPslqrIqOShIBqjspwKyJuasAbm/U5kCBtFh2wJwS9oGAeJwDR+eZeePUA== Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, barryleiba@gmail.com, core@ietf.org Subject: Re: [core] Last Call: (Block-wise transfers in CoAP) to Proposed Standard 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, 01 Feb 2016 22:55:15 -0000 G=C3=B6ran, It I always more helpful to be on the same page. See below > -----Original Message----- > From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > Sent: Monday, February 01, 2016 1:55 PM > To: Jim Schaad ; ietf@ietf.org > Cc: draft-ietf-core-block@ietf.org; core-chairs@ietf.org; = core@ietf.org; > barryleiba@gmail.com > Subject: Re: [core] Last Call: = (Block-wise transfers > in CoAP) to Proposed Standard >=20 > Jim, >=20 > Yes, apparently we do talk past each other. Inline. >=20 > On 2016-02-01 21:28, "Jim Schaad" wrote: >=20 > >G=C3=B6ran, > > > >You apparently have missed the main point of what I was saying in my > >message. > > > >I see both of these cases as having a single message to be protected: > >1. I am sending a small message that does not get fragmented 2. I = am > >sending a large message that needs to be fragmented into 5 messages > >using the Block-wise transfer options. > > > >In both cases I am doing an integrity protection/encryption operation > >on a single message that might later be fragmented into multiple = pieces. >=20 > I don=E2=80=99t understand how your solution protects CoAP metadata = like Code, > Content-Format and Uri-Path. I may be wrong but it seems you are only > protecting CoAP payload, which is sufficient for certain use cases, = but for other > use cases we also need to protect metadata. The blockwise draft = applies to both > kind of use cases. Remember that I am looking at dealing with this as a single message. = There is going to be a solution for using COSE with CoAP that is = protecting the headers in a single message. I am assuming that this is = the same solution that needs to be used for dealing with the fragmented = message as well. The set of options from the fragmented message is = built into an external object which is then authenticated as part of the = process of authenticating the base block. This is where the current BLOCK draft falls apart on its own merits. It = does not discuss what should happen if the set of options is not the = same between all of the blocks. This is a problem if one is using = security or not. The correct set of headers is the set that needs to be = protected, but there is no way to determine what the set of headers is = supposed to be. >=20 >=20 > > I do not want to integrity protect each of the 5 block transfer > >messages independently because of a number of problems which you have > >pointed out about messages getting re-fragmented in transit. >=20 > My point of view is that messages should not be re-fragmented in = transit. Why do you believe that this is a problem? I cannot see any problems = with it myself. >=20 > > Additionally, I do not want to deal with each messages separately > >because I do not want to be in a situation where a block could be > >changed for a different block from a different stream. >=20 > This is not an issue if you integrity protect the appropriate Block = option, which > contains the number of the block and if it is the last. > Re-fragmentation prevents Block options from being possible to = integrity > protect between client and server. That is insufficient to provide the protection. In addition you would = need to be able to protect some value which says that all of these are = from a single fragmented message as well. This means that one would = need to ensure that this value is not reused under some set of = constraints. What happens if I received a block 4 of 5 from server A = and a block 4 of 5 from server B. The block values are going to be = correct, but they are from different streams. So protecting what stream = they are from is needed as well as making sure that there is some value = which to protect from different streams from the same server. (Ok - I = just found another thing that I need to make sure that the BLOCK draft = supports correctly.) >=20 > > > >This would be the case of sending A1 A2 A3 A4 and receiving A1 A2 B3 = A4 > >where each of the fragments individually verifies, but the entire > >stream has been changed. Doing a single integrity operation over the > >entire stream of (A1 A2 A3 A4) means that receiving (A1 A2 B3 A4) = would > >fail to validate because the entire stream of bytes would fail = validation. >=20 > This is not an issue if you integrity protect the appropriate Block = option. Not that the block option is the same for both A3 and B3. =20 NUM =3D 3, M =3D no, SZX=3D1K >=20 >=20 > > > >This means that I treat security identically if the block options are > >there or if the block options are not there. >=20 > Yes, since you focus on an over-the-top solution you can do that. But = the only > over-the-top solution I know of that protects metadata is the one = mentioned > below which moves REST out of CoAP. >=20 > > > >There are other discussions that need to be dealt with about options > >and how they interact with security, but the report of the group > >working on this has not yet come up for review. I am just worried = about > >getting this draft finished. >=20 > And I=E2=80=99m worried that this draft voids the candidate solutions = for protecting > payload and metadata. There I cannot help as I have not seen anything yet. Jim >=20 > G=C3=B6ran >=20 >=20 > > > >jim > > > >> -----Original Message----- > >> From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com] > >> Sent: Monday, February 01, 2016 12:20 AM > >> To: Jim Schaad ; ietf@ietf.org > >> Cc: draft-ietf-core-block@ietf.org; core-chairs@ietf.org; > >>core@ietf.org; barryleiba@gmail.com > >> Subject: Re: [core] Last Call: > >>(Block-wise transfers in CoAP) to Proposed Standard > >> > >> Hi Jim > >> > >> Thanks for picking up the thread. > >> > >> We spent some time in Prague thinking about this. You are right = that > >>there are different options with different characteristics. Here = are > >>the cases we have considered. > >> > >> Just to recap the objective, this is about protecting communication > >>between CoAP client and CoAP server while allowing legitimate > >>operations of one or more intermediary CoAP proxies. Client and > >>server are assumed to have a security association. > >> > >> On a high level the candidate solutions are either built entirely = on > >>top of CoAP or add new CoAP options. > >> > >> Looking at the former first, one solution is to wrap just the CoAP > >>payload/content, e.g. using COSE [1]. (We called this object = security > >>of content, OSCON). This is useful if the payload includes certain > >>meta data, like in the case of CWT, or if certain information, such > >>as resource identifier etc., is implicit from the security > >>association. > >> > >> This solution however does not protect the metadata sent in the = CoAP > >>message, such as e.g. Code (GET/DELETE/etc), Uri-Path or Content > >>Format. > >> Even if such information would be integrity protected, e.g. using > >>External-AAD in [1], it neither protects messages which do not have > >>payload, like e.g. > >>GET > >> requests, nor does it address confidentiality desirable for a = subset > >>of such metadata for privacy reasons. > >> > >> An alternative solution on top of CoAP is to move the RESTful > >>protocol out of CoAP and only use POST with some dummy Uri-Path, > >>Content Format etc. In this way all messages could carry a = protected > >>object as in [1] and the nature of the interaction and content is > >>contained in this object. This is probably violating the purpose of > >>CoAP too much to be of any interest. > >> > >> Those are the only solutions we have considered on top of CoAP. I'm > >>not sure if the solution you propose is related to one of these? > >> > >> All other solutions I'm aware of which address the general problem > >>space, e.g. > >> OSCOAP, are built "within" CoAP, using CoAP options to carry > >>protected objects (such as [1]) which include integrity protection = of > >>the payload and meta-data. > >> Now, what happens if the payload is large? If the originating > >>endpoint does the fragmentation then the destination endpoint can > >>verify the integrity. > >>If a proxy > >> using the blockwise draft (re-)fragments the payload (which also > >>changes a Block option) such that it is different when reaching the > >>destination endpoint, then integrity verification will fail. The > >>destination endpoint cannot distinguish a legitimate > >>introduction/change of payload and Block option from any other = change > >>of the message, hence it cannot verify integrity. This can be used = to > >>disable integrity protection at CoAP layer also for shorter = messages, > >>since the destination endpoint must treat the existence of a Block > >>option as a generic "security off" button. > >> > >> This is quite different from the CoAP options standardized so far > >>where you can protect individual messages between client and server > >>at the same time as allowing legitimate proxy operation, even > >>verifying that intermediate nodes has performed the correct CoAP > >>option manipulations such as e.g. when forward proxies change the > >>Uri-* options making the message reach the correct destination URI. > >> > >> IMHO CoAP should not allow an intermediate device to legitimately > >>turn off integrity protecting between client and server. CoAP = should > >>definitely support integrity protection of short messages between > >>client and server through proxies. This is where CoAP shines > >>brightly. Given that, it is straightforward to integrity protect > >>messages fragmented at the endpoints. > >> And with the Block options integrity protected the entire message > >>built up of the fragments is automatically protected as well. > >> > >> G=C3=B6ran > >> > >> [1] https://tools.ietf.org/html/draft-ietf-cose-msg > >> > >> > >> > >> > >> > >> On 2016-01-29 00:18, "Jim Schaad" wrote: > >> > >> >G=C3=B6ran, > >> > > >> >I finally got caught up on reading the CORE mailing list (lots of > >> >boredom on issues I don=E2=80=99t think I care about) and I did = not find any > >> >responses to your mail on this issue. I would like to propose a > >> >different solution to the problem which I think you will find both > >> >workable and potential not requiring any updates to the current = draft. > >> > > >> >When I read this draft the first time, I read it as a network > >> >fragmentation draft rather than as a messaging draft. As such I = did > >> >not have the same concerns about object security as you seem to = have. > >> >I made the decision that I would apply the security to the = entirety > >> >of the message being sent, and then fragment it into blocks = afterwards. > >> >Such an approach allows for a number of things that you are having > >> >problems with to be ignored. > >> > > >> >How the fragmentation is done, is change or is removed become > >> >immaterial as the end recipient would need to have all of the > >> >fragments delivered and in the correct order in order to process = the > >> >message and do validation. > >> > > >> >Overhead is smaller because the overhead of encrypting/signing at > >> >the object security level is done once rather than once per > >> >fragment. This allows for fewer bytes to be sent across the wire. > >> > > >> >The headers of the first message in the fragment are the ones that > >> >the object security system would be using both for security > >> >calculation purposes and for the receiver to process the validated = message. > >> > > >> >There are still some question that potentially need to be dealt = with: > >> > > >> >1) Are the block option headers authenticated? The probable = answer > >> >should be no as they are designed to be changed by intermediaries. > >> >This can be deferred until the general discussion about the rest = of > >> >the current headers. > >> > > >> >2) What options are required to be copied forward into subsequent > >> >messages and which can be omitted? I was unable to find any > >> >guidance on this issue from reading the document and thus would > >> >naively make the assumption that all options not specified by this > >> >document are copied forward and should be checked to make sure = that > >> >they are unchanged in future messages. However I doubt that is = the desire > of the authors. > >> >This however is not a security specific issue and needs to be > >> >addressed in this document. > >> > > >> >3) Do we want to apply per message security as well - that is an > >> >issue that can and should be punted to a future object security = draft. > >> >However, I don't see the point except to protect the ACK/NACK or > >> >lack of on each individual hop. But this is point-to-point not = end-to-end. > >> > > >> >Jim > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: core [mailto:core-bounces@ietf.org] On Behalf Of = G=C3=B6ran > >> >>Selander > >> >> Sent: Wednesday, November 25, 2015 11:07 PM > >> >> To: ietf@ietf.org > >> >> Cc: draft-ietf-core-block@ietf.org; core-chairs@ietf.org; > >> >>core@ietf.org; barryleiba@gmail.com > >> >> Subject: Re: [core] Last Call: > >> >>(Block-wise transfers in CoAP) to Proposed Standard > >> >> > >> >> > >> >> > >> >> There was a thread on the CoRE WG mailing list a couple of = months > >> >>ago on the topic of blockwise and object security. The starting > >> >>point was a question if CoAP proxies can (re-)partition messages > >> >>into blocks as defined in this draft, and the implications on > >> >>end-to-end security between client and server through such a > >> >>proxy. The conclusions of that discussion has an impact on this > >> >>draft, but there are no considerations of this kind made in > >> >>version -18. More details are given below, including some > >> >>alternative proposals for how to address this. > >> >>Apologies > >> >> for the long e-mail. > >> >> > >> >> > >> >> Background: > >> >> > >> >> There is an ongoing discussion in CoRE and ACE WGs since a year = on > >> >>the > >> >>end-to- > >> >> end security properties of CoAP, i.e. protecting the = communication > >> >>between a client and a server through proxies. RFC 7252 and = other > >> >>specifications in the CoAP suite define a set of legitimate = proxy > >> >>operations on CoAP messages which requires DTLS to be terminated > >> >>at proxies. This implies that the proxy has access not only with > >> >>the data required for perform the intended proxy operation but is > >> >>also able to eavesdrop or manipulate any part of the CoAP payload > >> >>and metadata in transit between client and server without being > >> >>protected or detected by DTLS. > >> >> > >> >> > >> >> One way to mitigate this threat is to complement or replace DTLS > >> >>with application layer protection of CoAP payload and metadata > >> >>between client and server for the use cases where the proxy = should > >> >>not be fully trusted. > >> >> This has been discussed in the CoRE WG meetings during the three > >> >>last IETF F2F meetings and there are draft solutions using the > >> >>message format being developed in the COSE WG. > >> >> > >> >> > >> >> With the COAP proxy operations standardized so far it has been > >> >>possible to protect the CoAP messages adequately with security = on > >> >>transport layer, application layer or a combination thereof. In > >> >>the case where the legitimate proxy operation is predictable by > >> >>client and server, application layer security can be defined to > >> >>both verify that no illegitimate changes has been performed as > >> >>well as verifying the legitimate changes. In the case where proxy > >> >>operations are not predictable =E2=80=94 even if the data the = proxy is > >> >>operating on cannot be protected =E2=80=94 it has so far been = possible to > >> >>use other information elements to provide the required = end-to-end > security properities. > >> >>For example, the CoAP header field Token may be changed by a > >> >>proxy, but instead a transaction identifier can be introduced in > >> >>the application security wrapper (COSE > >> >> header) to define a message (exchange) identifier common to = client > >> >>and server. > >> >> > >> >> > >> >> Blockwise: > >> >> > >> >> With the definition of blockwise transfer as specified in this > >> >>draft a proxy may partition or re-partitioning a message into > >> >>blocks where the size of the blocks are decided by the proxy. As = a > >> >>consequence, it is not possible to integrity protect individual > >> >>blocks end-to-end between client and server: DTLS does not = protect > >> >>the message data within the proxy, and application layer = integrity > >> >>protection of individual blocks cannot be performed unless the > >> >>partitioning into blocks as received by one endpoint is = identical > >> >>to that sent by the other endpoint. Hence, when CoAP Block = options > >> >>are used as defined in this draft, end-to-end security of the > >> >>individual CoAP request and response breaks down. For example: a > >> >>proxy may addBlock options, send any number of blocks with any > >> >>payload to an endpoint without being possible to detect or = protect > >> >>against. In contrast to the existing standards in the CoAP = suite, > >> >>in this case it is not possible to bypass the construction and > >> >>define a secure end-to-end block partitioning with less than > >> >>disabling block partitioning as specified in this draft. > >> >> > >> >> > >> >> One solution to this is to disallow proxies to re-partition a > >> >>message, thus redefine the Block options such that they are > >> >>possible to integrity protect end- to-end. Integrity protecting > >> >>each block and corresponding Block options as defined in the > >> >>current draft has additional benefits: If any block in the = sequence > >> >>fails verification, it can be individually requested to be = resent. > >> >>When all blocks has been verified the entire message has been > >> >>verified. A receiving node may even perform certain actions = based > >> >>on received verified blocks before the entire message has been = received. > >> >> > >> >> > >> >> Instead of delegating to proxies to partition into blocks, the > >>sending > >> >>endpoint > >> >> would need to anticipate or get information about the relevant > >> >>block size, e.g. > >> >> using a size indication in the link-format description = [RFC6990]. > >> >>Additional > >> >> methods for blocksize discovery may also be defined. > >> >> While this may not be as simple as leaving it entirely to the > >> >>proxy > >>to > >> >>decide, > >> >> considering the additional security benefits I believe this is = the > >> >>right trade off to make. > >> >> > >> >> > >> >> An alternative solution is to prevent proxies from = re-partitioning > >> >>a message only in the case where end-to-end security of CoAP > >> >>message is applied, > >>which > >> >>in > >> >> current solution proposals is indicated with the presence of a > >>certain > >> >>CoAP > >> >> option X (which e.g. contains the COSE object). > >> >> This would have the same benefits as the previous solution, but > >> >>requires the code in the proxy implementing this draft to be = aware > >> >>of option X, > >>and > >> >>hence > >> >> that dependency needs to be specified in this draft. And option = X > >> >>is > >>not > >> >> standardized yet, so would require introducing a placeholder. > >> >> > >> >> > >> >> There are other alternatives as well but this e-mail is already > >> >>too long. > >> >> The main point I wanted to make is that given that we now have a > >>better > >> >> understanding of how to achieve security between client and = server > >> >>through proxies compared to when RFC7252 was written, my opinon = is > >> >>that we should not ignore these security issues in new = standards. > >> >> > >> >> > >> >> > >> >> G=C3=B6ran > >> >> > >> >> > >> >> > >> >> On 2015-11-20 22:32, "The IESG" wrote: > >> >> > >> >> > > >> >> >The IESG has received a request from the Constrained RESTful > >> >> >Environments WG (core) to consider the following document: > >> >> >- 'Block-wise transfers in CoAP' > >> >> > as Proposed Standard > >> >> > > >> >> >The IESG plans to make a decision in the next few weeks, and > >>solicits > >> >> >final comments on this action. Please send substantive comments > >> >> >to > >>the > >> >> >ietf@ietf.org mailing lists by 2015-12-04. Exceptionally, > >> >> >comments > >>may > >> >> >be sent to iesg@ietf.org instead. In either case, please retain > >> >> >the beginning of the Subject line to allow automated sorting. > >> >> > > >> >> >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 file can be obtained via > >> >> >https://datatracker.ietf.org/doc/draft-ietf-core-block/ > >> >> > > >> >> >IESG discussion can be tracked via > >> >> >https://datatracker.ietf.org/doc/draft-ietf-core-block/ballot/ > >> >> > > >> >> > > >> >> >No IPR declarations have been submitted directly on this I-D. > >> >> > > >> >> > > >> >> > >> >> _______________________________________________ > >> >> core mailing list > >> >> core@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/core > >> > > > > > From nobody Mon Feb 1 15:15:24 2016 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 CA7421B388D; Mon, 1 Feb 2016 15:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qZmk-nKh6jDP; Mon, 1 Feb 2016 15:15:20 -0800 (PST) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C841B388C; Mon, 1 Feb 2016 15:15:20 -0800 (PST) Received: from mfilter46-d.gandi.net (mfilter46-d.gandi.net [217.70.178.177]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id D0383FB8A3; Tue, 2 Feb 2016 00:15:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter46-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter46-d.gandi.net (mfilter46-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id UDDqd5TFWWA1; Tue, 2 Feb 2016 00:15:17 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id ECF8EFB882; Tue, 2 Feb 2016 00:15:15 +0100 (CET) Message-ID: <56AFE702.2030307@tzi.org> Date: Tue, 02 Feb 2016 00:15:14 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Jim Schaad References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com> <063a01d15a22$24099250$6c1cb6f0$@augustcellars.com> <00d701d15d2f$2f849840$8e8dc8c0$@augustcellars.com> <00e601d15d43$3b5938b0$b20baa10$@augustcellars.com> In-Reply-To: <00e601d15d43$3b5938b0$b20baa10$@augustcellars.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core-chairs@ietf.org, ietf@ietf.org, core@ietf.org, draft-ietf-core-block@ietf.org, barryleiba@gmail.com Subject: Re: [core] Last Call: (Block-wise transfers in CoAP) to Proposed Standard 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, 01 Feb 2016 23:15:23 -0000 Jim Schaad wrote: > This is where the current BLOCK draft falls apart on its own merits. It does not discuss what should happen if the set of options is not the same between all of the blocks. This is a problem if one is using security or not. The correct set of headers is the set that needs to be protected, but there is no way to determine what the set of headers is supposed to be. This is not entirely true. For Content-Format, 2.3 has this discussion: The Content-Format Option sent with the requests or responses MUST reflect the content-format of the entire body. If blocks of a response body arrive with different content-format options, it is up to the client how to handle this error (it will typically abort any ongoing block-wise transfer). If blocks of a request arrive at a server with mismatching content-format options, the server MUST NOT assemble them into a single request; this usually leads to a 4.08 (Request Entity Incomplete, Section 2.9.2) error response on the mismatching block. For ETag, 2.4 has: Block-wise transfers can be used to GET resources the representations of which are entirely static (not changing over time at all, such as in a schema describing a device), or for dynamically changing resources. In the latter case, the Block2 Option SHOULD be used in conjunction with the ETag Option, to ensure that the blocks being reassembled are from the same version of the representation: The server SHOULD include an ETag option in each response. If an ETag option is available, the client's reassembler, when reassembling the representation from the blocks being exchanged, MUST compare ETag Options. If the ETag Options do not match in a GET transfer, the requester has the option of attempting to retrieve fresh values for the blocks it retrieved first. To minimize the resulting It is hard to discuss all potential options because new options may have interesting interactions with the Block options, which I hope will be specified with those options. More interesting is Max-Age, as this can change during the transfer, or Size2. Location-Path/-Query is something that is often only available at the end of the block transfer, so I would expect that to come with the block(s) carrying the 2.01. Also, 2.4 specifies: When a request is answered with a response carrying a Block2 Option with the M bit set, the requester may retrieve additional blocks of the resource representation by sending further requests with the same options as the initial request and... While I agree this could be spelled out in more detail, the information basically is there. Grüße, Carsten From nobody Tue Feb 2 02:24:22 2016 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 CB2091ACE41 for ; Tue, 2 Feb 2016 02:24:20 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Xt1l0Q2d-q9k for ; Tue, 2 Feb 2016 02:24:18 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 488A61ACE3F for ; Tue, 2 Feb 2016 02:24:18 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id 78so66492209lfy.3 for ; Tue, 02 Feb 2016 02:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=LFkb7N7AamtQ+QUmYpuzNaRDkRUPzGq3Bt24+TNHdfY=; b=KkbiEuLLForDiMtlnIhWFdblHwIO76XJPoSXEloMxZVbVRKVBipUTrUb/jYtdO8dNc VaXofvqOJteSm/z2qQaISYuZIxHxKK76ma1BKOBHY7IVyVOKubogGh9vdUQbIsHCDzrT JpDwoVqhclW2jokbKjuJvkD6DqwNNnmk0iwmwa0Ol56IzfLVWTulHP7Xb/zhDUtS8STb L05rsBQMyGOnEUI1QssdZ4Mm29jdRdapTGO+W0iAmUhprnDO/3Kj4HpaAkdatW/TyaZm kdZYG1teiuOqIy8WoxjoyjaEpKeWNChdP2ts9MP9FwZwkC3uFvHtC5T05ngDjQulFBvH PEDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=LFkb7N7AamtQ+QUmYpuzNaRDkRUPzGq3Bt24+TNHdfY=; b=Ibvjp9L/hFiJGBpIRF/Vhcf4nTFjiFhuSyduLpIFmi/6ebMcZ7IPunmyjVt+3qUz02 peLawtkk9AiMj69MpQBdo0FdJPDfl3wOAyLG1e3FWrszxC8MaXpFMl2Yyi4gl1LXclSI NxsJ6PiHDegzKAggiA8J5f0ZFNkok7/wbMpJQLb20lh67e6elvU8eqGFkdvCYP9cGvDB h4Wo8AZ3dIYAEmDicOAeDyLBPffYXmwn0Ug5eGV1OiL9+gaZ/M2VSZCsy2sUGePVx6dr ijs64Og3jF63uqd4MLgdvPEfkihJLdnvOLgWjwJrAStR9AQoA4f8LJxCYltponsGACyA z3GQ== X-Gm-Message-State: AG10YOSUaatCBPzymyN7WKXUQz1qYnWFxmOXXj9BIcJ6jfKQAtP/RZ5EHe9gpQSpi9TkvbaA X-Received: by 10.25.159.9 with SMTP id i9mr11282875lfe.109.1454408656499; Tue, 02 Feb 2016 02:24:16 -0800 (PST) Received: from Hyperion.suse ([85.235.10.186]) by smtp.gmail.com with ESMTPSA id m64sm106151lfd.32.2016.02.02.02.24.15 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Feb 2016 02:24:15 -0800 (PST) To: core@ietf.org References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com> <063a01d15a22$24099250$6c1cb6f0$@augustcellars.com> <56AB166F.9040404@tzi.org> From: Ludwig Seitz Message-ID: <56B083CE.40307@sics.se> Date: Tue, 2 Feb 2016 11:24:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56AB166F.9040404@tzi.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060805060104030800060606" Archived-At: Subject: Re: [core] Last Call: (Block-wise transfers in CoAP) to Proposed Standard 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, 02 Feb 2016 10:24:21 -0000 This is a cryptographically signed message in MIME format. --------------ms060805060104030800060606 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 01/29/2016 08:36 AM, Carsten Bormann wrote: > Hi Jim, > > [...] I think the biggest remaining question with this > is what to do against an attacker polluting a cache with a bad block > (creating a problem for availability, not integrity). (In RFC7252's > security model, DTLS prevents that from happening.) > I think that this is the point we were considering when we thought it=20 would be good to protect individual fragments. If you receive a fragment, you'd like to be able to verify that it is=20 legit, before you store it, and before you request further fragments. Otherwise it's just to easy to fill up the memory of a constrained=20 device with junk. /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=C3=A4gen 17 SE-223 70 Lund Phone +46(0)70 349 9251 http://www.sics.se --------------ms060805060104030800060606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtEwggTnMIIDz6ADAgECAhAfP2QWc8z7Bo71GhHCZ7DdMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMTA3MTE1NzM3WhcNMTcwMTA3MTE1NzM3WjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiG5fxnXbdU0+3qInGZloXB0zZLM6XAu0EmTuCsWOU8eXN lCe37PTURORfLc3te4gCDcG1GrI2AuWR9MvlcYddMZt5y0T5BVWIu534vVJtG3QCuEYRJOTW B6RWQfK+dIPpZsNhgEQkYLjTHYoCu58gP0pfxNie1X7D+RxeQcq+ynNmyFdsxc2mI+dQqBKq 4zTsCNP4/jpSuovXTn8hEbbR8zkVQ2v/Gx+EO8oMIvkIEUYzkMxe3E9A7dq5DwotRDzP+y3g C4DCtI0tfIUtFjx18Pb5UMNUKZjitrOpXfheEz/igxziydri8bYpx4qGU9CNX+MvQG7Ogqju XKfQhUTTAgMBAAGjggGuMIIBqjALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFBMb8zf+BJ13fxqEl9gYiwxZ4hpmMB8G A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYn aHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCBDmx1 ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNV HSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAbgRzIj1s9U5kpXodti5kdj3ztjPb oz4pz8zNwn3qPUW8c3Zd40IFe+R5hRDuIm2aa//fmwop2mLM3+5/LnSnacaDnRfE7pP3NgqX XUuuZf9TtMLU6RUh2Z9JKs0IzWKALPhoLgnCsbtYDrF4QAoVqeNV79Lb6a3r6KdB/xFErbee OkZk/iw9HCr/jnvysYjfFQcBounseJS3JG4RNIuDpfsWPupQSAhl4s0akaakiwqOHCU7x0Ra rbCN+bg+6R5FEtSouIh53Z04JmI7LU3leo/AseQiUpJ6HqQNJYjnsCw8DDbijNhH41ZZKrvB rKMfVvlCH9VqrKW4kPGajKMEJDCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJ KoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIx NjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNV BAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENv bSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL19 2vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk 9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89V LnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZ ZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4G A1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/ BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9z ZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFy dHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2Nh LmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4St DwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y 5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bj yOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfC BJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odh QJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfr Bzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4W VWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9Vyrw MdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAfP2QWc8z7Bo71 GhHCZ7DdMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNjAyMDIxMDI0MTRaMC8GCSqGSIb3DQEJBDEiBCDh8bTS3r4+cDog MaogZ9QWZckAS/UyOHEZ2IZSs1WMlDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQHz9kFnPM+waO9RoRwmew3TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ Hz9kFnPM+waO9RoRwmew3TANBgkqhkiG9w0BAQEFAASCAQCC9+eMoLUMeFfledsE1Zr2ye/d Xg1g+jg+Lbe2Wj77Rh4fcH8cj9QHMyaxF16f/Huo+i3RXyJPyMsM6bTWXSy9s+DhIeYOyyZl 48clqblNXUV1mcAQCdSbhwec77KohSs+DtV9Akac3dYwcYpZvL/Jc/f0GgxCi2eZlXtaSj0L 4RH1j6hZCSvt/KXxjOhTbrHorR202tPFODk26YqYINkfFz7AKJgISXKFyG+xq0FV4j9aSOoh kX062lPUznvPUDcHyQH2N0RStbnnUClJokf70wqQ9/jvob6JF2Xw3WkTdzl5SNWGVh0RSE5p JYR/jF6tthqwSUJq11NMgT8YUC6UAAAAAAAA --------------ms060805060104030800060606-- From nobody Tue Feb 2 06:28:23 2016 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 1AACA1AC399; Tue, 2 Feb 2016 06:28:22 -0800 (PST) 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 i19A63DHBEna; Tue, 2 Feb 2016 06:28:17 -0800 (PST) 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 61F0C1A9166; Tue, 2 Feb 2016 06:28:15 -0800 (PST) X-AuditID: c1b4fb25-f797e6d000007600-8a-56b0bcfdcdb4 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 08.C7.30208.DFCB0B65; Tue, 2 Feb 2016 15:28:13 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.151]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Tue, 2 Feb 2016 15:27:58 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "ietf@ietf.org" Thread-Topic: [core] Last Call: (Block-wise transfers in CoAP) to Proposed Standard Thread-Index: AQHRI9sb/ga71FS+3UKAe+rFI8Rp+56t6kEAgGQBhwCABV8vgIAAuuuAgAAozgD///9IgIABFicA Date: Tue, 2 Feb 2016 14:27:58 +0000 Message-ID: References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com> <063a01d15a22$24099250$6c1cb6f0$@augustcellars.com> <00d701d15d2f$2f849840$8e8dc8c0$@augustcellars.com> <00e601d15d43$3b5938b0$b20baa10$@augustcellars.com> In-Reply-To: <00e601d15d43$3b5938b0$b20baa10$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-ID: <1C82659FE016914A95A17CFF76F5B90C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGIsWRmVeSWpSXmKPExsUyM2K7pe7fPRvCDNr/qVt8f36NxWLbxgts Fvverme2aDw0j9Fi9fTvbBbPNs5ncWDz2DhnOpvHzll32T2WLPnJFMAcxWWTkpqTWZZapG+X wJXxqPMac8GWfqaKhbt6mBsYd3QwdTFyckgImEhs+nGYBcIWk7hwbz1bFyMXh5DAYUaJB+/m sUM4ixkl3hy/zw5SxSbgIvGg4RFYt4iAh8St51NYQYqYBU4Adfw/DJYQFiiW+Nq2iR2iqETi wumNbBB2lMSi/TtYQWwWARWJr6dnMoLYvAIWEq3vLzJCbPvAJPF6zUSwmzgFHCROfl7PDGIz At33/dQasAXMAuISt57Mh/pBQGLJnvPMELaoxMvH/4AWcHCICuhJdB2pADElBBQllvfLgZjM ApoS63fpQwyxllj6/xkbhK0oMaX7ITvENYISJ2c+YZnAKDELya5ZCN2zkHTPQtI9C0n3AkbW VYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBsXtwy2/VHYyX3zgeYhTgYFTi4S14vD5MiDWx rLgy9xCjBAezkgjv/vQNYUK8KYmVValF+fFFpTmpxYcYpTlYlMR51zgDVQukJ5akZqemFqQW wWSZODilGhh54oX1+nNPveeKcWH6lKBytEr5F1fGqrysX55e/B/OLvUuvje9Jfr2RCP904y7 izm9z1Z+33qPuaU5ddKi1Cc+P2fP673r39C2Vdb3UuGOBw4PVnG9LlNIkJ8XqGPXzq1m/7nr TmNc05E9QSsjn82ZuSPqhYBGI/dEHeNZ89/vWpPy9W12U4kSS3FGoqEWc1FxIgBrewch2QIA AA== Archived-At: Cc: "draft-ietf-core-block@ietf.org" , "core-chairs@ietf.org" , "barryleiba@gmail.com" , "core@ietf.org" Subject: Re: [core] Last Call: (Block-wise transfers in CoAP) to Proposed Standard 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, 02 Feb 2016 14:28:22 -0000 SmltLA0KDQpPbiAyMDE2LTAyLTAxIDIzOjUyLCAiSmltIFNjaGFhZCIgPGlldGZAYXVndXN0Y2Vs bGFycy5jb20+IHdyb3RlOg0KDQo+R8O2cmFuLA0KPg0KPkl0IEkgYWx3YXlzIG1vcmUgaGVscGZ1 bCB0byBiZSBvbiB0aGUgc2FtZSBwYWdlLg0KDQpZZXMsIEkgaG9wZSB3ZSBnZXQgdGhlcmUgc29v biA6LSkgQ2xlYXJseSB3ZSBoYXZlIGRpZmZlcmVudCBzb2x1dGlvbnMgaW4NCm1pbmQgYW5kIHZh bHVlIHRoZSBkcmF3YmFja3MgZGlmZmVyZW50bHkuDQoNCk1vcmUgaW5saW5lLg0KDQoNCj4NCj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBHw7ZyYW4gU2VsYW5kZXIgW21h aWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb21dDQo+PiBTZW50OiBNb25kYXksIEZlYnJ1 YXJ5IDAxLCAyMDE2IDE6NTUgUE0NCj4+IFRvOiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxh cnMuY29tPjsgaWV0ZkBpZXRmLm9yZw0KPj4gQ2M6IGRyYWZ0LWlldGYtY29yZS1ibG9ja0BpZXRm Lm9yZzsgY29yZS1jaGFpcnNAaWV0Zi5vcmc7IGNvcmVAaWV0Zi5vcmc7DQo+PiBiYXJyeWxlaWJh QGdtYWlsLmNvbQ0KPj4gU3ViamVjdDogUmU6IFtjb3JlXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRm LWNvcmUtYmxvY2stMTgudHh0Pg0KPj4oQmxvY2std2lzZSB0cmFuc2ZlcnMNCj4+IGluIENvQVAp IHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+PiANCj4+IEppbSwNCj4+IA0KPj4gWWVzLCBhcHBhcmVu dGx5IHdlIGRvIHRhbGsgcGFzdCBlYWNoIG90aGVyLiBJbmxpbmUuDQo+PiANCj4+IE9uIDIwMTYt MDItMDEgMjE6MjgsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4gd3JvdGU6 DQo+PiANCj4+ID5Hw7ZyYW4sDQo+PiA+DQo+PiA+WW91IGFwcGFyZW50bHkgaGF2ZSBtaXNzZWQg dGhlIG1haW4gcG9pbnQgb2Ygd2hhdCBJIHdhcyBzYXlpbmcgaW4gbXkNCj4+ID5tZXNzYWdlLg0K Pj4gPg0KPj4gPkkgc2VlIGJvdGggb2YgdGhlc2UgY2FzZXMgYXMgaGF2aW5nIGEgc2luZ2xlIG1l c3NhZ2UgdG8gYmUgcHJvdGVjdGVkOg0KPj4gPjEuICBJIGFtIHNlbmRpbmcgYSBzbWFsbCBtZXNz YWdlIHRoYXQgZG9lcyBub3QgZ2V0IGZyYWdtZW50ZWQgMi4gIEkgYW0NCj4+ID5zZW5kaW5nIGEg bGFyZ2UgbWVzc2FnZSB0aGF0IG5lZWRzIHRvIGJlIGZyYWdtZW50ZWQgaW50byA1IG1lc3NhZ2Vz DQo+PiA+dXNpbmcgdGhlIEJsb2NrLXdpc2UgdHJhbnNmZXIgb3B0aW9ucy4NCj4+ID4NCj4+ID5J biBib3RoIGNhc2VzIEkgYW0gZG9pbmcgYW4gaW50ZWdyaXR5IHByb3RlY3Rpb24vZW5jcnlwdGlv biBvcGVyYXRpb24NCj4+ID5vbiBhIHNpbmdsZSBtZXNzYWdlIHRoYXQgbWlnaHQgbGF0ZXIgYmUg ZnJhZ21lbnRlZCBpbnRvIG11bHRpcGxlDQo+PnBpZWNlcy4NCj4+IA0KPj4gSSBkb27igJl0IHVu ZGVyc3RhbmQgaG93IHlvdXIgc29sdXRpb24gcHJvdGVjdHMgQ29BUCBtZXRhZGF0YSBsaWtlIENv ZGUsDQo+PiBDb250ZW50LUZvcm1hdCBhbmQgVXJpLVBhdGguIEkgbWF5IGJlIHdyb25nIGJ1dCBp dCBzZWVtcyB5b3UgYXJlIG9ubHkNCj4+IHByb3RlY3RpbmcgQ29BUCBwYXlsb2FkLCB3aGljaCBp cyBzdWZmaWNpZW50IGZvciBjZXJ0YWluIHVzZSBjYXNlcywgYnV0DQo+PmZvciBvdGhlcg0KPj4g dXNlIGNhc2VzIHdlIGFsc28gbmVlZCB0byBwcm90ZWN0IG1ldGFkYXRhLiBUaGUgYmxvY2t3aXNl IGRyYWZ0IGFwcGxpZXMNCj4+dG8gYm90aA0KPj4ga2luZCBvZiB1c2UgY2FzZXMuDQo+DQo+UmVt ZW1iZXIgdGhhdCBJIGFtIGxvb2tpbmcgYXQgZGVhbGluZyB3aXRoIHRoaXMgYXMgYSBzaW5nbGUg bWVzc2FnZS4NCj5UaGVyZSBpcyBnb2luZyB0byBiZSBhIHNvbHV0aW9uIGZvciB1c2luZyBDT1NF IHdpdGggQ29BUCB0aGF0IGlzDQo+cHJvdGVjdGluZyB0aGUgaGVhZGVycyBpbiBhIHNpbmdsZSBt ZXNzYWdlLiAgSSBhbSBhc3N1bWluZyB0aGF0IHRoaXMgaXMNCj50aGUgc2FtZSBzb2x1dGlvbiB0 aGF0IG5lZWRzIHRvIGJlIHVzZWQgZm9yIGRlYWxpbmcgd2l0aCB0aGUgZnJhZ21lbnRlZA0KPm1l c3NhZ2UgYXMgd2VsbC4gIFRoZSBzZXQgb2Ygb3B0aW9ucyBmcm9tIHRoZSBmcmFnbWVudGVkIG1l c3NhZ2UgaXMgYnVpbHQNCj5pbnRvIGFuIGV4dGVybmFsIG9iamVjdCB3aGljaCBpcyB0aGVuIGF1 dGhlbnRpY2F0ZWQgYXMgcGFydCBvZiB0aGUNCj5wcm9jZXNzIG9mIGF1dGhlbnRpY2F0aW5nIHRo ZSBiYXNlIGJsb2NrLg0KPg0KPlRoaXMgaXMgd2hlcmUgdGhlIGN1cnJlbnQgQkxPQ0sgZHJhZnQg ZmFsbHMgYXBhcnQgb24gaXRzIG93biBtZXJpdHMuICBJdA0KPmRvZXMgbm90IGRpc2N1c3Mgd2hh dCBzaG91bGQgaGFwcGVuIGlmIHRoZSBzZXQgb2Ygb3B0aW9ucyBpcyBub3QgdGhlIHNhbWUNCj5i ZXR3ZWVuIGFsbCBvZiB0aGUgYmxvY2tzLiBUaGlzIGlzIGEgcHJvYmxlbSBpZiBvbmUgaXMgdXNp bmcgc2VjdXJpdHkgb3INCj5ub3QuICBUaGUgY29ycmVjdCBzZXQgb2YgaGVhZGVycyBpcyB0aGUg c2V0IHRoYXQgbmVlZHMgdG8gYmUgcHJvdGVjdGVkLA0KPmJ1dCB0aGVyZSBpcyBubyB3YXkgdG8g ZGV0ZXJtaW5lIHdoYXQgdGhlIHNldCBvZiBoZWFkZXJzIGlzIHN1cHBvc2VkIHRvDQo+YmUuDQo+ DQo+PiANCj4+IA0KPj4gPiBJIGRvIG5vdCB3YW50IHRvIGludGVncml0eSBwcm90ZWN0IGVhY2gg b2YgdGhlIDUgYmxvY2sgdHJhbnNmZXINCj4+ID5tZXNzYWdlcyBpbmRlcGVuZGVudGx5IGJlY2F1 c2Ugb2YgYSBudW1iZXIgb2YgcHJvYmxlbXMgd2hpY2ggeW91IGhhdmUNCj4+ID5wb2ludGVkIG91 dCBhYm91dCBtZXNzYWdlcyBnZXR0aW5nIHJlLWZyYWdtZW50ZWQgaW4gdHJhbnNpdC4NCj4+IA0K Pj4gTXkgcG9pbnQgb2YgdmlldyBpcyB0aGF0IG1lc3NhZ2VzIHNob3VsZCBub3QgYmUgcmUtZnJh Z21lbnRlZCBpbg0KPj50cmFuc2l0Lg0KPg0KPldoeSBkbyB5b3UgYmVsaWV2ZSB0aGF0IHRoaXMg aXMgYSBwcm9ibGVtPyAgSSBjYW5ub3Qgc2VlIGFueSBwcm9ibGVtcw0KPndpdGggaXQgbXlzZWxm Lg0KDQoNCkkgZmluZCBpdCBwcm9ibGVtYXRpYyB3aXRoIGEgQmxvY2sgb3B0aW9uIHdoaWNoIHdo ZW5ldmVyIHVzZWQgaGFzIGFzDQplZmZlY3QgdGhhdCB0aGUgcmVjZWl2ZXIgY2Fubm90IHZlcmlm eSB0aGUgaW50ZWdyaXR5IG9mIHRoZSByZWNlaXZlZCBDb0FQDQptZXNzYWdlOyB0aGF0IHJlcXVp cmVzIHRoZSBtZXNzYWdlIHRvIGJlIGNhY2hlZDsgYW5kIHRoYXQgb25seSBhZnRlcg0KaGF2aW5n IHJlY2VpdmVkIGFuIHVuc3BlY2lmaWVkIG51bWJlciBvZiBzdWJzZXF1ZW50IG1lc3NhZ2VzIGl0 IGlzIG1heWJlDQpwb3NzaWJsZSB0byB2ZXJpZnkgdGhlIGludGVncml0eSBvZi4NCg0KDQoNCj4N Cj4+IA0KPj4gPiBBZGRpdGlvbmFsbHksIEkgZG8gbm90IHdhbnQgdG8gZGVhbCB3aXRoIGVhY2gg bWVzc2FnZXMgc2VwYXJhdGVseQ0KPj4gPmJlY2F1c2UgSSBkbyBub3Qgd2FudCB0byBiZSBpbiBh IHNpdHVhdGlvbiB3aGVyZSBhIGJsb2NrIGNvdWxkIGJlDQo+PiA+Y2hhbmdlZCBmb3IgYSBkaWZm ZXJlbnQgYmxvY2sgZnJvbSBhIGRpZmZlcmVudCBzdHJlYW0uDQo+PiANCj4+IFRoaXMgaXMgbm90 IGFuIGlzc3VlIGlmIHlvdSBpbnRlZ3JpdHkgcHJvdGVjdCB0aGUgYXBwcm9wcmlhdGUgQmxvY2sN Cj4+b3B0aW9uLCB3aGljaA0KPj4gY29udGFpbnMgdGhlIG51bWJlciBvZiB0aGUgYmxvY2sgYW5k IGlmIGl0IGlzIHRoZSBsYXN0Lg0KPj4gUmUtZnJhZ21lbnRhdGlvbiBwcmV2ZW50cyBCbG9jayBv cHRpb25zIGZyb20gYmVpbmcgcG9zc2libGUgdG8gaW50ZWdyaXR5DQo+PiBwcm90ZWN0IGJldHdl ZW4gY2xpZW50IGFuZCBzZXJ2ZXIuDQo+DQo+VGhhdCBpcyBpbnN1ZmZpY2llbnQgdG8gcHJvdmlk ZSB0aGUgcHJvdGVjdGlvbi4gIEluIGFkZGl0aW9uIHlvdSB3b3VsZA0KPm5lZWQgdG8gYmUgYWJs ZSB0byBwcm90ZWN0IHNvbWUgdmFsdWUgd2hpY2ggc2F5cyB0aGF0IGFsbCBvZiB0aGVzZSBhcmUN Cj5mcm9tIGEgc2luZ2xlIGZyYWdtZW50ZWQgbWVzc2FnZSBhcyB3ZWxsLiAgVGhpcyBtZWFucyB0 aGF0IG9uZSB3b3VsZCBuZWVkDQo+dG8gZW5zdXJlIHRoYXQgdGhpcyB2YWx1ZSBpcyBub3QgcmV1 c2VkIHVuZGVyIHNvbWUgc2V0IG9mIGNvbnN0cmFpbnRzLg0KPldoYXQgaGFwcGVucyBpZiBJIHJl Y2VpdmVkIGEgYmxvY2sgNCBvZiA1IGZyb20gc2VydmVyIEEgYW5kIGEgYmxvY2sgNCBvZg0KPjUg ZnJvbSBzZXJ2ZXIgQi4gIFRoZSBibG9jayB2YWx1ZXMgYXJlIGdvaW5nIHRvIGJlIGNvcnJlY3Qs IGJ1dCB0aGV5IGFyZQ0KPmZyb20gZGlmZmVyZW50IHN0cmVhbXMuICBTbyBwcm90ZWN0aW5nIHdo YXQgc3RyZWFtIHRoZXkgYXJlIGZyb20gaXMNCj5uZWVkZWQgYXMgd2VsbCBhcyBtYWtpbmcgc3Vy ZSB0aGF0IHRoZXJlIGlzIHNvbWUgdmFsdWUgd2hpY2ggdG8gcHJvdGVjdA0KPmZyb20gZGlmZmVy ZW50IHN0cmVhbXMgZnJvbSB0aGUgc2FtZSBzZXJ2ZXIuICAoT2sgLSBJIGp1c3QgZm91bmQgYW5v dGhlcg0KPnRoaW5nIHRoYXQgSSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBCTE9DSyBkcmFm dCBzdXBwb3J0cyBjb3JyZWN0bHkuKQ0KDQpBcyBtZW50aW9uZWQsIHdlIGFzc3VtZSBhIHNlY3Vy aXR5IGFzc29jaWF0aW9uIHBlciBzZXJ2ZXIgc28gd2UgY2FuIHRlbGwNCmFwYXJ0IGJsb2NrcyBm cm9tIGRpZmZlcmVudCBzZXJ2ZXJzLiBGb3IgT1NDT0FQIHdlIGFzc3VtZSBhIGZyZXNobmVzcw0K cGFyYW1ldGVyIHdoaWNoIGNvdWxkIHBvdGVudGlhbGx5IGJlIHVzZWQgdG8gZGlzdGluZ3Vpc2gg ZGlmZmVyZW50DQpmcmFnbWVudHMgZnJvbSB0aGUgc2FtZSBzZXJ2ZXIsIHVubGVzcyB0aGVyZSBp cyBwYXJhbGxlbCB0cmFuc21pc3Npb24gb2YNCmRpZmZlcmVudCBzdHJlYW1zLiBBbmQgYXMgeW91 IG5vdGVkLCBpbiB0aGF0IGNhc2UgdGhlcmUgbXVzdCBiZSBzb21lIG90aGVyDQp3YXkgdG8gZGlz dGluZ3Vpc2ggdGhlIGZyYWdtZW50cywgYW5kIHRoYXQgaW5mb3JtYXRpb24gaXMgcG90ZW50aWFs bHkNCmFscmVhZHkgaW50ZWdyaXR5IHByb3RlY3RlZCAoZS5nLiBieSBiZWluZyBwYXJ0IG9mIGFu IG9wdGlvbiB0aGF0IGlzDQppbnRlZ3JpdHkgcHJvdGVjdGVkKSBvciBjYW4gYmVjb21lIGludGVn cml0eSBwcm90ZWN0ZWQuDQoNCg0KPg0KPj4gDQo+PiA+DQo+PiA+VGhpcyB3b3VsZCBiZSB0aGUg Y2FzZSBvZiBzZW5kaW5nIEExIEEyIEEzIEE0IGFuZCByZWNlaXZpbmcgQTEgQTIgQjMgQTQNCj4+ ID53aGVyZSBlYWNoIG9mIHRoZSBmcmFnbWVudHMgaW5kaXZpZHVhbGx5IHZlcmlmaWVzLCBidXQg dGhlIGVudGlyZQ0KPj4gPnN0cmVhbSBoYXMgYmVlbiBjaGFuZ2VkLiAgRG9pbmcgYSBzaW5nbGUg aW50ZWdyaXR5IG9wZXJhdGlvbiBvdmVyIHRoZQ0KPj4gPmVudGlyZSBzdHJlYW0gb2YgKEExIEEy IEEzIEE0KSBtZWFucyB0aGF0IHJlY2VpdmluZyAoQTEgQTIgQjMgQTQpIHdvdWxkDQo+PiA+ZmFp bCB0byB2YWxpZGF0ZSBiZWNhdXNlIHRoZSBlbnRpcmUgc3RyZWFtIG9mIGJ5dGVzIHdvdWxkIGZh aWwNCj4+dmFsaWRhdGlvbi4NCj4+IA0KPj4gVGhpcyBpcyBub3QgYW4gaXNzdWUgaWYgeW91IGlu dGVncml0eSBwcm90ZWN0IHRoZSBhcHByb3ByaWF0ZSBCbG9jaw0KPj5vcHRpb24uDQo+DQo+Tm90 IHRoYXQgdGhlIGJsb2NrIG9wdGlvbiAgaXMgdGhlIHNhbWUgZm9yIGJvdGggQTMgYW5kIEIzLg0K Pk5VTSA9IDMsIE0gPSBubywgU1pYPTFLDQoNCldlbGwgSSBtZWFudCB5b3UgaW50ZWdyaXR5IHBy b3RlY3QgYWxzbyB0aGUgQmxvY2sgb3B0aW9uLCBpbiBhZGRpdGlvbiB0bw0KdGhlIG90aGVyIG9w dGlvbnMsIHBheWxvYWQgYW5kIGZyZXNobmVzcyBwYXJhbWV0ZXIuDQoNCj4NCj4+IA0KPj4gDQo+ PiA+DQo+PiA+VGhpcyBtZWFucyB0aGF0IEkgdHJlYXQgc2VjdXJpdHkgaWRlbnRpY2FsbHkgaWYg dGhlIGJsb2NrIG9wdGlvbnMgYXJlDQo+PiA+dGhlcmUgb3IgaWYgdGhlIGJsb2NrIG9wdGlvbnMg YXJlIG5vdCB0aGVyZS4NCj4+IA0KPj4gWWVzLCBzaW5jZSB5b3UgZm9jdXMgb24gYW4gb3Zlci10 aGUtdG9wIHNvbHV0aW9uIHlvdSBjYW4gZG8gdGhhdC4gQnV0DQo+PnRoZSBvbmx5DQo+PiBvdmVy LXRoZS10b3Agc29sdXRpb24gSSBrbm93IG9mIHRoYXQgcHJvdGVjdHMgbWV0YWRhdGEgaXMgdGhl IG9uZQ0KPj5tZW50aW9uZWQNCj4+IGJlbG93IHdoaWNoIG1vdmVzIFJFU1Qgb3V0IG9mIENvQVAu DQo+PiANCj4+ID4NCj4+ID5UaGVyZSBhcmUgb3RoZXIgZGlzY3Vzc2lvbnMgdGhhdCBuZWVkIHRv IGJlIGRlYWx0IHdpdGggYWJvdXQgb3B0aW9ucw0KPj4gPmFuZCBob3cgdGhleSBpbnRlcmFjdCB3 aXRoIHNlY3VyaXR5LCBidXQgdGhlIHJlcG9ydCBvZiB0aGUgZ3JvdXANCj4+ID53b3JraW5nIG9u IHRoaXMgaGFzIG5vdCB5ZXQgY29tZSB1cCBmb3IgcmV2aWV3LiBJIGFtIGp1c3Qgd29ycmllZCBh Ym91dA0KPj4gPmdldHRpbmcgdGhpcyBkcmFmdCBmaW5pc2hlZC4NCj4+IA0KPj4gQW5kIEnigJlt IHdvcnJpZWQgdGhhdCB0aGlzIGRyYWZ0IHZvaWRzIHRoZSBjYW5kaWRhdGUgc29sdXRpb25zIGZv cg0KPj5wcm90ZWN0aW5nDQo+PiBwYXlsb2FkIGFuZCBtZXRhZGF0YS4NCj4NCj5UaGVyZSBJIGNh bm5vdCBoZWxwIGFzIEkgaGF2ZSBub3Qgc2VlbiBhbnl0aGluZyB5ZXQuDQoNClNvcnJ5LCBJIHRo b3VnaHQgaXQgd2FzIGNsZWFyIHRoYXQgSSB3YXMgcmVmZXJyaW5nIHRvIGNvbnN0cnVjdGlvbnMg bGlrZQ0KZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eSBvciBkcmFmdC1iZXJnbWFu bi1hY2UtZGNhZi1jb3NlLg0KDQpHw7ZyYW4NCg0KDQo+DQo+SmltDQo+DQo+PiANCj4+IEfDtnJh bg0KPj4gDQo+PiANCj4+ID4NCj4+ID5qaW0NCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBHw7ZyYW4gU2VsYW5kZXIgW21haWx0bzpnb3Jhbi5zZWxh bmRlckBlcmljc3Nvbi5jb21dDQo+PiA+PiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDAxLCAyMDE2 IDEyOjIwIEFNDQo+PiA+PiBUbzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47 IGlldGZAaWV0Zi5vcmcNCj4+ID4+IENjOiBkcmFmdC1pZXRmLWNvcmUtYmxvY2tAaWV0Zi5vcmc7 IGNvcmUtY2hhaXJzQGlldGYub3JnOw0KPj4gPj5jb3JlQGlldGYub3JnOyAgYmFycnlsZWliYUBn bWFpbC5jb20NCj4+ID4+IFN1YmplY3Q6IFJlOiBbY29yZV0gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0 Zi1jb3JlLWJsb2NrLTE4LnR4dD4NCj4+ID4+KEJsb2NrLXdpc2UgdHJhbnNmZXJzICBpbiBDb0FQ KSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPj4gPj4NCj4+ID4+IEhpIEppbQ0KPj4gPj4NCj4+ID4+ IFRoYW5rcyBmb3IgcGlja2luZyB1cCB0aGUgdGhyZWFkLg0KPj4gPj4NCj4+ID4+IFdlIHNwZW50 IHNvbWUgdGltZSBpbiBQcmFndWUgdGhpbmtpbmcgYWJvdXQgdGhpcy4gWW91IGFyZSByaWdodCB0 aGF0DQo+PiA+PnRoZXJlIGFyZSAgZGlmZmVyZW50IG9wdGlvbnMgd2l0aCBkaWZmZXJlbnQgY2hh cmFjdGVyaXN0aWNzLiBIZXJlIGFyZQ0KPj4gPj50aGUgY2FzZXMgd2UgaGF2ZSAgY29uc2lkZXJl ZC4NCj4+ID4+DQo+PiA+PiBKdXN0IHRvIHJlY2FwIHRoZSBvYmplY3RpdmUsIHRoaXMgaXMgYWJv dXQgcHJvdGVjdGluZyBjb21tdW5pY2F0aW9uDQo+PiA+PmJldHdlZW4gIENvQVAgY2xpZW50IGFu ZCBDb0FQIHNlcnZlciB3aGlsZSBhbGxvd2luZyBsZWdpdGltYXRlDQo+PiA+Pm9wZXJhdGlvbnMg b2Ygb25lIG9yICBtb3JlIGludGVybWVkaWFyeSBDb0FQIHByb3hpZXMuIENsaWVudCBhbmQNCj4+ ID4+c2VydmVyIGFyZSBhc3N1bWVkIHRvIGhhdmUgYSAgc2VjdXJpdHkgYXNzb2NpYXRpb24uDQo+ PiA+Pg0KPj4gPj4gT24gYSBoaWdoIGxldmVsIHRoZSBjYW5kaWRhdGUgc29sdXRpb25zIGFyZSBl aXRoZXIgYnVpbHQgZW50aXJlbHkgb24NCj4+ID4+dG9wIG9mIENvQVAgb3IgIGFkZCBuZXcgQ29B UCBvcHRpb25zLg0KPj4gPj4NCj4+ID4+IExvb2tpbmcgYXQgdGhlIGZvcm1lciBmaXJzdCwgb25l IHNvbHV0aW9uIGlzIHRvIHdyYXAganVzdCB0aGUgQ29BUA0KPj4gPj5wYXlsb2FkL2NvbnRlbnQs IGUuZy4gdXNpbmcgQ09TRSBbMV0uIChXZSBjYWxsZWQgdGhpcyBvYmplY3Qgc2VjdXJpdHkNCj4+ ID4+b2YgY29udGVudCwgIE9TQ09OKS4gVGhpcyBpcyB1c2VmdWwgaWYgdGhlIHBheWxvYWQgaW5j bHVkZXMgY2VydGFpbg0KPj4gPj5tZXRhIGRhdGEsIGxpa2UgaW4gdGhlIGNhc2UgIG9mIENXVCwg b3IgaWYgY2VydGFpbiBpbmZvcm1hdGlvbiwgc3VjaA0KPj4gPj5hcyByZXNvdXJjZSBpZGVudGlm aWVyIGV0Yy4sIGlzIGltcGxpY2l0ICBmcm9tIHRoZSBzZWN1cml0eQ0KPj4gPj5hc3NvY2lhdGlv bi4NCj4+ID4+DQo+PiA+PiBUaGlzIHNvbHV0aW9uIGhvd2V2ZXIgZG9lcyBub3QgcHJvdGVjdCB0 aGUgbWV0YWRhdGEgc2VudCBpbiB0aGUgQ29BUA0KPj4gPj5tZXNzYWdlLCAgc3VjaCBhcyBlLmcu IENvZGUgKEdFVC9ERUxFVEUvZXRjKSwgVXJpLVBhdGggb3IgQ29udGVudA0KPj4gPj5Gb3JtYXQu DQo+PiA+PiBFdmVuIGlmIHN1Y2ggaW5mb3JtYXRpb24gd291bGQgYmUgaW50ZWdyaXR5IHByb3Rl Y3RlZCwgZS5nLiB1c2luZw0KPj4gPj5FeHRlcm5hbC1BQUQgaW4gIFsxXSwgaXQgbmVpdGhlciBw cm90ZWN0cyBtZXNzYWdlcyB3aGljaCBkbyBub3QgaGF2ZQ0KPj4gPj5wYXlsb2FkLCBsaWtlIGUu Zy4NCj4+ID4+R0VUDQo+PiA+PiByZXF1ZXN0cywgbm9yIGRvZXMgaXQgYWRkcmVzcyBjb25maWRl bnRpYWxpdHkgZGVzaXJhYmxlIGZvciBhIHN1YnNldA0KPj4gPj5vZiBzdWNoICBtZXRhZGF0YSBm b3IgcHJpdmFjeSByZWFzb25zLg0KPj4gPj4NCj4+ID4+IEFuIGFsdGVybmF0aXZlIHNvbHV0aW9u IG9uIHRvcCBvZiBDb0FQIGlzIHRvIG1vdmUgdGhlIFJFU1RmdWwNCj4+ID4+cHJvdG9jb2wgb3V0 IG9mICBDb0FQIGFuZCBvbmx5IHVzZSBQT1NUIHdpdGggc29tZSBkdW1teSBVcmktUGF0aCwNCj4+ ID4+Q29udGVudCBGb3JtYXQgZXRjLiBJbiB0aGlzICB3YXkgYWxsIG1lc3NhZ2VzIGNvdWxkIGNh cnJ5IGEgcHJvdGVjdGVkDQo+PiA+Pm9iamVjdCBhcyBpbiBbMV0gYW5kIHRoZSBuYXR1cmUgb2Yg dGhlICBpbnRlcmFjdGlvbiBhbmQgY29udGVudCBpcw0KPj4gPj5jb250YWluZWQgaW4gdGhpcyBv YmplY3QuIFRoaXMgaXMgcHJvYmFibHkgdmlvbGF0aW5nIHRoZSAgcHVycG9zZSBvZg0KPj4gPj5D b0FQIHRvbyBtdWNoIHRvIGJlIG9mIGFueSBpbnRlcmVzdC4NCj4+ID4+DQo+PiA+PiBUaG9zZSBh cmUgdGhlIG9ubHkgc29sdXRpb25zIHdlIGhhdmUgY29uc2lkZXJlZCBvbiB0b3Agb2YgQ29BUC4g SSdtDQo+PiA+Pm5vdCBzdXJlIGlmICB0aGUgc29sdXRpb24geW91IHByb3Bvc2UgaXMgcmVsYXRl ZCB0byBvbmUgb2YgdGhlc2U/DQo+PiA+Pg0KPj4gPj4gQWxsIG90aGVyIHNvbHV0aW9ucyBJJ20g YXdhcmUgb2Ygd2hpY2ggYWRkcmVzcyB0aGUgZ2VuZXJhbCBwcm9ibGVtDQo+PiA+PnNwYWNlLCBl LmcuDQo+PiA+PiBPU0NPQVAsIGFyZSBidWlsdCAid2l0aGluIiBDb0FQLCB1c2luZyBDb0FQIG9w dGlvbnMgdG8gY2FycnkNCj4+ID4+cHJvdGVjdGVkIG9iamVjdHMgIChzdWNoIGFzIFsxXSkgd2hp Y2ggaW5jbHVkZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBvZg0KPj4gPj50aGUgcGF5bG9hZCBhbmQg bWV0YS1kYXRhLg0KPj4gPj4gTm93LCB3aGF0IGhhcHBlbnMgaWYgdGhlIHBheWxvYWQgaXMgbGFy Z2U/IElmIHRoZSBvcmlnaW5hdGluZw0KPj4gPj5lbmRwb2ludCBkb2VzIHRoZSAgZnJhZ21lbnRh dGlvbiB0aGVuIHRoZSBkZXN0aW5hdGlvbiBlbmRwb2ludCBjYW4NCj4+ID4+dmVyaWZ5IHRoZSBp bnRlZ3JpdHkuDQo+PiA+PklmIGEgcHJveHkNCj4+ID4+IHVzaW5nIHRoZSBibG9ja3dpc2UgZHJh ZnQgKHJlLSlmcmFnbWVudHMgdGhlIHBheWxvYWQgKHdoaWNoIGFsc28NCj4+ID4+Y2hhbmdlcyBh ICBCbG9jayBvcHRpb24pIHN1Y2ggdGhhdCBpdCBpcyBkaWZmZXJlbnQgd2hlbiByZWFjaGluZyB0 aGUNCj4+ID4+ZGVzdGluYXRpb24gZW5kcG9pbnQsICB0aGVuIGludGVncml0eSB2ZXJpZmljYXRp b24gd2lsbCBmYWlsLiBUaGUNCj4+ID4+ZGVzdGluYXRpb24gZW5kcG9pbnQgY2Fubm90IGRpc3Rp bmd1aXNoIGEgIGxlZ2l0aW1hdGUNCj4+ID4+aW50cm9kdWN0aW9uL2NoYW5nZSBvZiBwYXlsb2Fk IGFuZCBCbG9jayBvcHRpb24gZnJvbSBhbnkgb3RoZXIgIGNoYW5nZQ0KPj4gPj5vZiB0aGUgbWVz c2FnZSwgaGVuY2UgaXQgY2Fubm90IHZlcmlmeSBpbnRlZ3JpdHkuIFRoaXMgY2FuIGJlIHVzZWQg dG8NCj4+ID4+ZGlzYWJsZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBhdCBDb0FQIGxheWVyIGFsc28g Zm9yIHNob3J0ZXIgbWVzc2FnZXMsDQo+PiA+PnNpbmNlIHRoZSAgZGVzdGluYXRpb24gZW5kcG9p bnQgbXVzdCB0cmVhdCB0aGUgZXhpc3RlbmNlIG9mIGEgQmxvY2sNCj4+ID4+b3B0aW9uIGFzIGEg Z2VuZXJpYyAgInNlY3VyaXR5IG9mZiIgYnV0dG9uLg0KPj4gPj4NCj4+ID4+IFRoaXMgaXMgcXVp dGUgZGlmZmVyZW50IGZyb20gdGhlIENvQVAgb3B0aW9ucyBzdGFuZGFyZGl6ZWQgc28gZmFyDQo+ PiA+PndoZXJlIHlvdSBjYW4gIHByb3RlY3QgaW5kaXZpZHVhbCBtZXNzYWdlcyBiZXR3ZWVuIGNs aWVudCBhbmQgc2VydmVyDQo+PiA+PmF0IHRoZSBzYW1lIHRpbWUgYXMgIGFsbG93aW5nIGxlZ2l0 aW1hdGUgcHJveHkgb3BlcmF0aW9uLCBldmVuDQo+PiA+PnZlcmlmeWluZyB0aGF0IGludGVybWVk aWF0ZSBub2RlcyBoYXMgIHBlcmZvcm1lZCB0aGUgY29ycmVjdCBDb0FQDQo+PiA+Pm9wdGlvbiBt YW5pcHVsYXRpb25zIHN1Y2ggYXMgZS5nLiB3aGVuIGZvcndhcmQgIHByb3hpZXMgY2hhbmdlIHRo ZQ0KPj4gPj5VcmktKiBvcHRpb25zIG1ha2luZyB0aGUgbWVzc2FnZSByZWFjaCB0aGUgY29ycmVj dCAgZGVzdGluYXRpb24gVVJJLg0KPj4gPj4NCj4+ID4+IElNSE8gQ29BUCBzaG91bGQgbm90IGFs bG93IGFuIGludGVybWVkaWF0ZSBkZXZpY2UgdG8gbGVnaXRpbWF0ZWx5DQo+PiA+PnR1cm4gb2Zm ICBpbnRlZ3JpdHkgcHJvdGVjdGluZyBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyLiBDb0FQIHNo b3VsZA0KPj4gPj5kZWZpbml0ZWx5IHN1cHBvcnQgIGludGVncml0eSBwcm90ZWN0aW9uIG9mIHNo b3J0IG1lc3NhZ2VzIGJldHdlZW4NCj4+ID4+Y2xpZW50IGFuZCBzZXJ2ZXIgdGhyb3VnaCAgcHJv eGllcy4gVGhpcyBpcyB3aGVyZSBDb0FQIHNoaW5lcw0KPj4gPj5icmlnaHRseS4gR2l2ZW4gdGhh dCwgaXQgaXMgc3RyYWlnaHRmb3J3YXJkIHRvICBpbnRlZ3JpdHkgcHJvdGVjdA0KPj4gPj5tZXNz YWdlcyBmcmFnbWVudGVkIGF0IHRoZSBlbmRwb2ludHMuDQo+PiA+PiBBbmQgd2l0aCB0aGUgQmxv Y2sgb3B0aW9ucyBpbnRlZ3JpdHkgcHJvdGVjdGVkIHRoZSBlbnRpcmUgbWVzc2FnZQ0KPj4gPj5i dWlsdCB1cCBvZiB0aGUgIGZyYWdtZW50cyBpcyBhdXRvbWF0aWNhbGx5IHByb3RlY3RlZCBhcyB3 ZWxsLg0KPj4gPj4NCj4+ID4+IEfDtnJhbg0KPj4gPj4NCj4+ID4+IFsxXSBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3NlLW1zZw0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0K Pj4gPj4NCj4+ID4+DQo+PiA+PiBPbiAyMDE2LTAxLTI5IDAwOjE4LCAiSmltIFNjaGFhZCIgPGll dGZAYXVndXN0Y2VsbGFycy5jb20+IHdyb3RlOg0KPj4gPj4NCj4+ID4+ID5Hw7ZyYW4sDQo+PiA+ PiA+DQo+PiA+PiA+SSBmaW5hbGx5IGdvdCBjYXVnaHQgdXAgb24gcmVhZGluZyB0aGUgQ09SRSBt YWlsaW5nIGxpc3QgKGxvdHMgb2YNCj4+ID4+ID5ib3JlZG9tIG9uIGlzc3VlcyBJIGRvbuKAmXQg dGhpbmsgSSBjYXJlIGFib3V0KSBhbmQgSSBkaWQgbm90IGZpbmQgYW55DQo+PiA+PiA+cmVzcG9u c2VzIHRvIHlvdXIgbWFpbCBvbiB0aGlzIGlzc3VlLiAgSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2Ug YQ0KPj4gPj4gPmRpZmZlcmVudCBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbSB3aGljaCBJIHRoaW5r IHlvdSB3aWxsIGZpbmQgYm90aA0KPj4gPj4gPndvcmthYmxlIGFuZCBwb3RlbnRpYWwgbm90IHJl cXVpcmluZyBhbnkgdXBkYXRlcyB0byB0aGUgY3VycmVudA0KPj5kcmFmdC4NCj4+ID4+ID4NCj4+ ID4+ID5XaGVuIEkgcmVhZCB0aGlzIGRyYWZ0IHRoZSBmaXJzdCB0aW1lLCBJIHJlYWQgaXQgYXMg YSBuZXR3b3JrDQo+PiA+PiA+ZnJhZ21lbnRhdGlvbiBkcmFmdCByYXRoZXIgdGhhbiBhcyBhIG1l c3NhZ2luZyBkcmFmdC4gIEFzIHN1Y2ggSSBkaWQNCj4+ID4+ID5ub3QgaGF2ZSB0aGUgc2FtZSBj b25jZXJucyBhYm91dCBvYmplY3Qgc2VjdXJpdHkgYXMgeW91IHNlZW0gdG8NCj4+aGF2ZS4NCj4+ ID4+ID5JIG1hZGUgdGhlIGRlY2lzaW9uIHRoYXQgSSB3b3VsZCBhcHBseSB0aGUgc2VjdXJpdHkg dG8gdGhlIGVudGlyZXR5DQo+PiA+PiA+b2YgdGhlIG1lc3NhZ2UgYmVpbmcgc2VudCwgYW5kIHRo ZW4gZnJhZ21lbnQgaXQgaW50byBibG9ja3MNCj4+YWZ0ZXJ3YXJkcy4NCj4+ID4+ID5TdWNoIGFu IGFwcHJvYWNoIGFsbG93cyBmb3IgYSBudW1iZXIgb2YgdGhpbmdzIHRoYXQgeW91IGFyZSBoYXZp bmcNCj4+ID4+ID5wcm9ibGVtcyB3aXRoIHRvIGJlIGlnbm9yZWQuDQo+PiA+PiA+DQo+PiA+PiA+ SG93IHRoZSBmcmFnbWVudGF0aW9uIGlzIGRvbmUsIGlzIGNoYW5nZSBvciBpcyByZW1vdmVkIGJl Y29tZQ0KPj4gPj4gPmltbWF0ZXJpYWwgYXMgdGhlIGVuZCByZWNpcGllbnQgd291bGQgbmVlZCB0 byBoYXZlIGFsbCBvZiB0aGUNCj4+ID4+ID5mcmFnbWVudHMgZGVsaXZlcmVkIGFuZCBpbiB0aGUg Y29ycmVjdCBvcmRlciBpbiBvcmRlciB0byBwcm9jZXNzIHRoZQ0KPj4gPj4gPm1lc3NhZ2UgYW5k IGRvIHZhbGlkYXRpb24uDQo+PiA+PiA+DQo+PiA+PiA+T3ZlcmhlYWQgaXMgc21hbGxlciBiZWNh dXNlIHRoZSBvdmVyaGVhZCBvZiBlbmNyeXB0aW5nL3NpZ25pbmcgYXQNCj4+ID4+ID50aGUgb2Jq ZWN0IHNlY3VyaXR5IGxldmVsIGlzIGRvbmUgb25jZSByYXRoZXIgdGhhbiBvbmNlIHBlcg0KPj4g Pj4gPmZyYWdtZW50LiAgVGhpcyBhbGxvd3MgZm9yIGZld2VyIGJ5dGVzIHRvIGJlIHNlbnQgYWNy b3NzIHRoZSB3aXJlLg0KPj4gPj4gPg0KPj4gPj4gPlRoZSBoZWFkZXJzIG9mIHRoZSBmaXJzdCBt ZXNzYWdlIGluIHRoZSBmcmFnbWVudCBhcmUgdGhlIG9uZXMgdGhhdA0KPj4gPj4gPnRoZSBvYmpl Y3Qgc2VjdXJpdHkgc3lzdGVtIHdvdWxkIGJlIHVzaW5nIGJvdGggZm9yIHNlY3VyaXR5DQo+PiA+ PiA+Y2FsY3VsYXRpb24gcHVycG9zZXMgYW5kIGZvciB0aGUgcmVjZWl2ZXIgdG8gcHJvY2VzcyB0 aGUgdmFsaWRhdGVkDQo+Pm1lc3NhZ2UuDQo+PiA+PiA+DQo+PiA+PiA+VGhlcmUgYXJlIHN0aWxs IHNvbWUgcXVlc3Rpb24gdGhhdCBwb3RlbnRpYWxseSBuZWVkIHRvIGJlIGRlYWx0DQo+PndpdGg6 DQo+PiA+PiA+DQo+PiA+PiA+MSkgQXJlIHRoZSBibG9jayBvcHRpb24gaGVhZGVycyBhdXRoZW50 aWNhdGVkPyAgVGhlIHByb2JhYmxlIGFuc3dlcg0KPj4gPj4gPnNob3VsZCBiZSBubyBhcyB0aGV5 IGFyZSBkZXNpZ25lZCB0byBiZSBjaGFuZ2VkIGJ5IGludGVybWVkaWFyaWVzLg0KPj4gPj4gPlRo aXMgY2FuIGJlIGRlZmVycmVkIHVudGlsIHRoZSBnZW5lcmFsIGRpc2N1c3Npb24gYWJvdXQgdGhl IHJlc3Qgb2YNCj4+ID4+ID50aGUgY3VycmVudCBoZWFkZXJzLg0KPj4gPj4gPg0KPj4gPj4gPjIp IFdoYXQgb3B0aW9ucyBhcmUgcmVxdWlyZWQgdG8gYmUgY29waWVkIGZvcndhcmQgaW50byBzdWJz ZXF1ZW50DQo+PiA+PiA+bWVzc2FnZXMgYW5kIHdoaWNoIGNhbiBiZSBvbWl0dGVkPyAgSSB3YXMg dW5hYmxlIHRvIGZpbmQgYW55DQo+PiA+PiA+Z3VpZGFuY2Ugb24gdGhpcyBpc3N1ZSBmcm9tIHJl YWRpbmcgdGhlIGRvY3VtZW50IGFuZCB0aHVzIHdvdWxkDQo+PiA+PiA+bmFpdmVseSBtYWtlIHRo ZSBhc3N1bXB0aW9uIHRoYXQgYWxsIG9wdGlvbnMgbm90IHNwZWNpZmllZCBieSB0aGlzDQo+PiA+ PiA+ZG9jdW1lbnQgYXJlIGNvcGllZCBmb3J3YXJkIGFuZCBzaG91bGQgYmUgY2hlY2tlZCB0byBt YWtlIHN1cmUgdGhhdA0KPj4gPj4gPnRoZXkgYXJlIHVuY2hhbmdlZCBpbiBmdXR1cmUgbWVzc2Fn ZXMuICBIb3dldmVyIEkgZG91YnQgdGhhdCBpcyB0aGUNCj4+ZGVzaXJlDQo+PiBvZiB0aGUgYXV0 aG9ycy4NCj4+ID4+ID5UaGlzIGhvd2V2ZXIgaXMgbm90IGEgc2VjdXJpdHkgc3BlY2lmaWMgaXNz dWUgYW5kIG5lZWRzIHRvIGJlDQo+PiA+PiA+YWRkcmVzc2VkIGluIHRoaXMgZG9jdW1lbnQuDQo+ PiA+PiA+DQo+PiA+PiA+MykgRG8gd2Ugd2FudCB0byBhcHBseSBwZXIgbWVzc2FnZSBzZWN1cml0 eSBhcyB3ZWxsIC0gdGhhdCBpcyBhbg0KPj4gPj4gPmlzc3VlIHRoYXQgY2FuIGFuZCBzaG91bGQg YmUgcHVudGVkIHRvIGEgZnV0dXJlIG9iamVjdCBzZWN1cml0eQ0KPj5kcmFmdC4NCj4+ID4+ID5I b3dldmVyLCBJIGRvbid0IHNlZSB0aGUgcG9pbnQgZXhjZXB0IHRvIHByb3RlY3QgdGhlIEFDSy9O QUNLIG9yDQo+PiA+PiA+bGFjayBvZiBvbiBlYWNoIGluZGl2aWR1YWwgaG9wLiAgQnV0IHRoaXMg aXMgcG9pbnQtdG8tcG9pbnQgbm90DQo+PmVuZC10by1lbmQuDQo+PiA+PiA+DQo+PiA+PiA+Smlt DQo+PiA+PiA+DQo+PiA+PiA+DQo+PiA+PiA+DQo+PiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4gPj4gPj4gRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEfDtnJhbg0KPj4gPj4gPj5TZWxhbmRlcg0KPj4gPj4gPj4gU2VudDog V2VkbmVzZGF5LCBOb3ZlbWJlciAyNSwgMjAxNSAxMTowNyBQTQ0KPj4gPj4gPj4gVG86IGlldGZA aWV0Zi5vcmcNCj4+ID4+ID4+IENjOiBkcmFmdC1pZXRmLWNvcmUtYmxvY2tAaWV0Zi5vcmc7IGNv cmUtY2hhaXJzQGlldGYub3JnOw0KPj4gPj4gPj5jb3JlQGlldGYub3JnOyAgYmFycnlsZWliYUBn bWFpbC5jb20NCj4+ID4+ID4+IFN1YmplY3Q6IFJlOiBbY29yZV0gTGFzdCBDYWxsOiA8ZHJhZnQt aWV0Zi1jb3JlLWJsb2NrLTE4LnR4dD4NCj4+ID4+ID4+KEJsb2NrLXdpc2UgdHJhbnNmZXJzICBp biBDb0FQKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPj4gPj4gPj4NCj4+ID4+ID4+DQo+PiA+PiA+ Pg0KPj4gPj4gPj4gVGhlcmUgd2FzIGEgdGhyZWFkIG9uIHRoZSBDb1JFIFdHIG1haWxpbmcgbGlz dCBhIGNvdXBsZSBvZiBtb250aHMNCj4+ID4+ID4+YWdvIG9uIHRoZSAgdG9waWMgb2YgYmxvY2t3 aXNlIGFuZCBvYmplY3Qgc2VjdXJpdHkuIFRoZSBzdGFydGluZw0KPj4gPj4gPj5wb2ludCB3YXMg YSBxdWVzdGlvbiBpZiBDb0FQICBwcm94aWVzIGNhbiAocmUtKXBhcnRpdGlvbiBtZXNzYWdlcw0K Pj4gPj4gPj5pbnRvIGJsb2NrcyBhcyBkZWZpbmVkIGluIHRoaXMgZHJhZnQsIGFuZCB0aGUgIGlt cGxpY2F0aW9ucyBvbg0KPj4gPj4gPj5lbmQtdG8tZW5kIHNlY3VyaXR5IGJldHdlZW4gY2xpZW50 IGFuZCBzZXJ2ZXIgdGhyb3VnaCBzdWNoIGENCj4+ID4+ID4+cHJveHkuIFRoZSBjb25jbHVzaW9u cyBvZiB0aGF0IGRpc2N1c3Npb24gaGFzIGFuIGltcGFjdCBvbiB0aGlzDQo+PiA+PiA+PmRyYWZ0 LCBidXQgdGhlcmUgIGFyZSBubyBjb25zaWRlcmF0aW9ucyBvZiB0aGlzIGtpbmQgbWFkZSBpbg0K Pj4gPj4gPj52ZXJzaW9uIC0xOC4gTW9yZSBkZXRhaWxzIGFyZSBnaXZlbiAgYmVsb3csIGluY2x1 ZGluZyBzb21lDQo+PiA+PiA+PmFsdGVybmF0aXZlIHByb3Bvc2FscyBmb3IgaG93IHRvIGFkZHJl c3MgdGhpcy4NCj4+ID4+ID4+QXBvbG9naWVzDQo+PiA+PiA+PiBmb3IgdGhlIGxvbmcgZS1tYWls Lg0KPj4gPj4gPj4NCj4+ID4+ID4+DQo+PiA+PiA+PiBCYWNrZ3JvdW5kOg0KPj4gPj4gPj4NCj4+ ID4+ID4+IFRoZXJlIGlzIGFuIG9uZ29pbmcgZGlzY3Vzc2lvbiBpbiBDb1JFIGFuZCBBQ0UgV0dz IHNpbmNlIGEgeWVhciBvbg0KPj4gPj4gPj50aGUNCj4+ID4+ID4+ZW5kLXRvLQ0KPj4gPj4gPj4g ZW5kIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgQ29BUCwgaS5lLiBwcm90ZWN0aW5nIHRoZSBjb21t dW5pY2F0aW9uDQo+PiA+PiA+PmJldHdlZW4gYSAgY2xpZW50IGFuZCBhIHNlcnZlciB0aHJvdWdo IHByb3hpZXMuIFJGQyA3MjUyIGFuZCBvdGhlcg0KPj4gPj4gPj5zcGVjaWZpY2F0aW9ucyBpbiB0 aGUgIENvQVAgc3VpdGUgZGVmaW5lIGEgc2V0IG9mIGxlZ2l0aW1hdGUgcHJveHkNCj4+ID4+ID4+ b3BlcmF0aW9ucyBvbiBDb0FQIG1lc3NhZ2VzIHdoaWNoICByZXF1aXJlcyBEVExTIHRvIGJlIHRl cm1pbmF0ZWQNCj4+ID4+ID4+YXQgcHJveGllcy4gVGhpcyBpbXBsaWVzIHRoYXQgdGhlIHByb3h5 IGhhcyBhY2Nlc3MgIG5vdCBvbmx5IHdpdGgNCj4+ID4+ID4+dGhlIGRhdGEgcmVxdWlyZWQgZm9y IHBlcmZvcm0gdGhlIGludGVuZGVkIHByb3h5IG9wZXJhdGlvbiBidXQgaXMNCj4+ID4+ID4+YWxz byBhYmxlIHRvIGVhdmVzZHJvcCBvciBtYW5pcHVsYXRlIGFueSBwYXJ0IG9mIHRoZSBDb0FQIHBh eWxvYWQNCj4+ID4+ID4+YW5kIG1ldGFkYXRhIGluIHRyYW5zaXQgYmV0d2VlbiBjbGllbnQgYW5k IHNlcnZlciB3aXRob3V0IGJlaW5nDQo+PiA+PiA+PnByb3RlY3RlZCBvciAgZGV0ZWN0ZWQgYnkg RFRMUy4NCj4+ID4+ID4+DQo+PiA+PiA+Pg0KPj4gPj4gPj4gT25lIHdheSB0byBtaXRpZ2F0ZSB0 aGlzIHRocmVhdCBpcyB0byBjb21wbGVtZW50IG9yIHJlcGxhY2UgRFRMUw0KPj4gPj4gPj53aXRo IGFwcGxpY2F0aW9uIGxheWVyIHByb3RlY3Rpb24gb2YgQ29BUCBwYXlsb2FkIGFuZCBtZXRhZGF0 YQ0KPj4gPj4gPj5iZXR3ZWVuIGNsaWVudCBhbmQgIHNlcnZlciBmb3IgdGhlIHVzZSBjYXNlcyB3 aGVyZSB0aGUgcHJveHkgc2hvdWxkDQo+PiA+PiA+Pm5vdCBiZSBmdWxseSB0cnVzdGVkLg0KPj4g Pj4gPj4gVGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgaW4gdGhlIENvUkUgV0cgbWVldGluZ3MgZHVy aW5nIHRoZSB0aHJlZQ0KPj4gPj4gPj5sYXN0IElFVEYgRjJGICBtZWV0aW5ncyBhbmQgdGhlcmUg YXJlIGRyYWZ0IHNvbHV0aW9ucyB1c2luZyB0aGUNCj4+ID4+ID4+bWVzc2FnZSBmb3JtYXQgYmVp bmcgIGRldmVsb3BlZCBpbiB0aGUgQ09TRSBXRy4NCj4+ID4+ID4+DQo+PiA+PiA+Pg0KPj4gPj4g Pj4gV2l0aCB0aGUgQ09BUCBwcm94eSBvcGVyYXRpb25zIHN0YW5kYXJkaXplZCBzbyBmYXIgaXQg aGFzIGJlZW4NCj4+ID4+ID4+cG9zc2libGUgdG8gIHByb3RlY3QgdGhlIENvQVAgbWVzc2FnZXMg YWRlcXVhdGVseSB3aXRoIHNlY3VyaXR5IG9uDQo+PiA+PiA+PnRyYW5zcG9ydCBsYXllciwgIGFw cGxpY2F0aW9uIGxheWVyIG9yIGEgY29tYmluYXRpb24gdGhlcmVvZi4gSW4NCj4+ID4+ID4+dGhl IGNhc2Ugd2hlcmUgdGhlIGxlZ2l0aW1hdGUgIHByb3h5IG9wZXJhdGlvbiBpcyBwcmVkaWN0YWJs ZSBieQ0KPj4gPj4gPj5jbGllbnQgYW5kIHNlcnZlciwgYXBwbGljYXRpb24gbGF5ZXIgc2VjdXJp dHkgY2FuICBiZSBkZWZpbmVkIHRvDQo+PiA+PiA+PmJvdGggdmVyaWZ5IHRoYXQgbm8gaWxsZWdp dGltYXRlIGNoYW5nZXMgaGFzIGJlZW4gcGVyZm9ybWVkIGFzDQo+PiA+PiA+PndlbGwgYXMgdmVy aWZ5aW5nIHRoZSBsZWdpdGltYXRlIGNoYW5nZXMuIEluIHRoZSBjYXNlIHdoZXJlIHByb3h5DQo+ PiA+PiA+Pm9wZXJhdGlvbnMgYXJlICBub3QgcHJlZGljdGFibGUg4oCUIGV2ZW4gaWYgdGhlIGRh dGEgdGhlIHByb3h5IGlzDQo+PiA+PiA+Pm9wZXJhdGluZyBvbiBjYW5ub3QgYmUgcHJvdGVjdGVk ICDigJQgaXQgaGFzIHNvIGZhciBiZWVuIHBvc3NpYmxlIHRvDQo+PiA+PiA+PnVzZSBvdGhlciBp bmZvcm1hdGlvbiBlbGVtZW50cyB0byBwcm92aWRlIHRoZSAgcmVxdWlyZWQgZW5kLXRvLWVuZA0K Pj4gc2VjdXJpdHkgcHJvcGVyaXRpZXMuDQo+PiA+PiA+PkZvciBleGFtcGxlLCB0aGUgQ29BUCBo ZWFkZXIgZmllbGQgIFRva2VuIG1heSBiZSBjaGFuZ2VkIGJ5IGENCj4+ID4+ID4+cHJveHksIGJ1 dCBpbnN0ZWFkIGEgdHJhbnNhY3Rpb24gaWRlbnRpZmllciBjYW4gYmUgIGludHJvZHVjZWQgaW4N Cj4+ID4+ID4+dGhlIGFwcGxpY2F0aW9uIHNlY3VyaXR5IHdyYXBwZXIgKENPU0UNCj4+ID4+ID4+ IGhlYWRlcikgdG8gZGVmaW5lIGEgbWVzc2FnZSAoZXhjaGFuZ2UpIGlkZW50aWZpZXIgY29tbW9u IHRvIGNsaWVudA0KPj4gPj4gPj5hbmQgc2VydmVyLg0KPj4gPj4gPj4NCj4+ID4+ID4+DQo+PiA+ PiA+PiBCbG9ja3dpc2U6DQo+PiA+PiA+Pg0KPj4gPj4gPj4gV2l0aCB0aGUgZGVmaW5pdGlvbiBv ZiBibG9ja3dpc2UgdHJhbnNmZXIgYXMgc3BlY2lmaWVkIGluIHRoaXMNCj4+ID4+ID4+ZHJhZnQg YSBwcm94eSBtYXkgIHBhcnRpdGlvbiBvciByZS1wYXJ0aXRpb25pbmcgYSBtZXNzYWdlIGludG8N Cj4+ID4+ID4+YmxvY2tzIHdoZXJlIHRoZSBzaXplIG9mIHRoZSBibG9ja3MgIGFyZSBkZWNpZGVk IGJ5IHRoZSBwcm94eS4gQXMgYQ0KPj4gPj4gPj5jb25zZXF1ZW5jZSwgaXQgaXMgbm90IHBvc3Np YmxlIHRvIGludGVncml0eSBwcm90ZWN0ICBpbmRpdmlkdWFsDQo+PiA+PiA+PmJsb2NrcyBlbmQt dG8tZW5kIGJldHdlZW4gY2xpZW50IGFuZCBzZXJ2ZXI6IERUTFMgZG9lcyBub3QgcHJvdGVjdA0K Pj4gPj4gPj50aGUgbWVzc2FnZSBkYXRhIHdpdGhpbiB0aGUgcHJveHksIGFuZCBhcHBsaWNhdGlv biBsYXllciBpbnRlZ3JpdHkNCj4+ID4+ID4+cHJvdGVjdGlvbiBvZiBpbmRpdmlkdWFsIGJsb2Nr cyBjYW5ub3QgYmUgcGVyZm9ybWVkIHVubGVzcyB0aGUNCj4+ID4+ID4+cGFydGl0aW9uaW5nIGlu dG8gYmxvY2tzIGFzICByZWNlaXZlZCBieSBvbmUgZW5kcG9pbnQgaXMgaWRlbnRpY2FsDQo+PiA+ PiA+PnRvIHRoYXQgc2VudCBieSB0aGUgb3RoZXIgZW5kcG9pbnQuIEhlbmNlLCAgd2hlbiBDb0FQ IEJsb2NrIG9wdGlvbnMNCj4+ID4+ID4+YXJlIHVzZWQgYXMgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0 LCBlbmQtdG8tZW5kIHNlY3VyaXR5ICBvZiB0aGUNCj4+ID4+ID4+aW5kaXZpZHVhbCBDb0FQIHJl cXVlc3QgYW5kIHJlc3BvbnNlIGJyZWFrcyBkb3duLiBGb3IgZXhhbXBsZTogYQ0KPj4gPj4gPj5w cm94eSAgbWF5IGFkZEJsb2NrIG9wdGlvbnMsIHNlbmQgYW55IG51bWJlciBvZiBibG9ja3Mgd2l0 aCBhbnkNCj4+ID4+ID4+cGF5bG9hZCB0byBhbiAgZW5kcG9pbnQgd2l0aG91dCBiZWluZyBwb3Nz aWJsZSB0byBkZXRlY3Qgb3IgcHJvdGVjdA0KPj4gPj4gPj5hZ2FpbnN0LiBJbiBjb250cmFzdCB0 byB0aGUgIGV4aXN0aW5nIHN0YW5kYXJkcyBpbiB0aGUgQ29BUCBzdWl0ZSwNCj4+ID4+ID4+aW4g dGhpcyBjYXNlIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBieXBhc3MgdGhlICBjb25zdHJ1Y3Rpb24g YW5kDQo+PiA+PiA+PmRlZmluZSBhIHNlY3VyZSBlbmQtdG8tZW5kIGJsb2NrIHBhcnRpdGlvbmlu ZyB3aXRoIGxlc3MgdGhhbg0KPj4gPj4gPj5kaXNhYmxpbmcgYmxvY2sgcGFydGl0aW9uaW5nIGFz IHNwZWNpZmllZCBpbiB0aGlzIGRyYWZ0Lg0KPj4gPj4gPj4NCj4+ID4+ID4+DQo+PiA+PiA+PiBP bmUgc29sdXRpb24gdG8gdGhpcyBpcyB0byBkaXNhbGxvdyBwcm94aWVzIHRvIHJlLXBhcnRpdGlv biBhDQo+PiA+PiA+Pm1lc3NhZ2UsIHRodXMgIHJlZGVmaW5lIHRoZSBCbG9jayBvcHRpb25zIHN1 Y2ggdGhhdCB0aGV5IGFyZQ0KPj4gPj4gPj5wb3NzaWJsZSB0byBpbnRlZ3JpdHkgcHJvdGVjdCBl bmQtICB0by1lbmQuICBJbnRlZ3JpdHkgcHJvdGVjdGluZw0KPj4gPj4gPj5lYWNoIGJsb2NrIGFu ZCBjb3JyZXNwb25kaW5nIEJsb2NrIG9wdGlvbnMgYXMgIGRlZmluZWQgaW4gdGhlDQo+PiA+PiA+ PmN1cnJlbnQgZHJhZnQgaGFzIGFkZGl0aW9uYWwgYmVuZWZpdHM6IElmIGFueSBibG9jayBpbiB0 aGUgc2VxdWVuY2UNCj4+ID4+ID4+ZmFpbHMgdmVyaWZpY2F0aW9uLCBpdCBjYW4gYmUgaW5kaXZp ZHVhbGx5IHJlcXVlc3RlZCB0byBiZSByZXNlbnQuDQo+PiA+PiA+PldoZW4gYWxsIGJsb2NrcyAg aGFzIGJlZW4gdmVyaWZpZWQgdGhlIGVudGlyZSBtZXNzYWdlIGhhcyBiZWVuDQo+PiA+PiA+PnZl cmlmaWVkLiAgQSByZWNlaXZpbmcgbm9kZSBtYXkgIGV2ZW4gcGVyZm9ybSBjZXJ0YWluIGFjdGlv bnMgYmFzZWQNCj4+ID4+ID4+b24gcmVjZWl2ZWQgdmVyaWZpZWQgYmxvY2tzIGJlZm9yZSB0aGUg ZW50aXJlICBtZXNzYWdlIGhhcyBiZWVuDQo+PnJlY2VpdmVkLg0KPj4gPj4gPj4NCj4+ID4+ID4+ DQo+PiA+PiA+PiBJbnN0ZWFkIG9mIGRlbGVnYXRpbmcgdG8gcHJveGllcyB0byBwYXJ0aXRpb24g aW50byBibG9ja3MsIHRoZQ0KPj4gPj5zZW5kaW5nDQo+PiA+PiA+PmVuZHBvaW50DQo+PiA+PiA+ PiB3b3VsZCBuZWVkIHRvIGFudGljaXBhdGUgb3IgZ2V0IGluZm9ybWF0aW9uIGFib3V0IHRoZSBy ZWxldmFudA0KPj4gPj4gPj5ibG9jayBzaXplLCBlLmcuDQo+PiA+PiA+PiB1c2luZyBhIHNpemUg aW5kaWNhdGlvbiBpbiB0aGUgbGluay1mb3JtYXQgZGVzY3JpcHRpb24gW1JGQzY5OTBdLg0KPj4g Pj4gPj5BZGRpdGlvbmFsDQo+PiA+PiA+PiBtZXRob2RzIGZvciBibG9ja3NpemUgZGlzY292ZXJ5 IG1heSBhbHNvIGJlIGRlZmluZWQuDQo+PiA+PiA+PiBXaGlsZSB0aGlzIG1heSBub3QgYmUgYXMg c2ltcGxlIGFzIGxlYXZpbmcgaXQgZW50aXJlbHkgdG8gdGhlDQo+PiA+PiA+PnByb3h5DQo+PiA+ PnRvDQo+PiA+PiA+PmRlY2lkZSwNCj4+ID4+ID4+IGNvbnNpZGVyaW5nIHRoZSBhZGRpdGlvbmFs IHNlY3VyaXR5IGJlbmVmaXRzIEkgYmVsaWV2ZSB0aGlzIGlzIHRoZQ0KPj4gPj4gPj5yaWdodCB0 cmFkZSBvZmYgdG8gIG1ha2UuDQo+PiA+PiA+Pg0KPj4gPj4gPj4NCj4+ID4+ID4+IEFuIGFsdGVy bmF0aXZlIHNvbHV0aW9uIGlzIHRvIHByZXZlbnQgcHJveGllcyBmcm9tIHJlLXBhcnRpdGlvbmlu Zw0KPj4gPj4gPj5hIG1lc3NhZ2Ugb25seSAgaW4gdGhlIGNhc2Ugd2hlcmUgZW5kLXRvLWVuZCBz ZWN1cml0eSBvZiBDb0FQDQo+PiA+PiA+Pm1lc3NhZ2UgaXMgYXBwbGllZCwNCj4+ID4+d2hpY2gN Cj4+ID4+ID4+aW4NCj4+ID4+ID4+IGN1cnJlbnQgc29sdXRpb24gcHJvcG9zYWxzIGlzIGluZGlj YXRlZCB3aXRoIHRoZSBwcmVzZW5jZSBvZiBhDQo+PiA+PmNlcnRhaW4NCj4+ID4+ID4+Q29BUA0K Pj4gPj4gPj4gb3B0aW9uIFggKHdoaWNoIGUuZy4gY29udGFpbnMgdGhlIENPU0Ugb2JqZWN0KS4N Cj4+ID4+ID4+IFRoaXMgd291bGQgaGF2ZSB0aGUgc2FtZSBiZW5lZml0cyBhcyB0aGUgcHJldmlv dXMgc29sdXRpb24sIGJ1dA0KPj4gPj4gPj5yZXF1aXJlcyB0aGUgIGNvZGUgaW4gdGhlIHByb3h5 IGltcGxlbWVudGluZyB0aGlzIGRyYWZ0IHRvIGJlIGF3YXJlDQo+PiA+PiA+Pm9mIG9wdGlvbiBY LA0KPj4gPj5hbmQNCj4+ID4+ID4+aGVuY2UNCj4+ID4+ID4+IHRoYXQgZGVwZW5kZW5jeSBuZWVk cyB0byBiZSBzcGVjaWZpZWQgaW4gdGhpcyBkcmFmdC4gQW5kIG9wdGlvbiBYDQo+PiA+PiA+Pmlz DQo+PiA+Pm5vdA0KPj4gPj4gPj4gc3RhbmRhcmRpemVkIHlldCwgc28gd291bGQgcmVxdWlyZSBp bnRyb2R1Y2luZyBhIHBsYWNlaG9sZGVyLg0KPj4gPj4gPj4NCj4+ID4+ID4+DQo+PiA+PiA+PiBU aGVyZSBhcmUgb3RoZXIgYWx0ZXJuYXRpdmVzIGFzIHdlbGwgYnV0IHRoaXMgZS1tYWlsIGlzIGFs cmVhZHkNCj4+ID4+ID4+dG9vIGxvbmcuDQo+PiA+PiA+PiBUaGUgbWFpbiBwb2ludCBJIHdhbnRl ZCB0byBtYWtlIGlzIHRoYXQgZ2l2ZW4gdGhhdCB3ZSBub3cgaGF2ZSBhDQo+PiA+PmJldHRlcg0K Pj4gPj4gPj4gdW5kZXJzdGFuZGluZyBvZiBob3cgdG8gYWNoaWV2ZSBzZWN1cml0eSBiZXR3ZWVu IGNsaWVudCBhbmQgc2VydmVyDQo+PiA+PiA+PnRocm91Z2ggIHByb3hpZXMgY29tcGFyZWQgdG8g d2hlbiBSRkM3MjUyIHdhcyB3cml0dGVuLCBteSBvcGlub24gaXMNCj4+ID4+ID4+dGhhdCB3ZSBz aG91bGQgIG5vdCBpZ25vcmUgdGhlc2Ugc2VjdXJpdHkgaXNzdWVzIGluIG5ldyBzdGFuZGFyZHMu DQo+PiA+PiA+Pg0KPj4gPj4gPj4NCj4+ID4+ID4+DQo+PiA+PiA+PiBHw7ZyYW4NCj4+ID4+ID4+ DQo+PiA+PiA+Pg0KPj4gPj4gPj4NCj4+ID4+ID4+IE9uIDIwMTUtMTEtMjAgMjI6MzIsICJUaGUg SUVTRyIgPGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPiB3cm90ZToNCj4+ID4+ID4+DQo+PiA+PiA+ PiA+DQo+PiA+PiA+PiA+VGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBD b25zdHJhaW5lZCBSRVNUZnVsDQo+PiA+PiA+PiA+RW52aXJvbm1lbnRzIFdHIChjb3JlKSB0byBj b25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KPj4gPj4gPj4gPi0gJ0Jsb2NrLXdpc2Ug dHJhbnNmZXJzIGluIENvQVAnDQo+PiA+PiA+PiA+ICA8ZHJhZnQtaWV0Zi1jb3JlLWJsb2NrLTE4 LnR4dD4gYXMgUHJvcG9zZWQgU3RhbmRhcmQNCj4+ID4+ID4+ID4NCj4+ID4+ID4+ID5UaGUgSUVT RyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQNCj4+ ID4+c29saWNpdHMNCj4+ID4+ID4+ID5maW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxl YXNlIHNlbmQgc3Vic3RhbnRpdmUgY29tbWVudHMNCj4+ID4+ID4+ID50bw0KPj4gPj50aGUNCj4+ ID4+ID4+ID5pZXRmQGlldGYub3JnIG1haWxpbmcgbGlzdHMgYnkgMjAxNS0xMi0wNC4gRXhjZXB0 aW9uYWxseSwNCj4+ID4+ID4+ID5jb21tZW50cw0KPj4gPj5tYXkNCj4+ID4+ID4+ID5iZSBzZW50 IHRvIGllc2dAaWV0Zi5vcmcgaW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBsZWFzZSByZXRhaW4N Cj4+ID4+ID4+ID50aGUgYmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0 b21hdGVkIHNvcnRpbmcuDQo+PiA+PiA+PiA+DQo+PiA+PiA+PiA+QWJzdHJhY3QNCj4+ID4+ID4+ ID4NCj4+ID4+ID4+ID4NCj4+ID4+ID4+ID4gICBDb0FQIGlzIGEgUkVTVGZ1bCB0cmFuc2ZlciBw cm90b2NvbCBmb3IgY29uc3RyYWluZWQgbm9kZXMgYW5kDQo+PiA+PiA+PiA+ICAgbmV0d29ya3Mu ICBCYXNpYyBDb0FQIG1lc3NhZ2VzIHdvcmsgd2VsbCBmb3IgdGhlIHNtYWxsDQo+PiA+PiA+PiA+ IHBheWxvYWRzDQo+PiA+PndlDQo+PiA+PiA+PiA+ICAgZXhwZWN0IGZyb20gdGVtcGVyYXR1cmUg c2Vuc29ycywgbGlnaHQgc3dpdGNoZXMsIGFuZCBzaW1pbGFyDQo+PiA+PiA+PiA+ICAgYnVpbGRp bmctYXV0b21hdGlvbiBkZXZpY2VzLiAgT2NjYXNpb25hbGx5LCBob3dldmVyLA0KPj5hcHBsaWNh dGlvbnMNCj4+ID4+ID4+ID4gICB3aWxsIG5lZWQgdG8gdHJhbnNmZXIgbGFyZ2VyIHBheWxvYWRz IC0tIGZvciBpbnN0YW5jZSwgZm9yDQo+PiA+PmZpcm13YXJlDQo+PiA+PiA+PiA+ICAgdXBkYXRl cy4gIFdpdGggSFRUUCwgVENQIGRvZXMgdGhlIGdydW50IHdvcmsgb2Ygc2xpY2luZyBsYXJnZQ0K Pj4gPj4gPj4gPiAgIHBheWxvYWRzIHVwIGludG8gbXVsdGlwbGUgcGFja2V0cyBhbmQgZW5zdXJp bmcgdGhhdCB0aGV5IGFsbA0KPj4gPj5hcnJpdmUNCj4+ID4+ID4+ID4gICBhbmQgYXJlIGhhbmRs ZWQgaW4gdGhlIHJpZ2h0IG9yZGVyLg0KPj4gPj4gPj4gPg0KPj4gPj4gPj4gPiAgIENvQVAgaXMg YmFzZWQgb24gZGF0YWdyYW0gdHJhbnNwb3J0cyBzdWNoIGFzIFVEUCBvciBEVExTLA0KPj53aGlj aA0KPj4gPj4gPj4gPiAgIGxpbWl0cyB0aGUgbWF4aW11bSBzaXplIG9mIHJlc291cmNlIHJlcHJl c2VudGF0aW9ucyB0aGF0IGNhbg0KPj5iZQ0KPj4gPj4gPj4gPiAgIHRyYW5zZmVycmVkIHdpdGhv dXQgdG9vIG11Y2ggZnJhZ21lbnRhdGlvbi4gIEFsdGhvdWdoIFVEUA0KPj4gPj5zdXBwb3J0cw0K Pj4gPj4gPj4gPiAgIGxhcmdlciBwYXlsb2FkcyB0aHJvdWdoIElQIGZyYWdtZW50YXRpb24sIGl0 IGlzIGxpbWl0ZWQgdG8gNjQNCj4+S2lCDQo+PiA+PiA+PiA+ICAgYW5kLCBtb3JlIGltcG9ydGFu dGx5LCBkb2Vzbid0IHJlYWxseSB3b3JrIHdlbGwgZm9yDQo+PmNvbnN0cmFpbmVkDQo+PiA+PiA+ PiA+ICAgYXBwbGljYXRpb25zIGFuZCBuZXR3b3Jrcy4NCj4+ID4+ID4+ID4NCj4+ID4+ID4+ID4g ICBJbnN0ZWFkIG9mIHJlbHlpbmcgb24gSVAgZnJhZ21lbnRhdGlvbiwgdGhpcyBzcGVjaWZpY2F0 aW9uDQo+PiA+PmV4dGVuZHMNCj4+ID4+ID4+ID4gICBiYXNpYyBDb0FQIHdpdGggYSBwYWlyIG9m ICJCbG9jayIgb3B0aW9ucywgZm9yIHRyYW5zZmVycmluZw0KPj4gPj5tdWx0aXBsZQ0KPj4gPj4g Pj4gPiAgIGJsb2NrcyBvZiBpbmZvcm1hdGlvbiBmcm9tIGEgcmVzb3VyY2UgcmVwcmVzZW50YXRp b24gaW4NCj4+bXVsdGlwbGUNCj4+ID4+ID4+ID4gICByZXF1ZXN0LXJlc3BvbnNlIHBhaXJzLiAg SW4gbWFueSBpbXBvcnRhbnQgY2FzZXMsIHRoZSBCbG9jaw0KPj4gPj5vcHRpb25zDQo+PiA+PiA+ PiA+ICAgZW5hYmxlIGEgc2VydmVyIHRvIGJlIHRydWx5IHN0YXRlbGVzczogdGhlIHNlcnZlciBj YW4gaGFuZGxlDQo+PmVhY2gNCj4+ID4+ID4+ID4gICBibG9jayB0cmFuc2ZlciBzZXBhcmF0ZWx5 LCB3aXRoIG5vIG5lZWQgZm9yIGEgY29ubmVjdGlvbg0KPj5zZXR1cCBvcg0KPj4gPj4gPj4gPiAg IG90aGVyIHNlcnZlci1zaWRlIG1lbW9yeSBvZiBwcmV2aW91cyBibG9jayB0cmFuc2ZlcnMuDQo+ PiA+PiA+PiA+DQo+PiA+PiA+PiA+ICAgSW4gc3VtbWFyeSwgdGhlIEJsb2NrIG9wdGlvbnMgcHJv dmlkZSBhIG1pbmltYWwgd2F5IHRvDQo+PnRyYW5zZmVyDQo+PiA+PiA+PiA+ICAgbGFyZ2VyIHJl cHJlc2VudGF0aW9ucyBpbiBhIGJsb2NrLXdpc2UgZmFzaGlvbi4NCj4+ID4+ID4+ID4NCj4+ID4+ ID4+ID4NCj4+ID4+ID4+ID4NCj4+ID4+ID4+ID4NCj4+ID4+ID4+ID5UaGUgZmlsZSBjYW4gYmUg b2J0YWluZWQgdmlhDQo+PiA+PiA+PiA+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1jb3JlLWJsb2NrLw0KPj4gPj4gPj4gPg0KPj4gPj4gPj4gPklFU0cgZGlzY3Vz c2lvbiBjYW4gYmUgdHJhY2tlZCB2aWENCj4+ID4+ID4+ID5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvcmUtYmxvY2svYmFsbG90Lw0KPj4gPj4gPj4gPg0KPj4g Pj4gPj4gPg0KPj4gPj4gPj4gPk5vIElQUiBkZWNsYXJhdGlvbnMgaGF2ZSBiZWVuIHN1Ym1pdHRl ZCBkaXJlY3RseSBvbiB0aGlzIEktRC4NCj4+ID4+ID4+ID4NCj4+ID4+ID4+ID4NCj4+ID4+ID4+ DQo+PiA+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gPj4gPj4gY29yZSBtYWlsaW5nIGxpc3QNCj4+ID4+ID4+IGNvcmVAaWV0Zi5vcmcNCj4+ ID4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KPj4gPj4g Pg0KPj4gPg0KPj4gPg0KPg0KDQo= From nobody Wed Feb 3 14:38:26 2016 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 608D41B3600; Wed, 3 Feb 2016 14:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 BFb8qAwF9-Xg; Wed, 3 Feb 2016 14:38:23 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6901B2D1C; Wed, 3 Feb 2016 14:38:23 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id f81so73003155iof.0; Wed, 03 Feb 2016 14:38:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=jjUdY5rDC/vS9OABcDIDGops1slNuIyYqylZZnA/if4=; b=EGxZK42I7tdPyLkd5CNt6U+XvTe8oQpec3udaZRD7VWy/Yen0Hd2TbX0fRILsXnOwv 4lSdWbs43ERldiT5VgXPVEP4cct4vK4t3YYxQE1jqPJfWVoiASKF1BqeZ14zt/z1nI+d rI3/y1v0uQH8xEGVneQSqOFym9vDy11dRxx+rBR3UPL+FudwldArLNMvfYvLrueErA4J 9qtyMhnTw6Cg+W+Iw9TS+8ZZeM0cI1B4yJ61in22K8nKGy/QQ5LDZEi0abpsw70ujbX3 rPWEitSfHJjpAnqivr+puZcjPRNIlVQ+73KY+9ndIGQrjl6YxmFcBIkeYRg+i8YB1gt3 LmCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jjUdY5rDC/vS9OABcDIDGops1slNuIyYqylZZnA/if4=; b=iHrVLW6D2KJ9do3l1bC1kp9vFjiLdYds0wFSZx+BzerI4sjuZUxQ0Xy1G5DBwU/bN3 0wz8CO/UMZ7TVFD8Xm+SUs67i5rQe76sSufWLf8Nr5Jd5jYX93oi1jonVw0Oa90gs+7s P9DE5/hutt+YYEWIONUWIgHbe3bznHUnmWN8vGx8YpX6ysX0XB0Hl7wYwBOB2aPkdsN5 o3ZUg6oKH96uppskwEr2/bT/Epl1D5yZEbSlXlkB5IA56HLoIiVFzOVh21ar3Gz9RDjQ 3fPIXbo3Vd/tvEFd58Wcp6b8KvLnWGdlxDcRWCjuL6/S1/NV2Hu27sPFEtRimZ4VhsSl Zyxg== X-Gm-Message-State: AG10YOQ0lMBcpVhd2UIQHyyrCO7spz1tT5A4UH7UL/6E7huYj2TyRLjJld3lLPU5TI91pgjuCNSdn6HuBZMhwA== MIME-Version: 1.0 X-Received: by 10.107.41.142 with SMTP id p136mr6186733iop.70.1454539102749; Wed, 03 Feb 2016 14:38:22 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.34.14 with HTTP; Wed, 3 Feb 2016 14:38:22 -0800 (PST) In-Reply-To: <56AE324E.2010403@tzi.org> References: <20151020210304.27062.87223.idtracker@ietfa.amsl.com> <5626AE89.70305@tzi.org> <56289F96.1090608@cisco.com> <56AE324E.2010403@tzi.org> Date: Wed, 3 Feb 2016 17:38:22 -0500 X-Google-Sender-Auth: Zzrp-9xjSiibHUvNVTQNv_y-8E8 Message-ID: From: Barry Leiba To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: core-chairs@ietf.org, The IESG , "core@ietf.org WG" Subject: Re: [core] Benoit Claise's Block on charter-ietf-core-01-01: (with BLOCK) 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, 03 Feb 2016 22:38:25 -0000 Beno=C3=AEt, can you have a look at this version?: > An edited version charter-ietf-core-01-01 with detailed history is now at > https://svn.tools.ietf.org/svn/wg/core/charter-ietf-core.txt Barry On Sun, Jan 31, 2016 at 11:11 AM, Carsten Bormann wrote: > Hi Barry, > > I'm back in Germany. > > I have expunged DICE (which has now closed) by replacing it with a > reference to the security area in general (for DTLS over SMS), with a > reference to the TLS WG (on DTLS specific efficiency work), and simply > striking DICE from the list of WGs to coordinate with. That should > cover Stephen's comments. > > Re Benoit's input (key: >>>>> and >> are Beno=C3=AEt; >>> are Carsten) > >>>>> - "CoRE will also develop a way to make RESTCONF-style management >>>>> functions >>>>> available via CoAP that is appropriate for constrained node networks. >>>>> This >>>>> will require very close coordination with NETCONF and other operation= s >>>>> and >>>>> management working groups." >>>>> >>>>> What is the goal of this coordination with NETCONF? >>>>> Could RESTCONF be reused? If not, why not? >>>>> If yes, will RESTCONF need to be modified? >> >>>> We want to coordinate with the NETCONF WG to ensure that the result of >>>> our work makes sense as a part of the overall NETCONF family. >> >>> Thanks. The coordination objectives should be mentioned in the charter. >> >>>> The basis for COMI is RESTCONF, but there will be a need for some >>>> streamlining. >> >>> Can you expand on this, or point to a draft section/email thread. > > The main draft is draft-vanderstok-core-comi, and there are some > additional considerations in draft-veillette-core-cool. > > (Or did you ask for text/pointers to be in the charter?) > >>>> It is not clear whether this will lead to modifications >>>> of RESTCONF itself; more likely COMI will just be a dialect that is >>>> applicable to very constrained devices. There are different approache= s >>>> on the question whether the YANG models have to take some specific car= e >>>> about being used in COMI, > > (I was alluding to the COOL work here.) > >>> (I've not been following the core mailing list and I don't know which >>> specifics you speak about) >>> I hope you will not go that path. >>> This would be a failure from an OPS point of view: we need a single YAN= G >>> data model language, and not another data model language. > > One objective that has been repeatedly stated in the COMI work is that > any random YANG module should be usable with COMI, but there are still > discussions whether this will be a less efficient mode and/or we should > be leaving out some parts (RPC has been stated as an example). I think > we have been progressing towards enabling full coverage. There may, > however, be some considerable efficiency gains that can be reaped by > evolving YANG modules in a specific way. > >>> In the end, if >>> there are YANG specifics for constrained node networks, then it's a >>> different data model language. > > I think this statement reflects the current direction well, however, > there may be some willingness to do additional work (such as COOL's SID > files) in exchange for significant reductions in the message size. > >>> To illustrate my point: shall we see RFC 7223bis, A YANG Data Model for >>> Interface Management for constrained networks? > > We already have RFC 7388, and we'd rather get more integration with the > YANG world than less. > >>> >>> Unless I miss something on the above, this should even mentioned in the= core >>> charter. >>> >>> CoRE will also develop a way to make RESTCONF-style management >>> functions available, based on YANG, via CoAP that is appropriate fo= r >>> constrained >>> node networks. >>> >>> + >>> >>> No YANG specifics for constrained nodes network ... > > I somewhat nebulously phrased that as: > > Besides continuing to examine operational and manageability aspects of > the CoAP protocol itself, CoRE will also develop a way to make > RESTCONF-style management functions available via CoAP that is > appropriate for constrained node networks. This will require very clos= e > coordination with NETCONF and other operations and management working > groups. The YANG modeling language is not a target for change in > this process, however additional supporting mechanisms may be > employed in specific cases where significant performance gains are > both attainable and required. > > (Maybe this can still be improved.) > >>> And LWM2M? >>> >>> Do we need to expand a bit on those in the charter? I guess so > > I have added to the above: > > The working > group will continue to consider the OMA LWM2M management functions > as a well-accepted alternative form of management and provide > support at the CoAP protocol level where required. > > That wording is obviously even more up for discussion: WG, please chime > in (potentially after limiting the CC list to core@ietf.org). > > An edited version charter-ietf-core-01-01 with detailed history is now at > https://svn.tools.ietf.org/svn/wg/core/charter-ietf-core.txt > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Feb 3 22:48:45 2016 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 DD53A1ACCFC for ; Wed, 3 Feb 2016 22:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euc2lgJFR-tw for ; Wed, 3 Feb 2016 22:48:42 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 EC7901ACCC7 for ; Wed, 3 Feb 2016 22:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=EdjLRmYKLLmUPC1vJeJBjIt6dKjP0FAxax3vXjYhwkM=; b=JCggPZyuIUBKpUGMn0UXBtE7EL lSqMxtIvkCy4huzmUvRayRThc+jiJssK3OK3ne1m9H07Fk5idOMupvJv5n7Ze+s09qNWz1zn0TLGR B7xHcmUC6/wjnvx41VBuaMZ0ACC6Gx33/1+xpaSVhHPMbwcotqzm7nhwrhAbAZJ5WuMuf4Tb1FEvG Z8OfT0LLWHLfmaSalgVpwPwNs9N/4aQQJbJkSD4xoJ8iWAsynJdUCQQCrLBvFTiqpIqFgy90hUJiq aluH4aZ9FNqQc8orRNdmxlkoVKl+hZ0gLJTalMwXtrxdiSu68B2fovJH9kdi0jBPY6oIEgbFN2QdZ 6IBDradg==; Received: from ppp118-209-220-84.lns20.mel8.internode.on.net ([118.209.220.84]:56534 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aRDiY-004MK5-UL for core@ietf.org; Thu, 04 Feb 2016 17:48:38 +1100 To: core@ietf.org From: Christian Groves Message-ID: <56B2F440.3050506@nteczone.com> Date: Thu, 4 Feb 2016 17:48:32 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [core] Binding attributes in draft-ietf-core-interfaces 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, 04 Feb 2016 06:48:44 -0000 Hello, I'm reading clause 5.1/draft-ietf-core-interfaces on boundto attributes. It specifies the interaction between pmin/pmax attributes and the "change step", "Greater than" and "less than" attributes. The draft doesn't limit which attributes may appear so I take it its possible to specify all of them in a single binding. Is this correct? If it is it leads to the issue of the interaction between the "change step" and "greater than" and "less than" attributes. I didn't see this described anywhere? E.g. for a temperature reading if st=5, lt=10, gt=26 is set and the initial ambient temperature was 20 when set. The temperature rises to 30. I could assume there's a notification at 25 related to st=5 Then there's a notification at 26 related to gt=26 However is there a notification at 30? The text for change step indicates "how much the value of a resource SHOULD change before sending a new notification (compared to the value of the last notification)". The last notification in this case is 26 which would make the change step 31. A possible alternate interpretation is that notifications only occur when the change step is below 10 or over 26. Alternatively a new change step notification above would seem superfluous if there's always a notification whenever the temperature changes above 26. What was the intention with the attributes? Regards, Christian G From nobody Wed Feb 3 23:22:34 2016 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 520C21A19E9 for ; Wed, 3 Feb 2016 23:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 sXQQoVapJOoS for ; Wed, 3 Feb 2016 23:22:31 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCD191A0AFE for ; Wed, 3 Feb 2016 23:22:31 -0800 (PST) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 6E9A738F26 for ; Wed, 3 Feb 2016 23:22:31 -0800 (PST) From: "Jim Schaad" To: References: In-Reply-To: Date: Wed, 3 Feb 2016 23:19:57 -0800 Message-ID: <02a701d15f1c$7428d0d0$5c7a7270$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AdFfGDW2+0YJpoH7TSy4hWQxoefQRQABBCZg Archived-At: Subject: [core] FW: Question on RFC 7252 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, 04 Feb 2016 07:22:33 -0000 In section 2.2, these is discussion dealing with figure 5 about how to deal with the case where a server can perform an operation, but it may take a while to do and it does not want the client to continually send it messages or time out waiting for a response. The solution presented requires that a token be present in the original request so that it can be tied to the eventual response message. There does not appear to be any text dealing with the case of a token not being present. What is the proper response to say - ask again but make sure there is a token in the request this time? One could start the request processing and respond with a 5.03 - service unavailable and an estimate of how long it will take to complete the request but that seems wrong some how What is the correct response to give if the separate message cannot be sent anytime soon because the server already has a message in its cache with the message id of the original request? I am assuming, and believe that the text in section 4.4 says that messages ids must be unique for the sender to a specific address so the changes are low unless the server is using a hit cache for multiple recipients. Jim From nobody Thu Feb 4 00:22:35 2016 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 837EE1A1B00 for ; Thu, 4 Feb 2016 00:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 WyJLm_DdtJK0 for ; Thu, 4 Feb 2016 00:22:31 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8591A0363 for ; Thu, 4 Feb 2016 00:22:31 -0800 (PST) Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id CEA021720A1; Thu, 4 Feb 2016 09:22:29 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 4vbySiOd8pC0; Thu, 4 Feb 2016 09:22:28 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id C37AE1720B3; Thu, 4 Feb 2016 09:22:27 +0100 (CET) Message-ID: <56B30A42.8080001@tzi.org> Date: Thu, 04 Feb 2016 09:22:26 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Jim Schaad References: <02a701d15f1c$7428d0d0$5c7a7270$@augustcellars.com> In-Reply-To: <02a701d15f1c$7428d0d0$5c7a7270$@augustcellars.com> 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] FW: Question on RFC 7252 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, 04 Feb 2016 08:22:33 -0000 Hi Jim, > In section 2.2, these is discussion dealing with figure 5 about how to deal > with the case where a server can perform an operation, but it may take a > while to do and it does not want the client to continually send it messages > or time out waiting for a response. The solution presented requires that a > token be present in the original request so that it can be tied to the > eventual response message. There does not appear to be any text dealing with > the case of a token not being present. There is always a token present (it may be zero-length, but an empty token is still a token that is distinguishable from all other tokens). > What is the proper response to say - ask again but make sure there is a > token in the request this time? One could start the request processing and > respond with a 5.03 - service unavailable and an estimate of how long it > will take to complete the request but that seems wrong some how That kind of response is different from a separate response as discussed here and in section 5.2.2. It may be quite appropriate, e.g. if the server simply cannot keep request state for the time that it needs to be able to prepare a response. (I think you are aware that section 5.9.3.4 suggests using max-age for indicating when a new request should be attempted.) > What is the correct response to give if the separate message cannot be sent > anytime soon because the server already has a message in its cache with the > message id of the original request? Not sure I can parse this. If the server already has a (request?) message in its cache with the message id of the original request, it simply repeats the response it already sent. > I am assuming, and believe that the > text in section 4.4 says that messages ids must be unique for the sender to > a specific address so the changes are low unless the server is using a hit > cache for multiple recipients. Message-IDs are per endpoint (peer endpoint in case of receiving a CON/NON or sending an ACK/RST). Grüße, Carsten From nobody Thu Feb 4 05:52:25 2016 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 837471B2FA3; Thu, 4 Feb 2016 05:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 oxbnyHszI8lJ; Thu, 4 Feb 2016 05:52:22 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFA21B2FA6; Thu, 4 Feb 2016 05:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5644; q=dns/txt; s=iport; t=1454593940; x=1455803540; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=WjPujQ7LIggqVo0Lgi24NQVowx6mc68K5hC3kB24wyQ=; b=RcZl+IUTAnNKrpqawED5x8U6VI67b3NVdLrTmEnVt4vk8FAXDdPtfHKI i3B/4aD2pIxZ7LhKuqfQQ0+RQnLf6xqtAu6As80P/XdFYbVU8keQ5uZxF Y4yA7GJsDbH5omneqk5xIF+LUtezHPBAQIQka51218ytrrw+BaiSIQ9IO I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBACiVrNW/xbLJq1ehAxtiFuychcKh?= =?us-ascii?q?WwCggMBAQEBAQGBC4RCAQEEAQEBIA8BBTQCCgEQCQIYAgIFFgsCAgkDAgECARU?= =?us-ascii?q?wBgEMBgIBAYgXDpQynROPGwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEe4UXhDeEA?= =?us-ascii?q?hEBgx6BOgEElnGFSYgEgVuEQoMDhVGOQGKCAxmBSTsuAQGGeIEwAQEB?= X-IronPort-AV: E=Sophos;i="5.22,395,1449532800"; d="scan'208";a="630225059" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Feb 2016 13:52:17 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u14DqGuR019176; Thu, 4 Feb 2016 13:52:17 GMT To: Barry Leiba , Carsten Bormann References: <20151020210304.27062.87223.idtracker@ietfa.amsl.com> <5626AE89.70305@tzi.org> <56289F96.1090608@cisco.com> <56AE324E.2010403@tzi.org> From: Benoit Claise Message-ID: <56B35790.2090406@cisco.com> Date: Thu, 4 Feb 2016 14:52:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: core-chairs@ietf.org, The IESG , "core@ietf.org WG" Subject: Re: [core] Benoit Claise's Block on charter-ietf-core-01-01: (with BLOCK) 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, 04 Feb 2016 13:52:24 -0000 Hi Barry, Can we please use the tool (https://datatracker.ietf.org/doc/charter-ietf-core/history/) so that I can do a quick diff. Regards, B. > Benoît, can you have a look at this version?: >> An edited version charter-ietf-core-01-01 with detailed history is now at >> https://svn.tools.ietf.org/svn/wg/core/charter-ietf-core.txt > Barry > > > On Sun, Jan 31, 2016 at 11:11 AM, Carsten Bormann wrote: >> Hi Barry, >> >> I'm back in Germany. >> >> I have expunged DICE (which has now closed) by replacing it with a >> reference to the security area in general (for DTLS over SMS), with a >> reference to the TLS WG (on DTLS specific efficiency work), and simply >> striking DICE from the list of WGs to coordinate with. That should >> cover Stephen's comments. >> >> Re Benoit's input (key: >>>>>> and >> are Benoît; >>> are Carsten) >>>>>> - "CoRE will also develop a way to make RESTCONF-style management >>>>>> functions >>>>>> available via CoAP that is appropriate for constrained node networks. >>>>>> This >>>>>> will require very close coordination with NETCONF and other operations >>>>>> and >>>>>> management working groups." >>>>>> >>>>>> What is the goal of this coordination with NETCONF? >>>>>> Could RESTCONF be reused? If not, why not? >>>>>> If yes, will RESTCONF need to be modified? >>>>> We want to coordinate with the NETCONF WG to ensure that the result of >>>>> our work makes sense as a part of the overall NETCONF family. >>>> Thanks. The coordination objectives should be mentioned in the charter. >>>>> The basis for COMI is RESTCONF, but there will be a need for some >>>>> streamlining. >>>> Can you expand on this, or point to a draft section/email thread. >> The main draft is draft-vanderstok-core-comi, and there are some >> additional considerations in draft-veillette-core-cool. >> >> (Or did you ask for text/pointers to be in the charter?) >> >>>>> It is not clear whether this will lead to modifications >>>>> of RESTCONF itself; more likely COMI will just be a dialect that is >>>>> applicable to very constrained devices. There are different approaches >>>>> on the question whether the YANG models have to take some specific care >>>>> about being used in COMI, >> (I was alluding to the COOL work here.) >> >>>> (I've not been following the core mailing list and I don't know which >>>> specifics you speak about) >>>> I hope you will not go that path. >>>> This would be a failure from an OPS point of view: we need a single YANG >>>> data model language, and not another data model language. >> One objective that has been repeatedly stated in the COMI work is that >> any random YANG module should be usable with COMI, but there are still >> discussions whether this will be a less efficient mode and/or we should >> be leaving out some parts (RPC has been stated as an example). I think >> we have been progressing towards enabling full coverage. There may, >> however, be some considerable efficiency gains that can be reaped by >> evolving YANG modules in a specific way. >> >>>> In the end, if >>>> there are YANG specifics for constrained node networks, then it's a >>>> different data model language. >> I think this statement reflects the current direction well, however, >> there may be some willingness to do additional work (such as COOL's SID >> files) in exchange for significant reductions in the message size. >> >>>> To illustrate my point: shall we see RFC 7223bis, A YANG Data Model for >>>> Interface Management for constrained networks? >> We already have RFC 7388, and we'd rather get more integration with the >> YANG world than less. >> >>>> Unless I miss something on the above, this should even mentioned in the core >>>> charter. >>>> >>>> CoRE will also develop a way to make RESTCONF-style management >>>> functions available, based on YANG, via CoAP that is appropriate for >>>> constrained >>>> node networks. >>>> >>>> + >>>> >>>> No YANG specifics for constrained nodes network ... >> I somewhat nebulously phrased that as: >> >> Besides continuing to examine operational and manageability aspects of >> the CoAP protocol itself, CoRE will also develop a way to make >> RESTCONF-style management functions available via CoAP that is >> appropriate for constrained node networks. This will require very close >> coordination with NETCONF and other operations and management working >> groups. The YANG modeling language is not a target for change in >> this process, however additional supporting mechanisms may be >> employed in specific cases where significant performance gains are >> both attainable and required. >> >> (Maybe this can still be improved.) >> >>>> And LWM2M? >>>> >>>> Do we need to expand a bit on those in the charter? I guess so >> I have added to the above: >> >> The working >> group will continue to consider the OMA LWM2M management functions >> as a well-accepted alternative form of management and provide >> support at the CoAP protocol level where required. >> >> That wording is obviously even more up for discussion: WG, please chime >> in (potentially after limiting the CC list to core@ietf.org). >> >> An edited version charter-ietf-core-01-01 with detailed history is now at >> https://svn.tools.ietf.org/svn/wg/core/charter-ietf-core.txt >> >> Grüße, Carsten >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > . > From nobody Thu Feb 4 05:58:23 2016 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 5E4F21B2F92 for ; Thu, 4 Feb 2016 05:58:21 -0800 (PST) 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 fRpaK14SCLka for ; Thu, 4 Feb 2016 05:58:19 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 07AF81B2EB9 for ; Thu, 4 Feb 2016 05:58:18 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id n128so45639285pfn.3 for ; Thu, 04 Feb 2016 05:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=4lTmSeh6CIJz0u6h1QZgpyk1o3xNn0GPaBxPYur2etE=; b=zpMwtOjIf1LMoEgUUYv7zLki4GHXzAMbCvFpYG+bI/yLApxb+6JsKobXDsBw4/YZ7q FzE8t9qOc6p0kmgI4gnKM9aJxMSZxR3lDYn4V2L3Tw2kh0jjH0xYGCk9pCo/UvWOJLFy F/+Cq+rw9GJMcd6DPav4c55icDV1ezLBI+IWY5RSZXhZsYd4KnkZWGv27QYP4lY7GZ8b rO4EvzNtv2hmCe9bmyJ0IyGIOgPRJvZ83RNcv+OlbZ9lR2BrmGcpkDbQcFS3wTRz/DLH q4XTiyPPdj+ozlCE5h9ZsMjCsdMT8edBsRciEHn5oLYpwM2g/ZtnuD7GQMiwFK8X1BX0 VkHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=4lTmSeh6CIJz0u6h1QZgpyk1o3xNn0GPaBxPYur2etE=; b=GIpjwoF4CZ7TeaXEFn9CUqPmwl9bIuKz741Rj4LkE2Jk3NM3UE/ugeKaw+y6bx9w1M Ns2dnRz4Qi2YqiaY+lFIj69Z6zxPRz01oIlOXX4Es5OBF0ZgJsxQlWRNvywbgOpiFnCl YFz3THiy5HfueiG+HpQWAlz8P3RRNvFvx/g5yXXHOgNvN+2a00/NBx+Ln2iQkKMgOz/6 JwE7oHmOoMG5ipgRL1SV2EQmM1CndS9OGA7+ZAF8BCA5k3Okf6vYFGkaSdvMRhQDhrSs YzfOSBlhzlNnPYCH5xn7RIaS4XKgs0IH+JB70XsdricDDQRvfCWmI967X7sWQdCgXvss B8UA== X-Gm-Message-State: AG10YOQZPy5cnY6cH8t+7HG++qJLO9aFHaxWYhOeJwnKyGcpr3kPHHnr7ZAgUp17SdT8tQ== X-Received: by 10.67.2.10 with SMTP id bk10mr10888904pad.26.1454594298512; Thu, 04 Feb 2016 05:58:18 -0800 (PST) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id ya4sm17497393pab.22.2016.02.04.05.58.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 05:58:17 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_921FFAB6-304B-48B8-8A7D-F63F2454DBE8" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <56B2F440.3050506@nteczone.com> Date: Thu, 4 Feb 2016 05:58:16 -0800 Message-Id: <7070C578-7687-45DE-A4CD-50231F2F28AF@gmail.com> References: <56B2F440.3050506@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core@ietf.org Subject: Re: [core] Binding attributes in draft-ietf-core-interfaces 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, 04 Feb 2016 13:58:21 -0000 --Apple-Mail=_921FFAB6-304B-48B8-8A7D-F63F2454DBE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Christian, Thanks for the question. I think we may need to clarify this some more = in the text or with a figure.=20 The notification is controlled by a state machine driven by new sample = values. I think the part we need to clarify is:=20 *Whether a notification is generated depends on the state reported in = the moss recent previous notification, as well as the current sample = value, and the notification attribute values. So saynig "the temperature rises to 30" we need to indicate the sequence = of values which were sampled between 20 and 30, and follow the=20 state machine. You gave sample values of 20, 25, 26, and 30. Let's assume that these = values are sampled in sequence.=20 Assume that the initial value of 20 was the last reported value, and set = the state of the state machine. The next sample is 25, which causes a notification (report) to be = generated due to the st=3D5 attribute. The new most recent value is now = 25. The next sample is 26, which generates a notification due to the gt=3D26 = attribute, The new most recent value is now 26. The next sample is 30, which does not generate a notification since the = last reported value was 26 and no new reporting condition is met. Does this make sense? If so, I will add this to the issue list for the = next draft update. Also, I see that we are not clearly defining what happens when a sampled = value is exactly equal to a threshold value. In the analysis above, we = assume that a threshold value is a reporting condition, but we will need = to clearly specify "greater" vs. "greater or equal" instead of = "crossing" as in the text. Best regards, Michael PS there is some reference implementation code for OMA LWM2M which = follows the definition in the CoRE Interfaces draft: = https://github.com/connectIOT/lwm2m-objects/blob/master/LWM2M_resource.cpp= = = https://github.com/connectIOT/lwm2m-objects/blob/master/LWM2M_resource_att= ributes.cpp = > On Feb 3, 2016, at 10:48 PM, Christian Groves = wrote: >=20 > Hello, >=20 > I'm reading clause 5.1/draft-ietf-core-interfaces on boundto = attributes. It specifies the interaction between pmin/pmax attributes = and the "change step", "Greater than" and "less than" attributes. The = draft doesn't limit which attributes may appear so I take it its = possible to specify all of them in a single binding. Is this correct? >=20 > If it is it leads to the issue of the interaction between the "change = step" and "greater than" and "less than" attributes. I didn't see this = described anywhere? >=20 > E.g. for a temperature reading if st=3D5, lt=3D10, gt=3D26 is set and = the initial ambient temperature was 20 when set. > The temperature rises to 30. > I could assume there's a notification at 25 related to st=3D5 > Then there's a notification at 26 related to gt=3D26 > However is there a notification at 30? >=20 > The text for change step indicates "how much the value of a resource = SHOULD change before sending a new notification (compared to the value = of the last notification)". The last notification in this case is 26 = which would make the change step 31. >=20 > A possible alternate interpretation is that notifications only occur = when the change step is below 10 or over 26. Alternatively a new change = step notification above would seem superfluous if there's always a = notification whenever the temperature changes above 26. >=20 > What was the intention with the attributes? >=20 > Regards, Christian G >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_921FFAB6-304B-48B8-8A7D-F63F2454DBE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Christian,

Thanks for the question. I think we may need to clarify this = some more in the text or with a figure. 

The notification is controlled by a = state machine driven by new sample values.

I think the part we need to clarify = is: 
*Whether a notification is generated = depends on the state reported in the moss recent previous notification, = as well as the current sample value, and the notification attribute = values.

So = saynig "the temperature rises to 30" we need to indicate the sequence of = values which were sampled between 20 and 30, and follow = the 
state machine.

You gave sample values of 20, 25, 26, = and 30. Let's assume that these values are sampled in = sequence. 

Assume that the initial value of 20 was the last reported = value, and set the state of the state machine.

The next sample is 25, which causes a = notification (report) to be generated due to the st=3D5 attribute. The = new most recent value is now 25.

The next sample is 26, which generates = a notification due to the gt=3D26 attribute, The new most recent value = is now 26.

The = next sample is 30, which does not generate a notification since the last = reported value was 26 and no new reporting condition is met.

Does this make sense? If = so, I will add this to the issue list for the next draft = update.

Also, = I see that we are not clearly defining what happens when a sampled value = is exactly equal to a threshold value. In the analysis above, we assume = that a threshold value is a reporting condition, but we will need to = clearly specify "greater" vs. "greater or equal" instead of "crossing" = as in the text.

Best regards,

Michael

PS there is some reference implementation code for OMA LWM2M = which follows the definition in the CoRE Interfaces draft:

https://github.com/connectIOT/lwm2m-objects/blob/master/LWM2M_r= esource.cpp
https://github.com/connectIOT/lwm2m-objects/blob/master/LWM2M_r= esource_attributes.cpp


On Feb 3, 2016, at 10:48 PM, Christian Groves <Christian.Groves@nteczone.com> wrote:

Hello,

I'm reading clause = 5.1/draft-ietf-core-interfaces on boundto attributes. It specifies the = interaction between pmin/pmax attributes and the "change step", "Greater = than" and "less than" attributes. The draft doesn't limit which = attributes may appear so I take it its possible to specify all of them = in a single binding. Is this correct?

If it = is it leads to the issue of the interaction between the "change step" = and "greater than" and "less than" attributes. I didn't see this = described anywhere?

E.g. for a temperature = reading if st=3D5, lt=3D10, gt=3D26 is set and the initial ambient = temperature was 20 when set.
The temperature rises to = 30.
I could assume there's a notification at 25 related to = st=3D5
Then there's a notification at 26 related to = gt=3D26
However is there a notification at 30?

The text for change step indicates "how much = the value of a resource SHOULD change before sending a new notification = (compared to the value of the last notification)". The last notification = in this case is 26 which would make the change step 31.

A possible alternate interpretation is that notifications = only occur when the change step is below 10 or over 26. Alternatively a = new change step notification above would seem superfluous if there's = always a notification whenever the temperature changes above 26.

What was the intention with the attributes?

Regards, Christian G

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

= --Apple-Mail=_921FFAB6-304B-48B8-8A7D-F63F2454DBE8-- From nobody Thu Feb 4 05:59:14 2016 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 64A7C1B2EB9; Thu, 4 Feb 2016 05:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 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, 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 lIV92JNZGosL; Thu, 4 Feb 2016 05:59:06 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9601B2FA4; Thu, 4 Feb 2016 05:59:06 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id f81so92974295iof.0; Thu, 04 Feb 2016 05:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=AR1hYmseTj6xn6PJuHh33tM3rgU6pIzQ2my+3sKmyOw=; b=ITn6bXUCyV8xt9/LIN0D66dDEcMztd6U2Jt92keTokJvR9DAcLFuvjx7VUlrQgsOEf rPK7VEz7D5fwzAMb8mozUVyjRfsJWCGA+jemOra2LWVP3mg4l1vF6emsflagJjB1ROmg iZsCa7sXGvmvvm9B2Hmim94B4QWUW6FME1fJYrwQy/7BqZp6GIzhemIOWkf9bQMt+DCu +0GNBSIKrDEAMKzjLXoLIFELsvDiptRIyZO9JJeRj7/k94C0puAhC6oNGvojY9YuSlrm O4B8Uix8+PBuSyYdHxvRAudELslK/v63tKkGfClLUvjhsZx2J+ipZAZpO3EF0onRZ+wM IAkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AR1hYmseTj6xn6PJuHh33tM3rgU6pIzQ2my+3sKmyOw=; b=cyqPsAfy01K7UkZk+5wkLxOAiv06PTKmiEj1xjo7OpZIte8/2T1R35papWdv5mTz9E rgMtFzoA/QLrva5Wvxf7czm0gZ8NUP6uAyzv/p+qbKPZB7j4a3zasPv21RxWaPeQyRKR Yki8zgEuHrOFZinuiby+HxWqTC/kK05rW6lQkt5hDchKkUA0vVn1bgUQghSeuPpc+DvY VoiOavpWG6hjI69Az/Sx15dX4270mzt+nESKCa84UphUmNcqohhw5UQQUYl1rzeFoBaY LhMRHjsiaxlcI/v676sGd+cYDH69d6CpC2UhfQJ1hXGbObe/JrpFJLiBjjXnr7sO7HNS 7mfQ== X-Gm-Message-State: AG10YOTmzIkOFMq5x7sJ5TXfIUbWpY2OeKKistG6Q5WxpAIUDBtHRLeSdTsbn7J59s9gCvPeknu5uaWIRBw3YA== MIME-Version: 1.0 X-Received: by 10.107.131.206 with SMTP id n75mr9011793ioi.189.1454594346100; Thu, 04 Feb 2016 05:59:06 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.156.5 with HTTP; Thu, 4 Feb 2016 05:59:06 -0800 (PST) In-Reply-To: <56B35790.2090406@cisco.com> References: <20151020210304.27062.87223.idtracker@ietfa.amsl.com> <5626AE89.70305@tzi.org> <56289F96.1090608@cisco.com> <56AE324E.2010403@tzi.org> <56B35790.2090406@cisco.com> Date: Thu, 4 Feb 2016 08:59:06 -0500 X-Google-Sender-Auth: eZFaawhU2VulO4gqjpWo3R_J_hE Message-ID: From: Barry Leiba To: Benoit Claise Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: core-chairs@ietf.org, The IESG , "core@ietf.org WG" Subject: Re: [core] Benoit Claise's Block on charter-ietf-core-01-01: (with BLOCK) 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, 04 Feb 2016 13:59:08 -0000 > Can we please use the tool > (https://datatracker.ietf.org/doc/charter-ietf-core/history/) so that I c= an > do a quick diff. Sorry; done -- please check it. b >> Beno=C3=AEt, can you have a look at this version?: >>> >>> An edited version charter-ietf-core-01-01 with detailed history is now = at >>> https://svn.tools.ietf.org/svn/wg/core/charter-ietf-core.txt >> >> Barry >> >> >> On Sun, Jan 31, 2016 at 11:11 AM, Carsten Bormann wrote: >>> >>> Hi Barry, >>> >>> I'm back in Germany. >>> >>> I have expunged DICE (which has now closed) by replacing it with a >>> reference to the security area in general (for DTLS over SMS), with a >>> reference to the TLS WG (on DTLS specific efficiency work), and simply >>> striking DICE from the list of WGs to coordinate with. That should >>> cover Stephen's comments. >>> >>> Re Benoit's input (key: >>>>>>> >>>>>>> and >> are Beno=C3=AEt; >>> are Carsten) >>>>>>> - "CoRE will also develop a way to make RESTCONF-style management >>>>>>> functions >>>>>>> available via CoAP that is appropriate for constrained node network= s. >>>>>>> This >>>>>>> will require very close coordination with NETCONF and other >>>>>>> operations >>>>>>> and >>>>>>> management working groups." >>>>>>> >>>>>>> What is the goal of this coordination with NETCONF? >>>>>>> Could RESTCONF be reused? If not, why not? >>>>>>> If yes, will RESTCONF need to be modified? >>>>>> >>>>>> We want to coordinate with the NETCONF WG to ensure that the result = of >>>>>> our work makes sense as a part of the overall NETCONF family. >>>>> >>>>> Thanks. The coordination objectives should be mentioned in the charte= r. >>>>>> >>>>>> The basis for COMI is RESTCONF, but there will be a need for some >>>>>> streamlining. >>>>> >>>>> Can you expand on this, or point to a draft section/email thread. >>> >>> The main draft is draft-vanderstok-core-comi, and there are some >>> additional considerations in draft-veillette-core-cool. >>> >>> (Or did you ask for text/pointers to be in the charter?) >>> >>>>>> It is not clear whether this will lead to modifications >>>>>> of RESTCONF itself; more likely COMI will just be a dialect that is >>>>>> applicable to very constrained devices. There are different >>>>>> approaches >>>>>> on the question whether the YANG models have to take some specific >>>>>> care >>>>>> about being used in COMI, >>> >>> (I was alluding to the COOL work here.) >>> >>>>> (I've not been following the core mailing list and I don't know which >>>>> specifics you speak about) >>>>> I hope you will not go that path. >>>>> This would be a failure from an OPS point of view: we need a single >>>>> YANG >>>>> data model language, and not another data model language. >>> >>> One objective that has been repeatedly stated in the COMI work is that >>> any random YANG module should be usable with COMI, but there are still >>> discussions whether this will be a less efficient mode and/or we should >>> be leaving out some parts (RPC has been stated as an example). I think >>> we have been progressing towards enabling full coverage. There may, >>> however, be some considerable efficiency gains that can be reaped by >>> evolving YANG modules in a specific way. >>> >>>>> In the end, if >>>>> there are YANG specifics for constrained node networks, then it's a >>>>> different data model language. >>> >>> I think this statement reflects the current direction well, however, >>> there may be some willingness to do additional work (such as COOL's SID >>> files) in exchange for significant reductions in the message size. >>> >>>>> To illustrate my point: shall we see RFC 7223bis, A YANG Data Model f= or >>>>> Interface Management for constrained networks? >>> >>> We already have RFC 7388, and we'd rather get more integration with the >>> YANG world than less. >>> >>>>> Unless I miss something on the above, this should even mentioned in t= he >>>>> core >>>>> charter. >>>>> >>>>> CoRE will also develop a way to make RESTCONF-style management >>>>> functions available, based on YANG, via CoAP that is appropriate >>>>> for >>>>> constrained >>>>> node networks. >>>>> >>>>> + >>>>> >>>>> No YANG specifics for constrained nodes network ... >>> >>> I somewhat nebulously phrased that as: >>> >>> Besides continuing to examine operational and manageability aspects = of >>> the CoAP protocol itself, CoRE will also develop a way to make >>> RESTCONF-style management functions available via CoAP that is >>> appropriate for constrained node networks. This will require very >>> close >>> coordination with NETCONF and other operations and management workin= g >>> groups. The YANG modeling language is not a target for change in >>> this process, however additional supporting mechanisms may be >>> employed in specific cases where significant performance gains are >>> both attainable and required. >>> >>> (Maybe this can still be improved.) >>> >>>>> And LWM2M? >>>>> >>>>> Do we need to expand a bit on those in the charter? I guess so >>> >>> I have added to the above: >>> >>> The working >>> group will continue to consider the OMA LWM2M management functions >>> as a well-accepted alternative form of management and provide >>> support at the CoAP protocol level where required. >>> >>> That wording is obviously even more up for discussion: WG, please chime >>> in (potentially after limiting the CC list to core@ietf.org). >>> >>> An edited version charter-ietf-core-01-01 with detailed history is now = at >>> https://svn.tools.ietf.org/svn/wg/core/charter-ietf-core.txt >>> >>> Gr=C3=BC=C3=9Fe, Carsten >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> >> . >> > From nobody Thu Feb 4 08:05:29 2016 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 9D7481B321E for ; Thu, 4 Feb 2016 08:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJWKlDneYYEU for ; Thu, 4 Feb 2016 08:05:22 -0800 (PST) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 B2AF61B321C for ; Thu, 4 Feb 2016 08:05:22 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id w123so49407481pfb.0 for ; Thu, 04 Feb 2016 08:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ZnPCowPEuv7eZRxNnynSYKcp3uUe7QBkHlTw6a37OtY=; b=nLACsDaofmQYfJsZ6RDFlpy9WsU8OQy0Ig52XnH9uk52odxb/PvfipvCE9KVFYsI0h K28Rqw1IwkLHG2xFq5WYcjjpYf8r19O3lDgq7SphQX5LJf5xd6D1CQfgtG7Dwo+6N72E XO12lc3/YiiMA/5Ck7Qmo9SGX0qyKdtZVEg5kyhBojfOOTnNWcJiZhna8w+sX/tLiXh9 Km+NYVR8tPBbyKLSpZX7ccuno1usglItW5xFN3p8Gw0JHmHPUBprEd5n306p/fAaTVOu 3vcKeHk2iL+TuGDNVzHyMArym9n4dIcCo5nTrz7fkmwMxmW1ijK1N0lBecQviR0yRtYG UVpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ZnPCowPEuv7eZRxNnynSYKcp3uUe7QBkHlTw6a37OtY=; b=QvoyKlqZ8lThlocPHuro/mXHDX2JP3hqG6x08nnl5jYzDWPjtA6Adb0jpdnrrMb3Fb HH3h2vDHtBb+OtbQuEfqyCTd4AZbYMdcWI00JppT2MYKtXLDkH0gTjkmNejFpyDi3U2w Bj0IUYvIG5U1S7m1gRxsvePW4Oj0gCeW6LX7J94lcJN2eLH7bBaWeU3UdovCsnxoo10/ jyQT/Zyhh/lNu1G/shnm33m/WgtrxcEpvJf6JjNZ4b6ZC1KHR/CBCI51GrdMVcUB34WG iueuwd+hOzYf410nD1CDVoV8SBcGKdf7uI/0Qs+hzbp8xfO97JuRAy33h1LfcLhVHLLc smxQ== X-Gm-Message-State: AG10YORytJyTnbc6feAbqnx9FG20Iwf7X6hZTujoGDnmaRMvXj7us3D53+fLi4/C8TJ1kQ== X-Received: by 10.98.7.219 with SMTP id 88mr12021719pfh.49.1454601922431; Thu, 04 Feb 2016 08:05:22 -0800 (PST) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id s90sm12636246pfa.49.2016.02.04.08.05.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 08:05:21 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3F52D36C-AA98-46E2-B92D-6295F34078F1" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <7070C578-7687-45DE-A4CD-50231F2F28AF@gmail.com> Date: Thu, 4 Feb 2016 08:05:19 -0800 Message-Id: <179DFA4D-9EB7-4053-A24A-A42A6C6EBA63@gmail.com> References: <56B2F440.3050506@nteczone.com> <7070C578-7687-45DE-A4CD-50231F2F28AF@gmail.com> To: Christian Groves X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core@ietf.org Subject: Re: [core] Binding attributes in draft-ietf-core-interfaces 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, 04 Feb 2016 16:05:25 -0000 --Apple-Mail=_3F52D36C-AA98-46E2-B92D-6295F34078F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The code I pointed to makes an arbitrary distinction placing a sample = value greater than the threshold setting in the band above the = threshold, and a sample value less than or equal to the threshold = setting (lt or gt) within the "band" below the threshold, and a places . = It does this in order to generalize to an arbitrary number of threshold = values. To more precisely implement the implied semantics of "gt" and = "lt" the comparison should be done on 2 threshold values and compared = for s < limits[0] and s > limits[1], where s is the sample value, = limits[0] is "lt" and limits[1] is "gt". If no one objects, I will create an issue to update the draft text to = clarify that (s > gt) is the upper band and (s < lt) is the lower band, = and provide reference implementation code to that effect. /*=20 Determine which band [0..num_limits] the provided sample is in Works with any number of bands 2 to MAX_LIMITS+1 using an array of limit = settings */ int band(sample s) { if (s > limits[num_limits-1]){ return num_limits; } else{ for ( int limit =3D 0; limit < num_limits; limit++ ){ if (s <=3D limits[limit]){ return limit; } } } return -1; } > On Feb 4, 2016, at 5:58 AM, Michael Koster = wrote: >=20 > Hi Christian, >=20 > Thanks for the question. I think we may need to clarify this some more = in the text or with a figure.=20 >=20 > The notification is controlled by a state machine driven by new sample = values. >=20 > I think the part we need to clarify is:=20 > *Whether a notification is generated depends on the state reported in = the moss recent previous notification, as well as the current sample = value, and the notification attribute values. >=20 > So saynig "the temperature rises to 30" we need to indicate the = sequence of values which were sampled between 20 and 30, and follow the=20= > state machine. >=20 > You gave sample values of 20, 25, 26, and 30. Let's assume that these = values are sampled in sequence.=20 >=20 > Assume that the initial value of 20 was the last reported value, and = set the state of the state machine. >=20 > The next sample is 25, which causes a notification (report) to be = generated due to the st=3D5 attribute. The new most recent value is now = 25. >=20 > The next sample is 26, which generates a notification due to the gt=3D26= attribute, The new most recent value is now 26. >=20 > The next sample is 30, which does not generate a notification since = the last reported value was 26 and no new reporting condition is met. >=20 > Does this make sense? If so, I will add this to the issue list for the = next draft update. >=20 > Also, I see that we are not clearly defining what happens when a = sampled value is exactly equal to a threshold value. In the analysis = above, we assume that a threshold value is a reporting condition, but we = will need to clearly specify "greater" vs. "greater or equal" instead of = "crossing" as in the text. >=20 > Best regards, >=20 > Michael >=20 > PS there is some reference implementation code for OMA LWM2M which = follows the definition in the CoRE Interfaces draft: >=20 > = https://github.com/connectIOT/lwm2m-objects/blob/master/LWM2M_resource.cpp= = > = https://github.com/connectIOT/lwm2m-objects/blob/master/LWM2M_resource_att= ributes.cpp = >=20 >=20 >> On Feb 3, 2016, at 10:48 PM, Christian Groves = > = wrote: >>=20 >> Hello, >>=20 >> I'm reading clause 5.1/draft-ietf-core-interfaces on boundto = attributes. It specifies the interaction between pmin/pmax attributes = and the "change step", "Greater than" and "less than" attributes. The = draft doesn't limit which attributes may appear so I take it its = possible to specify all of them in a single binding. Is this correct? >>=20 >> If it is it leads to the issue of the interaction between the "change = step" and "greater than" and "less than" attributes. I didn't see this = described anywhere? >>=20 >> E.g. for a temperature reading if st=3D5, lt=3D10, gt=3D26 is set and = the initial ambient temperature was 20 when set. >> The temperature rises to 30. >> I could assume there's a notification at 25 related to st=3D5 >> Then there's a notification at 26 related to gt=3D26 >> However is there a notification at 30? >>=20 >> The text for change step indicates "how much the value of a resource = SHOULD change before sending a new notification (compared to the value = of the last notification)". The last notification in this case is 26 = which would make the change step 31. >>=20 >> A possible alternate interpretation is that notifications only occur = when the change step is below 10 or over 26. Alternatively a new change = step notification above would seem superfluous if there's always a = notification whenever the temperature changes above 26. >>=20 >> What was the intention with the attributes? >>=20 >> Regards, Christian G >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 --Apple-Mail=_3F52D36C-AA98-46E2-B92D-6295F34078F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The code I pointed to makes an arbitrary = distinction placing a sample value greater than the threshold setting in = the band above the threshold, and a sample value less than or equal to = the threshold setting (lt or gt) within the "band" below the threshold, = and a places . It does this in order to generalize to an arbitrary = number of threshold values. To more precisely implement the implied = semantics of "gt" and "lt" the comparison should be done on 2 threshold = values and compared for s < limits[0] and s > limits[1], where s = is the sample value, limits[0] is "lt" and limits[1] is "gt".

If no one objects, I = will create an issue to update the draft text to clarify that (s > = gt) is the upper band and (s < lt) is the lower band, and provide = reference implementation code to that effect.

/* 
Determine which = band [0..num_limits] the provided sample is in
Works with any number of bands 2 to MAX_LIMITS+1 using an = array of limit settings
*/
int band(sample s)
{
    if (s > limits[num_limits-1]){
        return num_limits;
    = }
    else{
        for ( int limit =3D = 0; limit < num_limits; limit++ = ){
            if (s <=3D limits[limit]){
    =             return limit;
      =       }
        }
    }
    return -1;
}


On = Feb 4, 2016, at 5:58 AM, Michael Koster <michaeljohnkoster@gmail.com> wrote:

Hi = Christian,

Thanks = for the question. I think we may need to clarify this some more in the = text or with a figure. 

The notification is controlled by a = state machine driven by new sample values.

I think the part we need to clarify = is: 
*Whether a notification is generated = depends on the state reported in the moss recent previous notification, = as well as the current sample value, and the notification attribute = values.

So = saynig "the temperature rises to 30" we need to indicate the sequence of = values which were sampled between 20 and 30, and follow = the 
state machine.

You gave sample values of 20, 25, 26, = and 30. Let's assume that these values are sampled in = sequence. 

Assume that the initial value of 20 was the last reported = value, and set the state of the state machine.

The next sample is 25, which causes a = notification (report) to be generated due to the st=3D5 attribute. The = new most recent value is now 25.

The next sample is 26, which generates = a notification due to the gt=3D26 attribute, The new most recent value = is now 26.

The = next sample is 30, which does not generate a notification since the last = reported value was 26 and no new reporting condition is met.

Does this make sense? If = so, I will add this to the issue list for the next draft = update.

Also, = I see that we are not clearly defining what happens when a sampled value = is exactly equal to a threshold value. In the analysis above, we assume = that a threshold value is a reporting condition, but we will need to = clearly specify "greater" vs. "greater or equal" instead of "crossing" = as in the text.

Best regards,

Michael

PS there is some reference implementation code for OMA LWM2M = which follows the definition in the CoRE Interfaces draft:

https://github.com/connectIOT/lwm2m-objects/blob/master/LWM2M_r= esource.cpp
https://github.com/connectIOT/lwm2m-objects/blob/master/LWM2M_r= esource_attributes.cpp


On Feb 3, 2016, at 10:48 PM, Christian Groves = <Christian.Groves@nteczone.com> wrote:

Hello,

I'm reading clause = 5.1/draft-ietf-core-interfaces on boundto attributes. It specifies the = interaction between pmin/pmax attributes and the "change step", "Greater = than" and "less than" attributes. The draft doesn't limit which = attributes may appear so I take it its possible to specify all of them = in a single binding. Is this correct?

If it = is it leads to the issue of the interaction between the "change step" = and "greater than" and "less than" attributes. I didn't see this = described anywhere?

E.g. for a temperature = reading if st=3D5, lt=3D10, gt=3D26 is set and the initial ambient = temperature was 20 when set.
The temperature rises to = 30.
I could assume there's a notification at 25 related to = st=3D5
Then there's a notification at 26 related to = gt=3D26
However is there a notification at 30?

The text for change step indicates "how much = the value of a resource SHOULD change before sending a new notification = (compared to the value of the last notification)". The last notification = in this case is 26 which would make the change step 31.

A possible alternate interpretation is that notifications = only occur when the change step is below 10 or over 26. Alternatively a = new change step notification above would seem superfluous if there's = always a notification whenever the temperature changes above 26.

What was the intention with the attributes?

Regards, Christian G

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


= --Apple-Mail=_3F52D36C-AA98-46E2-B92D-6295F34078F1-- From nobody Thu Feb 4 18:09:14 2016 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 86D651B2CB5 for ; Thu, 4 Feb 2016 18:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.01 X-Spam-Level: X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_22=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_46=0.6, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Q6LJWXu2ZPD for ; Thu, 4 Feb 2016 18:09:10 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 C78611B2CB0 for ; Thu, 4 Feb 2016 18:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=RMpQSpZXvwEW00q+8iTYauQNmIkNvknpb1nutXTOT9U=; b=jqk88+B2sYgB518kbU7aqr68qi zmrFYpHOSamW9UAFFwRfQlx9+F1pt+YLOlybErJrHocG0nIxY6lc4uCkazR2GOn1WN80HHEa0EbC7 EK63zn3YIz6hrG71UtYeGwqiG9j5nfEBT9Y8k0W0SinT07Dr7XajGWjHxrtoh22yD23Sod+Y4zBIN uBZDzspvHcrkLslFlYxW9W/TyUma7ISTxlE6XnsbRYLIPiWAA32VdcgOWNtBOkiPOEYhCaB1z+SBd xj00f7ShdkNsP3hz7WVLbxVd5mqQ03xpPTxzatGeTwj/M7rbc7tY3fKZ90du44S2tvIcY16hpTYQv ww5wNYvQ==; Received: from ppp118-209-214-147.lns20.mel8.internode.on.net ([118.209.214.147]:50582 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aRVpb-0013cX-5B; Fri, 05 Feb 2016 13:09:07 +1100 To: Michael Koster References: <56B2F440.3050506@nteczone.com> <7070C578-7687-45DE-A4CD-50231F2F28AF@gmail.com> <179DFA4D-9EB7-4053-A24A-A42A6C6EBA63@gmail.com> From: Christian Groves Message-ID: <56B4043C.5020502@nteczone.com> Date: Fri, 5 Feb 2016 13:09:00 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <179DFA4D-9EB7-4053-A24A-A42A6C6EBA63@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: core@ietf.org Subject: Re: [core] Binding attributes in draft-ietf-core-interfaces 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, 05 Feb 2016 02:09:13 -0000 Hello Michael, Thanks for the response and the references. I agree I think its worth clarifying the text about this. Please see my responses below marked [CNG]. I think there's several more issues that are worth clarifying: 1. Whether multiple instances of the attributes are allowed. E.g. is setting st=5,st=4 allowed? If so what would it mean? 2. For pmin it indicates wait time "even if it has changed" and for pmax it indicates wait time "regardless if it has changed". My assumption is that pmax is basically being used as a keepalive and is used to generate a notification with a state synchronisation value whether a value has changed or not. Is that correct? Its also not clear whether the value is the current value or the last reported value. e.g. if have st=5 and the last reported value is 25. Should the notification due to pmax be the current value say 26, or the last reported step value? For pmin I assume this is used to limit the number of notifications sent and only comes into play when something "has changed". I wonder how this works in an alarm type scenario, where I want to know immediately when a threshold as been reached, but I don't need a keepalive very often and I don't want to be bombarded by notifications once the threshold is reached. e.g. pmin=x ,pmax=300, gt=90 If I receive a notification due to pmax the current text says that the system must wait X seconds (i.e. /This parameter has lower priority than the period parameters, thus even if the Greater Than limit has been crossed, the time since the last notification SHOULD be between pmin and pmax/) due to pmin=x before triggering the notification. If the threshold is reached immediately after sending the pmax notification then it means that for X seconds some undesirable action may be occurring before I receive notification. I could set X to be a small value to minimise the delay but this has the effect of generating more messages. So I wonder if it would be possible to update the text in such a way that st,gt,lt are notified immediately when a value changes to meet the criteria but subsequent notifications related to the criteria are subject to pmin? 3. For the step value would it be possible to include a seed/start value? e.g. rather than being notified of initial value + step e.g.st=5 initial value=21.34, leading to notification of 26.34, 31.54 but instead be notified based on seed value e.g. st=5, seed=20, leading to a report of 25, 30. I don't know if such a thing was considered before? Regards, Christian On 5/02/2016 3:05 AM, Michael Koster wrote: > The code I pointed to makes an arbitrary distinction placing a sample > value greater than the threshold setting in the band above the > threshold, and a sample value less than or equal to the threshold > setting (lt or gt) within the "band" below the threshold, and a places > . It does this in order to generalize to an arbitrary number of > threshold values. To more precisely implement the implied semantics of > "gt" and "lt" the comparison should be done on 2 threshold values and > compared for s < limits[0] and s > limits[1], where s is the sample > value, limits[0] is "lt" and limits[1] is "gt". > > If no one objects, I will create an issue to update the draft text to > clarify that (s > gt) is the upper band and (s < lt) is the lower > band, and provide reference implementation code to that effect. > > /* > Determine which band [0..num_limits] the provided sample is in > Works with any number of bands 2 to MAX_LIMITS+1 using an array of > limit settings > */ > int band(sample s) > { > if (s > limits[num_limits-1]){ > return num_limits; > } > else{ > for ( int limit = 0; limit < num_limits; limit++ ){ > if (s <= limits[limit]){ > return limit; > } > } > } > return -1; > } > > >> On Feb 4, 2016, at 5:58 AM, Michael Koster >> > wrote: >> >> Hi Christian, >> >> Thanks for the question. I think we may need to clarify this some >> more in the text or with a figure. >> >> The notification is controlled by a state machine driven by new >> sample values. >> >> I think the part we need to clarify is: >> *Whether a notification is generated depends on the state reported in >> the moss recent previous notification, as well as the current sample >> value, and the notification attribute values. >> >> So saynig "the temperature rises to 30" we need to indicate the >> sequence of values which were sampled between 20 and 30, and follow the >> state machine. >> >> You gave sample values of 20, 25, 26, and 30. Let's assume that these >> values are sampled in sequence. >> >> Assume that the initial value of 20 was the last reported value, and >> set the state of the state machine. >> >> The next sample is 25, which causes a notification (report) to be >> generated due to the st=5 attribute. The new most recent value is now 25. >> >> The next sample is 26, which generates a notification due to the >> gt=26 attribute, The new most recent value is now 26. >> >> The next sample is 30, which does not generate a notification since >> the last reported value was 26 and no new reporting condition is met. [CNG] Wouldn't 30 be notified because it meets the gt=26 attribute criteria? I assumed that gt didn't result in a single notification but notification of all value changes over 26. I think it has to be clear whether the attributes are ORed or ANDed together to produce a notification. >> >> Does this make sense? If so, I will add this to the issue list for >> the next draft update. >> >> Also, I see that we are not clearly defining what happens when a >> sampled value is exactly equal to a threshold value. In the analysis >> above, we assume that a threshold value is a reporting condition, but >> we will need to clearly specify "greater" vs. "greater or equal" >> instead of "crossing" as in the text. [CNG] I agree this needs to be clarified, I was going to bring this up. From a user perspective wouldn't it be easier to say "greater than or equal to"? e.g. I want to set an alarm to trigger at 26. To me it's more logical to set it at 26 than to think I have to set it at 25.99 to report when 26 is hit. >> >> Best regards, >> >> Michael >> >> PS there is some reference implementation code for OMA LWM2M which >> follows the definition in the CoRE Interfaces draft: >> >> https://github.com/connectIOT/lwm2m-objects/blob/master/LWM2M_resource.cpp >> https://github.com/connectIOT/lwm2m-objects/blob/master/LWM2M_resource_attributes.cpp >> >> >>> On Feb 3, 2016, at 10:48 PM, Christian Groves >>> >> > wrote: >>> >>> Hello, >>> >>> I'm reading clause 5.1/draft-ietf-core-interfaces on boundto >>> attributes. It specifies the interaction between pmin/pmax >>> attributes and the "change step", "Greater than" and "less than" >>> attributes. The draft doesn't limit which attributes may appear so I >>> take it its possible to specify all of them in a single binding. Is >>> this correct? >>> >>> If it is it leads to the issue of the interaction between the >>> "change step" and "greater than" and "less than" attributes. I >>> didn't see this described anywhere? >>> >>> E.g. for a temperature reading if st=5, lt=10, gt=26 is set and the >>> initial ambient temperature was 20 when set. >>> The temperature rises to 30. >>> I could assume there's a notification at 25 related to st=5 >>> Then there's a notification at 26 related to gt=26 >>> However is there a notification at 30? >>> >>> The text for change step indicates "how much the value of a resource >>> SHOULD change before sending a new notification (compared to the >>> value of the last notification)". The last notification in this case >>> is 26 which would make the change step 31. >>> >>> A possible alternate interpretation is that notifications only occur >>> when the change step is below 10 or over 26. Alternatively a new >>> change step notification above would seem superfluous if there's >>> always a notification whenever the temperature changes above 26. >>> >>> What was the intention with the attributes? >>> >>> Regards, Christian G >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> > From nobody Sat Feb 6 19:59:16 2016 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 174FF1B31D6; Sat, 6 Feb 2016 19:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 Oa2NcQ3dGjJy; Sat, 6 Feb 2016 19:59:12 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F901B31BF; Sat, 6 Feb 2016 19:59:12 -0800 (PST) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id B654C38EF8; Sat, 6 Feb 2016 19:59:11 -0800 (PST) From: "Jim Schaad" To: References: <0c9901d14736$e2353940$a69fabc0$@augustcellars.com> <568AED5E.7000408@cs.tcd.ie> In-Reply-To: <568AED5E.7000408@cs.tcd.ie> Date: Sat, 6 Feb 2016 19:56:39 -0800 Message-ID: <050301d1615b$8ca13b70$a5e3b250$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQLlEEvf79rpkp+SgCb/nHXkvCWZkALyuLCEnOEAncA= Archived-At: Cc: core@ietf.org, Ace@ietf.org Subject: Re: [core] [Ace] Should we support padding for Enveloped/Encrypted Messages 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, 07 Feb 2016 03:59:15 -0000 Before I close this issue, does anyone else want to weight in? Jim > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Monday, January 04, 2016 2:09 PM > To: Jim Schaad ; cose@ietf.org > Cc: Ace@ietf.org > Subject: Re: [Ace] Should we support padding for Enveloped/Encrypted > Messages > > > I would argue to try define a padding mechanism here. > > As you note, it may be important later and there are some real issues when > dealing with constrained use-cases. In fact, in the limit one might want to define > a padding-only form for COSE to handle the case where the existence of any > traffic defeats any confidentiality protection. (E.g. sensor that fires a packet > when temp==20C.) I know that that'd not often be useful but I think there will be > times when it will. > > The argument that applications can best do this is not a bad one, but can be > countered. If a node has a common crypto library that ensures that padding can > be done consistently across multiple applications, which could be harder if not > defined at this layer. > (And even more likely, application developers don't care or don't bother or don't > know how to do this well.) > > Cheers, > S. > > PS: FWIW, I'd make the same argument for any protocol - I think we need to > define basic padding mechanisms whenever we can now so that we or others > can learn how to best use those later. > > > On 04/01/16 21:28, Jim Schaad wrote: > > Padding of content is useful for dealing with traffic analysis > > attacks. This can be seen as becoming important as it is now part of > > the basic framework of TLS 1.3. One possible simple analysis that can > > be performed against sensors is looking for thresholds in reported > > values. Just looking at the message length, one can tell the > > difference between '9.0' and '10.0' unless the first item is padded > > out to the same length. For example using either '09.0' or ' 9.0'. > > > > We currently do not have any facility to do a generic padding and it > > is not clear that we should provide one. The benefit is that it would > > allow for the ability to reduce the set of traffic analysis attacks. > > The down side is that we probably need to have some type of length > > field added to encrypted content for all messages. This means that we > > potentially have a single byte (or more depending on how it is done) to all > messages increasing the length. > > It is also not clear yet how much the IoT world cares about doing the > > type of protection in the near term. (It is possible that in time they > > may start > > caring.) > > > > One possible answer is to add the padding to the end of the current > > message ala the PKCS#7 padding. There would be N bytes appended to the > > end of the message, each containing the value of N. The default would > > be to append a single byte with the value of '1'. > > > > The use of padding would be described as being application specific > > rather than being generic. However the single byte would always need > > to be paid even if there was not padding done. > > > > At this time my inclination is to treat this as a problem that the > > application should be solving and to simply address it as a security > > consideration in the COSE message draft. > > > > Any comments? I would like to resolve this by the end of this week. > > > > Jim > > > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Wed Feb 10 01:49:09 2016 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 8534B1A0545 for ; Wed, 10 Feb 2016 01:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 r3H1RO5gS3lA for ; Wed, 10 Feb 2016 01:49:06 -0800 (PST) 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 2F2401A046D for ; Wed, 10 Feb 2016 01:49:06 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-54-56bb078ff4fe Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 17.6F.05041.F870BB65; Wed, 10 Feb 2016 10:49:03 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.36]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Wed, 10 Feb 2016 10:48:53 +0100 From: Mohit Sethi M To: "'core@ietf.org'" Thread-Topic: New Version Notification for draft-aura-eap-noob-00.txt Thread-Index: AdFihh2/WnLd5xyHRJ+BuP/LMH/wvABXyiyAAABJvuAAAEtBkA== Date: Wed, 10 Feb 2016 09:48:52 +0000 Message-ID: References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> <56B8B561.8040300@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbFdV7effXeYwdNGQYt9b9czW7yZuJHd gcnj+OvFrB5LlvxkCmCK4rJJSc3JLEst0rdL4MqYdfkiS8EJ64oje++wNTC2WHUxcnJICJhI LJ3/igXCFpO4cG89WxcjF4eQwGFGiXfTpzCBJIQEFjNKHNwuBmKzCRhITJ6ygh3EFhFQldj2 /DNYDbOAscTjlZtYQWxhAReJN88b2SBqXCXuXetmhrCdJA7/38sIYrMA9U49PQ/M5hXwlXj6 YjkrxOJXjBJ7PvwBS3AK+Ek8fbsX7DpGoOu+n1oDtUxc4taT+UwQVwtILNlznhnCFpV4+fgf K4StKHF1+nKgGg6gek2J9bv0IVoVJaZ0P2SH2CsocXLmE5YJjGKzkEydhdAxC0nHLCQdCxhZ VjGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIERs/BLb+tdjAefO54iFGAg1GJh9fAfFeYEGti WXFl7iFGCQ5mJRFegR9AId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxrnNeHCQmkJ5akZqemFqQW wWSZODilGhgjEo9aqJ5f6Xbx1bv/n/kF9ojMOuj35OG3L/sKi7Mm7wr7E6iRmrw99suCsvPR MRumiLj80U1rsGssOHnVctMfz7xDvcEZH6tm/32q571O132nwOzT7VU7ne4abD/mv/LwLwEL 4wXhn6wFkso/L1f4k1Q+T/D7/kV+yw2OPFyYI9ti9do+LbZRiaU4I9FQi7moOBEA/1G+JZoC AAA= Archived-At: Cc: "'Tuomas.aura@aalto.fi'" Subject: [core] FW: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 09:49:08 -0000 RGVhciBhbGwNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgSUVURiBEcmFmdCB0aXRsZWQg4oCc TmltYmxlIG91dC1vZi1iYW5kIGF1dGhlbnRpY2F0aW9uIGZvciBFQVAgKEVBUC1OT09CKeKAnSB0 byB0aGUgc2FhZyBtYWlsaW5nIGxpc3QuIFdlIHRob3VnaHQgaXQgbWlnaHQgYmUgaW50ZXJlc3Rp bmcgdG8gc29tZSBmb2xrcyBoZXJlIGFzIHdlbGwgc2luY2UgdGhlIGRyYWZ0IGRlYWxzIHdpdGgg c2VjdXJlIGJvb3RzdHJhcHBpbmcgb2YgSW9UIGFwcGxpYW5jZXMuICANCg0KVGhlIGRyYWZ0IGRl ZmluZXMgYW4gRUFQIG1ldGhvZCB3aGVyZSB0aGUgYXV0aGVudGljYXRpb24gaXMgYmFzZWQgb24g YSB1c2VyLWFzc2lzdGVkIG91dC1vZi1iYW5kIChPT0IpIGNoYW5uZWwgYmV0d2VlbiB0aGUgc2Vy dmVyIGFuZCBwZWVyLiBJdCBpcyBpbnRlbmRlZCBhcyBhIGdlbmVyaWMgYm9vdHN0cmFwcGluZyBz b2x1dGlvbiBmb3IgSW50ZXJuZXQtb2YtVGhpbmdzIGRldmljZXMgd2hpY2ggaGF2ZSBubyBwcmUt Y29uZmlndXJlZCBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscyBhbmQgd2hpY2ggYXJlIG5vdCB5 ZXQgcmVnaXN0ZXJlZCBvbiB0aGUgYXV0aGVudGljYXRpb24gc2VydmVyLiBDb25zaWRlciBkZXZp Y2VzIHlvdSBqdXN0IGJvdWdodCBvciBib3Jyb3dlZC4NCg0KVGhlIEVBUC1OT09CIG1ldGhvZCBp cyBtb3JlIGdlbmVyaWMgdGhhbiBtb3N0IGFkLWhvYyBib290c3RyYXBwaW5nIHNvbHV0aW9ucyBp biB0aGF0IGl0IHN1cHBvcnRzIG1hbnkgdHlwZXMgb2YgT09CIGNoYW5uZWxzLiBXZSBzcGVjaWZ5 IHRoZSBleGFjdCBpbi1iYW5kIG1lc3NhZ2VzIGJ1dCBvbmx5IHRoZSBPT0IgbWVzc2FnZSBjb250 ZW50cyBhbmQgbm90IHRoZSBPT0IgY2hhbm5lbCBkZXRhaWxzLiBBbHNvLCBFQVAtTk9PQiBzdXBw b3J0cyB1Ymljb21wIGRldmljZXMgd2l0aCBvbmx5IG91dHB1dCAoZS5nLiBkaXNwbGF5KSBvciBv bmx5IGlucHV0IChlLmcuIGNhbWVyYSkuIE1vcmVvdmVyLCBpdCBtYWtlcyBjb21iaW5lZCB1c2Ug b2YgYm90aCBzZWNyZWN5IGFuZCBpbnRlZ3JpdHkgb2YgdGhlIE9PQiBjaGFubmVsIGZvciBtb3Jl IHJvYnVzdCBzZWN1cml0eSB0aGFuIHRoZSBhZC1ob2Mgc29sdXRpb25zLiBXZSBoYXZlIHB1dCBh IGxvdCBvZiBlZmZvcnQgaW50byBkZXNpZ25pbmcgYSByb2J1c3Qgc2VjdXJpdHkgcHJvdG9jb2wu DQoNCkZvciBvbmUgYXBwbGljYXRpb24gZXhhbXBsZSwgd2UgaGF2ZSB1c2VkIGFuIGVhcmxpZXIg dmVyc2lvbiBvZiB0aGUgcHJvdG9jb2wgZm9yIGJvb3RzdHJhcHBpbmcgc2VjdXJpdHkgZm9yIHVi aXF1aXRvdXMgZGlzcGxheXM6IHRoZSB1c2VyIGNhbiBjb25maWd1cmUgd2lyZWxlc3MgbmV0d29y ayBhY2Nlc3MsIGxpbmsgdGhlIGRldmljZSB0byBhIGNsb3VkIHNlcnZpY2UsIGFuZCByZWdpc3Rl ciBvd25lcnNoaXAgb2YgdGhlIGRldmljZSBmb3IgYSBzcGVjaWZpYyBjbG91ZCB1c2VyIOKAkyBh bGwgaW4gb25lIHNpbXBsZSBzdGVwIG9mIHNjYW5uaW5nIGEgUVIgY29kZSB3aXRoIGEgc21hcnQg cGhvbmUuIFRoZXJlIHNlZW1lZCB0byBtb3JlIHBvdGVudGlhbCB0byB0aGlzIGlkZWEgdGhhbiBq dXN0IHVzaW5nIGl0IGZvciBvdXIgb3duIHN5c3RlbSwgYW5kIHRodXMgd2UgZGVjaWRlZCB0byB3 cml0ZSBhIGdlbmVyaWMgRUFQIG1ldGhvZCBmb3Igb3V0LW9mLWJhbmQgYXV0aGVudGljYXRpb24u DQoNClRoZSBkcmFmdCBpcyBhdmFpbGFibGUgaGVyZToNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1hdXJhLWVhcC1ub29iLTAwDQoNClBsZWFzZSBzZWUgaWYgeW91IGNhbiBtYWtl IHVzZSBvZiBpdC4gV2UgbG9vayBmb3J3YXJkIHRvIHlvdXIgZmVlZGJhY2sgYW5kIGNvbW1lbnRz IGhlcmUgb3Igb24gdGhlIHNhYWcgbWFpbGluZyBsaXN0Lg0KDQpUaGFua3MNCi8tLU1vaGl0DQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNb2hpdCBTZXRoaSBbbWFpbHRvOm1v aGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tXSANClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMDgsIDIw MTYgNTozNCBQTQ0KVG86IHNhYWdAaWV0Zi5vcmc7IGVtdUBpZXRmLm9yZw0KQ2M6IHR1b21hcy5h dXJhQGFhbHRvLmZpDQpTdWJqZWN0OiBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQNCg0KRGVhciBhbGwNCg0KV2UgaGF2ZSBqdXN0IHN1 Ym1pdHRlZCBhIG5ldyBJRVRGIERyYWZ0IHRpdGxlZCDigJxOaW1ibGUgb3V0LW9mLWJhbmQgYXV0 aGVudGljYXRpb24gZm9yIEVBUCAoRUFQLU5PT0Ip4oCdLg0KDQpUaGUgZHJhZnQgZGVmaW5lcyBh biBFQVAgbWV0aG9kIHdoZXJlIHRoZSBhdXRoZW50aWNhdGlvbiBpcyBiYXNlZCBvbiBhIHVzZXIt YXNzaXN0ZWQgb3V0LW9mLWJhbmQgKE9PQikgY2hhbm5lbCBiZXR3ZWVuIHRoZSBzZXJ2ZXIgYW5k IHBlZXIuIEl0IGlzIGludGVuZGVkIGFzIGEgZ2VuZXJpYyBib290c3RyYXBwaW5nIHNvbHV0aW9u IGZvciBJbnRlcm5ldC1vZi1UaGluZ3MgZGV2aWNlcyB3aGljaCBoYXZlIG5vIHByZS1jb25maWd1 cmVkIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzIGFuZCB3aGljaCBhcmUgbm90IHlldCByZWdp c3RlcmVkIG9uIHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIuIENvbnNpZGVyIGRldmljZXMgeW91 IGp1c3QgYm91Z2h0IG9yIGJvcnJvd2VkLg0KDQpUaGUgRUFQLU5PT0IgbWV0aG9kIGlzIG1vcmUg Z2VuZXJpYyB0aGFuIG1vc3QgYWQtaG9jIGJvb3RzdHJhcHBpbmcgc29sdXRpb25zIGluIHRoYXQg aXQgc3VwcG9ydHMgbWFueSB0eXBlcyBvZiBPT0IgY2hhbm5lbHMuIFdlIHNwZWNpZnkgdGhlIGV4 YWN0IGluLWJhbmQgbWVzc2FnZXMgYnV0IG9ubHkgdGhlIE9PQiBtZXNzYWdlIGNvbnRlbnRzIGFu ZCBub3QgdGhlIE9PQiBjaGFubmVsIGRldGFpbHMuIEFsc28sIEVBUC1OT09CIHN1cHBvcnRzIHVi aWNvbXAgZGV2aWNlcyB3aXRoIG9ubHkgb3V0cHV0IChlLmcuIGRpc3BsYXkpIG9yIG9ubHkgaW5w dXQgKGUuZy4gY2FtZXJhKS4gTW9yZW92ZXIsIGl0IG1ha2VzIGNvbWJpbmVkIHVzZSBvZiBib3Ro IHNlY3JlY3kgYW5kIGludGVncml0eSBvZiB0aGUgT09CIGNoYW5uZWwgZm9yIG1vcmUgcm9idXN0 IHNlY3VyaXR5IHRoYW4gdGhlIGFkLWhvYyBzb2x1dGlvbnMuIFdlIGhhdmUgcHV0IGEgbG90IG9m IGVmZm9ydCBpbnRvIGRlc2lnbmluZyBhIHJvYnVzdCBzZWN1cml0eSBwcm90b2NvbC4NCg0KRm9y IG9uZSBhcHBsaWNhdGlvbiBleGFtcGxlLCB3ZSBoYXZlIHVzZWQgYW4gZWFybGllciB2ZXJzaW9u IG9mIHRoZSBwcm90b2NvbCBmb3IgYm9vdHN0cmFwcGluZyBzZWN1cml0eSBmb3IgdWJpcXVpdG91 cyBkaXNwbGF5czogdGhlIHVzZXIgY2FuIGNvbmZpZ3VyZSB3aXJlbGVzcyBuZXR3b3JrIGFjY2Vz cywgbGluayB0aGUgZGV2aWNlIHRvIGEgY2xvdWQgc2VydmljZSwgYW5kIHJlZ2lzdGVyIG93bmVy c2hpcCBvZiB0aGUgZGV2aWNlIGZvciBhIHNwZWNpZmljIGNsb3VkIHVzZXIg4oCTIGFsbCBpbiBv bmUgc2ltcGxlIHN0ZXAgb2Ygc2Nhbm5pbmcgYSBRUiBjb2RlIHdpdGggYSBzbWFydCBwaG9uZS4g VGhlcmUgc2VlbWVkIHRvIG1vcmUgcG90ZW50aWFsIHRvIHRoaXMgaWRlYSB0aGFuIGp1c3QgdXNp bmcgaXQgZm9yIG91ciBvd24gc3lzdGVtLCBhbmQgdGh1cyB3ZSBkZWNpZGVkIHRvIHdyaXRlIGEg Z2VuZXJpYyBFQVAgbWV0aG9kIGZvciBvdXQtb2YtYmFuZCBhdXRoZW50aWNhdGlvbi4NCg0KVGhl IGRyYWZ0IGlzIGF2YWlsYWJsZSBoZXJlOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWF1cmEtZWFwLW5vb2ItMDANCg0KUGxlYXNlIHNlZSBpZiB5b3UgY2FuIG1ha2UgdXNlIG9m IGl0LiBXZSBsb29rIGZvcndhcmQgdG8geW91ciBmZWVkYmFjayBhbmQgY29tbWVudHMuDQoNClJl Z2FyZHMNCi8tLU1vaGl0DQoNCg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0N ClN1YmplY3Q6IAlOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWF1cmEtZWFwLW5v b2ItMDAudHh0DQpEYXRlOiAJTW9uLCAwOCBGZWIgMjAxNiAwNDozMDozNSAtMDgwMA0KRnJvbTog CWludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KVG86IAlUdW9tYXMgQXVyYSA8dHVvbWFzLmF1cmFA YWFsdG8uZmk+LCBNb2hpdCBTZXRoaSA8bW9oaXRAcGl1aGEubmV0Pg0KDQoNCg0KQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWF1cmEtZWFwLW5vb2ItMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgVHVvbWFzIEF1cmEgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv c2l0b3J5Lg0KDQpOYW1lOgkJCWRyYWZ0LWF1cmEtZWFwLW5vb2INClJldmlzaW9uOgkJMDANClRp dGxlOgkJCU5pbWJsZSBvdXQtb2YtYmFuZCBhdXRoZW50aWNhdGlvbiBmb3IgRUFQIChFQVAtTk9P QikNCkRvY3VtZW50IGRhdGU6CTIwMTYtMDItMDgNCkdyb3VwOgkJCUluZGl2aWR1YWwgU3VibWlz c2lvbg0KUGFnZXM6CQkJMzUNClVSTDoJCQlodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQNClN0YXR1czoJCQlodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hdXJhLWVhcC1ub29iLw0KSHRtbGl6ZWQ6CQlodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYXVyYS1lYXAtbm9vYi0wMA0KDQoNCkFic3Ry YWN0Og0KICAgIEV4dGVuc2libGUgQXV0aGVudGljYXRpb24gUHJvdG9jb2wgKEVBUCkgW1JGQzM3 NDhdIHByb3ZpZGVzIHN1cHBvcnQNCiAgICBmb3IgbXVsdGlwbGUgYXV0aGVudGljYXRpb24gbWV0 aG9kcy4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgRUFQLQ0KICAgIE5PT0IgYXV0aGVudGlj YXRpb24gbWV0aG9kIGZvciBuaW1ibGUgb3V0LW9mLWJhbmQgKE9PQikNCiAgICBhdXRoZW50aWNh dGlvbiBhbmQga2V5IGRlcml2YXRpb24uICBUaGlzIEVBUCBtZXRob2QgaXMgaW50ZW5kZWQgZm9y DQogICAgYm9vdHN0cmFwcGluZyBhbGwga2luZHMgb2YgSW50ZXJuZXQtb2YtVGhpbmdzIChJb1Qp IGRldmljZXMgdGhhdCBoYXZlDQogICAgYSBtaW5pbWFsIHVzZXIgaW50ZXJmYWNlIGFuZCBubyBw cmUtY29uZmlndXJlZCBhdXRoZW50aWNhdGlvbg0KICAgIGNyZWRlbnRpYWxzLiAgVGhlIG1ldGhv ZCBtYWtlcyB1c2Ugb2YgYSB1c2VyLWFzc2lzdGVkIG9uZS1kaXJlY3Rpb25hbA0KICAgIE9PQiBj aGFubmVsIGJldHdlZW4gdGhlIHBlZXIgZGV2aWNlIGFuZCBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIu DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0K From nobody Wed Feb 10 07:09:32 2016 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 1476C1B2BB1 for ; Wed, 10 Feb 2016 07:09:31 -0800 (PST) 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 acDOzGXidYVi for ; Wed, 10 Feb 2016 07:09:29 -0800 (PST) Received: from mail-yk0-x242.google.com (mail-yk0-x242.google.com [IPv6:2607:f8b0:4002:c07::242]) (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 A471E1B2BAE for ; Wed, 10 Feb 2016 07:09:29 -0800 (PST) Received: by mail-yk0-x242.google.com with SMTP id z7so634328yka.1 for ; Wed, 10 Feb 2016 07:09:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lO8uS+s+BYFW4Q+I1UqS5HIX0c5Wdf1q5xraKOns/xg=; b=MnQmeBQ1BEeOO50nx8x3tmSiC02p2nIqqXs4GZryOIyliOWv5lbGHYh+btKC67mqgH 0zmVSqnS0SYCrFul21RPd+ILl7EOIw8yEiIIlaYpzOzF1he0M5jBOzgO58axgAY+dMLH BfO5iaxIphXl9X+5sQOlXJ0ANbhd+vf6uGC5409fr9HKiX/1/yRnzsTrYh/VoYUgmNs6 cUJ8E3N/dnVDVSPVF+OthYG3jEMQU7rr2mRfoAq+J/CtEAxbleE3+N33ovIxDhY3+hnT i5nEitk5swqmnfCaaBs4iWAWteKJFUMeIIfOuZW/y5RJy3A9D3p1Z8Moh3/7zrr46LTm X0kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=lO8uS+s+BYFW4Q+I1UqS5HIX0c5Wdf1q5xraKOns/xg=; b=XIKrLjtSAacDmu8IY8ZtLhlISpDWiC8Dzbei+3VknmiEhNPklUpJ+ppF5wmag7Sdn2 y74NL6uhp70G2EaOuK9hewpccOatqbeF8mt2D5Sybig6LB87+lBjqi40a0lfvGb73dmE IKHZqePe5QWc+qLbwkDQrWI99KHBMbCwPqo4EjQL7cC6fisD7Afudqu30b6SY5cSmZL2 irF0MLGAfYCy0kVhjlsnc/3LItEOkeUEESMHxWIrwxhZqu2pOaujxnXqx8x+R6J6jkY6 /XDDo81ua27Bk15P1k1Y0wnnFMz3Wu5FrPe/Jc3ZLuEjRVskqSht2jmDaXIK0TenJreu wkYA== X-Gm-Message-State: AG10YORabCbFt+5VXKgnxS9mn3dIdzmkkQNC7e9+4Od0Q5n/EbOht/suZGQDCulVkRZok0SmbM1omvGCz2F1mg== MIME-Version: 1.0 X-Received: by 10.37.95.84 with SMTP id t81mr21693655ybb.58.1455116968997; Wed, 10 Feb 2016 07:09:28 -0800 (PST) Received: by 10.37.102.69 with HTTP; Wed, 10 Feb 2016 07:09:28 -0800 (PST) Date: Wed, 10 Feb 2016 16:09:28 +0100 Message-ID: From: Zafi Ramarosandratana To: core@ietf.org Content-Type: multipart/alternative; boundary=001a114275940b3b02052b6bd281 Archived-At: Subject: [core] Use of PATCH in draft-ietf-core-resource-directory-05 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, 10 Feb 2016 15:09:31 -0000 --001a114275940b3b02052b6bd281 Content-Type: text/plain; charset=UTF-8 All, Section 5.6 shows the PATCH method for updating links of an endpoint. It mandates that payload be a merge-patch+json format, which differs from the rest of the document where the CoRE link format (RFC6690) is used. IMHO, it would be much convenient to also allow RFC6690 for the PATCH method. The following examples illustrate the proposed approach: - adding the link ;ct=41;rt="humidity-s";if="sensor" to the collection of links at the location /rd/4521 Req: PATCH /rd/4521 Payload: ;ct=41;rt="humidity-s";if="sensor" - modifying all links at the location /rd/4521 which are identified by href="/sensors/temp" Req: PATCH /rd/4521?href="/sensors/temp" Payload: rt="temperature-c";if="sensor" - removing all links at the location /rd/4521 which are identified by href="/sensors/light" Req: PATCH /rd/4521?href="/sensors/light" Regards, Zafi. --001a114275940b3b02052b6bd281 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,<= br>
Section 5.6 shows the PATCH method for updating links of an endpoint= . It mandates that payload be a merge-patch+json format, which differs from= the rest of the document where the CoRE link format (RFC6690) is used.
=
IMHO, it would be much convenient to also allow RFC6690 for the PATCH m= ethod.

The following examples illustrate the proposed approach:
<= br>- adding the link </sensors/humid>;ct=3D41;rt=3D"humidity-s&q= uot;;if=3D"sensor" to the collection of links at the location /rd= /4521

=C2=A0Req: PATCH /rd/4521
=C2=A0Payload: </sensors/humid= >;ct=3D41;rt=3D"humidity-s";if=3D"sensor"

- m= odifying all links at the location /rd/4521 which are identified by href=3D= "/sensors/temp"

Req: PATCH /rd/4521?href=3D"/sensors/= temp"
Payload: rt=3D"temperature-c";if=3D"sensor&quo= t;

- removing all links at the location /rd/4521 which are identifie= d by href=3D"/sensors/light"

Req: PATCH /rd/4521?href=3D&q= uot;/sensors/light"

Regards,
Zafi.
--001a114275940b3b02052b6bd281-- From nobody Thu Feb 11 09:37:11 2016 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 DB1221B3804 for ; Thu, 11 Feb 2016 09:37:09 -0800 (PST) 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 PZIDHjmtpp-2 for ; Thu, 11 Feb 2016 09:37:08 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (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 60D4F1B37F9 for ; Thu, 11 Feb 2016 09:37:08 -0800 (PST) Received: by mail-pa0-x236.google.com with SMTP id p5so1756218paw.1 for ; Thu, 11 Feb 2016 09:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Mjup0wWs8dWl3EkHZ6MtS7aUmhvnZyvb+ARpNPdBY5U=; b=omJHC7zBRyx3E57yekKThGN5gwcLsR8Ocb15k/HKdh05CnEOKS3rLc2prInCurIbbX rwBxtT5mZgpNMhUlqkjcx5xTjPcMUA1S6dIEwLS3THHQoYeFqQE9evuixhgsp6Y5P1h3 1I63qbpu/rRh+4IfNtZpjCzs8FGXMzdUEx7WD4m68kDMwEVyUESzdvkNP8rPk/9DrHvz rPmFA6WCgem9c8YRG4YQ2k2C1H+S6xWoIsofu7mBXGcyCaP5Y/BigDGhYwl6U8SSdPfR VNDv/W1Ta5X443lf2EIMYL8LOTU+XCb/sgK7KpZZZYwOMOfXGnXKYODouRMxNJLwNwH8 wFhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Mjup0wWs8dWl3EkHZ6MtS7aUmhvnZyvb+ARpNPdBY5U=; b=IKaXJsy4dGoIaG6Pzvg6T8HA/fMWZ4eAVWfetgVe5/yvxy2KuFbfAfatRePV2iWJVS 7iHuTpAHszuqXKp+r1v57UHG/y7eSLFXnA5iDb0q9JSRxH2PrSKIXzGFXW28tTWOOUew A0HpT47/i1vUUhfhtLStUgk0HyZxL1xfCvovG4ESw53dDUNJYp4C+M823MBxfkknAW/W 44yL+DB7LGMG6NmQw5wQErfxGluWCdYIXuYhnRx9kPHuZnr7Rox7g9l0pFjsa2u+0Bam q5v5QxmNCQQGvVScRZR46hS1LMgX44Pqz7nJeqKuOoT1LNphTRJGGJf7vOlNy5NBM0Bu HnTg== X-Gm-Message-State: AG10YOR4Ew/8W/yzkyM8ryujo8vF+8X6aKD5dQLZDgMiCOKLjzknUpdabVPxq7ucm7l/ng== X-Received: by 10.67.22.166 with SMTP id ht6mr68847500pad.9.1455212228048; Thu, 11 Feb 2016 09:37:08 -0800 (PST) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id 87sm7311757pfq.93.2016.02.11.09.37.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Feb 2016 09:37:07 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_A66A7100-5FF1-4018-A691-9262B3F2C08D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <786991F1-1E38-4337-BCB8-C6D6D0E6092C@gmail.com> Date: Thu, 11 Feb 2016 09:37:05 -0800 Message-Id: References: <20160118110500.GA7789@hephaistos.amsuess.com> <1B2E05E6-1FA3-4AC4-95ED-E6045B6F94E0@gmail.com> <20160118165811.GF7454@hephaistos.amsuess.com> <20160126120126.GD7789@hephaistos.amsuess.com> <20160126164036.GE7789@hephaistos.amsuess.com> <786991F1-1E38-4337-BCB8-C6D6D0E6092C@gmail.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "Cullen Jennings \(fluffy\)" , core Subject: Re: [core] SenML and link-format in RDF (was: Re: Designs to resolve streaming issues in SenML) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 17:37:10 -0000 --Apple-Mail=_A66A7100-5FF1-4018-A691-9262B3F2C08D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Picking up the original thread again, I am building a reference = implementation [1] of collections that uses the representation format = below [2]. It turns out that rather than simply extending the existing senml or = link-format content formats, the better approach may be to define a new = content-format to represent the collection that resues the identifiers = from senml and link-format. In this way, I can provide a map format for = the collection that is optimized for collection processing by the tools, = while supplying standard link-format and senml content formats for = hypertext applications. To this end, I would propose to define a new content-format for a = "hypermedia sensor markup language" which enables representation of a = hypermedia construction that includes both senml and link-format = resources. Resources that support application/hsml ( +json, cbor, xml, = exi) should also be able to return representations of application/senml = and application/link-format for use by general hypermedia applications. = The representation of the Hypermedia Collection would be defined this = way in the CoRE Interfaces draft. This will decouple changes in senml from the collection model and = content format but keep the identifier mapping to the common link and = data formats so tools can easily construct correct representations in = multiple formats, indluding senml optimized for efficient processing. Does this sound like a good course of action? Best regards, Michael [1] https://github.com/connectIOT/HypermediaDemo = [2] [ { "bn": "/light/colorHS/currentcolorh/", "e": [ { "n": "", "v": 0 } ], "l": [ { "href": "", "rel": [ "self", "item" ], "rt": [ "property", "currentcolorh" ] } ] } ] --Apple-Mail=_A66A7100-5FF1-4018-A691-9262B3F2C08D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Picking up the original thread again, I  am building a = reference implementation [1]  of collections that uses the = representation format below [2].

It turns out that rather than simply extending the existing = senml or link-format content formats, the better approach may be to = define a new content-format to represent the collection that resues the = identifiers from senml and link-format. In this way, I can provide a map = format for the collection that is optimized for collection processing by = the tools, while supplying standard link-format and senml content = formats for hypertext applications.

To this end, I would propose to define = a new content-format for a "hypermedia sensor markup language" which = enables representation of a hypermedia construction that includes both = senml and link-format resources. Resources that support application/hsml = ( +json, cbor, xml, exi) should also be able to return representations = of application/senml and application/link-format for use by general = hypermedia applications. The representation of the Hypermedia Collection = would be defined this way in the CoRE Interfaces draft.

This will decouple = changes in senml from the collection model and content format but keep = the identifier mapping to the common link and data formats so tools can = easily construct correct representations in multiple formats, indluding = senml optimized for efficient processing.

Does this sound like a = good course of action?

Best regards,

Michael

[1] https://github.com/connectIOT/HypermediaDemo

[2]
[
  {
    "bn": = "/light/colorHS/currentcolorh/",
    "e": = [
      {
      =   "n": "",
        "v": = 0
      }
    = ],
    "l": [
      = {
        "href": "",
        "rel": [
    =       "self",
          = "item"
        ],
        "rt": [
    =       "property",
      =     "currentcolorh"
        = ]
      }
    = ]
  }
]

= --Apple-Mail=_A66A7100-5FF1-4018-A691-9262B3F2C08D-- From nobody Sat Feb 13 18:57:44 2016 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 CF5831B3761 for ; Sat, 13 Feb 2016 18:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.501 X-Spam-Level: ** X-Spam-Status: No, score=2.501 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, J_CHICKENPOX_22=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoIj8wETOLWz for ; Sat, 13 Feb 2016 18:57:39 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E167B1B375F for ; Sat, 13 Feb 2016 18:57:38 -0800 (PST) Received: by mail-pa0-x231.google.com with SMTP id fy10so27539138pac.1 for ; Sat, 13 Feb 2016 18:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=id4hjlj1BfDx4eXgWz2adfzzbY243zLl4ZtaKGBRt6U=; b=WzXH/MR0ThR8/rESh3Q6nR9yFMX/ongPeF9bZMQCu2LFev2GszhcighZWIhcyRqzLG /TMK1OolsNLOfGSAT2LqNidfLXMJFbZ5qscs2blbgRDdOJ77syYg+B2OnHZ8jjpoBTtI GyYyAg0lkS4wDVBjMSDrMh5ATfpjSnAVf5r4+ScgXM2XQSeiCZKcr2TF5Oebvst+Sgvj 7X6v+QLsoEtSl1eP4Udd+EGmkmtADNQh1OZKoce8pPUYyitOTOZDzmMqmfuG6PqYv15J zcB4Hen/62Vqb7Q8qw0hwRbPbxQ4JEtCObH/dIes4T4jdgWUblU1fLOY93JUzn+L2FDl Dm3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=id4hjlj1BfDx4eXgWz2adfzzbY243zLl4ZtaKGBRt6U=; b=elvcPzxAQpt/EG2SAG/iAMVB6AGkCB3EbDdRA+pMcSjZVJdpxexz3izxe4uDzgiaEd 5pZc/DJEHyogQ0VYIEZZhHTjMnCW+CdL1zaNR39OO/ipU6RCl/jETlUMi5ipmOoaoMUB nbKF0c8AA4AL/9jM5Bjr1vlLeFYqJ64fQRg4d2StbIh4bLZdbjuIIFjAyD6X+GRW+7BQ RIne9hp6jAXl/A2mz/a1wmO9PsgY/ErTxwFRPZwlAmGGgGRqvbtN4BSLQofrAxQZcR8T Ehnslnl+Y3O6CShiEI+euu4peVtg1TmMxqpIdGfJUpuNq5UTkYfHGY7DnHTRX0Sgd2id yohw== X-Gm-Message-State: AG10YOTlmOkTZU/JA39DuXV880J9wK2/JycdX0rl3cTbyZLHwh7URLJb59WckDAGE7gOUA== X-Received: by 10.66.157.161 with SMTP id wn1mr13585831pab.146.1455418658024; Sat, 13 Feb 2016 18:57:38 -0800 (PST) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id c9sm28911257pfd.90.2016.02.13.18.57.36 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 13 Feb 2016 18:57:36 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_20D35C57-40F2-4112-A327-3D90200F4BA0" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <56B4043C.5020502@nteczone.com> Date: Sat, 13 Feb 2016 18:57:34 -0800 Message-Id: <513D642A-0D83-48CD-B26C-4F9829A08811@gmail.com> References: <56B2F440.3050506@nteczone.com> <7070C578-7687-45DE-A4CD-50231F2F28AF@gmail.com> <179DFA4D-9EB7-4053-A24A-A42A6C6EBA63@gmail.com> <56B4043C.5020502@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core@ietf.org Subject: Re: [core] Binding attributes in draft-ietf-core-interfaces 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, 14 Feb 2016 02:57:43 -0000 --Apple-Mail=_20D35C57-40F2-4112-A327-3D90200F4BA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Christian, Thanks for the detailed review; my comments are in line. Best regards, Michael > On Feb 4, 2016, at 6:09 PM, Christian Groves = wrote: >=20 > Hello Michael, >=20 > Thanks for the response and the references. I agree I think its worth = clarifying the text about this. Please see my responses below marked = [CNG]. >=20 > I think there's several more issues that are worth clarifying: >=20 > 1. Whether multiple instances of the attributes are allowed. E.g. is = setting st=3D5,st=3D4 allowed? If so what would it mean? Multiple instances don't seem to be meaningful. Only one instance of = each attribute are allowed. I will add an issue for this in the github. I think it may be useful to add more limit values than gt, lt, for = example lt, gt, lt2, gt2 for some cases. >=20 > 2. For pmin it indicates wait time "even if it has changed" and for = pmax it indicates wait time "regardless if it has changed". > My assumption is that pmax is basically being used as a keepalive and = is used to generate a notification with a state synchronisation value = whether a value has changed or not. Is that correct? Its also not clear = whether the value is the current value or the last reported value. e.g. = if have st=3D5 and the last reported value is 25. Should the = notification due to pmax be the current value say 26, or the last = reported step value? Pmax is intended to eventually synchronize the state of the resource, so = it needs to be the current value, or more precisely the most recent = sample. >=20 > For pmin I assume this is used to limit the number of notifications = sent and only comes into play when something "has changed". Pmin is intended to limit the number of messages sent. In the usual = case, it would be set to a value that is compatible with the expected = response time of the system. >=20 > I wonder how this works in an alarm type scenario, where I want to = know immediately when a threshold as been reached, but I don't need a = keepalive very often and I don't want to be bombarded by notifications = once the threshold is reached. e.g. pmin=3Dx ,pmax=3D300, gt=3D90 >=20 > If I receive a notification due to pmax the current text says that the = system must wait X seconds (i.e. /This parameter has lower priority than = the period parameters, thus even if the Greater Than limit has been = crossed, the time since the last notification SHOULD be between pmin and = pmax/) due to pmin=3Dx before triggering the notification. If the = threshold is reached immediately after sending the pmax notification = then it means that for X seconds some undesirable action may be = occurring before I receive notification. I could set X to be a small = value to minimise the delay but this has the effect of generating more = messages. Pmin may not be the best way to specifically deal with a noisy sensor. = The intention of pmin is to limit messages that would arrive at a rate = faster than the rest of the system can process them. In this case, I = would expect the pmin delay to be acceptable in handling the alarm.=20 >=20 > So I wonder if it would be possible to update the text in such a way = that st,gt,lt are notified immediately when a value changes to meet the = criteria but subsequent notifications related to the criteria are = subject to pmin? If pmin is set to a value that is within the expected response time of = the system, it shouldn't matter if there was a notification just before = an interesting state change occurs. This is the expected use of pmin. Are you suggesting a second pmin type attribute for state changes where = the observed value crosses particular limits in a particular direction? = If there is a use case, we could add a critical minimum time, like cmin, = that can be optionally added to induce this behavior. One could set = cmin=3D0 in addition to pmin to enable "immediate" reporting of = particular state changes. Another approach is to add a new optional type of limit for critical = reporting, like clt, cgt attributes that have priority over pmin, I = suppose only when the value crosses in the outward direction. >=20 > 3. For the step value would it be possible to include a seed/start = value? e.g. rather than being notified of initial value + step e.g.st=3D5 = initial value=3D21.34, leading to notification of 26.34, 31.54 but = instead be notified based on seed value e.g. st=3D5, seed=3D20, leading = to a report of 25, 30. I don't know if such a thing was considered = before? If the attributes are being used to control observe, the first GET will = return a value and set the initial conditions for step. In the case of a = push binding, we should probably specify an initial message since the = client will need to be initialiazed anyway. I'll add another issue for = this. >=20 > Regards, Christian >=20 > On 5/02/2016 3:05 AM, Michael Koster wrote: >> The code I pointed to makes an arbitrary distinction placing a sample = value greater than the threshold setting in the band above the = threshold, and a sample value less than or equal to the threshold = setting (lt or gt) within the "band" below the threshold, and a places . = It does this in order to generalize to an arbitrary number of threshold = values. To more precisely implement the implied semantics of "gt" and = "lt" the comparison should be done on 2 threshold values and compared = for s < limits[0] and s > limits[1], where s is the sample value, = limits[0] is "lt" and limits[1] is "gt". >>=20 >> If no one objects, I will create an issue to update the draft text to = clarify that (s > gt) is the upper band and (s < lt) is the lower band, = and provide reference implementation code to that effect. >>=20 >> /* >> Determine which band [0..num_limits] the provided sample is in >> Works with any number of bands 2 to MAX_LIMITS+1 using an array of = limit settings >> */ >> int band(sample s) >> { >> if (s > limits[num_limits-1]){ >> return num_limits; >> } >> else{ >> for ( int limit =3D 0; limit < num_limits; limit++ ){ >> if (s <=3D limits[limit]){ >> return limit; >> } >> } >> } >> return -1; >> } >>=20 >>=20 >>> On Feb 4, 2016, at 5:58 AM, Michael Koster = = >> wrote: >>>=20 >>> Hi Christian, >>>=20 >>> Thanks for the question. I think we may need to clarify this some = more in the text or with a figure. >>>=20 >>> The notification is controlled by a state machine driven by new = sample values. >>>=20 >>> I think the part we need to clarify is: >>> *Whether a notification is generated depends on the state reported = in the moss recent previous notification, as well as the current sample = value, and the notification attribute values. >>>=20 >>> So saynig "the temperature rises to 30" we need to indicate the = sequence of values which were sampled between 20 and 30, and follow the >>> state machine. >>>=20 >>> You gave sample values of 20, 25, 26, and 30. Let's assume that = these values are sampled in sequence. >>>=20 >>> Assume that the initial value of 20 was the last reported value, and = set the state of the state machine. >>>=20 >>> The next sample is 25, which causes a notification (report) to be = generated due to the st=3D5 attribute. The new most recent value is now = 25. >>>=20 >>> The next sample is 26, which generates a notification due to the = gt=3D26 attribute, The new most recent value is now 26. >>>=20 >>> The next sample is 30, which does not generate a notification since = the last reported value was 26 and no new reporting condition is met. > [CNG] Wouldn't 30 be notified because it meets the gt=3D26 attribute = criteria? >=20 > I assumed that gt didn't result in a single notification but = notification of all value changes over 26. I think it has to be clear = whether the attributes are ORed or ANDed together to produce a = notification. >=20 >>>=20 >>> Does this make sense? If so, I will add this to the issue list for = the next draft update. >>>=20 >>> Also, I see that we are not clearly defining what happens when a = sampled value is exactly equal to a threshold value. In the analysis = above, we assume that a threshold value is a reporting condition, but we = will need to clearly specify "greater" vs. "greater or equal" instead of = "crossing" as in the text. > [CNG] I agree this needs to be clarified, I was going to bring this = up. =46rom a user perspective wouldn't it be easier to say "greater than = or equal to"? e.g. I want to set an alarm to trigger at 26. To me it's = more logical to set it at 26 than to think I have to set it at 25.99 to = report when 26 is hit. >=20 >>>=20 >>> Best regards, >>>=20 >>> Michael >>>=20 >>> PS there is some reference implementation code for OMA LWM2M which = follows the definition in the CoRE Interfaces draft: >>>=20 >>> = https://github.com/connectIOT/lwm2m-objects/blob/master/LWM2M_resource.cpp= = >>> = https://github.com/connectIOT/lwm2m-objects/blob/master/LWM2M_resource_att= ributes.cpp = >>>=20 >>>=20 >>>> On Feb 3, 2016, at 10:48 PM, Christian Groves = = >> wrote: >>>>=20 >>>> Hello, >>>>=20 >>>> I'm reading clause 5.1/draft-ietf-core-interfaces on boundto = attributes. It specifies the interaction between pmin/pmax attributes = and the "change step", "Greater than" and "less than" attributes. The = draft doesn't limit which attributes may appear so I take it its = possible to specify all of them in a single binding. Is this correct? >>>>=20 >>>> If it is it leads to the issue of the interaction between the = "change step" and "greater than" and "less than" attributes. I didn't = see this described anywhere? >>>>=20 >>>> E.g. for a temperature reading if st=3D5, lt=3D10, gt=3D26 is set = and the initial ambient temperature was 20 when set. >>>> The temperature rises to 30. >>>> I could assume there's a notification at 25 related to st=3D5 >>>> Then there's a notification at 26 related to gt=3D26 >>>> However is there a notification at 30? >>>>=20 >>>> The text for change step indicates "how much the value of a = resource SHOULD change before sending a new notification (compared to = the value of the last notification)". The last notification in this case = is 26 which would make the change step 31. >>>>=20 >>>> A possible alternate interpretation is that notifications only = occur when the change step is below 10 or over 26. Alternatively a new = change step notification above would seem superfluous if there's always = a notification whenever the temperature changes above 26. >>>>=20 >>>> What was the intention with the attributes? >>>>=20 >>>> Regards, Christian G >>>>=20 >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_20D35C57-40F2-4112-A327-3D90200F4BA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Christian,

Thanks for the detailed review; my comments are in = line.

Best = regards,

Michael

On Feb 4, 2016, at 6:09 PM, = Christian Groves <Christian.Groves@nteczone.com> wrote:

Hello Michael,

Thanks for the response and the references. I = agree I think its worth clarifying the text about this. Please see my = responses below marked [CNG].

I think there's several = more issues that are worth clarifying:

1. Whether multiple instances of the attributes = are allowed. E.g. is setting st=3D5,st=3D4 allowed?  If so what = would it mean?

Multiple instances don't = seem to be meaningful. Only one instance of each attribute are allowed. = I will add an issue for this in the github.

I think it may be useful to add more limit values = than gt, lt, for example lt, gt, lt2, gt2 for some cases.


2. For pmin it indicates wait time "even if it = has changed" and for pmax it indicates wait time "regardless if it has = changed".
My assumption is that pmax = is basically being used as a keepalive and is used to generate a = notification with a state synchronisation value whether a value has = changed or not. Is that correct? Its also not clear whether the value is = the current value or the last reported value. e.g. if have st=3D5 and = the last reported value is 25. Should the notification due to pmax be = the current value say 26, or the last reported step value?

Pmax is intended = to eventually synchronize the state of the resource, so it needs to be = the current value, or more precisely the most recent = sample.
For pmin I assume this is used to limit the = number of notifications sent and only comes into play when something = "has changed".

Pmin is intended = to limit the number of messages sent. In the usual case, it would be set = to a value that is compatible with the expected response time of the = system.

I wonder how this works in = an alarm type scenario, where I want to know immediately when a = threshold as been reached, but I don't need a keepalive very often and I = don't want to be bombarded by notifications once the threshold is = reached. e.g. pmin=3Dx ,pmax=3D300, gt=3D90

If I receive a = notification due to pmax the current text says that the system must wait = X seconds (i.e. /This parameter has lower priority than the period = parameters, thus even if the Greater Than limit has been crossed, the = time since the last notification SHOULD be between pmin and pmax/) due = to pmin=3Dx before triggering the notification. If the threshold is = reached immediately after sending the pmax notification then it means = that for X seconds some undesirable action may be occurring before I = receive notification. I could set X to be a small value to minimise the = delay but this has the effect of generating more messages.

Pmin may not be = the best way to specifically deal with a noisy sensor. The intention of = pmin is to limit messages that would arrive at a rate faster than the = rest of the system can process them. In this case, I would expect the = pmin delay to be acceptable in handling the alarm. 

So I wonder if it would be possible to update = the text in such a way that st,gt,lt are notified immediately when a = value changes to meet the criteria but subsequent notifications related = to the criteria are subject to pmin?

If pmin is set to a value that is within the expected = response time of the system, it shouldn't matter if there was a = notification just before an interesting state change occurs. This is the = expected use of pmin.

Are you = suggesting a second pmin type attribute for state changes where the = observed value crosses particular limits in a particular direction? If = there is a use case, we could add a critical minimum time, like cmin, = that can be optionally added to induce this behavior. One could set = cmin=3D0 in addition to pmin to enable "immediate" reporting of = particular state changes.

Another = approach is to add a new optional type of limit for critical reporting, = like clt, cgt attributes that have priority over pmin, I suppose only = when the value crosses in the outward direction.

3. For the step = value would it be possible to include a seed/start value? e.g. rather = than being notified of initial value + step e.g.st=3D5 initial = value=3D21.34, leading to notification of 26.34, 31.54 but instead be = notified based on seed value e.g. st=3D5, seed=3D20, leading to a report = of 25, 30. I don't know if such a thing was considered before?

If the = attributes are being used to control observe, the first GET will return = a value and set the initial conditions for step. In the case of a push = binding, we should probably specify an initial message since the client = will need to be initialiazed anyway. I'll add another issue for this.

Regards, Christian

On 5/02/2016 3:05 AM, Michael Koster = wrote:
The code I pointed to makes an arbitrary distinction = placing a sample value greater than the threshold setting in the band = above the threshold, and a sample value less than or equal to the = threshold setting (lt or gt) within the "band" below the threshold, and = a places . It does this in order to generalize to an arbitrary number of = threshold values. To more precisely implement the implied semantics of = "gt" and "lt" the comparison should be done on 2 threshold values and = compared for s < limits[0] and s > limits[1], where s is the = sample value, limits[0] is "lt" and limits[1] is "gt".

If no one objects, I will create an issue to update the draft = text to clarify that (s > gt) is the upper band and (s < lt) is = the lower band, and provide reference implementation code to that = effect.

/*
Determine which = band [0..num_limits] the provided sample is in
Works with = any number of bands 2 to MAX_LIMITS+1 using an array of limit = settings
*/
int band(sample s)
{
if (s > limits[num_limits-1]){
return num_limits;
   }
else{
for ( int limit =3D 0; limit < = num_limits; limit++ ){
if (s <=3D limits[limit]){
return limit;
          &nb= sp;}
       }
   }
return -1;
}

On Feb 4, 2016, at 5:58 AM, Michael Koster <michaeljohnkoster@gmail.com <mailto:michaeljohnkoster@gmail.com>> wrote:

Hi Christian,

Thanks for the question. I think we may need to clarify this = some more in the text or with a figure.

The = notification is controlled by a state machine driven by new sample = values.

I think the part we need to clarify = is:
*Whether a notification is generated depends on the = state reported in the moss recent previous notification, as well as the = current sample value, and the notification attribute values.

So saynig "the temperature rises to 30" we = need to indicate the sequence of values which were sampled between 20 = and 30, and follow the
state machine.

You gave sample values of 20, 25, 26, and 30. Let's assume = that these values are sampled in sequence.

Assume that the initial value of 20 was the last reported = value, and set the state of the state machine.

The next sample is 25, which causes a notification (report) = to be generated due to the st=3D5 attribute. The new most recent value = is now 25.

The next sample is 26, which = generates a notification due to the gt=3D26 attribute, The new most = recent value is now 26.

The next sample is = 30, which does not generate a notification since the last reported value = was 26 and no new reporting condition is met.
[CNG] Wouldn't 30 be notified because it meets = the gt=3D26 attribute criteria?

   I assumed that gt didn't = result in a single notification but notification of all value changes = over 26. I think it has to be clear whether the attributes are ORed or = ANDed together to produce a notification.


Does this make sense? If so, I will add this = to the issue list for the next draft update.

Also, I see that we are not clearly defining what happens = when a sampled value is exactly equal to a threshold value. In the = analysis above, we assume that a threshold value is a reporting = condition, but we will need to clearly specify "greater" vs. "greater or = equal" instead of "crossing" as in the text.
[CNG] I agree this needs to be clarified, I was = going to bring this up. =46rom a user perspective wouldn't it be easier = to say "greater than or equal to"? e.g. I want to set an alarm to = trigger at 26. To me it's more logical to set it at 26 than to think I = have to set it at 25.99 to report when 26 is hit.


Best regards,

Michael

PS there is some = reference implementation code for OMA LWM2M which follows the definition = in the CoRE Interfaces draft:

https://github.com/connectIOT/lwm2m-objects/blob/master/LWM2M_r= esource.cpp
https://github.com/connectIOT/lwm2m-objects/blob/master/LWM2M_r= esource_attributes.cpp


On Feb 3, 2016, at 10:48 = PM, Christian Groves <Christian.Groves@nteczone.com <mailto:Christian.Groves@nteczone.com>> wrote:

Hello,

I'm = reading clause 5.1/draft-ietf-core-interfaces on boundto attributes. It = specifies the interaction between pmin/pmax attributes and the "change = step", "Greater than" and "less than" attributes. The draft doesn't = limit which attributes may appear so I take it its possible to specify = all of them in a single binding. Is this correct?

If it is it leads to the issue of the interaction between the = "change step" and "greater than" and "less than" attributes. I didn't = see this described anywhere?

E.g. for a = temperature reading if st=3D5, lt=3D10, gt=3D26 is set and the initial = ambient temperature was 20 when set.
The temperature rises = to 30.
I could assume there's a notification at 25 related = to st=3D5
Then there's a notification at 26 related to = gt=3D26
However is there a notification at 30?

The text for change step indicates "how much = the value of a resource SHOULD change before sending a new notification = (compared to the value of the last notification)". The last notification = in this case is 26 which would make the change step 31.

A possible alternate interpretation is that notifications = only occur when the change step is below 10 or over 26. Alternatively a = new change step notification above would seem superfluous if there's = always a notification whenever the temperature changes above 26.

What was the intention with the attributes?

Regards, Christian G

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

= --Apple-Mail=_20D35C57-40F2-4112-A327-3D90200F4BA0-- From nobody Sat Feb 13 19:19:51 2016 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 28B2B1B3793 for ; Sat, 13 Feb 2016 19:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 jiiSWGkfSfRr for ; Sat, 13 Feb 2016 19:19:48 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3F11B3792 for ; Sat, 13 Feb 2016 19:19:48 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id q63so68369906pfb.0 for ; Sat, 13 Feb 2016 19:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=l2Q5LrR+/eEPc+5i1gJtBRbStyrR+bqQxQiAnKM3K98=; b=gTGtiiMDCo+IO2mwqT/MkP7tkQLrDzrXYd4JXe11re5zdPo9ct7DZpL7A2HWQAD3Ho ObnM49P1lPfsjIbmAwLQD5O4Eg+ByfAYB2wOBTuVJTyXUhtoSujv5YKipKPbZDfHKBt/ xK8lxeheM1v9JZznsDGLBtY1KIIzvmtdQmosVkuehUkupj0scug3zuSZlqe4BfyWn82q k0lFSf0bxCJVVzGkyas94K+iK13Gwd4117jUF5/sv/GAXktTw3PUI3IcTa0ej90uu/5o BQyMgcMURNISHiyh1RP/c4blzam4i6k7xZBcZl73wUbcNCv4XJJ8e9TV87C925tl3KMA x6bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=l2Q5LrR+/eEPc+5i1gJtBRbStyrR+bqQxQiAnKM3K98=; b=XGrL0vTpH75bAsnmFE2RPKvsilunKREeqHi6nFvJktWGXhhPqQ73eaSQhJI/FI6zso 5zzt7VfOdCDQux1t/Z6+zzrGJBngaBuAoR0PCGPYSiYVaAW3T4VRsEio6jQ8f8abTiq+ I5EflFX4IwqOxZRNDyI8WbUVWFq+kYGkrY12GqbvILfaHFTy3/af3rkatFkr+igmfPpS R2jRVPMZu1LuYDzXwv5h2QFs8HKDTAbKEvR9u2iLTOqIpMdCLuAe0JK3nmNpy173A+dM 3g0VXqynLffNheC2R5ytO5vdYvyPKC4pFSXVpOoZIpFqXsgwCRqe43zOfBNBWjKf3qqu 2VYg== X-Gm-Message-State: AG10YOTBcVsJbX1Xx7S/+0seIHZVD4Hw+mpHka297uld/UB9y77DugfP2woonOpfykjdMA== X-Received: by 10.98.68.73 with SMTP id r70mr13951133pfa.136.1455419988109; Sat, 13 Feb 2016 19:19:48 -0800 (PST) Received: from [10.0.0.21] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id i23sm28994749pfj.68.2016.02.13.19.19.47 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 13 Feb 2016 19:19:47 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E911D488-B705-49CE-A67A-EAD011AF4F61" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <513D642A-0D83-48CD-B26C-4F9829A08811@gmail.com> Date: Sat, 13 Feb 2016 19:19:46 -0800 Message-Id: <6C921742-9C21-4100-8548-7CB45845CF65@gmail.com> References: <56B2F440.3050506@nteczone.com> <7070C578-7687-45DE-A4CD-50231F2F28AF@gmail.com> <179DFA4D-9EB7-4053-A24A-A42A6C6EBA63@gmail.com> <56B4043C.5020502@nteczone.com> <513D642A-0D83-48CD-B26C-4F9829A08811@gmail.com> To: Christian Groves X-Mailer: Apple Mail (2.2104) Archived-At: Cc: core@ietf.org Subject: Re: [core] Binding attributes in draft-ietf-core-interfaces 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, 14 Feb 2016 03:19:50 -0000 --Apple-Mail=_E911D488-B705-49CE-A67A-EAD011AF4F61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The intention is to produce one notification when a limit value, gt or = lt, is crossed, not to continuously send notifications (at the sample = rate? at pmin? ) when a value is in a particular state. Pmax is = intended to send repeat notifications for eventual consistency. Maybe = there should also be a cmax to set a notification repeat intereval when = the state is in a "critical" band. Also your text below is "all value changes" ; what do you mean by all = changes? do you mean all samples, or do you mean an additional change in = value after a limit has been crossed?=20 Perhaps it would be good if you would explain your use case in more = detail with some concrete examples of when values change and when you do = and do not expect notifications. If we want to add special alarm = functionality, I think we may want to define some special attributes for = that case, like amin, amax, agt, alt. Best regards, Michael > On Feb 13, 2016, at 6:57 PM, Michael Koster = wrote: >=20 >>>> The next sample is 26, which generates a notification due to the = gt=3D26 attribute, The new most recent value is now 26. >>>>=20 >>>> The next sample is 30, which does not generate a notification since = the last reported value was 26 and no new reporting condition is met. >> [CNG] Wouldn't 30 be notified because it meets the gt=3D26 attribute = criteria? >>=20 >> I assumed that gt didn't result in a single notification but = notification of all value changes over 26. I think it has to be clear = whether the attributes are ORed or ANDed together to produce a = notification. >>=20 >=20 --Apple-Mail=_E911D488-B705-49CE-A67A-EAD011AF4F61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The intention is to produce one notification when a limit = value, gt or lt, is crossed, not to continuously send notifications (at = the sample rate? at pmin? ) when a value is in a particular state. =  Pmax is intended to send repeat notifications for eventual = consistency. Maybe there should also be a cmax to set a notification = repeat intereval when the state is in a "critical" band.

Also your text below is = "all value changes" ; what do you mean by all changes? do you mean all = samples, or do you mean an additional change in value after a limit has = been crossed? 

Perhaps it would be good if you would explain your use case = in more detail with some concrete examples of when values change and = when you do and do not expect notifications. If we want to add special = alarm functionality, I think we may want to define some special = attributes for that case, like amin, amax, agt, alt.

Best regards,

Michael

On Feb 13, 2016, at 6:57 PM, Michael Koster = <michaeljohnkoster@gmail.com> wrote:

The = next sample is 26, which generates a notification due to the gt=3D26 = attribute, The new most recent value is now 26.

The next sample is 30, which does not generate a notification = since the last reported value was 26 and no new reporting condition is = met.
[CNG] Wouldn't 30 be notified because it meets the gt=3D26 = attribute criteria?

   I assumed that gt didn't result in a = single notification but notification of all value changes over 26. I = think it has to be clear whether the attributes are ORed or ANDed = together to produce a notification.



= --Apple-Mail=_E911D488-B705-49CE-A67A-EAD011AF4F61-- From nobody Sun Feb 14 20:14:43 2016 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 869041B2D7F for ; Sun, 14 Feb 2016 20:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.71 X-Spam-Level: ** X-Spam-Status: No, score=2.71 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, J_CHICKENPOX_25=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_45=0.6, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ufbVsrn9i4l for ; Sun, 14 Feb 2016 20:14:39 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 147FD1B2D7A for ; Sun, 14 Feb 2016 20:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=1lacf+lRY00u2ZKJCE3N+2mzvgaYF7aFLQgsTzJLRGM=; b=FVIkFolu/dC+6D5Qbb5r6tql63 5mYO4N1EvQRnA67VznSGFQnn4bk7/HgKvSiVb0z1Ks2MEHboFuegmnM+OGsevKO5B+TX6mmkB4wue VQnUagyLbtCGYXIsiW4CI7XflBgVY4L27UtK4ImqwyAm7RuUWfOjdyiYLF7a4jdKbwLRzSLWhO8BT MHxTMQxMPtTu+XjBM+55SWaiCtmcEwr3/9S1sePvmoXgvb5KKVe6rcp+tq42oA6hLIiwtaB8Oux/B k0AUUFV2sKBhlZZCPrP/2rN4tLWkcKMLp5JkLO8twETVgOfHK7jvPSe09PtHI6CifL+AfNIAR/ff0 SEJ7Wdtw==; Received: from ppp118-209-196-167.lns20.mel8.internode.on.net ([118.209.196.167]:51930 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aVAYV-001IUm-EX; Mon, 15 Feb 2016 15:14:35 +1100 To: Michael Koster References: <56B2F440.3050506@nteczone.com> <7070C578-7687-45DE-A4CD-50231F2F28AF@gmail.com> <179DFA4D-9EB7-4053-A24A-A42A6C6EBA63@gmail.com> <56B4043C.5020502@nteczone.com> <513D642A-0D83-48CD-B26C-4F9829A08811@gmail.com> <6C921742-9C21-4100-8548-7CB45845CF65@gmail.com> From: Christian Groves Message-ID: <56C150AA.50304@nteczone.com> Date: Mon, 15 Feb 2016 15:14:34 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <6C921742-9C21-4100-8548-7CB45845CF65@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: core@ietf.org Subject: Re: [core] Binding attributes in draft-ietf-core-interfaces 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, 15 Feb 2016 04:14:41 -0000 Hello Michael, As part of a use case I've proposed an updates to the binding attributes which I think will handle both simple and complex cases with the same synyax. Regards, Christian On 14/02/2016 2:19 PM, Michael Koster wrote: > The intention is to produce one notification when a limit value, gt or > lt, is crossed, not to continuously send notifications (at the sample > rate? at pmin? ) when a value is in a particular state. [CNG] OK this wasn't clear. I was taking crossed to to mean notifications occurred once the value was crossed. So cs leads to multiple notifications but gt and lt only result in one notification? > Pmax is intended to send repeat notifications for eventual > consistency. Maybe there should also be a cmax to set a notification > repeat intereval when the state is in a "critical" band. [CNG] This could be useful. > > Also your text below is "all value changes" ; what do you mean by all > changes? do you mean all samples, or do you mean an additional change > in value after a limit has been crossed? [CNG] I meant all samples that met the attribute/s criteria. e.g. pmin=x, pmax=y, gt=26 I would get a notification when 26 is crossed. Then if the sample was 26 at pmax the next notification would be 26. If the sample changed to 27 at the expiry of pmin the notification would include 27 and so on. The addition of cs=5 would modify the behaviour. > > Perhaps it would be good if you would explain your use case in more > detail with some concrete examples of when values change and when you > do and do not expect notifications. If we want to add special alarm > functionality, I think we may want to define some special attributes > for that case, like amin, amax, agt, alt. [CNG] I don't think special "alarm" functionality is needed. I think it just needs to be possible for a user to set the bindings and know what notifications will be expected. Probably the simplest approach is to have a single attribute that indicates when a value is met or crossed (in either direction). This would allow the user to be explicit when it wants a notification. The downside is that multiple bindings would be needed, leading possibly to a large table. An alternate approach could be to separate the value range specification from the notification rate specification. A strawman: A binding would consist of a band, notification and timing attributes: Band - Sets a value region that triggers a notification. When a sample is equal to or within this region notification is governed by the NotificationRate parameter. Band consists of two parameters: start and end (which are included in the notification range). Either start or end could be omitted essentially meaning through to the end or start of the number range, e.g. (,20) would mean 0 through to 20. (20,) would mean 20 and over. If both start and end are omitted then the notifications are unbounded and the initial sample value is taken as the start value. NotificationRate - Would consist of one of the following: once - This would indicate that a notification is set only once on entering the band. cs:value - This would indicate that a notification is set on entering the band and then when the sample changes value according to band:start + (N * cs:value). If value is omitted then the samples are notified whenever sampling indicates a change (subject to pmin timing). Timing - Two parameters: Pmin: Minimum time between notifications. A notification is generated only if the sample value has changed and meets a particular binding criteria (band/notificationRate). Pmax: Maximum time between notifications. A notification is generated irrespective whether the sample value has changed or not. If multiple bindings relate to the same value band then the pmin and pmax values used for notifications related to those values should be the smallest values. Band, NotificationRate, Pmin and Pmax are at most once per binding. Use case -------- Monitoring temperature in some plant process. Temp degC. The following 3 bindings are made between two resources: a) Notify once when process reaches 20c: band(20,),notificationRate(once), pmin=60, pmax=300 b) Notify every 1c change in the range 40c to 49c: band(40,49),notificationRate(cs:1), pmin=60, pmax=240 c) Notify immediately when meeting or exceeding 50c according to sample rate: band (50,),notificationRate(cs),pmin=1, pmax=180. A notification is received once the process meets/exceeds 20c. Whilst the temperature exceeds 20c notifications are sent according to pmin=60 and pmax=x. The temperature stays between 20 and 39 for some time with notifications being generated by pmax=x. The temperature then jumps to 41 and a notification is generated. The notification is delayed for 30s because of the pmin=60 threshold. The temperature continues to rise and after another pmin its 45c so a notification is generated. The temperature then stablises at 45. A notification of 45c is then generated at pmax=240. 10 seconds later the temperature jumps to 60. A notification is immediately generated as pmin for that band is pmin=1. Then temperature again jumps to 70 and a notification is immediately generated subject to pmin=1. The simplest use case would be: band(,),notificationRate(once), pmin=x, pmax=y Which indicates a notification with the current sample ise generated on setting the binding and then a notification will be generated according to pmax. Thoughts? > > Best regards, > > Michael > >> On Feb 13, 2016, at 6:57 PM, Michael Koster >> > wrote: >> >>>>> The next sample is 26, which generates a notification due to the >>>>> gt=26 attribute, The new most recent value is now 26. >>>>> >>>>> The next sample is 30, which does not generate a notification >>>>> since the last reported value was 26 and no new reporting >>>>> condition is met. >>> [CNG] Wouldn't 30 be notified because it meets the gt=26 attribute >>> criteria? >>> >>> I assumed that gt didn't result in a single notification but >>> notification of all value changes over 26. I think it has to be >>> clear whether the attributes are ORed or ANDed together to produce a >>> notification. >>> >> > From nobody Sun Feb 14 23:31:03 2016 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 B0F111A6F8F; Sun, 14 Feb 2016 23:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, 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 mzxwPR9xvMDc; Sun, 14 Feb 2016 23:30:58 -0800 (PST) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id EAEC81A6F93; Sun, 14 Feb 2016 23:30:55 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DPAQBPfMFW/wQXEqxVCYQMbboZAQ2BZxcBCYVsAhyBQxQBAQEBAQEBgQqEQQEBAQQBAQEgSwkCEAsHBgQDAQIoAwICAiUfCQgGCwgbiA2saQEBAWWOMAEBAQEBAQEBAgEBAQEBAQEBGIRoZ4R3hAkRLgoNghs4E4EnBY0nc4hfgTuEFIliSoN5iFWOPh4BAYQtYgGIdwEBAQ X-IPAS-Result: A2DPAQBPfMFW/wQXEqxVCYQMbboZAQ2BZxcBCYVsAhyBQxQBAQEBAQEBgQqEQQEBAQQBAQEgSwkCEAsHBgQDAQIoAwICAiUfCQgGCwgbiA2saQEBAWWOMAEBAQEBAQEBAgEBAQEBAQEBGIRoZ4R3hAkRLgoNghs4E4EnBY0nc4hfgTuEFIliSoN5iFWOPh4BAYQtYgGIdwEBAQ X-IronPort-AV: E=Sophos;i="5.22,449,1449513000"; d="scan'208";a="52626986" In-Reply-To: <56B8B561.8040300@ericsson.com> References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> <56B8B561.8040300@ericsson.com> To: Mohit Sethi MIME-Version: 1.0 X-KeepSent: 7E755D92:2E628249-65257F5A:00275705; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Mon, 15 Feb 2016 13:00:47 +0530 X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4HF528 | October 8, 2015) at 02/15/2016 13:00:48, Serialize complete at 02/15/2016 13:00:48 Content-Type: multipart/alternative; boundary="=_alternative 002945D865257F5A_=" Archived-At: Cc: "'core@ietf.org'" , "'t2trg@irtf.org'" , saag@ietf.org, tuomas.aura@aalto.fi, emu@ietf.org Subject: Re: [core] [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 07:31:00 -0000 This is a multipart message in MIME format. --=_alternative 002945D865257F5A_= MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTW9oaXQsDQpJIHdhcyBnb2luZyB0aHJvdWdoIHlvdXIgZHJhZnQuIExvb2tzIHRvIGJlIGEg cHJvbWlzaW5nIHByb3Bvc2l0aW9uLiANCkhvd2V2ZXIsIEkgaGF2ZSBnb3QgYSBmZXcgcXVlc3Rp b25zIGZpcnN0IGhhbmQuDQoNClRoZSBhdXRoZW50aWNhdG9yIGFjdHMgYXMgYSB0cmFuc3BhcmVu dCBub2RlIGFuZCBmb3J3YXJkcyB0aGUgcGFja2V0cyB0byANCnRoZSBzZXJ2ZXIgc29vbiBhZnRl ciB0aGUgZmlyc3QgbWVzc2FnZSBmb3IgRUFQIElkZW50aXR5IHJlcXVlc3QuIEluIGEgDQp0eXBp Y2FsIG5ldHdvcmsgd291bGQgYSBzaW5nbGUgYXV0aGVudGljYXRvciBtYXAgdG8gc2V2ZXJhbCBz ZXJ2ZXJzIG9yIHRoZSANCmFzc3VtcHRpb24gaXMgdGhhdCB0aGVyZSBpcyBhbHdheXMgb25lIHRv IG9uZSBtYXBwaW5nIGJldHdlZW4gc2VydmVyIGFuZCANCmF1dGhlbnRpY2F0b3I/IA0KDQpIb3cg ZG9lcyB0aGUgYXV0aGVudGljYXRvciBhc3NvY2lhdGUgaXRzZWxmIHRvIHRoZSBzZXJ2ZXIgYXQg dGhlIGZpcnN0IA0KcGxhY2U/DQoNCldoYXQgaXMgdGhlIGFzc3VtcHRpb24gcmVnYXJkaW5nIHRo ZSAgdW5kZXJseWluZyBwaHlzaWNhbCBuZXR3b3JrIGFuZCBob3cgDQp0aGUgYXV0aGVudGljYXRv ciBtYXBzIHRvIHRoZSBkaWZmZXJlbnQgbm9kZXMgaW4gdGhlIG5ldHdvcmsgKGUuZy4gYSANCnJv dXRlciBpbiBhIFdpRmkgbGlrZSBzZXR1cCk/DQoNClJlZ2FyZHMNCkFiaGlqYW4gQmhhdHRhY2hh cnl5YQ0KQXNzb2NpYXRlIENvbnN1bHRhbnQNClNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtv bGthdGEsIEluZGlhDQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzDQpNYWlsdG86IGFiaGlqYW4u YmhhdHRhY2hhcnl5YUB0Y3MuY29tDQpXZWJzaXRlOiBodHRwOi8vd3d3LnRjcy5jb20NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFeHBlcmllbmNlIGNlcnRh aW50eS4gICBJVCBTZXJ2aWNlcw0KICAgICAgICAgICAgICAgICAgICAgICAgQnVzaW5lc3MgU29s dXRpb25zDQogICAgICAgICAgICAgICAgICAgICAgICBDb25zdWx0aW5nDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KDQpGcm9tOiAgIE1vaGl0IFNl dGhpIDxtb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbT4NClRvOiAgICAgPHNhYWdAaWV0Zi5vcmc+ LCA8ZW11QGlldGYub3JnPg0KQ2M6ICAgICB0dW9tYXMuYXVyYUBhYWx0by5maQ0KRGF0ZTogICAw Mi8wOC8yMDE2IDA5OjEwIFBNDQpTdWJqZWN0OiAgICAgICAgW3NhYWddIEZ3ZDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciANCmRyYWZ0LWF1cmEtZWFwLW5vb2ItMDAudHh0DQpTZW50IGJ5 OiAgICAgICAgInNhYWciIDxzYWFnLWJvdW5jZXNAaWV0Zi5vcmc+DQoNCg0KDQpEZWFyIGFsbA0K DQpXZSBoYXZlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IElFVEYgRHJhZnQgdGl0bGVkIOKAnE5pbWJs ZSBvdXQtb2YtYmFuZCANCmF1dGhlbnRpY2F0aW9uIGZvciBFQVAgKEVBUC1OT09CKeKAnS4NCg0K VGhlIGRyYWZ0IGRlZmluZXMgYW4gRUFQIG1ldGhvZCB3aGVyZSB0aGUgYXV0aGVudGljYXRpb24g aXMgYmFzZWQgb24gYSANCnVzZXItYXNzaXN0ZWQgb3V0LW9mLWJhbmQgKE9PQikgY2hhbm5lbCBi ZXR3ZWVuIHRoZSBzZXJ2ZXIgYW5kIHBlZXIuIEl0IA0KaXMgaW50ZW5kZWQgYXMgYSBnZW5lcmlj IGJvb3RzdHJhcHBpbmcgc29sdXRpb24gZm9yIEludGVybmV0LW9mLVRoaW5ncyANCmRldmljZXMg d2hpY2ggaGF2ZSBubyBwcmUtY29uZmlndXJlZCBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscyBh bmQgDQp3aGljaCBhcmUgbm90IHlldCByZWdpc3RlcmVkIG9uIHRoZSBhdXRoZW50aWNhdGlvbiBz ZXJ2ZXIuIENvbnNpZGVyIA0KZGV2aWNlcyB5b3UganVzdCBib3VnaHQgb3IgYm9ycm93ZWQuDQoN ClRoZSBFQVAtTk9PQiBtZXRob2QgaXMgbW9yZSBnZW5lcmljIHRoYW4gbW9zdCBhZC1ob2MgYm9v dHN0cmFwcGluZyANCnNvbHV0aW9ucyBpbiB0aGF0IGl0IHN1cHBvcnRzIG1hbnkgdHlwZXMgb2Yg T09CIGNoYW5uZWxzLiBXZSBzcGVjaWZ5IHRoZSANCmV4YWN0IGluLWJhbmQgbWVzc2FnZXMgYnV0 IG9ubHkgdGhlIE9PQiBtZXNzYWdlIGNvbnRlbnRzIGFuZCBub3QgdGhlIE9PQiANCmNoYW5uZWwg ZGV0YWlscy4gQWxzbywgRUFQLU5PT0Igc3VwcG9ydHMgdWJpY29tcCBkZXZpY2VzIHdpdGggb25s eSANCm91dHB1dCAoZS5nLiBkaXNwbGF5KSBvciBvbmx5IGlucHV0IChlLmcuIGNhbWVyYSkuIE1v cmVvdmVyLCBpdCBtYWtlcyANCmNvbWJpbmVkIHVzZSBvZiBib3RoIHNlY3JlY3kgYW5kIGludGVn cml0eSBvZiB0aGUgT09CIGNoYW5uZWwgZm9yIG1vcmUgDQpyb2J1c3Qgc2VjdXJpdHkgdGhhbiB0 aGUgYWQtaG9jIHNvbHV0aW9ucy4gV2UgaGF2ZSBwdXQgYSBsb3Qgb2YgZWZmb3J0IA0KaW50byBk ZXNpZ25pbmcgYSByb2J1c3Qgc2VjdXJpdHkgcHJvdG9jb2wuDQoNCkZvciBvbmUgYXBwbGljYXRp b24gZXhhbXBsZSwgd2UgaGF2ZSB1c2VkIGFuIGVhcmxpZXIgdmVyc2lvbiBvZiB0aGUgDQpwcm90 b2NvbCBmb3IgYm9vdHN0cmFwcGluZyBzZWN1cml0eSBmb3IgdWJpcXVpdG91cyBkaXNwbGF5czog dGhlIHVzZXIgDQpjYW4gY29uZmlndXJlIHdpcmVsZXNzIG5ldHdvcmsgYWNjZXNzLCBsaW5rIHRo ZSBkZXZpY2UgdG8gYSBjbG91ZCANCnNlcnZpY2UsIGFuZCByZWdpc3RlciBvd25lcnNoaXAgb2Yg dGhlIGRldmljZSBmb3IgYSBzcGVjaWZpYyBjbG91ZCB1c2VyIA0K4oCTIGFsbCBpbiBvbmUgc2lt cGxlIHN0ZXAgb2Ygc2Nhbm5pbmcgYSBRUiBjb2RlIHdpdGggYSBzbWFydCBwaG9uZS4gVGhlcmUg DQpzZWVtZWQgdG8gbW9yZSBwb3RlbnRpYWwgdG8gdGhpcyBpZGVhIHRoYW4ganVzdCB1c2luZyBp dCBmb3Igb3VyIG93biANCnN5c3RlbSwgYW5kIHRodXMgd2UgZGVjaWRlZCB0byB3cml0ZSBhIGdl bmVyaWMgRUFQIG1ldGhvZCBmb3IgDQpvdXQtb2YtYmFuZCBhdXRoZW50aWNhdGlvbi4NCg0KVGhl IGRyYWZ0IGlzIGF2YWlsYWJsZSBoZXJlOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWF1cmEtZWFwLW5vb2ItMDANCg0KUGxlYXNlIHNlZSBpZiB5b3UgY2FuIG1ha2UgdXNlIG9m IGl0LiBXZSBsb29rIGZvcndhcmQgdG8geW91ciBmZWVkYmFjayANCmFuZCBjb21tZW50cy4NCg0K UmVnYXJkcw0KLy0tTW9oaXQNCg0KDQotLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0t LQ0KU3ViamVjdDogICAgICAgICAgICAgICAgIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig DQpkcmFmdC1hdXJhLWVhcC1ub29iLTAwLnR4dA0KRGF0ZTogICAgICAgICAgICBNb24sIDA4IEZl YiAyMDE2IDA0OjMwOjM1IC0wODAwDQpGcm9tOiAgICAgICAgICAgIGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZw0KVG86ICAgICAgICAgICAgICBUdW9tYXMgQXVyYSA8dHVvbWFzLmF1cmFAYWFsdG8u Zmk+LCBNb2hpdCBTZXRoaSANCjxtb2hpdEBwaXVoYS5uZXQ+DQoNCg0KDQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgVHVvbWFzIEF1cmEgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3Np dG9yeS4NCg0KTmFtZTogICAgICAgICAgICAgICAgICAgICAgICAgICAgZHJhZnQtYXVyYS1lYXAt bm9vYg0KUmV2aXNpb246ICAgICAgICAgICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgICAgICAg ICAgICAgICAgICBOaW1ibGUgb3V0LW9mLWJhbmQgYXV0aGVudGljYXRpb24gZm9yIEVBUCANCihF QVAtTk9PQikNCkRvY3VtZW50IGRhdGU6ICAgICAgICAgICAyMDE2LTAyLTA4DQpHcm91cDogICAg ICAgICAgICAgICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAg ICAgICAgICAgICAgICAgICAgICAgIDM1DQpVUkw6aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWF1cmEtZWFwLW5vb2ItMDAudHh0DQpTdGF0dXM6aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYXVyYS1lYXAtbm9vYi8NCkh0bWxpemVkOmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hdXJhLWVhcC1ub29iLTAwDQoNCg0KQWJzdHJh Y3Q6DQogICAgRXh0ZW5zaWJsZSBBdXRoZW50aWNhdGlvbiBQcm90b2NvbCAoRUFQKSBbUkZDMzc0 OF0gcHJvdmlkZXMgc3VwcG9ydA0KICAgIGZvciBtdWx0aXBsZSBhdXRoZW50aWNhdGlvbiBtZXRo b2RzLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBFQVAtDQogICAgTk9PQiBhdXRoZW50aWNh dGlvbiBtZXRob2QgZm9yIG5pbWJsZSBvdXQtb2YtYmFuZCAoT09CKQ0KICAgIGF1dGhlbnRpY2F0 aW9uIGFuZCBrZXkgZGVyaXZhdGlvbi4gIFRoaXMgRUFQIG1ldGhvZCBpcyBpbnRlbmRlZCBmb3IN CiAgICBib290c3RyYXBwaW5nIGFsbCBraW5kcyBvZiBJbnRlcm5ldC1vZi1UaGluZ3MgKElvVCkg ZGV2aWNlcyB0aGF0IGhhdmUNCiAgICBhIG1pbmltYWwgdXNlciBpbnRlcmZhY2UgYW5kIG5vIHBy ZS1jb25maWd1cmVkIGF1dGhlbnRpY2F0aW9uDQogICAgY3JlZGVudGlhbHMuICBUaGUgbWV0aG9k IG1ha2VzIHVzZSBvZiBhIHVzZXItYXNzaXN0ZWQgb25lLWRpcmVjdGlvbmFsDQogICAgT09CIGNo YW5uZWwgYmV0d2VlbiB0aGUgcGVlciBkZXZpY2UgYW5kIGF1dGhlbnRpY2F0aW9uIHNlcnZlci4N Cg0KICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiANCnN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kc2FhZyBtYWlsaW5nIGxpc3QNCnNhYWdAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZw0KDQoNCj09PT09LS0tLS09PT09PS0tLS0t PT09PT0KTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsCm1l c3NhZ2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1heSBjb250YWluIApjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSAKbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0aW9uLCB1c2UsIApyZXZpZXcsIGRpc3RyaWJ1dGlvbiwg cHJpbnRpbmcgb3IgY29weWluZyBvZiB0aGUgCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IGUtbWFpbCBtZXNzYWdlIAphbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHBy b2hpYml0ZWQuIElmIAp5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IsIApwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhvbmUgYW5kIApp bW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdlIAphbmQgYW55IGF0 dGFjaG1lbnRzLiBUaGFuayB5b3UKCgo= --=_alternative 002945D865257F5A_= MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIE1vaGl0LDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSB3YXMgZ29pbmcgdGhyb3VnaCB5b3VyIGRyYWZ0 LiBMb29rcw0KdG8gYmUgYSBwcm9taXNpbmcgcHJvcG9zaXRpb24uIEhvd2V2ZXIsIEkgaGF2ZSBn b3QgYSBmZXcgcXVlc3Rpb25zIGZpcnN0DQpoYW5kLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIGF1dGhlbnRpY2F0b3IgYWN0cyBhcyBhIHRyYW5z cGFyZW50DQpub2RlIGFuZCBmb3J3YXJkcyB0aGUgcGFja2V0cyB0byB0aGUgc2VydmVyIHNvb24g YWZ0ZXIgdGhlIGZpcnN0IG1lc3NhZ2UNCmZvciBFQVAgSWRlbnRpdHkgcmVxdWVzdC4gSW4gYSB0 eXBpY2FsIG5ldHdvcmsgd291bGQgYSBzaW5nbGUgYXV0aGVudGljYXRvcg0KbWFwIHRvIHNldmVy YWwgc2VydmVycyBvciB0aGUgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZXJlIGlzIGFsd2F5cyBvbmUg dG8NCm9uZSBtYXBwaW5nIGJldHdlZW4gc2VydmVyIGFuZCBhdXRoZW50aWNhdG9yPyA8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhvdyBkb2VzIHRoZSBh dXRoZW50aWNhdG9yIGFzc29jaWF0ZQ0KaXRzZWxmIHRvIHRoZSBzZXJ2ZXIgYXQgdGhlIGZpcnN0 IHBsYWNlPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ V2hhdCBpcyB0aGUgYXNzdW1wdGlvbiByZWdhcmRpbmcgdGhlDQombmJzcDt1bmRlcmx5aW5nIHBo eXNpY2FsIG5ldHdvcmsgYW5kIGhvdyB0aGUgYXV0aGVudGljYXRvciBtYXBzIHRvIHRoZQ0KZGlm ZmVyZW50IG5vZGVzIGluIHRoZSBuZXR3b3JrIChlLmcuIGEgcm91dGVyIGluIGEgV2lGaSBsaWtl IHNldHVwKT88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlJlZ2FyZHM8YnI+DQpBYmhpamFuIEJoYXR0YWNoYXJ5eWE8YnI+DQpBc3NvY2lhdGUgQ29uc3Vs dGFudDxicj4NClNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEsIEluZGlhPGJyPg0K VGF0YSBDb25zdWx0YW5jeSBTZXJ2aWNlczxicj4NCk1haWx0bzogYWJoaWphbi5iaGF0dGFjaGFy eXlhQHRjcy5jb208YnI+DQpXZWJzaXRlOiA8L2ZvbnQ+PGEgaHJlZj1odHRwOi8vd3d3LnRjcy5j b20vPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRwOi8vd3d3LnRjcy5jb208L2Zv bnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkV4cGVyaWVuY2UgY2VydGFpbnR5 LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJVCBTZXJ2aWNlczxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtCdXNpbmVzcyBTb2x1dGlvbnM8YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Q29uc3VsdGluZzxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkZyb206ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPk1v aGl0IFNldGhpICZsdDttb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbSZndDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+VG86ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PiZsdDtzYWFnQGlldGYub3JnJmd0OywNCiZsdDtlbXVAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkNjOiAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij50dW9tYXMuYXVyYUBhYWx0by5maTwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVm NWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5EYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4wMi8wOC8yMDE2IDA5OjEwIFBN PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYi PlN1YmplY3Q6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPltzYWFnXSBGd2Q6DQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWF1cmEtZWFwLW5vb2ItMDAudHh0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBj b2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPlNlbnQgYnk6ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O3Nh YWcmcXVvdDsNCiZsdDtzYWFnLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPGJyPg0KPGhy IG5vc2hhZGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5EZWFyIGFsbDxicj4N Cjxicj4NCldlIGhhdmUganVzdCBzdWJtaXR0ZWQgYSBuZXcgSUVURiBEcmFmdCB0aXRsZWQg4oCc TmltYmxlIG91dC1vZi1iYW5kIDxicj4NCmF1dGhlbnRpY2F0aW9uIGZvciBFQVAgKEVBUC1OT09C KeKAnS48YnI+DQo8YnI+DQpUaGUgZHJhZnQgZGVmaW5lcyBhbiBFQVAgbWV0aG9kIHdoZXJlIHRo ZSBhdXRoZW50aWNhdGlvbiBpcyBiYXNlZCBvbiBhDQo8YnI+DQp1c2VyLWFzc2lzdGVkIG91dC1v Zi1iYW5kIChPT0IpIGNoYW5uZWwgYmV0d2VlbiB0aGUgc2VydmVyIGFuZCBwZWVyLiBJdA0KPGJy Pg0KaXMgaW50ZW5kZWQgYXMgYSBnZW5lcmljIGJvb3RzdHJhcHBpbmcgc29sdXRpb24gZm9yIElu dGVybmV0LW9mLVRoaW5ncw0KPGJyPg0KZGV2aWNlcyB3aGljaCBoYXZlIG5vIHByZS1jb25maWd1 cmVkIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzIGFuZCA8YnI+DQp3aGljaCBhcmUgbm90IHll dCByZWdpc3RlcmVkIG9uIHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIuIENvbnNpZGVyIDxicj4N CmRldmljZXMgeW91IGp1c3QgYm91Z2h0IG9yIGJvcnJvd2VkLjxicj4NCjxicj4NClRoZSBFQVAt Tk9PQiBtZXRob2QgaXMgbW9yZSBnZW5lcmljIHRoYW4gbW9zdCBhZC1ob2MgYm9vdHN0cmFwcGlu ZyA8YnI+DQpzb2x1dGlvbnMgaW4gdGhhdCBpdCBzdXBwb3J0cyBtYW55IHR5cGVzIG9mIE9PQiBj aGFubmVscy4gV2Ugc3BlY2lmeSB0aGUNCjxicj4NCmV4YWN0IGluLWJhbmQgbWVzc2FnZXMgYnV0 IG9ubHkgdGhlIE9PQiBtZXNzYWdlIGNvbnRlbnRzIGFuZCBub3QgdGhlIE9PQg0KPGJyPg0KY2hh bm5lbCBkZXRhaWxzLiBBbHNvLCBFQVAtTk9PQiBzdXBwb3J0cyB1Ymljb21wIGRldmljZXMgd2l0 aCBvbmx5IDxicj4NCm91dHB1dCAoZS5nLiBkaXNwbGF5KSBvciBvbmx5IGlucHV0IChlLmcuIGNh bWVyYSkuIE1vcmVvdmVyLCBpdCBtYWtlcyA8YnI+DQpjb21iaW5lZCB1c2Ugb2YgYm90aCBzZWNy ZWN5IGFuZCBpbnRlZ3JpdHkgb2YgdGhlIE9PQiBjaGFubmVsIGZvciBtb3JlDQo8YnI+DQpyb2J1 c3Qgc2VjdXJpdHkgdGhhbiB0aGUgYWQtaG9jIHNvbHV0aW9ucy4gV2UgaGF2ZSBwdXQgYSBsb3Qg b2YgZWZmb3J0DQo8YnI+DQppbnRvIGRlc2lnbmluZyBhIHJvYnVzdCBzZWN1cml0eSBwcm90b2Nv bC48YnI+DQo8YnI+DQpGb3Igb25lIGFwcGxpY2F0aW9uIGV4YW1wbGUsIHdlIGhhdmUgdXNlZCBh biBlYXJsaWVyIHZlcnNpb24gb2YgdGhlIDxicj4NCnByb3RvY29sIGZvciBib290c3RyYXBwaW5n IHNlY3VyaXR5IGZvciB1YmlxdWl0b3VzIGRpc3BsYXlzOiB0aGUgdXNlciA8YnI+DQpjYW4gY29u ZmlndXJlIHdpcmVsZXNzIG5ldHdvcmsgYWNjZXNzLCBsaW5rIHRoZSBkZXZpY2UgdG8gYSBjbG91 ZCA8YnI+DQpzZXJ2aWNlLCBhbmQgcmVnaXN0ZXIgb3duZXJzaGlwIG9mIHRoZSBkZXZpY2UgZm9y IGEgc3BlY2lmaWMgY2xvdWQgdXNlcg0KPGJyPg0K4oCTIGFsbCBpbiBvbmUgc2ltcGxlIHN0ZXAg b2Ygc2Nhbm5pbmcgYSBRUiBjb2RlIHdpdGggYSBzbWFydCBwaG9uZS4gVGhlcmUNCjxicj4NCnNl ZW1lZCB0byBtb3JlIHBvdGVudGlhbCB0byB0aGlzIGlkZWEgdGhhbiBqdXN0IHVzaW5nIGl0IGZv ciBvdXIgb3duIDxicj4NCnN5c3RlbSwgYW5kIHRodXMgd2UgZGVjaWRlZCB0byB3cml0ZSBhIGdl bmVyaWMgRUFQIG1ldGhvZCBmb3IgPGJyPg0Kb3V0LW9mLWJhbmQgYXV0aGVudGljYXRpb24uPGJy Pg0KPGJyPg0KVGhlIGRyYWZ0IGlzIGF2YWlsYWJsZSBoZXJlOjxicj4NCjwvZm9udD48L3R0Pjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hdXJhLWVhcC1ub29iLTAw Ij48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hdXJh LWVhcC1ub29iLTAwPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPGJyPg0K UGxlYXNlIHNlZSBpZiB5b3UgY2FuIG1ha2UgdXNlIG9mIGl0LiBXZSBsb29rIGZvcndhcmQgdG8g eW91ciBmZWVkYmFjaw0KPGJyPg0KYW5kIGNvbW1lbnRzLjxicj4NCjxicj4NClJlZ2FyZHM8YnI+ DQovLS1Nb2hpdDxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0t LS0tLS0tPGJyPg0KU3ViamVjdDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1hdXJhLWVhcC1ub29iLTAwLnR4dDxicj4NCkRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TW9uLA0KMDggRmViIDIw MTYgMDQ6MzA6MzUgLTA4MDA8YnI+DQpGcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2ludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zzxicj4NClRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO1R1b21hcw0KQXVyYSAmbHQ7dHVvbWFzLmF1cmFAYWFsdG8uZmkmZ3Q7 LCBNb2hpdCBTZXRoaSAmbHQ7bW9oaXRAcGl1aGEubmV0Jmd0Ozxicj4NCjxicj4NCjxicj4NCjxi cj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1hdXJhLWVhcC1ub29iLTAwLnR4dDxicj4N CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVHVvbWFzIEF1cmEgYW5kIHBvc3Rl ZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFm dC1hdXJhLWVhcC1ub29iPGJyPg0KUmV2aXNpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjAwPGJyPg0KVGl0bGU6ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TmltYmxl DQpvdXQtb2YtYmFuZCBhdXRoZW50aWNhdGlvbiBmb3IgRUFQIChFQVAtTk9PQik8YnI+DQpEb2N1 bWVudCBkYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAyMDE2LTAyLTA4PGJyPg0KR3JvdXA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5kaXZpZHVhbA0KU3VibWlz c2lvbjxicj4NClBhZ2VzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzM1PGJyPg0KVVJMOjwvZm9udD48L3R0PjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hdXJhLWVhcC1ub29iLTAw LnR4dCI+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQ8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNp emU9Mj48YnI+DQpTdGF0dXM6PC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtYXVyYS1lYXAtbm9vYi8iPjx0dD48Zm9udCBzaXplPTI+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYXVyYS1lYXAtbm9vYi88L2ZvbnQ+ PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpIdG1saXplZDo8L2ZvbnQ+PC90dD48YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYXVyYS1lYXAtbm9vYi0wMCI+ PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYXVyYS1l YXAtbm9vYi0wMDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjxicj4NCjxi cj4NCkFic3RyYWN0Ojxicj4NCiAmbmJzcDsgJm5ic3A7RXh0ZW5zaWJsZSBBdXRoZW50aWNhdGlv biBQcm90b2NvbCAoRUFQKSBbUkZDMzc0OF0gcHJvdmlkZXMNCnN1cHBvcnQ8YnI+DQogJm5ic3A7 ICZuYnNwO2ZvciBtdWx0aXBsZSBhdXRoZW50aWNhdGlvbiBtZXRob2RzLiAmbmJzcDtUaGlzIGRv Y3VtZW50DQpkZWZpbmVzIHRoZSBFQVAtPGJyPg0KICZuYnNwOyAmbmJzcDtOT09CIGF1dGhlbnRp Y2F0aW9uIG1ldGhvZCBmb3IgbmltYmxlIG91dC1vZi1iYW5kIChPT0IpPGJyPg0KICZuYnNwOyAm bmJzcDthdXRoZW50aWNhdGlvbiBhbmQga2V5IGRlcml2YXRpb24uICZuYnNwO1RoaXMgRUFQIG1l dGhvZA0KaXMgaW50ZW5kZWQgZm9yPGJyPg0KICZuYnNwOyAmbmJzcDtib290c3RyYXBwaW5nIGFs bCBraW5kcyBvZiBJbnRlcm5ldC1vZi1UaGluZ3MgKElvVCkgZGV2aWNlcw0KdGhhdCBoYXZlPGJy Pg0KICZuYnNwOyAmbmJzcDthIG1pbmltYWwgdXNlciBpbnRlcmZhY2UgYW5kIG5vIHByZS1jb25m aWd1cmVkIGF1dGhlbnRpY2F0aW9uPGJyPg0KICZuYnNwOyAmbmJzcDtjcmVkZW50aWFscy4gJm5i c3A7VGhlIG1ldGhvZCBtYWtlcyB1c2Ugb2YgYSB1c2VyLWFzc2lzdGVkDQpvbmUtZGlyZWN0aW9u YWw8YnI+DQogJm5ic3A7ICZuYnNwO09PQiBjaGFubmVsIGJldHdlZW4gdGhlIHBlZXIgZGV2aWNl IGFuZCBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIuPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGJyPg0KPGJyPg0K PGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPGJyPg0KPGJyPg0KVGhl IElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNhYWcgbWFpbGluZyBsaXN0PGJy Pg0Kc2FhZ0BpZXRmLm9yZzxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBz aXplPTI+PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8cD49PT09PS0tLS0tPT09PT0tLS0tLT09 PT09PGJyPgpOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWw8 YnI+Cm1lc3NhZ2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1heSBjb250YWluIDxicj4KY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgPGJyPgpub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc3NlbWluYXRpb24sIHVzZSwgPGJyPgpyZXZp ZXcsIGRpc3RyaWJ1dGlvbiwgcHJpbnRpbmcgb3IgY29weWluZyBvZiB0aGUgPGJyPgppbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSA8YnI+CmFuZC9vciBhdHRhY2ht ZW50cyB0byBpdCBhcmUgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgPGJyPgp5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIDxicj4KcGxlYXNlIG5vdGlmeSB1cyBi eSByZXBseSBlLW1haWwgb3IgdGVsZXBob25lIGFuZCA8YnI+CmltbWVkaWF0ZWx5IGFuZCBwZXJt YW5lbnRseSBkZWxldGUgdGhlIG1lc3NhZ2UgPGJyPgphbmQgYW55IGF0dGFjaG1lbnRzLiBUaGFu ayB5b3U8L3A+Cgo8cD48L3A+ --=_alternative 002945D865257F5A_=-- From nobody Wed Feb 17 04:19:29 2016 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 5C03C1B398D for ; Wed, 17 Feb 2016 04:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, 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 zKnjp1xlaEOr for ; Wed, 17 Feb 2016 04:19:25 -0800 (PST) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 420261B3989 for ; Wed, 17 Feb 2016 04:19:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DPAQDiY8RW/wQXEqxehAxth1myQQENgWcXAQuFagKBeBQBAQEBAQEBgQuEQQEBAXsdBwYEAwECKE0HAhkIG4gNqxYBAQGPegEBCAIBHYNPgRpnhH2EHTgNghtLGIEPBY0pc4hngT6EFYliSoN5iFSORx4BAYQtYgGIYAEBAQ X-IPAS-Result: A2DPAQDiY8RW/wQXEqxehAxth1myQQENgWcXAQuFagKBeBQBAQEBAQEBgQuEQQEBAXsdBwYEAwECKE0HAhkIG4gNqxYBAQGPegEBCAIBHYNPgRpnhH2EHTgNghtLGIEPBY0pc4hngT6EFYliSoN5iFSORx4BAYQtYgGIYAEBAQ X-IronPort-AV: E=Sophos;i="5.22,460,1449513000"; d="scan'208";a="53648229" To: core@ietf.org MIME-Version: 1.0 X-KeepSent: 184CED70:AF0624BA-65257F5C:004315DC; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Wed, 17 Feb 2016 17:49:19 +0530 X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4HF528 | October 8, 2015) at 02/17/2016 17:49:20, Serialize complete at 02/17/2016 17:49:20 Content-Type: multipart/alternative; boundary="=_alternative 0043B00465257F5C_=" Archived-At: Subject: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-14.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 12:19:28 -0000 This is a multipart message in MIME format. --=_alternative 0043B00465257F5C_= Content-Type: text/plain; charset="US-ASCII" Dear list, A new version of the No-Response option draft has been submitted. Please note, this draft is now in the RFC editor's queue through independent submission channel. The present version of the draft addresses technical review comments received via the RFC editor's desk. The intended status has been changed to "Informational". Thanks to Esko for the review. 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 ____________________________________________ ----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 02/17/2016 05:42 PM ----- From: internet-drafts@ietf.org To: "Soma Bandyopadhyay" , "Abhijan Bhattacharyya" , "Arpan Pal" , "Tulika Bose" Date: 02/17/2016 05:34 PM Subject: New Version Notification for draft-tcs-coap-no-response-option-14.txt A new version of I-D, draft-tcs-coap-no-response-option-14.txt has been successfully submitted by Abhijan Bhattacharyya and posted to the IETF repository. Name: draft-tcs-coap-no-response-option Revision: 14 Title: CoAP option for no server-response Document date: 2016-02-17 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-14.txt Status: https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/ Htmlized: https://tools.ietf.org/html/draft-tcs-coap-no-response-option-14 Diff: https://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-14 Abstract: There can be M2M scenarios where responses from a server against requests from client are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating a bulk of resources simultaneously, or updating a resource with a very high frequency. CoAP already provides a non-confirmable (NON) mode of message exchange where the server end-point does not respond with ACK. However, obeying the request/response semantics, the server end-point responds back with a status code indicating "the result of the attempt to understand and satisfy the request". This document introduces a header option for CoAP called 'No- Response'. Using this option the client can explicitly tell the server to suppress all responses against the particular request. This option also provides granular control to enable suppression of a particular class of response or a combination of response-classes. This option may be effective for both unicast and multicast requests. This document also discusses a few exemplary applications which benefit from this option. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =====-----=====-----===== 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 0043B00465257F5C_= Content-Type: text/html; charset="US-ASCII" Dear list,
A new version of the No-Response option draft has been submitted. Please note, this draft is now in the RFC editor's queue through independent submission channel. The present version of the draft addresses technical review comments received via the RFC editor's desk. The intended status has been changed to "Informational".
Thanks to Esko for the review.

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
____________________________________________
----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 02/17/2016 05:42 PM -----

From:        internet-drafts@ietf.org
To:        "Soma Bandyopadhyay" <soma.bandyopadhyay@tcs.com>, "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.com>, "Arpan Pal" <arpan.pal@tcs.com>, "Tulika Bose" <tulika.bose@tcs.com>
Date:        02/17/2016 05:34 PM
Subject:        New Version Notification for draft-tcs-coap-no-response-option-14.txt




A new version of I-D, draft-tcs-coap-no-response-option-14.txt
has been successfully submitted by Abhijan Bhattacharyya and posted to the
IETF repository.

Name:                                  draft-tcs-coap-no-response-option
Revision:                 14
Title:                                  CoAP option for no server-response
Document date:                 2016-02-17
Group:                                  Individual Submission
Pages:                                  17
URL:            https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-14.txt
Status:         https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/
Htmlized:       https://tools.ietf.org/html/draft-tcs-coap-no-response-option-14
Diff:           https://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-14

Abstract:
  There can be M2M scenarios where responses from a server against
  requests from client are redundant. This kind of open-loop exchange
  (with no response path from the server to the client) may be desired
  to minimize resource consumption in constrained systems while
  updating a bulk of resources simultaneously, or updating a resource
  with a very high frequency. CoAP already provides a non-confirmable
  (NON) mode of message exchange where the server end-point does not
  respond with ACK. However, obeying the request/response semantics,
  the server end-point responds back with a status code indicating
  "the result of the attempt to understand and satisfy the request".

  This document introduces a header option for CoAP called 'No-
  Response'. Using this option the client can explicitly tell the
  server to suppress all responses against the particular request.
  This option also provides granular control to enable suppression of
  a particular class of response or a combination of response-classes.
  This option may be effective for both unicast and multicast
  requests. This document also discusses a few exemplary applications
  which benefit from this option.

                                                                                 


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

The IETF Secretariat

=====-----=====-----=====
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 0043B00465257F5C_=-- From nobody Wed Feb 17 05:16:39 2016 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 01E8C1A8A3D; Wed, 17 Feb 2016 05:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 c3MQwqJl2AUC; Wed, 17 Feb 2016 05:16:35 -0800 (PST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D494B1B2A5C; Wed, 17 Feb 2016 05:16:34 -0800 (PST) Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 81C26C5A87; Wed, 17 Feb 2016 14:16:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter16-d.gandi.net (mfilter16-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id U_lOHuxL8785; Wed, 17 Feb 2016 14:16:31 +0100 (CET) X-Originating-IP: 193.54.23.146 Received: from [10.138.197.159] (unknown [193.54.23.146]) (Authenticated sender: alex@ackl.io) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 5A584C5A7D; Wed, 17 Feb 2016 14:16:31 +0100 (CET) From: Alexander Pelov Content-Type: multipart/alternative; boundary="Apple-Mail=_D194B7BF-082D-4EE1-8B0C-251D1AD5243E" Message-Id: <76B7C8E4-6AAA-4ADB-91A2-FDCE97EA2E6C@ackl.io> Date: Wed, 17 Feb 2016 14:16:31 +0100 To: "lp-wan@ietf.org" , Core , T2TRG@irtf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [core] Constrained signaling over LP-WAN (CoSOL) update 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, 17 Feb 2016 13:16:37 -0000 --Apple-Mail=_D194B7BF-082D-4EE1-8B0C-251D1AD5243E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, You can find an updated version of the CoSOL draft, which provides a = general overview of a CoAP based approach to network management of = constrained networks. It is a minor update to the previous version, = which takes into account several remarks that have been suggested on the = mailing list and during the last IETF. https://www.ietf.org/internet-drafts/draft-pelov-core-cosol-01.txt = Best, Alexander --Apple-Mail=_D194B7BF-082D-4EE1-8B0C-251D1AD5243E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Dear all,

You can find an updated version of the CoSOL draft, which provides a general overview of a CoAP based approach to network management of constrained networks. It is a minor update to the previous version, which takes into account several remarks that have been suggested on the mailing list and during the last IETF.


Best,
Alexander

--Apple-Mail=_D194B7BF-082D-4EE1-8B0C-251D1AD5243E-- From nobody Thu Feb 18 08:27:38 2016 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 D32FF1B2CE9; Thu, 18 Feb 2016 08:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.205 X-Spam-Level: X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] 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 QmvViX06hDui; Thu, 18 Feb 2016 08:27:32 -0800 (PST) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) by ietfa.amsl.com (Postfix) with ESMTP id 430AD1AD059; Thu, 18 Feb 2016 08:27:30 -0800 (PST) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 41AE82710CD_6C5F0F1B; Thu, 18 Feb 2016 16:27:29 +0000 (GMT) Received: from EXHUB02.org.aalto.fi (exhub02.org.aalto.fi [130.233.222.119]) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTP id B52A22710AA_6C5F0F0F; Thu, 18 Feb 2016 16:27:28 +0000 (GMT) Received: from EXMDB01.org.aalto.fi ([169.254.2.222]) by EXHUB02.org.aalto.fi ([130.233.222.119]) with mapi id 14.03.0224.002; Thu, 18 Feb 2016 18:27:28 +0200 From: Aura Tuomas To: Abhijan Bhattacharyya , Mohit Sethi Thread-Topic: [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt Thread-Index: AQHRYmyDaEz8z8wkLU+ZyRerPC0UrZ8iJdqAgAp5WICAAFk8kA== Date: Thu, 18 Feb 2016 16:27:28 +0000 Message-ID: <7F9C975440487E49BBD35F4FB088ED74CFCDBBAD@EXMDB01.org.aalto.fi> References: <20160208123035.1562.80507.idtracker@ietfa.amsl.com> <56B8B561.8040300@ericsson.com> In-Reply-To: Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.76.33.105] Content-Type: multipart/alternative; boundary="_000_7F9C975440487E49BBD35F4FB088ED74CFCDBBADEXMDB01orgaalto_" MIME-Version: 1.0 Archived-At: Cc: "'t2trg@irtf.org'" , "saag@ietf.org" , "'core@ietf.org'" , "emu@ietf.org" Subject: Re: [core] [saag] Fwd: New Version Notification for draft-aura-eap-noob-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 16:27:35 -0000 --_000_7F9C975440487E49BBD35F4FB088ED74CFCDBBADEXMDB01orgaalto_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWJoaWphbiwNCg0KVGhhbmsgeW91IGZvciB0aGUgcXVlc3Rpb25zLg0KDQpUaGVyZSBpcyBh IG9uZS10by1vbmUgbWFwcGluZyBiZXR3ZWVuIHRoZSBFQVAgc2VydmVyIGFuZCBhdXRoZW50aWNh dG9yLiBUaGUgRUFQIHNlcnZlciBpcyBkZXRlcm1pbmVkIGJ5IGhvdyB0aGUgYXV0aGVudGljYXRv ciBvciBsb2NhbCBBQUEgc2VydmVyIGlzIGNvbmZpZ3VyZWQuIFRoYXQgaXMsIHRoZSBsb2NhbCBu ZXR3b3JrIGFkbWluaXN0cmF0b3JzIGNhbiByb3V0ZSBhY2Nlc3MgcmVxdWVzdHMgZm9yIOKAnEBl YXAtbm9vYi5vcmfigJ0gdG8gYW55IHNlcnZlciB0aGV5IGNob29zZS4NCg0KSW4gb3VyIG93biBz ZXR1cCwgd2UgaGF2ZSBjb25maWd1cmVkIHRoZSBSQURJVVMgc2VydmVyIGF0IG91ciBsb2NhbCB3 aXJlbGVzcyBuZXR3b3JrIHRvIHRydXN0IGFub3RoZXIsIHJlbW90ZSBSQURJVVMgc2VydmVyIGZv ciBOQUlzIHRoYXQgZW5kIOKAnEBlYXAtbm9vYi5vcmfigJ0uIFRoYXQgcmVtb3RlIHNlcnZlciBo YW5kbGVzIEVBUC1OT09CIGZvciBhbGwgdGhlIHN0YXRpb25zIGluIG91ciB3aXJlbGVzcyBuZXR3 b3JrLg0KDQpUdW9tYXMNCg0KUC5TLiBTb3JyeSBhYm91dCB0aGUgY3Jvc3MtcG9zdGluZy4gTGV0 4oCZcyBzZW5kIHRoZSBmb2xsb3ctdXBzIG9ubHkgdG8gc2FhZ0BpZXRmLm9yZzxtYWlsdG86c2Fh Z0BpZXRmLm9yZz4uDQoNCg0KDQpGcm9tOiBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgW21haWx0bzph YmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbV0NClNlbnQ6IE1vbmRheSwgMTUgRmVicnVhcnks IDIwMTYgMDk6MzENClRvOiBNb2hpdCBTZXRoaSA8bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20+ DQpDYzogc2FhZ0BpZXRmLm9yZzsgZW11QGlldGYub3JnOyBBdXJhIFR1b21hcyA8dHVvbWFzLmF1 cmFAYWFsdG8uZmk+OyAnY29yZUBpZXRmLm9yZycgPGNvcmVAaWV0Zi5vcmc+OyAndDJ0cmdAaXJ0 Zi5vcmcnIDx0MnRyZ0BpcnRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2FhZ10gRndkOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWF1cmEtZWFwLW5vb2ItMDAudHh0DQoNCkhpIE1v aGl0LA0KSSB3YXMgZ29pbmcgdGhyb3VnaCB5b3VyIGRyYWZ0LiBMb29rcyB0byBiZSBhIHByb21p c2luZyBwcm9wb3NpdGlvbi4gSG93ZXZlciwgSSBoYXZlIGdvdCBhIGZldyBxdWVzdGlvbnMgZmly c3QgaGFuZC4NCg0KVGhlIGF1dGhlbnRpY2F0b3IgYWN0cyBhcyBhIHRyYW5zcGFyZW50IG5vZGUg YW5kIGZvcndhcmRzIHRoZSBwYWNrZXRzIHRvIHRoZSBzZXJ2ZXIgc29vbiBhZnRlciB0aGUgZmly c3QgbWVzc2FnZSBmb3IgRUFQIElkZW50aXR5IHJlcXVlc3QuIEluIGEgdHlwaWNhbCBuZXR3b3Jr IHdvdWxkIGEgc2luZ2xlIGF1dGhlbnRpY2F0b3IgbWFwIHRvIHNldmVyYWwgc2VydmVycyBvciB0 aGUgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZXJlIGlzIGFsd2F5cyBvbmUgdG8gb25lIG1hcHBpbmcg YmV0d2VlbiBzZXJ2ZXIgYW5kIGF1dGhlbnRpY2F0b3I/DQoNCkhvdyBkb2VzIHRoZSBhdXRoZW50 aWNhdG9yIGFzc29jaWF0ZSBpdHNlbGYgdG8gdGhlIHNlcnZlciBhdCB0aGUgZmlyc3QgcGxhY2U/ DQoNCldoYXQgaXMgdGhlIGFzc3VtcHRpb24gcmVnYXJkaW5nIHRoZSAgdW5kZXJseWluZyBwaHlz aWNhbCBuZXR3b3JrIGFuZCBob3cgdGhlIGF1dGhlbnRpY2F0b3IgbWFwcyB0byB0aGUgZGlmZmVy ZW50IG5vZGVzIGluIHRoZSBuZXR3b3JrIChlLmcuIGEgcm91dGVyIGluIGEgV2lGaSBsaWtlIHNl dHVwKT8NCg0KUmVnYXJkcw0KQWJoaWphbiBCaGF0dGFjaGFyeXlhDQpBc3NvY2lhdGUgQ29uc3Vs dGFudA0KU2NpZW50aXN0LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWENClRhdGEgQ29u c3VsdGFuY3kgU2VydmljZXMNCk1haWx0bzogYWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb208 bWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPg0KV2Vic2l0ZTogaHR0cDovL3d3 dy50Y3MuY29tPGh0dHA6Ly93d3cudGNzLmNvbS8+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRXhwZXJpZW5jZSBjZXJ0YWludHkuICAgICAgICBJVCBTZXJ2 aWNlcw0KICAgICAgICAgICAgICAgICAgICAgICBCdXNpbmVzcyBTb2x1dGlvbnMNCiAgICAgICAg ICAgICAgICAgICAgICAgQ29uc3VsdGluZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KDQoNCg0KRnJvbTogICAgICAgIE1vaGl0IFNldGhpIDxtb2hpdC5t LnNldGhpQGVyaWNzc29uLmNvbTxtYWlsdG86bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20+Pg0K VG86ICAgICAgICA8c2FhZ0BpZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4+LCA8ZW11QGll dGYub3JnPG1haWx0bzplbXVAaWV0Zi5vcmc+Pg0KQ2M6ICAgICAgICB0dW9tYXMuYXVyYUBhYWx0 by5maTxtYWlsdG86dHVvbWFzLmF1cmFAYWFsdG8uZmk+DQpEYXRlOiAgICAgICAgMDIvMDgvMjAx NiAwOToxMCBQTQ0KU3ViamVjdDogICAgICAgIFtzYWFnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQNClNlbnQgYnk6ICAgICAgICAi c2FhZyIgPHNhYWctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2FhZy1ib3VuY2VzQGlldGYub3Jn Pj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpEZWFyIGFsbA0KDQpX ZSBoYXZlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IElFVEYgRHJhZnQgdGl0bGVkIOKAnE5pbWJsZSBv dXQtb2YtYmFuZA0KYXV0aGVudGljYXRpb24gZm9yIEVBUCAoRUFQLU5PT0Ip4oCdLg0KDQpUaGUg ZHJhZnQgZGVmaW5lcyBhbiBFQVAgbWV0aG9kIHdoZXJlIHRoZSBhdXRoZW50aWNhdGlvbiBpcyBi YXNlZCBvbiBhDQp1c2VyLWFzc2lzdGVkIG91dC1vZi1iYW5kIChPT0IpIGNoYW5uZWwgYmV0d2Vl biB0aGUgc2VydmVyIGFuZCBwZWVyLiBJdA0KaXMgaW50ZW5kZWQgYXMgYSBnZW5lcmljIGJvb3Rz dHJhcHBpbmcgc29sdXRpb24gZm9yIEludGVybmV0LW9mLVRoaW5ncw0KZGV2aWNlcyB3aGljaCBo YXZlIG5vIHByZS1jb25maWd1cmVkIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzIGFuZA0Kd2hp Y2ggYXJlIG5vdCB5ZXQgcmVnaXN0ZXJlZCBvbiB0aGUgYXV0aGVudGljYXRpb24gc2VydmVyLiBD b25zaWRlcg0KZGV2aWNlcyB5b3UganVzdCBib3VnaHQgb3IgYm9ycm93ZWQuDQoNClRoZSBFQVAt Tk9PQiBtZXRob2QgaXMgbW9yZSBnZW5lcmljIHRoYW4gbW9zdCBhZC1ob2MgYm9vdHN0cmFwcGlu Zw0Kc29sdXRpb25zIGluIHRoYXQgaXQgc3VwcG9ydHMgbWFueSB0eXBlcyBvZiBPT0IgY2hhbm5l bHMuIFdlIHNwZWNpZnkgdGhlDQpleGFjdCBpbi1iYW5kIG1lc3NhZ2VzIGJ1dCBvbmx5IHRoZSBP T0IgbWVzc2FnZSBjb250ZW50cyBhbmQgbm90IHRoZSBPT0INCmNoYW5uZWwgZGV0YWlscy4gQWxz bywgRUFQLU5PT0Igc3VwcG9ydHMgdWJpY29tcCBkZXZpY2VzIHdpdGggb25seQ0Kb3V0cHV0IChl LmcuIGRpc3BsYXkpIG9yIG9ubHkgaW5wdXQgKGUuZy4gY2FtZXJhKS4gTW9yZW92ZXIsIGl0IG1h a2VzDQpjb21iaW5lZCB1c2Ugb2YgYm90aCBzZWNyZWN5IGFuZCBpbnRlZ3JpdHkgb2YgdGhlIE9P QiBjaGFubmVsIGZvciBtb3JlDQpyb2J1c3Qgc2VjdXJpdHkgdGhhbiB0aGUgYWQtaG9jIHNvbHV0 aW9ucy4gV2UgaGF2ZSBwdXQgYSBsb3Qgb2YgZWZmb3J0DQppbnRvIGRlc2lnbmluZyBhIHJvYnVz dCBzZWN1cml0eSBwcm90b2NvbC4NCg0KRm9yIG9uZSBhcHBsaWNhdGlvbiBleGFtcGxlLCB3ZSBo YXZlIHVzZWQgYW4gZWFybGllciB2ZXJzaW9uIG9mIHRoZQ0KcHJvdG9jb2wgZm9yIGJvb3RzdHJh cHBpbmcgc2VjdXJpdHkgZm9yIHViaXF1aXRvdXMgZGlzcGxheXM6IHRoZSB1c2VyDQpjYW4gY29u ZmlndXJlIHdpcmVsZXNzIG5ldHdvcmsgYWNjZXNzLCBsaW5rIHRoZSBkZXZpY2UgdG8gYSBjbG91 ZA0Kc2VydmljZSwgYW5kIHJlZ2lzdGVyIG93bmVyc2hpcCBvZiB0aGUgZGV2aWNlIGZvciBhIHNw ZWNpZmljIGNsb3VkIHVzZXINCuKAkyBhbGwgaW4gb25lIHNpbXBsZSBzdGVwIG9mIHNjYW5uaW5n IGEgUVIgY29kZSB3aXRoIGEgc21hcnQgcGhvbmUuIFRoZXJlDQpzZWVtZWQgdG8gbW9yZSBwb3Rl bnRpYWwgdG8gdGhpcyBpZGVhIHRoYW4ganVzdCB1c2luZyBpdCBmb3Igb3VyIG93bg0Kc3lzdGVt LCBhbmQgdGh1cyB3ZSBkZWNpZGVkIHRvIHdyaXRlIGEgZ2VuZXJpYyBFQVAgbWV0aG9kIGZvcg0K b3V0LW9mLWJhbmQgYXV0aGVudGljYXRpb24uDQoNClRoZSBkcmFmdCBpcyBhdmFpbGFibGUgaGVy ZToNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hdXJhLWVhcC1ub29iLTAwDQoN ClBsZWFzZSBzZWUgaWYgeW91IGNhbiBtYWtlIHVzZSBvZiBpdC4gV2UgbG9vayBmb3J3YXJkIHRv IHlvdXIgZmVlZGJhY2sNCmFuZCBjb21tZW50cy4NCg0KUmVnYXJkcw0KLy0tTW9oaXQNCg0KDQot LS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDogICAgICAgICAgICAg ICAgICBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWF1cmEtZWFwLW5vb2ItMDAu dHh0DQpEYXRlOiAgICAgICAgICAgICAgICAgIE1vbiwgMDggRmViIDIwMTYgMDQ6MzA6MzUgLTA4 MDANCkZyb206ICAgICAgICAgICAgICAgICAgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpUbzogICAgICAgICAgICAgICAgICBUdW9tYXMg QXVyYSA8dHVvbWFzLmF1cmFAYWFsdG8uZmk8bWFpbHRvOnR1b21hcy5hdXJhQGFhbHRvLmZpPj4s IE1vaGl0IFNldGhpIDxtb2hpdEBwaXVoYS5uZXQ8bWFpbHRvOm1vaGl0QHBpdWhhLm5ldD4+DQoN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVHVvbWFzIEF1cmEgYW5kIHBvc3RlZCB0 byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZHJhZnQtYXVyYS1lYXAtbm9vYg0KUmV2aXNpb246ICAgICAgICAgICAgICAgICAw MA0KVGl0bGU6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5pbWJsZSBvdXQtb2Yt YmFuZCBhdXRoZW50aWNhdGlvbiBmb3IgRUFQIChFQVAtTk9PQikNCkRvY3VtZW50IGRhdGU6ICAg ICAgICAgICAgICAgICAyMDE2LTAyLTA4DQpHcm91cDogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgMzUNClVSTDpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQNClN0YXR1czpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1hdXJhLWVhcC1ub29iLw0KSHRtbGl6ZWQ6aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWF1cmEtZWFwLW5vb2ItMDANCg0KDQpBYnN0cmFjdDoNCiAg IEV4dGVuc2libGUgQXV0aGVudGljYXRpb24gUHJvdG9jb2wgKEVBUCkgW1JGQzM3NDhdIHByb3Zp ZGVzIHN1cHBvcnQNCiAgIGZvciBtdWx0aXBsZSBhdXRoZW50aWNhdGlvbiBtZXRob2RzLiAgVGhp cyBkb2N1bWVudCBkZWZpbmVzIHRoZSBFQVAtDQogICBOT09CIGF1dGhlbnRpY2F0aW9uIG1ldGhv ZCBmb3IgbmltYmxlIG91dC1vZi1iYW5kIChPT0IpDQogICBhdXRoZW50aWNhdGlvbiBhbmQga2V5 IGRlcml2YXRpb24uICBUaGlzIEVBUCBtZXRob2QgaXMgaW50ZW5kZWQgZm9yDQogICBib290c3Ry YXBwaW5nIGFsbCBraW5kcyBvZiBJbnRlcm5ldC1vZi1UaGluZ3MgKElvVCkgZGV2aWNlcyB0aGF0 IGhhdmUNCiAgIGEgbWluaW1hbCB1c2VyIGludGVyZmFjZSBhbmQgbm8gcHJlLWNvbmZpZ3VyZWQg YXV0aGVudGljYXRpb24NCiAgIGNyZWRlbnRpYWxzLiAgVGhlIG1ldGhvZCBtYWtlcyB1c2Ugb2Yg YSB1c2VyLWFzc2lzdGVkIG9uZS1kaXJlY3Rpb25hbA0KICAgT09CIGNoYW5uZWwgYmV0d2VlbiB0 aGUgcGVlciBkZXZpY2UgYW5kIGF1dGhlbnRpY2F0aW9uIHNlcnZlci4NCg0KDQoNCg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzYWFnIG1h aWxpbmcgbGlzdA0Kc2FhZ0BpZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZw0KDQo9PT09PS0tLS0tPT09PT0tLS0t LT09PT09DQpOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwN Cm1lc3NhZ2UgYW5kL29yIGF0dGFjaG1lbnRzIHRvIGl0IG1heSBjb250YWluDQpjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZQ0Kbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0aW9uLCB1c2UsDQpyZXZpZXcsIGRpc3RyaWJ1dGlv biwgcHJpbnRpbmcgb3IgY29weWluZyBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIGUtbWFpbCBtZXNzYWdlDQphbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5 IHByb2hpYml0ZWQuIElmDQp5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4g ZXJyb3IsDQpwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IGUtbWFpbCBvciB0ZWxlcGhvbmUgYW5k DQppbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdlDQphbmQgYW55 IGF0dGFjaG1lbnRzLiBUaGFuayB5b3UNCg== --_000_7F9C975440487E49BBD35F4FB088ED74CFCDBBADEXMDB01orgaalto_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkg QWJoaWphbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5r IHlvdSBmb3IgdGhlIHF1ZXN0aW9ucy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VGhlcmUgaXMgYSBvbmUtdG8tb25lIG1hcHBpbmcgYmV0d2VlbiB0aGUgRUFQ IHNlcnZlciBhbmQgYXV0aGVudGljYXRvci4gVGhlIEVBUCBzZXJ2ZXIgaXMgZGV0ZXJtaW5lZCBi eSBob3cgdGhlIGF1dGhlbnRpY2F0b3Igb3IgbG9jYWwgQUFBIHNlcnZlciBpcyBjb25maWd1cmVk Lg0KIFRoYXQgaXMsIHRoZSBsb2NhbCBuZXR3b3JrIGFkbWluaXN0cmF0b3JzIGNhbiByb3V0ZSBh Y2Nlc3MgcmVxdWVzdHMgZm9yIOKAnEBlYXAtbm9vYi5vcmfigJ0gdG8gYW55IHNlcnZlciB0aGV5 IGNob29zZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SW4g b3VyIG93biBzZXR1cCwgd2UgaGF2ZSBjb25maWd1cmVkIHRoZSBSQURJVVMgc2VydmVyIGF0IG91 ciBsb2NhbCB3aXJlbGVzcyBuZXR3b3JrIHRvIHRydXN0IGFub3RoZXIsIHJlbW90ZSBSQURJVVMg c2VydmVyIGZvciBOQUlzIHRoYXQgZW5kIOKAnEBlYXAtbm9vYi5vcmfigJ0uDQogVGhhdCByZW1v dGUgc2VydmVyIGhhbmRsZXMgRUFQLU5PT0IgZm9yIGFsbCB0aGUgc3RhdGlvbnMgaW4gb3VyIHdp cmVsZXNzIG5ldHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5UdW9tYXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UC5T LiBTb3JyeSBhYm91dCB0aGUgY3Jvc3MtcG9zdGluZy4gTGV04oCZcyBzZW5kIHRoZSBmb2xsb3ct dXBzIG9ubHkgdG8NCjxhIGhyZWY9Im1haWx0bzpzYWFnQGlldGYub3JnIj5zYWFnQGlldGYub3Jn PC9hPi4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQWJoaWphbiBCaGF0dGFjaGFy eXlhIFttYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb21dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gTW9uZGF5LCAxNSBGZWJydWFyeSwgMjAxNiAwOTozMTxicj4NCjxiPlRvOjwvYj4gTW9o aXQgU2V0aGkgJmx0O21vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gc2FhZ0BpZXRmLm9yZzsgZW11QGlldGYub3JnOyBBdXJhIFR1b21hcyAmbHQ7dHVvbWFzLmF1 cmFAYWFsdG8uZmkmZ3Q7OyAnY29yZUBpZXRmLm9yZycgJmx0O2NvcmVAaWV0Zi5vcmcmZ3Q7OyAn dDJ0cmdAaXJ0Zi5vcmcnICZsdDt0MnRyZ0BpcnRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtzYWFnXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYXVy YS1lYXAtbm9vYi0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPkhpIE1vaGl0LDwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkkgd2FzIGdvaW5n IHRocm91Z2ggeW91ciBkcmFmdC4gTG9va3MgdG8gYmUgYSBwcm9taXNpbmcgcHJvcG9zaXRpb24u IEhvd2V2ZXIsIEkgaGF2ZSBnb3QgYSBmZXcgcXVlc3Rpb25zIGZpcnN0IGhhbmQuPC9zcGFuPg0K PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGF1dGhlbnRpY2F0b3IgYWN0cyBhcyBhIHRy YW5zcGFyZW50IG5vZGUgYW5kIGZvcndhcmRzIHRoZSBwYWNrZXRzIHRvIHRoZSBzZXJ2ZXIgc29v biBhZnRlciB0aGUgZmlyc3QgbWVzc2FnZSBmb3IgRUFQIElkZW50aXR5IHJlcXVlc3QuIEluIGEg dHlwaWNhbCBuZXR3b3JrIHdvdWxkIGEgc2luZ2xlIGF1dGhlbnRpY2F0b3IgbWFwIHRvDQogc2V2 ZXJhbCBzZXJ2ZXJzIG9yIHRoZSBhc3N1bXB0aW9uIGlzIHRoYXQgdGhlcmUgaXMgYWx3YXlzIG9u ZSB0byBvbmUgbWFwcGluZyBiZXR3ZWVuIHNlcnZlciBhbmQgYXV0aGVudGljYXRvcj8NCjwvc3Bh bj48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Ib3cgZG9lcyB0aGUgYXV0aGVudGljYXRvciBh c3NvY2lhdGUgaXRzZWxmIHRvIHRoZSBzZXJ2ZXIgYXQgdGhlIGZpcnN0IHBsYWNlPzwvc3Bhbj4N Cjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPldoYXQgaXMgdGhlIGFzc3VtcHRpb24gcmVnYXJk aW5nIHRoZSAmbmJzcDt1bmRlcmx5aW5nIHBoeXNpY2FsIG5ldHdvcmsgYW5kIGhvdyB0aGUgYXV0 aGVudGljYXRvciBtYXBzIHRvIHRoZSBkaWZmZXJlbnQgbm9kZXMgaW4gdGhlIG5ldHdvcmsgKGUu Zy4gYSByb3V0ZXIgaW4gYSBXaUZpIGxpa2Ugc2V0dXApPzwvc3Bhbj4NCjxicj4NCjxicj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPlJlZ2FyZHM8YnI+DQpBYmhpamFuIEJoYXR0YWNoYXJ5eWE8YnI+DQpBc3Nv Y2lhdGUgQ29uc3VsdGFudDxicj4NClNjaWVudGlzdCwgSW5ub3ZhdGlvbiBMYWIsIEtvbGthdGEs IEluZGlhPGJyPg0KVGF0YSBDb25zdWx0YW5jeSBTZXJ2aWNlczxicj4NCk1haWx0bzogPC9zcGFu PjxhIGhyZWY9Im1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFAdGNzLmNvbSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPjxicj4NCldlYnNpdGU6IDwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LnRjcy5jb20vIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5odHRwOi8vd3d3LnRjcy5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K RXhwZXJpZW5jZSBjZXJ0YWludHkuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lUIFNlcnZp Y2VzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtCdXNpbmVzcyBTb2x1dGlvbnM8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NvbnN1bHRpbmc8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzVGNUY1RiI+RnJvbTogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TW9oaXQgU2V0aGkgJmx0Ozwvc3Bh bj48YSBocmVmPSJtYWlsdG86bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 Ozwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNUY1RjVGIj5UbzogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jmx0Ozwvc3Bhbj48YSBocmVm PSJtYWlsdG86c2FhZ0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5zYWFnQGlldGYub3JnPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDssDQogJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZW11 QGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmVtdUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1RjVGNUYiPkNjOiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnR1b21hcy5h dXJhQGFhbHRvLmZpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPnR1b21hcy5hdXJhQGFhbHRvLmZpPC9zcGFuPjwv YT4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNUY1RjVGIj5EYXRlOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4wMi8wOC8yMDE2IDA5OjEwIFBNPC9z cGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1RjVGNUYiPlN1YmplY3Q6ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPltzYWFnXSBGd2Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQ8L3NwYW4+ DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzVGNUY1RiI+U2VudCBieTogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+JnF1b3Q7c2FhZyZxdW90OyAmbHQ7 PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzYWFnLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+c2FhZy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3Nw YW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSI0IiB3aWR0aD0iMTAwJSIg bm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6I0EwQTBBMCIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K PGJyPg0KPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5EZWFyIGFsbDwv c3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8YnI+DQo8dHQ+V2UgaGF2ZSBqdXN0IHN1Ym1pdHRl ZCBhIG5ldyBJRVRGIERyYWZ0IHRpdGxlZCDigJxOaW1ibGUgb3V0LW9mLWJhbmQgPC90dD48YnI+ DQo8dHQ+YXV0aGVudGljYXRpb24gZm9yIEVBUCAoRUFQLU5PT0Ip4oCdLjwvdHQ+PGJyPg0KPGJy Pg0KPHR0PlRoZSBkcmFmdCBkZWZpbmVzIGFuIEVBUCBtZXRob2Qgd2hlcmUgdGhlIGF1dGhlbnRp Y2F0aW9uIGlzIGJhc2VkIG9uIGEgPC90dD48YnI+DQo8dHQ+dXNlci1hc3Npc3RlZCBvdXQtb2Yt YmFuZCAoT09CKSBjaGFubmVsIGJldHdlZW4gdGhlIHNlcnZlciBhbmQgcGVlci4gSXQgPC90dD4N Cjxicj4NCjx0dD5pcyBpbnRlbmRlZCBhcyBhIGdlbmVyaWMgYm9vdHN0cmFwcGluZyBzb2x1dGlv biBmb3IgSW50ZXJuZXQtb2YtVGhpbmdzIDwvdHQ+PGJyPg0KPHR0PmRldmljZXMgd2hpY2ggaGF2 ZSBubyBwcmUtY29uZmlndXJlZCBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscyBhbmQgPC90dD48 YnI+DQo8dHQ+d2hpY2ggYXJlIG5vdCB5ZXQgcmVnaXN0ZXJlZCBvbiB0aGUgYXV0aGVudGljYXRp b24gc2VydmVyLiBDb25zaWRlciA8L3R0Pjxicj4NCjx0dD5kZXZpY2VzIHlvdSBqdXN0IGJvdWdo dCBvciBib3Jyb3dlZC48L3R0Pjxicj4NCjxicj4NCjx0dD5UaGUgRUFQLU5PT0IgbWV0aG9kIGlz IG1vcmUgZ2VuZXJpYyB0aGFuIG1vc3QgYWQtaG9jIGJvb3RzdHJhcHBpbmcgPC90dD48YnI+DQo8 dHQ+c29sdXRpb25zIGluIHRoYXQgaXQgc3VwcG9ydHMgbWFueSB0eXBlcyBvZiBPT0IgY2hhbm5l bHMuIFdlIHNwZWNpZnkgdGhlIDwvdHQ+DQo8YnI+DQo8dHQ+ZXhhY3QgaW4tYmFuZCBtZXNzYWdl cyBidXQgb25seSB0aGUgT09CIG1lc3NhZ2UgY29udGVudHMgYW5kIG5vdCB0aGUgT09CIDwvdHQ+ DQo8YnI+DQo8dHQ+Y2hhbm5lbCBkZXRhaWxzLiBBbHNvLCBFQVAtTk9PQiBzdXBwb3J0cyB1Ymlj b21wIGRldmljZXMgd2l0aCBvbmx5IDwvdHQ+PGJyPg0KPHR0Pm91dHB1dCAoZS5nLiBkaXNwbGF5 KSBvciBvbmx5IGlucHV0IChlLmcuIGNhbWVyYSkuIE1vcmVvdmVyLCBpdCBtYWtlcyA8L3R0Pjxi cj4NCjx0dD5jb21iaW5lZCB1c2Ugb2YgYm90aCBzZWNyZWN5IGFuZCBpbnRlZ3JpdHkgb2YgdGhl IE9PQiBjaGFubmVsIGZvciBtb3JlIDwvdHQ+PGJyPg0KPHR0PnJvYnVzdCBzZWN1cml0eSB0aGFu IHRoZSBhZC1ob2Mgc29sdXRpb25zLiBXZSBoYXZlIHB1dCBhIGxvdCBvZiBlZmZvcnQgPC90dD48 YnI+DQo8dHQ+aW50byBkZXNpZ25pbmcgYSByb2J1c3Qgc2VjdXJpdHkgcHJvdG9jb2wuPC90dD48 YnI+DQo8YnI+DQo8dHQ+Rm9yIG9uZSBhcHBsaWNhdGlvbiBleGFtcGxlLCB3ZSBoYXZlIHVzZWQg YW4gZWFybGllciB2ZXJzaW9uIG9mIHRoZSA8L3R0Pjxicj4NCjx0dD5wcm90b2NvbCBmb3IgYm9v dHN0cmFwcGluZyBzZWN1cml0eSBmb3IgdWJpcXVpdG91cyBkaXNwbGF5czogdGhlIHVzZXIgPC90 dD48YnI+DQo8dHQ+Y2FuIGNvbmZpZ3VyZSB3aXJlbGVzcyBuZXR3b3JrIGFjY2VzcywgbGluayB0 aGUgZGV2aWNlIHRvIGEgY2xvdWQgPC90dD48YnI+DQo8dHQ+c2VydmljZSwgYW5kIHJlZ2lzdGVy IG93bmVyc2hpcCBvZiB0aGUgZGV2aWNlIGZvciBhIHNwZWNpZmljIGNsb3VkIHVzZXIgPC90dD4N Cjxicj4NCjx0dD7igJMgYWxsIGluIG9uZSBzaW1wbGUgc3RlcCBvZiBzY2FubmluZyBhIFFSIGNv ZGUgd2l0aCBhIHNtYXJ0IHBob25lLiBUaGVyZSA8L3R0Pg0KPGJyPg0KPHR0PnNlZW1lZCB0byBt b3JlIHBvdGVudGlhbCB0byB0aGlzIGlkZWEgdGhhbiBqdXN0IHVzaW5nIGl0IGZvciBvdXIgb3du IDwvdHQ+PGJyPg0KPHR0PnN5c3RlbSwgYW5kIHRodXMgd2UgZGVjaWRlZCB0byB3cml0ZSBhIGdl bmVyaWMgRUFQIG1ldGhvZCBmb3IgPC90dD48YnI+DQo8dHQ+b3V0LW9mLWJhbmQgYXV0aGVudGlj YXRpb24uPC90dD48YnI+DQo8YnI+DQo8dHQ+VGhlIGRyYWZ0IGlzIGF2YWlsYWJsZSBoZXJlOjwv dHQ+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1hdXJhLWVhcC1ub29iLTAwIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hdXJhLWVhcC1ub29iLTAwPC9zcGFuPjwv dHQ+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8YnI+DQo8dHQ+UGxlYXNlIHNlZSBpZiB5b3UgY2FuIG1h a2UgdXNlIG9mIGl0LiBXZSBsb29rIGZvcndhcmQgdG8geW91ciBmZWVkYmFjayA8L3R0Pjxicj4N Cjx0dD5hbmQgY29tbWVudHMuPC90dD48YnI+DQo8YnI+DQo8dHQ+UmVnYXJkczwvdHQ+PGJyPg0K PHR0Pi8tLU1vaGl0PC90dD48YnI+DQo8YnI+DQo8YnI+DQo8dHQ+LS0tLS0tLS0gRm9yd2FyZGVk IE1lc3NhZ2UgLS0tLS0tLS08L3R0Pjxicj4NCjx0dD5TdWJqZWN0OiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO05ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQ8L3R0Pjxicj4NCjx0 dD5EYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO01vbiwgMDggRmViIDIwMTYgMDQ6MzA6MzUgLTA4MDA8L3R0Pjxicj4NCjx0 dD5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzwvdHQ+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48YnI+DQo8dHQ+VG86ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VHVvbWFzIEF1cmEgJmx0OzwvdHQ+PC9zcGFuPjxh IGhyZWY9Im1haWx0bzp0dW9tYXMuYXVyYUBhYWx0by5maSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnR1b21hcy5hdXJh QGFhbHRvLmZpPC9zcGFuPjwvYT48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZn dDssIE1vaGl0IFNldGhpICZsdDs8L3NwYW4+PC90dD48YSBocmVmPSJtYWlsdG86bW9oaXRAcGl1 aGEubmV0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+bW9oaXRAcGl1aGEubmV0PC9zcGFuPjwvYT48dHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDs8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHR0PkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1hdXJhLWVhcC1u b29iLTAwLnR4dDwvdHQ+PGJyPg0KPHR0PmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgVHVvbWFzIEF1cmEgYW5kIHBvc3RlZCB0byB0aGU8L3R0Pjxicj4NCjx0dD5JRVRGIHJlcG9z aXRvcnkuPC90dD48YnI+DQo8YnI+DQo8dHQ+TmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWF1cmEtZWFwLW5vb2I8 L3R0Pjxicj4NCjx0dD5SZXZpc2lvbjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAwMDwvdHQ+PGJyPg0KPHR0PlRpdGxlOiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TmltYmxl IG91dC1vZi1iYW5kIGF1dGhlbnRpY2F0aW9uIGZvciBFQVAgKEVBUC1OT09CKTwvdHQ+PGJyPg0K PHR0PkRvY3VtZW50IGRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgMjAxNi0wMi0wODwvdHQ+PGJyPg0KPHR0Pkdyb3VwOiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5k aXZpZHVhbCBTdWJtaXNzaW9uPC90dD48YnI+DQo8dHQ+UGFnZXM6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDszNTwvdHQ+PGJyPg0K PHR0PlVSTDo8L3R0Pjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtYXVyYS1lYXAtbm9vYi0wMC50eHQiPjx0dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWF1cmEtZWFwLW5vb2ItMDAudHh0PC9zcGFuPjwvdHQ+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+ U3RhdHVzOjwvdHQ+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWF1cmEtZWFwLW5vb2IvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWF1cmEtZWFwLW5vb2Iv PC9zcGFuPjwvdHQ+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+SHRtbGl6ZWQ6PC90dD48L3NwYW4+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWF1cmEtZWFwLW5vb2It MDAiPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWF1cmEtZWFwLW5vb2ItMDA8L3NwYW4+PC90dD48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pjxicj4NCjxicj4NCjxicj4NCjx0dD5BYnN0cmFjdDo8L3R0Pjxicj4NCjx0dD4mbmJzcDsgJm5i c3A7RXh0ZW5zaWJsZSBBdXRoZW50aWNhdGlvbiBQcm90b2NvbCAoRUFQKSBbUkZDMzc0OF0gcHJv dmlkZXMgc3VwcG9ydDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyAmbmJzcDtmb3IgbXVsdGlwbGUgYXV0 aGVudGljYXRpb24gbWV0aG9kcy4gJm5ic3A7VGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBFQVAt PC90dD48YnI+DQo8dHQ+Jm5ic3A7ICZuYnNwO05PT0IgYXV0aGVudGljYXRpb24gbWV0aG9kIGZv ciBuaW1ibGUgb3V0LW9mLWJhbmQgKE9PQik8L3R0Pjxicj4NCjx0dD4mbmJzcDsgJm5ic3A7YXV0 aGVudGljYXRpb24gYW5kIGtleSBkZXJpdmF0aW9uLiAmbmJzcDtUaGlzIEVBUCBtZXRob2QgaXMg aW50ZW5kZWQgZm9yPC90dD48YnI+DQo8dHQ+Jm5ic3A7ICZuYnNwO2Jvb3RzdHJhcHBpbmcgYWxs IGtpbmRzIG9mIEludGVybmV0LW9mLVRoaW5ncyAoSW9UKSBkZXZpY2VzIHRoYXQgaGF2ZTwvdHQ+ PGJyPg0KPHR0PiZuYnNwOyAmbmJzcDthIG1pbmltYWwgdXNlciBpbnRlcmZhY2UgYW5kIG5vIHBy ZS1jb25maWd1cmVkIGF1dGhlbnRpY2F0aW9uPC90dD48YnI+DQo8dHQ+Jm5ic3A7ICZuYnNwO2Ny ZWRlbnRpYWxzLiAmbmJzcDtUaGUgbWV0aG9kIG1ha2VzIHVzZSBvZiBhIHVzZXItYXNzaXN0ZWQg b25lLWRpcmVjdGlvbmFsPC90dD48YnI+DQo8dHQ+Jm5ic3A7ICZuYnNwO09PQiBjaGFubmVsIGJl dHdlZW4gdGhlIHBlZXIgZGV2aWNlIGFuZCBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIuPC90dD48YnI+ DQo8YnI+DQo8dHQ+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KPC90dD48YnI+DQo8YnI+DQo8YnI+DQo8dHQ+UGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbjwvdHQ+PGJyPg0KPHR0PnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPC90dD48YnI+DQo8YnI+DQo8dHQ+VGhlIElF VEYgU2VjcmV0YXJpYXQ8L3R0Pjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0dD5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvdHQ+PGJyPg0KPHR0PnNhYWcg bWFpbGluZyBsaXN0PC90dD48YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNhYWdAaWV0Zi5v cmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5zYWFnQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZyI+ PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NhYWc8L3NwYW4+PC90dD48L2E+PG86cD48L286cD48L3A+DQo8cD49 PT09PS0tLS0tPT09PT0tLS0tLT09PT09PGJyPg0KTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgZS1tYWlsPGJyPg0KbWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMgdG8g aXQgbWF5IGNvbnRhaW4gPGJyPg0KY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24uIElmIHlvdSBhcmUgPGJyPg0Kbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNz ZW1pbmF0aW9uLCB1c2UsIDxicj4NCnJldmlldywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBj b3B5aW5nIG9mIHRoZSA8YnI+DQppbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwg bWVzc2FnZSA8YnI+DQphbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hp Yml0ZWQuIElmIDxicj4NCnlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBl cnJvciwgPGJyPg0KcGxlYXNlIG5vdGlmeSB1cyBieSByZXBseSBlLW1haWwgb3IgdGVsZXBob25l IGFuZCA8YnI+DQppbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdl IDxicj4NCmFuZCBhbnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7F9C975440487E49BBD35F4FB088ED74CFCDBBADEXMDB01orgaalto_-- From nobody Fri Feb 19 07:02:10 2016 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A7D1B30F1; Fri, 19 Feb 2016 07:00:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160219150042.12357.86071.idtracker@ietfa.amsl.com> Date: Fri, 19 Feb 2016 07:00:42 -0800 Archived-At: X-Mailman-Approved-At: Fri, 19 Feb 2016 07:02:09 -0800 Cc: cabo@tzi.uni-bremen.de, barryleiba@computer.org, core-chairs@ietf.org, core@ietf.org Subject: [core] core - New Meeting Session Request for IETF 95 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 15:00:42 -0000 A new meeting session request has just been submitted by Dr. Carsten Bormann, a Chair of the core working group. --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Carsten Bormann Number of Sessions: 2 Length of Session(s): 1.5 Hours, 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: 6lo roll lwig appsawg tsvwg tcpm aqm ace jose cose t2trg Second Priority: 6man saag 6tisch dnssd netconf Third Priority: v6ops opsarea cfrg Special Requests: Prfrbly (pri 2), ≥ 1 of the 2 mtgs wth no cnflct in: "tls oauth jose uta" Pls avd othr IoT rltd BOFs tht mght cm up, sch as lpwan or its. *Prfrrd* pairing: Tue/Thu spce btwn Fri psbl. --------------------------------------------------------- From nobody Fri Feb 19 07:06:48 2016 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 6CF511B3111 for ; Fri, 19 Feb 2016 07:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZlE2XQneaQ5 for ; Fri, 19 Feb 2016 07:06:45 -0800 (PST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA96E1B312C for ; Fri, 19 Feb 2016 07:06:37 -0800 (PST) Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 0E5A941C0FC; Fri, 19 Feb 2016 16:06:36 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter16-d.gandi.net (mfilter16-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 0-M5isY85n6I; Fri, 19 Feb 2016 16:06:34 +0100 (CET) X-Originating-IP: 134.102.91.240 Received: from eduroam-pool10-497.wlan.uni-bremen.de (eduroam-pool10-497.wlan.uni-bremen.de [134.102.91.240]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 0B9A341C0A9; Fri, 19 Feb 2016 16:06:33 +0100 (CET) Message-ID: <56C72F78.1070805@tzi.org> Date: Fri, 19 Feb 2016 16:06:32 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: core@ietf.org References: <20160219150042.12357.86071.idtracker@ietfa.amsl.com> In-Reply-To: <20160219150042.12357.86071.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] core - New Meeting Session Request for IETF 95 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, 19 Feb 2016 15:06:47 -0000 Summary: We are planning to have a normal CoRE meeting at IETF95. "IETF Meeting Session Request Tool" wrote: > Prfrbly (pri 2), ≥ 1 of the 2 mtgs wth no cnflct in: "tls oauth jose uta" > Pls avd othr IoT rltd BOFs tht mght cm up, sch as lpwan or its. > *Prfrrd* pairing: Tue/Thu spce btwn > Fri psbl. If anyone wonders if I have completely lost my mind: This is a field that is inexplicably limited to 200 characters, so it is hard to put all needed information in there. Grüße, Carsten From nobody Mon Feb 29 02:04:01 2016 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 A57F31B2F48 for ; Mon, 29 Feb 2016 02:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, 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 cd9Hhlu_zB-n for ; Mon, 29 Feb 2016 02:03:58 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254D11B2F47 for ; Mon, 29 Feb 2016 02:03:57 -0800 (PST) Received: from [192.168.10.140] ([80.92.123.193]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MMBun-1aXIHO3toz-007zTq for ; Mon, 29 Feb 2016 11:03:56 +0100 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56D4178A.6040302@gmx.net> Date: Mon, 29 Feb 2016 11:03:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="638Htn3iPq1rTLVVdVuvPHbaADmMoMsA3" X-Provags-ID: V03:K0:rrikFwrdZWsa+kSx3SVITQbbjucd+zoijV2teHc0RIAWtQKTPlE fSLtfkjiRV9/kRNM3EkFUAciGMHG1TmnnzS7gel/BOWfS7lNSbJ0e3v8kwNNBaVP/t0xylN jyJYpcL/12HVqPOkjzdN8/Cim4lC+y5LZCgUswdKHwCaPHJDhLVsAOtSUg65Xl+IoaKul+5 tkn18uHKJC+8H0p/BXH8w== X-UI-Out-Filterresults: notjunk:1;V01:K0:ArYG9GrsIYc=:MgZanp89euOOASOzq8ZVsB e/FDMKYf8tDayoe2nkPEWWJVABklXTcCyLe8iDlrKt50TZYV8bXJGFkyudyRaI4wpaC/PIGpE 6R5ruW5IbwBENZB32DjRdPbyK5SSQywk9+7r30tA/UKBfvE+dcOJAUslkDUF+fFPGkvUnfpVI aZIgJIaFV8BXzBLvj4WomUOttaD/NPDz6I/lZlj9LFf8FxElqeI9IjzeilI81WFDgsxFlQWQi Dihp2FOYzbVSMeluYwsc3Z3G/jpq7b1lzEfVpR+rS4u6NpdR5HvEFgceafQaZRJzUE8qyPupa USMAeW2pYNfaZUYgRQv6LtuINlsWJkdO7A7hNRKVtSWzZHgfHYPMul8k39ZM2TiJNeUKDHStf rbupqHfDxXlX1FXhZ1GMnOQ6EUyTDrdsFTc9zEjrWTPGsKluF41B9AHGL7/OwpFbifIwFioFg VqrKDkCZdZRmz/GjKeNDsHWCKYTHc9yD6nLW5kVjEn0BMSwoJkhD/LfVDEkKW3NDuSs1wkltr 8m8AVcNXq02/7KK5KQpmk8oR+BU6R5FbvzJwscNfaHf+AjMzjQHiWxVvyH1B3F3V1mhlpNsdS c0X1oS5i81LMQOvY1Frt+mb2xhfwGwqdeV+Kw38E5y4oepXxrTNZxpgxguw5sFJcWAa9xvBDz 1qWlSKn/HvE3nMj1ayDtJBJpjldRSlluPv6qsw2iKCIpXeD4CIgmxOTpnmXwMMYsfh/0M6g4F 2myd7uH+mjIDon4mftrj6re4bVz5JuR8t+A1Z9MRFmBo5TH4SO4PBQzaJJI= Archived-At: Subject: [core] Introducing Server Name Identifiers in Certificates 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, 29 Feb 2016 10:04:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --638Htn3iPq1rTLVVdVuvPHbaADmMoMsA3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, working on the DTLS/TLS profile document Thomas and I realized that there are some challenges when certificates are used for IoT devices. For this reason we published already early 2015. When Thomas presented the draft at IETF #92 it triggered a fair amount of discussion and we got lots of good feedback from several CORE working group participants. Some time passed and the work on the DTLS/TLS profile draft finished but we haven't forgotten the feedback and have now re-written the document. Here is the link to the new document: https://tools.ietf.org/html/draft-fossati-core-server-name-id-00 The easiest way is to read Section 1 ("Introduction") and Section 8 ("Example") to see what we are trying to accomplish. Ciao Hannes --638Htn3iPq1rTLVVdVuvPHbaADmMoMsA3 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 iQEcBAEBCgAGBQJW1BeKAAoJEGhJURNOOiAtDC8H/3WXZwU1UNkaMLgAw9vc76nQ 3SSFKfjO6Nl+h/nhYDpMu1SpWNTv9HJfLk0VQU2oFet2IPvermayOVDDXRDQhX4y Jqgfe6EkGKxVLm91b+8KOuHW8ei6XQu6noEUakGLXPCKtvY9t3DHjqCcUzPJktT+ afLPLZXflpcJfAuBhtJmBGdXTM0xEdcLJlCCu0r8A+NaNR+OdmQwFH3MZgS/kxrr au86XMBByiE9T4HkxhPfHOLUwHhdN4EV3cozsWdSRzVhZ4kbhE3L5N1OpctWH7sV ErgQwPhfQ8DgtIO4ODfQkrMcM4LOop2GykUMBync6spL3RaRwX9FnIY0tciJF7Q= =jW7g -----END PGP SIGNATURE----- --638Htn3iPq1rTLVVdVuvPHbaADmMoMsA3--